From db9b65b80ffab503a5e987a4cff0f89662f701ce Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Mon, 18 May 2020 17:29:02 +0000
Subject: [PATCH 001/749] [Security] Bump activesupport from 6.0.2.1 to 6.0.3.1

Bumps [activesupport](https://github.com/rails/rails) from 6.0.2.1 to 6.0.3.1. **This update includes a security fix.**
- [Release notes](https://github.com/rails/rails/releases)
- [Changelog](https://github.com/rails/rails/blob/v6.0.3.1/activesupport/CHANGELOG.md)
- [Commits](https://github.com/rails/rails/compare/v6.0.2.1...v6.0.3.1)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 86d4efefbc6..a81214f5996 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,12 +1,12 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (6.0.2.1)
+    activesupport (6.0.3.1)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
       tzinfo (~> 1.1)
-      zeitwerk (~> 2.2)
+      zeitwerk (~> 2.2, >= 2.2.2)
     addressable (2.7.0)
       public_suffix (>= 2.0.2, < 5.0)
     coffee-script (2.4.1)
@@ -16,7 +16,7 @@ GEM
     colorator (1.1.0)
     commonmarker (0.17.13)
       ruby-enum (~> 0.5)
-    concurrent-ruby (1.1.5)
+    concurrent-ruby (1.1.6)
     dnsruby (1.61.3)
       addressable (~> 2.5)
     em-websocket (0.5.1)
@@ -210,7 +210,7 @@ GEM
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
-    minitest (5.14.0)
+    minitest (5.14.1)
     multipart-post (2.1.1)
     nokogiri (1.10.9)
       mini_portile2 (~> 2.4.0)
@@ -246,11 +246,11 @@ GEM
     thread_safe (0.3.6)
     typhoeus (1.3.1)
       ethon (>= 0.9.0)
-    tzinfo (1.2.6)
+    tzinfo (1.2.7)
       thread_safe (~> 0.1)
     unicode-display_width (1.6.1)
     yell (2.2.2)
-    zeitwerk (2.2.2)
+    zeitwerk (2.3.0)
 
 PLATFORMS
   ruby

From a3d2b00272adbba7befac295befdc2db3dd9428f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Wed, 20 May 2020 19:55:42 +0000
Subject: [PATCH 002/749] Translate starting-a-project.md via GitLocalize

---
 _articles/tr/starting-a-project.md | 116 ++++++++++-------------------
 1 file changed, 40 insertions(+), 76 deletions(-)

diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index d6eb2e2deda..14442735d40 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -26,25 +26,19 @@ Bir proje açık kaynak olduğunda, **herhangi biri herhangi bir amaç için pro
 
 Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek, benimseme engellerini azaltır. Ayrıca, kullanıcılara kapalı kaynağa göre kendi bilgisayarlarını ve bilgisayarlarında çalışan işlemleri kontrol etme imkanı da verir. Örneğin, açık kaynak yazılım kullanan bir işletme, yalnızca kapalı kaynak satıcısının ürün kararlarına güvenmek yerine, bir kişiyi yazılımda özel iyileştirmeler yapması için işe alma seçeneğine sahiptir.
 
-_Özgür yazılım_ , _açık kaynak ile_ aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. _Free_ ve  _Libre_ özgürlüğe atıfta bulunur [fiyata değil](#açık-kaynak-ücretsiz-anlamına-mı-geliyor).
+*Özgür yazılım* , *açık kaynak ile* aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. *Free* ve  *Libre* özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor).
 
 ### İnsanlar neden işlerini açık kaynak olarak sunarlar?
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
-    Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.
-  <p markdown="1" class="pquote-credit">
-— @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">     Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.   <p markdown="1" class="pquote-credit"> — @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)   </p> </aside>
 
 Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler:
 
-* **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur.
+- **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur.
 
-* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
+- **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
 
-* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
+- **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
 
 Açık kaynak sadece yazılım için değil. Veri kümelerinden kitaplara kadar her şeyi açık kaynak koduyla açabilirsiniz. Açık kaynak başka neler yapabileceğiniz hakkında fikir edinmek için [GitHub Explore](https://github.com/explore)'a göz atın.
 
@@ -68,19 +62,13 @@ Henüz ikna olmadıysanız, hedeflerinizin ne olabileceğini düşünmek için b
 
 ### Hedeflerinizi belirlemek
 
-Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, _neden bu projeye kaynak açıyorum?_
+Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, *neden bu projeye kaynak açıyorum?*
 
 Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahip farklı projeler için birden fazla hedefiniz olabilir.
 
 Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız.
 
-<aside markdown="1" class="pquote">
-   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
-   Bir noktada kullandığım özel bir UIAlertView yarattım ... ve açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca diğer geliştiricilere projelerinde nasıl kullanacaklarını açıklayan ilk belgelerimi yazdım. Muhtemelen hiç kimse onu kullanmamıştı çünkü basit bir projeydi ama katkım konusunda kendimi iyi hissediyordum.
-   <p markdown="1" class="pquote-credit">
-— @mavris, ["Kendi Kendine Öğrenen Yazılım Geliştiricileri: Açık Kaynak Neden Bizim İçin Önemli?"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
-   </p>
-</aside>
+<aside markdown="1" class="pquote">    <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">    Bir noktada kullandığım özel bir UIAlertView yarattım ... ve açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca diğer geliştiricilere projelerinde nasıl kullanacaklarını açıklayan ilk belgelerimi yazdım. Muhtemelen hiç kimse onu kullanmamıştı çünkü basit bir projeydi ama katkım konusunda kendimi iyi hissediyordum.    <p markdown="1" class="pquote-credit"> — @mavris, ["Kendi Kendine Öğrenen Yazılım Geliştiricileri: Açık Kaynak Neden Bizim İçin Önemli?"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)    </p> </aside>
 
 Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir.
 
@@ -90,13 +78,7 @@ Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve
 
 Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın.
 
-<aside markdown="1" class="pquote">
-   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-   Projeyi açmaya başladığınızda, yönetim süreçlerinizin projenizdeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. İşletmenizde istihdam edilmeyen katılımcıları, projenin kilit noktalarına dahil etmekten korkmayın - özellikle de sık sık katkıda bulunanlarsa.
-   <p markdown="1" class="pquote-credit">
-— @captainsafia, ["Öyleyse bir açık kaynak proje açmak istiyorsun, ha?"](Https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
-   </p>
-</aside>
+<aside markdown="1" class="pquote">    <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">    Projeyi açmaya başladığınızda, yönetim süreçlerinizin projenizdeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. İşletmenizde istihdam edilmeyen katılımcıları, projenin kilit noktalarına dahil etmekten korkmayın - özellikle de sık sık katkıda bulunanlarsa.    <p markdown="1" class="pquote-credit"> — @captainsafia, ["Öyleyse bir açık kaynak proje açmak istiyorsun, ha?"](Https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)    </p> </aside>
 
 ### Diğer projelere katkıda bulunmak
 
@@ -112,10 +94,10 @@ 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/)
-* [Davranış kuralları](../code-of-conduct/)
+- [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/)
+- [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.
 
@@ -125,7 +107,7 @@ Projeniz GitHub'taysa, bu dosyaları önerilen dosya adlarıyla kök dizininize
 
 Açık kaynaklı lisans, başkalarının projenize yanıt vermeden kullanabileceğini, kopyalayabileceğini, değiştirebileceğini ve katkıda bulunabileceğini garanti eder. Aynı zamanda sizi kötü yasal durumlardan korur. **Açık kaynak kodlu bir proje başlatırken projenize bir lisans eklemelisiniz.**
 
-Hukiki işler eğlenceli değildir. İyi haber şu ki, mevcut bir lisansı kopyalayıp havuzunuza yapıştırabilirsiniz. Zor işinizi korumak sadece bir dakikanızı alacaktır.
+Açık kaynaklı lisans, başkalarının projenize yanıt vermeden kullanabileceğini, kopyalayabileceğini, değiştirebileceğini ve katkıda bulunabileceğini garanti eder. Aynı zamanda sizi kötü yasal durumlardan korur. **Açık kaynak kodlu bir proje başlatırken projenize bir lisans eklemelisiniz.**
 
 [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](https://choosealicense.com) de vardır.
 
@@ -139,42 +121,36 @@ Açık kaynak kodlu bir projeyi yönetmenin yasal yönleri hakkında başka soru
 
 README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar.
 
-README'nizde aşağıdaki soruları cevaplamaya çalışın:
+In your README, try to answer the following questions:
 
-* Bu proje ne yapıyor?
-* Bu proje neden faydalıdır?
-* Kullanmaya nasıl başlarım?
-* İhtiyacım olursa nereden daha fazla yardım alabilirim?
+- Bu proje ne yapıyor?
+- Bu proje neden faydalıdır?
+- Kullanmaya nasıl başlarım?
+- İhtiyacım olursa nereden daha fazla yardım alabilirim?
 
 README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin.
 
-<aside markdown="1" class="pquote">
-   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
-   Daha iyi belgeler, daha fazla kullanıcı, daha az destek talebi ve daha fazla katkıda bulunan anlamına gelir. (...) Unutma ki okuyucuların sen değilsin. Tamamen farklı deneyimlerle projeye gelebilecek insanlar var.
-   <p markdown="1" class="pquote-credit">
-- @tracymakes, ["Yazdıkların okunuyor (video)")(https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
-   </p>
-</aside>
+<aside markdown="1" class="pquote">    <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">    Daha iyi belgeler, daha fazla kullanıcı, daha az destek talebi ve daha fazla katkıda bulunan anlamına gelir. (...) Unutma ki okuyucuların sen değilsin. Tamamen farklı deneyimlerle projeye gelebilecek insanlar var.    <p markdown="1" class="pquote-credit"> - @tracymakes, ["Yazdıkların okunuyor (video)")(https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)    </p> </aside>
 
 Bazen, insanlar bir README yazmaktan kaçınırlar çünkü proje bitmemiş gibi hissederler veya katkı kabul etmek istemezler. Bunların hepsi yazmak için çok iyi nedenler.
 
 Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make a README" kılavuzunu](https://www.makeareadme.com/) veya @PurpleBooth'ın [README şablonunu](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) kullanmayı deneyin.
 
-Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler.
+Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make a README" kılavuzunu](https://www.makeareadme.com/) veya @PurpleBooth'ın [README şablonunu](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) kullanmayı deneyin.
 
 ### Katkıda bulunma rehberinizi yazmak
 
-Bir CONTRIBUTING dosyası, izleyicilerinize projenize nasıl katkıda bulunabileceklerini söyler. Örneğin, şunlarla ilgili bilgiler de ekleyebilirsiniz:
+Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler.
 
-* Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin)
-* Yeni bir özellik nasıl önerilir
-* Proje ortamı nasıl kurulur ve testler nasıl yapılır
+- Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin)
+- Yeni bir özellik nasıl önerilir
+- Proje ortamı nasıl kurulur ve testler nasıl yapılır
 
 Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır:
 
-* Aradığınız katkı türleri
-* Proje için yol haritanız veya vizyonunuz
-* Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli)
+- Aradığınız katkı türleri
+- Proje için yol haritanız veya vizyonunuz
+- Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli)
 
 Sıcak, arkadaşça bir ton kullanmak ve katkılar için özel önerilerde bulunmak (örneğin, dokümantasyon yazmak veya bir web sitesi yapmak gibi) yeni gelenlerin kendilerini memnun ve istekli hissetmelerini sağlama konusunda yardımcı olabilir.
 
@@ -188,25 +164,19 @@ 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/master/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.
+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/master/CONTRIBUTING-template.md) veya @mozilla'nın ["Bir CONTRIBUTING.md Nasıl Oluşturulur"](https://mozillascience.github.io/working-open-workshop/contributing/) makalesine bakabilirsiniz.
 
-![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+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.
 
 ### Davranış kural listesi oluşturmak
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
-  Hepimiz, muhtemelen bir şeyin neden belli bir şekilde olması gerektiğini açıklamaya çalışan bir geliştirici olarak ya da bir kullanıcı olarak... basit bir soru sormakla ... ... kötüye kullanılan şeyin yaşadığı deneyimlerimiz oldu. (...) Davranış kuralları, ekibinizin yapıcı söylemleri çok ciddiye aldığını gösteren, kolayca referans verilen ve bağlanabilir bir belge haline gelir.
-  <p markdown="1" class="pquote-credit">
-- @mlynch, ["Açık Kaynağı Daha Mutlu Bir Yer Yapma"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">   Hepimiz, muhtemelen bir şeyin neden belli bir şekilde olması gerektiğini açıklamaya çalışan bir geliştirici olarak ya da bir kullanıcı olarak... basit bir soru sormakla ... ... kötüye kullanılan şeyin yaşadığı deneyimlerimiz oldu. (...) Davranış kuralları, ekibinizin yapıcı söylemleri çok ciddiye aldığını gösteren, kolayca referans verilen ve bağlanabilir bir belge haline gelir.   <p markdown="1" class="pquote-credit"> - @mlynch, ["Açık Kaynağı Daha Mutlu Bir Yer Yapma"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)   </p> </aside>
 
 Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır.
 
 Daha fazla bilgi için [Davranış Kuralları kılavuzumuza](../code-of-conduct/) göz atın.
 
-Katılımcıların _nasıl_ davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir.
+Katılımcıların *nasıl* davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir.
 
 Açık kaynaklı lisanslara benzer şekilde, davranış kuralları için de yeni ortaya çıkan standartlar vardır, bu yüzden kendiniz yazmak zorunda değilsiniz. [Contributor Covenant](https://contributor-covenant.org/), Kubernet, Rails ve Swift dahil olmak üzere [40.000'den fazla açık kaynaklı proje](https://www.contributor-covenant.org/adopters) tarafından kullanılan bir davranış kural listesi şablonudur. Hangi metni kullanırsanız kullanın, gerektiğinde davranış kurallarınızı uygulamak için hazırlıklı olmalısınız.
 
@@ -214,14 +184,14 @@ Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosy
 
 ## Projenizi isimlendirme ve markalama
 
-Marka, gösterişli bir logo veya çekici bir proje adından daha fazlasıdır. Projeniz hakkında nasıl konuştuğunuzla ve mesajınızla kime ulaştığınızla ilgilidir.
+Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosyayı projenizin kök dizininde tutun, böylece README'nizden kolayca bulabilir ve linkleyebilirsiniz.
 
 ### Doğru ismi seçmek
 
-Hatırlanması kolay olan ve ideal olarak projenin ne yaptığı hakkında bir fikir veren bir isim seçin. Örneğin:
+Marka, gösterişli bir logo veya çekici bir proje adından daha fazlasıdır. Projeniz hakkında nasıl konuştuğunuzla ve mesajınızla kime ulaştığınızla ilgilidir.
 
-* [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler
-* [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur
+- [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler
+- [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur
 
 Mevcut bir projenin üzerine inşa ediyorsanız, adlarını ön ek olarak kullanmak projenizin ne yaptığını netleştirmeye yardımcı olabilir (örneğin, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` komutunu getirir).
 
@@ -235,25 +205,19 @@ Bir web sitesi, Twitter hesabı veya projenizi temsil eden diğer özellikleri i
 
 Projenizin adının herhangi bir ticari markayı ihlal etmediğinden emin olun. Bir şirket sizden projenizi kapatmanızı isteyebilir veya hatta aleyhinize yasal işlem başlatabilir. Bu riske değmez.
 
-[WIPO Global Marka Veritabanını](http://www.wipo.int/branddb/en/) ticari marka çakışmaları için kontrol edebilirsiniz. Eğer bir şirketteyseniz, bu [hukuk ekibinizin size yardımcı olabileceği](../legal/) şeylerden biridir.
+Projenizin adının herhangi bir ticari markayı ihlal etmediğinden emin olun. Bir şirket sizden projenizi kapatmanızı isteyebilir veya hatta aleyhinize yasal işlem başlatabilir. Bu riske değmez.
 
-Sonunda, proje adınız için hızlı bir Google araması yapın. İnsanlar projenizi kolayca bulabilecek mi? Arama sonuçlarında görmelerini istemediğiniz başka bir şey var mı?
+[WIPO Global Marka Veritabanını](http://www.wipo.int/branddb/en/) ticari marka çakışmaları için kontrol edebilirsiniz. Eğer bir şirketteyseniz, bu [hukuk ekibinizin size yardımcı olabileceği](../legal/) şeylerden biridir.
 
 ### Nasıl yazdığın (ve kodladığın) markanı da etkiler!
 
 Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri.
 
-Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün.
+Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-    Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.
-  <p markdown="1" class="pquote-credit">
-- [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">     Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.   <p markdown="1" class="pquote-credit"> - [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)   </p> </aside>
 
-Sıcak, kapsayıcı bir dil kullanmak ("onlar" gibi, tek bir kişiye atıfta bulunsanız bile), projenizin yeni katılımcılar için memnuniyetle karşılanmasında yardımcı olabilir. Okuyucularınızın çoğu anadili İngilizce olmayabilir.
+Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün.
 
 Kelimeleri nasıl yazdığınızın ötesinde, kodlama stiliniz de projenizin markasının bir parçası olabilir. [Angular](https://angular.io/guide/styleguide) ve [jQuery](https://contribute.jquery.org/style-guide/js/) titiz kodlama stilleri ve yönergeleri olan projelere iki örnektir.
 

From 697da015ded8bbea360becc788a70eca8242494e Mon Sep 17 00:00:00 2001
From: "gitlocalize-app[bot]"
 <55277160+gitlocalize-app[bot]@users.noreply.github.com>
Date: Wed, 20 May 2020 19:55:44 +0000
Subject: [PATCH 003/749] Translate starting-a-project.md via GitLocalize

---
 _articles/tr/starting-a-project.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index 14442735d40..88db439963a 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -30,7 +30,7 @@ Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek
 
 ### İnsanlar neden işlerini açık kaynak olarak sunarlar?
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">     Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.   <p markdown="1" class="pquote-credit"> — @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)   </p> </aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">   Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.   <p markdown="1" class="pquote-credit"> - @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)   </p> </aside>
 
 Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler:
 
@@ -68,7 +68,7 @@ Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahi
 
 Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız.
 
-<aside markdown="1" class="pquote">    <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">    Bir noktada kullandığım özel bir UIAlertView yarattım ... ve açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca diğer geliştiricilere projelerinde nasıl kullanacaklarını açıklayan ilk belgelerimi yazdım. Muhtemelen hiç kimse onu kullanmamıştı çünkü basit bir projeydi ama katkım konusunda kendimi iyi hissediyordum.    <p markdown="1" class="pquote-credit"> — @mavris, ["Kendi Kendine Öğrenen Yazılım Geliştiricileri: Açık Kaynak Neden Bizim İçin Önemli?"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)    </p> </aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">   Bir noktada kullandığım özel bir UIAlertView yarattım ... ve açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca diğer geliştiricilere projelerinde nasıl kullanacaklarını açıklayan ilk belgelerimi yazdım. Muhtemelen hiç kimse onu kullanmamıştı çünkü basit bir projeydi ama katkım konusunda kendimi iyi hissediyordum.   <p markdown="1" class="pquote-credit"> - @mavris, ["Kendi Kendine Öğrenen Yazılım Geliştiricileri: Açık Kaynak Neden Bizim İçin Önemli?"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)   </p> </aside>
 
 Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir.
 
@@ -121,7 +121,7 @@ Açık kaynak kodlu bir projeyi yönetmenin yasal yönleri hakkında başka soru
 
 README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar.
 
-In your README, try to answer the following questions:
+README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar.
 
 - Bu proje ne yapıyor?
 - Bu proje neden faydalıdır?
@@ -130,7 +130,7 @@ In your README, try to answer the following questions:
 
 README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin.
 
-<aside markdown="1" class="pquote">    <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">    Daha iyi belgeler, daha fazla kullanıcı, daha az destek talebi ve daha fazla katkıda bulunan anlamına gelir. (...) Unutma ki okuyucuların sen değilsin. Tamamen farklı deneyimlerle projeye gelebilecek insanlar var.    <p markdown="1" class="pquote-credit"> - @tracymakes, ["Yazdıkların okunuyor (video)")(https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)    </p> </aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">   Daha iyi belgeler, daha fazla kullanıcı, daha az destek talebi ve daha fazla katkıda bulunan anlamına gelir. (...) Unutma ki okuyucuların sen değilsin. Tamamen farklı deneyimlerle projeye gelebilecek insanlar var.   <p markdown="1" class="pquote-credit"> - @tracymakes, ["Yazdıkların okunuyor (video)")(https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)   </p> </aside>
 
 Bazen, insanlar bir README yazmaktan kaçınırlar çünkü proje bitmemiş gibi hissederler veya katkı kabul etmek istemezler. Bunların hepsi yazmak için çok iyi nedenler.
 

From d42188cc7a191ce8140f2e751cf0014098d70ad8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bruno=20Fran=C3=A7a?=
 <39228171+bsfranca2@users.noreply.github.com>
Date: Sun, 24 May 2020 18:46:35 -0300
Subject: [PATCH 004/749] accent correction in Portuguese

---
 _articles/pt/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index 9be6ae9d9c7..b5684dc7902 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -27,7 +27,7 @@ Para entender como funciona, imagine que seu amigo está dando uma festa, e voc
 * Um amigo, Alex, que é um chefe de pastelaria, sugere reduzir o açúcar (_modifica_)
 * Outra amiga, Lisa, pede para utilizá-la em um jantar na próxima semana (_distribui_)
 
-Em comparação, um processo de código fechado seria ir a um restaurante e pedir um pedaço de torta. Você tem que pagar uma taxa para comer a torta, e o restaurante provavelmente não te dará a receita. Se vocẽ copiasse a torta deles exatamente e a vendesse sob seu próprio nome, o restaurante poderia abrir uma ação contra você.
+Em comparação, um processo de código fechado seria ir a um restaurante e pedir um pedaço de torta. Você tem que pagar uma taxa para comer a torta, e o restaurante provavelmente não te dará a receita. Se você copiasse a torta deles exatamente e a vendesse sob seu próprio nome, o restaurante poderia abrir uma ação contra você.
 
 ### Por que as pessoas tornam seu trabalho open source?
 

From ec602c948eea39c4c4b3a7adb5bef2d863eacd77 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bruno=20Fran=C3=A7a?=
 <39228171+bsfranca2@users.noreply.github.com>
Date: Sun, 24 May 2020 19:02:39 -0300
Subject: [PATCH 005/749] accent correction in Portuguese

---
 _articles/pt/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index b5684dc7902..ed7dc2035da 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -87,7 +87,7 @@ A medida que o seu projeto cresce, sua comunidade pode precisar de mais do que a
 
 Enquanto a quantidade de tempo que você gasta em tarefas que não envolvem código depende do tamanho e escopo do seu projeto, você deve estar preparado, como um mantenedor, a cuidar delas você mesmo ou a encontrar alguém para ajudá-lo.
 
-**Se você faz parte de uma empresa tornando um projeto open source,** certifique-se de que seu projeto tem os recursos internos que ele precisa para florescer. Vocẽ irá querer identificar quem é responsável por manter o projeto após o almoço e compartilhar essas tarefas com a comunidade.
+**Se você faz parte de uma empresa tornando um projeto open source,** certifique-se de que seu projeto tem os recursos internos que ele precisa para florescer. Você irá querer identificar quem é responsável por manter o projeto após o almoço e compartilhar essas tarefas com a comunidade.
 
 Se você precisar de uma renda dedicada ou pessoal para promoção, operações e manutenção do projeto, comece essas discussões cedo.
 

From 4c973ba7203fb79ad4213fce2245faefcda88e2c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bruno=20Fran=C3=A7a?=
 <39228171+bsfranca2@users.noreply.github.com>
Date: Sun, 24 May 2020 19:06:14 -0300
Subject: [PATCH 006/749] accent correction in Portuguese

---
 _articles/pt/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index ed7dc2035da..b13c6f64ce4 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -203,7 +203,7 @@ Crie um link para seu arquivo CONTRIBUTING a partir do seu README, de modo que m
   </p>
 </aside>
 
-Finalmente, um código de conduta ajuda a criar regras básicas de comportamento para os participantes do seu projeto. Isso possui um valor especial se vocẽ está lançando um projeto open source para a comunidade ou alguma empresa. Um código de conduta te dá o poder de facilitar um comportamento saudável e construtivo da comunidade, o que irá reduzir seu estresse como mantenedor.
+Finalmente, um código de conduta ajuda a criar regras básicas de comportamento para os participantes do seu projeto. Isso possui um valor especial se você está lançando um projeto open source para a comunidade ou alguma empresa. Um código de conduta te dá o poder de facilitar um comportamento saudável e construtivo da comunidade, o que irá reduzir seu estresse como mantenedor.
 
 Para mais informações, dê uma olhada no nosso [guia do Código de Conduta](../code-of-conduct/).
 

From 884ddddf43a48196159a4396319369324aaeaff0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bruno=20Fran=C3=A7a?=
 <39228171+bsfranca2@users.noreply.github.com>
Date: Sun, 24 May 2020 19:28:28 -0300
Subject: [PATCH 007/749] accent correction in Portuguese

---
 _articles/pt/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index b13c6f64ce4..56fe51e3925 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -93,7 +93,7 @@ Se você precisar de uma renda dedicada ou pessoal para promoção, operações
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-  Quando você começa a tornar o projeto open source, é importante se certificar de que os seus processos ãdministrativos levam em consideração as contribuições e habilidades da comunidade em torno do seu projeto. Não tenha medo de envolver contribuidores que não são empregados da sua empresa em aspectos chave do projeto - especialmente se eles sao contribuidores assíduos.
+  Quando você começa a tornar o projeto open source, é importante se certificar de que os seus processos administrativos levam em consideração as contribuições e habilidades da comunidade em torno do seu projeto. Não tenha medo de envolver contribuidores que não são empregados da sua empresa em aspectos chave do projeto - especialmente se eles sao contribuidores assíduos.
   <p markdown="1" class="pquote-credit">
 — @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
   </p>

From 7dd182049f0cbc7782f6118ac7bc86b94876e67c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bruno=20Fran=C3=A7a?=
 <39228171+bsfranca2@users.noreply.github.com>
Date: Sun, 24 May 2020 19:34:56 -0300
Subject: [PATCH 008/749] accent correction in Portuguese

---
 _articles/pt/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index 56fe51e3925..54691d69ff4 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -93,7 +93,7 @@ Se você precisar de uma renda dedicada ou pessoal para promoção, operações
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-  Quando você começa a tornar o projeto open source, é importante se certificar de que os seus processos administrativos levam em consideração as contribuições e habilidades da comunidade em torno do seu projeto. Não tenha medo de envolver contribuidores que não são empregados da sua empresa em aspectos chave do projeto - especialmente se eles sao contribuidores assíduos.
+  Quando você começa a tornar o projeto open source, é importante se certificar de que os seus processos administrativos levam em consideração as contribuições e habilidades da comunidade em torno do seu projeto. Não tenha medo de envolver contribuidores que não são empregados da sua empresa em aspectos chave do projeto - especialmente se eles são contribuidores assíduos.
   <p markdown="1" class="pquote-credit">
 — @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
   </p>

From f3b6d75b9d2f6d619eb11c3062f2a71e1cbf8534 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bruno=20Fran=C3=A7a?=
 <39228171+bsfranca2@users.noreply.github.com>
Date: Sun, 24 May 2020 19:37:53 -0300
Subject: [PATCH 009/749] Writing error

---
 _articles/pt/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index 54691d69ff4..fbf21edb4a2 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -118,7 +118,7 @@ Independente do estágio em que você decida tornar o seu projeto open source, t
 * [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
 * [Code of conduct](../code-of-conduct/)
 
-Como um mantenedor, esses componentes irão ajudá-lo a comunicar suas espectativas, administrar contribuições, e projeger o direito legal de todos (inclusive o seu). Eles aumentam suas chances de ter uma experência positiva significativamente.
+Como um mantenedor, esses componentes irão ajudá-lo a comunicar suas espectativas, administrar contribuições, e proteger o direito legal de todos (inclusive o seu). Eles aumentam suas chances de ter uma experência positiva significativamente.
 
 Se seu projeto está no GitHub, colocar esses arquivos no seu diretório root com os nomes recomendados ajudará o GitHub a reconhecê-los e automaticamente mostrá-los da maneira apropriada aos seus leitores.
 

From 0d9f52dd89a320e04d9ccf9cbb9c25f87d4e53e1 Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Mon, 25 May 2020 23:01:05 +0000
Subject: [PATCH 010/749] Bump github-pages from 204 to 206

Bumps [github-pages](https://github.com/github/pages-gem) from 204 to 206.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v204...v206)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index a81214f5996..3f08f091811 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -26,14 +26,14 @@ GEM
       ffi (>= 1.3.0)
     eventmachine (1.2.7)
     execjs (2.7.0)
-    faraday (1.0.0)
+    faraday (1.0.1)
       multipart-post (>= 1.2, < 3)
     ffi (1.12.2)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (204)
+    github-pages (206)
       github-pages-health-check (= 1.16.1)
-      jekyll (= 3.8.5)
+      jekyll (= 3.8.7)
       jekyll-avatar (= 0.7.0)
       jekyll-coffeescript (= 1.1.1)
       jekyll-commonmark-ghpages (= 0.1.6)
@@ -72,7 +72,7 @@ GEM
       mercenary (~> 0.3)
       minima (= 2.5.1)
       nokogiri (>= 1.10.4, < 2.0)
-      rouge (= 3.13.0)
+      rouge (= 3.19.0)
       terminal-table (~> 1.4)
     github-pages-health-check (1.16.1)
       addressable (~> 2.3)
@@ -94,7 +94,7 @@ GEM
     http_parser.rb (0.6.0)
     i18n (0.9.5)
       concurrent-ruby (~> 1.0)
-    jekyll (3.8.5)
+    jekyll (3.8.7)
       addressable (~> 2.4)
       colorator (~> 1.0)
       em-websocket (~> 0.5)
@@ -216,7 +216,7 @@ GEM
       mini_portile2 (~> 2.4.0)
     nokogumbo (2.0.2)
       nokogiri (~> 1.8, >= 1.8.4)
-    octokit (4.15.0)
+    octokit (4.18.0)
       faraday (>= 0.9)
       sawyer (~> 0.8.0, >= 0.5.3)
     parallel (1.19.1)
@@ -225,13 +225,13 @@ GEM
     public_suffix (3.1.1)
     rainbow (3.0.0)
     rake (13.0.1)
-    rb-fsevent (0.10.3)
+    rb-fsevent (0.10.4)
     rb-inotify (0.10.1)
       ffi (~> 1.0)
-    rouge (3.13.0)
-    ruby-enum (0.7.2)
+    rouge (3.19.0)
+    ruby-enum (0.8.0)
       i18n
-    rubyzip (2.0.0)
+    rubyzip (2.3.0)
     safe_yaml (1.0.5)
     sass (3.7.4)
       sass-listen (~> 4.0.0)
@@ -244,11 +244,11 @@ GEM
     terminal-table (1.8.0)
       unicode-display_width (~> 1.1, >= 1.1.1)
     thread_safe (0.3.6)
-    typhoeus (1.3.1)
+    typhoeus (1.4.0)
       ethon (>= 0.9.0)
     tzinfo (1.2.7)
       thread_safe (~> 0.1)
-    unicode-display_width (1.6.1)
+    unicode-display_width (1.7.0)
     yell (2.2.2)
     zeitwerk (2.3.0)
 

From 507389d2618a38c523a063b7e1d2f9ba34b2373c Mon Sep 17 00:00:00 2001
From: Abilio Esteves <eco.abilio@gmail.com>
Date: Sun, 14 Jun 2020 22:21:21 -0300
Subject: [PATCH 011/749] reviews list of first-timers resources

---
 _articles/de/how-to-contribute.md      | 4 ++--
 _articles/es/how-to-contribute.md      | 2 ++
 _articles/fr/how-to-contribute.md      | 2 ++
 _articles/hu/how-to-contribute.md      | 1 +
 _articles/id/how-to-contribute.md      | 2 ++
 _articles/ja/how-to-contribute.md      | 7 ++++---
 _articles/ko/how-to-contribute.md      | 2 ++
 _articles/pt/how-to-contribute.md      | 7 ++++---
 _articles/ta/how-to-contribute.md      | 2 ++
 _articles/zh-hans/how-to-contribute.md | 2 ++
 _articles/zh-hant/how-to-contribute.md | 2 ++
 11 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/_articles/de/how-to-contribute.md b/_articles/de/how-to-contribute.md
index f23942c6138..b94b7043554 100644
--- a/_articles/de/how-to-contribute.md
+++ b/_articles/de/how-to-contribute.md
@@ -239,10 +239,10 @@ Weiterhin, können Sie auf folgenden Seiten neue Projekte zum Beitragen entdecke
 
 * [GitHub Explore](https://github.com/explore/)
 * [Open Source Friday](https://opensourcefriday.com)
-* [First Timers Only](http://www.firsttimersonly.com/)
+* [First Timers Only](https://www.firsttimersonly.com/)
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
-* [Up For Grabs](http://up-for-grabs.net/)
+* [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://www.sourcesort.com/)
diff --git a/_articles/es/how-to-contribute.md b/_articles/es/how-to-contribute.md
index 6f81d3ad0d6..bc8f64bb38c 100644
--- a/_articles/es/how-to-contribute.md
+++ b/_articles/es/how-to-contribute.md
@@ -216,6 +216,8 @@ Puedes tambi&eacute;n utilizar algunos de los siguientes recursos para ayudarte
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
 
 ### Una lista de verificaci&oacute;n antes de que contribuyas
 
diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md
index 7b678dd5fe9..7ec90a96ee5 100644
--- a/_articles/fr/how-to-contribute.md
+++ b/_articles/fr/how-to-contribute.md
@@ -216,6 +216,8 @@ Vous pouvez également utiliser l'une des ressources suivantes pour vous aider 
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
 
 ### Une checklist avant de contribuer
 
diff --git a/_articles/hu/how-to-contribute.md b/_articles/hu/how-to-contribute.md
index 6d2498cf74b..8c882058d7f 100644
--- a/_articles/hu/how-to-contribute.md
+++ b/_articles/hu/how-to-contribute.md
@@ -220,6 +220,7 @@ Az alábbiakban találsz néhány oldalt, amelyek segítenek abban, hogy felfede
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
 
 ### Egy ellenőrző lista, mielőtt részt vennél a projektben
 
diff --git a/_articles/id/how-to-contribute.md b/_articles/id/how-to-contribute.md
index 47a52cd4e0d..186ad3100f6 100644
--- a/_articles/id/how-to-contribute.md
+++ b/_articles/id/how-to-contribute.md
@@ -216,6 +216,8 @@ Anda juga bisa menggunakan salah satu dari beberapa sumber daya berikut untuk me
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
 
 ### Daftar sebelum Anda berkontribusi
 
diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md
index 2bf8d0338cb..43923ef4afc 100644
--- a/_articles/ja/how-to-contribute.md
+++ b/_articles/ja/how-to-contribute.md
@@ -211,12 +211,13 @@ README を読んで、壊れたリンクやタイポを見つけるかもしれ
 
 * [GitHub Explore](https://github.com/explore/)
 * [Open Source Friday](https://opensourcefriday.com)
-* [First Timers Only](http://www.firsttimersonly.com/)
-* [Your First PR](https://yourfirstpr.github.io/)
+* [First Timers Only](https://www.firsttimersonly.com/)
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
-* [Up For Grabs](http://up-for-grabs.net/)
+* [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
 
 ### コントリビュートする前のチェックリスト
 
diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md
index f62d90a42ba..8ba1371726b 100644
--- a/_articles/ko/how-to-contribute.md
+++ b/_articles/ko/how-to-contribute.md
@@ -216,6 +216,8 @@ README를 스캔하여 깨진 링크나 오타를 찾을 수 있습니다. 또
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
 
 ### 기여하기 전 확인할 사항
 
diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md
index e3b29975e24..36579e4c3d7 100644
--- a/_articles/pt/how-to-contribute.md
+++ b/_articles/pt/how-to-contribute.md
@@ -211,12 +211,13 @@ Você também pode usar um dos seguintes recursos para ajudá-lo a descobrir e c
 
 * [GitHub Explore](https://github.com/explore/)
 * [Open Source Friday](https://opensourcefriday.com)
-* [First Timers Only](http://www.firsttimersonly.com/)
-* [Your First PR](https://yourfirstpr.github.io/)
+* [First Timers Only](https://www.firsttimersonly.com/)
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
-* [Up For Grabs](http://up-for-grabs.net/)
+* [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
 
 ### Um checklist antes de você contribuir
 
diff --git a/_articles/ta/how-to-contribute.md b/_articles/ta/how-to-contribute.md
index 4e49aeb57c5..c27a34f7070 100644
--- a/_articles/ta/how-to-contribute.md
+++ b/_articles/ta/how-to-contribute.md
@@ -216,6 +216,8 @@ related:
 * [24 இழு கோரிக்கைகள்](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
 * [பங்களிப்பாளர்-நிஞ்ஜா](https://contributor.ninja)
+* [முதல் பங்களிப்புகள்](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
 
 ### பங்களிக்கும் முன் ஒரு சரிபார்ப்புப் பட்டியல்
 
diff --git a/_articles/zh-hans/how-to-contribute.md b/_articles/zh-hans/how-to-contribute.md
index 7c1bc126b1f..e985ca3882f 100644
--- a/_articles/zh-hans/how-to-contribute.md
+++ b/_articles/zh-hans/how-to-contribute.md
@@ -217,6 +217,8 @@ redirect_from: /zh-cn/how-to-contribute/
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
 * [像忍者一样贡献](https://contributor.ninja)
+* [最初的贡献](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
 
 ### 提交贡献之前的检查列表
 
diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md
index e2328f70e80..32d16ac5969 100644
--- a/_articles/zh-hant/how-to-contribute.md
+++ b/_articles/zh-hant/how-to-contribute.md
@@ -217,6 +217,8 @@ redirect_from: /zh-tw/how-to-contribute/
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](http://up-for-grabs.net/)
 * [貢獻忍者](https://contributor.ninja)
+* [最初的贡献](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
 
 ### **提交貢獻前應做的檢查清單**
 

From 30ddd43415eb1ca82ab4fc66c7a1a26c39e5388d Mon Sep 17 00:00:00 2001
From: SADIK KUZU <sadikkuzu@hotmail.com>
Date: Wed, 17 Jun 2020 02:40:49 +0300
Subject: [PATCH 012/749] Applying translations into header (class=h00-mktg)

---
 _layouts/index.html | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/_layouts/index.html b/_layouts/index.html
index bbc73bfabd7..2f74e50281f 100644
--- a/_layouts/index.html
+++ b/_layouts/index.html
@@ -2,13 +2,18 @@
 layout: default
 ---
 {% assign t = site.data.locales[page.lang][page.lang] %}
+{% if page.title %}
+  {% assign header = page.title %}
+{% else %}
+  {% assign header = site.title %}
+{% endif %}
 {% include nav.html %}
 
 <div class="bg-gray-light">
 
   <header class="py-4 py-md-6">
     <div class="container-lg p-responsive mx-auto text-center pt-6">
-      <h1 class="h00-mktg">{{ site.title }}</h1>
+      <h1 class="h00-mktg">{{ header }}</h1>
       <p class="lead-mktg text-gray mb-md-5 col-md-8 mx-auto">
         {{ t.index.lead }}
       </p>

From 1093e99e47fcb168cc8a7e600116b3a44d38c5a6 Mon Sep 17 00:00:00 2001
From: SADIK KUZU <sadikkuzu@hotmail.com>
Date: Wed, 17 Jun 2020 02:49:30 +0300
Subject: [PATCH 013/749] Turkish translation improvements

---
 _articles/tr/index.html | 2 +-
 _data/locales/tr.yml    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/tr/index.html b/_articles/tr/index.html
index fbec4f5f3f5..12cf403b695 100644
--- a/_articles/tr/index.html
+++ b/_articles/tr/index.html
@@ -1,6 +1,6 @@
 ---
 layout: index
 lang: tr
-title: Açık kaynak rehberleri
+title: Açık Kaynak Rehberleri
 permalink: /tr/
 ---
diff --git a/_data/locales/tr.yml b/_data/locales/tr.yml
index c1d0b1d3cd0..9851448afd5 100644
--- a/_data/locales/tr.yml
+++ b/_data/locales/tr.yml
@@ -22,7 +22,7 @@ tr:
       button: Abone Olun 
     byline:
       # [code], [love], and [github] will be replaced by octicons
-      format: "[github] ve [friends] ile beraber [love] ile [code]"
+      format: "[github] ve [friends] tarafından [love] ile [code]"
       # Label for code octicon
       code_label: code
       # Label for love octicon

From 73a6ea2d3cdb787f9943f058aa177a0c41b65ee6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Fernando=20Cordova?= <jfernancordova@gmail.com>
Date: Wed, 17 Jun 2020 21:56:05 -0300
Subject: [PATCH 014/749] Open Source Guides

---
 _articles/es/legal.md |  2 +-
 _data/locales/es.yml  | 12 ++++++------
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/_articles/es/legal.md b/_articles/es/legal.md
index a9c8c2419ac..29a307f5e41 100644
--- a/_articles/es/legal.md
+++ b/_articles/es/legal.md
@@ -1,6 +1,6 @@
 ---
 lang: es
-title: Aspectos legales del codigo abierto.
+title: Aspectos legales del código abierto.
 description: Todo lo que te has preguntado sobre la parte legal de c&oacute;digo abierto.
 class: legal
 order: 10
diff --git a/_data/locales/es.yml b/_data/locales/es.yml
index 2a2bb73f715..3eb1c235f37 100644
--- a/_data/locales/es.yml
+++ b/_data/locales/es.yml
@@ -4,21 +4,21 @@ es:
     about: Acerca de
     contribute: Contribuir
   index:
-    lead: El software de c&oacute;digo abierto es desarrollado por personas como tu, aprende c&oacute;mo crear y hacer que tu proyecto crezca.
-    opensourcefriday: It's Friday! Invest a few hours contributing to the software you use and love
+    lead: El software de código abierto es desarrollado por personas como tu, aprende cómo crear y hacer que tu proyecto crezca.
+    opensourcefriday: ¡Es viernes! Invierte unas cuántas horas para contribuir al software que usas y amas
   article:
     table_of_contents: Tabla de contenidos
-    back_to_all_guides: Back to all guides
-    related_guides: Related Guides
+    back_to_all_guides: Volver a todas las guías
+    related_guides: Guías relacionadas
   footer:
     contribute:
       heading: Contribuir
-      description: Tienes alguna sugerencia? Este contenido es de c&oacute;digo abierto. Ay&uacute;danos a mejorarlo.
+      description: ¿Tienes alguna sugerencia? Este contenido es de código abierto. Ayúdanos a mejorarlo.
       button: Contribuir
     subscribe:
       heading: Suscribirse para novedades
       description: Sea el primero en enterarse de los últimos consejos y recursos de código abierto.
-      label: Direcci&oacute;n de correo
+      label: Dirección de correo
       button: Suscribirse
     byline:
       # [code], [love], and [github] will be replaced by octicons

From 9b1683b8407503b0f588ccfce246f0287630e74b Mon Sep 17 00:00:00 2001
From: Satoshi Watanabe <sassy.watanabe@gmail.com>
Date: Sat, 27 Jun 2020 18:30:47 +0900
Subject: [PATCH 015/749] add index title in japanese page.

---
 _articles/ja/index.html | 1 +
 1 file changed, 1 insertion(+)

diff --git a/_articles/ja/index.html b/_articles/ja/index.html
index 84d7572edc0..a7cf02f62cb 100644
--- a/_articles/ja/index.html
+++ b/_articles/ja/index.html
@@ -1,5 +1,6 @@
 ---
 layout: index
+title: オープンソースガイドライン
 lang: ja
 permalink: /ja/
 ---

From f0f35f435607fa2989d575c023bcc7ff87395f72 Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Mon, 29 Jun 2020 13:34:26 -0700
Subject: [PATCH 016/749] Update head.html

---
 _includes/head.html | 1 +
 1 file changed, 1 insertion(+)

diff --git a/_includes/head.html b/_includes/head.html
index 16d5c5860fb..6349cd761bd 100644
--- a/_includes/head.html
+++ b/_includes/head.html
@@ -1,6 +1,7 @@
 <head>
   <meta charset="utf-8">
   <meta name="viewport" content="width=device-width, initial-scale=1">
+  <meta name="google-site-verification" content="c1kuD-K2HIVF635lypcsWPoD4kilo5-jA_wBFyT4uMY" />
   <link rel="icon" type="image/x-icon" href="https://github.githubassets.com/favicon.ico">
   <link href="https://fonts.googleapis.com/css?family=Roboto:300,300i,400,400i,700,700i" rel="stylesheet">
   <link href="{{ "/assets/css/index.css" | relative_url }}" rel="stylesheet">

From 3426d2b5b2fc6bd6ed491c9c0916104779468825 Mon Sep 17 00:00:00 2001
From: Rafael Farias Lima <finha.farias@outlook.com>
Date: Wed, 8 Jul 2020 10:29:29 -0300
Subject: [PATCH 017/749] Update translation for portuguese

---
 _articles/pt/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md
index 36579e4c3d7..81f16203699 100644
--- a/_articles/pt/how-to-contribute.md
+++ b/_articles/pt/how-to-contribute.md
@@ -427,7 +427,7 @@ Antes de abrir uma issue, pull request ou fazer uma pergunta no bate-papo, ter o
 >
 > 😢 _"Porque você não dá suporte ao meu caso de uso? Isto é inaceitável!"_
 
-**Acima de tudo, mantenha a classe.** O open source é composto por contribuidores de todo o mundo. O contexto se perde em idiomas, culturas, regiões geográficas e fusos horários. Além disso, a comunicação escrita torna mais difícil transmitir um tom ou humor. Assuma boas intenções nessas conversas. É normal se desfazer de uma ideia de forma educada e pedir mais contexto ou esclarecer melhor sua posição. Apenas tente deixar a internet em um lugar melhor do que quando você a encontrou.
+**Acima de tudo, mantenha a classe.** O open source é composto por contribuidores de todo o mundo. O contexto se perde em idiomas, culturas, regiões geográficas e fusos horários. Além disso, a comunicação escrita torna mais difícil transmitir um tom ou humor. Assuma boas intenções nessas conversas. É normal se desfazer de uma ideia de forma educada e pedir mais contexto ou esclarecer melhor sua posição. Apenas tente deixar a internet melhor do que quando você a encontrou.
 
 ### Capturando o contexto
 

From f7bb97940c9c387a3bdfa65c186330e932aeba7f Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Thu, 9 Jul 2020 16:19:56 +0100
Subject: [PATCH 018/749] Use blob/HEAD instead of blob/master.

This fixes one currently broken link and will fix future cases if people
rename their default branches.
---
 .github/PULL_REQUEST_TEMPLATE.md               | 2 +-
 _articles/building-community.md                | 4 ++--
 _articles/code-of-conduct.md                   | 2 +-
 _articles/de/building-community.md             | 4 ++--
 _articles/de/code-of-conduct.md                | 2 +-
 _articles/de/leadership-and-governance.md      | 4 ++--
 _articles/de/legal.md                          | 2 +-
 _articles/de/starting-a-project.md             | 6 +++---
 _articles/es/building-community.md             | 4 ++--
 _articles/es/code-of-conduct.md                | 2 +-
 _articles/es/leadership-and-governance.md      | 4 ++--
 _articles/es/starting-a-project.md             | 6 +++---
 _articles/fr/building-community.md             | 4 ++--
 _articles/fr/code-of-conduct.md                | 2 +-
 _articles/fr/leadership-and-governance.md      | 4 ++--
 _articles/fr/starting-a-project.md             | 6 +++---
 _articles/hu/building-community.md             | 4 ++--
 _articles/hu/code-of-conduct.md                | 2 +-
 _articles/hu/leadership-and-governance.md      | 4 ++--
 _articles/hu/legal.md                          | 4 ++--
 _articles/hu/starting-a-project.md             | 6 +++---
 _articles/id/building-community.md             | 4 ++--
 _articles/id/code-of-conduct.md                | 2 +-
 _articles/id/leadership-and-governance.md      | 4 ++--
 _articles/id/starting-a-project.md             | 6 +++---
 _articles/ja/building-community.md             | 8 ++++----
 _articles/ja/code-of-conduct.md                | 2 +-
 _articles/ja/leadership-and-governance.md      | 4 ++--
 _articles/ja/legal.md                          | 2 +-
 _articles/ja/starting-a-project.md             | 6 +++---
 _articles/ko/building-community.md             | 4 ++--
 _articles/ko/code-of-conduct.md                | 2 +-
 _articles/ko/leadership-and-governance.md      | 4 ++--
 _articles/ko/starting-a-project.md             | 8 ++++----
 _articles/leadership-and-governance.md         | 4 ++--
 _articles/legal.md                             | 2 +-
 _articles/pl/building-community.md             | 4 ++--
 _articles/pl/code-of-conduct.md                | 2 +-
 _articles/pl/leadership-and-governance.md      | 4 ++--
 _articles/pl/legal.md                          | 2 +-
 _articles/pl/starting-a-project.md             | 6 +++---
 _articles/pt/building-community.md             | 4 ++--
 _articles/pt/code-of-conduct.md                | 2 +-
 _articles/pt/leadership-and-governance.md      | 4 ++--
 _articles/pt/starting-a-project.md             | 6 +++---
 _articles/ro/building-community.md             | 8 ++++----
 _articles/ro/code-of-conduct.md                | 4 ++--
 _articles/ro/leadership-and-governance.md      | 4 ++--
 _articles/ro/starting-a-project.md             | 8 ++++----
 _articles/starting-a-project.md                | 6 +++---
 _articles/ta/building-community.md             | 4 ++--
 _articles/ta/code-of-conduct.md                | 2 +-
 _articles/ta/leadership-and-governance.md      | 4 ++--
 _articles/ta/starting-a-project.md             | 6 +++---
 _articles/tr/building-community.md             | 4 ++--
 _articles/tr/code-of-conduct.md                | 2 +-
 _articles/tr/leadership-and-governance.md      | 4 ++--
 _articles/tr/starting-a-project.md             | 6 +++---
 _articles/zh-hans/building-community.md        | 4 ++--
 _articles/zh-hans/code-of-conduct.md           | 2 +-
 _articles/zh-hans/leadership-and-governance.md | 4 ++--
 _articles/zh-hans/legal.md                     | 2 +-
 _articles/zh-hans/starting-a-project.md        | 6 +++---
 _articles/zh-hant/README.md                    | 4 ++--
 _articles/zh-hant/building-community.md        | 8 ++++----
 _articles/zh-hant/code-of-conduct.md           | 2 +-
 _articles/zh-hant/leadership-and-governance.md | 6 +++---
 _articles/zh-hant/legal.md                     | 2 +-
 _articles/zh-hant/starting-a-project.md        | 6 +++---
 _includes/nav.html                             | 2 +-
 docs/translations.md                           | 2 +-
 test/prose                                     | 2 +-
 72 files changed, 144 insertions(+), 144 deletions(-)

diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index c63a6ec543e..12222f08657 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -1,4 +1,4 @@
-- [ ] Have you followed the [contributing guidelines](https://github.com/github/opensource.guide/blob/master/CONTRIBUTING.md)?
+- [ ] Have you followed the [contributing guidelines](https://github.com/github/opensource.guide/blob/HEAD/CONTRIBUTING.md)?
 - [ ] Have you explained what your changes do, and why they add value to the Guides?
 
 **Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.**
diff --git a/_articles/building-community.md b/_articles/building-community.md
index da465bf736a..eb4a09ebd3a 100644
--- a/_articles/building-community.md
+++ b/_articles/building-community.md
@@ -143,7 +143,7 @@ Finally, use your documentation to make people feel welcome at every step of the
 
 You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration.
 
-For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md):
+For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
 
 > We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
 
@@ -165,7 +165,7 @@ See if you can find ways to share ownership with your community as much as possi
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md) does.
+* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
 
 * If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
 
diff --git a/_articles/code-of-conduct.md b/_articles/code-of-conduct.md
index a92e75e7811..0b21e42d458 100644
--- a/_articles/code-of-conduct.md
+++ b/_articles/code-of-conduct.md
@@ -60,7 +60,7 @@ You should explain how your code of conduct will be enforced **_before_** a viol
 
 You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
 
-Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
 > Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
 
diff --git a/_articles/de/building-community.md b/_articles/de/building-community.md
index ed8c7f0bebf..40ae61a0032 100644
--- a/_articles/de/building-community.md
+++ b/_articles/de/building-community.md
@@ -153,7 +153,7 @@ Nicht zuletzt sollten Sie die Dokumentation nutzen, um Leute mit offenen Armen z
 
 Sie werden mit den meisten Leuten, die auf Ihr Projekt stoßen nie interagieren. Ihnen könnten Beiträge entgehen, weil jemand sich eingeschüchtert fühlte, oder nicht herausfand, was es denn zu tun gab. Schon ein paar freundliche Worte können verhindern, dass jemand einfach weiter zieht.
 
-Zum Beispiel: [Rubinius](https://github.com/rubinius/rubinius/) beginnt [den Kontributionsratgeber](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md) mit:
+Zum Beispiel: [Rubinius](https://github.com/rubinius/rubinius/) beginnt [den Kontributionsratgeber](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) mit:
 
 > Zum Einstieg möchten wir Dir erstmal unseren Dank aussprechen, dass Du Rubinius nutzt. Dieses Projekt wurde mit viel Liebe aufgebaut und wir schätzen alle Benutzer\*innen, die Fehler aufspüren, Geschwindigkeitsverbesserungen vornehmen und bei der Dokumentation helfen. Jeder Beitrag bedeutet uns etwas, also vielen Dank für Ihre Teilnahme! Wir bitten Sie jedoch, einige Richtlinien zu befolgen, damit wir Ihr Issue erfolgreich bearbeiten können.
 >
@@ -181,7 +181,7 @@ Schauen Sie, ob Sie Wege finden können, Verantwortlichkeiten so weit wie mögli
 
 ![Cookiecutter-Issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Führen Sie eine CONTRIBUTORS- oder AUTHORS-Datei in Ihrem Projekt**, die alle Leute aufzählt, die einen Beitrag geleistet haben, wie z.B. bei [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md).
+* **Führen Sie eine CONTRIBUTORS- oder AUTHORS-Datei in Ihrem Projekt**, die alle Leute aufzählt, die einen Beitrag geleistet haben, wie z.B. bei [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
 
 * Wenn Sie schon eine etwas größere Gemeinschaft versammelt haben, **senden Sie eine Rundmail oder schreiben ins Blog**, dass Sie Kontributor\*innen danken. Rusts [This Week in Rust](https://this-week-in-rust.org/) und Hoodies [Shoutout-Grüße](http://hood.ie/blog/shoutouts-week-24.html) sind zwei gute Beispiele dafür.
 
diff --git a/_articles/de/code-of-conduct.md b/_articles/de/code-of-conduct.md
index 18f9305542b..7a2c427c733 100644
--- a/_articles/de/code-of-conduct.md
+++ b/_articles/de/code-of-conduct.md
@@ -58,7 +58,7 @@ Sie sollten erklären, wie Ihr Verhaltenskodex durchgesetzt wird, **_bevor_** es
 
 Sie sollten Leuten einen privaten Weg (z.B. eine E-Mail-Adresse) geben, um einen Verstoß gegen den Verhaltenskodex zu melden und erklären, wer diesen Bericht erhält. Es kann ein\*e Maintainer\*in, eine Gruppe von Maintainer\*innen oder eine Verhaltenskodex-Arbeitsgruppe sein.
 
-Vergessen Sie nicht, dass jemand einen Verstoß über eine Person melden können möchte, die diese Berichte erhält. Bieten Sie in diesem Fall die Möglichkeit, Verstöße an eine andere Person zu melden. @ctb und @mr-c zum Beispiel [erklären zu ihrem Projekt](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+Vergessen Sie nicht, dass jemand einen Verstoß über eine Person melden können möchte, die diese Berichte erhält. Bieten Sie in diesem Fall die Möglichkeit, Verstöße an eine andere Person zu melden. @ctb und @mr-c zum Beispiel [erklären zu ihrem Projekt](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
 > Fälle von missbräuchlichem, belästigendem oder anderweitig inakzeptablem Verhalten können per E-Mail an **khmer-project@idyll.org** gemeldet werden, die nur an C. Titus Brown und Michael R. Crusoe geht. Um ein Problem zu melden, das einen von ihnen betrifft, senden Sie bitte eine E-Mail an **Judi Brown Clarke, Ph.D.** den Diversity Director am BEACON Center for the Study of Evolution in Action, einem NSF Center for Science and Technology.*
 >
diff --git a/_articles/de/leadership-and-governance.md b/_articles/de/leadership-and-governance.md
index f05c1051a30..1eff016164e 100644
--- a/_articles/de/leadership-and-governance.md
+++ b/_articles/de/leadership-and-governance.md
@@ -75,11 +75,11 @@ Wenn Ihr Projekt eine sehr aktive Gemeinschaft von Mitwirkenden hat, können Sie
   _\[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team._
 
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Führungsteams können einen Kommunikationskanal einrichten (z.B. im IRC) oder sich regelmäßig treffen, um das Projekt zu besprechen (z.B. in Gitter oder Google Hangout). Sie können diese Meetings sogar öffentlich machen, damit andere Leute zuhören können. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) zum Beispiel, [lädt zu wöchentlichen Sprechstunden ein](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs).
+Führungsteams können einen Kommunikationskanal einrichten (z.B. im IRC) oder sich regelmäßig treffen, um das Projekt zu besprechen (z.B. in Gitter oder Google Hangout). Sie können diese Meetings sogar öffentlich machen, damit andere Leute zuhören können. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) zum Beispiel, [lädt zu wöchentlichen Sprechstunden ein](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 Vergessen Sie nicht, nach der Festlegung von Führungsrollen zu dokumentieren, wie Menschen diese erreichen können! Richten Sie einen klaren Prozess ein, wie Leute Maintainer\*in werden oder einem Gremium in Ihrem Projekt beitreten können, und beschreiben Sie diesen Prozess in einer GOVERNANCE.md.
 
diff --git a/_articles/de/legal.md b/_articles/de/legal.md
index fc1b70edebb..e74a64e6176 100644
--- a/_articles/de/legal.md
+++ b/_articles/de/legal.md
@@ -113,7 +113,7 @@ Durch das Hinzufügen von "Papierkram", den einige für unnötig, schwer verstä
 Einige Situationen, in denen Sie eine zusätzliche Kontributionsvereinbarung für Ihr Projekt in Betracht ziehen sollten, sind z.B:
 
 * Ihre Anwälte wollen, dass alle Mitwirkenden ausdrücklich die Kontributionsbedingungen akzeptieren (_unterschreiben_, on- oder off-line), vielleicht weil sie der Meinung sind, dass die Open-Source-Lizenz selbst nicht ausreicht (obwohl sie ausreicht!). Wenn dies die einzige Sorge ist, sollte eine Kontributionsvereinbarung, welche die Open-Source-Lizenz des Projekts bestätigt, ausreichen. Das [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) ist ein gutes Beispiel für eine leichtgewichtige, zusätzliche Kontributionsvereinbarung. Für manche Projekte kann ein [Developer Certificate of Origin](https://github.com/probot/dco) eine Alternative sein.
-* Sie oder Ihre Anwälte wollen Entwickler\*innen bestätigen lassen, dass Ihre Commits autorisiert sind. Viele Projekte nutzen dafür das [Developer Certificate of Origin](https://developercertificate.org/). Beispielsweise nutzt die Node.js-Community [ein DCO](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md) anstatt ihres [vorherigen CLAs](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution). [DCO Probot](https://github.com/probot/dco) bietet eine einfache Möglichkeit, in Ihrem Projekt ein solches DCO automatisch einzufordern.
+* Sie oder Ihre Anwälte wollen Entwickler\*innen bestätigen lassen, dass Ihre Commits autorisiert sind. Viele Projekte nutzen dafür das [Developer Certificate of Origin](https://developercertificate.org/). Beispielsweise nutzt die Node.js-Community [ein DCO](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) anstatt ihres [vorherigen CLAs](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution). [DCO Probot](https://github.com/probot/dco) bietet eine einfache Möglichkeit, in Ihrem Projekt ein solches DCO automatisch einzufordern.
 * Ihr Projekt verwendet eine Open-Source-Lizenz, die keine ausdrückliche Patenterteilung enthält (z.B. MIT), die Sie aber von allen Mitwirkenden benötigen. Von denen können Einige für Unternehmen mit großen Patentportfolios arbeiten, die gegen Sie oder die anderen Mitwirkenden und Benutzer\*innen des Projekts verwendet werden könnten. Die [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) ist eine häufig verwendete zusätzliche Kontributionsvereinbarung mit einer der Apache License 2.0 entsprechenden Patenterteilung.
 * Ihr Projekt steht unter einer Copyleft-Lizenz, aber Sie müssen auch eine proprietäre Version des Projekts verbreiten. Sie werden von allen Kontributor\*innen eine Rechteverwertungsvereinbarung einholen müssen, die Ihnen (aber nicht der Öffentlichkeit) eine permissive Lizenz gewährt. Das [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) ist ein Beispiel für eine solche Vereinbarungen.
 * Sie sind der Meinung, dass Ihr Projekt im Laufe seiner Laufzeit seine Lizenz wechseln muss und möchten, dass die Mitwirkenden dieser Änderungen im Voraus zustimmen.
diff --git a/_articles/de/starting-a-project.md b/_articles/de/starting-a-project.md
index ca5f57be50b..e34d9f9cce3 100644
--- a/_articles/de/starting-a-project.md
+++ b/_articles/de/starting-a-project.md
@@ -40,7 +40,7 @@ _Freie Software_ meint dieselbe Art von Projekten wie _Open Source_. Der [Begrif
 
 * **Zusammenarbeit:** Open-Source-Projekte nehmen Beiträge aus der ganzen Welt an. [Exercism](https://github.com/exercism/) beispielsweise ist eine Programmierübungsplatform mit über 350 Kontributor\*innen.
 
-* **Anpassungen:** Open-Source-Projekte können von jedem Menschen für fast jeden Zweck benutzt werden. Leute können daraus sogar andere Dinge bauen. [WordPress](https://github.com/WordPress) beispielsweise begann als ein Fork eines existierenden Projekts namens [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
+* **Anpassungen:** Open-Source-Projekte können von jedem Menschen für fast jeden Zweck benutzt werden. Leute können daraus sogar andere Dinge bauen. [WordPress](https://github.com/WordPress) beispielsweise begann als ein Fork eines existierenden Projekts namens [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
 * **Transparenz:** In einem Open-Source-Projekt können Fehler oder Ungereimtheiten von jedem behoben werden. Transparenz ist sowohl für Regierungen in [Bulgarien](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) oder den [Vereinigten Staaten](https://web.archive.org/web/20180306072551/https://sourcecode.cio.gov/), für regulierte Industrien wie den Banken- oder Gesundheitssektor und für Sicherheitssoftware wie [Let's Encrypt](https://github.com/letsencrypt) gleichermaßen wichtig.
 
@@ -189,7 +189,7 @@ Neben thematischen Details präsentiert die CONTRIBUTING-Datei auch Ihre Erwartu
 
 Mit einem warmen, freundlichen Ton und spezifischen Vorschlägen für Beiträge (wie z.B. "Dokumentationen verfassen" oder "eine Website erstellen") können Sie dazu beitragen, dass sich Neuankömmlinge willkommen und begeistert fühlen.
 
-Beispielsweise leitet [Active Admin](https://github.com/activeadmin/activeadmin/)  [ihre Beitragsrichtlinien](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) ein mit:
+Beispielsweise leitet [Active Admin](https://github.com/activeadmin/activeadmin/)  [ihre Beitragsrichtlinien](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) ein mit:
 
 > Zuerst einmal vielen Dank, dass Sie überlegt haben, einen Beitrag zu Active Admin zu leisten, denn es sind Menschen wie Sie, die Active Admin so großartig machen.
 >
@@ -199,7 +199,7 @@ In der Anfangsphase Ihres Projekts kann Ihre CONTRIBUTING-Datei einfach sein. Si
 
 Im Laufe der Zeit können Sie weitere häufig gestellte Fragen zu Ihrer CONTRIBUTING-Datei hinzufügen. Diese Informationen aufzuschreiben verhindert, dass weniger Leute die immer wieder gleichen Fragen stellen werden.
 
-@nayafia's [CONTRIBUTING-Vorlage](https://github.com/nayafia/contributing-template/blob/master/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.
+@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, sodass mehr Leute sie bemerken. 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.
 
diff --git a/_articles/es/building-community.md b/_articles/es/building-community.md
index 85ad14861a7..92e4d643ff7 100644
--- a/_articles/es/building-community.md
+++ b/_articles/es/building-community.md
@@ -138,7 +138,7 @@ Finalmente, utiliza tu documentaci&oacute;n para hacer que las personas se sient
 
 Nunca vas a interactuar con la mayor&iacute;a de las personas que se acercan a tu proyecto. Puede haber colaboradores que no recibiste porque &aacute;lguien se sinti&oacute; intimidado o no supo c&oacute;mo comenzar. Incluso algunas palabras amables pueden evitar que esas personas abandonen tu proyecto por verse frustradas
 
-Por ejemplo, as&iacute; es como [Rubinius](https://github.com/rubinius/rubinius/) comienza su  [gu&iacute;a de contribuciones](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md):/
+Por ejemplo, as&iacute; es como [Rubinius](https://github.com/rubinius/rubinius/) comienza su  [gu&iacute;a de contribuciones](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):/
 
 > Queremos comenzar agradeciendo por utilizar Rubinius. Este proyecto es un trabajo de amor, y apreciamos a todos los usuarios que detectan errores, hacen mejoras al rendimiento, y ayudan con su documentaci&oacute;n. Cada contribuci&oacute;n es significativa, as&iacute; que gracias por participar. Dicho esto, aqu&iacute; dejamos algunas pautas que pedimos que sigan para que podamos abordar con &eacute;xito su problema.
 
@@ -161,7 +161,7 @@ Observa si puedes encontrar maneras de compartir la propiedad de tu comunidad ta
 
 ![cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Inicia un archivo de COLABORADORES o AUTORES en tu proyecto** que liste a todos los que colaboraron con tu proyecto, como lo hace [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md).
+* **Inicia un archivo de COLABORADORES o AUTORES en tu proyecto** que liste a todos los que colaboraron con tu proyecto, como lo hace [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
 
 * Si tienes una comunidad considerable, **env&iacute;a un bolet&iacute;n o escribe un post en un blog** agradeciendo a los colaboradores. Rust's [This Week in Rust](https://this-week-in-rust.org/) y Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) son dos buenos ejemplos.
 
diff --git a/_articles/es/code-of-conduct.md b/_articles/es/code-of-conduct.md
index d4d9af2ef86..291cdbe2e1d 100644
--- a/_articles/es/code-of-conduct.md
+++ b/_articles/es/code-of-conduct.md
@@ -54,7 +54,7 @@ Deber&iacute;as explicar de qu&eacute; manera tu c&oacute;digo de conducta va a
 
 Deber&iacute;as brindar a las personas, una manera privada (por ejemplo, mediante una direcci&oacute;n de email) de reportar una violaci&oacute;n al c&oacute;digo de conducta y explicar qui&eacute;n recibe dicho reporte. Puede ser un responsable de mantenimiento, un grupo de tales responsables, o un grupo de trabajo de c&oacute;digo de conducta.
 
-Recuerda que alguien puede que desee reportar una violaci&oacute;n acerca de la persona que recibe dichos reportes. En tal caso, br&iacute;ndales la posibilidad de que dichos reportes, sean revisados por alguien m&aacute;s. Por ejemplo, @ctb y @mr-c [explican en su proyecto](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+Recuerda que alguien puede que desee reportar una violaci&oacute;n acerca de la persona que recibe dichos reportes. En tal caso, br&iacute;ndales la posibilidad de que dichos reportes, sean revisados por alguien m&aacute;s. Por ejemplo, @ctb y @mr-c [explican en su proyecto](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
 > Instancias de abuso, acoso o similares comportamientos inaceptables pueden ser reportados mandando un email a **khmer-project@idyll.org** el cual solamente se dirigir&aacute; a C. Titus Brown and Michael R. Crusoe. Para reportar una cuesti&oacute;n que involucra a ambos, por favor env&iacute;a un email a **Judi Brown Clarke, Ph.D.** el Director de Diversidad en el BEACON Center for the Study of Evolution in Action, un centro de la Fundaci&oacute;n de Ciencia Nacional para la Ciencia y Tecnologia.*
 
diff --git a/_articles/es/leadership-and-governance.md b/_articles/es/leadership-and-governance.md
index 145e27db883..6d4bff40845 100644
--- a/_articles/es/leadership-and-governance.md
+++ b/_articles/es/leadership-and-governance.md
@@ -63,11 +63,11 @@ Si tu proyecto tiene una comunidad de contribuidores muy activa, puede formar un
 <aside markdown="1" class="pquote">
   Nosotros complementamos el equipo central con varios "sub-grupos". Cada sub-grupo se centra en un &aacute;rea espec&iacute;fica, por ejemplo, dise&ntilde;o de lenguajes o bibliotecas. (...) Para garantizar una coordinaci&oacute;n global y una visi&oacute;n s&oacute;lida y coherente del proyecto en su conjunto, cada sub-grupo est&aacute; dirigido por un miembro del equipo central.
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Los equipos de liderazgo pueden querer crear un canal designado (como en IRC) o reunirse regularmente para discutir el proyecto (como en Gitter o Google Hangout). Incluso puedes hacer p&uacute;blicas esas reuniones para que otras personas puedan escucharlas. [Cucumber-rub&iacute;](https://github.com/cucumber/cucumber-ruby), por ejemplo, [hospeda las horas de oficina cada semana](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talk-with-other-devs).
+Los equipos de liderazgo pueden querer crear un canal designado (como en IRC) o reunirse regularmente para discutir el proyecto (como en Gitter o Google Hangout). Incluso puedes hacer p&uacute;blicas esas reuniones para que otras personas puedan escucharlas. [Cucumber-rub&iacute;](https://github.com/cucumber/cucumber-ruby), por ejemplo, [hospeda las horas de oficina cada semana](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talk-with-other-devs).
 
 Una vez que haya establecido roles de liderazgo, ¡no olvides documentar c&oacute;mo la gente puede alcanzarlos! Establece un proceso claro para que alguien pueda convertirse en un mantenedor o unirse a un subcomit&eacute; en su proyecto y escribirlo en su GOVERNANCE.md.
 
diff --git a/_articles/es/starting-a-project.md b/_articles/es/starting-a-project.md
index 4f6324f09af..a4be874ce18 100644
--- a/_articles/es/starting-a-project.md
+++ b/_articles/es/starting-a-project.md
@@ -43,7 +43,7 @@ Realicemos una comparaci&oacute;n: un proceso de c&oacute;digo cerrado ser&iacut
 
 * **Colaboraci&oacute;n:** Los proyectos de c&oacute;digo abierto pueden aceptar cambios efectuados por cualquier persona alrededor del mundo. [Exercism](https://github.com/exercism/), por ejemplo, una plataforma para ejercicios de programaci&oacute;n con m&aacute;s de 350 colaboradores.
 
-* **Adopci&oacute;n y remezcla:** Los proyectos de c&oacute;digo abierto puedne ser usados por cualquiera para casi cualquier pr&oacute;p&oacute;sito. Las personas pueden usarlos hasta para construir otras cosas. [WordPress](https://github.com/WordPress), por ejemplo, comenzaron como un "fork" de un proyecto existente llamado [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
+* **Adopci&oacute;n y remezcla:** Los proyectos de c&oacute;digo abierto puedne ser usados por cualquiera para casi cualquier pr&oacute;p&oacute;sito. Las personas pueden usarlos hasta para construir otras cosas. [WordPress](https://github.com/WordPress), por ejemplo, comenzaron como un "fork" de un proyecto existente llamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
 * **Transparencia:** Cualquiera puede inspeccionar un proyecto de este tipo, ya sea para encontrar errores como inconsistencias. La transparencia es de importancia para gobiernos como el de [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o [United States](https://sourcecode.cio.gov/), para industrias reguladas como la bancaria o la del cuidado de la salud, y para la seguridad del software como [Let's Encrypt](https://github.com/letsencrypt).
 
@@ -179,7 +179,7 @@ Adem&aacute;s de detalles t&eacute;cnicos, este archivo es una oportunidad para
 
 Usando un tono c&aacute;lido y amigable, y ofreciendo sugerencias espec&iacute;ficas para contribuciones puede ayudar a los iniciados a sentirse bienvenidos y ansiosos de participar.
 
-Por ejemplo, [Active Admin](https://github.com/activeadmin/activeadmin/) comienza [su gu&iacute;a de contribuciones](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) con:
+Por ejemplo, [Active Admin](https://github.com/activeadmin/activeadmin/) comienza [su gu&iacute;a de contribuciones](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) con:
 
 > Primero, muchas gracias por considerar contribuir a Active Admin. Son personas como ustedes las que la hacen una gran herramienta.
 
@@ -187,7 +187,7 @@ En las primeras etapas del proyecto, tu archivo CONTRIBUITNG puede ser simple. S
 
 Con el tiempo, quiz&aacute;s debas agregar otras "preguntas frecuentes" a tu archivo. Escribir &eacute;sta informaci&oacute;n significa que menos personas te preguntar&aacute;n nuevamente la misma pregunta.
 
-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/master/CONTRIBUTING-template.md) o @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
+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.
 
diff --git a/_articles/fr/building-community.md b/_articles/fr/building-community.md
index 981fafb9a2f..929419b9e3b 100644
--- a/_articles/fr/building-community.md
+++ b/_articles/fr/building-community.md
@@ -138,7 +138,7 @@ Enfin, utilisez votre documentation pour que les gens se sentent les bienvenus 
 
 Vous n'interagirez jamais avec la plupart des personnes qui atterrissent sur votre projet. Il se peut que vous ayez reçu des contributions parce que quelqu'un se sentait intimidé ou ne savait pas par où commencer. Même quelques mots gentils peuvent empêcher quelqu'un de quitter votre projet avec de la frustration.
 
-Par exemple, voici comment [Rubinius](https://github.com/rubinius/rubinius/) commence [son guide de contribution] (https://github.com/rubinius/rubinius/blob/master/.github/contributing.md) :
+Par exemple, voici comment [Rubinius](https://github.com/rubinius/rubinius/) commence [son guide de contribution] (https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) :
 
 > Nous voulons commencer par vous dire merci d'utiliser Rubinius. Ce projet est un travail d'amour, et nous apprécions tous les utilisateurs qui détectent les bogues, améliorent les performances et aident à la documentation. Chaque contribution est significative, alors merci de votre participation. Cela étant dit, voici quelques lignes directrices que nous vous demandons de suivre afin que nous puissions résoudre votre problème avec succès.
 
@@ -160,7 +160,7 @@ Voyez si vous pouvez trouver le moyen de partager la propriété avec votre comm
 
 ![Problème de Cookiecutter](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Démarrez un fichier CONTRIBUTORS ou AUTHORS dans votre projet** qui répertorie tous ceux qui ont contribué à votre projet, comme [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md).
+* **Démarrez un fichier CONTRIBUTORS ou AUTHORS dans votre projet** qui répertorie tous ceux qui ont contribué à votre projet, comme [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
 
 * Si vous avez une communauté importante **, envoyez un bulletin d'information ou rédigez un article** remerciant les contributeurs. [La semaine de Rust](https://this-week-in-rust.org/) et celle de Hoodie [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) sont deux bons exemples.
 
diff --git a/_articles/fr/code-of-conduct.md b/_articles/fr/code-of-conduct.md
index 6532ce370bd..5dc103fd488 100644
--- a/_articles/fr/code-of-conduct.md
+++ b/_articles/fr/code-of-conduct.md
@@ -54,7 +54,7 @@ Vous devrez expliquer comment votre code de conduite sera appliqué **_avant_**
 
 Vous devriez donner aux gens un moyen privé (comme une adresse e-mail) de signaler une violation du code de conduite et d'expliquer qui reçoit ce rapport. Il pourrait s'agir d'un responsable, d'un groupe de responsables ou d'un groupe de travail sur le code de conduite.
 
-N'oubliez pas que quelqu'un pourrait vouloir signaler une violation à propos d'une personne qui reçoit ces rapports. Dans ce cas, donnez-leur la possibilité de signaler les violations à quelqu'un d'autre. Par exemple, @ctb et @mr-c [expliquent sur leur projet](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer) :
+N'oubliez pas que quelqu'un pourrait vouloir signaler une violation à propos d'une personne qui reçoit ces rapports. Dans ce cas, donnez-leur la possibilité de signaler les violations à quelqu'un d'autre. Par exemple, @ctb et @mr-c [expliquent sur leur projet](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer) :
 
 > Les cas de comportement abusif, harcelant ou autrement inacceptable peuvent être signalés en envoyant un courriel à **khmer-project@idyll.org**, ce qui ne concerne que C. Titus Brown et Michael R. Crusoe. Pour signaler un problème concernant l'un ou l'autre d'entre eux, veuillez envoyer un courriel à **Judi Brown Clarke, Ph. D.** Directrice de la diversité au Centre BEACON pour l'étude de l'évolution en action, un centre NSF pour la science et la technologie.*
 
diff --git a/_articles/fr/leadership-and-governance.md b/_articles/fr/leadership-and-governance.md
index cfc190dc21f..35eb894925d 100644
--- a/_articles/fr/leadership-and-governance.md
+++ b/_articles/fr/leadership-and-governance.md
@@ -63,11 +63,11 @@ Si votre projet a une communauté de contributeurs très active, vous pouvez for
 <aside markdown="1" class="pquote">
   \[Nous\] complétons l'équipe de base avec plusieurs "sous-équipes". Chaque sous-équipe est concentrée sur une zone spécifique, par exemple, la conception de langage ou les bibliothèques. (...) Pour assurer une coordination globale et une vision forte et cohérente pour le projet dans son ensemble, chaque sous-équipe est dirigée par un membre de l'équipe de base.
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Les équipes de direction peuvent vouloir créer une chaîne désignée (comme sur IRC) ou se rencontrer régulièrement pour discuter du projet (comme sur Gitter ou Google Hangout). Vous pouvez même rendre ces réunions publiques afin que les autres puissent les écouter. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), par exemple, [héberge des heures de bureau chaque semaine](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs).
+Les équipes de direction peuvent vouloir créer une chaîne désignée (comme sur IRC) ou se rencontrer régulièrement pour discuter du projet (comme sur Gitter ou Google Hangout). Vous pouvez même rendre ces réunions publiques afin que les autres puissent les écouter. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), par exemple, [héberge des heures de bureau chaque semaine](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 Une fois que vous avez établi des rôles de leadership, n'oubliez pas de documenter comment les gens peuvent les atteindre ! Établissez un processus clair pour que quelqu'un puisse devenir responsable ou rejoindre un sous-comité dans votre projet, et l'écrire dans votre GOVERNANCE.md.
 
diff --git a/_articles/fr/starting-a-project.md b/_articles/fr/starting-a-project.md
index 73a18e2867a..662905a0857 100644
--- a/_articles/fr/starting-a-project.md
+++ b/_articles/fr/starting-a-project.md
@@ -43,7 +43,7 @@ Par comparaison, un processus de source fermée serait de se rendre dans un rest
 
 * **Collaboration :** Les projets open source peuvent accepter des changements de n'importe qui dans le monde. [Exercism](https://github.com/exercism/), par exemple, est une plate-forme d'exercices de programmation avec plus de 350 contributeurs.
 
-* **Adoption et remixage :** Les projets open source peuvent être utilisés par n'importe qui pour presque n'importe quel but. Les gens peuvent même l'utiliser pour construire d'autres choses. [WordPress](https://github.com/WordPress), par exemple, a commencé en tant que fork d'un projet existant appelé [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
+* **Adoption et remixage :** Les projets open source peuvent être utilisés par n'importe qui pour presque n'importe quel but. Les gens peuvent même l'utiliser pour construire d'autres choses. [WordPress](https://github.com/WordPress), par exemple, a commencé en tant que fork d'un projet existant appelé [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
 * **Transparence :** Tout le monde peut inspecter un projet open source pour y chercher des erreurs ou des incohérences. La transparence est importante pour des gouvernements comme celui de [Bulgarie](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou des [États-Unis](https://sourcecode.cio.gov/), les industries réglementées comme la banque ou les soins de santé, et les logiciels de sécurité comme [Let's Encrypt](https://github.com/letsencrypt).
 
@@ -179,7 +179,7 @@ En plus des détails techniques, un fichier CONTRIBUTING est une opportunité de
 
 Utiliser un ton chaleureux et amical et offrir des suggestions précises pour les contributions (comme la rédaction de documentation ou la création d'un site Web) peut faire beaucoup pour que les nouveaux arrivants se sentent les bienvenus et enthousiastes à l'idée de participer.
 
-Par exemple, [Active Admin](https://github.com/activeadmin/activeadmin/) démarre [son guide de contribution](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) avec:
+Par exemple, [Active Admin](https://github.com/activeadmin/activeadmin/) démarre [son guide de contribution](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) avec:
 
 > Tout d'abord, merci d'envisager de contribuer à Active Admin. Ce sont des gens comme vous qui font d'Active Admin un outil formidable.
 
@@ -187,7 +187,7 @@ Dans les premières étapes de votre projet, votre fichier CONTRIBUTING peut êt
 
 Au fil du temps, vous pouvez ajouter d'autres questions fréquemment posées à votre fichier CONTRIBUTING. L'écriture de cette information signifie que moins de personnes vous poseront les mêmes questions encore et encore.
 
-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/master/CONTRIBUTING-template.md) ou le guide de @mozilla ["Comment Construire un CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
+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.
 
diff --git a/_articles/hu/building-community.md b/_articles/hu/building-community.md
index 096b2e2a3cc..2e1051c4336 100644
--- a/_articles/hu/building-community.md
+++ b/_articles/hu/building-community.md
@@ -139,7 +139,7 @@ Végül, de nem utolsó sorban a dokumentáció alapján érezzék az emberek, h
 
 Általában nem fogsz közvetlenül minden emberrel kommunikálni, aki megfordul a projekten. Lehet, hogy lesznek olyan hozzájárulások, amelyeket azért nem kapsz meg, mert valaki elrettent a projekttől, vagy nem tudta, hogy hol kezdje. Akár néhány kedves szó is elég lehet ahhoz, hogy megakadályozd, hogy valaki csalódottan hagyja el a projektet.
 
-Itt egy példa, hogy hogyan kezdj a [Rubinius](https://github.com/rubinius/rubinius/) projektben, [a CONTRIBUTING útmutatójuk](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md):
+Itt egy példa, hogy hogyan kezdj a [Rubinius](https://github.com/rubinius/rubinius/) projektben, [a CONTRIBUTING útmutatójuk](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
 
 > Mindenekelőtt azzal szeretnénk kezdeni, hogy köszönjük azt, hogy használod a Rubinius-t. Ez a projekt szeretetteljes munkát jelent, és nagyra értékeljük az összes felhasználót, aki hibákat észlel, javít a teljesítményben és segítséget nyújt a dokumentációban. Minden hozzájárulás hasznos, ezért köszönjük a részvételed. Kérjük néhány iránymutatást tarts be, hogy sikeresen meg tudjuk oldani a problémádat.
 
@@ -161,7 +161,7 @@ Nézd meg, hogyan találhatod meg a módját, hogy a lehető legnagyobb mérték
 
 ![Cookiecutter hiba](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Állíts össze egy CONTRIBUTORS vagy AUTHORS fájlt a projektben,** amely listáz mindenkit aki hozzájárul a projekthez. Például ahogy a [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md) csinálja.
+* **Állíts össze egy CONTRIBUTORS vagy AUTHORS fájlt a projektben,** amely listáz mindenkit aki hozzájárul a projekthez. Például ahogy a [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) csinálja.
 
 * Ha széles közösséged van, **akkor küldj ki hírlevelet vagy vezess blogot** amelyen megköszönöd a hozzájárulásokat. A Rust-nak a [Heti Rust](https://this-week-in-rust.org/) és a Hoodie-nak a [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) két jó példa erre.
 
diff --git a/_articles/hu/code-of-conduct.md b/_articles/hu/code-of-conduct.md
index ff15b04cdb6..b135eccca46 100644
--- a/_articles/hu/code-of-conduct.md
+++ b/_articles/hu/code-of-conduct.md
@@ -54,7 +54,7 @@ Magyarázd el részletesen, hogy a magatartási kódexnek hogyan szerzel érvén
 
 Praktikus biztosítani egy privát csatornát (pl. e-mail cím), amin a magatartási kódex megsértését jelenteni tudják. Add meg azt is, hogy ki vagy kik kapják a jelentést. Ez lehet egy vagy több karbantartó, esetleg egy külön testület.
 
-Ne feledd, előfordulhat, hogy épp olyan személyre vonatkozóan érkezik kifogás aki szintén kapja a jelentést. Ebben az esetben adj lehetőséget arra, hogy más személy részére jelentsék a szabálysértést. Például, @ctb és @mr-c [kifejtik ezt a projektjükben](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+Ne feledd, előfordulhat, hogy épp olyan személyre vonatkozóan érkezik kifogás aki szintén kapja a jelentést. Ebben az esetben adj lehetőséget arra, hogy más személy részére jelentsék a szabálysértést. Például, @ctb és @mr-c [kifejtik ezt a projektjükben](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
 > A zaklató, erőszakos vagy egyéb elfogadhatatlan viselkedést emailben lehet jelenteni **khmer-project@idyll.org** címre, amelyet csak C. Titus Brown és Michael R. Crusoe kap meg. Ha bármelyikük érintett a szabálysértésben, akkor **Judi Brown Clarke, Ph.D.** Sokszínűségért Felelős Igazgató legyen a címzett.*
 
diff --git a/_articles/hu/leadership-and-governance.md b/_articles/hu/leadership-and-governance.md
index 44be24d61dc..d125f3a6846 100644
--- a/_articles/hu/leadership-and-governance.md
+++ b/_articles/hu/leadership-and-governance.md
@@ -63,11 +63,11 @@ Ha a projektben nagyon aktív a közreműködő közösség, akkor a "karbantart
 <aside markdown="1" class="pquote">
   A központi csapatot számos "alcsoporttal" egészítettük ki. Minden alcsoportnak saját területe van, például nyelvi tervezés vagy a programozói könyvtárak. (...) Minden egyes alcsoportot a központi csapat egy tagja vezeti, ezzel biztosítjuk a globális koordinációt és az egész projekt egységes, koherens vízióját.
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-A vezetői csapatok egy kijelölt csatornát hozhatnak létre (például IRC) vagy találkozhatnak rendszeresen egyéb projekt megbeszéléseken (mint a Gitter vagy Google Hangout). Akár nyilvánosak is lehetnek ezek, így a többi résztvevő is láthatja. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), például, [minden héten időt biztosít erre](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs).
+A vezetői csapatok egy kijelölt csatornát hozhatnak létre (például IRC) vagy találkozhatnak rendszeresen egyéb projekt megbeszéléseken (mint a Gitter vagy Google Hangout). Akár nyilvánosak is lehetnek ezek, így a többi résztvevő is láthatja. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), például, [minden héten időt biztosít erre](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 Miután létrehoztad a vezetői szerepeket, ne felejtsd el dokumentálni, hogyan érhetik el őket az emberek! Határozz meg egy világos folyamatot arra vonatkozóan, hogy valaki hogyan válhat karbantartóvá, vagy csatlakozhat egy albizottsághoz a projektben, és írd le a GOVERNANCE.md-ben.
 
diff --git a/_articles/hu/legal.md b/_articles/hu/legal.md
index 1e47effe4a4..cca7b35181d 100644
--- a/_articles/hu/legal.md
+++ b/_articles/hu/legal.md
@@ -105,7 +105,7 @@ Amikor ez olyan "papírmunkát" okoz, amit egyesek szükségtelennek, nehezen é
 Egyes helyzetekben, szükséges lehet további, a projekthez kapcsolódó közreműködői megállapodást kötni:
 
 * A jogászok azt szeretnék, ha minden résztvevő kifejezetten elfogadná (_aláírná_, online vagy offline) a közreműködői feltételeket, talán azért, mert úgy érzik, hogy a nyílt forráskódú licenc nem elég (annak ellenére, hogy ez nem így van!). Ha csak ez az egyetlen gond, akkor elegendőnek kell lennie a nyílt forráskódú licencnek, és egy azt megerősítő közreműködői megállapodásnak. A [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) egy jó példa egy érthető, könnyen használható CLA-nak.
-* Te vagy a jogászok azt szeretnék, hogy a fejlesztők minden commit-ja jogilag megállja a helyét. Ezt a projektek a [Developer Certificate of Origin](https://developercertificate.org/) segítségével érik el. Például, a Node.js közösség a saját CLA-juk helyett [inkább](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) a DCO-t [használja](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md). A DCO automatikus kikényszerítése egy Git repository-n legegyszerűbben a [DCO Probot-tal](https://github.com/probot/dco) érhető el.
+* Te vagy a jogászok azt szeretnék, hogy a fejlesztők minden commit-ja jogilag megállja a helyét. Ezt a projektek a [Developer Certificate of Origin](https://developercertificate.org/) segítségével érik el. Például, a Node.js közösség a saját CLA-juk helyett [inkább](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) a DCO-t [használja](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md). A DCO automatikus kikényszerítése egy Git repository-n legegyszerűbben a [DCO Probot-tal](https://github.com/probot/dco) érhető el.
 * A projekt egy olyan nyílt forráskódú licencet használ, amely nem tartalmaz kifejezetten szabadalom használati engedélyt (például MIT), így szükséges egy szabadalom használati engedély nyilatkozat minden résztvevőtől, akik közül néhányan nagy szabadalom portfólióval rendelkező cégeknek dolgoznak, amelyek a szabadalmaikat felhasználva támadhatnak téged vagy a projekt többi résztvevőjét és felhasználóit. Az [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) egy elterjedten használt kiegészítő közreműködői megállapodás, ami az Apache License 2.0 licencben szereplő szabadalom használati jogosultságot tartalmazza.
 * A projekted "copyleft" licencelésű, de a projektből egy szabadalmaztatott, saját verziót is terjeszteni szeretnél. Minden résztvevőnek át kell ruháznia rád a szerzői jogait, hogy megengedje neked (de nem a nyilvánosságnak) a szabad felhasználást. A [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) egy ilyen típusú megállapodás.
 * Úgy gondolod, hogy a projekt élete során szükség lehet a licenc módosítására, és azt szeretnéd, hogy a közreműködők előre elfogadják az ilyen jellegű változtatásokat.
@@ -134,7 +134,7 @@ Ha a céged első nyílt forráskódú projektjének publikálásán dolgozol, a
 
 Hosszabb távon a jogi csapat többet tehet azért, hogy segítsen a vállalatnak profitálni a nyílt forráskódból és közben biztonságban tudhassa magát:
 
-* **Munkavállalói hozzájárulás szabályozása:** Fontold meg olyan vállalati irányelv kidolgozását, amely meghatározza, hogy a munkavállalók hogyan járulnak hozzá a nyílt forráskódú projektekhez. Az egyértelmű szabályozás csökkenti a zavart az alkalmazottak körében, és segít abban, hogy a vállalat érdekeinek megfelelően járuljanak hozzá a nyílt forráskódú projektekhez, akár munkájuk részeként, akár szabadidejükben. Jó példa erre a Rackspace féle [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/). 
+* **Munkavállalói hozzájárulás szabályozása:** Fontold meg olyan vállalati irányelv kidolgozását, amely meghatározza, hogy a munkavállalók hogyan járulnak hozzá a nyílt forráskódú projektekhez. Az egyértelmű szabályozás csökkenti a zavart az alkalmazottak körében, és segít abban, hogy a vállalat érdekeinek megfelelően járuljanak hozzá a nyílt forráskódú projektekhez, akár munkájuk részeként, akár szabadidejükben. Jó példa erre a Rackspace féle [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/hu/starting-a-project.md b/_articles/hu/starting-a-project.md
index c10e4a76b1a..d4d585486ba 100644
--- a/_articles/hu/starting-a-project.md
+++ b/_articles/hu/starting-a-project.md
@@ -36,7 +36,7 @@ _Free software_ kifejezés ugyanazokra a projektekre vonatkozik, mint amire az _
 
 * **Együttműködés:** A nyílt forráskódú projektek bárkitől elfogadnak módosítást a világ bármely részéről. [Exercism](https://github.com/exercism/), például egy programozási gyakorlást segítő projekt több, mint 350 fejlesztő részvételével.
 
-* **Elterjedés és újrafelhasználás:** A nyílt forráskódú projekteket bárki használhatja szinte bármilyen célra. Az emberek akár más dolgok létrehozására is felhasználhatják. A [WordPress] (https://github.com/WordPress) például úgy kezdte, hogy egy létező, [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md) nevű projektet elágaztattak.
+* **Elterjedés és újrafelhasználás:** A nyílt forráskódú projekteket bárki használhatja szinte bármilyen célra. Az emberek akár más dolgok létrehozására is felhasználhatják. A [WordPress] (https://github.com/WordPress) például úgy kezdte, hogy egy létező, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) nevű projektet elágaztattak.
 
 * **Átláthatóság:** A nyílt forráskódú projektet bárki megvizsgálhatja, vagy hibákat kereshet benne. Az átláthatóság a kormányoknak is fontos, mint ahogy [Bulgária](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) teszi ezt, vagy ahogy az [Amerikai Egyesült Államok](https://sourcecode.cio.gov/) szabályozza a bank, és egészségügy iparát, de fontos a biztonsági szoftverek esetén is, mint a [Let's Encrypt](https://github.com/letsencrypt).
 
@@ -173,7 +173,7 @@ A műszaki adatokon kívül, a CONTRIBUTING fájl lehetőséget nyújt arra, hog
 
 Kedves, barátságos hang használata, és konkrét javaslatok nyújtása a hozzájárulásokhoz (például dokumentáció készítése vagy weboldal készítése) nagyban hozzájárulhat ahhoz, hogy az újonnan érkezők azt érezzék, hogy szívesen látják őket, és örüljenek a részvételnek.
 
-Például az [Active Admin](https://github.com/activeadmin/activeadmin/) a [saját részvételi szabályzatát](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) ezzel kezdi:
+Például az [Active Admin](https://github.com/activeadmin/activeadmin/) a [saját részvételi szabályzatát](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) ezzel kezdi:
 
 > Legelőször is, köszönöm hogy részt kívánsz venni az Active Admin projektben. Az olyan emberek mint te, tehetik az Active Admin ilyen nagyszerű eszközzé.
 
@@ -181,7 +181,7 @@ A CONTRIBUTING állomány a projekt korai fázisában egyszerű. Mindig el kell
 
 Idővel további gyakori kérdéseket adhatsz hozzá a CONTRIBUTING fájlhoz. Ezen információk írása azt jelenti, hogy kevesebb ember fogja újra és újra ugyanazt a kérdést feltenni.
 
-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/master/CONTRIBUTING-template.md) vagy a @mozilla's ["Hogyan építs CONTRIBUTING.md-t?"](https://mozillascience.github.io/working-open-workshop/contributing/).
+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.
 
diff --git a/_articles/id/building-community.md b/_articles/id/building-community.md
index b30ac71734b..09d564c460b 100644
--- a/_articles/id/building-community.md
+++ b/_articles/id/building-community.md
@@ -138,7 +138,7 @@ Akhirnya, gunakan dokumentasi Anda untuk membuat orang lain nyaman pada setiap l
 
 Anda tidak akan pernah berinteraksi dengan sebagian besar orang-orang yang hadir pada proyek Anda. Bisa jadi terdapat kontribusi yang tidak Anda dapatkan karena seseorang merasa terintimidasi atau tidak tahu bagaimana memulainya. Sebuah kata-kata sederhana bisa menjaga mereka untuk tetap bertahan dan bebas dari rasa frustasi.
 
-Sebagai contoh, berikut bagaimana cara [Rubinius](https://github.com/rubinius/rubinius/) memulai [panduan kontribusinya](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md):
+Sebagai contoh, berikut bagaimana cara [Rubinius](https://github.com/rubinius/rubinius/) memulai [panduan kontribusinya](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
 
 > Kita ingin memulainya dengan mengucapkan terima kasih karena menggunakan Rubinius. Proyek ini merupakan hasil cinta kami, dan kami menghargai semua pengguna yang menemukan kesalahan, membuat perbaikan performa, dan membantu dengan dokumentasi. Setiap kontribusi sangat berharga, sehingga kami mengucapkan terima kasih untuk berpartisipasi. Meski demikian, berikut adalah beberapa panduan yang kami harapkan untuk bisa diikuti sehingga kami bisa menyelesaikan permasalahan Anda dengan baik.
 
@@ -160,7 +160,7 @@ Cari cara untuk bisa berbagi kepemilikan dengan komunitas Anda sebanyak mungkin.
 
 ![cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Bualah dokumen CONTRIBUTORS atau AUTHORS pada proyek Anda** yang mendata semua orang yang berkontribusi pada proyek Anda, seperti [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md).
+* **Bualah dokumen CONTRIBUTORS atau AUTHORS pada proyek Anda** yang mendata semua orang yang berkontribusi pada proyek Anda, seperti [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
 
 * Jika Anda memiliki komunitas yang cukup besar, **kirimkan surat berita atau tuliskan blog** dan ucapkan terima kasih pada kontributor. [This Week in Rust](https://this-week-in-rust.org/) milik Rust dan [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) milik Hoodie adalah dua contoh bagus.
 
diff --git a/_articles/id/code-of-conduct.md b/_articles/id/code-of-conduct.md
index eab55cfb5a0..910858359b9 100644
--- a/_articles/id/code-of-conduct.md
+++ b/_articles/id/code-of-conduct.md
@@ -54,7 +54,7 @@ Anda harus menjelaskan bagaimana kode etik Anda akan diterapkan **_sebelum_** pe
 
 Anda harus memberikan sebuah jalan yang pribadi (seperti alamat email) untuk melaporkan pelanggaran kode etik dan menjelaskan siapa yang menerima laporan tersebut. Penerima laporan bisa jadi pengelola, sekelompok orang pengelola, atau tim kode etik.
 
-Jangan lupa bahwa seseorang mungkin melaporkan pelanggaran terhadap orang yang akan menerima laporan tersebut. Pada kasus ini, berikan opsi untuk melaporkan pelanggaran pada orang lain. Misalnya, @ctb dan @mr-c [menjelaskan pada proyek mereka](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+Jangan lupa bahwa seseorang mungkin melaporkan pelanggaran terhadap orang yang akan menerima laporan tersebut. Pada kasus ini, berikan opsi untuk melaporkan pelanggaran pada orang lain. Misalnya, @ctb dan @mr-c [menjelaskan pada proyek mereka](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
 > Perilaku kasar, melecehkan, atau perilaku lainnya yang tidak dapat diterima dapat dilaporkan dengan mengirimkan email pada **khmer-project@idyll.org** yang akan sampai pada C. Titus Brown dan Michael R. Crusoe. Untuk melaporkan masalah pada salah satu dari mereka, kirimkan email pada **Judi Brown Clarke, Ph.D.** Direktur  Diversity pada BEACON Center untuk Studi Evolusi, sebuah pusat studi NSF untuk Ilmu Pengetahuan dan Teknologi.*
 
diff --git a/_articles/id/leadership-and-governance.md b/_articles/id/leadership-and-governance.md
index bd01bad63ec..5207df0d5bf 100644
--- a/_articles/id/leadership-and-governance.md
+++ b/_articles/id/leadership-and-governance.md
@@ -63,11 +63,11 @@ Jika proyek Anda memiliki komunitas kontributor yang aktif, Anda mungkin perlu m
 <aside markdown="1" class="pquote">
   \[Kami\] melengkapi tim inti dengan beberapa "sub tim". Setiap sub tim berfokus pada area tertentu, misalnya desain bahasa atau pustaka. (...) Untuk memastikan koordinasi yang kuat dan global, penyamaan visi pada proyek secara keseluruhan, setiap sub tim dipimpin oleh anggota dari tim inti.
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Tim pemimpin mungkin perlu membuat chanel khusus (seperti IRC) atau bertemu secara rutin untuk mendiskusikan proyek (seperti pada Gitter atau Google Hangout). Anda bisa membuat hasil rapat tersebut secara terbuka sehingga orang lain bisa mendengarkan. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), misalnya, [mengadakan jam kerja setiap minggunya](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs).
+Tim pemimpin mungkin perlu membuat chanel khusus (seperti IRC) atau bertemu secara rutin untuk mendiskusikan proyek (seperti pada Gitter atau Google Hangout). Anda bisa membuat hasil rapat tersebut secara terbuka sehingga orang lain bisa mendengarkan. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), misalnya, [mengadakan jam kerja setiap minggunya](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 Setelah Anda mendefinisikan peran pemimpin Anda, jangan lupa untuk mendokumentasikan bagaimana orang lain bisa mencapai posisi tersebut! Buatlah proses yang jelas bagaimana seseorang bisa menjadi seorang pengelola atau bergabung pada sub komite pada proyek Anda, dan tuliskan pada GOVERNANCE.md.
 
diff --git a/_articles/id/starting-a-project.md b/_articles/id/starting-a-project.md
index f1c276d7109..052e0dea70e 100644
--- a/_articles/id/starting-a-project.md
+++ b/_articles/id/starting-a-project.md
@@ -43,7 +43,7 @@ Sebagai perbandingan, sebuah proses yang tertutup akan seperti dimana Anda pergi
 
 * **Kolaborasi:** Proyek open source bisa menerima perubahan dari siapapun juga di seluruh dunia. [Exercism](https://github.com/exercism/), sebagai contoh, adalah kerangka latihan pemrograman dengan lebih dari 350 kontributor.
 
-* **Adopsi dan menggabungkan:** Proyek open source bisa digunakan oleh siapapun untuk hampir semua tujuan. Bahkan bisa digunakan untuk membangun proyek lain. [WordPress](https://github.com/WordPress), sebagai contoh, dimulai dari hasil _fork_ dari proyek yang sudah ada bernama [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
+* **Adopsi dan menggabungkan:** Proyek open source bisa digunakan oleh siapapun untuk hampir semua tujuan. Bahkan bisa digunakan untuk membangun proyek lain. [WordPress](https://github.com/WordPress), sebagai contoh, dimulai dari hasil _fork_ dari proyek yang sudah ada bernama [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
 * **Transparansi:** Setiap orang dapat melihat kesalahan atau inkonsistensi pada proyek open source. Transparansi sangat penting bagi pemerintah seperti [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) atau  [Amerika Serikat](https://sourcecode.cio.gov/), industri yang memiliki regulasi seperti perbankan atau kesehatan, dan perangkat lunak keamanan seperti [Let's Encrypt](https://github.com/letsencrypt).
 
@@ -179,7 +179,7 @@ Selain aspek teknis, dokumen CONTRIBUTING juga merupakan kesempatan untuk mengko
 
 Menggunakan nada yang bersahabat dan menawarkan tawaran yang spesifik untuk kontribusi (misalnya menuliskan dokumentasi, atau membuat halaman web) bisa membuat pendatang merasa nyaman dan diterima serta tertarik untuk berpartisipasi.
 
-Sebagai contoh, [Active Admin](https://github.com/activeadmin/activeadmin/) memulai [panduan kontribusinya](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) dengan:
+Sebagai contoh, [Active Admin](https://github.com/activeadmin/activeadmin/) memulai [panduan kontribusinya](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) dengan:
 
 > Pertama-tama, terima kasih karena Anda mempertimbangkan untuk berpartisipasi pada Active Admin. Orang-orang seperti Anda yang membuat Active Admin menjadi sebuah perangkat yang hebat.
 
@@ -187,7 +187,7 @@ Pada fase awal dari proyek Anda, dokumen CONTRIBUTING bisa sangat sederhana. And
 
 Seiring dengan berjalannya waktu, Anda bisa menambahkan pertanyaan yang paling sering ditanyakan pada dokumen CONTRIBUTING. Menuliskan informasi ini berarti lebih sedikit orang yang akan bertanya pertanyaan yang sama kepada Anda berulang kali.
 
-Untuk bantuan tentang penulisan dokumen CONTRIBUTING, silahkan lihat  [template panduan berkontribusi](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) milik @nayafia atau ["Bagaimana Membangun Dokumen CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) milik @mozilla.
+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.
 
diff --git a/_articles/ja/building-community.md b/_articles/ja/building-community.md
index 4646d63c147..64bed111839 100644
--- a/_articles/ja/building-community.md
+++ b/_articles/ja/building-community.md
@@ -30,7 +30,7 @@ related:
 * **コントリビュートの仕方をわかりやすく説明しよう**。その際、 [CONTRIBUTING ファイルを使い](../starting-a-project/#コントリビュートのガイドラインを書く)、イシューの状態を最新に保ちましょう。
 
 [GitHub の 2017 Open Source Survey](http://opensourcesurvey.org/2017/) では、未完成であったり混乱するドキュメントはオープンソースプロジェクトのユーザーにとって最大の問題である事が示されています。良いドキュメントが人々をあなたのプロジェクトに招き入れます。結果として、イシューやプルリクエストを登録する人が出てきます。こういったやり取りを、漏斗の底に近づいてもらう機会として利用しましょう。
- 
+
 * **新しくプロジェクトに参加してくれた人に対して、興味を示してくれたことへの感謝の気持ちを伝えよう！** 一度ネガティブな経験をしただけで、人は戻ってきてくれなくなってしまいます。
 * **すぐに返事を返すようにしよう。** 一ヶ月もの間イシューに返事をしなければ、おそらく彼らはあなたのプロジェクトのことを忘れ去ってしまうでしょう。
 * **受け入れるコントリビュートの種類について心を広く持とう。** 多くのコントリビューターがバグレポートや小さな修正から始めます。プロジェクトへの[コントリビュートには多くのやり方](../how-to-contribute/#コントリビュートするということが意味するもの)があります。人々が望むやり方でコントリビュートできるように手助けしましょう。
@@ -82,7 +82,7 @@ related:
 
 ![Middleman pull request](/assets/images/building-community/middleman_pr.png)
 
-[Mozilla の調査によると](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177)、48時間以内にコードレビューをしてもらったコントリビューターは返答や再度コントリビュートを行う確率が非常に高いということがわかっています。 
+[Mozilla の調査によると](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177)、48時間以内にコードレビューをしてもらったコントリビューターは返答や再度コントリビュートを行う確率が非常に高いということがわかっています。
 
 Stack Overflow、Twitter、Reddit といったインターネットにおける他の場所でもあなたのプロジェクトについての会話が交わされることがあります。そのような場所からも通知が来るよう設定しておくことで、誰かがあなたのプロジェクトに言及したときに通知を受け取ることができます。
 
@@ -138,7 +138,7 @@ CONTRIBUTING ファイルに、新しいコントリビューターに始め方
 
 プロジェクトを見たほとんどの人はあなたとやり取りすることはないでしょう。人々は恐れを感じたり、どのように始めたらよいかわからないといった理由で、コントリビュートをやめたかもしれません。そういった場合でも、ほんの少しでも彼らを歓迎する言葉があれば、彼らがイライラしてプロジェクトを去ってしまう事を防ぐことができます。
 
-これは [Rubinius](https://github.com/rubinius/rubinius/) の[コントリビュートガイド](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md)の書き出しの例です：
+これは [Rubinius](https://github.com/rubinius/rubinius/) の[コントリビュートガイド](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md)の書き出しの例です：
 
 > まず最初に、Rubinius を使ってくれてありがとうとお伝えしたいと思います。このプロジェクトは愛の結晶であり、バグを見つけてくれたり、性能を向上させたり、ドキュメントを書くことを手伝ってくれる全てのユーザーに感謝しています。あらゆるコントリビュートには意味があるので、参加してくれることに感謝しています。そうは言っても、私達があなた達の問題に首尾よく取り組む事ができるように、いくつかのガイドラインに従うようお願いしたいと思います。
 
@@ -160,7 +160,7 @@ CONTRIBUTING ファイルに、新しいコントリビューターに始め方
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **CONTRIBUTORS ファイルや AUTHORS ファイルをプロジェクトに作ろう。** [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md) が実施しているように、これらのファイルにプロジェクトにコントリビュートしてくれた人すべてをリストしましょう。
+* **CONTRIBUTORS ファイルや AUTHORS ファイルをプロジェクトに作ろう。** [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) が実施しているように、これらのファイルにプロジェクトにコントリビュートしてくれた人すべてをリストしましょう。
 
 * かなり大きなコミュニティを既に獲得しているのであれば、コントリビューターへの感謝を伝える **ニュースレターを送ったり、ブログポストを書いたりしましょう。** Rust の [This Week in Rust](https://this-week-in-rust.org/) や Hoodie の [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) はどちらも良い事例です。
 
diff --git a/_articles/ja/code-of-conduct.md b/_articles/ja/code-of-conduct.md
index b488cc46cca..26a4dbf6b7c 100644
--- a/_articles/ja/code-of-conduct.md
+++ b/_articles/ja/code-of-conduct.md
@@ -54,7 +54,7 @@ CODE_OF_CONDUCT ファイルをプロジェクトのルートディレクトリ
 
 メンバーに対しては、行動規範の違反を報告するための（メールアドレスのような）プライベートな方法を与え、それを受け取るのが誰なのかを説明するべきです。それは一人のメンテナーかもしれないし、メンテナー達のグループかもしれないし、行動規範チームかもしれません。
 
-行動規範違反の報告を受けている人自身の違反行為を、誰かが報告するかもしれないことを忘れてはいけません。この場合は、他の人に違反を報告できるような選択肢を設けましょう。例えば、 @ctb と @mr-c は、彼らの [khmer](https://github.com/dib-lab/khmer) というプロジェクトで[このように説明しています](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst):
+行動規範違反の報告を受けている人自身の違反行為を、誰かが報告するかもしれないことを忘れてはいけません。この場合は、他の人に違反を報告できるような選択肢を設けましょう。例えば、 @ctb と @mr-c は、彼らの [khmer](https://github.com/dib-lab/khmer) というプロジェクトで[このように説明しています](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst):
 
 > 不正行為やハラスメント、受け入れられない行為は、 **khmer-project@idyll.org** にメールを送ることによって報告することが出来ます。このメールは、 C. Titus Brown と Michael R. Crusoe のみが受け取ります。彼ら二人のどちらかが関係する問題について報告する場合は、 NSF Center for Science and Technology の BEACON Center for the Study of Evolution in Action のダイバーシティディレクターの **Judi Brown Clarke, Ph.D.** にメールで報告して下さい。*
 
diff --git a/_articles/ja/leadership-and-governance.md b/_articles/ja/leadership-and-governance.md
index 6e77c47efff..dea45030763 100644
--- a/_articles/ja/leadership-and-governance.md
+++ b/_articles/ja/leadership-and-governance.md
@@ -63,11 +63,11 @@ related:
 <aside markdown="1" class="pquote">
   \[私達は\] コアチームに対して、幾つかの「サブチーム」で支えています。各サブチームはそれぞれ特定の領域にフォーカスしています。例えば、言語設計やライブラリなどです。 (...) 世界をまたがるコラボレーションと、プロジェクト全体として協力で一貫したビジョンを維持するために、各サブチームはコアチームのメンバーによってリードされています。
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-リーダーシップチームは( IRC のような)専用のチャンネルを作りたいと思ったり、プロジェクトについて定期的に議論するために( Gitter 上や Google Hangout 上で)集まりたいと思うかもしれません。こういったミーティングでさえも公にする事で、他の人も議論を聞けるようにしましょう。例えば、 [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) では、 [毎週オフィスアワーを設けています](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs)。
+リーダーシップチームは( IRC のような)専用のチャンネルを作りたいと思ったり、プロジェクトについて定期的に議論するために( Gitter 上や Google Hangout 上で)集まりたいと思うかもしれません。こういったミーティングでさえも公にする事で、他の人も議論を聞けるようにしましょう。例えば、 [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) では、 [毎週オフィスアワーを設けています](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs)。
 
 一度リーダーシップの役割を確立したなら、どのようにして彼らにコンタクトを取れるかドキュメントにまとめることを忘れないようにしましょう。メンテナーにどのようにしたらなれるかであったりどのように分科会に参加するのかのプロセスを明確に確立し、 GOVERNANCE.md ファイルにそれを記載しましょう。
 
diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md
index e948f3192a0..9fa40fcc7af 100644
--- a/_articles/ja/legal.md
+++ b/_articles/ja/legal.md
@@ -105,7 +105,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
 追加のコントリビューターアグリーメントがプロジェクトに必要になってくるケースにはこういったものがあります：
 
 * あなたの弁護士が全てのコントリビューターが明示的にコントリビュート規約に同意する（オンラインかオフラインでの _サイン_）必要があると判断した場合。これはおそらく、オープンソースライセンスだけでは十分でない（たとえ実際には十分だったとしても！）と感じているからでしょう。もしこれが唯一の懸念なのであれば、あるオープンソースライセンスを支持する旨のコントリビューターアグリーメントで十分なはずです。 [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) が、軽量な追加のコントリビューターアグリーメントの良い例です。
-* あなたや弁護士が、開発者が行う全てのコミットは承認されていると表明してほしいと考える場合。[Developer Certificate of Origin](https://developercertificate.org/) の要件はこれを達成するプロジェクトの数です。例えば、Node.js コミュニティは彼らが以前使っていた CLA の[代わりに](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution)、DCO を[使っています](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md)。あなたのリポジトリでDCOの執行を自動化するためのシンプルなオプションは [DCO Probot](https://github.com/probot/dco) を使うことです。
+* あなたや弁護士が、開発者が行う全てのコミットは承認されていると表明してほしいと考える場合。[Developer Certificate of Origin](https://developercertificate.org/) の要件はこれを達成するプロジェクトの数です。例えば、Node.js コミュニティは彼らが以前使っていた CLA の[代わりに](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution)、DCO を[使っています](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md)。あなたのリポジトリでDCOの執行を自動化するためのシンプルなオプションは [DCO Probot](https://github.com/probot/dco) を使うことです。
 * プロジェクトで使っているオープンソースライセンスに特許許諾が明記されておらず（ MIT ライセンスのように）、全てのコントリビューターから特許許諾を取る必要がある場合。これは、コントリビューターの中にあなたのプロジェクトやプロジェクトのコントリビューター、ユーザーを巨大な特許ポートフォリオの対象にする企業があるかもしれないためです。 [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) は、 Apache License 2.0 に記載されている特許許諾をコピーした追加のコントリビューターアグリーメントで、一般的に使われています。
 * プロジェクトがコピーレフトライセンスを使っているが、プロプライエタリバージョンも提供する必要がある場合。この場合、全てのコントリビューターから、コピーライトをあなたに割り当てるか、寛容なライセンスを（パブリックに対してではなく）あなたに対して許諾する必要があるでしょう。 [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) はこの種の同意の例です。
 * プロジェクトが成熟するに連れてライセンスを変更する必要があると考えており、コントリビューターに前もってライセンス変更の同意を得ておきたい場合。
diff --git a/_articles/ja/starting-a-project.md b/_articles/ja/starting-a-project.md
index d4692babe6b..ebb9d017ee8 100644
--- a/_articles/ja/starting-a-project.md
+++ b/_articles/ja/starting-a-project.md
@@ -36,7 +36,7 @@ _フリーソフトウェア_ という言葉も _オープンソース_ と同
 
 * **コラボレーション：** オープンソースプロジェクトは世界の誰からも変更を受け付けます。例えば [Exercism](https://github.com/exercism/) は、350を超えるコントリビューターがいるプログラミング練習プラットフォームです。
 
-* **取り入れて再構成：** オープンソースプロジェクトは誰しもがほとんどいかなる理由のためにも使えるものです。人々は他のものを作るためにでも使うことができます。例えば [WordPress](https://github.com/WordPress) は、 [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md) と呼ばれる既存のプロジェクトのフォークとして始まりました。
+* **取り入れて再構成：** オープンソースプロジェクトは誰しもがほとんどいかなる理由のためにも使えるものです。人々は他のものを作るためにでも使うことができます。例えば [WordPress](https://github.com/WordPress) は、 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) と呼ばれる既存のプロジェクトのフォークとして始まりました。
 
 * **透明性：** 誰でもオープンソースプロジェクトにエラーがないかや一貫していないところがないか調べることができます。透明性は[ブルガリア](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a)や[アメリカ](https://sourcecode.cio.gov/)のような政府、銀行やヘルスケアのような規制産業、 [Let's Encrypt](https://github.com/letsencrypt) のようなセキュリティソフトウェアにとって重要です。
 
@@ -172,7 +172,7 @@ CONTRIBUTING ファイルはあなたのプロジェクトにどうやって参
 
 暖かく友好的なトーンを使って、（ドキュメントを書く、もしくはウェブサイトを作る、といったような）コントリビュートを具体的に提示することで、新しく来る人が歓迎されていて是非参加したいと思ってもらうのにとても役に立ちます。
 
-例えば、 [Active Admin](https://github.com/activeadmin/activeadmin/) は[コントリビュートガイド](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md)を下記の内容から始めています：
+例えば、 [Active Admin](https://github.com/activeadmin/activeadmin/) は[コントリビュートガイド](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md)を下記の内容から始めています：
 
 > まずはじめに、 Active Admin へのコントリビュートを考えてくれてありがとうございます。あなたのような人々が Active Admin を偉大なツールにしているのです。
 
@@ -180,7 +180,7 @@ CONTRIBUTING ファイルはあなたのプロジェクトにどうやって参
 
 時間が経つにつれて、 CONTRIBUTING ファイルに頻繁に聞かれる質問を加えるでしょう。こういった情報を書くことによって、同じ質問を何度も繰り返ししてくる人が減っていくでしょう。
 
-CONTRIBUTING ファイルを書くときに更に役に立つものとして、 @nayafia の [contributing guide template](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) や @mozilla の ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/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 でコントリビューターがイシューを登録したり、プルリクエストをオープンする際に、そのファイルへのリンクが自動的に表示されます。
 
diff --git a/_articles/ko/building-community.md b/_articles/ko/building-community.md
index a8d30018603..e25692a3ce1 100644
--- a/_articles/ko/building-community.md
+++ b/_articles/ko/building-community.md
@@ -139,7 +139,7 @@ CONTRIBUTING 파일에 새 기여자들이 시작할 방법을 자세히 설명
 
 여러분의 프로젝트에서 작업하는 대부분의 사람과는 직접 의사소통할 기회가 없을 것입니다. 누군가 자신이 없거나 어디서 시작할지 갈피를 잡지 못해서, 결국 하지 못한 기여 또한 있을 것입니다. 친절함을 담은 몇 마디면 사람들이 실망한 채 프로젝트를 떠나는 것을 예방할 수 있습니다.
 
-[Rubinius](https://github.com/rubinius/rubinius/)의 [기여 가이드](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md)는 어떻게 시작하는지 참조하세요.
+[Rubinius](https://github.com/rubinius/rubinius/)의 [기여 가이드](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md)는 어떻게 시작하는지 참조하세요.
 
 > Rubinius를 사용해 주시는 것에 대해 먼저 감사의 말씀을 드리고 싶습니다. 이 프로젝트는 여러분의 사랑의 산출물이며, 저희는 버그를 잡고, 성능을 개선하고, 문서화를 돕는 모든 여러분께 고마움을 느낍니다. 모든 기여는 의미가 있습니다. 프로젝트에 참여해 주셔서 감사합니다. 다만, 저희가 여러분의 이슈를 받아들이기 위해 필요로 하는 몇 가지 지침이 있으니 참고해 주세요.
 
@@ -161,7 +161,7 @@ CONTRIBUTING 파일에 새 기여자들이 시작할 방법을 자세히 설명
 
 ![Cookiecutter 이슈](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md)가 사용하는 방법처럼 **CONTRIBUTORS 혹은 AUTHORS 파일**을 만들어 모든 프로젝트 기여자를 담은 하나의 목록을 작성하세요. 
+* [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md)가 사용하는 방법처럼 **CONTRIBUTORS 혹은 AUTHORS 파일**을 만들어 모든 프로젝트 기여자를 담은 하나의 목록을 작성하세요.
 
 * 어느 정도 규모의 커뮤니티가 형성됐다면 기여자들에 대한 감사를 담은 **뉴스 레터를 보내거나 블로그 포스트를 게시하세요**. Rust의 [This Week in Rust](https://this-week-in-rust.org/)와 Hoodie의 [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html)가 좋은 예입니다.
 
diff --git a/_articles/ko/code-of-conduct.md b/_articles/ko/code-of-conduct.md
index 2e234a1375a..887ea9c8d1c 100644
--- a/_articles/ko/code-of-conduct.md
+++ b/_articles/ko/code-of-conduct.md
@@ -54,7 +54,7 @@ related:
 
 행동강령을 보고하고 누가 그 보고서를 받았는지 설명하기 위해 사람들에게 사적인 (이메일 주소같은) 방법을 제공해야합니다. 메인테이너, 그룹 메인테이너 또는 행동강령 그룹이 될 수 있습니다.
 
-누군가 그 보고서를 받는 사람에 대한 위반 사항을 보고하기를 원할 수도 있다는 것을 잊지 마십시오. 이 경우, 위반 사항을 다른 사람에게 보고 할 수있는 옵션을 제공하십시오. 예시로, @ctb와 @mr-c는 [그 프로젝트에 설명하고](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer)하고 있습니다:
+누군가 그 보고서를 받는 사람에 대한 위반 사항을 보고하기를 원할 수도 있다는 것을 잊지 마십시오. 이 경우, 위반 사항을 다른 사람에게 보고 할 수있는 옵션을 제공하십시오. 예시로, @ctb와 @mr-c는 [그 프로젝트에 설명하고](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer)하고 있습니다:
 
 > 학대, 괴롭힘 또는 기타 용납 될 수없는 행동의 사례는 C.kidman Brown과 Michael R. Crusoe에게만 보내지는 **khmer-project@idyll.org** 로 이메일을 보내서 신고할 수 있습니다. 두 가지 중 하나와 관련된 문제를 신고하려면  BEACON 행동 과학 연구 센터 (NSF Center for Science and Technology)의 다양성 책임자 (Diversity Director)인 **Judi Brown Clarke 박사**에게 이메일을 보내 주시기 바랍니다
 
diff --git a/_articles/ko/leadership-and-governance.md b/_articles/ko/leadership-and-governance.md
index 577e95f83d3..e2c107b53df 100644
--- a/_articles/ko/leadership-and-governance.md
+++ b/_articles/ko/leadership-and-governance.md
@@ -63,11 +63,11 @@ related:
 <aside markdown="1" class="pquote">
   \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
   <p markdown="1" class="pquote-credit">
-— [“Rust Governance RFC”](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— [“Rust Governance RFC”](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-리더 팀은 IRC 등 지정된 채널을 만들거나 Gitter나 Google Hangout 등에서 정기적으로 프로젝트 토론 시간을 가지는 것이 좋습니다. 다른 사람들도 참관할 수 있게 채널이나 토론을 공개해도 됩니다. 예컨대 [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)는 [매주 토론 시간을 갖습니다](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs).
+리더 팀은 IRC 등 지정된 채널을 만들거나 Gitter나 Google Hangout 등에서 정기적으로 프로젝트 토론 시간을 가지는 것이 좋습니다. 다른 사람들도 참관할 수 있게 채널이나 토론을 공개해도 됩니다. 예컨대 [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)는 [매주 토론 시간을 갖습니다](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 리더십 역할을 구성한 후에는 사람들이 어떻게 그 역할을 부여받을 수 있는지 문서화하는 것을 잊지 마세요! 관리자나 특정 분야 전문 기여자가 되는 방법을 명확하게 정하고 GOVERNANCE 파일에 기록하세요.
 
diff --git a/_articles/ko/starting-a-project.md b/_articles/ko/starting-a-project.md
index 3404ad74c9d..4581cd52132 100644
--- a/_articles/ko/starting-a-project.md
+++ b/_articles/ko/starting-a-project.md
@@ -43,7 +43,7 @@ related:
 
 * **협업:** 오픈소스 프로젝트는 전 세계 누구에게서든 수정을 받을 수 있습니다. 예를 들어 [Exercism](https://github.com/exercism/)은 350명이 넘는 기여자가 참여하는 프로그래밍 연습 플랫폼입니다.
 
-* **채택과 재가공:** 오픈소스 프로젝트는 거의 모든 용도로 누구나 사용할 수 있습니다. 심지어 사람들이 그 프로젝트를 기반으로 다른 프로젝트를 만들 수도 있습니다. 예컨대 [WordPress](https://github.com/WordPress)는 [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md)라는 기존 프로젝트의 포크로 시작했습니다.
+* **채택과 재가공:** 오픈소스 프로젝트는 거의 모든 용도로 누구나 사용할 수 있습니다. 심지어 사람들이 그 프로젝트를 기반으로 다른 프로젝트를 만들 수도 있습니다. 예컨대 [WordPress](https://github.com/WordPress)는 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md)라는 기존 프로젝트의 포크로 시작했습니다.
 
 * **투명성:** 누구나 오픈소스 프로젝트에서 오류나 불일치를 검사 할 수 있습니다. 투명성은 [불가리아](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a)나 [미국](https://sourcecode.cio.gov/) 같은 정부, 은행 또는 의료 같은 규제 대상 산업, Let's Encrypt 등의 보안 소프트웨어에는 투명성이 중요합니다.
 
@@ -175,11 +175,11 @@ CONTRIBUTING 파일은 잠재 기여자들에게 프로젝트에 기여하는 
 
 * 원하는 기여 유형
 * 프로젝트 로드맵 또는 비전
-* 기여자가 여러분과 연락하는 데 사용할 (혹은 사용하지 말아야 할) 방법 
+* 기여자가 여러분과 연락하는 데 사용할 (혹은 사용하지 말아야 할) 방법
 
 따뜻하고 친근한 어조를 사용하고, 문서나 웹사이트 작성 등 기여에 대한 구체적인 제안을 제공하는 것은 새로운 사람들이 기꺼이 기여를 만들게 하는 데 도움이 될 수 있습니다.
 
-예를 들어 [Active Admin](https://github.com/activeadmin/activeadmin/)은 다음과 같이 [기여 가이드](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md)를 시작합니다.
+예를 들어 [Active Admin](https://github.com/activeadmin/activeadmin/)은 다음과 같이 [기여 가이드](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md)를 시작합니다.
 
 > 먼저, Active Admin에 기여해 주셔서 감사합니다. 여러분의 기여가 Active Admin을 이렇게 훌륭한 툴로 만듭니다.
 
@@ -187,7 +187,7 @@ CONTRIBUTING 파일은 잠재 기여자들에게 프로젝트에 기여하는 
 
 시간이 지나면 자주 묻는 질문을 CONTRIBUTING 파일에 추가할 수 있습니다. 이 정보를 적어두면 같은 질문을 반복해서 하는 사람들이 줄어들 것입니다.
 
-CONTRIBUTING 파일을 작성하는 데 도움이 필요하면 @nayafia의 [contributing guide template](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) 또는 @mozilla의 ["How to Build a CONTRIBUTING.md"](http://mozillascience.github.io/working-open-workshop/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가 자동으로 링크를 생성합니다.
 
diff --git a/_articles/leadership-and-governance.md b/_articles/leadership-and-governance.md
index ab4c7977007..b8006c30107 100644
--- a/_articles/leadership-and-governance.md
+++ b/_articles/leadership-and-governance.md
@@ -72,11 +72,11 @@ If your project has a very active contributor community, you might form a "core
 <aside markdown="1" class="pquote">
   \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs).
+Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
 
diff --git a/_articles/legal.md b/_articles/legal.md
index 93a6467fdae..ed6cf093fd5 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -113,7 +113,7 @@ Also, by adding "paperwork" that some believe is unnecessary, hard to understand
 Some situations where you may want to consider an additional contributor agreement for your project include:
 
 * Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
-* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
+* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
 * Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
 * Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
 * You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
diff --git a/_articles/pl/building-community.md b/_articles/pl/building-community.md
index d969785878e..6ab4f50f7f3 100644
--- a/_articles/pl/building-community.md
+++ b/_articles/pl/building-community.md
@@ -145,7 +145,7 @@ Na koniec skorzystaj z dokumentacji, aby ludzie czuli się mile widziani na każ
 
 Nigdy nie będziesz wchodzić w interakcje z większością ludzi, którzy wylądują na twoim projekcie. Mogą istnieć kontrybucje, których nie otrzymałeś, ponieważ ktoś czuł się zastraszony lub nie wiedział, od czego zacząć. Nawet kilka miłych słów może zniechęcić kogoś do opuszczenia projektu.
 
-Na przykład oto jak [Rubinius](https://github.com/rubinius/rubinius/) zaczyna [jego pomocny przewodnik](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md):
+Na przykład oto jak [Rubinius](https://github.com/rubinius/rubinius/) zaczyna [jego pomocny przewodnik](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
 
 > We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
 
@@ -169,7 +169,7 @@ Sprawdź, czy możesz w jak największym stopniu znaleźć sposób na dzielenie
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Uruchom plik CONTRIBUTORS lub AUTHORS w swoim projekcie** zawiera listę wszystkich, którzy przyczynili się do twojego projektu, takich jak [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md).
+* **Uruchom plik CONTRIBUTORS lub AUTHORS w swoim projekcie** zawiera listę wszystkich, którzy przyczynili się do twojego projektu, takich jak [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
 
 * Jeśli masz sporą społeczność, **wyślij biuletyn lub napisz post na blogu** dziękując autorom. Rusta [This Week in Rust](https://this-week-in-rust.org/) i Hoodie'ego [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) są dwoma dobrymi przykładami
 
diff --git a/_articles/pl/code-of-conduct.md b/_articles/pl/code-of-conduct.md
index ae8f18cfed0..3e39fbf0d6b 100644
--- a/_articles/pl/code-of-conduct.md
+++ b/_articles/pl/code-of-conduct.md
@@ -54,7 +54,7 @@ Musisz wyjaśnić, w jaki sposób Twój kodeks postępowania będzie egzekwowany
 
 Powinieneś dać ludziom prywatny sposób (np. Adres e-mail), aby zgłosić naruszenie zasad postępowania i wyjaśnić, kto otrzyma to zgłoszenie. Może to być opiekun, grupa opiekunów lub grupa robocza ds. Kodeksu postępowania.
 
-Nie zapominaj, że ktoś może chcieć zgłosić naruszenie dotyczące osoby, która je otrzyma. W takim przypadku daj im możliwość zgłaszania naruszeń komuś innemu. Na przykład, @ctb oraz @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+Nie zapominaj, że ktoś może chcieć zgłosić naruszenie dotyczące osoby, która je otrzyma. W takim przypadku daj im możliwość zgłaszania naruszeń komuś innemu. Na przykład, @ctb oraz @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
 > Przypadki obraźliwych, nękających lub w inny sposób niedopuszczalnych zachowań można zgłaszać, wysyłając wiadomość e-mail na adres **khmer-project@idyll.org**, który jest wysyłany tylko do C. Titusa Browna i Michaela R. Crusoe. Aby zgłosić problem dotyczący któregokolwiek z nich, wyślij wiadomość e-mail **dr Judi Brown Clarke** dyrektor ds. Różnorodności w Centrum Badań nad Ewolucją w Działaniu BEACON, Centrum Nauki i Technologii NSF.*
 
diff --git a/_articles/pl/leadership-and-governance.md b/_articles/pl/leadership-and-governance.md
index 56858ad1596..76d6bb30c99 100644
--- a/_articles/pl/leadership-and-governance.md
+++ b/_articles/pl/leadership-and-governance.md
@@ -67,11 +67,11 @@ Jeśli Twój projekt ma bardzo aktywną społeczność współpracowników, moż
 <aside markdown="1" class="pquote">
   \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Zespoły kierownicze mogą chcieć utworzyć wyznaczony kanał (np. Na IRC) lub regularnie spotykać się w celu omówienia projektu (np. Na Gitter lub Google Hangout). Możesz nawet upublicznić te spotkania, aby inni mogli je słuchać. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), na przykład [organizuje godziny pracy co tydzień](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs)
+Zespoły kierownicze mogą chcieć utworzyć wyznaczony kanał (np. Na IRC) lub regularnie spotykać się w celu omówienia projektu (np. Na Gitter lub Google Hangout). Możesz nawet upublicznić te spotkania, aby inni mogli je słuchać. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), na przykład [organizuje godziny pracy co tydzień](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs)
 
 Po ustaleniu ról przywódczych nie zapomnij udokumentować, w jaki sposób ludzie mogą je osiągnąć! Ustal przejrzysty proces, w jaki sposób ktoś może zostać opiekunem lub dołączyć do podkomitetu w swoim projekcie, i zapisz go w swoim GOVERNANCE.md.
 
diff --git a/_articles/pl/legal.md b/_articles/pl/legal.md
index a46f863cf3b..796d4014a97 100644
--- a/_articles/pl/legal.md
+++ b/_articles/pl/legal.md
@@ -109,7 +109,7 @@ Ponadto poprzez dodanie „dokumentacji”, którą niektórzy uważają za niep
 Niektóre sytuacje, w których warto rozważyć zawarcie dodatkowej umowy wnoszącej wkład dla twojego projektu, obejmują:
 
 * Twoi prawnicy chcą, aby wszyscy współtwórcy wyraźnie zaakceptowali warunki udziału (_sign_, online lub offline), być może dlatego, że uważają, że sama licencja typu open source nie wystarczy (nawet jeśli jest!). Jeśli jest to jedyny problem, wystarczy umowa współtwórcy, która potwierdza licencję open source projektu. [Umowa licencyjna na indywidualnego dostawcę jQuery](https://contribute.jquery.org/CLA/) jest dobrym przykładem niewielkiej dodatkowej umowy na współautora.
-* Ty lub twoi prawnicy chcielibyście, aby programiści oświadczyli, że każde dokonane przez nich zatwierdzenie jest dozwolone. Wymaganiem [Developer Certificate of Origin](https://developercertificate.org/) jest to, ile projektów to osiąga. Na przykład społeczność Node.js [używa](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md) DCO [zamiast](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) wcześniejszego CLA. Prostą opcją zautomatyzowania wymuszania kontroli DCO w repozytorium jest [DCO Probot](https://github.com/probot/dco).
+* Ty lub twoi prawnicy chcielibyście, aby programiści oświadczyli, że każde dokonane przez nich zatwierdzenie jest dozwolone. Wymaganiem [Developer Certificate of Origin](https://developercertificate.org/) jest to, ile projektów to osiąga. Na przykład społeczność Node.js [używa](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [zamiast](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) wcześniejszego CLA. Prostą opcją zautomatyzowania wymuszania kontroli DCO w repozytorium jest [DCO Probot](https://github.com/probot/dco).
 * Twój projekt wykorzystuje licencję typu open source, która nie obejmuje wyraźnej granty patentowej (takiej jak MIT), i potrzebujesz grantu patentowego od wszystkich autorów, z których niektórzy mogą pracować dla firm z dużymi portfelami patentowymi, które mogłyby być wykorzystane do Ciebie lub inni uczestnicy projektu i użytkownicy. [Umowa licencyjna na indywidualnego dostawcę Apache](https://www.apache.org/licenses/icla.pdf) to powszechnie stosowana dodatkowa umowa na współautora, której udzielenie patentowe odzwierciedla kopię zawartą w licencji Apache 2.0.
 * Twój projekt jest objęty licencją copyleft, ale musisz także rozpowszechniać zastrzeżoną wersję projektu. Będziesz potrzebował każdego współtwórcy, aby przypisać Ci prawa autorskie lub udzielić (ale nie publicznie) zezwolenia na korzystanie z licencji. [Umowa współtwórcy MongoDB](https://www.mongodb.com/legal/contributor-agreement) jest przykładem tego rodzaju umowy.
 * Uważasz, że Twój projekt może wymagać zmiany licencji przez cały okres jego użytkowania i chcesz, aby współtwórcy zgodzili się z wyprzedzeniem na takie zmiany.
diff --git a/_articles/pl/starting-a-project.md b/_articles/pl/starting-a-project.md
index 4a8f1d78fa9..dcce8e1b24d 100644
--- a/_articles/pl/starting-a-project.md
+++ b/_articles/pl/starting-a-project.md
@@ -38,7 +38,7 @@ _Wolne oprogramowanie_ odnosi się do tego samego zestawu projektów, co _otwart
 
 * **Współpraca:** Projekty open source mogą akceptować zmiany od każdego na świecie. [Exercism](https://github.com/exercism/), na przykład, jest platformą ćwiczeń programistycznych z ponad 350 uczestnikami.
 
-* **Adopcja i remiksowanie:** projekty open source mogą być wykorzystywane przez każdego do prawie dowolnego celu. Ludzie mogą nawet używać go do budowania innych rzeczy. [WordPress](https://github.com/WordPress), na przykład, zaczął się jako rozwidlenie istniejącego projektu o nazwie[b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
+* **Adopcja i remiksowanie:** projekty open source mogą być wykorzystywane przez każdego do prawie dowolnego celu. Ludzie mogą nawet używać go do budowania innych rzeczy. [WordPress](https://github.com/WordPress), na przykład, zaczął się jako rozwidlenie istniejącego projektu o nazwie[b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
 * **Transparentność:** Każdy może sprawdzić projekt open source pod kątem błędów lub niespójności. Przejrzystość ma znaczenie dla rządów takich jak [Bułgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) lub [Stany Zjednoczone](https://sourcecode.cio.gov/), regulowane branże, takie jak bankowość lub opieka zdrowotna, oraz oprogramowanie zabezpieczające, takie jak [Let's Encrypt](https://github.com/letsencrypt).
 
@@ -180,7 +180,7 @@ Oprócz szczegółów technicznych plik CONTRIBUTING jest także okazją do wyra
 
 Używanie ciepłego, przyjaznego tonu i oferowanie konkretnych sugestii dotyczących wkładu (takich jak pisanie dokumentacji lub tworzenie strony internetowej) może znacznie przyczynić się do tego, że nowo przybyli poczują się mile widziani i podekscytowani uczestnictwem.
 
-Na przykład [Active Admin](https://github.com/activeadmin/activeadmin/) uruchamia [swój przewodnik pomocniczy](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) z:
+Na przykład [Active Admin](https://github.com/activeadmin/activeadmin/) uruchamia [swój przewodnik pomocniczy](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) z:
 
 > Po pierwsze, dziękuję za rozważenie włączenia się w Active Admin. Ludzie tacy jak Ty sprawiają, że Active Admin jest tak doskonałym narzędziem.
 
@@ -188,7 +188,7 @@ Na najwcześniejszych etapach projektu plik WKŁADU może być prosty. Zawsze po
 
 Z czasem możesz dodawać inne często zadawane pytania do pliku WKŁAD. Zapisanie tych informacji oznacza, że coraz mniej osób będzie zadawać ci te same pytania w kółko.
 
-Aby uzyskać więcej pomocy w pisaniu pliku WKŁAD, sprawdź @nayafia [contributing guide template](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) lub @mozilla ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
+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.
 
diff --git a/_articles/pt/building-community.md b/_articles/pt/building-community.md
index d438f9e9902..eb80725f447 100644
--- a/_articles/pt/building-community.md
+++ b/_articles/pt/building-community.md
@@ -136,7 +136,7 @@ Por fim, use a sua documentação para fazer as pessoas se sentirem bem-vindas a
 
 Você não interagirá com a maior parte das pessoas que chegarem ao seu projeto. Podem haver contribuições que você não recebeu porque alguém se sentiu intimidado ou não soube como começar. Até mesmo algumas palavras gentis podem fazer com que alguém não deixe, frustradamente, o seu projeto.
 
-Por exemplo, veja como [Rubinius](https://github.com/rubinius/rubinius/) introduz o [seu guia de contribuição](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md):
+Por exemplo, veja como [Rubinius](https://github.com/rubinius/rubinius/) introduz o [seu guia de contribuição](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
 
 > Em primeiro lugar, gostaríamos de agradecer por usar o Rubinus. Este projeto é um trabalho de amor, e apreciamos todos os usuários que capturam bugs, fazem melhorias de desempenho, e ajudam com a documentação. Toda contribuição é importante, então obrigado por participar. Dito isso, aqui estão algumas orientações que pedimos que siga, de modo que possamos ter sucesso em identificar o seu problema.
 
@@ -158,7 +158,7 @@ Procure encontrar maneiras de compartilhar a propriedade com a sua comunidade o
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Crie um arquivo CONTRIBUTORS ou AUTHORS em seu projeto** que liste todos os que contribuíram para o seu projeto, como o [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md) faz.
+* **Crie um arquivo CONTRIBUTORS ou AUTHORS em seu projeto** que liste todos os que contribuíram para o seu projeto, como o [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) faz.
 
 * Se você possui uma comunidade de tamanho razoável, **envie uma newsletterm ou escreva um post em um blog** agradecendo aos contribuidores. A [This Week in Rust](https://this-week-in-rust.org/), do Rust, e a [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html), da Hoodie, são dois bons exemplos.
 
diff --git a/_articles/pt/code-of-conduct.md b/_articles/pt/code-of-conduct.md
index 99417090d0c..00d4f305288 100644
--- a/_articles/pt/code-of-conduct.md
+++ b/_articles/pt/code-of-conduct.md
@@ -54,7 +54,7 @@ Você deve explicar como o seu código de conduta será aplicado **_antes_** que
 
 Você deve sempre dar as pessoas um modo privado (como um endereço de e-mail) para relatarem uma violação do código de conduta e informar os reponsáveis por receber as queixas. Pode ser um mantenedor, um grupo de mantenedores, ou um grupo de trabalho do código de conduta.
 
-Não se esqueça de que alguém pode querer relatar uma violação sobre alguém que receba esses relatos. Neste caso, dê a eles uma opção para relatar violações a outra pessoa. Por exemplo, @ctb e @mr-c [explicam em seu projeto](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+Não se esqueça de que alguém pode querer relatar uma violação sobre alguém que receba esses relatos. Neste caso, dê a eles uma opção para relatar violações a outra pessoa. Por exemplo, @ctb e @mr-c [explicam em seu projeto](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
 > Casos de comportamento abusivo, de assédio, ou de outra forma inaceitável podem ser relatados enviando um e-mail para **khmer-project@idyll.org**, chegando somente a C. Titus Brown e Michael R. Crusoe. Para relatar um problema envolvendo algum deles, por favor envie um e-mail para **Judi Brown Clarke, Ph.D.**, o Diretor de Diversidade no Centro BEACON para o Estudo da Evolução em Ação, um Centro NSF para Ciência e Tecnologia.*
 
diff --git a/_articles/pt/leadership-and-governance.md b/_articles/pt/leadership-and-governance.md
index 433db18ef64..ba7aa9471ed 100644
--- a/_articles/pt/leadership-and-governance.md
+++ b/_articles/pt/leadership-and-governance.md
@@ -63,11 +63,11 @@ Se seu projeto possui uma comunidade contribuinte muito ativa, você pode formar
 <aside markdown="1" class="pquote">
   \[Nós\] complementamos a equipe principal com várias "subequipes". Cada subequipe é focada em um área específica, e.q., design de linguagem ou bibliotecas. (...) Para assegurar a coordenação global e uma forte e coerente visão para o projeto como um todo, cada subequipe é liderada por um membro da equipe principal.
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Times de lideranças podem querer criar um canal designado (como no IRC) ou se encontrar regularmente para discutir o projeto (como no Gitter ou Google Hangouts). Você pode sempre tornar essas reuniões públicas para que outras pessoãs possam escutá-las. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), por exemplo, [disponibiliza horários de atendimento toda semana](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs).
+Times de lideranças podem querer criar um canal designado (como no IRC) ou se encontrar regularmente para discutir o projeto (como no Gitter ou Google Hangouts). Você pode sempre tornar essas reuniões públicas para que outras pessoãs possam escutá-las. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), por exemplo, [disponibiliza horários de atendimento toda semana](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 Uma vez que você tenha estabelecido papéis de liderança, não esqueça de documentar como as pessoas podem alcançá-los! Estabeleça um processo claro de como alguém pode se tornar um mantenedor, ou se juntar à um subcomitê em seu projeto, e escreva isso em seu arquivo GOVERNANCE.md.
 
diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index fbf21edb4a2..350c3586248 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -43,7 +43,7 @@ Em comparação, um processo de código fechado seria ir a um restaurante e pedi
 
 * **Colaboração:** Projetos open source podem aceitar mudanças de qualquer pessoa no mundo. [Exercism](https://github.com/exercism/), por exemplo, é uma plataforma de exercícios de programação com mais de 350 contribuidores.
 
-* **Adoção e remixing:** Projetos open source podem ser utilizados por qualquer um para praticamente qualquer propósito. As pessoas podem até mesmo utilizá-lo para construir outras coisas. [WordPress](https://github.com/WordPress), por exemplo, começou como um fork de um projeto chamado [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
+* **Adoção e remixing:** Projetos open source podem ser utilizados por qualquer um para praticamente qualquer propósito. As pessoas podem até mesmo utilizá-lo para construir outras coisas. [WordPress](https://github.com/WordPress), por exemplo, começou como um fork de um projeto chamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
 * **Transparência:** Qualquer um pode inspecionar um projeto open source por erros ou inconsistências. A transparência importa a gorvernos como a [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou os [Estados Unidos](https://sourcecode.cio.gov/), industrias regulamentadas como bancos ou industrias de saúde, e softwares de segurança como [Let's Encrypt](https://github.com/letsencrypt).
 
@@ -179,7 +179,7 @@ Além dos detalhes técnicos, um arquivo CONTRIBUTING é uma oportunidade de com
 
 Usar um tom acolhedor, amigável e oferecer sugestões específicas para contribuições (como escrever uma documentação, ou fazer um website) pode fazer uma grande diferença em fazer com que novos contribuidores se sintam bem vindos e felizes em participar.
 
-Por exemplo, o [Active Admin](https://github.com/activeadmin/activeadmin/) começa [seu guia de contribuição](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) com:
+Por exemplo, o [Active Admin](https://github.com/activeadmin/activeadmin/) começa [seu guia de contribuição](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) com:
 
 > Primeiramente, obrigado por considerar contribuir para o Active Admin. São pessoas como você que fazem o Active Admin esta grande ferramenta.
 
@@ -187,7 +187,7 @@ Nos primeiros estágios do seu projeto, seu arquivo de CONTRIBUTING pode ser sim
 
 Ao longo do tempo, você pode adicionar outras questões frequentemente respondidas ao seu arquivo CONTRIBUTING. Escrever essas informações significa que menos pessoas te farão as mesmas perguntas repetidas vezes.
 
-Para mais ajuda em como escrever seu arquivo CONTRIBUTING, dê uma olhada no [contributing guide template](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) de @nayafia ou o ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) do @mozilla.
+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.
 
diff --git a/_articles/ro/building-community.md b/_articles/ro/building-community.md
index 4c52e6136a3..e558e2591d8 100644
--- a/_articles/ro/building-community.md
+++ b/_articles/ro/building-community.md
@@ -117,7 +117,7 @@ Comunicarea publică poate fi atât de ușoară ca direcționarea oamenilor căt
 [Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) pune deoparte ore de birou din 2 în 2 săptămâni pentru a ajuta membrii comunității:
 
 > Kops de asemenea are timp pus deoparte din 2 în 2 săptămâni pentru a oferi ajutor și îndrumare comunitații. Întreținătorii Kops au căzut de acord să pună timp deoparte specific dedicat lucrului cu nou-veniții, ajutării cu PR-urile, și discutării de noi facilități.
-> 
+>
 > Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.
 
 Excepții notabile pentru comunicarea publică sunt: 1) probleme de securitate și 2) încălcări sensibile ale codului de conduită. Ar trebui să ai întotdeauna o cale pentru oameni să raporteze aceste probleme în mod privat. Dacă nu dorești să folosești adresa ta de email personală, configurează o adresă de email dedicată.
@@ -165,10 +165,10 @@ Documentația bună devine doar mai importantă pe măsură ce comunitatea ta cr
 
 Nu vei interacționa niciodată cu marea majoritate a oamenilor care ajung la proiectul tău. Ar putea fi contribuții pe care nu le-ai primit deoarece cineva s-a simțit intimidat sau nu a știut de unde să înceapă. Chiar câteva cuvinte puține pot ține un om să nu părăsească frustrat proiectul tău.
 
-De exemplu, iată cum [Rubinius](https://github.com/rubinius/rubinius/) începe [ghidul său de contribuire](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md):
+De exemplu, iată cum [Rubinius](https://github.com/rubinius/rubinius/) începe [ghidul său de contribuire](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
 
 > Vrem să începem prin a vă mulțumi că folosiți Rubinius. Acest proiect este o muncă a iubirii, și apreciem toți utilizatorii care descoperă bug-uri, fac îmbunătățiri de performanță, și ajută cu documentația. Orice contribuție este semnificativă, deci vă mulțumim pentru participare. Acestea fiind spuse, iată câteva instrucțiuni pe care vă cerem să le urmați pentru ca să vă abordăm cu succes problema.
-> 
+>
 > We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
 
 ### Împarte proprietatea proiectului tău
@@ -196,7 +196,7 @@ Vezi dacă poți găsi moduri de a împărți proprietatea cu comunitatea ta câ
 
 ![problemă Cookiecutter](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Începe un fișier CONTRIBUTORS sau AUTHORS în proiectul tău** care listează pe toți cei care au contribuit la proiectul tău, la fel cum face [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md).
+* **Începe un fișier CONTRIBUTORS sau AUTHORS în proiectul tău** care listează pe toți cei care au contribuit la proiectul tău, la fel cum face [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
 
 * Dacă ai o comunitate considerabilă, **trimite un buletin informativ sau scrie o postare de blog** mulțumind contributorilor. [This Week in Rust](https://this-week-in-rust.org/) al Rust și [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) al Hoodie sunt două exemple bune.
 
diff --git a/_articles/ro/code-of-conduct.md b/_articles/ro/code-of-conduct.md
index d3629527fb1..408c7c90fdf 100644
--- a/_articles/ro/code-of-conduct.md
+++ b/_articles/ro/code-of-conduct.md
@@ -67,10 +67,10 @@ Ar trebui să explici cum codul tău de conduită va fi impus **_înainte_** ca
 
 Ar trebui să oferi oamenilor o cale privată (cum ar fi o adresă de email) pentru a raporta o încălcare a codului de conduită și să explici cine primește raportul. Ar putea fi un întreținător, un grup de întreținători, sau un grup de lucru pentru codul de conduită.
 
-Nu uita că cineva ar putea să vrea să raporteze o încălcare despre o persoană care primește aceste rapoarte. În acest caz, dă-le o opțiune să raporteze încălcările altcuiva. De exemplu @ctb și @mr-c [explică despre proiectul lor](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+Nu uita că cineva ar putea să vrea să raporteze o încălcare despre o persoană care primește aceste rapoarte. În acest caz, dă-le o opțiune să raporteze încălcările altcuiva. De exemplu @ctb și @mr-c [explică despre proiectul lor](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
 > Exemple de comportament abuziv, hărțuitor, sau altfel inacceptabil pot fi raportate scriind email către **khmer-project@idyll.org** care ajung doar la C. Titus Brown și Michael R. Crusoe. Pentru a raporta o problemă care implică pe oricare din aceștia te rugăm să scrii email către **Judi Brown Clarke, Ph.D.** Directorul pentru Diversitate la Centrul BEACON pentru Studiul Evoluției în Acțiune, un Centru NSF pentru Știință și Tehnologie.
-> 
+>
 > Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.
 
 Pentru inspirație, aruncă o privire la [manualul impunerii](https://www.djangoproject.com/conduct/enforcement-manual/) al Django (deși poate nu vei avea nevoie de ceva atât de cuprinzător, depinzând de dimensiunea proiectului tău).
diff --git a/_articles/ro/leadership-and-governance.md b/_articles/ro/leadership-and-governance.md
index 9f6eaf4dbaa..ddbc06a2d36 100644
--- a/_articles/ro/leadership-and-governance.md
+++ b/_articles/ro/leadership-and-governance.md
@@ -93,11 +93,11 @@ Dacă proiectul tău are o comunitate de contributori foarte activă, ai putea s
     </em>
   </p>
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Echipele de conducere ar putea dori să creeze un canal desemnat (cum ar fi pe IRC) sau să se întâlnească periodic să discute despre proiect (cum ar fi pe Gitter sau Google Hangouts). Poți chiar face aceste întâlniri publice astfel încât alți oameni pot asculta. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), de exemplu, [găzduiește ore de lucru săptămânal](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs).
+Echipele de conducere ar putea dori să creeze un canal desemnat (cum ar fi pe IRC) sau să se întâlnească periodic să discute despre proiect (cum ar fi pe Gitter sau Google Hangouts). Poți chiar face aceste întâlniri publice astfel încât alți oameni pot asculta. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), de exemplu, [găzduiește ore de lucru săptămânal](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 Odată ce ai stabilit roluri de conducere, nu uita să documentezi modul în care oamenii pot să le atingă! Stabilește un proces clar pentru cum cineva poate deveni un întreținător sau să se alăture unui subcomitet în cadrul proiectului tău, și scrie aceasta în GOVERNANCE.md-ul tău.
 
diff --git a/_articles/ro/starting-a-project.md b/_articles/ro/starting-a-project.md
index 0709493062b..9565d1dd22d 100644
--- a/_articles/ro/starting-a-project.md
+++ b/_articles/ro/starting-a-project.md
@@ -56,7 +56,7 @@ Prin comparație, într-un proces cu sursă închisă mergi la un restaurant și
 
 * **Colaborarea:** Proiectele cu sursă deschisă pot accepta schimbări de la oricine din lume. [Exercism](https://github.com/exercism/), de exemplu, este o platformă de exerciții de programare cu peste 350 de contributori.
 
-* **Adoptarea și remixarea:** Proiectele cu sursă deschisă pot fi folosite de oricine pentru aproape orice scop. Oamenii le pot folosi chiar și pentru a construi alte lucruri. [WordPress](https://github.com/WordPress), de exemplu, a început ca o bifurcație a unui proiect existent numit [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
+* **Adoptarea și remixarea:** Proiectele cu sursă deschisă pot fi folosite de oricine pentru aproape orice scop. Oamenii le pot folosi chiar și pentru a construi alte lucruri. [WordPress](https://github.com/WordPress), de exemplu, a început ca o bifurcație a unui proiect existent numit [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
 * **Transparența:** Oricine poate inspecta un proiect cu sursă deschisă pentru erori sau neconcordanțe. Transparența contează pentru guverne, cum ar fi [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) sau [Statele Unite](https://sourcecode.cio.gov/), industrii reglementate cum ar fi sectorul bancar sau asistența medicală, și software-uri de securitate cum ar fi [Let's Encrypt](https://github.com/letsencrypt).
 
@@ -213,17 +213,17 @@ Un fișier CONTRIBUTING spune audienței tale cum să participe în proiectul t
 
 Folosind un ton cald și prietenos și oferind sugestii specifice pentru contribuții (cum ar fi scrierea documentației, sau facerea unui site web) poate parcurge o cale lungă pentru a face nou-veniții să se simtă bineveniți și entuziasmați să participe.
 
-De exemplu, [Active Admin](https://github.com/activeadmin/activeadmin/) începe [ghidul său de contribuire](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) cu:
+De exemplu, [Active Admin](https://github.com/activeadmin/activeadmin/) începe [ghidul său de contribuire](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) cu:
 
 > Mai întâi de toate, îți mulțumesc pentru că ai considerat să contribui la Active Admin. Oamenii ca voi sunt cei care fac Active Admin o unealtă grozavă.
-> 
+>
 > First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
 
 În primele etape ale proiectului tău, fișierul tău CONTRIBUTING poate fi simplu. Ar trebui mereu să explici cum se raportează bug-uri sau înregistrează probleme, și oricare cerință tehnică (cum ar fi teste) pentru a face o contribuție.
 
 Cu timpul, ai putea adăuga alte întrebări puse des în fișierul tău CONTRIBUTING. Scriind aceste informații înseamnă că mai puțini oameni vă vor întreba aceleași întrebări de mai multe ori.
 
-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/master/CONTRIBUTING-template.md) al @nayafia sau [„How to Build a CONTRIBUTING.md”](https://mozillascience.github.io/working-open-workshop/contributing/) al @mozilla.
+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.
 
diff --git a/_articles/starting-a-project.md b/_articles/starting-a-project.md
index 9b1140f59be..dac82be8178 100644
--- a/_articles/starting-a-project.md
+++ b/_articles/starting-a-project.md
@@ -42,7 +42,7 @@ _Free software_ refers to the same set of projects as _open source_. Sometimes y
 
 * **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
 
-* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
+* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
 * **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
 
@@ -178,7 +178,7 @@ In addition to technical details, a CONTRIBUTING file is an opportunity to commu
 
 Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
 
-For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) with:
+For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
 
 > First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
 
@@ -186,7 +186,7 @@ In the earliest stages of your project, your CONTRIBUTING file can be simple. Yo
 
 Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
 
-For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
+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.
 
diff --git a/_articles/ta/building-community.md b/_articles/ta/building-community.md
index 6690f162ce9..63a8127852c 100644
--- a/_articles/ta/building-community.md
+++ b/_articles/ta/building-community.md
@@ -138,7 +138,7 @@ related:
 
 உங்கள் திட்டத்தில் உள்ள பெரும்பாலான மக்களுடன் நீங்கள் தொடர்பு கொள்ள மாட்டீர்கள். நீங்கள் பெறாத பங்களிப்புகள் இருக்கலாம், ஏனெனில் யாரோ ஒருவர் பயமுறுத்தப்பட்டார் அல்லது எங்கு தொடங்குவது என தெரியாமல் இருக்கலாம். உங்கள் திட்டத்தை இருந்து யாரேனும் விலகுவதை உங்களின் ஒரு சில கனிவான வார்த்தைகளால் தடுக்கலாம்.
 
-உதாரணமாக, [ரூபினிஸ்](https://github.com/rubinius/rubinius/) இங்கே எப்படி [அதன் பங்களிப்பு வழிகாட்டியை](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md) தொடங்குகியது:
+உதாரணமாக, [ரூபினிஸ்](https://github.com/rubinius/rubinius/) இங்கே எப்படி [அதன் பங்களிப்பு வழிகாட்டியை](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) தொடங்குகியது:
 
 > ரூபினியஸைப் பயன்படுத்துவதற்கு நன்றி தெரிவிப்பதன் மூலம் நாம் துவங்க வேண்டும். இந்த திட்டம் காதலால் உருவானது, மற்றும் பிழைகள் பிடிக்க, செயல்திறன் மேம்பாடுகள், மற்றும் ஆவணங்களை உதவி என்று அனைத்து பயனர்களையும் பாராட்டுகிறோம். ஒவ்வொரு பங்களிப்பும் அர்த்தமுள்ளது, எனவே பங்கு பெறுவதற்கு நன்றி. இதனால் கூறப்படுவதன் என்னவெனில், உங்களுடைய பிரச்சினையை வெற்றிகரமாக தீர்க்க நாங்கள் பின்பற்றும் சில வழிகாட்டு நெறிகள் நீங்கள் பின்பற்ற வேண்டும் .
 
@@ -160,7 +160,7 @@ related:
 
 ![Cookiecutter சிக்கல்](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* [சினாட்ரா](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md) போன்று உங்கள் திட்டத்தில் பங்களித்த அனைவருக்கும் **உங்கள் திட்டத்தில் ஒரு பங்களிப்பாளர்கள்(CONTRIBUTORS) அல்லது நூலாசிரியர்கள்(AUTHORS) கோப்பைத் தொடங்கவும்.**
+* [சினாட்ரா](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) போன்று உங்கள் திட்டத்தில் பங்களித்த அனைவருக்கும் **உங்கள் திட்டத்தில் ஒரு பங்களிப்பாளர்கள்(CONTRIBUTORS) அல்லது நூலாசிரியர்கள்(AUTHORS) கோப்பைத் தொடங்கவும்.**
 
 * உங்கள் சமூகம் பெரியதாயிருந்தால், **ஒரு செய்திமடலை முடிக்க அல்லது வலைப்பதிவு இடுகையை எழுதுவதன் முலம்** பங்களிப்பாளர்களுக்கு நன்றி சொல்லுங்கள். ரஸ்ட்-ன் [இந்த வாரம் ரஸ்ட்](https://this-week-in-rust.org/) மற்றும் ஹூடி-ன் [கூச்சலிடுங்கள்](http://hood.ie/blog/shoutouts-week-24.html) இரண்டு நல்ல உதாரணங்களாகும்.
 
diff --git a/_articles/ta/code-of-conduct.md b/_articles/ta/code-of-conduct.md
index 3d70fc9a6c2..8b8f8c1b78c 100644
--- a/_articles/ta/code-of-conduct.md
+++ b/_articles/ta/code-of-conduct.md
@@ -54,7 +54,7 @@ related:
 
 நடத்தை மீறல்களை மக்கள் தனிப்பட்ட முறையில் புகாரளிக்க (மின்னஞ்சல் முகவரியைப் போன்ற) கொடுக்க வேண்டும், மற்றும் அந்த அறிக்கையை யார் பெறுகிறார்கள் என்பதை விளக்கவும். இது ஒரு பராமரிப்பாளர், பராமரிப்பாளர்களின் குழு, அல்லது நடத்தை விதி குழுவாக இருக்கலாம்.
 
-அந்த அறிக்கையைப் பெறும் நபரைப் பற்றி ஒருவர் மீறல் குறித்து புகாரளிக்க விரும்புவதை மறந்துவிடாதீர்கள். இந்த வழக்கில், வேறு யாரிடாமவது மீறல்களைப் புகாரளிக்க அவர்களுக்கு விருப்பத்தெரிவு கொடுங்கள். உதாரணத்திற்கு, @ctb and @mr-c [தங்கள் திட்டத்தை விளக்குகிறார்கள்](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+அந்த அறிக்கையைப் பெறும் நபரைப் பற்றி ஒருவர் மீறல் குறித்து புகாரளிக்க விரும்புவதை மறந்துவிடாதீர்கள். இந்த வழக்கில், வேறு யாரிடாமவது மீறல்களைப் புகாரளிக்க அவர்களுக்கு விருப்பத்தெரிவு கொடுங்கள். உதாரணத்திற்கு, @ctb and @mr-c [தங்கள் திட்டத்தை விளக்குகிறார்கள்](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
 > துஷ்பிரயோகம், தொந்தரவு, அல்லது ஏற்றுக்கொள்ள முடியாத தன்மை ஆகியவற்றின் நிகழ்வுகள் **khmer-project@idyll.org** என்ற மின்னஞ்சல் மூலம் புகாரளிக்கலாம். டைட்டஸ் பிரவுன் மற்றும் மைக்கேல் ஆர். க்ரூஸோ. அவர்களில் ஒருவர் சம்பந்தப்பட்ட ஒரு சிக்கலைப் புகாரளிக்க மின்னஞ்சல் **ஜுடி பிரவுன் கிளார்க், Ph.D.** பரிணாம வளர்ச்சிக்கான ஆய்விற்கான BEACON மையத்தில் பல்வகைமை பணிப்பாளர், அறிவியல் மற்றும் தொழில்நுட்பத்திற்கான NSF மையம்.*
 
diff --git a/_articles/ta/leadership-and-governance.md b/_articles/ta/leadership-and-governance.md
index cbf487d084e..aef4f793166 100644
--- a/_articles/ta/leadership-and-governance.md
+++ b/_articles/ta/leadership-and-governance.md
@@ -63,11 +63,11 @@ related:
 <aside markdown="1" class="pquote">
   \[நாங்கள்\] உள்ளக அணிக்கு பல "துணைஅணிகளை" பிற்சேர்ப்பு செய்கிறோம். ஒவ்வொரு துணைஅணியும் ஒரு குறிப்பிட்ட பகுதியில் கவனம் செலுத்துகிறது, எ.கா., மொழி வடிவமைப்பு அல்லது நிரலகங்கள். (...) உலகளாவிய ஒருங்கிணைப்பு மற்றும் முழுமையான திட்டத்திற்கான வலுவான, ஒத்திசைவான பார்வைக்கு, ஒவ்வொரு துணைத் தலைமையும் முக்கிய குழுவின் உறுப்பினரால் வழிநடத்தப்படுகிறது.
   <p markdown="1" class="pquote-credit">
-— ["ரஸ்ட் ஆளுமை RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— ["ரஸ்ட் ஆளுமை RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-தலைமை குழுக்கள் நியமிக்கப்பட்ட சேனலை (ஐஆர்சி போன்றவை) உருவாக்குவதற்கு அல்லது திட்டத்தை (கிட்டர் அல்லது கூகுள் ஹாங்க் அவுட் போன்றவை) விவாதிப்பதற்கு எண்ணலாம். அந்த கூட்டங்களைப் பொதுவில் வைப்பபதபதால் மற்றவர்கள் கேட்கலாம். உதாரணத்திற்கு [கூக்கூம்பர்-ரூபி](https://github.com/cucumber/cucumber-ruby), [ஒவ்வொரு வாரமும் அலுவல் நேரத்தை நடத்துகிறது](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs).
+தலைமை குழுக்கள் நியமிக்கப்பட்ட சேனலை (ஐஆர்சி போன்றவை) உருவாக்குவதற்கு அல்லது திட்டத்தை (கிட்டர் அல்லது கூகுள் ஹாங்க் அவுட் போன்றவை) விவாதிப்பதற்கு எண்ணலாம். அந்த கூட்டங்களைப் பொதுவில் வைப்பபதபதால் மற்றவர்கள் கேட்கலாம். உதாரணத்திற்கு [கூக்கூம்பர்-ரூபி](https://github.com/cucumber/cucumber-ruby), [ஒவ்வொரு வாரமும் அலுவல் நேரத்தை நடத்துகிறது](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 தலைமைத்துவப் பாத்திரங்களை நீங்கள் உருவாக்கியிருந்தால், மக்களை எவ்வாறு அடைவது என்பதை ஆவணப்படுத்த மறக்காதீர்கள்! யாரேனும் ஒருவர் பராமரிப்பாளராக அல்லது உங்கள் திட்டத்தில் துணைக்குழுவில் சேரலாம் என்பதற்கும், அதை உங்கள் GOVERNANCE.md இல் எழுதுவதற்கும் ஒரு தெளிவான வழிமுறையை உருவாக்குங்கள்.
 
diff --git a/_articles/ta/starting-a-project.md b/_articles/ta/starting-a-project.md
index 4c7910af126..54ab9b8cdf9 100644
--- a/_articles/ta/starting-a-project.md
+++ b/_articles/ta/starting-a-project.md
@@ -43,7 +43,7 @@ related:
 
 * **கூட்டு முயற்சி:** திறந்த மூல திட்டங்கள் உலகில் யாரிடமிருந்தும் மாற்றங்களை ஏற்கலாம். உதாரணமாக, [Exercism](https://github.com/exercism/) என்பது, 350 பங்களிப்பாளர்களுடன் உள்ள ஒரு நிரலாக்க பயிற்சிபாட தளமாகும்.
 
-* **ஏற்றல் மற்றும் மறுகலப்பு செய்தல்:** திறந்த மூல திட்டங்களை ஏறக்குறைய எந்த நோக்கத்திற்காகவும் பயன்படுத்தலாம். மற்ற விஷயங்களை உருவாக்க மக்கள் அதை பயன்படுத்தலாம். உதாரணமாக, [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md) என்று அழைக்கப்படும் ஒரு திட்டத்தின் ஒரு முனையாகத் துவங்கியது [வேர்ட்பிரஸ்](https://github.com/WordPress).
+* **ஏற்றல் மற்றும் மறுகலப்பு செய்தல்:** திறந்த மூல திட்டங்களை ஏறக்குறைய எந்த நோக்கத்திற்காகவும் பயன்படுத்தலாம். மற்ற விஷயங்களை உருவாக்க மக்கள் அதை பயன்படுத்தலாம். உதாரணமாக, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) என்று அழைக்கப்படும் ஒரு திட்டத்தின் ஒரு முனையாகத் துவங்கியது [வேர்ட்பிரஸ்](https://github.com/WordPress).
 
 * **வெளிப்படைத்தன்மை:** தவறுகள் அல்லது முரண்பாடுகளுக்கு எவரும் திறந்த மூல திட்டத்தை ஆய்வு செய்ய முடியும். [பல்கேரியா](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-source-98bf626cf70a) அல்லது [ஐக்கிய நாடுகள்](https://sourcecode.cio.gov/) போன்ற அரசாங்கங்களுக்கு, வங்கி அல்லது சுகாதாரம் போன்ற ஒழுங்குபடுத்தப்பட்ட தொழிற்சாலைகள், மற்றும் பாதுகாப்பு மென்பொருள் [Let's Encrypt](https://github.com/letsencrypt) போன்றவற்றிற்கு வெளிப்படைத்தன்மை முக்கியமானது.
 
@@ -179,7 +179,7 @@ README கள் உங்கள் திட்டத்தை எவ்வா
 
 ஒரு இரக்கம் உள்ள, நட்புரீதியான தொனியைப் பயன்படுத்தி, பங்களிப்பிற்கான குறிப்பிட்ட பரிந்துரைகளை வழங்குதல் (ஆவணங்கள் எழுதுதல் அல்லது வலைத்தளமாக்குதல் போன்றவை) புதுமுகங்கள் வரவேற்பு மற்றும் பங்கேற்க ஆர்வமுடையவையாக இருப்பதால் நீண்ட தூரம் செல்லலாம்.
 
-உதாரணமாக, [ஆக்டிவ் அட்மின்](https://github.com/activeadmin/activeadmin/) [அதன் பங்களிப்பு வழிகாட்டி](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) உடன் தொடங்குகிறது:
+உதாரணமாக, [ஆக்டிவ் அட்மின்](https://github.com/activeadmin/activeadmin/) [அதன் பங்களிப்பு வழிகாட்டி](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) உடன் தொடங்குகிறது:
 
 > முதலில், ஆக்டிவ் அட்மினுக்கு பங்களிக்க கருதியதற்கு நன்றி. ஆக்டிவ் அட்மின் போன்ற ஒரு பெரிய கருவியை உருவாக்கியது உங்களை போன்ற மக்கள் தான்.
 
@@ -187,7 +187,7 @@ README கள் உங்கள் திட்டத்தை எவ்வா
 
 காலப்போக்கில், உங்கள் பங்களிப்புக் கோப்பில் நீங்கள் அடிக்கடி கேட்கப்படும் கேள்விகள் சேர்க்கப்படலாம். இந்த தகவலை எழுதுவது குறைவான மக்கள் உங்களை மீண்டும் அதே கேள்விகளை கேட்க வேண்டும் என்பதாகும்.
 
-உங்கள் பங்களிப்புக் கோப்பை எழுதுவதற்கு அதிக உதவிக்காக, @nayafia இன் [பங்களிப்பு வழிகாட்டி வார்ப்புரு](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) அல்லது @mozilla's ["எப்படி ஒரு CONTRIBUTING.md உருவாக்கவும்"](Https://mozillascience.github.io/working-open-workshop/contributing/) என பார்க்கவும்.
+உங்கள் பங்களிப்புக் கோப்பை எழுதுவதற்கு அதிக உதவிக்காக, @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/), உங்கள் பங்களிப்பாளர் ஒரு சிக்கல் உருவாக்கும் போது அல்லது ஒரு மிகுதிக் கோரிக்கையைத் திறக்கும் போது கிட்ஹப் தானாகவே கோப்பில் இணைக்கப்படும்
 
diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md
index d1c8e1d66fe..79c7f8ff2cd 100644
--- a/_articles/tr/building-community.md
+++ b/_articles/tr/building-community.md
@@ -143,7 +143,7 @@ Son olarak, insanların yolun her aşamasında kendilerini rahat hissetmelerini
 
 Projenize ulaşan çoğu insanla asla etkileşime geçemeyeceksiniz. Biri kendini çekingen hissettiği veya nereden başlayacağını bilmediği için almadığınız katkılar olabilir. Birkaç nazik kelime bile, birisinin projenizde hayal kırıklığına uğratmasına engel olabilirsiniz.
 
-Örneğin, [Rubinius](https://github.com/rubinius/rubinius/)[katkıda bulunan kılavuzuna](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md) {a2}şöyle{/a2} başlıyor:
+Örneğin, [Rubinius](https://github.com/rubinius/rubinius/)[katkıda bulunan kılavuzuna](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) {a2}şöyle{/a2} başlıyor:
 
 > Rubinius'u kullandığınız için teşekkür ederek başlamak istiyoruz. Bu proje bir sevgi emeğidir ve hataları yakalayan, performans iyileştirmeleri yapan ve belgelere yardımcı olan tüm kullanıcıları takdir ediyoruz. Her katkı anlamlıdır, katılımınız için teşekkür ederiz. İşte sorununuzu başarıyla çözebilmemiz için izlemenizi istediğimiz birkaç kural.
 
@@ -165,7 +165,7 @@ Mülkiyetinizi topluluğunuzla mümkün olduğunca paylaşmanın yollarını bul
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* Projenizde, projenize katkıda bulunan herkesi listeleyen **bir CONTRIBUTORS veya AUTHORS dosyası başlatın**,[Sinatra'nın](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md) yaptığı gibi.
+* Projenizde, projenize katkıda bulunan herkesi listeleyen **bir CONTRIBUTORS veya AUTHORS dosyası başlatın**,[Sinatra'nın](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) yaptığı gibi.
 
 * Oldukça büyük bir topluluğunuz varsa, **bülten gönderin veya katkıda bulunanlara teşekkür eden bir blog yazısı yazın**. Rust'ın [Rust'ta Bu Hafta](https://this-week-in-rust.org/) ve Hoodie'nin [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) bültenleri iki güzel örnek.
 
diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md
index 7c87eee3d85..571fd442f74 100644
--- a/_articles/tr/code-of-conduct.md
+++ b/_articles/tr/code-of-conduct.md
@@ -60,7 +60,7 @@ Bir ihlal meydana _gelmeden önce_ davranış kurallarınızın nasıl uygulanac
 
 İnsanlara davranış kuralları ihlalini bildirebilmeleri için özel bir yol (e-posta adresi gibi) vermelisiniz ve bu raporun kimlere ulaştığını açıklamalısınız. Bu bir kurucu, bir geliştirme grubu veya bir davranış kuralları çalışma grubu olabilir.
 
-Birisinin, bu raporları alan bir kişi hakkındaki ihlali bildirmek isteyebileceğini de unutmayın. Bu durumda, ihlalleri bir başkasına bildirme seçeneği de verin. Örneğin, @ctb ve @mr-c"nin [projeleri üzerinde açıkladıkları gibi](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst) , [khmer](https://github.com/dib-lab/khmer) :
+Birisinin, bu raporları alan bir kişi hakkındaki ihlali bildirmek isteyebileceğini de unutmayın. Bu durumda, ihlalleri bir başkasına bildirme seçeneği de verin. Örneğin, @ctb ve @mr-c"nin [projeleri üzerinde açıkladıkları gibi](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst) , [khmer](https://github.com/dib-lab/khmer) :
 
 > Kötü niyetli, taciz edici veya kabul edilemez davranışların **örnekleri** , yalnızca C. Titus Brown ve Michael R. Crusoe'ye gönderilen **khmer-project@idyll.org adresine** e-posta {strong2}gönderilerek{/strong2} bildirilebilir. İkisini de içeren bir sorunu bildirmek için lütfen {strong3}Judi Brown Clarke, Ph.D.{/strong3} NSAC Bilim ve Teknoloji Merkezi olan, Eylemdeki Evrim Çalışması Merkezi'ndeki BEACON Çeşitlilik Direktörü. *
 
diff --git a/_articles/tr/leadership-and-governance.md b/_articles/tr/leadership-and-governance.md
index b0425577a83..1adb235e572 100644
--- a/_articles/tr/leadership-and-governance.md
+++ b/_articles/tr/leadership-and-governance.md
@@ -72,11 +72,11 @@ Projeniz çok aktif bir katılımcı topluluğa sahipse, farklı konu alanların
 <aside markdown="1" class="pquote">
   \[Biz\] çekirdek takıma birkaç "alt takım" ekliyoruz. Her alt takım belirli bir alana, örneğin dil tasarımına veya kütüphanelere odaklanır. (...) Küresel koordinasyon ve bir bütün olarak proje için güçlü, tutarlı bir vizyon sağlamak için her bir alt ekip, çekirdek ekibin bir üyesi tarafından yönetilir.
   <p markdown="1" class="pquote-credit">
-- ["Rust Yönetişim RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+- ["Rust Yönetişim RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Liderlik ekipleri projeyi tartışmak için (Gitter veya Google Hangout'ta olduğu gibi) belirlenmiş bir kanal oluşturmak (IRC'deki gibi) veya düzenli olarak buluşmak isteyebilir. Hatta başkalarının dinleyebilmesi için bu toplantıları halka açabilirsiniz. Örneğin [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) [her hafta çalışma saatlerinde yayın yapar](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs) .
+Liderlik ekipleri projeyi tartışmak için (Gitter veya Google Hangout'ta olduğu gibi) belirlenmiş bir kanal oluşturmak (IRC'deki gibi) veya düzenli olarak buluşmak isteyebilir. Hatta başkalarının dinleyebilmesi için bu toplantıları halka açabilirsiniz. Örneğin [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) [her hafta çalışma saatlerinde yayın yapar](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs) .
 
 Liderlik rolleri belirledikten sonra, insanların onlara nasıl ulaşabileceğini belgelemeyi unutmayın! Projenizde birisinin nasıl sorumlu olabileceği ya da bir alt komiteye katılabileceği konusunda net bir süreç belirleyin ve bunu GOVERNANCE.md'inize yazın.
 
diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index d6eb2e2deda..d5ef2ae8642 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -42,7 +42,7 @@ Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](htt
 
 * **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur.
 
-* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
+* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
 
 * **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
 
@@ -178,7 +178,7 @@ Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi
 
 Sıcak, arkadaşça bir ton kullanmak ve katkılar için özel önerilerde bulunmak (örneğin, dokümantasyon yazmak veya bir web sitesi yapmak gibi) yeni gelenlerin kendilerini memnun ve istekli hissetmelerini sağlama konusunda yardımcı olabilir.
 
-Örneğin, [Active Admin](https://github.com/activeadmin/activeadmin/) [katkıda bulunan rehberine](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) şu şekilde başlar:
+Örneğin, [Active Admin](https://github.com/activeadmin/activeadmin/) [katkıda bulunan rehberine](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) şu şekilde başlar:
 
 > Öncelikle, Active Admin’e katkıda bulunduğunuz için teşekkür ederiz. Active Admin'i harika bir araç yapan sizin gibi insanlar.
 
@@ -186,7 +186,7 @@ Projenizin ilk aşamalarında, CONTRIBUTING dosyanız basit olabilir. Hataların
 
 Zamanla, CONTRIBUTING dosyanıza sıkça sorulan diğer soruları ekleyebilirsiniz. Bu bilgileri yazmak, daha az kişinin size aynı soruları tekrar soracağı anlamına gelir.
 
-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/master/CONTRIBUTING-template.md) veya @mozilla'nın ["Bir CONTRIBUTING.md Nasıl Oluşturulur"](https://mozillascience.github.io/working-open-workshop/contributing/) makalesine bakabilirsiniz.
+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.
 
diff --git a/_articles/zh-hans/building-community.md b/_articles/zh-hans/building-community.md
index 2abb8ee329e..26ffdd1fba7 100644
--- a/_articles/zh-hans/building-community.md
+++ b/_articles/zh-hans/building-community.md
@@ -76,7 +76,7 @@ redirect_from: /zh-cn/building-community/
 
 ### 积极回应
 
-一旦你[推广项目](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-03.md)，人们将会给你们反馈。他们可能会问项目是如何工作的，或者参与项目初期需要你的帮助。
+一旦你[推广项目](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/HEAD/github-open-source-guide-03.md)，人们将会给你们反馈。他们可能会问项目是如何工作的，或者参与项目初期需要你的帮助。
 
 当有人列出一条issue，提交一个pull request，或者询问项目的有关问题时，你们应该尽量回答他们。当你们快速地做出回应时，人们将感觉到他们参与了对话，以及他们将会更热情地参与。
 
@@ -142,7 +142,7 @@ redirect_from: /zh-cn/building-community/
 
 你不可能做到与项目中的绝大多数人产生互动，你们可能没有收到一些贡献，因为有些人感到害怕或者不知道该从何处开始，有时候即使是几个字也能阻止一些人沮丧地离开你们的项目。
 
-例如，这里是[Rubinius](https://github.com/rubinius/rubinius/)如何开始[它的贡献指南](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md)：
+例如，这里是[Rubinius](https://github.com/rubinius/rubinius/)如何开始[它的贡献指南](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md)：
 
 > 我们想感谢你们使用Rubinius。这个项目是一个充满爱的工作，我们希望所有用户查找bugs，取得性能上的提升，以及帮助完善文档。每一个贡献都是有意义的，所以感谢你们的参与。话虽如此，但我们还是要求你们遵守一些指南，这样我们就能够找到你们的issue。
 
diff --git a/_articles/zh-hans/code-of-conduct.md b/_articles/zh-hans/code-of-conduct.md
index 5e7a939d4e7..5b88b4f89ed 100644
--- a/_articles/zh-hans/code-of-conduct.md
+++ b/_articles/zh-hans/code-of-conduct.md
@@ -55,7 +55,7 @@ redirect_from: /zh-cn/code-of-conduct/
 
 你们可以给大家一个私有的渠道（如email地址）以便大家报告违规行为以及解释谁收到了这一的报告。它可以是维护者，一组维护者或行为守则工作组。
 
-请不要忘记了有人可能想要报告某些人违规接受了这些报告。在这样的情况下，也给他们举报那些人的机会。例如，@ctb和@mr-c [在他们的项目上解释](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst)， [khmer](https://github.com/dib-lab/khmer)：
+请不要忘记了有人可能想要报告某些人违规接受了这些报告。在这样的情况下，也给他们举报那些人的机会。例如，@ctb和@mr-c [在他们的项目上解释](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst)， [khmer](https://github.com/dib-lab/khmer)：
 
 > 对于滥用现象，扰乱或者其他不可接受的行为都可以向**khmer-project@idyll.org**（仅由C. Titus Brown和Michael R. Crusoe处理）发送邮件。要报告涉及其中任何一个的问题，请电邮**Judi Brown Clarke，Ph.D.** BEACON行动进化研究中心的多元化主任，NSF科学技术中心。
 
diff --git a/_articles/zh-hans/leadership-and-governance.md b/_articles/zh-hans/leadership-and-governance.md
index 621249fcb12..b837d84b9d2 100644
--- a/_articles/zh-hans/leadership-and-governance.md
+++ b/_articles/zh-hans/leadership-and-governance.md
@@ -64,12 +64,12 @@ redirect_from: /zh-cn/leadership-and-governance/
 <aside markdown="1" class="pquote">
   \[我们\] 为核心团队设立多个"子团队"。每个子团队都会专门的聚焦于某个特定的领域，举例来说，语言设计或程序库(...) 为了确保全局的协调和健壮，会将整体的项目设置为同一个愿景，每个子团队是由核心团队的一员。
   <p markdown="1" class="pquote-credit">
-— ["Rust 治理 RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— ["Rust 治理 RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
 领导者团队或许要创建一个指定的频道（如IRC），又或者是参与项目的日常讨论（如Gitter或Google Hangout）。你需要将这些会议可以公开访问，以便让人们方便倾听。举例来说，
- [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)就会[每周开一次会议，每次持续几小时](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs).
+ [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)就会[每周开一次会议，每次持续几小时](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 一旦你建立了领导力角色，一定不要忘记撰写文档，告诉人们如何成为领导者！要为如何成为一名维护者或加入到项目的子委员会创建一个清晰的流程，并将之写入 GOVERNANCE.md 文件。
 
diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index 5ff25064f2c..5b8c9adc1a4 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -126,7 +126,7 @@ redirect_from: /zh-cn/legal/
 
 * **专利：**你们公司是否申请了与你们项目有关的专利？如果开源源代码，这会对公司的专利进行[公开披露](https://en.wikipedia.org/wiki/Public_disclosure)。可悲的是，你们可能被要求等待（或者公司会重新思考应用程序）。如果你们期望从拥有大量专利组合的公司的员工那里得到贡献，们的法律团队可能希望你们使用来自贡献者的明确专利授权的许可协议（例如Apache 2.0或GPLv3）或其他贡献者协议（见上文）。
 
-* **商标：**认真检查你们的项目名[没有与已经存在的商标冲突](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-02.md#避免命名冲突)。如果你们将自己公司的商标用于项目，请检查它有没有造成冲突。[FOSSmarks](http://fossmarks.org/)是在自由和开源项目的背景下理解商标的实用指南。
+* **商标：**认真检查你们的项目名[没有与已经存在的商标冲突](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/HEAD/github-open-source-guide-02.md#避免命名冲突)。如果你们将自己公司的商标用于项目，请检查它有没有造成冲突。[FOSSmarks](http://fossmarks.org/)是在自由和开源项目的背景下理解商标的实用指南。
 
 * **隐私：**你们的项目是否收集了用户数据并存储到公司的服务器？你们的法律团队可以帮助你们遵守公司政策和外部法规。
 
diff --git a/_articles/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md
index f73ce9c3e94..94817b6a085 100644
--- a/_articles/zh-hans/starting-a-project.md
+++ b/_articles/zh-hans/starting-a-project.md
@@ -44,7 +44,7 @@ redirect_from: /zh-cn/starting-a-project/
 
 * **协作：** 开源项目可以接受世界各地人们的修改。 例如 [Exercism](https://github.com/exercism/) 就是一个拥有350多个贡献者的练习平台。
 
-* **采用和重组：** 任何人几乎可以出于任何目的使用开源项目。人们甚至可以使用它来构建其他东西。例如，[WordPress](https://github.com/WordPress) 就是派生自一个名为 [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md) 的现有项目。
+* **采用和重组：** 任何人几乎可以出于任何目的使用开源项目。人们甚至可以使用它来构建其他东西。例如，[WordPress](https://github.com/WordPress) 就是派生自一个名为 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) 的现有项目。
 
 * **透明度：** 任何人都可以检查开源项目是否有错误或不一致。 透明度对[保加利亚](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美国](https://sourcecode.cio.gov/)等政府，银行或医疗保健等受监管行业以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全软件都很重要。
 
@@ -180,7 +180,7 @@ redirect_from: /zh-cn/starting-a-project/
 
 使用热情友好的语气并提供具体的贡献建议（例如编写文档或者搭建网站）可以大大提高新人的参与度。
 
-例如，[Active Admin](https://github.com/activeadmin/activeadmin/) 以这样的方式开始[它的贡献指南](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md)：
+例如，[Active Admin](https://github.com/activeadmin/activeadmin/) 以这样的方式开始[它的贡献指南](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md)：
 
 > 首先， 非常感谢你考虑为 Active Admin 贡献帮助。正是你这样的人使 Active Admin 成为一个很棒的工具。
 
@@ -188,7 +188,7 @@ redirect_from: /zh-cn/starting-a-project/
 
 随着时间的推移，你可以将其他常见问题添加到贡献文件中去。写下这些信息意味着问你相同问题的人会越来越少。
 
-想要获得更多有关编写贡献文件的方式，请查阅 @nayafia 的 [贡献指南模板](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) 或者 @mozilla 的 ["如何构建 CONTRIBUTION.md"](https://mozillascience.github.io/working-open-workshop/contributing/)。
+想要获得更多有关编写贡献文件的方式，请查阅 @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 会自动链接你的文件。
 
diff --git a/_articles/zh-hant/README.md b/_articles/zh-hant/README.md
index b080300899e..7d1ec86dd6a 100644
--- a/_articles/zh-hant/README.md
+++ b/_articles/zh-hant/README.md
@@ -4,11 +4,11 @@
 
 ## 貢獻
 
-網站是由[Jekyll](https://jekyllrb.com/) 套件建立而成。請先閱讀 [貢獻指引](https://github.com/github/opensource.guide/blob/master/CONTRIBUTING.md) 來了解如何回饋以及貢獻。
+網站是由[Jekyll](https://jekyllrb.com/) 套件建立而成。請先閱讀 [貢獻指引](https://github.com/github/opensource.guide/blob/HEAD/CONTRIBUTING.md) 來了解如何回饋以及貢獻。
 
 ## 授權
 
-內容以 [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/) 的方式釋出。請參閱 [notices](https://github.com/github/opensource.guide/blob/master/CONTRIBUTING.md) 文件以了解歸音指南、貢獻條款、軟體以及第三方授權權限。
+內容以 [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/) 的方式釋出。請參閱 [notices](https://github.com/github/opensource.guide/blob/HEAD/CONTRIBUTING.md) 文件以了解歸音指南、貢獻條款、軟體以及第三方授權權限。
 
 ## 人員致謝
 
diff --git a/_articles/zh-hant/building-community.md b/_articles/zh-hant/building-community.md
index 9d3c85b2642..ac2fd953bff 100644
--- a/_articles/zh-hant/building-community.md
+++ b/_articles/zh-hant/building-community.md
@@ -27,8 +27,8 @@ redirect_from: /zh-tw/building-community/
 
 從你的說明文件開始著手：
 
-* **讓大家很容易上手。** [一份好閱讀的 README](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-02.md#編寫readme)以及清晰的程式碼範例，讓大家很容易的上手。
-* **清楚的說明該如何貢獻**，使用[你的CONTRIBUTING file](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-02.md#編寫你的貢獻指南)並持續更新issues。
+* **讓大家很容易上手。** [一份好閱讀的 README](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/HEAD/github-open-source-guide-02.md#編寫readme)以及清晰的程式碼範例，讓大家很容易的上手。
+* **清楚的說明該如何貢獻**，使用[你的CONTRIBUTING file](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/HEAD/github-open-source-guide-02.md#編寫你的貢獻指南)並持續更新issues。
 
 在 [GitHub 2017 開源調查報告](http://opensourcesurvey.org/2017/)中指出，令人困惑或不完整的說明文件是開源使用者最大的困擾，好的說明文建會吸引人們與專案互動。總有一天，會有人開啟一個 issue 或 PR。盡量使用這些工具讓人們有機會朝漏斗的下方邁進。
 
@@ -76,7 +76,7 @@ redirect_from: /zh-tw/building-community/
 
 ### 積極迴應
 
-一旦你[推廣專案](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-03.md)，人們將會給你們回饋。他們可能會問專案是如何工作的，或者希望有人教他怎麼使用。
+一旦你[推廣專案](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/HEAD/github-open-source-guide-03.md)，人們將會給你們回饋。他們可能會問專案是如何工作的，或者希望有人教他怎麼使用。
 
 當有人提出一條 issue ，提交一個 pull request ，或詢問專案有關的問題時，你們應該盡快回覆他們。當你們快速地做出反應時，大家會覺得有參與到對話，會有熱情去參與專案。
 
@@ -140,7 +140,7 @@ redirect_from: /zh-tw/building-community/
 
 你不可能與專案中大多數的人互動，因為有些人怕犯錯，或不知道該從何處開始，結果就可能讓你錯失獲得貢獻的機會。但有時候也只是幾個字，就能避免一些人沮喪地離開你們的專案。
 
-例如[Rubinius](https://github.com/rubinius/rubinius/)在[它的貢獻指南](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md)開頭寫道：
+例如[Rubinius](https://github.com/rubinius/rubinius/)在[它的貢獻指南](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md)開頭寫道：
 
 > 我們感謝你們使用 Rubinius 。這專案是個充滿愛的工作，我們感激所有參與的人，不論是為我們抓 bug 、提升性能或完善說明文件。每一個貢獻都是有意義的，感謝你們的參與。話雖如此，我們還是要求參與者遵守一些指南，如此一來我們也才能夠回覆你們的 issue 。
 
diff --git a/_articles/zh-hant/code-of-conduct.md b/_articles/zh-hant/code-of-conduct.md
index 22f76d3c878..10649a5de71 100644
--- a/_articles/zh-hant/code-of-conduct.md
+++ b/_articles/zh-hant/code-of-conduct.md
@@ -55,7 +55,7 @@ redirect_from: /zh-tw/code-of-conduct/
 
 你們可以給大家一個私有的渠道（如email地址）以便大家報告違規行爲以及解釋誰收到了這一的報告。它可以是維護者，一組維護者或行爲守則工作組。
 
-請不要忘記了有人可能想要報告某些人違規接受了這些報告。在這樣的情況下，也給他們舉報那些人的機會。例如，@ctb和@mr-c [在他們的專案上解釋](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst)， [khmer](https://github.com/dib-lab/khmer)：
+請不要忘記了有人可能想要報告某些人違規接受了這些報告。在這樣的情況下，也給他們舉報那些人的機會。例如，@ctb和@mr-c [在他們的專案上解釋](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst)， [khmer](https://github.com/dib-lab/khmer)：
 
 > 對於濫用現象，擾亂或者其他不可接受的行爲都可以向**khmer-project@idyll.org**（僅由C. Titus Brown和Michael R. Crusoe處理）發送郵件。要報告涉及其中任何一個的問題，請電郵**Judi Brown Clarke，Ph.D.** BEACON行動進化研究中心的多元化主任，NSF科學技術中心。
 
diff --git a/_articles/zh-hant/leadership-and-governance.md b/_articles/zh-hant/leadership-and-governance.md
index c7437d86216..fea3320d450 100644
--- a/_articles/zh-hant/leadership-and-governance.md
+++ b/_articles/zh-hant/leadership-and-governance.md
@@ -25,7 +25,7 @@ redirect_from: /zh-tw/leadership-and-governance/
 * **貢獻者**
 * **修訂者**
 
-**對於某些專案來說， "維護者"** 就是唯一擁有提交權限的人。然而在其它的一些專案中，維護者會列在README上  
+**對於某些專案來說， "維護者"** 就是唯一擁有提交權限的人。然而在其它的一些專案中，維護者會列在README上
 
 作爲一名維護者，不一定非得一定要爲專案撰寫程式。有可能是專案的佈道師，爲專案的宣傳做了很多的工作，又或者是撰寫文件讓更多的人參與進來。不管他們每天做什麼，維護者就是那些對專案方向負責的人，並致力於專案的改進。
 
@@ -64,12 +64,12 @@ redirect_from: /zh-tw/leadership-and-governance/
 <aside markdown="1" class="pquote">
   \[我們\] 爲核心團隊設立多個"子團隊"。每個子團隊都會專門的聚焦於某個特定的領域，舉例來說，語言設計或程序庫(...) 爲了確保全局的協調和健壯，會將整體的專案設置爲同一個願景，每個子團隊是由核心團隊的一員。
   <p markdown="1" class="pquote-credit">
-— ["Rust 治理 RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md)
+— ["Rust 治理 RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
 領導者團隊或許要創建一個指定的頻道（如IRC），又或者是參與專案的日常討論（如Gitter或Google Hangout）。你需要將這些會議可以公開訪問，以便讓人們方便傾聽。舉例來說，
- [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)就會[每週開一次會議，每次持續幾小時](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs).
+ [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)就會[每週開一次會議，每次持續幾小時](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 一旦你建立了領導力角色，一定不要忘記撰寫文件，告訴人們如何成爲領導者！要爲如何成爲一名維護者或加入到專案的子委員會創建一個清晰的流程，並將之寫入 GOVERNANCE.md 文件。
 
diff --git a/_articles/zh-hant/legal.md b/_articles/zh-hant/legal.md
index 862fe2eadfc..4d1de93e01a 100644
--- a/_articles/zh-hant/legal.md
+++ b/_articles/zh-hant/legal.md
@@ -125,7 +125,7 @@ redirect_from: /zh-tw/legal/
 
 * **專利：**你們公司是否申請了與你們專案有關的專利？如果開源源程式碼，這會對公司的專利進行[公開披露](https://en.wikipedia.org/wiki/Public_disclosure)。可悲的是，你們可能被要求等待（或者公司會重新思考應用程序）。如果你們期望從擁有大量專利組合的公司的員工那裏得到貢獻，們的法律團隊可能希望你們使用來自貢獻者的明確專利授權的許可協議（例如Apache 2.0或GPLv3）或其他貢獻者協議（見上文）。
 
-* **商標：**認真檢查你們的專案名[沒有與已經存在的商標衝突](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-02.md#避免命名衝突)。如果你們將自己公司的商標用於專案，請檢查它有沒有造成衝突。[FOSSmarks](http://fossmarks.org/)是在自由和開源專案的背景下理解商標的實用指南。
+* **商標：**認真檢查你們的專案名[沒有與已經存在的商標衝突](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/HEAD/github-open-source-guide-02.md#避免命名衝突)。如果你們將自己公司的商標用於專案，請檢查它有沒有造成衝突。[FOSSmarks](http://fossmarks.org/)是在自由和開源專案的背景下理解商標的實用指南。
 
 * **隱私：**你們的專案是否收集了用戶數據並存儲到公司的服務器？你們的法律團隊可以幫助你們遵守公司政策和外部法規。
 
diff --git a/_articles/zh-hant/starting-a-project.md b/_articles/zh-hant/starting-a-project.md
index 65211025286..cb4743815fd 100644
--- a/_articles/zh-hant/starting-a-project.md
+++ b/_articles/zh-hant/starting-a-project.md
@@ -44,7 +44,7 @@ redirect_from: /zh-tw/starting-a-project/
 
 * **協作：** 開源專案可以接受世界各地人們的修改。 例如 [Exercism](https://github.com/exercism/) 就是一個擁有350多個貢獻者的練習平臺。
 
-* **採用和重組：** 任何人幾乎可以出於任何目的使用開源專案。人們甚至可以使用它來構建其他東西。例如，[WordPress](https://github.com/WordPress) 就是派生自一個名爲 [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md) 的現有專案。
+* **採用和重組：** 任何人幾乎可以出於任何目的使用開源專案。人們甚至可以使用它來構建其他東西。例如，[WordPress](https://github.com/WordPress) 就是派生自一個名爲 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) 的現有專案。
 
 * **透明度：** 任何人都可以檢查開源專案是否有錯誤或不一致。 透明度對[保加利亞](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美國](https://sourcecode.cio.gov/)等政府，銀行或醫療保健等受監管行業以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全軟件都很重要。
 
@@ -180,7 +180,7 @@ redirect_from: /zh-tw/starting-a-project/
 
 溫柔友好的逾期和向貢獻者們提供具體的建議（例如寫文檔或者搭建一個網頁）能夠有效地使新人感到受歡迎並樂於參與其中。
 
-例如，[Active Admin](https://github.com/activeadmin/activeadmin/) 以這樣的方式開始[它的貢獻指南](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md)：
+例如，[Active Admin](https://github.com/activeadmin/activeadmin/) 以這樣的方式開始[它的貢獻指南](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md)：
 
 > 首先， 非常感謝你考慮爲 Active Admin 貢獻幫助。正式你這樣的人們使得 Active Admin 成爲瞭如此優秀的工具。
 
@@ -188,7 +188,7 @@ redirect_from: /zh-tw/starting-a-project/
 
 隨着時間的推移，你硬弓增加其他常見問題到你的貢獻文件中去。寫下這些資訊意味着問你相同問題的人會越來越少。
 
-想要獲得更多有關編寫貢獻文件的方式，請查閱 @nayafia 的 [貢獻指南模板](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) 或者 @mozilla 的 ["如何構建 CONTRIBUTION.md"](http://mozillascience.github.io/working-open-workshop/contributing/)。
+想要獲得更多有關編寫貢獻文件的方式，請查閱 @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 會自動鏈接你的文件。
 
diff --git a/_includes/nav.html b/_includes/nav.html
index 7253115e490..d25cc143864 100644
--- a/_includes/nav.html
+++ b/_includes/nav.html
@@ -9,7 +9,7 @@
           </a>
         </li>
         <li class="d-inline-block border-right">
-          <a class="d-block p-4" href="https://github.com/github/opensource.guide/blob/master/CONTRIBUTING.md">
+          <a class="d-block p-4" href="https://github.com/github/opensource.guide/blob/HEAD/CONTRIBUTING.md">
             {{ t.nav.contribute }}
           </a>
         </li>
diff --git a/docs/translations.md b/docs/translations.md
index d2dd5f72897..281eb851c26 100644
--- a/docs/translations.md
+++ b/docs/translations.md
@@ -13,7 +13,7 @@ If there's not, then today is your day to lead this effort! Here's how to start:
 1. Create a new branch for your translation work e.g. `es`.
 1. Copy `_data/locales/en.yml` to your target language file e.g. `_data/locales/es.yml` and translate all the strings.
 1. Create a new directory in `_articles/` for your language e.g. `_articles/es/`, copy each guide from `_articles/` into that folder and translate the content in each guide, except for the field names in the front matter between the `---`s at the top of each file, e.g., `title:` should remain unchanged. Remove the `toc:` fields (they are only used for English).
-1. Copy `index.html` to your target language index file e.g. `[_articles/es/index.html](https://github.com/github/opensource.guide/blob/master/_articles/es/index.html)` and update the `lang:` and add the `permalink:` fields. Example: `lang: es` and `permalink: /es/`. All other fields' values must remain unchanged.
+1. Copy `index.html` to your target language index file e.g. `[_articles/es/index.html](https://github.com/github/opensource.guide/blob/HEAD/_articles/es/index.html)` and update the `lang:` and add the `permalink:` fields. Example: `lang: es` and `permalink: /es/`. All other fields' values must remain unchanged.
 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.)
 
diff --git a/test/prose b/test/prose
index 696c68f4273..a73ab1e8fa6 100755
--- a/test/prose
+++ b/test/prose
@@ -98,7 +98,7 @@ var markdown = unified()
   .use(stringify)
   .use(frontmatter, 'yaml')
 
-  // https://github.com/wooorm/remark-lint/blob/master/doc/rules.md
+  // https://github.com/wooorm/remark-lint/blob/HEAD/doc/rules.md
   .use(lint)
 
   // Headings

From 8ced75f6d09aa70e74bff7a50a2af2342b358795 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Sun, 12 Jul 2020 22:34:53 +0000
Subject: [PATCH 019/749] Translate building-community.md via GitLocalize

---
 _articles/tr/building-community.md | 104 ++++++++---------------------
 1 file changed, 28 insertions(+), 76 deletions(-)

diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md
index 79c7f8ff2cd..361c73d3f2f 100644
--- a/_articles/tr/building-community.md
+++ b/_articles/tr/building-community.md
@@ -8,10 +8,10 @@ toc:
   growing-your-community: Topluluğunuzu büyütmek
   resolving-conflicts: Çatışmaları çözmek
 order: 4
-image: "/assets/images/cards/building.png"
+image: /assets/images/cards/building.png
 related:
-  - best-practices
-  - coc
+- best-practices
+- coc
 ---
 
 ## Projenizi başarı için hazırlamak
@@ -30,24 +30,18 @@ Topluluğunuzu oluştururken huninin tepesindeki birinin (potansiyel bir kullan
 
 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ıda-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.
+- **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.
 
 [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.
 
-* **Yeni birileri projenize geldiğinde, ilgilendikleri için teşekkür edin!** Birinin geri gelmek istememesi için yalnızca bir olumsuz deneyim yeterlidir.
-* **Hızlı cevap verin.** Sorunlarına bir ay boyunca cevap vermezseniz, büyük olasılıkla projenizi çoktan unutmuş olurlar.
-* **Kabul edeceğiniz katkı türleri konusunda açık fikirli olun.** Katkıda bulunan birçok kişi bir hata raporu veya küçük bir düzeltme ile başlar. Bir projeye [katkıda bulunmak için birçok yol](../how-to-contribute/#katkıda-bulunmak-ne-demektir) var. İnsanların nasıl istiyorlarsa öyle yardım etmelerine izin verin.
-* **Katılmadığınız bir katkı varsa** , fikirleri için onlara teşekkür edin ve [niçin](../best-practices/#hayır-demeyi-öğrenme) projenin kapsamına uymadığını açıklayın, varsa ilgili dokümantasyondan alıntı yapın.
+- **Yeni birileri projenize geldiğinde, ilgilendikleri için teşekkür edin!** Birinin geri gelmek istememesi için yalnızca bir olumsuz deneyim yeterlidir.
+- **Hızlı cevap verin.** Sorunlarına bir ay boyunca cevap vermezseniz, büyük olasılıkla projenizi çoktan unutmuş olurlar.
+- **Kabul edeceğiniz katkı türleri konusunda açık fikirli olun.** Katkıda bulunan birçok kişi bir hata raporu veya küçük bir düzeltme ile başlar. Bir projeye [katkıda bulunmak için birçok yol](../how-to-contribute/#katk%C4%B1da-bulunmak-ne-demektir) var. İnsanların nasıl istiyorlarsa öyle yardım etmelerine izin verin.
+- **Katılmadığınız bir katkı varsa** , fikirleri için onlara teşekkür edin ve [niçin](../best-practices/#hay%C4%B1r-demeyi-%C3%B6%C4%9Frenme) projenin kapsamına uymadığını açıklayın, varsa ilgili dokümantasyondan alıntı yapın.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  Açık kaynağa katkıda bulunmak, bazıları için daha kolaydır. İnsanların içinde bir şeyi doğru anlamadıkları ya da yapmadıkları için uyarılma korkuları vardır. (...) Katkı yapanlara çok düşük teknik yeterlilikle (dokümantasyon, web içeriği işaretlemesi vb.) katkıda bulunacakları bir yol vererek, bu korkuyu büyük ölçüde azaltabilirsiniz.
-  <p markdown="1" class="pquote-credit">
-— @mikeal, ["Modern açık kaynakta katılımcı tabanını büyütmek"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/mikeal?s=180">   Bazıları için açık kaynağa katkıda bulunmak diğerlerinden daha kolaydır. Doğru bir şey yapmamak ya da sadece uyum sağlamaktan bağırmaktan korkmak çok fazla. (...) Katkıda bulunanlara çok düşük teknik yeterliliğe (dokümantasyon, web içeriği işaretleme, vb.) Katkıda bulunacak bir yer vererek bu kaygılar.  <p markdown="1" class="pquote-credit"> — @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)   </p></aside>
 
 Açık kaynak katkıda bulunanların çoğunluğu "geçici katkı yapanlardır": yani bir projeye yalnızca ara sıra katkıda bulunan insanlar. Sıradan bir katılımcının projenizi hızlandırmak için tam zamanı olmayacağı için işiniz onların katkıda bulunmalarını kolaylaştırmaktır.
 
@@ -55,13 +49,7 @@ Diğer katılımcıları teşvik etmek kendinize yapılan bir yatırımdır. En
 
 ### Her şeyi belgeleyin
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  Hiç kimseyi tanımadığınız (teknoloji) bir etkinliğe katıldınız mı, ama diğerleri gruplarda durup eski arkadaşlar gibi sohbet ettiler mi? (...) Şimdi açık kaynaklı bir projeye katkıda bulunmak istediğinizi hayal edin, ancak bunun neden veya nasıl olduğunu görmüyorsunuz.
-  <p markdown="1" class="pquote-credit">
-— @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">   Hiç kimseyi tanımadığınız (teknoloji) bir etkinliğe katıldınız mı, ama diğerleri gruplarda durup eski arkadaşlar gibi sohbet ettiler mi? (...) Şimdi açık kaynaklı bir projeye katkıda bulunmak istediğinizi hayal edin, ancak bunun neden veya nasıl olduğunu görmüyorsunuz.   <p markdown="1" class="pquote-credit"> — @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)   </p> </aside>
 
 Yeni bir projeye başladığınızda, çalışmanızı özel tutmak doğal olabilir. Ancak, açık kaynaklı projeler, sürecinizi halka açık olarak belgelemeniz durumunda gelişir.
 
@@ -117,17 +105,11 @@ Herhangi bir popüler proje kaçınılmaz olarak topluluğunuza yardım etmek ye
 
 Bu tür insanlara karşı sıfır tolerans politikası benimsemek için elinizden geleni yapın. Denetlenmezse, negatif insanlar topluluğunuzdaki diğer insanları rahatsız eder. Hatta ayrılmalarına sebep olabilirler.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
-  Gerçek şu ki, destekleyici bir topluluğa sahip olmak anahtardır. Bu işi asla meslektaşlarımın, arkadaş canlısı internet yabancılarının ve konuşkan IRC kanallarının yardımı olmadan yapamam. (...) Daha azına razı olmayın. Pisliklere razı olmayın.
-  <p markdown="1" class="pquote-credit">
-— @okdistribute, ["Bir FOSS Projesinin Nasıl Çalıştırılacağı"](https://okdistribute.xyz/post/okf-de)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/okdistribute?s=180">   Gerçek şu ki, destekleyici bir topluluğa sahip olmak çok önemlidir. Meslektaşlarımın, arkadaş canlısı yabancıların ve konuşkan IRC kanallarının yardımı olmadan bu işi asla yapamazdım. (...) Daha azına razı olma. Pisliklere razı olma.  <p markdown="1" class="pquote-credit"> — @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)   </p></aside>
 
 Projenizin önemsiz yönleriyle ilgili düzenli tartışmalar, sizin de dahil olmak üzere diğerlerini önemli görevlere odaklanmaktan alıkoyuyor. Projenize gelen yeni insanlar bu konuşmaları görebilir ve katılmak istemeyebilir.
 
-Projenizde olumsuz davranışlar olduğunu gördüğünüzde, herkese açık olarak uyarın. Nazikçe ama sert bir tonda, davranışlarının neden kabul edilebilir olmadığını açıklayın. Sorun devam ederse, [onlardan gitmelerini istemeniz](../code-of-conduct/#davranış-kural-listesini-güçlendirmek) gerekebilir. [Davranış kuralları listeniz](../code-of-conduct/) bu konuşmalar için yapıcı bir rehber olabilir.
+Projenizde olumsuz davranışlar olduğunu gördüğünüzde, herkese açık olarak uyarın. Nazikçe ama sert bir tonda, davranışlarının neden kabul edilebilir olmadığını açıklayın. Sorun devam ederse, [onlardan gitmelerini istemeniz](../code-of-conduct/#davran%C4%B1%C5%9F-kural-listesini-g%C3%BC%C3%A7lendirmek) gerekebilir. [Davranış kuralları listeniz](../code-of-conduct/) bu konuşmalar için yapıcı bir rehber olabilir.
 
 ### Katkıda bulunan katılımcılarla oldukları yerde tanışın
 
@@ -137,7 +119,7 @@ CONTRIBUTING dosyanızda, yeni katılımcılara nasıl başlayacaklarını açı
 
 ![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
 
-Sorun listenizde, katkıda bulunanlar için farklı türlerlerde etiket kullanmak uygundur: örneğin, [_"ilk gelenler için"_](https://kentcdodds.com/blog/first-timers-only) , _"başlamak için"_ veya _"belge"._ [Bu etiketler](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14), projenizde yeni birisinin sorunlarınızı hızla taramasını ve başlamasını kolaylaştırır.
+Sorun listenizde, katkıda bulunanlar için farklı türlerlerde etiket kullanmak uygundur: örneğin, [*"ilk gelenler için"*](https://kentcdodds.com/blog/first-timers-only) , *"başlamak için"* veya *"belge".* [Bu etiketler](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14), projenizde yeni birisinin sorunlarınızı hızla taramasını ve başlamasını kolaylaştırır.
 
 Son olarak, insanların yolun her aşamasında kendilerini rahat hissetmelerini sağlamak için belgelerinizi kullanın.
 
@@ -149,41 +131,29 @@ Projenize ulaşan çoğu insanla asla etkileşime geçemeyeceksiniz. Biri kendin
 
 ### Projenizi paylaşın
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
-  Liderleriniz, bütün sağlıklı toplulukların yapması gerektiği gibi farklı görüşlere sahip olacak! Bununla birlikte, en yüksek sesin insanları yorarak her zaman kazanmamasını ve daha az belirgin ve azınlık seslerinin duyulmasını sağlamak için adımlar atmanız gerekir.
-  <p markdown="1" class="pquote-credit">
-— @sagesharp, ["İyi bir topluluğu ne oluşturur?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/sagesharp?s=180">   Tüm sağlıklı toplulukların yapması gerektiği gibi liderlerinizin farklı görüşleri olacaktır! Bununla birlikte, en yüksek sesin insanları yormadan her zaman kazanmamasını ve daha az belirgin ve azınlık seslerinin duyulmasını sağlamak için adımlar atmanız gerekir.   <p markdown="1" class="pquote-credit"> — @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)   </p></aside>
 
 İnsanlar sahiplik hissi duyduklarında projelere katkıda bulunmaktan heyecan duyarlar. Bu, projenizin vizyonunu devretmeniz veya istemediğiniz katkıları kabul etmeniz gerektiği anlamına gelmez. Ancak başkalarına ne kadar çok kredi verirseniz, o kadar çok sadık kalırlar.
 
 Mülkiyetinizi topluluğunuzla mümkün olduğunca paylaşmanın yollarını bulabilecek misiniz bir bakın. İşte bazı fikirler:
 
-* **Kolay (kritik olmayan) hataları kendiniz düzeltmeye karşı direnç gösterin.** Bunun yerine, bunları yeni katkıda bulunanlar bulmak için fırsatlar olarak kullanın veya katkıda bulunmak isteyen birini akıl hocası olarak kullanın. İlk başta doğal görünmeyebilir, ancak yatırımınız zamanla karşılığını verir. Örneğin, @michaeljoseph, bir katılımcıdan, sorunu kendisini düzeltmek yerine, [Cookiecutter](https://github.com/audreyr/cookiecutter) konusuna ilişkin bir PR isteği göndermesini istedi.
+- **Kolay (kritik olmayan) hataları kendiniz düzeltmeye karşı direnç gösterin.** Bunun yerine, bunları yeni katkıda bulunanlar bulmak için fırsatlar olarak kullanın veya katkıda bulunmak isteyen birini akıl hocası olarak kullanın. İlk başta doğal görünmeyebilir, ancak yatırımınız zamanla karşılığını verir. Örneğin, @michaeljoseph, bir katılımcıdan, sorunu kendisini düzeltmek yerine, [Cookiecutter](https://github.com/audreyr/cookiecutter) konusuna ilişkin bir PR isteği göndermesini istedi.
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* Projenizde, projenize katkıda bulunan herkesi listeleyen **bir CONTRIBUTORS veya AUTHORS dosyası başlatın**,[Sinatra'nın](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) yaptığı gibi.
+- Projenizde, projenize katkıda bulunan herkesi listeleyen **bir CONTRIBUTORS veya AUTHORS dosyası başlatın**,[Sinatra'nın](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) yaptığı gibi.
 
-* Oldukça büyük bir topluluğunuz varsa, **bülten gönderin veya katkıda bulunanlara teşekkür eden bir blog yazısı yazın**. Rust'ın [Rust'ta Bu Hafta](https://this-week-in-rust.org/) ve Hoodie'nin [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) bültenleri iki güzel örnek.
+- Oldukça büyük bir topluluğunuz varsa, **bülten gönderin veya katkıda bulunanlara teşekkür eden bir blog yazısı yazın**. Rust'ın [Rust'ta Bu Hafta](https://this-week-in-rust.org/) ve Hoodie'nin [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) bültenleri iki güzel örnek.
 
-* **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.
+- **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://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.
 
 Gerçek şu ki çoğu projede işlerin çoğunu yapan [yalnızca](https://peerj.com/preprints/1233.pdf) 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.
 
 Çağrıya her zaman cevap verecek birini bulamayacak olsanız da, bir mesaj bırakmak, diğer kişilerin girme şansını arttırır.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
-  \[Sizin için\] yapamadığınız şeyleri yapma yeteneğine sahip olan ve zevk alan katılımcıları işe almak en iyisidir. Kodlamayı seviyor musunuz, ancak soruları yanıtlamıyor musunuz? Topluluğunuzdaki bireylerin bunu yapmasına izin verin.
-  <p markdown="1" class="pquote-credit">
-— @gr2m, ["Toplulukları Karşılama"](http://hood.ie/blog/welcoming-communities.html)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">   \[Sizin için\] yapamadığınız şeyleri yapma yeteneğine sahip olan ve zevk alan katılımcıları işe almak en iyisidir. Kodlamayı seviyor musunuz, ancak soruları yanıtlamıyor musunuz? Topluluğunuzdaki bireylerin bunu yapmasına izin verin.   <p markdown="1" class="pquote-credit"> — @gr2m, ["Toplulukları Karşılama"](http://hood.ie/blog/welcoming-communities.html)   </p> </aside>
 
 ## Çatışmaları çözme
 
@@ -197,15 +167,9 @@ Projeniz popülerleştikçe, aldığınız kararlara daha fazla insan ilgi göst
 
 Topluluğunuz zor bir mesele ile boğuşurken, tansiyon artabilir. İnsanlar sinirlenebilir veya öfkelenebilir ve birbirlerine ya da size yönelebilirler.
 
-Bir proje sorumlusu olarak işiniz, bu durumların tırmanmasını önlemektir. Konuyla ilgili güçlü bir fikriniz olsa bile, kavgaya atılmak ve görüşlerinizi dayatmak yerine, moderatör veya kolaylaştırıcı olarak yer almaya çalışın. Birisi kaba veya tartışmacı davranıyorsa, tartışmaları medeni ve üretken kılmak için [hemen harekete](../building-community/#kötü-karakterlere-müsamaha-göstermeyin) geçin.
+Bir proje sorumlusu olarak işiniz, bu durumların tırmanmasını önlemektir. Konuyla ilgili güçlü bir fikriniz olsa bile, kavgaya atılmak ve görüşlerinizi dayatmak yerine, moderatör veya kolaylaştırıcı olarak yer almaya çalışın. Birisi kaba veya tartışmacı davranıyorsa, tartışmaları medeni ve üretken kılmak için [hemen harekete](../building-community/#k%C3%B6t%C3%BC-karakterlere-m%C3%BCsamaha-g%C3%B6stermeyin) geçin.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
-  Bir proje sorumlusu olarak, katkıda bulunanlarınıza saygılı olmak çok önemlidir. Sıklıkla söylediklerinizi kişisel olarak alırlar.
-  <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Doğru Olun veya Yolda Olun"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/kennethreitz?s=180">   Bir proje sorumlusu olarak, katılımcılarınıza saygılı olmak son derece önemlidir. Sık sık söylediklerinizi kişisel olarak alırlar.   <p markdown="1" class="pquote-credit"> — @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)   </p></aside>
 
 Diğer insanlar rehberlik için size bakar. İyi bir örnek olun. Gerektiğinde hayal kırıklığını, mutsuzluğu veya endişeyi ifade edebilirsiniz, ancak bunu sakince yapın.
 
@@ -225,13 +189,7 @@ Bazen oy vermek gerekli bir sonlandırıcıdır. Ancak, mümkün olduğu kadar,
 
 Bir uzlaşma arayışı sürecinde, topluluk üyeleri yeterince duyulduğunu hissedene kadar önemli endişelerini tartışırlar. Sadece küçük kaygılar kalırsa, topluluk ileriye doğru hareket eder. "Uzlaşma arayışı", bir topluluğun mükemmel bir cevaba ulaşamayabileceğini kabul eder. Bunun yerine, dinlemeye ve tartışmaya öncelik verir.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
-  Atom sorunları için oylama sisteminin bulunmamasının bir nedeni, Atom ekibinin her durumda bir oylama sistemini takip etmemesidir. Bazen popüler olmasa bile doğru olanı seçmemiz gerekir. (...) Yapabileceğim ve yapabileceğim tek şey ... toplumu dinlemek benim işim.
-  <p markdown="1" class="pquote-credit">
-— @lee-dohm [atomun karar alma süreci'nde](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/lee-dohm?s=180">   Atom sorunları için bir oylama sisteminin bulunmamasının bir nedeni de Atom ekibinin her durumda bir oylama sistemini takip etmemesi. Bazen popüler olmasa bile neyin doğru olduğunu düşündüğümüzü seçmek zorundayız. (...) Yapabileceğim ve yapmayı taahhüt edebileceğim şey, toplumu dinlemek benim işim.  <p markdown="1" class="pquote-credit"> — @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)   </p></aside>
 
 Aslında bir uzlaşma arama sürecini benimsemeseniz bile, bir proje sorumlusu olarak, insanların dinlediğinizi bilmesi önemlidir. Diğer insanların duyulduklarını hissetmeleri ve endişelerini çözmeyi denediğinizi görmeleri, hassas durumları dağıtmak için size bir yol verir. Ardından, kelimelerinizi eylemlerle devam ettirin.
 
@@ -245,19 +203,13 @@ Aktif olarak çözüme doğru hareket ettiği sürece tartışmayı teşvik edin
 
 Bu konuşmaların devam etmesine izin vermek yalnızca eldeki sorun için değil, topluluğunuzun sağlığı için de kötüdür. Bu tür konuşmalara izin verildiğini veya hatta teşvik edildiğini gösteren bir mesaj verir ve insanların gelecekteki sorunları dile getirmeleri veya çözmeleri konusunda cesaretlerini kırar.
 
-Siz veya başkaları tarafından yapılan her noktada kendinize, _"Bu bizi çözüme nasıl daha fazla yaklaştırır?" Diye sorun._
+Siz veya başkaları tarafından yapılan her noktada kendinize, *"Bu bizi çözüme nasıl daha fazla yaklaştırır?" Diye sorun.*
 
-Konuşma çözülmeye ulaştıysa, sohbeti yeniden odaklamak için gruba _"Bundan sonra hangi adımları atmalıyız?"_ diye sorun.
+Konuşma çözülmeye ulaştıysa, sohbeti yeniden odaklamak için gruba *"Bundan sonra hangi adımları atmalıyız?"* diye sorun.
 
 Bir konuşma açıkça bir yere gitmiyorsa, yapılacak net bir işlem yoksa veya uygun bir işlem yapılmamışsa, sorunu kapatın ve neden kapattığınızı açıklayın.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-  Bir başlığı, baskı yapmadan sonuca doğru yönlendirmek bir sanattır. İnsanları zamanlarını boşa harcamayı bırakmalarına ya da söyleyecek yapıcı bir şeyleri olmadıkça göndermemelerini istemek için uyarmak işe yaramayacaktır. (...) Bunun yerine, daha fazla ilerleme için şartlar önermek zorundasınız: insanlara bir rota verin, istediğiniz sonuçlara götürecek bir yol verin, ancak davranışınızı dikte eder gibi konuşmayın.
-  <p markdown="1" class="pquote-credit">
-— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/kfogel?s=180">   Bir başlığı saldırgan olmadan faydalı olmaya doğru yönlendirmek bir sanattır. İnsanları zamanlarını boşa harcamayı bırakmaları için uyarmak ya da söyleyecek yapıcı bir şeyleri olmadıkça mesaj göndermemelerini istemek işe yaramaz. (...) Bunun yerine, ilerleme için koşullar önermelisiniz: insanlara, istediğiniz sonuca götüren, ancak davranışları dikte ediyormuşsunuz gibi gelmeden, takip edecekleri bir yol verin.   <p markdown="1" class="pquote-credit"> — @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)   </p></aside>
 
 ### Savaşlarınızı akıllıca seçin
 

From 4a0e1a4759e6250bfdbafafdfe16cfee591631de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Sun, 12 Jul 2020 22:35:45 +0000
Subject: [PATCH 020/749] Translate legal.md via GitLocalize

---
 _articles/tr/legal.md | 73 +++++++++++++++----------------------------
 1 file changed, 25 insertions(+), 48 deletions(-)

diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index 8af1a33e7cc..e3bc4e1d626 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -52,13 +52,7 @@ Başkalarının projenizi kullanmasını, dağıtmasını, değiştirmesini veya
 
 GitHub'da yeni bir proje oluşturduğunuzda sizden [bir lisans eklemeniz istenir](https://help.github.com/articles/open-source-licensing/).
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
-  Standartlaştırılmış bir lisans, yasal eğitim almayanların yazılımla neler yapabileceklerini ve yapamadıklarını tam olarak bilmeleri için bir vekil olarak hizmet eder. Kesinlikle gerekli olmadıkça, ajans kodunun akış aşağı kullanımına engel teşkil edecek özel, değiştirilmiş veya standart olmayan terimlerden kaçının.
-  <p markdown="1" class="pquote-credit">
-- @benbalter, ["Bir devlet avukatının açık kaynaklı yazılım lisanslama hakkında bilmesi gereken her şey"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">   Standartlaştırılmış bir lisans, yasal eğitim almayanların yazılımla neler yapabileceklerini ve yapamadıklarını tam olarak bilmeleri için bir vekil olarak hizmet eder. Kesinlikle gerekli olmadıkça, ajans kodunun akış aşağı kullanımına engel teşkil edecek özel, değiştirilmiş veya standart olmayan terimlerden kaçının.   <p markdown="1" class="pquote-credit"> - @benbalter, ["Bir devlet avukatının açık kaynaklı yazılım lisanslama hakkında bilmesi gereken her şey"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)   </p> </aside>
 
 ## Projem için hangi açık kaynak lisansı uygundur?
 
@@ -72,11 +66,11 @@ Projenizin büyük olasılıkla (veya olacak) **bağımlılıkları var**. Örne
 
 Ayrıca, projenizi kullanacağını ve projenize katkıda bulunacağını umduğunuz **toplulukları** göz önünde bulundurmak isteyebilirsiniz:
 
-* **Projenizin diğer projeler tarafından bir bağımlılık olarak kullanılmasını istiyor musunuz?** İlgili topluluktaki en popüler lisansı kullanmak için muhtemelen en iyisi. Örneğin, [MIT](https://choosealicense.com/licenses/mit/), [npm kütüphaneleri](https://libraries.io/search?platforms=NPM) için en popüler lisanstır.
-* **Projenizin büyük işletmelere hitap etmesini ister misiniz?** Büyük bir işletme muhtemelen tüm katılımcılardan açık bir patent lisansı isteyecektir. Bu durumda, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) size (ve onlara) uygundur.
-* **Projenizin, yaptıkları katkıların kapalı kaynak kodlu yazılımlarda kullanılmasını istemeyenlere hitap etmesini ister misiniz?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) veya (kapalı kaynak hizmetlerine katkıda bulunmak istemiyorlarsa) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) sizin için iyidir.
+- **Projenizin diğer projeler tarafından bir bağımlılık olarak kullanılmasını istiyor musunuz?** İlgili topluluktaki en popüler lisansı kullanmak için muhtemelen en iyisi. Örneğin, [MIT](https://choosealicense.com/licenses/mit/), [npm kütüphaneleri](https://libraries.io/search?platforms=NPM) için en popüler lisanstır.
+- **Projenizin büyük işletmelere hitap etmesini ister misiniz?** Büyük bir işletme muhtemelen tüm katılımcılardan açık bir patent lisansı isteyecektir. Bu durumda, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) size (ve onlara) uygundur.
+- **Projenizin, yaptıkları katkıların kapalı kaynak kodlu yazılımlarda kullanılmasını istemeyenlere hitap etmesini ister misiniz?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) veya (kapalı kaynak hizmetlerine katkıda bulunmak istemiyorlarsa) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) sizin için iyidir.
 
-**Şirketinizin** açık kaynaklı projeleri için özel lisanslama gereksinimleri olabilir. Örneğin, izin verilen bir lisans gerektirebilir, böylece şirket projenizi şirketin kapalı kaynaklı ürününde kullanabilir. Veya şirketiniz güçlü bir copyleft lisansı ve ek bir katkı sözleşmesi (aşağıya bakınız) isteyebilir, böylece yalnızca şirketiniz ve başka hiç kimse projenizi kapalı kaynaklı yazılımında kullanamaz. Yada şirketiniz, herhangi biri belirli bir lisanslama stratejisi gerektirebilecek standartlar, sosyal sorumluluk veya şeffaflıkla ilgili belirli ihtiyaçlara sahip olabilir. [Şirketinizin hukuk departmanıyla](#şirketimin-hukuk-ekibinin-neleri-bilmesi-gerekiyor) konuşun.
+**Şirketinizin** açık kaynaklı projeleri için özel lisanslama gereksinimleri olabilir. Örneğin, izin verilen bir lisans gerektirebilir, böylece şirket projenizi şirketin kapalı kaynaklı ürününde kullanabilir. Veya şirketiniz güçlü bir copyleft lisansı ve ek bir katkı sözleşmesi (aşağıya bakınız) isteyebilir, böylece yalnızca şirketiniz ve başka hiç kimse projenizi kapalı kaynaklı yazılımında kullanamaz. Yada şirketiniz, herhangi biri belirli bir lisanslama stratejisi gerektirebilecek standartlar, sosyal sorumluluk veya şeffaflıkla ilgili belirli ihtiyaçlara sahip olabilir. [Şirketinizin hukuk departmanıyla](#%C5%9Firketimin-hukuk-ekibinin-neleri-bilmesi-gerekiyor) konuşun.
 
 GitHub'da yeni bir proje oluşturduğunuzda, size bir lisans seçme seçeneği sunulur. Yukarıda belirtilen lisanslardan birinin dahil edilmesi GitHub projenizi açık kaynak yapacaktır. Başka seçenekler görmek isterseniz, projeniz için doğru lisansı bulmak için [choosealicense.com](https://choosealicense.com) adresini ziyaret edin, proje [yazılım](https://choosealicense.com/non-software/) projesi olmasa bile.
 
@@ -102,65 +96,48 @@ Ek bir katılımcı sözleşmesi - genellikle Katılımcı Lisans Sözleşmesi (
 
 Ayrıca, bazılarının gereksiz olduğuna, anlaşılmasının zor veya haksız olduğuna inandığı "evraklar" ekleyerek (sözleşme alıcısı katkıda bulunanlardan veya halkın projenin açık kaynak lisansı aracılığıyla yaptığı haklardan daha fazla hak kazandığında), ek bir katılımcı anlaşması projenin topluluğuna dostça görülmeyebilir.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
-  Node.js için CLA'yı kaldırdık. Bunu yapmak, Node.js katılımcısı için giriş engelini azalttı ve böylece katılımcı tabanını genişletti.
-  <p markdown="1" class="pquote-credit">
-- @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.joyent.com/blog/broadening-node-js-contributions)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">   Node.js için CLA'yı kaldırdık. Bunu yapmak, Node.js katılımcısı için giriş engelini azalttı ve böylece katılımcı tabanını genişletti.   <p markdown="1" class="pquote-credit"> - @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.joyent.com/blog/broadening-node-js-contributions)   </p> </aside>
 
 Projeniz için ek bir katılımcı sözleşmesi düşünmek isteyebileceğiniz bazı durumlar şunlardır:
 
-* Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!)  tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı _işaretlemelerini_) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir.
-* Projeniz, açık bir patent hibesi (MIT gibi) içermeyen bir açık kaynak lisansı kullanıyor ve bazıları sizi hedeflemek için kullanılabilecek büyük patent portföyleri olan şirketler için çalışabilecek tüm katılımcılardan bir patent hibesine ihtiyacınız var. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)  Apache License 2.0. lisansında bulunan ve çokça kullanılan bir katılımcı sözleşmesidir.
-* Projeniz bir copyleft lisansı altında, ancak aynı zamanda projenin tescilli bir versiyonunu da dağıtmanız gerekiyor. Size telif hakkı veren veya size (ancak halka değil) izin veren bir lisans veren her katılımcıya ihtiyacınız olacaktır. [MongoDB Katılımcı Anlaşması](https://www.mongodb.com/legal/contributor-agreement) bu tür bir anlaşma örneğidir.
-* Projenizin ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmesini isteyebileceğinizi düşünüyorsunuz.
-* Projenizin kullanım ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmelerini isteyebilirsiniz.
+- Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!)  tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı *işaretlemelerini*) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir.
+- Projeniz, açık bir patent hibesi (MIT gibi) içermeyen bir açık kaynak lisansı kullanıyor ve bazıları sizi hedeflemek için kullanılabilecek büyük patent portföyleri olan şirketler için çalışabilecek tüm katılımcılardan bir patent hibesine ihtiyacınız var. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)  Apache License 2.0. lisansında bulunan ve çokça kullanılan bir katılımcı sözleşmesidir.
+- Projeniz bir copyleft lisansı altında, ancak aynı zamanda projenin tescilli bir versiyonunu da dağıtmanız gerekiyor. Size telif hakkı veren veya size (ancak halka değil) izin veren bir lisans veren her katılımcıya ihtiyacınız olacaktır. [MongoDB Katılımcı Anlaşması](https://www.mongodb.com/legal/contributor-agreement) bu tür bir anlaşma örneğidir.
+- Projenizin ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmesini isteyebileceğinizi düşünüyorsunuz.
+- Projenizin kullanım ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmelerini isteyebilirsiniz.
 
 Projeniz için ek bir katılımcı sözleşmesi kullanmanız gerekiyorsa, katılımcıların dikkatini dağıtmayı en aza indirmek için [CLA yardımcısı](https://github.com/cla-assistant/cla-assistant) gibi bir entegrasyon kullanmayı düşünün.
 
-## Şirketimin hukuk ekibinin neleri bilmesi gerekiyor?
+## Şirketimin hukuk ekibinin neyi bilmesi gerekiyor?
 
 Açık kaynaklı bir projeyi bir şirket çalışanı olarak yayınlıyorsanız, önce hukuk ekibiniz bir proje tedarik ettiğinizi bilmelidir.
 
-Daha iyi veya daha kötüsü, kişisel bir proje olsa bile, onlara bildirmeyi düşünün. Büyük olasılıkla, şirketinizle kendilerine projelerinizi kontrol etmelerini sağlayan bir "çalışan IP sözleşmesi" uygulamanız vardır, özellikle de şirketin işi ile ilgili ise veya projeyi geliştirmek için herhangi bir şirket kaynağını kullanıyorsanız. Şirketiniz size kolayca izin _vermeli_ ve belki de zaten çalışan dostu bir IP sözleşmesi veya şirket politikası ile sahip olabilir. Aksi takdirde pazarlık yapabilirsiniz (örneğin, projenizin şirketin sizin için mesleki öğrenme ve gelişim hedeflerine hizmet ettiğini açıklayın) veya daha iyi bir şirket bulana kadar projeniz üzerinde çalışmaktan kaçının.
+Daha iyi veya daha kötüsü, kişisel bir proje olsa bile, onlara bildirmeyi düşünün. Büyük olasılıkla, şirketinizle kendilerine projelerinizi kontrol etmelerini sağlayan bir "çalışan IP sözleşmesi" uygulamanız vardır, özellikle de şirketin işi ile ilgili ise veya projeyi geliştirmek için herhangi bir şirket kaynağını kullanıyorsanız. Şirketiniz size kolayca izin *vermeli* ve belki de zaten çalışan dostu bir IP sözleşmesi veya şirket politikası ile sahip olabilir. Aksi takdirde pazarlık yapabilirsiniz (örneğin, projenizin şirketin sizin için mesleki öğrenme ve gelişim hedeflerine hizmet ettiğini açıklayın) veya daha iyi bir şirket bulana kadar projeniz üzerinde çalışmaktan kaçının.
 
 **Şirketiniz için bir proje açmaya açıksanız**, kesinlikle onları bilgilendirin. Yasal ekibinizde muhtemelen, şirketin iş gereksinimlerine ve projenizin bağımlılıklarının lisanslarına uymasını sağlama konusundaki uzmanlığına dayalı olarak kullanılacak açık kaynaklı lisans (ve belki de ek katkı sözleşmesi) için politikalar zaten vardır. Olmazsa, sen ve onlar şanslısınız demektir! Hukuk ekibiniz bu olayları çözmek için sizinle birlikte çalışmaya istekli olmalıdır. Göz önünde bulundurulması gereken bazı şeyler:
 
-* **Üçüncü taraf materyali:** Projeniz başkaları tarafından yaratılan bağımlılıklara sahip mi, yoksa başkalarının kodunu içeriyor veya kullanıyor mu? Bunlar açık kaynak ise, malzemelerin açık kaynak lisanslarına uymanız gerekir. Bu, üçüncü taraf açık kaynaklı lisanslarla çalışan bir lisans seçmekle başlar (yukarıya bakın). Projeniz üçüncü taraf açık kaynak materyalini değiştirir veya dağıtırsa, yasal ekibiniz ayrıca üçüncü taraf açık kaynak lisanslarının diğer koşullarını yerine getirdiğinizi bilmek isteyecektir. Projeniz açık kaynak lisansı olmayan başkalarının kodunu kullanıyorsa, büyük olasılıkla üçüncü taraf bakımcılardan [açık kaynak lisansı eklemelerini](https://choosealicense.com/no-license/#for-users) istemeniz ve bunlardan birini alamamanız durumunda, kodlarını kullanmaktan vazgeçmeniz gerekir.
+- **Üçüncü taraf materyali:** Projeniz başkaları tarafından yaratılan bağımlılıklara sahip mi, yoksa başkalarının kodunu içeriyor veya kullanıyor mu? Bunlar açık kaynak ise, malzemelerin açık kaynak lisanslarına uymanız gerekir. Bu, üçüncü taraf açık kaynaklı lisanslarla çalışan bir lisans seçmekle başlar (yukarıya bakın). Projeniz üçüncü taraf açık kaynak materyalini değiştirir veya dağıtırsa, yasal ekibiniz ayrıca üçüncü taraf açık kaynak lisanslarının diğer koşullarını yerine getirdiğinizi bilmek isteyecektir. Projeniz açık kaynak lisansı olmayan başkalarının kodunu kullanıyorsa, büyük olasılıkla üçüncü taraf bakımcılardan [açık kaynak lisansı eklemelerini](https://choosealicense.com/no-license/#for-users) istemeniz ve bunlardan birini alamamanız durumunda, kodlarını kullanmaktan vazgeçmeniz gerekir.
 
-* **Ticari sırlar:** Projede, şirketin genel kullanıma açık olmasını istemediği bir şey olup olmadığını dikkate alın. Öyleyse, gizli tutmak istediğiniz malzemeyi çıkardıktan sonra projenizin geri kalan kısmını kaynak olarak açabilirsiniz.
+- **Ticari sırlar:** Projede, şirketin genel kullanıma açık olmasını istemediği bir şey olup olmadığını dikkate alın. Öyleyse, gizli tutmak istediğiniz malzemeyi çıkardıktan sonra projenizin geri kalan kısmını kaynak olarak açabilirsiniz.
 
-* **Patentler:** Şirketiniz, projenizin açık kaynak kodlu bir şekilde [kamuya açıklanmasını](https://en.wikipedia.org/wiki/Public_disclosure) sağlayacak bir patent başvurusu yapıyor mu? Ne yazık ki beklemeniz istenebilir (veya şirketten, uygulamanın bilgeliğini yeniden gözden geçirir). Projenize büyük patent portföyüne sahip şirketlerin çalışanlarından katkıda bulunmayı bekliyorsanız, yasal ekibiniz katkıda bulunanlardan (Apache 2.0 veya GPLv3 gibi) açık bir patent ödeneği olan bir lisans  veya ek bir katılımcı sözleşmesini ( yukarıyı bakın) kullanmanızı isteyebilir.
+- **Patentler:** Şirketiniz, projenizin açık kaynak kodlu bir şekilde [kamuya açıklanmasını](https://en.wikipedia.org/wiki/Public_disclosure) sağlayacak bir patent başvurusu yapıyor mu? Ne yazık ki beklemeniz istenebilir (veya şirketten, uygulamanın bilgeliğini yeniden gözden geçirir). Projenize büyük patent portföyüne sahip şirketlerin çalışanlarından katkıda bulunmayı bekliyorsanız, yasal ekibiniz katkıda bulunanlardan (Apache 2.0 veya GPLv3 gibi) açık bir patent ödeneği olan bir lisans  veya ek bir katılımcı sözleşmesini ( yukarıyı bakın) kullanmanızı isteyebilir.
 
-* **Ticari Markalar:** Projenizin adının [mevcut hiçbir ticari marka ile çakışmadığından](../starting-a-project/#benzersiz-isim-bulmak) emin olun. Projede kendi şirket ticari markalarınızı kullanıyorsanız, herhangi bir anlaşmazlık yaratmadığını kontrol edin. [FOSSmarks](http://fossmarks.org/) , markaları ücretsiz ve açık kaynaklı projeler bağlamında anlamak için pratik bir rehberdir.
+- **Ticari Markalar:** Projenizin adının [mevcut hiçbir ticari marka ile çakışmadığından](../starting-a-project/#benzersiz-isim-bulmak) emin olun. Projede kendi şirket ticari markalarınızı kullanıyorsanız, herhangi bir anlaşmazlık yaratmadığını kontrol edin. [FOSSmarks](http://fossmarks.org/) , markaları ücretsiz ve açık kaynaklı projeler bağlamında anlamak için pratik bir rehberdir.
 
-* **Gizlilik:** Projeniz kullanıcılar hakkında veri topluyor mu? Şirket sunucularına "bağlanıyor" mu? Hukuk ekibiniz şirket politikalarına ve dış düzenlemelere uymanıza yardımcı olabilir.
+- **Gizlilik:** Projeniz kullanıcılar hakkında veri topluyor mu? Şirket sunucularına "bağlanıyor" mu? Hukuk ekibiniz şirket politikalarına ve dış düzenlemelere uymanıza yardımcı olabilir.
 
 Şirketinizin ilk açık kaynaklı projesini yayınlıyorsanız, yukarıdakiler üstesinden gelmek için fazlasıyla yeterlidir (ancak endişelenmeyin, çoğu proje endişelendirecek bir durum oluşturmayacaktır).
 
 Daha uzun vadede hukuk ekibiniz, şirketin açık kaynaklara katılımından daha fazlasını elde etmesi ve güvende kalması için daha fazlasını yapabilir:
 
-* **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)'dır.
+- **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)'dır.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
-  Bir yama ile ilgili IP'nin serbest bırakılması, çalışanın bilgi birikimini ve itibarını arttırır. Şirketin bu çalışanın gelişimine yatırım yaptığını ve bir güçlendirme ve özerklik duygusu yarattığını göstermektedir. Tüm bu faydalar ayrıca daha yüksek moral ve daha iyi bir çalışanın kalmasına yol açmaktadır.
-  <p markdown="1" class="pquote-credit">
-- @vanl, ["Bir Model IP ve Açık Kaynak Katkı Politikası"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">   Bir yama ile ilgili IP'nin serbest bırakılması, çalışanın bilgi birikimini ve itibarını arttırır. Şirketin bu çalışanın gelişimine yatırım yaptığını ve bir güçlendirme ve özerklik duygusu yarattığını göstermektedir. Tüm bu faydalar ayrıca daha yüksek moral ve daha iyi bir çalışanın kalmasına yol açmaktadır.   <p markdown="1" class="pquote-credit"> - @vanl, ["Bir Model IP ve Açık Kaynak Katkı Politikası"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)   </p> </aside>
 
-* **Neyi yayınlama:** [(Neredeyse) her şey?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Eğer yasal ekibiniz şirketinizin açık kaynaklı stratejisini anlıyor ve yatırım yapıyorsa, çabalarınızı engellemekten ziyade en iyi şekilde yardım edebileceklerdir.
-* **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir.
+- **Neyi yayınlama:** [(Neredeyse) her şey?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Eğer yasal ekibiniz şirketinizin açık kaynaklı stratejisini anlıyor ve yatırım yapıyorsa, çabalarınızı engellemekten ziyade en iyi şekilde yardım edebileceklerdir.
+- **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir.
 
-<aside markdown="1" class="pquote">
-    Kuruluşların hem \["izin verilen" hem de "copyleft"\] kategorilerine uyan bir lisans ve uyum stratejisi olmalıdır. Bu, alt bileşenler ve bağımlılıklar dahil, kullanmakta olduğunuz açık kaynaklı yazılım için geçerli olan lisans terimlerinin kaydını tutmakla başlar.
-    <p markdown="1" class="pquote-credit">
-- Heather Meeker, ["Açık Kaynak Kodlu Yazılım: Uygunluk Esasları ve En İyi Uygulamalar"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
-    </p>
-</aside>
+<aside markdown="1" class="pquote">     Kuruluşların hem \["izin verilen" hem de "copyleft"\] kategorilerine uyan bir lisans ve uyum stratejisi olmalıdır. Bu, alt bileşenler ve bağımlılıklar dahil, kullanmakta olduğunuz açık kaynaklı yazılım için geçerli olan lisans terimlerinin kaydını tutmakla başlar.     <p markdown="1" class="pquote-credit"> - Heather Meeker, ["Açık Kaynak Kodlu Yazılım: Uygunluk Esasları ve En İyi Uygulamalar"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)     </p> </aside>
 
-* **Patentler:** Şirketiniz, üyelerin büyük açık kaynaklı projeleri kullanmalarını korumak için ortak bir savunma patenti havuzu olan [Açık Buluşma Ağı](https://www.openinventionnetwork.com/)'na katılmak veya başka bir [alternatif patent lisansını](https://www.eff.org/document/hacking-patent-system-2016) keşfetmek isteyebilir.
-* **Yönetişim:** Özellikle bir projeyi [şirket dışındaki](../leadership-and-governance/#projemi-desteklemek-i%C3%A7in-t%C3%BCzel-ki%C5%9Fili%C4%9Fe-ihtiyac%C4%B1m-var-m%C4%B1) bir {a2}tüzel kişiliğe{/a2} taşımanın ne zaman anlamlı olacağı.
+- **Patentler:** Şirketiniz, üyelerin büyük açık kaynaklı projeleri kullanmalarını korumak için ortak bir savunma patenti havuzu olan [Açık Buluşma Ağı](https://www.openinventionnetwork.com/)'na katılmak veya başka bir [alternatif patent lisansını](https://www.eff.org/document/hacking-patent-system-2016) keşfetmek isteyebilir.
+- **Yönetişim:** Özellikle bir projeyi [şirket dışındaki](../leadership-and-governance/#projemi-desteklemek-i%C3%A7in-t%C3%BCzel-ki%C5%9Fili%C4%9Fe-ihtiyac%C4%B1m-var-m%C4%B1) bir {a2}tüzel kişiliğe{/a2} taşımanın ne zaman anlamlı olacağı.

From 8d4d513f081aac8d3f974807fc2326e9b5947372 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Sun, 12 Jul 2020 22:44:38 +0000
Subject: [PATCH 021/749] Translate starting-a-project.md via GitLocalize

---
 _articles/tr/starting-a-project.md | 118 ++++++++++-------------------
 1 file changed, 41 insertions(+), 77 deletions(-)

diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index d5ef2ae8642..875d84ef818 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -26,25 +26,19 @@ Bir proje açık kaynak olduğunda, **herhangi biri herhangi bir amaç için pro
 
 Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek, benimseme engellerini azaltır. Ayrıca, kullanıcılara kapalı kaynağa göre kendi bilgisayarlarını ve bilgisayarlarında çalışan işlemleri kontrol etme imkanı da verir. Örneğin, açık kaynak yazılım kullanan bir işletme, yalnızca kapalı kaynak satıcısının ürün kararlarına güvenmek yerine, bir kişiyi yazılımda özel iyileştirmeler yapması için işe alma seçeneğine sahiptir.
 
-_Özgür yazılım_ , _açık kaynak ile_ aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. _Free_ ve  _Libre_ özgürlüğe atıfta bulunur [fiyata değil](#açık-kaynak-ücretsiz-anlamına-mı-geliyor).
+*Özgür yazılım* , *açık kaynak ile* aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. *Free* ve  *Libre* özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor).
 
 ### İnsanlar neden işlerini açık kaynak olarak sunarlar?
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
-    Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.
-  <p markdown="1" class="pquote-credit">
-— @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">     Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.   <p markdown="1" class="pquote-credit"> — @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)   </p> </aside>
 
 Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler:
 
-* **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur.
+- **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur.
 
-* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
+- **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
 
-* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
+- **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
 
 Açık kaynak sadece yazılım için değil. Veri kümelerinden kitaplara kadar her şeyi açık kaynak koduyla açabilirsiniz. Açık kaynak başka neler yapabileceğiniz hakkında fikir edinmek için [GitHub Explore](https://github.com/explore)'a göz atın.
 
@@ -68,19 +62,13 @@ Henüz ikna olmadıysanız, hedeflerinizin ne olabileceğini düşünmek için b
 
 ### Hedeflerinizi belirlemek
 
-Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, _neden bu projeye kaynak açıyorum?_
+Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, *neden bu projeye kaynak açıyorum?*
 
 Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahip farklı projeler için birden fazla hedefiniz olabilir.
 
 Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız.
 
-<aside markdown="1" class="pquote">
-   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
-   Bir noktada kullandığım özel bir UIAlertView yarattım ... ve açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca diğer geliştiricilere projelerinde nasıl kullanacaklarını açıklayan ilk belgelerimi yazdım. Muhtemelen hiç kimse onu kullanmamıştı çünkü basit bir projeydi ama katkım konusunda kendimi iyi hissediyordum.
-   <p markdown="1" class="pquote-credit">
-— @mavris, ["Kendi Kendine Öğrenen Yazılım Geliştiricileri: Açık Kaynak Neden Bizim İçin Önemli?"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
-   </p>
-</aside>
+<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/mavris?s=180">   Bir noktada kullandığım özel bir UIAlertView işlevi oluşturdum ... ve onu açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca, diğer geliştiricilere projelerinde nasıl kullanılacağını açıklayan ilk belgelerimi de yazdım. Muhtemelen hiç kimse bunu kullanmamıştı çünkü bu basit bir projeydi ama katkım hakkında kendimi iyi hissediyordum.   <p markdown="1" class="pquote-credit"> — @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)   </p></aside>
 
 Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir.
 
@@ -90,13 +78,7 @@ Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve
 
 Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın.
 
-<aside markdown="1" class="pquote">
-   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-   Projeyi açmaya başladığınızda, yönetim süreçlerinizin projenizdeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. İşletmenizde istihdam edilmeyen katılımcıları, projenin kilit noktalarına dahil etmekten korkmayın - özellikle de sık sık katkıda bulunanlarsa.
-   <p markdown="1" class="pquote-credit">
-— @captainsafia, ["Öyleyse bir açık kaynak proje açmak istiyorsun, ha?"](Https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
-   </p>
-</aside>
+<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/captainsafia?s=180">   Projeyi açık kaynak yapmaya başladığınızda, yönetim süreçlerinizin projenizin çevresindeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. Şirketinizde çalışmayan katılımcıları projenin kilit yönlerine dahil etmekten korkmayın - özellikle de sık sık katkıda bulunanlarsa.   <p markdown="1" class="pquote-credit"> — @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)   </p></aside>
 
 ### Diğer projelere katkıda bulunmak
 
@@ -112,10 +94,10 @@ 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/)
-* [Davranış kuralları](../code-of-conduct/)
+- [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/)
+- [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.
 
@@ -125,7 +107,7 @@ Projeniz GitHub'taysa, bu dosyaları önerilen dosya adlarıyla kök dizininize
 
 Açık kaynaklı lisans, başkalarının projenize yanıt vermeden kullanabileceğini, kopyalayabileceğini, değiştirebileceğini ve katkıda bulunabileceğini garanti eder. Aynı zamanda sizi kötü yasal durumlardan korur. **Açık kaynak kodlu bir proje başlatırken projenize bir lisans eklemelisiniz.**
 
-Hukiki işler eğlenceli değildir. İyi haber şu ki, mevcut bir lisansı kopyalayıp havuzunuza yapıştırabilirsiniz. Zor işinizi korumak sadece bir dakikanızı alacaktır.
+Açık kaynaklı lisans, başkalarının projenize yanıt vermeden kullanabileceğini, kopyalayabileceğini, değiştirebileceğini ve katkıda bulunabileceğini garanti eder. Aynı zamanda sizi kötü yasal durumlardan korur. **Açık kaynak kodlu bir proje başlatırken projenize bir lisans eklemelisiniz.**
 
 [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](https://choosealicense.com) de vardır.
 
@@ -133,52 +115,46 @@ GitHub'da yeni bir proje oluşturduğunuzda, size bir lisans seçme seçeneği s
 
 ![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
 
-Açık kaynak kodlu bir projeyi yönetmenin yasal yönleri hakkında başka sorularınız veya endişeleriniz varsa, size yardımcı [olacağız](../legal/) .
+Açık kaynak kodlu bir projeyi yönetmenin yasal yönleri hakkında başka sorularınız veya endişeleriniz varsa, size yardımcı olacak bir [bölümüz](../legal/) var.
 
 ### README Yazma
 
 README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar.
 
-README'nizde aşağıdaki soruları cevaplamaya çalışın:
+README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar.
 
-* Bu proje ne yapıyor?
-* Bu proje neden faydalıdır?
-* Kullanmaya nasıl başlarım?
-* İhtiyacım olursa nereden daha fazla yardım alabilirim?
+- Bu proje ne yapıyor?
+- Bu proje neden faydalıdır?
+- Kullanmaya nasıl başlarım?
+- İhtiyacım olursa nereden daha fazla yardım alabilirim?
 
 README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin.
 
-<aside markdown="1" class="pquote">
-   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
-   Daha iyi belgeler, daha fazla kullanıcı, daha az destek talebi ve daha fazla katkıda bulunan anlamına gelir. (...) Unutma ki okuyucuların sen değilsin. Tamamen farklı deneyimlerle projeye gelebilecek insanlar var.
-   <p markdown="1" class="pquote-credit">
-- @tracymakes, ["Yazdıkların okunuyor (video)")(https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
-   </p>
-</aside>
+<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/tracymakes?s=180">   Daha iyi dokümantasyon, daha fazla kullanıcı, daha az destek talebi ve daha fazla katılımcı anlamına gelir. (...) Okuyucularınızın siz olmadığını unutmayın. Tamamen farklı deneyimleri olan ve projeye gelebilecek insanlar var.   <p markdown="1" class="pquote-credit"> — @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)   </p></aside>
 
 Bazen, insanlar bir README yazmaktan kaçınırlar çünkü proje bitmemiş gibi hissederler veya katkı kabul etmek istemezler. Bunların hepsi yazmak için çok iyi nedenler.
 
 Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make a README" kılavuzunu](https://www.makeareadme.com/) veya @PurpleBooth'ın [README şablonunu](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) kullanmayı deneyin.
 
-Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler.
+Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make a README" kılavuzunu](https://www.makeareadme.com/) veya @PurpleBooth'ın [README şablonunu](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) kullanmayı deneyin.
 
 ### Katkıda bulunma rehberinizi yazmak
 
-Bir CONTRIBUTING dosyası, izleyicilerinize projenize nasıl katkıda bulunabileceklerini söyler. Örneğin, şunlarla ilgili bilgiler de ekleyebilirsiniz:
+Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler.
 
-* Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin)
-* Yeni bir özellik nasıl önerilir
-* Proje ortamı nasıl kurulur ve testler nasıl yapılır
+- Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin)
+- Yeni bir özellik nasıl önerilir
+- Proje ortamı nasıl kurulur ve testler nasıl yapılır
 
 Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır:
 
-* Aradığınız katkı türleri
-* Proje için yol haritanız veya vizyonunuz
-* Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli)
+- Aradığınız katkı türleri
+- Proje için yol haritanız veya vizyonunuz
+- Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli)
 
 Sıcak, arkadaşça bir ton kullanmak ve katkılar için özel önerilerde bulunmak (örneğin, dokümantasyon yazmak veya bir web sitesi yapmak gibi) yeni gelenlerin kendilerini memnun ve istekli hissetmelerini sağlama konusunda yardımcı olabilir.
 
-Örneğin, [Active Admin](https://github.com/activeadmin/activeadmin/) [katkıda bulunan rehberine](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) şu şekilde başlar:
+Örneğin, [Active Admin](https://github.com/activeadmin/activeadmin/) [katkıda bulunan rehberine](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) şu şekilde başlar:
 
 > Öncelikle, Active Admin’e katkıda bulunduğunuz için teşekkür ederiz. Active Admin'i harika bir araç yapan sizin gibi insanlar.
 
@@ -186,27 +162,21 @@ Projenizin ilk aşamalarında, CONTRIBUTING dosyanız basit olabilir. Hataların
 
 Zamanla, CONTRIBUTING dosyanıza sıkça sorulan diğer soruları ekleyebilirsiniz. Bu bilgileri yazmak, daha az kişinin size aynı soruları tekrar soracağı anlamına gelir.
 
-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.
+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/master/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.
+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.
 
 ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
 ### Davranış kural listesi oluşturmak
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
-  Hepimiz, muhtemelen bir şeyin neden belli bir şekilde olması gerektiğini açıklamaya çalışan bir geliştirici olarak ya da bir kullanıcı olarak... basit bir soru sormakla ... ... kötüye kullanılan şeyin yaşadığı deneyimlerimiz oldu. (...) Davranış kuralları, ekibinizin yapıcı söylemleri çok ciddiye aldığını gösteren, kolayca referans verilen ve bağlanabilir bir belge haline gelir.
-  <p markdown="1" class="pquote-credit">
-- @mlynch, ["Açık Kaynağı Daha Mutlu Bir Yer Yapma"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/mlynch?s=180">   Hepimiz, muhtemelen bir şeyin neden belirli bir şekilde olması gerektiğini açıklamaya çalışan bir proje sahibi olarak ya da bir kullanıcı olarak basit bir soru gibi sorulan istismarla karşılaştığımız deneyimler yaşadık. (...) Davranış kuralları, ekibinizin yapıcı söylemi çok ciddiye aldığını gösteren, kolayca atıfta bulunulabilir ve bağlanabilir bir belge haline gelir.  <p markdown="1" class="pquote-credit"> — @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)   </p></aside>
 
 Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır.
 
 Daha fazla bilgi için [Davranış Kuralları kılavuzumuza](../code-of-conduct/) göz atın.
 
-Katılımcıların _nasıl_ davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir.
+Katılımcıların *nasıl* davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir.
 
 Açık kaynaklı lisanslara benzer şekilde, davranış kuralları için de yeni ortaya çıkan standartlar vardır, bu yüzden kendiniz yazmak zorunda değilsiniz. [Contributor Covenant](https://contributor-covenant.org/), Kubernet, Rails ve Swift dahil olmak üzere [40.000'den fazla açık kaynaklı proje](https://www.contributor-covenant.org/adopters) tarafından kullanılan bir davranış kural listesi şablonudur. Hangi metni kullanırsanız kullanın, gerektiğinde davranış kurallarınızı uygulamak için hazırlıklı olmalısınız.
 
@@ -214,14 +184,14 @@ Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosy
 
 ## Projenizi isimlendirme ve markalama
 
-Marka, gösterişli bir logo veya çekici bir proje adından daha fazlasıdır. Projeniz hakkında nasıl konuştuğunuzla ve mesajınızla kime ulaştığınızla ilgilidir.
+Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosyayı projenizin kök dizininde tutun, böylece README'nizden kolayca bulabilir ve linkleyebilirsiniz.
 
 ### Doğru ismi seçmek
 
 Hatırlanması kolay olan ve ideal olarak projenin ne yaptığı hakkında bir fikir veren bir isim seçin. Örneğin:
 
-* [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler
-* [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur
+- [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler
+- [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur
 
 Mevcut bir projenin üzerine inşa ediyorsanız, adlarını ön ek olarak kullanmak projenizin ne yaptığını netleştirmeye yardımcı olabilir (örneğin, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` komutunu getirir).
 
@@ -235,25 +205,19 @@ Bir web sitesi, Twitter hesabı veya projenizi temsil eden diğer özellikleri i
 
 Projenizin adının herhangi bir ticari markayı ihlal etmediğinden emin olun. Bir şirket sizden projenizi kapatmanızı isteyebilir veya hatta aleyhinize yasal işlem başlatabilir. Bu riske değmez.
 
-[WIPO Global Marka Veritabanını](http://www.wipo.int/branddb/en/) ticari marka çakışmaları için kontrol edebilirsiniz. Eğer bir şirketteyseniz, bu [hukuk ekibinizin size yardımcı olabileceği](../legal/) şeylerden biridir.
+Projenizin adının herhangi bir ticari markayı ihlal etmediğinden emin olun. Bir şirket sizden projenizi kapatmanızı isteyebilir veya hatta aleyhinize yasal işlem başlatabilir. Bu riske değmez.
 
-Sonunda, proje adınız için hızlı bir Google araması yapın. İnsanlar projenizi kolayca bulabilecek mi? Arama sonuçlarında görmelerini istemediğiniz başka bir şey var mı?
+[WIPO Global Marka Veritabanını](http://www.wipo.int/branddb/en/) ticari marka çakışmaları için kontrol edebilirsiniz. Eğer bir şirketteyseniz, bu [hukuk ekibinizin size yardımcı olabileceği](../legal/) şeylerden biridir.
 
 ### Nasıl yazdığın (ve kodladığın) markanı da etkiler!
 
 Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri.
 
-Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün.
+Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-    Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.
-  <p markdown="1" class="pquote-credit">
-- [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/janl?s=180">   Posta listesindeki her konuya dahil olmaya çalıştım ve örnek davranışlar sergiliyorum, insanlara iyi davranıyorum, sorunlarını ciddiye alıyorum ve genel olarak yardımcı olmaya çalışıyorum. Bir süre sonra, insanlar sadece soru sormak için değil, aynı zamanda cevaplamaya da yardım etmek için tarzımı taklit etmeye başladılar ve bu benim çok hoşuma gitti.   <p markdown="1" class="pquote-credit"> — @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)   </p></aside>
 
-Sıcak, kapsayıcı bir dil kullanmak ("onlar" gibi, tek bir kişiye atıfta bulunsanız bile), projenizin yeni katılımcılar için memnuniyetle karşılanmasında yardımcı olabilir. Okuyucularınızın çoğu anadili İngilizce olmayabilir.
+Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün.
 
 Kelimeleri nasıl yazdığınızın ötesinde, kodlama stiliniz de projenizin markasının bir parçası olabilir. [Angular](https://angular.io/guide/styleguide) ve [jQuery](https://contribute.jquery.org/style-guide/js/) titiz kodlama stilleri ve yönergeleri olan projelere iki örnektir.
 

From bdc19fac1e6aab40e835395c3aa2f0f0417b603b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 13 Jul 2020 02:06:59 +0300
Subject: [PATCH 022/749] Fix linter bugs on tr/starting-a-project.md

---
 _articles/tr/starting-a-project.md | 44 +++++++++++++++---------------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index ca3336a531a..e26fe7045ee 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -26,7 +26,7 @@ Bir proje açık kaynak olduğunda, **herhangi biri herhangi bir amaç için pro
 
 Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek, benimseme engellerini azaltır. Ayrıca, kullanıcılara kapalı kaynağa göre kendi bilgisayarlarını ve bilgisayarlarında çalışan işlemleri kontrol etme imkanı da verir. Örneğin, açık kaynak yazılım kullanan bir işletme, yalnızca kapalı kaynak satıcısının ürün kararlarına güvenmek yerine, bir kişiyi yazılımda özel iyileştirmeler yapması için işe alma seçeneğine sahiptir.
 
-*Özgür yazılım* , *açık kaynak ile* aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. *Free* ve  *Libre* özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor).
+_Özgür yazılım_ , _açık kaynak ile_ aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. _Free_ ve  _Libre_ özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor).
 
 ### İnsanlar neden işlerini açık kaynak olarak sunarlar?
 
@@ -34,11 +34,11 @@ Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek
 
 Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler:
 
-- **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur.
+* **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur.
 
-- **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
+* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
 
-- **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
+* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
 
 Açık kaynak sadece yazılım için değil. Veri kümelerinden kitaplara kadar her şeyi açık kaynak koduyla açabilirsiniz. Açık kaynak başka neler yapabileceğiniz hakkında fikir edinmek için [GitHub Explore](https://github.com/explore)'a göz atın.
 
@@ -62,7 +62,7 @@ Henüz ikna olmadıysanız, hedeflerinizin ne olabileceğini düşünmek için b
 
 ### Hedeflerinizi belirlemek
 
-Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, *neden bu projeye kaynak açıyorum?*
+Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, _neden bu projeye kaynak açıyorum?_
 
 Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahip farklı projeler için birden fazla hedefiniz olabilir.
 
@@ -94,10 +94,10 @@ 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/)
-- [Davranış kuralları](../code-of-conduct/)
+* [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/)
+* [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.
 
@@ -123,10 +123,10 @@ README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını
 
 README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar.
 
-- Bu proje ne yapıyor?
-- Bu proje neden faydalıdır?
-- Kullanmaya nasıl başlarım?
-- İhtiyacım olursa nereden daha fazla yardım alabilirim?
+* Bu proje ne yapıyor?
+* Bu proje neden faydalıdır?
+* Kullanmaya nasıl başlarım?
+* İhtiyacım olursa nereden daha fazla yardım alabilirim?
 
 README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin.
 
@@ -142,15 +142,15 @@ Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make
 
 Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler.
 
-- Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin)
-- Yeni bir özellik nasıl önerilir
-- Proje ortamı nasıl kurulur ve testler nasıl yapılır
+* Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin)
+* Yeni bir özellik nasıl önerilir
+* Proje ortamı nasıl kurulur ve testler nasıl yapılır
 
 Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır:
 
-- Aradığınız katkı türleri
-- Proje için yol haritanız veya vizyonunuz
-- Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli)
+* Aradığınız katkı türleri
+* Proje için yol haritanız veya vizyonunuz
+* Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli)
 
 Sıcak, arkadaşça bir ton kullanmak ve katkılar için özel önerilerde bulunmak (örneğin, dokümantasyon yazmak veya bir web sitesi yapmak gibi) yeni gelenlerin kendilerini memnun ve istekli hissetmelerini sağlama konusunda yardımcı olabilir.
 
@@ -176,7 +176,7 @@ Son olarak, bir davranış kural listesi projenizin katılımcı davranışları
 
 Daha fazla bilgi için [Davranış Kuralları kılavuzumuza](../code-of-conduct/) göz atın.
 
-Katılımcıların *nasıl* davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir.
+Katılımcıların _nasıl_ davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir.
 
 Açık kaynaklı lisanslara benzer şekilde, davranış kuralları için de yeni ortaya çıkan standartlar vardır, bu yüzden kendiniz yazmak zorunda değilsiniz. [Contributor Covenant](https://contributor-covenant.org/), Kubernet, Rails ve Swift dahil olmak üzere [40.000'den fazla açık kaynaklı proje](https://www.contributor-covenant.org/adopters) tarafından kullanılan bir davranış kural listesi şablonudur. Hangi metni kullanırsanız kullanın, gerektiğinde davranış kurallarınızı uygulamak için hazırlıklı olmalısınız.
 
@@ -190,8 +190,8 @@ Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosy
 
 Marka, gösterişli bir logo veya çekici bir proje adından daha fazlasıdır. Projeniz hakkında nasıl konuştuğunuzla ve mesajınızla kime ulaştığınızla ilgilidir.
 
-- [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler
-- [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur
+* [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler
+* [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur
 
 Mevcut bir projenin üzerine inşa ediyorsanız, adlarını ön ek olarak kullanmak projenizin ne yaptığını netleştirmeye yardımcı olabilir (örneğin, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` komutunu getirir).
 

From caa2b45677bd303a008a5c046367ec9f2b67354d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 13 Jul 2020 02:10:37 +0300
Subject: [PATCH 023/749] Fix linter bugs on _articles/tr/legal.md

---
 _articles/tr/legal.md | 38 +++++++++++++++++++-------------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index e3bc4e1d626..126e15bb712 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -66,9 +66,9 @@ Projenizin büyük olasılıkla (veya olacak) **bağımlılıkları var**. Örne
 
 Ayrıca, projenizi kullanacağını ve projenize katkıda bulunacağını umduğunuz **toplulukları** göz önünde bulundurmak isteyebilirsiniz:
 
-- **Projenizin diğer projeler tarafından bir bağımlılık olarak kullanılmasını istiyor musunuz?** İlgili topluluktaki en popüler lisansı kullanmak için muhtemelen en iyisi. Örneğin, [MIT](https://choosealicense.com/licenses/mit/), [npm kütüphaneleri](https://libraries.io/search?platforms=NPM) için en popüler lisanstır.
-- **Projenizin büyük işletmelere hitap etmesini ister misiniz?** Büyük bir işletme muhtemelen tüm katılımcılardan açık bir patent lisansı isteyecektir. Bu durumda, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) size (ve onlara) uygundur.
-- **Projenizin, yaptıkları katkıların kapalı kaynak kodlu yazılımlarda kullanılmasını istemeyenlere hitap etmesini ister misiniz?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) veya (kapalı kaynak hizmetlerine katkıda bulunmak istemiyorlarsa) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) sizin için iyidir.
+* **Projenizin diğer projeler tarafından bir bağımlılık olarak kullanılmasını istiyor musunuz?** İlgili topluluktaki en popüler lisansı kullanmak için muhtemelen en iyisi. Örneğin, [MIT](https://choosealicense.com/licenses/mit/), [npm kütüphaneleri](https://libraries.io/search?platforms=NPM) için en popüler lisanstır.
+* **Projenizin büyük işletmelere hitap etmesini ister misiniz?** Büyük bir işletme muhtemelen tüm katılımcılardan açık bir patent lisansı isteyecektir. Bu durumda, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) size (ve onlara) uygundur.
+* **Projenizin, yaptıkları katkıların kapalı kaynak kodlu yazılımlarda kullanılmasını istemeyenlere hitap etmesini ister misiniz?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) veya (kapalı kaynak hizmetlerine katkıda bulunmak istemiyorlarsa) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) sizin için iyidir.
 
 **Şirketinizin** açık kaynaklı projeleri için özel lisanslama gereksinimleri olabilir. Örneğin, izin verilen bir lisans gerektirebilir, böylece şirket projenizi şirketin kapalı kaynaklı ürününde kullanabilir. Veya şirketiniz güçlü bir copyleft lisansı ve ek bir katkı sözleşmesi (aşağıya bakınız) isteyebilir, böylece yalnızca şirketiniz ve başka hiç kimse projenizi kapalı kaynaklı yazılımında kullanamaz. Yada şirketiniz, herhangi biri belirli bir lisanslama stratejisi gerektirebilecek standartlar, sosyal sorumluluk veya şeffaflıkla ilgili belirli ihtiyaçlara sahip olabilir. [Şirketinizin hukuk departmanıyla](#%C5%9Firketimin-hukuk-ekibinin-neleri-bilmesi-gerekiyor) konuşun.
 
@@ -100,11 +100,11 @@ Ayrıca, bazılarının gereksiz olduğuna, anlaşılmasının zor veya haksız
 
 Projeniz için ek bir katılımcı sözleşmesi düşünmek isteyebileceğiniz bazı durumlar şunlardır:
 
-- Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!)  tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı *işaretlemelerini*) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir.
-- Projeniz, açık bir patent hibesi (MIT gibi) içermeyen bir açık kaynak lisansı kullanıyor ve bazıları sizi hedeflemek için kullanılabilecek büyük patent portföyleri olan şirketler için çalışabilecek tüm katılımcılardan bir patent hibesine ihtiyacınız var. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)  Apache License 2.0. lisansında bulunan ve çokça kullanılan bir katılımcı sözleşmesidir.
-- Projeniz bir copyleft lisansı altında, ancak aynı zamanda projenin tescilli bir versiyonunu da dağıtmanız gerekiyor. Size telif hakkı veren veya size (ancak halka değil) izin veren bir lisans veren her katılımcıya ihtiyacınız olacaktır. [MongoDB Katılımcı Anlaşması](https://www.mongodb.com/legal/contributor-agreement) bu tür bir anlaşma örneğidir.
-- Projenizin ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmesini isteyebileceğinizi düşünüyorsunuz.
-- Projenizin kullanım ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmelerini isteyebilirsiniz.
+* Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!)  tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı *işaretlemelerini*) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir.
+* Projeniz, açık bir patent hibesi (MIT gibi) içermeyen bir açık kaynak lisansı kullanıyor ve bazıları sizi hedeflemek için kullanılabilecek büyük patent portföyleri olan şirketler için çalışabilecek tüm katılımcılardan bir patent hibesine ihtiyacınız var. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)  Apache License 2.0. lisansında bulunan ve çokça kullanılan bir katılımcı sözleşmesidir.
+* Projeniz bir copyleft lisansı altında, ancak aynı zamanda projenin tescilli bir versiyonunu da dağıtmanız gerekiyor. Size telif hakkı veren veya size (ancak halka değil) izin veren bir lisans veren her katılımcıya ihtiyacınız olacaktır. [MongoDB Katılımcı Anlaşması](https://www.mongodb.com/legal/contributor-agreement) bu tür bir anlaşma örneğidir.
+* Projenizin ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmesini isteyebileceğinizi düşünüyorsunuz.
+* Projenizin kullanım ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmelerini isteyebilirsiniz.
 
 Projeniz için ek bir katılımcı sözleşmesi kullanmanız gerekiyorsa, katılımcıların dikkatini dağıtmayı en aza indirmek için [CLA yardımcısı](https://github.com/cla-assistant/cla-assistant) gibi bir entegrasyon kullanmayı düşünün.
 
@@ -112,32 +112,32 @@ Projeniz için ek bir katılımcı sözleşmesi kullanmanız gerekiyorsa, katıl
 
 Açık kaynaklı bir projeyi bir şirket çalışanı olarak yayınlıyorsanız, önce hukuk ekibiniz bir proje tedarik ettiğinizi bilmelidir.
 
-Daha iyi veya daha kötüsü, kişisel bir proje olsa bile, onlara bildirmeyi düşünün. Büyük olasılıkla, şirketinizle kendilerine projelerinizi kontrol etmelerini sağlayan bir "çalışan IP sözleşmesi" uygulamanız vardır, özellikle de şirketin işi ile ilgili ise veya projeyi geliştirmek için herhangi bir şirket kaynağını kullanıyorsanız. Şirketiniz size kolayca izin *vermeli* ve belki de zaten çalışan dostu bir IP sözleşmesi veya şirket politikası ile sahip olabilir. Aksi takdirde pazarlık yapabilirsiniz (örneğin, projenizin şirketin sizin için mesleki öğrenme ve gelişim hedeflerine hizmet ettiğini açıklayın) veya daha iyi bir şirket bulana kadar projeniz üzerinde çalışmaktan kaçının.
+Daha iyi veya daha kötüsü, kişisel bir proje olsa bile, onlara bildirmeyi düşünün. Büyük olasılıkla, şirketinizle kendilerine projelerinizi kontrol etmelerini sağlayan bir "çalışan IP sözleşmesi" uygulamanız vardır, özellikle de şirketin işi ile ilgili ise veya projeyi geliştirmek için herhangi bir şirket kaynağını kullanıyorsanız. Şirketiniz size kolayca izin _vermeli_ ve belki de zaten çalışan dostu bir IP sözleşmesi veya şirket politikası ile sahip olabilir. Aksi takdirde pazarlık yapabilirsiniz (örneğin, projenizin şirketin sizin için mesleki öğrenme ve gelişim hedeflerine hizmet ettiğini açıklayın) veya daha iyi bir şirket bulana kadar projeniz üzerinde çalışmaktan kaçının.
 
 **Şirketiniz için bir proje açmaya açıksanız**, kesinlikle onları bilgilendirin. Yasal ekibinizde muhtemelen, şirketin iş gereksinimlerine ve projenizin bağımlılıklarının lisanslarına uymasını sağlama konusundaki uzmanlığına dayalı olarak kullanılacak açık kaynaklı lisans (ve belki de ek katkı sözleşmesi) için politikalar zaten vardır. Olmazsa, sen ve onlar şanslısınız demektir! Hukuk ekibiniz bu olayları çözmek için sizinle birlikte çalışmaya istekli olmalıdır. Göz önünde bulundurulması gereken bazı şeyler:
 
-- **Üçüncü taraf materyali:** Projeniz başkaları tarafından yaratılan bağımlılıklara sahip mi, yoksa başkalarının kodunu içeriyor veya kullanıyor mu? Bunlar açık kaynak ise, malzemelerin açık kaynak lisanslarına uymanız gerekir. Bu, üçüncü taraf açık kaynaklı lisanslarla çalışan bir lisans seçmekle başlar (yukarıya bakın). Projeniz üçüncü taraf açık kaynak materyalini değiştirir veya dağıtırsa, yasal ekibiniz ayrıca üçüncü taraf açık kaynak lisanslarının diğer koşullarını yerine getirdiğinizi bilmek isteyecektir. Projeniz açık kaynak lisansı olmayan başkalarının kodunu kullanıyorsa, büyük olasılıkla üçüncü taraf bakımcılardan [açık kaynak lisansı eklemelerini](https://choosealicense.com/no-license/#for-users) istemeniz ve bunlardan birini alamamanız durumunda, kodlarını kullanmaktan vazgeçmeniz gerekir.
+* **Üçüncü taraf materyali:** Projeniz başkaları tarafından yaratılan bağımlılıklara sahip mi, yoksa başkalarının kodunu içeriyor veya kullanıyor mu? Bunlar açık kaynak ise, malzemelerin açık kaynak lisanslarına uymanız gerekir. Bu, üçüncü taraf açık kaynaklı lisanslarla çalışan bir lisans seçmekle başlar (yukarıya bakın). Projeniz üçüncü taraf açık kaynak materyalini değiştirir veya dağıtırsa, yasal ekibiniz ayrıca üçüncü taraf açık kaynak lisanslarının diğer koşullarını yerine getirdiğinizi bilmek isteyecektir. Projeniz açık kaynak lisansı olmayan başkalarının kodunu kullanıyorsa, büyük olasılıkla üçüncü taraf bakımcılardan [açık kaynak lisansı eklemelerini](https://choosealicense.com/no-license/#for-users) istemeniz ve bunlardan birini alamamanız durumunda, kodlarını kullanmaktan vazgeçmeniz gerekir.
 
-- **Ticari sırlar:** Projede, şirketin genel kullanıma açık olmasını istemediği bir şey olup olmadığını dikkate alın. Öyleyse, gizli tutmak istediğiniz malzemeyi çıkardıktan sonra projenizin geri kalan kısmını kaynak olarak açabilirsiniz.
+* **Ticari sırlar:** Projede, şirketin genel kullanıma açık olmasını istemediği bir şey olup olmadığını dikkate alın. Öyleyse, gizli tutmak istediğiniz malzemeyi çıkardıktan sonra projenizin geri kalan kısmını kaynak olarak açabilirsiniz.
 
-- **Patentler:** Şirketiniz, projenizin açık kaynak kodlu bir şekilde [kamuya açıklanmasını](https://en.wikipedia.org/wiki/Public_disclosure) sağlayacak bir patent başvurusu yapıyor mu? Ne yazık ki beklemeniz istenebilir (veya şirketten, uygulamanın bilgeliğini yeniden gözden geçirir). Projenize büyük patent portföyüne sahip şirketlerin çalışanlarından katkıda bulunmayı bekliyorsanız, yasal ekibiniz katkıda bulunanlardan (Apache 2.0 veya GPLv3 gibi) açık bir patent ödeneği olan bir lisans  veya ek bir katılımcı sözleşmesini ( yukarıyı bakın) kullanmanızı isteyebilir.
+* **Patentler:** Şirketiniz, projenizin açık kaynak kodlu bir şekilde [kamuya açıklanmasını](https://en.wikipedia.org/wiki/Public_disclosure) sağlayacak bir patent başvurusu yapıyor mu? Ne yazık ki beklemeniz istenebilir (veya şirketten, uygulamanın bilgeliğini yeniden gözden geçirir). Projenize büyük patent portföyüne sahip şirketlerin çalışanlarından katkıda bulunmayı bekliyorsanız, yasal ekibiniz katkıda bulunanlardan (Apache 2.0 veya GPLv3 gibi) açık bir patent ödeneği olan bir lisans  veya ek bir katılımcı sözleşmesini ( yukarıyı bakın) kullanmanızı isteyebilir.
 
-- **Ticari Markalar:** Projenizin adının [mevcut hiçbir ticari marka ile çakışmadığından](../starting-a-project/#benzersiz-isim-bulmak) emin olun. Projede kendi şirket ticari markalarınızı kullanıyorsanız, herhangi bir anlaşmazlık yaratmadığını kontrol edin. [FOSSmarks](http://fossmarks.org/) , markaları ücretsiz ve açık kaynaklı projeler bağlamında anlamak için pratik bir rehberdir.
+* **Ticari Markalar:** Projenizin adının [mevcut hiçbir ticari marka ile çakışmadığından](../starting-a-project/#benzersiz-isim-bulmak) emin olun. Projede kendi şirket ticari markalarınızı kullanıyorsanız, herhangi bir anlaşmazlık yaratmadığını kontrol edin. [FOSSmarks](http://fossmarks.org/) , markaları ücretsiz ve açık kaynaklı projeler bağlamında anlamak için pratik bir rehberdir.
 
-- **Gizlilik:** Projeniz kullanıcılar hakkında veri topluyor mu? Şirket sunucularına "bağlanıyor" mu? Hukuk ekibiniz şirket politikalarına ve dış düzenlemelere uymanıza yardımcı olabilir.
+* **Gizlilik:** Projeniz kullanıcılar hakkında veri topluyor mu? Şirket sunucularına "bağlanıyor" mu? Hukuk ekibiniz şirket politikalarına ve dış düzenlemelere uymanıza yardımcı olabilir.
 
 Şirketinizin ilk açık kaynaklı projesini yayınlıyorsanız, yukarıdakiler üstesinden gelmek için fazlasıyla yeterlidir (ancak endişelenmeyin, çoğu proje endişelendirecek bir durum oluşturmayacaktır).
 
 Daha uzun vadede hukuk ekibiniz, şirketin açık kaynaklara katılımından daha fazlasını elde etmesi ve güvende kalması için daha fazlasını yapabilir:
 
-- **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)'dır.
+* **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)'dır.
 
 <aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">   Bir yama ile ilgili IP'nin serbest bırakılması, çalışanın bilgi birikimini ve itibarını arttırır. Şirketin bu çalışanın gelişimine yatırım yaptığını ve bir güçlendirme ve özerklik duygusu yarattığını göstermektedir. Tüm bu faydalar ayrıca daha yüksek moral ve daha iyi bir çalışanın kalmasına yol açmaktadır.   <p markdown="1" class="pquote-credit"> - @vanl, ["Bir Model IP ve Açık Kaynak Katkı Politikası"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)   </p> </aside>
 
-- **Neyi yayınlama:** [(Neredeyse) her şey?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Eğer yasal ekibiniz şirketinizin açık kaynaklı stratejisini anlıyor ve yatırım yapıyorsa, çabalarınızı engellemekten ziyade en iyi şekilde yardım edebileceklerdir.
-- **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir.
+* **Neyi yayınlama:** [(Neredeyse) her şey?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Eğer yasal ekibiniz şirketinizin açık kaynaklı stratejisini anlıyor ve yatırım yapıyorsa, çabalarınızı engellemekten ziyade en iyi şekilde yardım edebileceklerdir.
+* **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir.
 
 <aside markdown="1" class="pquote">     Kuruluşların hem \["izin verilen" hem de "copyleft"\] kategorilerine uyan bir lisans ve uyum stratejisi olmalıdır. Bu, alt bileşenler ve bağımlılıklar dahil, kullanmakta olduğunuz açık kaynaklı yazılım için geçerli olan lisans terimlerinin kaydını tutmakla başlar.     <p markdown="1" class="pquote-credit"> - Heather Meeker, ["Açık Kaynak Kodlu Yazılım: Uygunluk Esasları ve En İyi Uygulamalar"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)     </p> </aside>
 
-- **Patentler:** Şirketiniz, üyelerin büyük açık kaynaklı projeleri kullanmalarını korumak için ortak bir savunma patenti havuzu olan [Açık Buluşma Ağı](https://www.openinventionnetwork.com/)'na katılmak veya başka bir [alternatif patent lisansını](https://www.eff.org/document/hacking-patent-system-2016) keşfetmek isteyebilir.
-- **Yönetişim:** Özellikle bir projeyi [şirket dışındaki](../leadership-and-governance/#projemi-desteklemek-i%C3%A7in-t%C3%BCzel-ki%C5%9Fili%C4%9Fe-ihtiyac%C4%B1m-var-m%C4%B1) bir {a2}tüzel kişiliğe{/a2} taşımanın ne zaman anlamlı olacağı.
+* **Patentler:** Şirketiniz, üyelerin büyük açık kaynaklı projeleri kullanmalarını korumak için ortak bir savunma patenti havuzu olan [Açık Buluşma Ağı](https://www.openinventionnetwork.com/)'na katılmak veya başka bir [alternatif patent lisansını](https://www.eff.org/document/hacking-patent-system-2016) keşfetmek isteyebilir.
+* **Yönetişim:** Özellikle bir projeyi [şirket dışındaki](../leadership-and-governance/#projemi-desteklemek-i%C3%A7in-t%C3%BCzel-ki%C5%9Fili%C4%9Fe-ihtiyac%C4%B1m-var-m%C4%B1) bir {a2}tüzel kişiliğe{/a2} taşımanın ne zaman anlamlı olacağı.

From 32e35b8f828874addf18573ee729c79938e18339 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 13 Jul 2020 02:13:23 +0300
Subject: [PATCH 024/749] Fix linter bugs on tr/building-community.md

---
 _articles/tr/building-community.md | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md
index 361c73d3f2f..8cb14c52d53 100644
--- a/_articles/tr/building-community.md
+++ b/_articles/tr/building-community.md
@@ -30,16 +30,16 @@ Topluluğunuzu oluştururken huninin tepesindeki birinin (potansiyel bir kullan
 
 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.
+* **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.
 
 [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.
 
-- **Yeni birileri projenize geldiğinde, ilgilendikleri için teşekkür edin!** Birinin geri gelmek istememesi için yalnızca bir olumsuz deneyim yeterlidir.
-- **Hızlı cevap verin.** Sorunlarına bir ay boyunca cevap vermezseniz, büyük olasılıkla projenizi çoktan unutmuş olurlar.
-- **Kabul edeceğiniz katkı türleri konusunda açık fikirli olun.** Katkıda bulunan birçok kişi bir hata raporu veya küçük bir düzeltme ile başlar. Bir projeye [katkıda bulunmak için birçok yol](../how-to-contribute/#katk%C4%B1da-bulunmak-ne-demektir) var. İnsanların nasıl istiyorlarsa öyle yardım etmelerine izin verin.
-- **Katılmadığınız bir katkı varsa** , fikirleri için onlara teşekkür edin ve [niçin](../best-practices/#hay%C4%B1r-demeyi-%C3%B6%C4%9Frenme) projenin kapsamına uymadığını açıklayın, varsa ilgili dokümantasyondan alıntı yapın.
+* **Yeni birileri projenize geldiğinde, ilgilendikleri için teşekkür edin!** Birinin geri gelmek istememesi için yalnızca bir olumsuz deneyim yeterlidir.
+* **Hızlı cevap verin.** Sorunlarına bir ay boyunca cevap vermezseniz, büyük olasılıkla projenizi çoktan unutmuş olurlar.
+* **Kabul edeceğiniz katkı türleri konusunda açık fikirli olun.** Katkıda bulunan birçok kişi bir hata raporu veya küçük bir düzeltme ile başlar. Bir projeye [katkıda bulunmak için birçok yol](../how-to-contribute/#katk%C4%B1da-bulunmak-ne-demektir) var. İnsanların nasıl istiyorlarsa öyle yardım etmelerine izin verin.
+* **Katılmadığınız bir katkı varsa** , fikirleri için onlara teşekkür edin ve [niçin](../best-practices/#hay%C4%B1r-demeyi-%C3%B6%C4%9Frenme) projenin kapsamına uymadığını açıklayın, varsa ilgili dokümantasyondan alıntı yapın.
 
 <aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/mikeal?s=180">   Bazıları için açık kaynağa katkıda bulunmak diğerlerinden daha kolaydır. Doğru bir şey yapmamak ya da sadece uyum sağlamaktan bağırmaktan korkmak çok fazla. (...) Katkıda bulunanlara çok düşük teknik yeterliliğe (dokümantasyon, web içeriği işaretleme, vb.) Katkıda bulunacak bir yer vererek bu kaygılar.  <p markdown="1" class="pquote-credit"> — @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)   </p></aside>
 
@@ -119,7 +119,7 @@ CONTRIBUTING dosyanızda, yeni katılımcılara nasıl başlayacaklarını açı
 
 ![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
 
-Sorun listenizde, katkıda bulunanlar için farklı türlerlerde etiket kullanmak uygundur: örneğin, [*"ilk gelenler için"*](https://kentcdodds.com/blog/first-timers-only) , *"başlamak için"* veya *"belge".* [Bu etiketler](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14), projenizde yeni birisinin sorunlarınızı hızla taramasını ve başlamasını kolaylaştırır.
+Sorun listenizde, katkıda bulunanlar için farklı türlerlerde etiket kullanmak uygundur: örneğin, [_"ilk gelenler için"_](https://kentcdodds.com/blog/first-timers-only) , _"başlamak için"_ veya _"belge"._ [Bu etiketler](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14), projenizde yeni birisinin sorunlarınızı hızla taramasını ve başlamasını kolaylaştırır.
 
 Son olarak, insanların yolun her aşamasında kendilerini rahat hissetmelerini sağlamak için belgelerinizi kullanın.
 
@@ -137,17 +137,17 @@ Projenize ulaşan çoğu insanla asla etkileşime geçemeyeceksiniz. Biri kendin
 
 Mülkiyetinizi topluluğunuzla mümkün olduğunca paylaşmanın yollarını bulabilecek misiniz bir bakın. İşte bazı fikirler:
 
-- **Kolay (kritik olmayan) hataları kendiniz düzeltmeye karşı direnç gösterin.** Bunun yerine, bunları yeni katkıda bulunanlar bulmak için fırsatlar olarak kullanın veya katkıda bulunmak isteyen birini akıl hocası olarak kullanın. İlk başta doğal görünmeyebilir, ancak yatırımınız zamanla karşılığını verir. Örneğin, @michaeljoseph, bir katılımcıdan, sorunu kendisini düzeltmek yerine, [Cookiecutter](https://github.com/audreyr/cookiecutter) konusuna ilişkin bir PR isteği göndermesini istedi.
+* **Kolay (kritik olmayan) hataları kendiniz düzeltmeye karşı direnç gösterin.** Bunun yerine, bunları yeni katkıda bulunanlar bulmak için fırsatlar olarak kullanın veya katkıda bulunmak isteyen birini akıl hocası olarak kullanın. İlk başta doğal görünmeyebilir, ancak yatırımınız zamanla karşılığını verir. Örneğin, @michaeljoseph, bir katılımcıdan, sorunu kendisini düzeltmek yerine, [Cookiecutter](https://github.com/audreyr/cookiecutter) konusuna ilişkin bir PR isteği göndermesini istedi.
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-- Projenizde, projenize katkıda bulunan herkesi listeleyen **bir CONTRIBUTORS veya AUTHORS dosyası başlatın**,[Sinatra'nın](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) yaptığı gibi.
+* Projenizde, projenize katkıda bulunan herkesi listeleyen **bir CONTRIBUTORS veya AUTHORS dosyası başlatın**,[Sinatra'nın](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) yaptığı gibi.
 
-- Oldukça büyük bir topluluğunuz varsa, **bülten gönderin veya katkıda bulunanlara teşekkür eden bir blog yazısı yazın**. Rust'ın [Rust'ta Bu Hafta](https://this-week-in-rust.org/) ve Hoodie'nin [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) bültenleri iki güzel örnek.
+* Oldukça büyük bir topluluğunuz varsa, **bülten gönderin veya katkıda bulunanlara teşekkür eden bir blog yazısı yazın**. Rust'ın [Rust'ta Bu Hafta](https://this-week-in-rust.org/) ve Hoodie'nin [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) bültenleri iki güzel örnek.
 
-- **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.
+* **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://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.
 
 Gerçek şu ki çoğu projede işlerin çoğunu yapan [yalnızca](https://peerj.com/preprints/1233.pdf) 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.
 
@@ -203,9 +203,9 @@ Aktif olarak çözüme doğru hareket ettiği sürece tartışmayı teşvik edin
 
 Bu konuşmaların devam etmesine izin vermek yalnızca eldeki sorun için değil, topluluğunuzun sağlığı için de kötüdür. Bu tür konuşmalara izin verildiğini veya hatta teşvik edildiğini gösteren bir mesaj verir ve insanların gelecekteki sorunları dile getirmeleri veya çözmeleri konusunda cesaretlerini kırar.
 
-Siz veya başkaları tarafından yapılan her noktada kendinize, *"Bu bizi çözüme nasıl daha fazla yaklaştırır?" Diye sorun.*
+Siz veya başkaları tarafından yapılan her noktada kendinize, _"Bu bizi çözüme nasıl daha fazla yaklaştırır?" Diye sorun._
 
-Konuşma çözülmeye ulaştıysa, sohbeti yeniden odaklamak için gruba *"Bundan sonra hangi adımları atmalıyız?"* diye sorun.
+Konuşma çözülmeye ulaştıysa, sohbeti yeniden odaklamak için gruba _"Bundan sonra hangi adımları atmalıyız?"_ diye sorun.
 
 Bir konuşma açıkça bir yere gitmiyorsa, yapılacak net bir işlem yoksa veya uygun bir işlem yapılmamışsa, sorunu kapatın ve neden kapattığınızı açıklayın.
 

From dc81c9af16ccf240a29118e0367553165c069b23 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 13 Jul 2020 02:20:48 +0300
Subject: [PATCH 025/749] Fix linter on _articles/tr/legal.md

---
 _articles/tr/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index 126e15bb712..b1251c808de 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -100,7 +100,7 @@ Ayrıca, bazılarının gereksiz olduğuna, anlaşılmasının zor veya haksız
 
 Projeniz için ek bir katılımcı sözleşmesi düşünmek isteyebileceğiniz bazı durumlar şunlardır:
 
-* Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!)  tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı *işaretlemelerini*) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir.
+* Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!)  tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı _işaretlemelerini_) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir.
 * Projeniz, açık bir patent hibesi (MIT gibi) içermeyen bir açık kaynak lisansı kullanıyor ve bazıları sizi hedeflemek için kullanılabilecek büyük patent portföyleri olan şirketler için çalışabilecek tüm katılımcılardan bir patent hibesine ihtiyacınız var. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)  Apache License 2.0. lisansında bulunan ve çokça kullanılan bir katılımcı sözleşmesidir.
 * Projeniz bir copyleft lisansı altında, ancak aynı zamanda projenin tescilli bir versiyonunu da dağıtmanız gerekiyor. Size telif hakkı veren veya size (ancak halka değil) izin veren bir lisans veren her katılımcıya ihtiyacınız olacaktır. [MongoDB Katılımcı Anlaşması](https://www.mongodb.com/legal/contributor-agreement) bu tür bir anlaşma örneğidir.
 * Projenizin ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmesini isteyebileceğinizi düşünüyorsunuz.

From 42cab801d4c1d343ea2deb377288ee3049b88b05 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 13 Jul 2020 02:31:22 +0300
Subject: [PATCH 026/749] Minor

---
 _articles/tr/best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md
index 1c9c394d7e9..100a06a1bdc 100644
--- a/_articles/tr/best-practices.md
+++ b/_articles/tr/best-practices.md
@@ -176,7 +176,7 @@ Yeni katılımcılar kazanmanın bir yolu da [yeni katılanlar için kolay çöz
 
 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.
 
-Başkalarını yüreklendirmek ve [projenin sahipliğini paylaşmak](../building-community/#projenizi-payla%C5%9F%C4%B1n) kendi iş yükünüzü azaltır. @lmccart kendi projesinde bunu nasıl yaptığını aşağıdaki gibi anlatıyor, [p5.js](https://github.com/processing/p5.js).
+Başkalarını yüreklendirmek ve [projenin sahipliğini paylaşmak](../building-community/#projenizi-paylaşın) kendi iş yükünüzü azaltır. @lmccart kendi projesinde bunu nasıl yaptığını aşağıdaki gibi anlatıyor, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">

From 8346cee19aa498d441c66bb76983ca387f0bd5a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 13 Jul 2020 02:53:27 +0300
Subject: [PATCH 027/749] Fix linter bugs

---
 _articles/tr/building-community.md | 64 +++++++++++++++++---
 _articles/tr/starting-a-project.md | 96 ++++++++++++++++++++++++------
 2 files changed, 134 insertions(+), 26 deletions(-)

diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md
index 8cb14c52d53..1b7e8f00854 100644
--- a/_articles/tr/building-community.md
+++ b/_articles/tr/building-community.md
@@ -41,7 +41,13 @@ Belgelerinizle başlayın:
 * **Kabul edeceğiniz katkı türleri konusunda açık fikirli olun.** Katkıda bulunan birçok kişi bir hata raporu veya küçük bir düzeltme ile başlar. Bir projeye [katkıda bulunmak için birçok yol](../how-to-contribute/#katk%C4%B1da-bulunmak-ne-demektir) var. İnsanların nasıl istiyorlarsa öyle yardım etmelerine izin verin.
 * **Katılmadığınız bir katkı varsa** , fikirleri için onlara teşekkür edin ve [niçin](../best-practices/#hay%C4%B1r-demeyi-%C3%B6%C4%9Frenme) projenin kapsamına uymadığını açıklayın, varsa ilgili dokümantasyondan alıntı yapın.
 
-<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/mikeal?s=180">   Bazıları için açık kaynağa katkıda bulunmak diğerlerinden daha kolaydır. Doğru bir şey yapmamak ya da sadece uyum sağlamaktan bağırmaktan korkmak çok fazla. (...) Katkıda bulunanlara çok düşük teknik yeterliliğe (dokümantasyon, web içeriği işaretleme, vb.) Katkıda bulunacak bir yer vererek bu kaygılar.  <p markdown="1" class="pquote-credit"> — @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)   </p></aside>
+<aside markdown="1" class="pquote">
+    <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/mikeal?s=180">
+    Bazıları için açık kaynağa katkıda bulunmak diğerlerinden daha kolaydır. Doğru bir şey yapmamak ya da sadece uyum sağlamaktan bağırmaktan korkmak çok fazla. (...) Katkıda bulunanlara çok düşük teknik yeterliliğe (dokümantasyon, web içeriği işaretleme, vb.) Katkıda bulunacak bir yer vererek bu kaygılar.
+    <p markdown="1" class="pquote-credit">
+— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+   </p>
+</aside>
 
 Açık kaynak katkıda bulunanların çoğunluğu "geçici katkı yapanlardır": yani bir projeye yalnızca ara sıra katkıda bulunan insanlar. Sıradan bir katılımcının projenizi hızlandırmak için tam zamanı olmayacağı için işiniz onların katkıda bulunmalarını kolaylaştırmaktır.
 
@@ -49,7 +55,13 @@ Diğer katılımcıları teşvik etmek kendinize yapılan bir yatırımdır. En
 
 ### Her şeyi belgeleyin
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">   Hiç kimseyi tanımadığınız (teknoloji) bir etkinliğe katıldınız mı, ama diğerleri gruplarda durup eski arkadaşlar gibi sohbet ettiler mi? (...) Şimdi açık kaynaklı bir projeye katkıda bulunmak istediğinizi hayal edin, ancak bunun neden veya nasıl olduğunu görmüyorsunuz.   <p markdown="1" class="pquote-credit"> — @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)   </p> </aside>
+<aside markdown="1" class="pquote">
+    <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+    Hiç kimseyi tanımadığınız (teknoloji) bir etkinliğe katıldınız mı, ama diğerleri gruplarda durup eski arkadaşlar gibi sohbet ettiler mi? (...) Şimdi açık kaynaklı bir projeye katkıda bulunmak istediğinizi hayal edin, ancak bunun neden veya nasıl olduğunu görmüyorsunuz.
+    <p markdown="1" class="pquote-credit">
+— @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+   </p>
+</aside>
 
 Yeni bir projeye başladığınızda, çalışmanızı özel tutmak doğal olabilir. Ancak, açık kaynaklı projeler, sürecinizi halka açık olarak belgelemeniz durumunda gelişir.
 
@@ -105,7 +117,13 @@ Herhangi bir popüler proje kaçınılmaz olarak topluluğunuza yardım etmek ye
 
 Bu tür insanlara karşı sıfır tolerans politikası benimsemek için elinizden geleni yapın. Denetlenmezse, negatif insanlar topluluğunuzdaki diğer insanları rahatsız eder. Hatta ayrılmalarına sebep olabilirler.
 
-<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/okdistribute?s=180">   Gerçek şu ki, destekleyici bir topluluğa sahip olmak çok önemlidir. Meslektaşlarımın, arkadaş canlısı yabancıların ve konuşkan IRC kanallarının yardımı olmadan bu işi asla yapamazdım. (...) Daha azına razı olma. Pisliklere razı olma.  <p markdown="1" class="pquote-credit"> — @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)   </p></aside>
+<aside markdown="1" class="pquote">
+    <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/okdistribute?s=180">
+    Gerçek şu ki, destekleyici bir topluluğa sahip olmak çok önemlidir. Meslektaşlarımın, arkadaş canlısı yabancıların ve konuşkan IRC kanallarının yardımı olmadan bu işi asla yapamazdım. (...) Daha azına razı olma. Pisliklere razı olma.
+    <p markdown="1" class="pquote-credit">
+— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+    </p>
+</aside>
 
 Projenizin önemsiz yönleriyle ilgili düzenli tartışmalar, sizin de dahil olmak üzere diğerlerini önemli görevlere odaklanmaktan alıkoyuyor. Projenize gelen yeni insanlar bu konuşmaları görebilir ve katılmak istemeyebilir.
 
@@ -131,7 +149,13 @@ Projenize ulaşan çoğu insanla asla etkileşime geçemeyeceksiniz. Biri kendin
 
 ### Projenizi paylaşın
 
-<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/sagesharp?s=180">   Tüm sağlıklı toplulukların yapması gerektiği gibi liderlerinizin farklı görüşleri olacaktır! Bununla birlikte, en yüksek sesin insanları yormadan her zaman kazanmamasını ve daha az belirgin ve azınlık seslerinin duyulmasını sağlamak için adımlar atmanız gerekir.   <p markdown="1" class="pquote-credit"> — @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)   </p></aside>
+<aside markdown="1" class="pquote">
+    <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/sagesharp?s=180">
+    Tüm sağlıklı toplulukların yapması gerektiği gibi liderlerinizin farklı görüşleri olacaktır! Bununla birlikte, en yüksek sesin insanları yormadan her zaman kazanmamasını ve daha az belirgin ve azınlık seslerinin duyulmasını sağlamak için adımlar atmanız gerekir.
+    <p markdown="1" class="pquote-credit">
+— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+   </p>
+</aside>
 
 İnsanlar sahiplik hissi duyduklarında projelere katkıda bulunmaktan heyecan duyarlar. Bu, projenizin vizyonunu devretmeniz veya istemediğiniz katkıları kabul etmeniz gerektiği anlamına gelmez. Ancak başkalarına ne kadar çok kredi verirseniz, o kadar çok sadık kalırlar.
 
@@ -153,7 +177,13 @@ Gerçek şu ki çoğu projede işlerin çoğunu yapan [yalnızca](https://peerj.
 
 Çağrıya her zaman cevap verecek birini bulamayacak olsanız da, bir mesaj bırakmak, diğer kişilerin girme şansını arttırır.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">   \[Sizin için\] yapamadığınız şeyleri yapma yeteneğine sahip olan ve zevk alan katılımcıları işe almak en iyisidir. Kodlamayı seviyor musunuz, ancak soruları yanıtlamıyor musunuz? Topluluğunuzdaki bireylerin bunu yapmasına izin verin.   <p markdown="1" class="pquote-credit"> — @gr2m, ["Toplulukları Karşılama"](http://hood.ie/blog/welcoming-communities.html)   </p> </aside>
+<aside markdown="1" class="pquote">
+    <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
+    \[Sizin için\] yapamadığınız şeyleri yapma yeteneğine sahip olan ve zevk alan katılımcıları işe almak en iyisidir. Kodlamayı seviyor musunuz, ancak soruları yanıtlamıyor musunuz? Topluluğunuzdaki bireylerin bunu yapmasına izin verin.
+    <p markdown="1" class="pquote-credit">
+— @gr2m, ["Toplulukları Karşılama"](http://hood.ie/blog/welcoming-communities.html)
+    </p>
+</aside>
 
 ## Çatışmaları çözme
 
@@ -169,7 +199,13 @@ Topluluğunuz zor bir mesele ile boğuşurken, tansiyon artabilir. İnsanlar sin
 
 Bir proje sorumlusu olarak işiniz, bu durumların tırmanmasını önlemektir. Konuyla ilgili güçlü bir fikriniz olsa bile, kavgaya atılmak ve görüşlerinizi dayatmak yerine, moderatör veya kolaylaştırıcı olarak yer almaya çalışın. Birisi kaba veya tartışmacı davranıyorsa, tartışmaları medeni ve üretken kılmak için [hemen harekete](../building-community/#k%C3%B6t%C3%BC-karakterlere-m%C3%BCsamaha-g%C3%B6stermeyin) geçin.
 
-<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/kennethreitz?s=180">   Bir proje sorumlusu olarak, katılımcılarınıza saygılı olmak son derece önemlidir. Sık sık söylediklerinizi kişisel olarak alırlar.   <p markdown="1" class="pquote-credit"> — @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)   </p></aside>
+<aside markdown="1" class="pquote">
+    <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/kennethreitz?s=180">
+    Bir proje sorumlusu olarak, katılımcılarınıza saygılı olmak son derece önemlidir. Sık sık söylediklerinizi kişisel olarak alırlar.
+    <p markdown="1" class="pquote-credit">
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+    </p>
+</aside>
 
 Diğer insanlar rehberlik için size bakar. İyi bir örnek olun. Gerektiğinde hayal kırıklığını, mutsuzluğu veya endişeyi ifade edebilirsiniz, ancak bunu sakince yapın.
 
@@ -189,7 +225,13 @@ Bazen oy vermek gerekli bir sonlandırıcıdır. Ancak, mümkün olduğu kadar,
 
 Bir uzlaşma arayışı sürecinde, topluluk üyeleri yeterince duyulduğunu hissedene kadar önemli endişelerini tartışırlar. Sadece küçük kaygılar kalırsa, topluluk ileriye doğru hareket eder. "Uzlaşma arayışı", bir topluluğun mükemmel bir cevaba ulaşamayabileceğini kabul eder. Bunun yerine, dinlemeye ve tartışmaya öncelik verir.
 
-<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/lee-dohm?s=180">   Atom sorunları için bir oylama sisteminin bulunmamasının bir nedeni de Atom ekibinin her durumda bir oylama sistemini takip etmemesi. Bazen popüler olmasa bile neyin doğru olduğunu düşündüğümüzü seçmek zorundayız. (...) Yapabileceğim ve yapmayı taahhüt edebileceğim şey, toplumu dinlemek benim işim.  <p markdown="1" class="pquote-credit"> — @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)   </p></aside>
+<aside markdown="1" class="pquote">
+    <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/lee-dohm?s=180">
+    Atom sorunları için bir oylama sisteminin bulunmamasının bir nedeni de Atom ekibinin her durumda bir oylama sistemini takip etmemesi. Bazen popüler olmasa bile neyin doğru olduğunu düşündüğümüzü seçmek zorundayız. (...) Yapabileceğim ve yapmayı taahhüt edebileceğim şey, toplumu dinlemek benim işim.
+    <p markdown="1" class="pquote-credit">
+— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+    </p>
+</aside>
 
 Aslında bir uzlaşma arama sürecini benimsemeseniz bile, bir proje sorumlusu olarak, insanların dinlediğinizi bilmesi önemlidir. Diğer insanların duyulduklarını hissetmeleri ve endişelerini çözmeyi denediğinizi görmeleri, hassas durumları dağıtmak için size bir yol verir. Ardından, kelimelerinizi eylemlerle devam ettirin.
 
@@ -209,7 +251,13 @@ Konuşma çözülmeye ulaştıysa, sohbeti yeniden odaklamak için gruba _"Bunda
 
 Bir konuşma açıkça bir yere gitmiyorsa, yapılacak net bir işlem yoksa veya uygun bir işlem yapılmamışsa, sorunu kapatın ve neden kapattığınızı açıklayın.
 
-<aside markdown="1" class="pquote">   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/kfogel?s=180">   Bir başlığı saldırgan olmadan faydalı olmaya doğru yönlendirmek bir sanattır. İnsanları zamanlarını boşa harcamayı bırakmaları için uyarmak ya da söyleyecek yapıcı bir şeyleri olmadıkça mesaj göndermemelerini istemek işe yaramaz. (...) Bunun yerine, ilerleme için koşullar önermelisiniz: insanlara, istediğiniz sonuca götüren, ancak davranışları dikte ediyormuşsunuz gibi gelmeden, takip edecekleri bir yol verin.   <p markdown="1" class="pquote-credit"> — @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)   </p></aside>
+<aside markdown="1" class="pquote">
+    <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/kfogel?s=180">
+    Bir başlığı saldırgan olmadan faydalı olmaya doğru yönlendirmek bir sanattır. İnsanları zamanlarını boşa harcamayı bırakmaları için uyarmak ya da söyleyecek yapıcı bir şeyleri olmadıkça mesaj göndermemelerini istemek işe yaramaz. (...) Bunun yerine, ilerleme için koşullar önermelisiniz: insanlara, istediğiniz sonuca götüren, ancak davranışları dikte ediyormuşsunuz gibi gelmeden, takip edecekleri bir yol verin.
+    <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+    </p>
+</aside>
 
 ### Savaşlarınızı akıllıca seçin
 
diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index e26fe7045ee..f09df79a75a 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -30,7 +30,13 @@ _Özgür yazılım_ , _açık kaynak ile_ aynı proje grubunu ifade eder. Bazen
 
 ### İnsanlar neden işlerini açık kaynak olarak sunarlar?
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">   Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.   <p markdown="1" class="pquote-credit"> - @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)   </p> </aside>
+<aside markdown="1" class="pquote">
+    <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+    Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.
+    <p markdown="1" class="pquote-credit">
+- @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+    </p>
+</aside>
 
 Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler:
 
@@ -68,7 +74,13 @@ Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahi
 
 Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">   Bir noktada kullandığım özel bir UIAlertView yarattım ... ve açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca diğer geliştiricilere projelerinde nasıl kullanacaklarını açıklayan ilk belgelerimi yazdım. Muhtemelen hiç kimse onu kullanmamıştı çünkü basit bir projeydi ama katkım konusunda kendimi iyi hissediyordum.   <p markdown="1" class="pquote-credit"> - @mavris, ["Kendi Kendine Öğrenen Yazılım Geliştiricileri: Açık Kaynak Neden Bizim İçin Önemli?"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)   </p> </aside>
+<aside markdown="1" class="pquote">
+    <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+    Bir noktada kullandığım özel bir UIAlertView yarattım ... ve açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca diğer geliştiricilere projelerinde nasıl kullanacaklarını açıklayan ilk belgelerimi yazdım. Muhtemelen hiç kimse onu kullanmamıştı çünkü basit bir projeydi ama katkım konusunda kendimi iyi hissediyordum.
+    <p markdown="1" class="pquote-credit">
+- @mavris, ["Kendi Kendine Öğrenen Yazılım Geliştiricileri: Açık Kaynak Neden Bizim İçin Önemli?"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+    </p>
+</aside>
 
 Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir.
 
@@ -78,7 +90,13 @@ Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve
 
 Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın.
 
-<aside markdown="1" class="pquote">    <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">    Projeyi açmaya başladığınızda, yönetim süreçlerinizin projenizdeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. İşletmenizde istihdam edilmeyen katılımcıları, projenin kilit noktalarına dahil etmekten korkmayın - özellikle de sık sık katkıda bulunanlarsa.    <p markdown="1" class="pquote-credit"> — @captainsafia, ["Öyleyse bir açık kaynak proje açmak istiyorsun, ha?"](Https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)    </p> </aside>
+<aside markdown="1" class="pquote">
+    <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+    Projeyi açmaya başladığınızda, yönetim süreçlerinizin projenizdeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. İşletmenizde istihdam edilmeyen katılımcıları, projenin kilit noktalarına dahil etmekten korkmayın - özellikle de sık sık katkıda bulunanlarsa.
+    <p markdown="1" class="pquote-credit">
+— @captainsafia, ["Öyleyse bir açık kaynak proje açmak istiyorsun, ha?"](Https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+    </p>
+</aside>
 
 ### Diğer projelere katkıda bulunmak
 
@@ -130,7 +148,13 @@ README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını
 
 README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">   Daha iyi belgeler, daha fazla kullanıcı, daha az destek talebi ve daha fazla katkıda bulunan anlamına gelir. (...) Unutma ki okuyucuların sen değilsin. Tamamen farklı deneyimlerle projeye gelebilecek insanlar var.   <p markdown="1" class="pquote-credit"> - @tracymakes, ["Yazdıkların okunuyor (video)")(https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)   </p> </aside>
+<aside markdown="1" class="pquote">
+    <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+    Daha iyi belgeler, daha fazla kullanıcı, daha az destek talebi ve daha fazla katkıda bulunan anlamına gelir. (...) Unutma ki okuyucuların sen değilsin. Tamamen farklı deneyimlerle projeye gelebilecek insanlar var.
+    <p markdown="1" class="pquote-credit">
+- @tracymakes, ["Yazdıkların okunuyor (video)")(https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+    </p>
+</aside>
 
 Bazen, insanlar bir README yazmaktan kaçınırlar çünkü proje bitmemiş gibi hissederler veya katkı kabul etmek istemezler. Bunların hepsi yazmak için çok iyi nedenler.
 
@@ -170,7 +194,13 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan
 
 ### Davranış kural listesi oluşturmak
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">   Hepimiz, muhtemelen bir şeyin neden belli bir şekilde olması gerektiğini açıklamaya çalışan bir geliştirici olarak ya da bir kullanıcı olarak... basit bir soru sormakla ... ... kötüye kullanılan şeyin yaşadığı deneyimlerimiz oldu. (...) Davranış kuralları, ekibinizin yapıcı söylemleri çok ciddiye aldığını gösteren, kolayca referans verilen ve bağlanabilir bir belge haline gelir.   <p markdown="1" class="pquote-credit"> - @mlynch, ["Açık Kaynağı Daha Mutlu Bir Yer Yapma"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)   </p> </aside>
+<aside markdown="1" class="pquote">
+    <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+    Hepimiz, muhtemelen bir şeyin neden belli bir şekilde olması gerektiğini açıklamaya çalışan bir geliştirici olarak ya da bir kullanıcı olarak... basit bir soru sormakla ... ... kötüye kullanılan şeyin yaşadığı deneyimlerimiz oldu. (...) Davranış kuralları, ekibinizin yapıcı söylemleri çok ciddiye aldığını gösteren, kolayca referans verilen ve bağlanabilir bir belge haline gelir.
+    <p markdown="1" class="pquote-credit">
+- @mlynch, ["Açık Kaynağı Daha Mutlu Bir Yer Yapma"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+    </p>
+</aside>
 
 Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır.
 
@@ -215,7 +245,13 @@ Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici b
 
 Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">     Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.   <p markdown="1" class="pquote-credit"> - [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)   </p> </aside>
+<aside markdown="1" class="pquote">
+    <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+    Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.
+    <p markdown="1" class="pquote-credit">
+- [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+    </p>
+</aside>
 
 Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün.
 
@@ -231,39 +267,53 @@ Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol l
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox1" class="overflow-hidden d-block text-normal">     Projenin açık kaynak lisanslı LICENSE dosyası var   </label>
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Projenin açık kaynak lisanslı LICENSE dosyası var
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox2" class="overflow-hidden d-block text-normal">     Proje temel dokümantasyona sahiptir (README, CONTRIBUTING, CODE_OF_CONDUCT)   </label>
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    Proje temel dokümantasyona sahiptir (README, CONTRIBUTING, CODE_OF_CONDUCT)
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox3" class="overflow-hidden d-block text-normal">     Adı hatırlamak kolaydır, projenin ne yaptığı hakkında bir fikir verir ve mevcut bir projeyle çelişmez veya ticari markaları ihlal etmez   </label>
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    Adı hatırlamak kolaydır, projenin ne yaptığı hakkında bir fikir verir ve mevcut bir projeyle çelişmez veya ticari markaları ihlal etmez
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox4" class="overflow-hidden d-block text-normal">     Sorun listesi, açıkça düzenlenmiş ve etiketlenmiş konularla birlikte güncel   </label>
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    Sorun listesi, açıkça düzenlenmiş ve etiketlenmiş konularla birlikte güncel
+  </label>
 </div>
 
 **Kod**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox5" class="overflow-hidden d-block text-normal">     Proje tutarlı kod kuralları ve temiz işlev/yöntem/değişken adlarını kullanıyor   </label>
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Proje tutarlı kod kuralları ve temiz işlev/yöntem/değişken adlarını kullanıyor
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox6" class="overflow-hidden d-block text-normal">     Kod açıkça yorumlanmış, amaçları ve aykırı vakaları belgelemektedir.   </label>
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Kod açıkça yorumlanmış, amaçları ve aykırı vakaları belgelemektedir.
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox7" class="overflow-hidden d-block text-normal">     Revizyon geçmişinde, sorunlarda veya PR isteklerinde (örneğin şifreler veya kamuya açık olmayan diğer bilgiler) hassas bilgi yok   </label>
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Revizyon geçmişinde, sorunlarda veya PR isteklerinde (örneğin şifreler veya kamuya açık olmayan diğer bilgiler) hassas bilgi yok
+  </label>
 </div>
 
 **İnsanlar**
@@ -272,29 +322,39 @@ Bireyseniz:
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox8" class="overflow-hidden d-block text-normal">     Hukuk departmanıyla konuştunuz ve/veya şirketinizin IP ve açık kaynaklı politikalarını anladınız (eğer bir yerde çalışansanız).   </label>
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Hukuk departmanıyla konuştunuz ve/veya şirketinizin IP ve açık kaynaklı politikalarını anladınız (eğer bir yerde çalışansanız).
+  </label>
 </div>
 
 Bir şirket veya kuruluşsanız:
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox9" class="overflow-hidden d-block text-normal">     Hukuk departmanınızla konuştunuz   </label>
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Hukuk departmanınızla konuştunuz
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox10" class="overflow-hidden d-block text-normal">     Projeyi duyurmak ve tanıtmak için bir pazarlama planınız var   </label>
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    Projeyi duyurmak ve tanıtmak için bir pazarlama planınız var
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox11" class="overflow-hidden d-block text-normal">     Birisi topluluk etkileşimlerini yönetmeyi taahhüt eder (sorunlara cevap verme, çekme isteklerini gözden geçirme ve birleştirme)   </label>
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Birisi topluluk etkileşimlerini yönetmeyi taahhüt eder (sorunlara cevap verme, çekme isteklerini gözden geçirme ve birleştirme)
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox12" class="overflow-hidden d-block text-normal">     En az iki kişinin projeye yönetici erişimi var   </label>
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    En az iki kişinin projeye yönetici erişimi var
+  </label>
 </div>
 
 ## Başardınız!

From 4a82ac30f2e4fd3e54853adb3e25272e8b445e53 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 13 Jul 2020 02:53:39 +0300
Subject: [PATCH 028/749] Add GADPP to the project

---
 .github/workflows/gadpp.yml | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 .github/workflows/gadpp.yml

diff --git a/.github/workflows/gadpp.yml b/.github/workflows/gadpp.yml
new file mode 100644
index 00000000000..eea3d82d407
--- /dev/null
+++ b/.github/workflows/gadpp.yml
@@ -0,0 +1,19 @@
+ 
+on: [push]
+
+jobs:
+  gadpp_job:
+    runs-on: ubuntu-latest
+    name: Update GitHub Profile Page
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+      - name: GADPP
+        uses: umutphp/github-action-dynamic-profile-page@v2
+        id: gadpp
+        env:
+          API_TOKEN_GITHUB: ${{ secrets.API_TOKEN_GITHUB }}
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          github-username: 'umutphp'
+          user-email: 'umutphp@gmail.com'

From 9497ca2c7d2df001b2a379179ade27b19000c249 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 13 Jul 2020 03:01:57 +0300
Subject: [PATCH 029/749] Fix linter on _articles/tr/legal.md

---
 _articles/tr/legal.md | 31 +++++++++++++++++++++++++++----
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index b1251c808de..d731ef33abe 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -52,7 +52,13 @@ Başkalarının projenizi kullanmasını, dağıtmasını, değiştirmesini veya
 
 GitHub'da yeni bir proje oluşturduğunuzda sizden [bir lisans eklemeniz istenir](https://help.github.com/articles/open-source-licensing/).
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">   Standartlaştırılmış bir lisans, yasal eğitim almayanların yazılımla neler yapabileceklerini ve yapamadıklarını tam olarak bilmeleri için bir vekil olarak hizmet eder. Kesinlikle gerekli olmadıkça, ajans kodunun akış aşağı kullanımına engel teşkil edecek özel, değiştirilmiş veya standart olmayan terimlerden kaçının.   <p markdown="1" class="pquote-credit"> - @benbalter, ["Bir devlet avukatının açık kaynaklı yazılım lisanslama hakkında bilmesi gereken her şey"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)   </p> </aside>
+<aside markdown="1" class="pquote">
+    <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
+    Standartlaştırılmış bir lisans, yasal eğitim almayanların yazılımla neler yapabileceklerini ve yapamadıklarını tam olarak bilmeleri için bir vekil olarak hizmet eder. Kesinlikle gerekli olmadıkça, ajans kodunun akış aşağı kullanımına engel teşkil edecek özel, değiştirilmiş veya standart olmayan terimlerden kaçının.
+    <p markdown="1" class="pquote-credit">
+- @benbalter, ["Bir devlet avukatının açık kaynaklı yazılım lisanslama hakkında bilmesi gereken her şey"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+    </p>
+</aside>
 
 ## Projem için hangi açık kaynak lisansı uygundur?
 
@@ -96,7 +102,13 @@ Ek bir katılımcı sözleşmesi - genellikle Katılımcı Lisans Sözleşmesi (
 
 Ayrıca, bazılarının gereksiz olduğuna, anlaşılmasının zor veya haksız olduğuna inandığı "evraklar" ekleyerek (sözleşme alıcısı katkıda bulunanlardan veya halkın projenin açık kaynak lisansı aracılığıyla yaptığı haklardan daha fazla hak kazandığında), ek bir katılımcı anlaşması projenin topluluğuna dostça görülmeyebilir.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">   Node.js için CLA'yı kaldırdık. Bunu yapmak, Node.js katılımcısı için giriş engelini azalttı ve böylece katılımcı tabanını genişletti.   <p markdown="1" class="pquote-credit"> - @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.joyent.com/blog/broadening-node-js-contributions)   </p> </aside>
+<aside markdown="1" class="pquote">
+    <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
+    Node.js için CLA'yı kaldırdık. Bunu yapmak, Node.js katılımcısı için giriş engelini azalttı ve böylece katılımcı tabanını genişletti.
+    <p markdown="1" class="pquote-credit">
+- @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.joyent.com/blog/broadening-node-js-contributions)
+    </p>
+</aside>
 
 Projeniz için ek bir katılımcı sözleşmesi düşünmek isteyebileceğiniz bazı durumlar şunlardır:
 
@@ -132,12 +144,23 @@ Daha uzun vadede hukuk ekibiniz, şirketin açık kaynaklara katılımından dah
 
 * **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)'dır.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">   Bir yama ile ilgili IP'nin serbest bırakılması, çalışanın bilgi birikimini ve itibarını arttırır. Şirketin bu çalışanın gelişimine yatırım yaptığını ve bir güçlendirme ve özerklik duygusu yarattığını göstermektedir. Tüm bu faydalar ayrıca daha yüksek moral ve daha iyi bir çalışanın kalmasına yol açmaktadır.   <p markdown="1" class="pquote-credit"> - @vanl, ["Bir Model IP ve Açık Kaynak Katkı Politikası"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)   </p> </aside>
+<aside markdown="1" class="pquote">
+    <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
+    Bir yama ile ilgili IP'nin serbest bırakılması, çalışanın bilgi birikimini ve itibarını arttırır. Şirketin bu çalışanın gelişimine yatırım yaptığını ve bir güçlendirme ve özerklik duygusu yarattığını göstermektedir. Tüm bu faydalar ayrıca daha yüksek moral ve daha iyi bir çalışanın kalmasına yol açmaktadır.
+    <p markdown="1" class="pquote-credit">
+- @vanl, ["Bir Model IP ve Açık Kaynak Katkı Politikası"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+    </p>
+</aside>
 
 * **Neyi yayınlama:** [(Neredeyse) her şey?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Eğer yasal ekibiniz şirketinizin açık kaynaklı stratejisini anlıyor ve yatırım yapıyorsa, çabalarınızı engellemekten ziyade en iyi şekilde yardım edebileceklerdir.
 * **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir.
 
-<aside markdown="1" class="pquote">     Kuruluşların hem \["izin verilen" hem de "copyleft"\] kategorilerine uyan bir lisans ve uyum stratejisi olmalıdır. Bu, alt bileşenler ve bağımlılıklar dahil, kullanmakta olduğunuz açık kaynaklı yazılım için geçerli olan lisans terimlerinin kaydını tutmakla başlar.     <p markdown="1" class="pquote-credit"> - Heather Meeker, ["Açık Kaynak Kodlu Yazılım: Uygunluk Esasları ve En İyi Uygulamalar"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)     </p> </aside>
+<aside markdown="1" class="pquote">
+    Kuruluşların hem \["izin verilen" hem de "copyleft"\] kategorilerine uyan bir lisans ve uyum stratejisi olmalıdır. Bu, alt bileşenler ve bağımlılıklar dahil, kullanmakta olduğunuz açık kaynaklı yazılım için geçerli olan lisans terimlerinin kaydını tutmakla başlar.
+    <p markdown="1" class="pquote-credit">
+- Heather Meeker, ["Açık Kaynak Kodlu Yazılım: Uygunluk Esasları ve En İyi Uygulamalar"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+    </p>
+</aside>
 
 * **Patentler:** Şirketiniz, üyelerin büyük açık kaynaklı projeleri kullanmalarını korumak için ortak bir savunma patenti havuzu olan [Açık Buluşma Ağı](https://www.openinventionnetwork.com/)'na katılmak veya başka bir [alternatif patent lisansını](https://www.eff.org/document/hacking-patent-system-2016) keşfetmek isteyebilir.
 * **Yönetişim:** Özellikle bir projeyi [şirket dışındaki](../leadership-and-governance/#projemi-desteklemek-i%C3%A7in-t%C3%BCzel-ki%C5%9Fili%C4%9Fe-ihtiyac%C4%B1m-var-m%C4%B1) bir {a2}tüzel kişiliğe{/a2} taşımanın ne zaman anlamlı olacağı.

From 4f6fb5c13367c200544662a6bcb38cf8f6bc3724 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 13 Jul 2020 03:13:26 +0300
Subject: [PATCH 030/749] Minor

---
 _articles/tr/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index d731ef33abe..f57ef942a09 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -76,7 +76,7 @@ Ayrıca, projenizi kullanacağını ve projenize katkıda bulunacağını umduğ
 * **Projenizin büyük işletmelere hitap etmesini ister misiniz?** Büyük bir işletme muhtemelen tüm katılımcılardan açık bir patent lisansı isteyecektir. Bu durumda, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) size (ve onlara) uygundur.
 * **Projenizin, yaptıkları katkıların kapalı kaynak kodlu yazılımlarda kullanılmasını istemeyenlere hitap etmesini ister misiniz?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) veya (kapalı kaynak hizmetlerine katkıda bulunmak istemiyorlarsa) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) sizin için iyidir.
 
-**Şirketinizin** açık kaynaklı projeleri için özel lisanslama gereksinimleri olabilir. Örneğin, izin verilen bir lisans gerektirebilir, böylece şirket projenizi şirketin kapalı kaynaklı ürününde kullanabilir. Veya şirketiniz güçlü bir copyleft lisansı ve ek bir katkı sözleşmesi (aşağıya bakınız) isteyebilir, böylece yalnızca şirketiniz ve başka hiç kimse projenizi kapalı kaynaklı yazılımında kullanamaz. Yada şirketiniz, herhangi biri belirli bir lisanslama stratejisi gerektirebilecek standartlar, sosyal sorumluluk veya şeffaflıkla ilgili belirli ihtiyaçlara sahip olabilir. [Şirketinizin hukuk departmanıyla](#%C5%9Firketimin-hukuk-ekibinin-neleri-bilmesi-gerekiyor) konuşun.
+**Şirketinizin** açık kaynaklı projeleri için özel lisanslama gereksinimleri olabilir. Örneğin, izin verilen bir lisans gerektirebilir, böylece şirket projenizi şirketin kapalı kaynaklı ürününde kullanabilir. Veya şirketiniz güçlü bir copyleft lisansı ve ek bir katkı sözleşmesi (aşağıya bakınız) isteyebilir, böylece yalnızca şirketiniz ve başka hiç kimse projenizi kapalı kaynaklı yazılımında kullanamaz. Yada şirketiniz, herhangi biri belirli bir lisanslama stratejisi gerektirebilecek standartlar, sosyal sorumluluk veya şeffaflıkla ilgili belirli ihtiyaçlara sahip olabilir. [Şirketinizin hukuk departmanıyla](#şirketimin-hukuk-ekibinin-neleri-bilmesi-gerekiyor) konuşun.
 
 GitHub'da yeni bir proje oluşturduğunuzda, size bir lisans seçme seçeneği sunulur. Yukarıda belirtilen lisanslardan birinin dahil edilmesi GitHub projenizi açık kaynak yapacaktır. Başka seçenekler görmek isterseniz, projeniz için doğru lisansı bulmak için [choosealicense.com](https://choosealicense.com) adresini ziyaret edin, proje [yazılım](https://choosealicense.com/non-software/) projesi olmasa bile.
 

From 9eafde6453ff6fddbdb2e36c790120edf51bda90 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 13 Jul 2020 03:21:42 +0300
Subject: [PATCH 031/749] Fix typo

---
 _articles/tr/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index f57ef942a09..68b0914d0f1 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -120,7 +120,7 @@ Projeniz için ek bir katılımcı sözleşmesi düşünmek isteyebileceğiniz b
 
 Projeniz için ek bir katılımcı sözleşmesi kullanmanız gerekiyorsa, katılımcıların dikkatini dağıtmayı en aza indirmek için [CLA yardımcısı](https://github.com/cla-assistant/cla-assistant) gibi bir entegrasyon kullanmayı düşünün.
 
-## Şirketimin hukuk ekibinin neyi bilmesi gerekiyor?
+## Şirketimin hukuk ekibinin neleri bilmesi gerekiyor?
 
 Açık kaynaklı bir projeyi bir şirket çalışanı olarak yayınlıyorsanız, önce hukuk ekibiniz bir proje tedarik ettiğinizi bilmelidir.
 

From 10de0ecd84a1d183a76e62b8b7b54ca2b377b2ec Mon Sep 17 00:00:00 2001
From: Fabricio Damazio <fabridamazio@gmail.com>
Date: Sun, 19 Jul 2020 13:43:55 -0300
Subject: [PATCH 032/749] Fix pt translation grammar error

Change "espectativas" to "expectativas".
---
 _articles/pt/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index 350c3586248..f5cf3244ec3 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -118,7 +118,7 @@ Independente do estágio em que você decida tornar o seu projeto open source, t
 * [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
 * [Code of conduct](../code-of-conduct/)
 
-Como um mantenedor, esses componentes irão ajudá-lo a comunicar suas espectativas, administrar contribuições, e proteger o direito legal de todos (inclusive o seu). Eles aumentam suas chances de ter uma experência positiva significativamente.
+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.
 
 Se seu projeto está no GitHub, colocar esses arquivos no seu diretório root com os nomes recomendados ajudará o GitHub a reconhecê-los e automaticamente mostrá-los da maneira apropriada aos seus leitores.
 

From 1310f5d312e8e4f8e857315f17fd2ec58af68e57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Sun, 19 Jul 2020 20:53:26 +0300
Subject: [PATCH 033/749] Remove gadpp from project

---
 .github/workflows/gadpp.yml | 19 -------------------
 1 file changed, 19 deletions(-)
 delete mode 100644 .github/workflows/gadpp.yml

diff --git a/.github/workflows/gadpp.yml b/.github/workflows/gadpp.yml
deleted file mode 100644
index eea3d82d407..00000000000
--- a/.github/workflows/gadpp.yml
+++ /dev/null
@@ -1,19 +0,0 @@
- 
-on: [push]
-
-jobs:
-  gadpp_job:
-    runs-on: ubuntu-latest
-    name: Update GitHub Profile Page
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v2
-      - name: GADPP
-        uses: umutphp/github-action-dynamic-profile-page@v2
-        id: gadpp
-        env:
-          API_TOKEN_GITHUB: ${{ secrets.API_TOKEN_GITHUB }}
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        with:
-          github-username: 'umutphp'
-          user-email: 'umutphp@gmail.com'

From fa9e45d59ed10ed920b1a035007a221851dc5345 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 20 Jul 2020 01:43:43 +0300
Subject: [PATCH 034/749] Fix aside indendation

---
 _articles/tr/building-community.md | 62 +++++++++++++++---------------
 _articles/tr/legal.md              | 38 +++++++++---------
 _articles/tr/starting-a-project.md | 58 ++++++++++++++--------------
 3 files changed, 79 insertions(+), 79 deletions(-)

diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md
index 1b7e8f00854..3f23d731ddb 100644
--- a/_articles/tr/building-community.md
+++ b/_articles/tr/building-community.md
@@ -42,11 +42,11 @@ Belgelerinizle başlayın:
 * **Katılmadığınız bir katkı varsa** , fikirleri için onlara teşekkür edin ve [niçin](../best-practices/#hay%C4%B1r-demeyi-%C3%B6%C4%9Frenme) projenin kapsamına uymadığını açıklayın, varsa ilgili dokümantasyondan alıntı yapın.
 
 <aside markdown="1" class="pquote">
-    <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/mikeal?s=180">
-    Bazıları için açık kaynağa katkıda bulunmak diğerlerinden daha kolaydır. Doğru bir şey yapmamak ya da sadece uyum sağlamaktan bağırmaktan korkmak çok fazla. (...) Katkıda bulunanlara çok düşük teknik yeterliliğe (dokümantasyon, web içeriği işaretleme, vb.) Katkıda bulunacak bir yer vererek bu kaygılar.
+  <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/mikeal?s=180">
+  Bazıları için açık kaynağa katkıda bulunmak diğerlerinden daha kolaydır. Doğru bir şey yapmamak ya da sadece uyum sağlamaktan bağırmaktan korkmak çok fazla. (...) Katkıda bulunanlara çok düşük teknik yeterliliğe (dokümantasyon, web içeriği işaretleme, vb.) Katkıda bulunacak bir yer vererek bu kaygılar.
     <p markdown="1" class="pquote-credit">
 — @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
-   </p>
+  </p>
 </aside>
 
 Açık kaynak katkıda bulunanların çoğunluğu "geçici katkı yapanlardır": yani bir projeye yalnızca ara sıra katkıda bulunan insanlar. Sıradan bir katılımcının projenizi hızlandırmak için tam zamanı olmayacağı için işiniz onların katkıda bulunmalarını kolaylaştırmaktır.
@@ -56,11 +56,11 @@ Diğer katılımcıları teşvik etmek kendinize yapılan bir yatırımdır. En
 ### Her şeyi belgeleyin
 
 <aside markdown="1" class="pquote">
-    <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-    Hiç kimseyi tanımadığınız (teknoloji) bir etkinliğe katıldınız mı, ama diğerleri gruplarda durup eski arkadaşlar gibi sohbet ettiler mi? (...) Şimdi açık kaynaklı bir projeye katkıda bulunmak istediğinizi hayal edin, ancak bunun neden veya nasıl olduğunu görmüyorsunuz.
-    <p markdown="1" class="pquote-credit">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  Hiç kimseyi tanımadığınız (teknoloji) bir etkinliğe katıldınız mı, ama diğerleri gruplarda durup eski arkadaşlar gibi sohbet ettiler mi? (...) Şimdi açık kaynaklı bir projeye katkıda bulunmak istediğinizi hayal edin, ancak bunun neden veya nasıl olduğunu görmüyorsunuz.
+  <p markdown="1" class="pquote-credit">
 — @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
-   </p>
+  </p>
 </aside>
 
 Yeni bir projeye başladığınızda, çalışmanızı özel tutmak doğal olabilir. Ancak, açık kaynaklı projeler, sürecinizi halka açık olarak belgelemeniz durumunda gelişir.
@@ -118,11 +118,11 @@ Herhangi bir popüler proje kaçınılmaz olarak topluluğunuza yardım etmek ye
 Bu tür insanlara karşı sıfır tolerans politikası benimsemek için elinizden geleni yapın. Denetlenmezse, negatif insanlar topluluğunuzdaki diğer insanları rahatsız eder. Hatta ayrılmalarına sebep olabilirler.
 
 <aside markdown="1" class="pquote">
-    <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/okdistribute?s=180">
-    Gerçek şu ki, destekleyici bir topluluğa sahip olmak çok önemlidir. Meslektaşlarımın, arkadaş canlısı yabancıların ve konuşkan IRC kanallarının yardımı olmadan bu işi asla yapamazdım. (...) Daha azına razı olma. Pisliklere razı olma.
-    <p markdown="1" class="pquote-credit">
+  <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/okdistribute?s=180">
+  Gerçek şu ki, destekleyici bir topluluğa sahip olmak çok önemlidir. Meslektaşlarımın, arkadaş canlısı yabancıların ve konuşkan IRC kanallarının yardımı olmadan bu işi asla yapamazdım. (...) Daha azına razı olma. Pisliklere razı olma.
+  <p markdown="1" class="pquote-credit">
 — @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
-    </p>
+  </p>
 </aside>
 
 Projenizin önemsiz yönleriyle ilgili düzenli tartışmalar, sizin de dahil olmak üzere diğerlerini önemli görevlere odaklanmaktan alıkoyuyor. Projenize gelen yeni insanlar bu konuşmaları görebilir ve katılmak istemeyebilir.
@@ -150,11 +150,11 @@ Projenize ulaşan çoğu insanla asla etkileşime geçemeyeceksiniz. Biri kendin
 ### Projenizi paylaşın
 
 <aside markdown="1" class="pquote">
-    <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/sagesharp?s=180">
-    Tüm sağlıklı toplulukların yapması gerektiği gibi liderlerinizin farklı görüşleri olacaktır! Bununla birlikte, en yüksek sesin insanları yormadan her zaman kazanmamasını ve daha az belirgin ve azınlık seslerinin duyulmasını sağlamak için adımlar atmanız gerekir.
-    <p markdown="1" class="pquote-credit">
+  <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/sagesharp?s=180">
+  Tüm sağlıklı toplulukların yapması gerektiği gibi liderlerinizin farklı görüşleri olacaktır! Bununla birlikte, en yüksek sesin insanları yormadan her zaman kazanmamasını ve daha az belirgin ve azınlık seslerinin duyulmasını sağlamak için adımlar atmanız gerekir.
+  <p markdown="1" class="pquote-credit">
 — @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
-   </p>
+  </p>
 </aside>
 
 İnsanlar sahiplik hissi duyduklarında projelere katkıda bulunmaktan heyecan duyarlar. Bu, projenizin vizyonunu devretmeniz veya istemediğiniz katkıları kabul etmeniz gerektiği anlamına gelmez. Ancak başkalarına ne kadar çok kredi verirseniz, o kadar çok sadık kalırlar.
@@ -178,11 +178,11 @@ Gerçek şu ki çoğu projede işlerin çoğunu yapan [yalnızca](https://peerj.
 Çağrıya her zaman cevap verecek birini bulamayacak olsanız da, bir mesaj bırakmak, diğer kişilerin girme şansını arttırır.
 
 <aside markdown="1" class="pquote">
-    <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
-    \[Sizin için\] yapamadığınız şeyleri yapma yeteneğine sahip olan ve zevk alan katılımcıları işe almak en iyisidir. Kodlamayı seviyor musunuz, ancak soruları yanıtlamıyor musunuz? Topluluğunuzdaki bireylerin bunu yapmasına izin verin.
-    <p markdown="1" class="pquote-credit">
+  <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
+  \[Sizin için\] yapamadığınız şeyleri yapma yeteneğine sahip olan ve zevk alan katılımcıları işe almak en iyisidir. Kodlamayı seviyor musunuz, ancak soruları yanıtlamıyor musunuz? Topluluğunuzdaki bireylerin bunu yapmasına izin verin.
+  <p markdown="1" class="pquote-credit">
 — @gr2m, ["Toplulukları Karşılama"](http://hood.ie/blog/welcoming-communities.html)
-    </p>
+  </p>
 </aside>
 
 ## Çatışmaları çözme
@@ -200,11 +200,11 @@ Topluluğunuz zor bir mesele ile boğuşurken, tansiyon artabilir. İnsanlar sin
 Bir proje sorumlusu olarak işiniz, bu durumların tırmanmasını önlemektir. Konuyla ilgili güçlü bir fikriniz olsa bile, kavgaya atılmak ve görüşlerinizi dayatmak yerine, moderatör veya kolaylaştırıcı olarak yer almaya çalışın. Birisi kaba veya tartışmacı davranıyorsa, tartışmaları medeni ve üretken kılmak için [hemen harekete](../building-community/#k%C3%B6t%C3%BC-karakterlere-m%C3%BCsamaha-g%C3%B6stermeyin) geçin.
 
 <aside markdown="1" class="pquote">
-    <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/kennethreitz?s=180">
-    Bir proje sorumlusu olarak, katılımcılarınıza saygılı olmak son derece önemlidir. Sık sık söylediklerinizi kişisel olarak alırlar.
-    <p markdown="1" class="pquote-credit">
+  <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/kennethreitz?s=180">
+  Bir proje sorumlusu olarak, katılımcılarınıza saygılı olmak son derece önemlidir. Sık sık söylediklerinizi kişisel olarak alırlar.
+  <p markdown="1" class="pquote-credit">
 — @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
-    </p>
+  </p>
 </aside>
 
 Diğer insanlar rehberlik için size bakar. İyi bir örnek olun. Gerektiğinde hayal kırıklığını, mutsuzluğu veya endişeyi ifade edebilirsiniz, ancak bunu sakince yapın.
@@ -226,11 +226,11 @@ Bazen oy vermek gerekli bir sonlandırıcıdır. Ancak, mümkün olduğu kadar,
 Bir uzlaşma arayışı sürecinde, topluluk üyeleri yeterince duyulduğunu hissedene kadar önemli endişelerini tartışırlar. Sadece küçük kaygılar kalırsa, topluluk ileriye doğru hareket eder. "Uzlaşma arayışı", bir topluluğun mükemmel bir cevaba ulaşamayabileceğini kabul eder. Bunun yerine, dinlemeye ve tartışmaya öncelik verir.
 
 <aside markdown="1" class="pquote">
-    <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/lee-dohm?s=180">
-    Atom sorunları için bir oylama sisteminin bulunmamasının bir nedeni de Atom ekibinin her durumda bir oylama sistemini takip etmemesi. Bazen popüler olmasa bile neyin doğru olduğunu düşündüğümüzü seçmek zorundayız. (...) Yapabileceğim ve yapmayı taahhüt edebileceğim şey, toplumu dinlemek benim işim.
-    <p markdown="1" class="pquote-credit">
+  <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/lee-dohm?s=180">
+  Atom sorunları için bir oylama sisteminin bulunmamasının bir nedeni de Atom ekibinin her durumda bir oylama sistemini takip etmemesi. Bazen popüler olmasa bile neyin doğru olduğunu düşündüğümüzü seçmek zorundayız. (...) Yapabileceğim ve yapmayı taahhüt edebileceğim şey, toplumu dinlemek benim işim.
+  <p markdown="1" class="pquote-credit">
 — @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
-    </p>
+  </p>
 </aside>
 
 Aslında bir uzlaşma arama sürecini benimsemeseniz bile, bir proje sorumlusu olarak, insanların dinlediğinizi bilmesi önemlidir. Diğer insanların duyulduklarını hissetmeleri ve endişelerini çözmeyi denediğinizi görmeleri, hassas durumları dağıtmak için size bir yol verir. Ardından, kelimelerinizi eylemlerle devam ettirin.
@@ -252,11 +252,11 @@ Konuşma çözülmeye ulaştıysa, sohbeti yeniden odaklamak için gruba _"Bunda
 Bir konuşma açıkça bir yere gitmiyorsa, yapılacak net bir işlem yoksa veya uygun bir işlem yapılmamışsa, sorunu kapatın ve neden kapattığınızı açıklayın.
 
 <aside markdown="1" class="pquote">
-    <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/kfogel?s=180">
-    Bir başlığı saldırgan olmadan faydalı olmaya doğru yönlendirmek bir sanattır. İnsanları zamanlarını boşa harcamayı bırakmaları için uyarmak ya da söyleyecek yapıcı bir şeyleri olmadıkça mesaj göndermemelerini istemek işe yaramaz. (...) Bunun yerine, ilerleme için koşullar önermelisiniz: insanlara, istediğiniz sonuca götüren, ancak davranışları dikte ediyormuşsunuz gibi gelmeden, takip edecekleri bir yol verin.
-    <p markdown="1" class="pquote-credit">
+  <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/kfogel?s=180">
+  Bir başlığı saldırgan olmadan faydalı olmaya doğru yönlendirmek bir sanattır. İnsanları zamanlarını boşa harcamayı bırakmaları için uyarmak ya da söyleyecek yapıcı bir şeyleri olmadıkça mesaj göndermemelerini istemek işe yaramaz. (...) Bunun yerine, ilerleme için koşullar önermelisiniz: insanlara, istediğiniz sonuca götüren, ancak davranışları dikte ediyormuşsunuz gibi gelmeden, takip edecekleri bir yol verin.
+  <p markdown="1" class="pquote-credit">
 — @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
-    </p>
+  </p>
 </aside>
 
 ### Savaşlarınızı akıllıca seçin
diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index 68b0914d0f1..4ca577da3f2 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -53,11 +53,11 @@ Başkalarının projenizi kullanmasını, dağıtmasını, değiştirmesini veya
 GitHub'da yeni bir proje oluşturduğunuzda sizden [bir lisans eklemeniz istenir](https://help.github.com/articles/open-source-licensing/).
 
 <aside markdown="1" class="pquote">
-    <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
-    Standartlaştırılmış bir lisans, yasal eğitim almayanların yazılımla neler yapabileceklerini ve yapamadıklarını tam olarak bilmeleri için bir vekil olarak hizmet eder. Kesinlikle gerekli olmadıkça, ajans kodunun akış aşağı kullanımına engel teşkil edecek özel, değiştirilmiş veya standart olmayan terimlerden kaçının.
-    <p markdown="1" class="pquote-credit">
-- @benbalter, ["Bir devlet avukatının açık kaynaklı yazılım lisanslama hakkında bilmesi gereken her şey"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
-    </p>
+  <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
+  Standartlaştırılmış bir lisans, yasal eğitim almayanların yazılımla neler yapabileceklerini ve yapamadıklarını tam olarak bilmeleri için bir vekil olarak hizmet eder. Kesinlikle gerekli olmadıkça, ajans kodunun akış aşağı kullanımına engel teşkil edecek özel, değiştirilmiş veya standart olmayan terimlerden kaçının.
+  <p markdown="1" class="pquote-credit">
+— @benbalter, ["Bir devlet avukatının açık kaynaklı yazılım lisanslama hakkında bilmesi gereken her şey"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+  </p>
 </aside>
 
 ## Projem için hangi açık kaynak lisansı uygundur?
@@ -103,11 +103,11 @@ Ek bir katılımcı sözleşmesi - genellikle Katılımcı Lisans Sözleşmesi (
 Ayrıca, bazılarının gereksiz olduğuna, anlaşılmasının zor veya haksız olduğuna inandığı "evraklar" ekleyerek (sözleşme alıcısı katkıda bulunanlardan veya halkın projenin açık kaynak lisansı aracılığıyla yaptığı haklardan daha fazla hak kazandığında), ek bir katılımcı anlaşması projenin topluluğuna dostça görülmeyebilir.
 
 <aside markdown="1" class="pquote">
-    <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
-    Node.js için CLA'yı kaldırdık. Bunu yapmak, Node.js katılımcısı için giriş engelini azalttı ve böylece katılımcı tabanını genişletti.
-    <p markdown="1" class="pquote-credit">
-- @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.joyent.com/blog/broadening-node-js-contributions)
-    </p>
+  <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
+  Node.js için CLA'yı kaldırdık. Bunu yapmak, Node.js katılımcısı için giriş engelini azalttı ve böylece katılımcı tabanını genişletti.
+  <p markdown="1" class="pquote-credit">
+— @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.joyent.com/blog/broadening-node-js-contributions)
+  </p>
 </aside>
 
 Projeniz için ek bir katılımcı sözleşmesi düşünmek isteyebileceğiniz bazı durumlar şunlardır:
@@ -145,21 +145,21 @@ Daha uzun vadede hukuk ekibiniz, şirketin açık kaynaklara katılımından dah
 * **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)'dır.
 
 <aside markdown="1" class="pquote">
-    <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
-    Bir yama ile ilgili IP'nin serbest bırakılması, çalışanın bilgi birikimini ve itibarını arttırır. Şirketin bu çalışanın gelişimine yatırım yaptığını ve bir güçlendirme ve özerklik duygusu yarattığını göstermektedir. Tüm bu faydalar ayrıca daha yüksek moral ve daha iyi bir çalışanın kalmasına yol açmaktadır.
-    <p markdown="1" class="pquote-credit">
-- @vanl, ["Bir Model IP ve Açık Kaynak Katkı Politikası"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
-    </p>
+  <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
+  Bir yama ile ilgili IP'nin serbest bırakılması, çalışanın bilgi birikimini ve itibarını arttırır. Şirketin bu çalışanın gelişimine yatırım yaptığını ve bir güçlendirme ve özerklik duygusu yarattığını göstermektedir. Tüm bu faydalar ayrıca daha yüksek moral ve daha iyi bir çalışanın kalmasına yol açmaktadır.
+  <p markdown="1" class="pquote-credit">
+— @vanl, ["Bir Model IP ve Açık Kaynak Katkı Politikası"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+  </p>
 </aside>
 
 * **Neyi yayınlama:** [(Neredeyse) her şey?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Eğer yasal ekibiniz şirketinizin açık kaynaklı stratejisini anlıyor ve yatırım yapıyorsa, çabalarınızı engellemekten ziyade en iyi şekilde yardım edebileceklerdir.
 * **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir.
 
 <aside markdown="1" class="pquote">
-    Kuruluşların hem \["izin verilen" hem de "copyleft"\] kategorilerine uyan bir lisans ve uyum stratejisi olmalıdır. Bu, alt bileşenler ve bağımlılıklar dahil, kullanmakta olduğunuz açık kaynaklı yazılım için geçerli olan lisans terimlerinin kaydını tutmakla başlar.
-    <p markdown="1" class="pquote-credit">
-- Heather Meeker, ["Açık Kaynak Kodlu Yazılım: Uygunluk Esasları ve En İyi Uygulamalar"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
-    </p>
+  Kuruluşların hem \["izin verilen" hem de "copyleft"\] kategorilerine uyan bir lisans ve uyum stratejisi olmalıdır. Bu, alt bileşenler ve bağımlılıklar dahil, kullanmakta olduğunuz açık kaynaklı yazılım için geçerli olan lisans terimlerinin kaydını tutmakla başlar.
+  <p markdown="1" class="pquote-credit">
+— Heather Meeker, ["Açık Kaynak Kodlu Yazılım: Uygunluk Esasları ve En İyi Uygulamalar"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+  </p>
 </aside>
 
 * **Patentler:** Şirketiniz, üyelerin büyük açık kaynaklı projeleri kullanmalarını korumak için ortak bir savunma patenti havuzu olan [Açık Buluşma Ağı](https://www.openinventionnetwork.com/)'na katılmak veya başka bir [alternatif patent lisansını](https://www.eff.org/document/hacking-patent-system-2016) keşfetmek isteyebilir.
diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index f09df79a75a..73f2f1ff1d3 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -31,11 +31,11 @@ _Özgür yazılım_ , _açık kaynak ile_ aynı proje grubunu ifade eder. Bazen
 ### İnsanlar neden işlerini açık kaynak olarak sunarlar?
 
 <aside markdown="1" class="pquote">
-    <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
-    Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.
-    <p markdown="1" class="pquote-credit">
-- @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
-    </p>
+  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+  Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.
+  <p markdown="1" class="pquote-credit">
+— @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+  </p>
 </aside>
 
 Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler:
@@ -75,11 +75,11 @@ Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahi
 Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız.
 
 <aside markdown="1" class="pquote">
-    <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
-    Bir noktada kullandığım özel bir UIAlertView yarattım ... ve açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca diğer geliştiricilere projelerinde nasıl kullanacaklarını açıklayan ilk belgelerimi yazdım. Muhtemelen hiç kimse onu kullanmamıştı çünkü basit bir projeydi ama katkım konusunda kendimi iyi hissediyordum.
-    <p markdown="1" class="pquote-credit">
-- @mavris, ["Kendi Kendine Öğrenen Yazılım Geliştiricileri: Açık Kaynak Neden Bizim İçin Önemli?"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
-    </p>
+  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+  Bir noktada kullandığım özel bir UIAlertView yarattım ... ve açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca diğer geliştiricilere projelerinde nasıl kullanacaklarını açıklayan ilk belgelerimi yazdım. Muhtemelen hiç kimse onu kullanmamıştı çünkü basit bir projeydi ama katkım konusunda kendimi iyi hissediyordum.
+  <p markdown="1" class="pquote-credit">
+— @mavris, ["Kendi Kendine Öğrenen Yazılım Geliştiricileri: Açık Kaynak Neden Bizim İçin Önemli?"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+  </p>
 </aside>
 
 Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir.
@@ -91,11 +91,11 @@ Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve
 Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın.
 
 <aside markdown="1" class="pquote">
-    <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-    Projeyi açmaya başladığınızda, yönetim süreçlerinizin projenizdeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. İşletmenizde istihdam edilmeyen katılımcıları, projenin kilit noktalarına dahil etmekten korkmayın - özellikle de sık sık katkıda bulunanlarsa.
-    <p markdown="1" class="pquote-credit">
+  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+  Projeyi açmaya başladığınızda, yönetim süreçlerinizin projenizdeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. İşletmenizde istihdam edilmeyen katılımcıları, projenin kilit noktalarına dahil etmekten korkmayın - özellikle de sık sık katkıda bulunanlarsa.
+  <p markdown="1" class="pquote-credit">
 — @captainsafia, ["Öyleyse bir açık kaynak proje açmak istiyorsun, ha?"](Https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
-    </p>
+  </p>
 </aside>
 
 ### Diğer projelere katkıda bulunmak
@@ -149,11 +149,11 @@ README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını
 README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin.
 
 <aside markdown="1" class="pquote">
-    <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
-    Daha iyi belgeler, daha fazla kullanıcı, daha az destek talebi ve daha fazla katkıda bulunan anlamına gelir. (...) Unutma ki okuyucuların sen değilsin. Tamamen farklı deneyimlerle projeye gelebilecek insanlar var.
-    <p markdown="1" class="pquote-credit">
+  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+  Daha iyi belgeler, daha fazla kullanıcı, daha az destek talebi ve daha fazla katkıda bulunan anlamına gelir. (...) Unutma ki okuyucuların sen değilsin. Tamamen farklı deneyimlerle projeye gelebilecek insanlar var.
+  <p markdown="1" class="pquote-credit">
 - @tracymakes, ["Yazdıkların okunuyor (video)")(https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
-    </p>
+  </p>
 </aside>
 
 Bazen, insanlar bir README yazmaktan kaçınırlar çünkü proje bitmemiş gibi hissederler veya katkı kabul etmek istemezler. Bunların hepsi yazmak için çok iyi nedenler.
@@ -178,7 +178,7 @@ Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi
 
 Sıcak, arkadaşça bir ton kullanmak ve katkılar için özel önerilerde bulunmak (örneğin, dokümantasyon yazmak veya bir web sitesi yapmak gibi) yeni gelenlerin kendilerini memnun ve istekli hissetmelerini sağlama konusunda yardımcı olabilir.
 
-Örneğin, [Active Admin](https://github.com/activeadmin/activeadmin/) [katkıda bulunan rehberine](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) şu şekilde başlar:
+Örneğin, [Active Admin](https://github.com/activeadmin/activeadmin/) [katkıda bulunan rehberine](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) şu şekilde başlar:
 
 > Öncelikle, Active Admin’e katkıda bulunduğunuz için teşekkür ederiz. Active Admin'i harika bir araç yapan sizin gibi insanlar.
 
@@ -195,11 +195,11 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan
 ### Davranış kural listesi oluşturmak
 
 <aside markdown="1" class="pquote">
-    <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
-    Hepimiz, muhtemelen bir şeyin neden belli bir şekilde olması gerektiğini açıklamaya çalışan bir geliştirici olarak ya da bir kullanıcı olarak... basit bir soru sormakla ... ... kötüye kullanılan şeyin yaşadığı deneyimlerimiz oldu. (...) Davranış kuralları, ekibinizin yapıcı söylemleri çok ciddiye aldığını gösteren, kolayca referans verilen ve bağlanabilir bir belge haline gelir.
-    <p markdown="1" class="pquote-credit">
-- @mlynch, ["Açık Kaynağı Daha Mutlu Bir Yer Yapma"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
-    </p>
+  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+  Hepimiz, muhtemelen bir şeyin neden belli bir şekilde olması gerektiğini açıklamaya çalışan bir geliştirici olarak ya da bir kullanıcı olarak... basit bir soru sormakla ... ... kötüye kullanılan şeyin yaşadığı deneyimlerimiz oldu. (...) Davranış kuralları, ekibinizin yapıcı söylemleri çok ciddiye aldığını gösteren, kolayca referans verilen ve bağlanabilir bir belge haline gelir.
+  <p markdown="1" class="pquote-credit">
+— @mlynch, ["Açık Kaynağı Daha Mutlu Bir Yer Yapma"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+  </p>
 </aside>
 
 Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır.
@@ -246,11 +246,11 @@ Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici b
 Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri.
 
 <aside markdown="1" class="pquote">
-    <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-    Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.
-    <p markdown="1" class="pquote-credit">
-- [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
-    </p>
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.
+  <p markdown="1" class="pquote-credit">
+— [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
 </aside>
 
 Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün.

From 3d1d220dff0a5d1ec70406c2e4e17cf86a0a4ccc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 20 Jul 2020 01:45:28 +0300
Subject: [PATCH 035/749] Minor fix on indentation

---
 _articles/tr/building-community.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md
index 3f23d731ddb..63fc0b6431c 100644
--- a/_articles/tr/building-community.md
+++ b/_articles/tr/building-community.md
@@ -44,7 +44,7 @@ Belgelerinizle başlayın:
 <aside markdown="1" class="pquote">
   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/mikeal?s=180">
   Bazıları için açık kaynağa katkıda bulunmak diğerlerinden daha kolaydır. Doğru bir şey yapmamak ya da sadece uyum sağlamaktan bağırmaktan korkmak çok fazla. (...) Katkıda bulunanlara çok düşük teknik yeterliliğe (dokümantasyon, web içeriği işaretleme, vb.) Katkıda bulunacak bir yer vererek bu kaygılar.
-    <p markdown="1" class="pquote-credit">
+  <p markdown="1" class="pquote-credit">
 — @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
   </p>
 </aside>

From c972bcc271f4284c05a359e800d923172a2e3a9d Mon Sep 17 00:00:00 2001
From: Mike Linksvayer <mlinksva@github.com>
Date: Sun, 19 Jul 2020 17:41:56 -0700
Subject: [PATCH 036/749] master->HEAD

---
 _articles/tr/best-practices.md     | 2 +-
 _articles/tr/starting-a-project.md | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md
index 100a06a1bdc..5427fe39a07 100644
--- a/_articles/tr/best-practices.md
+++ b/_articles/tr/best-practices.md
@@ -72,7 +72,7 @@ Yazmaya değer birkaç kural:
 * Bekleme süresi ne kadardır (_örneğin, "7 gün içinde bir bakıcıdan bir yanıt bekleyebilirsiniz. O zamana kadar bir şey duymadıysanız, ipliğe ping atmaktan çekinmeyin."_)
 * Projeye ne kadar zaman harcıyorsunuz (_örneğin, "Bu projeye haftada sadece 5 saat harcıyoruz"_)
 
-[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) ve [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) geliştiriciler ve katkıda bulunanlar için temel kuralları olan projelere birkaç örnektir.
+[Jekyll](https://github.com/jekyll/jekyll/tree/HEAD/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) ve [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) geliştiriciler ve katkıda bulunanlar için temel kuralları olan projelere birkaç örnektir.
 
 ### İletişimi herkese açık tutun
 
diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index 73f2f1ff1d3..63621017f3d 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -186,9 +186,9 @@ Projenizin ilk aşamalarında, CONTRIBUTING dosyanız basit olabilir. Hataların
 
 Zamanla, CONTRIBUTING dosyanıza sıkça sorulan diğer soruları ekleyebilirsiniz. Bu bilgileri yazmak, daha az kişinin size aynı soruları tekrar soracağı anlamına gelir.
 
-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/master/CONTRIBUTING-template.md) veya @mozilla'nın ["Bir CONTRIBUTING.md Nasıl Oluşturulur"](https://mozillascience.github.io/working-open-workshop/contributing/) makalesine bakabilirsiniz.
+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.
 
-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/master/CONTRIBUTING-template.md) veya @mozilla'nın ["Bir CONTRIBUTING.md Nasıl Oluşturulur"](https://mozillascience.github.io/working-open-workshop/contributing/) makalesine bakabilirsiniz.
+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.
 

From 837a51ff508e91f0bc82f46beb3be0e3e4a9c777 Mon Sep 17 00:00:00 2001
From: William Sandres <33907565+HakaCode@users.noreply.github.com>
Date: Wed, 29 Jul 2020 23:00:15 -0300
Subject: [PATCH 037/749] =?UTF-8?q?corre=C3=A7=C3=A3o=20de=20erro=20de=20d?=
 =?UTF-8?q?igita=C3=A7=C3=A3o?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Acredito em ter arrumado o erro de digitação.
---
 _articles/pt/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index f5cf3244ec3..9b02b69aa57 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -23,7 +23,7 @@ O open source é poderoso porque diminui as barreiras para adoção, o que permi
 Para entender como funciona, imagine que seu amigo está dando uma festa, e você leva uma torta de cereja.
 
 * Todos experimentam a torta (_usa_)
-* A torta é um sucesso! Eles te pedem a receita, que você disponibilizai (_vê_)
+* A torta é um sucesso! Eles te pedem a receita, que você disponibiliza (_vê_)
 * Um amigo, Alex, que é um chefe de pastelaria, sugere reduzir o açúcar (_modifica_)
 * Outra amiga, Lisa, pede para utilizá-la em um jantar na próxima semana (_distribui_)
 

From cfec46988704124447ee78c11a72565661cf8903 Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Fri, 7 Aug 2020 14:26:59 +0000
Subject: [PATCH 038/749] Bump github-pages from 206 to 207

Bumps [github-pages](https://github.com/github/pages-gem) from 206 to 207.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v206...v207)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 36 +++++++++++++++++++++++-------------
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 3f08f091811..b8af9284227 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (6.0.3.1)
+    activesupport (6.0.3.2)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
@@ -17,8 +17,8 @@ GEM
     commonmarker (0.17.13)
       ruby-enum (~> 0.5)
     concurrent-ruby (1.1.6)
-    dnsruby (1.61.3)
-      addressable (~> 2.5)
+    dnsruby (1.61.4)
+      simpleidn (~> 0.1)
     em-websocket (0.5.1)
       eventmachine (>= 0.12.9)
       http_parser.rb (~> 0.6.0)
@@ -28,12 +28,12 @@ GEM
     execjs (2.7.0)
     faraday (1.0.1)
       multipart-post (>= 1.2, < 3)
-    ffi (1.12.2)
+    ffi (1.13.1)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (206)
+    github-pages (207)
       github-pages-health-check (= 1.16.1)
-      jekyll (= 3.8.7)
+      jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
       jekyll-coffeescript (= 1.1.1)
       jekyll-commonmark-ghpages (= 0.1.6)
@@ -67,7 +67,8 @@ GEM
       jekyll-theme-time-machine (= 0.1.1)
       jekyll-titles-from-headings (= 0.5.3)
       jemoji (= 0.11.1)
-      kramdown (= 1.17.0)
+      kramdown (= 2.3.0)
+      kramdown-parser-gfm (= 1.1.0)
       liquid (= 4.0.3)
       mercenary (~> 0.3)
       minima (= 2.5.1)
@@ -80,7 +81,7 @@ GEM
       octokit (~> 4.0)
       public_suffix (~> 3.0)
       typhoeus (~> 1.3)
-    html-pipeline (2.12.3)
+    html-pipeline (2.13.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
     html-proofer (3.15.3)
@@ -94,14 +95,14 @@ GEM
     http_parser.rb (0.6.0)
     i18n (0.9.5)
       concurrent-ruby (~> 1.0)
-    jekyll (3.8.7)
+    jekyll (3.9.0)
       addressable (~> 2.4)
       colorator (~> 1.0)
       em-websocket (~> 0.5)
       i18n (~> 0.7)
       jekyll-sass-converter (~> 1.0)
       jekyll-watch (~> 2.0)
-      kramdown (~> 1.14)
+      kramdown (>= 1.17, < 3)
       liquid (~> 4.0)
       mercenary (~> 0.3.3)
       pathutil (~> 0.9)
@@ -199,7 +200,10 @@ GEM
       gemoji (~> 3.0)
       html-pipeline (~> 2.2)
       jekyll (>= 3.0, < 5.0)
-    kramdown (1.17.0)
+    kramdown (2.3.0)
+      rexml
+    kramdown-parser-gfm (1.1.0)
+      kramdown (~> 2.0)
     liquid (4.0.3)
     listen (3.2.1)
       rb-fsevent (~> 0.10, >= 0.10.3)
@@ -212,7 +216,7 @@ GEM
       jekyll-seo-tag (~> 2.1)
     minitest (5.14.1)
     multipart-post (2.1.1)
-    nokogiri (1.10.9)
+    nokogiri (1.10.10)
       mini_portile2 (~> 2.4.0)
     nokogumbo (2.0.2)
       nokogiri (~> 1.8, >= 1.8.4)
@@ -228,6 +232,7 @@ GEM
     rb-fsevent (0.10.4)
     rb-inotify (0.10.1)
       ffi (~> 1.0)
+    rexml (3.2.4)
     rouge (3.19.0)
     ruby-enum (0.8.0)
       i18n
@@ -241,6 +246,8 @@ GEM
     sawyer (0.8.2)
       addressable (>= 2.3.5)
       faraday (> 0.8, < 2.0)
+    simpleidn (0.1.1)
+      unf (~> 0.1.4)
     terminal-table (1.8.0)
       unicode-display_width (~> 1.1, >= 1.1.1)
     thread_safe (0.3.6)
@@ -248,9 +255,12 @@ GEM
       ethon (>= 0.9.0)
     tzinfo (1.2.7)
       thread_safe (~> 0.1)
+    unf (0.1.4)
+      unf_ext
+    unf_ext (0.0.7.7)
     unicode-display_width (1.7.0)
     yell (2.2.2)
-    zeitwerk (2.3.0)
+    zeitwerk (2.4.0)
 
 PLATFORMS
   ruby

From 96ae6ed6bbeac102abc2517162d867d396aa4775 Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Sun, 9 Aug 2020 22:51:32 +0800
Subject: [PATCH 039/749] Created new ms language folder

---
 _articles/ms/best-practices.txt | 286 ++++++++++++++++++++++++++++++++
 1 file changed, 286 insertions(+)
 create mode 100644 _articles/ms/best-practices.txt

diff --git a/_articles/ms/best-practices.txt b/_articles/ms/best-practices.txt
new file mode 100644
index 00000000000..6002e651e1c
--- /dev/null
+++ b/_articles/ms/best-practices.txt
@@ -0,0 +1,286 @@
+---
+lang: ms
+title: Memulakan projek sumber terbuka
+description: Ketahui lebih lanjut mengenai dunia sumber terbuka dan bersiap sedia untuk melancarkan projek anda sendiri.
+class: best-practices
+toc:
+  what-does-it-mean-to-be-a-maintainer: "Apa maksudnya menjadi pemelihara?"
+  documenting-your-processes: "Mendokumentasikan proses anda"
+  learning-to-say-no: "Belajar bila untuk mengatakan tidak"
+  leverage-your-community: "Macamana manfaatkan komuniti anda"
+  bring-in-the-robots: "belajar proses mana yang perlu automatik (robots)"
+  its-okay-to-hit-pause: "Tidak apa-apa untuk berhenti sebentar"
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+  - metrics
+  - leadership
+---
+
+## Apa maksudnya menjadi penyelenggara projek sumber terbuka ?
+
+Sekiranya anda mengekalkan projek sumber terbuka yang digunakan oleh banyak orang, anda mungkin menyedari bahawa anda kurang mengekod dan lebih banyak menjawab masalah.
+
+Pada peringkat awal projek, anda bereksperimen dengan idea baru dan membuat keputusan berdasarkan apa yang anda mahukan. Apabila projek anda semakin popular, anda akan dapat bekerja dengan pengguna dan penyumbang anda lebih banyak.
+
+Menyelenggara projek memerlukan lebih daripada sekadar kod. Tugas-tugas ini sering tidak dijangka, tetapi sama pentingnya dengan projek yang sedang berkembang. Kami telah mengumpulkan beberapa cara untuk menjadikan hidup anda lebih mudah, dari proses pendokumentasian hingga memanfaatkan komuniti anda.
+
+## Mendokumentasikan proses anda
+
+Menulis perkara adalah salah satu perkara terpenting yang boleh anda lakukan sebagai penyelenggara.
+
+Dokumentasi bukan sahaja menjelaskan pemikiran anda sendiri, tetapi membantu orang lain memahami apa yang anda perlukan atau harapkan, bahkan sebelum mereka bertanya.
+
+Menulis perkara menjadi lebih mudah untuk mengatakan tidak apabila sesuatu tidak sesuai dengan skop anda. Ini juga memudahkan orang untuk masuk dan menolong. Anda tidak pernah tahu siapa yang mungkin membaca atau menggunakan projek anda.
+
+Walaupun anda tidak menggunakan perenggan penuh, mencatat titik peluru lebih baik daripada tidak menulis sama sekali.
+
+Ingatlah untuk memastikan dokumentasi anda sentiasa terkini. Sekiranya anda tidak dapat selalu melakukan ini, hapus dokumentasi anda yang sudah lapuk atau nyatakan bahawa ia sudah lapuk sehingga penyumbang tahu kemas kini dialu-alukan.
+
+### Tuliskan visi projek anda
+
+Mulakan dengan menuliskan matlamat projek anda. Tambahkan mereka ke README anda, atau buat fail berasingan yang disebut VISION. Sekiranya ada artifak lain yang dapat membantu, seperti peta jalan projek, buat juga umum.
+
+Mempunyai visi yang jelas dan didokumentasikan membuat anda tetap fokus dan membantu anda mengelakkan "jangkauan skop" dari sumbangan orang lain.
+
+Sebagai contoh, @lord mendapati bahawa mempunyai visi projek membantunya mengetahui permintaan mana yang perlu diluangkan. Sebagai penyelenggara baru, dia menyesal tidak berpegang pada skop projeknya ketika dia mendapat permintaan fitur pertama untuk [Slate] (https://github.com/lord/slate).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
+  Saya meraba-raba. Saya tidak berusaha mencari penyelesaian yang lengkap. Sebagai ganti penyelesaian separuh, saya harap saya mengatakan "Saya tidak mempunyai masa untuk ini sekarang, tetapi saya akan menambahkannya ke dalam senarai jangka panjang yang bagus."
+  <p markdown="1" class="pquote-credit">
+— @lord, ["Petua untuk penyelenggara sumber terbuka baru"](https://lord.io/blog/2014/oss-tips/)
+  </p>
+</aside>
+
+### Sampaikan harapan anda
+
+Peraturan boleh mengganggu untuk menuliskannya. Kadang-kadang anda mungkin merasa seperti mengawal tingkah laku orang lain atau membunuh semua keseronokan.
+
+Ditulis dan dikuatkuasakan dengan adil, bagaimanapun, peraturan yang baik memberi kuasa kepada penyelenggara. Mereka menghalang anda daripada diseret untuk melakukan perkara yang tidak mahu anda lakukan.
+
+Sebilangan besar orang yang menemui projek anda tidak mengetahui apa-apa tentang anda atau keadaan anda. Mereka mungkin menganggap anda dibayar untuk mengusahakannya, terutamanya jika ia adalah sesuatu yang selalu mereka gunakan dan bergantung. Mungkin pada satu ketika anda meluangkan banyak masa ke dalam projek anda, tetapi sekarang anda sibuk dengan pekerjaan baru atau ahli keluarga.
+
+Semua ini baik-baik saja! Pastikan orang lain tahu mengenainya.
+
+Sekiranya mengekalkan projek anda secara sambilan atau secara sukarela, jujurlah berapa banyak masa yang anda ada. Ini tidak sama dengan berapa banyak masa yang anda fikirkan memerlukan projek itu, atau berapa banyak masa yang orang lain mahu anda habiskan.
+
+Berikut adalah beberapa peraturan yang perlu ditulis:
+
+* Bagaimana sumbangan dikaji dan diterima (_Adakah mereka memerlukan ujian? Templat masalah?_)
+* Jenis sumbangan yang akan anda terima (_Adakah anda hanya memerlukan bantuan dengan bahagian tertentu kod anda?_)
+* Bila sesuai untuk ditindaklanjuti (_sebagai contoh, "Anda dapat mengharapkan tindak balas dari penjaga dalam masa 7 hari. Sekiranya anda belum mendengar apa-apa pada masa itu, jangan ragu untuk melakukan ping."_)
+* Berapa banyak masa yang anda habiskan untuk projek itu (_sebagai contoh, "Kami hanya menghabiskan kira-kira 5 jam seminggu untuk projek ini"_)
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), dan [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) adalah beberapa contoh projek dengan peraturan asas untuk penyelenggara dan penyumbang.
+
+### Jaga komunikasi secara terbuka
+
+Jangan lupa untuk mendokumentasikan interaksi anda juga. Di mana sahaja anda boleh, teruskan komunikasi mengenai projek anda kepada umum. Sekiranya seseorang cuba menghubungi anda secara peribadi untuk membincangkan permintaan ciri atau keperluan sokongan, arahkan mereka dengan sopan ke saluran komunikasi awam, seperti senarai mel atau pelacak masalah.
+
+Sekiranya anda bertemu dengan penyelenggara lain, atau membuat keputusan utama secara tertutup, dokumentasikan perbualan ini di khalayak ramai, walaupun hanya menghantar catatan anda.
+
+Dengan cara itu, sesiapa sahaja yang menyertai komuniti anda akan mendapat akses kepada maklumat yang sama dengan seseorang yang berada di sana selama bertahun-tahun.
+
+## Belajar bila untuk mengatakan tidak
+
+Anda telah menulis perkara. Sebaik-baiknya, semua orang akan membaca dokumentasi anda, tetapi pada hakikatnya, anda harus mengingatkan orang lain bahawa pengetahuan ini ada.
+
+Akan tetapi, segala sesuatu yang ditulis dapat membantu melumpuhkan situasi ketika anda perlu menguatkuasakan peraturan anda.
+
+Mengatakan tidak tidak menyenangkan, tetapi _ "Sumbangan anda tidak sesuai dengan kriteria projek ini" _ terasa kurang peribadi daripada _ "Saya tidak suka sumbangan anda" _.
+
+Mengatakan tidak berlaku untuk banyak situasi yang akan anda hadapi sebagai penjaga: permintaan ciri yang tidak sesuai dengan ruang lingkup, seseorang menggelincirkan perbincangan, melakukan pekerjaan yang tidak perlu untuk orang lain.
+
+### Pastikan perbualan tetap mesra
+
+Salah satu tempat paling penting yang akan anda praktikkan dengan mengatakan tidak adalah masalah anda dan tarik permintaan. Sebagai penyelenggara projek, anda pasti akan menerima cadangan yang tidak mahu anda terima.
+
+Mungkin sumbangan itu mengubah skop projek anda atau tidak sesuai dengan visi anda. Mungkin idea itu bagus, tetapi pelaksanaannya kurang baik.
+
+Terlepas dari alasannya, adalah mungkin untuk menangani sumbangan yang tidak sesuai dengan standard projek anda.
+
+Sekiranya anda menerima sumbangan yang tidak mahu anda terima, reaksi pertama anda mungkin adalah mengabaikannya atau berpura-pura tidak melihatnya. Melakukannya boleh menyakitkan perasaan orang lain dan bahkan menurunkan semangat penyumbang lain dalam komuniti anda.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
+  Kunci untuk menangani sokongan untuk projek sumber terbuka berskala besar adalah memastikan masalah terus berjalan. Cuba untuk mengelakkan masalah. Sekiranya anda seorang pembangun iOS, anda pasti tahu betapa sukarnya menghantar radar. Anda mungkin akan mendengar 2 tahun kemudian, dan diberitahu untuk mencuba lagi dengan versi iOS terkini.
+  <p markdown="1" class="pquote-credit">
+— @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
+  </p>
+</aside>
+
+Jangan biarkan sumbangan yang tidak diingini terbuka kerana anda merasa bersalah atau mahu bersikap baik. Lama kelamaan, masalah dan PR anda yang tidak dijawab akan menjadikan kerja projek anda terasa lebih tertekan dan menakutkan.
+
+Lebih baik segera menutup sumbangan yang anda tahu yang anda tidak mahu terima. Sekiranya projek anda sudah mengalami tunggakan yang besar, @steveklabnik mempunyai cadangan untuk [bagaimana menyelesaikan masalah dengan cekap](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+
+Kedua, mengabaikan sumbangan akan memberi isyarat negatif kepada komuniti anda. Menyumbang kepada projek boleh menakutkan, terutamanya jika ini pertama kali seseorang. Walaupun anda tidak menerima sumbangan mereka, terima kasih orang yang berada di belakangnya dan terima kasih atas minat mereka. Ini pujian besar!
+
+Sekiranya anda tidak mahu menerima sumbangan:
+
+* **Mengucapkan Terima kasih** atas sumbangan mereka
+* **Jelaskan mengapa ia tidak sesuai** dengan skop projek, dan berikan cadangan yang jelas untuk penambahbaikan, jika anda mampu. Bersikap baik, tetapi tegas.
+* **Pautan ke dokumentasi yang relevan**, jika anda memilikinya. Sekiranya anda melihat permintaan berulang untuk perkara yang tidak mahu anda terima, tambahkan permintaan tersebut ke dalam dokumentasi anda untuk mengelakkan diri anda berulang.
+* **Tutup permintaan**
+
+Anda tidak memerlukan lebih daripada 1-2 ayat untuk bertindak balas. Sebagai contoh, apabila pengguna[celery](https://github.com/celery/celery/) melaporkan ralat berkaitan Windows, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):
+
+![Celery screenshot](/assets/images/best-practices/celery.png)
+
+Sekiranya memikirkan untuk tidak menakutkan anda, anda tidak sendirian. Sebagai @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> Saya telah bercakap dengan penyelenggara dari beberapa projek sumber terbuka yang berbeza, Mesos, Kubernetes, Chromium, dan mereka semua bersetuju bahawa salah satu bahagian yang paling sukar untuk menjadi penyelenggara adalah mengatakan "Tidak" untuk membetulkan yang tidak anda mahukan.
+
+Jangan merasa bersalah kerana tidak mahu menerima sumbangan seseorang. Peraturan pertama sumber terbuka, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Tidak adalah sementara, ya adalah selamanya." _ Walaupun berempati dengan semangat orang lain adalah perkara yang baik, menolak sumbangan tidak sama dengan menolak orang di belakangnya."
+
+Pada akhirnya, jika sumbangan tidak cukup baik, anda tidak berkewajiban untuk menerimanya. Bersikap baik dan responsif apabila orang menyumbang kepada projek anda, tetapi hanya menerima perubahan yang anda benar-benar yakin akan menjadikan projek anda lebih baik. Semakin kerap anda berlatih mengatakan tidak, semakin mudah. Janji.
+
+### Bersikap proaktif
+
+Untuk mengurangkan jumlah sumbangan yang tidak diingini, terangkan proses projek anda untuk menghantar dan menerima sumbangan dalam panduan penyumbang anda.
+
+Sekiranya anda menerima terlalu banyak sumbangan berkualiti rendah, minta penyumbang melakukan sedikit kerja terlebih dahulu, misalnya:
+
+* Isi isu atau templat PR / senarai semak
+* Buka masalah sebelum menghantar PR
+
+Sekiranya mereka tidak mematuhi peraturan anda, segera tutup masalahnya dan arahkan ke dokumentasi anda.
+
+Walaupun pendekatan ini mungkin terasa tidak baik pada mulanya, proaktif sebenarnya baik untuk kedua-dua pihak. Ini mengurangkan peluang seseorang untuk meletakkan banyak waktu kerja yang terbuang menjadi permintaan tarik yang tidak akan Anda terima. Dan ini menjadikan beban kerja anda lebih mudah diuruskan.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+  Sebaik-baiknya, jelaskan kepada mereka dan dalam fail CONTRIBUTING.md bagaimana mereka dapat memperoleh petunjuk yang lebih baik di masa depan mengenai perkara yang akan atau tidak akan diterima sebelum mereka memulakan kerja.
+  <p markdown="1" class="pquote-credit">
+— @MikeMcQuaid, ["Permintaan Tarik Penutup dengan Baik"](https://github.com/blog/2124-kindly-closing-pull-requests)
+  </p>
+</aside>
+
+Kadang kala, apabila anda mengatakan tidak, calon penyumbang anda mungkin marah atau mengecam keputusan anda. Sekiranya tingkah laku mereka menjadi bermusuhan, [ambil langkah untuk meredakan keadaan](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively.
+
+### Ikuti bimbingan
+
+Mungkin seseorang dalam komuniti anda kerap menghantar sumbangan yang tidak memenuhi piawaian projek anda. Ini boleh membuat frustasi bagi kedua-dua pihak untuk berulang kali menolak.
+
+Sekiranya anda melihat bahawa seseorang berminat dengan projek anda, tetapi memerlukan sedikit penggilap, bersabarlah. Terangkan dengan jelas dalam setiap situasi mengapa sumbangan mereka tidak memenuhi jangkaan projek. Cuba arahkan mereka ke tugas yang lebih mudah atau tidak samar-samar, seperti masalah yang ditandai _ "isu pertama yang baik", _ agar kaki mereka basah. Sekiranya anda mempunyai masa, pertimbangkan untuk membimbing mereka melalui sumbangan pertama mereka, atau cari orang lain dalam komuniti anda yang mungkin bersedia membimbing mereka.
+
+## Macamana manfaatkan komuniti anda
+
+Anda tidak perlu melakukan semuanya sendiri. Komuniti projek anda wujud dengan alasan! Walaupun anda belum mempunyai komuniti penyumbang aktif, jika anda mempunyai banyak pengguna, buat mereka bekerja.
+
+### Berkongsi beban kerja
+
+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.
+
+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.
+
+Menggalakkan orang lain untuk [berkongsi pemilikan projek](../building-community/#share-ownership-of-your-project) dapat mengurangkan beban kerja anda sendiri, seperti yang dijumpai oleh @lmccart pada projeknya, [p5.js](https://github.com/processing/p5.js).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
+  Saya pernah berkata, "Ya, sesiapa sahaja boleh terlibat, anda tidak perlu mempunyai banyak kepakaran pengekodan [...]." Kami ada orang yang mendaftar untuk datang [ke suatu acara] dan ketika itulah saya benar-benar bertanya-tanya: adakah ini benar, apa yang saya katakan? Akan ada 40 orang yang muncul, dan sepertinya saya tidak boleh duduk bersama mereka masing-masing ... Tetapi orang-orang datang bersama, dan ia cukup berjaya. Sebaik sahaja seseorang mendapatkannya, mereka dapat mengajar jiran mereka.
+  <p markdown="1" class="pquote-credit">
+—  @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+  </p>
+</aside>
+
+Sekiranya anda perlu menjauhkan diri dari projek anda, sama ada dalam masa rehat atau kekal, tidak ada rasa malu untuk meminta orang lain mengambil alih tugas anda.
+
+Sekiranya orang lain berminat dengan arahannya, beri mereka akses atau menyerahkan kawalan secara rasmi kepada orang lain. Sekiranya seseorang membuat projek anda secara aktif dan secara aktif menyelenggarakannya di tempat lain, pertimbangkan untuk menghubungkan ke garpu dari projek asal anda. Senang sekali bahawa ramai orang mahu projek anda terus berjalan!
+
+@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) mendokumentasikan visi untuk projeknya, [Dokku](https://github.com/dokku/dokku), membantu tujuan tersebut terus dicapai walaupun dia melangkah keluar dari projek:
+
+> Saya menulis halaman wiki yang menerangkan apa yang saya mahukan dan mengapa saya menginginkannya. Atas sebab-sebab tertentu, mengejutkan saya bahawa penyelenggara mula memindahkan projek ke arah itu! Adakah ia berlaku seperti bagaimana saya melakukannya? Tidak selalu. Tetapi projek ini masih mendekatkan apa yang saya tulis.
+
+### Biarkan orang lain membina penyelesaian yang mereka perlukan
+
+Sekiranya calon penyumbang mempunyai pendapat yang berbeza mengenai apa yang harus dilakukan oleh projek anda, anda mungkin ingin mendorong mereka untuk mengusahakan garpu mereka dengan lembut.
+
+Memaksa projek tidak harus menjadi perkara yang buruk. Mampu menyalin dan mengubahsuai projek adalah salah satu perkara terbaik mengenai sumber terbuka. Menggalakkan ahli komuniti anda untuk bekerja di garpu mereka sendiri dapat menyediakan saluran kreatif yang mereka perlukan, tanpa bertentangan dengan visi projek anda.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
+  Saya memenuhi kes penggunaan 80%. Sekiranya anda adalah salah satu unicorn, sila buat kerja saya. Saya tidak akan tersinggung! Projek awam saya hampir selalu bertujuan untuk menyelesaikan masalah yang paling biasa; Saya berusaha mempermudah saya dengan lebih mendalam dengan mengerjakan kerja saya atau memanjangkannya.
+  <p markdown="1" class="pquote-credit">
+— @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+  </p>
+</aside>
+
+Perkara yang sama berlaku untuk pengguna yang benar-benar mahukan penyelesaian yang anda tidak mempunyai lebar jalur untuk dibina. Menawarkan API dan penyesuaian penyesuaian dapat membantu orang lain memenuhi keperluan mereka sendiri, tanpa harus mengubah sumbernya secara langsung. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) pemalam yang menggalakkan untuk CocoaPod membawa kepada "beberapa idea yang paling menarik":
+
+> Hampir tidak dapat dielakkan apabila projek menjadi besar, penyelenggara harus menjadi lebih konservatif mengenai bagaimana mereka memperkenalkan kod baru. Anda menjadi pandai mengatakan "tidak", tetapi banyak orang mempunyai keperluan yang sah. Oleh itu, anda akhirnya menukar alat anda menjadi platform.
+
+## Belajar proses mana yang perlu automatik (robots)
+
+Sama seperti ada tugas yang dapat ditolong oleh orang lain, ada juga tugas yang tidak perlu dilakukan oleh manusia. Robot adalah rakan anda. Gunakan mereka untuk menjadikan hidup anda sebagai penyelenggara lebih mudah.
+
+### Memerlukan ujian dan pemeriksaan lain untuk meningkatkan kualiti kod anda
+
+Salah satu cara terpenting untuk mengautomasikan projek anda adalah dengan menambahkan ujian.
+
+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.
+
+Sekiranya anda menambahkan ujian, pastikan untuk menerangkan bagaimana ia berfungsi dalam fail CONTRIBUTING anda.
+<aside markdown="1" class="pquote">
+  <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)
+  </p>
+</aside>
+
+### Gunakan alat untuk mengautomasikan tugas penyelenggaraan asas
+
+Berita baik tentang mengekalkan projek yang popular ialah penyelenggara lain mungkin menghadapi masalah serupa dan membina jalan penyelesaian untuknya.
+
+Terdapat [pelbagai alat tersedia](https://github.com/showcases/tools-for-open-source)untuk membantu mengautomasikan beberapa aspek kerja penyelenggaraan. Beberapa contoh:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) mengautomasikan siaran anda
+* [mention-bot](https://github.com/facebook/mention-bot) menyebut pengulas berpotensi untuk permintaan tarik
+* [Danger](https://github.com/danger/danger) membantu mengautomasikan semakan kod
+* [no-response](https://github.com/probot/no-response) menutup masalah di mana pengarang tidak menjawab permintaan untuk mendapatkan maklumat lebih lanjut
+* [dependabot-preview](https://github.com/marketplace/dependabot-preview) memeriksa fail kebergantungan anda setiap hari untuk keperluan yang ketinggalan zaman dan membuka permintaan tarikan individu untuk apa sahaja yang dijumpainya
+
+Fatau laporan pepijat dan sumbangan umum lain, GitHub mempunyai [Templat Masalah dan Templat Tarik Permintaan] (https://github.com/blog/2111-issue-and-pull-request-templates), yang boleh anda buat untuk melancarkan komunikasi anda terima. @TalAter membuat [Pilih panduan Pengembaraan Anda Sendiri] (https://www.talater.com/open-source-templates/#/) untuk membantu anda menulis isu dan templat PR anda.
+
+Untuk menguruskan pemberitahuan e-mel anda, anda boleh menyiapkan [penapis e-mel] (https://github.com/blog/2203-email-updates-about-your-own-activity) untuk disusun mengikut keutamaan.
+
+Sekiranya anda ingin mendapatkan sedikit lebih maju, panduan gaya dan pelapis dapat menyeragamkan sumbangan projek dan menjadikannya lebih mudah untuk disemak dan diterima.
+
+Namun, jika piawaian anda terlalu rumit, ia dapat meningkatkan halangan untuk menyumbang. Pastikan anda hanya menambahkan peraturan yang cukup untuk menjadikan kehidupan semua orang lebih mudah.
+
+Sekiranya anda tidak pasti alat mana yang harus digunakan, perhatikan apa yang dilakukan oleh projek popular lain, terutamanya yang ada di ekosistem anda. Sebagai contoh, bagaimana proses sumbangan untuk modul Node yang lain? Menggunakan alat dan pendekatan yang serupa juga akan menjadikan proses anda lebih akrab dengan penyumbang sasaran anda.
+
+## Tidak apa-apa untuk berhenti sebentar
+
+Kerja sumber terbuka sekali memberikan kegembiraan kepada anda. Mungkin sekarang ini mula membuat anda merasa terhindar atau bersalah.
+
+Mungkin anda merasa terharu atau rasa takut yang semakin meningkat ketika anda memikirkan projek anda. Sementara itu, permasalahan dan permintaan tarik semakin bertambah.
+
+Burnout adalah masalah yang nyata dan meluas dalam kerja sumber terbuka, terutama di kalangan penyelenggara. Sebagai penjaga, kebahagiaan anda adalah syarat yang tidak dapat dirundingkan untuk kelangsungan projek sumber terbuka mana pun.
+
+Walaupun tidak boleh dikatakan, berehat sebentar! Anda tidak perlu menunggu sehingga anda merasa terbakar untuk bercuti. @brettcannon, pemaju teras Python, memutuskan untuk mengambil [percutian selama sebulan] (https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) setelah 14 tahun OSS sukarela bekerja.
+
+Sama seperti jenis pekerjaan lain, berehat sebentar akan membuat anda segar, gembira, dan gembira dengan pekerjaan anda.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
+  Dalam mengekalkan WP-CLI, saya mendapati bahawa saya harus membuat diri saya bahagia terlebih dahulu, dan menetapkan batasan yang jelas mengenai penglibatan saya. Imbangan terbaik yang saya dapati adalah 2-5 jam seminggu, sebagai sebahagian daripada jadual kerja biasa saya. Ini menjadikan penglibatan saya menjadi minat, dan daripada merasa terlalu suka bekerja. Kerana saya mengutamakan masalah yang sedang saya jalankan, saya dapat membuat kemajuan secara berkala terhadap perkara yang saya rasa paling penting.
+  <p markdown="1" class="pquote-credit">
+— @danielbachhuber, ["Takziah, anda sekarang menjadi penyelenggara projek sumber terbuka yang popular"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+  </p>
+</aside>
+
+Kadang-kadang, sukar untuk mengambil cuti dari kerja sumber terbuka apabila terasa seperti semua orang memerlukan anda. Orang mungkin juga berusaha membuat anda merasa bersalah kerana melangkah pergi.
+
+Lakukan yang terbaik untuk mencari sokongan untuk pengguna dan komuniti anda semasa anda jauh dari projek. Sekiranya anda tidak dapat mencari sokongan yang anda perlukan, istirahatlah pula. Pastikan anda berkomunikasi ketika anda tidak ada, sehingga orang tidak bingung dengan kekurangan respons anda.
+
+Beristirahat juga berlaku untuk lebih daripada sekadar percutian. Sekiranya anda tidak mahu melakukan kerja sumber terbuka pada hujung minggu, atau semasa waktu kerja, sampaikan harapan tersebut kepada orang lain, sehingga mereka tahu untuk tidak mengganggu anda.
+
+## Jaga diri anda terlebih dahulu!
+
+Mengekalkan projek yang popular memerlukan kemahiran yang berbeza daripada tahap pertumbuhan yang lebih awal, tetapi ia tidak kurang memberangsangkan. Sebagai penyelenggara, anda akan mempraktikkan kepemimpinan dan kemahiran peribadi pada tahap yang dapat dialami oleh beberapa orang. Walaupun tidak selalu mudah dikendalikan, menetapkan batas yang jelas dan hanya mengambil perkara yang anda selesa akan membantu anda tetap bahagia, segar, dan produktif.
\ No newline at end of file

From 5c85ef128f306869a7faeaf3eb24c9ce16868130 Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 01:20:57 +0800
Subject: [PATCH 040/749] Translated to Malay

---
 _articles/ms/README.md                        |   6 +
 .../{best-practices.txt => best-practices.md} |   0
 _articles/ms/building-community.md            | 279 +++++++++
 _articles/ms/code-of-conduct.md               | 120 ++++
 _articles/ms/finding-users.md                 | 163 ++++++
 _articles/ms/getting-paid.md                  | 191 +++++++
 _articles/ms/how-to-contribute.md             | 534 ++++++++++++++++++
 _articles/ms/index.html                       |   6 +
 _articles/ms/leadership-and-governance.md     | 166 ++++++
 _articles/ms/legal.md                         | 166 ++++++
 _articles/ms/metrics.md                       | 134 +++++
 _articles/ms/starting-a-project.md            | 362 ++++++++++++
 12 files changed, 2127 insertions(+)
 create mode 100644 _articles/ms/README.md
 rename _articles/ms/{best-practices.txt => best-practices.md} (100%)
 create mode 100644 _articles/ms/building-community.md
 create mode 100644 _articles/ms/code-of-conduct.md
 create mode 100644 _articles/ms/finding-users.md
 create mode 100644 _articles/ms/getting-paid.md
 create mode 100644 _articles/ms/how-to-contribute.md
 create mode 100644 _articles/ms/index.html
 create mode 100644 _articles/ms/leadership-and-governance.md
 create mode 100644 _articles/ms/legal.md
 create mode 100644 _articles/ms/metrics.md
 create mode 100644 _articles/ms/starting-a-project.md

diff --git a/_articles/ms/README.md b/_articles/ms/README.md
new file mode 100644
index 00000000000..e409cfd0d51
--- /dev/null
+++ b/_articles/ms/README.md
@@ -0,0 +1,6 @@
+---
+lang: ms
+title: README
+description: A README file with the intention of informing the usage of this folder, which translates the english language of the original file to the language of Malay, code = ms
+---
+
diff --git a/_articles/ms/best-practices.txt b/_articles/ms/best-practices.md
similarity index 100%
rename from _articles/ms/best-practices.txt
rename to _articles/ms/best-practices.md
diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
new file mode 100644
index 00000000000..dba8d5bcc40
--- /dev/null
+++ b/_articles/ms/building-community.md
@@ -0,0 +1,279 @@
+---
+lang: ms
+title: Membina Komuniti Sambutan
+description: Membangun komuniti yang mendorong orang untuk menggunakan, menyumbang, dan menginjil projek anda.
+class: building
+toc:
+  setting-your-project-up-for-success: "Menyiapkan projek anda untuk berjaya"
+  growing-your-community: "Memperkembangkan komuniti anda"
+  resolving-conflicts: "Menyelesaikan konflik"
+order: 4
+image: /assets/images/cards/building.png
+related:
+  - best-practices
+  - coc
+---
+
+## Menyiapkan projek anda untuk berjaya
+
+Anda telah melancarkan projek anda, anda menyebarkan berita, dan orang-orang memeriksanya. Hebat! Sekarang, bagaimana anda membuat mereka bertahan?
+
+Komuniti yang ramah adalah pelaburan untuk masa depan dan reputasi projek anda. Sekiranya projek anda baru mula melihat sumbangan pertamanya, mulakan dengan memberi pengalaman positif kepada penyumbang awal, dan permudahkan mereka terus kembali.
+
+### Buat orang merasa diterima
+
+Salah satu cara untuk memikirkan komuniti projek anda adalah melalui apa yang disebut oleh @MikeMcQuaid [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+
+Semasa anda membina komuniti, pertimbangkan bagaimana seseorang di bahagian atas corong (pengguna berpotensi) mungkin secara teorinya melangkah ke bahagian bawah (penyelenggara aktif). Matlamat anda adalah untuk mengurangkan geseran pada setiap tahap pengalaman penyumbang. Apabila orang memperoleh kemenangan dengan mudah, mereka akan merasa terdorong untuk melakukan lebih banyak perkara.
+
+Mulakan dengan dokumentasi anda:
+
+* **Permudahkan seseorang untuk menggunakan projek anda.**[A friendly README](../starting-a-project/#writing-a-readme) dan contoh kod yang jelas akan memudahkan sesiapa sahaja yang memasuki projek anda untuk memulakan.
+* **Terangkan dengan jelas cara menyumbang**, menggunakan [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) dan mengemas kini masalah anda.
+* **Isu pertama yang baik**: Untuk membantu penyumbang baru memulakan, pertimbangkan secara jelas [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 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.
+
+* **Apabila seseorang baru memasuki projek anda, terima kasih atas minat mereka!** Hanya memerlukan satu pengalaman negatif untuk membuat seseorang tidak mahu kembali.
+* **Bersikap responsif.** Sekiranya anda tidak menjawab masalah mereka selama sebulan, kemungkinannya, mereka sudah melupakan projek anda.
+* **Berfikiran terbuka tentang jenis sumbangan yang akan anda terima.** Banyak penyumbang bermula dengan laporan bug atau perbaikan kecil. Disana ada[many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) ke projek. Biarkan orang menolong bagaimana mereka mahu menolong.
+* **Sekiranya ada sumbangan yang anda tidak setuju,** terima kasih atas idea mereka dan [explain why](../best-practices/#learning-to-say-no) ini tidak sesuai dengan skop projek, menghubungkan ke dokumentasi yang relevan jika anda memilikinya.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  Menyumbang kepada sumber terbuka lebih mudah bagi sesetengah orang daripada yang lain. Terdapat banyak ketakutan untuk ditengking kerana tidak melakukan sesuatu yang betul atau tidak sesuai. (...) Dengan memberi para penyumbang tempat untuk menyumbang dengan kecekapan teknikal yang sangat rendah (dokumentasi, penurunan kandungan web, dll.) Anda dapat mengurangkan kebimbangan itu.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+  </p>
+</aside>
+
+Sebilangan besar penyumbang sumber terbuka adalah "penyumbang kasual": orang yang menyumbang kepada projek hanya sekali-sekala. Penyumbang kasual mungkin tidak mempunyai masa untuk mencapai kemajuan sepenuhnya dengan projek anda, jadi tugas anda adalah untuk memudahkan mereka menyumbang.
+
+Mendorong penyumbang lain adalah pelaburan dalam diri anda juga. Apabila anda memberi peluang kepada peminat terbesar anda untuk berlari dengan karya yang mereka sukai, tidak ada tekanan untuk melakukan semuanya sendiri.
+
+### Mendokumentasikan semuanya
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  Pernahkah anda ke acara (berteknologi) di mana anda tidak mengenali sesiapa, tetapi orang lain sepertinya berdiri dalam kumpulan dan berbual seperti rakan lama? (...) Sekarang bayangkan anda mahu menyumbang kepada projek sumber terbuka, tetapi anda tidak melihat mengapa atau bagaimana ini berlaku.
+  <p markdown="1" class="pquote-credit">
+— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+Apabila anda memulakan projek baru, mungkin terasa wajar untuk menjaga kerahsiaan kerja anda. Tetapi projek sumber terbuka berkembang apabila anda mendokumentasikan proses anda di khalayak ramai.
+
+Apabila anda menuliskan sesuatu, lebih banyak orang dapat mengambil bahagian dalam setiap langkah. Anda mungkin mendapat pertolongan mengenai sesuatu yang anda tidak tahu bahawa anda perlukan.
+
+Menulis perkara bermaksud lebih daripada sekadar dokumentasi teknikal. Bila-bila masa anda merasa terdorong untuk menulis sesuatu atau membincangkan projek anda secara tertutup, tanyakan pada diri anda sama ada anda boleh membuatnya terbuka.
+
+Bersikap telus mengenai peta jalan projek anda, jenis sumbangan yang anda cari, bagaimana sumbangan dikaji, atau mengapa anda membuat keputusan tertentu.
+
+Sekiranya anda melihat banyak pengguna menghadapi masalah yang sama, dokumentasikan jawapannya di README.
+
+Untuk perjumpaan, pertimbangkan untuk menerbitkan nota atau catatan anda dalam isu yang berkaitan. Maklum balas yang anda dapat dari tahap ketelusan ini mungkin akan mengejutkan anda.
+
+Mendokumentasikan segala-galanya juga berlaku untuk pekerjaan yang anda lakukan. Sekiranya anda sedang mengemas kini projek anda, masukkan ke dalam permintaan tarik dan tandakan sebagai kerja yang sedang berjalan (WIP). Dengan cara itu, orang lain dapat merasa terlibat dalam proses tersebut sejak awal.
+
+### Bersikap responsif
+
+Seperti awak[promote your project](../finding-users), orang akan mempunyai maklum balas untuk anda. Mereka mungkin mempunyai pertanyaan tentang bagaimana sesuatu berfungsi, atau memerlukan bantuan untuk memulai.
+
+Try responsif ketika seseorang mengajukan masalah, mengajukan permintaan tarik, atau mengajukan pertanyaan mengenai projek anda. Apabila anda bertindak balas dengan cepat, orang akan merasakan mereka adalah sebahagian daripada dialog, dan mereka akan lebih bersemangat untuk turut serta.
+
+Walaupun anda tidak dapat segera meninjau permintaan tersebut, mengakuinya lebih awal dapat meningkatkan pertunangan. Inilah cara @tdreyno menanggapi permintaan penarikan [Middleman](https://github.com/middleman/middleman/pull/1466):
+
+![Middleman pull request](/assets/images/building-community/middleman_pr.png)
+
+[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) penyumbang yang menerima ulasan kod dalam masa 48 jam mempunyai kadar pulangan dan sumbangan berulang yang jauh lebih tinggi.
+
+Perbualan mengenai projek anda juga boleh berlaku di tempat lain di internet, seperti Stack Overflow, Twitter, atau Reddit. Anda boleh mengatur pemberitahuan di beberapa tempat ini sehingga anda diberi amaran ketika seseorang menyebutkan projek anda.
+
+### Beri komuniti anda tempat untuk berkumpul
+
+Terdapat dua sebab untuk memberi tempat kepada komuniti anda untuk berkumpul.
+
+Sebab pertama adalah untuk mereka. Tolong orang mengenali antara satu sama lain. Orang yang mempunyai kepentingan bersama pasti menginginkan tempat untuk membincangkannya. Dan apabila komunikasi bersifat umum dan mudah diakses, sesiapa sahaja boleh membaca arkib masa lalu untuk mencapai kelajuan dan mengambil bahagian.
+
+Sebab kedua adalah untuk anda. Sekiranya anda tidak memberi orang awam tempat untuk membincangkan projek anda, mereka mungkin akan menghubungi anda secara langsung. Pada mulanya, nampaknya cukup mudah untuk membalas mesej peribadi "hanya sekali ini". Tetapi lama-kelamaan, terutamanya jika projek anda menjadi popular, anda akan merasa letih. Tahan godaan untuk berkomunikasi dengan orang lain mengenai projek anda secara tertutup. Sebaliknya, arahkan mereka ke saluran awam yang ditentukan.
+
+Komunikasi awam semudah mengarahkan orang untuk membuka masalah dan bukannya menghantar e-mel kepada anda secara langsung atau memberi komen di blog anda. Anda juga boleh membuat senarai mel, atau membuat akaun Twitter, Slack, atau saluran IRC agar orang dapat membincangkan projek anda. Atau cuba semua perkara di atas!
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) mengetepikan waktu pejabat setiap minggu untuk membantu anggota masyarakat:
+
+> Kops juga mempunyai masa yang diperuntukkan setiap minggu untuk menawarkan pertolongan dan bimbingan kepada masyarakat. Penyelenggara Kops telah bersetuju untuk meluangkan masa yang khusus dikhaskan untuk bekerja dengan pendatang baru, membantu PR, dan membincangkan ciri baru.
+
+Pengecualian untuk komunikasi awam adalah: 1) masalah keselamatan dan 2) pelanggaran tatakelakuan sensitif. Anda semestinya mempunyai cara untuk orang melaporkan masalah ini secara peribadi. Sekiranya anda tidak mahu menggunakan e-mel peribadi anda, sediakan alamat e-mel khusus.
+
+## Memperkembangkan komuniti anda
+
+Masyarakat sangat kuat. Kekuatan itu boleh menjadi berkat atau kutukan, bergantung pada bagaimana Anda menggunakannya. Apabila komuniti projek anda berkembang, ada cara untuk menolongnya menjadi kekuatan pembinaan, bukan kehancuran.
+
+### Jangan bertolak ansur dengan pelakon jahat
+
+Mana-mana projek yang popular pasti akan menarik orang yang membahayakan, dan bukannya membantu, komuniti anda. Mereka mungkin memulakan perbahasan yang tidak perlu, bertengkar dengan ciri-ciri remeh, atau menggertak orang lain.
+
+Lakukan yang terbaik untuk mengamalkan dasar toleransi sifar terhadap jenis orang ini. Sekiranya dibiarkan, orang negatif akan membuat orang lain dalam komuniti anda tidak selesa. Mereka mungkin juga pergi.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
+  Yang benar adalah bahawa mempunyai komuniti yang menyokong adalah kunci. Saya tidak akan dapat melakukan kerja ini tanpa bantuan rakan sekerja, orang asing yang ramah, dan saluran IRC yang cerewet. (...) Jangan berpuas hati. Jangan berpuas hati dengan orang yang teruk.
+  <p markdown="1" class="pquote-credit">
+— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+  </p>
+</aside>
+
+Perbahasan berkala mengenai aspek sepele projek anda mengalihkan perhatian orang lain, termasuk anda, daripada memfokus pada tugas penting. Orang baru yang tiba ke projek anda mungkin melihat perbualan ini dan tidak mahu mengambil bahagian.
+
+Apabila anda melihat tingkah laku negatif berlaku pada projek anda, panggilnya secara terbuka. Jelaskan, dengan nada yang baik tetapi tegas, mengapa tingkah laku mereka tidak dapat diterima. Sekiranya masalah itu berlanjutan, anda mungkin perlu [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) boleh menjadi panduan yang membina untuk perbualan ini.
+
+### Temui penyumbang di mana mereka berada
+
+Dokumentasi yang baik hanya menjadi lebih penting apabila komuniti anda berkembang. Penyumbang kasual, yang mungkin tidak biasa dengan projek anda, membaca dokumentasi anda untuk mendapatkan konteks yang mereka perlukan dengan cepat.
+
+Dalam fail CONTRIBUTING anda, jelaskan cara penyumbang baru kepada penyumbang baru. Anda mungkin mahu membuat bahagian khusus untuk tujuan ini. [Django](https://github.com/django/django), sebagai contoh, mempunyai halaman arahan khas untuk mengalu-alukan penyumbang baru.
+
+![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
+
+Dalam barisan masalah anda, labelkan pepijat yang sesuai untuk pelbagai jenis penyumbang: sebagai contoh, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only),_ "terbitan pertama yang baik" _, atau _ "dokumentasi" _. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) permudahkan seseorang yang baru dalam projek anda untuk mengimbas masalah anda dengan cepat dan memulakannya.
+
+Akhirnya, gunakan dokumentasi anda untuk membuat orang merasa diterima di setiap langkah.
+
+Anda tidak akan pernah berinteraksi dengan kebanyakan orang yang menggunakan projek anda. Mungkin ada sumbangan yang tidak anda terima kerana seseorang merasa terintimidasi atau tidak tahu di mana hendak memulakannya. Bahkan beberapa kata yang baik dapat membuat seseorang tidak meninggalkan projek anda dalam kekecewaan.
+
+Contohnya, inilah caranya [Rubinius](https://github.com/rubinius/rubinius/) bermula [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+> Kami ingin memulai dengan mengucapkan terima kasih kerana menggunakan Rubinius. Projek ini adalah usaha cinta, dan kami menghargai semua pengguna yang menangkap pepijat, membuat peningkatan prestasi, dan membantu dengan dokumentasi. Setiap sumbangan amat bermakna, jadi terima kasih kerana turut serta. Oleh itu, berikut adalah beberapa panduan yang kami minta anda ikuti sehingga kami dapat menyelesaikan masalah anda dengan jayanya.
+
+### Kongsi pemilikan projek anda
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
+  Pemimpin anda akan berbeza pendapat, sebagaimana seharusnya semua komuniti sihat! Namun, anda perlu mengambil langkah untuk memastikan suara yang paling keras tidak selalu menang dengan melelahkan orang, dan suara yang kurang menonjol dan minoriti kedengaran.
+  <p markdown="1" class="pquote-credit">
+— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+  </p>
+</aside>
+
+Orang ramai teruja untuk menyumbang kepada projek apabila mereka merasakan kepemilikan. Itu tidak bermaksud anda perlu membalikkan visi projek anda atau menerima sumbangan yang tidak anda mahukan. Tetapi semakin banyak anda memberi penghargaan kepada orang lain, semakin banyak mereka tetap bertahan.
+
+Lihat apakah anda boleh mencari cara untuk berkongsi pemilikan dengan komuniti anda sebanyak mungkin. Berikut adalah beberapa idea:
+
+* **Tahan untuk memperbaiki pepijat yang mudah (tidak kritikal).** Sebagai gantinya, gunakannya sebagai peluang untuk merekrut penyumbang baru, atau membimbing seseorang yang ingin menyumbang. Mungkin kelihatan tidak wajar pada mulanya, tetapi pelaburan anda akan membuahkan hasil dari masa ke masa. Sebagai contoh, @michaeljoseph meminta penyumbang untuk mengemukakan permintaan tarik pada a[Cookiecutter](https://github.com/audreyr/cookiecutter) masalah di bawah, bukannya membetulkannya sendiri.
+
+![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
+
+* **Mulakan fail CONTRIBUTORS atau AUTHORS dalam projek anda** yang menyenaraikan semua orang yang menyumbang untuk projek anda, seperti [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
+
+* Sekiranya anda mempunyai komuniti yang cukup besar, **menghantar surat berita atau menulis catatan blog** mengucapkan terima kasih kepada penyumbang. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) adalah dua contoh yang baik.
+
+* **Berikan akses kepada setiap penyumbang.** @felixge mendapati bahawa ini menjadikan orang[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.
+
+* 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.
+
+Kenyataannya adalah bahawa[most projects only have](https://peerj.com/preprints/1233.pdf)satu atau dua penyelenggara yang melakukan sebahagian besar kerja. Semakin besar projek anda, dan semakin besar komuniti anda, semakin mudah mendapatkan bantuan.
+
+Walaupun anda mungkin tidak selalu menjumpai seseorang untuk menjawab panggilan tersebut, memberi isyarat di luar sana akan meningkatkan kemungkinan orang lain akan masuk. Dan lebih awal anda memulakannya, semakin cepat orang dapat membantu.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
+  \[Ia ada di dalam anda\] minat terbaik untuk merekrut penyumbang yang menikmati dan yang mampu melakukan perkara yang bukan anda lakukan. Adakah anda menikmati pengekodan, tetapi tidak menjawab masalah? Kemudian kenal pasti individu-individu dalam komuniti anda yang melakukannya dan biarkan mereka memilikinya.
+  <p markdown="1" class="pquote-credit">
+— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+  </p>
+</aside>
+
+## Menyelesaikan konflik
+
+Pada peringkat awal projek anda, membuat keputusan besar adalah mudah. Apabila anda ingin melakukan sesuatu, anda hanya melakukannya.
+
+Oleh kerana projek anda menjadi lebih popular, lebih ramai orang akan tertarik dengan keputusan yang anda buat. Walaupun anda tidak mempunyai komuniti penyumbang yang besar, jika projek anda mempunyai banyak pengguna, anda akan mendapati orang mempertimbangkan keputusan atau membangkitkan masalah mereka sendiri.
+
+Sebahagian besarnya, jika anda telah membina komuniti yang ramah, hormat dan mendokumentasikan proses anda secara terbuka, komuniti anda seharusnya dapat mencari penyelesaian. Tetapi kadang-kadang anda menghadapi masalah yang agak sukar untuk ditangani.
+
+### Tetapkan bar untuk kebaikan
+
+Apabila komuniti anda bergelut dengan masalah yang sukar, kemarahan mungkin akan meningkat. Orang mungkin menjadi marah atau kecewa dan mengeluarkannya satu sama lain, atau pada anda.
+
+Tugas anda sebagai penyelenggara adalah untuk memastikan situasi ini tidak meningkat. Walaupun anda mempunyai pendapat yang kuat mengenai topik ini, cubalah mengambil kedudukan sebagai moderator atau fasilitator, daripada melompat ke dalam pertengkaran dan mendorong pandangan anda. Sekiranya seseorang bersikap tidak baik atau memonopoli perbualan, [act immediately](../building-community/#dont-tolerate-bad-actors) agar perbincangan tetap sopan dan produktif.
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
+ Sebagai penyelenggara projek, sangat penting untuk menghormati penyumbang anda. Mereka sering mengambil apa yang anda katakan secara peribadi.
+  <p markdown="1" class="pquote-credit">
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+  </p>
+</aside>
+
+Orang lain mencari bimbingan anda. Berikan contoh yang baik. Anda masih dapat menyatakan kekecewaan, ketidakbahagiaan, atau keprihatinan, tetapi melakukannya dengan tenang.
+
+Menjaga kesegaran anda tidak mudah, tetapi menunjukkan kepemimpinan dapat meningkatkan kesihatan komuniti anda. Internet terima kasih.
+
+### Perlakukan README anda sebagai perlembagaan
+
+README anda adalah [more than just a set of instructions](../starting-a-project/#writing-a-readme). Ia juga merupakan tempat untuk membincangkan tujuan, visi produk, dan peta jalan anda. Sekiranya orang terlalu fokus memperdebatkan kelebihan ciri tertentu, ia mungkin dapat meninjau semula README anda dan membincangkan visi projek anda yang lebih tinggi. Memfokuskan pada README anda juga melumpuhkan perbualan, sehingga anda dapat mengadakan perbincangan yang membina.
+
+### Fokus pada perjalanan, bukan destinasi
+
+Beberapa projek menggunakan proses pengundian untuk membuat keputusan utama. Walaupun masuk akal pada pandangan pertama, pemungutan suara menekankan mendapatkan "jawaban", daripada mendengarkan dan menangani masalah satu sama lain.
+
+Pengundian boleh menjadi politik, di mana anggota masyarakat merasa tertekan untuk saling memilih atau memilih dengan cara tertentu. Tidak semua orang memilih, sama ada ia [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) dalam komuniti anda, atau pengguna semasa yang tidak tahu ada suara.
+
+Kadang kala, pengundian adalah pemangkin yang perlu. Walau seberapa banyak yang anda mampu, tekankan ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) bukannya muafakat.
+
+Di bawah proses pencarian konsensus, anggota masyarakat membincangkan masalah utama sehingga mereka merasa mereka telah didengar dengan cukup. Apabila hanya ada masalah kecil, masyarakat bergerak maju. "Pencarian konsensus" mengakui bahawa masyarakat mungkin tidak dapat mencapai jawapan yang sempurna. Sebaliknya, ia mengutamakan pendengaran dan perbincangan.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
+  Sebahagian daripada sebab mengapa sistem pemungutan suara tidak ada untuk Masalah Atom adalah kerana pasukan Atom tidak akan mengikuti sistem pengundian dalam semua hal. Kadang-kadang kita harus memilih apa yang kita rasa betul walaupun tidak popular. (...) Apa yang dapat saya tawarkan dan berjanji untuk dilakukan ... adalah tugas saya untuk mendengarkan masyarakat.
+  <p markdown="1" class="pquote-credit">
+— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+  </p>
+</aside>
+
+Walaupun anda tidak benar-benar menggunakan proses mencari konsensus, sebagai penyelenggara projek, penting bagi orang untuk mengetahui bahawa anda sedang mendengar. Membuat orang lain merasa terdengar, dan berkomitmen untuk menyelesaikan masalah mereka, banyak membantu menangani situasi sensitif. Kemudian, ikuti kata-kata anda dengan tindakan.
+
+Jangan terburu-buru membuat keputusan kerana mempunyai keputusan. Pastikan bahawa semua orang merasa terdengar dan bahawa semua maklumat telah diumumkan sebelum membuat keputusan.
+
+### Pastikan perbualan tertumpu pada tindakan
+
+Perbincangan itu penting, tetapi ada perbezaan antara perbualan produktif dan tidak produktif.
+
+Galakkan perbincangan selagi ia bergerak secara aktif ke arah penyelesaian. Sekiranya jelas bahawa perbualan mereda atau di luar topik, jab menjadi lebih peribadi, atau orang-orang membicarakan perincian kecil, sudah waktunya untuk mematikannya.
+
+Membiarkan perbualan ini diteruskan bukan hanya buruk untuk masalah yang dihadapi, tetapi juga buruk bagi kesihatan komuniti anda. Ini mengirimkan mesej bahawa jenis percakapan ini diizinkan atau bahkan digalakkan, dan ini dapat mendorong orang untuk membangkitkan atau menyelesaikan masalah di masa depan.
+
+Dengan setiap titik yang dibuat oleh anda atau oleh orang lain, tanyakan pada diri sendiri, _ "Bagaimana ini mendekatkan kita dengan penyelesaian?" _
+
+Sekiranya perbualan mula terungkai, tanyakan kepada kumpulan, _ "Langkah mana yang harus kita ambil selanjutnya?" _ Untuk memfokuskan kembali perbualan.
+
+Sekiranya perbualan jelas tidak akan ke mana-mana, tidak ada tindakan yang jelas untuk diambil, atau tindakan yang sesuai telah diambil, tutup masalahnya dan terangkan mengapa anda menutupnya.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Membimbing utas ke arah berguna tanpa memaksa adalah seni. Tidak akan berguna hanya untuk memberi nasihat kepada orang ramai agar berhenti membuang masa mereka, atau meminta mereka untuk tidak mengeposkan melainkan mereka mempunyai sesuatu yang membina. (...) Sebagai gantinya, anda harus mencadangkan syarat untuk kemajuan lebih lanjut: beri laluan kepada orang lain, jalan untuk diikuti yang membawa kepada hasil yang anda mahukan, namun tanpa terdengar seperti anda menentukan tingkah laku.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+  </p>
+</aside>
+
+### Pilih pertempuran anda dengan bijak
+
+Konteks adalah penting. Pertimbangkan siapa yang terlibat dalam perbincangan dan bagaimana mereka mewakili masyarakat yang lain.
+
+Adakah semua orang dalam komuniti kesal dengan, atau bahkan terlibat dengan, masalah ini? Atau adakah pengacau sendirian? Jangan lupa untuk mempertimbangkan ahli komuniti anda yang senyap, bukan hanya suara aktif.
+
+Sekiranya masalah ini tidak mewakili keperluan masyarakat anda yang lebih luas, anda mungkin perlu mengakui keprihatinan segelintir orang. Sekiranya ini adalah masalah berulang tanpa penyelesaian yang jelas, arahkan mereka ke perbincangan sebelumnya mengenai topik ini dan tutup utasnya.
+
+### Kenal pasti tiebreak komuniti
+
+Dengan sikap yang baik dan komunikasi yang jelas, situasi yang paling sukar dapat diselesaikan. Namun, walaupun dalam perbualan yang produktif, hanya ada perbezaan pendapat tentang cara meneruskannya. Dalam kes ini, kenal pasti individu atau sekumpulan orang yang boleh berfungsi sebagai pemula.
+
+Tiebreaker dapat menjadi penyelenggara utama proyek, atau mungkin sekelompok kecil orang yang membuat keputusan berdasarkan pengundian. Sebaik-baiknya, anda telah mengenal pasti tiebreak dan proses yang berkaitan dalam fail GOVERNANCE sebelum anda mesti menggunakannya.
+
+Tiebreaker anda harus menjadi pilihan terakhir. Isu memecah belah adalah peluang untuk komuniti anda berkembang dan belajar. Rebut peluang ini dan gunakan proses kolaboratif untuk beralih ke penyelesaian sedapat mungkin.
+
+## Komuniti adalah ❤️ sumber terbuka
+
+Komuniti yang sihat dan berkembang menghasilkan ribuan jam yang dicurahkan ke sumber terbuka setiap minggu. Banyak penyumbang menunjukkan kepada orang lain sebagai alasan untuk bekerja - atau tidak bekerja - di sumber terbuka. Dengan belajar bagaimana memanfaatkan kekuatan itu secara konstruktif, anda akan membantu seseorang di luar sana mempunyai pengalaman sumber terbuka yang tidak dapat dilupakan.
diff --git a/_articles/ms/code-of-conduct.md b/_articles/ms/code-of-conduct.md
new file mode 100644
index 00000000000..5347f17adf3
--- /dev/null
+++ b/_articles/ms/code-of-conduct.md
@@ -0,0 +1,120 @@
+---
+lang: ms
+title: Tatakelakuan Anda
+description: Memudahkan tingkah laku masyarakat yang sihat dan konstruktif dengan menerapkan dan menguatkuasakan tatakelakuan.
+class: coc
+toc:
+  why-do-i-need-a-code-of-conduct: "Mengapa saya memerlukan tatakelakuan?"
+  establishing-a-code-of-conduct: "Menetapkan tatakelakuan"
+  deciding-how-youll-enforce-your-code-of-conduct: "Memutuskan bagaimana anda akan melaksanakan tatakelakuan anda"
+  enforcing-your-code-of-conduct: "Menguatkuasakan tatakelakuan anda"
+  your-responsibilities-as-a-maintainer: "Tanggungjawab anda sebagai penjaga"
+order: 8
+image: /assets/images/cards/coc.png
+related:
+  - building
+  - leadership
+---
+
+## Mengapa saya memerlukan tatakelakuan?
+
+Kod tingkah laku adalah dokumen yang menetapkan harapan untuk tingkah laku bagi peserta projek anda. Mengamalkan, dan menegakkan, kod tingkah laku dapat membantu mewujudkan suasana sosial yang positif untuk komuniti anda.
+
+Tata kelakuan membantu melindungi bukan hanya peserta anda, tetapi diri anda sendiri. Sekiranya anda mengekalkan projek, anda mungkin mendapati bahawa sikap yang tidak produktif dari peserta lain dapat membuat anda merasa kecewa atau tidak senang dengan kerja anda dari masa ke masa.
+
+Kod tingkah laku memberi kuasa kepada anda untuk memudahkan tingkah laku masyarakat yang sihat dan membina. Bersikap proaktif mengurangkan kemungkinan anda, atau orang lain, menjadi letih dengan projek anda, dan membantu anda mengambil tindakan ketika seseorang melakukan sesuatu yang tidak anda setujui.
+
+## Menetapkan tatakelakuan
+
+Cuba buat kod tingkah laku seawal mungkin: idealnya, ketika pertama kali membuat projek anda.
+
+Selain menyampaikan harapan anda, kod tingkah laku menerangkan perkara berikut:
+
+* Di mana tatakelakuan berkuatkuasa _ (hanya pada isu dan permintaan tarik, atau aktiviti masyarakat seperti acara?) _
+* Siapa yang mematuhi tata kelakuan _ (anggota masyarakat dan penyelenggara, tetapi bagaimana dengan penaja?) _
+* Apa yang berlaku sekiranya seseorang melanggar tatakelakuan
+* Bagaimana seseorang dapat melaporkan pelanggaran
+
+Di mana sahaja anda boleh, gunakan seni sebelumnya. [Contributor Covenant](https://contributor-covenant.org/) adalah tatakelakuan drop-in yang digunakan oleh lebih dari 40,000 projek sumber terbuka, termasuk Kubernetes, Rails, dan Swift.
+
+[Django Code of Conduct](https://www.djangoproject.com/conduct/) dan [Citizen Code of Conduct](http://citizencodeofconduct.org/) juga merupakan dua contoh tatakelakuan yang baik.
+
+Letakkan fail CODE_OF_CONDUCT di direktori root projek anda, dan jadikan ia dapat dilihat oleh komuniti anda dengan menghubungkannya dari fail CONTRIBUTING atau README anda.
+
+## Memutuskan bagaimana anda akan menguatkuasakan tatakelakuan anda
+
+<aside markdown="1" class="pquote">
+  Kod tingkah laku yang tidak (atau tidak dapat) ditegakkan lebih buruk daripada tidak ada kod tingkah laku sama sekali: ia menghantar mesej bahawa nilai-nilai dalam kod tingkah laku sebenarnya tidak penting atau dihormati dalam komuniti anda.
+  <p markdown="1" class="pquote-credit">
+— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+  </p>
+</aside>
+
+Anda harus menjelaskan bagaimana tatakelakuan anda akan ditegakkan **_sebelum_** pelanggaran berlaku. Terdapat beberapa sebab untuk melakukannya:
+
+* Ini menunjukkan bahawa anda serius mengambil tindakan ketika diperlukan.
+
+* Komuniti anda akan merasa lebih yakin bahawa aduan benar-benar dikaji.
+
+* Anda akan meyakinkan komuniti anda bahawa proses peninjauan dilakukan dengan adil dan telus, sekiranya mereka mendapati diri mereka disiasat atas pelanggaran.
+
+Anda harus memberi orang cara persendirian (seperti alamat e-mel) untuk melaporkan pelanggaran tatakelakuan dan menjelaskan siapa yang menerima laporan tersebut. Ini boleh menjadi penyelenggara, sekumpulan penyelenggara, atau kumpulan kerja kod etika.
+
+Jangan lupa bahawa seseorang mungkin ingin melaporkan pelanggaran mengenai orang yang menerima laporan tersebut. Dalam kes ini, beri mereka pilihan untuk melaporkan pelanggaran kepada orang lain. Contohnya, @ctb dan @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Contoh tingkah laku kasar, melecehkan, atau tidak boleh diterima mungkin dilaporkan dengan menghantar e-mel **khmer-project@idyll.org** melalui email yang hanya ditujukan kepada C. Titus Brown dan Michael R. Crusoe. Untuk melaporkan masalah yang melibatkan salah satu daripada mereka, sila hantarkan e-mel **Judi Brown Clarke, Ph.D.** Diversity Director kat BEACON Center for the Study of Evolution in Action, Pusat Sains dan Teknologi NSF. 
+
+Untuk inspirasi, lihatlah Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (walaupun anda mungkin tidak memerlukan sesuatu yang komprehensif, bergantung pada ukuran projek anda).
+
+## Menguatkuasakan tatakelakuan anda
+
+Kadang kala, walaupun ada usaha terbaik anda, seseorang akan melakukan sesuatu yang melanggar kod ini. Terdapat beberapa cara untuk mengatasi tingkah laku negatif atau berbahaya ketika muncul.
+
+### Kumpulkan maklumat mengenai keadaan
+
+Perlakukan suara setiap ahli komuniti sama pentingnya dengan suara anda. Sekiranya anda menerima laporan bahawa seseorang melanggar tatakelakuan, ambil serius dan selidiki masalah tersebut, walaupun tidak sesuai dengan pengalaman anda sendiri dengan orang itu. Melakukannya memberi isyarat kepada komuniti anda bahawa anda menghargai perspektif mereka dan mempercayai penilaian mereka.
+
+Anggota komuniti yang berkenaan mungkin merupakan pesalah berulang yang secara konsisten membuat orang lain merasa tidak selesa, atau mereka mungkin hanya pernah mengatakan atau melakukan sesuatu sekali. Kedua-duanya boleh menjadi alasan untuk mengambil tindakan, bergantung pada konteksnya.
+
+Sebelum anda bertindak balas, berikan masa untuk memahami apa yang berlaku. Baca komen dan perbualan orang yang lalu untuk lebih memahami siapa mereka dan mengapa mereka bertindak sedemikian. Cuba kumpulkan perspektif selain pandangan anda mengenai orang ini dan tingkah laku mereka.
+
+<aside markdown="1" class="pquote">
+  Jangan tertarik dengan hujah. Jangan sesekali berurusan dengan tingkah laku orang lain sebelum anda selesai menangani masalah tersebut. Fokus pada perkara yang anda perlukan.
+  <p markdown="1" class="pquote-credit">
+— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+  </p>
+</aside>
+
+### Lakukan tindakan yang sewajarnya
+
+Setelah mengumpulkan dan memproses maklumat yang mencukupi, anda perlu memutuskan apa yang harus dilakukan. Semasa anda mempertimbangkan langkah seterusnya, ingat bahawa matlamat anda sebagai moderator adalah untuk memupuk persekitaran yang selamat, hormat, dan bekerjasama. Pertimbangkan bukan sahaja bagaimana menangani situasi yang dimaksudkan, tetapi bagaimana tindak balas anda akan mempengaruhi tingkah laku dan harapan masyarakat anda yang lain untuk terus maju.
+
+Apabila seseorang melaporkan pelanggaran tatakelakuan, itu adalah tugas anda, bukan tugas mereka untuk mengatasinya. Kadang kala, wartawan mendedahkan maklumat yang berisiko besar terhadap kerjaya, reputasi, atau keselamatan fizikal mereka. Memaksa mereka untuk berhadapan dengan pelaku gangguan mereka dapat menempatkan wartawan dalam posisi yang berkompromi. Anda harus mengendalikan komunikasi langsung dengan orang yang berkenaan, kecuali wartawan secara terang-terangan meminta sebaliknya.
+
+Terdapat beberapa cara untuk menanggapi pelanggaran tatakelakuan:
+
+* **Beri amaran umum kepada orang yang dimaksudkan** dan terangkan bagaimana tingkah laku mereka memberi kesan negatif kepada orang lain, lebih baik di saluran di mana ia berlaku. Sekiranya mungkin, komunikasi awam menyampaikan kepada masyarakat lain bahawa anda memandang serius tatakelakuan. Bersikap baik, tetapi tegas dalam komunikasi anda.
+
+* **Hubungi orang itu secara peribadi** untuk menjelaskan bagaimana tingkah laku mereka memberi kesan negatif kepada orang lain. Anda mungkin mahu menggunakan saluran komunikasi peribadi jika keadaan tersebut melibatkan maklumat peribadi yang sensitif. Sekiranya anda berkomunikasi dengan seseorang secara peribadi, adalah idea yang baik untuk menghubungi mereka yang pertama kali melaporkan keadaan, jadi mereka tahu bahawa anda telah mengambil tindakan. Minta persetujuan orang yang melapor sebelum meminta mereka.
+
+Kadang kala, penyelesaian tidak dapat dicapai. Orang yang dimaksudkan boleh menjadi agresif atau bermusuhan ketika berhadapan atau tidak mengubah tingkah laku mereka. Dalam keadaan ini, anda mungkin ingin mempertimbangkan untuk mengambil tindakan yang lebih kuat. Sebagai contoh:
+
+* **Tangguhkan orang yang dimaksudkan dari projek tersebut** , yang diberlakukan melalui larangan sementara untuk mengambil bahagian dalam aspek apa pun projek
+
+* **Larangan secara kekal** orang dari projek
+
+Melarang anggota tidak boleh dipandang ringan dan mewakili perbezaan perspektif yang tetap dan tidak dapat diselesaikan. Anda hanya harus mengambil langkah-langkah ini apabila sudah jelas bahawa penyelesaian tidak dapat dicapai.
+
+## Tanggungjawab anda sebagai penjaga
+
+Tata kelakuan bukanlah undang-undang yang dikuatkuasakan dengan sewenang-wenangnya. Anda adalah penguatkuasa kod tingkah laku dan menjadi tanggungjawab anda untuk mengikuti peraturan yang ditetapkan oleh kod tingkah laku.
+
+Sebagai penjaga, anda menetapkan garis panduan untuk komuniti anda dan menguatkuasakan garis panduan tersebut sesuai dengan peraturan yang dinyatakan dalam tatakelakuan anda. Ini bermaksud memandang serius setiap laporan pelanggaran tatakelakuan. Wartawan tersebut harus meneliti aduan mereka secara menyeluruh dan adil. Sekiranya anda menentukan bahawa tingkah laku yang mereka laporkan bukanlah pelanggaran, sampaikan dengan jelas kepada mereka dan terangkan mengapa anda tidak akan mengambil tindakan terhadapnya. Apa yang mereka lakukan adalah bergantung kepada mereka: bertolak ansur dengan tingkah laku yang mereka hadapi, atau berhenti mengambil bahagian dalam komuniti.
+
+Laporan tingkah laku yang tidak secara teknikal_ melanggar tatakelakuan mungkin masih menunjukkan bahawa terdapat masalah dalam komuniti anda, dan anda harus menyiasat potensi masalah ini dan bertindak sewajarnya. Ini mungkin termasuk menyemak semula kod tingkah laku anda untuk menjelaskan tingkah laku yang dapat diterima dan / atau berbicara dengan orang yang perilakunya dilaporkan dan memberitahu mereka bahawa walaupun mereka tidak melanggar kod tingkah laku, mereka melewati apa yang diharapkan dan memastikan peserta berasa tidak selesa.
+
+Pada akhirnya, sebagai penjaga, anda menetapkan dan menegakkan piawaian untuk tingkah laku yang boleh diterima. Anda mempunyai kemampuan untuk membentuk nilai-nilai komuniti projek tersebut, dan para peserta mengharapkan anda untuk menerapkan nilai-nilai tersebut dengan adil dan adil.
+
+## Galakkan tingkah laku yang anda ingin lihat di dunia 🌎
+
+Apabila projek kelihatan bermusuhan atau tidak disenangi, walaupun hanya satu orang yang tingkah lakunya ditoleransi oleh orang lain, anda berisiko kehilangan banyak lagi penyumbang, yang mungkin tidak pernah anda temui. Tidak selalunya mudah untuk menerapkan atau menegakkan kod tingkah laku, tetapi memupuk persekitaran yang ramah akan membantu komuniti anda berkembang.
\ No newline at end of file
diff --git a/_articles/ms/finding-users.md b/_articles/ms/finding-users.md
new file mode 100644
index 00000000000..0db652708cb
--- /dev/null
+++ b/_articles/ms/finding-users.md
@@ -0,0 +1,163 @@
+---
+lang: ms
+title: Mencari Pengguna untuk Projek Anda
+description: Bantu projek sumber terbuka anda berkembang dengan mendapatkannya di tangan pengguna yang gembira.
+class: finding
+toc:
+  spreading-the-word: "Menyebarkan berita"
+  figure-out-your-message: "Cari tahu mesej anda"
+  help-people-find-and-follow-your-project: "Bantu orang mencari dan mengikuti projek anda"
+  go-where-your-projects-audience-is-online: "Pergi ke tempat penonton projek anda (dalam talian)"
+  go-where-your-projects-audience-is-offline: "Pergi ke tempat khalayak projek anda (luar talian)"
+  build-a-reputation: "Membina reputasi"
+order: 3
+image: /assets/images/cards/finding.png
+related:
+  - beginners
+  - building
+---
+
+## Menyebarkan berita
+
+Tidak ada peraturan yang mengatakan bahawa anda harus mempromosikan projek sumber terbuka semasa anda melancarkan. Terdapat banyak alasan yang memuaskan untuk bekerja di sumber terbuka yang tidak ada kaitan dengan populariti. Daripada berharap orang lain mencari dan menggunakan projek sumber terbuka anda, anda harus menyebarkan berita mengenai kerja keras anda!
+
+## Cari tahu mesej anda
+
+Sebelum anda memulakan kerja mempromosikan projek anda, anda seharusnya dapat menjelaskan apa yang dilakukannya dan mengapa ia penting.
+
+Apa yang menjadikan projek anda berbeza atau menarik? Mengapa anda membuatnya? Menjawab soalan-soalan ini untuk diri sendiri akan membantu anda menyampaikan kepentingan projek anda.
+
+Ingatlah bahawa orang terlibat sebagai pengguna, dan akhirnya menjadi penyumbang, kerana projek anda menyelesaikan masalah bagi mereka. Semasa anda memikirkan mesej dan nilai projek anda, cubalah melihatnya melalui apa yang diinginkan oleh pengguna dan penyumbang.
+
+Sebagai contoh, @robb menggunakan contoh kod untuk menyampaikan dengan jelas mengapa projeknya, [Cartography](https://github.com/robb/Cartography), berguna:
+
+![Cartography README](/assets/images/finding-users/cartography.jpg)
+
+Untuk mengetahui lebih mendalam mengenai pemesejan, periksa Mozilla["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/)latihan untuk mengembangkan personaliti pengguna.
+
+## Bantu orang mencari dan mengikuti projek anda
+
+<aside markdown="1" class="pquote">
+  Anda semestinya memerlukan satu URL "home" yang boleh anda promosikan dan arahkan orang berkaitan dengan projek anda. Anda tidak perlu memaparkan templat mewah atau bahkan nama domain, tetapi projek anda memerlukan titik fokus.
+  <p markdown="1" class="pquote-credit">
+— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+  </p>
+</aside>
+
+Bantu orang mencari dan mengingati projek anda dengan menunjukkan mereka ke satu ruang nama.
+
+**Mempunyai pegangan yang jelas untuk mempromosikan karya anda.** Pegangan Twitter, URL GitHub, atau saluran IRC adalah cara mudah untuk mengarahkan orang ke projek anda. Kedai-kedai ini juga memberi tempat kepada komuniti yang sedang berkembang untuk bersidang.
+
+Sekiranya anda belum mahu menyediakan kedai untuk projek anda, promosikan pegangan Twitter atau GitHub anda sendiri dalam semua yang anda lakukan. Mempromosikan pegangan Twitter atau GitHub anda akan memberi tahu orang bagaimana menghubungi anda atau mengikuti kerja anda. Sekiranya anda bercakap di perjumpaan atau acara, pastikan maklumat hubungan anda disertakan dalam bio atau slaid anda.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
+  Kesalahan yang saya buat pada hari-hari awal (...) tidak memulakan akaun Twitter untuk projek tersebut. Twitter adalah kaedah terbaik untuk membuat orang sentiasa mengetahui tentang sesuatu projek dan juga sentiasa memberi pendedahan kepada orang tentang projek tersebut.
+  <p markdown="1" class="pquote-credit">
+— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+  </p>
+</aside>
+
+**Pertimbangkan untuk membuat laman web untuk projek anda.** Laman web menjadikan projek anda lebih mesra dan lebih mudah dilayari, terutama jika dipasangkan dengan dokumentasi dan tutorial yang jelas. Mempunyai laman web juga menunjukkan bahawa projek anda aktif yang akan membuatkan penonton anda merasa lebih selesa menggunakannya. Berikan contoh untuk memberi idea kepada orang ramai tentang cara menggunakan projek anda.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), pencipta bersama Django, mengatakan bahawa laman web adalah _ "sejauh ini adalah perkara terbaik yang kami lakukan dengan Django pada masa awal" _.
+
+Sekiranya projek anda dihoskan di GitHub, anda boleh menggunakan [GitHub Pages](https://pages.github.com/) untuk membuat laman web dengan mudah. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), dan [Middleman](https://middlemanapp.com/) ialah [a few examples](https://github.com/showcases/github-pages-examples) laman web yang sangat baik dan komprehensif.
+
+![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
+
+Sekarang kerana anda mempunyai mesej untuk projek anda, dan cara mudah bagi orang lain untuk mencari projek anda, mari keluar ke sana dan berbincang dengan khalayak anda!
+
+## Pergi ke tempat penonton projek anda (dalam talian)
+
+Jangkauan dalam talian adalah kaedah terbaik untuk berkongsi dan menyebarkan berita dengan cepat. Dengan menggunakan saluran dalam talian, anda berpotensi menjangkau khalayak yang sangat luas.
+
+Manfaatkan komuniti dan platform dalam talian yang ada untuk menjangkau khalayak anda. Sekiranya projek sumber terbuka anda adalah projek perisian, anda mungkin dapat mencari khalayak anda [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/).Cari saluran di mana anda fikir orang akan mendapat banyak faedah atau teruja dengan kerja anda.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
+ Setiap program mempunyai fungsi yang sangat spesifik yang hanya berguna bagi sebahagian pengguna. Jangan spam sebanyak mungkin orang. Sebaliknya, sasarkan usaha anda kepada komuniti yang akan mendapat manfaat daripada mengetahui tentang projek anda.
+  <p markdown="1" class="pquote-credit">
+— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+  </p>
+</aside>
+
+Lihat apakah anda dapat mencari cara untuk berkongsi projek anda dengan cara yang relevan:
+
+* **Kenali projek dan komuniti sumber terbuka yang relevan.** Kadang kala, anda tidak perlu mempromosikan projek anda secara langsung. Sekiranya projek anda sesuai untuk saintis data yang menggunakan Python, kenali komuniti sains data Python. Apabila orang mengenali anda, peluang semula jadi akan timbul untuk membincangkan dan berkongsi kerja anda.
+* **Cari orang yang mengalami masalah yang diselesaikan oleh projek anda.** Cari melalui forum yang berkaitan untuk orang yang menjadi sasaran khalayak projek anda. Jawab soalan mereka dan cari cara yang bijaksana, bila sesuai, untuk mencadangkan projek anda sebagai jalan penyelesaian.
+* **Minta maklum balas.** Perkenalkan diri anda dan karya anda kepada penonton yang menganggapnya relevan dan menarik. Jadilah spesifik mengenai siapa yang anda fikir akan mendapat manfaat daripada projek anda. Cuba selesaikan ayat: _ "Saya rasa projek saya akan benar-benar membantu X, yang berusaha melakukan Y_". Dengarkan dan balas maklum balas orang lain, bukan sekadar mempromosikan karya anda.
+
+Secara umumnya, fokus menolong orang lain sebelum meminta sesuatu sebagai balasan. Kerana sesiapa sahaja dapat mempromosikan projek dalam talian dengan mudah, akan ada banyak kebisingan. Untuk menonjol dari orang ramai, beri orang konteks untuk siapa anda dan bukan hanya yang anda mahukan.
+
+Sekiranya tidak ada yang memberi perhatian atau menanggapi jangkauan awal anda, jangan putus asa! Sebilangan besar pelancaran projek adalah proses berulang yang boleh memakan masa berbulan-bulan atau bertahun-tahun. Sekiranya anda tidak mendapat sambutan pada kali pertama, cubalah taktik lain, atau cari cara untuk menambah nilai pekerjaan orang lain terlebih dahulu. Mempromosikan dan melancarkan projek anda memerlukan masa dan dedikasi.
+
+## Pergi ke tempat penonton projek anda (luar talian)
+
+![Public speaking](/assets/images/finding-users/public_speaking.jpg)
+
+Acara luar talian adalah kaedah popular untuk mempromosikan projek baru kepada khalayak. Mereka adalah kaedah yang baik untuk menjangkau khalayak yang terlibat dan membina hubungan manusia yang lebih mendalam, terutamanya jika anda berminat untuk menjangkau pembangun.
+
+Jika anda [new to public speaking](https://speaking.io/), mulakan dengan mencari pertemuan tempatan yang berkaitan dengan bahasa atau ekosistem projek anda.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
+  Saya agak gementar pergi ke PyCon. Saya memberi ceramah, saya hanya akan mengetahui beberapa orang di sana, saya akan pergi selama seminggu. (...) Saya tidak seharusnya risau. PyCon sangat hebat! (...) Semua orang sangat ramah dan ramah, sehinggakan saya jarang mendapat masa untuk tidak bercakap dengan orang!
+  <p markdown="1" class="pquote-credit">
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+  </p>
+</aside>
+
+Sekiranya anda tidak pernah bercakap di acara sebelumnya, adalah normal untuk merasa gementar! Ingatlah bahawa khalayak anda hadir kerana mereka benar-benar ingin mendengar tentang karya anda.
+
+Semasa anda menulis ceramah anda, tumpukan perhatian kepada perkara yang menarik dan menarik perhatian penonton anda. Pastikan bahasa anda mesra dan mudah didekati. Senyum, bernafas, dan bersenang-senang.
+
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
+  Apabila anda mula menulis ceramah anda, tidak kira apa topik anda, ia dapat membantu sekiranya anda melihat perbincangan anda sebagai cerita yang anda sampaikan kepada orang lain.
+  <p markdown="1" class="pquote-credit">
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+  </p>
+</aside>
+
+Apabila anda merasa bersedia, pertimbangkan untuk bercakap di persidangan untuk mempromosikan projek anda. Persidangan dapat membantu anda menjangkau lebih banyak orang, kadang-kadang dari seluruh dunia.
+
+Cari persidangan yang khusus untuk bahasa atau ekosistem anda. Sebelum anda menyampaikan ceramah anda, selidiki persidangan untuk menyesuaikan ceramah anda untuk hadirin dan tingkatkan peluang anda untuk diterima untuk bercakap di persidangan. Anda sering dapat mengetahui penonton anda dengan melihat penceramah persidangan.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
+  Saya menulis dengan sangat baik kepada orang-orang JSConf dan meminta mereka memberi saya slot di mana saya dapat membentangkannya di JSConf EU. (...) Saya sangat takut, menunjukkan perkara ini yang telah saya kerjakan selama enam bulan. (...) Sepanjang masa saya hanya berfikir, ya Tuhan. Apa yang saya buat di sini?
+  <p markdown="1" class="pquote-credit">
+— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+  </p>
+</aside>
+
+## Membangun reputasi
+
+Sebagai tambahan kepada strategi yang dinyatakan di atas, cara terbaik untuk mengajak orang untuk berkongsi dan menyumbang kepada projek anda adalah dengan berkongsi dan menyumbang kepada projek mereka.
+
+Membantu pendatang baru, berkongsi sumber, dan memberikan sumbangan yang teliti untuk projek orang lain akan membantu anda membina reputasi positif. Menjadi ahli yang aktif dalam komuniti sumber terbuka akan membantu orang mempunyai konteks untuk pekerjaan anda dan lebih cenderung untuk memberi perhatian dan berkongsi projek anda. Membangun hubungan dengan projek sumber terbuka yang lain malah boleh menjalin kerjasama rasmi.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
+  Satu-satunya sebab urllib3 adalah perpustakaan Python pihak ketiga yang paling popular hari ini adalah kerana ia adalah sebahagian daripada permintaan.
+  <p markdown="1" class="pquote-credit">
+— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+  </p>
+</aside>
+
+Tidak terlalu awal, atau terlambat, untuk mula membina reputasi anda Walaupun anda sudah melancarkan projek anda sendiri, teruskan mencari cara untuk menolong orang lain.
+
+Tidak ada penyelesaian semalam untuk membina penonton. Memperoleh kepercayaan dan penghormatan orang lain memerlukan masa, dan membina reputasi anda tidak akan pernah berakhir.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
+  PhantomJS dilancarkan untuk pertama kalinya pada awal tahun 2011. (...) Saya menyebarkan berita dengan cara biasa: Saya tweet mengenainya, saya menulis catatan blog mengenai perkara-perkara yang boleh anda lakukan dengannya, saya menyebutnya semasa pelbagai perbincangan dalam perjumpaan. Ketika menjadi lebih terkenal pada tahun 2014, saya mula memberikan persembahan mengenainya.
+  <p markdown="1" class="pquote-credit">
+— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
+  </p>
+</aside>
+
+## Terus!
+
+Mungkin memerlukan masa yang lama sebelum orang melihat projek sumber terbuka anda. Tak mengapa! Beberapa projek yang paling popular hari ini mengambil masa bertahun-tahun untuk mencapai tahap aktiviti yang tinggi. Fokus pada membina hubungan dan bukannya berharap projek anda mendapat populariti secara spontan. Bersabarlah, dan teruskan berkongsi karya anda dengan mereka yang menghargainya.
\ No newline at end of file
diff --git a/_articles/ms/getting-paid.md b/_articles/ms/getting-paid.md
new file mode 100644
index 00000000000..1722caa7396
--- /dev/null
+++ b/_articles/ms/getting-paid.md
@@ -0,0 +1,191 @@
+---
+lang: ms
+title: Mendapat Bayaran untuk Kerja Sumber Terbuka
+description: Pertahankan kerja anda dalam sumber terbuka dengan mendapatkan sokongan kewangan untuk masa atau projek anda.
+class: getting-paid
+toc:
+  why-some-people-seek-financial-support: "Mengapa sebilangan orang meminta sokongan kewangan"
+  funding-your-own-time: "Membiayai masa anda sendiri"
+  finding-funding-for-your-project: "Mencari dana untuk projek anda"
+  building-a-case-for-financial-support: "Membina kes untuk sokongan kewangan"
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+  - best-practices
+  - leadership
+---
+
+## Mengapa sebilangan orang meminta sokongan kewangan
+
+Sebilangan besar kerja sumber terbuka adalah sukarela. Sebagai contoh, seseorang mungkin menemui bug dalam projek yang mereka gunakan dan mengirimkan perbaikan cepat, atau mereka mungkin senang bermain-main dengan projek sumber terbuka di masa lapang mereka.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
+Saya mencari projek pengaturcaraan "hobi" yang akan membuat saya sibuk sepanjang minggu sekitar Krismas. (...) Saya mempunyai komputer di rumah, dan tidak banyak yang lain di tangan saya. Saya memutuskan untuk menulis jurubahasa untuk bahasa skrip baru yang saya fikirkan akhir-akhir ini. (...) Saya memilih Python sebagai tajuk kerja.
+  <p markdown="1" class="pquote-credit">
+— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+  </p>
+</aside>
+
+Terdapat banyak sebab mengapa seseorang tidak mahu dibayar untuk pekerjaan sumber terbuka mereka.
+
+* **Mereka mungkin sudah mempunyai pekerjaan sepenuh masa yang mereka sukai,** yang membolehkan mereka menyumbang kepada sumber terbuka pada masa lapang.
+* **Mereka gemar memikirkan sumber terbuka sebagai hobi** atau melarikan diri secara kreatif dan tidak ingin merasa berkewajiban dari segi kewangan untuk mengerjakan projek mereka.
+* **Mereka mendapat faedah lain dari memberikan sumbangan kepada sumber terbuka,** seperti membangun reputasi atau portfolio mereka, mempelajari kemahiran baru, atau merasa lebih dekat dengan komuniti.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
+  Sumbangan kewangan menambah rasa tanggungjawab, bagi sebilangan orang. (...) Penting bagi kita, di dunia yang serentak dengan dunia pantas, di mana kita hidup, untuk dapat mengatakan "tidak sekarang, saya merasa seperti melakukan sesuatu yang sama sekali berbeza".
+  <p markdown="1" class="pquote-credit">
+— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+  </p>
+</aside>
+
+Bagi yang lain, terutamanya ketika sumbangan sedang berlangsung atau memerlukan masa yang besar, bayaran untuk menyumbang kepada sumber terbuka adalah satu-satunya cara mereka dapat mengambil bahagian, sama ada kerana projek itu memerlukannya, atau atas sebab peribadi.
+
+Menyelenggara projek popular boleh menjadi tanggungjawab yang besar, memakan masa 10 atau 20 jam seminggu dan bukannya beberapa jam sebulan.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
+  Tanya mana-mana penyelenggara projek sumber terbuka, dan mereka akan memberitahu anda mengenai realiti jumlah kerja yang diperlukan untuk menguruskan projek. Anda mempunyai pelanggan. Anda sedang menyelesaikan masalah untuknya. Anda membuat ciri baru. Ini menjadi permintaan sebenar pada masa anda.
+  <p markdown="1" class="pquote-credit">
+— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+  </p>
+</aside>
+
+Pekerjaan bergaji juga membolehkan orang dari pelbagai lapisan masyarakat memberikan sumbangan yang bermakna. Sebilangan orang tidak mampu meluangkan masa yang belum dibayar untuk projek sumber terbuka, berdasarkan kedudukan kewangan semasa, hutang, atau keluarga atau kewajipan menjaga mereka yang lain. Ini bermakna dunia tidak pernah melihat sumbangan daripada orang-orang berbakat yang tidak dapat meluangkan masa mereka secara sukarela. Ini mempunyai implikasi etika, seperti @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), kerana pekerjaan yang dilakukan berat sebelah memihak kepada mereka yang sudah mempunyai kelebihan dalam hidup, yang kemudian memperoleh kelebihan tambahan berdasarkan sumbangan sukarelawan mereka, sementara yang lain yang tidak dapat menjadi sukarelawan kemudian tidak mendapat peluang kemudian, yang memperkuat saat ini kekurangan kepelbagaian dalam komuniti sumber terbuka.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
+   OSS memberikan faedah besar kepada industri teknologi, yang pada gilirannya, memberi manfaat kepada semua industri. (...) Namun, jika satu-satunya orang yang dapat memusatkan perhatiannya adalah orang yang beruntung dan yang taksub, maka ada potensi yang belum dimanfaatkan.
+  <p markdown="1" class="pquote-credit">
+— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+  </p>
+</aside>
+
+Sekiranya anda mencari sokongan kewangan, ada dua jalan yang perlu dipertimbangkan. Anda boleh membiayai masa anda sendiri sebagai penyumbang, atau anda dapat mencari dana organisasi untuk projek tersebut.
+
+## Membiayai masa anda sendiri
+
+Hari ini, banyak orang dibayar untuk bekerja secara sambilan atau sepenuh masa di sumber terbuka. Cara yang paling biasa untuk dibayar untuk masa anda adalah dengan berbincang dengan majikan anda.
+
+Lebih mudah untuk membuat kes untuk kerja sumber terbuka jika majikan anda benar-benar menggunakan projek ini, tetapi kreatif dengan usaha anda. Mungkin majikan anda tidak menggunakan projek itu, tetapi mereka menggunakan Python, dan mengekalkan projek Python yang popular membantu menarik pemaju Python baru. Mungkin itu menjadikan majikan anda kelihatan lebih mesra pemaju secara amnya.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
+  Seperti banyak sumber terbuka, saya bergelut dengan beban penyelenggaraan projek. Ketika mula-mula mula melakukan open source, saya selalu terlambat untuk mengerjakannya atau tepat ketika saya pulang ke rumah. (...) Saya dapat membincangkan masalah yang saya hadapi dengan bos saya dan kami mendapat idea tentang bagaimana kami dapat memasukkan tugas sumber terbuka memandangkan penggunaan Babel oleh kami sendiri.
+  <p markdown="1" class="pquote-credit">
+— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
+  </p>
+</aside>
+
+Sekiranya anda tidak mempunyai projek sumber terbuka yang sedia ada, anda ingin mengusahakannya, tetapi lebih suka bahawa hasil kerja anda sekarang bersumber terbuka, buatlah majikan anda membuka sumber perisian dalaman mereka.
+
+Banyak syarikat sedang mengembangkan program sumber terbuka untuk membina jenama mereka dan merekrut bakat berkualiti.
+
+@hueniverse, misalnya, mendapati bahawa ada alasan kewangan untuk membenarkannya [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Dan @jamesgpearce mendapati bahawa program sumber terbuka Facebook [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) dalam merekrut:
+
+> Ini sejalan dengan budaya penggodam kami, dan bagaimana organisasi kami dirasakan. Kami bertanya kepada pekerja kami, "Adakah anda mengetahui program perisian sumber terbuka di Facebook?". Dua pertiga berkata "Ya". Separuh mengatakan bahawa program ini memberi sumbangan positif kepada keputusan mereka untuk bekerja untuk kita. Ini bukan angka marginal, dan saya harap, trend yang berterusan.
+
+Sekiranya syarikat anda melalui laluan ini, penting untuk menjaga batas antara aktiviti komuniti dan syarikat. Pada akhirnya, sumber terbuka mempertahankan dirinya melalui sumbangan daripada orang di seluruh dunia, dan itu lebih besar daripada satu syarikat atau lokasi mana pun.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
+  Mendapat gaji untuk bekerja di sumber terbuka adalah peluang yang jarang dan luar biasa, tetapi anda tidak harus melepaskan semangat anda dalam proses ini. Kesungguhan anda adalah mengapa syarikat mahu membayar anda.
+  <p markdown="1" class="pquote-credit">
+— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+  </p>
+</aside>
+
+Sekiranya anda tidak dapat meyakinkan majikan anda untuk memprioritaskan pekerjaan sumber terbuka, pertimbangkan untuk mencari majikan baru yang mendorong sumbangan pekerja kepada sumber terbuka. Cari syarikat yang membuat dedikasi mereka untuk kerja sumber terbuka secara eksplisit. Sebagai contoh:
+
+* Beberapa syarikat, seperti [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), mempunyai laman web yang menonjolkan penglibatan mereka dalam sumber terbuka
+* [Zalando](https://opensource.zalando.com) menerbitkannya [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) untuk pekerja
+
+Projek yang berasal dari syarikat besar, seperti [Go](https://github.com/golang) atau [React](https://github.com/facebook/react), kemungkinan juga akan menggaji orang untuk bekerja di sumber terbuka.
+
+Bergantung pada keadaan peribadi anda, anda boleh mencuba mengumpulkan wang secara bebas untuk membiayai kerja sumber terbuka anda. Sebagai contoh:
+
+* @gaearon membiayai kerjanya [Redux](https://github.com/reactjs/redux) melalui [Patreon crowdfunding campaign](https://redux.js.org/)
+* @andrewgodwin membiayai kerja migrasi skema Django [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+Akhirnya, kadang-kadang projek sumber terbuka memberi banyak manfaat kepada masalah yang mungkin anda pertimbangkan untuk membantu.
+
+* @ConnorChristie dapat dibayar[helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol berfungsi di perpustakaan javascript mereka [through a bounty on gitcoin](https://gitcoin.co/).
+* @mamiM melakukan terjemahan Jepun untuk @MetaMask selepas [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+
+## Mencari dana untuk projek anda
+
+Di luar pengaturan untuk penyumbang individu, kadang-kadang projek mengumpulkan wang dari syarikat, individu, atau yang lain untuk membiayai kerja yang sedang berjalan.
+
+Pembiayaan organisasi mungkin dilakukan untuk membayar penyumbang semasa, meliputi kos menjalankan projek (seperti biaya hosting), atau melabur ke dalam ciri atau idea baru.
+
+Apabila populariti sumber terbuka meningkat, mencari dana untuk projek masih eksperimen, tetapi ada beberapa pilihan umum yang tersedia.
+
+### Kumpulkan wang untuk pekerjaan anda melalui kempen crowdfunding atau tajaan
+
+Mencari tajaan berfungsi dengan baik jika anda sudah mempunyai khalayak atau reputasi yang kuat, atau projek anda sangat popular.
+Beberapa contoh projek yang ditaja termasuk:
+
+* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
+* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803)
+* **[Ruby Together](https://rubytogether.org/),** organisasi bukan untung yang membayar untuk bekerja [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), dan projek infrastruktur Ruby yang lain
+
+### Buat aliran pendapatan
+
+Bergantung pada projek anda, anda mungkin dapat mengenakan bayaran untuk sokongan komersial, pilihan yang dihoskan, atau ciri tambahan. Beberapa contoh termasuk:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** menawarkan versi berbayar untuk sokongan tambahan
+* **[Travis CI](https://github.com/travis-ci)** menawarkan versi berbayar produknya
+* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+
+Beberapa projek popular, seperti [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker),malah mengumpulkan modal teroka untuk menyokong pertumbuhan perniagaan mereka.
+
+### Memohon pembiayaan geran
+
+Beberapa yayasan dan syarikat perisian menawarkan geran untuk kerja sumber terbuka. Kadang kala, geran boleh dibayar kepada individu tanpa menubuhkan entiti undang-undang untuk projek tersebut.
+
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** menerima geran dari [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)**kerja dibiayai oleh[Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** menerima geran dari[Sloan Foundation](https://sloan.org/programs/digital-technology)
+* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+
+Untuk pilihan dan kajian kes yang lebih terperinci, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) mendapat bayaran untuk kerja sumber terbuka. Jenis pembiayaan yang berbeza memerlukan kemahiran yang berbeza, jadi pertimbangkan kekuatan anda untuk mengetahui pilihan mana yang paling sesuai untuk anda.
+
+## Membangun kes untuk sokongan kewangan
+
+Sama ada projek anda adalah idea baru, atau sudah ada selama bertahun-tahun, anda harus meletakkan pemikiran penting untuk mengenal pasti sasaran anda dan membuat kes yang menarik.
+
+Sama ada anda ingin membayar untuk masa anda sendiri, atau mengumpul dana untuk projek, anda seharusnya dapat menjawab soalan berikut.
+
+### Kesan
+
+Mengapa projek ini berguna? Mengapa pengguna anda, atau calon pengguna, sangat menyukainya? Di mana ia akan berada dalam lima tahun?
+
+### Daya tarikan
+
+Cuba kumpulkan bukti bahawa projek anda penting, sama ada metrik, anekdot, atau testimoni. Adakah terdapat syarikat atau orang terkenal yang menggunakan projek anda sekarang? Sekiranya tidak, adakah orang ternama menyokongnya?
+
+### Nilai untuk pengembara
+
+Pemberi dana, sama ada majikan anda atau yayasan pemberian dana, sering didekati dengan peluang. Mengapa mereka harus menyokong projek anda berbanding peluang lain? Bagaimana mereka mendapat keuntungan secara peribadi?
+
+### Penggunaan dana
+
+Apa sebenarnya yang akan anda capai dengan dana yang dicadangkan? Fokus pada pencapaian projek atau hasil daripada membayar gaji.
+
+### Bagaimana anda akan menerima dana
+
+Adakah pemegang dana mempunyai keperluan sekitar pengeluaran? Sebagai contoh, anda mungkin perlu menjadi bukan untung atau mempunyai penaja fiskal bukan untung. Atau mungkin dana mesti diberikan kepada kontraktor individu dan bukannya organisasi. Keperluan ini berbeza antara pemberi dana, jadi pastikan anda melakukan penyelidikan terlebih dahulu.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
+  Selama bertahun-tahun, kami menjadi sumber utama ikon mesra laman web, dengan komuniti lebih daripada 20 juta orang dan telah dipaparkan di lebih daripada 70 juta laman web, termasuk Whitehouse.gov. (...) Versi 4 adalah tiga tahun yang lalu. Teknologi laman web telah banyak berubah sejak itu, dan terus terang, Font Awesome semakin basi. (...) Itulah sebabnya kami memperkenalkan Font Awesome 5. Kami memodenkan dan menulis semula CSS dan merancang semula setiap ikon dari atas ke bawah. Kami bercakap reka bentuk yang lebih baik, konsistensi yang lebih baik, dan mudah dibaca.
+  <p markdown="1" class="pquote-credit">
+— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+  </p>
+</aside>
+
+## Eksperimen dan jangan menyerah
+
+Mengumpulkan wang tidak mudah, sama ada anda projek sumber terbuka, bukan untung, atau permulaan perisian, dan dalam kebanyakan kes memerlukan anda untuk kreatif. Mengenal pasti bagaimana anda mahu dibayar, melakukan penyelidikan anda, dan meletakkan diri anda di kasut penyokong anda akan membantu anda membina kes pembiayaan yang meyakinkan.
diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
new file mode 100644
index 00000000000..efe6fefa00f
--- /dev/null
+++ b/_articles/ms/how-to-contribute.md
@@ -0,0 +1,534 @@
+---
+lang: ms
+title: Cara Menyumbang kepada Sumber Terbuka
+description: Ingin menyumbang kepada sumber terbuka? Panduan untuk membuat sumbangan sumber terbuka, untuk pertama kali dan untuk veteran.
+class: contribute
+toc:
+  why-contribute-to-open-source: "Mengapa menyumbang kepada sumber terbuka?"
+  what-it-means-to-contribute: "Apa maksudnya menyumbang"
+  orienting-yourself-to-a-new-project: "Mengarahkan diri anda ke projek baru"
+  finding-a-project-to-contribute-to: "Mencari projek untuk disumbangkan"
+  how-to-submit-a-contribution: "Cara menghantar sumbangan"
+  what-happens-after-you-submit-a-contribution: "Apa yang berlaku setelah anda menghantar sumbangan"
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+  - beginners
+  - building
+---
+
+## Why contribute to open source?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
+  Mengusahakan \ [freenode \] membantu saya memperoleh banyak kemahiran yang kemudian saya gunakan untuk pengajian di universiti dan pekerjaan sebenar saya. Saya fikir mengusahakan projek sumber terbuka membantu saya sama seperti membantu projek!
+  <p markdown="1" class="pquote-credit">
+— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+  </p>
+</aside>
+
+Menyumbang kepada sumber terbuka boleh menjadi kaedah yang bermanfaat untuk belajar, mengajar, dan membina pengalaman dalam apa sahaja kemahiran yang dapat anda bayangkan.
+
+Mengapa orang menyumbang kepada sumber terbuka? Banyak sebab!
+
+### Perbaiki perisian yang anda percayai
+
+Banyak penyumbang sumber terbuka bermula dengan menjadi pengguna perisian yang mereka sumbangkan. Apabila anda menemui bug dalam perisian sumber terbuka yang anda gunakan, anda mungkin ingin melihat sumbernya untuk melihat apakah anda boleh menambalnya sendiri. Sekiranya demikian, menyumbang kembali adalah cara terbaik untuk memastikan bahawa rakan anda (dan anda sendiri semasa anda mengemas kini ke keluaran seterusnya) akan dapat memanfaatkannya.
+
+### Meningkatkan kemahiran yang ada
+
+Sama ada pengekodan, reka bentuk antara muka pengguna, reka bentuk grafik, penulisan, atau penyusunan, jika anda mencari latihan, ada tugas untuk anda dalam projek sumber terbuka.
+
+### Berjumpa dengan orang yang berminat dengan perkara serupa
+
+Projek sumber terbuka dengan komuniti yang mesra dan mesra membuatkan orang kembali bertahun-tahun. Banyak orang menjalin persahabatan sepanjang hayat melalui penyertaan mereka dalam sumber terbuka, sama ada ia saling bertemu di persidangan atau sembang dalam talian lewat malam mengenai burrito.
+
+### Cari mentor dan ajar orang lain
+
+Bekerja dengan orang lain dalam projek bersama bermaksud anda harus menerangkan bagaimana anda melakukan sesuatu, dan juga meminta bantuan orang lain. Tindakan belajar dan mengajar boleh menjadi aktiviti yang memuaskan bagi semua orang yang terlibat.
+
+### Bina artifak awam yang membantu anda mengembangkan reputasi (dan kerjaya)
+
+Secara definisi, semua karya sumber terbuka anda bersifat umum, yang bermaksud anda mendapat contoh percuma untuk dibawa ke mana sahaja sebagai demonstrasi mengenai apa yang boleh anda lakukan.
+
+### Pelajari kemahiran orang
+
+Sumber terbuka menawarkan peluang untuk mempraktikkan kepemimpinan dan kemahiran pengurusan, seperti menyelesaikan konflik, mengatur pasukan orang, dan mengutamakan pekerjaan.
+
+### Memberi kuasa untuk dapat membuat perubahan, walaupun yang kecil
+
+Anda tidak perlu menjadi penyumbang seumur hidup untuk menikmati berpartisipasi dalam sumber terbuka. Adakah anda pernah melihat kesalahan ketik di laman web, dan berharap ada yang memperbaikinya? Pada projek sumber terbuka, anda boleh melakukannya. Sumber terbuka membantu orang-orang merasa bebas sepanjang hidup mereka dan bagaimana mereka mengalami dunia, dan itu sendiri sangat memuaskan.
+
+## Apa maksudnya menyumbang
+
+Sekiranya anda penyumbang sumber terbuka baru, prosesnya boleh menakutkan. Bagaimana anda mencari projek yang betul? Bagaimana jika anda tidak tahu bagaimana membuat kod? Bagaimana jika ada yang salah?
+
+Tidak perlu risau! Terdapat pelbagai cara untuk terlibat dengan projek sumber terbuka, dan beberapa petua akan membantu anda memanfaatkan sepenuhnya pengalaman anda.
+
+### Anda tidak perlu menyumbang kod
+
+Kesalahpahaman umum mengenai menyumbang kepada sumber terbuka ialah anda perlu menyumbang kod. Sebenarnya, selalunya bahagian lain dari projek itu [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). Anda akan melaksanakan projek ini dengan menawarkan banyak sumbangan seperti ini!
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
+ Saya terkenal dengan karya saya di CocoaPods, tetapi kebanyakan orang tidak tahu bahawa saya sebenarnya tidak membuat kerja sebenar pada alat CocoaPods itu sendiri. Masa saya dalam projek ini kebanyakannya dihabiskan untuk melakukan perkara seperti dokumentasi dan mengerjakan penjenamaan.
+  <p markdown="1" class="pquote-credit">
+— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+  </p>
+</aside>
+
+Walaupun anda suka menulis kod, jenis sumbangan lain adalah kaedah terbaik untuk terlibat dengan projek dan bertemu dengan ahli komuniti lain. Membina hubungan tersebut akan memberi anda peluang untuk bekerja di bahagian lain projek.
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
+ Saya pertama kali menghubungi pasukan pengembangan Python (aka python-dev) ketika saya menghantar e-mel kepada senarai mel pada 17 Jun 2002 mengenai penerimaan tampalan saya. Saya dengan cepat menangkap bug sumber terbuka, dan memutuskan untuk mula menguruskan pencernaan e-mel untuk kumpulan itu. Mereka memberi saya alasan yang baik untuk meminta penjelasan mengenai sesuatu topik, tetapi lebih kritikal saya dapat melihat ketika seseorang menunjukkan sesuatu yang perlu diperbaiki.
+  <p markdown="1" class="pquote-credit">
+— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
+  </p>
+</aside>
+
+### Adakah anda suka merancang acara?
+
+* Mengadakan bengkel atau pertemuan mengenai projek tersebut,[like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Mengatur persidangan projek (jika ada)
+* Membantu ahli komuniti mencari persidangan yang tepat dan mengemukakan cadangan untuk bercakap
+
+### Adakah anda suka merancang?
+
+* Susun semula susun atur untuk meningkatkan kebolehgunaan projek
+* Lakukan penyelidikan pengguna untuk menyusun semula dan menyempurnakan navigasi atau menu projek,[like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Kumpulkan panduan gaya untuk membantu projek mempunyai reka bentuk visual yang konsisten
+* Buat seni untuk t-shirt atau logo baru,[like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+
+### Adakah anda suka menulis?
+
+* Tulis dan perbaiki dokumentasi projek
+* Buat folder contoh yang menunjukkan bagaimana projek itu digunakan
+* Mulakan buletin untuk projek ini, atau pilih sorotan dari senarai surat
+* Tulis tutorial untuk projek itu,[like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Tulis terjemahan untuk dokumentasi projek
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
+ Serius, \ [dokumentasi \] sangat penting. Dokumentasi setakat ini hebat dan menjadi ciri pembunuh Babel. Ada bahagian yang tentu dapat menggunakan beberapa karya dan bahkan penambahan perenggan di sini atau di sana sangat dihargai.
+  <p markdown="1" class="pquote-credit">
+— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+  </p>
+</aside>
+
+### Adakah anda suka mengatur?
+
+* Pautkan ke masalah pendua, dan cadangkan label terbitan baru, agar segala sesuatu tetap teratur
+* Selesaikan masalah terbuka dan cadangkan tutup yang lama,[like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
+*Tanyakan penjelasan mengenai isu yang baru dibuka untuk memajukan perbincangan
+
+### Adakah anda suka membuat kod?
+
+* Cari masalah terbuka untuk mengatasi, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+*Tanya sama ada anda dapat membantu menulis ciri baru
+* Automatik penyediaan projek
+* Meningkatkan perkakas dan ujian
+
+### Adakah anda suka menolong orang?
+
+* Jawab soalan mengenai projek seperti, Stack Overflow([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
+*Jawab soalan untuk orang yang mempunyai masalah terbuka
+* Bantu menyederhanakan papan perbincangan atau saluran perbualan
+
+### Adakah anda suka menolong orang lain membuat kod?
+
+* Semak kod pada kiriman orang lain
+* Tulis tutorial bagaimana projek dapat digunakan
+* Tawaran untuk mentor penyumbang lain,[like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### Anda tidak hanya perlu mengerjakan projek perisian!
+
+Walaupun "sumber terbuka" sering merujuk kepada perisian, anda boleh berkolaborasi dengan apa sahaja. Terdapat buku, resipi, senarai, dan kelas yang dikembangkan sebagai projek sumber terbuka.
+
+Sebagai contoh:
+
+* @sindresorhus kurate [list of "awesome" lists](https://github.com/sindresorhus/awesome)
+* @h5bp mengekalkan [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) untuk calon pemaju depan
+* @stuartlynn dan @nicole-a-tesla dibuat [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+
+Walaupun anda seorang pembangun perisian, mengerjakan projek dokumentasi dapat membantu anda memulakan sumber terbuka. Selalunya kurang menakutkan untuk mengerjakan projek yang tidak melibatkan kod, dan proses kolaborasi akan membina keyakinan dan pengalaman anda.
+
+## Mengarahkan diri anda ke projek baru
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
+  Sekiranya anda pergi ke pelacak masalah dan perkara kelihatan membingungkan, itu bukan hanya anda. Alat ini memerlukan banyak pengetahuan tersirat, tetapi orang dapat menolong anda menavigasi dan anda boleh mengemukakan soalan kepada mereka.
+  <p markdown="1" class="pquote-credit">
+— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+  </p>
+</aside>
+
+Untuk apa-apa yang lebih daripada kesalahan typo, menyumbang kepada sumber terbuka adalah seperti berjalan ke sekumpulan orang asing di pesta. Sekiranya anda mula bercakap tentang llamas, semasa mereka sedang dalam perbincangan mengenai ikan mas, mereka mungkin akan melihat anda sedikit aneh.
+
+Sebelum melompat secara membabi buta dengan cadangan anda sendiri, mulailah dengan belajar membaca ruangan. Melakukannya meningkatkan peluang idea anda diperhatikan dan didengar.
+
+### Anatomi projek sumber terbuka
+
+Setiap komuniti sumber terbuka berbeza.
+
+Menghabiskan bertahun-tahun untuk satu projek sumber terbuka bermakna anda telah mengetahui satu projek sumber terbuka. Pindah ke projek lain, dan anda mungkin mendapati perbendaharaan kata, norma, dan gaya komunikasi sama sekali berbeza.
+
+Yang mengatakan, banyak projek sumber terbuka mengikuti struktur organisasi yang serupa. Memahami peranan masyarakat dan proses keseluruhan akan membantu anda berorientasi dengan cepat ke mana-mana projek baru.
+
+Projek sumber terbuka khas mempunyai jenis orang berikut:
+
+* **Pengarang:** Orang atau organisasi yang membuat projek
+* **Pemilik:** Orang yang mempunyai hak milik pentadbiran ke atas organisasi atau repositori (tidak selalu sama dengan pengarang asal)
+* **Penyelenggara:** Penyumbang yang bertanggungjawab memacu visi dan mengurus aspek organisasi projek (Mereka juga mungkin pengarang atau pemilik projek.)
+* **Penyumbang:** Semua orang yang telah menyumbang sesuatu untuk projek ini
+* **Anggota Komuniti:** Orang yang menggunakan projek. Mereka mungkin aktif dalam perbualan atau menyatakan pendapat mereka mengenai arah projek
+
+Projek yang lebih besar mungkin juga mempunyai jawatankuasa kecil atau kumpulan kerja yang berfokus pada tugas yang berbeza, seperti perkakas, percobaan, penyederhanaan masyarakat, dan pengorganisasian acara. Lihat di laman web projek untuk halaman "pasukan", atau di repositori untuk dokumentasi tadbir urus, untuk mendapatkan maklumat ini.
+
+Projek juga mempunyai dokumentasi. Fail-fail ini biasanya disenaraikan di tingkat atas repositori.
+
+* **LICENSE:** Secara definisi, setiap projek sumber terbuka mesti mempunyai[open source license](https://choosealicense.com).Sekiranya projek itu tidak mempunyai lesen, ia bukan sumber terbuka.
+* **README:** README adalah manual arahan yang mengalu-alukan ahli komuniti baru untuk projek ini. Ia menerangkan mengapa projek ini berguna dan bagaimana memulakannya.
+* **CONTRIBUTING:** Manakala README membantu orang _menggunakan projek, menyumbang dokumen membantu orang _memberi sumbangan_ dalam projek. Ia menerangkan jenis sumbangan apa yang diperlukan dan bagaimana prosesnya berjalan. Walaupun tidak setiap projek mempunyai fail CONTRIBUTING, kehadirannya memberi isyarat bahawa ini adalah projek yang dapat disumbangkan.
+* **CODE_OF_CONDUCT:** Kod tingkah laku menetapkan peraturan asas untuk tingkah laku peserta yang berkaitan dan membantu mempermudah persekitaran yang ramah dan mesra. Walaupun tidak setiap projek mempunyai fail CODE_OF_CONDUCT, kehadirannya menunjukkan bahawa ini adalah projek yang baik untuk disumbangkan.
+* **Other documentation:** Mungkin ada dokumentasi tambahan, seperti tutorial, panduan, atau dasar pemerintahan, terutama pada proyek yang lebih besar.
+
+Akhirnya, projek sumber terbuka menggunakan alat berikut untuk mengatur perbincangan. Membaca arkib akan memberi anda gambaran yang baik tentang bagaimana masyarakat berfikir dan berfungsi.
+
+* **Issue tracker:** Di mana orang membincangkan masalah yang berkaitan dengan projek.
+* **Pull requests:** Tempat orang membincangkan dan mengkaji perubahan yang sedang dilakukan.
+* **Discussion forums or mailing lists:** Beberapa projek mungkin menggunakan saluran ini untuk topik perbualan (misalnya, _ "Bagaimana saya ..." _ atau _ "Apa pendapat anda tentang ..." _ bukannya laporan pepijat atau permintaan ciri). Yang lain menggunakan pelacak masalah untuk semua perbualan.
+* **Synchronous chat channel:** Beberapa projek menggunakan saluran sembang (seperti Slack atau IRC) untuk perbualan santai, kolaborasi, dan pertukaran cepat.
+
+## Mencari projek untuk disumbangkan
+
+Sekarang setelah anda mengetahui bagaimana projek sumber terbuka berfungsi, inilah masanya untuk mencari projek untuk disumbangkan!
+
+Sekiranya anda tidak pernah menyumbang kepada sumber terbuka sebelumnya, dapatkan nasihat Presiden A.S. John F. Kennedy, yang pernah berkata, _ "Jangan tanya apa yang boleh dilakukan oleh negara anda untuk anda - tanyakan apa yang boleh anda lakukan untuk negara anda." _
+
+Menyumbang kepada sumber terbuka berlaku di semua peringkat, di semua projek. Anda tidak perlu terlalu memikirkan apa sebenarnya sumbangan pertama anda, atau bagaimana bentuknya.
+
+Sebaliknya, mulakan dengan memikirkan projek yang sudah anda gunakan, atau mahu gunakan. Projek yang akan anda sumbangkan secara aktif adalah projek yang anda mahukan.
+
+Dalam projek-projek itu, setiap kali anda merasa berfikir bahawa sesuatu boleh menjadi lebih baik atau berbeza, bertindaklah mengikut naluri anda.
+
+Sumber terbuka bukan kelab eksklusif; ia dibuat oleh orang seperti anda. "Sumber terbuka" hanyalah istilah yang baik untuk menangani masalah dunia sebagai penyelesaian.
+
+Anda mungkin mengimbas README dan mencari pautan yang rosak atau kesalahan ketik. Atau anda pengguna baru dan anda melihat ada sesuatu yang rosak, atau masalah yang anda fikirkan semestinya ada dalam dokumentasi. Daripada mengabaikannya dan terus bergerak, atau meminta orang lain untuk memperbaikinya, lihat sama ada anda dapat membantu dengan memasukkan masuk. Itulah sumber terbuka!
+
+> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) untuk sumber terbuka adalah dokumentasi, seperti kesalahan ketik, memformat semula, atau menulis terjemahan.
+
+Sekiranya anda mencari masalah yang ada yang dapat anda perbaiki, setiap projek sumber terbuka mempunyai `/contribute`halaman yang menyoroti masalah mesra pemula yang boleh anda mulakan. Navigasi ke halaman utama repositori di GitHub, dan tambahkan `/contribute` di hujung URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+Anda juga boleh menggunakan salah satu sumber berikut untuk membantu anda menemui dan menyumbang kepada projek baru:
+
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
+
+### Senarai semak sebelum anda menyumbang
+
+Apabila anda menemui projek yang ingin anda sumbangkan, lakukan imbasan pantas untuk memastikan bahawa projek tersebut sesuai untuk menerima sumbangan. Jika tidak, kerja keras anda mungkin tidak akan mendapat sambutan.
+
+Berikut adalah senarai semak yang berguna untuk menilai sama ada projek itu baik untuk penyumbang baru.
+
+**Memenuhi definisi sumber terbuka**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+  Adakah ia mempunyai lesen? Biasanya, terdapat fail bernama LICENSE di akar repositori.
+  </label>
+</div>
+
+** Projek secara aktif menerima sumbangan **
+
+Lihat aktiviti komit di cawangan induk. Di GitHub, anda dapat melihat maklumat ini di laman utama repositori.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+  Bilakah komitmen terbaru?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+  Berapakah jumlah penyumbang projek ini?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+  Berapa kerapkah orang melakukan? (Di GitHub, anda boleh mendapatkannya dengan mengklik "Komitmen" di bar atas.)
+  </label>
+</div>
+
+Seterusnya, perhatikan masalah projek.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Berapa banyak isu terbuka yang ada?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Adakah penyelenggara bertindak balas dengan cepat terhadap masalah ketika dibuka?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Adakah terdapat perbincangan aktif mengenai isu-isu tersebut?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Are the issues recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Adakah masalah ditutup? (Di GitHub, klik tab "tertutup" di halaman Isu untuk melihat masalah tertutup.)
+  </label>
+</div>
+
+Sekarang lakukan perkara yang sama untuk permintaan tarikan projek.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    Berapa banyak permintaan tarik terbuka yang ada?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox20" class="overflow-hidden d-block text-normal">
+    Adakah penyelenggara bertindak balas dengan cepat untuk menarik permintaan ketika dibuka?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Adakah perbincangan aktif mengenai permintaan tarik?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    Adakah permintaan tarikan baru-baru ini?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox13" class="overflow-hidden d-block text-normal">
+    Sejauh mana baru-baru ini permintaan penggabungan digabungkan? (Di GitHub, klik tab "tertutup" di halaman Tarik Permintaan untuk melihat PR tertutup.)
+  </label>
+</div>
+
+** Projek dialu-alukan **
+
+Projek yang mesra dan mesra memberi isyarat bahawa mereka akan menerima penyumbang baru.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox14" class="overflow-hidden d-block text-normal">
+    Adakah penyelenggara memberi respons yang baik terhadap soalan dalam masalah?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox15" class="overflow-hidden d-block text-normal">
+    Adakah orang ramah dalam isu, forum perbincangan, dan sembang (misalnya, IRC atau Slack)?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox16" class="overflow-hidden d-block text-normal">
+    Adakah permintaan tarik disemak?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox17" class="overflow-hidden d-block text-normal">
+    Adakah penyelenggara mengucapkan terima kasih atas sumbangan mereka?
+  </label>
+</div>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Bila-bila masa anda melihat urutan panjang, periksa jawapan dari pemaju teras yang datang lewat. Adakah mereka merangkum secara konstruktif, dan mengambil langkah-langkah untuk membuat keputusan dengan tetap sopan? Sekiranya anda melihat banyak peperangan api berlaku, itu sering kali menandakan bahawa tenaga akan menjadi hujah dan bukannya menjadi pembangunan.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+  </p>
+</aside>
+
+## Cara menghantar sumbangan
+
+Anda telah menjumpai projek yang anda suka, dan anda sudah bersedia untuk memberikan sumbangan. Akhirnya! Inilah cara mendapatkan sumbangan anda dengan cara yang betul.
+
+### Berkomunikasi dengan berkesan
+
+Sama ada anda penyumbang sekali atau cuba menyertai komuniti, bekerja dengan orang lain adalah salah satu kemahiran terpenting yang akan anda kembangkan dalam sumber terbuka.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
+  \ [Sebagai penyumbang baru, \] Saya dengan cepat menyedari bahawa saya harus mengemukakan soalan sekiranya saya mahu menutup masalah ini. Saya melayari asas kod. Setelah mengetahui apa yang sedang berlaku, saya meminta lebih banyak arah. Dan voilà! Saya dapat menyelesaikan masalah ini setelah mendapat semua butiran berkaitan yang saya perlukan.
+  <p markdown="1" class="pquote-credit">
+— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+  </p>
+</aside>
+
+Sebelum anda membuka masalah atau menarik permintaan, atau mengajukan soalan dalam sembang, ingatlah perkara ini untuk membantu idea anda disampaikan dengan berkesan.
+
+** Beri konteks. ** Bantu orang lain dengan pantas. Sekiranya anda mengalami ralat, jelaskan apa yang anda cuba lakukan dan bagaimana menghasilkannya. Sekiranya anda mencadangkan idea baru, jelaskan mengapa anda berpendapat bahawa ia berguna untuk projek ini (bukan hanya untuk anda!).
+
+> 😇 _ "X tidak berlaku semasa saya melakukan Y" _
+>
+> 😢 _ "X rosak! Sila perbaiki." _
+
+** Lakukan kerja rumah anda terlebih dahulu. ** Tidak perlu mengetahui apa-apa, tetapi tunjukkan bahawa anda telah mencuba. Sebelum meminta bantuan, pastikan untuk memeriksa README, dokumentasi, masalah (terbuka atau tertutup), senarai mel, dan cari di internet untuk mendapatkan jawapan. Orang akan menghargai apabila anda menunjukkan bahawa anda cuba belajar.
+
+> 😇 _ "Saya tidak pasti bagaimana melaksanakan X. Saya memeriksa dokumen bantuan dan tidak menemui sebutan." _
+>
+> 😢 _ "Bagaimana saya X?" _
+
+** Jauhkan permintaan pendek dan langsung. ** Sama seperti menghantar e-mel, setiap sumbangan, tidak kira seberapa sederhana atau bermanfaat, memerlukan ulasan orang lain. Banyak projek mempunyai lebih banyak permintaan masuk daripada orang yang ada untuk membantu. Bersikap ringkas. Anda akan meningkatkan peluang seseorang dapat menolong anda.
+
+> 😇 _ "Saya ingin menulis tutorial API." _
+>
+> 😢 _ "Saya memandu di jalan raya pada suatu hari dan berhenti untuk mencari minyak, dan kemudian saya mempunyai idea yang luar biasa ini untuk sesuatu yang seharusnya kita lakukan, tetapi sebelum saya menerangkannya, izinkan saya menunjukkan kepada anda ..." _
+
+** Jauhkan semua komunikasi untuk umum. ** Walaupun menggoda, jangan menghubungi penyelenggara secara tertutup kecuali anda perlu berkongsi maklumat sensitif (seperti masalah keselamatan atau pelanggaran tingkah laku serius). Apabila perbualan anda tetap terbuka, lebih ramai orang dapat belajar dan mendapat faedah daripada pertukaran anda. Perbincangan boleh menjadi sumbangan mereka sendiri.
+
+>😇 _ (sebagai komen) "@ -maintainer Hai! Bagaimana kita harus meneruskan PR ini?" _
+>
+> 😢 _ (sebagai e-mel) "Hai, maaf kerana mengganggu anda melalui e-mel, tetapi saya tertanya-tanya adakah anda berpeluang untuk mengkaji semula PR saya" _
+
+** Tidak apa-apa untuk mengemukakan soalan (tetapi bersabarlah!). ** Semua orang baru dalam projek ini pada satu ketika, dan bahkan penyumbang yang berpengalaman perlu terus maju ketika mereka melihat projek baru. Dengan cara yang sama, penyelenggara lama juga tidak selalu mengenal setiap bahagian projek. Tunjukkan kepada mereka kesabaran yang sama seperti yang anda mahukan kepada mereka.
+
+> 😇 _ "Terima kasih kerana melihat ralat ini. Saya mengikuti cadangan anda. Inilah hasilnya." _
+>
+> 😢 _ "Mengapa anda tidak dapat menyelesaikan masalah saya? Bukankah ini projek anda?" _
+
+** Hormati keputusan masyarakat. ** Idea anda mungkin berbeza dengan keutamaan atau visi masyarakat. Mereka mungkin memberikan maklum balas atau memutuskan untuk tidak meneruskan idea anda. Walaupun anda harus berbincang dan mencari kompromi, penyelenggara harus mematuhi keputusan anda lebih lama daripada yang anda mahukan. Sekiranya anda tidak bersetuju dengan arahan mereka, anda sentiasa boleh menggunakan garpu anda sendiri atau memulakan projek anda sendiri.
+
+> 😇 _ "Saya kecewa anda tidak dapat menyokong kes penggunaan saya, tetapi seperti yang anda jelaskan, ini hanya mempengaruhi sebahagian kecil pengguna, saya faham mengapa. Terima kasih kerana mendengar." _
+>
+> 😢 _ "Mengapa anda tidak menyokong kes penggunaan saya? Ini tidak boleh diterima!" _
+
+** Yang terpenting, jaga agar tetap berkelas. ** Sumber terbuka terdiri daripada kolaborator dari seluruh dunia. Konteks hilang di seluruh bahasa, budaya, geografi, dan zon waktu. Di samping itu, komunikasi bertulis menjadikannya lebih sukar untuk menyampaikan nada atau mood. Anggap niat baik dalam perbualan ini. Adalah baik untuk menolak idea dengan sopan, meminta lebih banyak konteks, atau memperjelas kedudukan anda. Cubalah tinggalkan internet di tempat yang lebih baik daripada ketika anda menjumpainya.
+
+### Mengumpulkan konteks
+
+Sebelum melakukan apa-apa, lakukan pemeriksaan cepat untuk memastikan idea anda tidak dibincangkan di tempat lain. Skim README projek, isu (terbuka dan tertutup), senarai mel, dan Stack Overflow. Anda tidak perlu menghabiskan berjam-jam untuk menyelesaikan segala-galanya, tetapi pencarian pantas untuk beberapa istilah utama sangat membantu.
+
+Sekiranya anda tidak menemui idea anda di tempat lain, anda sudah bersedia untuk bergerak. Sekiranya projek tersebut berada di GitHub, anda mungkin akan berkomunikasi dengan membuka masalah atau menarik permintaan:
+
+* **Masalah** seperti memulakan perbualan atau perbincangan
+* **Permintaan tarik** adalah untuk memulakan kerja penyelesaian
+* **Untuk komunikasi ringan,** seperti penjelasan atau pertanyaan bagaimana, cuba tanyakan pada Stack Overflow, IRC, Slack, atau saluran sembang lain, jika projek tersebut memiliki satu
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
+  Anda akan belajar <em> banyak </em> dari mengambil satu projek yang anda gunakan secara aktif, "menonton" di GitHub dan membaca setiap isu dan PR.
+<p markdown="1" class="pquote-credit">
+— @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
+  </p>
+</aside>
+
+### Membuka masalah
+
+Anda biasanya harus membuka masalah dalam situasi berikut:
+
+* Laporkan kesalahan yang tidak dapat anda atasi sendiri
+* Bincangkan topik atau idea peringkat tinggi (misalnya, komuniti, visi atau dasar)
+* Mencadangkan ciri baru atau idea projek lain
+
+Petua untuk berkomunikasi mengenai masalah:
+
+* **Jika anda melihat masalah terbuka yang ingin anda atasi,** beri komen mengenai masalah ini untuk memberi tahu orang bahawa anda sedang mengatasinya. Dengan cara itu, orang kurang menggandakan karya anda.
+* **Jika masalah dibuka beberapa saat yang lalu,** ada kemungkinan masalah itu ditangani di tempat lain, atau sudah diselesaikan, jadi beri komen untuk meminta pengesahan sebelum memulakan pekerjaan.
+* **Sekiranya anda membuka masalah, tetapi kemudian anda akan mengetahui sendiri jawapannya,** beri komen mengenai masalah ini untuk memberi tahu orang lain, kemudian tutup masalahnya. Malah mendokumentasikan hasil itu adalah sumbangan untuk projek tersebut.
+
+### Membuka permintaan tarik
+
+Anda biasanya harus membuka permintaan tarik dalam situasi berikut:
+
+* Kirimkan perbaikan sepele (contohnya, kesalahan ketik, pautan yang rosak atau ralat yang jelas)
+* Mulailah mengusahakan sumbangan yang telah diminta, atau yang telah anda bincangkan, dalam suatu isu
+
+Permintaan tarikan tidak harus mewakili kerja yang telah siap. Biasanya lebih baik membuka permintaan tarik lebih awal, sehingga orang lain dapat menonton atau memberikan maklum balas mengenai kemajuan anda. Cukup tandakan sebagai "WIP" (Work in Progress) di baris subjek. Anda boleh menambah lebih banyak komitmen kemudian.
+
+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/).)
+* **[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.
+* **Uji perubahan anda!** Jalankan perubahan anda terhadap ujian yang ada jika ada dan buat yang baru bila diperlukan. Sama ada ujian ada atau tidak, pastikan perubahan anda tidak mematahkan projek yang ada.
+* **Sumbang dalam gaya projek** dengan sebaik mungkin. Ini mungkin bermaksud menggunakan inden, titik koma atau komen yang berbeza daripada yang anda lakukan di repositori anda sendiri, tetapi memudahkan penyelenggara bergabung, yang lain memahami dan mengekalkannya di masa depan.
+
+Permintaan adalah permintaan permintaan pertama anda, periksa [Make a Pull Request](http://makeapullrequest.com/), yang @kentcdodds buat sebagai tutorial video panduan. Anda juga boleh berlatih membuat permintaan tarik di[First Contributions](https://github.com/Roshanjossey/first-contributions) repositori, dibuat oleh @Roshanjossey.
+
+## Apa yang berlaku selepas anda menghantar sumbangan
+
+Kamu lakukan! Selamat menjadi penyumbang sumber terbuka. Kami harap ini adalah yang pertama daripada banyak.
+
+Selepas anda menghantar sumbangan, salah satu perkara berikut akan berlaku:
+
+### 😭 Anda tidak mendapat sambutan.
+
+Semoga anda[checked the project for signs of activity](#a-checklist-before-you-contribute)sebelum memberi sumbangan. Walaupun pada projek yang aktif, kemungkinan sumbangan anda tidak mendapat sambutan.
+
+Sekiranya anda tidak mendapat sambutan selama lebih dari seminggu, adalah wajar untuk memberi respons dengan sopan dalam utas yang sama, meminta ulasan seseorang. Sekiranya anda mengetahui nama orang yang tepat untuk mengulas sumbangan anda, anda boleh @ -menyebutkannya dalam utas itu.
+
+** Jangan ** hubungi orang itu secara peribadi; ingat bahawa komunikasi awam sangat penting untuk projek sumber terbuka.
+
+Sekiranya anda membuat bongkahan yang sopan dan masih tidak ada yang bertindak balas, kemungkinan tidak ada yang akan bertindak balas. Ini bukan perasaan yang hebat, tetapi jangan biarkan itu mengecewakan anda. Ia berlaku kepada semua orang! Terdapat banyak kemungkinan sebab mengapa anda tidak mendapat sambutan, termasuk keadaan peribadi yang mungkin di luar kawalan anda. Cuba cari projek atau cara lain untuk menyumbang. Sekiranya ada, ini adalah alasan yang baik untuk tidak meluangkan terlalu banyak masa untuk membuat sumbangan sebelum anggota masyarakat lain terlibat dan responsif.
+
+### 🚧 Seseorang meminta perubahan pada sumbangan anda.
+
+Sudah biasa anda diminta membuat perubahan pada sumbangan anda, sama ada maklum balas mengenai skop idea anda, atau perubahan pada kod anda.
+
+Apabila seseorang meminta perubahan, bersikap responsif. Mereka telah meluangkan masa untuk menyemak sumbangan anda. Membuka PR dan berjalan jauh adalah bentuk yang buruk. Sekiranya anda tidak tahu bagaimana membuat perubahan, teliti masalahnya, kemudian minta bantuan jika anda memerlukannya.
+
+Sekiranya anda tidak mempunyai masa untuk menyelesaikan masalah ini lagi (contohnya, jika perbualan telah berlangsung selama berbulan-bulan, dan keadaan anda telah berubah), beritahu penyelenggara itu sehingga mereka tidak mengharapkan respons. Orang lain mungkin senang mengambil alih.
+
+### 👎 Sumbangan anda tidak diterima.
+
+Sumbangan anda mungkin atau tidak akan diterima pada akhirnya. Mudah-mudahan anda tidak terlalu banyak mengerjakannya. Sekiranya anda tidak pasti mengapa ia tidak diterima, adalah wajar untuk meminta maklum balas dan penjelasan penyelenggara. Namun, pada akhirnya, anda harus menghormati bahawa ini adalah keputusan mereka. Jangan membantah atau bermusuhan. Anda sentiasa dialu-alukan untuk menggunakan versi anda sendiri sekiranya anda tidak bersetuju!
+
+### contribution Sumbangan anda diterima.
+
+Hore! Anda berjaya memberikan sumbangan sumber terbuka!
+
+## Kamu lakukan!
+
+Sama ada anda baru sahaja memberikan sumbangan sumber terbuka anda, atau anda mencari cara baru untuk menyumbang, kami harap anda terinspirasi untuk mengambil tindakan. Walaupun sumbangan anda tidak diterima, jangan lupa mengucapkan terima kasih ketika penjaga menjaga usaha anda. Sumber terbuka dibuat oleh orang seperti anda: satu isu, permintaan tarik, komen, atau lima tinggi dalam satu masa.
\ No newline at end of file
diff --git a/_articles/ms/index.html b/_articles/ms/index.html
new file mode 100644
index 00000000000..d6658e07bad
--- /dev/null
+++ b/_articles/ms/index.html
@@ -0,0 +1,6 @@
+---
+layout: index
+title: Open Source Guides
+lang: ms
+permalink: /ms/
+---
diff --git a/_articles/ms/leadership-and-governance.md b/_articles/ms/leadership-and-governance.md
new file mode 100644
index 00000000000..ef136dabfa6
--- /dev/null
+++ b/_articles/ms/leadership-and-governance.md
@@ -0,0 +1,166 @@
+---
+lang: ms
+title: Kepimpinan dan Pemerintahan
+description: Projek sumber terbuka yang berkembang dapat memanfaatkan peraturan formal untuk membuat keputusan.
+class: leadership
+toc:
+  understanding-governance-for-your-growing-project: "Memahami tadbir urus untuk projek anda yang sedang berkembang"
+  what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?"
+  how-do-i-formalize-these-leadership-roles: "Bagaimana saya memformalkan peranan kepemimpinan ini?"
+  when-should-i-give-someone-commit-access: "Bilakah saya harus memberikan akses kepada seseorang?"
+  what-are-some-of-the-common-governance-structures-for-open-source-projects: "Apakah beberapa struktur pemerintahan biasa untuk projek sumber terbuka?"
+  do-i-need-governance-docs-when-i-launch-my-project: "Adakah saya memerlukan dokumen tadbir urus semasa melancarkan projek saya?"
+  what-happens-if-corporate-employees-start-submitting-contributions: "Apa yang berlaku sekiranya pekerja korporat mula menghantar sumbangan?"
+  do-i-need-a-legal-entity-to-support-my-project: "Adakah saya memerlukan entiti undang-undang untuk menyokong projek saya?"
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+  - best-practices
+  - metrics
+---
+
+## Memahami tadbir urus untuk projek anda yang sedang berkembang
+
+Projek anda berkembang, orang terlibat, dan anda komited untuk memastikan perkara ini berjalan. Pada tahap ini, anda mungkin tertanya-tanya bagaimana memasukkan penyumbang projek biasa ke dalam aliran kerja anda, sama ada memberi seseorang akses atau menyelesaikan perbahasan masyarakat. Sekiranya anda mempunyai soalan, kami mempunyai jawapan.
+
+## Apa contoh peranan formal yang digunakan dalam projek sumber terbuka?
+
+Banyak projek mengikuti struktur yang serupa untuk peranan dan pengiktirafan penyumbang.
+
+Walaupun begitu, maksud peranan ini sepenuhnya bergantung kepada anda. Berikut adalah beberapa jenis peranan yang mungkin anda kenali:
+
+* **Penyelenggara**
+* **Penyumbang**
+* **Komersial**
+
+**Untuk beberapa projek, "penyelenggara"** adalah satu-satunya orang dalam projek yang mempunyai akses komit. Dalam projek lain, mereka hanyalah orang yang disenaraikan dalam README sebagai penyelenggara.
+
+Penyelenggara tidak semestinya menjadi seseorang yang menulis kod untuk projek anda. Mungkin seseorang yang telah melakukan banyak pekerjaan menginjil projek anda, atau dokumentasi bertulis yang menjadikan projek ini lebih mudah diakses oleh orang lain. Terlepas dari apa yang mereka lakukan sehari-hari, penyelenggara mungkin adalah seseorang yang merasa bertanggungjawab atas arahan projek dan komited untuk memperbaikinya.
+
+**"Penyumbang" boleh jadi sesiapa sahaja** yang memberi komen mengenai sesuatu isu atau permintaan penarik, orang yang menambah nilai pada projek (sama ada ia mencetuskan masalah, menulis kod, atau menganjurkan acara), atau sesiapa sahaja dengan permintaan tarik gabungan (mungkin definisi penyumbang yang paling sempit).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  \[For Node.js,\] setiap orang yang muncul untuk memberi komen mengenai sesuatu masalah atau menghantar kod adalah anggota komuniti projek. Hanya dapat melihat mereka bermaksud bahawa mereka telah melewati batas dari menjadi pengguna hingga menjadi penyumbang.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+  </p>
+</aside>
+
+**Istilah "committer"** mungkin digunakan untuk membezakan akses komit, yang merupakan jenis tanggungjawab tertentu, dari bentuk sumbangan lain.
+
+Walaupun anda dapat menentukan peranan projek anda dengan cara yang anda mahukan, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) untuk mendorong lebih banyak bentuk sumbangan. Anda boleh menggunakan peranan kepemimpinan untuk mengenali secara rasmi orang yang telah memberikan sumbangan yang luar biasa untuk projek anda, tanpa mengira kemahiran teknikal mereka.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
+  Anda mungkin mengenali saya sebagai "penemu" Django ... tetapi sebenarnya saya adalah lelaki yang diupah untuk mengerjakan sesuatu setahun setelah ia dibuat. (...) Orang mengesyaki bahawa saya berjaya kerana kemahiran pengaturcaraan saya ... tetapi saya paling baik rata-rata pengaturcara.
+  <p markdown="1" class="pquote-credit">
+— @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+  </p>
+</aside>
+
+## Bagaimana saya memformalkan peranan kepemimpinan ini?
+
+Memformalkan peranan kepemimpinan anda membantu orang merasakan kepemilikan dan memberitahu ahli komuniti lain yang ingin meminta pertolongan.
+
+Untuk projek yang lebih kecil, menetapkan pemimpin boleh semudah menambahkan nama mereka ke nama anda dalam fail README atau fail CONTRIBUTORS.
+
+
+Untuk projek yang lebih besar, jika anda mempunyai laman web, buat halaman pasukan atau senaraikan pemimpin projek anda di sana. Sebagai contoh, [Postgres](https://github.com/postgres/postgres/) mempunyai [comprehensive team page](https://www.postgresql.org/community/contributors/) dengan profil pendek untuk setiap penyumbang.
+
+Sekiranya projek anda mempunyai komuniti penyumbang yang sangat aktif, anda mungkin membentuk "pasukan teras" penyelenggara, atau bahkan jawatankuasa kecil orang yang mengambil alih bidang isu yang berbeza (contohnya keselamatan, pencetus masalah, atau tingkah laku masyarakat). Biarkan orang mengatur diri sendiri dan menjadi sukarelawan untuk peranan yang paling mereka gemari, daripada menyerahkannya.
+
+<aside markdown="1" class="pquote">
+  \[We\] lengkapkan pasukan teras dengan beberapa "subteam". Setiap subtumpuan difokuskan pada bidang tertentu, misalnya, reka bentuk bahasa atau perpustakaan. (...) Untuk memastikan koordinasi global dan visi yang kuat dan koheren untuk projek secara keseluruhan, setiap subteam diketuai oleh anggota pasukan teras.
+  <p markdown="1" class="pquote-credit">
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+  </p>
+</aside>
+
+Pasukan kepemimpinan mungkin ingin membuat saluran yang ditentukan (seperti di IRC) atau bertemu secara berkala untuk membincangkan projek tersebut (seperti di Gitter atau Google Hangout). Anda juga boleh membuat perjumpaan itu umum sehingga orang lain dapat mendengar. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), sebagai contoh, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+
+Setelah anda menentukan peranan kepemimpinan, jangan lupa untuk mendokumentasikan bagaimana orang dapat mencapainya! Buat proses yang jelas bagaimana seseorang boleh menjadi penyelenggara atau bergabung dengan jawatankuasa kecil dalam projek anda, dan tuliskannya ke dalam GOVERNANCE.md. anda.
+
+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 [shared ownership](../building-community/#share-ownership-of-your-project).
+
+## Bilakah saya harus memberikan akses kepada seseorang?
+
+Sebilangan orang berpendapat bahawa anda harus memberikan akses kepada semua orang yang memberikan sumbangan. Melakukannya dapat mendorong lebih banyak orang merasakan pemilikan projek anda.
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
+  Setiap kali seseorang menghantar permintaan tarikan kepada anda, berikan mereka akses ke projek anda. Walaupun mungkin terdengar sangat bodoh pada mulanya, menggunakan strategi ini akan membolehkan anda melepaskan kekuatan sebenar GitHub. (...) Setelah orang membuat akses, mereka tidak lagi khawatir tambalan mereka tidak digabungkan ... menyebabkan mereka meletakkan lebih banyak pekerjaan ke dalamnya.
+  <p markdown="1" class="pquote-credit">
+— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+  </p>
+</aside>
+
+## Apa saja struktur pemerintahan biasa untuk projek sumber terbuka?
+
+Terdapat tiga struktur pemerintahan bersama yang berkaitan dengan projek sumber terbuka.
+
+* **BDFL:** BDFL bermaksud "Benevolent Dictator for Life". Di bawah struktur ini, satu orang (biasanya penulis awal projek) mempunyai pendapat akhir mengenai semua keputusan projek utama.[Python](https://github.com/python) adalah contoh klasik. Projek yang lebih kecil mungkin BDFL secara lalai, kerana hanya ada satu atau dua penyelenggara. Projek yang berasal dari syarikat mungkin juga termasuk dalam kategori BDFL.
+
+* **Meritokrasi:** **(Catatan: istilah "meritokrasi" membawa konotasi negatif bagi beberapa komuniti dan mempunyai [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Di bawah meritokrasi, penyumbang projek aktif (mereka yang menunjukkan "prestasi") diberi peranan membuat keputusan secara rasmi. Keputusan biasanya dibuat berdasarkan konsensus suara yang murni. Konsep meritokrasi dipelopori oleh [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list)adalah meritokrasi. Sumbangan hanya boleh dibuat oleh individu yang mewakili diri mereka sendiri, bukan oleh syarikat.
+
+* **Sumbangan liberal:** Di bawah model sumbangan liberal, orang yang melakukan kerja paling banyak diakui sebagai yang paling berpengaruh, tetapi ini berdasarkan karya semasa dan bukan sumbangan bersejarah. Keputusan projek utama dibuat berdasarkan proses mencari konsensus (membincangkan rungutan utama) dan bukannya suara murni, dan berusaha untuk memasukkan sebanyak mungkin perspektif masyarakat. Contoh popular projek yang menggunakan model sumbangan liberal termasuk [Node.js](https://foundation.nodejs.org/) dan [Rust](https://www.rust-lang.org/).
+
+Yang mana yang harus anda gunakan? Terpulang pada anda! Setiap model mempunyai kelebihan dan pertukaran. Dan walaupun pada awalnya mereka kelihatan agak berbeza, ketiga-tiga model mempunyai lebih banyak persamaan daripada yang kelihatan. Sekiranya anda berminat untuk menggunakan salah satu model ini, lihat templat ini:
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Adakah saya memerlukan dokumen tadbir urus semasa melancarkan projek saya?
+
+Tidak ada masa yang tepat untuk menuliskan urus tadbir projek anda, tetapi lebih mudah untuk ditentukan setelah anda melihat dinamika komuniti anda berjalan. Bahagian terbaik (dan paling sukar) mengenai pemerintahan sumber terbuka adalah ia dibentuk oleh masyarakat!
+
+Beberapa dokumentasi awal pasti akan menyumbang kepada tadbir urus projek anda, jadi mulailah menuliskan apa yang anda boleh. Sebagai contoh, anda dapat menentukan harapan yang jelas untuk tingkah laku, atau bagaimana proses penyumbang anda berfungsi, walaupun pada pelancaran projek anda.
+
+Sekiranya anda merupakan sebahagian daripada syarikat yang melancarkan projek sumber terbuka, ada baiknya anda mengadakan perbincangan dalaman sebelum melancarkan bagaimana syarikat anda mengharapkan untuk mengekalkan dan membuat keputusan mengenai projek tersebut ke hadapan. Anda juga mungkin ingin menerangkan secara terbuka sesuatu yang khusus mengenai bagaimana syarikat anda (atau tidak akan) terlibat dengan projek ini.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
+  Kami menugaskan pasukan kecil untuk menguruskan projek di GitHub yang sebenarnya mengusahakannya di Facebook. Contohnya, React dikendalikan oleh jurutera React.
+  <p markdown="1" class="pquote-credit">
+— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+  </p>
+</aside>
+
+## Apa yang berlaku sekiranya pekerja korporat mula menghantar sumbangan?
+
+Projek sumber terbuka yang berjaya digunakan oleh banyak orang dan syarikat, dan beberapa syarikat akhirnya mempunyai aliran pendapatan yang akhirnya terikat dengan projek tersebut. Sebagai contoh, syarikat boleh menggunakan kod projek sebagai salah satu komponen dalam penawaran perkhidmatan komersial.
+
+Oleh kerana projek ini semakin banyak digunakan, orang yang mempunyai kepakaran di dalamnya menjadi lebih banyak permintaan - anda mungkin salah satunya! - dan kadangkala akan dibayar untuk pekerjaan yang mereka lakukan dalam projek tersebut.
+
+Penting untuk memperlakukan aktiviti komersial seperti biasa dan sebagai sumber tenaga pembangunan yang lain. Pembangun berbayar tidak semestinya mendapat layanan istimewa berbanding yang belum dibayar, tentu saja; setiap sumbangan mesti dinilai berdasarkan kelebihan teknikalnya. Namun, orang harus merasa senang terlibat dalam kegiatan komersial, dan merasa selesa menyatakan kes penggunaannya ketika berdebat untuk memihak kepada peningkatan atau ciri tertentu.
+
+"Komersial" sepenuhnya serasi dengan "sumber terbuka". "Komersial" bermaksud ada wang yang terlibat di suatu tempat - perisian itu digunakan dalam perdagangan, yang semakin besar kemungkinan apabila projek mendapat penerapan. (Apabila perisian sumber terbuka digunakan sebagai bagian dari produk sumber bukan terbuka, produk keseluruhan masih merupakan perisian "proprietari", namun, seperti sumber terbuka, ia mungkin digunakan untuk tujuan komersial atau bukan komersial.)
+
+Seperti orang lain, pemaju yang bermotivasi komersial mendapat pengaruh dalam projek melalui kualiti dan kuantiti sumbangan mereka. Jelas sekali, pembangun yang dibayar untuk waktunya mungkin dapat melakukan lebih banyak daripada seseorang yang tidak dibayar, tetapi tidak mengapa: pembayaran adalah salah satu daripada banyak kemungkinan faktor yang boleh mempengaruhi berapa banyak yang dilakukan seseorang. Pastikan perbincangan projek anda tertumpu pada sumbangan, bukan pada faktor luaran yang membolehkan orang membuat sumbangan tersebut.
+
+## Adakah saya memerlukan entiti undang-undang untuk menyokong projek saya?
+
+Anda tidak memerlukan entiti undang-undang untuk menyokong projek sumber terbuka anda kecuali anda mengendalikan wang.
+
+Contohnya, jika anda ingin membuat perniagaan komersial, anda boleh menubuhkan C Corp atau LLC (jika anda berpusat di AS). Sekiranya anda hanya membuat kerja kontrak yang berkaitan dengan projek sumber terbuka anda, anda boleh menerima wang sebagai pemilik tunggal, atau menubuhkan LLC (jika anda berpusat di AS).
+
+Sekiranya anda ingin menerima sumbangan untuk projek sumber terbuka anda, anda boleh menyiapkan butang derma (misalnya menggunakan PayPal atau Stripe), tetapi wang tersebut tidak akan ditolak cukai melainkan anda bukan untung yang layak (501c3, jika anda berada di AS).
+
+Sebilangan besar projek tidak mahu mengalami masalah untuk menubuhkan organisasi bukan untung, jadi mereka mencari penaja fiskal bukan untung. Penaja fiskal menerima sumbangan bagi pihak anda, biasanya sebagai pertukaran untuk peratusan sumbangan. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) dan [Open Collective](https://opencollective.com/opensource)adalah contoh organisasi yang berfungsi sebagai penaja fiskal untuk projek sumber terbuka.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
+  Matlamat kami adalah untuk menyediakan infrastruktur yang dapat digunakan oleh masyarakat agar dapat bertahan hidup, sehingga mewujudkan persekitaran di mana setiap orang - penyumbang, penyokong, penaja - mendapat manfaat konkrit daripadanya.
+  <p markdown="1" class="pquote-credit">
+— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+  </p>
+</aside>
+
+Sekiranya projek anda berkait rapat dengan bahasa atau ekosistem tertentu, mungkin ada asas perisian berkaitan yang boleh anda bekerjasama. Sebagai contoh, [Python Software Foundation](https://www.python.org/psf/) menolong menyokong[PyPI](https://pypi.org/), pengurus pakej Python, dan [Node.js Foundation](https://foundation.nodejs.org/) menolong menyokong [Express.js](https://expressjs.com/), rangka kerja berasaskan Node.
diff --git a/_articles/ms/legal.md b/_articles/ms/legal.md
new file mode 100644
index 00000000000..d3e6e3f49ea
--- /dev/null
+++ b/_articles/ms/legal.md
@@ -0,0 +1,166 @@
+---
+lang: ms
+title: Bahagian Undang-Undang Sumber Terbuka
+description: Semua perkara yang pernah anda terfikir mengenai sisi undang-undang sumber terbuka, dan beberapa perkara yang tidak anda lakukan.
+class: legal
+toc:
+  why-do-people-care-so-much-about-the-legal-side-of-open-source: "Mengapa orang begitu mementingkan sisi undang-undang sumber terbuka?"
+  are-public-github-projects-open-source: "Adakah projek GitHub awam adalah sumber terbuka?"
+  just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Beri saya ringkasan mengenai perkara yang saya perlukan untuk melindungi projek saya"
+  which-open-source-license-is-appropriate-for-my-project: "Lesen sumber terbuka mana yang sesuai untuk projek saya?"
+  what-if-i-want-to-change-the-license-of-my-project: "Bagaimana jika saya mahu menukar lesen projek saya?"
+  does-my-project-need-an-additional-contributor-agreement: "Adakah projek saya memerlukan perjanjian penyumbang tambahan?"
+  what-does-my-companys-legal-team-need-to-know: "Apa yang perlu diketahui oleh pasukan undang-undang syarikat saya?"
+order: 10
+image: /assets/images/cards/legal.png
+related:
+  - contribute
+  - leadership
+---
+
+## Memahami implikasi undang-undang dari sumber terbuka
+
+Berkongsi karya kreatif anda dengan dunia boleh menjadi pengalaman yang menarik dan bermanfaat. Ini juga boleh bermaksud banyak perkara undang-undang yang anda tidak tahu yang anda perlu bimbangkan. Syukurlah, anda tidak perlu bermula dari awal. Kami telah memenuhi keperluan undang-undang anda. (Sebelum anda menggali, pastikan anda membaca [disclaimer](/notices/).)
+
+## Mengapa orang begitu mementingkan sisi undang-undang sumber terbuka?
+
+Gembira anda bertanya! Apabila anda membuat karya kreatif (seperti penulisan, grafik, atau kod), karya tersebut di bawah hak cipta eksklusif secara lalai. Artinya, undang-undang menganggap bahawa sebagai pengarang karya anda, anda mempunyai pendapat dalam apa yang dapat dilakukan oleh orang lain dengannya.
+
+Secara umum, itu bermakna tidak ada orang lain yang dapat menggunakan, menyalin, menyebarkan, atau mengubahsuai karya anda tanpa menghadapi risiko pengurangan, perombakan, atau proses pengadilan.
+
+Sumber terbuka adalah keadaan yang tidak biasa, bagaimanapun, kerana penulis mengharapkan orang lain akan menggunakan, mengubah, dan berkongsi karya. Tetapi kerana lalai undang-undang masih merupakan hak cipta eksklusif, anda memerlukan lesen yang menyatakan kebenaran ini secara jelas.
+
+Sekiranya anda tidak menggunakan lesen sumber terbuka, semua orang yang menyumbang untuk projek anda juga menjadi pemegang hak cipta eksklusif karya mereka. Ini bermaksud tiada siapa yang boleh menggunakan, menyalin, menyebarkan, atau mengubah sumbangan mereka - dan bahawa "tiada siapa" termasuk anda.
+
+Akhirnya, projek anda mungkin mempunyai kebergantungan dengan keperluan lesen yang tidak anda ketahui. Komuniti projek anda, atau polisi majikan anda, mungkin juga memerlukan projek anda menggunakan lesen sumber terbuka tertentu. Kami akan membahas situasi ini di bawah.
+
+## 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**.
+
+![Create repository](/assets/images/legal/repo-create-name.png)
+
+**Membuat projek GitHub anda umum tidak sama dengan melesenkan projek anda.** Projek awam dilindungi oleh [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), yang membolehkan orang lain melihat dan melengkapkan projek anda, tetapi pekerjaan anda sebaliknya tidak mempunyai kebenaran.
+
+Sekiranya anda ingin orang lain menggunakan, menyebarkan, mengubah suai, atau menyumbang kembali ke projek anda, anda perlu memasukkan lesen sumber terbuka. Sebagai contoh, seseorang tidak boleh menggunakan bahagian projek GitHub anda secara sah dalam kod mereka, walaupun secara terbuka, melainkan anda secara jelas memberi mereka hak untuk melakukannya.
+
+## Beri saya ringkasan mengenai perkara yang saya perlukan untuk melindungi projek saya.
+
+Anda bernasib baik, kerana hari ini, lesen sumber terbuka diseragamkan dan mudah digunakan. Anda boleh menyalin-menampal lesen yang ada terus ke projek anda.
+
+[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/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
+  Lesen standard berfungsi sebagai proksi bagi mereka yang tidak mempunyai latihan undang-undang untuk mengetahui dengan tepat apa yang mereka boleh dan tidak boleh lakukan dengan perisian. Sekiranya tidak diperlukan, elakkan syarat-syarat khusus, diubahsuai, atau tidak standard, yang akan menjadi penghalang penggunaan kod agensi di hilir.
+  <p markdown="1" class="pquote-credit">
+— @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+  </p>
+</aside>
+
+## Lesen sumber terbuka mana yang sesuai untuk projek saya?
+
+Sekiranya anda bermula dari papan tulis kosong, sukar untuk salah dengan[MIT License](https://choosealicense.com/licenses/mit/).Ringkas, sangat mudah difahami, dan membolehkan sesiapa sahaja melakukan apa sahaja selagi mereka menyimpan salinan lesen, termasuk notis hak cipta anda. Anda akan dapat melepaskan projek di bawah lesen lain jika anda memerlukannya.
+
+Jika tidak, memilih lesen sumber terbuka yang betul untuk projek anda bergantung pada objektif anda.
+
+Projek anda kemungkinan besar mempunyai (atau akan) **kebergantungan** (**dependencies**). Contohnya, jika anda membuka sumber projek Node.js, anda mungkin akan menggunakan perpustakaan dari Pengurus Pakej Node (npm). Setiap perpustakaan yang anda bergantung akan mempunyai lesen sumber terbuka sendiri. Sekiranya setiap lesen mereka "permisif" (memberikan izin kepada orang ramai untuk menggunakan, mengubah, dan berkongsi, tanpa syarat untuk pelesenan hilir), anda boleh menggunakan lesen yang anda mahukan. Lesen permisif biasa termasuk MIT, Apache 2.0, ISC, dan BSD.
+
+Sebaliknya, jika mana-mana lesen tanggungan anda adalah "copyleft yang kuat" (juga memberikan kebenaran yang sama kepada umum, tertakluk kepada syarat menggunakan lesen yang sama di hilir), maka projek anda harus menggunakan lesen yang sama. Lesen copyleft yang kuat termasuk GPLv2, GPLv3, dan AGPLv3.
+
+Anda mungkin juga ingin mempertimbangkan **komuniti** yang anda harap akan menggunakan dan menyumbang kepada projek anda:
+
+* **Adakah anda mahu projek anda digunakan sebagai pergantungan oleh projek lain?** Mungkin terbaik untuk menggunakan lesen yang paling popular di komuniti anda yang berkaitan. Sebagai contoh,[MIT](https://choosealicense.com/licenses/mit/) adalah lesen paling popular untuk [npm libraries](https://libraries.io/search?platforms=NPM).
+* **Adakah anda mahu projek anda menarik minat perniagaan besar?** Perniagaan besar kemungkinan akan memerlukan lesen paten ekspres dari semua penyumbang. Dalam kes ini, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)adakah anda (dan mereka) dilindungi.
+* **Adakah anda mahu projek anda menarik minat penyumbang yang tidak mahu sumbangan mereka digunakan dalam perisian sumber tertutup?**[GPLv3](https://choosealicense.com/licenses/gpl-3.0/) atau (jika mereka juga tidak mahu menyumbang kepada perkhidmatan sumber tertutup) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/)akan berjalan lancar.
+
+**Syarikat** anda mungkin mempunyai syarat pelesenan khusus untuk projek sumber terbuka. Sebagai contoh, ia mungkin memerlukan lesen yang boleh diterima agar syarikat dapat menggunakan projek anda dalam produk sumber tertutup syarikat. Atau syarikat anda mungkin memerlukan lesen copyleft yang kuat dan perjanjian penyumbang tambahan (lihat di bawah) sehingga hanya syarikat anda, dan tidak ada orang lain, yang dapat menggunakan projek anda dalam perisian sumber tertutup. Atau syarikat anda mungkin mempunyai keperluan tertentu yang berkaitan dengan standard, tanggungjawab sosial, atau ketelusan, yang mana mungkin memerlukan strategi pelesenan tertentu. Bercakap dengan anda[company's legal department](#what-does-my-companys-legal-team-need-to-know).
+
+Apabila anda membuat projek baru di GitHub, anda diberi pilihan untuk memilih lesen. Menyertakan salah satu lesen yang disebutkan di atas akan menjadikan projek GitHub anda sebagai sumber terbuka. Sekiranya anda ingin melihat pilihan lain, periksa [choosealicense.com](https://choosealicense.com) untuk mencari lesen yang sesuai untuk projek anda, walaupun ia [isn't software](https://choosealicense.com/non-software/).
+
+## Bagaimana jika saya ingin menukar lesen projek saya?
+
+Sebilangan besar projek tidak perlu menukar lesen. Tetapi kadang-kadang keadaan berubah.
+
+Sebagai contoh, semasa projek anda berkembang, ia menambahkan pergantungan atau pengguna, atau syarikat anda mengubah strategi, yang mana mungkin memerlukan atau menginginkan lesen yang berbeza. Juga, jika anda lalai untuk melesenkan projek anda sejak awal, menambahkan lesen sama seperti menukar lesen. Terdapat tiga perkara asas yang perlu dipertimbangkan semasa menambah atau menukar lesen projek anda:
+
+**Ini rumit.** Menentukan keserasian dan pematuhan lesen dan siapa yang memegang hak cipta boleh menjadi rumit dan membingungkan dengan cepat. Beralih ke lesen baru tetapi serasi untuk pelepasan dan sumbangan baru adalah berbeza daripada memberi semula semua sumbangan yang ada. Libatkan pasukan undang-undang anda pada petunjuk pertama keinginan untuk menukar lesen. Walaupun anda telah atau dapat memperoleh izin dari pemegang hak cipta projek anda untuk perubahan lesen, pertimbangkan kesan perubahan tersebut kepada pengguna dan penyumbang projek anda yang lain. Fikirkan perubahan lesen sebagai "acara tadbir urus" untuk projek anda yang kemungkinan besar akan berjalan lancar dengan komunikasi dan perundingan yang jelas dengan pihak berkepentingan projek anda. Semakin banyak alasan untuk memilih dan menggunakan lesen yang sesuai untuk projek anda sejak awal!
+
+**Lesen projek anda yang ada.** Sekiranya lesen yang ada pada projek anda sesuai dengan lesen yang ingin anda ubah, anda boleh mula menggunakan lesen baru. Ini kerana jika lesen A sesuai dengan lesen B, anda akan mematuhi syarat A sambil mematuhi syarat B (tetapi tidak semestinya sebaliknya). Oleh itu, jika anda sedang menggunakan lesen permisif (misalnya, MIT), anda boleh menukar kepada lesen dengan lebih banyak syarat, selagi anda menyimpan salinan lesen MIT dan sebarang notis hak cipta yang berkaitan (iaitu, terus mematuhi Syarat minimum lesen MIT). Tetapi jika lesen semasa anda tidak boleh diterima (mis., Copyleft, atau anda tidak mempunyai lesen) dan anda bukan satu-satunya pemegang hak cipta, anda tidak boleh menukar lesen projek anda kepada MIT. Pada hakikatnya, dengan lesen permis, pemegang hak cipta projek telah memberikan kebenaran terlebih dahulu untuk menukar lesen.
+
+**Pemegang hak cipta projek anda yang ada.** Sekiranya anda satu-satunya penyumbang projek anda, maka anda atau syarikat anda adalah pemegang hak cipta tunggal projek tersebut. Anda boleh menambah atau menukar apa sahaja lesen yang anda atau syarikat anda mahukan. Jika tidak, mungkin ada pemegang hak cipta lain yang anda perlukan persetujuannya untuk menukar lesen. Siapakah mereka? Orang yang mempunyai komitmen dalam projek anda adalah tempat yang baik untuk memulakan. Tetapi dalam beberapa kes hak cipta akan dipegang oleh majikan mereka. Dalam beberapa kes, orang hanya akan memberikan sumbangan minimum, tetapi tidak ada peraturan yang keras dan cepat bahawa sumbangan di bawah sebilangan baris kod tidak dikenakan hak cipta. Apa nak buat? Itu bergantung. Untuk projek yang agak kecil dan muda, mungkin memungkinkan semua penyumbang yang ada untuk menyetujui perubahan lesen dalam isu atau permintaan penarikan. Untuk projek besar dan lama, anda mungkin perlu mencari banyak penyumbang dan juga waris mereka. Mozilla mengambil masa bertahun-tahun (2001-2006) untuk mendapatkan semula Firefox, Thunderbird, dan perisian yang berkaitan.
+
+Sebagai alternatif, anda boleh meminta penyumbang bersetuju terlebih dahulu (melalui perjanjian penyumbang tambahan - lihat di bawah) terhadap perubahan lesen tertentu dalam keadaan tertentu, melebihi yang dibenarkan oleh lesen sumber terbuka anda yang ada. Ini sedikit sebanyak mengubah kerumitan menukar lesen. Anda memerlukan lebih banyak pertolongan daripada peguam anda di muka, dan anda masih mahu berkomunikasi dengan jelas dengan pihak berkepentingan projek anda semasa melaksanakan pertukaran lesen.
+
+## 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).
+
+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.
+
+Juga, dengan menambahkan "kertas kerja" yang diyakini oleh beberapa orang tidak perlu, sukar difahami, atau tidak adil (apabila penerima perjanjian mendapat lebih banyak hak daripada penyumbang atau orang ramai melalui lesen sumber terbuka projek), perjanjian penyumbang tambahan mungkin dianggap tidak ramah kepada komuniti projek.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
+   Kami telah menghilangkan CLA untuk Node.js. Melakukan ini mengurangkan halangan kemasukan penyumbang Node.js sehingga memperluas pangkalan penyumbang.
+  <p markdown="1" class="pquote-credit">
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+  </p>
+</aside>
+
+Beberapa situasi di mana anda mungkin ingin mempertimbangkan perjanjian penyumbang tambahan untuk projek anda termasuk:
+
+* Peguam anda mahu semua penyumbang menerima secara jelas syarat-syarat sumbangan (_sign_, online atau offline), mungkin kerana mereka merasakan lesen sumber terbuka itu sendiri tidak mencukupi (walaupun sudah!). Sekiranya ini satu-satunya masalah, perjanjian penyumbang yang mengesahkan lesen sumber terbuka projek harus mencukupi. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) adalah contoh yang baik dari perjanjian penyumbang tambahan ringan.
+* Anda atau peguam anda mahu pembangun menyatakan bahawa setiap komitmen yang mereka buat diberi kuasa. [Developer Certificate of Origin](https://developercertificate.org/) keperluannya adalah berapa banyak projek yang mencapainya. Contohnya, komuniti Node.js [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) CLA mereka yang terdahulu. Pilihan mudah untuk mengotomatisasi pelaksanaan DCO di repositori anda adalah [DCO Probot](https://github.com/probot/dco).
+* Projek anda menggunakan lesen sumber terbuka yang tidak termasuk pemberian paten ekspres (seperti MIT), dan anda memerlukan pemberian paten dari semua penyumbang, beberapa di antaranya mungkin bekerja untuk syarikat yang mempunyai portfolio paten besar yang dapat digunakan untuk menargetkan anda atau penyumbang dan pengguna projek yang lain. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) adalah perjanjian penyumbang tambahan yang biasa digunakan yang mempunyai pemberian hak paten seperti yang terdapat dalam Apache License 2.0.
+* Projek anda di bawah lesen copyleft, tetapi anda juga perlu mengedarkan versi proprietari projek tersebut. Anda memerlukan setiap penyumbang untuk memberikan hak cipta kepada anda atau memberi anda (tetapi bukan orang ramai) lesen yang mengizinkan. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) adalah contoh jenis perjanjian ini.
+* Anda fikir projek anda mungkin perlu menukar lesen sepanjang hayatnya dan mahu penyumbang bersetuju terlebih dahulu untuk perubahan tersebut.
+
+Sekiranya anda perlu menggunakan perjanjian penyumbang tambahan dengan projek anda, pertimbangkan untuk menggunakan integrasi seperti [CLA assistant](https://github.com/cla-assistant/cla-assistant) untuk mengurangkan gangguan penyumbang.
+
+## Apa yang perlu diketahui oleh pasukan undang-undang syarikat saya?
+
+Sekiranya anda melancarkan projek sumber terbuka sebagai pekerja syarikat, pertama, pasukan undang-undang anda harus mengetahui bahawa anda membuka projek secara terbuka.
+
+Untuk lebih baik atau lebih buruk, pertimbangkan untuk memberitahu mereka walaupun itu adalah projek peribadi. Anda mungkin mempunyai "perjanjian IP pekerja" dengan syarikat anda yang memberi mereka beberapa kawalan terhadap projek anda, terutamanya jika semuanya berkaitan dengan perniagaan syarikat atau anda menggunakan sumber syarikat untuk mengembangkan projek tersebut. Syarikat anda boleh memberi anda kebenaran, dan mungkin telah melalui perjanjian IP mesra pekerja atau polisi syarikat. Sekiranya tidak, anda boleh berunding (misalnya, jelaskan bahawa projek anda memenuhi objektif pembelajaran dan pembangunan profesional syarikat untuk anda), atau elakkan mengusahakan projek anda sehingga anda menemui syarikat yang lebih baik.
+
+**Sekiranya anda membuka projek untuk syarikat anda,** maka jelaskan kepada mereka. Pasukan undang-undang anda mungkin sudah mempunyai polisi untuk apa lesen sumber terbuka (dan mungkin perjanjian penyumbang tambahan) untuk digunakan berdasarkan keperluan dan kepakaran perniagaan syarikat untuk memastikan projek anda mematuhi lesen tanggungannya. Sekiranya tidak, anda dan mereka bernasib baik! Pasukan undang-undang anda harus bersemangat untuk bekerjasama dengan anda untuk mengetahui perkara ini. Beberapa perkara yang perlu difikirkan:
+
+* **Bahan pihak ketiga:** Adakah projek anda mempunyai kebergantungan yang dibuat oleh orang lain atau termasuk atau menggunakan kod orang lain? Sekiranya ini adalah sumber terbuka, anda perlu mematuhi lesen sumber terbuka bahan tersebut. Itu bermula dengan memilih lesen yang sesuai dengan lesen sumber terbuka pihak ketiga (lihat di atas). Sekiranya projek anda mengubah atau menyebarkan bahan sumber terbuka pihak ketiga, pasukan undang-undang anda juga ingin mengetahui bahawa anda memenuhi syarat lain dari lesen sumber terbuka pihak ketiga seperti mengekalkan notis hak cipta. Sekiranya projek anda menggunakan kod orang lain yang tidak mempunyai lesen sumber terbuka, anda mungkin perlu meminta penyelenggara pihak ketiga [add an open source license](https://choosealicense.com/no-license/#for-users), dan jika anda tidak dapat memperolehnya, hentikan penggunaan kod mereka dalam projek anda.
+
+* **Rahsia perdagangan:** Pertimbangkan sama ada terdapat apa-apa dalam projek yang syarikat itu tidak mahu sediakan untuk orang awam. Sekiranya demikian, anda boleh membuka sumber keseluruhan projek anda, setelah mengekstrak bahan yang ingin anda rahsiakan.
+
+* **Paten:** Adakah syarikat anda memohon paten yang merupakan sumber terbuka projek anda [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Malangnya, anda mungkin diminta untuk menunggu (atau mungkin syarikat akan mempertimbangkan semula kebijaksanaan permohonan). Sekiranya anda mengharapkan sumbangan untuk projek anda dari pekerja syarikat dengan portfolio paten yang besar, pasukan undang-undang anda mungkin mahu anda menggunakan lesen dengan pemberian paten ekspres dari penyumbang (seperti Apache 2.0 atau GPLv3), atau perjanjian penyumbang tambahan ( lihat di atas).
+
+* **Tanda Dagangan:** Periksa semula nama projek anda[does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). Sekiranya anda menggunakan tanda dagangan syarikat anda sendiri dalam projek, periksa bahawa ia tidak menimbulkan konflik. [FOSSmarks](http://fossmarks.org/)adalah panduan praktikal untuk memahami tanda dagangan dalam konteks projek sumber bebas dan terbuka.
+
+* **Privasi:** Adakah projek anda mengumpulkan data pengguna? "Telefon rumah" ke pelayan syarikat? Pasukan undang-undang anda dapat membantu anda mematuhi dasar syarikat dan peraturan luaran.
+
+Sekiranya anda melepaskan projek sumber terbuka pertama syarikat anda, perkara di atas lebih dari cukup untuk diselesaikan (tetapi jangan bimbang, kebanyakan projek seharusnya tidak menimbulkan kebimbangan besar).
+
+Jangka panjang, pasukan undang-undang anda boleh melakukan lebih banyak perkara untuk membantu syarikat mendapatkan lebih banyak hasil daripada penglibatannya dalam sumber terbuka, dan tetap selamat:
+
+* **Dasar sumbangan pekerja:** Pertimbangkan untuk mengembangkan polisi korporat yang menentukan bagaimana pekerja anda menyumbang untuk projek sumber terbuka. Dasar yang jelas akan mengurangkan kekeliruan di kalangan pekerja anda dan membantu mereka menyumbang kepada projek sumber terbuka demi kepentingan syarikat, sama ada sebagai sebahagian daripada pekerjaan mereka atau pada masa lapang. Contoh yang baik ialah Rackspace [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
+  Membiarkan IP yang berkaitan dengan patch membina asas pengetahuan dan reputasi pekerja. Ini menunjukkan bahawa syarikat dilaburkan dalam pengembangan pekerja tersebut dan mewujudkan rasa pemberdayaan dan autonomi. Semua faedah ini juga membawa kepada semangat kerja yang lebih tinggi dan pengekalan pekerja yang lebih baik.
+  <p markdown="1" class="pquote-credit">
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+  </p>
+</aside>
+
+* **Apa yang hendak dilepaskan:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Sekiranya pasukan undang-undang anda memahami dan dilaburkan dalam strategi sumber terbuka syarikat anda, mereka akan dapat membantu dan bukannya menghalang usaha anda.
+* **Pematuhan:** Walaupun syarikat anda tidak mengeluarkan projek sumber terbuka, ia menggunakan perisian sumber terbuka orang lain. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) dapat mencegah sakit kepala, kelewatan produk, dan tuntutan mahkamah.
+
+<aside markdown="1" class="pquote">
+  Organisasi mesti mempunyai strategi lesen dan pematuhan yang sesuai dengan kedua kategori [["permisive" dan "copyleft" \]. Ini bermula dengan mencatat syarat-syarat pelesenan yang berlaku untuk perisian sumber terbuka yang Anda gunakan - termasuk subkomponen dan dependensi.
+  <p markdown="1" class="pquote-credit">
+— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+  </p>
+</aside>
+
+* **Paten:** Syarikat anda mungkin ingin bergabung dengan[Open Invention Network](https://www.openinventionnetwork.com/), kumpulan paten pertahanan bersama untuk melindungi penggunaan projek sumber terbuka utama anggota, atau meneroka yang lain[alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
+* **Tadbir urus:** Terutama jika dan bila masuk akal untuk memindahkan projek ke [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
diff --git a/_articles/ms/metrics.md b/_articles/ms/metrics.md
new file mode 100644
index 00000000000..dbd4a354d58
--- /dev/null
+++ b/_articles/ms/metrics.md
@@ -0,0 +1,134 @@
+---
+lang: ms
+title: Metrik Sumber Terbuka
+description: Buat keputusan yang tepat untuk membantu projek sumber terbuka anda berkembang dengan mengukur dan mengesan kejayaannya.
+class: metrics
+toc:
+  why-measure-anything: "Mengapa mengukur apa-apa?"
+  discovery: "Penemuan"
+  usage: "Penggunaan"
+  retention: "Pengekalan"
+  maintainer-activity: "Aktiviti penyelenggara"
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+  - finding
+  - best-practices
+---
+
+## Mengapa mengukur apa-apa?
+
+Data, jika digunakan dengan bijak, dapat membantu anda membuat keputusan yang lebih baik sebagai penyelenggara sumber terbuka.
+
+Dengan lebih banyak maklumat, anda boleh:
+
+* Fahami bagaimana pengguna bertindak balas terhadap ciri baru
+* Cari tahu dari mana pengguna baru berasal
+* Kenali, dan tentukan apakah akan mendukung, kes penggunaan atau fungsi luar
+* Hitung populariti projek anda
+* Fahami bagaimana projek anda digunakan
+* Kumpulkan wang melalui tajaan dan geran
+
+Contohnya, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) mendapati bahawa Analitis Google membantu mereka mengutamakan kerja:
+
+>Homebrew disediakan secara percuma dan dikendalikan sepenuhnya oleh sukarelawan pada masa lapang. Hasilnya, kami tidak mempunyai sumber untuk membuat kajian pengguna terperinci mengenai pengguna Homebrew untuk memutuskan cara terbaik untuk merancang ciri masa depan dan mengutamakan kerja semasa. Analisis pengguna agregat tanpa nama membolehkan kami mengutamakan pembaikan dan ciri berdasarkan bagaimana, di mana dan kapan orang menggunakan Homebrew.
+
+Populariti bukan segalanya. Semua orang masuk ke sumber terbuka dengan alasan yang berbeza. Sekiranya matlamat anda sebagai penyelenggara sumber terbuka adalah untuk mempamerkan karya anda, bersikap telus mengenai kod anda, atau hanya bersenang-senang, metrik mungkin tidak penting bagi anda.
+
+Sekiranya anda berminat untuk memahami projek anda pada tahap yang lebih mendalam, baca cara untuk menganalisis aktiviti projek anda.
+
+## Penemuan
+
+Sebelum ada yang dapat menggunakan atau menyumbang kembali ke projek anda, mereka perlu mengetahui bahawa ia wujud. Tanya pada diri anda: _apa orang mencari projek ini? _
+
+![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:
+
+* **Jumlah paparan halaman:** Memberitahu anda berapa kali projek anda dilihat
+
+* **Jumlah pelawat unik:** Memberitahu anda berapa orang yang melihat projek anda
+
+* **Merujuk laman web:** Memberitahu anda dari mana pengunjung datang. Metrik ini dapat membantu anda mengetahui di mana untuk menjangkau khalayak anda dan adakah usaha promosi anda berjalan lancar.
+
+* **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.
+
+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.
+
+## Penggunaan
+
+Orang ramai mencari projek anda mengenai perkara liar dan gila yang kami panggil internet ini. Sebaik-baiknya, apabila mereka melihat projek anda, mereka akan merasa terdorong untuk melakukan sesuatu. Soalan kedua yang ingin anda ajukan ialah: _apa orang menggunakan projek ini?_
+
+Sekiranya anda menggunakan pengurus pakej, seperti npm atau RubyGems.org, untuk mengedarkan projek anda, anda mungkin dapat mengesan muat turun projek anda.
+
+Setiap pengurus pakej boleh menggunakan definisi "download" yang sedikit berbeza, dan muat turuntuk mengesan statistik penggunaan di banyak pengurus pakej yang popular.
+
+Sekiranya projek anda berada di GitHub, arahkan kembali ke halaman "Traffic". Anda boleh menggunakanun tidak semestinya berkaitan dengan pemasangan atau penggunaan, tetapi menyediakan beberapa asas untuk perbandingan. Cuba gunakan [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+
+If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+
+![Clone graph](/assets/images/metrics/clone_graph.png)
+
+Sekiranya penggunaannya rendah berbanding dengan jumlah orang yang menemui projek anda, ada dua masalah yang perlu dipertimbangkan. Sama ada:
+
+* Projek anda tidak berjaya menukar khalayak anda, atau
+* Anda menarik penonton yang salah
+
+Sebagai contoh, jika projek anda muncul di halaman depan Berita Peretas, anda mungkin akan melihat lonjakan penemuan (lalu lintas), tetapi kadar penukaran yang lebih rendah, kerana anda menjangkau semua orang di Berita Peretas. Sekiranya projek Ruby anda diketengahkan pada persidangan Ruby, anda mungkin akan melihat kadar penukaran yang tinggi dari khalayak yang disasarkan.
+
+Cuba cari tahu dari mana datangnya khalayak anda dan minta maklum balas orang lain di halaman projek anda untuk mengetahui dua masalah yang mana yang anda hadapi.
+
+Setelah anda mengetahui bahawa orang menggunakan projek anda, anda mungkin ingin mencuba untuk mengetahui apa yang mereka lakukan dengannya. Adakah mereka membangunnya dengan memalsukan kod anda dan menambahkan ciri? Adakah mereka menggunakannya untuk sains atau perniagaan?
+
+## Pengekalan
+
+Orang mencari projek anda dan mereka menggunakannya. Soalan seterusnya yang ingin anda tanyakan kepada diri sendiri ialah: Adakah orang yang menyumbang kembali ke projek ini? _
+
+Tidak terlalu awal untuk mula memikirkan penyumbang. Tanpa orang lain masuk, anda berisiko meletakkan diri anda dalam keadaan tidak sihat di mana projek anda _popular_ (banyak orang menggunakannya) tetapi tidak _support_ (tidak cukup masa penyelenggara untuk memenuhi permintaan).
+
+Pengekalan juga memerlukan [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2),kerana penyumbang aktif sebelum ini akhirnya akan beralih kepada perkara lain.
+
+Contoh metrik komuniti yang mungkin ingin anda lacak secara berkala termasuk:
+
+* **Jumlah penyumbang dan jumlah komitmen setiap penyumbang:** Memberitahu anda berapa banyak penyumbang yang anda miliki, dan siapa yang kurang lebih aktif. Di GitHub, anda dapat melihatnya di bawah "Wawasan" -> "Penyumbang." Buat masa ini, grafik ini hanya mengira penyumbang yang telah berkomitmen untuk cabang lalai repositori.
+
+![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+
+* **Penyumbang kali pertama, santai, dan berulang:** Membantu anda mengesan sama ada anda mendapat penyumbang baru dan sama ada mereka kembali. (Penyumbang kasual adalah penyumbang dengan jumlah komitmen yang rendah. Sama ada satu komitmen, kurang daripada lima komitmen, atau yang lain terpulang kepada anda.) Tanpa penyumbang baru, komuniti projek anda boleh menjadi stagnan.
+
+* **Bilangan masalah terbuka dan permintaan tarik terbuka:** Jika jumlah ini terlalu tinggi, anda mungkin memerlukan bantuan untuk mencetuskan masalah dan mengkaji kod.
+
+* **Jumlah masalah _opened_ dan permintaan tarik _opened_:** Masalah yang dibuka bermaksud seseorang cukup mengambil berat tentang projek anda untuk membuka masalah. Sekiranya jumlah itu bertambah dari masa ke masa, ini menunjukkan orang berminat dengan projek anda.
+
+* **Jenis sumbangan:** Contohnya, melakukan, memperbaiki kesalahan ketik atau pepijat, atau memberi komen mengenai sesuatu masalah.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
+  Sumber terbuka lebih daripada sekadar kod. Projek sumber terbuka yang berjaya merangkumi sumbangan kod dan dokumentasi bersama perbualan mengenai perubahan ini.
+  <p markdown="1" class="pquote-credit">
+— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+  </p>
+</aside>
+
+## Aktiviti penyelenggara
+
+Akhirnya, anda ingin menutup gelung dengan memastikan penyelenggara projek anda dapat menangani jumlah sumbangan yang diterima. Soalan terakhir yang ingin anda tanyakan kepada diri anda ialah: _am Saya (atau adakah kita) menjawab komuniti kita?_
+
+Penyelenggara yang tidak responsif menjadi hambatan bagi projek sumber terbuka. Sekiranya seseorang mengemukakan sumbangan tetapi tidak pernah mendapat balasan daripada penjaga, mereka mungkin akan merasa putus asa dan pergi.
+
+[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) menunjukkan bahawa tindak balas pemelihara adalah faktor penting dalam mendorong sumbangan berulang.
+
+Pertimbangkan untuk mengesan berapa lama anda (atau penyelenggara lain) bertindak balas terhadap sumbangan, sama ada masalah atau permintaan penarik. Menjawab tidak memerlukan tindakan. Ini semudah mengatakan: _"Terima kasih atas penyerahan anda! Saya akan mengulasnya dalam minggu depan."_
+
+Anda juga dapat mengukur masa yang diperlukan untuk beralih antara tahap dalam proses sumbangan, seperti:
+
+* Rata-rata masa masalah masih terbuka
+* Sama ada isu ditutup oleh PR
+* Sama ada masalah basi ditutup
+* Waktu purata untuk menggabungkan permintaan tarik
+
+## Gunakan 📊 untuk mengetahui tentang orang
+
+Memahami metrik akan membantu anda membina projek sumber terbuka yang aktif dan berkembang. Walaupun anda tidak melacak setiap metrik di papan pemuka, gunakan kerangka di atas untuk memusatkan perhatian anda pada jenis tingkah laku yang akan membantu projek anda berkembang maju.
\ No newline at end of file
diff --git a/_articles/ms/starting-a-project.md b/_articles/ms/starting-a-project.md
new file mode 100644
index 00000000000..2f050162708
--- /dev/null
+++ b/_articles/ms/starting-a-project.md
@@ -0,0 +1,362 @@
+---
+lang: ms
+title: Memulakan Projek Sumber Terbuka
+description: Ketahui lebih lanjut mengenai dunia sumber terbuka dan bersiap sedia untuk melancarkan projek anda sendiri.
+class: beginners
+toc:
+  the-what-and-why-of-open-source: "Apa dan mengapa sumber terbuka"
+  should-i-launch-my-own-open-source-project: "Sekiranya saya melancarkan projek sumber terbuka saya sendiri?"
+  launching-your-own-open-source-project: "Melancarkan projek sumber terbuka anda sendiri"
+  naming-and-branding-your-project: "Menamakan dan menjenamakan projek anda"
+  your-pre-launch-checklist: "Senarai semak pra-pelancaran anda"
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+  - finding
+  - building
+---
+
+## "apa" dan "mengapa" sumber terbuka
+
+Oleh itu, anda berfikir untuk memulakan dengan sumber terbuka? Tahniah! Dunia menghargai sumbangan anda. Mari kita bincangkan apa itu sumber terbuka dan mengapa orang melakukannya.
+
+### Apa maksud "sumber terbuka"?
+
+Apabila projek adalah sumber terbuka, itu bermaksud **siapa sahaja bebas menggunakan, mengkaji, mengubah dan menyebarkan projek anda untuk tujuan apa pun.** Kebenaran ini diberlakukan melalui[an open source license](https://opensource.org/licenses).
+
+Sumber terbuka sangat kuat kerana ia dapat mengurangkan halangan untuk menerima pakai dan berkolaborasi, memungkinkan orang menyebarkan dan memperbaiki projek dengan cepat. Juga kerana memberi pengguna potensi untuk mengendalikan pengkomputeran mereka sendiri, berbanding dengan sumber tertutup. Sebagai contoh, perniagaan yang menggunakan perisian sumber terbuka mempunyai pilihan untuk mengupah seseorang untuk membuat penambahbaikan khusus pada perisian, daripada hanya bergantung pada keputusan produk penjual sumber tertutup.
+
+_Perisian percuma_ merujuk kepada set projek yang sama dengan _open source_. Kadang-kadang anda juga akan melihat[these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) digabungkan sebagai "perisian sumber bebas dan terbuka" (FOSS) atau "perisian bebas, bebas, dan sumber terbuka" (FLOSS). _Free_ dan _libre_ merujuk kepada kebebasan,[not price](#does-open-source-mean-free-of-charge).
+
+### Mengapa orang membuka sumber pekerjaan mereka?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+  Salah satu pengalaman paling bermanfaat yang saya dapat daripada menggunakan dan berkolaborasi pada sumber terbuka berasal dari hubungan yang saya bina dengan pembangun lain yang menghadapi banyak masalah yang sama dengan saya.
+  <p markdown="1" class="pquote-credit">
+— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+  </p>
+</aside>
+
+[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) mengapa seseorang atau organisasi ingin membuka sumber projek. Beberapa contoh merangkumi:
+
+* **Kerjasama:** Projek sumber terbuka dapat menerima perubahan dari sesiapa sahaja di dunia. [Exercism](https://github.com/exercism/), sebagai contoh, adalah platform latihan pengaturcaraan dengan lebih daripada 350 penyumbang.
+
+* **Adopsi dan pencampuran semula:** Projek sumber terbuka dapat digunakan oleh siapa saja untuk hampir semua tujuan. Orang bahkan boleh menggunakannya untuk membina perkara lain.[WordPress](https://github.com/WordPress),sebagai contoh, dimulakan sebagai garpu projek sedia ada yang dipanggil [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Ketelusan:** Sesiapa sahaja dapat memeriksa projek sumber terbuka untuk kesilapan atau ketidakkonsistenan. Perkara ketelusan kepada kerajaan seperti [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/),industri terkawal seperti perbankan atau penjagaan kesihatan, dan perisian keselamatan seperti [Let's Encrypt](https://github.com/letsencrypt).
+
+Sumber terbuka bukan hanya untuk perisian. Anda boleh membuka sumber semuanya dari set data hingga buku. Lihatlah[GitHub Explore](https://github.com/explore)untuk idea mengenai apa lagi yang boleh anda buka sumber.
+
+### Adakah sumber terbuka bermaksud "percuma"?
+
+Salah satu tarikan terbesar sumber terbuka adalah bahawa ia tidak memerlukan wang. "Percuma", bagaimanapun, adalah hasil sampingan dari nilai keseluruhan sumber terbuka.
+
+Kerana [an open source license requires](https://opensource.org/osd-annotated)bahawa sesiapa sahaja boleh menggunakan, mengubah suai, dan berkongsi projek anda untuk hampir semua tujuan, projek itu sendiri cenderung percuma. Sekiranya projek itu memerlukan wang untuk digunakan, sesiapa sahaja boleh membuat salinan secara sah dan menggunakan versi percuma sebagai gantinya.
+
+Akibatnya, kebanyakan projek sumber terbuka adalah percuma, tetapi "percuma" bukan sebahagian daripada definisi sumber terbuka. Terdapat cara untuk mengenakan bayaran untuk projek sumber terbuka secara tidak langsung melalui pelesenan ganda atau ciri terhad, sementara masih mematuhi definisi rasmi sumber terbuka.
+
+## Perlukah saya melancarkan projek sumber terbuka saya sendiri?
+
+Jawapan ringkasnya adalah ya, kerana tidak kira hasilnya, melancarkan projek anda sendiri adalah cara terbaik untuk mengetahui bagaimana sumber terbuka berfungsi.
+
+Sekiranya anda tidak pernah membuka projek bersumber sebelumnya, anda mungkin merasa gementar dengan apa yang orang akan katakan, atau adakah orang akan melihatnya sama sekali. Sekiranya ini terdengar seperti anda, anda tidak bersendirian!
+
+Karya sumber terbuka adalah seperti aktiviti kreatif lain, sama ada penulisan atau lukisan. Rasanya menakutkan untuk berkongsi karya anda dengan dunia, tetapi satu-satunya cara untuk menjadi lebih baik adalah berlatih - walaupun anda tidak mempunyai penonton.
+
+Sekiranya anda belum yakin, luangkan masa untuk memikirkan apakah matlamat anda.
+
+### Menetapkan matlamat anda
+
+Matlamat dapat membantu anda mengetahui apa yang harus diusahakan, apa yang harus dikatakan tidak, dan di mana anda memerlukan bantuan daripada orang lain. Mulakan dengan bertanya pada diri sendiri, _mengapa saya membuka sumber projek ini?_
+
+Tidak ada satu jawapan yang tepat untuk soalan ini. Anda mungkin mempunyai banyak tujuan untuk satu projek, atau projek yang berbeza dengan tujuan yang berbeza.
+
+Sekiranya satu-satunya tujuan anda adalah untuk mempamerkan hasil kerja anda, anda mungkin tidak mahukan sumbangan, dan bahkan mengatakannya dalam README anda. Sebaliknya, jika anda mahukan penyumbang, anda akan meluangkan masa untuk membuat dokumentasi yang jelas dan membuat pendatang baru merasa diterima.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+  Pada satu ketika saya membuat UIAlertView khusus yang saya gunakan ... dan saya memutuskan untuk menjadikannya sumber terbuka. Oleh itu, saya mengubahnya menjadi lebih dinamik dan memuat naiknya ke GitHub. Saya juga menulis dokumentasi pertama saya yang menerangkan kepada pemaju lain bagaimana menggunakannya pada projek mereka. Mungkin tidak ada yang menggunakannya kerana ini adalah projek yang mudah tetapi saya berasa gembira dengan sumbangan saya.
+  <p markdown="1" class="pquote-credit">
+— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+  </p>
+</aside>
+
+Semasa projek anda berkembang, komuniti anda mungkin memerlukan lebih daripada sekadar kod dari anda. Menanggapi masalah, mengkaji kod, dan menginjil projek anda adalah semua tugas penting dalam projek sumber terbuka.
+
+Walaupun jumlah masa yang anda habiskan untuk tugas bukan pengekodan bergantung pada ukuran dan ruang lingkup projek anda, anda harus bersedia sebagai penyelenggara untuk mengatasinya sendiri atau mencari seseorang untuk membantu anda.
+
+**Sekiranya anda merupakan sebahagian daripada syarikat yang memperoleh projek terbuka,** pastikan projek anda mempunyai sumber dalaman yang diperlukan untuk berkembang maju. Anda ingin mengenal pasti siapa yang bertanggungjawab untuk mengekalkan projek tersebut selepas pelancaran, dan bagaimana anda akan berkongsi tugas tersebut dengan komuniti anda.
+
+Sekiranya anda memerlukan anggaran atau kakitangan khusus untuk promosi, operasi dan penyelenggaraan projek, mulailah perbincangan tersebut lebih awal.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+  Semasa anda mula membuka sumber projek, penting untuk memastikan bahawa proses pengurusan anda mengambil kira sumbangan dan kemampuan masyarakat di sekitar projek anda. Jangan takut untuk melibatkan penyumbang yang tidak bekerja dalam perniagaan anda dalam aspek utama projek - terutamanya jika mereka sering menjadi penyumbang.
+  <p markdown="1" class="pquote-credit">
+— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+  </p>
+</aside>
+
+### Menyumbang kepada projek lain
+
+Sekiranya matlamat anda adalah untuk belajar bagaimana berkolaborasi dengan orang lain atau memahami bagaimana sumber terbuka berfungsi, pertimbangkan untuk menyumbang kepada projek yang ada. Mulakan dengan projek yang sudah anda gunakan dan sukai. Menyumbang kepada projek boleh semudah memperbaiki kesalahan ketik atau mengemas kini dokumentasi.
+
+Sekiranya anda tidak pasti cara memulakan sebagai penyumbang, lihat kami [How to Contribute to Open Source guide](../how-to-contribute/).
+
+## Melancarkan projek sumber terbuka anda sendiri
+
+Tidak ada masa yang tepat untuk membuka sumber pekerjaan anda. Anda boleh membuka sumber idea, karya yang sedang berjalan, atau setelah bertahun-tahun menjadi sumber tertutup.
+
+Secara umum, anda harus membuka sumber projek anda apabila anda merasa selesa melihat orang lain, dan memberi maklum balas mengenai kerja anda.
+
+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/)
+* [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.
+
+Sekiranya projek anda berada di GitHub, meletakkan fail-fail ini di direktori root anda dengan nama fail yang disyorkan akan membantu GitHub mengenali dan memaparkannya secara automatik kepada pembaca anda.
+
+### Memilih lesen
+
+Lesen sumber terbuka menjamin bahawa orang lain dapat menggunakan, menyalin, mengubah suai, dan menyumbang kembali ke projek anda tanpa kesan. Ia juga melindungi anda dari situasi undang-undang yang melekit. **Anda mesti menyertakan lesen semasa melancarkan projek sumber terbuka.**
+
+Kerja undang-undang tidak menyeronokkan. Berita baiknya ialah anda boleh menyalin dan menampal lesen yang ada ke dalam repositori anda. Hanya perlu satu minit untuk melindungi kerja keras anda.
+
+[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[there are other options](https://choosealicense.com) untuk dipilih.
+
+Apabila anda membuat projek baru di GitHub, anda diberi pilihan untuk memilih lesen. Menyertakan lesen sumber terbuka akan menjadikan projek GitHub anda sebagai sumber terbuka.
+
+![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+
+Sekiranya anda mempunyai pertanyaan atau kebimbangan lain mengenai aspek undang-undang dalam menguruskan projek sumber terbuka, [we've got you covered](../legal/).
+
+### Menulis README
+
+README melakukan lebih daripada sekadar menjelaskan cara menggunakan projek anda. Mereka juga menjelaskan mengapa projek anda penting, dan apa yang pengguna anda boleh lakukan dengannya.
+
+Dalam README anda, cuba jawab soalan berikut:
+
+* Apa yang dilakukan oleh projek ini?
+* Mengapa projek ini berguna?
+* Bagaimana saya memulakan?
+* Di mana saya boleh mendapatkan lebih banyak pertolongan, jika saya memerlukannya?
+
+Anda boleh menggunakan README anda untuk menjawab soalan lain, seperti bagaimana anda menangani sumbangan, apakah matlamat projek tersebut, dan maklumat mengenai lesen dan atribusi. Sekiranya anda tidak mahu menerima sumbangan, atau projek anda belum siap untuk dihasilkan, tuliskan maklumat ini.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+  Dokumentasi yang lebih baik bermaksud lebih banyak pengguna, kurang permintaan sokongan, dan lebih banyak penyumbang. (...) Ingat bahawa pembaca anda bukan anda. Ada orang yang mungkin datang ke projek yang mempunyai pengalaman yang sama sekali berbeza.
+  <p markdown="1" class="pquote-credit">
+— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+  </p>
+</aside>
+
+Kadang-kadang, orang mengelak daripada menulis README kerana mereka merasa projek ini belum selesai, atau mereka tidak mahu sumbangan. Ini semua adalah alasan yang baik untuk menulisnya.
+
+Untuk lebih banyak inspirasi, cuba gunakan @ dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2)untuk menulis BACAAN lengkap.
+
+Apabila anda memasukkan fail README dalam direktori root, GitHub akan memaparkannya secara automatik di halaman utama repositori.
+
+### Menulis garis panduan penyumbang anda
+
+Fail CONTRIBUTING memberitahu penonton anda bagaimana untuk mengambil bahagian dalam projek anda. Contohnya, anda mungkin memasukkan maklumat mengenai:
+
+* Cara memfailkan laporan pepijat (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
+* Cara mencadangkan ciri baru
+* Cara mengatur persekitaran anda dan menjalankan ujian
+
+Sebagai tambahan kepada butiran teknikal, fail CONTRIBUTING adalah peluang untuk menyampaikan harapan anda terhadap sumbangan, seperti:
+
+* Jenis sumbangan yang anda cari
+* Peta jalan atau visi anda untuk projek tersebut
+* Bagaimana penyumbang seharusnya (atau tidak seharusnya) menghubungi anda
+
+Menggunakan nada yang mesra dan mesra serta memberikan cadangan khusus untuk sumbangan (seperti menulis dokumentasi, atau membuat laman web) dapat membuat pendatang baru merasa disambut dan teruja untuk turut serta.
+
+Sebagai contoh, [Active Admin](https://github.com/activeadmin/activeadmin/) memulai [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md)dengan:
+
+> Pertama, terima kasih kerana mempertimbangkan untuk menyumbang kepada Admin Aktif. Orang seperti anda menjadikan Admin Aktif sebagai alat yang hebat.
+
+Pada peringkat awal projek anda, fail CONTRIBUTING anda boleh dibuat dengan mudah. Anda harus selalu menerangkan cara melaporkan pepijat atau masalah fail, dan sebarang keperluan teknikal (seperti ujian) untuk memberi sumbangan.
+
+Lama kelamaan, anda mungkin menambahkan soalan lain yang sering diajukan ke fail CONTRIBUTING anda. Menulis maklumat ini bermaksud semakin sedikit orang yang akan menanyakan soalan yang sama berulang kali kepada anda.
+
+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.
+
+![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+
+### Menetapkan tatakelakuan
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+  Kita semua mempunyai pengalaman di mana kita menghadapi apa yang mungkin disalahgunakan baik sebagai penyelenggara yang berusaha menjelaskan mengapa sesuatu harus menjadi cara tertentu, atau sebagai pengguna ... mengajukan soalan mudah. (...) Tatakelakuan menjadi dokumen yang mudah dirujuk dan dihubungkan yang menunjukkan bahawa pasukan anda mengambil wacana konstruktif dengan sangat serius.
+  <p markdown="1" class="pquote-credit">
+— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+  </p>
+</aside>
+
+Akhirnya, kod tingkah laku membantu menetapkan peraturan asas untuk tingkah laku bagi peserta projek anda. Ini amat berharga jika anda melancarkan projek sumber terbuka untuk komuniti atau syarikat. Kod tingkah laku memberi kuasa kepada anda untuk memfasilitasi tingkah laku masyarakat yang sihat dan membina, yang akan mengurangkan tekanan anda sebagai penjaga.
+
+Untuk maklumat lebih lanjut, lihat kami [Code of Conduct guide](../code-of-conduct/).
+
+Selain berkomunikasi _how_ anda mengharapkan peserta berkelakuan, kod tingkah laku juga cenderung menggambarkan kepada siapa harapan ini berlaku, ketika berlaku, dan apa yang harus dilakukan jika pelanggaran berlaku.
+
+Sama seperti lesen sumber terbuka, terdapat juga piawaian kod tingkah laku yang muncul, jadi anda tidak perlu menulis sendiri. The[Contributor Covenant](https://contributor-covenant.org/) adalah tatakelakuan drop-in yang digunakan oleh [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), termasuk Kubernetes, Rails, dan Swift. Tidak kira teks yang anda gunakan, anda harus bersiap sedia untuk menegakkan tatakelakuan anda bila perlu.
+
+Tampal teks terus ke fail CODE_OF_CONDUCT di repositori anda. Simpan fail tersebut di direktori root projek anda sehingga mudah dicari, dan pautkan ke sana dari README anda.
+
+## Menamakan dan menjenamakan projek anda
+
+Penjenamaan lebih daripada sekadar logo yang mencolok atau nama projek yang menarik. Ini mengenai bagaimana anda membincangkan projek anda, dan siapa yang anda sampaikan dengan mesej anda.
+
+### Memilih nama yang betul
+
+Pilih nama yang senang diingat dan, idealnya, memberi idea tentang apa yang dilakukan oleh projek itu. Sebagai contoh:
+
+* [Sentry](https://github.com/getsentry/sentry) memantau aplikasi untuk pelaporan kerosakan
+* [Thin](https://github.com/macournoyer/thin) adalah pelayan web Ruby yang pantas dan ringkas
+
+Sekiranya anda membina projek yang ada, menggunakan nama mereka sebagai awalan dapat membantu menjelaskan apa yang dilakukan oleh projek anda (contohnya, [node-fetch](https://github.com/bitinn/node-fetch) bawah `window.fetch` ke Node.js).
+
+Pertimbangkan kejelasan di atas semua. Rasa tidak senang, tetapi ingat bahawa beberapa lelucon mungkin tidak diterjemahkan ke budaya lain atau orang yang mempunyai pengalaman berbeza dari anda. Sebilangan pengguna berpotensi anda mungkin merupakan pekerja syarikat: anda tidak mahu membuat mereka tidak selesa apabila mereka harus menjelaskan projek anda di tempat kerja!
+
+### Mengelakkan konflik nama
+
+[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/),terutamanya jika anda berkongsi bahasa atau ekosistem yang sama. Sekiranya nama anda bertindih dengan projek sedia ada yang popular, anda mungkin membingungkan khalayak anda.
+
+Sekiranya anda mahukan laman web, pemegang Twitter, atau sifat lain untuk mewakili projek anda, pastikan anda dapat memperoleh nama yang anda mahukan. Sebaik-baiknya, [reserve those names now](https://instantdomainsearch.com/) untuk ketenangan fikiran, walaupun anda belum mahu menggunakannya
+
+Pastikan bahawa nama projek anda tidak melanggar tanda dagangan. Syarikat mungkin meminta anda untuk menghentikan projek anda di kemudian hari, atau bahkan mengambil tindakan undang-undang terhadap anda. Ia tidak sepadan dengan risikonya.
+
+Anda boleh menyemak [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) untuk konflik tanda dagangan. Sekiranya anda berada di syarikat, ini adalah salah satu perkara yang anda miliki [legal team can help you with](../legal/).
+
+Akhirnya, buat carian Google dengan cepat untuk nama projek anda. Adakah orang dapat mencari projek anda dengan mudah? Adakah perkara lain muncul dalam hasil carian yang anda tidak mahu mereka lihat?
+
+### Cara anda menulis (dan kod) juga mempengaruhi jenama anda!
+
+Sepanjang hayat projek anda, anda akan melakukan banyak penulisan: README, tutorial, dokumen komuniti, menanggapi masalah, bahkan mungkin buletin dan senarai surat.
+
+Sama ada dokumentasi rasmi atau e-mel biasa, gaya penulisan anda adalah sebahagian daripada jenama projek anda. Pertimbangkan bagaimana anda dapat menemui audiens anda dan apakah itu nada yang ingin anda sampaikan.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  Saya cuba terlibat dengan setiap urutan dalam senarai mel, dan menunjukkan tingkah laku teladan, bersikap baik kepada orang lain, memandang serius masalah mereka dan berusaha untuk membantu secara keseluruhan. Selepas beberapa ketika, orang-orang tidak hanya bertanya, tetapi membantu menjawabnya, dan dengan rasa gembira saya, mereka meniru gaya saya.
+  <p markdown="1" class="pquote-credit">
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+Menggunakan bahasa yang mesra dan inklusif (seperti "mereka", walaupun merujuk kepada orang bujang) dapat membuat projek anda terasa senang menerima penyumbang baru. Berpeganglah pada bahasa yang mudah, kerana kebanyakan pembaca anda mungkin bukan penutur bahasa Inggeris asli.
+
+Di luar cara anda menulis perkataan, gaya pengekodan anda juga boleh menjadi sebahagian daripada jenama projek anda. [Angular](https://angular.io/guide/styleguide) dan [jQuery](https://contribute.jquery.org/style-guide/js/) adalah dua contoh projek dengan gaya dan garis panduan pengkodan yang ketat.
+
+Anda tidak perlu menulis panduan gaya untuk projek anda semasa anda baru memulakannya, dan anda mungkin merasa senang untuk memasukkan gaya pengkodan yang berbeza ke dalam projek anda pula. Tetapi anda harus menjangkakan bagaimana gaya penulisan dan pengekodan anda dapat menarik atau mencegah pelbagai jenis orang. Peringkat awal projek anda adalah peluang anda untuk menetapkan preseden yang ingin anda lihat.
+
+## 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.
+
+**Dokumentasi**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Projek mempunyai fail LICENSE dengan lesen sumber terbuka
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    Projek mempunyai dokumentasi asas (README, CONTRIBUTING, CODE_OF_CONDUCT)
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    Nama itu mudah diingat, memberikan beberapa idea tentang apa yang dilakukan oleh projek itu, dan tidak bertentangan dengan projek yang ada atau melanggar tanda dagang
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    Antrean masalah terkini, dengan isu yang teratur dan dilabel dengan jelas
+  </label>
+</div>
+
+**Code**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Projek menggunakan konvensyen kod yang konsisten dan fungsi / kaedah / nama pemboleh ubah yang jelas
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Kod tersebut dikomentari dengan jelas, mendokumentasikan niat dan kes-kes kelebihan
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Tidak ada bahan sensitif dalam sejarah semakan, masalah, atau permintaan tarik (misalnya, kata laluan atau maklumat bukan umum lain)
+  </label>
+</div>
+
+**Orang**
+
+Sekiranya anda seorang individu:
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+  Anda telah berbincang dengan jabatan undang-undang dan / atau memahami dasar IP dan sumber terbuka syarikat anda (jika anda seorang pekerja di suatu tempat)
+  </label>
+</div>
+
+Sekiranya anda syarikat atau organisasi:
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Anda telah bercakap dengan jabatan undang-undang anda
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    Anda mempunyai rancangan pemasaran untuk mengumumkan dan mempromosikan projek tersebut
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Seseorang komited untuk mengurus interaksi masyarakat (menanggapi masalah, mengkaji dan menggabungkan permintaan tarik)
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    Sekurang-kurangnya dua orang mempunyai akses pentadbiran ke projek ini
+  </label>
+</div>
+
+## Kamu lakukan!
+
+Tahniah kerana sumber terbuka projek pertama anda. Tidak kira hasilnya, bekerja di khalayak ramai adalah hadiah untuk masyarakat. Dengan setiap komitmen, komen, dan permintaan tarik, anda mencipta peluang untuk diri sendiri dan orang lain untuk belajar dan berkembang.
\ No newline at end of file

From cc3a0ce6080dca7b4237f633cde7cd1e104c0dfb Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 01:44:08 +0800
Subject: [PATCH 041/749] fixed some test errors

---
 _articles/ms/best-practices.md     | 9 +++++----
 _articles/ms/building-community.md | 7 ++++---
 _articles/ms/code-of-conduct.md    | 4 ++--
 _articles/ms/finding-users.md      | 4 ++--
 4 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md
index 6002e651e1c..d9175388c46 100644
--- a/_articles/ms/best-practices.md
+++ b/_articles/ms/best-practices.md
@@ -88,7 +88,7 @@ Anda telah menulis perkara. Sebaik-baiknya, semua orang akan membaca dokumentasi
 
 Akan tetapi, segala sesuatu yang ditulis dapat membantu melumpuhkan situasi ketika anda perlu menguatkuasakan peraturan anda.
 
-Mengatakan tidak tidak menyenangkan, tetapi _ "Sumbangan anda tidak sesuai dengan kriteria projek ini" _ terasa kurang peribadi daripada _ "Saya tidak suka sumbangan anda" _.
+Mengatakan tidak menyenangkan, tetapi _"Sumbangan anda tidak sesuai dengan kriteria projek ini"_ terasa kurang peribadi daripada _"Saya tidak suka sumbangan anda"_.
 
 Mengatakan tidak berlaku untuk banyak situasi yang akan anda hadapi sebagai penjaga: permintaan ciri yang tidak sesuai dengan ruang lingkup, seseorang menggelincirkan perbincangan, melakukan pekerjaan yang tidak perlu untuk orang lain.
 
@@ -131,7 +131,7 @@ Sekiranya memikirkan untuk tidak menakutkan anda, anda tidak sendirian. Sebagai
 
 > Saya telah bercakap dengan penyelenggara dari beberapa projek sumber terbuka yang berbeza, Mesos, Kubernetes, Chromium, dan mereka semua bersetuju bahawa salah satu bahagian yang paling sukar untuk menjadi penyelenggara adalah mengatakan "Tidak" untuk membetulkan yang tidak anda mahukan.
 
-Jangan merasa bersalah kerana tidak mahu menerima sumbangan seseorang. Peraturan pertama sumber terbuka, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Tidak adalah sementara, ya adalah selamanya." _ Walaupun berempati dengan semangat orang lain adalah perkara yang baik, menolak sumbangan tidak sama dengan menolak orang di belakangnya."
+Jangan merasa bersalah kerana tidak mahu menerima sumbangan seseorang. Peraturan pertama sumber terbuka, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Tidak adalah sementara, ya adalah selamanya."_ Walaupun berempati dengan semangat orang lain adalah perkara yang baik, menolak sumbangan tidak sama dengan menolak orang di belakangnya."
 
 Pada akhirnya, jika sumbangan tidak cukup baik, anda tidak berkewajiban untuk menerimanya. Bersikap baik dan responsif apabila orang menyumbang kepada projek anda, tetapi hanya menerima perubahan yang anda benar-benar yakin akan menjadikan projek anda lebih baik. Semakin kerap anda berlatih mengatakan tidak, semakin mudah. Janji.
 
@@ -162,7 +162,7 @@ Kadang kala, apabila anda mengatakan tidak, calon penyumbang anda mungkin marah
 
 Mungkin seseorang dalam komuniti anda kerap menghantar sumbangan yang tidak memenuhi piawaian projek anda. Ini boleh membuat frustasi bagi kedua-dua pihak untuk berulang kali menolak.
 
-Sekiranya anda melihat bahawa seseorang berminat dengan projek anda, tetapi memerlukan sedikit penggilap, bersabarlah. Terangkan dengan jelas dalam setiap situasi mengapa sumbangan mereka tidak memenuhi jangkaan projek. Cuba arahkan mereka ke tugas yang lebih mudah atau tidak samar-samar, seperti masalah yang ditandai _ "isu pertama yang baik", _ agar kaki mereka basah. Sekiranya anda mempunyai masa, pertimbangkan untuk membimbing mereka melalui sumbangan pertama mereka, atau cari orang lain dalam komuniti anda yang mungkin bersedia membimbing mereka.
+Sekiranya anda melihat bahawa seseorang berminat dengan projek anda, tetapi memerlukan sedikit penggilap, bersabarlah. Terangkan dengan jelas dalam setiap situasi mengapa sumbangan mereka tidak memenuhi jangkaan projek. Cuba arahkan mereka ke tugas yang lebih mudah atau tidak samar-samar, seperti masalah yang ditandai _"isu pertama yang baik",_ agar kaki mereka basah. Sekiranya anda mempunyai masa, pertimbangkan untuk membimbing mereka melalui sumbangan pertama mereka, atau cari orang lain dalam komuniti anda yang mungkin bersedia membimbing mereka.
 
 ## Macamana manfaatkan komuniti anda
 
@@ -208,7 +208,7 @@ Memaksa projek tidak harus menjadi perkara yang buruk. Mampu menyalin dan mengub
   </p>
 </aside>
 
-Perkara yang sama berlaku untuk pengguna yang benar-benar mahukan penyelesaian yang anda tidak mempunyai lebar jalur untuk dibina. Menawarkan API dan penyesuaian penyesuaian dapat membantu orang lain memenuhi keperluan mereka sendiri, tanpa harus mengubah sumbernya secara langsung. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) pemalam yang menggalakkan untuk CocoaPod membawa kepada "beberapa idea yang paling menarik":
+Perkara yang sama berlaku untuk pengguna yang benar-benar mahukan penyelesaian yang anda tidak mempunyai lebar jalur untuk dibina. Menawarkan API dan penyesuaian dapat membantu orang lain memenuhi keperluan mereka sendiri, tanpa harus mengubah sumbernya secara langsung. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) pemalam yang menggalakkan untuk CocoaPod membawa kepada "beberapa idea yang paling menarik":
 
 > Hampir tidak dapat dielakkan apabila projek menjadi besar, penyelenggara harus menjadi lebih konservatif mengenai bagaimana mereka memperkenalkan kod baru. Anda menjadi pandai mengatakan "tidak", tetapi banyak orang mempunyai keperluan yang sah. Oleh itu, anda akhirnya menukar alat anda menjadi platform.
 
@@ -225,6 +225,7 @@ Ujian membantu penyumbang merasa yakin bahawa mereka tidak akan merosakkan apa-a
 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.
 
 Sekiranya anda menambahkan ujian, pastikan untuk menerangkan bagaimana ia berfungsi dalam fail CONTRIBUTING anda.
+
 <aside markdown="1" class="pquote">
   <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.
diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
index dba8d5bcc40..18a66960fb5 100644
--- a/_articles/ms/building-community.md
+++ b/_articles/ms/building-community.md
@@ -137,7 +137,7 @@ Dalam fail CONTRIBUTING anda, jelaskan cara penyumbang baru kepada penyumbang ba
 
 ![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
 
-Dalam barisan masalah anda, labelkan pepijat yang sesuai untuk pelbagai jenis penyumbang: sebagai contoh, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only),_ "terbitan pertama yang baik" _, atau _ "dokumentasi" _. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) permudahkan seseorang yang baru dalam projek anda untuk mengimbas masalah anda dengan cepat dan memulakannya.
+Dalam barisan masalah anda, labelkan pepijat yang sesuai untuk pelbagai jenis penyumbang: sebagai contoh, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only),_"terbitan pertama yang baik"_, atau _"dokumentasi"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) permudahkan seseorang yang baru dalam projek anda untuk mengimbas masalah anda dengan cepat dan memulakannya.
 
 Akhirnya, gunakan dokumentasi anda untuk membuat orang merasa diterima di setiap langkah.
 
@@ -198,6 +198,7 @@ Sebahagian besarnya, jika anda telah membina komuniti yang ramah, hormat dan men
 Apabila komuniti anda bergelut dengan masalah yang sukar, kemarahan mungkin akan meningkat. Orang mungkin menjadi marah atau kecewa dan mengeluarkannya satu sama lain, atau pada anda.
 
 Tugas anda sebagai penyelenggara adalah untuk memastikan situasi ini tidak meningkat. Walaupun anda mempunyai pendapat yang kuat mengenai topik ini, cubalah mengambil kedudukan sebagai moderator atau fasilitator, daripada melompat ke dalam pertengkaran dan mendorong pandangan anda. Sekiranya seseorang bersikap tidak baik atau memonopoli perbualan, [act immediately](../building-community/#dont-tolerate-bad-actors) agar perbincangan tetap sopan dan produktif.
+
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
  Sebagai penyelenggara projek, sangat penting untuk menghormati penyumbang anda. Mereka sering mengambil apa yang anda katakan secara peribadi.
@@ -244,9 +245,9 @@ Galakkan perbincangan selagi ia bergerak secara aktif ke arah penyelesaian. Seki
 
 Membiarkan perbualan ini diteruskan bukan hanya buruk untuk masalah yang dihadapi, tetapi juga buruk bagi kesihatan komuniti anda. Ini mengirimkan mesej bahawa jenis percakapan ini diizinkan atau bahkan digalakkan, dan ini dapat mendorong orang untuk membangkitkan atau menyelesaikan masalah di masa depan.
 
-Dengan setiap titik yang dibuat oleh anda atau oleh orang lain, tanyakan pada diri sendiri, _ "Bagaimana ini mendekatkan kita dengan penyelesaian?" _
+Dengan setiap titik yang dibuat oleh anda atau oleh orang lain, tanyakan pada diri sendiri, _"Bagaimana ini mendekatkan kita dengan penyelesaian?"_
 
-Sekiranya perbualan mula terungkai, tanyakan kepada kumpulan, _ "Langkah mana yang harus kita ambil selanjutnya?" _ Untuk memfokuskan kembali perbualan.
+Sekiranya perbualan mula terungkai, tanyakan kepada kumpulan, _"Langkah mana yang harus kita ambil selanjutnya?"_ Untuk memfokuskan kembali perbualan.
 
 Sekiranya perbualan jelas tidak akan ke mana-mana, tidak ada tindakan yang jelas untuk diambil, atau tindakan yang sesuai telah diambil, tutup masalahnya dan terangkan mengapa anda menutupnya.
 
diff --git a/_articles/ms/code-of-conduct.md b/_articles/ms/code-of-conduct.md
index 5347f17adf3..7ef16277bc8 100644
--- a/_articles/ms/code-of-conduct.md
+++ b/_articles/ms/code-of-conduct.md
@@ -30,8 +30,8 @@ Cuba buat kod tingkah laku seawal mungkin: idealnya, ketika pertama kali membuat
 
 Selain menyampaikan harapan anda, kod tingkah laku menerangkan perkara berikut:
 
-* Di mana tatakelakuan berkuatkuasa _ (hanya pada isu dan permintaan tarik, atau aktiviti masyarakat seperti acara?) _
-* Siapa yang mematuhi tata kelakuan _ (anggota masyarakat dan penyelenggara, tetapi bagaimana dengan penaja?) _
+* Di mana tatakelakuan berkuatkuasa _(hanya pada isu dan permintaan tarik, atau aktiviti masyarakat seperti acara?)_
+* Siapa yang mematuhi tata kelakuan _(anggota masyarakat dan penyelenggara, tetapi bagaimana dengan penaja?)_
 * Apa yang berlaku sekiranya seseorang melanggar tatakelakuan
 * Bagaimana seseorang dapat melaporkan pelanggaran
 
diff --git a/_articles/ms/finding-users.md b/_articles/ms/finding-users.md
index 0db652708cb..c241261e483 100644
--- a/_articles/ms/finding-users.md
+++ b/_articles/ms/finding-users.md
@@ -60,7 +60,7 @@ Sekiranya anda belum mahu menyediakan kedai untuk projek anda, promosikan pegang
 
 **Pertimbangkan untuk membuat laman web untuk projek anda.** Laman web menjadikan projek anda lebih mesra dan lebih mudah dilayari, terutama jika dipasangkan dengan dokumentasi dan tutorial yang jelas. Mempunyai laman web juga menunjukkan bahawa projek anda aktif yang akan membuatkan penonton anda merasa lebih selesa menggunakannya. Berikan contoh untuk memberi idea kepada orang ramai tentang cara menggunakan projek anda.
 
-[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), pencipta bersama Django, mengatakan bahawa laman web adalah _ "sejauh ini adalah perkara terbaik yang kami lakukan dengan Django pada masa awal" _.
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), pencipta bersama Django, mengatakan bahawa laman web adalah _"sejauh ini adalah perkara terbaik yang kami lakukan dengan Django pada masa awal"_.
 
 Sekiranya projek anda dihoskan di GitHub, anda boleh menggunakan [GitHub Pages](https://pages.github.com/) untuk membuat laman web dengan mudah. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), dan [Middleman](https://middlemanapp.com/) ialah [a few examples](https://github.com/showcases/github-pages-examples) laman web yang sangat baik dan komprehensif.
 
@@ -86,7 +86,7 @@ Lihat apakah anda dapat mencari cara untuk berkongsi projek anda dengan cara yan
 
 * **Kenali projek dan komuniti sumber terbuka yang relevan.** Kadang kala, anda tidak perlu mempromosikan projek anda secara langsung. Sekiranya projek anda sesuai untuk saintis data yang menggunakan Python, kenali komuniti sains data Python. Apabila orang mengenali anda, peluang semula jadi akan timbul untuk membincangkan dan berkongsi kerja anda.
 * **Cari orang yang mengalami masalah yang diselesaikan oleh projek anda.** Cari melalui forum yang berkaitan untuk orang yang menjadi sasaran khalayak projek anda. Jawab soalan mereka dan cari cara yang bijaksana, bila sesuai, untuk mencadangkan projek anda sebagai jalan penyelesaian.
-* **Minta maklum balas.** Perkenalkan diri anda dan karya anda kepada penonton yang menganggapnya relevan dan menarik. Jadilah spesifik mengenai siapa yang anda fikir akan mendapat manfaat daripada projek anda. Cuba selesaikan ayat: _ "Saya rasa projek saya akan benar-benar membantu X, yang berusaha melakukan Y_". Dengarkan dan balas maklum balas orang lain, bukan sekadar mempromosikan karya anda.
+* **Minta maklum balas.** Perkenalkan diri anda dan karya anda kepada penonton yang menganggapnya relevan dan menarik. Jadilah spesifik mengenai siapa yang anda fikir akan mendapat manfaat daripada projek anda. Cuba selesaikan ayat: _"Saya rasa projek saya akan benar-benar membantu X, yang berusaha melakukan Y_". Dengarkan dan balas maklum balas orang lain, bukan sekadar mempromosikan karya anda.
 
 Secara umumnya, fokus menolong orang lain sebelum meminta sesuatu sebagai balasan. Kerana sesiapa sahaja dapat mempromosikan projek dalam talian dengan mudah, akan ada banyak kebisingan. Untuk menonjol dari orang ramai, beri orang konteks untuk siapa anda dan bukan hanya yang anda mahukan.
 

From 4055b5c60adffd1b039e63cd05c726ce9a1bccb7 Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 01:50:21 +0800
Subject: [PATCH 042/749] fixed the end of line error

---
 _articles/ms/best-practices.md    | 2 +-
 _articles/ms/code-of-conduct.md   | 2 +-
 _articles/ms/finding-users.md     | 2 +-
 _articles/ms/how-to-contribute.md | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md
index d9175388c46..6522d93765a 100644
--- a/_articles/ms/best-practices.md
+++ b/_articles/ms/best-practices.md
@@ -284,4 +284,4 @@ Beristirahat juga berlaku untuk lebih daripada sekadar percutian. Sekiranya anda
 
 ## Jaga diri anda terlebih dahulu!
 
-Mengekalkan projek yang popular memerlukan kemahiran yang berbeza daripada tahap pertumbuhan yang lebih awal, tetapi ia tidak kurang memberangsangkan. Sebagai penyelenggara, anda akan mempraktikkan kepemimpinan dan kemahiran peribadi pada tahap yang dapat dialami oleh beberapa orang. Walaupun tidak selalu mudah dikendalikan, menetapkan batas yang jelas dan hanya mengambil perkara yang anda selesa akan membantu anda tetap bahagia, segar, dan produktif.
\ No newline at end of file
+Mengekalkan projek yang popular memerlukan kemahiran yang berbeza daripada tahap pertumbuhan yang lebih awal, tetapi ia tidak kurang memberangsangkan. Sebagai penyelenggara, anda akan mempraktikkan kepemimpinan dan kemahiran peribadi pada tahap yang dapat dialami oleh beberapa orang. Walaupun tidak selalu mudah dikendalikan, menetapkan batas yang jelas dan hanya mengambil perkara yang anda selesa akan membantu anda tetap bahagia, segar, dan produktif.
diff --git a/_articles/ms/code-of-conduct.md b/_articles/ms/code-of-conduct.md
index 7ef16277bc8..bb04a2b1996 100644
--- a/_articles/ms/code-of-conduct.md
+++ b/_articles/ms/code-of-conduct.md
@@ -117,4 +117,4 @@ Pada akhirnya, sebagai penjaga, anda menetapkan dan menegakkan piawaian untuk ti
 
 ## Galakkan tingkah laku yang anda ingin lihat di dunia 🌎
 
-Apabila projek kelihatan bermusuhan atau tidak disenangi, walaupun hanya satu orang yang tingkah lakunya ditoleransi oleh orang lain, anda berisiko kehilangan banyak lagi penyumbang, yang mungkin tidak pernah anda temui. Tidak selalunya mudah untuk menerapkan atau menegakkan kod tingkah laku, tetapi memupuk persekitaran yang ramah akan membantu komuniti anda berkembang.
\ No newline at end of file
+Apabila projek kelihatan bermusuhan atau tidak disenangi, walaupun hanya satu orang yang tingkah lakunya ditoleransi oleh orang lain, anda berisiko kehilangan banyak lagi penyumbang, yang mungkin tidak pernah anda temui. Tidak selalunya mudah untuk menerapkan atau menegakkan kod tingkah laku, tetapi memupuk persekitaran yang ramah akan membantu komuniti anda berkembang.
diff --git a/_articles/ms/finding-users.md b/_articles/ms/finding-users.md
index c241261e483..5cdd59c702e 100644
--- a/_articles/ms/finding-users.md
+++ b/_articles/ms/finding-users.md
@@ -160,4 +160,4 @@ Tidak ada penyelesaian semalam untuk membina penonton. Memperoleh kepercayaan da
 
 ## Terus!
 
-Mungkin memerlukan masa yang lama sebelum orang melihat projek sumber terbuka anda. Tak mengapa! Beberapa projek yang paling popular hari ini mengambil masa bertahun-tahun untuk mencapai tahap aktiviti yang tinggi. Fokus pada membina hubungan dan bukannya berharap projek anda mendapat populariti secara spontan. Bersabarlah, dan teruskan berkongsi karya anda dengan mereka yang menghargainya.
\ No newline at end of file
+Mungkin memerlukan masa yang lama sebelum orang melihat projek sumber terbuka anda. Tak mengapa! Beberapa projek yang paling popular hari ini mengambil masa bertahun-tahun untuk mencapai tahap aktiviti yang tinggi. Fokus pada membina hubungan dan bukannya berharap projek anda mendapat populariti secara spontan. Bersabarlah, dan teruskan berkongsi karya anda dengan mereka yang menghargainya.
diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
index efe6fefa00f..883100083eb 100644
--- a/_articles/ms/how-to-contribute.md
+++ b/_articles/ms/how-to-contribute.md
@@ -531,4 +531,4 @@ Hore! Anda berjaya memberikan sumbangan sumber terbuka!
 
 ## Kamu lakukan!
 
-Sama ada anda baru sahaja memberikan sumbangan sumber terbuka anda, atau anda mencari cara baru untuk menyumbang, kami harap anda terinspirasi untuk mengambil tindakan. Walaupun sumbangan anda tidak diterima, jangan lupa mengucapkan terima kasih ketika penjaga menjaga usaha anda. Sumber terbuka dibuat oleh orang seperti anda: satu isu, permintaan tarik, komen, atau lima tinggi dalam satu masa.
\ No newline at end of file
+Sama ada anda baru sahaja memberikan sumbangan sumber terbuka anda, atau anda mencari cara baru untuk menyumbang, kami harap anda terinspirasi untuk mengambil tindakan. Walaupun sumbangan anda tidak diterima, jangan lupa mengucapkan terima kasih ketika penjaga menjaga usaha anda. Sumber terbuka dibuat oleh orang seperti anda: satu isu, permintaan tarik, komen, atau lima tinggi dalam satu masa.

From 24493a789a9cf3c8b04d00d1b2d1ead4332a4601 Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 02:00:16 +0800
Subject: [PATCH 043/749] fixed more errors

---
 _articles/ms/how-to-contribute.md         | 52 +++++++++++------------
 _articles/ms/leadership-and-governance.md |  1 -
 _articles/ms/metrics.md                   |  6 +--
 _articles/ms/starting-a-project.md        |  2 +-
 4 files changed, 30 insertions(+), 31 deletions(-)

diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
index 883100083eb..f801cae42cc 100644
--- a/_articles/ms/how-to-contribute.md
+++ b/_articles/ms/how-to-contribute.md
@@ -80,7 +80,7 @@ Kesalahpahaman umum mengenai menyumbang kepada sumber terbuka ialah anda perlu m
 Walaupun anda suka menulis kod, jenis sumbangan lain adalah kaedah terbaik untuk terlibat dengan projek dan bertemu dengan ahli komuniti lain. Membina hubungan tersebut akan memberi anda peluang untuk bekerja di bahagian lain projek.
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
- Saya pertama kali menghubungi pasukan pengembangan Python (aka python-dev) ketika saya menghantar e-mel kepada senarai mel pada 17 Jun 2002 mengenai penerimaan tampalan saya. Saya dengan cepat menangkap bug sumber terbuka, dan memutuskan untuk mula menguruskan pencernaan e-mel untuk kumpulan itu. Mereka memberi saya alasan yang baik untuk meminta penjelasan mengenai sesuatu topik, tetapi lebih kritikal saya dapat melihat ketika seseorang menunjukkan sesuatu yang perlu diperbaiki.
+   Saya pertama kali menghubungi pasukan pengembangan Python (aka python-dev) ketika saya menghantar e-mel kepada senarai mel pada 17 Jun 2002 mengenai penerimaan tampalan saya. Saya dengan cepat menangkap bug sumber terbuka, dan memutuskan untuk mula menguruskan pencernaan e-mel untuk kumpulan itu. Mereka memberi saya alasan yang baik untuk meminta penjelasan mengenai sesuatu topik, tetapi lebih kritikal saya dapat melihat ketika seseorang menunjukkan sesuatu yang perlu diperbaiki.
   <p markdown="1" class="pquote-credit">
 — @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
   </p>
@@ -196,14 +196,14 @@ Akhirnya, projek sumber terbuka menggunakan alat berikut untuk mengatur perbinca
 
 * **Issue tracker:** Di mana orang membincangkan masalah yang berkaitan dengan projek.
 * **Pull requests:** Tempat orang membincangkan dan mengkaji perubahan yang sedang dilakukan.
-* **Discussion forums or mailing lists:** Beberapa projek mungkin menggunakan saluran ini untuk topik perbualan (misalnya, _ "Bagaimana saya ..." _ atau _ "Apa pendapat anda tentang ..." _ bukannya laporan pepijat atau permintaan ciri). Yang lain menggunakan pelacak masalah untuk semua perbualan.
+* **Discussion forums or mailing lists:** Beberapa projek mungkin menggunakan saluran ini untuk topik perbualan (misalnya, _"Bagaimana saya ..."_ atau _"Apa pendapat anda tentang ..."_ bukannya laporan pepijat atau permintaan ciri). Yang lain menggunakan pelacak masalah untuk semua perbualan.
 * **Synchronous chat channel:** Beberapa projek menggunakan saluran sembang (seperti Slack atau IRC) untuk perbualan santai, kolaborasi, dan pertukaran cepat.
 
 ## Mencari projek untuk disumbangkan
 
 Sekarang setelah anda mengetahui bagaimana projek sumber terbuka berfungsi, inilah masanya untuk mencari projek untuk disumbangkan!
 
-Sekiranya anda tidak pernah menyumbang kepada sumber terbuka sebelumnya, dapatkan nasihat Presiden A.S. John F. Kennedy, yang pernah berkata, _ "Jangan tanya apa yang boleh dilakukan oleh negara anda untuk anda - tanyakan apa yang boleh anda lakukan untuk negara anda." _
+Sekiranya anda tidak pernah menyumbang kepada sumber terbuka sebelumnya, dapatkan nasihat Presiden A.S. John F. Kennedy, yang pernah berkata, _"Jangan tanya apa yang boleh dilakukan oleh negara anda untuk anda - tanyakan apa yang boleh anda lakukan untuk negara anda."_
 
 Menyumbang kepada sumber terbuka berlaku di semua peringkat, di semua projek. Anda tidak perlu terlalu memikirkan apa sebenarnya sumbangan pertama anda, atau bagaimana bentuknya.
 
@@ -246,7 +246,7 @@ Berikut adalah senarai semak yang berguna untuk menilai sama ada projek itu baik
   </label>
 </div>
 
-** Projek secara aktif menerima sumbangan **
+**Projek secara aktif menerima sumbangan**
 
 Lihat aktiviti komit di cawangan induk. Di GitHub, anda dapat melihat maklumat ini di laman utama repositori.
 
@@ -345,7 +345,7 @@ Sekarang lakukan perkara yang sama untuk permintaan tarikan projek.
   </label>
 </div>
 
-** Projek dialu-alukan **
+**Projek dialu-alukan**
 
 Projek yang mesra dan mesra memberi isyarat bahawa mereka akan menerima penyumbang baru.
 
@@ -403,43 +403,43 @@ Sama ada anda penyumbang sekali atau cuba menyertai komuniti, bekerja dengan ora
 
 Sebelum anda membuka masalah atau menarik permintaan, atau mengajukan soalan dalam sembang, ingatlah perkara ini untuk membantu idea anda disampaikan dengan berkesan.
 
-** Beri konteks. ** Bantu orang lain dengan pantas. Sekiranya anda mengalami ralat, jelaskan apa yang anda cuba lakukan dan bagaimana menghasilkannya. Sekiranya anda mencadangkan idea baru, jelaskan mengapa anda berpendapat bahawa ia berguna untuk projek ini (bukan hanya untuk anda!).
+**Beri konteks.** Bantu orang lain dengan pantas. Sekiranya anda mengalami ralat, jelaskan apa yang anda cuba lakukan dan bagaimana menghasilkannya. Sekiranya anda mencadangkan idea baru, jelaskan mengapa anda berpendapat bahawa ia berguna untuk projek ini (bukan hanya untuk anda!).
 
-> 😇 _ "X tidak berlaku semasa saya melakukan Y" _
+> 😇 _"X tidak berlaku semasa saya melakukan Y"_
 >
-> 😢 _ "X rosak! Sila perbaiki." _
+> 😢 _"X rosak! Sila perbaiki."_
 
-** Lakukan kerja rumah anda terlebih dahulu. ** Tidak perlu mengetahui apa-apa, tetapi tunjukkan bahawa anda telah mencuba. Sebelum meminta bantuan, pastikan untuk memeriksa README, dokumentasi, masalah (terbuka atau tertutup), senarai mel, dan cari di internet untuk mendapatkan jawapan. Orang akan menghargai apabila anda menunjukkan bahawa anda cuba belajar.
+**Lakukan kerja rumah anda terlebih dahulu.** Tidak perlu mengetahui apa-apa, tetapi tunjukkan bahawa anda telah mencuba. Sebelum meminta bantuan, pastikan untuk memeriksa README, dokumentasi, masalah (terbuka atau tertutup), senarai mel, dan cari di internet untuk mendapatkan jawapan. Orang akan menghargai apabila anda menunjukkan bahawa anda cuba belajar.
 
-> 😇 _ "Saya tidak pasti bagaimana melaksanakan X. Saya memeriksa dokumen bantuan dan tidak menemui sebutan." _
+> 😇 _"Saya tidak pasti bagaimana melaksanakan X. Saya memeriksa dokumen bantuan dan tidak menemui sebutan."_
 >
-> 😢 _ "Bagaimana saya X?" _
+> 😢 _"Bagaimana saya X?"_
 
-** Jauhkan permintaan pendek dan langsung. ** Sama seperti menghantar e-mel, setiap sumbangan, tidak kira seberapa sederhana atau bermanfaat, memerlukan ulasan orang lain. Banyak projek mempunyai lebih banyak permintaan masuk daripada orang yang ada untuk membantu. Bersikap ringkas. Anda akan meningkatkan peluang seseorang dapat menolong anda.
+**Jauhkan permintaan pendek dan langsung.** Sama seperti menghantar e-mel, setiap sumbangan, tidak kira seberapa sederhana atau bermanfaat, memerlukan ulasan orang lain. Banyak projek mempunyai lebih banyak permintaan masuk daripada orang yang ada untuk membantu. Bersikap ringkas. Anda akan meningkatkan peluang seseorang dapat menolong anda.
 
-> 😇 _ "Saya ingin menulis tutorial API." _
+> 😇 _"Saya ingin menulis tutorial API."_
 >
-> 😢 _ "Saya memandu di jalan raya pada suatu hari dan berhenti untuk mencari minyak, dan kemudian saya mempunyai idea yang luar biasa ini untuk sesuatu yang seharusnya kita lakukan, tetapi sebelum saya menerangkannya, izinkan saya menunjukkan kepada anda ..." _
+> 😢 _"Saya memandu di jalan raya pada suatu hari dan berhenti untuk mencari minyak, dan kemudian saya mempunyai idea yang luar biasa ini untuk sesuatu yang seharusnya kita lakukan, tetapi sebelum saya menerangkannya, izinkan saya menunjukkan kepada anda ..."_
 
-** Jauhkan semua komunikasi untuk umum. ** Walaupun menggoda, jangan menghubungi penyelenggara secara tertutup kecuali anda perlu berkongsi maklumat sensitif (seperti masalah keselamatan atau pelanggaran tingkah laku serius). Apabila perbualan anda tetap terbuka, lebih ramai orang dapat belajar dan mendapat faedah daripada pertukaran anda. Perbincangan boleh menjadi sumbangan mereka sendiri.
+**Jauhkan semua komunikasi untuk umum.** Walaupun menggoda, jangan menghubungi penyelenggara secara tertutup kecuali anda perlu berkongsi maklumat sensitif (seperti masalah keselamatan atau pelanggaran tingkah laku serius). Apabila perbualan anda tetap terbuka, lebih ramai orang dapat belajar dan mendapat faedah daripada pertukaran anda. Perbincangan boleh menjadi sumbangan mereka sendiri.
 
->😇 _ (sebagai komen) "@ -maintainer Hai! Bagaimana kita harus meneruskan PR ini?" _
+>😇 _(sebagai komen) "@ -maintainer Hai! Bagaimana kita harus meneruskan PR ini?"_
 >
-> 😢 _ (sebagai e-mel) "Hai, maaf kerana mengganggu anda melalui e-mel, tetapi saya tertanya-tanya adakah anda berpeluang untuk mengkaji semula PR saya" _
+> 😢 _(sebagai e-mel) "Hai, maaf kerana mengganggu anda melalui e-mel, tetapi saya tertanya-tanya adakah anda berpeluang untuk mengkaji semula PR saya"_
 
-** Tidak apa-apa untuk mengemukakan soalan (tetapi bersabarlah!). ** Semua orang baru dalam projek ini pada satu ketika, dan bahkan penyumbang yang berpengalaman perlu terus maju ketika mereka melihat projek baru. Dengan cara yang sama, penyelenggara lama juga tidak selalu mengenal setiap bahagian projek. Tunjukkan kepada mereka kesabaran yang sama seperti yang anda mahukan kepada mereka.
+**Tidak apa-apa untuk mengemukakan soalan (tetapi bersabarlah!).** Semua orang baru dalam projek ini pada satu ketika, dan bahkan penyumbang yang berpengalaman perlu terus maju ketika mereka melihat projek baru. Dengan cara yang sama, penyelenggara lama juga tidak selalu mengenal setiap bahagian projek. Tunjukkan kepada mereka kesabaran yang sama seperti yang anda mahukan kepada mereka.
 
-> 😇 _ "Terima kasih kerana melihat ralat ini. Saya mengikuti cadangan anda. Inilah hasilnya." _
+> 😇 _"Terima kasih kerana melihat ralat ini. Saya mengikuti cadangan anda. Inilah hasilnya."_
 >
-> 😢 _ "Mengapa anda tidak dapat menyelesaikan masalah saya? Bukankah ini projek anda?" _
+> 😢 _"Mengapa anda tidak dapat menyelesaikan masalah saya? Bukankah ini projek anda?"_
 
-** Hormati keputusan masyarakat. ** Idea anda mungkin berbeza dengan keutamaan atau visi masyarakat. Mereka mungkin memberikan maklum balas atau memutuskan untuk tidak meneruskan idea anda. Walaupun anda harus berbincang dan mencari kompromi, penyelenggara harus mematuhi keputusan anda lebih lama daripada yang anda mahukan. Sekiranya anda tidak bersetuju dengan arahan mereka, anda sentiasa boleh menggunakan garpu anda sendiri atau memulakan projek anda sendiri.
+**Hormati keputusan masyarakat.** Idea anda mungkin berbeza dengan keutamaan atau visi masyarakat. Mereka mungkin memberikan maklum balas atau memutuskan untuk tidak meneruskan idea anda. Walaupun anda harus berbincang dan mencari kompromi, penyelenggara harus mematuhi keputusan anda lebih lama daripada yang anda mahukan. Sekiranya anda tidak bersetuju dengan arahan mereka, anda sentiasa boleh menggunakan garpu anda sendiri atau memulakan projek anda sendiri.
 
-> 😇 _ "Saya kecewa anda tidak dapat menyokong kes penggunaan saya, tetapi seperti yang anda jelaskan, ini hanya mempengaruhi sebahagian kecil pengguna, saya faham mengapa. Terima kasih kerana mendengar." _
+> 😇 _"Saya kecewa anda tidak dapat menyokong kes penggunaan saya, tetapi seperti yang anda jelaskan, ini hanya mempengaruhi sebahagian kecil pengguna, saya faham mengapa. Terima kasih kerana mendengar."_
 >
-> 😢 _ "Mengapa anda tidak menyokong kes penggunaan saya? Ini tidak boleh diterima!" _
+> 😢 _"Mengapa anda tidak menyokong kes penggunaan saya? Ini tidak boleh diterima!"_
 
-** Yang terpenting, jaga agar tetap berkelas. ** Sumber terbuka terdiri daripada kolaborator dari seluruh dunia. Konteks hilang di seluruh bahasa, budaya, geografi, dan zon waktu. Di samping itu, komunikasi bertulis menjadikannya lebih sukar untuk menyampaikan nada atau mood. Anggap niat baik dalam perbualan ini. Adalah baik untuk menolak idea dengan sopan, meminta lebih banyak konteks, atau memperjelas kedudukan anda. Cubalah tinggalkan internet di tempat yang lebih baik daripada ketika anda menjumpainya.
+**Yang terpenting, jaga agar tetap berkelas.** Sumber terbuka terdiri daripada kolaborator dari seluruh dunia. Konteks hilang di seluruh bahasa, budaya, geografi, dan zon waktu. Di samping itu, komunikasi bertulis menjadikannya lebih sukar untuk menyampaikan nada atau mood. Anggap niat baik dalam perbualan ini. Adalah baik untuk menolak idea dengan sopan, meminta lebih banyak konteks, atau memperjelas kedudukan anda. Cubalah tinggalkan internet di tempat yang lebih baik daripada ketika anda menjumpainya.
 
 ### Mengumpulkan konteks
 
@@ -495,7 +495,7 @@ Sekiranya projek tersebut berada di GitHub, berikut adalah cara mengemukakan per
 * **Uji perubahan anda!** Jalankan perubahan anda terhadap ujian yang ada jika ada dan buat yang baru bila diperlukan. Sama ada ujian ada atau tidak, pastikan perubahan anda tidak mematahkan projek yang ada.
 * **Sumbang dalam gaya projek** dengan sebaik mungkin. Ini mungkin bermaksud menggunakan inden, titik koma atau komen yang berbeza daripada yang anda lakukan di repositori anda sendiri, tetapi memudahkan penyelenggara bergabung, yang lain memahami dan mengekalkannya di masa depan.
 
-Permintaan adalah permintaan permintaan pertama anda, periksa [Make a Pull Request](http://makeapullrequest.com/), yang @kentcdodds buat sebagai tutorial video panduan. Anda juga boleh berlatih membuat permintaan tarik di[First Contributions](https://github.com/Roshanjossey/first-contributions) repositori, dibuat oleh @Roshanjossey.
+Permintaan adalah permintaan pertama anda, periksa [Make a Pull Request](http://makeapullrequest.com/), yang @kentcdodds buat sebagai tutorial video panduan. Anda juga boleh berlatih membuat permintaan tarik di[First Contributions](https://github.com/Roshanjossey/first-contributions) repositori, dibuat oleh @Roshanjossey.
 
 ## Apa yang berlaku selepas anda menghantar sumbangan
 
@@ -509,7 +509,7 @@ Semoga anda[checked the project for signs of activity](#a-checklist-before-you-c
 
 Sekiranya anda tidak mendapat sambutan selama lebih dari seminggu, adalah wajar untuk memberi respons dengan sopan dalam utas yang sama, meminta ulasan seseorang. Sekiranya anda mengetahui nama orang yang tepat untuk mengulas sumbangan anda, anda boleh @ -menyebutkannya dalam utas itu.
 
-** Jangan ** hubungi orang itu secara peribadi; ingat bahawa komunikasi awam sangat penting untuk projek sumber terbuka.
+**Jangan** hubungi orang itu secara peribadi; ingat bahawa komunikasi awam sangat penting untuk projek sumber terbuka.
 
 Sekiranya anda membuat bongkahan yang sopan dan masih tidak ada yang bertindak balas, kemungkinan tidak ada yang akan bertindak balas. Ini bukan perasaan yang hebat, tetapi jangan biarkan itu mengecewakan anda. Ia berlaku kepada semua orang! Terdapat banyak kemungkinan sebab mengapa anda tidak mendapat sambutan, termasuk keadaan peribadi yang mungkin di luar kawalan anda. Cuba cari projek atau cara lain untuk menyumbang. Sekiranya ada, ini adalah alasan yang baik untuk tidak meluangkan terlalu banyak masa untuk membuat sumbangan sebelum anggota masyarakat lain terlibat dan responsif.
 
diff --git a/_articles/ms/leadership-and-governance.md b/_articles/ms/leadership-and-governance.md
index ef136dabfa6..971aa801001 100644
--- a/_articles/ms/leadership-and-governance.md
+++ b/_articles/ms/leadership-and-governance.md
@@ -65,7 +65,6 @@ Memformalkan peranan kepemimpinan anda membantu orang merasakan kepemilikan dan
 
 Untuk projek yang lebih kecil, menetapkan pemimpin boleh semudah menambahkan nama mereka ke nama anda dalam fail README atau fail CONTRIBUTORS.
 
-
 Untuk projek yang lebih besar, jika anda mempunyai laman web, buat halaman pasukan atau senaraikan pemimpin projek anda di sana. Sebagai contoh, [Postgres](https://github.com/postgres/postgres/) mempunyai [comprehensive team page](https://www.postgresql.org/community/contributors/) dengan profil pendek untuk setiap penyumbang.
 
 Sekiranya projek anda mempunyai komuniti penyumbang yang sangat aktif, anda mungkin membentuk "pasukan teras" penyelenggara, atau bahkan jawatankuasa kecil orang yang mengambil alih bidang isu yang berbeza (contohnya keselamatan, pencetus masalah, atau tingkah laku masyarakat). Biarkan orang mengatur diri sendiri dan menjadi sukarelawan untuk peranan yang paling mereka gemari, daripada menyerahkannya.
diff --git a/_articles/ms/metrics.md b/_articles/ms/metrics.md
index dbd4a354d58..d11e3988913 100644
--- a/_articles/ms/metrics.md
+++ b/_articles/ms/metrics.md
@@ -31,7 +31,7 @@ Dengan lebih banyak maklumat, anda boleh:
 
 Contohnya, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) mendapati bahawa Analitis Google membantu mereka mengutamakan kerja:
 
->Homebrew disediakan secara percuma dan dikendalikan sepenuhnya oleh sukarelawan pada masa lapang. Hasilnya, kami tidak mempunyai sumber untuk membuat kajian pengguna terperinci mengenai pengguna Homebrew untuk memutuskan cara terbaik untuk merancang ciri masa depan dan mengutamakan kerja semasa. Analisis pengguna agregat tanpa nama membolehkan kami mengutamakan pembaikan dan ciri berdasarkan bagaimana, di mana dan kapan orang menggunakan Homebrew.
+> Homebrew disediakan secara percuma dan dikendalikan sepenuhnya oleh sukarelawan pada masa lapang. Hasilnya, kami tidak mempunyai sumber untuk membuat kajian pengguna terperinci mengenai pengguna Homebrew untuk memutuskan cara terbaik untuk merancang ciri masa depan dan mengutamakan kerja semasa. Analisis pengguna agregat tanpa nama membolehkan kami mengutamakan pembaikan dan ciri berdasarkan bagaimana, di mana dan kapan orang menggunakan Homebrew.
 
 Populariti bukan segalanya. Semua orang masuk ke sumber terbuka dengan alasan yang berbeza. Sekiranya matlamat anda sebagai penyelenggara sumber terbuka adalah untuk mempamerkan karya anda, bersikap telus mengenai kod anda, atau hanya bersenang-senang, metrik mungkin tidak penting bagi anda.
 
@@ -39,7 +39,7 @@ Sekiranya anda berminat untuk memahami projek anda pada tahap yang lebih mendala
 
 ## Penemuan
 
-Sebelum ada yang dapat menggunakan atau menyumbang kembali ke projek anda, mereka perlu mengetahui bahawa ia wujud. Tanya pada diri anda: _apa orang mencari projek ini? _
+Sebelum ada yang dapat menggunakan atau menyumbang kembali ke projek anda, mereka perlu mengetahui bahawa ia wujud. Tanya pada diri anda: _apa orang mencari projek ini?_
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
@@ -131,4 +131,4 @@ Anda juga dapat mengukur masa yang diperlukan untuk beralih antara tahap dalam p
 
 ## Gunakan 📊 untuk mengetahui tentang orang
 
-Memahami metrik akan membantu anda membina projek sumber terbuka yang aktif dan berkembang. Walaupun anda tidak melacak setiap metrik di papan pemuka, gunakan kerangka di atas untuk memusatkan perhatian anda pada jenis tingkah laku yang akan membantu projek anda berkembang maju.
\ No newline at end of file
+Memahami metrik akan membantu anda membina projek sumber terbuka yang aktif dan berkembang. Walaupun anda tidak melacak setiap metrik di papan pemuka, gunakan kerangka di atas untuk memusatkan perhatian anda pada jenis tingkah laku yang akan membantu projek anda berkembang maju.
diff --git a/_articles/ms/starting-a-project.md b/_articles/ms/starting-a-project.md
index 2f050162708..f5779160837 100644
--- a/_articles/ms/starting-a-project.md
+++ b/_articles/ms/starting-a-project.md
@@ -359,4 +359,4 @@ Sekiranya anda syarikat atau organisasi:
 
 ## Kamu lakukan!
 
-Tahniah kerana sumber terbuka projek pertama anda. Tidak kira hasilnya, bekerja di khalayak ramai adalah hadiah untuk masyarakat. Dengan setiap komitmen, komen, dan permintaan tarik, anda mencipta peluang untuk diri sendiri dan orang lain untuk belajar dan berkembang.
\ No newline at end of file
+Tahniah kerana sumber terbuka projek pertama anda. Tidak kira hasilnya, bekerja di khalayak ramai adalah hadiah untuk masyarakat. Dengan setiap komitmen, komen, dan permintaan tarik, anda mencipta peluang untuk diri sendiri dan orang lain untuk belajar dan berkembang.

From 1459d624f021f1783a5df9c3ed822ce37c368db5 Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 02:08:25 +0800
Subject: [PATCH 044/749] fixed 2 more errors

---
 _articles/ms/how-to-contribute.md | 13 +++++++------
 _config.yml                       |  2 ++
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
index f801cae42cc..79c13e398b4 100644
--- a/_articles/ms/how-to-contribute.md
+++ b/_articles/ms/how-to-contribute.md
@@ -78,12 +78,13 @@ Kesalahpahaman umum mengenai menyumbang kepada sumber terbuka ialah anda perlu m
 </aside>
 
 Walaupun anda suka menulis kod, jenis sumbangan lain adalah kaedah terbaik untuk terlibat dengan projek dan bertemu dengan ahli komuniti lain. Membina hubungan tersebut akan memberi anda peluang untuk bekerja di bahagian lain projek.
+
 <aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-   Saya pertama kali menghubungi pasukan pengembangan Python (aka python-dev) ketika saya menghantar e-mel kepada senarai mel pada 17 Jun 2002 mengenai penerimaan tampalan saya. Saya dengan cepat menangkap bug sumber terbuka, dan memutuskan untuk mula menguruskan pencernaan e-mel untuk kumpulan itu. Mereka memberi saya alasan yang baik untuk meminta penjelasan mengenai sesuatu topik, tetapi lebih kritikal saya dapat melihat ketika seseorang menunjukkan sesuatu yang perlu diperbaiki.
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-  </p>
+    <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
+      Saya pertama kali menghubungi pasukan pengembangan Python (aka python-dev) ketika saya menghantar e-mel kepada senarai mel pada 17 Jun 2002 mengenai penerimaan tampalan saya. Saya dengan cepat menangkap bug sumber terbuka, dan memutuskan untuk mula menguruskan pencernaan e-mel untuk kumpulan itu. Mereka memberi saya alasan yang baik untuk meminta penjelasan mengenai sesuatu topik, tetapi lebih kritikal saya dapat melihat ketika seseorang menunjukkan sesuatu yang perlu diperbaiki.
+    <p markdown="1" class="pquote-credit">
+      — @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
+    </p>
 </aside>
 
 ### Adakah anda suka merancang acara?
@@ -423,7 +424,7 @@ Sebelum anda membuka masalah atau menarik permintaan, atau mengajukan soalan dal
 
 **Jauhkan semua komunikasi untuk umum.** Walaupun menggoda, jangan menghubungi penyelenggara secara tertutup kecuali anda perlu berkongsi maklumat sensitif (seperti masalah keselamatan atau pelanggaran tingkah laku serius). Apabila perbualan anda tetap terbuka, lebih ramai orang dapat belajar dan mendapat faedah daripada pertukaran anda. Perbincangan boleh menjadi sumbangan mereka sendiri.
 
->😇 _(sebagai komen) "@ -maintainer Hai! Bagaimana kita harus meneruskan PR ini?"_
+> 😇 _(sebagai komen) "@ -maintainer Hai! Bagaimana kita harus meneruskan PR ini?"_
 >
 > 😢 _(sebagai e-mel) "Hai, maaf kerana mengganggu anda melalui e-mel, tetapi saya tertanya-tanya adakah anda berpeluang untuk mengkaji semula PR saya"_
 
diff --git a/_config.yml b/_config.yml
index b9075e8af22..760411a69ff 100644
--- a/_config.yml
+++ b/_config.yml
@@ -56,3 +56,5 @@ twitter:
 
 facebook:
   publisher: https://www.facebook.com/GitHub/
+
+github: [metadata]
\ No newline at end of file

From cdb6f1aa04e6d2893669d7b0f8fa4ce33069db63 Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 02:17:19 +0800
Subject: [PATCH 045/749] trying to fix issue with metadata

---
 _config.yml | 2 --
 1 file changed, 2 deletions(-)

diff --git a/_config.yml b/_config.yml
index 760411a69ff..b9075e8af22 100644
--- a/_config.yml
+++ b/_config.yml
@@ -56,5 +56,3 @@ twitter:
 
 facebook:
   publisher: https://www.facebook.com/GitHub/
-
-github: [metadata]
\ No newline at end of file

From d99e4222e225fcafc58a7b0a394a4e1a8b41a9b9 Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 03:37:20 +0800
Subject: [PATCH 046/749] followed the required steps

---
 _articles/ms/best-practices.md |  7 -------
 _data/locales/ms.yml           | 31 +++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 7 deletions(-)
 create mode 100644 _data/locales/ms.yml

diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md
index 6522d93765a..658456d9997 100644
--- a/_articles/ms/best-practices.md
+++ b/_articles/ms/best-practices.md
@@ -3,13 +3,6 @@ lang: ms
 title: Memulakan projek sumber terbuka
 description: Ketahui lebih lanjut mengenai dunia sumber terbuka dan bersiap sedia untuk melancarkan projek anda sendiri.
 class: best-practices
-toc:
-  what-does-it-mean-to-be-a-maintainer: "Apa maksudnya menjadi pemelihara?"
-  documenting-your-processes: "Mendokumentasikan proses anda"
-  learning-to-say-no: "Belajar bila untuk mengatakan tidak"
-  leverage-your-community: "Macamana manfaatkan komuniti anda"
-  bring-in-the-robots: "belajar proses mana yang perlu automatik (robots)"
-  its-okay-to-hit-pause: "Tidak apa-apa untuk berhenti sebentar"
 order: 5
 image: /assets/images/cards/best-practices.png
 related:
diff --git a/_data/locales/ms.yml b/_data/locales/ms.yml
new file mode 100644
index 00000000000..ac8316a2f6c
--- /dev/null
+++ b/_data/locales/ms.yml
@@ -0,0 +1,31 @@
+en:
+  locale_name: Malay
+  nav:
+    about: Mengenai
+    contribute: Menyumbang
+  index:
+    lead: Perisian sumber terbuka dibuat oleh orang seperti anda. Ketahui cara melancarkan dan mengembangkan projek anda.
+    opensourcefriday: Hari Jumaat! Melabur beberapa jam dengan menyumbang kepada perisian yang anda gunakan dan sukai
+  article:
+    table_of_contents: Isi kandungan
+    back_to_all_guides: Kembali ke semua panduan
+    related_guides: Panduan Berkaitan
+  footer:
+    contribute:
+      heading: Menyumbang
+      description: Ingin membuat cadangan? Kandungan ini adalah sumber terbuka. Bantu kami memperbaikinya.
+      button: Menyumbang
+    subscribe:
+      heading: Terus berhubung
+      description: Jadilah orang pertama yang mendengar mengenai petua dan sumber sumber terbuka terkini GitHub.
+      label: Alamat emel
+      button: Langgan
+    byline:
+      # [code], [love], and [github] will be replaced by octicons
+      format: "[code] dengan [love] oleh [github] dan [friends]"
+      # Label for code octicon
+      code_label: kod
+      # Label for love octicon
+      love_label: cinta
+      # Label for the contributors link
+      friends_label: rakan

From ce6f6db7c885677e99b98a6fb5591aaf34abf755 Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 04:00:34 +0800
Subject: [PATCH 047/749] removed redundant README.md file

---
 _articles/ms/README.md | 6 ------
 1 file changed, 6 deletions(-)
 delete mode 100644 _articles/ms/README.md

diff --git a/_articles/ms/README.md b/_articles/ms/README.md
deleted file mode 100644
index e409cfd0d51..00000000000
--- a/_articles/ms/README.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-lang: ms
-title: README
-description: A README file with the intention of informing the usage of this folder, which translates the english language of the original file to the language of Malay, code = ms
----
-

From f53cb84c1b6008fc3584eb6669573c01bd2335ca Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 04:37:55 +0800
Subject: [PATCH 048/749] testing fix href link issue

---
 _articles/ms/building-community.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
index 18a66960fb5..9c9caff5da3 100644
--- a/_articles/ms/building-community.md
+++ b/_articles/ms/building-community.md
@@ -197,7 +197,7 @@ Sebahagian besarnya, jika anda telah membina komuniti yang ramah, hormat dan men
 
 Apabila komuniti anda bergelut dengan masalah yang sukar, kemarahan mungkin akan meningkat. Orang mungkin menjadi marah atau kecewa dan mengeluarkannya satu sama lain, atau pada anda.
 
-Tugas anda sebagai penyelenggara adalah untuk memastikan situasi ini tidak meningkat. Walaupun anda mempunyai pendapat yang kuat mengenai topik ini, cubalah mengambil kedudukan sebagai moderator atau fasilitator, daripada melompat ke dalam pertengkaran dan mendorong pandangan anda. Sekiranya seseorang bersikap tidak baik atau memonopoli perbualan, [act immediately](../building-community/#dont-tolerate-bad-actors) agar perbincangan tetap sopan dan produktif.
+Tugas anda sebagai penyelenggara adalah untuk memastikan situasi ini tidak meningkat. Walaupun anda mempunyai pendapat yang kuat mengenai topik ini, cubalah mengambil kedudukan sebagai moderator atau fasilitator, daripada melompat ke dalam pertengkaran dan mendorong pandangan anda. Sekiranya seseorang bersikap tidak baik atau memonopoli perbualan, [bertindak segera](../building-community/#jangan-bertolak-ansur-buruk-pelakon) agar perbincangan tetap sopan dan produktif.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">

From 1ff76d07fdbca02e1912bcc75528496893fd9ba8 Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 04:50:03 +0800
Subject: [PATCH 049/749] Testing something

---
 _articles/ms/building-community.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
index 9c9caff5da3..e284c18e506 100644
--- a/_articles/ms/building-community.md
+++ b/_articles/ms/building-community.md
@@ -193,7 +193,7 @@ Oleh kerana projek anda menjadi lebih popular, lebih ramai orang akan tertarik d
 
 Sebahagian besarnya, jika anda telah membina komuniti yang ramah, hormat dan mendokumentasikan proses anda secara terbuka, komuniti anda seharusnya dapat mencari penyelesaian. Tetapi kadang-kadang anda menghadapi masalah yang agak sukar untuk ditangani.
 
-### Tetapkan bar untuk kebaikan
+### jangan-bertolak-ansur-buruk-pelakon
 
 Apabila komuniti anda bergelut dengan masalah yang sukar, kemarahan mungkin akan meningkat. Orang mungkin menjadi marah atau kecewa dan mengeluarkannya satu sama lain, atau pada anda.
 

From 76992d5ae00fd7968481ad8e91f7734b13603d91 Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 04:57:46 +0800
Subject: [PATCH 050/749] I think i figured it out

---
 _articles/ms/best-practices.md     | 2 +-
 _articles/ms/building-community.md | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md
index 658456d9997..1433cfceeca 100644
--- a/_articles/ms/best-practices.md
+++ b/_articles/ms/best-practices.md
@@ -169,7 +169,7 @@ Salah satu cara untuk mendapatkan penyumbang baru adalah dengan secara eksplisit
 
 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.
 
-Menggalakkan orang lain untuk [berkongsi pemilikan projek](../building-community/#share-ownership-of-your-project) dapat mengurangkan beban kerja anda sendiri, seperti yang dijumpai oleh @lmccart pada projeknya, [p5.js](https://github.com/processing/p5.js).
+Menggalakkan orang lain untuk [berkongsi pemilikan projek](../building-community/#berkongsi-pemilikan-projek) dapat mengurangkan beban kerja anda sendiri, seperti yang dijumpai oleh @lmccart pada projeknya, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
index e284c18e506..f166acf5d7a 100644
--- a/_articles/ms/building-community.md
+++ b/_articles/ms/building-community.md
@@ -193,11 +193,11 @@ Oleh kerana projek anda menjadi lebih popular, lebih ramai orang akan tertarik d
 
 Sebahagian besarnya, jika anda telah membina komuniti yang ramah, hormat dan mendokumentasikan proses anda secara terbuka, komuniti anda seharusnya dapat mencari penyelesaian. Tetapi kadang-kadang anda menghadapi masalah yang agak sukar untuk ditangani.
 
-### jangan-bertolak-ansur-buruk-pelakon
+### Tetapkan bar untuk kebaikan
 
 Apabila komuniti anda bergelut dengan masalah yang sukar, kemarahan mungkin akan meningkat. Orang mungkin menjadi marah atau kecewa dan mengeluarkannya satu sama lain, atau pada anda.
 
-Tugas anda sebagai penyelenggara adalah untuk memastikan situasi ini tidak meningkat. Walaupun anda mempunyai pendapat yang kuat mengenai topik ini, cubalah mengambil kedudukan sebagai moderator atau fasilitator, daripada melompat ke dalam pertengkaran dan mendorong pandangan anda. Sekiranya seseorang bersikap tidak baik atau memonopoli perbualan, [bertindak segera](../building-community/#jangan-bertolak-ansur-buruk-pelakon) agar perbincangan tetap sopan dan produktif.
+Tugas anda sebagai penyelenggara adalah untuk memastikan situasi ini tidak meningkat. Walaupun anda mempunyai pendapat yang kuat mengenai topik ini, cubalah mengambil kedudukan sebagai moderator atau fasilitator, daripada melompat ke dalam pertengkaran dan mendorong pandangan anda. Sekiranya seseorang bersikap tidak baik atau memonopoli perbualan, [bertindak segera](../building-community/#Jangan-bertolak-ansur-dengan-pelakon-jahat) agar perbincangan tetap sopan dan produktif.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">

From 8a4995da644ec87f019962a41ebc65c95a38d18f Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 05:19:30 +0800
Subject: [PATCH 051/749] fixing best-practices and building community

---
 _articles/ms/best-practices.md     |  2 +-
 _articles/ms/building-community.md | 16 ++++++++--------
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md
index 1433cfceeca..082754401f4 100644
--- a/_articles/ms/best-practices.md
+++ b/_articles/ms/best-practices.md
@@ -169,7 +169,7 @@ Salah satu cara untuk mendapatkan penyumbang baru adalah dengan secara eksplisit
 
 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.
 
-Menggalakkan orang lain untuk [berkongsi pemilikan projek](../building-community/#berkongsi-pemilikan-projek) dapat mengurangkan beban kerja anda sendiri, seperti yang dijumpai oleh @lmccart pada projeknya, [p5.js](https://github.com/processing/p5.js).
+Menggalakkan orang lain untuk [berkongsi pemilikan projek](../building-community/#kongsi-pemilikan-projek-anda) dapat mengurangkan beban kerja anda sendiri, seperti yang dijumpai oleh @lmccart pada projeknya, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
index f166acf5d7a..f3c1bf0a3a7 100644
--- a/_articles/ms/building-community.md
+++ b/_articles/ms/building-community.md
@@ -30,16 +30,16 @@ Semasa anda membina komuniti, pertimbangkan bagaimana seseorang di bahagian atas
 
 Mulakan dengan dokumentasi anda:
 
-* **Permudahkan seseorang untuk menggunakan projek anda.**[A friendly README](../starting-a-project/#writing-a-readme) dan contoh kod yang jelas akan memudahkan sesiapa sahaja yang memasuki projek anda untuk memulakan.
-* **Terangkan dengan jelas cara menyumbang**, menggunakan [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) dan mengemas kini masalah anda.
-* **Isu pertama yang baik**: Untuk membantu penyumbang baru memulakan, pertimbangkan secara jelas [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 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.
+* **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.
 
 [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.
 
 * **Apabila seseorang baru memasuki projek anda, terima kasih atas minat mereka!** Hanya memerlukan satu pengalaman negatif untuk membuat seseorang tidak mahu kembali.
 * **Bersikap responsif.** Sekiranya anda tidak menjawab masalah mereka selama sebulan, kemungkinannya, mereka sudah melupakan projek anda.
-* **Berfikiran terbuka tentang jenis sumbangan yang akan anda terima.** Banyak penyumbang bermula dengan laporan bug atau perbaikan kecil. Disana ada[many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) ke projek. Biarkan orang menolong bagaimana mereka mahu menolong.
-* **Sekiranya ada sumbangan yang anda tidak setuju,** terima kasih atas idea mereka dan [explain why](../best-practices/#learning-to-say-no) ini tidak sesuai dengan skop projek, menghubungkan ke dokumentasi yang relevan jika anda memilikinya.
+* **Berfikiran terbuka tentang jenis sumbangan yang akan anda terima.** Banyak penyumbang bermula dengan laporan bug atau perbaikan kecil. Disana ada[banyak cara untuk menyumbang](../how-to-contribute/#apa-maksudnya-menyumbang) ke projek. Biarkan orang menolong bagaimana mereka mahu menolong.
+* **Sekiranya ada sumbangan yang anda tidak setuju,** terima kasih atas idea mereka dan [terangkan mengapa](../best-practices/#belajar-bila-untuk-mengatakan-tidak) ini tidak sesuai dengan skop projek, menghubungkan ke dokumentasi yang relevan jika anda memilikinya.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -79,7 +79,7 @@ Mendokumentasikan segala-galanya juga berlaku untuk pekerjaan yang anda lakukan.
 
 ### Bersikap responsif
 
-Seperti awak[promote your project](../finding-users), orang akan mempunyai maklum balas untuk anda. Mereka mungkin mempunyai pertanyaan tentang bagaimana sesuatu berfungsi, atau memerlukan bantuan untuk memulai.
+Seperti awak[mempromosikan projek anda](../finding-users), orang akan mempunyai maklum balas untuk anda. Mereka mungkin mempunyai pertanyaan tentang bagaimana sesuatu berfungsi, atau memerlukan bantuan untuk memulai.
 
 Try responsif ketika seseorang mengajukan masalah, mengajukan permintaan tarik, atau mengajukan pertanyaan mengenai projek anda. Apabila anda bertindak balas dengan cepat, orang akan merasakan mereka adalah sebahagian daripada dialog, dan mereka akan lebih bersemangat untuk turut serta.
 
@@ -127,7 +127,7 @@ Lakukan yang terbaik untuk mengamalkan dasar toleransi sifar terhadap jenis oran
 
 Perbahasan berkala mengenai aspek sepele projek anda mengalihkan perhatian orang lain, termasuk anda, daripada memfokus pada tugas penting. Orang baru yang tiba ke projek anda mungkin melihat perbualan ini dan tidak mahu mengambil bahagian.
 
-Apabila anda melihat tingkah laku negatif berlaku pada projek anda, panggilnya secara terbuka. Jelaskan, dengan nada yang baik tetapi tegas, mengapa tingkah laku mereka tidak dapat diterima. Sekiranya masalah itu berlanjutan, anda mungkin perlu [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) boleh menjadi panduan yang membina untuk perbualan ini.
+Apabila anda melihat tingkah laku negatif berlaku pada projek anda, panggilnya secara terbuka. Jelaskan, dengan nada yang baik tetapi tegas, mengapa tingkah laku mereka tidak dapat diterima. Sekiranya masalah itu berlanjutan, anda mungkin perlu [minta mereka pergi](../code-of-conduct/#menguatkuasakan-tatakelakuan-anda). Kamu punya [tatakelakuan](../code-of-conduct/) boleh menjadi panduan yang membina untuk perbualan ini.
 
 ### Temui penyumbang di mana mereka berada
 
@@ -213,7 +213,7 @@ Menjaga kesegaran anda tidak mudah, tetapi menunjukkan kepemimpinan dapat mening
 
 ### Perlakukan README anda sebagai perlembagaan
 
-README anda adalah [more than just a set of instructions](../starting-a-project/#writing-a-readme). Ia juga merupakan tempat untuk membincangkan tujuan, visi produk, dan peta jalan anda. Sekiranya orang terlalu fokus memperdebatkan kelebihan ciri tertentu, ia mungkin dapat meninjau semula README anda dan membincangkan visi projek anda yang lebih tinggi. Memfokuskan pada README anda juga melumpuhkan perbualan, sehingga anda dapat mengadakan perbincangan yang membina.
+README anda adalah [lebih daripada sekumpulan arahan](../starting-a-project/#menulis-readme). Ia juga merupakan tempat untuk membincangkan tujuan, visi produk, dan peta jalan anda. Sekiranya orang terlalu fokus memperdebatkan kelebihan ciri tertentu, ia mungkin dapat meninjau semula README anda dan membincangkan visi projek anda yang lebih tinggi. Memfokuskan pada README anda juga melumpuhkan perbualan, sehingga anda dapat mengadakan perbincangan yang membina.
 
 ### Fokus pada perjalanan, bukan destinasi
 

From 03865ca685d69ad07fcb09af260abc8ee08c52cd Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 05:38:40 +0800
Subject: [PATCH 052/749] fixed internal links

---
 _articles/ms/building-community.md        | 2 +-
 _articles/ms/how-to-contribute.md         | 2 +-
 _articles/ms/leadership-and-governance.md | 4 ++--
 _articles/ms/legal.md                     | 6 +++---
 _articles/ms/starting-a-project.md        | 2 +-
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
index f3c1bf0a3a7..b4ff42130ba 100644
--- a/_articles/ms/building-community.md
+++ b/_articles/ms/building-community.md
@@ -197,7 +197,7 @@ Sebahagian besarnya, jika anda telah membina komuniti yang ramah, hormat dan men
 
 Apabila komuniti anda bergelut dengan masalah yang sukar, kemarahan mungkin akan meningkat. Orang mungkin menjadi marah atau kecewa dan mengeluarkannya satu sama lain, atau pada anda.
 
-Tugas anda sebagai penyelenggara adalah untuk memastikan situasi ini tidak meningkat. Walaupun anda mempunyai pendapat yang kuat mengenai topik ini, cubalah mengambil kedudukan sebagai moderator atau fasilitator, daripada melompat ke dalam pertengkaran dan mendorong pandangan anda. Sekiranya seseorang bersikap tidak baik atau memonopoli perbualan, [bertindak segera](../building-community/#Jangan-bertolak-ansur-dengan-pelakon-jahat) agar perbincangan tetap sopan dan produktif.
+Tugas anda sebagai penyelenggara adalah untuk memastikan situasi ini tidak meningkat. Walaupun anda mempunyai pendapat yang kuat mengenai topik ini, cubalah mengambil kedudukan sebagai moderator atau fasilitator, daripada melompat ke dalam pertengkaran dan mendorong pandangan anda. Sekiranya seseorang bersikap tidak baik atau memonopoli perbualan, [bertindak segera](../building-community/#jangan-bertolak-ansur-dengan-pelakon-jahat) agar perbincangan tetap sopan dan produktif.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
index 79c13e398b4..fbfe4256d46 100644
--- a/_articles/ms/how-to-contribute.md
+++ b/_articles/ms/how-to-contribute.md
@@ -506,7 +506,7 @@ Selepas anda menghantar sumbangan, salah satu perkara berikut akan berlaku:
 
 ### 😭 Anda tidak mendapat sambutan.
 
-Semoga anda[checked the project for signs of activity](#a-checklist-before-you-contribute)sebelum memberi sumbangan. Walaupun pada projek yang aktif, kemungkinan sumbangan anda tidak mendapat sambutan.
+Semoga anda[memeriksa projek untuk tanda-tanda aktiviti](#senarai-semak-sebelum-anda-menyumbang)sebelum memberi sumbangan. Walaupun pada projek yang aktif, kemungkinan sumbangan anda tidak mendapat sambutan.
 
 Sekiranya anda tidak mendapat sambutan selama lebih dari seminggu, adalah wajar untuk memberi respons dengan sopan dalam utas yang sama, meminta ulasan seseorang. Sekiranya anda mengetahui nama orang yang tepat untuk mengulas sumbangan anda, anda boleh @ -menyebutkannya dalam utas itu.
 
diff --git a/_articles/ms/leadership-and-governance.md b/_articles/ms/leadership-and-governance.md
index 971aa801001..5b5ab1fb9a5 100644
--- a/_articles/ms/leadership-and-governance.md
+++ b/_articles/ms/leadership-and-governance.md
@@ -49,7 +49,7 @@ Penyelenggara tidak semestinya menjadi seseorang yang menulis kod untuk projek a
 
 **Istilah "committer"** mungkin digunakan untuk membezakan akses komit, yang merupakan jenis tanggungjawab tertentu, dari bentuk sumbangan lain.
 
-Walaupun anda dapat menentukan peranan projek anda dengan cara yang anda mahukan, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) untuk mendorong lebih banyak bentuk sumbangan. Anda boleh menggunakan peranan kepemimpinan untuk mengenali secara rasmi orang yang telah memberikan sumbangan yang luar biasa untuk projek anda, tanpa mengira kemahiran teknikal mereka.
+Walaupun anda dapat menentukan peranan projek anda dengan cara yang anda mahukan, [pertimbangkan untuk menggunakan definisi yang lebih luas](../how-to-contribute/#apa-maksudnya-menyumbang) untuk mendorong lebih banyak bentuk sumbangan. Anda boleh menggunakan peranan kepemimpinan untuk mengenali secara rasmi orang yang telah memberikan sumbangan yang luar biasa untuk projek anda, tanpa mengira kemahiran teknikal mereka.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
@@ -82,7 +82,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 [shared ownership](../building-community/#share-ownership-of-your-project).
+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).
 
 ## Bilakah saya harus memberikan akses kepada seseorang?
 
diff --git a/_articles/ms/legal.md b/_articles/ms/legal.md
index d3e6e3f49ea..6ac6d8a0a2a 100644
--- a/_articles/ms/legal.md
+++ b/_articles/ms/legal.md
@@ -76,7 +76,7 @@ Anda mungkin juga ingin mempertimbangkan **komuniti** yang anda harap akan mengg
 * **Adakah anda mahu projek anda menarik minat perniagaan besar?** Perniagaan besar kemungkinan akan memerlukan lesen paten ekspres dari semua penyumbang. Dalam kes ini, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)adakah anda (dan mereka) dilindungi.
 * **Adakah anda mahu projek anda menarik minat penyumbang yang tidak mahu sumbangan mereka digunakan dalam perisian sumber tertutup?**[GPLv3](https://choosealicense.com/licenses/gpl-3.0/) atau (jika mereka juga tidak mahu menyumbang kepada perkhidmatan sumber tertutup) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/)akan berjalan lancar.
 
-**Syarikat** anda mungkin mempunyai syarat pelesenan khusus untuk projek sumber terbuka. Sebagai contoh, ia mungkin memerlukan lesen yang boleh diterima agar syarikat dapat menggunakan projek anda dalam produk sumber tertutup syarikat. Atau syarikat anda mungkin memerlukan lesen copyleft yang kuat dan perjanjian penyumbang tambahan (lihat di bawah) sehingga hanya syarikat anda, dan tidak ada orang lain, yang dapat menggunakan projek anda dalam perisian sumber tertutup. Atau syarikat anda mungkin mempunyai keperluan tertentu yang berkaitan dengan standard, tanggungjawab sosial, atau ketelusan, yang mana mungkin memerlukan strategi pelesenan tertentu. Bercakap dengan anda[company's legal department](#what-does-my-companys-legal-team-need-to-know).
+**Syarikat** anda mungkin mempunyai syarat pelesenan khusus untuk projek sumber terbuka. Sebagai contoh, ia mungkin memerlukan lesen yang boleh diterima agar syarikat dapat menggunakan projek anda dalam produk sumber tertutup syarikat. Atau syarikat anda mungkin memerlukan lesen copyleft yang kuat dan perjanjian penyumbang tambahan (lihat di bawah) sehingga hanya syarikat anda, dan tidak ada orang lain, yang dapat menggunakan projek anda dalam perisian sumber tertutup. Atau syarikat anda mungkin mempunyai keperluan tertentu yang berkaitan dengan standard, tanggungjawab sosial, atau ketelusan, yang mana mungkin memerlukan strategi pelesenan tertentu. Bercakap dengan anda[jabatan undang-undang syarikat](#apa-yang-perlu-diketahui-oleh-pasukan-undang-undang-syarikat-saya).
 
 Apabila anda membuat projek baru di GitHub, anda diberi pilihan untuk memilih lesen. Menyertakan salah satu lesen yang disebutkan di atas akan menjadikan projek GitHub anda sebagai sumber terbuka. Sekiranya anda ingin melihat pilihan lain, periksa [choosealicense.com](https://choosealicense.com) untuk mencari lesen yang sesuai untuk projek anda, walaupun ia [isn't software](https://choosealicense.com/non-software/).
 
@@ -134,7 +134,7 @@ Untuk lebih baik atau lebih buruk, pertimbangkan untuk memberitahu mereka walaup
 
 * **Paten:** Adakah syarikat anda memohon paten yang merupakan sumber terbuka projek anda [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Malangnya, anda mungkin diminta untuk menunggu (atau mungkin syarikat akan mempertimbangkan semula kebijaksanaan permohonan). Sekiranya anda mengharapkan sumbangan untuk projek anda dari pekerja syarikat dengan portfolio paten yang besar, pasukan undang-undang anda mungkin mahu anda menggunakan lesen dengan pemberian paten ekspres dari penyumbang (seperti Apache 2.0 atau GPLv3), atau perjanjian penyumbang tambahan ( lihat di atas).
 
-* **Tanda Dagangan:** Periksa semula nama projek anda[does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). Sekiranya anda menggunakan tanda dagangan syarikat anda sendiri dalam projek, periksa bahawa ia tidak menimbulkan konflik. [FOSSmarks](http://fossmarks.org/)adalah panduan praktikal untuk memahami tanda dagangan dalam konteks projek sumber bebas dan terbuka.
+* **Tanda Dagangan:** Periksa semula nama projek anda[tidak bertentangan dengan tanda dagangan yang ada](../starting-a-project/#mengelakkan-konflik-nama). Sekiranya anda menggunakan tanda dagangan syarikat anda sendiri dalam projek, periksa bahawa ia tidak menimbulkan konflik. [FOSSmarks](http://fossmarks.org/)adalah panduan praktikal untuk memahami tanda dagangan dalam konteks projek sumber bebas dan terbuka.
 
 * **Privasi:** Adakah projek anda mengumpulkan data pengguna? "Telefon rumah" ke pelayan syarikat? Pasukan undang-undang anda dapat membantu anda mematuhi dasar syarikat dan peraturan luaran.
 
@@ -163,4 +163,4 @@ Jangka panjang, pasukan undang-undang anda boleh melakukan lebih banyak perkara
 </aside>
 
 * **Paten:** Syarikat anda mungkin ingin bergabung dengan[Open Invention Network](https://www.openinventionnetwork.com/), kumpulan paten pertahanan bersama untuk melindungi penggunaan projek sumber terbuka utama anggota, atau meneroka yang lain[alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
-* **Tadbir urus:** Terutama jika dan bila masuk akal untuk memindahkan projek ke [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
+* **Tadbir urus:** Terutama jika dan bila masuk akal untuk memindahkan projek ke [entiti undang-undang di luar syarikat](../leadership-and-governance/#adakah-saya-memerlukan-entiti-undang-undang-untuk-menyokong-projek-saya).
diff --git a/_articles/ms/starting-a-project.md b/_articles/ms/starting-a-project.md
index f5779160837..c501437da9b 100644
--- a/_articles/ms/starting-a-project.md
+++ b/_articles/ms/starting-a-project.md
@@ -26,7 +26,7 @@ Apabila projek adalah sumber terbuka, itu bermaksud **siapa sahaja bebas menggun
 
 Sumber terbuka sangat kuat kerana ia dapat mengurangkan halangan untuk menerima pakai dan berkolaborasi, memungkinkan orang menyebarkan dan memperbaiki projek dengan cepat. Juga kerana memberi pengguna potensi untuk mengendalikan pengkomputeran mereka sendiri, berbanding dengan sumber tertutup. Sebagai contoh, perniagaan yang menggunakan perisian sumber terbuka mempunyai pilihan untuk mengupah seseorang untuk membuat penambahbaikan khusus pada perisian, daripada hanya bergantung pada keputusan produk penjual sumber tertutup.
 
-_Perisian percuma_ merujuk kepada set projek yang sama dengan _open source_. Kadang-kadang anda juga akan melihat[these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) digabungkan sebagai "perisian sumber bebas dan terbuka" (FOSS) atau "perisian bebas, bebas, dan sumber terbuka" (FLOSS). _Free_ dan _libre_ merujuk kepada kebebasan,[not price](#does-open-source-mean-free-of-charge).
+_Perisian percuma_ merujuk kepada set projek yang sama dengan _open source_. Kadang-kadang anda juga akan melihat[these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) digabungkan sebagai "perisian sumber bebas dan terbuka" (FOSS) atau "perisian bebas, bebas, dan sumber terbuka" (FLOSS). _Free_ dan _libre_ merujuk kepada kebebasan,[bukan harga](#adakah-sumber-terbuka-bermaksud-percuma).
 
 ### Mengapa orang membuka sumber pekerjaan mereka?
 

From dcfcb0b3bfe965e603e401301a4233a3632da658 Mon Sep 17 00:00:00 2001
From: Mike Linksvayer <mlinksva@github.com>
Date: Sun, 9 Aug 2020 16:34:05 -0700
Subject: [PATCH 053/749] format

---
 _articles/ms/how-to-contribute.md | 10 +++++-----
 _data/locales/ms.yml              |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
index fbfe4256d46..55cd3025be8 100644
--- a/_articles/ms/how-to-contribute.md
+++ b/_articles/ms/how-to-contribute.md
@@ -80,11 +80,11 @@ Kesalahpahaman umum mengenai menyumbang kepada sumber terbuka ialah anda perlu m
 Walaupun anda suka menulis kod, jenis sumbangan lain adalah kaedah terbaik untuk terlibat dengan projek dan bertemu dengan ahli komuniti lain. Membina hubungan tersebut akan memberi anda peluang untuk bekerja di bahagian lain projek.
 
 <aside markdown="1" class="pquote">
-    <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-      Saya pertama kali menghubungi pasukan pengembangan Python (aka python-dev) ketika saya menghantar e-mel kepada senarai mel pada 17 Jun 2002 mengenai penerimaan tampalan saya. Saya dengan cepat menangkap bug sumber terbuka, dan memutuskan untuk mula menguruskan pencernaan e-mel untuk kumpulan itu. Mereka memberi saya alasan yang baik untuk meminta penjelasan mengenai sesuatu topik, tetapi lebih kritikal saya dapat melihat ketika seseorang menunjukkan sesuatu yang perlu diperbaiki.
-    <p markdown="1" class="pquote-credit">
-      — @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-    </p>
+  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
+  Saya pertama kali menghubungi pasukan pengembangan Python (aka python-dev) ketika saya menghantar e-mel kepada senarai mel pada 17 Jun 2002 mengenai penerimaan tampalan saya. Saya dengan cepat menangkap bug sumber terbuka, dan memutuskan untuk mula menguruskan pencernaan e-mel untuk kumpulan itu. Mereka memberi saya alasan yang baik untuk meminta penjelasan mengenai sesuatu topik, tetapi lebih kritikal saya dapat melihat ketika seseorang menunjukkan sesuatu yang perlu diperbaiki.
+  <p markdown="1" class="pquote-credit">
+— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
+  </p>
 </aside>
 
 ### Adakah anda suka merancang acara?
diff --git a/_data/locales/ms.yml b/_data/locales/ms.yml
index ac8316a2f6c..b904a445625 100644
--- a/_data/locales/ms.yml
+++ b/_data/locales/ms.yml
@@ -1,4 +1,4 @@
-en:
+ms:
   locale_name: Malay
   nav:
     about: Mengenai

From fba71a138b0b2ef3a3adaef0ce035183d13b80e5 Mon Sep 17 00:00:00 2001
From: KaynenStrife <KaynenLeong@gmail.com>
Date: Mon, 10 Aug 2020 08:09:55 +0800
Subject: [PATCH 054/749] filled in missing translations in building-community
 and metrics

---
 _articles/ms/building-community.md | 6 +++---
 _articles/ms/metrics.md            | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
index b4ff42130ba..649d8addb41 100644
--- a/_articles/ms/building-community.md
+++ b/_articles/ms/building-community.md
@@ -165,11 +165,11 @@ Lihat apakah anda boleh mencari cara untuk berkongsi pemilikan dengan komuniti a
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Mulakan fail CONTRIBUTORS atau AUTHORS dalam projek anda** yang menyenaraikan semua orang yang menyumbang untuk projek anda, seperti [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
+* **Mulakan fail CONTRIBUTORS atau AUTHORS dalam projek anda** yang menyenaraikan semua orang yang menyumbang untuk projek anda, seperti [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md)
 
-* Sekiranya anda mempunyai komuniti yang cukup besar, **menghantar surat berita atau menulis catatan blog** mengucapkan terima kasih kepada penyumbang. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) adalah dua contoh yang baik.
+* Sekiranya anda mempunyai komuniti yang cukup besar, **menghantar surat berita atau menulis catatan blog** mengucapkan terima kasih kepada penyumbang. Penyumbang Rust [This Week in Rust](https://this-week-in-rust.org/) dan penyumbang Hoodie [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) adalah dua contoh yang baik.
 
-* **Berikan akses kepada setiap penyumbang.** @felixge mendapati bahawa ini menjadikan orang[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.
+* **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.
 
diff --git a/_articles/ms/metrics.md b/_articles/ms/metrics.md
index d11e3988913..192aa8441cb 100644
--- a/_articles/ms/metrics.md
+++ b/_articles/ms/metrics.md
@@ -65,11 +65,11 @@ Sekiranya anda menggunakan pengurus pakej, seperti npm atau RubyGems.org, untuk
 
 Setiap pengurus pakej boleh menggunakan definisi "download" yang sedikit berbeza, dan muat turuntuk mengesan statistik penggunaan di banyak pengurus pakej yang popular.
 
-Sekiranya projek anda berada di GitHub, arahkan kembali ke halaman "Traffic". Anda boleh menggunakanun tidak semestinya berkaitan dengan pemasangan atau penggunaan, tetapi menyediakan beberapa asas untuk perbandingan. Cuba gunakan [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+Sekiranya projek anda berada di GitHub, arahkan kembali ke halaman "Traffic". Anda boleh menggunakanun tidak semestinya berkaitan dengan pemasangan atau penggunaan, tetapi menyediakan beberapa asas untuk perbandingan. Cuba gunakan [Libraries.io](https://libraries.io/) untuk mengesan statistik penggunaan di banyak pengurus pakej yang popular.
 
-If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+Sekiranya projek anda berada di GitHub, arahkan kembali ke halaman "Traffic". Anda boleh menggunakan[graf klon](https://github.com/blog/1873-clone-graphs) untuk melihat berapa kali projek anda diklon pada hari tertentu, dipecah berdasarkan jumlah klon dan klon unik.
 
-![Clone graph](/assets/images/metrics/clone_graph.png)
+![graf klon](/assets/images/metrics/clone_graph.png)
 
 Sekiranya penggunaannya rendah berbanding dengan jumlah orang yang menemui projek anda, ada dua masalah yang perlu dipertimbangkan. Sama ada:
 

From f8fd82229422d4545a8f428d1aac94141a6ddf53 Mon Sep 17 00:00:00 2001
From: Kyoungae Kim <kyoungae.kim@lge.com>
Date: Fri, 14 Aug 2020 18:22:31 +0900
Subject: [PATCH 055/749] Update legal.md

Clarify the meaning
---
 _articles/ko/legal.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index 159ee742d76..aca341aa5cc 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -12,17 +12,17 @@ related:
 
 ## Understanding the legal implications of open source
 
-세계와 창의적인 작업을 공유하는 것은 흥미롭고 보람있는 경험이 될 수 있습니다. 그것은 또한 당신이 모른다고 걱정해야한다는 것을 합법적이라는 걸로 의미 할 수 있습니다. 고맙게도 처음부터 다시 시작할 필요는 없습니다. 귀하의 법적 요구 사항이 있습니다. (이 내용을 파기전에, [면책조항](/notices/)을 읽으십시오.)
+세계와 창의적인 작업을 공유하는 것은 흥미롭고 보람있는 경험이 될 수 있습니다. 그것은 또한 당신이 걱정해야 했지만 잘 몰랐던 여러 법적 문제를 의미할 수도 있습니다. 고맙게도 처음부터 다시 시작할 필요는 없습니다. 귀하의 법적 요구 사항이 있습니다. (이 내용을 파기전에, [면책조항](/notices/)을 읽으십시오.)
 
 ## Why do people care so much about the legal side of open source?
 
-물어봤다는건 다행입니다! 창의적인 작업(작성, 그래픽 또는 코드)을 할 때, 그 저작물은 기본적으로 독점적인 저작권하에 있습니다. 즉, 법은 귀하의 저작물의 작성자로서 다른 사람들이 할 수 있는 것에 대해 귀하가 말하고있는 것으로 간주합니다.
+물어봤다는건 다행입니다! 창의적인 작업(작성, 그래픽 또는 코드)을 할 때, 그 저작물은 기본적으로 독점적인 저작권하에 있습니다. 즉, 법은 귀하를 저작물의 작성자로서 다른 사람들이 할 수 있는 것에 대해 귀하가 말하고있는 것으로 간주합니다.
 
-일반적으로, 이는 타인이 인계, 훼손 또는 소송의 위험이 없이 작업을 사용, 복사, 배포 또는 수정할 수 있음을 의미합니다.
+일반적으로, 이는 타인이 인계, 훼손 또는 소송의 위험이 없이 작업을 사용, 복사, 배포 또는 수정할 수 없음을 의미합니다.
 
 그러나 오픈소스는 다른 사람들이 작업을 사용, 수정 및 공유하기를 기대하기 때문에 드문 경우입니다. 그러나 법적 기본값은 독점적인 저작권이므로 명시적으로 이러한 사용 권한을 명시한 사용권이 필요합니다.
 
-오픈소스 라이선스를 신청하지 않으면, 프로젝트에 기여한 모든 사람도 자신의 저작물의 독점적인 저작권자가 됩니다. 즉, 아무도 자신의 기여를 사용, 복사, 배포 또는 수정할 수 없으며 "아무도"에서는 귀하를 포함하지 않는다는 의미입니다.
+오픈소스 라이선스를 적용하지 않으면, 프로젝트에 기여한 모든 사람도 자신의 저작물의 독점적인 저작권자가 됩니다. 즉, 아무도 자신의 기여를 사용, 복사, 배포 또는 수정할 수 없으며 "아무도"에서는 귀하를 포함하지 않는다는 의미입니다.
 
 마지막으로, 프로젝트는 사용자가 알지 못하는 라이선스 요구 사항과의 종속성을 가질 수 있습니다. 프로젝트의 커뮤니티 또는 고용주의 정책에 따라 프로젝트에서 특정 오픈소스 라이선스를 사용해야 할 수도 있습니다. 아래에서 이러한 상황을 다룰 것입니다.
 
@@ -32,9 +32,9 @@ related:
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**GitHub 프로젝트를 공개하는 것은 프로젝트 라이센싱과 동일하지 않습니다.** 공개 프로젝트는 [GitHub의 서비스 약관](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)에 명시되어 있으며, 다른 사람들이 프로젝트를 포크화할 수는 있지만, 그렇지 않은 경우에는 권한이 없습니다.
+**GitHub 프로젝트를 공개하는 것은 프로젝트 라이센싱과 동일하지 않습니다.** 공개 프로젝트는 [GitHub의 서비스 약관](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)에 명시되어 있으며, 다른 사람들이 프로젝트를 보거나 포크할 수는 있지만, 다른 권한은 없습니다.
 
-다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게하려면, 오픈소스 라이선스를 포함해야합니다. 예를 들어, 권한을 부여하지 않는다는 조건에서는 공개적으로 GitHub 프로젝트의 일부를 코드에 명시적으로 사용할 수는 없습니다.
+다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게하려면, 오픈소스 라이선스를 포함해야합니다. 예를 들어, Github 프로젝트가 공개되어 있다 하더라도 명시적으로 권한을 부여하지 않는다면, 그 코드의 어느 부분도 사용할 수 없습니다. 
 
 ## Just give me the TL;DR on what I need to protect my project.
 
@@ -54,9 +54,9 @@ GitHub에서 새로운 프로젝트를 만들 때, [라이선스를 추가할 
 
 ## Which open source license is appropriate for my project?
 
-빈 슬레이트에서 시작한다면, [MIT 라이선스](https://choosealicense.com/licenses/mit/)를 잘못 읽는 것은 어렵습니다. 짧고 이해하기 쉽기 때문에 저작권 고지를 포함하여 라이선스 사본을 보관하는 한 누구나 아무 것도 할 수 없습니다. 필요한 경우 다른 라이선스로 프로젝트를 릴리스 할 수 있습니다.
+빈 슬레이트에서 시작한다면, [MIT 라이선스](https://choosealicense.com/licenses/mit/)를 잘못 읽는 것은 어렵습니다. MIT 라이선스는 짧고 이해하기 쉬우며, 저작권 고지를 포함하여 라이선스 사본을 보관하는 한 누구나 모든 것을 할 수 있도록 허락합니다.필요한 경우 다른 라이선스로 프로젝트를 릴리스 할 수 있습니다.
 
-그렇지 않으면 프로젝트에 적합한 오픈소스 라이선스를 선택하는 것이 목표에 달려 있습니다.
+그렇지 않으면 프로젝트에 적합한 오픈소스 라이선스를 선택하는 것이 목적에 달려 있습니다.
 
 프로젝트에 **의존성**이 있을 가능성이 큽니다. 예를 들어, Node.js 프로젝트를 오픈소스로 사용하는 경우 노드 패키지 관리자(npm)의 라이브러리를 사용할 수 있습니다. 의존하는 각 라이브러리에는 자체 오픈소스 라이선스가 있습니다. 각 라이선스가 "허용"(다운스트림 라이선스의 조건없이 공용 사용, 수정 및 공유할 수 있는 권한 부여)되어 있으면, 원하는 라이선스를 사용할 수 있습니다. 일반적인 허용 라이선스에는 MIT, Apache 2.0, ISC 및 BSD가 포함됩니다.
 

From 95631a1c3bbabed4a8311434ea3e397d4f6f8b0b Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Wed, 19 Aug 2020 13:48:43 +0100
Subject: [PATCH 056/749] CODEOWNERS: add team

Automatically request the relevant GitHub team for code review.
---
 CODEOWNERS | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 CODEOWNERS

diff --git a/CODEOWNERS b/CODEOWNERS
new file mode 100644
index 00000000000..c9bee33f7c7
--- /dev/null
+++ b/CODEOWNERS
@@ -0,0 +1 @@
+*  @github/communities-heart-reviewers

From 98b9c90b984afa8f2fea31131c5c1c3c73f6636e Mon Sep 17 00:00:00 2001
From: Wesley De Groot <email@wesleydegroot.nl>
Date: Mon, 24 Aug 2020 17:15:22 +0200
Subject: [PATCH 057/749] Create nl.yml

Create the first steps for the dutch translation
---
 _data/locales/nl.yml | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 _data/locales/nl.yml

diff --git a/_data/locales/nl.yml b/_data/locales/nl.yml
new file mode 100644
index 00000000000..b47af74e9df
--- /dev/null
+++ b/_data/locales/nl.yml
@@ -0,0 +1,31 @@
+nl:
+  locale_name: Nederlands
+  nav:
+    about: Over
+    contribute: Bijdragen
+  index:
+    lead: Open source software wordt gemaakt door mensen zoals jij. Leer hoe u uw project start en laat groeien.
+    opensourcefriday: Het is vrijdag! Investeer een paar uur om bij te dragen aan de software die u gebruikt en waar u van houdt
+  article:
+    table_of_contents: Inhoudsopgave
+    back_to_all_guides: Terug naar het overzicht
+    related_guides: Gerelateerde gidsen
+  footer:
+    contribute:
+      heading: Bijdragen
+      description: Wilt u een suggestie doen? Deze inhoud is open source. Help ons het te verbeteren.
+      button: Bijdragen
+    subscribe:
+      heading: Blijf op de hoogte
+      description: Wees de eerste die hoort over de nieuwste open source-tips en middellen van GitHub.
+      label: Email adres
+      button: Abonneren
+    byline:
+      # [code], [love], and [github] will be replaced by octicons
+      format: "[code] met [love] van [github] en [friends]"
+      # Label for code octicon
+      code_label: code
+      # Label for love octicon
+      love_label: love
+      # Label for the contributors link
+      friends_label: friends

From 2611749a0e91da4cc3ed1659e6bd6d550d95fb75 Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Mon, 24 Aug 2020 20:44:23 +0200
Subject: [PATCH 058/749] Created /nl/

---
 _articles/nl/best-practices.md            | 287 ++++++++++++
 _articles/nl/building-community.md        | 280 +++++++++++
 _articles/nl/code-of-conduct.md           | 120 +++++
 _articles/nl/finding-users.md             | 163 +++++++
 _articles/nl/getting-paid.md              | 191 ++++++++
 _articles/nl/how-to-contribute.md         | 535 ++++++++++++++++++++++
 _articles/nl/leadership-and-governance.md | 165 +++++++
 _articles/nl/legal.md                     | 166 +++++++
 _articles/nl/metrics.md                   | 132 ++++++
 _articles/nl/starting-a-project.md        | 362 +++++++++++++++
 10 files changed, 2401 insertions(+)
 create mode 100644 _articles/nl/best-practices.md
 create mode 100644 _articles/nl/building-community.md
 create mode 100644 _articles/nl/code-of-conduct.md
 create mode 100644 _articles/nl/finding-users.md
 create mode 100644 _articles/nl/getting-paid.md
 create mode 100644 _articles/nl/how-to-contribute.md
 create mode 100644 _articles/nl/leadership-and-governance.md
 create mode 100644 _articles/nl/legal.md
 create mode 100644 _articles/nl/metrics.md
 create mode 100644 _articles/nl/starting-a-project.md

diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
new file mode 100644
index 00000000000..a6ab4e409e3
--- /dev/null
+++ b/_articles/nl/best-practices.md
@@ -0,0 +1,287 @@
+---
+lang: nl
+title: Best Practices for Maintainers
+description: Making your life easier as an open source maintainer, from documenting processes to leveraging your community.
+class: best-practices
+toc:
+  what-does-it-mean-to-be-a-maintainer: "What does it mean to be a maintainer?"
+  documenting-your-processes: "Documenting your processes"
+  learning-to-say-no: "Learning to say no"
+  leverage-your-community: "Leverage your community"
+  bring-in-the-robots: "Bring in the robots"
+  its-okay-to-hit-pause: "It’s okay to hit pause"
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+  - metrics
+  - leadership
+---
+
+## What does it mean to be a maintainer?
+
+If you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more.
+
+In the early stages of a project, you're experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you'll find yourself working with your users and contributors more.
+
+Maintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community.
+
+## Documenting your processes
+
+Writing things down is one of the most important things you can do as a maintainer.
+
+Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask.
+
+Writing things down makes it easier to say no when something doesn't fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project.
+
+Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all.
+
+Remember to keep your documentation up-to-date. If you're not able to always do this, delete your outdated documentation or indicate it is outdated so contributors know updates are welcome.
+
+### Write down your project's vision
+
+Start by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well.
+
+Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions.
+
+For example, @lord discovered that having a project vision helped him figure out which requests to spend time on. As a new maintainer, he regretted not sticking to his project's scope when he got his first feature request for [Slate](https://github.com/lord/slate).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
+  I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of an half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
+  <p markdown="1" class="pquote-credit">
+— @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
+  </p>
+</aside>
+
+### Communicate your expectations
+
+Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun.
+
+Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do.
+
+Most people who come across your project don't know anything about you or your circumstances. They may assume you get paid to work on it, especially if it's something they regularly use and depend on. Maybe at one point you put a lot of time into your project, but now you're busy with a new job or family member.
+
+All of this is perfectly okay! Just make sure other people know about it.
+
+If maintaining your project is part-time or purely volunteered, be honest about how much time you have. This is not the same as how much time you think the project requires, or how much time others want you to spend.
+
+Here are a few rules that are worth writing down:
+
+* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_)
+* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_)
+* When it's appropriate to follow up (_for example, "You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread."_)
+* How much time you spend on the project (_for example, "We only spend about 5 hours per week on this project"_)
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors.
+
+### Keep communication public
+
+Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker.
+
+If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes.
+
+That way, anybody who joins your community will have access to the same information as someone who's been there for years.
+
+## Learning to say no
+
+You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists.
+
+Having everything written down, however, helps depersonalize situations when you do need to enforce your rules.
+
+Saying no isn't fun, but  _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_.
+
+Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others.
+
+### Keep the conversation friendly
+
+One of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept.
+
+Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor.
+
+Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards.
+
+If you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
+  The key to handle support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS.
+  <p markdown="1" class="pquote-credit">
+— @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
+  </p>
+</aside>
+
+Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.
+
+It's better to immediately close the contributions you know you don't want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+
+Secondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it's someone's first time. Even if you don't accept their contribution, acknowledge the person behind it and thank them for their interest. It's a big compliment!
+
+If you don't want to accept a contribution:
+
+* **Thank them** for their contribution
+* **Explain why it doesn't fit** into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm.
+* **Link to relevant documentation**, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself.
+* **Close the request**
+
+You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):
+
+![Celery screenshot](/assets/images/best-practices/celery.png)
+
+If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want.
+
+Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it.
+
+Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise.
+
+### Be proactive
+
+To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide.
+
+If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example:
+
+* Fill out a issue or PR template/checklist
+* Open an issue before submitting a PR
+
+If they don't follow your rules, close the issue immediately and point to your documentation.
+
+While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+  Ideally, explain to them and in a CONTRIBUTING.md file how they can get a better indication in the future on what would or would not be accepted before they begin the work.
+  <p markdown="1" class="pquote-credit">
+— @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
+  </p>
+</aside>
+
+Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively.
+
+### Embrace mentorship
+
+Maybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections.
+
+If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first issue,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them.
+
+## Leverage your community
+
+You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work.
+
+### Share the workload
+
+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.
+
+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.
+
+Encouraging others to [share ownership of the project](../building-community/#share-ownership-of-your-project) can greatly reduce your own workload, as @lmccart discovered on her project, [p5.js](https://github.com/processing/p5.js).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
+  I’d been saying, "Yeah, anyone can be involved, you don’t have to have a lot of coding expertise [...]." We had people sign up to come [to an event] and that’s when I was really wondering: is this true, what I’ve been saying? There are gonna be 40 people who show up, and it’s not like I can sit with each of them...But people came together, and it just sort of worked. As soon as one person got it, they could teach their neighbor.
+  <p markdown="1" class="pquote-credit">
+—  @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+  </p>
+</aside>
+
+If you need to step away from your project, either on hiatus or permanently, there's no shame in asking someone else to take over for you.
+
+If other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It's great that so many people want your project to live on!
+
+@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), helped those goals live on even after he stepped away from the project:
+
+> I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down.
+
+### Let others build the solutions they need
+
+If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork.
+
+Forking a project doesn't have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project's vision.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
+  I cater to the 80% use case. If you are one of the unicorns, please fork my work. I won't get offended! My public projects are almost always meant to solve the most common problems; I try to make it easy to go deeper by either forking my work or extending it.
+  <p markdown="1" class="pquote-credit">
+— @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+  </p>
+</aside>
+
+The same applies to a user who really wants a solution that you simply don't have the bandwidth to build. Offering APIs and customization hooks can help others meet their own needs, without having to modify the source directly. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) encouraging plugins for CocoaPods led to "some of the most interesting ideas":
+
+> It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying "no", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform.
+
+## Bring in the robots
+
+Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier.
+
+### Require tests and other checks to improve the quality of your code
+
+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.
+
+If you add tests, make sure to explain how they work in your CONTRIBUTING file.
+
+<aside markdown="1" class="pquote">
+  <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)
+  </p>
+</aside>
+
+### Use tools to automate basic maintenance tasks
+
+The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for it.
+
+There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases
+* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
+* [Danger](https://github.com/danger/danger) helps automate code review
+* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information
+* [dependabot-preview](https://github.com/marketplace/dependabot-preview) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
+
+For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.
+
+To manage your email notifications, you can set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize by priority.
+
+If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept.
+
+However, if your standards are too complicated, they can increase the barriers to contribution. Make sure you're only adding enough rules to make everyone's lives easier.
+
+If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors.
+
+## It's okay to hit pause
+
+Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty.
+
+Perhaps you're feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up.
+
+Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project.
+
+Although it should go without saying, take a break! You shouldn't have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take [a month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) after 14 years of volunteer OSS work.
+
+Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
+  In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
+  <p markdown="1" class="pquote-credit">
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+  </p>
+</aside>
+
+Sometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away.
+
+Do your best to find support for your users and community while you're away from a project. If you can't find the support you need, take a break anyway. Be sure to communicate when you're not available, so people aren't confused by your lack of responsiveness.
+
+Taking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you.
+
+## Take care of yourself first!
+
+Maintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive.
diff --git a/_articles/nl/building-community.md b/_articles/nl/building-community.md
new file mode 100644
index 00000000000..73e5cba0ffb
--- /dev/null
+++ b/_articles/nl/building-community.md
@@ -0,0 +1,280 @@
+---
+lang: nl
+title: Building Welcoming Communities
+description: Building a community that encourages people to use, contribute to, and evangelize your project.
+class: building
+toc:
+  setting-your-project-up-for-success: "Setting your project up for success"
+  growing-your-community: "Growing your community"
+  resolving-conflicts: "Resolving conflicts"
+order: 4
+image: /assets/images/cards/building.png
+related:
+  - best-practices
+  - coc
+---
+
+## Setting your project up for success
+
+You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around?
+
+A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back.
+
+### Make people feel welcome
+
+One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+
+As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more.
+
+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.
+
+[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.
+
+* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
+* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
+* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
+* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+  </p>
+</aside>
+
+The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute.
+
+Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself.
+
+### Document everything
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
+  <p markdown="1" class="pquote-credit">
+— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public.
+
+When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed.
+
+Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public.
+
+Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions.
+
+If you notice multiple users running into the same problem, document the answers in the README.
+
+For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you.
+
+Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on.
+
+### Be responsive
+
+As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started.
+
+Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating.
+
+Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466):
+
+![Middleman pull request](/assets/images/building-community/middleman_pr.png)
+
+[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution.
+
+Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project.
+
+### Give your community a place to congregate
+
+There are two reasons to give your community a place to congregate.
+
+The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate.
+
+The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel.
+
+Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above!
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members:
+
+> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.
+
+Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address.
+
+## Growing your community
+
+Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction.
+
+### Don't tolerate bad actors
+
+Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others.
+
+Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
+  The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.
+  <p markdown="1" class="pquote-credit">
+— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+  </p>
+</aside>
+
+Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
+
+When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations.
+
+### Meet contributors where they're at
+
+Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need.
+
+In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors.
+
+![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
+
+In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started.
+
+Finally, use your documentation to make people feel welcome at every step of the way.
+
+You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration.
+
+For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
+
+### Share ownership of your project
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
+  Your leaders will have different opinions, as all healthy communities should! However, you need to take steps to ensure the loudest voice doesn't always win by tiring people out, and that less prominent and minority voices are heard.
+  <p markdown="1" class="pquote-credit">
+— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+  </p>
+</aside>
+
+People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around.
+
+See if you can find ways to share ownership with your community as much as possible. Here are some ideas:
+
+* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself.
+
+![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
+
+* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
+
+* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+
+* **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.
+
+The reality is that [most projects only have](https://peerj.com/preprints/1233.pdf) 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.
+
+While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
+  \[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it.
+  <p markdown="1" class="pquote-credit">
+— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+  </p>
+</aside>
+
+## Resolving conflicts
+
+In the early stages of your project, making major decisions is easy. When you want to do something, you just do it.
+
+As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own.
+
+For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address.
+
+### Set the bar for kindness
+
+When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you.
+
+Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
+  As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
+  <p markdown="1" class="pquote-credit">
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+  </p>
+</aside>
+
+Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly.
+
+Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you.
+
+### Treat your README as a constitution
+
+Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion.
+
+### Focus on the journey, not the destination
+
+Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns.
+
+Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place.
+
+Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus.
+
+Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
+  Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
+  <p markdown="1" class="pquote-credit">
+— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+  </p>
+</aside>
+
+Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions.
+
+Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution.
+
+### Keep the conversation focused on action
+
+Discussion is important, but there is a difference between productive and unproductive conversations.
+
+Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down.
+
+Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues.
+
+With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_
+
+If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation.
+
+If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+  </p>
+</aside>
+
+### Pick your battles wisely
+
+Context is important. Consider who is involved in the discussion and how they represent the rest of the community.
+
+Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices.
+
+If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread.
+
+### Identify a community tiebreaker
+
+With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker.
+
+A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it.
+
+Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible.
+
+## Community is the ❤️ of open source
+
+Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience.
diff --git a/_articles/nl/code-of-conduct.md b/_articles/nl/code-of-conduct.md
new file mode 100644
index 00000000000..e70bd41632e
--- /dev/null
+++ b/_articles/nl/code-of-conduct.md
@@ -0,0 +1,120 @@
+---
+lang: nl
+title: Your Code of Conduct
+description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct.
+class: coc
+toc:
+  why-do-i-need-a-code-of-conduct: "Why do I need a code of conduct?"
+  establishing-a-code-of-conduct: "Establishing a code of conduct"
+  deciding-how-youll-enforce-your-code-of-conduct: "Deciding how you’ll enforce your code of conduct"
+  enforcing-your-code-of-conduct: "Enforcing your code of conduct"
+  your-responsibilities-as-a-maintainer: "Your responsibilities as a maintainer"
+order: 8
+image: /assets/images/cards/coc.png
+related:
+  - building
+  - leadership
+---
+
+## Why do I need a code of conduct?
+
+A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.
+
+Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.
+
+A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with.
+
+## Establishing a code of conduct
+
+Try to establish a code of conduct as early as possible: ideally, when you first create your project.
+
+In addition to communicating your expectations, a code of conduct describes the following:
+
+* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_
+* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_
+* What happens if someone violates the code of conduct
+* How someone can report violations
+
+Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
+
+The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](http://citizencodeofconduct.org/) are also two good code of conduct examples.
+
+Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
+
+## Deciding how you'll enforce your code of conduct
+
+<aside markdown="1" class="pquote">
+  A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
+  <p markdown="1" class="pquote-credit">
+— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+  </p>
+</aside>
+
+You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:
+
+* It demonstrates that you are serious about taking action when it's needed.
+
+* Your community will feel more reassured that complaints actually get reviewed.
+
+* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.
+
+You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
+
+Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+
+For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+
+## Enforcing your code of conduct
+
+Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up.
+
+### Gather information about the situation
+
+Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment.
+
+The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context.
+
+Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
+
+<aside markdown="1" class="pquote">
+  Don’t get pulled into an argument. Don’t get sidetracked into dealing with someone else’s behavior before you’ve finished dealing with the matter at hand. Focus on what you need.
+  <p markdown="1" class="pquote-credit">
+— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+  </p>
+</aside>
+
+### Take appropriate action
+
+After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward.
+
+When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise.
+
+There are a few ways you might respond to a code of conduct violation:
+
+* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication.
+
+* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them.
+
+Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example:
+
+* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project
+
+* **Permanently ban** the person from the project
+
+Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached.
+
+## Your responsibilities as a maintainer
+
+A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes.
+
+As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community.
+
+A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable.
+
+In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way.
+
+## Encourage the behavior you want to see in the world 🌎
+
+When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow.
diff --git a/_articles/nl/finding-users.md b/_articles/nl/finding-users.md
new file mode 100644
index 00000000000..1d1cd099656
--- /dev/null
+++ b/_articles/nl/finding-users.md
@@ -0,0 +1,163 @@
+---
+lang: nl
+title: Finding Users for Your Project
+description: Help your open source project grow by getting it in the hands of happy users.
+class: finding
+toc:
+  spreading-the-word: "Spreading the word"
+  figure-out-your-message: "Figure out your message"
+  help-people-find-and-follow-your-project: "Help people find and follow your project"
+  go-where-your-projects-audience-is-online: "Go where your project’s audience is (online)"
+  go-where-your-projects-audience-is-offline: "Go where your project’s audience is (offline)"
+  build-a-reputation: "Build a reputation"
+order: 3
+image: /assets/images/cards/finding.png
+related:
+  - beginners
+  - building
+---
+
+## Spreading the word
+
+There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work!
+
+## Figure out your message
+
+Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters.
+
+What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance.
+
+Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want.
+
+For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
+
+![Cartography README](/assets/images/finding-users/cartography.jpg)
+
+For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+
+## Help people find and follow your project
+
+<aside markdown="1" class="pquote">
+  You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
+  <p markdown="1" class="pquote-credit">
+— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+  </p>
+</aside>
+
+Help people find and remember your project by pointing them to a single namespace.
+
+**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.
+
+If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. 
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
+  A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project.
+  <p markdown="1" class="pquote-credit">
+— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+  </p>
+</aside>
+
+**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_.
+
+If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+
+![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
+
+Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!
+
+## Go where your project's audience is (online)
+
+Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
+
+Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
+  Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project.
+  <p markdown="1" class="pquote-credit">
+— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+  </p>
+</aside>
+
+See if you can find ways to share your project in relevant ways:
+
+* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.
+* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.
+* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work.
+
+Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want.
+
+If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication.
+
+## Go where your project's audience is (offline)
+
+![Public speaking](/assets/images/finding-users/public_speaking.jpg)
+
+Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.
+
+If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
+  I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
+  <p markdown="1" class="pquote-credit">
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+  </p>
+</aside>
+
+If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.
+
+As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.
+
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
+  When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+  <p markdown="1" class="pquote-credit">
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+  </p>
+</aside>
+
+When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.
+
+Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
+  I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?
+  <p markdown="1" class="pquote-credit">
+— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+  </p>
+</aside>
+
+## Build a reputation
+
+In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.
+
+Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
+  The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+  <p markdown="1" class="pquote-credit">
+— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+  </p>
+</aside>
+
+It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others.
+
+There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
+  PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it.
+  <p markdown="1" class="pquote-credit">
+— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
+  </p>
+</aside>
+
+## Keep at it!
+
+It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.
diff --git a/_articles/nl/getting-paid.md b/_articles/nl/getting-paid.md
new file mode 100644
index 00000000000..4e7285c778f
--- /dev/null
+++ b/_articles/nl/getting-paid.md
@@ -0,0 +1,191 @@
+---
+lang: nl
+title: Getting Paid for Open Source Work
+description: Sustain your work in open source by getting financial support for your time or your project.
+class: getting-paid
+toc:
+  why-some-people-seek-financial-support: "Why some people seek financial support"
+  funding-your-own-time: "Funding your own time"
+  finding-funding-for-your-project: "Finding funding for your project"
+  building-a-case-for-financial-support: "Building a case for financial support"
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+  - best-practices
+  - leadership
+---
+
+## Why some people seek financial support
+
+Much of open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
+I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+  <p markdown="1" class="pquote-credit">
+— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+  </p>
+</aside>
+
+There are many reasons why a person would not want to be paid for their open source work.
+
+* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
+* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
+* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
+  Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+  <p markdown="1" class="pquote-credit">
+— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+  </p>
+</aside>
+
+For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+
+Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
+  Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+  <p markdown="1" class="pquote-credit">
+— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+  </p>
+</aside>
+
+Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
+   OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+  <p markdown="1" class="pquote-credit">
+— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+  </p>
+</aside>
+
+If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+
+## Funding your own time
+
+Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+
+It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
+  Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.
+  <p markdown="1" class="pquote-credit">
+— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
+  </p>
+</aside>
+
+If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+
+Many companies are developing open source programs to build their brand and recruit quality talent.
+
+@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+
+> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+
+If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
+  Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+  <p markdown="1" class="pquote-credit">
+— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+  </p>
+</aside>
+
+If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+
+* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
+* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+
+Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+
+Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
+
+* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
+* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+Finally, sometimes open source projects put bounties on issues that you might consider helping with. 
+
+* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their javascript library [through a bounty on gitcoin](https://gitcoin.co/).
+* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+
+## Finding funding for your project
+
+Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+
+Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing into new features or ideas.
+
+As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+
+### Raise money for your work through crowdfunding campaigns or sponsorships
+
+Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
+A few examples of sponsored projects include:
+
+* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
+* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803)
+* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+
+### Create a revenue stream
+
+Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
+* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
+* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+
+Some popular projects, like [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+
+### Apply for grant funding
+
+Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+
+For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+
+## Building a case for financial support
+
+Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+
+Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+
+### Impact
+
+Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+
+### Traction
+
+Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+
+### Value to funder
+
+Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+
+### Use of funds
+
+What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+
+### How you'll receive the funds
+
+Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
+  For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+  <p markdown="1" class="pquote-credit">
+— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+  </p>
+</aside>
+
+## Experiment and don't give up
+
+Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md
new file mode 100644
index 00000000000..c02def3ef02
--- /dev/null
+++ b/_articles/nl/how-to-contribute.md
@@ -0,0 +1,535 @@
+---
+lang: nl
+title: How to Contribute to Open Source
+description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans.
+class: contribute
+toc:
+  why-contribute-to-open-source: "Why contribute to open source?"
+  what-it-means-to-contribute: "What it means to contribute"
+  orienting-yourself-to-a-new-project: "Orienting yourself to a new project"
+  finding-a-project-to-contribute-to: "Finding a project to contribute to"
+  how-to-submit-a-contribution: "How to submit a contribution"
+  what-happens-after-you-submit-a-contribution: "What happens after you submit a contribution"
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+  - beginners
+  - building
+---
+
+## Why contribute to open source?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
+  Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+  <p markdown="1" class="pquote-credit">
+— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+  </p>
+</aside>
+
+Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+
+Why do people contribute to open source? Plenty of reasons!
+
+### Improve software you rely on
+
+Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+
+### Improve existing skills
+
+Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+
+### Meet people who are interested in similar things
+
+Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+
+### Find mentors and teach others
+
+Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+
+### Build public artifacts that help you grow a reputation (and a career)
+
+By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+
+### Learn people skills
+
+Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+
+### It's empowering to be able to make changes, even small ones
+
+You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+
+## What it means to contribute
+
+If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+
+Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+
+### You don't have to contribute code
+
+A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
+  I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+  <p markdown="1" class="pquote-credit">
+— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+  </p>
+</aside>
+
+Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
+  I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing.
+  <p markdown="1" class="pquote-credit">
+— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
+  </p>
+</aside>
+
+### Do you like planning events?
+
+* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Organize the project's conference (if they have one)
+* Help community members find the right conferences and submit proposals for speaking
+
+### Do you like to design?
+
+* Restructure layouts to improve the project's usability
+* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Put together a style guide to help the project have a consistent visual design
+* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+
+### Do you like to write?
+
+* Write and improve the project's documentation
+* Curate a folder of examples showing how the project is used
+* Start a newsletter for the project, or curate highlights from the mailing list
+* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Write a translation for the project's documentation
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
+  Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+  <p markdown="1" class="pquote-credit">
+— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+  </p>
+</aside>
+
+### Do you like organizing?
+
+* Link to duplicate issues, and suggest new issue labels, to keep things organized
+* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
+* Ask clarifying questions on recently opened issues to move the discussion forward
+
+### Do you like to code?
+
+* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Ask if you can help write a new feature
+* Automate project setup
+* Improve tooling and testing
+
+### Do you like helping people?
+
+* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
+* Answer questions for people on open issues
+* Help moderate the discussion boards or conversation channels
+
+### Do you like helping others code?
+
+* Review code on other people's submissions
+* Write tutorials for how a project can be used
+* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### You don't just have to work on software projects!
+
+While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+
+For example:
+
+* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
+* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
+* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+
+Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
+
+## Orienting yourself to a new project
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
+  If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+  <p markdown="1" class="pquote-credit">
+— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+  </p>
+</aside>
+
+For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+
+Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
+
+### Anatomy of an open source project
+
+Every open source community is different.
+
+Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+
+That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+
+A typical open source project has the following types of people:
+
+* **Author:** The person/s or organization that created the project
+* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
+* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
+* **Contributors:** Everyone who has contributed something back to the project
+* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+
+Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+
+A project also has documentation. These files are usually listed in the top level of a repository.
+
+* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
+* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
+* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
+* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
+* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.
+
+Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+
+* **Issue tracker:** Where people discuss issues related to the project.
+* **Pull requests:** Where people discuss and review changes that are in progress.
+* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
+* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
+
+## Finding a project to contribute to
+
+Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+
+If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_
+
+Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+
+Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+
+Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+
+Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+
+You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
+
+> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+
+If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+You can also use one of the following resources to help you discover and contribute to new projects:
+
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
+
+### A checklist before you contribute
+
+When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+
+Here's a handy checklist to evaluate whether a project is good for new contributors.
+
+**Meets the definition of open source**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+  </label>
+</div>
+
+**Project actively accepts contributions**
+
+Look at the commit activity on the master branch. On GitHub, you can see this information on a repository's homepage.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+  When was the latest commit?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+  How many contributors does the project have?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  </label>
+</div>
+
+Next, look at the project's issues.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    How many open issues are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to issues when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Are the issues recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+  </label>
+</div>
+
+Now do the same for the project's pull requests.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    How many open pull requests are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox20" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to pull requests when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the pull requests?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    Are the pull requests recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox13" class="overflow-hidden d-block text-normal">
+    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+  </label>
+</div>
+
+**Project is welcoming**
+
+A project that is friendly and welcoming signals that they will be receptive to new contributors.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox14" class="overflow-hidden d-block text-normal">
+    Do the maintainers respond helpfully to questions in issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox15" class="overflow-hidden d-block text-normal">
+    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox16" class="overflow-hidden d-block text-normal">
+    Do pull requests get reviewed?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox17" class="overflow-hidden d-block text-normal">
+    Do maintainers thank people for their contributions?
+  </label>
+</div>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+  </p>
+</aside>
+
+## How to submit a contribution
+
+You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+
+### Communicating effectively
+
+Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
+  \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+  <p markdown="1" class="pquote-credit">
+— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+  </p>
+</aside>
+
+Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+
+**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+
+> 😇 _"X doesn't happen when I do Y"_
+>
+> 😢 _"X is broken! Please fix it."_
+
+**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn.
+
+> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+>
+> 😢 _"How do I X?"_
+
+**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+
+> 😇 _"I'd like to write an API tutorial."_
+>
+> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+
+**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+
+> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+>
+> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+
+**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+
+> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+>
+> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+
+**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+
+> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+>
+> 😢 _"Why won't you support my use case? This is unacceptable!"_
+
+**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+
+### Gathering context
+
+Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+
+If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request:
+
+* **Issues** are like starting a conversation or discussion
+* **Pull requests** are for starting work on a solution
+* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
+  You'll learn <em>a lot</em> from taking a single project you actively use, "watching" it on GitHub and reading every issue and PR.
+<p markdown="1" class="pquote-credit">
+— @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
+  </p>
+</aside>
+
+### Opening an issue
+
+You should usually open an issue in the following situations:
+
+* Report an error you can't solve yourself
+* Discuss a high-level topic or idea (for example, community, vision or policies)
+* Propose a new feature or other project idea
+
+Tips for communicating on issues:
+
+* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
+* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
+* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+
+### Opening a pull request
+
+You should usually open a pull request in the following situations:
+
+* Submit trivial fixes (for example, a typo, a broken link or an obvious error)
+* Start work on a contribution that was already asked for, or that you've already discussed, in an issue
+
+A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
+
+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/).)
+* **[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.
+* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
+* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+
+If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+
+## What happens after you submit a contribution
+
+You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
+
+After you submit a contribution, one of the following will happen:
+
+### 😭 You don't get a response.
+
+Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+
+If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+
+**Don't** reach out to that person privately; remember that public communication is vital to open source projects.
+
+If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+
+### 🚧 Someone requests changes to your contribution.
+
+It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+
+When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it.
+
+If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
+
+### 👎 Your contribution doesn't get accepted.
+
+Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+
+### 🎉 Your contribution gets accepted.
+
+Hooray! You've successfully made an open source contribution!
+
+## You did it!
+
+Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
diff --git a/_articles/nl/leadership-and-governance.md b/_articles/nl/leadership-and-governance.md
new file mode 100644
index 00000000000..4b4d7963bb1
--- /dev/null
+++ b/_articles/nl/leadership-and-governance.md
@@ -0,0 +1,165 @@
+---
+lang: nl
+title: Leadership and Governance
+description: Growing open source projects can benefit from formal rules for making decisions.
+class: leadership
+toc:
+  understanding-governance-for-your-growing-project: "Understanding governance for your growing project"
+  what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?"
+  how-do-i-formalize-these-leadership-roles: "How do I formalize these leadership roles?"
+  when-should-i-give-someone-commit-access: "When should I give someone commit access?"
+  what-are-some-of-the-common-governance-structures-for-open-source-projects: "What are some of the common governance structures for open source projects?"
+  do-i-need-governance-docs-when-i-launch-my-project: "Do I need governance docs when I launch my project?"
+  what-happens-if-corporate-employees-start-submitting-contributions: "What happens if corporate employees start submitting contributions?"
+  do-i-need-a-legal-entity-to-support-my-project: "Do I need a legal entity to support my project?"
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+  - best-practices
+  - metrics
+---
+
+## Understanding governance for your growing project
+
+Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+
+## What are examples of formal roles used in open source projects?
+
+Many projects follow a similar structure for contributor roles and recognition.
+
+What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+
+* **Maintainer**
+* **Contributor**
+* **Committer**
+
+**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+
+A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+
+**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+  </p>
+</aside>
+
+**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+
+While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
+  You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+  <p markdown="1" class="pquote-credit">
+— @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+  </p>
+</aside>
+
+## How do I formalize these leadership roles?
+
+Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+
+For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+
+For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+
+If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+
+<aside markdown="1" class="pquote">
+  \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+  <p markdown="1" class="pquote-credit">
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+  </p>
+</aside>
+
+Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+
+Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+
+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).
+
+## When should I give someone commit access?
+
+Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
+  Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+  <p markdown="1" class="pquote-credit">
+— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+  </p>
+</aside>
+
+## What are some of the common governance structures for open source projects?
+
+There are three common governance structures associated with open source projects.
+
+* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+
+* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+
+* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
+
+Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Do I need governance docs when I launch my project?
+
+There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+
+Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+
+If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
+  We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+  <p markdown="1" class="pquote-credit">
+— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+  </p>
+</aside>
+
+## What happens if corporate employees start submitting contributions?
+
+Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+
+As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+
+It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+
+"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+
+Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+
+## Do I need a legal entity to support my project?
+
+You don't need a legal entity to support your open source project unless you're handling money.
+
+For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+
+If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+
+Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
+  Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+  <p markdown="1" class="pquote-credit">
+— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+  </p>
+</aside>
+
+If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
new file mode 100644
index 00000000000..02b8fb25799
--- /dev/null
+++ b/_articles/nl/legal.md
@@ -0,0 +1,166 @@
+---
+lang: nl
+title: The Legal Side of Open Source
+description: Everything you've ever wondered about the legal side of open source, and a few things you didn't.
+class: legal
+toc:
+  why-do-people-care-so-much-about-the-legal-side-of-open-source: "Why do people care so much about the legal side of open source?"
+  are-public-github-projects-open-source: "Are public GitHub projects open source?"
+  just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Just give me the TL;DR on what I need to protect my project"
+  which-open-source-license-is-appropriate-for-my-project: "Which open source license is appropriate for my project?"
+  what-if-i-want-to-change-the-license-of-my-project: "What if I want to change the license of my project?"
+  does-my-project-need-an-additional-contributor-agreement: "Does my project need an additional contributor agreement?"
+  what-does-my-companys-legal-team-need-to-know: "What does my company’s legal team need to know?"
+order: 10
+image: /assets/images/cards/legal.png
+related:
+  - contribute
+  - leadership
+---
+
+## Understanding the legal implications of open source
+
+Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+
+## Why do people care so much about the legal side of open source?
+
+Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+
+In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+
+If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+
+Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
+
+## 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**.
+
+![Create repository](/assets/images/legal/repo-create-name.png)
+
+**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+
+If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+
+## Just give me the TL;DR on what I need to protect my project.
+
+You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+
+[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 the most popular open source 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/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
+  A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+  <p markdown="1" class="pquote-credit">
+— @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+  </p>
+</aside>
+
+## Which open source license is appropriate for my project?
+
+If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+
+Otherwise, picking the right open source license for your project depends on your objectives.
+
+Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+
+On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+
+You may also want to consider the **communities** you hope will use and contribute to your project:
+
+* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
+* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
+* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+
+Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+
+When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+
+## What if I want to change the license of my project?
+
+Most projects never need to change licenses. But occasionally circumstances change.
+
+For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+
+**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+
+**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+
+**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+
+Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+
+## 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).
+
+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.
+
+Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
+    We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+  <p markdown="1" class="pquote-credit">
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+  </p>
+</aside>
+
+Some situations where you may want to consider an additional contributor agreement for your project include:
+
+* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
+* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
+* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
+* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
+* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
+
+If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+
+## What does my company's legal team need to know?
+
+If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+
+For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+
+**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+
+* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+
+* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+
+* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
+
+* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+
+* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+
+If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+
+Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+
+* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
+  Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+  <p markdown="1" class="pquote-credit">
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+  </p>
+</aside>
+
+* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
+* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+
+<aside markdown="1" class="pquote">
+  Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+  <p markdown="1" class="pquote-credit">
+— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+  </p>
+</aside>
+
+* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
+* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
diff --git a/_articles/nl/metrics.md b/_articles/nl/metrics.md
new file mode 100644
index 00000000000..60a2a72d703
--- /dev/null
+++ b/_articles/nl/metrics.md
@@ -0,0 +1,132 @@
+---
+lang: nl
+title: Open Source Metrics
+description: Make informed decisions to help your open source project thrive by measuring and tracking its success.
+class: metrics
+toc:
+  why-measure-anything: "Why measure anything?"
+  discovery: "Discovery"
+  usage: "Usage"
+  retention: "Retention"
+  maintainer-activity: "Maintainer activity"
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+  - finding
+  - best-practices
+---
+
+## Why measure anything?
+
+Data, when used wisely, can help you make better decisions as an open source maintainer.
+
+With more information, you can:
+
+* Understand how users respond to a new feature
+* Figure out where new users come from
+* Identify, and decide whether to support, an outlier use case or functionality
+* Quantify your project's popularity
+* Understand how your project is used
+* Raise money through sponsorships and grants
+
+For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+
+> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+
+Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+
+If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+
+## Discovery
+
+Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+
+![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:
+
+* **Total page views:** Tells you how many times your project was viewed
+
+* **Total unique visitors:** Tells you how many people viewed your project
+
+* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+
+* **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.
+
+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.
+
+## Usage
+
+People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+
+If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+
+Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+
+If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+
+![Clone graph](/assets/images/metrics/clone_graph.png)
+
+If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+
+* Your project isn't successfully converting your audience, or
+* You're attracting the wrong audience
+
+For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+
+Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+
+Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+
+## Retention
+
+People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+
+It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+
+Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+
+Examples of community metrics that you may want to regularly track include:
+
+* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+
+![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+
+* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+
+* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+
+* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+
+* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
+  Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+  <p markdown="1" class="pquote-credit">
+— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+  </p>
+</aside>
+
+## Maintainer activity
+
+Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+
+Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+
+[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+
+Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+
+You could also measure the time it takes to move between stages in the contribution process, such as:
+
+* Average time an issue remains open
+* Whether issues get closed by PRs
+* Whether stale issues get closed
+* Average time to merge a pull request
+
+## Use 📊 to learn about people
+
+Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
diff --git a/_articles/nl/starting-a-project.md b/_articles/nl/starting-a-project.md
new file mode 100644
index 00000000000..b7502bc5744
--- /dev/null
+++ b/_articles/nl/starting-a-project.md
@@ -0,0 +1,362 @@
+---
+lang: nl
+title: Starting an Open Source Project
+description: Learn more about the world of open source and get ready to launch your own project.
+class: beginners
+toc:
+  the-what-and-why-of-open-source: "The what and why of open source"
+  should-i-launch-my-own-open-source-project: "Should I launch my own open source project?"
+  launching-your-own-open-source-project: "Launching your own open source project"
+  naming-and-branding-your-project: "Naming and branding your project"
+  your-pre-launch-checklist: "Your pre-launch checklist"
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+  - finding
+  - building
+---
+
+## The "what" and "why" of open source
+
+So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+
+### What does "open source" mean?
+
+When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+
+Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+
+_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+
+### Why do people open source their work?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+  One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+  <p markdown="1" class="pquote-credit">
+— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+  </p>
+</aside>
+
+[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+
+* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+
+* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+
+Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+
+### Does open source mean "free of charge"?
+
+One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+
+Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+
+As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+
+## Should I launch my own open source project?
+
+The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+
+If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+
+Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+
+If you're not yet convinced, take a moment to think about what your goals might be.
+
+### Setting your goals
+
+Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself,  _why am I open sourcing this project?_
+
+There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+
+If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+  At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+  <p markdown="1" class="pquote-credit">
+— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+  </p>
+</aside>
+
+As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+
+While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+
+**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+
+If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+  As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+  <p markdown="1" class="pquote-credit">
+— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+  </p>
+</aside>
+
+### Contributing to other projects
+
+If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+
+If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+
+## Launching your own open source project
+
+There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+
+Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+
+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/)
+* [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.
+
+If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+
+### Choosing a license
+
+An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+
+Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+
+[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 the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+
+When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+
+![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+
+If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+
+### Writing a README
+
+READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+
+In your README, try to answer the following questions:
+
+* What does this project do?
+* Why is this project useful?
+* How do I get started?
+* Where can I get more help, if I need it?
+
+You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+  Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+  <p markdown="1" class="pquote-credit">
+— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+  </p>
+</aside>
+
+Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+
+For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+
+When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+
+### Writing your contributing guidelines
+
+A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+
+* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
+* How to suggest a new feature
+* How to set up your environment and run tests
+
+In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+
+* The types of contributions you're looking for
+* Your roadmap or vision for the project
+* How contributors should (or should not) get in touch with you
+
+Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+
+For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+
+> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+
+In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+
+Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+
+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.
+
+![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+
+### Establishing a code of conduct
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+  We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+  <p markdown="1" class="pquote-credit">
+— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+  </p>
+</aside>
+
+Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+
+For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+
+In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+
+Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+
+Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+
+## Naming and branding your project
+
+Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+
+### Choosing the right name
+
+Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+
+* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
+* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+
+If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+
+Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+
+### Avoiding name conflicts
+
+[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+
+If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+
+Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+
+You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+
+Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+
+### How you write (and code) affects your brand, too!
+
+Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+
+Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+  <p markdown="1" class="pquote-credit">
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+
+Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+
+It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+
+## 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.
+
+**Documentation**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Project has a LICENSE file with an open source license
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    The issue queue is up-to-date, with issues clearly organized and labeled
+  </label>
+</div>
+
+**Code**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Project uses consistent code conventions and clear function/method/variable names
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    The code is clearly commented, documenting intentions and edge cases
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+  </label>
+</div>
+
+**People**
+
+If you're an individual:
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  </label>
+</div>
+
+If you're a company or organization:
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    You've talked to your legal department
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    You have a marketing plan for announcing and promoting the project
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    At least two people have administrative access to the project
+  </label>
+</div>
+
+## You did it!
+
+Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.

From 4e783d1cbfbd58dbcdf4e6d2a802339b5afd2549 Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Mon, 24 Aug 2020 21:09:37 +0200
Subject: [PATCH 059/749] First steps for best-practices.md

---
 _articles/nl/best-practices.md | 93 ++++++++++++++++++----------------
 _articles/nl/index.html        |  6 +++
 _articles/nl/index.min.html    |  1 +
 3 files changed, 55 insertions(+), 45 deletions(-)
 create mode 100644 _articles/nl/index.html
 create mode 100644 _articles/nl/index.min.html

diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index a6ab4e409e3..b9a73350e0d 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -1,15 +1,15 @@
 ---
 lang: nl
-title: Best Practices for Maintainers
-description: Making your life easier as an open source maintainer, from documenting processes to leveraging your community.
+title: Tips voor open source-beheerder
+description: Uw leven gemakkelijker maken als open source-beheerder, van het documenteren van processen tot het benutten van uw gemeenschap.
 class: best-practices
 toc:
-  what-does-it-mean-to-be-a-maintainer: "What does it mean to be a maintainer?"
-  documenting-your-processes: "Documenting your processes"
-  learning-to-say-no: "Learning to say no"
-  leverage-your-community: "Leverage your community"
-  bring-in-the-robots: "Bring in the robots"
-  its-okay-to-hit-pause: "It’s okay to hit pause"
+  what-does-it-mean-to-be-a-maintainer: "Wat betekent het om een open source-onderhouder te zijn?"
+  documenting-your-processes: "Documenteren van uw processen"
+  learning-to-say-no: "Nee leren zeggen"
+  leverage-your-community: "Maak gebruik van uw community"
+  bring-in-the-robots: "Breng de robots"
+  its-okay-to-hit-pause: "Het is oké om op pauze te drukken"
 order: 5
 image: /assets/images/cards/best-practices.png
 related:
@@ -17,72 +17,75 @@ related:
   - leadership
 ---
 
-## What does it mean to be a maintainer?
+## Wat betekent het om een open source-onderhouder te zijn?
 
-If you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more.
+Als je een open source-project onderhoudt dat veel mensen gebruiken, heb je misschien gemerkt dat je minder codeert en meer op problemen reageert.
 
-In the early stages of a project, you're experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you'll find yourself working with your users and contributors more.
+In de vroege stadia van een project experimenteer je met nieuwe ideeën en neem je beslissingen op basis van wat je wilt. Naarmate uw project populairder wordt, zult u merken dat u meer met uw gebruikers en bijdragers samenwerkt.
 
-Maintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community.
+Voor het onderhouden van een project is meer nodig dan alleen code. Deze taken zijn vaak onverwacht, maar net zo belangrijk voor een groeiend project. We hebben een aantal manieren verzameld om uw leven gemakkelijker te maken, van het documenteren van processen tot het benutten van uw gemeenschap.
 
-## Documenting your processes
+## Documenteren van uw processen
 
-Writing things down is one of the most important things you can do as a maintainer.
+Dingen documenteren is een van de belangrijkste dingen die u als onderhouder kunt doen.
 
-Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask.
+Documentatie verduidelijkt niet alleen uw eigen denken, maar het helpt andere mensen ook te begrijpen wat u nodig heeft of verwacht, nog voordat ze erom vragen.
 
-Writing things down makes it easier to say no when something doesn't fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project.
+Door dingen op te schrijven, wordt het gemakkelijker om nee te zeggen als iets niet binnen uw bereik past. Het maakt het ook gemakkelijker voor mensen om in te springen en te helpen. Je weet nooit wie je project leest of gebruikt.
 
-Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all.
+Zelfs als u geen volledige alinea's gebruikt, is het beter om opsommingstekens op te schrijven dan helemaal niet te documenteren.
 
-Remember to keep your documentation up-to-date. If you're not able to always do this, delete your outdated documentation or indicate it is outdated so contributors know updates are welcome.
+Denk eraan om uw documentatie up-to-date te houden. Als u dit niet altijd kunt doen, verwijdert u uw verouderde documentatie of geeft u aan dat deze verouderd is, zodat bijdragers weten dat updates welkom zijn.
 
-### Write down your project's vision
+### Schrijf de visie van uw project op
 
-Start by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well.
+Begin met het opschrijven van de doelen van uw project. Voeg ze toe aan je README, of maak een apart bestand met de naam VISION. Als er andere artefacten zijn die kunnen helpen, zoals een projectroadmap, maak die dan ook openbaar.
 
-Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions.
+Door een duidelijke, gedocumenteerde visie te hebben, blijft u gefocust en kunt u voorkomen dat u "scoop" van andermans bijdragen krijgt.
 
-For example, @lord discovered that having a project vision helped him figure out which requests to spend time on. As a new maintainer, he regretted not sticking to his project's scope when he got his first feature request for [Slate](https://github.com/lord/slate).
+@Lord ontdekte bijvoorbeeld dat het hebben van een projectvisie hem hielp uitzoeken aan welke verzoeken hij tijd moest besteden. Als nieuwe open source-onderhouder had hij er spijt van dat hij zich niet aan de reikwijdte van zijn project had gehouden toen hij zijn eerste functieverzoek kreeg voor [Slate](https://github.com/lord/slate).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
-  I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of an half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
+Ik heb het gerommeld. Ik heb niet de moeite genomen om met een complete oplossing te komen. In plaats van een halfslachtige oplossing, zou ik willen dat ik had gezegd: "Ik heb hier momenteel geen tijd voor, maar ik zal het toevoegen aan de lange termijn lijst met leuke dingen."
+  
+_I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of an half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."_
+
   <p markdown="1" class="pquote-credit">
 — @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
   </p>
 </aside>
 
-### Communicate your expectations
-
-Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun.
-
-Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do.
+### Communiceer uw verwachtingen
 
-Most people who come across your project don't know anything about you or your circumstances. They may assume you get paid to work on it, especially if it's something they regularly use and depend on. Maybe at one point you put a lot of time into your project, but now you're busy with a new job or family member.
+Regels kunnen zenuwslopend zijn om op te schrijven. Soms heb je misschien het gevoel dat je het gedrag van andere mensen controleert of al het plezier wegneemt.
 
-All of this is perfectly okay! Just make sure other people know about it.
+Eerlijk geschreven en gehandhaafd, maar goede regels geven open soruce-onderhouders meer mogelijkheden. Ze voorkomen dat u wordt meegesleurd in dingen die u niet wilt doen.
+ 
+De meeste mensen die uw project tegenkomen, weten niets over u of uw omstandigheden. Ze gaan er misschien van uit dat je wordt betaald om eraan te werken, vooral als het iets is dat ze regelmatig gebruiken en waarvan ze afhankelijk zijn. Misschien heb je op een gegeven moment veel tijd in je project gestoken, maar ben je nu bezig met een nieuwe baan of familielid.
 
-If maintaining your project is part-time or purely volunteered, be honest about how much time you have. This is not the same as how much time you think the project requires, or how much time others want you to spend.
+Dit is allemaal in orde! Zorg ervoor dat andere mensen ervan op de hoogte zijn.
 
-Here are a few rules that are worth writing down:
+Als het onderhouden van uw project parttime of puur vrijwillig is, wees dan eerlijk over hoeveel tijd u hebt. Dit is niet hetzelfde als hoeveel tijd u denkt dat het project nodig heeft, of hoeveel tijd anderen willen dat u eraan besteedt.
 
-* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_)
-* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_)
-* When it's appropriate to follow up (_for example, "You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread."_)
-* How much time you spend on the project (_for example, "We only spend about 5 hours per week on this project"_)
+Hier zijn een paar regels die het waard zijn om op te schrijven:
 
-[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors.
+* Hoe een bijdrage wordt beoordeeld en geaccepteerd (_Hebben ze tests nodig? Een issue-sjabloon? _)
+* De soorten bijdragen die je accepteert (_Wil je alleen hulp bij een bepaald deel van je code? _)
+* Wanneer het gepast is om op te volgen (_bijvoorbeeld: "U kunt binnen 7 dagen een reactie van een onderhouder verwachten. Als u tegen die tijd niets heeft gehoord, kunt u de discussie pingen." _)
+* Hoeveel tijd u aan het project besteedt (_bijvoorbeeld: "We besteden slechts ongeveer 5 uur per week aan dit project" _)
 
-### Keep communication public
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), en [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) zijn verschillende voorbeelden van projecten met basisregels voor beheerders en bijdragers.
 
-Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker.
+### Houd de communicatie openbaar
 
-If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes.
+Vergeet ook niet uw interacties te documenteren. Houd de communicatie over uw project waar mogelijk openbaar. Als iemand privé contact met u opneemt om een functieverzoek of ondersteuningsbehoefte te bespreken, verwijs hem dan beleefd naar een openbaar communicatiekanaal, zoals een mailinglijst of issue tracker.
 
-That way, anybody who joins your community will have access to the same information as someone who's been there for years.
+Als u andere beheerders ontmoet, of een belangrijke beslissing neemt in privé, documenteer deze gesprekken dan in het openbaar, zelfs als u alleen maar uw aantekeningen plaatst.
 
-## Learning to say no
+Op die manier heeft iedereen die lid wordt van uw community toegang tot dezelfde informatie als iemand die er al jaren is.
+ 
+## Nee leren zeggen
 
 You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists.
 
@@ -164,7 +167,7 @@ Maybe someone in your community regularly submits contributions that don't meet
 
 If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first issue,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them.
 
-## Leverage your community
+## Maak gebruik van uw community
 
 You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work.
 
@@ -212,7 +215,7 @@ The same applies to a user who really wants a solution that you simply don't hav
 
 > It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying "no", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform.
 
-## Bring in the robots
+## Breng de robots
 
 Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier.
 
@@ -256,7 +259,7 @@ However, if your standards are too complicated, they can increase the barriers t
 
 If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors.
 
-## It's okay to hit pause
+## Het is oké om op pauze te drukken
 
 Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty.
 
diff --git a/_articles/nl/index.html b/_articles/nl/index.html
new file mode 100644
index 00000000000..c40c3e9db24
--- /dev/null
+++ b/_articles/nl/index.html
@@ -0,0 +1,6 @@
+---
+layout: index
+title: Open source gids
+lang: nl
+permalink: /nl/
+---
diff --git a/_articles/nl/index.min.html b/_articles/nl/index.min.html
new file mode 100644
index 00000000000..d89f91b25b7
--- /dev/null
+++ b/_articles/nl/index.min.html
@@ -0,0 +1 @@
+--- layout: index title: Open source gids lang: nl permalink: /nl/ ---
\ No newline at end of file

From c777592cd78f85aff022def902a54dea232317e3 Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Tue, 25 Aug 2020 19:50:44 +0200
Subject: [PATCH 060/749] =?UTF-8?q?Fixes=20=20Don=E2=80=99t=20pad=20=20wit?=
 =?UTF-8?q?h=20inner=20spaces?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 _articles/nl/best-practices.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index b9a73350e0d..ca75e50d38f 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -70,10 +70,10 @@ Als het onderhouden van uw project parttime of puur vrijwillig is, wees dan eerl
 
 Hier zijn een paar regels die het waard zijn om op te schrijven:
 
-* Hoe een bijdrage wordt beoordeeld en geaccepteerd (_Hebben ze tests nodig? Een issue-sjabloon? _)
-* De soorten bijdragen die je accepteert (_Wil je alleen hulp bij een bepaald deel van je code? _)
-* Wanneer het gepast is om op te volgen (_bijvoorbeeld: "U kunt binnen 7 dagen een reactie van een onderhouder verwachten. Als u tegen die tijd niets heeft gehoord, kunt u de discussie pingen." _)
-* Hoeveel tijd u aan het project besteedt (_bijvoorbeeld: "We besteden slechts ongeveer 5 uur per week aan dit project" _)
+* Hoe een bijdrage wordt beoordeeld en geaccepteerd (_Hebben ze tests nodig? Een issue-sjabloon?_)
+* De soorten bijdragen die je accepteert (_Wil je alleen hulp bij een bepaald deel van je code?_)
+* Wanneer het gepast is om op te volgen (_bijvoorbeeld: "U kunt binnen 7 dagen een reactie van een onderhouder verwachten. Als u tegen die tijd niets heeft gehoord, kunt u de discussie pingen."_)
+* Hoeveel tijd u aan het project besteedt (_bijvoorbeeld: "We besteden slechts ongeveer 5 uur per week aan dit project"_)
 
 [Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), en [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) zijn verschillende voorbeelden van projecten met basisregels voor beheerders en bijdragers.
 

From 9331b3c2204d53054439f803027de560e7796571 Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Tue, 25 Aug 2020 20:10:47 +0200
Subject: [PATCH 061/749] Small update + fixed breaking test

---
 _articles/nl/best-practices.md     | 58 ++++++++++++++++--------------
 _articles/nl/building-community.md |  2 +-
 2 files changed, 32 insertions(+), 28 deletions(-)

diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index ca75e50d38f..2d7e74da009 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -1,6 +1,6 @@
 ---
 lang: nl
-title: Tips voor open source-beheerder
+title: Tips voor een open source-beheerder
 description: Uw leven gemakkelijker maken als open source-beheerder, van het documenteren van processen tot het benutten van uw gemeenschap.
 class: best-practices
 toc:
@@ -87,52 +87,56 @@ Op die manier heeft iedereen die lid wordt van uw community toegang tot dezelfde
  
 ## Nee leren zeggen
 
-You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists.
+Je hebt dingen opgeschreven. Idealiter zou iedereen uw documentatie lezen, maar in werkelijkheid moet u anderen eraan herinneren dat deze kennis bestaat.
 
-Having everything written down, however, helps depersonalize situations when you do need to enforce your rules.
+Door alles op te schrijven, kunt u situaties onpersoonlijk maken waarin u uw regels wel moet handhaven.
 
-Saying no isn't fun, but  _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_.
+Nee zeggen is niet leuk, maar _"Uw bijdrage voldoet niet aan de criteria van dit project"_ voelt minder persoonlijk dan _"Ik vind uw bijdrage niet leuk"_.
 
-Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others.
+Nee zeggen is van toepassing op veel situaties die je als open source-onderhouder tegenkomt: functieverzoeken die niet binnen het bereik passen, iemand die een discussie ontspoort, onnodig werk voor anderen doet.
 
-### Keep the conversation friendly
+### Houd het gesprek vriendelijk
 
-One of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept.
+Een van de belangrijkste plaatsen waar u kunt oefenen om nee te zeggen, is uw issue en pull request lijst met verzoeken. Als projectbeheerder ontvangt u onvermijdelijk suggesties die u niet wilt accepteren.
 
-Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor.
+Misschien verandert de bijdrage de reikwijdte van uw project of past deze niet bij uw visie. Misschien is het idee goed, maar de implementatie is slecht.
 
-Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards.
+Ongeacht de reden is het mogelijk om tactvol om te gaan met bijdragen die niet voldoen aan de normen van uw project.
 
-If you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community.
+Als u een bijdrage ontvangt die u niet wilt accepteren, is uw eerste reactie misschien dat u deze negeert of doet alsof u deze niet hebt gezien. Dit kan de gevoelens van de ander schaden en zelfs andere potentiële bijdragers in uw gemeenschap demotiveren.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
-  The key to handle support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS.
+  De sleutel tot het afhandelen van ondersteuning voor grootschalige open source-projecten is om problemen in beweging te houden. Probeer te voorkomen dat problemen vastlopen. Als je een iOS-ontwikkelaar bent, weet je hoe frustrerend het kan zijn om radars in te dienen. Mogelijk hoort u 2 jaar later terug en wordt u verteld het opnieuw te proberen met de nieuwste versie van iOS.
+  
+  _The key to handle support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS._
   <p markdown="1" class="pquote-credit">
 — @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
   </p>
 </aside>
 
-Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.
-
-It's better to immediately close the contributions you know you don't want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Laat geen ongewenste bijdrage openstaan omdat je je schuldig voelt of aardig wilt zijn. Na verloop van tijd zullen uw onbeantwoorde problemen en PR's het werken aan uw project veel stressvoller en intimiderend maken.
 
-Secondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it's someone's first time. Even if you don't accept their contribution, acknowledge the person behind it and thank them for their interest. It's a big compliment!
+Het is beter om de bijdragen waarvan u weet dat u ze niet wilt accepteren, onmiddellijk af te sluiten. Als uw project al een grote achterstand heeft, heeft @steveklabnik suggesties voor [hoe u problemen efficiënt kunt sorteren (Engels)](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
 
-If you don't want to accept a contribution:
+Ten tweede is het negeren van bijdragen een negatief signaal naar uw gemeenschap. Bijdragen aan een project kan intimiderend zijn, vooral als het iemands eerste keer is. Zelfs als u hun bijdrage niet accepteert, erken de persoon erachter en bedank hem voor zijn interesse. Het is een groot compliment!
+ 
+Als u een bijdrage niet wil accepteren:
 
-* **Thank them** for their contribution
-* **Explain why it doesn't fit** into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm.
-* **Link to relevant documentation**, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself.
-* **Close the request**
+* **Bedank ze** voor hun bijdrage
+* **Leg uit waarom het niet past** in de scope van het project, en bied duidelijke suggesties voor verbetering, als je kunt. Wees aardig, maar standvastig.
+* **Link naar relevante documentatie**, als u die heeft. Als u herhaalde verzoeken opmerkt voor dingen die u niet wilt accepteren, voegt u deze toe aan uw documentatie om te voorkomen dat u zichzelf herhaalt.
+* **Sluit het verzoek**
 
-You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):
+Je hebt niet meer dan 1-2 zinnen nodig om te reageren. Als voorbeeld, als een gebruiker van [celery](https://github.com/celery/celery/) een Windows-gerelateerde fout meldde, @berkerpeksag [reageerde met (Engels)](https://github.com/celery/celery/issues/3383):
 
 ![Celery screenshot](/assets/images/best-practices/celery.png)
 
-If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):
+Als de gedachte om nee te zeggen je bang maakt, ben je niet de enige. zoals @jessfraz [het omschrijft](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> Ik heb met onderhouders van verschillende open source-projecten gesproken, Mesos, Kubernetes, Chromium, en ze zijn het er allemaal over eens dat een van de moeilijkste aspecten van het zijn van een onderhouder is om "Nee" te zeggen tegen patches die je niet wilt.
 
-> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want.
+> _I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want._
 
 Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it.
 
@@ -279,12 +283,12 @@ Just like any other type of work, taking regular breaks will keep you refreshed,
   </p>
 </aside>
 
-Sometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away.
+Soms kan het moeilijk zijn om een pauze in te lassen van open source-werk als het voelt alsof iedereen je nodig heeft. Mensen kunnen zelfs proberen je een schuldgevoel te geven omdat je weggaat.
 
-Do your best to find support for your users and community while you're away from a project. If you can't find the support you need, take a break anyway. Be sure to communicate when you're not available, so people aren't confused by your lack of responsiveness.
+Doe uw best om ondersteuning voor uw gebruikers en gemeenschap te vinden terwijl u niet aan een project zit. Als je de ondersteuning die je nodig hebt niet kunt vinden, neem dan toch een pauze. Zorg ervoor dat u communiceert wanneer u niet beschikbaar bent, zodat mensen niet in de war raken door uw gebrek aan reactievermogen.
 
-Taking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you.
+Pauzes nemen geldt ook voor meer dan alleen vakanties. Als je in het weekend of tijdens werkuren geen open source-werk wilt doen, communiceer die verwachtingen dan aan anderen, zodat ze weten dat ze je niet lastig vallen.
 
 ## Take care of yourself first!
 
-Maintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive.
+Het onderhouden van een populair project vereist andere vaardigheden dan de eerdere groeifasen, maar het is niet minder lonend. Als onderhouder oefen je leiderschap en persoonlijke vaardigheden op een niveau dat maar weinig mensen ervaren. Hoewel het niet altijd gemakkelijk te beheren is, helpt het stellen van duidelijke grenzen en alleen aan te nemen waar je je prettig bij voelt, je gelukkig, verfrist en productief te blijven.
diff --git a/_articles/nl/building-community.md b/_articles/nl/building-community.md
index 73e5cba0ffb..9f5b6e43758 100644
--- a/_articles/nl/building-community.md
+++ b/_articles/nl/building-community.md
@@ -39,7 +39,7 @@ Start with your documentation:
 * **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
 * **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
 * **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
-* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#nee-leren-zeggen) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">

From aea70ee584746e7e5e50dcf4db9a4ae16d16cf33 Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Tue, 25 Aug 2020 20:18:08 +0200
Subject: [PATCH 062/749] Fixed retext-repeated-words

---
 _articles/nl/best-practices.md | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index 2d7e74da009..13305519751 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -115,7 +115,7 @@ Als u een bijdrage ontvangt die u niet wilt accepteren, is uw eerste reactie mis
   </p>
 </aside>
 
-Laat geen ongewenste bijdrage openstaan omdat je je schuldig voelt of aardig wilt zijn. Na verloop van tijd zullen uw onbeantwoorde problemen en PR's het werken aan uw project veel stressvoller en intimiderend maken.
+Laat geen ongewenste bijdrage openstaan omdat je een schuldgevoel hebt of aardig wilt zijn. Na verloop van tijd zullen uw onbeantwoorde problemen en PR's het werken aan uw project veel stressvoller en intimiderend maken.
 
 Het is beter om de bijdragen waarvan u weet dat u ze niet wilt accepteren, onmiddellijk af te sluiten. Als uw project al een grote achterstand heeft, heeft @steveklabnik suggesties voor [hoe u problemen efficiënt kunt sorteren (Engels)](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
 
@@ -136,8 +136,6 @@ Als de gedachte om nee te zeggen je bang maakt, ben je niet de enige. zoals @jes
 
 > Ik heb met onderhouders van verschillende open source-projecten gesproken, Mesos, Kubernetes, Chromium, en ze zijn het er allemaal over eens dat een van de moeilijkste aspecten van het zijn van een onderhouder is om "Nee" te zeggen tegen patches die je niet wilt.
 
-> _I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want._
-
 Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it.
 
 Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise.
@@ -291,4 +289,4 @@ Pauzes nemen geldt ook voor meer dan alleen vakanties. Als je in het weekend of
 
 ## Take care of yourself first!
 
-Het onderhouden van een populair project vereist andere vaardigheden dan de eerdere groeifasen, maar het is niet minder lonend. Als onderhouder oefen je leiderschap en persoonlijke vaardigheden op een niveau dat maar weinig mensen ervaren. Hoewel het niet altijd gemakkelijk te beheren is, helpt het stellen van duidelijke grenzen en alleen aan te nemen waar je je prettig bij voelt, je gelukkig, verfrist en productief te blijven.
+Het onderhouden van een populair project vereist andere vaardigheden dan de eerdere groeifasen, maar het is niet minder lonend. Als onderhouder oefen je leiderschap en persoonlijke vaardigheden op een niveau dat maar weinig mensen ervaren. Hoewel het niet altijd gemakkelijk te beheren is, helpt het stellen van duidelijke grenzen en alleen aan te nemen waar je een prettig gevoel bij hebt, je gelukkig door voelt of wat je verfrist om productief te blijven.

From ce89d025111429132d4bf2b89cee51451d206284 Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Tue, 25 Aug 2020 20:47:58 +0200
Subject: [PATCH 063/749] updated 'friends' label

---
 _articles/nl/best-practices.md | 69 ++++++++++++++++++----------------
 _data/locales/nl.yml           |  4 +-
 2 files changed, 39 insertions(+), 34 deletions(-)

diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index 13305519751..c3f0661a8ed 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -117,7 +117,7 @@ Als u een bijdrage ontvangt die u niet wilt accepteren, is uw eerste reactie mis
 
 Laat geen ongewenste bijdrage openstaan omdat je een schuldgevoel hebt of aardig wilt zijn. Na verloop van tijd zullen uw onbeantwoorde problemen en PR's het werken aan uw project veel stressvoller en intimiderend maken.
 
-Het is beter om de bijdragen waarvan u weet dat u ze niet wilt accepteren, onmiddellijk af te sluiten. Als uw project al een grote achterstand heeft, heeft @steveklabnik suggesties voor [hoe u problemen efficiënt kunt sorteren (Engels)](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Het is beter om de bijdragen waarvan u weet dat u ze niet wilt accepteren, onmiddellijk af te sluiten. Als uw project al een grote achterstand heeft, heeft @steveklabnik suggesties voor [hoe u problemen efficiënt kunt sorteren](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
 
 Ten tweede is het negeren van bijdragen een negatief signaal naar uw gemeenschap. Bijdragen aan een project kan intimiderend zijn, vooral als het iemands eerste keer is. Zelfs als u hun bijdrage niet accepteert, erken de persoon erachter en bedank hem voor zijn interesse. Het is een groot compliment!
  
@@ -128,7 +128,7 @@ Als u een bijdrage niet wil accepteren:
 * **Link naar relevante documentatie**, als u die heeft. Als u herhaalde verzoeken opmerkt voor dingen die u niet wilt accepteren, voegt u deze toe aan uw documentatie om te voorkomen dat u zichzelf herhaalt.
 * **Sluit het verzoek**
 
-Je hebt niet meer dan 1-2 zinnen nodig om te reageren. Als voorbeeld, als een gebruiker van [celery](https://github.com/celery/celery/) een Windows-gerelateerde fout meldde, @berkerpeksag [reageerde met (Engels)](https://github.com/celery/celery/issues/3383):
+Je hebt niet meer dan 1-2 zinnen nodig om te reageren. Als voorbeeld, als een gebruiker van [celery](https://github.com/celery/celery/) een Windows-gerelateerde fout meldde, @berkerpeksag [reageerde met](https://github.com/celery/celery/issues/3383):
 
 ![Celery screenshot](/assets/images/best-practices/celery.png)
 
@@ -136,78 +136,83 @@ Als de gedachte om nee te zeggen je bang maakt, ben je niet de enige. zoals @jes
 
 > Ik heb met onderhouders van verschillende open source-projecten gesproken, Mesos, Kubernetes, Chromium, en ze zijn het er allemaal over eens dat een van de moeilijkste aspecten van het zijn van een onderhouder is om "Nee" te zeggen tegen patches die je niet wilt.
 
-Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it.
+Voel je niet schuldig over het niet willen accepteren van iemands bijdrage. De eerste regel van open source, [volgens](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Nee is tijdelijk, ja is voor altijd."_ Hoewel empathie met het enthousiasme van een ander een goede zaak is, is het afwijzen van een bijdrage niet hetzelfde als het afwijzen van de persoon erachter.
 
-Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise.
+Als een bijdrage uiteindelijk niet goed genoeg is, bent u niet verplicht deze te accepteren. Wees vriendelijk en responsief wanneer mensen bijdragen aan uw project, maar accepteer alleen veranderingen waarvan u echt denkt dat ze uw project beter zullen maken. Hoe vaker je oefent om nee te zeggen, hoe gemakkelijker het wordt. Beloofd.
 
-### Be proactive
+### Wees proactief
 
-To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide.
+Om het aantal ongewenste bijdragen in de eerste plaats te verminderen, legt u het proces van uw project voor het indienen en accepteren van bijdragen uit in uw handleiding voor bijdragen.
 
-If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example:
+Als u te veel bijdragen van lage kwaliteit ontvangt, moet u van tevoren eisen dat bijdragers wat werk doen, bijvoorbeeld:
 
-* Fill out a issue or PR template/checklist
-* Open an issue before submitting a PR
+* Vul een probleem of PR-sjabloon/checklist in
+* Open een issue voordat je een PR opent
 
-If they don't follow your rules, close the issue immediately and point to your documentation.
+Als ze uw regels niet volgen, sluit u het probleem onmiddellijk af en verwijst u naar uw documentatie.
 
-While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage.
+Hoewel deze aanpak in het begin misschien onaardig aanvoelt, is proactief zijn eigenlijk goed voor beide partijen. Het verkleint de kans dat iemand veel verspilde uren werk in een pull-verzoek stopt dat u niet zult accepteren. En het maakt uw werklast gemakkelijker te beheren.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-  Ideally, explain to them and in a CONTRIBUTING.md file how they can get a better indication in the future on what would or would not be accepted before they begin the work.
+  Leg ze idealiter en in een CONTRIBUTING.md-bestand uit hoe ze in de toekomst een betere indicatie kunnen krijgen van wat wel of niet geaccepteerd zou worden voordat ze met het werk beginnen.
+  
+  _Ideally, explain to them and in a CONTRIBUTING.md file how they can get a better indication in the future on what would or would not be accepted before they begin the work._
   <p markdown="1" class="pquote-credit">
 — @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
   </p>
 </aside>
 
-Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively.
+Soms, als u nee zegt, kan uw potentiële bijdrager van streek raken of uw beslissing bekritiseren. Als hun gedrag vijandig wordt, [neem deze maatregelen om het positief te houden](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) of verwijder ze zelfs uit uw gemeenschap, als ze niet bereid zijn constructief samen te werken.
 
-### Embrace mentorship
+### Omarm mentorschap
 
-Maybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections.
+Misschien dient iemand in uw gemeenschap regelmatig bijdragen in die niet voldoen aan de normen van uw project. Het kan voor beide partijen frustrerend zijn om herhaaldelijk afwijzingen te doorstaan.
 
-If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first issue,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them.
+Als je ziet dat iemand enthousiast is over je project, maar een beetje gepolijst moet worden, wees dan geduldig. Leg in elke situatie duidelijk uit waarom hun bijdragen niet voldoen aan de verwachtingen van het project. Wijs ze op een gemakkelijkere of minder dubbelzinnige taak, zoals een probleem met de aanduiding _"good first issue"_ om ze te laten wennen. Als u tijd heeft, overweeg dan om hen te begeleiden door middel van hun eerste bijdrage, of zoek iemand anders in uw gemeenschap die misschien bereid is om hen te begeleiden.
 
 ## Maak gebruik van uw community
 
-You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work.
+U hoeft niet alles zelf te doen. De gemeenschap van uw project bestaat niet voor niets! Zelfs als u nog geen actieve bijdragersgemeenschap heeft, kunt u, als u veel gebruikers heeft, ze aan het werk zetten.
 
-### Share the workload
+### Deel de werklast
 
-If you're looking for others to pitch in, start by asking around.
+Als je op zoek bent naar anderen om bij te praten, begin dan met rond te vragen.
 
-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.
+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.
 
-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.
+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.
 
-Encouraging others to [share ownership of the project](../building-community/#share-ownership-of-your-project) can greatly reduce your own workload, as @lmccart discovered on her project, [p5.js](https://github.com/processing/p5.js).
+Anderen aanmoedigen om [aandeelhouderschap van het project](../building-community/#share-ownership-of-your-project) te nemen, kan je werklast verlagen, zoals @lmccart ondekte op haar project, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
-  I’d been saying, "Yeah, anyone can be involved, you don’t have to have a lot of coding expertise [...]." We had people sign up to come [to an event] and that’s when I was really wondering: is this true, what I’ve been saying? There are gonna be 40 people who show up, and it’s not like I can sit with each of them...But people came together, and it just sort of worked. As soon as one person got it, they could teach their neighbor.
+  Ik had gezegd: "Ja, iedereen kan erbij betrokken zijn, je hoeft niet veel codeerkennis te hebben [...]." Er waren mensen die zich hadden aangemeld om [naar een evenement] te komen en toen vroeg ik me echt af: is dit waar, wat ik heb gezegd? Er zullen 40 mensen komen opdagen, en het is niet alsof ik bij elk van hen kan zitten... Maar mensen kwamen samen, en het werkte gewoon. Zodra een persoon het kreeg, konden ze het hun buurman leren.
+  
   <p markdown="1" class="pquote-credit">
-—  @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+—  @lmccart, ["Wat betekent "open source"? P5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
   </p>
 </aside>
 
-If you need to step away from your project, either on hiatus or permanently, there's no shame in asking someone else to take over for you.
+Als u afstand moet nemen van uw project, hetzij op pauze, hetzij permanent, is het geen schande om iemand anders te vragen om het voor u over te nemen.
 
-If other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It's great that so many people want your project to live on!
+Als andere mensen enthousiast zijn over de richting, geef ze dan toegang of draag de controle formeel over aan iemand anders. Als iemand uw project heeft geforked en het actief elders onderhoudt, overweeg dan om te linken naar de fork van uw oorspronkelijke project. Het is geweldig dat zoveel mensen willen dat uw project voortleeft!
 
-@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), helped those goals live on even after he stepped away from the project:
+@progrium [merkte dat](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) het documentern van zijn visie voor het project, [Dokku](https://github.com/dokku/dokku), hielp die doelen voortleven, zelfs nadat hij het project had verlaten:
 
-> I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down.
+> Ik schreef een wikipagina die beschreef wat ik wilde en waarom ik het wilde. Om de een of andere reden kwam het als een verrassing voor mij dat de beheerders het project in die richting begonnen te bewegen! Is het precies gebeurd zoals ik het zou doen? Niet altijd. Maar het bracht het project nog steeds dichter bij wat ik had opgeschreven.
 
-### Let others build the solutions they need
+### Laat anderen de oplossingen bouwen die ze nodig hebben
 
-If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork.
+Als een potentiële bijdrager een andere mening heeft over wat uw project zou moeten doen, wilt u hem misschien voorzichtig aanmoedigen om aan zijn eigen fork te werken.
 
-Forking a project doesn't have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project's vision.
+Een project forceren hoeft geen slechte zaak te zijn. Projecten kunnen kopiëren en wijzigen is een van de beste dingen van open source. Door uw gemeenschapsleden aan te moedigen om aan hun eigen fork te werken, kan dit de creatieve uitlaatklep zijn die ze nodig hebben, zonder in strijd te zijn met de visie van uw project.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
-  I cater to the 80% use case. If you are one of the unicorns, please fork my work. I won't get offended! My public projects are almost always meant to solve the most common problems; I try to make it easy to go deeper by either forking my work or extending it.
+  Ik speel in op de use case van 80%. Als je een van de eenhoorns bent, fork mijn werk dan alsjeblieft. Ik zal niet beledigd worden! Mijn openbare projecten zijn bijna altijd bedoeld om de meest voorkomende problemen op te lossen; Ik probeer het gemakkelijk te maken om dieper te gaan door mijn werk te forceren of uit te breiden.
+  
+  _I cater to the 80% use case. If you are one of the unicorns, please fork my work. I won't get offended! My public projects are almost always meant to solve the most common problems; I try to make it easy to go deeper by either forking my work or extending it._
   <p markdown="1" class="pquote-credit">
 — @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
   </p>
diff --git a/_data/locales/nl.yml b/_data/locales/nl.yml
index b47af74e9df..072e1964f4d 100644
--- a/_data/locales/nl.yml
+++ b/_data/locales/nl.yml
@@ -26,6 +26,6 @@ nl:
       # Label for code octicon
       code_label: code
       # Label for love octicon
-      love_label: love
+      love_label: liefde
       # Label for the contributors link
-      friends_label: friends
+      friends_label: vrienden

From 77216dd09b7f2f0b9bf059607e637673c5814de3 Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Thu, 27 Aug 2020 08:14:40 +0200
Subject: [PATCH 064/749] Finished 'Best Practices'

---
 _articles/nl/best-practices.md | 64 +++++++++++++++++++---------------
 _articles/nl/index.min.html    |  1 -
 2 files changed, 35 insertions(+), 30 deletions(-)
 delete mode 100644 _articles/nl/index.min.html

diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index c3f0661a8ed..dbbd6cef11c 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -224,65 +224,71 @@ The same applies to a user who really wants a solution that you simply don't hav
 
 ## Breng de robots
 
-Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier.
+Net zoals er taken zijn waar andere mensen je mee kunnen helpen, zijn er ook taken die geen mens ooit zou moeten hoeven doen. Robots zijn je vrienden. Gebruik ze om uw leven als open source-onderhouder gemakkelijker te maken.
 
-### Require tests and other checks to improve the quality of your code
+### Vereis tests en andere controles om de kwaliteit van uw code te verbeteren
 
-One of the most important ways you can automate your project is by adding tests.
+Een van de belangrijkste manieren waarop u uw project kunt automatiseren, is door tests toe te voegen.
 
-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.
+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.
 
-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.
+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.
 
-If you add tests, make sure to explain how they work in your CONTRIBUTING file.
+Als u tests toevoegt, leg dan uit hoe ze werken in uw CONTRIBUTING-bestand.
 
 <aside markdown="1" class="pquote">
   <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.
+  Ik geloof dat tests nodig zijn voor alle code waar mensen aan werken. Als de code volledig en perfect correct was, zou het geen wijzigingen nodig hebben - we schrijven alleen code als er iets mis is, of dat nu "Het crasht" of "Het mist zo-en-zo-functie". En ongeacht de wijzigingen die u aanbrengt, zijn tests essentieel om eventuele regressies op te sporen die u per ongeluk zou kunnen introduceren.
+  
+  _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 gemeenschapsautomatisering"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
-### Use tools to automate basic maintenance tasks
+### Gebruik tools om eenvoudige onderhoudstaken te automatiseren
+
+Het goede nieuws over het onderhouden van een populair project is dat andere beheerders waarschijnlijk met soortgelijke problemen te maken hebben gehad en er een oplossing voor hebben gebouwd.
 
-The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for it.
+Er zijn een hoop [verschillende tools beschikbaar](https://github.com/showcases/tools-for-open-source) om te helpen om sommige aspecten te automatiseren. 
 
-There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples:
+Een paar voorbeelden:
 
-* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases
-* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
-* [Danger](https://github.com/danger/danger) helps automate code review
-* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information
-* [dependabot-preview](https://github.com/marketplace/dependabot-preview) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
+* [semantic-release](https://github.com/semantic-release/semantic-release) automatiseert uw releases
+* [mention-bot](https://github.com/facebook/mention-bot) vermeldt potentiële reviewers voor pull-aanvragen
+* [Danger](https://github.com/danger/danger) helpt bij het automatiseren van codebeoordeling
+* [no-response](https://github.com/probot/no-response) sluit issues af waarbij de auteur niet heeft gereageerd op een verzoek om meer informatie
+* [dependabot-preview](https://github.com/marketplace/dependabot-preview) controleert uw afhankelijkheidsbestanden elke dag op verouderde vereisten en opent individuele pull-verzoeken voor alle gevonden items
 
-For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.
+Voor bugrapporten en andere veelvoorkomende bijdragen heeft GitHub [Issue-sjablonen en Pull Request-sjablonen](https://github.com/blog/2111-issue-and-pull-request-templates), die u kunt maken om de communicatie die u ontvangt te stroomlijnen. @TalAter heeft een [Kies je eigen avonturengids](https://www.talater.com/open-source-templates/#/) gemaakt om u te helpen bij het schrijven van uw issue en PR-sjablonen.
 
-To manage your email notifications, you can set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize by priority.
+Om uw e-mailmeldingen te beheren, kunt u [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) instellen om te organiseren op prioriteit.
 
-If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept.
+Als je wat geavanceerder wilt worden, kunnen stijlgidsen en linters projectbijdragen standaardiseren en ze gemakkelijker te beoordelen en te accepteren maken.
 
-However, if your standards are too complicated, they can increase the barriers to contribution. Make sure you're only adding enough rules to make everyone's lives easier.
+Als uw normen echter te ingewikkeld zijn, kunnen ze de drempels voor bijdragen vergroten. Zorg ervoor dat u alleen voldoende regels toevoegt om het leven van iedereen gemakkelijker te maken.
 
-If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors.
+Als u niet zeker weet welke tools u moet gebruiken, kijk dan wat andere populaire projecten doen, vooral die in uw ecosysteem. Hoe ziet het contributieproces er bijvoorbeeld uit voor andere Node-modules? Het gebruik van vergelijkbare tools en benaderingen zal uw proces ook meer vertrouwd maken bij uw beoogde bijdragers.
 
 ## Het is oké om op pauze te drukken
 
-Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty.
+Open source-werk heeft je ooit vreugde gebracht. Misschien begint het je nu een ontwijkend of schuldig gevoel te geven.
 
-Perhaps you're feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up.
+Misschien heb je het gevoel overweldigd te zijn of krijg je steeds meer angst als je aan je projecten denkt. En ondertussen stapelen de problemen en pull-verzoeken zich op.
 
-Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project.
+Burn-out is een echt en doordringend probleem in open source-werk, vooral onder beheerders. Als open source-onderhouder is uw geluk een niet-onderhandelbare vereiste voor het voortbestaan van elk open source-project.
 
-Although it should go without saying, take a break! You shouldn't have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take [a month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) after 14 years of volunteer OSS work.
+Hoewel het vanzelfsprekend zou moeten zijn, neem een pauze! U hoeft niet te wachten tot u zich opgebrand voelt om op vakantie te gaan. @brettcannon, een Python-kernontwikkelaar, besloot [een maand lang op vakantie te gaan](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) na 14 jaar als vrijwillig OSS (Opensource) werk.
 
-Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work.
+Net als bij elk ander soort werk, zal het nemen van regelmatige pauzes je verfrist, blij en enthousiast over je werk houden.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
-  In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
+  Bij het onderhouden van WP-CLI heb ik ontdekt dat ik mezelf eerst gelukkig moet maken en duidelijke grenzen moet stellen aan mijn betrokkenheid. De beste balans die ik heb gevonden, is 2-5 uur per week, als onderdeel van mijn normale werkschema. Dit zorgt ervoor dat mijn betrokkenheid een passie blijft, en dat ik me niet te veel als werk voel. Omdat ik prioriteit geef aan de problemen waaraan ik werk, kan ik regelmatig vooruitgang boeken op wat ik denk dat het belangrijkst is.
+  
+  _In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important._
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["Mijn condoleances, u bent nu de onderhouder (_maintainer_) van een populair open source-project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
@@ -292,6 +298,6 @@ Doe uw best om ondersteuning voor uw gebruikers en gemeenschap te vinden terwijl
 
 Pauzes nemen geldt ook voor meer dan alleen vakanties. Als je in het weekend of tijdens werkuren geen open source-werk wilt doen, communiceer die verwachtingen dan aan anderen, zodat ze weten dat ze je niet lastig vallen.
 
-## Take care of yourself first!
+## Zorg eerst voor uzelf!
 
 Het onderhouden van een populair project vereist andere vaardigheden dan de eerdere groeifasen, maar het is niet minder lonend. Als onderhouder oefen je leiderschap en persoonlijke vaardigheden op een niveau dat maar weinig mensen ervaren. Hoewel het niet altijd gemakkelijk te beheren is, helpt het stellen van duidelijke grenzen en alleen aan te nemen waar je een prettig gevoel bij hebt, je gelukkig door voelt of wat je verfrist om productief te blijven.
diff --git a/_articles/nl/index.min.html b/_articles/nl/index.min.html
deleted file mode 100644
index d89f91b25b7..00000000000
--- a/_articles/nl/index.min.html
+++ /dev/null
@@ -1 +0,0 @@
---- layout: index title: Open source gids lang: nl permalink: /nl/ ---
\ No newline at end of file

From 1507fd90d6e4122aef4453d2e051f912d1a239a8 Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Thu, 27 Aug 2020 12:04:36 +0200
Subject: [PATCH 065/749] Article 'Building Community'

---
 _articles/nl/best-practices.md            |   2 +-
 _articles/nl/building-community.md        | 261 ++++++++++++----------
 _articles/nl/leadership-and-governance.md |   2 +-
 3 files changed, 141 insertions(+), 124 deletions(-)

diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index dbbd6cef11c..be4fd139e47 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -183,7 +183,7 @@ Een manier om nieuwe bijdragers te werven, is door expliciet [label problemen di
 
 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.
 
-Anderen aanmoedigen om [aandeelhouderschap van het project](../building-community/#share-ownership-of-your-project) te nemen, kan je werklast verlagen, zoals @lmccart ondekte op haar project, [p5.js](https://github.com/processing/p5.js).
+Anderen aanmoedigen om [aandeelhouderschap van het project](../building-community/#deel-het-eigendom-van-uw-project) te nemen, kan je werklast verlagen, zoals @lmccart ondekte op haar project, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/nl/building-community.md b/_articles/nl/building-community.md
index 9f5b6e43758..28c9ef3bded 100644
--- a/_articles/nl/building-community.md
+++ b/_articles/nl/building-community.md
@@ -1,12 +1,12 @@
 ---
 lang: nl
-title: Building Welcoming Communities
-description: Building a community that encourages people to use, contribute to, and evangelize your project.
+title: Bouwen aan gastvrije gemeenschappen
+description: Een gemeenschap opbouwen die mensen aanmoedigt om uw project te gebruiken, eraan bij te dragen en het te evangeliseren.
 class: building
 toc:
-  setting-your-project-up-for-success: "Setting your project up for success"
-  growing-your-community: "Growing your community"
-  resolving-conflicts: "Resolving conflicts"
+  setting-your-project-up-for-success: "Uw project opzetten voor succes"
+  growing-your-community: "Je community laten groeien"
+  resolving-conflicts: "Conflicten oplossen"
 order: 4
 image: /assets/images/cards/building.png
 related:
@@ -14,267 +14,284 @@ related:
   - coc
 ---
 
-## Setting your project up for success
+## Uw project opzetten voor succes
 
-You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around?
+Je hebt je project gelanceerd, je verspreidt het woord en mensen bekijken het. Geweldig! Nu, hoe zorg je ervoor dat ze blijven hangen?
 
-A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back.
+Een gastvrije gemeenschap is een investering in de toekomst en reputatie van uw project. Als je project net zijn eerste bijdragen begint te zien, begin dan met het geven van een positieve ervaring aan vroege bijdragers en zorg ervoor dat ze gemakkelijk terug blijven komen.
 
-### Make people feel welcome
+### Zorg ervoor dat mensen zich welkom voelen
 
-One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+Een manier om na te denken over de gemeenschap van uw project is door wat @MikeMcQuaid het [bijdrager trechter](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) noemt:
 
-![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+![bijdrager trechter](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
 
-As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more.
+Bedenk bij het opbouwen van uw community hoe iemand bovenaan de trechter (een potentiële gebruiker) theoretisch de weg naar de bodem kan vinden (een actieve onderhouder). Uw doel is om wrijving in elke fase van de bijdragerservaring te verminderen. Als mensen gemakkelijk winnen, voelen ze zich gestimuleerd om meer te doen.
 
-Start with your documentation:
+Begin met uw documentatie:
 
-* **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.
+* **Maak het voor iemand gemakkelijk om uw project te gebruiken.** [Een vriendelijke README](../starting-a-project/#writing-a-readme) 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/#writing-your-contributing-guidelines) 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.
+* [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.
 
-[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.
-
-* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
-* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
-* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
-* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#nee-leren-zeggen) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+* **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.
+* **Wees responsief.** Als u een maand lang niet op hun probleem reageert, is de kans groot dat ze uw project al zijn vergeten.
+* **Sta open voor de soorten bijdragen die u accepteert.** Veel bijdragers beginnen met een bugrapport of een kleine oplossing. Er zijn [veel manieren om bij te dragen](../how-to-contribute/#what-it-means-to-contribute) aan een project. Laat mensen helpen zoals ze willen helpen.
+* **Als er een bijdrage is waar u het niet mee eens bent,** bedank ze voor hun idee, en [vertel waarom](../best-practices/#nee-leren-zeggen) het niet past in de scope van het project en linkt naar relevante documentatie als je die hebt.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns.
+  Bijdragen aan open source is voor sommigen gemakkelijker dan voor anderen. Er is veel angst om te worden uitgescholden omdat ze iets niet goed doen of gewoon niet passen. (...) Door bijdragers een plek te geven om bij te dragen met een zeer lage technische vaardigheid (documentatie, afwaardering van webinhoud, enz.), Kunt u aanzienlijk verminderen die zorgen.
+  
+  _Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns._
   <p markdown="1" class="pquote-credit">
-— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+— @mikeal, ["Een bijdrage leveren in moderne open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
   </p>
 </aside>
 
-The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute.
+De meeste open source-bijdragers zijn "casual bijdragers": mensen die slechts af en toe bijdragen aan een project. Een toevallige bijdrager heeft misschien geen tijd om volledig op de hoogte te zijn van uw project, dus het is uw taak om het hem gemakkelijk te maken om bij te dragen.
 
-Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself.
+Andere bijdragers aanmoedigen is ook een investering in uzelf. Als u uw grootste fans de kracht geeft om te rennen met het werk waar ze enthousiast over zijn, is er minder druk om alles zelf te doen.
 
-### Document everything
+### Documenteer alles
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
+  Ben je ooit naar een (tech-) evenement geweest waar je niemand kende, maar iedereen leek in groepen te staan en te chatten als oude vrienden? (...) Stel je nu voor dat je wilt bijdragen aan een open source-project, maar je begrijpt niet waarom of hoe dit gebeurt.
+  
+  _Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening._
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Duurzame open source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
-When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public.
+Wanneer u aan een nieuw project begint, kan het natuurlijk aanvoelen om uw werk privé te houden. Maar open source-projecten gedijen goed wanneer u uw proces openbaar documenteert.
 
-When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed.
+Als je dingen opschrijft, kunnen er bij elke stap meer mensen deelnemen. U kunt misschien hulp krijgen bij iets waarvan u niet eens wist dat u het nodig had.
 
-Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public.
+Dingen opschrijven is meer dan alleen technische documentatie. Elke keer dat u de neiging voelt om iets op te schrijven of uw project privé te bespreken, vraag uzelf dan af of u het openbaar kunt maken.
 
-Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions.
+Wees transparant over de roadmap van uw project, de soorten bijdragen die u zoekt, hoe bijdragen worden beoordeeld of waarom u bepaalde beslissingen hebt genomen.
 
-If you notice multiple users running into the same problem, document the answers in the README.
+Als u merkt dat meerdere gebruikers tegen hetzelfde probleem aanlopen, documenteer de antwoorden dan in de README.
 
-For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you.
+Overweeg voor vergaderingen uw aantekeningen of afhaalrestaurants te publiceren in een relevant nummer. De feedback die u van dit transparantieniveau krijgt, zal u misschien verbazen.
 
-Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on.
+Alles documenteren is ook van toepassing op het werk dat u doet. Als u aan een substantiële update van uw project werkt, plaatst u dit in een pull-aanvraag en markeert u het als een work in progress (_Werk in uitvoering_) (WIP). Op die manier kunnen andere mensen zich al vroeg bij het proces betrokken voelen.
 
-### Be responsive
+### Wees responsief
 
-As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started.
+Als jij [je project promoot](../finding-users), zullen mensen feedback voor je hebben. Ze hebben misschien vragen over hoe dingen werken of hebben hulp nodig om aan de slag te gaan.
 
-Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating.
+Probeer responsief te zijn wanneer iemand een probleem issue, een pull-verzoek indient of een vraag stelt over uw project. Als je snel reageert, zullen mensen het gevoel hebben dat ze deel uitmaken van een dialoog en zullen ze enthousiaster zijn over deelname.
 
-Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466):
+Zelfs als u het verzoek niet onmiddellijk kunt beoordelen, helpt het vroegtijdig erkennen van het verzoek de betrokkenheid te vergroten. Hier is hoe @tdreyno reageerde op een pull-verzoek op [Middleman](https://github.com/middleman/middleman/pull/1466):
 
 ![Middleman pull request](/assets/images/building-community/middleman_pr.png)
 
-[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution.
+[Een Mozilla-studie zag dat](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) bijdragers die binnen 48 uur codebeoordelingen ontvingen, een veel hoger rendement hadden en een veel hogere bijdrage.
 
-Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project.
+Gesprekken over uw project kunnen ook plaatsvinden op andere plaatsen op internet, zoals Stack Overflow, Twitter of Reddit. U kunt op sommige van deze plaatsen meldingen instellen, zodat u wordt gewaarschuwd wanneer iemand uw project noemt.
 
-### Give your community a place to congregate
+### Geef uw gemeenschap een plek om samen te komen
 
-There are two reasons to give your community a place to congregate.
+Er zijn twee redenen om uw gemeenschap een plek te geven om samen te komen.
 
-The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate.
+De eerste reden is voor hen. Help mensen elkaar te leren kennen. Mensen met gemeenschappelijke interesses zullen onvermijdelijk een plek willen hebben om erover te praten. En als communicatie openbaar en toegankelijk is, kan iedereen archieven uit het verleden lezen om op de hoogte te blijven en deel te nemen.
 
-The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel.
+De tweede reden is voor jou. Als je mensen geen openbare plek geeft om over je project te praten, zullen ze waarschijnlijk rechtstreeks contact met je opnemen. In het begin lijkt het misschien eenvoudig genoeg om "voor een keer" op privéberichten te reageren. Maar na verloop van tijd, vooral als uw project populair wordt, zult u zich uitgeput voelen. Weersta de verleiding om privé met mensen over uw project te communiceren. Verwijs ze in plaats daarvan naar een aangewezen openbaar kanaal.
 
-Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above!
+Openbare communicatie kan zo simpel zijn als mensen sturen om een ​​probleem te openen in plaats van u rechtstreeks te e-mailen of te reageren op uw blog. Je kunt ook een mailinglijst opzetten, of een Twitter-account, Slack- of IRC-kanaal maken zodat mensen over je project kunnen praten. Of probeer al het bovenstaande!
 
-[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members:
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) reserveert om de week kantooruren om leden van de gemeenschap te helpen:
 
-> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.
+> Kops heeft ook om de week tijd vrijgemaakt om hulp en begeleiding te bieden aan de gemeenschap. De beheerders van Kops zijn overeengekomen om tijd vrij te maken die specifiek is bedoeld voor het werken met nieuwkomers, het helpen met PR's en het bespreken van nieuwe functies.
 
-Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address.
+Uitzonderingen op openbare communicatie zijn: 1) beveiligingskwesties en 2) schendingen van gevoelige gedragscodes. U moet altijd een manier hebben waarop mensen deze problemen privé kunnen melden. Als u uw persoonlijke e-mailadres niet wilt gebruiken, stelt u een speciaal e-mailadres in.
 
-## Growing your community
+## Je community laten groeien
 
-Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction.
+Gemeenschappen zijn buitengewoon krachtig. Die macht kan een zegen of een vloek zijn, afhankelijk van hoe u die uitoefent. Naarmate de gemeenschap van uw project groeit, zijn er manieren om het te helpen een bouwkracht te worden, geen vernietiging.
 
-### Don't tolerate bad actors
+### Sta geen slechte acteurs toe
 
-Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others.
+Elk populair project zal onvermijdelijk mensen aantrekken die uw gemeenschap schaden in plaats van helpen. Ze kunnen onnodige debatten beginnen, kibbelen over triviale kenmerken of anderen pesten.
 
-Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave.
+Doe je best om een nultolerantiebeleid te voeren ten aanzien van dit soort mensen. Als dit niet wordt aangevinkt, zullen negatieve mensen andere mensen in uw gemeenschap ongemakkelijk maken. Ze kunnen zelfs vertrekken.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
-  The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.
+  De waarheid is dat het hebben van een ondersteunende gemeenschap de sleutel is. Ik zou dit werk nooit kunnen doen zonder de hulp van mijn collega's, vriendelijke internetvreemdelingen en spraakzame IRC-kanalen. (...) Neem geen genoegen met minder. Neem geen genoegen met klootzakken.
+  
+  _The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes._
   <p markdown="1" class="pquote-credit">
 — @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
   </p>
 </aside>
 
-Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
+Regelmatige debatten over triviale aspecten van uw project leiden anderen, waaronder u, af om zich op belangrijke taken te concentreren. Nieuwe mensen die naar uw project komen, kunnen deze gesprekken zien en willen niet deelnemen.
 
-When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations.
+Als u negatief gedrag in uw project ziet gebeuren, meld dit dan in het openbaar. Leg op vriendelijke maar krachtige toon uit waarom hun gedrag niet acceptabel is. Als het probleem aanhoudt, kan het nodig zijn [om te vragen om te vertrekken](../code-of-conduct/#enforcing-your-code-of-conduct). Uw [gedragsregels](../code-of-conduct/) kan een constructieve gids zijn voor deze gesprekken.
 
-### Meet contributors where they're at
+### Ontmoet bijdragers waar ze zijn
 
-Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need.
+Goede documentatie wordt alleen maar belangrijker naarmate uw gemeenschap groeit. Toevallige bijdragers, die anders misschien niet bekend zijn met uw project, lezen uw documentatie om snel de context te krijgen die ze nodig hebben.
 
-In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors.
+Vertel nieuwe bijdragers in uw CONTRIBUTORS-bestand expliciet hoe ze aan de slag kunnen. Misschien wilt u voor dit doel zelfs een speciale sectie maken. [Django](https://github.com/django/django), heeft bijvoorbeeld een speciale bestemmingspagina om nieuwe bijdragers te verwelkomen.
 
-![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
+![Django niewe bijdragers pagina](/assets/images/building-community/django_new_contributors.png)
 
-In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started.
+Label in uw issue wachtrij bugs die geschikt zijn voor verschillende soorten bijdragers: bijvoorbeeld [_"alleen first timers"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentatie"_. [Deze labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) maken het gemakkelijk voor iemand die nieuw is bij uw project om snel uw problemen te scannen en aan de slag te gaan.
 
-Finally, use your documentation to make people feel welcome at every step of the way.
+Gebruik ten slotte uw documentatie om ervoor te zorgen dat mensen zich bij elke stap welkom voelen.
 
-You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration.
+U zult nooit contact hebben met de meeste mensen die op uw project terechtkomen. Er kunnen bijdragen zijn die u niet hebt ontvangen omdat iemand zich geïntimideerd voelde of niet wist waar hij moest beginnen. Zelfs een paar vriendelijke woorden kunnen iemand ervan weerhouden uw project gefrustreerd te verlaten.
 
-For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+Hier is bijvoorbeeld hoe [Rubinius](https://github.com/rubinius/rubinius/) startte [zijn bijdrage gids](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
 
-> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
+> Om te beginnen willen we u bedanken voor het gebruik van Rubinius. Dit project is een werk van liefde, en we waarderen alle gebruikers die bugs ontdekken, prestatieverbeteringen aanbrengen en helpen met documentatie. Elke bijdrage is zinvol, dus bedankt voor je deelname. Dat gezegd hebbende, zijn hier enkele richtlijnen die we u vragen te volgen, zodat we uw probleem met succes kunnen oplossen.
 
-### Share ownership of your project
+### Deel het eigendom van uw project
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
-  Your leaders will have different opinions, as all healthy communities should! However, you need to take steps to ensure the loudest voice doesn't always win by tiring people out, and that less prominent and minority voices are heard.
+  Je leiders zullen verschillende meningen hebben, zoals alle gezonde gemeenschappen zouden moeten! U moet echter maatregelen nemen om ervoor te zorgen dat de luidste stem niet altijd wint door mensen uit te putten, en dat minder prominente stemmen en minderheidsstemmen worden gehoord.
+
+  _Your leaders will have different opinions, as all healthy communities should! However, you need to take steps to ensure the loudest voice doesn't always win by tiring people out, and that less prominent and minority voices are heard._
+
   <p markdown="1" class="pquote-credit">
-— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+— @sagesharp, ["Wat maakt een goede gemeenschap?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
   </p>
 </aside>
 
-People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around.
+Mensen zijn enthousiast om bij te dragen aan projecten als ze een gevoel van eigenaarschap voelen. Dat betekent niet dat u de visie van uw project moet overdragen of bijdragen moet accepteren die u niet wilt. Maar hoe meer je anderen erkent, hoe meer ze blijven hangen.
 
-See if you can find ways to share ownership with your community as much as possible. Here are some ideas:
+Kijk of je manieren kunt vinden om het eigendom zoveel mogelijk met je gemeenschap te delen. Hier zijn enkele ideeën:
 
-* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself.
+* **Weersta het oplossen van gemakkelijke (niet-kritieke) bugs.** Gebruik ze in plaats daarvan als kansen om nieuwe bijdragers te werven of iemand te begeleiden die een bijdrage wil leveren. In het begin lijkt het misschien onnatuurlijk, maar uw investering zal zich na verloop van tijd terugbetalen. @Michaeljoseph vroeg bijvoorbeeld een bijdrager om een pull-verzoek in te dienen voor een [Cookiecutter](https://github.com/audreyr/cookiecutter) issue hieronder, in plaats van het zelf te repareren.
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
+* **Start een CONTRIBUTORS- of AUTHORS-bestand in uw project** met een lijst van iedereen die aan uw project heeft bijgedragen, zoals [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) doet.
 
-* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+* Als je een omvangrijke community hebt, **stuur dan een nieuwsbrief of schrijf een blogpost** om bijdragers te bedanken. Rust's [Deze week in Rust](https://this-week-in-rust.org/) en Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) zijn twee goede voorbeelden.
 
-* **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.
+* **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.
 
-* 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.
+* 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.
 
-The reality is that [most projects only have](https://peerj.com/preprints/1233.pdf) 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.
+De realiteit is dat bij [de meeste projecten]
+(https://peerj.com/preprints/1233.pdf) 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.
 
-While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help.
+Hoewel je misschien niet altijd iemand vindt om de oproep te beantwoorden, vergroot het geven van een signaal de kans dat andere mensen meedoen. En hoe eerder je begint, hoe eerder mensen kunnen helpen.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
-  \[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it.
+  \[Het is in uw belang\] om bijdragers te werven die plezier hebben en die in staat zijn om de dingen te doen die u niet bent. Houd je van coderen, maar beantwoord je geen problemen? Identificeer vervolgens die personen in uw gemeenschap die dat wel doen en laat ze het hebben.
+  
+  _\[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it._
   <p markdown="1" class="pquote-credit">
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Gastvrije gemeenschappen"](http://hood.ie/blog/welcoming-communities.html)
   </p>
 </aside>
 
-## Resolving conflicts
+## Conflicten oplossen
 
-In the early stages of your project, making major decisions is easy. When you want to do something, you just do it.
+In de vroege stadia van uw project is het nemen van belangrijke beslissingen eenvoudig. Als je iets wilt doen, doe het dan gewoon.
 
-As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own.
+Naarmate uw project populairder wordt, zullen meer mensen belangstelling tonen voor de beslissingen die u neemt. Zelfs als je geen grote gemeenschap van bijdragers hebt, als je project veel gebruikers heeft, zul je merken dat mensen een afweging maken bij beslissingen of hun eigen problemen aan de orde stellen.
 
-For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address.
+Als je een vriendelijke, respectvolle gemeenschap hebt ontwikkeld en je processen openlijk hebt gedocumenteerd, zou je gemeenschap voor het grootste deel een oplossing moeten kunnen vinden. Maar soms kom je een probleem tegen dat wat moeilijker op te lossen is.
 
-### Set the bar for kindness
+### Leg de lat voor vriendelijkheid
 
-When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you.
+Wanneer uw gemeenschap worstelt met een moeilijk probleem, kunnen de gemoederen stijgen. Mensen kunnen boos of gefrustreerd worden en het op elkaar of op jou afkraken.
 
-Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive.
+Het is jouw taak als onderhouder om te voorkomen dat deze situaties escaleren. Zelfs als je een uitgesproken mening over het onderwerp hebt, probeer dan de positie van moderator of facilitator in te nemen, in plaats van de strijd aan te gaan en je mening te benadrukken. Als iemand onaardig is of het gesprek monopoliseert, [reageer meteen](../building-community/#sta-geen-slechte-acteurs-toe) discussies netjes en productief houden.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
-  As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
+  Als projectonderhouder is het uiterst belangrijk om respectvol te zijn voor uw bijdragers. Ze vatten wat je zegt vaak heel persoonlijk op.
+  
+  _As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally._
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Wees hartelijk of ga op weg"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
-Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly.
+Andere mensen vragen je om advies. Geef een goed voorbeeld. U kunt nog steeds teleurstelling, ongeluk of bezorgdheid uiten, maar doe dit rustig.
 
-Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you.
+Het hoofd koel houden is niet eenvoudig, maar leiderschap tonen verbetert de gezondheid van uw gemeenschap. Het internet dankt je.
 
-### Treat your README as a constitution
+### Behandel uw README als een grondwet
 
-Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion.
+Uw README is [meer dan alleen een reeks instructies](../starting-a-project/#writing-a-readme). Het is ook een plek om te praten over uw doelen, productvisie en roadmap. Als mensen overdreven gefocust zijn op het bespreken van de waarde van een bepaalde functie, kan het helpen om je README opnieuw te bekijken en te praten over de hogere visie van je project. Focussen op je README maakt het gesprek ook onpersoonlijk, zodat je een constructieve discussie kunt voeren.
 
-### Focus on the journey, not the destination
+### Concentreer u op de reis, niet op de bestemming
 
-Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns.
+Sommige projecten gebruiken een stemproces om belangrijke beslissingen te nemen. Hoewel stemmen op het eerste gezicht verstandig zijn, legt het de nadruk op het vinden van een 'antwoord' in plaats van naar elkaars zorgen te luisteren en erop in te gaan.
 
-Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place.
+Stemmen kan politiek worden, waarbij leden van de gemeenschap onder druk gezet worden om elkaar goed te doen of op een bepaalde manier te stemmen. Ook niet iedereen stemt of het de [stille meerderheid](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) is in uw gemeenschap, of huidige gebruikers die niet wisten dat er gestemd werd.
 
-Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus.
+Soms is stemmen een noodzakelijk kwaad. Zoveel als je kunt, leg echter de nadruk op ["consensus zoeken"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) in plaats van consensus.
 
-Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion.
+In het kader van een proces voor het zoeken naar consensus, bespreken leden van de gemeenschap belangrijke zorgen totdat ze vinden dat ze voldoende zijn gehoord. Als er nog maar kleine zorgen zijn, gaat de gemeenschap vooruit. "Consensus zoeken" erkent dat een gemeenschap misschien niet in staat zal zijn om tot een perfect antwoord te komen. In plaats daarvan geeft het prioriteit aan luisteren en discussiëren.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
-  Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
+  Een deel van de reden waarom er geen stemsysteem bestaat voor Atom Issues is dat het Atom-team niet in alle gevallen een stemsysteem gaat volgen. Soms moeten we kiezen wat we vinden dat juist is, zelfs als het niet populair is. (...) Wat ik kan bieden en beloven te doen ... is dat het mijn taak is om naar de gemeenschap te luisteren.
+  
+  _Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community._
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on [Atom's besluitvormingsproces](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
   </p>
 </aside>
 
-Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions.
+Zelfs als u niet echt een consensuszoekproces toepast, is het als projectonderhouder belangrijk dat mensen weten dat u luistert. Door ervoor te zorgen dat andere mensen zich gehoord voelen en zich ertoe verbinden hun zorgen op te lossen, kunnen gevoelige situaties aanzienlijk worden verspreid. Volg vervolgens uw woorden met daden.
 
-Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution.
+Overhaast geen beslissing om een oplossing te hebben. Zorg ervoor dat iedereen zich gehoord voelt en dat alle informatie openbaar is gemaakt voordat u naar een oplossing gaat.
 
-### Keep the conversation focused on action
+### Houd het gesprek gericht op actie
 
-Discussion is important, but there is a difference between productive and unproductive conversations.
+Discussie is belangrijk, maar er is een verschil tussen productieve en onproductieve gesprekken.
 
-Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down.
+Moedig discussie aan zolang deze actief naar een oplossing toe evolueert. Als het duidelijk is dat een gesprek wegkwijnt of afwijkt van het onderwerp, prikkels persoonlijk worden of mensen kibbelen over kleine details, is het tijd om het af te sluiten.
 
-Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues.
+Deze gesprekken laten doorgaan is niet alleen slecht voor het betreffende probleem, maar ook slecht voor de gezondheid van uw gemeenschap. Het geeft een bericht dat dit soort gesprekken is toegestaan ​​of zelfs aangemoedigd, en het kan mensen ontmoedigen om toekomstige problemen aan de orde te stellen of op te lossen.
 
-With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_
+Stel uzelf bij elk punt dat door u of anderen wordt gemaakt, de vraag: _"Hoe brengt dit ons dichter bij een oplossing?"_
 
-If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation.
+Als het gesprek begint te ontrafelen, vraag dan aan de groep: _"Welke stappen moeten we hierna nemen?"_ Om het gesprek opnieuw te focussen.
 
-If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it.
+Als een gesprek duidelijk nergens heen gaat, er geen duidelijke acties kunnen worden ondernomen, of als de juiste actie al is ondernomen, sluit dan het probleem af en leg uit waarom je het hebt gesloten.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-  Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
+  Een draad naar bruikbaarheid leiden zonder opdringerig te zijn, is een kunst. Het zal niet werken om mensen simpelweg te vermanen om te stoppen met het verspillen van hun tijd, of om hen te vragen niet te posten tenzij ze iets constructiefs te melden hebben. (...) In plaats daarvan moet je voorwaarden stellen voor verdere vooruitgang: geef mensen een route, een pad om te volgen dat leidt tot de resultaten die je wilt, maar zonder dat het lijkt alsof je gedrag dicteert.
+  
+  _Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct._
   <p markdown="1" class="pquote-credit">
-— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+— @kfogel, [_OSS Produceren_](https://producingoss.com/en/producingoss.html#common-pitfalls)
   </p>
 </aside>
 
-### Pick your battles wisely
+### Kies je gevechten verstandig
 
-Context is important. Consider who is involved in the discussion and how they represent the rest of the community.
+Context is belangrijk. Bedenk wie er bij de discussie betrokken is en hoe zij de rest van de gemeenschap vertegenwoordigen.
 
-Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices.
+Is iedereen in de gemeenschap boos over of zelfs betrokken bij deze kwestie? Of is het een eenzame onruststoker? Vergeet niet rekening te houden met uw stille gemeenschapsleden, niet alleen met de actieve stemmen.
 
-If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread.
+Als het probleem niet de bredere behoeften van uw gemeenschap weerspiegelt, moet u misschien de zorgen van een paar mensen erkennen. Als dit een terugkerend probleem is zonder een duidelijke oplossing, verwijs ze dan naar eerdere discussies over het onderwerp en sluit de thread.
 
-### Identify a community tiebreaker
+### Identificeer een schiftingspercentage van de gemeenschap
 
-With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker.
+Met een goede instelling en duidelijke communicatie zijn de meeste moeilijke situaties op te lossen. Maar zelfs in een productief gesprek kan er eenvoudig een verschil in mening zijn over hoe verder te gaan. Identificeer in deze gevallen een persoon of een groep mensen die als schiftingsvariant kunnen dienen.
 
-A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it.
+Een doorslag kan de primaire instandhouder van het project zijn, of het kan een kleine groep mensen zijn die een beslissing neemt op basis van stemmen. Idealiter heb je een schiftingspercentage en het bijbehorende proces geïdentificeerd in een GOVERNANCE-bestand voordat je het ooit hoeft te gebruiken.
 
-Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible.
+Je schifting zou een laatste redmiddel moeten zijn. Kwesties die verdeeldheid zaaien, zijn een kans voor uw gemeenschap om te groeien en te leren. Omarm deze kansen en gebruik een samenwerkingsproces om waar mogelijk tot een oplossing te komen.
 
-## Community is the ❤️ of open source
+## Community is het ❤️ van open source
 
-Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience.
+Gezonde, bloeiende gemeenschappen voeden de duizenden uren die elke week in open source worden gestoken. Veel bijdragers wijzen op andere mensen als de reden om wel of niet aan open source te werken. Door constructief te leren hoe je die kracht kunt aanboren, help je iemand daarbuiten een onvergetelijke open source-ervaring te hebben.
diff --git a/_articles/nl/leadership-and-governance.md b/_articles/nl/leadership-and-governance.md
index 4b4d7963bb1..1dcb6feadcc 100644
--- a/_articles/nl/leadership-and-governance.md
+++ b/_articles/nl/leadership-and-governance.md
@@ -82,7 +82,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://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/#deel-het-eigendom-van-uw-project).
 
 ## When should I give someone commit access?
 

From 54e6f184c300922a81ce1d0898a511e99a0b8ee6 Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Thu, 27 Aug 2020 12:27:03 +0200
Subject: [PATCH 066/749] Article 'Code of Conduct'

---
 _articles/nl/building-community.md |  2 +-
 _articles/nl/code-of-conduct.md    | 99 ++++++++++++++++--------------
 2 files changed, 53 insertions(+), 48 deletions(-)

diff --git a/_articles/nl/building-community.md b/_articles/nl/building-community.md
index 28c9ef3bded..82be15f49b5 100644
--- a/_articles/nl/building-community.md
+++ b/_articles/nl/building-community.md
@@ -132,7 +132,7 @@ Doe je best om een nultolerantiebeleid te voeren ten aanzien van dit soort mense
 
 Regelmatige debatten over triviale aspecten van uw project leiden anderen, waaronder u, af om zich op belangrijke taken te concentreren. Nieuwe mensen die naar uw project komen, kunnen deze gesprekken zien en willen niet deelnemen.
 
-Als u negatief gedrag in uw project ziet gebeuren, meld dit dan in het openbaar. Leg op vriendelijke maar krachtige toon uit waarom hun gedrag niet acceptabel is. Als het probleem aanhoudt, kan het nodig zijn [om te vragen om te vertrekken](../code-of-conduct/#enforcing-your-code-of-conduct). Uw [gedragsregels](../code-of-conduct/) kan een constructieve gids zijn voor deze gesprekken.
+Als u negatief gedrag in uw project ziet gebeuren, meld dit dan in het openbaar. Leg op vriendelijke maar krachtige toon uit waarom hun gedrag niet acceptabel is. Als het probleem aanhoudt, kan het nodig zijn [om te vragen om te vertrekken](../code-of-conduct/#handhaving-van-uw-gedragscode). Uw [gedragsregels](../code-of-conduct/) kan een constructieve gids zijn voor deze gesprekken.
 
 ### Ontmoet bijdragers waar ze zijn
 
diff --git a/_articles/nl/code-of-conduct.md b/_articles/nl/code-of-conduct.md
index e70bd41632e..d59157706bf 100644
--- a/_articles/nl/code-of-conduct.md
+++ b/_articles/nl/code-of-conduct.md
@@ -1,14 +1,14 @@
 ---
 lang: nl
-title: Your Code of Conduct
-description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct.
+title: Uw gedragscode
+description: Faciliteer gezond en constructief gedrag in de gemeenschap door een gedragscode aan te nemen en af te dwingen.
 class: coc
 toc:
-  why-do-i-need-a-code-of-conduct: "Why do I need a code of conduct?"
-  establishing-a-code-of-conduct: "Establishing a code of conduct"
-  deciding-how-youll-enforce-your-code-of-conduct: "Deciding how you’ll enforce your code of conduct"
-  enforcing-your-code-of-conduct: "Enforcing your code of conduct"
-  your-responsibilities-as-a-maintainer: "Your responsibilities as a maintainer"
+  why-do-i-need-a-code-of-conduct: "Waarom heb ik een gedragscode nodig?"
+  establishing-a-code-of-conduct: "Opstellen van een gedragscode"
+  deciding-how-youll-enforce-your-code-of-conduct: "Beslissen hoe u uw gedragscode handhaaft"
+  enforcing-your-code-of-conduct: "Handhaving van uw gedragscode"
+  your-responsibilities-as-a-maintainer: "Uw verantwoordelijkheden als open source-onderhouder"
 order: 8
 image: /assets/images/cards/coc.png
 related:
@@ -16,15 +16,15 @@ related:
   - leadership
 ---
 
-## Why do I need a code of conduct?
+## Waarom heb ik een gedragscode nodig?
 
-A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.
+Een gedragscode is een document waarin de verwachtingen voor het gedrag van de deelnemers aan uw project worden vastgelegd. Door een gedragscode aan te nemen en af te dwingen, kunt u een positieve sociale sfeer voor uw gemeenschap creëren.
 
-Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.
+Gedragscodes helpen niet alleen uw deelnemers te beschermen, maar ook uzelf. Als u een project onderhoudt, zult u merken dat een onproductieve houding van andere deelnemers u na verloop van tijd uitgeput of ongelukkig kan maken met uw werk.
 
-A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with.
+Een gedragscode stelt je in staat om gezond, constructief gemeenschapsgedrag te faciliteren. Door proactief te zijn, wordt de kans kleiner dat u of anderen vermoeid raken door uw project, en kunt u actie ondernemen wanneer iemand iets doet waar u het niet mee eens bent.
 
-## Establishing a code of conduct
+## Opstellen van een gedragscode
 
 Try to establish a code of conduct as early as possible: ideally, when you first create your project.
 
@@ -41,80 +41,85 @@ The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Ci
 
 Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
 
-## Deciding how you'll enforce your code of conduct
+## Beslissen hoe u uw gedragscode handhaaft
 
 <aside markdown="1" class="pquote">
-  A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
+  Een gedragscode die niet (of niet) kan worden afgedwongen, is erger dan helemaal geen gedragscode: het geeft de boodschap af dat de waarden in de gedragscode niet echt belangrijk of gerespecteerd worden in uw gemeenschap.
+  
+  _A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community._
   <p markdown="1" class="pquote-credit">
 — [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
   </p>
 </aside>
 
-You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:
+U moet uitleggen hoe uw gedragscode wordt gehandhaafd **_voordat_** een overtreding plaatsvindt. Er zijn verschillende redenen om dit te doen:
 
-* It demonstrates that you are serious about taking action when it's needed.
+* Het toont aan dat u serieus actie onderneemt wanneer dat nodig is.
 
-* Your community will feel more reassured that complaints actually get reviewed.
+* Uw gemeenschap zal zich meer gerustgesteld voelen dat klachten daadwerkelijk worden beoordeeld.
 
-* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.
+* U verzekert uw gemeenschap ervan dat het beoordelingsproces eerlijk en transparant is, mochten ze ooit worden onderzocht op een overtreding.
 
-You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
+Geef mensen een privé manier (zoals een e-mailadres) om een schending van de gedragscode te melden en leg uit wie die melding ontvangt. Het kan een onderhouder, een groep beheerders of een werkgroep gedragscode zijn.
 
-Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+Vergeet niet dat iemand misschien een overtreding wil melden over een persoon die deze meldingen ontvangt. Geef ze in dat geval de mogelijkheid om overtredingen aan iemand anders te melden. Bijvoorbeeld @ctb en @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
-> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+> Gevallen van beledigend, intimiderend of anderszins onaanvaardbaar gedrag kunnen worden gemeld door een e-mail te sturen naar **khmer-project@idyll.org**, dat alleen naar C. Titus Brown en Michael R. Crusoe gaat. Om een probleem te melden waarbij een van hen betrokken is, kunt u een e-mail sturen naar **Judi Brown Clarke, Ph.D.** de Diversity Director van het BEACON Center for the Study of Evolution in Action, een NSF Center for Science and Technology.
+>
+> _Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*_
 
-For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+Voor inspiratie, bekijk Django's [handhavingshandboek](https://www.djangoproject.com/conduct/enforcement-manual/) (hoewel je zoiets alomvattends misschien niet nodig hebt, afhankelijk van de grootte van je project).
 
-## Enforcing your code of conduct
+## Handhaving van uw gedragscode
 
-Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up.
+Soms, ondanks uw beste inspanningen, zal iemand iets doen dat in strijd is met deze code. Er zijn verschillende manieren om negatief of schadelijk gedrag aan te pakken als het zich voordoet.
 
-### Gather information about the situation
+### Verzamel informatie over de situatie
 
-Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment.
+Behandel de stem van elk communitylid net zo belangrijk als die van jou. Als u een melding ontvangt dat iemand de gedragscode heeft geschonden, neem deze dan serieus en onderzoek de zaak, zelfs als deze niet overeenkomt met uw eigen ervaring met die persoon. Door dit te doen, geeft u uw gemeenschap aan dat u hun perspectief waardeert en hun oordeel vertrouwt.
 
-The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context.
+Het gemeenschapslid in kwestie kan een recidiverende overtreder zijn die anderen consequent een ongemakkelijk gevoel geeft, of ze hebben misschien maar één keer iets gezegd of gedaan. Beide kunnen aanleiding zijn om actie te ondernemen, afhankelijk van de context.
 
-Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
+Geef uzelf de tijd om te begrijpen wat er is gebeurd voordat u reageert. Lees de eerdere opmerkingen en gesprekken van de persoon door om beter te begrijpen wie ze zijn en waarom ze zich misschien op zo'n manier hebben gedragen. Probeer andere dan de uwe perspectieven te verzamelen over deze persoon en zijn gedrag.
 
 <aside markdown="1" class="pquote">
-  Don’t get pulled into an argument. Don’t get sidetracked into dealing with someone else’s behavior before you’ve finished dealing with the matter at hand. Focus on what you need.
+  Laat je niet verleiden tot ruzie. Laat u niet op een zijspoor zetten om met het gedrag van iemand anders om te gaan voordat u klaar bent met het afhandelen van de kwestie. Concentreer u op wat u nodig heeft.
+  
   <p markdown="1" class="pquote-credit">
-— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+— Stephanie Zvan, ["Dus je hebt een beleid. Wat nu?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
   </p>
 </aside>
 
-### Take appropriate action
+### Onderneem passende maatregelen
 
-After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward.
+Nadat u voldoende informatie heeft verzameld en verwerkt, moet u beslissen wat u gaat doen. Bedenk bij het overwegen van uw volgende stappen dat het uw doel als moderator is om een ​​veilige, respectvolle en samenwerkende omgeving te creëren. Bedenk niet alleen hoe u met de situatie in kwestie om moet gaan, maar ook hoe uw reactie het gedrag en de verwachtingen van uw gemeenschap in de toekomst zal beïnvloeden.
 
-When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise.
+Wanneer iemand een overtreding van de gedragscode meldt, is het uw taak, niet hun taak om ermee om te gaan. Soms geeft de melder informatie vrij die een groot risico inhoudt voor zijn carrière, reputatie of fysieke veiligheid. Door hen te dwingen hun dader te confronteren, zou de verslaggever in een compromitterende positie kunnen komen. U dient de directe communicatie met de persoon in kwestie af te handelen, tenzij de melder uitdrukkelijk anders verzoekt.
 
-There are a few ways you might respond to a code of conduct violation:
+Er zijn een paar manieren waarop u kunt reageren op een overtreding van de gedragscode:
 
-* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication.
+* **Geef de persoon in kwestie een openbare waarschuwing** en leg uit hoe zijn gedrag een negatieve invloed heeft gehad op anderen, bij voorkeur in het kanaal waar het plaatsvond. Waar mogelijk maakt openbare communicatie aan de rest van de gemeenschap duidelijk dat u de gedragscode serieus neemt. Wees vriendelijk, maar standvastig in uw communicatie.
 
-* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them.
+* **Neem persoonlijk contact op met de persoon in kwestie** om uit te leggen hoe zijn gedrag een negatieve invloed heeft op anderen. U kunt een privé-communicatiekanaal gebruiken als het om gevoelige persoonlijke informatie gaat. Als je privé met iemand communiceert, is het een goed idee om diegenen die de situatie voor het eerst hebben gemeld te CC te geven, zodat ze weten dat je actie hebt ondernomen. Vraag de melder om toestemming voordat u een CC invoert.
 
-Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example:
+Soms kan er geen oplossing worden gevonden. De persoon in kwestie kan agressief of vijandig worden wanneer hij wordt geconfronteerd, of verandert zijn gedrag niet. In deze situatie kunt u overwegen om krachtigere maatregelen te nemen. Bijvoorbeeld:
 
-* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project
+* **Schorsing van de persoon** in kwestie van het project, afgedwongen door een tijdelijk verbod op deelname aan enig aspect van het project
 
-* **Permanently ban** the person from the project
+* **Bannen** de persoon permanent van het project
 
-Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached.
+Het verbieden van leden moet niet lichtvaardig worden opgevat en vertegenwoordigt een permanent en onverenigbaar verschil in perspectieven. U dient deze maatregelen alleen te nemen als het duidelijk is dat er geen oplossing kan worden gevonden.
 
-## Your responsibilities as a maintainer
+## Uw verantwoordelijkheden als open source-onderhouder
 
-A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes.
+Een gedragscode is geen wet die willekeurig wordt gehandhaafd. U bent de handhaver van de gedragscode en het is uw verantwoordelijkheid om de regels te volgen die in de gedragscode zijn vastgelegd.
 
-As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community.
+Als onderhouder stelt u de richtlijnen voor uw gemeenschap op en handhaaft u die richtlijnen volgens de regels die in uw gedragscode zijn uiteengezet. Dit betekent dat elke melding van een overtreding van de gedragscode serieus wordt genomen. De melder is een grondige en eerlijke beoordeling van zijn klacht verschuldigd. Als u vaststelt dat het gedrag dat zij hebben gemeld geen overtreding is, communiceer dat dan duidelijk aan hen en leg uit waarom u er geen actie tegen gaat ondernemen. Wat ze daarmee doen, is aan hen: tolereer het gedrag waarmee ze een probleem hadden, of stop met deelnemen aan de gemeenschap.
 
-A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable.
+Een melding van gedrag dat _technisch_ niet in strijd is met de gedragscode, kan nog steeds aangeven dat er een probleem is in uw gemeenschap, en u dient dit potentiële probleem te onderzoeken en dienovereenkomstig te handelen. Dit kan het herzien van uw gedragscode omvatten om acceptabel gedrag te verduidelijken en / of praten met de persoon wiens gedrag werd gemeld en hen vertellen dat hoewel ze de gedragscode niet hebben overtreden, ze de rand van wat wordt verwacht niet overschrijden en ervoor zorgen dat deelnemers voelen zich ongemakkelijk.
 
-In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way.
+Uiteindelijk bepaal en handhaaf je als onderhouder de normen voor acceptabel gedrag. Je hebt het vermogen om de gemeenschapswaarden van het project vorm te geven en deelnemers verwachten dat je die waarden op een eerlijke en evenwichtige manier afdwingt.
 
-## Encourage the behavior you want to see in the world 🌎
+## Moedig het gedrag aan dat u in de wereld wilt zien 🌎
 
-When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow.
+Als een project vijandig of onwelkom lijkt, zelfs als het maar één persoon is wiens gedrag door anderen wordt getolereerd, loop je het risico veel meer bijdragers te verliezen, van wie je sommigen misschien nooit zult ontmoeten. Het is niet altijd gemakkelijk om een gedragscode aan te nemen of af te dwingen, maar door een gastvrije omgeving te creëren, kan uw gemeenschap groeien.

From c0554d6e5a06b6f27ab9afb515488098e66ec5ed Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Thu, 27 Aug 2020 13:45:06 +0200
Subject: [PATCH 067/749] Article ' Finding Users'

---
 _articles/nl/finding-users.md | 140 +++++++++++++++++++---------------
 1 file changed, 78 insertions(+), 62 deletions(-)

diff --git a/_articles/nl/finding-users.md b/_articles/nl/finding-users.md
index 1d1cd099656..195d1b50e06 100644
--- a/_articles/nl/finding-users.md
+++ b/_articles/nl/finding-users.md
@@ -1,15 +1,15 @@
 ---
 lang: nl
-title: Finding Users for Your Project
-description: Help your open source project grow by getting it in the hands of happy users.
+title: Gebruikers zoeken voor uw project
+description: Help uw open source-project te groeien door het in handen te krijgen van tevreden gebruikers.
 class: finding
 toc:
-  spreading-the-word: "Spreading the word"
-  figure-out-your-message: "Figure out your message"
-  help-people-find-and-follow-your-project: "Help people find and follow your project"
-  go-where-your-projects-audience-is-online: "Go where your project’s audience is (online)"
-  go-where-your-projects-audience-is-offline: "Go where your project’s audience is (offline)"
-  build-a-reputation: "Build a reputation"
+  spreading-the-word: "Het woord verspreiden"
+  figure-out-your-message: "Zoek uit wat je bericht is"
+  help-people-find-and-follow-your-project: "Help mensen uw project te vinden en te volgen"
+  go-where-your-projects-audience-is-online: "Ga waar het publiek van uw project is (online)"
+  go-where-your-projects-audience-is-offline: "Ga waar het publiek van uw project is (offline)"
+  build-a-reputation: "Bouw een reputatie op"
 order: 3
 image: /assets/images/cards/finding.png
 related:
@@ -17,147 +17,163 @@ related:
   - building
 ---
 
-## Spreading the word
+## Het woord verspreiden
 
-There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work!
+Er is geen regel die zegt dat u een open source-project moet promoten wanneer u start. Er zijn veel goede redenen om in open source te werken die niets met populariteit te maken hebben. In plaats van te hopen dat anderen uw open source-project zullen vinden en gebruiken, moet u het woord over uw harde werk verspreiden!
 
-## Figure out your message
+## Zoek uit wat je bericht is
 
-Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters.
+Voordat u begint met het eigenlijke werk van het promoten van uw project, moet u kunnen uitleggen wat het doet en waarom het ertoe doet.
 
-What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance.
+Wat maakt uw project anders of interessant? Waarom heb je het gemaakt? Door deze vragen voor uzelf te beantwoorden, kunt u de betekenis van uw project overbrengen.
 
-Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want.
+Onthoud dat mensen erbij betrokken raken als gebruikers en uiteindelijk bijdragen worden, omdat uw project een probleem voor hen oplost. Terwijl je nadenkt over de boodschap en waarde van je project, probeer ze dan te bekijken door de lens van wat _gebruikers en bijdragers_ zouden kunnen willen.
 
-For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
+@robb gebruikt bijvoorbeeld codevoorbeelden om duidelijk te communiceren waarom zijn project,[Cartography](https://github.com/robb/Cartography), nuttig is:
 
 ![Cartography README](/assets/images/finding-users/cartography.jpg)
 
-For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+Voor een diepere duik in berichten, bekijk Mozilla's ["Persona's en paden"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) oefening voor het ontwikkelen van gebruikerspersonages.
 
-## Help people find and follow your project
+## Help mensen uw project te vinden en te volgen
 
 <aside markdown="1" class="pquote">
-  You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
+  U hebt idealiter een enkele "home"-URL nodig die u kunt promoten en waarnaar u mensen kunt verwijzen met betrekking tot uw project. U hoeft niet te spetteren op een mooie sjabloon of zelfs een domeinnaam, maar uw project heeft een centraal punt nodig.
+  
+  _You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point._
   <p markdown="1" class="pquote-credit">
-— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+— Peter Cooper & Robert Nyman, ["Hoe u het woord over uw code kunt verspreiden"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
   </p>
 </aside>
 
-Help people find and remember your project by pointing them to a single namespace.
+Help mensen uw project te vinden en te onthouden door ze naar een enkele naamruimte te verwijzen.
 
-**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.
+**Zorg voor een duidelijk handvat om uw werk te promoten.** Een Twitter-account, GitHub-URL of IRC-kanaal is een gemakkelijke manier om mensen naar uw project te verwijzen. Deze verkooppunten geven ook de groeiende gemeenschap van uw project een plek om samen te komen.
 
-If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. 
+Als u nog geen verkooppunten voor uw project wilt opzetten, promoot dan uw eigen Twitter- of GitHub-account bij alles wat u doet. Door je Twitter- of GitHub-account te promoten, kunnen mensen weten hoe ze contact met je kunnen opnemen of je werk kunnen volgen. Als je op een bijeenkomst of evenement spreekt, zorg er dan voor dat je contactgegevens in je biografie of dia's staan.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
-  A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project.
+  Een fout die ik in die vroege dagen maakte (...) was dat ik geen Twitter-account voor het project startte. Twitter is een geweldige manier om mensen op de hoogte te houden van een project en om mensen constant aan het project bloot te stellen.
+  
+  _A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project._
   <p markdown="1" class="pquote-credit">
-— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+— @nathanmarz, ["Geschiedenis van Apache Storm en geleerde lessen"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
   </p>
 </aside>
 
-**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project.
+**Overweeg om een website voor uw project te maken.** Een website maakt uw project vriendelijker en gemakkelijker te navigeren, vooral als deze is gekoppeld aan duidelijke documentatie en tutorials. Het hebben van een website suggereert ook dat uw project actief is, waardoor uw publiek zich er prettiger bij voelt. Geef voorbeelden om mensen ideeën te geven voor het gebruik van uw project.
 
-[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_.
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), mede-maker van Django, zei dat een website _"verreweg het beste was wat we vroeger met Django deden"_.
 
-If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+Als uw project op GitHub wordt gehost, kunt u [GitHub Pages](https://pages.github.com/) gebruiken om eenvoudig een website te maken. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), en [Middleman](https://middlemanapp.com/) zijn [een paar voorbeelden](https://github.com/showcases/github-pages-examples) van uitstekende, uitgebreide websites.
 
 ![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
 
-Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!
+Nu u een bericht voor uw project heeft en mensen uw project gemakkelijk kunnen vinden, gaan we naar buiten en praten met uw publiek!
 
-## Go where your project's audience is (online)
+## Ga waar het publiek van uw project is (online)
 
-Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
+Online bereik is een geweldige manier om snel te delen en het woord te verspreiden. Door online kanalen te gebruiken, heb je de potentie om een zeer breed publiek te bereiken.
 
-Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+Profiteer van bestaande online communities en platforms om uw publiek te bereiken. Als uw open source-project een softwareproject is, kunt u uw publiek waarschijnlijk vinden op [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), of [Quora](https://www.quora.com/). Vind de kanalen waarvan u denkt dat mensen er het meeste baat bij hebben of enthousiast zijn over uw werk.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
-  Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project.
+  Elk programma heeft zeer specifieke functies die slechts een fractie van de gebruikers nuttig zullen vinden. Spam niet zoveel mogelijk mensen. Richt uw inspanningen in plaats daarvan op gemeenschappen die baat hebben bij kennis van uw project.
+  
+  _Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project._
   <p markdown="1" class="pquote-credit">
-— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+— @pazdera, ["Marketing voor open source-projecten"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
   </p>
 </aside>
 
-See if you can find ways to share your project in relevant ways:
+Kijk of u manieren kunt vinden om uw project op relevante manieren te delen:
 
-* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.
-* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.
-* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work.
+* **Maak kennis met relevante open source-projecten en communities.** Soms hoeft u uw project niet rechtstreeks te promoten. Als je project perfect is voor datawetenschappers die Python gebruiken, maak dan kennis met de data science-community van Python. Als mensen je leren kennen, ontstaan ​​er natuurlijke mogelijkheden om over je werk te praten en het te delen.
+* **Vind mensen die het probleem ondervinden dat uw project oplost.** Doorzoek gerelateerde forums voor mensen die tot de doelgroep van uw project behoren. Beantwoord hun vraag en zoek, indien nodig, een tactvolle manier om uw project als oplossing voor te stellen.
+* **Vraag om feedback.** Stel uzelf en uw werk voor aan een publiek dat het relevant en interessant zou vinden. Wees specifiek over wie u denkt dat baat zou hebben bij uw project. Probeer de zin af te maken: _"Ik denk dat mijn project X echt zou helpen, die Y proberen te doen_". Luister en reageer op de feedback van anderen, in plaats van simpelweg uw werk te promoten.
 
-Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want.
+Richt u in het algemeen op het helpen van anderen voordat u in ruil daarvoor dingen vraagt. Omdat iedereen gemakkelijk een project online kan promoten, zal er veel concurrentie zijn. Om u te onderscheiden van de massa, geeft u mensen context voor wie u bent en niet alleen wat u wilt.
 
-If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication.
+Als niemand op uw eerste berichten let of reageert, raak dan niet ontmoedigd! De meeste projectlanceringen zijn een iteratief proces dat maanden of jaren kan duren. Als je de eerste keer geen reactie krijgt, probeer dan een andere tactiek of zoek eerst naar manieren om waarde toe te voegen aan het werk van anderen. Het promoten en lanceren van uw project kost tijd en toewijding.
 
-## Go where your project's audience is (offline)
+## Ga waar het publiek van uw project is (offline)
 
 ![Public speaking](/assets/images/finding-users/public_speaking.jpg)
 
-Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.
+Offline evenementen zijn een populaire manier om nieuwe projecten onder het publiek te promoten. Ze zijn een geweldige manier om een betrokken publiek te bereiken en diepere menselijke connecties op te bouwen, vooral als je ontwikkelaars wilt bereiken.
 
-If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.
+Als je [nieuw bent bij spreken in het openbaar](https://speaking.io/), begin dan met het vinden van een lokale bijeenkomst die gerelateerd is aan de taal of het ecosysteem van je project.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
-  I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
+  Ik was behoorlijk zenuwachtig om naar PyCon te gaan. Ik hield een lezing, ik zou daar maar een paar mensen leren kennen, ik ging een hele week. (...) Ik had me echter geen zorgen moeten maken. PyCon was fenomenaal geweldig! (...) Iedereen was ongelooflijk vriendelijk en extravert, zo erg dat ik zelden tijd vond om niet met mensen te praten!
+  
+  _I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!_
   <p markdown="1" class="pquote-credit">
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["Hoe ik heb geleerd om te stoppen met piekeren en van PyCon te houden"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
   </p>
 </aside>
 
-If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.
+Als je nog nooit op een evenement hebt gesproken, is het volkomen normaal om nerveus te zijn! Onthoud dat uw publiek er is omdat ze oprecht over uw werk willen horen.
 
-As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.
+Concentreer u tijdens het schrijven van uw lezing op wat uw publiek interessant zal vinden en waar ze waarde uit kunnen halen. Houd uw taal vriendelijk en benaderbaar. Glimlach, adem en heb plezier.
 
 <aside markdown="1" class="pquote">
   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
-  When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+  Wanneer u begint met het schrijven van uw lezing, ongeacht wat uw onderwerp is, kan het helpen als u uw lezing ziet als een verhaal dat u aan mensen vertelt.
+  
+  _When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people._
   <p markdown="1" class="pquote-credit">
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["Hoe u een Tech Conferentie Lezing voorbereidt en schrijft"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
   </p>
 </aside>
 
-When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.
+Als u zich er klaar voor voelt, overweeg dan om op een conferentie te spreken om uw project te promoten. Conferenties kunnen u helpen meer mensen te bereiken, soms van over de hele wereld.
 
-Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers.
+Zoek naar conferenties die specifiek zijn voor uw taal of ecosysteem. Voordat u uw toespraak indient, moet u de conferentie onderzoeken om uw lezing af te stemmen op de aanwezigen en uw kansen te vergroten om geaccepteerd te worden op de conferentie. U kunt vaak een idee krijgen van uw publiek door naar de sprekers van een conferentie te kijken.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
-  I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?
+  Ik schreef heel vriendelijk naar de JSConf-mensen en smeekte hen om me een slot te geven waar ik het op JSConf EU kon presenteren. (...) Ik was enorm bang toen ik dit ding presenteerde waar ik al een half jaar aan werkte. (...) De hele tijd dacht ik alleen maar: oh mijn God. Wat doe ik hier?
+  
+  _I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?_
   <p markdown="1" class="pquote-credit">
-— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+— @ry, ["Historie van Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
   </p>
 </aside>
 
-## Build a reputation
+## Bouw een reputatie op
 
-In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.
+Naast de hierboven beschreven strategieën, is de beste manier om mensen uit te nodigen om te delen en bij te dragen aan uw project, het delen van en bijdragen aan hun projecten.
 
-Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships.
+Door nieuwkomers te helpen, middelen te delen en doordachte bijdragen te leveren aan de projecten van anderen, kunt u een positieve reputatie opbouwen. Door een actief lid te zijn van de open source-gemeenschap, zullen mensen context voor uw werk hebben en zullen ze eerder aandacht besteden aan en uw project delen. Het ontwikkelen van relaties met andere open source-projecten kan zelfs leiden tot officiële partnerschappen.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
-  The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+  De enige reden waarom urllib3 tegenwoordig de populairste Python-bibliotheek van derden is, is omdat het deel uitmaakt van verzoeken.
+  
+  _The only reason urllib3 is the most popular third-party Python library today is because it's part of requests._
   <p markdown="1" class="pquote-credit">
-— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+— @shazow, ["Hoe u uw open source-project kunt laten floreren"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
   </p>
 </aside>
 
-It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others.
+Het is nooit te vroeg of te laat om uw reputatie op te bouwen. Zelfs als u uw eigen project al hebt gelanceerd, blijf zoeken naar manieren om anderen te helpen.
 
-There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.
+Er is geen oplossing van de ene op de andere dag om een publiek op te bouwen. Het vertrouwen en respect van anderen winnen kost tijd, en het opbouwen van uw reputatie houdt nooit op.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it.
+  PhantomJS werd begin 2011 voor het eerst uitgebracht. (...) Ik verspreidde het woord op de gebruikelijke manieren: ik twitterde erover, ik schreef blogposts over dingen die je ermee kon doen, ik noemde het tijdens verschillende discussies in meetups. Toen het in 2014 bekender werd, ben ik er presentaties over gaan geven.
+  
+  _PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it._
   <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
+— @ariya, ["Open source-beheerder verhalen"](https://github.com/open-source/stories/ariya)
   </p>
 </aside>
 
 ## Keep at it!
 
-It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.
+Het kan lang duren voordat mensen uw open source-project opmerken. Dat is goed! Enkele van de meest populaire projecten van vandaag hebben jaren geduurd om een hoog activiteitsniveau te bereiken. Concentreer u op het opbouwen van relaties in plaats van te hopen dat uw project spontaan populair zal worden. Wees geduldig en blijf uw werk delen met degenen die het op prijs stellen.

From 38e663fec4bcd0be3fa44bea71571deeb99a831c Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Thu, 27 Aug 2020 14:31:49 +0200
Subject: [PATCH 068/749] Article 'Getting Paid'

---
 _articles/nl/getting-paid.md | 187 +++++++++++++++++++----------------
 1 file changed, 102 insertions(+), 85 deletions(-)

diff --git a/_articles/nl/getting-paid.md b/_articles/nl/getting-paid.md
index 4e7285c778f..6de7d1d2ae5 100644
--- a/_articles/nl/getting-paid.md
+++ b/_articles/nl/getting-paid.md
@@ -1,13 +1,13 @@
 ---
 lang: nl
-title: Getting Paid for Open Source Work
-description: Sustain your work in open source by getting financial support for your time or your project.
+title: Betaald worden voor open source-werk
+description: Ondersteun uw werk in open source door financiële steun te krijgen voor uw tijd of uw project.
 class: getting-paid
 toc:
-  why-some-people-seek-financial-support: "Why some people seek financial support"
-  funding-your-own-time: "Funding your own time"
-  finding-funding-for-your-project: "Finding funding for your project"
-  building-a-case-for-financial-support: "Building a case for financial support"
+  why-some-people-seek-financial-support: "Waarom sommige mensen financiële steun zoeken"
+  funding-your-own-time: "Je eigen tijd financieren"
+  finding-funding-for-your-project: "Financiering vinden voor uw project"
+  building-a-case-for-financial-support: "Het bouwen van een case voor financiële steun"
 order: 7
 image: /assets/images/cards/getting-paid.png
 related:
@@ -15,177 +15,194 @@ related:
   - leadership
 ---
 
-## Why some people seek financial support
+## Waarom sommige mensen financiële steun zoeken
 
-Much of open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+Veel van het open source-werk wordt op vrijwillige basis aangeboden. Iemand kan bijvoorbeeld een bug tegenkomen in een project dat ze gebruiken en een snelle oplossing indienen, of ze kunnen in hun vrije tijd graag aan een open source-project sleutelen.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
-I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+  Ik was op zoek naar een "hobby" programmeerproject dat me doordeweeks rond Kerstmis bezig zou houden. (...) Ik had een homecomputer, en verder niet veel. Ik besloot een tolk te schrijven voor de nieuwe scripttaal waar ik de laatste tijd aan had gedacht. (...) Ik koos Python als werktitel.
+
+  _I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title._
+
   <p markdown="1" class="pquote-credit">
-— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+— @gvanrossum, ["Python programmeren"](https://www.python.org/doc/essays/foreword/)
   </p>
 </aside>
 
-There are many reasons why a person would not want to be paid for their open source work.
+Er zijn veel redenen waarom iemand niet zou willen worden betaald voor zijn open source-werk.
 
-* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
-* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
-* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+* **Ze hebben misschien al een fulltime baan waar ze van houden,** waardoor ze in hun vrije tijd kunnen bijdragen aan open source.
+* **Ze vinden open source graag een hobby** of een creatieve ontsnapping en willen zich niet financieel verplicht voelen om aan hun projecten te werken.
+* **Ze profiteren van andere voordelen door bij te dragen aan open source,** zoals het opbouwen van hun reputatie of portfolio, het leren van een nieuwe vaardigheid of het gevoel dichter bij een gemeenschap te zijn.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
-  Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+  Financiële donaties voegen voor sommigen een gevoel van verantwoordelijkheid toe. (...) Het is belangrijk voor ons, in de wereldwijd verbonden, snelle wereld waarin we leven, om te kunnen zeggen "niet nu, ik heb zin om iets heel anders te doen".
+
+  _Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different"._
+
   <p markdown="1" class="pquote-credit">
-— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+— @alloy, ["Waarom we geen donaties accepteren"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
   </p>
 </aside>
 
-For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+Voor anderen, vooral wanneer bijdragen doorlopend zijn of veel tijd vergen, is betaald krijgen om bij te dragen aan open source de enige manier waarop ze kunnen deelnemen, hetzij omdat het project dit vereist, hetzij om persoonlijke redenen.
 
-Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
+Het onderhouden van populaire projecten kan een aanzienlijke verantwoordelijkheid zijn, die 10 of 20 uur per week in beslag neemt in plaats van een paar uur per maand.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
-  Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+  Vraag het aan een willekeurige open source projectbeheerder, en zij zullen u vertellen over de realiteit van de hoeveelheid werk die nodig is om een project te beheren. Je hebt klanten. U lost problemen voor hen op. U creëert nieuwe functies. Dit wordt een echte tijdrovende bezigheid.
+  
+  _Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time._
+
   <p markdown="1" class="pquote-credit">
-— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+— @ashedryden, ["De ethiek van onbetaalde arbeid en de OSS-gemeenschap"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
   </p>
 </aside>
 
-Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+Betaald werk stelt mensen uit verschillende rangen en standen ook in staat om een zinvolle bijdrage te leveren. Sommige mensen kunnen het zich niet veroorloven om onbetaalde tijd aan open source-projecten te besteden, op basis van hun huidige financiële positie, schulden, familie- of andere zorgverplichtingen. Dat betekent dat de wereld nooit bijdragen ziet van getalenteerde mensen die het zich niet kunnen veroorloven om vrijwilligerswerk te doen. Dit heeft ethische implicaties, zoals @ashedryden [heeft beschreven](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), aangezien werk dat wordt gedaan, bevooroordeeld ten gunste van degenen die al voordelen in het leven hebben, die vervolgens extra voordelen krijgen op basis van hun vrijwilligersbijdragen, terwijl anderen die niet in staat zijn om vrijwilligerswerk te doen, later geen kansen krijgen, wat het huidige gebrek aan diversiteit in de open source versterkt gemeenschap.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
-   OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+  OSS levert enorme voordelen op voor de technologische industrie, wat op zijn beurt voordelen betekent voor alle industrieën. (...) Als de enige mensen die zich erop kunnen concentreren de gelukkigen en geobsedeerd zijn, dan is er een enorm onbenut potentieel.
+  
+   _OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential._
   <p markdown="1" class="pquote-credit">
-— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+— @isaacs, ["Geld en Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
   </p>
 </aside>
 
-If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+Als u op zoek bent naar financiële ondersteuning, zijn er twee manieren om te overwegen. U kunt uw eigen tijd als donateur financieren, of u kunt organisatorische financiering voor het project vinden.
 
-## Funding your own time
+## Je eigen tijd financieren
 
-Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+Tegenwoordig worden veel mensen betaald om part- of fulltime aan open source te werken. De meest gebruikelijke manier om voor uw tijd betaald te worden, is door met uw werkgever te praten.
 
-It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+Het is gemakkelijker om een pleidooi te houden voor open source-werk als je werkgever het project ook daadwerkelijk gebruikt, maar wees creatief met je pitch. Misschien gebruikt je werkgever het project niet, maar ze gebruiken Python, en het onderhouden van een populair Python-project helpt nieuwe Python-ontwikkelaars aan te trekken. Misschien zorgt het ervoor dat uw werkgever er in het algemeen ontwikkelaarvriendelijker uitziet.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.
+  Zoals velen in open source, worstelde ik met de last om een project te onderhouden. Toen ik voor het eerst met open source begon, bleef ik gewoon te laat om eraan te werken of toen ik thuiskwam. (...) Ik was in staat om met mijn baas de problemen te bespreken waarmee ik werd geconfronteerd en we kwamen met ideeën over hoe we open source-taken konden integreren met ons eigen gebruik van Babel.
+  
+  _Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel._
   <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
+— @hzoo, ["Open source-onderhouder verhalen"](https://github.com/open-source/stories/hzoo)
   </p>
 </aside>
 
-If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+Als je geen bestaand open source-project hebt waaraan je zou willen werken, maar liever hebt dat je huidige werkoutput open source is, pleit er dan voor dat je werkgever een deel van hun interne software open source maakt.
 
-Many companies are developing open source programs to build their brand and recruit quality talent.
+Veel bedrijven ontwikkelen open source-programma's om hun merk op te bouwen en talent van hoge kwaliteit te werven.
 
-@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+@hueniverse ontdekte bijvoorbeeld dat er financiële redenen waren om [Walmart's investering in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). En @jamesgpearce ontdekte dat het open source-programma van Facebook [een verschil maakte](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) bij het werven van:
 
-> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+> Het sluit nauw aan bij onze hackercultuur en hoe onze organisatie werd gezien. We vroegen onze medewerkers: "Was u op de hoogte van het open source softwareprogramma op Facebook?". Twee derde zei "Ja". De helft zei dat het programma een positieve bijdrage leverde aan hun beslissing om voor ons te werken. Dit zijn geen marginale cijfers, en naar ik hoop, een trend die zich voortzet.
 
-If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+Als uw bedrijf deze weg inslaat, is het belangrijk om de grenzen tussen gemeenschap en bedrijfsactiviteiten duidelijk te houden. Uiteindelijk houdt open source zichzelf in stand door bijdragen van mensen over de hele wereld, en dat is groter dan welk bedrijf of locatie dan ook.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
-  Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+  Betaald worden om aan open source te werken is een zeldzame en geweldige kans, maar je zou je passie in het proces niet moeten opgeven. Uw passie zou moeten zijn waarom bedrijven u willen betalen.
+  
+  _Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you._
   <p markdown="1" class="pquote-credit">
-— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+— @jessfraz, ["Wazige lijnen"](https://blog.jessfraz.com/post/blurred-lines/)
   </p>
 </aside>
 
-If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+Als u uw huidige werkgever niet kunt overtuigen om prioriteit te geven aan open source-werk, overweeg dan om een nieuwe werkgever te zoeken die werknemersbijdragen aan open source aanmoedigt. Zoek naar bedrijven die hun toewijding aan open source-werk expliciet maken. Bijvoorbeeld:
 
-* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
-* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+* Sommige bedrijven, zoals [Netflix](https://netflix.github.io/) of [PayPal](https://paypal.github.io/), hebben websites die hun betrokkenheid bij open source benadrukken
+* [Zalando](https://opensource.zalando.com) publiceerde zijn [open source bijdragebeleid](https://opensource.zalando.com/docs/using/contributing/) voor werknemers
 
-Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+Projecten die zijn ontstaan ​​bij een groot bedrijf, zoals [Go](https://github.com/golang) of [React](https://github.com/facebook/react), zullen waarschijnlijk ook mensen in dienst hebben om aan te werken open source.
 
-Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
+Afhankelijk van uw persoonlijke omstandigheden kunt u proberen om zelfstandig geld in te zamelen om uw open source-werk te financieren. Bijvoorbeeld:
 
-* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
-* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+* @gaearon financierde zijn werk op [Redux](https://github.com/reactjs/redux) via een [Patreon crowdfunding-campagne](https://redux.js.org/)
+* @andrewgodwin gefinancierd werk aan Django-schemamigraties [via een Kickstarter-campagne](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
-Finally, sometimes open source projects put bounties on issues that you might consider helping with. 
+Ten slotte geven open source-projecten soms premies voor problemen waarmee u zou kunnen helpen.
 
-* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their javascript library [through a bounty on gitcoin](https://gitcoin.co/).
-* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+* @ConnorChristie kon betaald worden voor [helpen](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol werken aan hun javascript-bibliotheek [via een premie op gitcoin](https://gitcoin.co/).
+* @mamiM deed Japanse vertalingen voor @MetaMask nadat de [kwestie werd gefinancierd op Bounties Network](https://explorer.bounties.network/bounty/134).
 
-## Finding funding for your project
+## Financiering vinden voor uw project
 
-Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+Naast regelingen voor individuele bijdragers, halen projecten soms geld op bij bedrijven, individuen of anderen om lopende werkzaamheden te financieren.
 
-Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing into new features or ideas.
+Organisatorische financiering kan gaan naar het betalen van huidige bijdragers, het dekken van de kosten van het uitvoeren van het project (zoals hostingvergoedingen) of het investeren in nieuwe functies of ideeën.
 
-As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+Naarmate de populariteit van open source toeneemt, is het vinden van financiering voor projecten nog experimenteel, maar er zijn een paar veelvoorkomende opties beschikbaar.
 
-### Raise money for your work through crowdfunding campaigns or sponsorships
+### Zamel geld in voor je werk door middel van crowdfundingcampagnes of sponsoring
 
-Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
-A few examples of sponsored projects include:
+Het vinden van sponsoring werkt goed als je al een sterk publiek of een sterke reputatie hebt, of als je project erg populair is.
+Enkele voorbeelden van gesponsorde projecten zijn:
 
-* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803)
-* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+* **[webpack](https://github.com/webpack)** zamelt geld in bij bedrijven en particulieren [via OpenCollective](https://opencollective.com/webpack)
+* **[Vue](https://github.com/vuejs/vue)** wordt [gefinancierd via Patreon](https://github.com/open-source/stories/yyx990803)
+* **[Ruby Together](https://rubytogether.org/),** een non-profitorganisatie die betaalt voor werk aan [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), en andere Ruby-infrastructuurprojecten
 
-### Create a revenue stream
+### Creëer een inkomstenstroom
 
-Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+Afhankelijk van uw project kunt u mogelijk kosten in rekening brengen voor commerciële ondersteuning, gehoste opties of extra functies. Enkele voorbeelden zijn:
 
-* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
-* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
-* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+* **[Sidekiq](https://github.com/mperham/sidekiq)** biedt betaalde versies voor extra ondersteuning
+* **[Travis CI](https://github.com/travis-ci)** biedt betaalde versies van zijn product
+* **[Ghost](https://github.com/TryGhost/Ghost)** is een non-profitorganisatie met een betaalde beheerde service
 
-Some popular projects, like [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+Sommige populaire projecten, zoals [npm](https://github.com/npm/npm) en [Docker](https://github.com/docker/docker), halen zelfs risicokapitaal op om de groei van hun bedrijf te ondersteunen.
 
-### Apply for grant funding
+### Subsidie ​​aanvragen
 
-Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+Sommige softwarestichtingen en bedrijven bieden beurzen aan voor open source-werk. Soms kunnen subsidies worden uitbetaald aan individuen zonder een juridische entiteit voor het project op te richten.
 
-* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
-* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
-* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
-* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** ontving een subsidie ​​van [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)** werk werd gefinancierd door [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** heeft een subsidie ​​ontvangen van de [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* De **[Python Software Foundation](https://www.python.org/psf/grants/)** biedt beurzen aan voor Python-gerelateerd werk
 
-For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+Voor meer gedetailleerde opties en casestudy's, @nayafia [schreef een gids](https://github.com/nayafia/lemonade-stand) om betaald te worden voor open source werk. Verschillende soorten financiering vereisen verschillende vaardigheden, dus overweeg uw sterke punten om erachter te komen welke optie voor u het beste werkt.
 
-## Building a case for financial support
+## Het bouwen van een case voor financiële steun
 
-Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+Of uw project nu een nieuw idee is of al jaren bestaat, u moet verwachten dat u veel aandacht besteedt aan het identificeren van uw beoogde financier en het maken van een overtuigende zaak.
 
-Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+Of je nu voor je eigen tijd wilt betalen of geld wilt inzamelen voor een project, je zou de volgende vragen moeten kunnen beantwoorden.
 
-### Impact
+### Gevolg
 
-Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+Waarom is dit project nuttig? Waarom vinden uw (potentiële) gebruikers het zo leuk? Waar zal het zijn over vijf jaar?
 
-### Traction
+### Tractie
 
-Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+Probeer bewijs te verzamelen dat uw project ertoe doet, of het nu gaat om statistieken, anekdotes of getuigenissen. Zijn er op dit moment bedrijven of opmerkelijke mensen die uw project gebruiken? Zo nee, heeft een vooraanstaand persoon het onderschreven?
 
-### Value to funder
+### Waarde voor financier
 
-Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+Financiers, of het nu uw werkgever of een stichting is, worden vaak benaderd met kansen. Waarom zouden ze uw project beter ondersteunen dan elke andere mogelijkheid? Hoe profiteren ze persoonlijk?
 
-### Use of funds
+### Gebruik van fondsen
 
-What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+Wat gaat u precies bereiken met de voorgestelde financiering? Concentreer u op mijlpalen of resultaten van projecten in plaats van een salaris te betalen.
 
-### How you'll receive the funds
+### Hoe u het geld ontvangt
 
-Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+Heeft de financier enige vereisten met betrekking tot uitbetaling? U moet bijvoorbeeld een non-profitorganisatie zijn of een fiscale sponsor hebben. Of misschien moet het geld aan een individuele aannemer worden gegeven in plaats van aan een organisatie. Deze vereisten variëren tussen financiers, dus zorg ervoor dat u van tevoren uw onderzoek doet.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
-  For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+  We zijn al jaren de toonaangevende bron van websitevriendelijke pictogrammen, met een community van meer dan 20 miljoen mensen en zijn te zien op meer dan 70 miljoen websites, waaronder Whitehouse.gov. (...) Versie 4 bestond drie jaar geleden. Webtechnologie is sindsdien veel veranderd, en eerlijk gezegd is Font Awesome een beetje muf geworden. (...) Daarom introduceren we Font Awesome 5. We moderniseren en herschrijven de CSS en herontwerpen elk pictogram van boven naar beneden. We hebben het over een beter ontwerp, betere consistentie en betere leesbaarheid.
+  
+  _For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability._
   <p markdown="1" class="pquote-credit">
 — @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
   </p>
 </aside>
 
-## Experiment and don't give up
+## Experimenteer en geef niet op
 
-Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
+Geld inzamelen is niet eenvoudig, of je nu een open source-project, een non-profitorganisatie of een software-startup bent, en in de meeste gevallen moet je creatief zijn. Door vast te stellen hoe u betaald wilt worden, onderzoek te doen en uzelf in de schoenen van uw financier te verplaatsen, kunt u een overtuigende zaak voor financiering opbouwen.

From 70409e3ca1361a916da42c6dcf4cb62c94d921fe Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Thu, 27 Aug 2020 15:33:46 +0200
Subject: [PATCH 069/749] Article 'Metrics'

---
 _articles/nl/building-community.md        |   2 +-
 _articles/nl/how-to-contribute.md         |  28 ++---
 _articles/nl/leadership-and-governance.md |  38 +++----
 _articles/nl/legal.md                     |  36 +++---
 _articles/nl/metrics.md                   | 128 +++++++++++-----------
 _articles/nl/starting-a-project.md        |  28 ++---
 6 files changed, 131 insertions(+), 129 deletions(-)

diff --git a/_articles/nl/building-community.md b/_articles/nl/building-community.md
index 82be15f49b5..cde8653013c 100644
--- a/_articles/nl/building-community.md
+++ b/_articles/nl/building-community.md
@@ -37,7 +37,7 @@ Begin met uw documentatie:
 
 * **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.
 * **Wees responsief.** Als u een maand lang niet op hun probleem reageert, is de kans groot dat ze uw project al zijn vergeten.
-* **Sta open voor de soorten bijdragen die u accepteert.** Veel bijdragers beginnen met een bugrapport of een kleine oplossing. Er zijn [veel manieren om bij te dragen](../how-to-contribute/#what-it-means-to-contribute) aan een project. Laat mensen helpen zoals ze willen helpen.
+* **Sta open voor de soorten bijdragen die u accepteert.** Veel bijdragers beginnen met een bugrapport of een kleine oplossing. Er zijn [veel manieren om bij te dragen](../how-to-contribute/#waarom-bijdragen-aan-open-source) aan een project. Laat mensen helpen zoals ze willen helpen.
 * **Als er een bijdrage is waar u het niet mee eens bent,** bedank ze voor hun idee, en [vertel waarom](../best-practices/#nee-leren-zeggen) het niet past in de scope van het project en linkt naar relevante documentatie als je die hebt.
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md
index c02def3ef02..0d67031233f 100644
--- a/_articles/nl/how-to-contribute.md
+++ b/_articles/nl/how-to-contribute.md
@@ -1,15 +1,15 @@
 ---
 lang: nl
-title: How to Contribute to Open Source
-description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans.
+title: Hoe u kunt bijdragen aan Open Source
+description: Wil je bijdragen aan open source? Een gids voor het maken van open source-bijdragen, voor beginners en veteranen.
 class: contribute
 toc:
-  why-contribute-to-open-source: "Why contribute to open source?"
-  what-it-means-to-contribute: "What it means to contribute"
-  orienting-yourself-to-a-new-project: "Orienting yourself to a new project"
-  finding-a-project-to-contribute-to: "Finding a project to contribute to"
-  how-to-submit-a-contribution: "How to submit a contribution"
-  what-happens-after-you-submit-a-contribution: "What happens after you submit a contribution"
+  why-contribute-to-open-source: "Waarom bijdragen aan open source?"
+  what-it-means-to-contribute: "Wat het betekent om bij te dragen"
+  orienting-yourself-to-a-new-project: "Je oriënteren op een nieuw project"
+  finding-a-project-to-contribute-to: "Een project vinden om aan bij te dragen"
+  how-to-submit-a-contribution: "Hoe u een bijdrage kunt indienen"
+  what-happens-after-you-submit-a-contribution: "Wat gebeurt er nadat u een bijdrage heeft ingeleverd?"
 order: 1
 image: /assets/images/cards/contribute.png
 related:
@@ -17,7 +17,7 @@ related:
   - building
 ---
 
-## Why contribute to open source?
+## Waarom bijdragen aan open source?
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
@@ -59,7 +59,7 @@ Open source offers opportunities to practice leadership and management skills, s
 
 You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
 
-## What it means to contribute
+## Wat het betekent om bij te dragen
 
 If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
 
@@ -153,7 +153,7 @@ For example:
 
 Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
 
-## Orienting yourself to a new project
+## Je oriënteren op een nieuw project
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
@@ -200,7 +200,7 @@ Finally, open source projects use the following tools to organize discussion. Re
 * **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
 * **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
 
-## Finding a project to contribute to
+## Een project vinden om aan bij te dragen
 
 Now that you've figured out how open source projects work, it's time to find a project to contribute to!
 
@@ -386,7 +386,7 @@ A project that is friendly and welcoming signals that they will be receptive to
   </p>
 </aside>
 
-## How to submit a contribution
+## Hoe u een bijdrage kunt indienen
 
 You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
 
@@ -498,7 +498,7 @@ If the project is on GitHub, here's how to submit a pull request:
 
 If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
 
-## What happens after you submit a contribution
+## Wat gebeurt er nadat u een bijdrage heeft ingeleverd?
 
 You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
 
diff --git a/_articles/nl/leadership-and-governance.md b/_articles/nl/leadership-and-governance.md
index 1dcb6feadcc..b63e1d92aff 100644
--- a/_articles/nl/leadership-and-governance.md
+++ b/_articles/nl/leadership-and-governance.md
@@ -1,17 +1,17 @@
 ---
 lang: nl
-title: Leadership and Governance
-description: Growing open source projects can benefit from formal rules for making decisions.
+title: Leiderschap en bestuur
+description: Groeiende open source-projecten kunnen profiteren van formele regels voor het nemen van beslissingen.
 class: leadership
 toc:
-  understanding-governance-for-your-growing-project: "Understanding governance for your growing project"
-  what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?"
-  how-do-i-formalize-these-leadership-roles: "How do I formalize these leadership roles?"
-  when-should-i-give-someone-commit-access: "When should I give someone commit access?"
-  what-are-some-of-the-common-governance-structures-for-open-source-projects: "What are some of the common governance structures for open source projects?"
-  do-i-need-governance-docs-when-i-launch-my-project: "Do I need governance docs when I launch my project?"
-  what-happens-if-corporate-employees-start-submitting-contributions: "What happens if corporate employees start submitting contributions?"
-  do-i-need-a-legal-entity-to-support-my-project: "Do I need a legal entity to support my project?"
+  understanding-governance-for-your-growing-project: "Inzicht in governance voor uw groeiende project"
+  what-are-examples-of-formal-roles-used-in-open-source-projects: "Wat zijn voorbeelden van formele rollen die worden gebruikt in open source-projecten?"
+  how-do-i-formalize-these-leadership-roles: "Hoe formaliseer ik deze leiderschapsrollen?"
+  when-should-i-give-someone-commit-access: "Wanneer moet ik iemand commit-toegang geven?"
+  what-are-some-of-the-common-governance-structures-for-open-source-projects: "Wat zijn enkele van de algemene bestuursstructuren voor open source-projecten?"
+  do-i-need-governance-docs-when-i-launch-my-project: "Heb ik beheersdocumenten nodig wanneer ik mijn project start?"
+  what-happens-if-corporate-employees-start-submitting-contributions: "Wat gebeurt er als bedrijfsmedewerkers bijdragen beginnen in te dienen?"
+  do-i-need-a-legal-entity-to-support-my-project: "Heb ik een juridische entiteit nodig om mijn project te ondersteunen?"
 order: 6
 image: /assets/images/cards/leadership.png
 related:
@@ -19,11 +19,11 @@ related:
   - metrics
 ---
 
-## Understanding governance for your growing project
+## Inzicht in governance voor uw groeiende project
 
 Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
 
-## What are examples of formal roles used in open source projects?
+## Wat zijn voorbeelden van formele rollen die worden gebruikt in open source-projecten?
 
 Many projects follow a similar structure for contributor roles and recognition.
 
@@ -49,7 +49,7 @@ A maintainer doesn't necessarily have to be someone who writes code for your pro
 
 **The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
 
-While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#waarom-bijdragen-aan-open-source) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
@@ -59,7 +59,7 @@ While you can define your project roles any way you'd like, [consider using broa
   </p>
 </aside>
 
-## How do I formalize these leadership roles?
+## Hoe formaliseer ik deze leiderschapsrollen?
 
 Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
 
@@ -84,7 +84,7 @@ Tools like [Vossibility](https://github.com/icecrime/vossibility-stack) can help
 
 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/#deel-het-eigendom-van-uw-project).
 
-## When should I give someone commit access?
+## Wanneer moet ik iemand commit-toegang geven?
 
 Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
 
@@ -100,7 +100,7 @@ If your project is on GitHub, you can use [protected branches](https://help.gith
   </p>
 </aside>
 
-## What are some of the common governance structures for open source projects?
+## Wat zijn enkele van de algemene bestuursstructuren voor open source-projecten?
 
 There are three common governance structures associated with open source projects.
 
@@ -116,7 +116,7 @@ Which one should you use? It's up to you! Every model has advantages and trade-o
 * [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
 * [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
 
-## Do I need governance docs when I launch my project?
+## Heb ik beheersdocumenten nodig wanneer ik mijn project start?
 
 There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
 
@@ -132,7 +132,7 @@ If you're part of a company launching an open source project, it's worth having
   </p>
 </aside>
 
-## What happens if corporate employees start submitting contributions?
+## Wat gebeurt er als bedrijfsmedewerkers bijdragen beginnen in te dienen?
 
 Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
 
@@ -144,7 +144,7 @@ It's important to treat commercial activity as normal and as just another source
 
 Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
 
-## Do I need a legal entity to support my project?
+## Heb ik een juridische entiteit nodig om mijn project te ondersteunen?
 
 You don't need a legal entity to support your open source project unless you're handling money.
 
diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
index 02b8fb25799..e6e35f7ede4 100644
--- a/_articles/nl/legal.md
+++ b/_articles/nl/legal.md
@@ -1,16 +1,16 @@
 ---
 lang: nl
-title: The Legal Side of Open Source
-description: Everything you've ever wondered about the legal side of open source, and a few things you didn't.
+title: De juridische kant van open source
+description: Alles wat je je ooit hebt afgevraagd over de juridische kant van open source, en een paar dingen die je niet deed.
 class: legal
 toc:
-  why-do-people-care-so-much-about-the-legal-side-of-open-source: "Why do people care so much about the legal side of open source?"
-  are-public-github-projects-open-source: "Are public GitHub projects open source?"
-  just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Just give me the TL;DR on what I need to protect my project"
-  which-open-source-license-is-appropriate-for-my-project: "Which open source license is appropriate for my project?"
-  what-if-i-want-to-change-the-license-of-my-project: "What if I want to change the license of my project?"
-  does-my-project-need-an-additional-contributor-agreement: "Does my project need an additional contributor agreement?"
-  what-does-my-companys-legal-team-need-to-know: "What does my company’s legal team need to know?"
+  why-do-people-care-so-much-about-the-legal-side-of-open-source: "Waarom geven mensen zoveel om de juridische kant van open source?"
+  are-public-github-projects-open-source: "Zijn openbare GitHub-projecten open source?"
+  just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Geef me gewoon de TL;DR over wat ik nodig heb om mijn project te beschermen"
+  which-open-source-license-is-appropriate-for-my-project: "Welke open source-licentie is geschikt voor mijn project?"
+  what-if-i-want-to-change-the-license-of-my-project: "Wat moet ik doen als ik de licentie van mijn project wil wijzigen?"
+  does-my-project-need-an-additional-contributor-agreement: "Heeft mijn project een aanvullende contribuantenovereenkomst nodig?"
+  what-does-my-companys-legal-team-need-to-know: "Wat moet het juridische team van mijn bedrijf weten?"
 order: 10
 image: /assets/images/cards/legal.png
 related:
@@ -22,7 +22,7 @@ related:
 
 Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
 
-## Why do people care so much about the legal side of open source?
+## Waarom geven mensen zoveel om de juridische kant van open source?
 
 Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
 
@@ -34,7 +34,7 @@ If you don't apply an open source license, everybody who contributes to your pro
 
 Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
 
-## Are public GitHub projects open source?
+## Zijn openbare GitHub-projecten 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**.
 
@@ -44,7 +44,7 @@ When you [create a new project](https://help.github.com/articles/creating-a-new-
 
 If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
 
-## Just give me the TL;DR on what I need to protect my project.
+## Geef me gewoon de TL;DR over wat ik nodig heb om mijn project te beschermen
 
 You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
 
@@ -60,7 +60,7 @@ When you create a new project on GitHub, you'll be [asked to add a license](http
   </p>
 </aside>
 
-## Which open source license is appropriate for my project?
+## Welke open source-licentie is geschikt voor mijn project?
 
 If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
 
@@ -76,11 +76,11 @@ You may also want to consider the **communities** you hope will use and contribu
 * **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
 * **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
 
-Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#wat-moet-het-juridische-team-van-mijn-bedrijf-weten).
 
 When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
 
-## What if I want to change the license of my project?
+## Wat moet ik doen als ik de licentie van mijn project wil wijzigen?
 
 Most projects never need to change licenses. But occasionally circumstances change.
 
@@ -94,7 +94,7 @@ For example, as your project grows it adds dependencies or users, or your compan
 
 Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
 
-## Does my project need an additional contributor agreement?
+## Heeft mijn project een aanvullende contribuantenovereenkomst nodig?
 
 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).
 
@@ -120,7 +120,7 @@ Some situations where you may want to consider an additional contributor agreeme
 
 If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
 
-## What does my company's legal team need to know?
+## Wat moet het juridische team van mijn bedrijf weten?
 
 If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
 
@@ -163,4 +163,4 @@ Longer term, your legal team can do more to help the company get more from its i
 </aside>
 
 * **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
-* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
+* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#heb-ik-een-juridische-entiteit-nodig-om-mijn-project-te-ondersteunen).
diff --git a/_articles/nl/metrics.md b/_articles/nl/metrics.md
index 60a2a72d703..3a755bff52f 100644
--- a/_articles/nl/metrics.md
+++ b/_articles/nl/metrics.md
@@ -1,14 +1,14 @@
 ---
 lang: nl
-title: Open Source Metrics
-description: Make informed decisions to help your open source project thrive by measuring and tracking its success.
+title: Open source-statistieken
+description: Neem weloverwogen beslissingen om uw open source-project te laten gedijen door het succes ervan te meten en bij te houden.
 class: metrics
 toc:
-  why-measure-anything: "Why measure anything?"
-  discovery: "Discovery"
-  usage: "Usage"
+  why-measure-anything: "Waarom iets meten?"
+  discovery: "Ontdekking"
+  usage: "Gebruik"
   retention: "Retention"
-  maintainer-activity: "Maintainer activity"
+  maintainer-activity: "open source beheerdersactiviteit"
 order: 9
 image: /assets/images/cards/metrics.png
 related:
@@ -16,117 +16,119 @@ related:
   - best-practices
 ---
 
-## Why measure anything?
+## Waarom iets meten?
 
-Data, when used wisely, can help you make better decisions as an open source maintainer.
+Data, mits verstandig gebruikt, kunnen u helpen betere beslissingen te nemen als open source-onderhouder.
 
-With more information, you can:
+Met meer informatie kunt u:
 
-* Understand how users respond to a new feature
-* Figure out where new users come from
-* Identify, and decide whether to support, an outlier use case or functionality
-* Quantify your project's popularity
-* Understand how your project is used
-* Raise money through sponsorships and grants
+* Begrijp hoe gebruikers reageren op een nieuwe functie
+* Zoek uit waar nieuwe gebruikers vandaan komen
+* Identificeer, en beslis of u een uitbijtergebruikscasus of -functionaliteit wilt ondersteunen
+* Kwantificeer de populariteit van uw project
+* Begrijp hoe uw project wordt gebruikt
+* Zamel geld in via sponsoring en beurzen
 
-For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+[Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) stelt bijvoorbeeld vast dat Google Analytics hen helpt bij het prioriteren van werk:
 
-> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+> Homebrew wordt gratis verstrekt en wordt in hun vrije tijd volledig gerund door vrijwilligers. Als gevolg hiervan hebben we niet de middelen om gedetailleerde gebruikersstudies van Homebrew-gebruikers uit te voeren om te beslissen hoe toekomstige functies het beste kunnen worden ontworpen en prioriteit kunnen worden gegeven aan huidig werk. Anonieme geaggregeerde gebruikersanalyses stellen ons in staat om prioriteit te geven aan fixes en functies op basis van hoe, waar en wanneer mensen Homebrew gebruiken.
 
-Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+Populariteit is niet alles. Iedereen komt om verschillende redenen in open source. Als het je doel is als open source-onderhouder om te pronken met je werk, transparant te zijn over je code of gewoon plezier te hebben, dan zijn metrics misschien niet belangrijk voor je.
 
-If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+Als u _geïnteresseerd_ bent om uw project op een dieper niveau te begrijpen, lees dan verder voor manieren om de activiteit van uw project te analyseren.
 
-## Discovery
+## Ontdekking
 
-Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+Voordat iemand uw project kan gebruiken of eraan kan bijdragen, moet hij of zij weten dat het bestaat. Stel uzelf de vraag: _vinden mensen dit project?_
 
 ![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:
+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:
 
-* **Total page views:** Tells you how many times your project was viewed
+* **Total page views:** geeft aan hoe vaak uw project is bekeken
 
-* **Total unique visitors:** Tells you how many people viewed your project
+* **Total unique visitors:** geeft aan hoeveel mensen uw project hebben bekeken
 
-* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+* **Referring sites:** vertelt u waar bezoekers vandaan kwamen. Deze statistiek kan u helpen erachter te komen waar u uw publiek kunt bereiken en of uw promotie-inspanningen werken.
 
-* **Popular content:** Tells you where visitors go on your project, broken down by page views and unique visitors.
+* **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/) 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://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.
 
-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.
+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.
 
-## Usage
+## Gebruik
 
-People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+Mensen vinden uw project op dit wilde en gekke ding dat we internet noemen. Idealiter voelen ze zich genoodzaakt om iets te doen als ze uw project zien. De tweede vraag die u wilt stellen is: _gebruiken mensen dit project?_
 
-If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+Als u een pakketbeheerder gebruikt, zoals npm of RubyGems.org, om uw project te distribueren, kunt u mogelijk de downloads van uw project volgen.
 
-Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+Elke pakketbeheerder kan een iets andere definitie van "downloaden" gebruiken, en downloads correleren niet noodzakelijkerwijs met installaties of gebruik, maar het biedt een basis ter vergelijking. Probeer [Libraries.io](https://libraries.io/) te gebruiken om gebruiksstatistieken bij te houden van veel populaire pakketbeheerders.
 
-If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+Als je project op GitHub staat, navigeer dan opnieuw naar de "Traffic"-pagina. U kunt de [kloongrafiek](https://github.com/blog/1873-clone-graphs) gebruiken om te zien hoe vaak uw project op een bepaalde dag is gekloond, opgesplitst in totaal aantal klonen en unieke klonen.
 
 ![Clone graph](/assets/images/metrics/clone_graph.png)
 
-If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+Als het gebruik laag is in vergelijking met het aantal mensen dat uw project ontdekt, zijn er twee zaken waarmee u rekening moet houden. Een van beide:
 
-* Your project isn't successfully converting your audience, or
-* You're attracting the wrong audience
+* Uw project slaagt er niet in uw publiek te converteren, of
+* Je trekt het verkeerde publiek aan
 
-For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+Als uw project bijvoorbeeld op de voorpagina van Hacker News belandt, ziet u waarschijnlijk een piek in de ontdekking (verkeer), maar een lagere conversieratio, omdat u iedereen op Hacker News bereikt. Als uw Ruby-project echter wordt gepresenteerd op een Ruby-conferentie, is de kans groter dat u een hoge conversieratio ziet bij een gericht publiek.
 
-Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+Probeer erachter te komen waar uw publiek vandaan komt en vraag anderen om feedback op uw projectpagina om erachter te komen met welke van deze twee problemen u te maken heeft.
 
-Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+Als je eenmaal weet dat mensen je project gebruiken, wil je misschien proberen erachter te komen wat ze ermee doen. Bouwen ze erop door uw code te forken en functies toe te voegen? Gebruiken ze het voor wetenschap of zaken?
 
-## Retention
+## Retentie
 
-People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+Mensen vinden uw project en ze gebruiken het. De volgende vraag die je jezelf wilt stellen is: _dragen mensen bij aan dit project?_
 
-It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+Het is nooit te vroeg om na te denken over bijdragers. Zonder dat andere mensen meewerken, riskeer je jezelf in een ongezonde situatie te brengen waarin je project _populair_ is (veel mensen gebruiken het) maar niet _ondersteund_ (niet genoeg tijd om aan de vraag te voldoen).
 
-Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+Retentie vereist ook een [instroom van nieuwe bijdragers](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), aangezien voorheen actieve bijdragers uiteindelijk verder zullen gaan naar andere dingen.
 
-Examples of community metrics that you may want to regularly track include:
+Voorbeelden van communitystatistieken die u regelmatig wilt bijhouden, zijn:
 
-* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+* **Totaal aantal bijdragers en aantal commits per bijdrager:** vertelt je hoeveel bijdragers je hebt en wie er meer of minder actief is. Op GitHub kun je dit bekijken onder "Insights" -> "Contributors". Op dit moment telt deze grafiek alleen bijdragers die zich hebben gecommitteerd aan de standaardvertakking van de repository.
 
-![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+![Bijdrager-grafiek](/assets/images/metrics/repo_contributors_specific_graph.png)
 
-* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+* **Eerste keer, losse en terugkerende bijdragers:** Helpt u bij te houden of u nieuwe bijdragers krijgt en of ze terugkomen. (Toevallige bijdragers zijn bijdragers met een laag aantal commits. Of dat nu één commit is, minder dan vijf commits of iets anders, is aan jou.) Zonder nieuwe bijdragers kan de community van je project stagneren.
 
-* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+* **Aantal openstaande issues en openstaande pull-verzoeken:** Als deze aantallen te hoog worden, heb je wellicht hulp nodig bij het testen van issues en codebeoordelingen.
 
-* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+* **Aantal _geopende_ issues en _geopende_ pull requests:** Geopende issues betekent dat iemand genoeg geeft om je project om een ​​issue te openen. Als dat aantal in de loop van de tijd toeneemt, suggereert dit dat mensen geïnteresseerd zijn in uw project.
 
-* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+* **Soorten bijdragen:** Bijvoorbeeld commits, typefouten of bugs verhelpen, of commentaar geven op een probleem.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
-  Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+  Open source is meer dan alleen code. Succesvolle open source-projecten omvatten bijdragen aan code en documentatie, samen met gesprekken over deze veranderingen.
+  
+  _Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes._
   <p markdown="1" class="pquote-credit">
 — @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
   </p>
 </aside>
 
-## Maintainer activity
+## open source beheerdersactiviteit
 
-Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+Ten slotte wilt u de cirkel sluiten door ervoor te zorgen dat de beheerders van uw project het volume van de ontvangen bijdragen aankunnen. De laatste vraag die je jezelf wilt stellen is: _Reageer ik (of zijn wij) op onze community?_
 
-Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+Niet-reagerende beheerders worden een bottleneck voor open source-projecten. Als iemand een bijdrage indient maar nooit iets van een onderhouder hoort, kan hij of zij zich ontmoedigd voelen en vertrekken.
 
-[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+[Onderzoek van Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggereert dat het reactievermogen van de open source-onderhouder een cruciale factor is bij het aanmoedigen van herhaalde bijdragen.
 
-Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+Overweeg om bij te houden hoe lang het duurt voordat u (of een andere onderhouder) reageert op bijdragen, of dit nu een probleem of een pull-verzoek is. Reageren vereist geen actie. Het kan zo simpel zijn als te zeggen: _"Bedankt voor uw inzending! Ik zal dit binnen de komende week beoordelen."_
 
-You could also measure the time it takes to move between stages in the contribution process, such as:
+U kunt ook de tijd meten die nodig is om tussen fasen in het bijdrageproces te schakelen, zoals:
 
-* Average time an issue remains open
-* Whether issues get closed by PRs
-* Whether stale issues get closed
-* Average time to merge a pull request
+* Gemiddelde tijd dat een probleem open blijft
+* Of kwesties worden gesloten door PR's
+* Of oude problemen worden gesloten
+* Gemiddelde tijd om een ​​pull-aanvraag samen te voegen
 
-## Use 📊 to learn about people
+## Gebruik 📊 om over mensen te leren
 
-Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+Door statistieken te begrijpen, kunt u een actief, groeiend open source-project opzetten. Zelfs als u niet elke statistiek op een dashboard volgt, kunt u het bovenstaande framework gebruiken om uw aandacht te richten op het soort gedrag dat uw project zal helpen gedijen.
diff --git a/_articles/nl/starting-a-project.md b/_articles/nl/starting-a-project.md
index b7502bc5744..a52b65499d4 100644
--- a/_articles/nl/starting-a-project.md
+++ b/_articles/nl/starting-a-project.md
@@ -1,14 +1,14 @@
 ---
 lang: nl
-title: Starting an Open Source Project
-description: Learn more about the world of open source and get ready to launch your own project.
+title: Een open source-project starten
+description: Leer meer over de wereld van open source en bereid je voor om je eigen project te lanceren.
 class: beginners
 toc:
-  the-what-and-why-of-open-source: "The what and why of open source"
-  should-i-launch-my-own-open-source-project: "Should I launch my own open source project?"
-  launching-your-own-open-source-project: "Launching your own open source project"
-  naming-and-branding-your-project: "Naming and branding your project"
-  your-pre-launch-checklist: "Your pre-launch checklist"
+  the-what-and-why-of-open-source: "Het wat en waarom van open source"
+  should-i-launch-my-own-open-source-project: "Moet ik mijn eigen open source-project lanceren?"
+  launching-your-own-open-source-project: "Uw eigen open source-project lanceren"
+  naming-and-branding-your-project: "Geef uw project een naam en branding"
+  your-pre-launch-checklist: "Uw checklist vóór de lancering"
 order: 2
 image: /assets/images/cards/beginner.png
 related:
@@ -16,7 +16,7 @@ related:
   - building
 ---
 
-## The "what" and "why" of open source
+## Het "wat" en "waarom" van open source
 
 So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
 
@@ -56,7 +56,7 @@ Because [an open source license requires](https://opensource.org/osd-annotated)
 
 As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
 
-## Should I launch my own open source project?
+## Moet ik mijn eigen open source-project lanceren?
 
 The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
 
@@ -104,7 +104,7 @@ If your goal is to learn how to collaborate with others or understand how open s
 
 If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
 
-## Launching your own open source project
+## Uw eigen open source-project lanceren
 
 There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
 
@@ -212,7 +212,7 @@ Much like open source licenses, there are also emerging standards for codes of c
 
 Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
 
-## Naming and branding your project
+## Geef uw project een naam en branding
 
 Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
 
@@ -259,7 +259,7 @@ Beyond how you write words, your coding style may also become part of your proje
 
 It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
 
-## Your pre-launch checklist
+## Uw checklist vóór de lancering
 
 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.
 
@@ -357,6 +357,6 @@ If you're a company or organization:
   </label>
 </div>
 
-## You did it!
+## Je hebt het gedaan!
 
-Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.
+Gefeliciteerd met het openen van uw eerste project. Ongeacht de uitkomst, werken in het openbaar is een geschenk voor de gemeenschap. Met elk commit-, commentaar- en pull-verzoek creëer je kansen voor jezelf en voor anderen om te leren en te groeien.

From 763c9913f6f360dce74243f135eff5b587f90232 Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Thu, 27 Aug 2020 16:19:23 +0200
Subject: [PATCH 070/749] Article 'Starting a project'

---
 _articles/nl/building-community.md |   6 +-
 _articles/nl/legal.md              |   2 +-
 _articles/nl/starting-a-project.md | 262 +++++++++++++++--------------
 3 files changed, 141 insertions(+), 129 deletions(-)

diff --git a/_articles/nl/building-community.md b/_articles/nl/building-community.md
index cde8653013c..ac1e1e6d370 100644
--- a/_articles/nl/building-community.md
+++ b/_articles/nl/building-community.md
@@ -30,8 +30,8 @@ Bedenk bij het opbouwen van uw community hoe iemand bovenaan de trechter (een po
 
 Begin met uw documentatie:
 
-* **Maak het voor iemand gemakkelijk om uw project te gebruiken.** [Een vriendelijke README](../starting-a-project/#writing-a-readme) 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/#writing-your-contributing-guidelines) en uw issues up-to-date houden.
+* **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.
 * [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.
 
@@ -226,7 +226,7 @@ Het hoofd koel houden is niet eenvoudig, maar leiderschap tonen verbetert de gez
 
 ### Behandel uw README als een grondwet
 
-Uw README is [meer dan alleen een reeks instructies](../starting-a-project/#writing-a-readme). Het is ook een plek om te praten over uw doelen, productvisie en roadmap. Als mensen overdreven gefocust zijn op het bespreken van de waarde van een bepaalde functie, kan het helpen om je README opnieuw te bekijken en te praten over de hogere visie van je project. Focussen op je README maakt het gesprek ook onpersoonlijk, zodat je een constructieve discussie kunt voeren.
+Uw README is [meer dan alleen een reeks instructies](../starting-a-project/#een-readme-schrijven). Het is ook een plek om te praten over uw doelen, productvisie en roadmap. Als mensen overdreven gefocust zijn op het bespreken van de waarde van een bepaalde functie, kan het helpen om je README opnieuw te bekijken en te praten over de hogere visie van je project. Focussen op je README maakt het gesprek ook onpersoonlijk, zodat je een constructieve discussie kunt voeren.
 
 ### Concentreer u op de reis, niet op de bestemming
 
diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
index e6e35f7ede4..8e4c84d961d 100644
--- a/_articles/nl/legal.md
+++ b/_articles/nl/legal.md
@@ -134,7 +134,7 @@ For better or worse, consider letting them know even if it's a personal project.
 
 * **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
 
-* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#naamconflicten-vermijden). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
 
 * **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
 
diff --git a/_articles/nl/starting-a-project.md b/_articles/nl/starting-a-project.md
index a52b65499d4..2fa10f93d1d 100644
--- a/_articles/nl/starting-a-project.md
+++ b/_articles/nl/starting-a-project.md
@@ -18,278 +18,290 @@ related:
 
 ## Het "wat" en "waarom" van open source
 
-So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+Dus je denkt erover om aan de slag te gaan met open source? Gefeliciteerd! De wereld waardeert uw bijdrage. Laten we het hebben over wat open source is en waarom mensen het doen.
 
-### What does "open source" mean?
+### Wat betekent "open source"?
 
-When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+Als een project open source is, betekent dit **dat iedereen vrij is om uw project voor elk doel te gebruiken, bestuderen, wijzigen en distribueren.** Deze machtigingen worden afgedwongen via [een open source-licentie](https://opensource.org/licenties).
 
-Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+Open source is krachtig omdat het de barrières voor acceptatie en samenwerking verlaagt, waardoor mensen projecten snel kunnen verspreiden en verbeteren. Ook omdat het gebruikers de mogelijkheid geeft om hun eigen computergebruik te beheersen, in vergelijking met closed source. Een bedrijf dat open source software gebruikt, heeft bijvoorbeeld de mogelijkheid om iemand in te huren om aangepaste verbeteringen aan de software aan te brengen, in plaats van uitsluitend te vertrouwen op de productbeslissingen van een closed source-leverancier.
 
-_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+_Vrije software (Free software)_ verwijst naar dezelfde reeks projecten als _open source_. Soms zie je ook [deze termen](https://en.wikipedia.org/wiki/Free_and_open-source_software) gecombineerd als "free en open source software" (FOSS) of "free, libre en open source software" (FLOSS). _Free_ en _libre_ verwijzen naar vrijheid, [niet de prijs](#betekend-open-source-gratis).
 
-### Why do people open source their work?
+### Waarom stellen mensen hun werk als open source beschikbaar?
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
-  One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+  Een van de meest lonende ervaringen die ik krijg bij het gebruiken van en samenwerken aan open source, komt voort uit de relaties die ik opbouw met andere ontwikkelaars die met veel van dezelfde problemen worden geconfronteerd als ik.
+  
+  _One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am._
   <p markdown="1" class="pquote-credit">
-— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+— @kentcdodds, ["Het was geweldig om in Open Source te komen"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
   </p>
 </aside>
 
-[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+[Er zijn veel redenen](https://ben.balter.com/2015/11/23/why-open-source/) waarom een persoon of organisatie een project zou willen open source maken. Enkele voorbeelden zijn:
 
-* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+* **Samenwerking:** Open source-projecten kunnen wijzigingen van iedereen ter wereld accepteren. [Exercism](https://github.com/exercism/) is bijvoorbeeld een oefenplatform voor programmeren met meer dan 350 medewerkers.
 
-* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **Adoptie en remixen:** Open source-projecten kunnen door iedereen voor bijna elk doel worden gebruikt. Mensen kunnen er zelfs andere dingen mee bouwen. [WordPress](https://github.com/WordPress) is bijvoorbeeld begonnen als een splitsing van een bestaand project met de naam [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparantie:** Iedereen kan een open source-project inspecteren op fouten of inconsistenties. Transparantie is belangrijk voor regeringen zoals [Bulgarije](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) of de [Verenigde Staten](https://sourcecode.cio.gov/), gereguleerde industrieën zoals het bankwezen of de gezondheidszorg, en beveiligingssoftware zoals [Let's Encrypt](https://github.com/letsencrypt).
 
-Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+Open source is niet alleen voor software. U kunt alles openen, van datasets tot boeken. Bekijk [GitHub Explore](https://github.com/explore) voor ideeën over wat je nog meer kunt open source.
 
-### Does open source mean "free of charge"?
+### Betekend open source gratis?
 
-One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+Een van de grootste voordelen van open source is dat het geen geld kost. "Gratis" is echter een bijproduct van de totale waarde van open source.
 
-Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+Omdat [een open source-licentie vereist](https://opensource.org/osd-annotated) dat iedereen uw project voor bijna elk doel kan gebruiken, wijzigen en delen, zijn projecten zelf meestal gratis. Als het project geld kost om te gebruiken, kan iedereen legaal een kopie maken en in plaats daarvan de gratis versie gebruiken.
 
-As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+Als gevolg hiervan zijn de meeste open source-projecten gratis, maar 'gratis' maakt geen deel uit van de open source-definitie. Er zijn manieren om indirect kosten in rekening te brengen voor open source-projecten via dubbele licenties of beperkte functies, terwijl ze toch voldoen aan de officiële definitie van open source.
 
 ## Moet ik mijn eigen open source-project lanceren?
 
-The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+Het korte antwoord is ja, want wat de uitkomst ook is, het starten van je eigen project is een geweldige manier om te leren hoe open source werkt.
 
-If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+Als je nog nooit een project hebt geopend, ben je misschien zenuwachtig over wat mensen zullen zeggen, of dat iemand het überhaupt zal opmerken. Als dit klinkt zoals jij, ben je niet de enige!
 
-Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+Open source werken is net als elke andere creatieve activiteit, of het nu gaat om schrijven of schilderen. Het kan eng aanvoelen om je werk met de wereld te delen, maar de enige manier om beter te worden, is door te oefenen - zelfs als je geen publiek hebt.
 
-If you're not yet convinced, take a moment to think about what your goals might be.
+Als u nog niet overtuigd bent, neem dan even de tijd om na te denken over uw doelen.
 
-### Setting your goals
+### Je doelen stellen
 
-Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself,  _why am I open sourcing this project?_
+Doelen kunnen u helpen erachter te komen waaraan u moet werken, waar u nee tegen moet zeggen en waar u hulp van anderen nodig heeft. Begin met jezelf af te vragen: _waarom ben ik open source voor dit project?_
 
-There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+Er is geen goed antwoord op deze vraag. Mogelijk hebt u meerdere doelen voor een enkel project, of verschillende projecten met verschillende doelen.
 
-If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+Als het je enige doel is om met je werk te pronken, wil je misschien niet eens bijdragen, en dat zeg je zelfs in je README. Aan de andere kant, als u donateurs wilt, investeert u tijd in duidelijke documentatie en zorgt u ervoor dat nieuwkomers zich welkom voelen.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
-  At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+  Op een gegeven moment heb ik een aangepaste UIAlertView gemaakt die ik gebruikte ... en ik besloot het open source te maken. Dus ik heb het aangepast om het dynamischer te maken en het naar GitHub geüpload. Ik schreef ook mijn eerste documentatie waarin ik aan andere ontwikkelaars uitlegde hoe ze het voor hun projecten konden gebruiken. Waarschijnlijk heeft niemand het ooit gebruikt omdat het een eenvoudig project was, maar ik voelde me goed over mijn bijdrage.
+  
+  _At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution._
   <p markdown="1" class="pquote-credit">
-— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+— @mavris, ["Zelf onderwezen softwareontwikkelaars: waarom open source belangrijk voor ons is"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
   </p>
 </aside>
 
-As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+Naarmate uw project groeit, heeft uw gemeenschap mogelijk meer nodig dan alleen code van u. Reageren op problemen, code herzien en uw project promoten, zijn allemaal belangrijke taken in een open source-project.
 
-While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+Hoewel de hoeveelheid tijd die u aan niet-coderende taken besteedt, afhangt van de omvang en reikwijdte van uw project, moet u als onderhouder erop voorbereid zijn om ze zelf aan te pakken of iemand te zoeken om u te helpen.
 
-**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+**Als u deel uitmaakt van een bedrijf dat een project opent,** zorg ervoor dat uw project over de interne middelen beschikt die het nodig heeft om te gedijen. U wilt weten wie verantwoordelijk is voor het onderhoud van het project na de lancering, en hoe u die taken met uw community deelt.
 
-If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+Als u een specifiek budget of personeel nodig heeft voor promotie, operaties en het onderhouden van het project, begin die gesprekken dan vroeg.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-  As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+  Als u begint met het openen van het project, is het belangrijk om ervoor te zorgen dat uw beheerprocessen rekening houden met de bijdragen en capaciteiten van de gemeenschap rond uw project. Wees niet bang om bijdragers die niet in uw bedrijf werkzaam zijn, te betrekken bij de belangrijkste aspecten van het project, vooral als ze regelmatig bijdragen.
+  
+  _As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors._
   <p markdown="1" class="pquote-credit">
-— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+— @captainsafia, ["Dus je wilt een project openen, hè?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
   </p>
 </aside>
 
-### Contributing to other projects
+### Bijdragen aan andere projecten
 
-If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+Als het uw doel is om te leren samenwerken met anderen of om te begrijpen hoe open source werkt, overweeg dan om bij te dragen aan een bestaand project. Begin met een project dat je al gebruikt en waar je van houdt. Bijdragen aan een project kan zo simpel zijn als het corrigeren van typefouten of het bijwerken van documentatie.
 
-If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+Als u niet zeker weet hoe u als bijdrager aan de slag kunt gaan, bekijk dan onze [Hoe u kunt bijdragen aan Open Source-gids](../how-to-contribute/).
 
 ## Uw eigen open source-project lanceren
 
-There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+Er is geen perfect moment om uw werk open source te maken. U kunt een idee openen, een werk in uitvoering of na jarenlang closed source te zijn geweest.
 
-Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+Over het algemeen moet u uw project openen als u zich op uw gemak voelt als anderen uw werk bekijken en er feedback op geven.
 
-No matter which stage you decide to open source your project, every project should include the following documentation:
+Ongeacht in welke fase u besluit uw project te openen, elk project moet de volgende documentatie bevatten:
 
-* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)
+* [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)
-* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
-* [Code of conduct](../code-of-conduct/)
+* [Richtlijnen voor het bijdragen](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Gedragscode](../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.
+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.
 
-If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+Als je project op GitHub staat, zal het plaatsen van deze bestanden in je root-directory met de aanbevolen bestandsnamen GitHub helpen ze te herkennen en automatisch aan je lezers te laten zien.
 
-### Choosing a license
+### Een licentie kiezen
 
-An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+Een open source-licentie garandeert dat anderen uw project zonder repercussies kunnen gebruiken, kopiëren, wijzigen en eraan kunnen bijdragen. Het beschermt je ook tegen plakkerige juridische situaties. **U moet een licentie toevoegen wanneer u een open source-project start.**
 
-Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+Juridisch werk is niet leuk. Het goede nieuws is dat u een bestaande licentie kunt kopiëren en in uw repository kunt plakken. Het duurt maar een minuut om uw harde werk te beschermen.
 
-[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 the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+[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](https://choosealicense.com) om uit te kiezen.
 
-When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+Wanneer u een nieuw project op GitHub maakt, krijgt u de mogelijkheid om een ​​licentie te selecteren. Als u een open source-licentie opneemt, wordt uw GitHub-project open source.
 
-![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+![Kies een licentie](/assets/images/starting-a-project/repository-license-picker.png)
 
-If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+Als u andere vragen of opmerkingen heeft over de juridische aspecten van het beheren van een open source-project, [wij hebben u gedekt](../legal/).
 
-### Writing a README
+### Een README schrijven
 
-READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+README's doen meer dan alleen uitleggen hoe u uw project kunt gebruiken. Ze leggen ook uit waarom uw project ertoe doet en wat uw gebruikers ermee kunnen doen.
 
-In your README, try to answer the following questions:
+Probeer in je README de volgende vragen te beantwoorden:
 
-* What does this project do?
-* Why is this project useful?
-* How do I get started?
-* Where can I get more help, if I need it?
+* Wat doet dit project?
+* Waarom is dit project nuttig?
+* Hoe begin ik eraan?
+* Waar kan ik meer hulp krijgen als ik die nodig heb?
 
-You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+U kunt uw README gebruiken om andere vragen te beantwoorden, zoals hoe u omgaat met bijdragen, wat de doelen van het project zijn en informatie over licenties en attributie. Als u geen bijdragen wilt accepteren, of uw project is nog niet klaar voor productie, schrijf deze informatie dan op.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
-  Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+  Betere documentatie betekent meer gebruikers, minder ondersteuningsverzoeken en meer bijdragers. (...) Onthoud dat u niet uw lezers bent. Er zijn mensen die misschien naar een project komen die totaal andere ervaringen hebben.
+  
+  _Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences._
   <p markdown="1" class="pquote-credit">
-— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+— @tracymakes, ["Schrijven zodat uw woorden worden gelezen (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
   </p>
 </aside>
 
-Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+Soms vermijden mensen het schrijven van een README omdat ze het gevoel hebben dat het project niet af is, of omdat ze geen bijdragen willen. Dit zijn allemaal hele goede redenen om er een te schrijven.
 
-For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+Voor meer inspiratie, probeer @dguo's ["Maak een README"-gids](https://www.makeareadme.com/) of @PurpleBooth's [README-sjabloon](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) om een volledige README te schrijven.
 
-When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+Als je een README-bestand opneemt in de root-directory, zal GitHub het automatisch op de startpagina van de repository weergeven.
 
-### Writing your contributing guidelines
+### Schrijven van uw bijdrage richtlijnen
 
-A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+Een CONTRIBUTING-bestand vertelt uw publiek hoe ze aan uw project kunnen deelnemen. U kunt bijvoorbeeld informatie opnemen over:
 
-* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
-* How to suggest a new feature
-* How to set up your environment and run tests
+* Hoe een bugrapport in te dienen (probeer [sjablonen voor issue en pull-verzoeken](https://github.com/blog/2111-issue-and-pull-request-templates) te gebruiken)
+* Hoe u een nieuwe functie kunt voorstellen
+* Hoe u uw omgeving instelt en tests uitvoert
 
-In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+Naast technische details is een CONTRIBUTING-bestand een gelegenheid om uw verwachtingen voor bijdragen te communiceren, zoals:
 
-* The types of contributions you're looking for
-* Your roadmap or vision for the project
-* How contributors should (or should not) get in touch with you
+* De soorten bijdragen die u zoekt
+* Uw roadmap of visie voor het project
+* Hoe bijdragers wel of niet contact met u moeten opnemen
 
-Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+Het gebruik van een warme, vriendelijke toon en het aanbieden van specifieke suggesties voor bijdragen (zoals het schrijven van documentatie of het maken van een website) kan ertoe bijdragen dat nieuwkomers zich welkom en enthousiast voelen om deel te nemen.
 
-For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+Bijvoorbeeld: [Active Admin](https://github.com/activeadmin/activeadmin/) start [zijn bijdragende gids](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) met:
 
-> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+> Allereerst bedankt dat u overweegt om bij te dragen aan Active Admin. Het zijn mensen zoals jij die Active Admin tot zo'n geweldig hulpmiddel maken.
 
-In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+In de vroegste stadia van uw project kan uw CONTRIBUTING-bestand eenvoudig zijn. U moet altijd uitleggen hoe u bugs of problemen met bestanden meldt, en welke technische vereisten (zoals tests) u heeft om een bijdrage te leveren.
 
-Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+Na verloop van tijd kunt u andere veelgestelde vragen aan uw CONTRIBUTING-bestand toevoegen. Als u deze informatie opschrijft, zullen minder mensen u keer op keer dezelfde vragen stellen.
 
-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/).
+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 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 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.
 
 ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
-### Establishing a code of conduct
+### Opstellen van een gedragscode
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
-  We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+  We hebben allemaal ervaringen gehad waarbij we te maken kregen met wat waarschijnlijk misbruik was, hetzij als onderhouder die probeerde uit te leggen waarom iets op een bepaalde manier moest zijn, of als gebruiker ... die een simpele vraag stelde. (...) Een gedragscode wordt een gemakkelijk te raadplegen en koppelbaar document dat aangeeft dat uw team constructief discours zeer serieus neemt.
+  
+  _We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously._
   <p markdown="1" class="pquote-credit">
-— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+— @mlynch, ["Open Source een gelukkiger plek maken"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
   </p>
 </aside>
 
-Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+Ten slotte helpt een gedragscode om basisregels vast te stellen voor het gedrag van de deelnemers aan uw project. Dit is vooral waardevol als u een open source-project start voor een gemeenschap of bedrijf. Een gedragscode stelt je in staat om gezond, constructief gemeenschapsgedrag te faciliteren, wat je stress als onderhouder zal verminderen.
 
-For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+Raadpleeg voor meer informatie onze [Gedragscode-gids](../code-of-conduct/).
 
-In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+Naast het communiceren van _hoe_ je verwacht dat deelnemers zich gedragen, beschrijft een gedragscode ook vaak op wie deze verwachtingen van toepassing zijn, wanneer ze van toepassing zijn en wat te doen bij een overtreding.
 
-Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+Net als bij open source-licenties, zijn er ook nieuwe normen voor gedragscodes, zodat u deze niet zelf hoeft te schrijven. De [Bijdrager Covenant](https://contributor-covenant.org/) is een drop-in gedragscode die wordt gebruikt door [meer dan 40.000 open source-projecten](https://www.contributor-covenant.org/adopters), inclusief Kubernetes, Rails en Swift. Welke tekst u ook gebruikt, u moet bereid zijn om uw gedragscode waar nodig af te dwingen.
 
-Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+Plak de tekst rechtstreeks in een CODE_OF_CONDUCT-bestand in uw repository. Bewaar het bestand in de root-directory van je project zodat het gemakkelijk te vinden is, en link ernaar vanuit je README.
 
 ## Geef uw project een naam en branding
 
-Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+Branding is meer dan een flitsend logo of pakkende projectnaam. Het gaat erom hoe u over uw project praat en wie u bereikt met uw bericht.
 
-### Choosing the right name
+### De juiste naam kiezen
 
-Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+Kies een naam die gemakkelijk te onthouden is en idealiter een idee geeft van wat het project doet. Bijvoorbeeld:
 
-* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
-* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+* [Sentry](https://github.com/getsentry/sentry) controleert apps op crashrapportage
+* [Thin](https://github.com/macournoyer/thin) is een snelle en eenvoudige Ruby-webserver
 
-If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+Als u voortbouwt op een bestaand project, kan het gebruik van hun naam als voorvoegsel helpen verduidelijken wat uw project doet (bijvoorbeeld [node-fetch](https://github.com/bitinn/node-fetch) brengt `window.fetch` naar Node.js).
 
-Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+Overweeg vooral duidelijkheid. Woordspelingen zijn leuk, maar onthoud dat sommige grappen mogelijk niet vertalen naar andere culturen of mensen met andere ervaringen dan jij. Sommige van uw potentiële gebruikers kunnen werknemers van het bedrijf zijn: u wilt ze niet ongemakkelijk maken als ze uw project op het werk moeten uitleggen!
 
-### Avoiding name conflicts
+### Naamconflicten vermijden
 
-[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+[Controleer op open source-projecten met een vergelijkbare naam](http://ivantomic.com/projects/ospnc/), vooral als je dezelfde taal of hetzelfde ecosysteem deelt. Als uw naam overlapt met een populair bestaand project, kunt u uw publiek in verwarring brengen.
 
-If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+Als u wilt dat een website, Twitter-handle of andere eigenschappen uw project vertegenwoordigen, zorg er dan voor dat u de gewenste namen krijgt. Idealiter [reserveer deze namen nu](https://instantdomainsearch.com/) voor gemoedsrust, zelfs als u ze nog niet wilt gebruiken.
 
-Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+Zorg ervoor dat de naam van uw project geen inbreuk maakt op handelsmerken. Een bedrijf kan u vragen om uw project later stop te zetten, of zelfs juridische stappen tegen u ondernemen. Het is het risico gewoon niet waard.
 
-You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+U kunt de [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) raadplegen voor handelsmerkconflicten. Als u bij een bedrijf werkt, is dit een van de dingen waarmee uw [juridische team u kan helpen](../legal/).
 
-Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+Voer tot slot een snelle Google-zoekopdracht uit naar uw projectnaam. Zullen mensen uw project gemakkelijk kunnen vinden? Verschijnt er iets anders in de zoekresultaten waarvan u niet wilt dat ze het zien?
 
-### How you write (and code) affects your brand, too!
+### Hoe u schrijft (en codeert), heeft ook invloed op uw merk!
 
-Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+Gedurende de levensduur van uw project zult u veel schrijven: README's, tutorials, gemeenschapsdocumenten, reageren op problemen, misschien zelfs nieuwsbrieven en mailinglijsten.
 
-Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+Of het nu gaat om officiële documentatie of een informele e-mail, uw schrijfstijl maakt deel uit van het merk van uw project. Bedenk hoe u op uw publiek zou kunnen overkomen en of dat de toon is die u wilt overbrengen.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+  Ik probeerde betrokken te zijn bij elke thread op de mailinglijst en voorbeeldig gedrag te tonen, aardig te zijn tegen mensen, hun problemen serieus te nemen en in het algemeen behulpzaam te zijn. Na een tijdje bleven mensen rondhangen om niet alleen vragen te stellen, maar ook om te helpen met het beantwoorden, en tot mijn grote vreugde bootsten ze mijn stijl na.
+  
+  _I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style._
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl op [CouchDB](https://github.com/apache/couchdb), ["Duurzaam open source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
-Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+Het gebruik van warme, inclusieve taal (zoals 'zij', zelfs als je naar de enige persoon verwijst), kan er voor zorgen dat je project een welkom gevoel krijgt bij nieuwe bijdragers. Blijf bij eenvoudige taal, aangezien veel van uw lezers mogelijk geen moedertaalsprekers Engels zijn.
 
-Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+Naast hoe u woorden schrijft, kan uw codeerstijl ook onderdeel worden van het merk van uw project. [Angular](https://angular.io/guide/styleguide) en [jQuery](https://contribute.jquery.org/style-guide/js/) zijn twee voorbeelden van projecten met rigoureuze coderingsstijlen en richtlijnen.
 
-It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+Het is niet nodig om een stijlgids voor je project te schrijven als je net begint, en het kan zijn dat je het toch leuk vindt om verschillende codeerstijlen in je project op te nemen. Maar u moet anticiperen op hoe uw schrijf- en coderingsstijl verschillende soorten mensen zou kunnen aantrekken of ontmoedigen. De vroegste stadia van uw project zijn uw kans om het precedent te scheppen dat u wenst te zien.
 
 ## Uw checklist vóór de lancering
 
-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.
+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.
 
-**Documentation**
+**Documentatie**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-    Project has a LICENSE file with an open source license
+    Project heeft een LICENSE-bestand met een open source-licentie
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+    Project heeft basisdocumentatie (README, CONTRIBUTING, CODE_OF_CONDUCT)
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+    De naam is gemakkelijk te onthouden, geeft een idee van wat het project doet en is niet in strijd met een bestaand project of inbreuk op handelsmerken
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-    The issue queue is up-to-date, with issues clearly organized and labeled
+    De issue wachtrij is up-to-date, met issues duidelijk geordend en gelabeld
   </label>
 </div>
 
@@ -298,55 +310,55 @@ Ready to open source your project? Here's a checklist to help. Check all the box
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    Project uses consistent code conventions and clear function/method/variable names
+    Project gebruikt consistente codeconventies en duidelijke functie/methode/variabelenamen
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    The code is clearly commented, documenting intentions and edge cases
+    De code is duidelijk becommentarieerd en documenteert intenties en randgevallen
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+    Er zijn geen gevoelige materialen in de revisiegeschiedenis, problemen of pull-verzoeken (bijvoorbeeld wachtwoorden of andere niet-openbare informatie)
   </label>
 </div>
 
-**People**
+**Mensen**
 
-If you're an individual:
+Als je een individu bent:
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  Je hebt met de juridische afdeling gesproken en/of je begrijpt het IP/IE en open source-beleid van je bedrijf (als je ergens een werknemer bent)
   </label>
 </div>
 
-If you're a company or organization:
+Als u een bedrijf of organisatie bent:
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    You've talked to your legal department
+    U heeft met uw juridische afdeling gesproken
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    You have a marketing plan for announcing and promoting the project
+    Je hebt een marketingplan om het project aan te kondigen en te promoten
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+    Iemand zet zich in voor het beheren van community-interacties (reageren op problemen, beoordelen en samenvoegen van pull-verzoeken)
   </label>
 </div>
 

From 75d6f45fd5cf2c0422649ec1d333d8133bfd7774 Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Thu, 27 Aug 2020 16:39:45 +0200
Subject: [PATCH 071/749] Article 'Leadership and Governance'

---
 _articles/nl/leadership-and-governance.md | 117 ++++++++++++----------
 1 file changed, 65 insertions(+), 52 deletions(-)

diff --git a/_articles/nl/leadership-and-governance.md b/_articles/nl/leadership-and-governance.md
index b63e1d92aff..cfc12b71160 100644
--- a/_articles/nl/leadership-and-governance.md
+++ b/_articles/nl/leadership-and-governance.md
@@ -21,39 +21,43 @@ related:
 
 ## Inzicht in governance voor uw groeiende project
 
-Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+Je project groeit, mensen zijn betrokken en je bent vastbesloten om dit ding gaande te houden. In dit stadium vraagt u zich misschien af hoe u regelmatige projectmedewerkers in uw workflow kunt opnemen, of het nu gaat om iemand commit-toegang te geven of om discussies in de gemeenschap op te lossen. Als u vragen heeft, hebben we de antwoorden.
 
 ## Wat zijn voorbeelden van formele rollen die worden gebruikt in open source-projecten?
 
-Many projects follow a similar structure for contributor roles and recognition.
+Veel projecten volgen een vergelijkbare structuur voor rollen en erkenning van medewerkers.
 
-What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+Wat deze rollen eigenlijk betekenen, is geheel aan jou. Hier zijn een paar soorten rollen die u wellicht herkent:
 
-* **Maintainer**
-* **Contributor**
+* **Open source-beheerder / Maintainer**
+* **Bijdrager / Contributor**
 * **Committer**
 
-**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+**Voor sommige projecten zijn "open source-beheerders"** de enige mensen in een project met commit-toegang. In andere projecten zijn het gewoon de mensen die in de README worden vermeld als beheerders.
 
-A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+Een onderhouder hoeft niet per se iemand te zijn die code voor uw project schrijft. Het kan iemand zijn die veel werk heeft verzet om uw project te evangeliseren, of schriftelijke documentatie die het project toegankelijker heeft gemaakt voor anderen. Ongeacht wat ze van dag tot dag doen, een onderhouder is waarschijnlijk iemand die verantwoordelijkheid voelt over de richting van het project en zich inzet om het te verbeteren.
 
-**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+**Een 'bijdrager' kan iedereen zijn** die opmerkingen maakt over een probleem of pull-verzoek, mensen die waarde toevoegen aan het project (of het nu gaat om triaging-problemen, het schrijven van code of het organiseren van evenementen), of iemand met een samengevoegd pull-verzoek (misschien de engste definitie van een bijdrager).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+  \[Voor Node.js\] is elke persoon die komt opdagen om commentaar te geven op een probleem of code in te dienen, lid van de community van een project. Alleen al om ze te kunnen zien, betekent dat ze de grens hebben overschreden van een gebruiker naar een bijdrager.
+  
+  _\[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor._
   <p markdown="1" class="pquote-credit">
-— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+— @mikeal, ["Gezond Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
   </p>
 </aside>
 
-**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+**De term "committer"** kan worden gebruikt om commit-toegang, wat een specifiek type verantwoordelijkheid is, te onderscheiden van andere vormen van bijdrage.
 
-While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#waarom-bijdragen-aan-open-source) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+Hoewel u uw projectrollen op elke gewenste manier kunt definiëren, [overweeg het gebruik van bredere definities](../how-to-contribute/#waarom-bijdragen-aan-open-source) om meer vormen van bijdrage aan te moedigen. U kunt leiderschapsrollen gebruiken om formeel mensen te erkennen die een uitstekende bijdrage aan uw project hebben geleverd, ongeacht hun technische vaardigheden.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
-  You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+  Je kent me misschien als de "uitvinder" van Django... maar eigenlijk ben ik de man die werd aangenomen om aan iets te werken een jaar nadat het al gemaakt was. (...) Mensen vermoeden dat ik succesvol ben vanwege mijn programmeervaardigheid... maar ik ben op zijn best een gemiddelde programmeur.
+  
+  _You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer._
   <p markdown="1" class="pquote-credit">
 — @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
   </p>
@@ -61,40 +65,44 @@ While you can define your project roles any way you'd like, [consider using broa
 
 ## Hoe formaliseer ik deze leiderschapsrollen?
 
-Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+Het formaliseren van uw leiderschapsrollen helpt mensen zich eigenaar te voelen en vertelt andere gemeenschapsleden naar wie ze moeten zoeken voor hulp.
 
-For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+Voor een kleiner project kan het aanwijzen van leiders net zo eenvoudig zijn als het toevoegen van hun naam aan uw README of een CONTRIBUTORS tekstbestand.
 
-For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+Voor een groter project, als u een website heeft, maak dan een teampagina aan of vermeld uw projectleiders daar. [Postgres](https://github.com/postgres/postgres/) heeft bijvoorbeeld een [uitgebreide teampagina](https://www.postgresql.org/community/contributors/) met korte profielen voor elke bijdrager.
 
-If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+Als uw project een zeer actieve bijdragersgemeenschap heeft, kunt u een "kernteam" van beheerders vormen, of zelfs subcommissies van mensen die de verantwoordelijkheid nemen voor verschillende probleemgebieden (bijvoorbeeld beveiliging, probleemopsporing of gedrag van de gemeenschap). Laat mensen zichzelf organiseren en vrijwilligerswerk doen voor de rollen waar ze het meest enthousiast over zijn, in plaats van ze toe te wijzen.
 
 <aside markdown="1" class="pquote">
-  \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+  \[We\] vullen het kernteam aan met verschillende "subteams". Elk subteam is gericht op een specifiek gebied, bijvoorbeeld taalontwerp of bibliotheken. (...) Om wereldwijde coördinatie en een sterke, samenhangende visie voor het project als geheel te verzekeren, wordt elk subteam geleid door een lid van het kernteam.
+  
+  _\[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team._
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+— ["Rust Bestuur RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+Leiderschapsteams willen misschien een aangewezen kanaal creëren (zoals op IRC) of regelmatig bijeenkomen om het project te bespreken (zoals op Gitter of Google Hangout). U kunt die bijeenkomsten zelfs openbaar maken, zodat andere mensen kunnen luisteren. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), bijvoorbeeld [host wekelijks kantooruren](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
-Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+Als u eenmaal leiderschapsrollen heeft vastgesteld, vergeet dan niet te documenteren hoe mensen deze kunnen bereiken! Stel een duidelijk proces vast voor hoe iemand een onderhouder kan worden of lid kan worden van een subcommissie in uw project, en schrijf het op uw GOVERNANCE.md.
 
-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.
+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.
 
-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/#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://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).
 
 ## Wanneer moet ik iemand commit-toegang geven?
 
-Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+Sommige mensen vinden dat je commitment moet geven aan iedereen die een bijdrage levert. Dit zou meer mensen kunnen aanmoedigen om zich eigenaar te voelen van uw project.
 
-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!
+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!
 
-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.
+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.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
-  Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+  Elke keer dat iemand je een pull-request stuurt, geef hem dan commit-toegang tot je project. Hoewel het in het begin misschien ongelooflijk stom klinkt, kun je met deze strategie de ware kracht van GitHub ontketenen. (...) Als mensen eenmaal commit-toegang hebben, zijn ze niet langer bang dat hun patch niet zal worden samengevoegd... waardoor ze er veel meer werk in steken.
+  
+  _Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it._
   <p markdown="1" class="pquote-credit">
 — @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
   </p>
@@ -102,64 +110,69 @@ If your project is on GitHub, you can use [protected branches](https://help.gith
 
 ## Wat zijn enkele van de algemene bestuursstructuren voor open source-projecten?
 
-There are three common governance structures associated with open source projects.
+Er zijn drie algemene bestuursstructuren die verband houden met open source-projecten.
 
-* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+* **BDFL:** BDFL staat voor "Benevolent Dictator for Life". Volgens deze structuur heeft één persoon (meestal de oorspronkelijke auteur van het project) het laatste woord over alle belangrijke projectbeslissingen. [Python](https://github.com/python) is een klassiek voorbeeld. Kleinere projecten zijn waarschijnlijk standaard BDFL, omdat er maar één of twee beheerders zijn. Een project dat is ontstaan ​​bij een bedrijf kan ook in de categorie BDFL vallen.
 
-* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+* **Meritocratie:** **(Opmerking: de term "meritocratie" heeft een negatieve connotatie voor sommige gemeenschappen en heeft een [complexe sociale en politieke geschiedenis](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Onder een meritocratie krijgen actieve projectmedewerkers (degenen die "verdienste" aantonen) een formele besluitvormende rol. Beslissingen worden meestal genomen op basis van zuivere stemconsensus. Het concept van meritocratie is ontwikkeld door de [Apache Foundation](https://www.apache.org/); [alle Apache-projecten](https://www.apache.org/index.html#projects-list) zijn meritocratieën. Bijdragen kunnen alleen worden gedaan door individuen die zichzelf vertegenwoordigen, niet door een bedrijf.
 
-* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
+* **Liberale bijdrage (_Liberal contribution_):** Volgens een liberaal contributiemodel worden de mensen die het meeste werk doen als meest invloedrijk erkend, maar dit is gebaseerd op huidig ​​werk en niet op historische bijdragen. Beslissingen voor grote projecten worden genomen op basis van een proces van consensus zoeken (bespreek belangrijke grieven) in plaats van pure stemming, en het streven is om zoveel mogelijk gemeenschapsperspectieven op te nemen. Populaire voorbeelden van projecten die een liberaal contributiemodel gebruiken, zijn onder meer [Node.js] (https://foundation.nodejs.org/) en [Rust] (https://www.rust-lang.org/).
 
-Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+Welke moet je gebruiken? Het is aan jou! Elk model heeft voordelen en afwegingen. En hoewel ze in eerste instantie misschien heel anders lijken, hebben alle drie de modellen meer gemeen dan ze lijken. Bekijk deze sjablonen als u geïnteresseerd bent in het adopteren van een van deze modellen:
 
-* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
-* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
-* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+* [BDFL-modelsjabloon](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Modelmodel voor meritocratie](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberale bijdragebeleid](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
 
 ## Heb ik beheersdocumenten nodig wanneer ik mijn project start?
 
-There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+Er is geen goed moment om de governance van uw project op te schrijven, maar het is veel gemakkelijker te definiëren als u eenmaal de dynamiek van uw gemeenschap heeft gezien. Het beste (en moeilijkste) deel van open source governance is dat het wordt gevormd door de gemeenschap!
 
-Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+Sommige vroege documentatie zal echter onvermijdelijk bijdragen aan het beheer van uw project, dus begin met opschrijven wat u kunt. U kunt bijvoorbeeld duidelijke verwachtingen voor gedrag definiëren, of hoe uw bijdragersproces werkt, zelfs bij de lancering van uw project.
 
-If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
+Als u deel uitmaakt van een bedrijf dat een open source-project lanceert, is het de moeite waard om vóór de lancering een interne discussie te hebben over hoe uw bedrijf verwacht te handhaven en beslissingen te nemen over het toekomstige project. Misschien wilt u ook in het openbaar uitleggen hoe uw bedrijf wel of niet bij het project betrokken zal zijn (of niet!).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
-  We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+  We wijzen kleine teams toe om projecten op GitHub te beheren die hier daadwerkelijk aan werken op Facebook. React wordt bijvoorbeeld gerund door een React-engineer.
+  
+  _We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer._
   <p markdown="1" class="pquote-credit">
-— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+— @caabernathy, ["Een kijkje in open source bij Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
   </p>
 </aside>
 
 ## Wat gebeurt er als bedrijfsmedewerkers bijdragen beginnen in te dienen?
 
-Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+Succesvolle open source-projecten worden door veel mensen en bedrijven gebruikt, en sommige bedrijven kunnen uiteindelijk inkomstenstromen hebben die uiteindelijk aan het project zijn gekoppeld. Een bedrijf kan bijvoorbeeld de projectcode gebruiken als een onderdeel van een commerciële dienstverlening.
 
-As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+Naarmate het project op grotere schaal wordt gebruikt, wordt er meer vraag naar mensen die er expertise in hebben - misschien bent u een van hen! - en worden soms betaald voor het werk dat ze in het project doen.
 
-It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+Het is belangrijk om commerciële activiteiten als normaal te behandelen en als een nieuwe bron van ontwikkelingsenergie. Betaalde ontwikkelaars mogen natuurlijk geen speciale behandeling krijgen ten opzichte van onbetaalde ontwikkelaars; elke bijdrage moet op zijn technische merites worden beoordeeld. Mensen moeten zich echter op hun gemak voelen bij commerciële activiteiten en zich op hun gemak voelen bij het vermelden van hun gebruiksscenario's wanneer ze pleiten voor een bepaalde verbetering of functie.
 
-"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+"Commercial" is volledig compatibel met "open source". "Commercieel" betekent gewoon dat er ergens geld mee gemoeid is - dat de software wordt gebruikt in de handel, wat steeds waarschijnlijker wordt naarmate een project wordt geaccepteerd. (Wanneer open source-software wordt gebruikt als onderdeel van een niet-open-sourceproduct, is het algehele product nog steeds "eigen" software, hoewel het, net als open source, voor commerciële of niet-commerciële doeleinden kan worden gebruikt.)
 
-Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+Net als ieder ander krijgen commercieel gemotiveerde ontwikkelaars invloed in het project door de kwaliteit en kwantiteit van hun bijdragen. Het is duidelijk dat een ontwikkelaar die voor haar tijd wordt betaald, meer kan dan iemand die niet wordt betaald, maar dat is oké: betaling is slechts een van de vele mogelijke factoren die van invloed kunnen zijn op hoeveel iemand doet. Houd uw projectdiscussies gericht op de bijdragen, niet op de externe factoren waardoor mensen die bijdragen kunnen leveren.
 
 ## Heb ik een juridische entiteit nodig om mijn project te ondersteunen?
 
-You don't need a legal entity to support your open source project unless you're handling money.
+U hebt geen juridische entiteit nodig om uw open source-project te ondersteunen, tenzij u met geld omgaat.
 
-For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+Als u bijvoorbeeld een commercieel bedrijf wilt opzetten, wilt u een C Corp of LLC opzetten (als u in de VS bent gevestigd). Als u alleen contractwerk doet in verband met uw open source-project, kunt u geld accepteren als een eenmanszaak of een LLC opzetten (als u in de VS bent gevestigd).
 
-If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+Als u donaties voor uw open source-project wilt accepteren, kunt u een donatieknop instellen (bijvoorbeeld met PayPal of Stripe), maar het geld is niet aftrekbaar voor de belasting, tenzij u een in aanmerking komende non-profitorganisatie bent (een 501c3, als je bent in de VS).
 
-Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+Veel projecten willen niet de moeite nemen om een ​​non-profitorganisatie op te zetten, dus zoeken ze in plaats daarvan een fiscale sponsor zonder winstoogmerk. Een fiscale sponsor accepteert namens u schenkingen, meestal in ruil voor een percentage van de schenking. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) en [Open Collective](https://opencollective.com/opensource) zijn voorbeelden van organisaties die als fiscale sponsors dienen voor open source-projecten.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
-  Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+    Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+
+  _Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it._
+  
   <p markdown="1" class="pquote-credit">
-— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+— @piamancini, ["Verder gaan dan het liefdadigheidskader"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
   </p>
 </aside>
 
-If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
+Als uw project nauw verbonden is met een bepaalde taal of een bepaald ecosysteem, kan er ook een gerelateerde softwarefundament zijn waarmee u kunt werken. De [Python Software Foundation](https://www.python.org/psf/) helpt bijvoorbeeld bij het ondersteunen van [PyPI](https://pypi.org/), de Python-pakketbeheerder en de [Node.js Foundation](https://foundation.nodejs.org/) helpt bij het ondersteunen van [Express.js](https://expressjs.com/), een op knooppunten gebaseerd raamwerk.

From 20de1188ee6dea4401b444ede11cf2eed97c8301 Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Thu, 27 Aug 2020 17:05:38 +0200
Subject: [PATCH 072/749] Article 'Legal'

---
 _articles/nl/legal.md | 135 +++++++++++++++++++++++-------------------
 1 file changed, 73 insertions(+), 62 deletions(-)

diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
index 8e4c84d961d..68c73cf9194 100644
--- a/_articles/nl/legal.md
+++ b/_articles/nl/legal.md
@@ -20,147 +20,158 @@ related:
 
 ## Understanding the legal implications of open source
 
-Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+Het delen van uw creatieve werk met de wereld kan een opwindende en lonende ervaring zijn. Het kan ook een heleboel juridische dingen betekenen waarvan je niet wist dat u zich er zorgen over moest maken. Gelukkig hoef je niet helemaal opnieuw te beginnen. We hebben uw juridische behoeften gedekt. (Lees voordat u verder gaat onze [disclaimer](/notices/).)
 
 ## Waarom geven mensen zoveel om de juridische kant van open source?
 
-Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+Blij dat je het vraagt! Wanneer u een creatief werk maakt (zoals schrijven, afbeeldingen of code), valt dat werk standaard onder exclusief auteursrecht. Dat wil zeggen, de wet gaat ervan uit dat u als auteur van uw werk inspraak hebt in wat anderen ermee kunnen doen.
 
-In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+Over het algemeen betekent dit dat niemand anders uw werk kan gebruiken, kopiëren, distribueren of wijzigen zonder het risico te lopen op uitval, opschudding of rechtszaak.
 
-Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+Open source is echter een ongebruikelijke omstandigheid, omdat de auteur verwacht dat anderen het werk zullen gebruiken, aanpassen en delen. Maar omdat de wettelijke standaard nog steeds exclusief copyright is, hebt u een licentie nodig waarin deze machtigingen expliciet worden vermeld.
 
-If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+Als u geen open source-licentie toepast, wordt iedereen die aan uw project bijdraagt ​​ook de exclusieve copyrighthouder van zijn werk. Dat betekent dat niemand zijn bijdragen kan gebruiken, kopiëren, verspreiden of wijzigen - en dat "niemand" jou ook omvat.
 
-Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
+Ten slotte kan uw project afhankelijkheden hebben met licentievereisten waarvan u zich niet bewust was. De gemeenschap van uw project of het beleid van uw werkgever kan ook vereisen dat uw project specifieke open source-licenties gebruikt. We behandelen deze situaties hieronder.
 
 ## Zijn openbare GitHub-projecten 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**.
+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**.
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+**Het openbaar maken van uw GitHub-project is niet hetzelfde als het licentiëren van uw project.** Openbare projecten vallen onder de [Servicevoorwaarden van GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), waarmee anderen uw project kunnen bekijken en splitsen (_een fork_), maar uw werk heeft verder geen rechten.
 
-If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+Als u wilt dat anderen uw project gebruiken, distribueren, wijzigen of eraan bijdragen, moet u een open source-licentie opnemen. Iemand kan bijvoorbeeld geen enkel deel van je GitHub-project legaal in zijn code gebruiken, zelfs niet als het openbaar is, tenzij je hem expliciet het recht geeft om dit te doen.
 
 ## Geef me gewoon de TL;DR over wat ik nodig heb om mijn project te beschermen
 
-You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+Je hebt geluk, want tegenwoordig zijn open source-licenties gestandaardiseerd en gebruiksvriendelijk. U kunt een bestaande licentie rechtstreeks in uw project kopiëren en plakken.
 
-[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 the most popular open source 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/).
+[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/).
 
-When you create a new project on GitHub, you'll be [asked to add a license](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://help.github.com/articles/open-source-licensing/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
-  A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+    Een gestandaardiseerde licentie dient als een proxy voor degenen zonder juridische opleiding om precies te weten wat ze wel en niet kunnen doen met de software. Vermijd, tenzij absoluut vereist, aangepaste, gewijzigde of niet-standaard voorwaarden, die een belemmering zullen vormen voor het downstream-gebruik van de agentschapscode.
+
+  _A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code._
+
   <p markdown="1" class="pquote-credit">
-— @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+— @benbalter, ["Alles wat een overheidsadvocaat moet weten over open source softwarelicenties"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
   </p>
 </aside>
 
 ## Welke open source-licentie is geschikt voor mijn project?
 
-If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+Als je begint met een blanco project, is het moeilijk om fout te gaan met de [MIT License](https://choosealicense.com/licenses/mit/). Het is kort, heel gemakkelijk te begrijpen en staat iedereen toe om alles te doen, zolang ze een kopie van de licentie bewaren, inclusief uw copyrightmelding. U kunt het project onder een andere licentie vrijgeven als dat ooit nodig is.
 
-Otherwise, picking the right open source license for your project depends on your objectives.
+Anders hangt het kiezen van de juiste open source-licentie voor uw project af van uw doelstellingen.
 
-Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+Uw project heeft (of zal) zeer waarschijnlijk **afhankelijkheden**. Als u bijvoorbeeld een Node.js-project open source maakt, gebruikt u waarschijnlijk bibliotheken van de Node Package Manager (npm). Elk van die bibliotheken waarvan u afhankelijk bent, heeft zijn eigen open source-licentie. Als elk van hun licenties "permissief" is (geeft het publiek toestemming om te gebruiken, wijzigen en delen, zonder enige voorwaarde voor downstreamlicenties), kunt u elke gewenste licentie gebruiken. Veelgebruikte licenties zijn onder meer MIT, Apache 2.0, ISC en BSD.
 
-On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+Aan de andere kant, als een van de licenties van je afhankelijkheden "sterk copyleft" is (geeft ook publiek dezelfde permissies, op voorwaarde dat je dezelfde licentie downstream gebruikt), dan zal je project dezelfde licentie moeten gebruiken. Veelgebruikte licenties voor sterke auteursplicht zijn GPLv2, GPLv3 en AGPLv3.
 
-You may also want to consider the **communities** you hope will use and contribute to your project:
+U kunt ook de **gemeenschappen** overwegen waarvan u hoopt dat ze zullen gebruiken en bijdragen aan uw project:
 
-* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
-* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
-* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+* **Wilt u dat uw project wordt gebruikt als afhankelijkheid door andere projecten?** Waarschijnlijk het beste om de meest populaire licentie in uw relevante gemeenschap te gebruiken. [MIT](https://choosealicense.com/licenses/mit/) is bijvoorbeeld de meest populaire licentie voor [npm libraries](https://libraries.io/search?platforms=NPM).
+* **Wilt u dat uw project grote bedrijven aanspreekt?** Een groot bedrijf wil waarschijnlijk een uitdrukkelijke patentlicentie van alle bijdragers. In dit geval heeft [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) jou (en hen) gedekt.
+* **Wilt u dat uw project een beroep doet op bijdragers die niet willen dat hun bijdragen worden gebruikt in closed source-software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) of (indien ze willen ook niet bijdragen aan closed source-diensten) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) zal goed overkomen.
 
-Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#wat-moet-het-juridische-team-van-mijn-bedrijf-weten).
+Uw **bedrijf** heeft mogelijk specifieke licentievereisten voor zijn open source-projecten. Het kan bijvoorbeeld een vergunning vereisen, zodat het bedrijf uw project kan gebruiken in het closed source-product van het bedrijf. Of uw bedrijf heeft mogelijk een sterke auteursplichtlicentie en een aanvullende bijdragersovereenkomst nodig (zie hieronder) zodat alleen uw bedrijf, en niemand anders, uw project kan gebruiken in closed source-software. Of uw bedrijf kan bepaalde behoeften hebben met betrekking tot normen, sociale verantwoordelijkheid of transparantie, die elk een bepaalde licentiestrategie vereisen. Neem contact op met de juridische afdeling van uw [bedrijf](#wat-moet-het-juridische-team-van-mijn-bedrijf-weten).
 
-When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+Wanneer u een nieuw project op GitHub maakt, krijgt u de mogelijkheid om een ​​licentie te selecteren. Als u een van de bovengenoemde licenties opneemt, wordt uw GitHub-project open source. Als je andere opties wilt zien, ga dan naar [choosealicense.com](https://choosealicense.com) om de juiste licentie voor je project te vinden, zelfs als het [geen software is](https://choosealicense.com/non-software/).
 
 ## Wat moet ik doen als ik de licentie van mijn project wil wijzigen?
 
-Most projects never need to change licenses. But occasionally circumstances change.
+De meeste projecten hoeven nooit van licentie te wisselen. Maar af en toe veranderen de omstandigheden.
 
-For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+Naarmate uw project groeit, voegt het bijvoorbeeld afhankelijkheden of gebruikers toe, of verandert uw bedrijf van strategie, die voor elk een andere licentie kunnen vereisen of willen. Als u vanaf het begin geen licentie voor uw project hebt verleend, is het toevoegen van een licentie in feite hetzelfde als het wijzigen van licenties. Er zijn drie fundamentele zaken waarmee u rekening moet houden bij het toevoegen of wijzigen van de licentie van uw project:
 
-**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+**Het is ingewikkeld.** Het bepalen van de compatibiliteit en naleving van licenties en wie het auteursrecht bezit, kan zeer snel ingewikkeld en verwarrend worden. Overschakelen naar een nieuwe maar compatibele licentie voor nieuwe releases en bijdragen is iets anders dan alle bestaande bijdragen opnieuw licentiëren. Betrek uw juridische team bij de eerste aanwijzing dat u licenties wilt wijzigen. Zelfs als u toestemming hebt of kunt krijgen van de auteursrechthouders van uw project voor een licentiewijziging, moet u rekening houden met de impact van de wijziging op de andere gebruikers en bijdragers van uw project. Beschouw een licentiewijziging als een "bestuursgebeurtenis" voor uw project dat waarschijnlijk vlotter zal verlopen met duidelijke communicatie en overleg met de belanghebbenden van uw project. Reden te meer om vanaf het begin een geschikte licentie voor uw project te kiezen en te gebruiken!
 
-**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+**De bestaande licentie van uw project.** Als de bestaande licentie van uw project compatibel is met de licentie waarnaar u wilt overschakelen, kunt u de nieuwe licentie gewoon gaan gebruiken. Dat komt omdat als licentie A compatibel is met licentie B, u voldoet aan de voorwaarden van A terwijl u voldoet aan de voorwaarden van B (maar niet noodzakelijkerwijs andersom). Dus als u momenteel een toegestane licentie gebruikt (bijv. MIT), kunt u overschakelen naar een licentie met meer voorwaarden, zolang u een kopie van de MIT-licentie en eventuele bijbehorende copyrightkennisgevingen bewaart (dat wil zeggen, blijf voldoen aan de Minimale voorwaarden van de MIT-licentie). Maar als je huidige licentie niet toelaatbaar is (bijv. Copyleft, of je hebt geen licentie) en je bent niet de enige copyrighthouder, dan zou je niet zomaar de licentie van je project kunnen veranderen in MIT. In wezen hebben de auteursrechthouders van het project met een toegestane licentie van tevoren toestemming gegeven om licenties te wijzigen.
 
-**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+**De bestaande auteursrechthouders van uw project.** Als u de enige bijdrager aan uw project bent, bent u of uw bedrijf de enige houder van het auteursrecht van het project. U kunt elke licentie die u of uw bedrijf wenst, toevoegen of wijzigen. Anders zijn er mogelijk andere auteursrechthouders met wie u toestemming nodig heeft om licenties te wijzigen. Wie zijn zij? Mensen die commits hebben in uw project, zijn een goede plek om te beginnen. Maar in sommige gevallen berust het auteursrecht bij de werkgevers van die mensen. In sommige gevallen hebben mensen slechts minimale bijdragen geleverd, maar er is geen vaste regel dat bijdragen onder een aantal coderegels niet onderhevig zijn aan auteursrechten. Wat te doen? Het hangt er van af. Voor een relatief klein en jong project kan het haalbaar zijn om alle bestaande bijdragers zover te krijgen dat ze instemmen met een licentiewijziging in een issue of pull-aanvraag. Voor grote en langlopende projecten moet u mogelijk veel bijdragers en zelfs hun erfgenamen zoeken. Mozilla heeft jaren (2001-2006) nodig gehad om Firefox, Thunderbird en gerelateerde software opnieuw te licentiëren.
 
-Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+Als alternatief kunt u bijdragers van tevoren laten instemmen (via een aanvullende overeenkomst voor bijdragers - zie hieronder) met bepaalde licentiewijzigingen onder bepaalde voorwaarden, naast die welke zijn toegestaan ​​door uw bestaande open source-licentie. Dit verschuift de complexiteit van het wijzigen van licenties een beetje. U heeft vooraf meer hulp van uw advocaten nodig en u wilt toch duidelijk communiceren met de belanghebbenden van uw project wanneer u een licentiewijziging doorvoert.
 
 ## Heeft mijn project een aanvullende contribuantenovereenkomst nodig?
 
-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).
+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).
 
-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.
+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.
 
-Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
+Door ook 'papierwerk' toe te voegen waarvan sommigen denken dat het onnodig, moeilijk te begrijpen of oneerlijk is (wanneer de ontvanger van de overeenkomst meer rechten krijgt dan bijdragers of het publiek via de open source-licentie van het project), kan een aanvullende overeenkomst voor bijdragers als onvriendelijk worden ervaren aan de gemeenschap van het project.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
-    We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+    We hebben de CLA voor Node.js. Door dit te doen, wordt de toegangsdrempel voor Node.js-bijdragers verlaagd, waardoor het aantal bijdragers wordt verbreed.
+    
+    _We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base._
+
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Node.js-bijdragen verbreden"](https://www.joyent.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
+Enkele situaties waarin u wellicht een aanvullende bijdrageovereenkomst voor uw project wilt overwegen, zijn onder meer:
 
-Some situations where you may want to consider an additional contributor agreement for your project include:
+* Uw advocaten willen dat alle bijdragers uitdrukkelijk (_tekenen_, online of offline) contributievoorwaarden accepteren, misschien omdat ze vinden dat de open source-licentie zelf niet voldoende is (ook al is het dat wel!). Als dit de enige zorg is, zou een bijdragersovereenkomst moeten volstaan ​​die de open source-licentie van het project bevestigt. De [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is een goed voorbeeld van een lichtgewicht aanvullende overeenkomst voor bijdragers.
+* U of uw advocaten willen dat ontwikkelaars verklaren dat elke toezegging die ze doen, geautoriseerd is. Een [Developer Certificate of Origin](https://developercertificate.org/) vereiste is hoeveel projecten dit bereiken. De Node.js-community [gebruikt](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) bijvoorbeeld de DCO [in plaats daarvan](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) van hun eerdere cao. Een eenvoudige optie om de handhaving van de DCO op uw repository te automatiseren, is de [DCO Probot] (https://github.com/probot/dco).
+* Uw project maakt gebruik van een open source-licentie die geen uitdrukkelijke octrooiverlening omvat (zoals MIT), en u hebt een octrooiverlening nodig van alle bijdragers, van wie sommigen mogelijk werken voor bedrijven met grote octrooiportefeuilles die kunnen worden gebruikt om u te targeten of de andere bijdragers en gebruikers van het project. De [Apache-licentieovereenkomst voor individuele bijdragers](https://www.apache.org/licenses/icla.pdf) is een veelgebruikte aanvullende overeenkomst voor bijdragers met een octrooiverlening die overeenkomt met die in de Apache-licentie 2.0.
+* Uw project valt onder een auteursplichtlicentie, maar u moet ook een eigen versie van het project distribueren. Je hebt elke bijdrager nodig om het auteursrecht aan jou toe te wijzen of jou (maar niet het publiek) een permissieve licentie te verlenen. De [MongoDB-bijdragersovereenkomst](https://www.mongodb.com/legal/contributor-agreement) is een voorbeeld van dit type overeenkomst.
+* U denkt dat uw project mogelijk licenties moet wijzigen gedurende de levensduur en u wilt dat bijdragers van tevoren akkoord gaan met dergelijke wijzigingen.
 
-* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
-* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
-* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
-* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
-* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
-
-If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+Als je toch een aanvullende bijdragersovereenkomst nodig hebt voor je project, overweeg dan om een ​​integratie zoals [CLA-assistent](https://github.com/cla-assistant/cla-assistant) te gebruiken om afleiding van bijdragers te minimaliseren.
 
 ## Wat moet het juridische team van mijn bedrijf weten?
 
-If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+Als u als bedrijfsmedewerker een open source-project vrijgeeft, moet uw juridische team eerst weten dat u een project open source maakt.
 
-For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+Overweeg om ze te laten weten, of het nu een persoonlijk project is, of het nu beter of slechter is. U hebt waarschijnlijk een "IP-overeenkomst voor werknemers" met uw bedrijf die hen enige controle geeft over uw projecten, vooral als ze überhaupt verband houden met de zaken van het bedrijf of als u bedrijfsmiddelen gebruikt om het project te ontwikkelen. Uw bedrijf _moet_ u gemakkelijk toestemming geven, en heeft dat misschien al gedaan via een werknemersvriendelijke IE-overeenkomst of een bedrijfsbeleid. Zo niet, dan kunt u onderhandelen (leg bijvoorbeeld uit dat uw project de professionele leer- en ontwikkelingsdoelstellingen van het bedrijf voor u dient), of werk niet aan uw project totdat u een beter bedrijf heeft gevonden.
 
-**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+**Als u een open source project voor uw bedrijf zoekt,** laat het hen dan zeker weten. Uw juridische team heeft waarschijnlijk al beleid voor welke open source-licentie (en misschien een aanvullende bijdragersovereenkomst) moet worden gebruikt op basis van de zakelijke vereisten en expertise van het bedrijf om ervoor te zorgen dat uw project voldoet aan de licenties van zijn afhankelijkheden. Zo niet, dan hebben jij en zij geluk! Uw juridische team zou graag met u willen samenwerken om dit uit te zoeken. Enkele dingen om over na te denken:
 
-* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+* **Materiaal van derden:** Heeft uw project afhankelijkheden die door anderen zijn gecreëerd of bevat of gebruikt u anderszins code van anderen? Als deze open source zijn, moet u voldoen aan de open source-licenties van het materiaal. Dat begint met het kiezen van een licentie die werkt met de open source-licenties van derden (zie hierboven). Als uw project open source-materiaal van derden wijzigt of verspreidt, zal uw juridische team ook willen weten dat u voldoet aan andere voorwaarden van de open source-licenties van derden, zoals het behouden van copyrightkennisgevingen. Als uw project code van anderen gebruikt die geen open source-licentie heeft, moet u waarschijnlijk de externe beheerders vragen om [een open source-licentie toe te voegen](https://choosealicense.com/no-license/#for-users), en als u er geen kunt krijgen, stop dan met het gebruik van hun code in uw project.
 
-* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+* **Handelsgeheimen:** Bedenk of er iets in het project staat dat het bedrijf niet beschikbaar wil stellen aan het grote publiek. Als dat het geval is, kunt u de rest van uw project open source maken, nadat u het materiaal hebt geëxtraheerd dat u privé wilt houden.
 
-* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
+* **Octrooien:** Vraagt ​​uw bedrijf een octrooi aan waarvan open sourcing uw project [openbaar](https://en.wikipedia.org/wiki/Public_disclosure) zou maken? Helaas wordt u mogelijk gevraagd om te wachten (of misschien heroverweegt het bedrijf de wijsheid van de toepassing). Als u bijdragen aan uw project verwacht van werknemers van bedrijven met grote octrooiportefeuilles, kan uw juridische team willen dat u een licentie gebruikt met een uitdrukkelijke octrooiverlening van bijdragers (zoals Apache 2.0 of GPLv3), of een aanvullende bijdragersovereenkomst (zie hierboven).
 
-* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#naamconflicten-vermijden). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+* **Handelsmerken:** Controleer nogmaals of de naam van uw project [niet in strijd is met bestaande handelsmerken](../starting-a-project/#naamconflicten-vermijden). Als u in het project uw eigen bedrijfsmerken gebruikt, controleer dan of dit geen conflicten veroorzaakt. [FOSSmarks](http://fossmarks.org/) is een praktische gids om handelsmerken te begrijpen in de context van gratis en open source projecten.
 
-* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+* **Privacy:** Verzamelt uw project gegevens over gebruikers? 'Naar huis bellen' naar bedrijfsservers? Uw juridische team kan u helpen bij het naleven van het bedrijfsbeleid en externe regelgeving.
 
-If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+Als u het eerste open source-project van uw bedrijf uitbrengt, is het bovenstaande meer dan voldoende om erdoorheen te komen (maar maakt u zich geen zorgen, de meeste projecten zouden geen grote zorgen moeten baren).
 
-Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+Op de langere termijn kan uw juridische team meer doen om het bedrijf te helpen meer uit zijn betrokkenheid bij open source te halen en veilig te blijven:
 
-* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Beleid inzake werknemersbijdragen:** Overweeg om een ​​bedrijfsbeleid te ontwikkelen dat aangeeft hoe uw werknemers bijdragen aan open source-projecten. Een duidelijk beleid zal de verwarring onder uw medewerkers verminderen en hen helpen bij te dragen aan open source-projecten in het belang van het bedrijf, zowel als onderdeel van hun baan als in hun vrije tijd. Een goed voorbeeld is Rackspace's [Model IP and Open Source Contribution Policy] (https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
-  Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+  Door de interlectuele eigenschap die aan een patch is gekoppeld, te verhuren, wordt de kennisbasis en de reputatie van de werknemer opgebouwd. Het laat zien dat het bedrijf investeert in de ontwikkeling van die medewerker en creëert een gevoel van empowerment en autonomie. Al deze voordelen leiden ook tot een hoger moreel en een beter behoud van werknemers.
+  
+  _Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention._
+
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["Een modelbeleid inzake intellectuele eigendom en bijdragen aan open source"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
-* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
-* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+* **Wat vrij te geven:** [(Bijna) alles?] (Http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Als uw juridische team het begrijpt en geïnvesteerd in de open source-strategie van uw bedrijf, zullen ze u het beste kunnen helpen in plaats van hinderen.
+* **Naleving:** Zelfs als uw bedrijf geen open source-projecten vrijgeeft, gebruikt het open source-software van anderen. [Bewustwording en proces](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) kan hoofdpijn, productvertragingen, en rechtszaken voorkomen.
 
 <aside markdown="1" class="pquote">
-  Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+  Organisaties moeten een licentie- en nalevingsstrategie hebben die past in de categorieën \["tolerant" en "copyleft"\]. Dit begint met het bijhouden van de licentievoorwaarden die van toepassing zijn op de open source-software die u gebruikt, inclusief subcomponenten en afhankelijkheden.
+  
+  _Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies._
+  
   <p markdown="1" class="pquote-credit">
-— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+— Heather Meeker, ["Open source-software: basisprincipes van compliance en best practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
   </p>
 </aside>
 
-* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
-* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#heb-ik-een-juridische-entiteit-nodig-om-mijn-project-te-ondersteunen).
+* **Patenten:** Uw bedrijf wil wellicht lid worden van het [Open Invention Network](https://www.openinventionnetwork.com/), een gedeelde defensieve patentpool om het gebruik van grote open source-projecten door leden te beschermen, of andere [alternatieve patentlicenties](https://www.eff.org/document/hacking-patent-system-2016).
+* **Governance:** Zeker als en wanneer het zinvol is om een project te verhuizen naar een [juridische entiteit buiten het bedrijf](../leadership-and-governance/#heb-ik-een-juridische-entiteit-nodig-om-mijn-project-te-ondersteunen).

From e37c96b67165fdcaf4a3d1a733ddec2989a4d2ca Mon Sep 17 00:00:00 2001
From: Wesley de Groot <wes@vista.aero>
Date: Thu, 27 Aug 2020 17:46:01 +0200
Subject: [PATCH 073/749] Article 'How to Contribute'

---
 _articles/nl/how-to-contribute.md | 432 ++++++++++++++++--------------
 1 file changed, 226 insertions(+), 206 deletions(-)

diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md
index 0d67031233f..dc7ee302cab 100644
--- a/_articles/nl/how-to-contribute.md
+++ b/_articles/nl/how-to-contribute.md
@@ -21,206 +21,217 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
-  Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+  Door aan \[freenode\] te werken, heb ik veel van de vaardigheden verworven die ik later gebruikte voor mijn studie aan de universiteit en mijn huidige baan. Ik denk dat werken aan open source-projecten mij net zo goed helpt als het project!
+  
+  _Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!_
   <p markdown="1" class="pquote-credit">
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Waarom ik graag bijdraag aan open source software"](https://www.errietta.me/blog/open-source/)
   </p>
 </aside>
 
-Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+Bijdragen aan open source kan een lonende manier zijn om te leren, les te geven en ervaring op te doen met vrijwel elke vaardigheid die je maar kunt bedenken.
 
-Why do people contribute to open source? Plenty of reasons!
+Waarom dragen mensen bij aan open source? Redenen genoeg!
 
-### Improve software you rely on
+### Verbeter de software waarop u vertrouwt
 
-Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+Veel open source-bijdragers beginnen door gebruikers te zijn van software waaraan ze bijdragen. Als je een bug vindt in open source-software die je gebruikt, wil je misschien naar de bron kijken om te zien of je deze zelf kunt patchen. Als dat het geval is, is het bijdragen van de patch de beste manier om ervoor te zorgen dat uw vrienden (en uzelf wanneer u een update naar de volgende release uitvoert) hiervan kunnen profiteren.
 
-### Improve existing skills
+### Verbeter bestaande vaardigheden
 
-Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+Of het nu gaat om codering, ontwerp van gebruikersinterface, grafisch ontwerp, schrijven of organiseren, als u op zoek bent naar oefening, is er een taak voor u in een open source-project.
 
-### Meet people who are interested in similar things
+### Ontmoet mensen die geïnteresseerd zijn in soortgelijke dingen
 
-Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+Open source-projecten met warme, gastvrije gemeenschappen zorgen ervoor dat mensen jarenlang terug blijven komen. Veel mensen vormen vriendschappen voor het leven door deel te nemen aan open source, of ze nu elkaar tegenkomen op conferenties of 's avonds laat online chats over burrito's.
 
-### Find mentors and teach others
+### Vind mentoren en leer anderen
 
-Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+Als je met anderen aan een gedeeld project werkt, moet je uitleggen hoe je de dingen doet, en ook andere mensen om hulp vragen. Het leren en onderwijzen kan voor alle betrokkenen een bevredigende activiteit zijn.
 
-### Build public artifacts that help you grow a reputation (and a career)
+### Bouw openbare artefacten waarmee u een reputatie (en een carrière) kunt opbouwen
 
-By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+Al uw open source-werk is per definitie openbaar, wat betekent dat u gratis voorbeelden krijgt die u overal mee naartoe kunt nemen als demonstratie van wat u kunt doen.
 
-### Learn people skills
+### Leer de vaardigheden van mensen
 
-Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+Open source biedt mogelijkheden om leiderschaps- en managementvaardigheden te oefenen, zoals het oplossen van conflicten, het organiseren van teams van mensen en het prioriteren van werk.
 
-### It's empowering to be able to make changes, even small ones
+### Het geeft kracht om veranderingen aan te brengen, zelfs kleine
 
-You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+U hoeft geen levenslange donateur te worden om te genieten van deelname aan open source. Heb je ooit een typefout op een website gezien en zou je willen dat iemand het zou repareren? Bij een open source-project kunt u precies dat doen. Open source helpt mensen keuzevrijheid te voelen over hun leven en hoe zij de wereld ervaren, en dat is op zichzelf al verheugend.
 
 ## Wat het betekent om bij te dragen
 
-If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+Als u een nieuwe open source-bijdrager bent, kan het proces intimiderend zijn. Hoe vind je het juiste project? Wat als u niet weet hoe u moet coderen? Wat als er iets mis gaat?
 
-Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+Geen zorgen! Er zijn allerlei manieren om betrokken te raken bij een open source-project, en een paar tips zullen u helpen het meeste uit uw ervaring te halen.
 
-### You don't have to contribute code
+### U hoeft geen code bij te dragen
 
-A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+Een veel voorkomende misvatting over bijdragen aan open source is dat je code moet bijdragen. In feite zijn het vaak de andere delen van een project die [het meest worden verwaarloosd of over het hoofd gezien](https://github.com/blog/2195-the-shape-of-open-source). Je doet het project een _grote_ gunst door aan te bieden mee te werken met dit soort bijdragen!
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
-  I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+  Ik sta bekend om mijn werk aan CocoaPods, maar de meeste mensen weten niet dat ik eigenlijk geen echt werk aan de CocoaPods-tool zelf doe. Mijn tijd aan het project besteed ik voornamelijk aan zaken als documentatie en branding.
+  
+  _I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding._
+  
   <p markdown="1" class="pquote-credit">
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Standaard naar OSS gaan"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
   </p>
 </aside>
 
-Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+Zelfs als je graag code schrijft, zijn andere soorten bijdragen een geweldige manier om bij een project betrokken te raken en andere leden van de gemeenschap te ontmoeten. Door die relaties op te bouwen, krijg je de kans om aan andere delen van het project te werken.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing.
+  Ik nam voor het eerst contact op met het Python-ontwikkelingsteam (ook bekend als python-dev) toen ik de mailinglijst op 17 juni 2002 e-mailde over het accepteren van mijn patch. Ik ontdekte snel de open source-bug en besloot om e-mailsamenvattingen voor de groep te gaan beheren. Ze gaven me een geweldig excuus om opheldering over een onderwerp te vragen, maar kritischer merkte ik dat iemand op iets wees dat moest worden opgelost.
+  
+  _I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing._
+  
   <p markdown="1" class="pquote-credit">
 — @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
   </p>
 </aside>
 
-### Do you like planning events?
+### Houd je van het plannen van evenementen?
 
-* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
-* Organize the project's conference (if they have one)
-* Help community members find the right conferences and submit proposals for speaking
+* Organiseer workshops of meetups over het project, [zoals @fzamperin deed voor NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Organiseer de conferentie van het project (als ze er een hebben)
+* Help leden van de gemeenschap de juiste conferenties te vinden en presenteer voorstellen om te spreken
 
-### Do you like to design?
+### Houd je van ontwerpen?
 
-* Restructure layouts to improve the project's usability
-* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
-* Put together a style guide to help the project have a consistent visual design
-* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+* Herstructureer lay-outs om de bruikbaarheid van het project te verbeteren
+* Voer gebruikersonderzoek uit om de navigatie of menu's van het project te reorganiseren en te verfijnen [zoals Drupal suggereert](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Stel een stijlgids samen om het project te helpen een consistent visueel ontwerp te hebben
+* Maak kunst voor t-shirts of een nieuw logo, [zoals de bijdragers van hapi.js deden](https://github.com/hapijs/contrib/issues/68)
 
-### Do you like to write?
+### Vind je het leuk om te schrijven?
 
-* Write and improve the project's documentation
-* Curate a folder of examples showing how the project is used
-* Start a newsletter for the project, or curate highlights from the mailing list
-* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
-* Write a translation for the project's documentation
+* Schrijf en verbeter de projectdocumentatie
+* Beheer een map met voorbeelden die laten zien hoe het project wordt gebruikt
+* Start een nieuwsbrief voor het project of cureer hoogtepunten uit de mailinglijst
+* Schrijf tutorials voor het project, [zoals de bijdragers van PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Schrijf een vertaling voor de documentatie van het project
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
-  Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+  Serieus, \[documentatie\] is enorm belangrijk. De documentatie tot nu toe was geweldig en was een geweldige eigenschap van Babel. Er zijn secties die zeker wat werk kunnen gebruiken en zelfs de toevoeging van een alinea hier of daar wordt enorm gewaardeerd.
+  
+  _Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated._
+  
   <p markdown="1" class="pquote-credit">
-— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+— @kittens, ["Roep bijdragers op"](https://github.com/babel/babel/issues/1347)
   </p>
 </aside>
 
-### Do you like organizing?
+### Houd je van organiseren?
 
-* Link to duplicate issues, and suggest new issue labels, to keep things organized
-* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
-* Ask clarifying questions on recently opened issues to move the discussion forward
+* Link naar dubbele problemen en stel nieuwe labels voor om alles georganiseerd te houden
+* Doorloop openstaande issues en stel voor om oude te sluiten, [zoals @nzakas deed voor ESLint](https://github.com/eslint/eslint/issues/6765)
+* Stel verhelderende vragen over recent geopende kwesties om de discussie vooruit te helpen
 
-### Do you like to code?
+### Vind je het leuk om te coderen?
 
-* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
-* Ask if you can help write a new feature
-* Automate project setup
-* Improve tooling and testing
+* Zoek een openstaand probleem om aan te pakken, [zoals @dianjin deed voor Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Vraag of u kunt helpen bij het schrijven van een nieuwe functie
+* Automatiseer het opzetten van projecten
+* Verbeter tooling en testen
 
-### Do you like helping people?
+### Vind je het leuk om mensen te helpen?
 
-* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
-* Answer questions for people on open issues
-* Help moderate the discussion boards or conversation channels
+* Beantwoord vragen over het project op bijvoorbeeld Stack Overflow ([zoals dit Postgres-voorbeeld] (https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) of Reddit
+* Beantwoord vragen voor mensen over openstaande kwesties
+* Help de discussieborden of gesprekskanalen te modereren
 
-### Do you like helping others code?
+### Vind je het leuk om anderen te helpen bij het coderen?
 
-* Review code on other people's submissions
-* Write tutorials for how a project can be used
-* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+* Beoordeel code inzendingen van andere mensen
+* Schrijf tutorials over hoe een project kan worden gebruikt
+* Aanbieding om een andere bijdrager te begeleiden, [zoals @ereichert deed voor @bronzdoc op Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
 
-### You don't just have to work on software projects!
+### U hoeft niet alleen aan softwareprojecten te werken!
 
-While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+Hoewel "open source" vaak verwijst naar software, kunt u aan vrijwel alles samenwerken. Er zijn boeken, recepten, lijsten en klassen die worden ontwikkeld als open source-projecten.
 
-For example:
+Bijvoorbeeld:
 
-* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
-* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
-* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+* @sindresorhus beheert een [lijst met "geweldige" lijsten](https://github.com/sindresorhus/awesome)
+* @h5bp houdt een [lijst met potentiële interviewvragen](https://github.com/h5bp/Front-end-Developer-Interview-Questions) bij voor front-end ontwikkelaarskandidaten
+* @stuartlynn en @nicole-a-tesla hebben een [verzameling leuke weetjes over papegaaiduikers](https://github.com/stuartlynn/puffin_facts) gemaakt
 
-Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
+Zelfs als u een softwareontwikkelaar bent, kan het werken aan een documentatieproject u helpen aan de slag te gaan in open source. Het is vaak minder intimiderend om aan projecten te werken waarbij geen code wordt gebruikt, en het samenwerkingsproces zal uw vertrouwen en ervaring vergroten.
 
 ## Je oriënteren op een nieuw project
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
-  If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+  Als je naar een issue-tracker gaat en de dingen verwarrend lijken, ben jij het niet alleen. Deze tools vereisen veel impliciete kennis, maar mensen kunnen je helpen er doorheen te navigeren en je kunt ze vragen stellen.
   <p markdown="1" class="pquote-credit">
-— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+— @shaunagm, ["Hoe u kunt bijdragen aan Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
   </p>
 </aside>
 
-For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+Voor meer dan een typefout is bijdragen aan open source net zoiets als naar een groep vreemden lopen op een feestje. Als je over lama's begint te praten, terwijl ze diep in een discussie over goudvissen zaten, zullen ze je waarschijnlijk een beetje vreemd aankijken.
 
-Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
+Voordat u blindelings met uw eigen suggesties begint, moet u eerst leren hoe u de kamer moet lezen. Hierdoor vergroot u de kans dat uw ideeën worden opgemerkt en gehoord.
 
-### Anatomy of an open source project
+### Anatomie van een open source-project
 
-Every open source community is different.
+Elke open source-community is anders.
 
-Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+Jarenlang aan één open source-project besteden, betekent dat je één open source-project hebt leren kennen. Ga naar een ander project en je zult misschien ontdekken dat de woordenschat, normen en communicatiestijlen totaal verschillend zijn.
 
-That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+Dat gezegd hebbende, veel open source-projecten volgen een vergelijkbare organisatiestructuur. Als u de verschillende rollen van de gemeenschap en het algehele proces begrijpt, kunt u zich snel op elk nieuw project oriënteren.
 
-A typical open source project has the following types of people:
+Een typisch open source-project heeft de volgende soorten mensen:
 
-* **Author:** The person/s or organization that created the project
-* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
-* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
-* **Contributors:** Everyone who has contributed something back to the project
-* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+* **Auteur:** De persoon/personen of organisatie die het project heeft gemaakt
+* **Eigenaar:** De persoon/personen die het administratieve eigendom hebben over de organisatie of opslagplaats (niet altijd dezelfde als de oorspronkelijke auteur)
+* **Beheerders:** medewerkers die verantwoordelijk zijn voor het aansturen van de visie en het managen van de organisatorische aspecten van het project (ze kunnen ook auteurs of eigenaren van het project zijn.)
+* **Bijdragers:** Iedereen die iets heeft bijgedragen aan het project
+* **Communityleden:** Mensen die het project gebruiken. Ze kunnen actief zijn in gesprekken of hun mening geven over de richting van het project
 
-Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+Grotere projecten kunnen ook subcommissies of werkgroepen hebben die zich richten op verschillende taken, zoals tooling, triage, community-moderatie en het organiseren van evenementen. Kijk op de website van een project voor een "team"-pagina of in de repository voor bestuursdocumentatie om deze informatie te vinden.
 
-A project also has documentation. These files are usually listed in the top level of a repository.
+Een project heeft ook documentatie. Deze bestanden worden meestal op het hoogste niveau van een repository vermeld.
 
-* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
-* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
-* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
-* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
-* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.
+* **LICENSE:** Per definitie moet elk open source project een [open source licentie](https://choosealicense.com) hebben. Als het project geen licentie heeft, is het geen open source.
+* **README:** De README is de instructiehandleiding die nieuwe gemeenschapsleden verwelkomt bij het project. Het legt uit waarom het project nuttig is en hoe u ermee kunt beginnen.
+* **CONTRIBUTORS:** Terwijl README's mensen helpen het project te _gebruiken_, helpen bijdragende documenten mensen _bij te dragen_ aan het project. Het legt uit welke soorten bijdragen nodig zijn en hoe het proces werkt. Hoewel niet elk project een CONTRIBUTING-bestand heeft, geeft de aanwezigheid ervan aan dat dit een welkom project is om aan bij te dragen.
+* **CODE_OF_CONDUCT:** De gedragscode stelt basisregels vast voor het bijbehorende gedrag van deelnemers en helpt om een ​​vriendelijke, gastvrije omgeving mogelijk te maken. Hoewel niet elk project een CODE_OF_CONDUCT-bestand heeft, geeft de aanwezigheid ervan aan dat dit een welkom project is om aan bij te dragen.
+* **Andere documentatie:** Er kan aanvullende documentatie zijn, zoals tutorials, walkthroughs of governance-beleid, vooral bij grotere projecten.
 
-Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+Ten slotte gebruiken open source-projecten de volgende tools om discussies te organiseren. Als je de archieven doorleest, krijg je een goed beeld van hoe de gemeenschap denkt en werkt.
 
-* **Issue tracker:** Where people discuss issues related to the project.
-* **Pull requests:** Where people discuss and review changes that are in progress.
-* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
-* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
+* **Issue tracker:** waar mensen problemen bespreken die verband houden met het project.
+* **Pull-verzoeken:** waar mensen wijzigingen bespreken en beoordelen die aan de gang zijn.
+* **Discussieforums of mailinglijsten** Sommige projecten kunnen deze kanalen gebruiken voor gespreksonderwerpen (bijvoorbeeld _"Hoe kan ik ..."_ of _"Waar denk je aan ..."_ in plaats van bugs rapporten of functieverzoeken). Anderen gebruiken de issue tracker voor alle gesprekken.
+* **Synchroon chatkanaal:** Sommige projecten gebruiken chatkanalen (zoals Slack of IRC) voor informele gesprekken, samenwerking en snelle uitwisselingen.
 
 ## Een project vinden om aan bij te dragen
 
-Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+Nu je weet hoe open source-projecten werken, is het tijd om een ​​project te vinden waaraan je kunt bijdragen!
 
-If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_
+Als je nog nooit eerder hebt bijgedragen aan open source, neem dan wat advies in van de Amerikaanse president John F. Kennedy, die ooit zei: _"Vraag niet wat uw land voor u kan doen - vraag wat u voor uw land kunt doen."_
 
-Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+Bijdragen aan open source gebeurt op alle niveaus, over projecten heen. U hoeft niet te veel na te denken over wat uw eerste bijdrage precies zal zijn, of hoe deze eruit zal zien.
 
-Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+Begin in plaats daarvan met nadenken over de projecten die u al gebruikt of wilt gebruiken. De projecten waaraan u actief bijdraagt, zijn de projecten waar u naar terugkeert.
 
-Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+Wanneer je binnen die projecten merkt dat je denkt dat iets beter of anders kan, handel dan naar je instinct.
 
-Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+Open source is geen exclusieve club; het is gemaakt door mensen zoals jij. "Open source" is gewoon een mooie term om de problemen van de wereld als herstelbaar te behandelen.
 
-You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
+U kunt een README lezen en een incorrecte link of typefout vinden. Of je bent een nieuwe gebruiker en je hebt gemerkt dat er iets kapot is, of een probleem waarvan je denkt dat het echt in de documentatie zou moeten staan. In plaats van het te negeren en verder te gaan, of iemand anders te vragen om het op te lossen, kijk of je kunt helpen door mee te doen. Dat is waar het bij open source om draait!
 
-> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+> [28% van de losse bijdragen](https://www.igor.pro.br/publica/papers/saner2016.pdf) aan open source zijn documentatie, zoals een typefout, herformattering of het schrijven van een vertaling.
 
-If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+Als u op zoek bent naar bestaande problemen die u kunt oplossen, heeft elk open source-project een '/ contribute'-pagina die beginnersvriendelijke problemen belicht waarmee u kunt beginnen. Navigeer naar de hoofdpagina van de repository op GitHub en voeg '/ contribute' toe aan het einde van de URL (bijvoorbeeld [`https://github.com/facebook/react/contribute`](https://github.com/facebook/contribute/contribute)).
 
-You can also use one of the following resources to help you discover and contribute to new projects:
+U kunt ook een van de volgende bronnen gebruiken om u te helpen bij het ontdekken van en bijdragen aan nieuwe projecten:
 
 * [GitHub Explore](https://github.com/explore/)
 * [Open Source Friday](https://opensourcefriday.com)
@@ -232,43 +243,43 @@ You can also use one of the following resources to help you discover and contrib
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://www.sourcesort.com/)
 
-### A checklist before you contribute
+### Een checklist voordat u bijdraagt
 
-When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+Als je een project hebt gevonden waaraan je zou willen bijdragen, doe dan een snelle scan om er zeker van te zijn dat het project geschikt is om bijdragen te accepteren. Anders krijgt uw harde werk misschien nooit een reactie.
 
-Here's a handy checklist to evaluate whether a project is good for new contributors.
+Hier is een handige checklist om te evalueren of een project goed is voor nieuwe bijdragers.
 
-**Meets the definition of open source**
+**Voldoet aan de definitie van open source**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+  Heeft het een licentie? Gewoonlijk is er een bestand met de naam LICENSE in de root van de repository.
   </label>
 </div>
 
-**Project actively accepts contributions**
+**Project accepteert actief bijdragen**
 
-Look at the commit activity on the master branch. On GitHub, you can see this information on a repository's homepage.
+Kijk naar de commit-activiteit op de main branch. Op GitHub kun je deze informatie zien op de startpagina van een repository.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-  When was the latest commit?
+  Wanneer was de laatste commit?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-  How many contributors does the project have?
+  Hoeveel bijdragers heeft het project?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  Hoe vaak commiten mensen? (Op GitHub kun je dit vinden door op "Commits" in de bovenste balk te klikken.)
   </label>
 </div>
 
@@ -277,259 +288,268 @@ Next, look at the project's issues.
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    How many open issues are there?
+    Hoeveel openstaande issues zijn er?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to issues when they are opened?
+    Reageren beheerders snel op issues wanneer ze worden geopend?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the issues?
+    Is er een actieve discussie over de issues?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-    Are the issues recent?
+    Zijn de issues recent?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+    Worden problemen gesloten? (Klik op GitHub op het tabblad "closed" op de pagina Issues om gesloten problemen te zien.)
   </label>
 </div>
 
-Now do the same for the project's pull requests.
+Doe nu hetzelfde voor de pull-verzoeken van het project.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    How many open pull requests are there?
+    Hoeveel openstaande pull-aanvragen zijn er?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox20" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to pull requests when they are opened?
+    Reageren beheerders snel op pull-verzoeken wanneer ze worden geopend?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the pull requests?
+    Is er actieve discussie over de pull-aanvragen?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    Are the pull requests recent?
+    Zijn de pull-aanvragen recent?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox13" class="overflow-hidden d-block text-normal">
-    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+    Hoe recent zijn pull-verzoeken samengevoegd? (Klik op GitHub op het tabblad "closed" op de pagina Pull Requests om gesloten PR's te zien.)
   </label>
 </div>
 
-**Project is welcoming**
+**Project is gastvrij**
 
-A project that is friendly and welcoming signals that they will be receptive to new contributors.
+Een project dat vriendelijk en gastvrij is, geeft aan dat ze ontvankelijk zullen zijn voor nieuwe bijdragers.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox14" class="overflow-hidden d-block text-normal">
-    Do the maintainers respond helpfully to questions in issues?
+    Reageren de beheerders behulpzaam op vragen in problemen?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox15" class="overflow-hidden d-block text-normal">
-    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+    Zijn mensen vriendelijk in de problemen, het discussieforum en de chat (bijvoorbeeld IRC of Slack)?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox16" class="overflow-hidden d-block text-normal">
-    Do pull requests get reviewed?
+    Worden pull-aanvragen beoordeeld?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox17" class="overflow-hidden d-block text-normal">
-    Do maintainers thank people for their contributions?
+    Bedanken onderhouders mensen voor hun bijdragen?
   </label>
 </div>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-  Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+  Elke keer dat je een lange thread ziet, controleer dan de reacties van kernontwikkelaars die laat in de thread komen. Vatten ze constructief samen en ondernemen ze stappen om de rode draad tot een beslissing te brengen terwijl ze beleefd blijven? Als je veel vlammenoorlogen ziet plaatsvinden, is dat vaak een teken dat energie in discussie gaat in plaats van in ontwikkeling.
+  
+  _Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development._
+  
   <p markdown="1" class="pquote-credit">
-— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+— @kfogel, [_OSS Produceren_](https://producingoss.com/en/evaluating-oss-projects.html)
   </p>
 </aside>
 
 ## Hoe u een bijdrage kunt indienen
 
-You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+Je hebt een project gevonden dat je leuk vindt en je bent klaar om een bijdrage te leveren. Tenslotte! Hier leest u hoe u uw bijdrage op de juiste manier krijgt.
 
-### Communicating effectively
+### Effectief communiceren
 
-Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+Of je nu een eenmalige bijdrage levert of probeert lid te worden van een community, samenwerken met anderen is een van de belangrijkste vaardigheden die je in open source zult ontwikkelen.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
-  \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+  \[Als nieuwe bijdrager\] realiseerde ik me al snel dat ik vragen moest stellen als ik het probleem wilde sluiten. Ik bladerde door de codebasis. Toen ik eenmaal een idee had van wat er aan de hand was, vroeg ik om meer richting. En voilà! Ik kon het probleem oplossen nadat ik alle relevante details had gekregen die ik nodig had.
+  
+  _\[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed._
+  
   <p markdown="1" class="pquote-credit">
-— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+— @shubheksha, [Een hobbelige reis voor beginners door de wereld van open source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
   </p>
 </aside>
 
-Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+Houd deze punten in gedachten voordat u een probleem of pull-aanvraag opent of een vraag stelt in de chat, zodat uw ideeën effectief overkomen.
 
-**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+**Geef context.** Help anderen om snel aan de slag te gaan. Als u een fout tegenkomt, leg dan uit wat u probeert te doen en hoe u deze kunt reproduceren. Als je een nieuw idee voorstelt, leg dan uit waarom je denkt dat het nuttig zou zijn voor het project (niet alleen voor jou!).
 
-> 😇 _"X doesn't happen when I do Y"_
+> 😇 _"X gebeurt niet wanneer ik Y doe"_
 >
-> 😢 _"X is broken! Please fix it."_
+> 😢 _"X is kapot! Los het probleem op."_
 
-**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn.
+**Maak van tevoren je huiswerk.** Het is oké om dingen niet te weten, maar laat zien dat je het geprobeerd hebt. Voordat u om hulp vraagt, moet u de README, documentatie, problemen (open of gesloten), mailinglijst van een project raadplegen en op internet naar een antwoord zoeken. Mensen zullen het waarderen als je laat zien dat je probeert te leren.
 
-> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+> 😇 _"Ik weet niet zeker hoe ik X moet implementeren. Ik heb de helpdocumenten gecontroleerd en geen vermeldingen gevonden."_
 >
-> 😢 _"How do I X?"_
+> 😢 _"Hoe kan ik X?"_
 
-**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+**Houd verzoeken kort en direct.** Net als bij het verzenden van een e-mail, vereist elke bijdrage, hoe eenvoudig of nuttig ook, de beoordeling van iemand anders. Veel projecten hebben meer inkomende verzoeken dan mensen die beschikbaar zijn om te helpen. Wees beknopt. Je vergroot de kans dat iemand je kan helpen.
 
-> 😇 _"I'd like to write an API tutorial."_
+> 😇 _"Ik zou graag een API-tutorial willen schrijven."_
 >
-> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+> 😢 _"Ik reed onlangs over de snelweg en stopte om te tanken, en toen had ik een geweldig idee voor iets dat we zouden moeten doen, maar voordat ik dat uitleg, wil ik je laten zien ..."_
 
-**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+**Houd alle communicatie openbaar.** Hoewel het verleidelijk is, moet u niet privé contact opnemen met beheerders, tenzij u gevoelige informatie moet delen (zoals een beveiligingsprobleem of een ernstige schending van het gedrag). Als u het gesprek openbaar houdt, kunnen meer mensen leren en profiteren van uw uitwisseling. Discussies kunnen op zichzelf bijdragen zijn.
 
-> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+> 😇 _(als commentaar) "@-maintainer Hallo! Hoe gaan we verder met deze PR?"_
 >
-> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+> 😢 _(als e-mail) "Hallo, sorry dat ik je stoor via e-mail, maar ik vroeg me af of je de kans hebt gehad om mijn PR te herzien"_
 
-**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+**Het is oké om vragen te stellen (maar wees geduldig!).** Iedereen was op een gegeven moment nieuw in het project en zelfs ervaren bijdragers moeten op de hoogte zijn als ze naar een nieuw project kijken. Op dezelfde manier zijn zelfs langdurige beheerders niet altijd bekend met elk onderdeel van het project. Toon ze hetzelfde geduld dat je zou willen dat ze je tonen.
 
-> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+> 😇 _"Bedankt voor het onderzoeken van deze fout. Ik heb uw suggesties gevolgd. Hier is de uitvoer."_
 >
-> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+> 😢 _"Waarom kun je mijn probleem niet oplossen? Is dit niet jouw project?"_
 
-**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+**Respecteer gemeenschapsbeslissingen.** Uw ideeën kunnen verschillen van de prioriteiten of visie van de gemeenschap. Ze kunnen feedback geven of besluiten uw idee niet na te streven. Terwijl u moet discussiëren en zoeken naar een compromis, moeten beheerders langer met uw beslissing leven dan u wilt. Als je het niet eens bent met hun richting, kun je altijd aan je eigen vork werken of je eigen project starten.
 
-> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+> 😇 _"Ik ben teleurgesteld dat je mijn use case niet kunt ondersteunen, maar zoals je hebt uitgelegd, heeft het slechts invloed op een klein deel van de gebruikers, ik begrijp waarom. Bedankt voor het luisteren."_
 >
-> 😢 _"Why won't you support my use case? This is unacceptable!"_
+> 😢 _"Waarom steun je mijn use case niet? Dit is onaanvaardbaar!"_
 
-**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+**Houd het vooral netjes.** Open source bestaat uit medewerkers van over de hele wereld. Context gaat verloren in talen, culturen, geografische gebieden en tijdzones. Bovendien maakt schriftelijke communicatie het moeilijker om een ​​toon of stemming over te brengen. Ga in deze gesprekken uit van goede bedoelingen. Het is prima om beleefd terug te komen op een idee, om meer context te vragen of je standpunt verder te verduidelijken. Probeer gewoon het internet op een betere plek achter te laten dan toen u het vond.
 
-### Gathering context
+### Context verzamelen
 
-Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+Voordat u iets doet, controleert u eerst of uw idee nergens anders is besproken. Bekijk de README, problemen (open en gesloten), mailinglijst en Stack Overflow van het project. Je hoeft geen uren te besteden aan het doornemen van alles, maar een snelle zoektocht naar een paar sleutelbegrippen gaat ver.
 
-If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request:
+Als u uw idee nergens anders kunt vinden, bent u klaar om een ​​stap te zetten. Als het project op GitHub staat, communiceer je waarschijnlijk door een issue of pull request te openen:
 
-* **Issues** are like starting a conversation or discussion
-* **Pull requests** are for starting work on a solution
-* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one
+* **Problemen/Issues** zijn als het starten van een gesprek of discussie
+* **Pull-aanvragen** zijn bedoeld om aan een oplossing te beginnen
+* **Voor eenvoudige communicatie**, zoals een verhelderende of how-to-vraag, kunt u vragen stellen op Stack Overflow, IRC, Slack of andere chatkanalen, als het project er een heeft
 
-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.
+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.
 
-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.
+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.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
-  You'll learn <em>a lot</em> from taking a single project you actively use, "watching" it on GitHub and reading every issue and PR.
+  Je leert <em>veel</em> door een enkel project te nemen dat je actief gebruikt, het op GitHub te "bekijken" en elk nummer en PR te lezen.
+  
+  _You'll learn <em>a lot</em> from taking a single project you actively use, "watching" it on GitHub and reading every issue and PR._
+  
 <p markdown="1" class="pquote-credit">
-— @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
+— @gaearon [over deelname aan projecten](https://twitter.com/dan_abramov/status/819555257055322112)
   </p>
 </aside>
 
-### Opening an issue
+### Een issue openen
 
-You should usually open an issue in the following situations:
+U zou gewoonlijk een probleem (_issue_) moeten openen in de volgende situaties:
 
-* Report an error you can't solve yourself
-* Discuss a high-level topic or idea (for example, community, vision or policies)
-* Propose a new feature or other project idea
+* Meld een fout die u niet zelf kunt oplossen
+* Bespreek een onderwerp of idee op hoog niveau (bijvoorbeeld gemeenschap, visie of beleid)
+* Stel een nieuwe functie of ander projectidee voor
 
-Tips for communicating on issues:
+Tips voor het communiceren over problemen:
 
-* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
-* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
-* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+* **Als u een openstaand probleem ziet dat u wilt aanpakken,** geef dan commentaar op het probleem om mensen te laten weten dat u ermee bezig bent. Op die manier is de kans kleiner dat mensen uw werk dupliceren.
+* **Als een probleem een tijdje geleden is geopend,** is het mogelijk dat het ergens anders wordt aangepakt of al is opgelost, dus reageer om bevestiging te vragen voordat u aan het werk gaat.
+* **Als je een probleem hebt geopend, maar het antwoord later zelf hebt bedacht,** geef dan commentaar op het probleem om mensen dit te laten weten en sluit het probleem vervolgens. Zelfs het documenteren van die uitkomst is een bijdrage aan het project.
 
-### Opening a pull request
+### Een pull-verzoek openen
 
-You should usually open a pull request in the following situations:
+U moet gewoonlijk een pull-aanvraag openen in de volgende situaties:
 
-* Submit trivial fixes (for example, a typo, a broken link or an obvious error)
-* Start work on a contribution that was already asked for, or that you've already discussed, in an issue
+* Voer triviale reparaties in (bijvoorbeeld een typefout, een verbroken link of een duidelijke fout)
+* Ga aan de slag met een bijdrage waar al om is gevraagd, of die je al hebt besproken in een issue
 
-A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
+Een pull-verzoek hoeft niet het voltooide werk te vertegenwoordigen. Het is meestal beter om vroegtijdig een pull-verzoek te openen, zodat anderen uw voortgang kunnen bekijken of feedback kunnen geven. Markeer het gewoon als een "WIP" (Work in Progress) in de onderwerpregel. Je kunt later altijd meer commits toevoegen.
 
-If the project is on GitHub, here's how to submit a pull request:
+Als het project op GitHub staat, kun je als volgt een pull-aanvraag indienen:
 
-* **[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/).)
-* **[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.
-* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
-* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+* **[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/).)
+* **[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.
+* **Test uw wijzigingen!** Voer uw wijzigingen uit met bestaande tests als deze bestaan ​​en maak nieuwe aan als dat nodig is. Of er tests bestaan ​​of niet, zorg ervoor dat uw wijzigingen het bestaande project niet verstoren.
+* **Draag zo goed mogelijk bij in de stijl van het project**. Dit kan betekenen dat u inspringingen, puntkomma's of commentaren anders moet gebruiken dan in uw eigen repository, maar het maakt het gemakkelijker voor de onderhouder om samen te voegen, zodat anderen het begrijpen en onderhouden in de toekomst.
 
-If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+Als dit je eerste pull-verzoek is, bekijk dan [Maak een  Pull Request](http://makeapullrequest.com/), dat @kentcdodds heeft gemaakt als een walkthrough video-tutorial. Je kunt ook oefenen met het maken van een pull-verzoek in de [First Contributions](https://github.com/Roshanjossey/first-contributions) repo, gemaakt door @Roshanjossey.
 
 ## Wat gebeurt er nadat u een bijdrage heeft ingeleverd?
 
-You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
+Je hebt het gedaan! Gefeliciteerd met het worden van een open source-bijdrager. We hopen dat dit de eerste van vele is.
 
-After you submit a contribution, one of the following will happen:
+Nadat u een bijdrage heeft ingeleverd, gebeurt een van de volgende zaken:
 
-### 😭 You don't get a response.
+### 😭 U krijgt geen antwoord.
 
-Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+Hopelijk heb je [het project gecontroleerd op tekenen van een checklist voordat je bijdraagt](#een-checklist-voordat-u-bijdraagt) voordat je een bijdrage levert. Zelfs bij een actief project is het echter mogelijk dat uw bijdrage geen reactie krijgt.
 
-If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+Als je al meer dan een week geen reactie hebt gekregen, is het redelijk om beleefd te reageren in dezelfde thread en iemand om een ​​recensie te vragen. Als u de naam kent van de juiste persoon om uw bijdrage te beoordelen, kunt u deze @-vermelding in die thread.
 
-**Don't** reach out to that person privately; remember that public communication is vital to open source projects.
+**Reik niet** privé naar die persoon; Onthoud dat openbare communicatie essentieel is voor open source-projecten.
 
-If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+Als je een beleefde hobbel maakt en nog steeds niemand reageert, is het mogelijk dat niemand ooit zal reageren. Het is geen geweldig gevoel, maar laat dat je niet ontmoedigen. Het is iedereen overkomen! Er zijn veel mogelijke redenen waarom u geen reactie heeft gekregen, waaronder persoonlijke omstandigheden waar u mogelijk geen controle over heeft. Probeer een ander project of een andere manier te vinden om bij te dragen. Dit is in ieder geval een goede reden om niet te veel tijd te investeren in het leveren van een bijdrage voordat andere leden van de gemeenschap betrokken en responsief zijn.
 
-### 🚧 Someone requests changes to your contribution.
+### 🚧 Iemand vraagt ​​om wijzigingen in uw bijdrage.
 
-It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+Het komt vaak voor dat u wordt gevraagd om wijzigingen aan te brengen in uw bijdrage, of dat nu feedback is over de reikwijdte van uw idee of wijzigingen in uw code.
 
-When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it.
+Reageer als iemand om veranderingen vraagt. Ze hebben de tijd genomen om uw bijdrage te herzien. Een PR openen en weglopen is een slechte vorm. Als u niet weet hoe u wijzigingen moet aanbrengen, onderzoek dan het probleem en vraag indien nodig om hulp.
 
-If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
+Als je geen tijd meer hebt om aan de kwestie te werken (bijvoorbeeld als het gesprek al maanden aan de gang is en je omstandigheden zijn veranderd), laat het de beheerder dan weten, zodat hij geen reactie verwacht. Iemand anders neemt het misschien graag over.
 
-### 👎 Your contribution doesn't get accepted.
+### 👎 Uw bijdrage wordt niet geaccepteerd.
 
-Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+Uw bijdrage kan uiteindelijk wel of niet worden geaccepteerd. Hopelijk heb je er niet al te veel werk in gestoken. Als u niet zeker weet waarom het niet werd geaccepteerd, is het volkomen redelijk om de beheerder om feedback en opheldering te vragen. Uiteindelijk moet u echter respecteren dat dit hun beslissing is. Maak geen ruzie en word niet vijandig. Je bent altijd welkom om te fork en aan je eigen versie te werken als je het niet eens bent!
 
-### 🎉 Your contribution gets accepted.
+### 🎉 Uw bijdrage wordt geaccepteerd.
 
-Hooray! You've successfully made an open source contribution!
+Hoera! Je hebt met succes een open source bijdrage geleverd!
 
-## You did it!
+## Je hebt het gedaan!
 
-Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
+Of je nu net je eerste open source-bijdrage hebt geleverd of op zoek bent naar nieuwe manieren om bij te dragen, we hopen dat je geïnspireerd bent om actie te ondernemen. Zelfs als uw bijdrage niet werd geaccepteerd, vergeet dan niet te bedanken wanneer een onderhouder moeite heeft gedaan om u te helpen. Open source wordt gemaakt door mensen zoals jij: één probleem, pull-verzoek, opmerking of high-five tegelijk.

From 6fcf43fa8f3df83f2ad3bf04c659fe348f6ebef8 Mon Sep 17 00:00:00 2001
From: Sam Chen <chenxsan@gmail.com>
Date: Sun, 6 Sep 2020 19:48:00 +0800
Subject: [PATCH 074/749] Update branch name

Currently the link was broken because of branch `master` renamed to `main`.
---
 _includes/footer.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_includes/footer.html b/_includes/footer.html
index 1344c683370..3bf511f15bd 100644
--- a/_includes/footer.html
+++ b/_includes/footer.html
@@ -9,7 +9,7 @@
           <h3 class="h3-mktg mb-3">{{ t.footer.contribute.heading }}</h3>
           <p class="mb-3 p-large">{{ t.footer.contribute.description }}</p>
           <p>
-            <a data-proofer-ignore href="https://github.com/{{ site.github.repository_nwo }}/edit/master/{{ page.path }}" class="btn btn-outline">
+            <a data-proofer-ignore href="https://github.com/{{ site.github.repository_nwo }}/edit/main/{{ page.path }}" class="btn btn-outline">
               {{ t.footer.contribute.button }}
             </a>
           </p>

From fc18f11c81dd87768f6cb9dbe422d58178309ac2 Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Fri, 11 Sep 2020 12:01:33 +0000
Subject: [PATCH 075/749] Bump html-proofer from 3.15.3 to 3.16.0

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.15.3 to 3.16.0.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.15.3...v3.16.0)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index b8af9284227..20b79913abd 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -84,7 +84,7 @@ GEM
     html-pipeline (2.13.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.15.3)
+    html-proofer (3.16.0)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)
@@ -223,7 +223,7 @@ GEM
     octokit (4.18.0)
       faraday (>= 0.9)
       sawyer (~> 0.8.0, >= 0.5.3)
-    parallel (1.19.1)
+    parallel (1.19.2)
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
     public_suffix (3.1.1)

From 9a4496b0313044a0d45b09cd2541f1e3bb0e4b08 Mon Sep 17 00:00:00 2001
From: John Bampton <jbampton@users.noreply.github.com>
Date: Wed, 16 Sep 2020 03:09:08 +1000
Subject: [PATCH 076/749] Fix case of GitHub.

Changed `Github` to `GitHub`.
---
 _articles/es/leadership-and-governance.md | 2 +-
 _articles/id/how-to-contribute.md         | 2 +-
 _articles/id/leadership-and-governance.md | 2 +-
 _articles/ko/legal.md                     | 2 +-
 _articles/zh-hans/finding-users.md        | 4 ++--
 _articles/zh-hans/legal.md                | 2 +-
 _articles/zh-hans/metrics.md              | 4 ++--
 _articles/zh-hant/best-practices.md       | 2 +-
 _articles/zh-hant/finding-users.md        | 4 ++--
 _articles/zh-hant/metrics.md              | 4 ++--
 _data/locales/fr.yml                      | 2 +-
 _data/locales/id.yml                      | 2 +-
 12 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/_articles/es/leadership-and-governance.md b/_articles/es/leadership-and-governance.md
index 6d4bff40845..851bdb87850 100644
--- a/_articles/es/leadership-and-governance.md
+++ b/_articles/es/leadership-and-governance.md
@@ -117,7 +117,7 @@ Si usted es parte de una empresa lanzando un proyecto de c&oacute;digo abierto,
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
-  Nosotros asignamos peque&ntilde;os equipos para gestionar proyectos en Github, los cuales está actualmente trabajando en ellos en Facebook. Por ejemplo, React es ejecutado por un Ingeniero de React.
+  Nosotros asignamos peque&ntilde;os equipos para gestionar proyectos en GitHub, los cuales está actualmente trabajando en ellos en Facebook. Por ejemplo, React es ejecutado por un Ingeniero de React.
   <p markdown="1" class="pquote-credit">
 — @caabernathy, ["Una vista interna del c&oacute;digo abierto en Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
   </p>
diff --git a/_articles/id/how-to-contribute.md b/_articles/id/how-to-contribute.md
index 186ad3100f6..32fb5cdd575 100644
--- a/_articles/id/how-to-contribute.md
+++ b/_articles/id/how-to-contribute.md
@@ -441,7 +441,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://help.github.com/articles/watching-repositories/) 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">
diff --git a/_articles/id/leadership-and-governance.md b/_articles/id/leadership-and-governance.md
index 5207df0d5bf..c10e564f2ed 100644
--- a/_articles/id/leadership-and-governance.md
+++ b/_articles/id/leadership-and-governance.md
@@ -117,7 +117,7 @@ Jika Anda bagian dari sebuah perusahaan yang merilis proyek open source, maka ak
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
-  Kami menugaskan kelompok kecil untuk mengelola proyek pada Github di Facebook. Sebagai contoh, React dikelola oleh pengembang React.
+  Kami menugaskan kelompok kecil untuk mengelola proyek pada GitHub di Facebook. Sebagai contoh, React dikelola oleh pengembang React.
   <p markdown="1" class="pquote-credit">
 — @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
   </p>
diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index aca341aa5cc..a29e73a35ad 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -34,7 +34,7 @@ related:
 
 **GitHub 프로젝트를 공개하는 것은 프로젝트 라이센싱과 동일하지 않습니다.** 공개 프로젝트는 [GitHub의 서비스 약관](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)에 명시되어 있으며, 다른 사람들이 프로젝트를 보거나 포크할 수는 있지만, 다른 권한은 없습니다.
 
-다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게하려면, 오픈소스 라이선스를 포함해야합니다. 예를 들어, Github 프로젝트가 공개되어 있다 하더라도 명시적으로 권한을 부여하지 않는다면, 그 코드의 어느 부분도 사용할 수 없습니다. 
+다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게하려면, 오픈소스 라이선스를 포함해야합니다. 예를 들어, GitHub 프로젝트가 공개되어 있다 하더라도 명시적으로 권한을 부여하지 않는다면, 그 코드의 어느 부분도 사용할 수 없습니다. 
 
 ## Just give me the TL;DR on what I need to protect my project.
 
diff --git a/_articles/zh-hans/finding-users.md b/_articles/zh-hans/finding-users.md
index f7a6452c369..2ab573437c8 100644
--- a/_articles/zh-hans/finding-users.md
+++ b/_articles/zh-hans/finding-users.md
@@ -40,9 +40,9 @@ redirect_from: /zh-cn/finding-users/
 
 通过引导他们到一个唯一的地址来帮助人们发现和记住你的项目。
 
-**要有一个推广的主阵地。**一个Twitter账号，Github链接，或者IRC频道是引导人们查看你的项目的一个简单方式。这些方式也给你日益增长的社区一个讨论的好地方。
+**要有一个推广的主阵地。**一个Twitter账号，GitHub链接，或者IRC频道是引导人们查看你的项目的一个简单方式。这些方式也给你日益增长的社区一个讨论的好地方。
 
-如果你目前还不想给你的项目搞这么多乱七八糟的东西，只要在有机会的时候推广你的Twitter账户和Github账户即可。举个例子，如果你在某一个讨论会或者活动上发言要保证在你的简历或者幻灯片上包含这些信息。只有这样人们才会知道怎么找到你或者关注你的工作。
+如果你目前还不想给你的项目搞这么多乱七八糟的东西，只要在有机会的时候推广你的Twitter账户和GitHub账户即可。举个例子，如果你在某一个讨论会或者活动上发言要保证在你的简历或者幻灯片上包含这些信息。只有这样人们才会知道怎么找到你或者关注你的工作。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index 5b8c9adc1a4..70f3811d41b 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -27,7 +27,7 @@ redirect_from: /zh-cn/legal/
 
 最后，你们的项目可能和你们不知道的许可证要求存在依赖关系。你们的项目社区，或者你们的雇主政策也可能要求你们使用特定的开源许可协议。我们将在下面介绍这些情况。
 
-## Github上的公开项目都是开源的吗？
+## GitHub上的公开项目都是开源的吗？
 
 当你们在GitHub上[创建一个新项目](https://help.github.com/articles/creating-a-new-repository/) 时，你们可以选择将仓库设置成**private**或者**public**。
 
diff --git a/_articles/zh-hans/metrics.md b/_articles/zh-hans/metrics.md
index d415d95fc2f..da2b857ccf7 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://help.github.com/articles/about-repository-graphs/#traffic) 获取诸如多少人访问过你的项目，他们从哪里得知的之类的信息。在你的项目主页，点击"Graphs", 然后"Traffic"。在这个页面，你可以看到:
 
 * **总浏览量:** 项目被查看了多少次
 
@@ -60,7 +60,7 @@ redirect_from: /zh-cn/metrics/
 
 每个包管理工具可能会对下载量有着大同小异的定义，而且下载量并不直接和安装、使用有关，但是它提供了一个基本的比较标准。尝试使用[Libraries.io](https://libraries.io/) 来跟踪很多流行包管理工具的使用数据。
 
-如果你的项目是托管在Github上，再一次切换到"Traffic" 页面，你可以用[clone graph](https://github.com/blog/1873-clone-graphs)看看你的项目在一个给定的日期被克隆了多少次，按照独立克隆者的总克隆数排序。
+如果你的项目是托管在GitHub上，再一次切换到"Traffic" 页面，你可以用[clone graph](https://github.com/blog/1873-clone-graphs)看看你的项目在一个给定的日期被克隆了多少次，按照独立克隆者的总克隆数排序。
 
 ![clone graph](/assets/images/metrics/clone_graph.png)
 
diff --git a/_articles/zh-hant/best-practices.md b/_articles/zh-hant/best-practices.md
index dcf58dd50df..b0401a04f8e 100644
--- a/_articles/zh-hant/best-practices.md
+++ b/_articles/zh-hant/best-practices.md
@@ -231,7 +231,7 @@ fork一個專案不什麼壞事情。能複製並且修改別人的程式是開
 * [mention-bot](https://github.com/facebook/mention-bot) 可能的貢獻者來幫你複查程式
 * [Danger](https://github.com/danger/danger) 幫你自動複查程式
 
-對於bug報告和其他常見形式的貢獻，Github有[Issue 模版和 Pull Request 模版](https://github.com/blog/2111-issue-and-pull-request-templates), 你可以用來降低溝通成本。你也可以設置[郵件過濾](https://github.com/blog/2203-email-updates-about-your-own-activity)來管理你的郵件提醒。
+對於bug報告和其他常見形式的貢獻，GitHub有[Issue 模版和 Pull Request 模版](https://github.com/blog/2111-issue-and-pull-request-templates), 你可以用來降低溝通成本。你也可以設置[郵件過濾](https://github.com/blog/2203-email-updates-about-your-own-activity)來管理你的郵件提醒。
 
 如果你想更加的先進和高效，程式風格指南和linter能讓你專案收到的貢獻更加規範，而且更容易複查和被接受。
 
diff --git a/_articles/zh-hant/finding-users.md b/_articles/zh-hant/finding-users.md
index 419c4f97eb6..94cbc2150dd 100644
--- a/_articles/zh-hant/finding-users.md
+++ b/_articles/zh-hant/finding-users.md
@@ -40,9 +40,9 @@ redirect_from: /zh-tw/finding-users/
 
 通過引導他們到一個唯一的地址來幫助人們發現和記住你的專案。
 
-**要有一個推廣的主陣地。**一個Twitter賬號，Github鏈接，或者IRC頻道是引導人們查看你們專案的一個簡單的方式。這些方式也給你日益增長的社群一個討論的好地方。
+**要有一個推廣的主陣地。**一個Twitter賬號，GitHub鏈接，或者IRC頻道是引導人們查看你們專案的一個簡單的方式。這些方式也給你日益增長的社群一個討論的好地方。
 
-如果你目前還不想給你的專案搞這麼多亂七八糟的東西，而且還要在有機會的時候推廣你的Twitter帳號和Github帳號。舉個例子，如果你某一個討論會或者活動上發言要保證在你的簡歷或者幻燈片上包含這些資訊。只有這樣人們才會知道怎麼找到你或者關注你的工作。
+如果你目前還不想給你的專案搞這麼多亂七八糟的東西，而且還要在有機會的時候推廣你的Twitter帳號和GitHub帳號。舉個例子，如果你某一個討論會或者活動上發言要保證在你的簡歷或者幻燈片上包含這些資訊。只有這樣人們才會知道怎麼找到你或者關注你的工作。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars2.githubusercontent.com/u/131416?v=3&s=400" class="pquote-avatar" alt="avatar">
diff --git a/_articles/zh-hant/metrics.md b/_articles/zh-hant/metrics.md
index f49cec99abe..9fffa326ec7 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://help.github.com/articles/about-repository-graphs/#traffic) 獲取諸如多少人訪問過你的專案，他們從哪裏得知的之類的資訊。在你的專案主頁，點擊"Graphs", 然後"Traffic"。在這個頁面，你可以看到:
 
 * **總瀏覽量:** 專案被查看了多少次
 
@@ -60,7 +60,7 @@ redirect_from: /zh-tw/metrics/
 
 每個包管理工具可能會對下載量有着大同小異的定義，而且下載量並不直接和安裝、使用有關，但是它提供了一個基本的比較標準。嘗試使用[Libraries.io](https://libraries.io/) 來跟蹤很多流行包管理工具的使用數據。
 
-如果你的專案是託管在Github上，再一次切換到"Traffic" 頁面，你可以用[clone graph](https://github.com/blog/1873-clone-graphs)看看你的專案在一個給定的日期被克隆了多少次，按照獨立克隆者的總克隆數排序。
+如果你的專案是託管在GitHub上，再一次切換到"Traffic" 頁面，你可以用[clone graph](https://github.com/blog/1873-clone-graphs)看看你的專案在一個給定的日期被克隆了多少次，按照獨立克隆者的總克隆數排序。
 
 ![clone graph](/assets/images/metrics/clone_graph.png)
 
diff --git a/_data/locales/fr.yml b/_data/locales/fr.yml
index 6ed7bd07f5f..919f1fba667 100644
--- a/_data/locales/fr.yml
+++ b/_data/locales/fr.yml
@@ -17,7 +17,7 @@ fr:
       button: Contribuer
     subscribe:
       heading: Restons en contact
-      description: Soyez le premier à découvrir les dernières astuces et ressources concernant les logiciels libres avec Github.
+      description: Soyez le premier à découvrir les dernières astuces et ressources concernant les logiciels libres avec GitHub.
       label: Adresse Email
       button: S'abonner
     byline:
diff --git a/_data/locales/id.yml b/_data/locales/id.yml
index 83d19d81375..a7254054b70 100644
--- a/_data/locales/id.yml
+++ b/_data/locales/id.yml
@@ -17,7 +17,7 @@ id:
       button: Kontribusi
     subscribe:
       heading: Terus berhubungan
-      description: Jadilah yang pertama untuk mendengar tentang tips dan sumber daya open source terbaru Github.
+      description: Jadilah yang pertama untuk mendengar tentang tips dan sumber daya open source terbaru GitHub.
       label: Alamat Email
       button: Berlangganan
     byline:

From e79abd747736f81623e0bf40722765c0efa95d94 Mon Sep 17 00:00:00 2001
From: John Bampton <jbampton@users.noreply.github.com>
Date: Wed, 16 Sep 2020 10:06:01 +1000
Subject: [PATCH 077/749] Fix case of JavaScript.

Changed `javascript` to `JavaScript`.
---
 _articles/getting-paid.md    | 2 +-
 _articles/hu/getting-paid.md | 2 +-
 _articles/ja/getting-paid.md | 2 +-
 _articles/ms/getting-paid.md | 2 +-
 _articles/nl/getting-paid.md | 2 +-
 _articles/pl/getting-paid.md | 2 +-
 _articles/pt/getting-paid.md | 2 +-
 _articles/tr/getting-paid.md | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/_articles/getting-paid.md b/_articles/getting-paid.md
index 8dd04786bf3..0df5ca6ecda 100644
--- a/_articles/getting-paid.md
+++ b/_articles/getting-paid.md
@@ -111,7 +111,7 @@ Depending on your personal circumstances, you can try raising money independentl
 
 Finally, sometimes open source projects put bounties on issues that you might consider helping with. 
 
-* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their javascript library [through a bounty on gitcoin](https://gitcoin.co/).
+* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
 * @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
 
 ## Finding funding for your project
diff --git a/_articles/hu/getting-paid.md b/_articles/hu/getting-paid.md
index 79a3da5924d..7fa29f1d3d4 100644
--- a/_articles/hu/getting-paid.md
+++ b/_articles/hu/getting-paid.md
@@ -106,7 +106,7 @@ A személyes körülményeidtől függően megpróbálhatsz önállóan pénzt g
 
 Végül, néha a nyílt forráskódú projektek díjakat tűznek ki a hibák megoldására, amelyekkel kapcsolatban akár érdemes lehet segítséget nyújtani.
 
-* @ConnorChristie fizetséget kapott azért, mert [segített](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol -nak a javascript könyvtár fejlesztésében, mindezt a [gitcoin rendszeren keresztül](https://gitcoin.co/).
+* @ConnorChristie fizetséget kapott azért, mert [segített](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol -nak a JavaScript könyvtár fejlesztésében, mindezt a [gitcoin rendszeren keresztül](https://gitcoin.co/).
 * @mamiM elvégezte a japán nyelvi fordítást @MetaMask részére, melyet [a Bounties Network-ön keresztül finanszíroztak](https://explorer.bounties.network/bounty/134).
 
 ## Találd meg a projekt finanszírozását
diff --git a/_articles/ja/getting-paid.md b/_articles/ja/getting-paid.md
index cfe61ba37f5..6a12b82fbe1 100644
--- a/_articles/ja/getting-paid.md
+++ b/_articles/ja/getting-paid.md
@@ -106,7 +106,7 @@ related:
 
 最後に、オープンソースプロジェクトの中には問題解決を手伝ってもらうために報奨金を提示しているものもあります。
 
-* @ConnorChristie は [gitcoin の報奨金制度](https://gitcoin.co/)で @MARKETProtocol が javascript ライブラリの作業を[手伝う](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14)ことで金銭を得ました。
+* @ConnorChristie は [gitcoin の報奨金制度](https://gitcoin.co/)で @MARKETProtocol が JavaScript ライブラリの作業を[手伝う](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14)ことで金銭を得ました。
 * @mamiM は @MetaMask の日本語訳作業が [Bounties Network に資金提供された際に](https://beta.bounties.network/bounty/v1/134)、その作業を行いました。
 
 ## あなたのプロジェクトへの資金提供を探そう
diff --git a/_articles/ms/getting-paid.md b/_articles/ms/getting-paid.md
index 1722caa7396..abeb71c1248 100644
--- a/_articles/ms/getting-paid.md
+++ b/_articles/ms/getting-paid.md
@@ -111,7 +111,7 @@ Bergantung pada keadaan peribadi anda, anda boleh mencuba mengumpulkan wang seca
 
 Akhirnya, kadang-kadang projek sumber terbuka memberi banyak manfaat kepada masalah yang mungkin anda pertimbangkan untuk membantu.
 
-* @ConnorChristie dapat dibayar[helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol berfungsi di perpustakaan javascript mereka [through a bounty on gitcoin](https://gitcoin.co/).
+* @ConnorChristie dapat dibayar[helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol berfungsi di perpustakaan JavaScript mereka [through a bounty on gitcoin](https://gitcoin.co/).
 * @mamiM melakukan terjemahan Jepun untuk @MetaMask selepas [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
 
 ## Mencari dana untuk projek anda
diff --git a/_articles/nl/getting-paid.md b/_articles/nl/getting-paid.md
index 6de7d1d2ae5..906eeb47b40 100644
--- a/_articles/nl/getting-paid.md
+++ b/_articles/nl/getting-paid.md
@@ -126,7 +126,7 @@ Afhankelijk van uw persoonlijke omstandigheden kunt u proberen om zelfstandig ge
 
 Ten slotte geven open source-projecten soms premies voor problemen waarmee u zou kunnen helpen.
 
-* @ConnorChristie kon betaald worden voor [helpen](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol werken aan hun javascript-bibliotheek [via een premie op gitcoin](https://gitcoin.co/).
+* @ConnorChristie kon betaald worden voor [helpen](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol werken aan hun JavaScript-bibliotheek [via een premie op gitcoin](https://gitcoin.co/).
 * @mamiM deed Japanse vertalingen voor @MetaMask nadat de [kwestie werd gefinancierd op Bounties Network](https://explorer.bounties.network/bounty/134).
 
 ## Financiering vinden voor uw project
diff --git a/_articles/pl/getting-paid.md b/_articles/pl/getting-paid.md
index e5e34b20420..34cff4c0d5e 100644
--- a/_articles/pl/getting-paid.md
+++ b/_articles/pl/getting-paid.md
@@ -118,7 +118,7 @@ W zależności od osobistych okoliczności możesz spróbować samodzielnie zebr
 
 Wreszcie, czasami projekty open source dają nagrody za problemy, z którymi możesz pomyśleć o pomocy.
 
-* @ConnorChristie był w stanie otrzymać wynagrodzenie za [pomoc](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol pracować nad biblioteką javascript [poprzez nagrodę za gitcoin](https://gitcoin.co/).
+* @ConnorChristie był w stanie otrzymać wynagrodzenie za [pomoc](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol pracować nad biblioteką JavaScript [poprzez nagrodę za gitcoin](https://gitcoin.co/).
 * @mamiM zrobiłem japońskie tłumaczenia dla @MetaMask po tym, jak [problem został sfinansowany przez Bounties Network](https://explorer.bounties.network/bounty/134).
 
 ## Znajdowanie funduszy na swój projekt
diff --git a/_articles/pt/getting-paid.md b/_articles/pt/getting-paid.md
index 52ac7839efd..319aa377b34 100644
--- a/_articles/pt/getting-paid.md
+++ b/_articles/pt/getting-paid.md
@@ -106,7 +106,7 @@ Dependendo de suas circunstâncias pessoais, você pode tentar conseguir dinheir
 
 Finalmente, as vezes, projetos open source põem recompensas em issues que você pode considerar ajudar a resolver. 
 
-* @ConnorChristie conseguiu ser pago por [ajudar](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol a trabalhar em sua biblioteca javascript [através de uma recompensa em gitcoin](https://gitcoin.co/).
+* @ConnorChristie conseguiu ser pago por [ajudar](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol a trabalhar em sua biblioteca JavaScript [através de uma recompensa em gitcoin](https://gitcoin.co/).
 * @mamiM fez traduções para o Japonês para @MetaMask após a [issue ser financiada na Bounties Network](https://explorer.bounties.network/bounty/134).
 
 ## Encontrando financiamento para o seu projeto
diff --git a/_articles/tr/getting-paid.md b/_articles/tr/getting-paid.md
index 8b3f0a7ef1e..a174211d33c 100644
--- a/_articles/tr/getting-paid.md
+++ b/_articles/tr/getting-paid.md
@@ -111,7 +111,7 @@ Kişisel durumunuza bağlı olarak, açık kaynaklı işinize para yatırmak iç
 
 Son olarak, bazen açık kaynaklı projeler, yardım etmeyi düşündüğünüz meselelere güçlükler getirir.
 
-* @ConnorChristie, @MARKETProtocol'un javascript paketlerinde [yardımcı olarak](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) gitcoin'deki bir [ödülle{/a2} para kazanabildi.](https://gitcoin.co/)
+* @ConnorChristie, @MARKETProtocol'un JavaScript paketlerinde [yardımcı olarak](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) gitcoin'deki bir [ödülle{/a2} para kazanabildi.](https://gitcoin.co/)
 * @mamiM, [sorun Bounties Network'te finanse](https://explorer.bounties.network/bounty/134) edildikten sonra @MetaMask için Japonca çeviriler yaptı.
 
 ## Projeniz için finansman bulma

From 9de4d2ef248e849430e3fb028dbb6953146bb7c4 Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Wed, 23 Sep 2020 19:26:08 +0300
Subject: [PATCH 078/749] Fix typo in translation doc

---
 docs/translations.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/translations.md b/docs/translations.md
index 281eb851c26..c964dcbd977 100644
--- a/docs/translations.md
+++ b/docs/translations.md
@@ -17,7 +17,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 inivte 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://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.
 
 ## Updating a translation
 

From 54fa3731acdde3180ac064baaf8909867ae61ee4 Mon Sep 17 00:00:00 2001
From: zhaoying <zhaoying1258@qq.com>
Date: Thu, 24 Sep 2020 23:39:09 +0800
Subject: [PATCH 079/749] Update zh-hans.yml

---
 _data/locales/zh-hans.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_data/locales/zh-hans.yml b/_data/locales/zh-hans.yml
index 6f9d2ef39bd..3c1aaa9534d 100644
--- a/_data/locales/zh-hans.yml
+++ b/_data/locales/zh-hans.yml
@@ -4,7 +4,7 @@ zh-hans:
     about: 关于
     contribute: 贡献
   index:
-    lead: 开源软件是由像你这样的人开发的。了解一下如何启动和增长您的项目。 
+    lead: 开源软件是由像你这样的人开发的。了解一下如何启动和发展您的项目。 
     opensourcefriday: 又是星期五！投入几个小时为您使用和喜爱的软件做出贡献
   article:
     table_of_contents: 目录

From 83bbad8db8f1c638ee480772861866cc5795fe93 Mon Sep 17 00:00:00 2001
From: zhaoying <zhaoying1258@qq.com>
Date: Thu, 24 Sep 2020 23:45:35 +0800
Subject: [PATCH 080/749] Update how-to-contribute.md

---
 _articles/zh-hans/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/how-to-contribute.md b/_articles/zh-hans/how-to-contribute.md
index e985ca3882f..3f72258f5a5 100644
--- a/_articles/zh-hans/how-to-contribute.md
+++ b/_articles/zh-hans/how-to-contribute.md
@@ -1,7 +1,7 @@
 ---
 lang: zh-hans
 title: 如何为开源做贡献
-description: 想为开源贡献力量？本指南针为"菜鸟"和初学者而准备！
+description: 想为开源贡献力量？本指南为"菜鸟"和初学者而准备！
 class: contribute
 order: 1
 image: /assets/images/cards/contribute.png

From ed0b4bd8f6f39d6e5b7b26a48ad1f24fdfe66f3e Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Mon, 28 Sep 2020 15:18:33 +0000
Subject: [PATCH 081/749] Bump github-pages from 207 to 208

Bumps [github-pages](https://github.com/github/pages-gem) from 207 to 208.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v207...v208)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 45 +++++++++++++++++++++++----------------------
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 20b79913abd..8c9b4471688 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (6.0.3.2)
+    activesupport (6.0.3.3)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
@@ -16,10 +16,10 @@ GEM
     colorator (1.1.0)
     commonmarker (0.17.13)
       ruby-enum (~> 0.5)
-    concurrent-ruby (1.1.6)
+    concurrent-ruby (1.1.7)
     dnsruby (1.61.4)
       simpleidn (~> 0.1)
-    em-websocket (0.5.1)
+    em-websocket (0.5.2)
       eventmachine (>= 0.12.9)
       http_parser.rb (~> 0.6.0)
     ethon (0.12.0)
@@ -31,23 +31,23 @@ GEM
     ffi (1.13.1)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (207)
+    github-pages (208)
       github-pages-health-check (= 1.16.1)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
       jekyll-coffeescript (= 1.1.1)
       jekyll-commonmark-ghpages (= 0.1.6)
       jekyll-default-layout (= 0.1.4)
-      jekyll-feed (= 0.13.0)
+      jekyll-feed (= 0.15.0)
       jekyll-gist (= 1.5.0)
       jekyll-github-metadata (= 2.13.0)
-      jekyll-mentions (= 1.5.1)
+      jekyll-mentions (= 1.6.0)
       jekyll-optional-front-matter (= 0.3.2)
       jekyll-paginate (= 1.1.0)
       jekyll-readme-index (= 0.3.0)
-      jekyll-redirect-from (= 0.15.0)
+      jekyll-redirect-from (= 0.16.0)
       jekyll-relative-links (= 0.6.1)
-      jekyll-remote-theme (= 0.4.1)
+      jekyll-remote-theme (= 0.4.2)
       jekyll-sass-converter (= 1.5.2)
       jekyll-seo-tag (= 2.6.1)
       jekyll-sitemap (= 1.4.0)
@@ -55,7 +55,7 @@ GEM
       jekyll-theme-architect (= 0.1.1)
       jekyll-theme-cayman (= 0.1.1)
       jekyll-theme-dinky (= 0.1.1)
-      jekyll-theme-hacker (= 0.1.1)
+      jekyll-theme-hacker (= 0.1.2)
       jekyll-theme-leap-day (= 0.1.1)
       jekyll-theme-merlot (= 0.1.1)
       jekyll-theme-midnight (= 0.1.1)
@@ -66,14 +66,14 @@ GEM
       jekyll-theme-tactile (= 0.1.1)
       jekyll-theme-time-machine (= 0.1.1)
       jekyll-titles-from-headings (= 0.5.3)
-      jemoji (= 0.11.1)
+      jemoji (= 0.12.0)
       kramdown (= 2.3.0)
       kramdown-parser-gfm (= 1.1.0)
       liquid (= 4.0.3)
       mercenary (~> 0.3)
       minima (= 2.5.1)
       nokogiri (>= 1.10.4, < 2.0)
-      rouge (= 3.19.0)
+      rouge (= 3.23.0)
       terminal-table (~> 1.4)
     github-pages-health-check (1.16.1)
       addressable (~> 2.3)
@@ -81,7 +81,7 @@ GEM
       octokit (~> 4.0)
       public_suffix (~> 3.0)
       typhoeus (~> 1.3)
-    html-pipeline (2.13.0)
+    html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
     html-proofer (3.16.0)
@@ -122,14 +122,14 @@ GEM
       rouge (>= 2.0, < 4.0)
     jekyll-default-layout (0.1.4)
       jekyll (~> 3.0)
-    jekyll-feed (0.13.0)
+    jekyll-feed (0.15.0)
       jekyll (>= 3.7, < 5.0)
     jekyll-gist (1.5.0)
       octokit (~> 4.2)
     jekyll-github-metadata (2.13.0)
       jekyll (>= 3.4, < 5.0)
       octokit (~> 4.0, != 4.4.0)
-    jekyll-mentions (1.5.1)
+    jekyll-mentions (1.6.0)
       html-pipeline (~> 2.3)
       jekyll (>= 3.7, < 5.0)
     jekyll-optional-front-matter (0.3.2)
@@ -137,14 +137,15 @@ GEM
     jekyll-paginate (1.1.0)
     jekyll-readme-index (0.3.0)
       jekyll (>= 3.0, < 5.0)
-    jekyll-redirect-from (0.15.0)
+    jekyll-redirect-from (0.16.0)
       jekyll (>= 3.3, < 5.0)
     jekyll-relative-links (0.6.1)
       jekyll (>= 3.3, < 5.0)
-    jekyll-remote-theme (0.4.1)
+    jekyll-remote-theme (0.4.2)
       addressable (~> 2.0)
       jekyll (>= 3.5, < 5.0)
-      rubyzip (>= 1.3.0)
+      jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0)
+      rubyzip (>= 1.3.0, < 3.0)
     jekyll-sass-converter (1.5.2)
       sass (~> 3.4)
     jekyll-seo-tag (2.6.1)
@@ -161,8 +162,8 @@ GEM
     jekyll-theme-dinky (0.1.1)
       jekyll (~> 3.5)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-hacker (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-hacker (0.1.2)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
     jekyll-theme-leap-day (0.1.1)
       jekyll (~> 3.5)
@@ -196,7 +197,7 @@ GEM
       jekyll (>= 3.3, < 5.0)
     jekyll-watch (2.2.1)
       listen (~> 3.0)
-    jemoji (0.11.1)
+    jemoji (0.12.0)
       gemoji (~> 3.0)
       html-pipeline (~> 2.2)
       jekyll (>= 3.0, < 5.0)
@@ -214,7 +215,7 @@ GEM
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
-    minitest (5.14.1)
+    minitest (5.14.2)
     multipart-post (2.1.1)
     nokogiri (1.10.10)
       mini_portile2 (~> 2.4.0)
@@ -233,7 +234,7 @@ GEM
     rb-inotify (0.10.1)
       ffi (~> 1.0)
     rexml (3.2.4)
-    rouge (3.19.0)
+    rouge (3.23.0)
     ruby-enum (0.8.0)
       i18n
     rubyzip (2.3.0)

From 318f867e106650a19e24fc00e12b0039b15db051 Mon Sep 17 00:00:00 2001
From: TeeVenDick <56723862+TeeVenDick@users.noreply.github.com>
Date: Thu, 1 Oct 2020 14:23:21 +0800
Subject: [PATCH 082/749] Update readme.md

Added links to their respective github profile to all the people mentioned in the acknowledgments
---
 README.md | 35 +++++++++++++++++++++++++++++++++--
 1 file changed, 33 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index cfcc09bcb5c..5fbeac7ba24 100644
--- a/README.md
+++ b/README.md
@@ -19,9 +19,40 @@ Content is released under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.
 
 ## Acknowledgments
 
-The initial release of these guides were authored by **@nayafia, @bkeepers, @stephbwills,** and **@mlinksva**.
+The initial release of these guides were authored by **[@nayafia][1], [@bkeepers][2], [@stephbwills][3],** and **[@mlinksva][4]**.
 
-Thanks to **@aitchabee, @benbalter, @brettcannon, @caabernathy, @coralineada, @dmleong, @ericholscher, @gr2m, @janl, @jessfraz, @joshsimmons, @kfogel, @kytrinyx, @lee-dohm, @mikeal, @mikemcquaid, @nathansobo, @nruff, @nsqe, @orta, @parkr, @shazow, @steveklabnik,** and **@wooorm** for lending their valuable input and expertise leading up to the initial release, and to **@sophshep** and **@jeejkang** for designing and illustrating the guides.
+Thanks to **[@aitchabee][5], [@benbalter][6], [@brettcannon][7], [@caabernathy][8], [@coralineada][9], [@dmleong][10], [@ericholscher][11], [@gr2m][12], [@janl][13], [@jessfraz][14], [@joshsimmons][15], [@kfogel][16], [@kytrinyx][17], [@lee-dohm][18], [@mikeal][19], [@mikemcquaid][20], [@nathansobo][21], [@nruff][22], [@nsqe][23], [@orta][24], [@parkr][25], [@shazow][26], [@steveklabnik][27],** and **[@wooorm][28]** for lending their valuable input and expertise leading up to the initial release, and to **[@sophshep][29]** and **[@jeejkang][30]** for designing and illustrating the guides.
 
 ## Disclaimer
 While we've got advice about running an open source project, we're not lawyers. Be sure to read our [disclaimer](notices.md#legal-disclaimer) before diving in.
+
+[1]:https://github.com/nayafia
+[2]:https://github.com/bkeepers
+[3]:https://github.com/stephbwills
+[4]:https://github.com/mlinksva
+[5]:https://github.com/aitchabee
+[6]:https://github.com/benbalter
+[7]:https://github.com/brettcannon
+[8]:https://github.com/caabernathy
+[9]:https://github.com/CoralineAda
+[10]:https://github.com/dmleong
+[11]:https://github.com/ericholscher
+[12]:https://github.com/gr2m
+[13]:https://github.com/janl
+[14]:https://github.com/jessfraz
+[15]:https://github.com/joshsimmons
+[16]:https://github.com/kfogel
+[17]:https://github.com/kytrinyx
+[18]:https://github.com/lee-dohm
+[19]:https://github.com/mikeal
+[20]:https://github.com/MikeMcQuaid
+[21]:https://github.com/nathansobo
+[22]:https://github.com/nruff
+[23]:https://github.com/nsqe
+[24]:https://github.com/orta
+[25]:https://github.com/parkr
+[26]:https://github.com/shazow
+[27]:https://github.com/steveklabnik
+[28]:https://github.com/wooorm
+[29]:https://github.com/sophshep
+[30]:https://github.com/jeejkang

From cf41b674438fd61331c61199a6bce58a48790b92 Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Wed, 7 Oct 2020 15:09:47 +0000
Subject: [PATCH 083/749] Bump github-pages from 208 to 209

Bumps [github-pages](https://github.com/github/pages-gem) from 208 to 209.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v208...v209)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 8c9b4471688..08bee422be3 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -31,14 +31,14 @@ GEM
     ffi (1.13.1)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (208)
+    github-pages (209)
       github-pages-health-check (= 1.16.1)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
       jekyll-coffeescript (= 1.1.1)
       jekyll-commonmark-ghpages (= 0.1.6)
       jekyll-default-layout (= 0.1.4)
-      jekyll-feed (= 0.15.0)
+      jekyll-feed (= 0.15.1)
       jekyll-gist (= 1.5.0)
       jekyll-github-metadata (= 2.13.0)
       jekyll-mentions (= 1.6.0)
@@ -122,7 +122,7 @@ GEM
       rouge (>= 2.0, < 4.0)
     jekyll-default-layout (0.1.4)
       jekyll (~> 3.0)
-    jekyll-feed (0.15.0)
+    jekyll-feed (0.15.1)
       jekyll (>= 3.7, < 5.0)
     jekyll-gist (1.5.0)
       octokit (~> 4.2)

From 2030728a0a9f08156bee5db1f0005e129b7126b0 Mon Sep 17 00:00:00 2001
From: Johannes Nicolai <jonico@github.com>
Date: Thu, 8 Oct 2020 14:49:44 +0200
Subject: [PATCH 084/749] Cosmetic change s/Guides/guides/

* s/Guides/guides/
---
 CONTRIBUTING.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d07f0c1a17c..ae95d763e11 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -45,7 +45,7 @@ If you don't see your idea listed, and you think it fits into the goals of this
 * **If your contribution is major,** such as a new guide, start by opening an issue first. That way, other people can weigh in on the discussion before you do any work.
 
 ## Style guide
-If you're writing content, see the [style guide](./docs/styleguide.md) to help your prose match the rest of the Guides.
+If you're writing content, see the [style guide](./docs/styleguide.md) to help your prose match the rest of the guides.
 
 ## Setting up your environment
 

From 8eee43bac3f81a6e974f2b3fa79691bd40714cee Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Wed, 21 Oct 2020 12:59:40 +0200
Subject: [PATCH 085/749] correction to a typo

---
 _articles/pl/metrics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/metrics.md b/_articles/pl/metrics.md
index b448ba7fc7f..64d0d259e70 100644
--- a/_articles/pl/metrics.md
+++ b/_articles/pl/metrics.md
@@ -108,7 +108,7 @@ Przykłady wskaźników społeczności, które warto regularnie śledzić, obejm
 
 ## Działalność maintainera
 
-Wreszcie, będziesz chciał zamknąć pętlę, upewniając się, że opiekunowie twojego projektu są w stanie obsłużyć liczbę otrzymanych wkładów. Ostatnie pytanie, które chcesz sobie zadać, brzmi: _am ja (lub my) odpowiadam na naszą społeczność?_
+Wreszcie, będziesz chciał zamknąć pętlę, upewniając się, że opiekunowie twojego projektu są w stanie obsłużyć liczbę otrzymanych wkładów. Ostatnie pytanie, które chcesz sobie zadać, brzmi: _czy ja (lub my) odpowiadam na naszą społeczność?_
 
 Niereagujący opiekunowie stają się wąskim gardłem dla projektów typu open source. Jeśli ktoś złoży datek, ale nigdy nie usłyszy od opiekuna, może poczuć się zniechęcony i odejść.
 

From dbea79d25ad054a4724a4b47709ffcbe8208da02 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Wed, 21 Oct 2020 14:14:17 +0200
Subject: [PATCH 086/749] in nav given the mother tongue "Polski"

---
 _data/locales/pl.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_data/locales/pl.yml b/_data/locales/pl.yml
index 31e6d603be3..44229fd1d1e 100644
--- a/_data/locales/pl.yml
+++ b/_data/locales/pl.yml
@@ -1,5 +1,5 @@
 pl:
-  locale_name: Polish
+  locale_name: Polski
   nav:
     about: O projekcie
     contribute: Współpracuj

From 3ddca9d62668be2ad521beee7b6a15637337a16f Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Wed, 21 Oct 2020 15:24:27 +0200
Subject: [PATCH 087/749] the word "friends" translated in the footer

---
 _data/locales/pl.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_data/locales/pl.yml b/_data/locales/pl.yml
index 31e6d603be3..fc553f6f0d1 100644
--- a/_data/locales/pl.yml
+++ b/_data/locales/pl.yml
@@ -1,5 +1,5 @@
 pl:
-  locale_name: Polish
+  locale_name: Polski
   nav:
     about: O projekcie
     contribute: Współpracuj
@@ -28,4 +28,4 @@ pl:
       # Label for love octicon
       love_label: love
       # Label for the contributors link
-      friends_label: friends
+      friends_label: przyjaciele

From 1a55c0aac70091f1eef53ac74076f690fbc5b9d7 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Wed, 21 Oct 2020 15:25:09 +0200
Subject: [PATCH 088/749] main guide title translated

---
 _articles/pl/index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/index.html b/_articles/pl/index.html
index cd0b888a5e2..08b1f87a3c1 100644
--- a/_articles/pl/index.html
+++ b/_articles/pl/index.html
@@ -1,6 +1,6 @@
 ---
 layout: index
-title: Open Source Guides
+title: Przewodnik Open Source
 lang: pl
 permalink: /pl/
 ---

From bfa9fa9fcc2738f17d114f276dbd5ba5d5810a25 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Wed, 21 Oct 2020 15:27:01 +0200
Subject: [PATCH 089/749] translated title in "starting a project"

---
 _articles/pl/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/starting-a-project.md b/_articles/pl/starting-a-project.md
index dcce8e1b24d..d344b947aab 100644
--- a/_articles/pl/starting-a-project.md
+++ b/_articles/pl/starting-a-project.md
@@ -1,6 +1,6 @@
 ---
 lang: pl
-title: Starting an Open Source Project
+title: Rozpoczęcie projektu Open Source
 description: Dowiedz się więcej o świecie open source i przygotuj się do uruchomienia własnego projektu.
 class: beginners
 order: 2

From 975c99bb92294dce01fe0c21bbe338d08b0e1ea5 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Thu, 22 Oct 2020 09:44:49 +0200
Subject: [PATCH 090/749] translated check list from Documentation section

---
 _articles/pl/starting-a-project.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/pl/starting-a-project.md b/_articles/pl/starting-a-project.md
index dcce8e1b24d..bb6a32deba3 100644
--- a/_articles/pl/starting-a-project.md
+++ b/_articles/pl/starting-a-project.md
@@ -274,28 +274,28 @@ Gotowy do otwarcia twojego projektu? Oto lista kontrolna, która pomoże. Zaznac
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-    Project has a LICENSE file with an open source license
+    Projekt posiada plik LICENSE z licencją typu open source
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+    Projekt posiada podstawową dokumentację (README, CONTRIBUTING, CODE_OF_CONDUCT)
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+    Nazwa jest łatwa do zapamiętania, daje pewne wyobrażenie o tym, czym jest projekt i nie koliduje z istniejącym projektem oraz nie narusza znaków towarowych
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-    The issue queue is up-to-date, with issues clearly organized and labeled
+    Lista "issue" jest aktualna, a sprawy są przejrzyście uporządkowane i opatrzone etykietami
   </label>
 </div>
 

From ee4c22ec785a2d1fa005bf2d92f4f6f26c7352c7 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Thu, 22 Oct 2020 10:01:22 +0200
Subject: [PATCH 091/749] translated check list from Code section

---
 _articles/pl/starting-a-project.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/pl/starting-a-project.md b/_articles/pl/starting-a-project.md
index bb6a32deba3..194fef6138b 100644
--- a/_articles/pl/starting-a-project.md
+++ b/_articles/pl/starting-a-project.md
@@ -304,21 +304,21 @@ Gotowy do otwarcia twojego projektu? Oto lista kontrolna, która pomoże. Zaznac
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    Project uses consistent code conventions and clear function/method/variable names
+    Projekt wykorzystuje spójne konwencje kodu i przejrzyste nazwy funkcji, metod oraz zmiennych
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    The code is clearly commented, documenting intentions and edge cases
+    Kod jest dobrze skomentowany, dokumentując intencje i skrajne przypadki
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+    W historii zmian, w problemach lub Pull Request nie ma żadnych poufnych materiałów (na przykład haseł lub innych niepublicznych informacji)
   </label>
 </div>
 

From 186e50af22462e8c0b4792cf9c40c96cfabcbce5 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Thu, 22 Oct 2020 10:13:22 +0200
Subject: [PATCH 092/749] translated check list from People section

---
 _articles/pl/starting-a-project.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/_articles/pl/starting-a-project.md b/_articles/pl/starting-a-project.md
index 194fef6138b..8cb2953dd6d 100644
--- a/_articles/pl/starting-a-project.md
+++ b/_articles/pl/starting-a-project.md
@@ -329,7 +329,7 @@ Jeśli jesteś osobą fizyczną:
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  Rozmawiałeś z działem prawnym i/lub rozumiesz zasady dotyczące własności intelektualnej i zasad dotyczące oprogramowania open source (jeśli jesteś zatrudniony)
   </label>
 </div>
 
@@ -338,28 +338,28 @@ Jeśli jesteś firmą lub organizacją:
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    You've talked to your legal department
+    Rozmawiałeś ze swoim działem prawnym
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    You have a marketing plan for announcing and promoting the project
+    Masz plan marketingowy, aby ogłosić i promować swój projekt
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+    Ktoś jest zaangażowany w zarządzanie interakcjami społeczności (odpowiadanie na problemy, przeglądanie i łączenie pull requests)
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    At least two people have administrative access to the project
+    Przynajmniej dwie osoby mają dostęp administracyjny do projektu
   </label>
 </div>
 

From f4de38ff713e2cf11f86ab28fcb8a6eb1d6cccaf Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Thu, 22 Oct 2020 10:27:20 +0200
Subject: [PATCH 093/749] the main title in Polish was corrected

---
 _articles/pl/index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/index.html b/_articles/pl/index.html
index 08b1f87a3c1..2f2da93827a 100644
--- a/_articles/pl/index.html
+++ b/_articles/pl/index.html
@@ -1,6 +1,6 @@
 ---
 layout: index
-title: Przewodnik Open Source
+title: Przewodnik po Open Source
 lang: pl
 permalink: /pl/
 ---

From dedf87327876f99f0aabdcd16c79c1f41b0d097a Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Tue, 27 Oct 2020 08:32:00 +0100
Subject: [PATCH 094/749] translated check list from section 1

---
 _articles/pl/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index 8215646ee60..4df43619e58 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -246,7 +246,7 @@ Oto przydatna lista kontrolna do oceny, czy projekt jest dobry dla nowych autor
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+  Czy ma licencję? Zwykle w katalogu głównym repozytorium znajduje się plik o nazwie LICENSE.
   </label>
 </div>
 

From cde0f3c21e8dc3a9384dbe071643b8160429ffd5 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Tue, 27 Oct 2020 08:38:12 +0100
Subject: [PATCH 095/749] translated check list from section 2

---
 _articles/pl/how-to-contribute.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index 4df43619e58..49767fe40e4 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -257,21 +257,21 @@ Spójrz na działanie zatwierdzania w gałęzi master. Na GitHub możesz zobaczy
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-  When was the latest commit?
+  Kiedy były ostatnie commit-y?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-  How many contributors does the project have?
+  Ilu współautorów ma projekt?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  Jak często ludzie się w to angażują? (Możesz znaleźć te informacje w GitHub, klikając "Commits" na górnym pasku).
   </label>
 </div>
 
@@ -280,35 +280,35 @@ Następnie spójrz na issues projektu.
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    How many open issues are there?
+    Ile jest otwartych spraw (issues)?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to issues when they are opened?
+    Czy opiekunowie szybko reagują na nowo utworzone problemy?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the issues?
+    Czy kwestie są aktywnie omawiane?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-    Are the issues recent?
+    Czy problemy są aktualne?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+    Czy problemy są zamykane? (W serwisie GitHub na stronie "Issues" kliknij "closed", aby wyświetlić zamknięte problemy).
   </label>
 </div>
 

From 5a238677a465255bd8852504822738f54174a92f Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Tue, 27 Oct 2020 08:59:31 +0100
Subject: [PATCH 096/749] translated check list from section 3

---
 _articles/pl/how-to-contribute.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index 49767fe40e4..6379d53a78c 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -312,40 +312,40 @@ Następnie spójrz na issues projektu.
   </label>
 </div>
 
-Now do the same for the project's pull requests.
+Teraz wykonaj te same kroki dla PR (pull requests) projektu.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    How many open pull requests are there?
+    Ile jest otwartych żądań ściągnięcia (tzw. pull request)?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox20" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to pull requests when they are opened?
+    Czy opiekunowie szybko reagują na nowo utworzone PR (pull request)?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the pull requests?
+    Czy pull request są aktywnie omawiane?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    Are the pull requests recent?
+    Czy PR są aktualne?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox13" class="overflow-hidden d-block text-normal">
-    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+    Jak niedawno zostały scalone jakiekolwiek PR? (W GitHub w zakładkę "Pull Requests" kliknij "closed", aby zobaczyć zamknięte PR).
   </label>
 </div>
 

From 8c90ece6a3559a39a7e44dd172276be4fab25825 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Tue, 27 Oct 2020 09:04:50 +0100
Subject: [PATCH 097/749] translated check list from section 4

---
 _articles/pl/how-to-contribute.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index 6379d53a78c..3159d01da87 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -356,28 +356,28 @@ Projekt przyjazny i gościnny sygnalizuje, że będą otwarci na nowych autorów
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox14" class="overflow-hidden d-block text-normal">
-    Do the maintainers respond helpfully to questions in issues?
+    Czy opiekunowie udzielają pomocnych odpowiedzi na pytania dotyczące problemów?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox15" class="overflow-hidden d-block text-normal">
-    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+    Czy ludzie są przyjaźni w Issues, na forum dyskusyjnym czy na czacie (np. IRC lub Slack)?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox16" class="overflow-hidden d-block text-normal">
-    Do pull requests get reviewed?
+    Czy PR są sprawdzane?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox17" class="overflow-hidden d-block text-normal">
-    Do maintainers thank people for their contributions?
+    Czy opiekunowie dziękują ludziom za ich wkład?
   </label>
 </div>
 

From 1d0aeb0f617c6d1329ced7af7ef70094b4e2a457 Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Sat, 14 Nov 2020 20:41:24 +0000
Subject: [PATCH 098/749] Bump html-proofer from 3.16.0 to 3.17.0

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.16.0 to 3.17.0.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.16.0...v3.17.0)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 08bee422be3..85728b305be 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -84,7 +84,7 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.16.0)
+    html-proofer (3.17.0)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)
@@ -224,7 +224,7 @@ GEM
     octokit (4.18.0)
       faraday (>= 0.9)
       sawyer (~> 0.8.0, >= 0.5.3)
-    parallel (1.19.2)
+    parallel (1.20.0)
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
     public_suffix (3.1.1)

From c8a876f5e73f8bec7a8a5891a0d036a630ba063a Mon Sep 17 00:00:00 2001
From: taskmgr <taskmgr@users.noreply.github.com>
Date: Sun, 22 Nov 2020 14:41:27 +0800
Subject: [PATCH 099/749] =?UTF-8?q?=E7=BF=BB=E8=AF=91=E6=94=B9=E8=BF=9B?=
 =?UTF-8?q?=EF=BC=9Acode-of-conduct.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

1）修改了错别字
2）修改了显示不正常的一处markdown语法
3）对部分翻译进行改进，使其更易理解（至少我觉得更好理解了）
---
 _articles/zh-hans/code-of-conduct.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/_articles/zh-hans/code-of-conduct.md b/_articles/zh-hans/code-of-conduct.md
index 5b88b4f89ed..66067f0e525 100644
--- a/_articles/zh-hans/code-of-conduct.md
+++ b/_articles/zh-hans/code-of-conduct.md
@@ -45,7 +45,7 @@ redirect_from: /zh-cn/code-of-conduct/
   </p>
 </aside>
 
-你们应该解释如何执行行为守则在违规发生**之前**。有几点理由说明为什么这么做：
+你们应该在违规发生**之前**解释如何执行行为守则。有几点理由说明为什么这么做：
 
 * 必要的时候，它表示你们处事认真谨慎。
 
@@ -67,9 +67,9 @@ redirect_from: /zh-cn/code-of-conduct/
 
 ### 搜集有关违规的信息
 
-认真对待社区中每个成员的想法。如果你们收到有人违规的报告，请认真对待并调查此事，即使它不符合你们自己的经验。这样做可以向你们的社区表面，你们珍视他们的观点和信任他们的判断。
+认真对待社区中每个成员的想法。如果你们收到有人违规的报告，请认真对待并调查此事，即使它不符合你们自己的经验。这样做可以向你们的社区表明，你们珍视他们的观点和信任他们的判断。
 
-有的社区成员可能是让大家一直不舒服的惯犯，或者他们只是说了或做了一次。这都需要依据实际情况进行处理。
+有的社区成员可能是让大家一直不舒服的惯犯，或者他们只是初犯。这都需要依据实际情况进行处理。
 
 在你们做出回应之前，请认真思考发生了什么事。通过阅读他们过去的评论和对话可以更好地理解他们为什么要那样做。尽量收集其他人对他们行为的看法。
 
@@ -84,7 +84,7 @@ redirect_from: /zh-cn/code-of-conduct/
 
 当搜集和处理足够的信息后，你们需要决定做什么。当你们在考虑下一步的时候，请牢记你们的目的是营造一个安全，尊重和协作的社区氛围。不仅要考虑如何处理有问题的情况，还要考虑们的反应将如何影响你们社区的其他行为和期望。
 
-当有人报告违规时，处理它是你们的工作，而不是他们的。有时，报告者透露他们的信息会给他们的职业生涯，声誉和人生安全带来很大的风险。迫使报告者面对骚扰者会将他们置于妥协的位置。除非报告者有特别的要求，你们应该直接和有问题的人沟通。
+当有人报告违规时，处理它是你们的工作，而不是他们的。有时，透露报告者本人的信息会给他们的职业生涯，声誉和人生安全带来很大的风险。迫使报告者面对骚扰者会将他们置于妥协的位置。除非报告者有特别的要求，你们应该直接和有问题的人沟通。
 
 这里有些方法帮助你们回应违规行为：
 
@@ -106,9 +106,9 @@ redirect_from: /zh-cn/code-of-conduct/
 
 作为维护者，你们可以为社区指定准则，同时你们可以根据行为守则执行这些准则。这意味着你们需要认真处理违规行为。报告者对他们的投诉进行了彻底和认真地审查。如果你们确定他们报告的行为没有违规，你们需要他们进行沟通并解释你们为什么不进行处理。他们会怎样做，取决于他们：容忍他们认为有问题的行为，或者停止参与社区。
 
-如果报告的行为没有_技术上_的违规，这可能表面你们的社区依然存在问题，同时你们应该调查潜在的问题以及采取相应的行动。这可能包括修改你们的行为守则，以澄清可接受的行为和/或与行为被举报的人交谈，并告诉他们，虽然他们没有违反行为守则，但是他们在期望和确定的边缘另其他参与者感到不舒服。
+如果报告的行为没有 _技术上_ 的违规，这可能表面你们的社区依然存在问题，同时你们应该调查潜在的问题以及采取相应的行动。这可能包括修改你们的行为守则，以澄清可接受的行为和/或与行为被举报的人交谈，并告诉他们，虽然他们没有违反行为守则，但是他们在期望和确定的边缘另其他参与者感到不舒服。
 
-最后，作为维护者，你们给可接受的行为建立和执行标准。你们有能力塑造项目社区的价值观，以及参与者希望你们能 公平公正地执行这些价值观。
+最后，作为维护者，你们给可接受的行为建立和执行标准。你们有能力塑造项目社区的价值观，以及参与者希望你们能公平公正地执行这些价值观。
 
 ## 鼓励你们希望看见的行为 🌎
 

From a5b862f6a13703a5900567831be75a8aef6f4d3d Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Mon, 23 Nov 2020 12:01:54 +0000
Subject: [PATCH 100/749] Bump html-proofer from 3.17.0 to 3.17.2

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.17.0 to 3.17.2.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.17.0...v3.17.2)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 85728b305be..41eb97fba81 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -84,7 +84,7 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.17.0)
+    html-proofer (3.17.2)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)
@@ -219,12 +219,12 @@ GEM
     multipart-post (2.1.1)
     nokogiri (1.10.10)
       mini_portile2 (~> 2.4.0)
-    nokogumbo (2.0.2)
+    nokogumbo (2.0.3)
       nokogiri (~> 1.8, >= 1.8.4)
     octokit (4.18.0)
       faraday (>= 0.9)
       sawyer (~> 0.8.0, >= 0.5.3)
-    parallel (1.20.0)
+    parallel (1.20.1)
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
     public_suffix (3.1.1)

From f1e3dea641dedf2edd5fd05b9afa2f7a24591dce Mon Sep 17 00:00:00 2001
From: Moritz Ruth <dev@moritzruth.de>
Date: Mon, 23 Nov 2020 18:41:14 +0100
Subject: [PATCH 101/749] Improve a weird sentence

No one would say it that way.
---
 _articles/de/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/de/starting-a-project.md b/_articles/de/starting-a-project.md
index e34d9f9cce3..929f8f1d54d 100644
--- a/_articles/de/starting-a-project.md
+++ b/_articles/de/starting-a-project.md
@@ -210,7 +210,7 @@ Verlinken Sie Ihre CONTRIBUTING-Datei in Ihrer README, sodass mehr Leute sie bem
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
 
-  Wir haben alle Erfahrungen gemacht, wo wir mit Beleidigungen zu tun hatten, entweder als Betreuer\*in beim Erklären, warum etwas auf eine bestimmte Weise geschehen musste, oder als Benutzer\*in (...) beim Stellen einfacher Frage. (...) Ein Verhaltenskodex wird zu einem leicht referenzierbaren und verlinkbaren Dokument, das klar stellt, dass Ihr Team den konstruktiven Diskurs sehr ernst nimmt.
+  Wir haben alle Erfahrungen gemacht, wo wir mit Beleidigungen zu tun hatten, entweder als Betreuer\*in beim Erklären, warum etwas auf eine bestimmte Weise geschehen musste, oder als Benutzer\*in (...) beim Stellen einer einfachen Frage. (...) Ein Verhaltenskodex wird zu einem leicht referenzierbaren und verlinkbaren Dokument, das klar stellt, dass Ihr Team den konstruktiven Diskurs sehr ernst nimmt.
 
   _We've all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously._
 

From f752991a31e526a9cfccad9a1e7ca42a12629b9b Mon Sep 17 00:00:00 2001
From: gabrielsanttana <gabriel.gsantana7@gmail.com>
Date: Wed, 25 Nov 2020 17:00:22 -0300
Subject: [PATCH 102/749] Minor adjustment in how to contribute article
 portuguese translation

---
 _articles/pt/how-to-contribute.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md
index 81f16203699..5f13ebac82c 100644
--- a/_articles/pt/how-to-contribute.md
+++ b/_articles/pt/how-to-contribute.md
@@ -487,7 +487,7 @@ Se este é o seu primeiro pull request, confira [Faça um pull request](http://m
 
 ## O que acontece depois que você envia uma contribuição
 
-Você fez isso! Parabéns por se tornar um contribuidor open source. Esperamos que seja a primeira de muitas.
+Você conseguiu! Parabéns por se tornar um contribuidor open source. Esperamos que seja a primeira de muitas.
 
 Depois de enviar uma contribuição, uma das seguintes situações ocorrerá:
 
@@ -517,6 +517,6 @@ Sua contribuição pode ou não ser aceita no final. Espero que você não tenha
 
 Viva! Você fez uma contribuição open source com sucesso!
 
-## Você fez isso!
+## Você conseguiu!
 
 Se você acabou de fazer sua primeira contribuição open source ou está procurando novas maneiras de contribuir, esperamos que você esteja inspirado a agir. Mesmo que sua contribuição não tenha sido aceita, não se esqueça de agradecer quando um mantenedor se esforçar para ajudá-lo. O open source é feito por pessoas como você: uma issue, pull request, comentário ou high-five de cada vez.

From 4711cc57d1d9756895d7f0069d1889c6c83bb458 Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Sat, 28 Nov 2020 20:37:35 +0000
Subject: [PATCH 103/749] Bump html-proofer from 3.17.2 to 3.17.3

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.17.2 to 3.17.3.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.17.2...v3.17.3)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 41eb97fba81..21cd3f33969 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -84,7 +84,7 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.17.2)
+    html-proofer (3.17.3)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)
@@ -219,7 +219,7 @@ GEM
     multipart-post (2.1.1)
     nokogiri (1.10.10)
       mini_portile2 (~> 2.4.0)
-    nokogumbo (2.0.3)
+    nokogumbo (2.0.4)
       nokogiri (~> 1.8, >= 1.8.4)
     octokit (4.18.0)
       faraday (>= 0.9)

From a5c0a6ccb6c67b4dafd20e0279957517d656c0d0 Mon Sep 17 00:00:00 2001
From: Christian Oliff <christianoliff@pm.me>
Date: Mon, 30 Nov 2020 09:50:42 +0900
Subject: [PATCH 104/749] Always load mc-validate.js over HTTPS

URLS without a protocol are an anti-pattern. This is safer and faster.
---
 _layouts/default.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_layouts/default.html b/_layouts/default.html
index 835ebce073f..0688a6a99aa 100644
--- a/_layouts/default.html
+++ b/_layouts/default.html
@@ -9,7 +9,7 @@
     </main>
 
     <script src="{{ "/assets/js/index.js" | relative_url }}"></script>
-    <script type="text/javascript" src="//s3.amazonaws.com/downloads.mailchimp.com/js/mc-validate.js"></script>
+    <script type="text/javascript" src="https://s3.amazonaws.com/downloads.mailchimp.com/js/mc-validate.js"></script>
     <script type="text/javascript">(function($) {window.fnames = new Array(); window.ftypes = new Array();fnames[0]='EMAIL';ftypes[0]='email';fnames[1]='FNAME';ftypes[1]='text';fnames[2]='LNAME';ftypes[2]='text';}(jQuery));var $mcj = jQuery.noConflict(true);</script>
   </body>
 </html>

From bfe8012e4b5395b2f11242868c710d492807dde5 Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Thu, 3 Dec 2020 11:24:18 +0000
Subject: [PATCH 105/749] Bump html-proofer from 3.17.3 to 3.17.4

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.17.3 to 3.17.4.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.17.3...v3.17.4)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 21cd3f33969..a8ed8fb2ecf 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -84,7 +84,7 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.17.3)
+    html-proofer (3.17.4)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)

From b0ed23631d4cf4c0320fa58a884624bf4883a654 Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Wed, 16 Dec 2020 09:41:59 +0000
Subject: [PATCH 106/749] Fix broken links

Point to The Internet Archive for these instead.
---
 _articles/building-community.md         |  4 ++--
 _articles/de/building-community.md      |  4 ++--
 _articles/de/starting-a-project.md      |  2 +-
 _articles/es/building-community.md      |  4 ++--
 _articles/es/starting-a-project.md      |  2 +-
 _articles/fr/building-community.md      |  4 ++--
 _articles/fr/starting-a-project.md      |  2 +-
 _articles/hu/building-community.md      |  4 ++--
 _articles/hu/starting-a-project.md      |  2 +-
 _articles/id/building-community.md      |  4 ++--
 _articles/id/starting-a-project.md      |  2 +-
 _articles/ja/building-community.md      |  4 ++--
 _articles/ja/starting-a-project.md      |  2 +-
 _articles/ko/building-community.md      |  4 ++--
 _articles/ko/starting-a-project.md      |  2 +-
 _articles/ms/building-community.md      |  4 ++--
 _articles/ms/starting-a-project.md      |  2 +-
 _articles/nl/building-community.md      | 25 ++++++++++++++++---------
 _articles/nl/starting-a-project.md      | 22 ++++++++++++++--------
 _articles/pl/building-community.md      |  4 ++--
 _articles/pl/starting-a-project.md      |  2 +-
 _articles/pt/building-community.md      |  4 ++--
 _articles/pt/starting-a-project.md      |  2 +-
 _articles/ro/building-community.md      |  4 ++--
 _articles/ro/starting-a-project.md      |  2 +-
 _articles/starting-a-project.md         |  2 +-
 _articles/ta/building-community.md      |  4 ++--
 _articles/ta/starting-a-project.md      |  2 +-
 _articles/tr/building-community.md      |  4 ++--
 _articles/tr/starting-a-project.md      |  2 +-
 _articles/zh-hans/building-community.md |  4 ++--
 _articles/zh-hans/starting-a-project.md |  2 +-
 _articles/zh-hant/building-community.md |  4 ++--
 _articles/zh-hant/starting-a-project.md |  2 +-
 34 files changed, 78 insertions(+), 65 deletions(-)

diff --git a/_articles/building-community.md b/_articles/building-community.md
index eb4a09ebd3a..a86c8b26c55 100644
--- a/_articles/building-community.md
+++ b/_articles/building-community.md
@@ -59,7 +59,7 @@ Encouraging other contributors is an investment in yourself, too. When you empow
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -203,7 +203,7 @@ Your job as a maintainer is to keep these situations from escalating. Even if yo
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
   As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/de/building-community.md b/_articles/de/building-community.md
index 40ae61a0032..aed4d18f5a6 100644
--- a/_articles/de/building-community.md
+++ b/_articles/de/building-community.md
@@ -63,7 +63,7 @@ Andere zur Mitarbeit zu ermutigen, ist auch eine Investition in sich selbst: Wen
   _Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening._
 
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -227,7 +227,7 @@ Ihre Aufgabe als Maintainer\*in ist es, solche Situationen vor einer Eskalation
   _As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally._
 
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/de/starting-a-project.md b/_articles/de/starting-a-project.md
index 929f8f1d54d..c8fffb06f98 100644
--- a/_articles/de/starting-a-project.md
+++ b/_articles/de/starting-a-project.md
@@ -270,7 +270,7 @@ Egal ob offizielle Dokumentation oder informelle E-Mail: Ihr Schreibstil ist ein
   _I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style._
 
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/es/building-community.md b/_articles/es/building-community.md
index 92e4d643ff7..a0e3273dfc3 100644
--- a/_articles/es/building-community.md
+++ b/_articles/es/building-community.md
@@ -54,7 +54,7 @@ Animar a otros colaboradores es tambi&eacute;n invertir en t&iacute; mismo . Cua
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   ¿Alguna vez viste un evento (t&eacute;cnico) en donde no conozcas a nadie, pero todos los dem&aacute;s parece que se encuentran en grupos y conversan como viejos amigos? (...) Ahora imag&iacute;nate queriendo contribuir con un proyecto de c&oacute;digo abierto, pero no distingues porqu&eacute; o c&oacute;mo esto est&aacute; sucediendo.
   <p markdown="1" class="pquote-credit">
-— @janl, ["C&oacute;digo abierto sostenible"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["C&oacute;digo abierto sostenible"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -201,7 +201,7 @@ Tu trabajo como encargado es evitar que estas situaciones escalen. Incluso si ti
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
   Como responsable de un proyecto, es extremadamente importante ser respetuoso con los colaboradores. A menudo toman lo que les dices de manera personal.
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/es/starting-a-project.md b/_articles/es/starting-a-project.md
index a4be874ce18..fa4cf1b910e 100644
--- a/_articles/es/starting-a-project.md
+++ b/_articles/es/starting-a-project.md
@@ -250,7 +250,7 @@ Ya sea documentaci&oacute;n oficial como casual (un email), tu estilo de redacci
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   He tratado de involucrarme con cada hilo del listado de emails, y mostrando un comportamiento ejemplar, siendo agradable con las personas, tomando sus issues seriamente y tratando de ser de ayuda por sobre todo. Despu&eacute;s de un tiempo las personas no solo me buscaban para hacerme preguntas si no para ayudarme a responderlas, y, para mi sorpresa, imitaban mi estilo.
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/fr/building-community.md b/_articles/fr/building-community.md
index 929419b9e3b..546055b23fd 100644
--- a/_articles/fr/building-community.md
+++ b/_articles/fr/building-community.md
@@ -54,7 +54,7 @@ Encourager les autres contributeurs est un investissement en vous aussi. Lorsque
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Avez-vous déjà assisté à un événement (technique) où vous ne connaissiez personne, mais tout le monde semblait se tenir en groupe et discuter comme de vieux amis? (...) Maintenant, imaginez que vous voulez contribuer à un projet open source, mais vous ne voyez pas pourquoi ou comment cela se passe.
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -198,7 +198,7 @@ Votre travail en tant que mainteneur consiste à éviter l'escalade de ces situa
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
   En tant que responsable du projet, il est extrêmement important d'être respectueux envers vos contributeurs. Ils prennent souvent ce que vous dites très personnellement.
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/fr/starting-a-project.md b/_articles/fr/starting-a-project.md
index 662905a0857..f46c9dac4ff 100644
--- a/_articles/fr/starting-a-project.md
+++ b/_articles/fr/starting-a-project.md
@@ -250,7 +250,7 @@ Qu'il s'agisse d'une documentation officielle ou d'un courriel occasionnel, votr
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   J'ai essayé de m'impliquer dans tous les sujets de la liste de diffusion, de montrer un comportement exemplaire, d'être gentil avec les gens, de prendre leurs problèmes au sérieux et d'essayer d'être utile dans l'ensemble. Au bout d'un moment, les gens sont restés non seulement à poser des questions, mais aussi à répondre aux questions, et à mon plus grand plaisir, ils ont imité mon style.
   <p markdown="1" class="pquote-credit">
-— @janl sur [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl sur [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/hu/building-community.md b/_articles/hu/building-community.md
index 2e1051c4336..f2f1b02fbda 100644
--- a/_articles/hu/building-community.md
+++ b/_articles/hu/building-community.md
@@ -55,7 +55,7 @@ Más közreműködők ösztönzése számodra is hasznos befektetés. Ha támoga
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Voltál már valaha olyan (tech-) rendezvényen, ahol nem ismertél senkit, de úgy tűnt számodra, hogy mindenki más csoportokban áll és beszélget, mint a régi jó barátok? (...) Most képzeld el, hogy hozzá szeretnél járulni egy nyílt forráskódú projekthez, de nem tudod, miként, és hogyan lehetséges ez.
   <p markdown="1" class="pquote-credit">
-— @janl, ["Fenntartható Nyílt Forráskód"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Fenntartható Nyílt Forráskód"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -199,7 +199,7 @@ Mint karbantartó az a feladatod, hogy ezt a szituációt ne engedd eszkalálód
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
   Karbantartóként rendkívül fontos, hogy tiszteld a közreműködőket. Gyakran megfogadják azt, amit személyesen nekik mondasz.
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/hu/starting-a-project.md b/_articles/hu/starting-a-project.md
index d4d585486ba..e9501edb923 100644
--- a/_articles/hu/starting-a-project.md
+++ b/_articles/hu/starting-a-project.md
@@ -244,7 +244,7 @@ Akár hivatalos dokumentáció, akár alkalmi e-mail, az írási stílusa része
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Megpróbáltam részt venni a levelezőlista minden szálában, és példamutató magatartást mutatni, kedves voltam az emberekkel, komolyan vettem a kérdéseket, és általában mindenkinek segítettem. Egy idő múlva az emberek úgy kezdtek el viselkedni mint én, és nem csak kérdéseket tettek fel, hanem a válaszokat is adtak az én stílusomban, ennek nagyon örültem.
   <p markdown="1" class="pquote-credit">
-— @janl [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/id/building-community.md b/_articles/id/building-community.md
index 09d564c460b..04e30777d32 100644
--- a/_articles/id/building-community.md
+++ b/_articles/id/building-community.md
@@ -54,7 +54,7 @@ Mendorong kontributor lain adalah sebuah investasi pada diri Anda juga. Ketika A
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Apakah Anda pernah menghadiri sebuah acara dimana Anda tidak mengenal siapapun, tetapi orang lain tampak saling mengenal satu sama lain dan berbicara seperti sahabat dekat? (...) Sekarang bayangkan Anda ingin berkontribusi pada proyek open source, namun Anda tidak dapat melihat kenapa dan bagaimana ini bisa terjadi.
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -198,7 +198,7 @@ Tugas Anda sebagai pengelola adalah menjaga situasi ini agar tidak sampai memunc
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
   Sebagai pengelola proyek, sangatlah penting untuk menghargai kontributor Anda. Mereka seringkali menerima apa yang Anda sampaikan secara personal.
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/id/starting-a-project.md b/_articles/id/starting-a-project.md
index 052e0dea70e..7822b03b815 100644
--- a/_articles/id/starting-a-project.md
+++ b/_articles/id/starting-a-project.md
@@ -250,7 +250,7 @@ Baik dokumentasi resmi atau email sehari-hari, gaya penulisan Anda merupakan bag
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Saya berusaha untuk ikut terlibat pada setiap diskusi pada mailing list, dan memberikan contoh panutan, bertindak baik kepada orang-orang, menganggap masalah mereka sebagai sesuatu yang serius, dan berusaha untuk membantu. Setelah beberapa waktu, orang-orang tidak hanya berhenti karena ada masalah, namun juga ikut membantu, dan mereka mengikuti gaya saya.
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/ja/building-community.md b/_articles/ja/building-community.md
index 64bed111839..57957e7df38 100644
--- a/_articles/ja/building-community.md
+++ b/_articles/ja/building-community.md
@@ -54,7 +54,7 @@ related:
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   これまでに（技術）イベントに参加して、知り合いが誰もおらず、周りは皆グループになって古くからの友人同士のように話しているといった経験をしたことはありませんか？（中略）オープンソースプロジェクトにコントリビュートをしたいと思っているのに、なぜ、またはどのようにそのプロジェクトが立ち上がったのかがわからないという状況を想像してみて下さい。
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -198,7 +198,7 @@ CONTRIBUTING ファイルに、新しいコントリビューターに始め方
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
   プロジェクトのメンテナーとして、コントリビューターに対して敬意を払うのは非常に重要です。彼らはあなたの言うことを非常に個人的に捉えることがよくあります。
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/ja/starting-a-project.md b/_articles/ja/starting-a-project.md
index ebb9d017ee8..2161de540af 100644
--- a/_articles/ja/starting-a-project.md
+++ b/_articles/ja/starting-a-project.md
@@ -243,7 +243,7 @@ README に CONTRIBUTING ファイルへのリンクをすることで、より
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   メーリングリストのすべてのスレッドに関わるようにしましたし、模範的な行動を示し、人々に親切にし、イシューを真剣に捉え、何より助けになるようにしました。しばらくすると、人々は質問をするだけでなく、質問に答えたり、何よりも嬉しいことに私のスタイルを真似してくれたのです。
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/ko/building-community.md b/_articles/ko/building-community.md
index e25692a3ce1..02fe65a80d1 100644
--- a/_articles/ko/building-community.md
+++ b/_articles/ko/building-community.md
@@ -54,7 +54,7 @@ related:
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source”](http://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Sustainable Open Source”](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -199,7 +199,7 @@ CONTRIBUTING 파일에 새 기여자들이 시작할 방법을 자세히 설명
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
   As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way”](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Be Cordial or Be on Your Way”](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/ko/starting-a-project.md b/_articles/ko/starting-a-project.md
index 4581cd52132..ba3087e873e 100644
--- a/_articles/ko/starting-a-project.md
+++ b/_articles/ko/starting-a-project.md
@@ -250,7 +250,7 @@ README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 읽게 할
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source”](http://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source”](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
index 649d8addb41..0ec63d1514e 100644
--- a/_articles/ms/building-community.md
+++ b/_articles/ms/building-community.md
@@ -59,7 +59,7 @@ Mendorong penyumbang lain adalah pelaburan dalam diri anda juga. Apabila anda me
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Pernahkah anda ke acara (berteknologi) di mana anda tidak mengenali sesiapa, tetapi orang lain sepertinya berdiri dalam kumpulan dan berbual seperti rakan lama? (...) Sekarang bayangkan anda mahu menyumbang kepada projek sumber terbuka, tetapi anda tidak melihat mengapa atau bagaimana ini berlaku.
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -203,7 +203,7 @@ Tugas anda sebagai penyelenggara adalah untuk memastikan situasi ini tidak menin
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
  Sebagai penyelenggara projek, sangat penting untuk menghormati penyumbang anda. Mereka sering mengambil apa yang anda katakan secara peribadi.
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/ms/starting-a-project.md b/_articles/ms/starting-a-project.md
index c501437da9b..38a3a5e0ab7 100644
--- a/_articles/ms/starting-a-project.md
+++ b/_articles/ms/starting-a-project.md
@@ -249,7 +249,7 @@ Sama ada dokumentasi rasmi atau e-mel biasa, gaya penulisan anda adalah sebahagi
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Saya cuba terlibat dengan setiap urutan dalam senarai mel, dan menunjukkan tingkah laku teladan, bersikap baik kepada orang lain, memandang serius masalah mereka dan berusaha untuk membantu secara keseluruhan. Selepas beberapa ketika, orang-orang tidak hanya bertanya, tetapi membantu menjawabnya, dan dengan rasa gembira saya, mereka meniru gaya saya.
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/nl/building-community.md b/_articles/nl/building-community.md
index ac1e1e6d370..a40f0830d2f 100644
--- a/_articles/nl/building-community.md
+++ b/_articles/nl/building-community.md
@@ -43,8 +43,9 @@ Begin met uw documentatie:
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
   Bijdragen aan open source is voor sommigen gemakkelijker dan voor anderen. Er is veel angst om te worden uitgescholden omdat ze iets niet goed doen of gewoon niet passen. (...) Door bijdragers een plek te geven om bij te dragen met een zeer lage technische vaardigheid (documentatie, afwaardering van webinhoud, enz.), Kunt u aanzienlijk verminderen die zorgen.
-  
+
   _Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns._
+
   <p markdown="1" class="pquote-credit">
 — @mikeal, ["Een bijdrage leveren in moderne open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
   </p>
@@ -59,10 +60,11 @@ Andere bijdragers aanmoedigen is ook een investering in uzelf. Als u uw grootste
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Ben je ooit naar een (tech-) evenement geweest waar je niemand kende, maar iedereen leek in groepen te staan en te chatten als oude vrienden? (...) Stel je nu voor dat je wilt bijdragen aan een open source-project, maar je begrijpt niet waarom of hoe dit gebeurt.
-  
+
   _Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening._
+
   <p markdown="1" class="pquote-credit">
-— @janl, ["Duurzame open source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Duurzame open source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -123,8 +125,9 @@ Doe je best om een nultolerantiebeleid te voeren ten aanzien van dit soort mense
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
   De waarheid is dat het hebben van een ondersteunende gemeenschap de sleutel is. Ik zou dit werk nooit kunnen doen zonder de hulp van mijn collega's, vriendelijke internetvreemdelingen en spraakzame IRC-kanalen. (...) Neem geen genoegen met minder. Neem geen genoegen met klootzakken.
-  
+
   _The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes._
+
   <p markdown="1" class="pquote-credit">
 — @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
   </p>
@@ -189,8 +192,9 @@ Hoewel je misschien niet altijd iemand vindt om de oproep te beantwoorden, vergr
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
   \[Het is in uw belang\] om bijdragers te werven die plezier hebben en die in staat zijn om de dingen te doen die u niet bent. Houd je van coderen, maar beantwoord je geen problemen? Identificeer vervolgens die personen in uw gemeenschap die dat wel doen en laat ze het hebben.
-  
+
   _\[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it._
+
   <p markdown="1" class="pquote-credit">
 — @gr2m, ["Gastvrije gemeenschappen"](http://hood.ie/blog/welcoming-communities.html)
   </p>
@@ -213,10 +217,11 @@ Het is jouw taak als onderhouder om te voorkomen dat deze situaties escaleren. Z
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
   Als projectonderhouder is het uiterst belangrijk om respectvol te zijn voor uw bijdragers. Ze vatten wat je zegt vaak heel persoonlijk op.
-  
+
   _As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally._
+
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Wees hartelijk of ga op weg"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Wees hartelijk of ga op weg"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
@@ -241,8 +246,9 @@ In het kader van een proces voor het zoeken naar consensus, bespreken leden van
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
   Een deel van de reden waarom er geen stemsysteem bestaat voor Atom Issues is dat het Atom-team niet in alle gevallen een stemsysteem gaat volgen. Soms moeten we kiezen wat we vinden dat juist is, zelfs als het niet populair is. (...) Wat ik kan bieden en beloven te doen ... is dat het mijn taak is om naar de gemeenschap te luisteren.
-  
+
   _Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community._
+
   <p markdown="1" class="pquote-credit">
 — @lee-dohm on [Atom's besluitvormingsproces](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
   </p>
@@ -269,8 +275,9 @@ Als een gesprek duidelijk nergens heen gaat, er geen duidelijke acties kunnen wo
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
   Een draad naar bruikbaarheid leiden zonder opdringerig te zijn, is een kunst. Het zal niet werken om mensen simpelweg te vermanen om te stoppen met het verspillen van hun tijd, of om hen te vragen niet te posten tenzij ze iets constructiefs te melden hebben. (...) In plaats daarvan moet je voorwaarden stellen voor verdere vooruitgang: geef mensen een route, een pad om te volgen dat leidt tot de resultaten die je wilt, maar zonder dat het lijkt alsof je gedrag dicteert.
-  
+
   _Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct._
+
   <p markdown="1" class="pquote-credit">
 — @kfogel, [_OSS Produceren_](https://producingoss.com/en/producingoss.html#common-pitfalls)
   </p>
diff --git a/_articles/nl/starting-a-project.md b/_articles/nl/starting-a-project.md
index 2fa10f93d1d..3d76a165378 100644
--- a/_articles/nl/starting-a-project.md
+++ b/_articles/nl/starting-a-project.md
@@ -33,8 +33,9 @@ _Vrije software (Free software)_ verwijst naar dezelfde reeks projecten als _ope
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
   Een van de meest lonende ervaringen die ik krijg bij het gebruiken van en samenwerken aan open source, komt voort uit de relaties die ik opbouw met andere ontwikkelaars die met veel van dezelfde problemen worden geconfronteerd als ik.
-  
+
   _One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am._
+
   <p markdown="1" class="pquote-credit">
 — @kentcdodds, ["Het was geweldig om in Open Source te komen"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
   </p>
@@ -79,8 +80,9 @@ Als het je enige doel is om met je werk te pronken, wil je misschien niet eens b
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
   Op een gegeven moment heb ik een aangepaste UIAlertView gemaakt die ik gebruikte ... en ik besloot het open source te maken. Dus ik heb het aangepast om het dynamischer te maken en het naar GitHub geüpload. Ik schreef ook mijn eerste documentatie waarin ik aan andere ontwikkelaars uitlegde hoe ze het voor hun projecten konden gebruiken. Waarschijnlijk heeft niemand het ooit gebruikt omdat het een eenvoudig project was, maar ik voelde me goed over mijn bijdrage.
-  
+
   _At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution._
+
   <p markdown="1" class="pquote-credit">
 — @mavris, ["Zelf onderwezen softwareontwikkelaars: waarom open source belangrijk voor ons is"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
   </p>
@@ -97,8 +99,9 @@ Als u een specifiek budget of personeel nodig heeft voor promotie, operaties en
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
   Als u begint met het openen van het project, is het belangrijk om ervoor te zorgen dat uw beheerprocessen rekening houden met de bijdragen en capaciteiten van de gemeenschap rond uw project. Wees niet bang om bijdragers die niet in uw bedrijf werkzaam zijn, te betrekken bij de belangrijkste aspecten van het project, vooral als ze regelmatig bijdragen.
-  
+
   _As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors._
+
   <p markdown="1" class="pquote-credit">
 — @captainsafia, ["Dus je wilt een project openen, hè?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
   </p>
@@ -157,8 +160,9 @@ U kunt uw README gebruiken om andere vragen te beantwoorden, zoals hoe u omgaat
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
   Betere documentatie betekent meer gebruikers, minder ondersteuningsverzoeken en meer bijdragers. (...) Onthoud dat u niet uw lezers bent. Er zijn mensen die misschien naar een project komen die totaal andere ervaringen hebben.
-  
+
   _Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences._
+
   <p markdown="1" class="pquote-credit">
 — @tracymakes, ["Schrijven zodat uw woorden worden gelezen (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
   </p>
@@ -205,8 +209,9 @@ Link naar uw BIJDRAGEN-bestand vanuit uw README, zodat meer mensen het kunnen zi
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
   We hebben allemaal ervaringen gehad waarbij we te maken kregen met wat waarschijnlijk misbruik was, hetzij als onderhouder die probeerde uit te leggen waarom iets op een bepaalde manier moest zijn, of als gebruiker ... die een simpele vraag stelde. (...) Een gedragscode wordt een gemakkelijk te raadplegen en koppelbaar document dat aangeeft dat uw team constructief discours zeer serieus neemt.
-  
-  _We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously._
+
+  _We've all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously._
+
   <p markdown="1" class="pquote-credit">
 — @mlynch, ["Open Source een gelukkiger plek maken"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
   </p>
@@ -258,10 +263,11 @@ Of het nu gaat om officiële documentatie of een informele e-mail, uw schrijfsti
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Ik probeerde betrokken te zijn bij elke thread op de mailinglijst en voorbeeldig gedrag te tonen, aardig te zijn tegen mensen, hun problemen serieus te nemen en in het algemeen behulpzaam te zijn. Na een tijdje bleven mensen rondhangen om niet alleen vragen te stellen, maar ook om te helpen met het beantwoorden, en tot mijn grote vreugde bootsten ze mijn stijl na.
-  
+
   _I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style._
+
   <p markdown="1" class="pquote-credit">
-— @janl op [CouchDB](https://github.com/apache/couchdb), ["Duurzaam open source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl op [CouchDB](https://github.com/apache/couchdb), ["Duurzaam open source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/pl/building-community.md b/_articles/pl/building-community.md
index 6ab4f50f7f3..743d5618be9 100644
--- a/_articles/pl/building-community.md
+++ b/_articles/pl/building-community.md
@@ -59,7 +59,7 @@ Zachęcanie innych współpracowników to także inwestycja w ciebie. Gdy umożl
   Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
   </i>
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -211,7 +211,7 @@ Twoim zadaniem jako opiekuna jest zapobieganie eskalacji tych sytuacji. Nawet je
   As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
   </i>
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/pl/starting-a-project.md b/_articles/pl/starting-a-project.md
index ff508f571d5..72bba217ab1 100644
--- a/_articles/pl/starting-a-project.md
+++ b/_articles/pl/starting-a-project.md
@@ -255,7 +255,7 @@ Niezależnie od tego, czy jest to oficjalna dokumentacja, czy zwykły e-mail, st
   I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
   </i>
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/pt/building-community.md b/_articles/pt/building-community.md
index eb80725f447..d7c706f7ed6 100644
--- a/_articles/pt/building-community.md
+++ b/_articles/pt/building-community.md
@@ -54,7 +54,7 @@ Encorajar outros contribuidores é, também, um investimento em si mesmo. Quando
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Você alguma vez já esteve presente em um evento (de tecnologia), onde não conhecia ninguém, porém o restante das pessoas parecia se reunir em grupos e batiam papo como velhos amigos? (...) Agora imagine que você quer contribuir em um projeto open source, mas não consegue enxergar por que ou como isso está acontecendo.
   <p markdown="1" class="pquote-credit">
-  — @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  — @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -196,7 +196,7 @@ Seu trabalho como um mantenedor é prevenir que tais situações cresçam, escal
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
   Como um mantenedor de projeto, é extremamente importante ser respeitoso para com seus contribuidores. Eles frequentemente levam o que você fala para o lado pessoal.
   <p markdown="1" class="pquote-credit">
-  — @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+  — @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index 9b02b69aa57..501f358de2b 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -250,7 +250,7 @@ Quer seja documentação oficial ou um email casual, seu estilo de escrita é pa
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Eu procurei estar envolvido com todas as threads na lista de emails e mostrar comportamento exemplar, sendo legal com as pessoas, levando seus problemas a sério e tentando ser útil de um modo geral. Após um tempo, as pessoas permaneceram não somente para fazer questionamentos, mas para ajudar com as respostas também, e, para minha completa alegria, elas imitaram o meu estilo.
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/ro/building-community.md b/_articles/ro/building-community.md
index e558e2591d8..e62f141234f 100644
--- a/_articles/ro/building-community.md
+++ b/_articles/ro/building-community.md
@@ -72,7 +72,7 @@ Majoritatea contributorilor la sursă deschisă sunt „contributori ocazionali
     </em>
   </p>
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -248,7 +248,7 @@ Slujba ta în calitate de întreținător este să ferești aceste situații de
     </em>
   </p>
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/ro/starting-a-project.md b/_articles/ro/starting-a-project.md
index 9565d1dd22d..c3060ede64a 100644
--- a/_articles/ro/starting-a-project.md
+++ b/_articles/ro/starting-a-project.md
@@ -300,7 +300,7 @@ Fie că este vorba de documentație oficială sau de un email obișnuit, stilul
     </em>
   </p>
   <p markdown="1" class="pquote-credit">
-— @janl despre [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl despre [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/starting-a-project.md b/_articles/starting-a-project.md
index dac82be8178..1ace069082f 100644
--- a/_articles/starting-a-project.md
+++ b/_articles/starting-a-project.md
@@ -249,7 +249,7 @@ Whether it's official documentation or a casual email, your writing style is par
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/ta/building-community.md b/_articles/ta/building-community.md
index 63a8127852c..3cf7b27a710 100644
--- a/_articles/ta/building-community.md
+++ b/_articles/ta/building-community.md
@@ -54,7 +54,7 @@ related:
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   நீங்கள் யாரையும் தெரியாத இடத்தில் (தொழில்நுட்ப-) நிகழ்வில் எப்போதாவது இருந்திருக்கிறீர்களா, ஆனால் எல்லோரும் குழுக்களில் நின்றுக்கொண்டு பழைய நண்பர்களைப் போல் அரட்டை அடிக்கிறார்களா? (...) Nஇப்போது நீங்கள் ஒரு திறந்த மூல திட்டத்தில் பங்களிப்பு செய்ய விரும்புகிறீர்கள் என்று கற்பனை செய்யுங்கள், ஆனால் இது ஏன் அல்லது எப்படி நடக்கிறது என்பதை நீங்கள் பார்க்கவில்லை.
   <p markdown="1" class="pquote-credit">
-— @janl, ["நிலையான திறந்த மூலம்"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["நிலையான திறந்த மூலம்"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -198,7 +198,7 @@ related:
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
   ஒரு திட்டம் பராமரிப்பாளராக, உங்களுக்கு பங்களிப்பவர்களுக்கு மரியாதை கொடுத்தல் மிகவும் முக்கியம். அவர்கள் அடிக்கடி நீங்கள் தனிப்பட்ட முறையில் என்ன சொல்கிறீர்கள் என்பதை எடுத்துக்கொள்கிறார்கள்.
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["உள்ளன்புள்ள அல்லது தனிவழியாக இருத்தல்"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["உள்ளன்புள்ள அல்லது தனிவழியாக இருத்தல்"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/ta/starting-a-project.md b/_articles/ta/starting-a-project.md
index 54ab9b8cdf9..04b33e646a2 100644
--- a/_articles/ta/starting-a-project.md
+++ b/_articles/ta/starting-a-project.md
@@ -250,7 +250,7 @@ README கள் உங்கள் திட்டத்தை எவ்வா
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   நான் மின்னஞ்சல் பட்டியலிலுள்ள ஒவ்வொரு பிரியிலும் ஈடுபட முயன்றேன், மாதிரியான நடத்தைகளை காட்டுவது, மக்களிடம் பரிவாக இருப்பது, அவர்களின் பிரச்சினைகளை தீவிரமாக எடுத்துக் கொண்டு, ஒட்டுமொத்தமாக உதவ முயற்சித்தேன். சிறிது காலத்திற்கு பிறகு, மக்கள் கேள்விகளை மட்டும் கேட்க மாட்டார்கள், ஆனால் பதிலுடன் உதவி செய்வார்கள், நான் முழுதாக மகிழும் அளவிற்கு, என் பாணியை நையாண்டி செய்வார்கள்.
   <p markdown="1" class="pquote-credit">
-— @janl [கவுச்டிபி](https://github.com/apache/couchdb), ["நிலையான திறந்த மூலம்"](https://writing.jan.io/2015/11/20/sustainable-open-source.html) பற்றி
+— @janl [கவுச்டிபி](https://github.com/apache/couchdb), ["நிலையான திறந்த மூலம்"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html) பற்றி
   </p>
 </aside>
 
diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md
index 63fc0b6431c..27a71fc056a 100644
--- a/_articles/tr/building-community.md
+++ b/_articles/tr/building-community.md
@@ -59,7 +59,7 @@ Diğer katılımcıları teşvik etmek kendinize yapılan bir yatırımdır. En
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Hiç kimseyi tanımadığınız (teknoloji) bir etkinliğe katıldınız mı, ama diğerleri gruplarda durup eski arkadaşlar gibi sohbet ettiler mi? (...) Şimdi açık kaynaklı bir projeye katkıda bulunmak istediğinizi hayal edin, ancak bunun neden veya nasıl olduğunu görmüyorsunuz.
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Sürdürülebilir Açık Kaynak"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -203,7 +203,7 @@ Bir proje sorumlusu olarak işiniz, bu durumların tırmanmasını önlemektir.
   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/kennethreitz?s=180">
   Bir proje sorumlusu olarak, katılımcılarınıza saygılı olmak son derece önemlidir. Sık sık söylediklerinizi kişisel olarak alırlar.
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index 63621017f3d..a466eb48bd2 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -249,7 +249,7 @@ Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici b
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.
   <p markdown="1" class="pquote-credit">
-— [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/zh-hans/building-community.md b/_articles/zh-hans/building-community.md
index 26ffdd1fba7..00e8961b2fa 100644
--- a/_articles/zh-hans/building-community.md
+++ b/_articles/zh-hans/building-community.md
@@ -56,7 +56,7 @@ redirect_from: /zh-cn/building-community/
   你是否参加过一个（技术）活动，你不认识在场的人，但是似乎每个人站在一个小组里像老朋友一样聊天？（。。。）现在想象下你想为一个开源项目做贡献，但是你不知道为什么或者这个是如何发生的。
 
   <p markdown="1" class="pquote-credit">
-— @janl, ["让开源可持续发展"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["让开源可持续发展"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -203,7 +203,7 @@ redirect_from: /zh-cn/building-community/
   作为一名维护者，尊重你们的贡献者非常重要。他们经常处理一些你们描述亲切的事情。
 
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["保持和善，要么滚蛋"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["保持和善，要么滚蛋"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md
index 94817b6a085..897a26d9232 100644
--- a/_articles/zh-hans/starting-a-project.md
+++ b/_articles/zh-hans/starting-a-project.md
@@ -251,7 +251,7 @@ redirect_from: /zh-cn/starting-a-project/
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   我尝试处理每一个细节，包括：处理邮件，展示示例，友好待人，认真处理大家的issues以及试图帮助到大家。经过一段时间后，大家可能不再是只问问题，还会帮助我解决其他人的疑问以及给我喜悦，他们模仿我的风格。
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
diff --git a/_articles/zh-hant/building-community.md b/_articles/zh-hant/building-community.md
index ac2fd953bff..94bc30da78a 100644
--- a/_articles/zh-hant/building-community.md
+++ b/_articles/zh-hant/building-community.md
@@ -56,7 +56,7 @@ redirect_from: /zh-tw/building-community/
   你是否參加過一個（技術）活動，你不認識在場的人，但似乎每個人都在自己的小組裡像老朋友一樣聊天？（…）現在想像，你想為一個開源專案做貢獻，但是你不知道為什麼這樣是辦得到的。
 
   <p markdown="1" class="pquote-credit">
-— @janl, ["持續發展開源"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["持續發展開源"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -201,7 +201,7 @@ redirect_from: /zh-tw/building-community/
   作為一名維護者，尊重你們的貢獻者是一件重要的事。他們經常會感情用事的去看待你的意見。
 
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["保持和善，要麼滾蛋"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["保持和善，要麼滾蛋"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/zh-hant/starting-a-project.md b/_articles/zh-hant/starting-a-project.md
index cb4743815fd..ca4a49e897b 100644
--- a/_articles/zh-hant/starting-a-project.md
+++ b/_articles/zh-hant/starting-a-project.md
@@ -251,7 +251,7 @@ redirect_from: /zh-tw/starting-a-project/
   <img src="https://avatars0.githubusercontent.com/u/11321?v=3&s=460" class="pquote-avatar" alt="avatar">
   我嘗試處理每一個細節，包括：處理郵件，展示示例，友好待人，認真處理大家的issues以及試圖幫助到大家。經過一段時間後，大家可能不再是只問問題，還會幫助我解決其他人的疑問以及給我喜悅，他們模仿我的風格。
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 

From 8dba19063bf73ae97121879a02ed54b14cfc7f39 Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Wed, 16 Dec 2020 09:48:15 +0000
Subject: [PATCH 107/749] Bump html-proofer from 3.17.4 to 3.18.0

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.17.4 to 3.18.0.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.17.4...v3.18.0)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index a8ed8fb2ecf..bd663a55509 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -84,7 +84,7 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.17.4)
+    html-proofer (3.18.0)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)

From 2d0398e2b1dfebc9b65d555ac0112db56219cb19 Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Wed, 16 Dec 2020 19:45:09 +0000
Subject: [PATCH 108/749] Bump html-proofer from 3.18.0 to 3.18.1

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.18.0 to 3.18.1.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.18.0...v3.18.1)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index bd663a55509..d0cf4ce650c 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -84,7 +84,7 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.18.0)
+    html-proofer (3.18.1)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)

From 00cc7a1353b74dd7a1a3ab2667d5baf7a910a89c Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Thu, 17 Dec 2020 16:39:30 +0000
Subject: [PATCH 109/749] Bump html-proofer from 3.18.1 to 3.18.2

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.18.1 to 3.18.2.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.18.1...v3.18.2)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index d0cf4ce650c..1712c1d4644 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -84,7 +84,7 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.18.1)
+    html-proofer (3.18.2)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)

From ecc615d00c5d676a3f3399ad40c0a57d490a3220 Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Thu, 17 Dec 2020 17:13:03 +0000
Subject: [PATCH 110/749] script/html-proofer: ignore Twitter failures.

They aren't actually failures.
---
 script/html-proofer | 1 +
 1 file changed, 1 insertion(+)

diff --git a/script/html-proofer b/script/html-proofer
index c1ed8bf31c9..0aecc9353ac 100755
--- a/script/html-proofer
+++ b/script/html-proofer
@@ -7,6 +7,7 @@ url_ignores = [
   "https://okdistribute.xyz/post/okf-de",
   "https://www.drupal.org/community-initiatives/drupal-core/usability",
   "https://scripts.sil.org/ofl",
+  %r{^https?://twitter\.com/},
 ]
 
 HTMLProofer::Runner.new(

From ae00f93beb600190b7e008b37b675b5165779fb4 Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Mon, 21 Dec 2020 02:29:53 +0000
Subject: [PATCH 111/749] Bump rake from 13.0.1 to 13.0.3

Bumps [rake](https://github.com/ruby/rake) from 13.0.1 to 13.0.3.
- [Release notes](https://github.com/ruby/rake/releases)
- [Changelog](https://github.com/ruby/rake/blob/master/History.rdoc)
- [Commits](https://github.com/ruby/rake/compare/v13.0.1...v13.0.3)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 1712c1d4644..587467a9671 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -229,7 +229,7 @@ GEM
       forwardable-extended (~> 2.6)
     public_suffix (3.1.1)
     rainbow (3.0.0)
-    rake (13.0.1)
+    rake (13.0.3)
     rb-fsevent (0.10.4)
     rb-inotify (0.10.1)
       ffi (~> 1.0)

From ef14904ca5f1c2b420f019703efc019c34c467e7 Mon Sep 17 00:00:00 2001
From: Denise Yu <deniseyu@github.com>
Date: Tue, 22 Dec 2020 11:14:07 -0500
Subject: [PATCH 112/749] Remove Google Analytics

---
 assets/js/ga.js    | 7 -------
 assets/js/index.js | 1 -
 2 files changed, 8 deletions(-)
 delete mode 100644 assets/js/ga.js

diff --git a/assets/js/ga.js b/assets/js/ga.js
deleted file mode 100644
index 12baffec2ec..00000000000
--- a/assets/js/ga.js
+++ /dev/null
@@ -1,7 +0,0 @@
-(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
-(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
-m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
-})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
-
-ga('create', 'UA-3769691-72', 'auto');
-ga('send', 'pageview');
diff --git a/assets/js/index.js b/assets/js/index.js
index 9955cde1e58..63fa0fcdddf 100644
--- a/assets/js/index.js
+++ b/assets/js/index.js
@@ -3,7 +3,6 @@
 
 {% include_relative jquery.min.js %}
 {% include_relative anchor.min.js %}
-{% include_relative ga.js %}
 {% include_relative toc.js %}
 {% include_relative locale.js %}
 

From 47c05c4ec1c442fd58aa8133afe1828803f3870a Mon Sep 17 00:00:00 2001
From: Gabriel Santana <gabriel.gsantana7@gmail.com>
Date: Wed, 23 Dec 2020 12:46:25 -0300
Subject: [PATCH 113/749] Add missing comma on how to contribute article

---
 _articles/pt/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md
index 81f16203699..3cea68f7a19 100644
--- a/_articles/pt/how-to-contribute.md
+++ b/_articles/pt/how-to-contribute.md
@@ -30,7 +30,7 @@ Seja codificando, desenhando interface do usuário, desenhando gráfico, escreve
 
 ### Encontre pessoas que estão interessadas em coisas parecidas
 
-Projetos open source com comunidades calorosas e acolhedoras mantêm as pessoas voltando por anos. Muitas pessoas formam amizades duradouras através da participação em open source, seja em reuniões em conferências ou conversas online sobre burritos.
+Projetos open source com comunidades calorosas e acolhedoras mantêm as pessoas voltando por anos. Muitas pessoas formam amizades duradouras através da participação em open source, seja em reuniões, em conferências ou conversas online sobre burritos.
 
 ### Encontre mentores e ensine outras pessoas
 

From 1a8311826804c1710c77ec95c460d68f39fe585a Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Mon, 4 Jan 2021 09:17:09 +0000
Subject: [PATCH 114/749] Bump nokogiri from 1.10.10 to 1.11.0

Bumps [nokogiri](https://github.com/sparklemotion/nokogiri) from 1.10.10 to 1.11.0.
- [Release notes](https://github.com/sparklemotion/nokogiri/releases)
- [Changelog](https://github.com/sparklemotion/nokogiri/blob/master/CHANGELOG.md)
- [Commits](https://github.com/sparklemotion/nokogiri/compare/v1.10.10...v1.11.0)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 587467a9671..d001520d62c 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -210,15 +210,16 @@ GEM
       rb-fsevent (~> 0.10, >= 0.10.3)
       rb-inotify (~> 0.9, >= 0.9.10)
     mercenary (0.3.6)
-    mini_portile2 (2.4.0)
+    mini_portile2 (2.5.0)
     minima (2.5.1)
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
     minitest (5.14.2)
     multipart-post (2.1.1)
-    nokogiri (1.10.10)
-      mini_portile2 (~> 2.4.0)
+    nokogiri (1.11.0)
+      mini_portile2 (~> 2.5.0)
+      racc (~> 1.4)
     nokogumbo (2.0.4)
       nokogiri (~> 1.8, >= 1.8.4)
     octokit (4.18.0)
@@ -228,6 +229,7 @@ GEM
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
     public_suffix (3.1.1)
+    racc (1.5.2)
     rainbow (3.0.0)
     rake (13.0.3)
     rb-fsevent (0.10.4)

From 286c3c445313a96bae443be45a12cb0c8e10e625 Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Mon, 4 Jan 2021 09:17:48 +0000
Subject: [PATCH 115/749] Bump html-proofer from 3.18.2 to 3.18.5

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.18.2 to 3.18.5.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.18.2...v3.18.5)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 587467a9671..7692967d03e 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -28,7 +28,7 @@ GEM
     execjs (2.7.0)
     faraday (1.0.1)
       multipart-post (>= 1.2, < 3)
-    ffi (1.13.1)
+    ffi (1.14.2)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
     github-pages (209)
@@ -84,7 +84,7 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.18.2)
+    html-proofer (3.18.5)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)
@@ -210,15 +210,16 @@ GEM
       rb-fsevent (~> 0.10, >= 0.10.3)
       rb-inotify (~> 0.9, >= 0.9.10)
     mercenary (0.3.6)
-    mini_portile2 (2.4.0)
+    mini_portile2 (2.5.0)
     minima (2.5.1)
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
     minitest (5.14.2)
     multipart-post (2.1.1)
-    nokogiri (1.10.10)
-      mini_portile2 (~> 2.4.0)
+    nokogiri (1.11.0)
+      mini_portile2 (~> 2.5.0)
+      racc (~> 1.4)
     nokogumbo (2.0.4)
       nokogiri (~> 1.8, >= 1.8.4)
     octokit (4.18.0)
@@ -228,6 +229,7 @@ GEM
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
     public_suffix (3.1.1)
+    racc (1.5.2)
     rainbow (3.0.0)
     rake (13.0.3)
     rb-fsevent (0.10.4)

From 96ce35605e22003b035ffa6c976e8e464fd40221 Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Fri, 15 Jan 2021 19:26:12 +0000
Subject: [PATCH 116/749] Create Dependabot config file

---
 .github/dependabot.yml | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 .github/dependabot.yml

diff --git a/.github/dependabot.yml b/.github/dependabot.yml
new file mode 100644
index 00000000000..449976a6090
--- /dev/null
+++ b/.github/dependabot.yml
@@ -0,0 +1,22 @@
+version: 2
+updates:
+- package-ecosystem: bundler
+  directory: "/"
+  schedule:
+    interval: daily
+    time: "10:00"
+    timezone: Europe/Vienna
+  pull-request-branch-name:
+    separator: "-"
+  open-pull-requests-limit: 99
+  rebase-strategy: disabled
+- package-ecosystem: npm
+  directory: "/"
+  schedule:
+    interval: daily
+    time: "10:00"
+    timezone: Europe/Vienna
+  pull-request-branch-name:
+    separator: "-"
+  open-pull-requests-limit: 99
+  rebase-strategy: disabled

From a6f08dc158a202e0de2029323448313492a1a8a2 Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Fri, 22 Jan 2021 15:09:27 +0000
Subject: [PATCH 117/749] Bump github-pages from 209 to 210

Bumps [github-pages](https://github.com/github/pages-gem) from 209 to 210.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v209...v210)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 34 +++++++++++++++++++---------------
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 7692967d03e..19ef9b5bbd9 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (6.0.3.3)
+    activesupport (6.0.3.4)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
@@ -16,8 +16,8 @@ GEM
     colorator (1.1.0)
     commonmarker (0.17.13)
       ruby-enum (~> 0.5)
-    concurrent-ruby (1.1.7)
-    dnsruby (1.61.4)
+    concurrent-ruby (1.1.8)
+    dnsruby (1.61.5)
       simpleidn (~> 0.1)
     em-websocket (0.5.2)
       eventmachine (>= 0.12.9)
@@ -26,12 +26,15 @@ GEM
       ffi (>= 1.3.0)
     eventmachine (1.2.7)
     execjs (2.7.0)
-    faraday (1.0.1)
+    faraday (1.3.0)
+      faraday-net_http (~> 1.0)
       multipart-post (>= 1.2, < 3)
+      ruby2_keywords
+    faraday-net_http (1.0.1)
     ffi (1.14.2)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (209)
+    github-pages (210)
       github-pages-health-check (= 1.16.1)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
@@ -49,7 +52,7 @@ GEM
       jekyll-relative-links (= 0.6.1)
       jekyll-remote-theme (= 0.4.2)
       jekyll-sass-converter (= 1.5.2)
-      jekyll-seo-tag (= 2.6.1)
+      jekyll-seo-tag (= 2.7.1)
       jekyll-sitemap (= 1.4.0)
       jekyll-swiss (= 1.0.0)
       jekyll-theme-architect (= 0.1.1)
@@ -148,8 +151,8 @@ GEM
       rubyzip (>= 1.3.0, < 3.0)
     jekyll-sass-converter (1.5.2)
       sass (~> 3.4)
-    jekyll-seo-tag (2.6.1)
-      jekyll (>= 3.3, < 5.0)
+    jekyll-seo-tag (2.7.1)
+      jekyll (>= 3.8, < 5.0)
     jekyll-sitemap (1.4.0)
       jekyll (>= 3.7, < 5.0)
     jekyll-swiss (1.0.0)
@@ -206,7 +209,7 @@ GEM
     kramdown-parser-gfm (1.1.0)
       kramdown (~> 2.0)
     liquid (4.0.3)
-    listen (3.2.1)
+    listen (3.4.1)
       rb-fsevent (~> 0.10, >= 0.10.3)
       rb-inotify (~> 0.9, >= 0.9.10)
     mercenary (0.3.6)
@@ -215,14 +218,14 @@ GEM
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
-    minitest (5.14.2)
+    minitest (5.14.3)
     multipart-post (2.1.1)
-    nokogiri (1.11.0)
+    nokogiri (1.11.1)
       mini_portile2 (~> 2.5.0)
       racc (~> 1.4)
     nokogumbo (2.0.4)
       nokogiri (~> 1.8, >= 1.8.4)
-    octokit (4.18.0)
+    octokit (4.20.0)
       faraday (>= 0.9)
       sawyer (~> 0.8.0, >= 0.5.3)
     parallel (1.20.1)
@@ -239,6 +242,7 @@ GEM
     rouge (3.23.0)
     ruby-enum (0.8.0)
       i18n
+    ruby2_keywords (0.0.4)
     rubyzip (2.3.0)
     safe_yaml (1.0.5)
     sass (3.7.4)
@@ -249,21 +253,21 @@ GEM
     sawyer (0.8.2)
       addressable (>= 2.3.5)
       faraday (> 0.8, < 2.0)
-    simpleidn (0.1.1)
+    simpleidn (0.2.1)
       unf (~> 0.1.4)
     terminal-table (1.8.0)
       unicode-display_width (~> 1.1, >= 1.1.1)
     thread_safe (0.3.6)
     typhoeus (1.4.0)
       ethon (>= 0.9.0)
-    tzinfo (1.2.7)
+    tzinfo (1.2.9)
       thread_safe (~> 0.1)
     unf (0.1.4)
       unf_ext
     unf_ext (0.0.7.7)
     unicode-display_width (1.7.0)
     yell (2.2.2)
-    zeitwerk (2.4.0)
+    zeitwerk (2.4.2)
 
 PLATFORMS
   ruby

From c19ec3845cc139c9e3cec63c73307b9021b8ba5a Mon Sep 17 00:00:00 2001
From: "dependabot-preview[bot]"
 <27856297+dependabot-preview[bot]@users.noreply.github.com>
Date: Tue, 26 Jan 2021 15:10:24 +0000
Subject: [PATCH 118/749] Bump github-pages from 210 to 211

Bumps [github-pages](https://github.com/github/pages-gem) from 210 to 211.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v210...v211)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
---
 Gemfile.lock | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 19ef9b5bbd9..86f0c164341 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -34,7 +34,7 @@ GEM
     ffi (1.14.2)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (210)
+    github-pages (211)
       github-pages-health-check (= 1.16.1)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
@@ -76,7 +76,7 @@ GEM
       mercenary (~> 0.3)
       minima (= 2.5.1)
       nokogiri (>= 1.10.4, < 2.0)
-      rouge (= 3.23.0)
+      rouge (= 3.26.0)
       terminal-table (~> 1.4)
     github-pages-health-check (1.16.1)
       addressable (~> 2.3)
@@ -239,7 +239,7 @@ GEM
     rb-inotify (0.10.1)
       ffi (~> 1.0)
     rexml (3.2.4)
-    rouge (3.23.0)
+    rouge (3.26.0)
     ruby-enum (0.8.0)
       i18n
     ruby2_keywords (0.0.4)

From f0e33a15748913cb1047e7376e6f7998bb18fbf1 Mon Sep 17 00:00:00 2001
From: Pichu Chen <pichubaby@gmail.com>
Date: Fri, 29 Jan 2021 11:46:50 +0800
Subject: [PATCH 119/749] Update building-community.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Minor change, fix type 文建 => 文件.
---
 _articles/zh-hant/building-community.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hant/building-community.md b/_articles/zh-hant/building-community.md
index 94bc30da78a..5d1e4f504d7 100644
--- a/_articles/zh-hant/building-community.md
+++ b/_articles/zh-hant/building-community.md
@@ -30,7 +30,7 @@ redirect_from: /zh-tw/building-community/
 * **讓大家很容易上手。** [一份好閱讀的 README](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/HEAD/github-open-source-guide-02.md#編寫readme)以及清晰的程式碼範例，讓大家很容易的上手。
 * **清楚的說明該如何貢獻**，使用[你的CONTRIBUTING file](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/HEAD/github-open-source-guide-02.md#編寫你的貢獻指南)並持續更新issues。
 
-在 [GitHub 2017 開源調查報告](http://opensourcesurvey.org/2017/)中指出，令人困惑或不完整的說明文件是開源使用者最大的困擾，好的說明文建會吸引人們與專案互動。總有一天，會有人開啟一個 issue 或 PR。盡量使用這些工具讓人們有機會朝漏斗的下方邁進。
+在 [GitHub 2017 開源調查報告](http://opensourcesurvey.org/2017/)中指出，令人困惑或不完整的說明文件是開源使用者最大的困擾，好的說明文件會吸引人們與專案互動。總有一天，會有人開啟一個 issue 或 PR。盡量使用這些工具讓人們有機會朝漏斗的下方邁進。
 
 * **當有人選擇了你們的專案，記得對他們表示謝意！** 因為可能只是一次不愉快的經歷，就足以讓一些人再也不想回來。
 * **及時回應。** 如果一個月都沒有回答他們的 issue，他們可能也早就忘記了你們的專案。

From 15098a64d308f549bd58b28a469b01fa069e1d6f Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 18 Feb 2021 09:04:35 +0000
Subject: [PATCH 120/749] Bump github-pages from 211 to 212

Bumps [github-pages](https://github.com/github/pages-gem) from 211 to 212.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v211...v212)

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 86f0c164341..1b27e90f6aa 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (6.0.3.4)
+    activesupport (6.0.3.5)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
@@ -34,8 +34,8 @@ GEM
     ffi (1.14.2)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (211)
-      github-pages-health-check (= 1.16.1)
+    github-pages (212)
+      github-pages-health-check (= 1.17.0)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
       jekyll-coffeescript (= 1.1.1)
@@ -78,11 +78,11 @@ GEM
       nokogiri (>= 1.10.4, < 2.0)
       rouge (= 3.26.0)
       terminal-table (~> 1.4)
-    github-pages-health-check (1.16.1)
+    github-pages-health-check (1.17.0)
       addressable (~> 2.3)
       dnsruby (~> 1.60)
       octokit (~> 4.0)
-      public_suffix (~> 3.0)
+      public_suffix (>= 2.0.2, < 5.0)
       typhoeus (~> 1.3)
     html-pipeline (2.14.0)
       activesupport (>= 2)
@@ -231,7 +231,7 @@ GEM
     parallel (1.20.1)
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
-    public_suffix (3.1.1)
+    public_suffix (4.0.6)
     racc (1.5.2)
     rainbow (3.0.0)
     rake (13.0.3)
@@ -240,7 +240,7 @@ GEM
       ffi (~> 1.0)
     rexml (3.2.4)
     rouge (3.26.0)
-    ruby-enum (0.8.0)
+    ruby-enum (0.9.0)
       i18n
     ruby2_keywords (0.0.4)
     rubyzip (2.3.0)

From 9dc82d540fc00e6f3ef2b6b7b56eb06051e121f0 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 22 Feb 2021 09:04:40 +0000
Subject: [PATCH 121/749] Bump html-proofer from 3.18.5 to 3.18.6

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.18.5 to 3.18.6.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.18.5...v3.18.6)

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 86f0c164341..3b97ba58567 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -87,7 +87,7 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.18.5)
+    html-proofer (3.18.6)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)

From ead79b71d10b9ab6fd2fabdad1ecbfa52ffcea03 Mon Sep 17 00:00:00 2001
From: Frazer Smith <43814140+Fdawgs@users.noreply.github.com>
Date: Wed, 24 Feb 2021 08:33:00 +0000
Subject: [PATCH 122/749] Add GitHub Actions to Dependabot config

Dependabot has the ability to keep GitHub Actions used in `.github/workflows` up to date.
See https://docs.github.com/en/github/administering-a-repository/keeping-your-actions-up-to-date-with-dependabot#example-dependabotyml-file-for-github-actions
---
 .github/dependabot.yml | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index 449976a6090..9417d2257f5 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -10,6 +10,16 @@ updates:
     separator: "-"
   open-pull-requests-limit: 99
   rebase-strategy: disabled
+- package-ecosystem: github-actions
+  directory: "/"
+  schedule:
+    interval: daily
+    time: "10:00"
+    timezone: Europe/Vienna
+  pull-request-branch-name:
+    separator: "-"
+  open-pull-requests-limit: 99
+  rebase-strategy: disabled
 - package-ecosystem: npm
   directory: "/"
   schedule:

From 4289f0685e5b9f1b561e5d521d72c85802d81590 Mon Sep 17 00:00:00 2001
From: Alexis THOMAS <ath0mas@users.noreply.github.com>
Date: Sun, 14 Feb 2021 19:14:32 +0100
Subject: [PATCH 123/749] Update french locale

---
 _data/locales/fr.yml | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/_data/locales/fr.yml b/_data/locales/fr.yml
index 919f1fba667..76cf2976556 100644
--- a/_data/locales/fr.yml
+++ b/_data/locales/fr.yml
@@ -4,21 +4,21 @@ fr:
     about: A propos
     contribute: Contribuer
   index:
-    lead: Les logiciels libres sont fait par des gens exactement comme vous. Apprennez comment lancer et développer votre projet.
-    opensourcefriday: C'est Vendredi ! Investissez quelques heures en contribuant aux logiciels que vous utilisez et aimez
+    lead: Les logiciels libres sont faits par des gens exactement comme vous. Apprennez comment lancer et développer votre projet.
+    opensourcefriday: C'est vendredi ! Investissez quelques heures en contribuant aux logiciels que vous utilisez et aimez
   article:
-    table_of_contents: Table des Matières
-    back_to_all_guides: Retour a tous les guides
-    related_guides: Guides Liés
+    table_of_contents: Table des matières
+    back_to_all_guides: Retour à tous les guides
+    related_guides: Guides liés
   footer:
     contribute:
       heading: Contribuer
-      description: Vous souhaitez faire une suggestion ? Ce contenu est libre. Aidez nous a l'améliorer.
+      description: Vous souhaitez faire une suggestion ? Ce contenu est libre. Aidez-nous à l'améliorer.
       button: Contribuer
     subscribe:
       heading: Restons en contact
       description: Soyez le premier à découvrir les dernières astuces et ressources concernant les logiciels libres avec GitHub.
-      label: Adresse Email
+      label: Adresse email
       button: S'abonner
     byline:
       # [code], [love], and [github] will be replaced by octicons

From 7ec8620bdeba6725495c108e059c47e96313a97a Mon Sep 17 00:00:00 2001
From: Alexis THOMAS <fr.alexisthomas@gmail.com>
Date: Sun, 14 Feb 2021 23:52:19 +0100
Subject: [PATCH 124/749] Wording in Front Matter for french articles

---
 _articles/fr/best-practices.md            | 4 ++--
 _articles/fr/code-of-conduct.md           | 2 +-
 _articles/fr/leadership-and-governance.md | 2 +-
 _articles/fr/legal.md                     | 2 +-
 _articles/fr/metrics.md                   | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/_articles/fr/best-practices.md b/_articles/fr/best-practices.md
index 3e5e4c64eae..bf106da764e 100644
--- a/_articles/fr/best-practices.md
+++ b/_articles/fr/best-practices.md
@@ -1,7 +1,7 @@
 ---
 lang: fr
-title: Bonnes Pratiques pour les Responsables
-description: Facilitez vous la vie en tant que responsable open source, de la documentation des processus à l'exploitation de votre communauté.
+title: Bonnes pratiques pour les responsables
+description: Facilitez-vous la vie en tant que responsable open source, de la documentation des processus à l'exploitation de votre communauté.
 class: best-practices
 order: 5
 image: /assets/images/cards/best-practices.png
diff --git a/_articles/fr/code-of-conduct.md b/_articles/fr/code-of-conduct.md
index 5dc103fd488..4726143d822 100644
--- a/_articles/fr/code-of-conduct.md
+++ b/_articles/fr/code-of-conduct.md
@@ -1,6 +1,6 @@
 ---
 lang: fr
-title: Votre Code de Conduite
+title: Votre code de conduite
 description: Faciliter un comportement communautaire sain et constructif en adoptant et en appliquant un code de conduite.
 class: coc
 order: 8
diff --git a/_articles/fr/leadership-and-governance.md b/_articles/fr/leadership-and-governance.md
index 35eb894925d..737da969ec0 100644
--- a/_articles/fr/leadership-and-governance.md
+++ b/_articles/fr/leadership-and-governance.md
@@ -1,6 +1,6 @@
 ---
 lang: fr
-title: Leadership et Gouvernance
+title: Leadership et gouvernance
 description: Les projets open source en croissance peuvent bénéficier de règles formelles pour prendre des décisions.
 class: leadership
 order: 6
diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index 8fba09379c4..84d83f5faa7 100644
--- a/_articles/fr/legal.md
+++ b/_articles/fr/legal.md
@@ -1,7 +1,7 @@
 ---
 lang: fr
 title: Le côté légal de l'Open Source
-description: Tout ce que vous avez jamais osé demandé sur le côté juridique de l'open source, et quelques autres.
+description: Tout ce que vous n'avez jamais osé demander sur le côté juridique de l'open source, et quelques autres.
 class: legal
 order: 10
 image: /assets/images/cards/legal.png
diff --git a/_articles/fr/metrics.md b/_articles/fr/metrics.md
index f5129cd1818..5eba8ca8186 100644
--- a/_articles/fr/metrics.md
+++ b/_articles/fr/metrics.md
@@ -1,6 +1,6 @@
 ---
 lang: fr
-title: Metriques Open Source
+title: Métriques Open Source
 description: Prendre des décisions éclairées pour aider votre projet open source à prospérer en mesurant et en suivant son succès.
 class: metrics
 order: 9

From 483e75b66624f9f3075749f4057c97d7334b46dd Mon Sep 17 00:00:00 2001
From: Alexis THOMAS <fr.alexisthomas@gmail.com>
Date: Mon, 15 Feb 2021 00:06:22 +0100
Subject: [PATCH 125/749] Review "Open Source" case in Front Matter for french

---
 _articles/fr/best-practices.md            | 2 +-
 _articles/fr/finding-users.md             | 2 +-
 _articles/fr/getting-paid.md              | 2 +-
 _articles/fr/how-to-contribute.md         | 2 +-
 _articles/fr/leadership-and-governance.md | 2 +-
 _articles/fr/legal.md                     | 2 +-
 _articles/fr/metrics.md                   | 2 +-
 _articles/fr/starting-a-project.md        | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/_articles/fr/best-practices.md b/_articles/fr/best-practices.md
index bf106da764e..25f17f923c6 100644
--- a/_articles/fr/best-practices.md
+++ b/_articles/fr/best-practices.md
@@ -1,7 +1,7 @@
 ---
 lang: fr
 title: Bonnes pratiques pour les responsables
-description: Facilitez-vous la vie en tant que responsable open source, de la documentation des processus à l'exploitation de votre communauté.
+description: Facilitez-vous la vie en tant que responsable Open Source, de la documentation des processus à l'exploitation de votre communauté.
 class: best-practices
 order: 5
 image: /assets/images/cards/best-practices.png
diff --git a/_articles/fr/finding-users.md b/_articles/fr/finding-users.md
index d73972951f6..8dcd4fdd539 100644
--- a/_articles/fr/finding-users.md
+++ b/_articles/fr/finding-users.md
@@ -1,7 +1,7 @@
 ---
 lang: fr
 title: Trouver des utilisateurs pour votre projet
-description: Aidez votre projet open source à se développer en le mettant entre les mains d'utilisateurs satisfaits.
+description: Aidez votre projet Open Source à se développer en le mettant entre les mains d'utilisateurs satisfaits.
 class: finding
 order: 3
 image: /assets/images/cards/finding.png
diff --git a/_articles/fr/getting-paid.md b/_articles/fr/getting-paid.md
index 7775c34ed98..4695e48695a 100644
--- a/_articles/fr/getting-paid.md
+++ b/_articles/fr/getting-paid.md
@@ -1,7 +1,7 @@
 ---
 lang: fr
 title: Etre payé pour faire de l'Open Source
-description: Soutenez votre travail en open source en obtenant un soutien financier pour votre temps ou votre projet.
+description: Soutenez votre travail en Open Source en obtenant un soutien financier pour votre temps ou votre projet.
 class: getting-paid
 order: 7
 image: /assets/images/cards/getting-paid.png
diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md
index 7ec90a96ee5..aa525528097 100644
--- a/_articles/fr/how-to-contribute.md
+++ b/_articles/fr/how-to-contribute.md
@@ -1,7 +1,7 @@
 ---
 lang: fr
 title: Comment contribuer à l'Open Source
-description: Vous voulez contribuer à l'open source ? Un guide pour faire des contributions open source, pour les débutants et pour les vétérans.
+description: Vous voulez contribuer à l'Open Source ? Un guide pour faire des contributions Open Source, pour les débutants et pour les vétérans.
 class: contribute
 order: 1
 image: /assets/images/cards/contribute.png
diff --git a/_articles/fr/leadership-and-governance.md b/_articles/fr/leadership-and-governance.md
index 737da969ec0..cf9f4cd9489 100644
--- a/_articles/fr/leadership-and-governance.md
+++ b/_articles/fr/leadership-and-governance.md
@@ -1,7 +1,7 @@
 ---
 lang: fr
 title: Leadership et gouvernance
-description: Les projets open source en croissance peuvent bénéficier de règles formelles pour prendre des décisions.
+description: Les projets Open Source en croissance peuvent bénéficier de règles formelles pour prendre des décisions.
 class: leadership
 order: 6
 image: /assets/images/cards/leadership.png
diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index 84d83f5faa7..7342d22995e 100644
--- a/_articles/fr/legal.md
+++ b/_articles/fr/legal.md
@@ -1,7 +1,7 @@
 ---
 lang: fr
 title: Le côté légal de l'Open Source
-description: Tout ce que vous n'avez jamais osé demander sur le côté juridique de l'open source, et quelques autres.
+description: Tout ce que vous n'avez jamais osé demander sur le côté juridique de l'Open Source, et quelques autres.
 class: legal
 order: 10
 image: /assets/images/cards/legal.png
diff --git a/_articles/fr/metrics.md b/_articles/fr/metrics.md
index 5eba8ca8186..b34030e1e65 100644
--- a/_articles/fr/metrics.md
+++ b/_articles/fr/metrics.md
@@ -1,7 +1,7 @@
 ---
 lang: fr
 title: Métriques Open Source
-description: Prendre des décisions éclairées pour aider votre projet open source à prospérer en mesurant et en suivant son succès.
+description: Prendre des décisions éclairées pour aider votre projet Open Source à prospérer en mesurant et en suivant son succès.
 class: metrics
 order: 9
 image: /assets/images/cards/metrics.png
diff --git a/_articles/fr/starting-a-project.md b/_articles/fr/starting-a-project.md
index f46c9dac4ff..24b40e13a61 100644
--- a/_articles/fr/starting-a-project.md
+++ b/_articles/fr/starting-a-project.md
@@ -1,7 +1,7 @@
 ---
 lang: fr
 title: Lancer un projet Open Source
-description: En savoir plus sur le monde de l'open source et préparez-vous à lancer votre propre projet.
+description: En savoir plus sur le monde de l'Open Source et préparez-vous à lancer votre propre projet.
 class: beginners
 order: 2
 image: /assets/images/cards/beginner.png

From 5f1c97818efa7a01517e112a0bb9886e3e103e80 Mon Sep 17 00:00:00 2001
From: Roberth <rialbellares@gmail.com>
Date: Thu, 25 Feb 2021 19:45:41 -0500
Subject: [PATCH 126/749] Fix some typos in Spanish translation

---
 _articles/es/how-to-contribute.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/es/how-to-contribute.md b/_articles/es/how-to-contribute.md
index bc8f64bb38c..18e7d119845 100644
--- a/_articles/es/how-to-contribute.md
+++ b/_articles/es/how-to-contribute.md
@@ -193,7 +193,7 @@ Finalmente, los proyectos de c&oacute;digo abierto utilizan las siguientes herra
 
 ¡Ahora que ya has descubierto c&oacute;mo funcionan los proyectos de c&oacute;digo abierto, es tiempo de encontrar un proyecto con el que contribuir!
 
-Si nunca antes contribuiste al c&oacute;digo abierto, acepta algunos consejos del presidente de los Estados Unidos, John F. Kennedy, quien una vez dijo, _"No preguntes qu&eacute; es lo que tu pa&iacute;s puede hacer por ti;, preg&uacute;ntate qu&eacute; es lo que t&uacute; puedes hacer por &eacute;l"_
+Si nunca antes contribuiste al c&oacute;digo abierto, acepta algunos consejos del presidente de los Estados Unidos, John F. Kennedy, quien una vez dijo, _"No preguntes qu&eacute; es lo que tu pa&iacute;s puede hacer por ti; preg&uacute;ntate qu&eacute; es lo que t&uacute; puedes hacer por &eacute;l"_
 
 Las contribuciones al c&oacute;digo abierto ocurren en todos los niveles a lo largo de los proyectos. No necesitas pensar demasiado cu&aacute;l ser&aacute; tu primera colaboraci&oacute;n, o c&oacute;mo se ver&aacute;.
 
@@ -474,7 +474,7 @@ Usualmente deber&iacute;as abrir un pull request en las siguientes situaciones:
 
 Un pull request no representa trabajo terminado. Usualmente es mejor abrir un pull request de forma temprana, de manera que otros puedan observar o dar retroalimentaci&oacute;n a tu progreso. Solo m&aacute;rcalo como "trabajo en proceso" (WIP por sus siglas en ingl&eacute;s, work in progress) en la l&iacute;nea del tema. Siempre puedes agregar m&aacute;s commits despu&eacute;s.
 
-Si el proyecto est&aacute; alojado en GITHUb, ac&aacute; te explicamos los pasos para enviar un pull request:
+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/).)
 * **[Crea una rama](https://guides.github.com/introduction/flow/)** para tus ediciones.
@@ -505,7 +505,7 @@ Si haces una llamada educada y todav&iacute;a nadie responde, es posible que nad
 
 Es com&uacute;n que te pidan hacer cambios a tu contribuci&oacute;n, ya sea una retroalimentaci&oacute;n sobre el alcance de tu idea, o cambios en tu c&oacute;digo.
 
-Cuando &aacute;lguien te pide cambios, comp&oacute;rtate de manera sensible, Se tomaron el tiempo necesario para revisar tu contribuci&oacute;n. Abrir un pull request y luego alejarse es de malos modales. Si no sabes c&oacute;mo hacer los cambios, investiga el problema, y luego pregunta por ayuda si la necesitas.
+Cuando alguien te pide cambios, comp&oacute;rtate de manera sensible, se tomaron el tiempo necesario para revisar tu contribuci&oacute;n. Abrir un pull request y luego alejarse es de malos modales. Si no sabes c&oacute;mo hacer los cambios, investiga el problema, y luego pregunta por ayuda si la necesitas.
 
 Si no tienes el tiempo para volver a trabajar en ese problema (por ejemplo, si la conversaci&oacute;n tuvo lugar durante meses, y tus circunstancias cambiaron), permite que el responsable lo sepa, de manera que no quede a la espera de una respuesta. Alguien puede sentirse complacido de hacerse cargo.
 

From 528b5ed56a251f274cfbc596346bae8d53f93728 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 9 Mar 2021 19:54:23 +0000
Subject: [PATCH 127/749] Bump actions/cache from v1 to v2.1.4

Bumps [actions/cache](https://github.com/actions/cache) from v1 to v2.1.4.
- [Release notes](https://github.com/actions/cache/releases)
- [Commits](https://github.com/actions/cache/compare/v1...26968a09c0ea4f3e233fdddbafd1166051a095f6)

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 401cc70771b..306ebe29798 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -17,7 +17,7 @@ jobs:
       uses: actions/setup-node@v1
 
     - name: Restore bundler cache
-      uses: actions/cache@v1
+      uses: actions/cache@v2.1.4
       with:
         path: vendor/gems
         key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}

From cb0c16de17a5058d18476a1d75ef99f525bada61 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 9 Mar 2021 19:54:24 +0000
Subject: [PATCH 128/749] Bump actions/checkout from v1 to v2.3.4

Bumps [actions/checkout](https://github.com/actions/checkout) from v1 to v2.3.4.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v1...5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f)

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 401cc70771b..5c2940eecf3 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -8,7 +8,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
     - name: Set up Git repository
-      uses: actions/checkout@v1
+      uses: actions/checkout@v2.3.4
 
     - name: Set up Ruby
       uses: actions/setup-ruby@v1

From 3189010cabfaa6c6b430eb345d612b2dca772ec4 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 9 Mar 2021 19:54:36 +0000
Subject: [PATCH 129/749] Bump actions/setup-node from v1 to v2.1.5

Bumps [actions/setup-node](https://github.com/actions/setup-node) from v1 to v2.1.5.
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/v1...46071b5c7a2e0c34e49c3cb8a0e792e86e18d5ea)

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 401cc70771b..6a391a626f7 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -14,7 +14,7 @@ jobs:
       uses: actions/setup-ruby@v1
 
     - name: Set up Node
-      uses: actions/setup-node@v1
+      uses: actions/setup-node@v2.1.5
 
     - name: Restore bundler cache
       uses: actions/cache@v1

From 0fd9c7358098c42cb113e627826247224e0bf85f Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 10 Mar 2021 09:05:42 +0000
Subject: [PATCH 130/749] Bump html-proofer from 3.18.6 to 3.18.8

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.18.6 to 3.18.8.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.18.6...v3.18.8)

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index ef99cafc9b8..42d5cd25d92 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -31,7 +31,7 @@ GEM
       multipart-post (>= 1.2, < 3)
       ruby2_keywords
     faraday-net_http (1.0.1)
-    ffi (1.14.2)
+    ffi (1.15.0)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
     github-pages (212)
@@ -87,7 +87,7 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.18.6)
+    html-proofer (3.18.8)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)

From 28335618e41ff73ddbdee6ba98d263143ec28b55 Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Wed, 10 Mar 2021 13:19:06 +0000
Subject: [PATCH 131/749] Update documentation

Make clear what the current procedures are for how we're running this
repository. None of these are proposed changes; they are updates based
on what we're already doing.
---
 CONTRIBUTING.md      | 12 +++++-------
 README.md            |  2 +-
 docs/translations.md |  4 ++--
 3 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index ae95d763e11..a58a16a23fd 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -18,11 +18,10 @@ We've put together the following guidelines to help you figure out where you can
 0. [Community](#community)
 
 ## Types of contributions we're looking for
+
 There are many ways you can directly contribute to the guides (in descending order of need):
 
 * Fix editorial inconsistencies or inaccuracies
-* Add stories, examples, or anecdotes that help illustrate a point
-* Revise language to be more approachable and friendly
 * [Translate guides into other languages](docs/translations.md)
 
 Interested in making a contribution? Read on!
@@ -40,11 +39,10 @@ Before we get started, here are a few things we expect from you (and that you sh
 
 If you'd like to contribute, start by searching through the [issues](https://github.com/github/opensource.guide/issues) and [pull requests](https://github.com/github/opensource.guide/pulls) to see whether someone else has raised a similar idea or question.
 
-If you don't see your idea listed, and you think it fits into the goals of this guide, do one of the following:
-* **If your contribution is minor,** such as a typo fix, open a pull request.
-* **If your contribution is major,** such as a new guide, start by opening an issue first. That way, other people can weigh in on the discussion before you do any work.
+If you don't see your idea listed, and you think it fits into the goals of this guide, open a pull request.
 
 ## Style guide
+
 If you're writing content, see the [style guide](./docs/styleguide.md) to help your prose match the rest of the guides.
 
 ## Setting up your environment
@@ -56,10 +54,10 @@ Once you have that set up, run:
     script/bootstrap
     script/server
 
-…and open http://localhost:4000 in your web browser.
+…and open <http://localhost:4000> in your web browser.
 
 ## Community
 
-Discussions about the Open Source Guides take place on this repository's [Issues](https://github.com/github/opensource.guide/issues) and [Pull Requests](https://github.com/github/opensource.guide/pulls) sections. Anybody is welcome to join these conversations. There is also a [mailing list](http://eepurl.com/cecpnT) for regular updates.
+Discussions about the Open Source Guides take place on this repository's [Issues](https://github.com/github/opensource.guide/issues) and [Pull Requests](https://github.com/github/opensource.guide/pulls) sections. Anybody is welcome to join these conversations.
 
 Wherever possible, do not take these conversations to private channels, including contacting the maintainers directly. Keeping communication public means everybody can benefit and learn from the conversation.
diff --git a/README.md b/README.md
index 5fbeac7ba24..df7704a20fc 100644
--- a/README.md
+++ b/README.md
@@ -7,7 +7,7 @@ Open Source Guides (https://opensource.guide/) are a collection of resources for
 ## Background
 Open Source Guides were created and are curated by GitHub, along with input from outside community reviewers, but they are not exclusive to GitHub products. One reason we started this project is because we felt that there weren't enough resources for people creating open source projects.
 
-Our goal is to aggregate community best practices, *not* what GitHub (or any other individual or entity) thinks is best. Therefore, we try to use examples and quotations from others to illustrate our points.
+Our goal was to aggregate community best practices, *not* what GitHub (or any other individual or entity) thinks is best. Therefore, we used examples and quotations from others to illustrate our points.
 
 ## Contributing
 
diff --git a/docs/translations.md b/docs/translations.md
index c964dcbd977..52364df202d 100644
--- a/docs/translations.md
+++ b/docs/translations.md
@@ -31,8 +31,8 @@ When tests find broken links, try to fix them across all translations. Ideally,
 
 ### Article updates
 
-We're collecting [tips](https://github.com/github/opensource.guide/issues/1119) on how to check if a translation should be updated to account for improvements made to the English source articles.
+Add the updated text in English to all translations to implicitly solicit pull requests to translate these strings.
 
 ### New articles
 
-New articles are rare! When we have one, we'll probably do [some form](https://github.com/github/opensource.guide/issues/1120) of a call for translations.
+We do not plan on ever adding any new articles.

From 20b8a67e5eb445fb72e973ff1a0b2835538fc352 Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Wed, 10 Mar 2021 13:41:14 +0000
Subject: [PATCH 132/749] getting-paid: add GitHub Sponsors reference

I've taken the same approach as Homebrew uses for our translations here
and added the English, non-translated string to the various articles so
readers can submit pull requests to update these translations.
---
 _articles/de/getting-paid.md      |  1 +
 _articles/es/getting-paid.md      |  1 +
 _articles/fr/getting-paid.md      |  1 +
 _articles/getting-paid.md         |  3 ++-
 _articles/hu/getting-paid.md      |  9 +++++----
 _articles/id/getting-paid.md      |  1 +
 _articles/ja/getting-paid.md      |  1 +
 _articles/ko/getting-paid.md      |  1 +
 _articles/ms/getting-paid.md      |  1 +
 _articles/nl/getting-paid.md      | 15 ++++++++++-----
 _articles/pl/getting-paid.md      |  1 +
 _articles/pt/getting-paid.md      |  3 ++-
 _articles/ro/getting-paid.md      |  5 +++--
 _articles/ta/getting-paid.md      |  1 +
 _articles/tr/getting-paid.md      |  1 +
 _articles/zh-hans/getting-paid.md |  1 +
 _articles/zh-hant/getting-paid.md |  1 +
 17 files changed, 34 insertions(+), 13 deletions(-)

diff --git a/_articles/de/getting-paid.md b/_articles/de/getting-paid.md
index aa061f71f05..fb4a9413aba 100644
--- a/_articles/de/getting-paid.md
+++ b/_articles/de/getting-paid.md
@@ -127,6 +127,7 @@ Aus einer großen Firma stammende Projekte, wie z.B. [Go](https://github.com/gol
 
 Außerdem können Sie versuchen, abhängig von Ihren persönlichen Umständen, selbstständig Geld zu sammeln, um Ihre Open-Source-Arbeit zu finanzieren, zum Beispiel:
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon finanzierte seine Arbeit an [Redux](https://github.com/reactjs/redux) mittels einer [Patreon-Crowdfunding-Kampagne](https://redux.js.org/)
 * @andrewgodwin finanzierte Arbeit an Djangos Schemamigrations [mittels einer Kickstarter-Kampagne](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
diff --git a/_articles/es/getting-paid.md b/_articles/es/getting-paid.md
index 74dd16a930f..873b8bc7d36 100644
--- a/_articles/es/getting-paid.md
+++ b/_articles/es/getting-paid.md
@@ -101,6 +101,7 @@ Proyectos que se originaron en una empresa grande, como [Go](https://github.com/
 
 Finalmente, dependiendo de tus circunstancias personales, puedes probar generar dinero de forma independiente para financiar tu trabajo de c&oacute;digo abierto. Por ejemplo:
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon financio su propio trabajo [Redux](https://github.com/reactjs/redux) a trav&eacute;s de [Patreon crowdfunding campaign](https://redux.js.org/)
 * @andrewgodwin financi&oacute; su trabajo de migraci&oacute;n de esquemas de Django [a trav&eacute;s de una campa&ntilde;a kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
diff --git a/_articles/fr/getting-paid.md b/_articles/fr/getting-paid.md
index 4695e48695a..05862fd61f8 100644
--- a/_articles/fr/getting-paid.md
+++ b/_articles/fr/getting-paid.md
@@ -101,6 +101,7 @@ Les projets provenant d'une grande entreprise, tels que [Go](https://github.com/
 
 Enfin, en fonction de votre situation personnelle, vous pouvez essayer de collecter des fonds de manière indépendante pour financer votre travail open source. Par exemple :
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon a fait financer son travail sur [Redux](https://github.com/reactjs/redux) via une [campagne de crowdfunding sur Patreon](https://redux.js.org/)
 * @andrewgodwin a fait financer le travail sur les migrations de schémas Django [à travers une campagne Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
diff --git a/_articles/getting-paid.md b/_articles/getting-paid.md
index 0df5ca6ecda..42d75af5b33 100644
--- a/_articles/getting-paid.md
+++ b/_articles/getting-paid.md
@@ -106,10 +106,11 @@ Projects that originated at a large company, such as [Go](https://github.com/gol
 
 Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
 * @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
-Finally, sometimes open source projects put bounties on issues that you might consider helping with. 
+Finally, sometimes open source projects put bounties on issues that you might consider helping with.
 
 * @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
 * @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
diff --git a/_articles/hu/getting-paid.md b/_articles/hu/getting-paid.md
index 7fa29f1d3d4..6a5af345930 100644
--- a/_articles/hu/getting-paid.md
+++ b/_articles/hu/getting-paid.md
@@ -68,7 +68,7 @@ Egyszerűbb elérni ezt, ha az adott nyílt forráskódú projektet a munkaadód
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Mint sokan mások a nyílt forráskódú közösségben, én is küzdöttem egy projekt fenntartásának terheivel. Amikor először kezdtem el a nyílt forráskódú munkát, későig maradtam a munkahelyemen, hogy dolgozhassak, vagy rögtön nekikezdtem, ahogy hazaértem. (...) Meg tudtam beszélni a vezetőmmel a problémákat, amikkel szembesültem és kitaláltuk, hogy mivel használjuk a Babel-t, be tudjuk beépíteni a nyílt forráskódú feladatokat a saját munkánkba. 
+  Mint sokan mások a nyílt forráskódú közösségben, én is küzdöttem egy projekt fenntartásának terheivel. Amikor először kezdtem el a nyílt forráskódú munkát, későig maradtam a munkahelyemen, hogy dolgozhassak, vagy rögtön nekikezdtem, ahogy hazaértem. (...) Meg tudtam beszélni a vezetőmmel a problémákat, amikkel szembesültem és kitaláltuk, hogy mivel használjuk a Babel-t, be tudjuk beépíteni a nyílt forráskódú feladatokat a saját munkánkba.
   <p markdown="1" class="pquote-credit">
 — @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
   </p>
@@ -101,6 +101,7 @@ A nagy cégektől származó projektek, mint a [Go](https://github.com/golang) v
 
 A személyes körülményeidtől függően megpróbálhatsz önállóan pénzt gyűjteni a nyílt forráskódú munkád finanszírozásához. Például:
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon a [Redux](https://github.com/reactjs/redux) projektet egy [Patreon crowdfunding kampányon](https://redux.js.org/) keresztül finanszírozta (önkéntes támogatás)
 * @andrewgodwin a Django schema migrációkat [egy Kickstarter kampányon keresztül](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) finanszírozta.
 
@@ -133,7 +134,7 @@ A projektedtől függően kérhetsz támogatást szupportért, új funkcióért,
 
 * **[Sidekiq](https://github.com/mperham/sidekiq)** kínál fizetős verziót támogatásért cserébe
 * **[Travis CI](https://github.com/travis-ci)** kínál fizetős verziót privát használatra
-* **[Ghost](https://github.com/TryGhost/Ghost)** alapvetően non-profit, de a felügyelt szolgáltatásért fizetni kell 
+* **[Ghost](https://github.com/TryGhost/Ghost)** alapvetően non-profit, de a felügyelt szolgáltatásért fizetni kell
 
 Néhány híres projekt, mint az [npm](https://github.com/npm/npm) és a [Docker](https://github.com/docker/docker), még kockázati tőkét is bevontak a növekedés finanszírozásához.
 
@@ -146,7 +147,7 @@ Egyes szoftveralapítványok és cégek támogatást nyújtanak a nyílt forrás
 * **[Libraries.io](https://github.com/librariesio)**  támogatást kapott a [Sloan Foundation](https://sloan.org/programs/digital-technology)-től
 * A **[Python Software Foundation](https://www.python.org/psf/grants/)** támogatást kínál a Python-hoz kapcsolódó projekteknek
 
-Ha érdekelnek a lehetőségek vagy esettanulmányok részletesebben, @nayafia [írt egy útmutatót](https://github.com/nayafia/lemonade-stand), hogy hogyan juthatunk pénzhez a nyílt forráskódú munkával. 
+Ha érdekelnek a lehetőségek vagy esettanulmányok részletesebben, @nayafia [írt egy útmutatót](https://github.com/nayafia/lemonade-stand), hogy hogyan juthatunk pénzhez a nyílt forráskódú munkával.
 A különböző finanszírozási lehetőségek különböző képességeket igényelnek, a választásnál vedd figyelembe az erősségeidet.
 
 ## Pénzügyi támogatás kiépítése
@@ -187,4 +188,4 @@ A támogatónak vannak kikötései a kifizetéssel kapcsolatosan? Például lehe
 
 Pénzügyi támogatást kapni nem könnyű dolog, legyen szó nyílt forráskódról, non-profit szervezetről, vagy szoftver startupról, legtöbb esetben kreatívnak kell lenned. El kell döntened, hogyan szeretnéd a támogatást megkapni, kutatnod kell, és a támogató helyébe kell képzelned magad, hogy meggyőzhesd a támogatásról.
 
-> 
+>
diff --git a/_articles/id/getting-paid.md b/_articles/id/getting-paid.md
index 861a68abaee..7baf18e5dc5 100644
--- a/_articles/id/getting-paid.md
+++ b/_articles/id/getting-paid.md
@@ -101,6 +101,7 @@ Proyek-proyek yang berasal dari perusahaan besar, seperti [Go](https://github.co
 
 Akhirnya, melihat dari kondisi pribadi Anda, Anda bisa mencoba mengumpulkan uang secara mandiri untuk mendanai proyek open source Anda. Sebagai contoh:
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon mendanai pekerjaannya pada [Redux](https://github.com/reactjs/redux) melalui [kampanye Patreon crowdfunding](https://redux.js.org/)
 * @andrewgodwin mendanai pekerjaan pada migrasi skema Django [melalui kampanye Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
diff --git a/_articles/ja/getting-paid.md b/_articles/ja/getting-paid.md
index 6a12b82fbe1..225eb1340d1 100644
--- a/_articles/ja/getting-paid.md
+++ b/_articles/ja/getting-paid.md
@@ -101,6 +101,7 @@ related:
 
 あなた個人の状況によっては、あなた個人でオープンソース活動に資金を出してもらう試みをすることも可能です。例えば：
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon は [Patreon でのクラウドファンディング](https://redux.js.org/)を通じて、 [Redux](https://github.com/reactjs/redux) の活動の資金を得ています。
 * @andrewgodwin は [Kickstarter のキャンペーン](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)を通じて、 Django のスキーママイグレーションの活動の資金を得ています。
 
diff --git a/_articles/ko/getting-paid.md b/_articles/ko/getting-paid.md
index 7e4a3182e3e..d616df03581 100644
--- a/_articles/ko/getting-paid.md
+++ b/_articles/ko/getting-paid.md
@@ -101,6 +101,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri
 
 마지막으로, 개인적인 상황에 따라, 오픈소스 작업을 위해 독립적으로 돈을 모으는 노력을 할 수 있습니다. 예시:
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon은 [Patreon crowdfunding campaign](https://redux.js.org/)을 통해 [Redux](https://github.com/reactjs/redux)에 대한 그의 작업에 펀드했습니다.
 * @andrewgodwin은 Django 스키마 마이그레이션 작업을 [Kickstarter 캠페인을 통해](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) 펀드했습니다.
 
diff --git a/_articles/ms/getting-paid.md b/_articles/ms/getting-paid.md
index abeb71c1248..f9c2c3396d9 100644
--- a/_articles/ms/getting-paid.md
+++ b/_articles/ms/getting-paid.md
@@ -106,6 +106,7 @@ Projek yang berasal dari syarikat besar, seperti [Go](https://github.com/golang)
 
 Bergantung pada keadaan peribadi anda, anda boleh mencuba mengumpulkan wang secara bebas untuk membiayai kerja sumber terbuka anda. Sebagai contoh:
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon membiayai kerjanya [Redux](https://github.com/reactjs/redux) melalui [Patreon crowdfunding campaign](https://redux.js.org/)
 * @andrewgodwin membiayai kerja migrasi skema Django [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
diff --git a/_articles/nl/getting-paid.md b/_articles/nl/getting-paid.md
index 906eeb47b40..ae05b842255 100644
--- a/_articles/nl/getting-paid.md
+++ b/_articles/nl/getting-paid.md
@@ -54,7 +54,7 @@ Het onderhouden van populaire projecten kan een aanzienlijke verantwoordelijkhei
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
   Vraag het aan een willekeurige open source projectbeheerder, en zij zullen u vertellen over de realiteit van de hoeveelheid werk die nodig is om een project te beheren. Je hebt klanten. U lost problemen voor hen op. U creëert nieuwe functies. Dit wordt een echte tijdrovende bezigheid.
-  
+
   _Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time._
 
   <p markdown="1" class="pquote-credit">
@@ -67,8 +67,9 @@ Betaald werk stelt mensen uit verschillende rangen en standen ook in staat om ee
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
   OSS levert enorme voordelen op voor de technologische industrie, wat op zijn beurt voordelen betekent voor alle industrieën. (...) Als de enige mensen die zich erop kunnen concentreren de gelukkigen en geobsedeerd zijn, dan is er een enorm onbenut potentieel.
-  
+
    _OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential._
+
   <p markdown="1" class="pquote-credit">
 — @isaacs, ["Geld en Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
   </p>
@@ -85,8 +86,9 @@ Het is gemakkelijker om een pleidooi te houden voor open source-werk als je werk
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
   Zoals velen in open source, worstelde ik met de last om een project te onderhouden. Toen ik voor het eerst met open source begon, bleef ik gewoon te laat om eraan te werken of toen ik thuiskwam. (...) Ik was in staat om met mijn baas de problemen te bespreken waarmee ik werd geconfronteerd en we kwamen met ideeën over hoe we open source-taken konden integreren met ons eigen gebruik van Babel.
-  
+
   _Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel._
+
   <p markdown="1" class="pquote-credit">
 — @hzoo, ["Open source-onderhouder verhalen"](https://github.com/open-source/stories/hzoo)
   </p>
@@ -105,8 +107,9 @@ Als uw bedrijf deze weg inslaat, is het belangrijk om de grenzen tussen gemeensc
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
   Betaald worden om aan open source te werken is een zeldzame en geweldige kans, maar je zou je passie in het proces niet moeten opgeven. Uw passie zou moeten zijn waarom bedrijven u willen betalen.
-  
+
   _Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you._
+
   <p markdown="1" class="pquote-credit">
 — @jessfraz, ["Wazige lijnen"](https://blog.jessfraz.com/post/blurred-lines/)
   </p>
@@ -121,6 +124,7 @@ Projecten die zijn ontstaan ​​bij een groot bedrijf, zoals [Go](https://gith
 
 Afhankelijk van uw persoonlijke omstandigheden kunt u proberen om zelfstandig geld in te zamelen om uw open source-werk te financieren. Bijvoorbeeld:
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon financierde zijn werk op [Redux](https://github.com/reactjs/redux) via een [Patreon crowdfunding-campagne](https://redux.js.org/)
 * @andrewgodwin gefinancierd werk aan Django-schemamigraties [via een Kickstarter-campagne](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
@@ -196,8 +200,9 @@ Heeft de financier enige vereisten met betrekking tot uitbetaling? U moet bijvoo
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
   We zijn al jaren de toonaangevende bron van websitevriendelijke pictogrammen, met een community van meer dan 20 miljoen mensen en zijn te zien op meer dan 70 miljoen websites, waaronder Whitehouse.gov. (...) Versie 4 bestond drie jaar geleden. Webtechnologie is sindsdien veel veranderd, en eerlijk gezegd is Font Awesome een beetje muf geworden. (...) Daarom introduceren we Font Awesome 5. We moderniseren en herschrijven de CSS en herontwerpen elk pictogram van boven naar beneden. We hebben het over een beter ontwerp, betere consistentie en betere leesbaarheid.
-  
+
   _For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability._
+
   <p markdown="1" class="pquote-credit">
 — @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
   </p>
diff --git a/_articles/pl/getting-paid.md b/_articles/pl/getting-paid.md
index 34cff4c0d5e..d5449946bd9 100644
--- a/_articles/pl/getting-paid.md
+++ b/_articles/pl/getting-paid.md
@@ -113,6 +113,7 @@ Projekty, które powstały w dużej firmie, takie jak [Go](https://github.com/go
 
 W zależności od osobistych okoliczności możesz spróbować samodzielnie zebrać pieniądze, aby sfinansować swoją pracę typu open source. Na przykład:
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon sfinansował swoją pracę [Redux](https://github.com/reactjs/redux) poprzez [kampanię crowdfundingową Patreon](https://redux.js.org/)
 * @andrewgodwin sfinansował prace nad migracjami schematu Django [poprzez kampanię Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
diff --git a/_articles/pt/getting-paid.md b/_articles/pt/getting-paid.md
index 319aa377b34..99df7d76e4e 100644
--- a/_articles/pt/getting-paid.md
+++ b/_articles/pt/getting-paid.md
@@ -101,10 +101,11 @@ Projetos que se originaram em uma grande empresa, como o [Go](https://github.com
 
 Dependendo de suas circunstâncias pessoais, você pode tentar conseguir dinheiro independentemente para financiar o seu trabalho open source. Por exemplo:
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon financiou seu trabalho no [Redux](https://github.com/reactjs/redux) através de uma [campanha de crowdfunding no Patreon](https://redux.js.org/)
 * @andrewgodwin financiou seu trabalho no Django schema migrations [através de uma campanha no Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
-Finalmente, as vezes, projetos open source põem recompensas em issues que você pode considerar ajudar a resolver. 
+Finalmente, as vezes, projetos open source põem recompensas em issues que você pode considerar ajudar a resolver.
 
 * @ConnorChristie conseguiu ser pago por [ajudar](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol a trabalhar em sua biblioteca JavaScript [através de uma recompensa em gitcoin](https://gitcoin.co/).
 * @mamiM fez traduções para o Japonês para @MetaMask após a [issue ser financiada na Bounties Network](https://explorer.bounties.network/bounty/134).
diff --git a/_articles/ro/getting-paid.md b/_articles/ro/getting-paid.md
index 52613240764..d8443f20472 100644
--- a/_articles/ro/getting-paid.md
+++ b/_articles/ro/getting-paid.md
@@ -23,7 +23,7 @@ O mare parte din munca open source este voluntară. De exemplu, cineva ar putea
   <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
   <p>
     Căutam un proiect de programare ca „hobby” care să mă țină ocupat în săptămâna din jurul Crăciunului. (...) Aveam un calculator acasă, și nu mai mult în mâinile mele. Am decis să scriu un interpretor pentru noul limbaj de scripting la care mă gândeam în ultimul timp. (...) Am ales Python ca un titlu de lucru.
-  </p>  
+  </p>
   <p>
     <em>
       I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
@@ -121,7 +121,7 @@ Multe companii dezvoltă programe open source pentru a-și construi marca și a
 @hueniverse, de exemplu, a constatat că există motive financiare pentru a justifica [investiția Walmart în open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Și @jamesgpearce a constatat că programul open source al Facebook [a făcut o diferență](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) în recrutare:
 
 > Este strâns aliniată cu cultura noastră a hackerilor, și cu felul în care organizația noastră a fost percepută. Ne-am întrebat angajații, „Ai fost conștient de programul software open source la Facebook?”. Două treimi au zis „Da”. O jumătate a zis că programul a contribuit în mod pozitiv la decizia de a lucra pentru noi. Acestea nu sunt numere marginale, ci, sper eu, o tendință care continuă.
-> 
+>
 > It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
 
 Dacă compania ta coboară pe acest traseu, este important să păstrezi granițele între comunitate și activitatea corporativă clare. În fine, open source se susține pe sine prin contribuții de la oameni din întreaga lume, și aceasta este mai mare decât oricare companie sau locație.
@@ -150,6 +150,7 @@ Proiectele care provin de la o companie mare, cum ar fi [Go](https://github.com/
 
 În funcție de circumstanțele tale personale, poți încerca să strângi bani în mod independent pentru a-ți finanța munca open source. De exemplu:
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon și-a finanțat munca pe [Redux](https://github.com/reactjs/redux) printr-o [campanie de finanțare colectivă Patreon](https://redux.js.org/)
 * @andrewgodwin a finanțat munca pe migrațiile de scheme Django [printr-o campanie Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
diff --git a/_articles/ta/getting-paid.md b/_articles/ta/getting-paid.md
index 3267c7af00b..e1f8322e338 100644
--- a/_articles/ta/getting-paid.md
+++ b/_articles/ta/getting-paid.md
@@ -101,6 +101,7 @@ related:
 
 இறுதியாக, உங்களுடைய தனிப்பட்ட சூழ்நிலைகளை பொறுத்து, நீங்கள் உங்கள் திறந்த மூல வேலைக்கு நிதி திரட்ட முயற்சி செய்யலாம். உதாரணத்திற்கு:
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon  தனது [Redux](https://github.com/reactjs/redux) திட்டத்திற்கான நிதியை [பேட்ரியன் கூட்டல் நிதி பிரச்சாரத்தின்](https://redux.js.org/) மூலம் திரட்டினார்.
 * @andrewgodwin  டிஜாங்க் திட்ட அமைப்புமுறைகளை [kickstarter பிரச்சாரத்தின்](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) மூலம் திரட்டினார்.
 
diff --git a/_articles/tr/getting-paid.md b/_articles/tr/getting-paid.md
index a174211d33c..aad2f945d62 100644
--- a/_articles/tr/getting-paid.md
+++ b/_articles/tr/getting-paid.md
@@ -106,6 +106,7 @@ Mevcut işvereninizi açık kaynak çalışmasına öncelik vermeye ikna edemiyo
 
 Kişisel durumunuza bağlı olarak, açık kaynaklı işinize para yatırmak için bağımsız olarak para toplamayı deneyebilirsiniz. Örneğin:
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon, [Redux](https://github.com/reactjs/redux) ile ilgili çalışmalarını bir [Patreon kitlesel fonlama kampanyası](https://redux.js.org/) yoluyla finanse etti
 * @andrewgodwin [, bir Kickstarter kampanyasıyla](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) Django şema göçleri konusundaki çalışmaları finanse etti
 
diff --git a/_articles/zh-hans/getting-paid.md b/_articles/zh-hans/getting-paid.md
index 6a24f0ba0d8..4fae2b29ddd 100644
--- a/_articles/zh-hans/getting-paid.md
+++ b/_articles/zh-hans/getting-paid.md
@@ -102,6 +102,7 @@ redirect_from: /zh-cn/getting-paid/
 
 当然最终还是要看你自身的条件而定，你甚至可以利用你的开源项目来独立的进行融资。这边就有几个案例：
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon 通过 [Patreon crowdfunding campaign](https://redux.js.org/) 为他的项目 [Redux](https://github.com/reactjs/redux) 成功的融到了资金。
 * @andrewgodwin [通过 Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) 为 Django schema 迁移拿到了资金
 
diff --git a/_articles/zh-hant/getting-paid.md b/_articles/zh-hant/getting-paid.md
index ca65d2def84..2d083b27ff5 100644
--- a/_articles/zh-hant/getting-paid.md
+++ b/_articles/zh-hant/getting-paid.md
@@ -102,6 +102,7 @@ redirect_from: /zh-tw/getting-paid/
 
 當然最終還是要看你自身的條件而定，你甚至可以利用你的開源專案來獨立的進行融資。這邊就有幾個案例：
 
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon 通過 [Patreon crowdfunding campaign](http://redux.js.org/)爲他的專案 [Redux](https://github.com/reactjs/redux)成功的融到了資金。
 * @andrewgodwin [通過 Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) 爲Django schema 遷移拿到了資金
 

From f92f7910abe2afacd5b2d1f8718b27229cc1c29b Mon Sep 17 00:00:00 2001
From: Emeric GOUY <emericgouy@gmail.com>
Date: Wed, 10 Mar 2021 18:20:36 +0100
Subject: [PATCH 133/749] fix typo : redundant example in fr/how-to-contribute

---
 _articles/fr/how-to-contribute.md | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md
index aa525528097..d5510878b74 100644
--- a/_articles/fr/how-to-contribute.md
+++ b/_articles/fr/how-to-contribute.md
@@ -429,9 +429,6 @@ Avant d'ouvrir une issue ou une pull request, ou de poser une question dans une
 
 **Surtout, gardez-le classique.** L'open source est composé de collaborateurs du monde entier. Le contexte se perd dans les langues, les cultures, les zones géographiques et les fuseaux horaires. De plus, la communication écrite rend plus difficile la transmission d'un ton ou d'une humeur. Supposer de bonnes intentions dans ces conversations. Il est bon de repousser poliment une idée, de demander plus de contexte ou de clarifier davantage votre position. Juste essayer de laisser l'Internet un meilleur endroit que lorsque vous l'avez trouvé.
 
-> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
->
-> 😢 _"Why can't you fix my problem? Isn't this your project?"_
 
 ### Rassembler le contexte
 

From fb59d77c1f6ba8598f435480cb17d87cf945976b Mon Sep 17 00:00:00 2001
From: Emeric GOUY <emericgouy@gmail.com>
Date: Wed, 10 Mar 2021 18:51:15 +0100
Subject: [PATCH 134/749] fix linter issue in fr/how-to-contribute

---
 _articles/fr/how-to-contribute.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md
index d5510878b74..53f3cb81372 100644
--- a/_articles/fr/how-to-contribute.md
+++ b/_articles/fr/how-to-contribute.md
@@ -429,7 +429,6 @@ Avant d'ouvrir une issue ou une pull request, ou de poser une question dans une
 
 **Surtout, gardez-le classique.** L'open source est composé de collaborateurs du monde entier. Le contexte se perd dans les langues, les cultures, les zones géographiques et les fuseaux horaires. De plus, la communication écrite rend plus difficile la transmission d'un ton ou d'une humeur. Supposer de bonnes intentions dans ces conversations. Il est bon de repousser poliment une idée, de demander plus de contexte ou de clarifier davantage votre position. Juste essayer de laisser l'Internet un meilleur endroit que lorsque vous l'avez trouvé.
 
-
 ### Rassembler le contexte
 
 Avant de faire quoi que ce soit, faites une vérification rapide pour vous assurer que votre idée n'a pas été discutée ailleurs. Parcourez le fichier README du projet, les issues (ouvertes et fermées), la liste de diffusion et Stack Overflow. Vous n'avez pas à passer des heures à tout faire, mais une recherche rapide de quelques termes clés va aider.

From 6a8b807851e38a6425ac8b294d08c36d3365f93e Mon Sep 17 00:00:00 2001
From: Zhizhen He <hezhizhen@caicloud.io>
Date: Mon, 15 Mar 2021 20:31:06 +0800
Subject: [PATCH 135/749] Add one missing character in Chinese translation

---
 _articles/zh-hans/code-of-conduct.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/code-of-conduct.md b/_articles/zh-hans/code-of-conduct.md
index 66067f0e525..bdb8c7dc97c 100644
--- a/_articles/zh-hans/code-of-conduct.md
+++ b/_articles/zh-hans/code-of-conduct.md
@@ -82,7 +82,7 @@ redirect_from: /zh-cn/code-of-conduct/
 
 ### 采取适当的行动
 
-当搜集和处理足够的信息后，你们需要决定做什么。当你们在考虑下一步的时候，请牢记你们的目的是营造一个安全，尊重和协作的社区氛围。不仅要考虑如何处理有问题的情况，还要考虑们的反应将如何影响你们社区的其他行为和期望。
+当搜集和处理足够的信息后，你们需要决定做什么。当你们在考虑下一步的时候，请牢记你们的目的是营造一个安全，尊重和协作的社区氛围。不仅要考虑如何处理有问题的情况，还要考虑你们的反应将如何影响你们社区的其他行为和期望。
 
 当有人报告违规时，处理它是你们的工作，而不是他们的。有时，透露报告者本人的信息会给他们的职业生涯，声誉和人生安全带来很大的风险。迫使报告者面对骚扰者会将他们置于妥协的位置。除非报告者有特别的要求，你们应该直接和有问题的人沟通。
 

From 27b6dd579572f009091de8e6d6f7773dcd327c0c Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Mon, 15 Mar 2021 18:10:55 -0400
Subject: [PATCH 136/749] Update CODEOWNERS

---
 CODEOWNERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CODEOWNERS b/CODEOWNERS
index c9bee33f7c7..c2ae4268f1e 100644
--- a/CODEOWNERS
+++ b/CODEOWNERS
@@ -1 +1 @@
-*  @github/communities-heart-reviewers
+*  @github/communities-heart-reviewers @github/devrel

From b07469384c25e0e1f303273f7e573bedcb2a1181 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Thu, 18 Mar 2021 18:51:08 +0330
Subject: [PATCH 137/749] Create fa.yml

Initial translation done.
---
 _data/locales/fa.yml | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 _data/locales/fa.yml

diff --git a/_data/locales/fa.yml b/_data/locales/fa.yml
new file mode 100644
index 00000000000..dd41c8e0717
--- /dev/null
+++ b/_data/locales/fa.yml
@@ -0,0 +1,31 @@
+en:
+  locale_name: Farsi
+  nav:
+    about: درباره
+    contribute: مشارکت
+  index:
+    lead: نرم‌افزار متن باز توسط افرادی مشابه شما ساخته شده است. اینجا می‌توانید راه اندازی و رشد دادن پروژه خود را یاد بگیرید.
+    opensourcefriday: امروز جمعه‌اس! چند ساعت صرف مشارکت در نرم افزاری کن که عاشقش هستی    
+  article:
+    table_of_contents: فهرست مطالب
+    back_to_all_guides: بازگشت به صفحه اصلی
+    related_guides: راهنماهای مرتبط
+  footer:
+    contribute:
+      heading: مشارکت
+      description: پیشنهاد یا نظری داری؟ این مطلب به صورت متن باز منتشر شد. می‌تونی در بهبودش کمک کنی.
+      button: مشارکت می‌کنم
+    subscribe:
+      heading: در ارتباط باش
+      description: اولین نفر ی باش که در خصوص آخرین نکات و ترفندهای متن باز در گیتهاب باخبر میشه.
+      label: آدرس ایمیل
+      button: شروع اشتراک
+    byline:
+      # [code], [love], and [github] will be replaced by octicons
+      format: "[code] با [love] توسط [github] و [friends]"
+      # Label for code octicon
+      code_label: code
+      # Label for love octicon
+      love_label: عشق
+      # Label for the contributors link
+      friends_label: دوستان

From 0df69de78f0350c7ff94504c8ac3c027a2f17b16 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Thu, 18 Mar 2021 19:01:23 +0330
Subject: [PATCH 138/749] Just started to translate guides.

Just started to translate guides.
---
 _articles/fa/best-practices.md            | 287 ++++++++++++
 _articles/fa/building-community.md        | 280 +++++++++++
 _articles/fa/code-of-conduct.md           | 120 +++++
 _articles/fa/finding-users.md             | 163 +++++++
 _articles/fa/getting-paid.md              | 192 ++++++++
 _articles/fa/how-to-contribute.md         | 535 ++++++++++++++++++++++
 _articles/fa/index.html                   |   6 +
 _articles/fa/leadership-and-governance.md | 165 +++++++
 _articles/fa/legal.md                     | 166 +++++++
 _articles/fa/metrics.md                   | 132 ++++++
 _articles/fa/starting-a-project.md        | 362 +++++++++++++++
 11 files changed, 2408 insertions(+)
 create mode 100644 _articles/fa/best-practices.md
 create mode 100644 _articles/fa/building-community.md
 create mode 100644 _articles/fa/code-of-conduct.md
 create mode 100644 _articles/fa/finding-users.md
 create mode 100644 _articles/fa/getting-paid.md
 create mode 100644 _articles/fa/how-to-contribute.md
 create mode 100644 _articles/fa/index.html
 create mode 100644 _articles/fa/leadership-and-governance.md
 create mode 100644 _articles/fa/legal.md
 create mode 100644 _articles/fa/metrics.md
 create mode 100644 _articles/fa/starting-a-project.md

diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md
new file mode 100644
index 00000000000..c1894f66eaf
--- /dev/null
+++ b/_articles/fa/best-practices.md
@@ -0,0 +1,287 @@
+---
+lang: fa
+title: بهترین روال‌های تجربه شده برای نگهدارنده‌ها
+description: زندگی خود را به عنوان یک نگهدارنده‌ی اوپن سورس آسان‌تر کنید؛ از ثبت‌کردن فرآیندها گرفته تا بهره‌بردن از اجتماع‌تان.
+class: best-practices
+toc:
+  what-does-it-mean-to-be-a-maintainer: "What does it mean to be a maintainer?"
+  documenting-your-processes: "Documenting your processes"
+  learning-to-say-no: "Learning to say no"
+  leverage-your-community: "Leverage your community"
+  bring-in-the-robots: "Bring in the robots"
+  its-okay-to-hit-pause: "It’s okay to hit pause"
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+  - metrics
+  - leadership
+---
+
+## What does it mean to be a maintainer?
+
+If you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more.
+
+In the early stages of a project, you're experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you'll find yourself working with your users and contributors more.
+
+Maintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community.
+
+## Documenting your processes
+
+Writing things down is one of the most important things you can do as a maintainer.
+
+Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask.
+
+Writing things down makes it easier to say no when something doesn't fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project.
+
+Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all.
+
+Remember to keep your documentation up-to-date. If you're not able to always do this, delete your outdated documentation or indicate it is outdated so contributors know updates are welcome.
+
+### Write down your project's vision
+
+Start by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well.
+
+Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions.
+
+For example, @lord discovered that having a project vision helped him figure out which requests to spend time on. As a new maintainer, he regretted not sticking to his project's scope when he got his first feature request for [Slate](https://github.com/lord/slate).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
+  I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of an half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
+  <p markdown="1" class="pquote-credit">
+— @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
+  </p>
+</aside>
+
+### Communicate your expectations
+
+Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun.
+
+Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do.
+
+Most people who come across your project don't know anything about you or your circumstances. They may assume you get paid to work on it, especially if it's something they regularly use and depend on. Maybe at one point you put a lot of time into your project, but now you're busy with a new job or family member.
+
+All of this is perfectly okay! Just make sure other people know about it.
+
+If maintaining your project is part-time or purely volunteered, be honest about how much time you have. This is not the same as how much time you think the project requires, or how much time others want you to spend.
+
+Here are a few rules that are worth writing down:
+
+* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_)
+* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_)
+* When it's appropriate to follow up (_for example, "You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread."_)
+* How much time you spend on the project (_for example, "We only spend about 5 hours per week on this project"_)
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors.
+
+### Keep communication public
+
+Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker.
+
+If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes.
+
+That way, anybody who joins your community will have access to the same information as someone who's been there for years.
+
+## Learning to say no
+
+You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists.
+
+Having everything written down, however, helps depersonalize situations when you do need to enforce your rules.
+
+Saying no isn't fun, but  _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_.
+
+Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others.
+
+### Keep the conversation friendly
+
+One of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept.
+
+Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor.
+
+Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards.
+
+If you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
+  The key to handle support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS.
+  <p markdown="1" class="pquote-credit">
+— @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
+  </p>
+</aside>
+
+Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.
+
+It's better to immediately close the contributions you know you don't want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+
+Secondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it's someone's first time. Even if you don't accept their contribution, acknowledge the person behind it and thank them for their interest. It's a big compliment!
+
+If you don't want to accept a contribution:
+
+* **Thank them** for their contribution
+* **Explain why it doesn't fit** into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm.
+* **Link to relevant documentation**, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself.
+* **Close the request**
+
+You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):
+
+![Celery screenshot](/assets/images/best-practices/celery.png)
+
+If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want.
+
+Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it.
+
+Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise.
+
+### Be proactive
+
+To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide.
+
+If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example:
+
+* Fill out a issue or PR template/checklist
+* Open an issue before submitting a PR
+
+If they don't follow your rules, close the issue immediately and point to your documentation.
+
+While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+  Ideally, explain to them and in a CONTRIBUTING.md file how they can get a better indication in the future on what would or would not be accepted before they begin the work.
+  <p markdown="1" class="pquote-credit">
+— @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
+  </p>
+</aside>
+
+Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively.
+
+### Embrace mentorship
+
+Maybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections.
+
+If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first issue,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them.
+
+## Leverage your community
+
+You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work.
+
+### Share the workload
+
+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.
+
+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.
+
+Encouraging others to [share ownership of the project](../building-community/#share-ownership-of-your-project) can greatly reduce your own workload, as @lmccart discovered on her project, [p5.js](https://github.com/processing/p5.js).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
+  I’d been saying, "Yeah, anyone can be involved, you don’t have to have a lot of coding expertise [...]." We had people sign up to come [to an event] and that’s when I was really wondering: is this true, what I’ve been saying? There are gonna be 40 people who show up, and it’s not like I can sit with each of them...But people came together, and it just sort of worked. As soon as one person got it, they could teach their neighbor.
+  <p markdown="1" class="pquote-credit">
+—  @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+  </p>
+</aside>
+
+If you need to step away from your project, either on hiatus or permanently, there's no shame in asking someone else to take over for you.
+
+If other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It's great that so many people want your project to live on!
+
+@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), helped those goals live on even after he stepped away from the project:
+
+> I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down.
+
+### Let others build the solutions they need
+
+If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork.
+
+Forking a project doesn't have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project's vision.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
+  I cater to the 80% use case. If you are one of the unicorns, please fork my work. I won't get offended! My public projects are almost always meant to solve the most common problems; I try to make it easy to go deeper by either forking my work or extending it.
+  <p markdown="1" class="pquote-credit">
+— @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+  </p>
+</aside>
+
+The same applies to a user who really wants a solution that you simply don't have the bandwidth to build. Offering APIs and customization hooks can help others meet their own needs, without having to modify the source directly. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) encouraging plugins for CocoaPods led to "some of the most interesting ideas":
+
+> It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying "no", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform.
+
+## Bring in the robots
+
+Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier.
+
+### Require tests and other checks to improve the quality of your code
+
+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.
+
+If you add tests, make sure to explain how they work in your CONTRIBUTING file.
+
+<aside markdown="1" class="pquote">
+  <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)
+  </p>
+</aside>
+
+### Use tools to automate basic maintenance tasks
+
+The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for it.
+
+There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases
+* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
+* [Danger](https://github.com/danger/danger) helps automate code review
+* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information
+* [dependabot-preview](https://github.com/marketplace/dependabot-preview) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
+
+For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.
+
+To manage your email notifications, you can set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize by priority.
+
+If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept.
+
+However, if your standards are too complicated, they can increase the barriers to contribution. Make sure you're only adding enough rules to make everyone's lives easier.
+
+If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors.
+
+## It's okay to hit pause
+
+Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty.
+
+Perhaps you're feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up.
+
+Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project.
+
+Although it should go without saying, take a break! You shouldn't have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take [a month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) after 14 years of volunteer OSS work.
+
+Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
+  In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
+  <p markdown="1" class="pquote-credit">
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+  </p>
+</aside>
+
+Sometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away.
+
+Do your best to find support for your users and community while you're away from a project. If you can't find the support you need, take a break anyway. Be sure to communicate when you're not available, so people aren't confused by your lack of responsiveness.
+
+Taking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you.
+
+## Take care of yourself first!
+
+Maintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive.
diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md
new file mode 100644
index 00000000000..a86c8b26c55
--- /dev/null
+++ b/_articles/fa/building-community.md
@@ -0,0 +1,280 @@
+---
+lang: en
+title: Building Welcoming Communities
+description: Building a community that encourages people to use, contribute to, and evangelize your project.
+class: building
+toc:
+  setting-your-project-up-for-success: "Setting your project up for success"
+  growing-your-community: "Growing your community"
+  resolving-conflicts: "Resolving conflicts"
+order: 4
+image: /assets/images/cards/building.png
+related:
+  - best-practices
+  - coc
+---
+
+## Setting your project up for success
+
+You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around?
+
+A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back.
+
+### Make people feel welcome
+
+One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+
+As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more.
+
+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.
+
+[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.
+
+* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
+* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
+* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
+* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+  </p>
+</aside>
+
+The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute.
+
+Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself.
+
+### Document everything
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
+  <p markdown="1" class="pquote-credit">
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public.
+
+When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed.
+
+Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public.
+
+Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions.
+
+If you notice multiple users running into the same problem, document the answers in the README.
+
+For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you.
+
+Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on.
+
+### Be responsive
+
+As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started.
+
+Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating.
+
+Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466):
+
+![Middleman pull request](/assets/images/building-community/middleman_pr.png)
+
+[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution.
+
+Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project.
+
+### Give your community a place to congregate
+
+There are two reasons to give your community a place to congregate.
+
+The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate.
+
+The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel.
+
+Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above!
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members:
+
+> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.
+
+Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address.
+
+## Growing your community
+
+Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction.
+
+### Don't tolerate bad actors
+
+Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others.
+
+Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
+  The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.
+  <p markdown="1" class="pquote-credit">
+— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+  </p>
+</aside>
+
+Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
+
+When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations.
+
+### Meet contributors where they're at
+
+Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need.
+
+In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors.
+
+![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
+
+In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started.
+
+Finally, use your documentation to make people feel welcome at every step of the way.
+
+You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration.
+
+For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
+
+### Share ownership of your project
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
+  Your leaders will have different opinions, as all healthy communities should! However, you need to take steps to ensure the loudest voice doesn't always win by tiring people out, and that less prominent and minority voices are heard.
+  <p markdown="1" class="pquote-credit">
+— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+  </p>
+</aside>
+
+People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around.
+
+See if you can find ways to share ownership with your community as much as possible. Here are some ideas:
+
+* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself.
+
+![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
+
+* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
+
+* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+
+* **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.
+
+The reality is that [most projects only have](https://peerj.com/preprints/1233.pdf) 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.
+
+While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
+  \[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it.
+  <p markdown="1" class="pquote-credit">
+— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+  </p>
+</aside>
+
+## Resolving conflicts
+
+In the early stages of your project, making major decisions is easy. When you want to do something, you just do it.
+
+As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own.
+
+For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address.
+
+### Set the bar for kindness
+
+When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you.
+
+Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
+  As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
+  <p markdown="1" class="pquote-credit">
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+  </p>
+</aside>
+
+Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly.
+
+Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you.
+
+### Treat your README as a constitution
+
+Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion.
+
+### Focus on the journey, not the destination
+
+Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns.
+
+Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place.
+
+Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus.
+
+Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
+  Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
+  <p markdown="1" class="pquote-credit">
+— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+  </p>
+</aside>
+
+Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions.
+
+Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution.
+
+### Keep the conversation focused on action
+
+Discussion is important, but there is a difference between productive and unproductive conversations.
+
+Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down.
+
+Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues.
+
+With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_
+
+If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation.
+
+If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+  </p>
+</aside>
+
+### Pick your battles wisely
+
+Context is important. Consider who is involved in the discussion and how they represent the rest of the community.
+
+Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices.
+
+If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread.
+
+### Identify a community tiebreaker
+
+With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker.
+
+A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it.
+
+Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible.
+
+## Community is the ❤️ of open source
+
+Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience.
diff --git a/_articles/fa/code-of-conduct.md b/_articles/fa/code-of-conduct.md
new file mode 100644
index 00000000000..0b21e42d458
--- /dev/null
+++ b/_articles/fa/code-of-conduct.md
@@ -0,0 +1,120 @@
+---
+lang: en
+title: Your Code of Conduct
+description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct.
+class: coc
+toc:
+  why-do-i-need-a-code-of-conduct: "Why do I need a code of conduct?"
+  establishing-a-code-of-conduct: "Establishing a code of conduct"
+  deciding-how-youll-enforce-your-code-of-conduct: "Deciding how you’ll enforce your code of conduct"
+  enforcing-your-code-of-conduct: "Enforcing your code of conduct"
+  your-responsibilities-as-a-maintainer: "Your responsibilities as a maintainer"
+order: 8
+image: /assets/images/cards/coc.png
+related:
+  - building
+  - leadership
+---
+
+## Why do I need a code of conduct?
+
+A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.
+
+Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.
+
+A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with.
+
+## Establishing a code of conduct
+
+Try to establish a code of conduct as early as possible: ideally, when you first create your project.
+
+In addition to communicating your expectations, a code of conduct describes the following:
+
+* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_
+* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_
+* What happens if someone violates the code of conduct
+* How someone can report violations
+
+Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
+
+The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](http://citizencodeofconduct.org/) are also two good code of conduct examples.
+
+Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
+
+## Deciding how you'll enforce your code of conduct
+
+<aside markdown="1" class="pquote">
+  A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
+  <p markdown="1" class="pquote-credit">
+— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+  </p>
+</aside>
+
+You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:
+
+* It demonstrates that you are serious about taking action when it's needed.
+
+* Your community will feel more reassured that complaints actually get reviewed.
+
+* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.
+
+You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
+
+Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+
+For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+
+## Enforcing your code of conduct
+
+Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up.
+
+### Gather information about the situation
+
+Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment.
+
+The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context.
+
+Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
+
+<aside markdown="1" class="pquote">
+  Don’t get pulled into an argument. Don’t get sidetracked into dealing with someone else’s behavior before you’ve finished dealing with the matter at hand. Focus on what you need.
+  <p markdown="1" class="pquote-credit">
+— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+  </p>
+</aside>
+
+### Take appropriate action
+
+After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward.
+
+When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise.
+
+There are a few ways you might respond to a code of conduct violation:
+
+* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication.
+
+* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them.
+
+Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example:
+
+* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project
+
+* **Permanently ban** the person from the project
+
+Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached.
+
+## Your responsibilities as a maintainer
+
+A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes.
+
+As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community.
+
+A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable.
+
+In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way.
+
+## Encourage the behavior you want to see in the world 🌎
+
+When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow.
diff --git a/_articles/fa/finding-users.md b/_articles/fa/finding-users.md
new file mode 100644
index 00000000000..84ec4c6e7ca
--- /dev/null
+++ b/_articles/fa/finding-users.md
@@ -0,0 +1,163 @@
+---
+lang: en
+title: Finding Users for Your Project
+description: Help your open source project grow by getting it in the hands of happy users.
+class: finding
+toc:
+  spreading-the-word: "Spreading the word"
+  figure-out-your-message: "Figure out your message"
+  help-people-find-and-follow-your-project: "Help people find and follow your project"
+  go-where-your-projects-audience-is-online: "Go where your project’s audience is (online)"
+  go-where-your-projects-audience-is-offline: "Go where your project’s audience is (offline)"
+  build-a-reputation: "Build a reputation"
+order: 3
+image: /assets/images/cards/finding.png
+related:
+  - beginners
+  - building
+---
+
+## Spreading the word
+
+There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work!
+
+## Figure out your message
+
+Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters.
+
+What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance.
+
+Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want.
+
+For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
+
+![Cartography README](/assets/images/finding-users/cartography.jpg)
+
+For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+
+## Help people find and follow your project
+
+<aside markdown="1" class="pquote">
+  You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
+  <p markdown="1" class="pquote-credit">
+— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+  </p>
+</aside>
+
+Help people find and remember your project by pointing them to a single namespace.
+
+**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.
+
+If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. 
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
+  A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project.
+  <p markdown="1" class="pquote-credit">
+— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+  </p>
+</aside>
+
+**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_.
+
+If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+
+![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
+
+Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!
+
+## Go where your project's audience is (online)
+
+Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
+
+Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
+  Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project.
+  <p markdown="1" class="pquote-credit">
+— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+  </p>
+</aside>
+
+See if you can find ways to share your project in relevant ways:
+
+* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.
+* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.
+* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work.
+
+Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want.
+
+If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication.
+
+## Go where your project's audience is (offline)
+
+![Public speaking](/assets/images/finding-users/public_speaking.jpg)
+
+Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.
+
+If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
+  I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
+  <p markdown="1" class="pquote-credit">
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+  </p>
+</aside>
+
+If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.
+
+As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.
+
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
+  When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+  <p markdown="1" class="pquote-credit">
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+  </p>
+</aside>
+
+When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.
+
+Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
+  I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?
+  <p markdown="1" class="pquote-credit">
+— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+  </p>
+</aside>
+
+## Build a reputation
+
+In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.
+
+Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
+  The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+  <p markdown="1" class="pquote-credit">
+— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+  </p>
+</aside>
+
+It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others.
+
+There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
+  PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it.
+  <p markdown="1" class="pquote-credit">
+— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
+  </p>
+</aside>
+
+## Keep at it!
+
+It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.
diff --git a/_articles/fa/getting-paid.md b/_articles/fa/getting-paid.md
new file mode 100644
index 00000000000..42d75af5b33
--- /dev/null
+++ b/_articles/fa/getting-paid.md
@@ -0,0 +1,192 @@
+---
+lang: en
+title: Getting Paid for Open Source Work
+description: Sustain your work in open source by getting financial support for your time or your project.
+class: getting-paid
+toc:
+  why-some-people-seek-financial-support: "Why some people seek financial support"
+  funding-your-own-time: "Funding your own time"
+  finding-funding-for-your-project: "Finding funding for your project"
+  building-a-case-for-financial-support: "Building a case for financial support"
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+  - best-practices
+  - leadership
+---
+
+## Why some people seek financial support
+
+Much of open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
+I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+  <p markdown="1" class="pquote-credit">
+— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+  </p>
+</aside>
+
+There are many reasons why a person would not want to be paid for their open source work.
+
+* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
+* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
+* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
+  Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+  <p markdown="1" class="pquote-credit">
+— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+  </p>
+</aside>
+
+For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+
+Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
+  Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+  <p markdown="1" class="pquote-credit">
+— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+  </p>
+</aside>
+
+Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
+   OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+  <p markdown="1" class="pquote-credit">
+— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+  </p>
+</aside>
+
+If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+
+## Funding your own time
+
+Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+
+It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
+  Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.
+  <p markdown="1" class="pquote-credit">
+— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
+  </p>
+</aside>
+
+If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+
+Many companies are developing open source programs to build their brand and recruit quality talent.
+
+@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+
+> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+
+If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
+  Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+  <p markdown="1" class="pquote-credit">
+— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+  </p>
+</aside>
+
+If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+
+* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
+* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+
+Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+
+Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
+
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
+* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
+* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+Finally, sometimes open source projects put bounties on issues that you might consider helping with.
+
+* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
+* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+
+## Finding funding for your project
+
+Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+
+Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing into new features or ideas.
+
+As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+
+### Raise money for your work through crowdfunding campaigns or sponsorships
+
+Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
+A few examples of sponsored projects include:
+
+* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
+* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803)
+* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+
+### Create a revenue stream
+
+Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
+* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
+* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+
+Some popular projects, like [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+
+### Apply for grant funding
+
+Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+
+For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+
+## Building a case for financial support
+
+Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+
+Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+
+### Impact
+
+Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+
+### Traction
+
+Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+
+### Value to funder
+
+Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+
+### Use of funds
+
+What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+
+### How you'll receive the funds
+
+Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
+  For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+  <p markdown="1" class="pquote-credit">
+— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+  </p>
+</aside>
+
+## Experiment and don't give up
+
+Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
new file mode 100644
index 00000000000..81158f6f25a
--- /dev/null
+++ b/_articles/fa/how-to-contribute.md
@@ -0,0 +1,535 @@
+---
+lang: en
+title: How to Contribute to Open Source
+description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans.
+class: contribute
+toc:
+  why-contribute-to-open-source: "Why contribute to open source?"
+  what-it-means-to-contribute: "What it means to contribute"
+  orienting-yourself-to-a-new-project: "Orienting yourself to a new project"
+  finding-a-project-to-contribute-to: "Finding a project to contribute to"
+  how-to-submit-a-contribution: "How to submit a contribution"
+  what-happens-after-you-submit-a-contribution: "What happens after you submit a contribution"
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+  - beginners
+  - building
+---
+
+## Why contribute to open source?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
+  Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+  <p markdown="1" class="pquote-credit">
+— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+  </p>
+</aside>
+
+Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+
+Why do people contribute to open source? Plenty of reasons!
+
+### Improve software you rely on
+
+Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+
+### Improve existing skills
+
+Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+
+### Meet people who are interested in similar things
+
+Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+
+### Find mentors and teach others
+
+Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+
+### Build public artifacts that help you grow a reputation (and a career)
+
+By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+
+### Learn people skills
+
+Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+
+### It's empowering to be able to make changes, even small ones
+
+You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+
+## What it means to contribute
+
+If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+
+Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+
+### You don't have to contribute code
+
+A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
+  I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+  <p markdown="1" class="pquote-credit">
+— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+  </p>
+</aside>
+
+Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
+  I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing.
+  <p markdown="1" class="pquote-credit">
+— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
+  </p>
+</aside>
+
+### Do you like planning events?
+
+* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Organize the project's conference (if they have one)
+* Help community members find the right conferences and submit proposals for speaking
+
+### Do you like to design?
+
+* Restructure layouts to improve the project's usability
+* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Put together a style guide to help the project have a consistent visual design
+* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+
+### Do you like to write?
+
+* Write and improve the project's documentation
+* Curate a folder of examples showing how the project is used
+* Start a newsletter for the project, or curate highlights from the mailing list
+* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Write a translation for the project's documentation
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
+  Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+  <p markdown="1" class="pquote-credit">
+— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+  </p>
+</aside>
+
+### Do you like organizing?
+
+* Link to duplicate issues, and suggest new issue labels, to keep things organized
+* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
+* Ask clarifying questions on recently opened issues to move the discussion forward
+
+### Do you like to code?
+
+* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Ask if you can help write a new feature
+* Automate project setup
+* Improve tooling and testing
+
+### Do you like helping people?
+
+* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
+* Answer questions for people on open issues
+* Help moderate the discussion boards or conversation channels
+
+### Do you like helping others code?
+
+* Review code on other people's submissions
+* Write tutorials for how a project can be used
+* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### You don't just have to work on software projects!
+
+While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+
+For example:
+
+* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
+* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
+* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+
+Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
+
+## Orienting yourself to a new project
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
+  If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+  <p markdown="1" class="pquote-credit">
+— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+  </p>
+</aside>
+
+For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+
+Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
+
+### Anatomy of an open source project
+
+Every open source community is different.
+
+Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+
+That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+
+A typical open source project has the following types of people:
+
+* **Author:** The person/s or organization that created the project
+* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
+* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
+* **Contributors:** Everyone who has contributed something back to the project
+* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+
+Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+
+A project also has documentation. These files are usually listed in the top level of a repository.
+
+* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
+* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
+* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
+* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
+* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.
+
+Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+
+* **Issue tracker:** Where people discuss issues related to the project.
+* **Pull requests:** Where people discuss and review changes that are in progress.
+* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
+* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
+
+## Finding a project to contribute to
+
+Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+
+If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_
+
+Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+
+Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+
+Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+
+Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+
+You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
+
+> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+
+If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+You can also use one of the following resources to help you discover and contribute to new projects:
+
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
+
+### A checklist before you contribute
+
+When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+
+Here's a handy checklist to evaluate whether a project is good for new contributors.
+
+**Meets the definition of open source**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+  </label>
+</div>
+
+**Project actively accepts contributions**
+
+Look at the commit activity on the master branch. On GitHub, you can see this information on a repository's homepage.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+  When was the latest commit?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+  How many contributors does the project have?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  </label>
+</div>
+
+Next, look at the project's issues.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    How many open issues are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to issues when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Are the issues recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+  </label>
+</div>
+
+Now do the same for the project's pull requests.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    How many open pull requests are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox20" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to pull requests when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the pull requests?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    Are the pull requests recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox13" class="overflow-hidden d-block text-normal">
+    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+  </label>
+</div>
+
+**Project is welcoming**
+
+A project that is friendly and welcoming signals that they will be receptive to new contributors.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox14" class="overflow-hidden d-block text-normal">
+    Do the maintainers respond helpfully to questions in issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox15" class="overflow-hidden d-block text-normal">
+    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox16" class="overflow-hidden d-block text-normal">
+    Do pull requests get reviewed?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox17" class="overflow-hidden d-block text-normal">
+    Do maintainers thank people for their contributions?
+  </label>
+</div>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+  </p>
+</aside>
+
+## How to submit a contribution
+
+You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+
+### Communicating effectively
+
+Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
+  \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+  <p markdown="1" class="pquote-credit">
+— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+  </p>
+</aside>
+
+Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+
+**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+
+> 😇 _"X doesn't happen when I do Y"_
+>
+> 😢 _"X is broken! Please fix it."_
+
+**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn.
+
+> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+>
+> 😢 _"How do I X?"_
+
+**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+
+> 😇 _"I'd like to write an API tutorial."_
+>
+> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+
+**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+
+> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+>
+> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+
+**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+
+> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+>
+> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+
+**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+
+> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+>
+> 😢 _"Why won't you support my use case? This is unacceptable!"_
+
+**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+
+### Gathering context
+
+Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+
+If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request:
+
+* **Issues** are like starting a conversation or discussion
+* **Pull requests** are for starting work on a solution
+* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
+  You'll learn <em>a lot</em> from taking a single project you actively use, "watching" it on GitHub and reading every issue and PR.
+<p markdown="1" class="pquote-credit">
+— @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
+  </p>
+</aside>
+
+### Opening an issue
+
+You should usually open an issue in the following situations:
+
+* Report an error you can't solve yourself
+* Discuss a high-level topic or idea (for example, community, vision or policies)
+* Propose a new feature or other project idea
+
+Tips for communicating on issues:
+
+* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
+* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
+* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+
+### Opening a pull request
+
+You should usually open a pull request in the following situations:
+
+* Submit trivial fixes (for example, a typo, a broken link or an obvious error)
+* Start work on a contribution that was already asked for, or that you've already discussed, in an issue
+
+A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
+
+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/).)
+* **[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.
+* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
+* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+
+If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+
+## What happens after you submit a contribution
+
+You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
+
+After you submit a contribution, one of the following will happen:
+
+### 😭 You don't get a response.
+
+Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+
+If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+
+**Don't** reach out to that person privately; remember that public communication is vital to open source projects.
+
+If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+
+### 🚧 Someone requests changes to your contribution.
+
+It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+
+When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it.
+
+If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
+
+### 👎 Your contribution doesn't get accepted.
+
+Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+
+### 🎉 Your contribution gets accepted.
+
+Hooray! You've successfully made an open source contribution!
+
+## You did it!
+
+Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
diff --git a/_articles/fa/index.html b/_articles/fa/index.html
new file mode 100644
index 00000000000..627d4f8ebb0
--- /dev/null
+++ b/_articles/fa/index.html
@@ -0,0 +1,6 @@
+---
+layout: index
+title: Guías de código abierto
+lang: es
+permalink: /es/
+---
diff --git a/_articles/fa/leadership-and-governance.md b/_articles/fa/leadership-and-governance.md
new file mode 100644
index 00000000000..b8006c30107
--- /dev/null
+++ b/_articles/fa/leadership-and-governance.md
@@ -0,0 +1,165 @@
+---
+lang: en
+title: Leadership and Governance
+description: Growing open source projects can benefit from formal rules for making decisions.
+class: leadership
+toc:
+  understanding-governance-for-your-growing-project: "Understanding governance for your growing project"
+  what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?"
+  how-do-i-formalize-these-leadership-roles: "How do I formalize these leadership roles?"
+  when-should-i-give-someone-commit-access: "When should I give someone commit access?"
+  what-are-some-of-the-common-governance-structures-for-open-source-projects: "What are some of the common governance structures for open source projects?"
+  do-i-need-governance-docs-when-i-launch-my-project: "Do I need governance docs when I launch my project?"
+  what-happens-if-corporate-employees-start-submitting-contributions: "What happens if corporate employees start submitting contributions?"
+  do-i-need-a-legal-entity-to-support-my-project: "Do I need a legal entity to support my project?"
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+  - best-practices
+  - metrics
+---
+
+## Understanding governance for your growing project
+
+Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+
+## What are examples of formal roles used in open source projects?
+
+Many projects follow a similar structure for contributor roles and recognition.
+
+What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+
+* **Maintainer**
+* **Contributor**
+* **Committer**
+
+**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+
+A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+
+**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+  </p>
+</aside>
+
+**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+
+While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
+  You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+  <p markdown="1" class="pquote-credit">
+— @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+  </p>
+</aside>
+
+## How do I formalize these leadership roles?
+
+Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+
+For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+
+For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+
+If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+
+<aside markdown="1" class="pquote">
+  \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+  <p markdown="1" class="pquote-credit">
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+  </p>
+</aside>
+
+Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+
+Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+
+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).
+
+## When should I give someone commit access?
+
+Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
+  Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+  <p markdown="1" class="pquote-credit">
+— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+  </p>
+</aside>
+
+## What are some of the common governance structures for open source projects?
+
+There are three common governance structures associated with open source projects.
+
+* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+
+* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+
+* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
+
+Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Do I need governance docs when I launch my project?
+
+There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+
+Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+
+If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
+  We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+  <p markdown="1" class="pquote-credit">
+— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+  </p>
+</aside>
+
+## What happens if corporate employees start submitting contributions?
+
+Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+
+As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+
+It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+
+"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+
+Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+
+## Do I need a legal entity to support my project?
+
+You don't need a legal entity to support your open source project unless you're handling money.
+
+For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+
+If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+
+Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
+  Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+  <p markdown="1" class="pquote-credit">
+— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+  </p>
+</aside>
+
+If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
new file mode 100644
index 00000000000..ed6cf093fd5
--- /dev/null
+++ b/_articles/fa/legal.md
@@ -0,0 +1,166 @@
+---
+lang: en
+title: The Legal Side of Open Source
+description: Everything you've ever wondered about the legal side of open source, and a few things you didn't.
+class: legal
+toc:
+  why-do-people-care-so-much-about-the-legal-side-of-open-source: "Why do people care so much about the legal side of open source?"
+  are-public-github-projects-open-source: "Are public GitHub projects open source?"
+  just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Just give me the TL;DR on what I need to protect my project"
+  which-open-source-license-is-appropriate-for-my-project: "Which open source license is appropriate for my project?"
+  what-if-i-want-to-change-the-license-of-my-project: "What if I want to change the license of my project?"
+  does-my-project-need-an-additional-contributor-agreement: "Does my project need an additional contributor agreement?"
+  what-does-my-companys-legal-team-need-to-know: "What does my company’s legal team need to know?"
+order: 10
+image: /assets/images/cards/legal.png
+related:
+  - contribute
+  - leadership
+---
+
+## Understanding the legal implications of open source
+
+Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+
+## Why do people care so much about the legal side of open source?
+
+Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+
+In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+
+If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+
+Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
+
+## 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**.
+
+![Create repository](/assets/images/legal/repo-create-name.png)
+
+**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+
+If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+
+## Just give me the TL;DR on what I need to protect my project.
+
+You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+
+[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 the most popular open source 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/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
+  A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+  <p markdown="1" class="pquote-credit">
+— @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+  </p>
+</aside>
+
+## Which open source license is appropriate for my project?
+
+If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+
+Otherwise, picking the right open source license for your project depends on your objectives.
+
+Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+
+On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+
+You may also want to consider the **communities** you hope will use and contribute to your project:
+
+* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
+* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
+* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+
+Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+
+When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+
+## What if I want to change the license of my project?
+
+Most projects never need to change licenses. But occasionally circumstances change.
+
+For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+
+**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+
+**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+
+**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+
+Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+
+## 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).
+
+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.
+
+Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
+    We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+  <p markdown="1" class="pquote-credit">
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+  </p>
+</aside>
+
+Some situations where you may want to consider an additional contributor agreement for your project include:
+
+* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
+* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
+* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
+* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
+* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
+
+If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+
+## What does my company's legal team need to know?
+
+If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+
+For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+
+**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+
+* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+
+* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+
+* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
+
+* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+
+* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+
+If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+
+Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+
+* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
+  Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+  <p markdown="1" class="pquote-credit">
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+  </p>
+</aside>
+
+* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
+* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+
+<aside markdown="1" class="pquote">
+  Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+  <p markdown="1" class="pquote-credit">
+— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+  </p>
+</aside>
+
+* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
+* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
diff --git a/_articles/fa/metrics.md b/_articles/fa/metrics.md
new file mode 100644
index 00000000000..080b3eea9d4
--- /dev/null
+++ b/_articles/fa/metrics.md
@@ -0,0 +1,132 @@
+---
+lang: en
+title: Open Source Metrics
+description: Make informed decisions to help your open source project thrive by measuring and tracking its success.
+class: metrics
+toc:
+  why-measure-anything: "Why measure anything?"
+  discovery: "Discovery"
+  usage: "Usage"
+  retention: "Retention"
+  maintainer-activity: "Maintainer activity"
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+  - finding
+  - best-practices
+---
+
+## Why measure anything?
+
+Data, when used wisely, can help you make better decisions as an open source maintainer.
+
+With more information, you can:
+
+* Understand how users respond to a new feature
+* Figure out where new users come from
+* Identify, and decide whether to support, an outlier use case or functionality
+* Quantify your project's popularity
+* Understand how your project is used
+* Raise money through sponsorships and grants
+
+For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+
+> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+
+Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+
+If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+
+## Discovery
+
+Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+
+![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:
+
+* **Total page views:** Tells you how many times your project was viewed
+
+* **Total unique visitors:** Tells you how many people viewed your project
+
+* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+
+* **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.
+
+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.
+
+## Usage
+
+People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+
+If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+
+Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+
+If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+
+![Clone graph](/assets/images/metrics/clone_graph.png)
+
+If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+
+* Your project isn't successfully converting your audience, or
+* You're attracting the wrong audience
+
+For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+
+Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+
+Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+
+## Retention
+
+People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+
+It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+
+Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+
+Examples of community metrics that you may want to regularly track include:
+
+* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+
+![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+
+* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+
+* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+
+* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+
+* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
+  Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+  <p markdown="1" class="pquote-credit">
+— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+  </p>
+</aside>
+
+## Maintainer activity
+
+Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+
+Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+
+[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+
+Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+
+You could also measure the time it takes to move between stages in the contribution process, such as:
+
+* Average time an issue remains open
+* Whether issues get closed by PRs
+* Whether stale issues get closed
+* Average time to merge a pull request
+
+## Use 📊 to learn about people
+
+Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md
new file mode 100644
index 00000000000..1ace069082f
--- /dev/null
+++ b/_articles/fa/starting-a-project.md
@@ -0,0 +1,362 @@
+---
+lang: en
+title: Starting an Open Source Project
+description: Learn more about the world of open source and get ready to launch your own project.
+class: beginners
+toc:
+  the-what-and-why-of-open-source: "The what and why of open source"
+  should-i-launch-my-own-open-source-project: "Should I launch my own open source project?"
+  launching-your-own-open-source-project: "Launching your own open source project"
+  naming-and-branding-your-project: "Naming and branding your project"
+  your-pre-launch-checklist: "Your pre-launch checklist"
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+  - finding
+  - building
+---
+
+## The "what" and "why" of open source
+
+So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+
+### What does "open source" mean?
+
+When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+
+Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+
+_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+
+### Why do people open source their work?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+  One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+  <p markdown="1" class="pquote-credit">
+— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+  </p>
+</aside>
+
+[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+
+* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+
+* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+
+Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+
+### Does open source mean "free of charge"?
+
+One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+
+Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+
+As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+
+## Should I launch my own open source project?
+
+The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+
+If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+
+Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+
+If you're not yet convinced, take a moment to think about what your goals might be.
+
+### Setting your goals
+
+Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself,  _why am I open sourcing this project?_
+
+There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+
+If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+  At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+  <p markdown="1" class="pquote-credit">
+— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+  </p>
+</aside>
+
+As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+
+While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+
+**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+
+If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+  As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+  <p markdown="1" class="pquote-credit">
+— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+  </p>
+</aside>
+
+### Contributing to other projects
+
+If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+
+If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+
+## Launching your own open source project
+
+There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+
+Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+
+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/)
+* [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.
+
+If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+
+### Choosing a license
+
+An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+
+Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+
+[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 the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+
+When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+
+![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+
+If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+
+### Writing a README
+
+READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+
+In your README, try to answer the following questions:
+
+* What does this project do?
+* Why is this project useful?
+* How do I get started?
+* Where can I get more help, if I need it?
+
+You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+  Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+  <p markdown="1" class="pquote-credit">
+— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+  </p>
+</aside>
+
+Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+
+For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+
+When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+
+### Writing your contributing guidelines
+
+A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+
+* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
+* How to suggest a new feature
+* How to set up your environment and run tests
+
+In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+
+* The types of contributions you're looking for
+* Your roadmap or vision for the project
+* How contributors should (or should not) get in touch with you
+
+Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+
+For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+
+> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+
+In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+
+Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+
+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.
+
+![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+
+### Establishing a code of conduct
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+  We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+  <p markdown="1" class="pquote-credit">
+— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+  </p>
+</aside>
+
+Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+
+For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+
+In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+
+Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+
+Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+
+## Naming and branding your project
+
+Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+
+### Choosing the right name
+
+Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+
+* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
+* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+
+If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+
+Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+
+### Avoiding name conflicts
+
+[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+
+If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+
+Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+
+You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+
+Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+
+### How you write (and code) affects your brand, too!
+
+Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+
+Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+  <p markdown="1" class="pquote-credit">
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+
+Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+
+It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+
+## 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.
+
+**Documentation**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Project has a LICENSE file with an open source license
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    The issue queue is up-to-date, with issues clearly organized and labeled
+  </label>
+</div>
+
+**Code**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Project uses consistent code conventions and clear function/method/variable names
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    The code is clearly commented, documenting intentions and edge cases
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+  </label>
+</div>
+
+**People**
+
+If you're an individual:
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  </label>
+</div>
+
+If you're a company or organization:
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    You've talked to your legal department
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    You have a marketing plan for announcing and promoting the project
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    At least two people have administrative access to the project
+  </label>
+</div>
+
+## You did it!
+
+Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.

From 507a96461ec1a3e067d98805d27fbe82e8c1810f Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Thu, 18 Mar 2021 19:05:47 +0330
Subject: [PATCH 139/749] First paragraphs translated.

---
 _articles/fa/best-practices.md | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md
index c1894f66eaf..a0726de88fd 100644
--- a/_articles/fa/best-practices.md
+++ b/_articles/fa/best-practices.md
@@ -3,13 +3,6 @@ lang: fa
 title: بهترین روال‌های تجربه شده برای نگهدارنده‌ها
 description: زندگی خود را به عنوان یک نگهدارنده‌ی اوپن سورس آسان‌تر کنید؛ از ثبت‌کردن فرآیندها گرفته تا بهره‌بردن از اجتماع‌تان.
 class: best-practices
-toc:
-  what-does-it-mean-to-be-a-maintainer: "What does it mean to be a maintainer?"
-  documenting-your-processes: "Documenting your processes"
-  learning-to-say-no: "Learning to say no"
-  leverage-your-community: "Leverage your community"
-  bring-in-the-robots: "Bring in the robots"
-  its-okay-to-hit-pause: "It’s okay to hit pause"
 order: 5
 image: /assets/images/cards/best-practices.png
 related:
@@ -17,13 +10,14 @@ related:
   - leadership
 ---
 
-## What does it mean to be a maintainer?
+## نگهدارنده بودن به چه معناست؟
 
-If you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more.
+اگر شما نگه‌دارنده‌ی پروژه‌ای اوپن سورس باشید که افراد زیادی از آن استفاده می‌کنند، حتما متوجه شده‌اید که کمتر مشغول به کدنویسی هستید و بیشتر نقش پاسخگویی به مشکلات را بر عهده‌ی خود دارید.
 
-In the early stages of a project, you're experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you'll find yourself working with your users and contributors more.
+در مراحل اولیه‌ی هر پروژه‌ای، شما ایده‌های جدیدی را امتحان می‌کنید و بر اساس آنچه می‌خواهید تصمیم‌گیری می‌کنید. با افزایش محبوبیت پروژه، متوجه می‌شوید که بیشتر مشغول کار با کاربران و همکاران خود خواهید بود.
+
+نگهداری یک پروژه، به چیزی بیشتر از کدنویسی نیاز دارد. این وظایف اغلب به صورت ناگهانی پیش می‌آیند؛ اما آن‌ها به همان اندازه‌ی پروژه‌ی در حال رشد مهم هستند. ما برای آسان‌تر کردن زندگی‌تان چند روش آماده کرده‌ایم؛ از مراحل ثبت کردن فرآیند گرفته تا بهره‌بردن از اجتماع‌تان.
 
-Maintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community.
 
 ## Documenting your processes
 

From bcf76c0dbe40f0db46b7e77c4b745eae59396da9 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 22 Mar 2021 09:44:44 +0000
Subject: [PATCH 140/749] Bump github-pages from 212 to 213

Bumps [github-pages](https://github.com/github/pages-gem) from 212 to 213.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v212...v213)

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 42d5cd25d92..2ed05c41e01 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -34,7 +34,7 @@ GEM
     ffi (1.15.0)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (212)
+    github-pages (213)
       github-pages-health-check (= 1.17.0)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
@@ -50,7 +50,7 @@ GEM
       jekyll-readme-index (= 0.3.0)
       jekyll-redirect-from (= 0.16.0)
       jekyll-relative-links (= 0.6.1)
-      jekyll-remote-theme (= 0.4.2)
+      jekyll-remote-theme (= 0.4.3)
       jekyll-sass-converter (= 1.5.2)
       jekyll-seo-tag (= 2.7.1)
       jekyll-sitemap (= 1.4.0)
@@ -144,7 +144,7 @@ GEM
       jekyll (>= 3.3, < 5.0)
     jekyll-relative-links (0.6.1)
       jekyll (>= 3.3, < 5.0)
-    jekyll-remote-theme (0.4.2)
+    jekyll-remote-theme (0.4.3)
       addressable (~> 2.0)
       jekyll (>= 3.5, < 5.0)
       jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0)
@@ -218,9 +218,9 @@ GEM
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
-    minitest (5.14.3)
+    minitest (5.14.4)
     multipart-post (2.1.1)
-    nokogiri (1.11.1)
+    nokogiri (1.11.2)
       mini_portile2 (~> 2.5.0)
       racc (~> 1.4)
     nokogumbo (2.0.4)

From 5eb776659224964fa18ac44a3a3c44af5f4842fb Mon Sep 17 00:00:00 2001
From: Chris Su <cs.akasuv@gmail.com>
Date: Mon, 29 Mar 2021 11:31:02 +0800
Subject: [PATCH 141/749] Replace more appropriate phrase in Chinese

The original translation is more creative than accurate. Being creative is good, but I think it's more important to deliver the exact meaning that the author intends to express to readers.
---
 _articles/zh-hans/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/how-to-contribute.md b/_articles/zh-hans/how-to-contribute.md
index 3f72258f5a5..59d5093a133 100644
--- a/_articles/zh-hans/how-to-contribute.md
+++ b/_articles/zh-hans/how-to-contribute.md
@@ -29,7 +29,7 @@ redirect_from: /zh-cn/how-to-contribute/
 
 无论是撰写代码、设计用户界面、图形设计、撰写文档、亦或是组织活动，假如你有实践的愿望，你总能在开源项目中找到自己的位置。
 
-### 遇见那些和你"臭味相投"的人
+### 遇见那些和你志趣相投之人
 
 开源项目一般都会有一个和谐、热心的社区，以让大家团结一致。实际上，开源界经常发生这样的情形，很多人的深厚友谊都是通过共同参与开源所建立起来的，至于具体的方式，可能是在一次技术研讨会上相谈甚欢，也可能是一直在聊天室中探讨问题。
 

From f91c5020413032adde481e6ca40fd47beac6c2ec Mon Sep 17 00:00:00 2001
From: koviubi56 <58398849+koviubi56@users.noreply.github.com>
Date: Tue, 30 Mar 2021 15:09:24 +0200
Subject: [PATCH 142/749] Fixed the WordPress link

---
 _articles/hu/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/hu/starting-a-project.md b/_articles/hu/starting-a-project.md
index e9501edb923..28ef6528c3d 100644
--- a/_articles/hu/starting-a-project.md
+++ b/_articles/hu/starting-a-project.md
@@ -36,7 +36,7 @@ _Free software_ kifejezés ugyanazokra a projektekre vonatkozik, mint amire az _
 
 * **Együttműködés:** A nyílt forráskódú projektek bárkitől elfogadnak módosítást a világ bármely részéről. [Exercism](https://github.com/exercism/), például egy programozási gyakorlást segítő projekt több, mint 350 fejlesztő részvételével.
 
-* **Elterjedés és újrafelhasználás:** A nyílt forráskódú projekteket bárki használhatja szinte bármilyen célra. Az emberek akár más dolgok létrehozására is felhasználhatják. A [WordPress] (https://github.com/WordPress) például úgy kezdte, hogy egy létező, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) nevű projektet elágaztattak.
+* **Elterjedés és újrafelhasználás:** A nyílt forráskódú projekteket bárki használhatja szinte bármilyen célra. Az emberek akár más dolgok létrehozására is felhasználhatják. A [WordPress](https://github.com/WordPress) például úgy kezdte, hogy egy létező, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) nevű projektet elágaztattak.
 
 * **Átláthatóság:** A nyílt forráskódú projektet bárki megvizsgálhatja, vagy hibákat kereshet benne. Az átláthatóság a kormányoknak is fontos, mint ahogy [Bulgária](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) teszi ezt, vagy ahogy az [Amerikai Egyesült Államok](https://sourcecode.cio.gov/) szabályozza a bank, és egészségügy iparát, de fontos a biztonsági szoftverek esetén is, mint a [Let's Encrypt](https://github.com/letsencrypt).
 

From 62251451a7cba23cccb0769b579b2eaf9f6b846d Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 1 Apr 2021 08:44:14 +0000
Subject: [PATCH 143/749] Bump github-pages from 213 to 214

Bumps [github-pages](https://github.com/github/pages-gem) from 213 to 214.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v213...v214)

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 2ed05c41e01..7b77fd0ca88 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (6.0.3.5)
+    activesupport (6.0.3.6)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
@@ -34,7 +34,7 @@ GEM
     ffi (1.15.0)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (213)
+    github-pages (214)
       github-pages-health-check (= 1.17.0)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
@@ -70,7 +70,7 @@ GEM
       jekyll-theme-time-machine (= 0.1.1)
       jekyll-titles-from-headings (= 0.5.3)
       jemoji (= 0.12.0)
-      kramdown (= 2.3.0)
+      kramdown (= 2.3.1)
       kramdown-parser-gfm (= 1.1.0)
       liquid (= 4.0.3)
       mercenary (~> 0.3)
@@ -204,12 +204,12 @@ GEM
       gemoji (~> 3.0)
       html-pipeline (~> 2.2)
       jekyll (>= 3.0, < 5.0)
-    kramdown (2.3.0)
+    kramdown (2.3.1)
       rexml
     kramdown-parser-gfm (1.1.0)
       kramdown (~> 2.0)
     liquid (4.0.3)
-    listen (3.4.1)
+    listen (3.5.1)
       rb-fsevent (~> 0.10, >= 0.10.3)
       rb-inotify (~> 0.9, >= 0.9.10)
     mercenary (0.3.6)

From 5f7044a44d277eacbf646100641a3f76dd19e1bd Mon Sep 17 00:00:00 2001
From: Liu Xing <meteormatt@users.noreply.github.com>
Date: Fri, 2 Apr 2021 11:27:32 +0800
Subject: [PATCH 144/749] Corrections for words

---
 _articles/zh-hans/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index 70f3811d41b..314eef32804 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -131,7 +131,7 @@ redirect_from: /zh-cn/legal/
 * **隐私：**你们的项目是否收集了用户数据并存储到公司的服务器？你们的法律团队可以帮助你们遵守公司政策和外部法规。
 
 如果你们发布了公司的第一开源项目，为了能通过，以上这些绰绰有余（不要担心，大多数项目不会引起重大关注）。
-长期来说，们的法律团队可以做更多的事情，以帮助公司从开源中获得更多，并保持安全：
+长期来说，你们的法律团队可以做更多的事情，以帮助公司从开源中获得更多，并保持安全：
 
 * **员工贡献策略：**考虑制定一个公司策略，指明你们的员工如何为开源项目贡献。明确的政策将减少你们员工的迷惑，并帮助他们为公司的最佳利益向开源项目做贡献，无论是作为他们工作的一部分还是在自由时间。Rackspace的[Model IP和开源贡献策略](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)就是很好的示例。
 

From e9d4557a95e9e96006e80da938d1168ddeebeae7 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 12 Apr 2021 10:15:00 +0000
Subject: [PATCH 145/749] Bump html-proofer from 3.18.8 to 3.19.0

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.18.8 to 3.19.0.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.18.8...v3.19.0)

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 7b77fd0ca88..4086bbc0959 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -22,8 +22,8 @@ GEM
     em-websocket (0.5.2)
       eventmachine (>= 0.12.9)
       http_parser.rb (~> 0.6.0)
-    ethon (0.12.0)
-      ffi (>= 1.3.0)
+    ethon (0.13.0)
+      ffi (>= 1.15.0)
     eventmachine (1.2.7)
     execjs (2.7.0)
     faraday (1.3.0)
@@ -87,7 +87,7 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.18.8)
+    html-proofer (3.19.0)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)
@@ -220,10 +220,10 @@ GEM
       jekyll-seo-tag (~> 2.1)
     minitest (5.14.4)
     multipart-post (2.1.1)
-    nokogiri (1.11.2)
+    nokogiri (1.11.3)
       mini_portile2 (~> 2.5.0)
       racc (~> 1.4)
-    nokogumbo (2.0.4)
+    nokogumbo (2.0.5)
       nokogiri (~> 1.8, >= 1.8.4)
     octokit (4.20.0)
       faraday (>= 0.9)

From fe6e76f6060bef45752da0aea2426505df454b75 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 14 Apr 2021 08:28:06 +0000
Subject: [PATCH 146/749] Bump actions/cache from v2.1.4 to v2.1.5

Bumps [actions/cache](https://github.com/actions/cache) from v2.1.4 to v2.1.5.
- [Release notes](https://github.com/actions/cache/releases)
- [Commits](https://github.com/actions/cache/compare/v2.1.4...1a9e2138d905efd099035b49d8b7a3888c653ca8)

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 1c421941949..27f8a14d6a8 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -17,7 +17,7 @@ jobs:
       uses: actions/setup-node@v2.1.5
 
     - name: Restore bundler cache
-      uses: actions/cache@v2.1.4
+      uses: actions/cache@v2.1.5
       with:
         path: vendor/gems
         key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}

From 5cccdbd611d6b573f5b972c36e772bc1b6e395d7 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Wed, 14 Apr 2021 15:43:19 +0430
Subject: [PATCH 147/749] first one has just finished.

Translation first article has just finished.
---
 _articles/fa/best-practices.md | 240 +++++++++++++++++----------------
 _articles/fa/index.html        |   6 +-
 2 files changed, 130 insertions(+), 116 deletions(-)

diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md
index a0726de88fd..8a7a7b9006d 100644
--- a/_articles/fa/best-practices.md
+++ b/_articles/fa/best-practices.md
@@ -19,263 +19,277 @@ related:
 نگهداری یک پروژه، به چیزی بیشتر از کدنویسی نیاز دارد. این وظایف اغلب به صورت ناگهانی پیش می‌آیند؛ اما آن‌ها به همان اندازه‌ی پروژه‌ی در حال رشد مهم هستند. ما برای آسان‌تر کردن زندگی‌تان چند روش آماده کرده‌ایم؛ از مراحل ثبت کردن فرآیند گرفته تا بهره‌بردن از اجتماع‌تان.
 
 
-## Documenting your processes
+## ثبت کردن فرآیندها
 
-Writing things down is one of the most important things you can do as a maintainer.
+نوشتن مطالب، یکی از مهم‌ترین کارهایی است که می‌توانید به عنوان نگهدارنده انجام دهید.
 
-Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask.
+ثبت کردن مطالب، نه تنها باعث شفافیت تفکر شما می‌شود، بلکه به دیگران کمک می‌کند تا حتی بدون پرسیدن سوالی، با احتیاجات و انتظارات شما آشنا شوند.
 
-Writing things down makes it easier to say no when something doesn't fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project.
+نوشتن مطالب، نه گفتن به چیزی که به درد شما نمی‌خورد را آسان‌تر می‌کند. همچنین فرآیند کمک کردن به شما را برای سایرین آسان‌تر می‌کند. شما هرگز نمی‌دانید که چه کسی ممکن است پروژه‌ی شما را مطالعه یا از آن استفاده کند.
 
-Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all.
+حتی اگر از پاراگراف‌های طولانی استفاده نمی‌کنید!، نوشتن نکات مهم بهتر از چیزی ننوشتن است.
 
-Remember to keep your documentation up-to-date. If you're not able to always do this, delete your outdated documentation or indicate it is outdated so contributors know updates are welcome.
+به یاد داشته باشید که نوشتن مطالب را به روز نگه دارید. اگر همیشه قادر به انجام این کار نیستید، مطالب قدیمی خود را حذف کنید یا مشخص کنید که این مطالب  منسوخ شده‌اند تا مانع به روز رسانی‌های مشارکت‌کنندگان نشوید.
 
-### Write down your project's vision
 
-Start by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well.
+### چشم انداز خودتان از پروژه را یادداشت کنید
 
-Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions.
+با نوشتن هدف‌های خودتان از پروژه، شروع کنید. آن‌ها را به «README» (من را بخوانید) خود اضافه کنید یا یک فایل جداگانه به نام  «VISION » (چشم انداز) ایجاد کنید. اگر موارد دیگری وجود دارد که می‌تواند به شما کمک کند؛ مانند نقشه‌ی راه پروژه، آن‌ها را نیز به صورت عمومی منتشر کنید.
 
-For example, @lord discovered that having a project vision helped him figure out which requests to spend time on. As a new maintainer, he regretted not sticking to his project's scope when he got his first feature request for [Slate](https://github.com/lord/slate).
+داشتن چشم‌اندازی واضح و ثبت شده، شما را متمرکز نگه می‌دارد و به شما کمک می‌کند تا از بسط یا تغییرات در اهداف اولیه جلوگیری شود.
+
+به عنوان مثال، @lord، متوجه شد که داشتن چشم‌انداز پروژه به او کمک می‌کند تا بفهمد برای کدام درخواست‌ها وقت بگذارد. به عنوان یک نگهدارنده‌ی جدید، وقتی اولین درخواست خود را برای [Slate](https://github.com/lord/slate) دریافت کرد، از عدم پایبندی به اهداف پروژه‌ی خود پشیمان شد.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
-  I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of an half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
+	دستپاچه شدم. تلاشی نکردم تا به راه‌حلی کامل دست پیدا کنم. ای کاش به جای یک راه‌حل بی‌فکر، می‌گفتم: «الان برای این وقت ندارم، اما آن را به لیست بلند مدت خودم اضافه کردم».
   <p markdown="1" class="pquote-credit">
 — @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
   </p>
 </aside>
 
-### Communicate your expectations
+### انتظارات خود را اعلام کنید
+
+نوشتن قوانین، می‌تواند اعصاب خردکن باشد. گاهی اوقات ممکن است این حس را داشته باشید که در حال کنترل رفتار دیگران و یا از بین بردن هیجان و لذت در میان دیگران هستید.
 
-Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun.
+با این حال، اگر قوانین، مناسب و به طور عادلانه‌ای نوشته و اجرا شوند باعث نگهداری هر چه بهتر می‌شوند. این قوانین، جلوی کارهایی که نمی‌خواهید انجام دهید را می‌گیرد.
 
-Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do.
+اکثر افرادی که با پروژه‌ی شما روبرو می‌شوند، چیزی از شما و شرایط شما نمی‌دانند. ممکن است فرض کنند که شما برای کار کردن بر روی پروژه حقوق می‌گیرید، به ویژه اگر آن پروژه چیزی باشد که آن‌ها مرتباً استفاده می‌کنند و به آن وابستگی دارند. ممکن است زمانی وقت زیادی را صرف پروژه‌ی خود می‌کردید، اما اکنون مشغول کار یا گذران زمان با خانواده‌ی خود هستید.
 
-Most people who come across your project don't know anything about you or your circumstances. They may assume you get paid to work on it, especially if it's something they regularly use and depend on. Maybe at one point you put a lot of time into your project, but now you're busy with a new job or family member.
+شما مرتکب کار اشتباهی نشده‌اید! ولی اطمینان حاصل کنید که بقیه‌ هم راجع به این مسائل اطلاع داشته باشند.
 
-All of this is perfectly okay! Just make sure other people know about it.
+اگر نگهداری پروژه برای شما کاری نیمه وقت است یا کاملاً داوطلبانه است، درمورد آن صادق باشید و روشن کنید که چقدر زمان برای این کار دارید. این مسئله با میزان زمانی که شما فکر می‌کنید پروژه به آن نیاز دارد یا مدت زمانی که دیگران می‌خواهند شما در آن صرف کنید، یکی نیست و با هم فرق می‌کند.
 
-If maintaining your project is part-time or purely volunteered, be honest about how much time you have. This is not the same as how much time you think the project requires, or how much time others want you to spend.
+در اینجا چند قانون داریم که به یاد داشتن آن‌ها ارزش دارد:
 
-Here are a few rules that are worth writing down:
+* مشارکت چگونه تعریف و پذیرفته می‌شود (_آیا نیاز به آزمون دارد؟ یا قالب طرح مشکل؟_)
+* انواع مشارکت‌هایی که می‌پذیرید (_آیا فقط برای قسمت‌های خاصی از کد خود کمک می‌خواهید؟_)
+* چه زمانی برای پیگیری مناسب است (_به عنوان مثال، «شما در طی 7 روز از  نگهدارنده می‌توانید انتظار پاسخگویی داشته باشید. اگر تا آن موقع خبری نشد، یادآوری کنید._)
+* چه مدت زمان صرف پروژه می‌کنید (_به عنوان مثال، «ما فقط 5 ساعت در هفته برای این پروژه وقت می‌گذاریم»_)
 
-* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_)
-* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_)
-* When it's appropriate to follow up (_for example, "You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread."_)
-* How much time you spend on the project (_for example, "We only spend about 5 hours per week on this project"_)
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), و [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) نمونه‌هایی از پروژه‌ها با دستور‌العمل‌هایی برای نگهدارندگان و مشارکت‌کنندگان هستند.
 
-[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors.
+### ابلاغیه‌های خود را به صورت عمومی اعلام کنید
 
-### Keep communication public
+تعاملات خود با بیرون را نیز ثبت کنید. در هر جایی که ممکن بود، ابلاغیه‌های مربوط به پروژ‌ه‌ی خود را به صورت عمومی اعلام کنید. اگر کسی خواست که به طور خصوصی درباره‌ی درخواستی یا پشتیبانی با شما به گفتگو بپردازد، مودبانه او را به کانال ارتباطی عمومی، همچون فهرست پستی (mailing list) یا «issue tracker» هدایت کنید.
 
-Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker.
+اگر با سایر نگهدارنده‌ها ملاقات کردید یا در خلوت تصمیم مهمی گرفتید، این مکالمه‌ها را به صورت عمومی ثبت کنید؛ حتی اگر بخواهد به صورت پست کردن یادداشت‌هایتان باشد.
 
-If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes.
+به این ترتیب، هر کسی که به انجمن شما بپیوندد به همان اطلاعاتی که سال‌ها در آنجا بوده است، دسترسی خواهد داشت.
 
-That way, anybody who joins your community will have access to the same information as someone who's been there for years.
 
-## Learning to say no
+## نه گفتن، را یاد بگیرید
 
-You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists.
+شما مطالب خود را ثبت کردید. در حالت ایده آل، همه نوشته‌ها و مستندات شما را می‌خوانند، اما در واقع، شما باید به دیگران وجود این اطلاعات را نیز یادآوری کنید.
 
-Having everything written down, however, helps depersonalize situations when you do need to enforce your rules.
+درصورتی که لازم باشد قوانین خود را اجرا کنید، با نوشتن و ثبت کردن همه چیز، به شما کمک می‌کند تا شرایط را از حالت شخصی‌سازی شده در‌آورید.
 
-Saying no isn't fun, but  _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_.
+نه گفتن، لذت‌بخش نیست؛ اما گفتن «مشارکت شما با معیارهای این پروژه مطابقت ندارد» کمتر از «من مشارکت با شما را دوست ندارم»، به شخصیت طرف برمی‌خورد.
 
-Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others.
+نه گفتن در بسیاری از شرایطی که به عنوان نگهدارنده با آن روبرو خواهید شد، به کار می‌آید: درخواست‌هایی که با ویژگی‌های پروژه‌ی شما متناسب نیستند، کسی که بحث را به بیراهه می‌کشاند، انجام کارهای غیرضروری برای دیگران.
 
-### Keep the conversation friendly
 
-One of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept.
+### دوستانه با دیگران ارتباط برقرار کنید
 
-Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor.
+یکی از مهم‌ترین جاهایی که شما باید تمرین نه گفتن را انجام دهید، در سر برخی از مسائل و «درخواست‌های pull» ای است که از شما می‌شود. به عنوان نگهدارنده‌ی پروژه، ناگزیر پیشنهادهایی دریافت خواهید کرد که نمی‌خواهید آن‌ها را بپذیرید.
 
-Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards.
+چونکه شاید آن مشارکت، اهداف پروژه‌ی شما را تغییر دهد یا با چشم‌انداز شما مطابقت نداشته باشد. یا شاید ایده خوب باشد، ولی اجرای آن ضعیف باشد.
 
-If you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community.
+صرف نظر از هرچه که دلیل بخواهد باشد، می‌توان مشارکت‌هایی را که مطابق با استانداردهای پروژه‌ی شما نیستند را با درایت مدیریت کرد.
+
+اگر مشارکتی به شما پیشنهاد بشود که نخواهید آن را بپذیرید؛ اولین واکنش شما ممکن است نادیده گرفتن آن یا تظاهر به ندیدن آن باشد. انجام این کار می‌تواند به احساسات طرف مقابل ضربه بزند و حتی باعث کاهش انگیزه‌ی سایر مشارکت‌کنندگان بالقوه‌ی اجتماع (community) شما شود.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
-  The key to handle support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS.
+	 نکته‌ی مهم در مدیریت پروژه‌های اوپن سورس در مقیاسی بزرگ، حرکت رو به جلو است. سعی کنید از ماندگاری مسائل و مشکلات، جلوگیری کنید. اگر توسعه‌دهنده‌ی iOS باشید، می‌دانید که این مسائل چقدر طاقت‌فرسا هستند. ممکن است 2 سال بعد دوباره این مسائل به سراغ شما بیاد و به شما گفته شود که با آخرین نسخه iOS دوباره امتحان کنید.
   <p markdown="1" class="pquote-credit">
 — @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
   </p>
 </aside>
 
-Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.
+مشارکت ناخواسته را صرف اینکه آدم خوبی به نظر برسید، ادامه ندهید زیرا در ادامه‌ی راه احساس گناه خواهید کرد. با گذشت زمان، مسائل و روابط عمومی بی‌پاسخ باعث می‌شود که کارتان روی پروژه بسیار استرس‌زا و ترسناک پیش برود. 
 
-It's better to immediately close the contributions you know you don't want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+بهتر است فوراً به مشارکت‌هایی که آن‌ها را نمی‌خواهید، پایان دهید. اکر پروژه شما از کمبود بک لاگ رنج می برد, @steveklabnik در مقاله [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) پیشنهاداتی در این خصوص ارائه کرده است.
 
-Secondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it's someone's first time. Even if you don't accept their contribution, acknowledge the person behind it and thank them for their interest. It's a big compliment!
+ثانیاً، بی‌توجهی به مشارکت‌هایتان، سیگنال‌های منفی‌ای به درون اجتماع می‌فرستد. مشارکت در هر پروژه‌ای می‌تواند دلهره‌آور باشد، خصوصاً اگر برای اولین بار باشد که در پروژه‌ای شرکت می‌کنید. حتی اگر مشارکت آن‌ها را قبول نکردید، از آن شخص تشکر کرده و از توجه او سپاسگزار باشید. کار پسندیده‌ای است!
 
-If you don't want to accept a contribution:
+اگر نمی‌خواهید مشارکت کسی را قبول کنید:
 
-* **Thank them** for their contribution
-* **Explain why it doesn't fit** into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm.
-* **Link to relevant documentation**, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself.
-* **Close the request**
+* از توجه آن‌ها **تشکر کنید**.
+* **توضیح دهید که چرا نمی‌توانید با آن‌ها همکاری داشته باشید** و اگر می‌توانید، پیشنهادهای واضحی را برای بهبود آن‌ها برای آینده ارائه دهید؛ مهربان باشید، اما مصمم.
+* در صورت داشتن دسترسی، آن‌ها را **به مستندات مربوطه ارجاع دهید**. اگر با درخواست‌های مکرر برای مواردی که نمی‌خواهید آن‌ها را بپذیرید، مواجه شدید؛ آن موارد را برای جلوگیری از مکررات به مستندات خود اضافه کنید. 
+* **درخواست مشارکت را ببندید**.
 
-You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):
+شما به 1 یا 2 جمله بیشتر، برای پاسخگویی نیاز نخواهید داشت. به عنوان مثال، هنگامی که [celery](https://github.com/celery/celery/)، خطایی مربوط به ویندوز را گزارش داد، «berkerpeksag» [اینگونه پاسخ](https://github.com/celery/celery/issues/3383) داد:
 
 ![Celery screenshot](/assets/images/best-practices/celery.png)
 
-If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):
+اگر فکر نه گفتن شما را وحشت زده می‌کند، بدانید که شما تنها نیستید. همانطور که @jessfraz می‌گوید:
+
+> من با نگهدارنده‌هایی از پروژه‌های اوپن سورس مختلف مانندMesos» ،«Kubernetes» «Chromium صحبت کرده‌ام و همه موافق هستند که یکی از سخت‌ترین قسمت‌های نگهدارنده بودن، «نه» گفتن به اصلاحاتی است که نمی‌خواهید.
 
-> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want.
+در نپذیرفتن پیشنهاد مشارکت کسی، احساس گناه نکنید. [طبق گفته‌ی](https://twitter.com/solomonstre/status/715277134978113536) @shykes، اولین قانون پروژه‌های اوپن سورس این است که: «نه موقتی‌ست، بله برای همیشه».  در حالی که همدردی با اشتیاق فرد دیگر، چیز پسندیده‌ای است؛ اما رد کردن پیشنهاد مشارکت به معنای رد کردن هویت فرد پشت سر آن پیشنهاد نیست.
 
-Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it.
+ختم کلام این است که اگر مشارکت با دیگری به اندازه کافی خوب نباشد، شما ملزم به پذیرفتن هیچ تعهدی نیستید. وقتی دیگران در پروژه‌ی شما مشارکت می‌کنند، مهربان و پاسخگو باشید؛ اما فقط تغییراتی را قبول کنید که واقعاً معتقد هستید پروژه‌ی شما را بهتر می‌کند. هر چه در نه گفتن، تمرین بیشتری داشته باشید؛ گفتن آن راحت‌تر می‌شود. به شما قول می‌دهم.
 
-Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise.
+### فعال باشید
 
-### Be proactive
+برای کاهش حجم مشارکت‌های ناخواسته در وهله‌ی اول، روند پروژه خود را در راهنمای ارسال و پذیرش مشارکت‌ها توضیح دهید.
 
-To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide.
+اگر درخواست‌های مشارکت بسیار کم کیفیت دریافت می‌کنید، از افراد متقاضی بخواهید کمی قبل از ارسال پیشنهاد، کارهایی انجام دهند؛ به عنوان مثال:
 
-If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example:
 
 * Fill out a issue or PR template/checklist
-* Open an issue before submitting a PR
+* قبل از ارسال درخواست Pull یک گزارش اشکال ارسال کنند.
 
-If they don't follow your rules, close the issue immediately and point to your documentation.
+اگر از قوانین شما پیروی نکردند، بلافاصله درخواست را رد کنید و آن‌ها را به راهنمای ارسال مرجوع کنید.
 
-While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage.
+اگرچه ممکن است در ابتدا این رویکرد کمی خشن به نظر برسد، اما فعال بودن برای هر دو طرف خوب است. در نتیجه این احتمال را کاهش می‌دهد که کسی ساعت‌های زیادی صرف «درخواست Pull»ی که شما آن را قبول نخواهید کرد، نکند. و ثانیا حجم کاری شما را نیز کمتر می‌کند و مدیریت آن ساده‌تر می‌شود
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-  Ideally, explain to them and in a CONTRIBUTING.md file how they can get a better indication in the future on what would or would not be accepted before they begin the work.
+	بهتر است که به افراد متقاضی در یک فایل «CONTRIBUTING.md» توضیح دهید که چه چیزهایی مورد قبول و چه چیزهایی مورد قبول شما برای شروع کردن کارشان نیست.
   <p markdown="1" class="pquote-credit">
 — @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
   </p>
 </aside>
 
-Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively.
+بعضی اوقات، وقتی نه می‌گویید، مشارکت‌کننده‌ی بالقوه ممکن است ناراحت شود یا از تصمیم شما انتقاد کند. اگر آن‌ها خصومت‌آمیز رفتار کردند و اگر نخواستند به طور سازنده همکاری کنند، [قدم‌هایی را برای خنثی کردن موقعیت](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) بردارید یا حتی آن‌ها را از اجتماع خودتان اخراج کنید.
+
+### با آعوش باز، پذیرای راهنمایی‌ و مشاوره باشید
+
+شاید کسانی در اجتماع شما باشند که مرتباً درخواست‌های مشارکتی پیشنهاد می‌کنند که با استانداردهای پروژه‌ی شما مطابقت نداشته باشد. مسلما رد شدن پیاپی برای هر دو طرف، طاقت‌فرساست.
+
+اگر دیدید کسی مشتاق پروژه‌ی شما است، اما به کمی پیشرفت نیاز دارد، صبور باشید. در هر شرایطی به روشنی توضیح دهید که چرا مشارکت آن‌ها متناسب با انتظارات پروژه‌ی شما نیست. سعی کنید ابتدا وظایفی ساده‌تر و با ابهامات کمتر به آن‌ها بسپرید تا به قول معروف «آماده‌ی کار شوند». اگر وقت داشتید، در اولین مشارکت، آن‌ها را راهنمایی کنید، یا شخص دیگری را در اجتماع خود پیدا کنید که تمایل به راهنمایی کردن آن‌ها داشته باشد.
 
-### Embrace mentorship
 
-Maybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections.
+## از اجتماع خود بهره ببرید
 
-If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first issue,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them.
+لازم نیست همه‌ی کارها را خودتان انجام دهید. دلیلی دارد که پروژه‌ی شما، اجتماعی برای خود دارد! حتی اگر هنوز اجتماعی فعال ندارید، اگر کاربران زیادی دارید، کارها را به آن‌ها بسپرید.
 
-## Leverage your community
+### حجم کار را با دیگران تقسیم کنید
 
-You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work.
+اگر می‌خواهید که دیگران به شما کمک کنند، از آن‌ها درخواست کنید.
 
-### Share the workload
+راهی برای جذب مشارکت‌کنندگان این است که کارها را از نظر سختی درجه‌بندی کنید و [کارهای ساده را به مبتدی‌ها بسپرید](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). سپس GitHub این موضوعات را در فضاهای مختلف خودش به نمایش می‌گذارد و باعث افزایش دیده شدن آن‌ها می‌شود.
 
-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.
 
-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.
+همانطور که @lmccart در پروژه‌ی خود متوجه شد، تشویق دیگران [به اشتراک گذاشتن مالکیت پروژه](../building-community/#share-ownership-of-your-project) می‌تواند حجم کاری شما را بسیار کاهش دهد[p5.js](https://github.com/processing/p5.js).
 
-Encouraging others to [share ownership of the project](../building-community/#share-ownership-of-your-project) can greatly reduce your own workload, as @lmccart discovered on her project, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
-  I’d been saying, "Yeah, anyone can be involved, you don’t have to have a lot of coding expertise [...]." We had people sign up to come [to an event] and that’s when I was really wondering: is this true, what I’ve been saying? There are gonna be 40 people who show up, and it’s not like I can sit with each of them...But people came together, and it just sort of worked. As soon as one person got it, they could teach their neighbor.
+  من می‌گفتم، «هر کسی می‌تواند در پروژه سهیم شود، لازم نیست که حتما مهارت زیادی در زمینه‌ی کدنویسی داشته باشید [...]» افرادی بودند که برای ورود به رویداد ما ثبت‌نام کردند و آن وقت بود که من واقعاً با خودم فکر کردم «آیا حرف‌هایی که می‌زدم واقعیت دارند؟» قرار هست که 40 نفر در رویداد حضور پیدا کنند و اینطور نیست که من بتوانم با هرکدام بنشینم و با آن‌ها صحبت کنم... اما مردم دور هم جمع شدند و خود به خود همه چی به خوبی پیش رفت. به محض اینکه یک نفر یاد گرفت، آن‌ها می‌توانند به یکدیگر یاد دهند.
   <p markdown="1" class="pquote-credit">
 —  @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
   </p>
 </aside>
 
-If you need to step away from your project, either on hiatus or permanently, there's no shame in asking someone else to take over for you.
+اگر لازم است کمی از پروژه‌ی خود فاصله بگیرید، یا وقفه‌ای در آن ایجاد کنید یا به طور کلی کنار بکشید؛ به هیچ وجه شرم‌آمور نیست که از شخص دیگری بخواهید مسئولیت کار شما را به عهده بگیرد.
 
-If other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It's great that so many people want your project to live on!
+اگر افراد دیگری مشتاق این هستند، به آن‌ها اجازه‌ی دسترسی دهید یا کنترل پروژه را به طور رسمی به شخص دیگری بسپارید. اگر کسی پروژه‌ی شما را به چند شاخه تبدیل کرد و به طور فعال آن را در جای دیگری نگهداری کرد، پیوند دادن پروژه‌ی اصلی خود به شاخه را مد نظر قرار دهید. این خیلی خوب است که مردم می‌خواهند پروژه شما ادامه یابد!
 
-@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), helped those goals live on even after he stepped away from the project:
 
-> I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down.
+@progrium [متوجه شد]( https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) که ثبت کردن چشم‌انداز [پروژه](https://github.com/dokku/dokku)، کمک کرد تا آن اهداف حتی پس از کنار کشیدن او ادامه یابند:
 
-### Let others build the solutions they need
 
-If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork.
+> من یک صفحه‌ در ویکی نوشتم و آنچه را که می‌خواهم و چرایی آن را توصیف کردم. بنا به دلایلی برای من تعجب‌آور بود که نگهدارندگان شروع به انتقال پروژه به سمت و سوی دلخواه خود کردند! آیا آنطور که می‌خواستم، پیش رفت؟ نه همیشه. ولی پروژه را به آنچه که نوشته‌ بودم، نزدیک‌تر کرد.
+
+### به دیگران اجازه دهید تا راه‎‌حل‌های مورد نیاز خودشان را طراحی کنند
+
+اگر فرد مشارکت‌کننده‌ای نظر دیگری در مورد کاری که پروژه باید انجام دهد داشته باشد، بهتر است که آن‌ها را با مهربانی تشویق به کار بر روی شاخه‌ی خودشان از پروژه بکنید.
+
+به چند شاخه تقسیم کردن پروژه، الزاما چیز بدی نیست. امکان کپی و اصلاح پروژه‌ها، یکی از بهترین ویژگی‌های اوپن سورس بودن است. تشویق اجتماع (community) خودتان به کار بر روی شاخه‌های خودشان می‌تواند فضای خلاقانه‌ی مورد نیاز را فراهم آورد، بدون اینکه با چشم‌اندازهای پروژه‌ی شما تداخلی ایجاد کند.
 
-Forking a project doesn't have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project's vision.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
-  I cater to the 80% use case. If you are one of the unicorns, please fork my work. I won't get offended! My public projects are almost always meant to solve the most common problems; I try to make it easy to go deeper by either forking my work or extending it.
+  من زمینه‌ی 80% موارد کاربردی را فراهم می‌کنم.  اگر از کار خود اطمینان دارید، لطفا شاخه‌ای از پروژه‌ی من را بردارید. دلخور نخواهم شد! پروژه‌های عمومی من اکثرا برای حل رایج‌ترین مشکلات هستند؛ سعی می‌کنم با شاخه شاخه کردن کارم یا بسط دادن، آن را کاربردی‌تر بکنم.
   <p markdown="1" class="pquote-credit">
 — @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
   </p>
 </aside>
 
-The same applies to a user who really wants a solution that you simply don't have the bandwidth to build. Offering APIs and customization hooks can help others meet their own needs, without having to modify the source directly. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) encouraging plugins for CocoaPods led to "some of the most interesting ideas":
+این موضوع همچنین درمورد کاربری صدق می‌کند که واقعاً نیاز به راه‌حلی دارد که ظرفیت طراحی آن را ندارید. ارائه‌ی APIها و هوک‌های سفارشی‌سازی (customization hooks)، بدون نیاز به تغییر مستقیم سورس، می‌توانند به دیگران در تأمین نیازهاشان کمک کنند. @orta [متوجه شد](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) که افزونه‌های پرورشی برای «CocoaPods» منجر به «برخی از جالب‌ترین ایده‌ها» شد:
+
 
-> It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying "no", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform.
+> تقریباً اجتناب‌ناپذیر به نظر می‌رسد که به محض بزرگ‌تر شدن پروژه، نگهدارنده‌ها باید در مورد نحوه تعریف کدهای جدید بسیار محافظه‌کارانه‌تر عمل کنند. شاید در گفتن «نه» تبحر پیدا کرده باشید، اما هنوز بسیاری از مردم نیازهایی معقول و منطقی دارند. بنابراین، در نهایت ابزار شما به یک پلتفرم تبدیل می‌شود.
 
-## Bring in the robots
+## از ربات‌ها استفاده کنید
 
-Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier.
+همانطور که وظایفی وجود دارد که دیگران می‌توانند در انجام آن‌ها به شما کمک کنند، وظایفی نیز وجود دارد که هیچ انسانی هرگز نباید آن‌ها را انجام دهد. ربات‌ها دوست شما هستند. به عنوان یک نگهدارنده، از آن‌ها برای سهولت زندگی خود استفاده کنید.
 
-### Require tests and other checks to improve the quality of your code
+### برای بهبود کیفیت کدهای خود، از تست‌ها و دیگر ابزار استفاده کنید.
 
-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.
+تست‌های خودکاری را طراحی کنید که برای همه مشارکت‌های آتی اجرا شود و اطمینان حاصل کنید که تست‌های شما به راحتی توسط مشارکت‌کنندگان قابل اجرا باشند. قبول کردن درخواست‌های مشارکت در کدها را ملزم به قبول شدن در آن تست بکنید. با این کار، حداقل استاندارد کیفیتی را برای همه‌ی درخواست‌ها تعیین می‌کنید. [با بررسی وضعیت](https://help.github.com/articles/about-required-status-checks/) در GitHub می‌توانید اطمینان حاصل کنید که بدون گذراندن تست‌های شما اجازه‌ی هیچ گونه تغییری داده نمی‌شود.
 
-If you add tests, make sure to explain how they work in your CONTRIBUTING file.
+اگر تست‌هایی اضافه کردید، حتماً نحوه‌ی کارکرد آن‌ها را در فایل «CONTRIBUTING» (مشارکت) خود توضیح دهید.
 
 <aside markdown="1" class="pquote">
   <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)
   </p>
 </aside>
 
-### Use tools to automate basic maintenance tasks
+### از ابزارها برای اتوماتیک کردن کارهای ساده‌ی نگهداری استفاده کنید
 
-The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for it.
+خبر خوب در مورد نگهداری پروژه‌های محبوب این است که نگهدارندگان دیگر احتمالاً با مسائل مشابهی روبرو شده‌اند و راه‌حلی از قبل برای آن طراحی کرده‌اند.
 
-There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples:
+[ابزارهای متنوعی برای کمک](https://github.com/showcases/tools-for-open-source) به اتوماتیک کردن برخی جنبه‌های کار نگهداری وجود دارد. به عنوان مثال:
 
-* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases
-* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
-* [Danger](https://github.com/danger/danger) helps automate code review
-* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information
-* [dependabot-preview](https://github.com/marketplace/dependabot-preview) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
 
-For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.
+* ابزار [emantic-release](https://github.com/semantic-release/semantic-release)، عرضه نسخه‌های جدید شما را اتوماتیک می‌کند.
+* ابزار [mention-bot](https://github.com/facebook/mention-bot)، به بازبین‌های بالقوه برای «درخواست pull»ها خبر می دهد.
+* ابزار [Danger](https://github.com/danger/danger)، به بررسی و بازبینی اتوماتیک کد کمک می‌کند.
+* ابزار [no-response](https://github.com/probot/no-response)، مسائلی را که نویسنده به درخواست‌ها برای اطلاعات بیشتر پاسخ نداده است، می‌بندد.
+* ابزار [dependabot-preview](https://github.com/marketplace/dependabot-preview)، هر روز «فایل‌های وابسته» (مثل کتابخانه‌ها یا کلاس‌های جانبی یا ماژول‌ها) شما را از نظر الزامات منسوخ شده بررسی می‌کند و «درخواست‌های pull» را برای هر موردی که پیدا می‌کند، باز می‌کند.
 
-To manage your email notifications, you can set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize by priority.
+برای گزارش اشکالات (bug) و سایر مشارکت‌های متداول، GitHub دارای [قالب‌های طرح مشکل و قالب‌های درخواست‌های pull](https://github.com/blog/2111-issue-and-pull-request-templates) است، که می‌توانید برای کارآمد ساختن ارتباطاتی که دریافت می‌کنید، استفاده کنید. «TalAter»، برای کمک کردن به شما برای طرح مشکلات و مسائل روابط عمومی (PR templates)، ابزار [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) را ساخت.
 
-If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept.
+برای مدیریت اعلان‌های ایمیل خود، می‌توانید [فیلترهای ایمیل](https://github.com/blog/2203-email-updates-about-your-own-activity) را تنظیم کنید تا ایمیل‌ها براساس اولویت سازماندهی شوند.
 
-However, if your standards are too complicated, they can increase the barriers to contribution. Make sure you're only adding enough rules to make everyone's lives easier.
+اگر می خواهید فراتر از حد معمول باشید، شیوه‌نامه‌ها (style guides) و ابزار «linters» می‌توانند مشارکت‌های پروژه را استاندارد کرده و بررسی و پذیرش آن‌ها را آسان کنند.
 
-If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors.
+اگرچه اگر استانداردهای شما بسیار پیچیده باشد، می تواند موانع و مسائل مشارکت را افزایش دهند. مطمئن شوید که فقط به اندازه‌ی کافی قوانینی را برای در آسایش قرار گرفتن دیگران اضافه کنید.
 
-## It's okay to hit pause
+اگر مطمئن نیستید که از چه ابزاری استفاده کنید، به سایر پروژه‌های معروف به ویژه آن پروژه‌هایی که مربوط به اکوسیستم خودتان است، توجه کنید. به عنوان مثال، فرآیند مشارکت برای سایر ماژول‌های «Node»، چگونه است؟ همچنین استفاده از ابزارها و رویکردهای مشابه، فرآیند کارتان را برای مشارکت‌کنندگان‌ شما آشناتر می‌کند.
 
-Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty.
 
-Perhaps you're feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up.
+## اشکالی ندارد اگر که وقفه‌ای در کار خود ایجاد کنید
 
-Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project.
+کار کردن به صورت اوپن سورس برای شما شادی آورد. شاید اکنون باعث شده است شما احساس انزواطلبی داشته باشید یا احساس گناه کنید.
 
-Although it should go without saying, take a break! You shouldn't have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take [a month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) after 14 years of volunteer OSS work.
+شاید وقتی به پروژه‌های خود فکر می‌کنید بیش از حد احساس آشفتگی و یا احساس ترس می‌کنید. و در همین حال، «مشکلات» و «درخواست‌های pull» روی هم انباشته می‌شود.
 
-Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work.
+فرسودگی و خسته شدن از کار، مسئله‌ای واقعی و فراگیر در پروژه‌های اوپن سورس است؛ مخصوصاً در میان نگهدارندگان. به عنوان یک فرد نگهدارنده، خوشحالی و رضایت شما برای بقای هر پروژه‌ی‌ اوپن سورسی، ضروری است.
+
+پس نیازی به گفتن نیست؛ به خودتان استراحت بدهید! نیازی نیست تا سر حد خستگی و فرسودگی پیش بروید تا سپس به تعطیلات بروید. @brettcannon، توسعه‌دهنده‌ی پایتون، [تصمیم گرفت پس از 14 سال کار داوطلبانه در OSS، به تعطیلات یک ماهه برود](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/). 
+
+درست مانند هر کار دیگری، تعطیلات منظم، شما را باطراوت نگه می‌دارد و باعث خوشحالی و هیجان شما نسبت به کارتان می‌شود.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
-  In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
+  در حین نگهداری «WP CLI»، متوجه شدم که باید ابتدا خودم را خوشحال کنم و مرزهای مشخصی را برای مشارکت خودم تعیین کنم. بهترین تعادلی که پیدا کردم این بود که 2 تا 5 ساعت را در هفته صرف این مشارکت جدای از برنامه‌ی عادی کارم، بکنم. این باعث شد که اشتیاقم به این کار مانند روز اول باشد و آن حس اجباری بودن کار را بر روی دوش حس نکنم. از آنجا که من موضوعاتی که بر روی آن‌ها کار می‌کنم را اولویت‌بندی می‌کنم، می‌توانم مرتباً در آن کارهایی که از نظرم مهم هستند، پیشرفت داشته باشم.
   <p markdown="1" class="pquote-credit">
 — @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
-Sometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away.
+گاهی اوقات، زمان‌هایی که حس می‌کنید همه به شما احتیاج دارند؛ ممکن است فاصله گرفتن از پروژه‌ی اوپن سورس سخت باشد. حتی ممکن است دیگران، شما را به خاطر فاصله گرفتن سرزنش کنند.
+
+در حالی که از پروژه فاصله گرفتید، تلاش خود را برای یافتن پشتیبانی از کاربران و اجتماع خود بکنید. اگر نتوانستید پشتیبانی دیگران را به دست آورید، به هر حال کار خودتان را بکنید و فاصله‌ای را که نیاز دارید از پروژه بگیرید. زمانی که حضور نداشتید، حتماً ارتباط خود را با دیگران حفظ کنید؛ تا مردم از نبود پاسخگویی گیج نشوند.
 
-Do your best to find support for your users and community while you're away from a project. If you can't find the support you need, take a break anyway. Be sure to communicate when you're not available, so people aren't confused by your lack of responsiveness.
+فاصله گرفتن، فقط منحصر به تعطیلات می‌شود. اگر نمی‌خواهید آخر هفته‌ یا در ساعات کاری، پروژه‌های اوپن سورس انجام دهید، این را به اطلاع دیگران برسانید تا بدانند که در آن اوقات مزاحم شما نشوند.
 
-Taking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you.
 
-## Take care of yourself first!
+## ابتدا به فکر خودتان باشید!
 
-Maintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive.
+نگهداری یک پروژه‌ی محبوب به مهارت‌های متفاوتی در مقایسه با مهارت‌های مراحل اولیه‌ی رشد نیاز دارد، اما به همان میزان پاداش بیشتری هم خواهد داشت. به عنوان یک نگهدارنده، شما باید مهارت‌های رهبری و شخصی در سطحی فرای دیگران داشته باشید. اگرچه مدیریت آن همیشه آسان نیست، اما تعیین مرزهای مشخص و تنها پذیرفتن آنچه که با آن راحت هستید به شما کمک می‌کند تا شاد، سرحال و کارآمد باشید.
diff --git a/_articles/fa/index.html b/_articles/fa/index.html
index 627d4f8ebb0..0bb1b27c4bd 100644
--- a/_articles/fa/index.html
+++ b/_articles/fa/index.html
@@ -1,6 +1,6 @@
 ---
 layout: index
-title: Guías de código abierto
-lang: es
-permalink: /es/
+title: راهنماهای متن‌باز
+lang: fa
+permalink: /fa/
 ---

From e6722bfa3311d799e8d8665d6d35e221a01774be Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Wed, 14 Apr 2021 19:09:55 +0430
Subject: [PATCH 148/749] Translation started.

---
 _articles/fa/finding-users.md | 24 +++++++++---------------
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/_articles/fa/finding-users.md b/_articles/fa/finding-users.md
index 84ec4c6e7ca..7c7d85fe8e4 100644
--- a/_articles/fa/finding-users.md
+++ b/_articles/fa/finding-users.md
@@ -1,15 +1,8 @@
 ---
 lang: en
-title: Finding Users for Your Project
-description: Help your open source project grow by getting it in the hands of happy users.
+title: پیدا کردن کاربر برای پروژه‌هایتان
+description: با داشتن کاربرانی راضی و خوشحال، به پروژه‌ی اوپن سورس خود کمک کنید تا رشد کند..
 class: finding
-toc:
-  spreading-the-word: "Spreading the word"
-  figure-out-your-message: "Figure out your message"
-  help-people-find-and-follow-your-project: "Help people find and follow your project"
-  go-where-your-projects-audience-is-online: "Go where your project’s audience is (online)"
-  go-where-your-projects-audience-is-offline: "Go where your project’s audience is (offline)"
-  build-a-reputation: "Build a reputation"
 order: 3
 image: /assets/images/cards/finding.png
 related:
@@ -17,17 +10,18 @@ related:
   - building
 ---
 
-## Spreading the word
+## به اطلاع همگان برسانید
 
-There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work!
+هیچ قانونی وجود ندارد که بگوید هنگام راه‌اندازی، باید پروژه‌ی اوپن سورس را تبلیغ کنید. دلایل رضایت‌بخش زیادی برای کار کردن در پروژه‌ای اوپن سورس وجود دارد که هیچ ارتباطی با محبوبیت ندارد. به جای امیدواری برای اینکه دیگران پروژه‌ی اوپن سورس شما را پیدا کنند و از آن استفاده کنند، باید در مورد پروژه و سخت‌کوشی خودتان صحبت کنید و آن را به گوش دیگران برسانید!
 
-## Figure out your message
+## از پیامی که می‌خواهید به گوش دیگران برسانید، اطمینان حاصل کنید
 
-Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters.
+قبل از اینکه شروع به تبلیغ و ترویج پروژه‌ بکنید، باید بتوانید که کارآیی و چرایی اهمیت آن را توضیح بدهید.
 
-What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance.
+چه چیزی موجب تفاوت و جالب بودن پروژه‌ی شما نسبت به دیگر پروژه‌ها می‌شود؟ به چه منظور آن را ساختید؟ پاسخ دادن به این سوالات، به شما کمک می‌کند تا به اهمیت پروژه‌ی خودتان پی ببرید و آن را واضح‌تر بیان کنید.
+
+به یاد داشته باشید به این دلیل که پروژه‌ی شما مشکلی را برای کاربران برطرف می‌کند؛ افراد به عنوان کاربر به پروژه‌ی شما ملحق می‌شوند و در نهایت به عنوان یک مشارکت‌کننده معرفی می‌شوند. همانطور که درباره‌ی پیام و ارزش پروژه‌‌ی خود فکر می‌کنید، سعی کنید آن‌ها را از دریچه‌ی آنچه که کاربران و مشارکت‌کنندگان می‌خواهند نظاره کنید.
 
-Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want.
 
 For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
 

From acbd9580ed514dc74b8ca8f0fbfd6da3a8aea690 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Thu, 15 Apr 2021 17:22:05 +0430
Subject: [PATCH 149/749] Initial translation done.

---
 _articles/fa/finding-users.md | 85 +++++++++++++++++------------------
 1 file changed, 42 insertions(+), 43 deletions(-)

diff --git a/_articles/fa/finding-users.md b/_articles/fa/finding-users.md
index 7c7d85fe8e4..b45a68c823f 100644
--- a/_articles/fa/finding-users.md
+++ b/_articles/fa/finding-users.md
@@ -23,135 +23,134 @@ related:
 به یاد داشته باشید به این دلیل که پروژه‌ی شما مشکلی را برای کاربران برطرف می‌کند؛ افراد به عنوان کاربر به پروژه‌ی شما ملحق می‌شوند و در نهایت به عنوان یک مشارکت‌کننده معرفی می‌شوند. همانطور که درباره‌ی پیام و ارزش پروژه‌‌ی خود فکر می‌کنید، سعی کنید آن‌ها را از دریچه‌ی آنچه که کاربران و مشارکت‌کنندگان می‌خواهند نظاره کنید.
 
 
-For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
+به عنوان مثال، @robb از کدها استفاده می‌کند تا به طور واضح اهمیت پروژه‌ی خود را نشان دهد؛ نقشه‌نگاری [Cartography](https://github.com/robb/Cartography) مفید واقع می‌شود:
 
 ![Cartography README](/assets/images/finding-users/cartography.jpg)
 
-For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+برای درک بهتر مفهوم، مورد [Personas and Pathways](https://mozillascience.github.io/working-open-workshop/personas_pathways/) موزیلا (Mozilla) را برای توسعه‌ی پرسونای کاربران بررسی کنید
 
-## Help people find and follow your project
+## مردم را در پیدا کردن و دنبال کردن پروژه‌ی خودتان یاری کنید
 
 <aside markdown="1" class="pquote">
-  You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
+  شما ترجیحاً به یک URL (نشانی وب) نیاز دارید تا بتوانید پروژه‌ی خود را تبلیغ کنید و مردم را به آن مشتاق سازید. لازم نیست که قالب و یا حتی یک آدرس اینترنتی شیک و فانتزی داشته باشید، اما پروژه‌ی شما به یک نقطه‌ی توجه (مطلب اصلی و مهم) نیاز دارد.
   <p markdown="1" class="pquote-credit">
 — Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
   </p>
 </aside>
 
-Help people find and remember your project by pointing them to a single namespace.
+طوری باشد که با اشاره‌ای کوچک، مردم پروژه‌ی شما را به یاد بیاورند.
 
-**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.
+**برای توسعه‌ی پروژه‌ی خود، کاملا بر کار خویش آگاه و از آن اطمینان داشته باشید. ** یک آدرس توییتری، آدرس GitHub یا کانال IRC راهی آسان برای مشایعت و هدایت افراد به سمت پروژه‌ی خودتان است. این رسانه‌ها همچنین به اجتماع در حال رشد پروژه‌ی شما، محلی برای تجمع و تبادل نظر می‌دهند.
 
-If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. 
+اگر هنوز مایل به راه‌اندازی رسانه‌هایی برای پروژه‌ی خودتان نیستید، در همه‌ی کارهایی که انجام می‌دهید Twitter یا GitHub خود را ترویج دهید. توسعه و تبلیغ Twitter یا GitHub به مردم این امکان را می‌دهد تا با شما در ارتباط باشند یا کارهای شما را دنبال کنند. اگر در جلسه یا رویدادی صحبت می‌کنید، اطمینان حاصل کنید تا اطلاعات تماس شما در مشخصات شما یا اسلایدها آمده باشد.
+ 
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
-  A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project.
+  اشتباهی که در همان روزهای اولیه مرتکب به آن شدم، افتتاح نکردن یک حساب توییتر برای پروژه بود. توییتر راهی عالی برای به روز نگه داشتن مردم در مورد پروژه و همچنین نشان دادن پروژه به آدم‌های جدید است.
   <p markdown="1" class="pquote-credit">
 — @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
   </p>
 </aside>
 
-**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project.
+**ساخت وب‌سایتی را برای پروژه‌ی خود مد نظر قرار دهید.** داشتن وب‌سایت، پروژه‌ی شما را دوستانه‌تر و برای وب‌گردی و گشت‌زنی ساده‌تر می‌کند؛ به ویژه هنگامی که با مستندات و آموزش‌های واضح همراه باشد. داشتن یک وب سایت همچنین بیانگر این است که پروژه‌ی شما فعال است که همین باعث می‌شود مخاطبان شما احساس راحتی بیشتری در استفاده از آن داشته باشند. مثال‌هایی را ارائه دهید تا به افراد در مورد چگونگی استفاده از پروژه‌تان ایده بدهد.
 
-[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_.
-
-If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+[@Adrianholovaty](https://news.ycombinator.com/item?id=7531689)، یکی از سازند‌گان شرکت «Django» گفت که وب‌سایت «بهترین کاری بود که می‌توانستیم برای Django در آن روزهای اولیه انجام دهیم». اگر پروژه‌ی شما در GitHub باشد، می‌توانید با استفاده از [GitHub Pages](https://pages.github.com/)، به راحتی وب‌سایت ایجاد کنید. [Yeoman](http://yeoman.io/)، [Vagrant](https://www.vagrantup.com/)  و [Middleman](https://middlemanapp.com/) چند نمونه از وب‌سایت‌های عالی و جامع هستند.                                      
 
 ![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
 
-Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!
+اکنون که برای پروژه‌ی خود رسالت و راهی آسان برای یافتن پروژه‌تان توسط مردم  دارید، وقت آن است که بیرون بزنیم و با مخاطبان ارتباط برقرار کنیم و با آن‌ها صحبت کنیم!
 
-## Go where your project's audience is (online)
+## هر جا که مخاطبان شما بودند، شما هم به آنجا بروید (آنلاین)
 
-Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
+اطلاع‌رسانی آنلاین، روشی عالی برای به اشتراک گذاشتن و انتقال سریع اخبار و اطلاعات است. با استفاده از مجرا‌های آنلاین، این امکان را خواهید داشت که به مخاطبان بسیار گسترده‌ای دسترسی پیدا کنید.
 
-Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+برای دسترسی به مخاطبان خود از ارتباطات‌ و بسترهای آنلاین موجود استفاده کنید. اگر پروژه‌ی اوپن سورس شما پروژه‌ای نرم‌افزاری است، احتمالاً بتوانید مخاطبان خود را در [Stack Overflow](https://stackoverflow.com/) ،[Hacker News](https://news.ycombinator.com/)  یا [Quora](https://www.quora.com/) پیدا کنید. کانال‌هایی را پیدا کنید که فکر می‌کنید مردم در آن از کار شما بیشترین استفاده را می‌برند یا مشتاق آن هستند.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
-  Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project.
+  هر برنامه‌ای، عملکرد بسیار خاص خود را دارد که فقط برای کسری از کاربران مفید واقع می‌شود. مردم را با تبلیغات بیش از حد برنامه، بمباران نکنید! درعوض، تلاش‌های خود را معطوف گروهی از افراد کنید که از مطلع شدن از پروژه‌ی شما بهره‌مند می‌شوند و برنامه برای آن‌ها مفید واقع می‌شود.
   <p markdown="1" class="pquote-credit">
 — @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
   </p>
 </aside>
 
-See if you can find ways to share your project in relevant ways:
+ببینید آیا می‌توانید روش‌هایی برای به اشتراک گذاشتن پروژه خود به صورت متناسبی پیدا کنید:
+
+* **با پروژه‌ها و انجمن‌های اوپن سورس مرتبط و مدنظرتان آشنا شوید.** گاهی اوقات، لازم نیست که مستقیماً پروژه‌ی خود را تبلیغ کنید. اگر پروژه‌ی شما برای متخصصین علم داده که از پایتون استفاده می‌کنند عالی است، با انجمن علوم داده‌ی پایتون ملاقات کنید و آشنا شوید. هنگامی که مردم با شما آشنا شوند، فرصت‌ها به صورت خودکار و طبیعی برای بحث و گقت و گو و به اشتراک گذاشتن کارهای شما بوجود می‌آید.
+* **افرادی که مشکلاتی دارند و پروژه‌ی شما، آن مشکلات را حل و فصل می‌کند را پیدا کنید. ** از طریق تالارهای گفتگوی (فروم‌ها) مرتبط، به جستجوی افرادی که می‌توانند مخاطبانِ هدفِ پروژه‌ی شما باشند، بپردازید. به سوالات آن‌ها پاسخ دهید و در زمانی مناسب، روشی مدبرانه تعبیه کنید تا پروژه‌ی خود را به عنوان یک راه‌حل پیشنهاد دهید.
+* **از انتقادات و پیشنهادات روی‌گردان نباشید.** خود و کارهایتان را به مخاطب‌هایی مرتبط و متناسب که به کار شما علاقه دارند، معرفی کنید. مخاطبان خود را بشناسید و کسانی که از پروژه‌ی شما سود و منفعت حاصل می‌کنند را مشخص کنید. سعی کنید این جمله را کامل کنید:  «من فکر می‌کنم پروژه‌ی من واقعاً به X، که در تلاش برای انجام کار Y است، کمک خواهد کرد». به جای اینکه صرفاً فقط کار خود را تبلیغ کنید، به بازخورد دیگران گوش دهید و پاسخگو باشید.
 
-* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.
-* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.
-* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work.
+به طور کلی، به کمک کردن به دیگران تمرکز کنید قبل از اینکه چیزهایی را در عوض درخواست کنید؛ چونکه که اگر هر کسی بخواهد پروژه‌های خودش را به صورت آنلاین تبلیغ کند، همهمه و شلوغی زیادی بر پا خواهد شد. برای اینکه در جمعی شناخته شوید، سعی کنید خود را به دیگران معرفی کنید و نه اینکه فقط آنچه که می‌خواهید را بازگو کنید.
 
-Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want.
+اگر کسی به فعالیت‌های اولیه‌ی شما پاسخی نداد و یا توجه نکرد، ناامید نشوید! اکثر راه‌اندازی‌های پروژه‌ها، فرآیندهایی هستند که باید چندین و چندین بار تکرار شوند که ممکن است ماه‌ها یا سال‌ها به طول انجامد. اگر بار اول پاسخی دریافت نکردید، تاکتیک دیگری را امتحان کنید یا ابتدا به دنبال روش‌هایی برای افزودن ارزش به کار دیگران باشید. راه‌اندازی و توسعه‌ی پروژه، به وقت و تعهد نیاز دارد.
 
-If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication.
 
-## Go where your project's audience is (offline)
+## هر جا که مخاطبان شما بودند، شما هم به آنجا بروید (آفلاین)
 
 ![Public speaking](/assets/images/finding-users/public_speaking.jpg)
 
-Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.
+رویدادهای آفلاین، روشی متداول برای تبلیغ پروژه‌های جدید برای مخاطبان است. این رویدادها راهی عالی برای دستیابی به مخاطبان مشتاق و ایجاد ارتباطات انسانی عمیق‌تر هستند؛ به خصوص که اگر شما می‌خواهید با توسعه‌دهندگان ارتباط برقرار کنید.
 
-If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.
+اگر [تجربه‌ی چندانی در حوزه‌ی سخنرانی در عموم](https://speaking.io/), ندارید و تازه‌کار هستید، با پیدا کردن یک جلسه‌ی محلی که مرتبط با محتوا یا اکوسیستم پروژه‌ی خودتان است شروع کنید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
-  I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
+  من از اینکه بخواهم به «PyCon» بروم، خیلی استرس داشتم. قرار بود که سخنرانی بکنم، قرار بود فقط با چند نفر در آنجا آشنا شوم، قرار بود یک هفته‌ی تمام آنجا می‌بودم. .... هر چند نیازی نبود که استرس داشته باشم. PyCon  فراتر از انتظارهایم فوق‌العاده بود! همگی به طرز خار‌ق‌العاده‌ای رفتاری دوستانه داشتند و خوش‌برخورد بودند، به قدری که من به ندرت وقت می‌کردم که با مردم صحبت نکنم!
   <p markdown="1" class="pquote-credit">
 — @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
   </p>
 </aside>
 
-If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.
+اگر قبلاً هرگز در رویدادی صحبت نکرده‌اید، اینکه استرس داشته باشید، کاملاً طبیعی است! به یاد داشته باشید که مخاطبان شما آنجا هستند زیرا واقعاً می‌خواهند در مورد کارهای شما بشنوند.
+هنگام نوشتن سخنرانی خود، بر آنچه که مخاطبان جالب می‌پندارند و از آن ارزش و درسی می‌گیرند، تمرکز کنید. دوستانه و صمیمانه سخن بگویید. لبخند به لب داشته باشید، تنفس کنید و لذت ببرید.
 
-As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.
+هنگامی که کار را بر روی متن سخنرانی خود آغاز می‌کنید، خواه هر چه موضوع سخنرانی شما باشد، اگر سخنرانی خود را همانند داستانی که برای مردم تعریف می‌کنید تصور کنید، می‌تواند به شما کمک بسزایی بکند.
 
 <aside markdown="1" class="pquote">
   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
-  When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+  وقتی احساس کردید که آماده‌اید، سخنرانی در کنفرانس‌ها به منظور تبلیغ پروژه‌ی خود را مد نظر قرار دهید. کنفرانس‌ها می‌توانند به شما کمک کنند تا به افراد بیشتری، گاهی اوقات از سراسر جهان، دسترسی پیدا کنید.
   <p markdown="1" class="pquote-credit">
 — Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
   </p>
 </aside>
 
-When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.
-
-Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers.
+به دنبال کنفرانس‌هایی باشید که مرتبط با محتوا یا اکوسیستم مورد نظر شما باشد. قبل از ارسال سخنرانی خود، در مورد کنفرانس تحقیق کنید تا سخنرانی خود را برای حاضران تنظیم و اصلاح کرده و در نتیجه شانس پذیرفته شدن برای سخنرانی در کنفرانس را افزایش دهید. شما همچنین می‌توانید با مراجعه به لیست سخنرانان کنفرانس، از نوع و کیفیت مخاطبان خود آگاه شوید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
-  I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?
+  من خیلی محترمانه برای مسئولان کنفرانس JS نامه نوشتم و از آن‌ها خواهش کردم تا نوبتی به من برای سخنرانی در کنفرانس JS اروپا به من بدهند. ...برای این سخنرانی که شش ماه بر روی آن کار کرده بودم، بسیار ترسیده بودم. ...فقط با خودم می‌گفتم، خدایا! من اینجا چیکار می‌کنم؟
   <p markdown="1" class="pquote-credit">
 — @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
   </p>
 </aside>
 
-## Build a reputation
+## برای خود اعتبار و شهرت دست و پا کنید
 
-In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.
+علاوه بر استراتژی‌های ذکر شده در بالا، بهترین راه برای دعوت مردم برای به اشتراک‌‌گذاری و مشارکت در پروژه‌ی شما، اشتراک و مشارکت در پروژه‌های آن‌ها است.
 
-Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships.
+کمک به تازه‌واردان، به اشتراک گذاشتن منابع و مشارکت مدبرانه در پروژه‌های دیگران به شما کمک می‌کند تا اعتبار خوبی برای خود بسازید. اگر عضوی فعال در اجتماع (انجمن) اوپن سورس باشید به شما کمک می‌کند تا مردم کار و محتوای شما را بشناسند و احتمال اینکه به پروژه شما توجه کنند و آن را به اشتراک بگذارند، بیشتر می‌شود. توسعه‌ی روابط با سایر پروژه‌های اوپن سورس، می‌تواند منجر به مشارکت و همکاری  رسمی شود.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
-  The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+ تنها به خاطر درخواست‌های زیاد از urllib3 است که urllib3 محبوب‌ترین کتابخانه‌ی پایتون شخص ثالث (third-party) امروزی است.
   <p markdown="1" class="pquote-credit">
 — @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
   </p>
 </aside>
 
-It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others.
+برای ایجاد و کسب اعتبار، هیچوقت خیلی زود و یا خیلی دیر نیست. حتی اگر پروژه‌ی خود را از قبل راه‌اندازی کرده‌اید، به جستجوی راه‌هایی برای کمک به دیگران ادامه دهید. برای ایجاد و جذب مخاطب، هیچ راه‌حل یک شبه‌ای وجود ندارد. 
 
-There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.
+جلب اعتماد و احترامِ دیگران نیازمند زمان است و هیچ پایانی برای ایجاد و کسب اعتبار  وجود ندارد
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it.
+  PhantomJS برای اولین بار در ابتدای سال 2011 منتشر شد. ...من با روش‌های متداول، خبر را پخش کردم:  من راجع به آن توییت کردم، در مورد کارهایی که می‌توانید با آن انجام دهید در وبلاگ‌ پست‌هایی گذاشتم، در گردهمایی‌ها، در بحث‌های مختلف به آن اشاره کردم. وقتی در سال 2014 بیشتر شناخته شد، شروع به ارائه‌ی سخنرانی‌هایی در مورد آن کردم.
   <p markdown="1" class="pquote-credit">
 — @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
   </p>
 </aside>
 
-## Keep at it!
+## تسلیم نشوید!
 
-It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.
+ممکن است مدت‌ها تا اینکه مردم متوجه پروژه‌ی اوپن سورس شما شوند طول بکشد. هیچ اشکالی نداره! برخی از محبوب‌ترین پروژه‌های امروزی، برای رسیدن به سطح بالایی از فعالیت، سال‌ها به طول انجامید. به جای اینکه امیدوار باشید پروژه‌ی شما به طور خود به خود محبوبیت پیدا کند، بر ایجاد روابط متمرکز شوید. صبور باشید و مدام کار خود را با کسانی که قدر آن را می‌دانند به اشتراک بگذارید.

From 6c838b193d085fbe5b47dfea3521e1f6f5b8a0a6 Mon Sep 17 00:00:00 2001
From: BobAnkh <bobankhshen@gmail.com>
Date: Fri, 16 Apr 2021 14:41:34 +0800
Subject: [PATCH 150/749] Fix a typo of zh-hans translation

---
 _articles/zh-hans/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index 314eef32804..28bfca47a9d 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -119,7 +119,7 @@ redirect_from: /zh-cn/legal/
 
 **如果你们的开源项目是为了你们的公司，**那么绝对要让他们知道。根据公司的业务需求和专业知识，你们的法律团队可能已经制定了有关开放源代码许可协议（以及可能还有其他贡献者协议）的政策，以确保您的项目符合其依赖关系的许可协议。如果不是这样，你们和他们很幸运！你们的法律团队应该渴望与你们合作，把这个东西搞清楚。你们需要思考这些事：
 
-* **第三方资源：**你们的项目有其他人创建的依赖或者使用他人的代码？如果这些事开源项目，你们需要遵守第三方资源的开源许可协议。首先，选择与第三方资源的开放源许可协议一起使用的许可协议（见上文）。如果你们的项目修改或者发布第三方开源资源，那么你们法律团队还想知道你们符合第三方开源许可协议的其他条件，例如保留版权声明。如果你们使用了其他没有开源许可协议的代码，那么你们可能会要求第三方资源的维护者[添加一个开源许可协议](https://choosealicense.com/no-license/#for-users)，要是你们得不到许可，你们只能停止使用他们的代码。
+* **第三方资源：**你们的项目有其他人创建的依赖或者使用他人的代码？如果这些是开源项目，你们需要遵守第三方资源的开源许可协议。首先，选择与第三方资源的开放源许可协议一起使用的许可协议（见上文）。如果你们的项目修改或者发布第三方开源资源，那么你们法律团队还想知道你们符合第三方开源许可协议的其他条件，例如保留版权声明。如果你们使用了其他没有开源许可协议的代码，那么你们可能会要求第三方资源的维护者[添加一个开源许可协议](https://choosealicense.com/no-license/#for-users)，要是你们得不到许可，你们只能停止使用他们的代码。
 
 
 * **商业机密：**请考虑项目中是否有公司不想对外公开的东西。如果是这样的话，你们只能开源项目的一部分，得保护好公司的商业机密。

From 166ab18e16c1444de190f0c393fed4f4f428a063 Mon Sep 17 00:00:00 2001
From: BobAnkh <bobankhshen@gmail.com>
Date: Fri, 16 Apr 2021 14:48:16 +0800
Subject: [PATCH 151/749] Fix a typo of zh-hant translation

---
 _articles/zh-hant/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hant/legal.md b/_articles/zh-hant/legal.md
index 4d1de93e01a..87b7dd670f3 100644
--- a/_articles/zh-hant/legal.md
+++ b/_articles/zh-hant/legal.md
@@ -119,7 +119,7 @@ redirect_from: /zh-tw/legal/
 
 **如果你們的開源專案是爲了你們的公司，**絕對需要讓他們知道。根據公司的業務需求和專業知識，你們的法律團隊可能已經制定了有關開放源程式碼許可協議（以及可能還有其他貢獻者協議）的政策，以確保您的專案符合其依賴關係的許可協議。如果不是這樣，你們和他們很幸運！你們的法律團隊應該渴望與你們合作，把這個東西搞清楚。你們需要思考這些事：
 
-* **第三方資源：**你們的專案有其他人創建的依賴或者使用他人的程式碼？如果這些事開源專案，你們需要遵守第三方資源的開源許可協議。首先，選擇與第三方資源的開放源許可協議一起使用的許可協議（見上文）。如果你們的專案修改或者發佈第三方開源資源，那麼你們法律團隊還想知道你們符合第三方開源許可協議的其他條件，例如保留版權聲明。如果你們使用了其他沒有開源許可協議的程式碼，那麼你們可能會要求第三方資源的維護者[添加一個開源許可協議](https://choosealicense.com/no-license/#for-users)，要是你們得不到許可，你們只能停止使用他們的程式碼。
+* **第三方資源：**你們的專案有其他人創建的依賴或者使用他人的程式碼？如果這些是開源專案，你們需要遵守第三方資源的開源許可協議。首先，選擇與第三方資源的開放源許可協議一起使用的許可協議（見上文）。如果你們的專案修改或者發佈第三方開源資源，那麼你們法律團隊還想知道你們符合第三方開源許可協議的其他條件，例如保留版權聲明。如果你們使用了其他沒有開源許可協議的程式碼，那麼你們可能會要求第三方資源的維護者[添加一個開源許可協議](https://choosealicense.com/no-license/#for-users)，要是你們得不到許可，你們只能停止使用他們的程式碼。
 
 * **商業機密：**請考慮專案中是否有公司不想對外公開的東西。如果是這樣的話，你們只能開源專案的一部分，得保護好公司的商業機密。
 

From e84c6228cd1e60096963b70fbed5a1c1892e384e Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Sat, 17 Apr 2021 18:25:48 +0430
Subject: [PATCH 152/749] Initial translation done.

---
 _articles/fa/how-to-contribute.md | 431 +++++++++++++++---------------
 1 file changed, 214 insertions(+), 217 deletions(-)

diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 81158f6f25a..71ff96fd79c 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -1,15 +1,8 @@
 ---
-lang: en
-title: How to Contribute to Open Source
-description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans.
+lang: fa
+title: چگونه در یک پروژه‌ی متن باز مشارکت کنیم
+description: می‌خواهید در یک پروژه‌ی متن باز مشارکت کنید؟ در ادامه‌ی مقاله نحوه‌ی مشارکت در یک پروژه‌ی متن باز برای افراد مبتدی و باتجربه شرح داده شده است.
 class: contribute
-toc:
-  why-contribute-to-open-source: "Why contribute to open source?"
-  what-it-means-to-contribute: "What it means to contribute"
-  orienting-yourself-to-a-new-project: "Orienting yourself to a new project"
-  finding-a-project-to-contribute-to: "Finding a project to contribute to"
-  how-to-submit-a-contribution: "How to submit a contribution"
-  what-happens-after-you-submit-a-contribution: "What happens after you submit a contribution"
 order: 1
 image: /assets/images/cards/contribute.png
 related:
@@ -17,210 +10,212 @@ related:
   - building
 ---
 
-## Why contribute to open source?
+## چرایی مشارکت در یک پروژه‌ی متن باز؟
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
-  Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+  کار کردن در Freenode به من در یادگیری بسیاری از مهارت‌ها کمک کرد و توانستم از آن‌ها در تحقیقات دانشگاهی و شغلم استفاده کنم. فکر می‌کنم به همان اندازه که کار کردن روی پروژه‌های متن باز به پیشبرد پروژه کمک می‌کند به همان اندازه به من هم کمک می‌کند!
   <p markdown="1" class="pquote-credit">
 — @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
   </p>
 </aside>
 
-Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+زمانی که در پروژه‌های متن باز مشارکت می‌کنید، چیزهای زیادی یاد می‌گیرد یا یاد می‌دهید، حتی می‌توانید در هر مهارتی که تصورش را می‌کنید تجربه کسب کنید.
 
-Why do people contribute to open source? Plenty of reasons!
+چرا افراد در پروژه‌های متن باز مشارکت می‌کنند؟ خب، دلایل زیادی وجود دارد!
 
-### Improve software you rely on
+### نرم‌افزاری که به آن متکی هستید را بهبود می‌دهید
 
-Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+مشارکت‌کننده‌ها مشارکت خود از پروژه‌هایی شروع می‌کنند که کاربر آن می‌شوند. زمانی که در نرم‌افزار یک پروژه‌ی متن باز باگ یا خطایی مشاهده کردید، در صورتی که توانایی برطرف کردن آن را داشته باشید می‌توانید به سرس کد آن نگاهی بیندازید و خودتان اصلاحیه‌ای برایش بنویسید. اگر با چنین موردی روبه‌رو شدید، مشارکت در اصلاح آن باگ بهترین راه برای مطمئن کردن دوستان (و خودتان مخصوصاً زمانی که نسخه‌ی بعدی آن به روز شود) باشد که می‌تواند مزیت‌های داشته باشد.
 
-### Improve existing skills
+### مهارت‌های موجودتان تقویت می‌شود
 
-Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+اگر به دنبال تمرین کدنویسی، طراحی رابط‌کاربری کاربر، طراحی گرافیک، نویسندگی یا سازماندهی کردن هستید، پروژه‌ی متن باز این تمرین‌ها را در اختیارتان قرار می‌دهد.
 
-### Meet people who are interested in similar things
+### با افرادی ملاقات می‌کنید که علایق‌شان با شما مشابه است
 
-Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+پروژه‌های متن باز با انجمن‌های گرم و گیرایش باعث می‌شود افرادی که در آن حضور دارند برای سال‌ها به آن مراجعه کنند. حتی بسیاری هستند که به واسطه‌ی همکاری‌شان در راه‌اندازی کنفرانس‌ها یا چت‌های آنلاین شبانه‌شان درباره‌ی burritos ، روابط دوستانه‌ی طولانی مدتی دارند.
 
-### Find mentors and teach others
+### استاد پیدا می‌کنید و به دیگران آموزش می‌دهید
 
-Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+کار کردن با دیگران در پروژه‌های مشترک شما را مجبور می‌کند نحوه‌ی انجام دادن کارها را توضیح دهید و به همان اندازه هم از دیگران کمک بخواهید. هر کسی می‌تواند خود را درگیری فعالیت‌های یادگیری و آموزشی کند.
 
-### Build public artifacts that help you grow a reputation (and a career)
+### محصولی عمومی تولید کنید که به رشد اعتبار و حرفه‌ی کاری‌تان کمک کند
 
-By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+بر اساس تعریف، تمام پروژه‌های متن باز شما عمومی هستند. به این معنا که نمونه پروژه‌ها را دریافت می‌کنید و می‌توانید آن را همه جا ببرید و نشان دهید که چه کارهایی می‌توانید با آن انجام دهید.
 
-### Learn people skills
+### مهارت‌های دیگران را یاد می‌گیرید
 
-Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+روژه‌های متن باز فرصتی فراهم می‌کنند که به واسطه‌ی آن می‌توانید مهارت‌های مدیریت و رهبری پروژه‌ی خود مانند برطرف کردن تضادها، سازماندهی کردن تیم و اولیت بندی کارها، را تقویت کنید.
 
-### It's empowering to be able to make changes, even small ones
+### به شما قدرت اعمال تغییرات هرچند کوچک را می‌دهد
 
-You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+لازم نیست برای لذت بردن از همکاری در یک پروژه‌ی متن باز، به یک مشارکت‌کننده‌ی درازمدت تبدیل شوید. تا حالا شده در یک وب‌سایت چند غلط‌های املائی ببینید و دوست داشتید یک نفر آن را اصلاح کند؟ خب، گر چنین حالتی برای پروژه‌تان به وجود بیاید، به راحتی می‌توانید آن را برطرف کنید. پروژه‌ی متن باز می‌تواند به افراد کمک کند تا شرکتی که در آن فعالیت می‌کنند و نحوه‌ی کسب کردن تجربه‌شان را از زندگی خود مهم‌تر بدانند و همین مسئله حس رضایت‌بخشی به آن‌ها می‌دهد.
 
-## What it means to contribute
+## مشارکت به چه معناست؟
 
-If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+اگر در مشارکت یک پروژه‌ی متن باز تازه‌وارد هستید، فرآیند آن می‌تواند ترسناک باشد. شما چگونه یک پروژه درست برای مشارکت کردن در آن را انتخاب می‌کنید؟ اگر چیزی از کد نویسی ندانید، چی؟ اگر چیزی درست پیش نرود، چی؟
 
-Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+خب، نگران نباشید! راه‌های زیادی برای مشارکت در پروژه‌های متن باز وجود دارد که در ادامه‌ی مقاله مواردی از آن‌ها را می‌آوریم که می‌تواند به بدست آوردن تجربه‌های بیشتر به شما کمک کند.
 
-### You don't have to contribute code
+### الزماً قرار نیست در فرایند کدنویسی مشارکت کنید
 
-A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+یک دید غلط و مرسومی که برای مشارکت در پروژه‌های متن باز وجود دارد این است که فکر می‌کنند برای مشارکت در آن باید حتما کدنویسی شود. در حقیقت، [اغلب بخش‌های دیگر پروژه](https://github.com/blog/2195-the-shape-of-open-source) است که از آن غفلت یا بیش از حد به آن توجه می‌شود. شما با برطرف کردن مشکلات و مشارکت در آن بخش‌ها لطف بزرگی به پروژه‌های متن باز می‌کنید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
-  I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+  من شهرتم را از کار در CocoaPods به دست آوردم، اما بیشتر مردم نمی‌دانند که من واقعاً هیچ کار واقعی با ابزار CocoaPods انجام نمی‌دادم. زمانم در آن پروژه بیشتر روی چیزهایی مانند اسناد یا کار روی برندسازی صرف می‌شد.
   <p markdown="1" class="pquote-credit">
 — @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
   </p>
 </aside>
 
-Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+حتی اگر هم به کدنویسی در پروژه علاقه‌مند باشید، روش‌های دیگر مشارکت بهترین راه‌برای درگیر شدن در یک پروژه و ملاقات با اعضای انجمن‌های دیگر وجود دارد. ساختن این روابط به شما فرصت‌هایی می‌دهد تا در بخش‌های دیگر پروژه مشارکت کنید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing.
+  زمانی که درخواست مشارکتم را در 17 ژوئن سال 2002 به تیم توسعه‌ی پایتون با نام مستعار (python-dev) ارسال کردم، توانستم اولین مشارکتم را با آن‌ها شروع کنم. به سرعت باگ‌ها و خطاهای پروژه‌ی متن باز را پیدا می‌کردم و تصمیم می‌گرفتم خلاصه‌های آن را برای گروه تنظیم کردم. آن‌ها بهانه‌های زیادی می‌آوردند که یک موضوع را روشن کنم، اما با تمام انتقادات، زمانی که هر کسی برای برطرف کردن یک مشکل به کمک نیاز داشت، من آن را متوجه می‌شدم.
   <p markdown="1" class="pquote-credit">
 — @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
   </p>
 </aside>
 
-### Do you like planning events?
+### آیا به برگزاری رویدادها علاقه‌مند هستید؟
 
-* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
-* Organize the project's conference (if they have one)
-* Help community members find the right conferences and submit proposals for speaking
+* ورکشاپ (کارگاه‌ها) را سازماندهی یا جلسات پروژه را برگزار کنید، مانند کاری که @fzamperin برای [NodeSchool](https://github.com/nodeschool/organizers/issues/406) انجام داد
+* در صورت داشتن، برای یک پروژه کنفرانس برگزار کنید
+* به اعضای انجمن کمک کنید تا کنفرانس‌های درستی پیدا و برای کنفرانس پرپوزال خود را ارسال کنند.
 
-### Do you like to design?
+### آیا به طراحی علاقه‌مند هستید؟
 
-* Restructure layouts to improve the project's usability
-* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
-* Put together a style guide to help the project have a consistent visual design
-* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+* با هدف افزایش قابلیت استفاده به بهبود ساختار برنامه ها کمک کنید.
+* مشابه [دروپال](https://www.drupal.org/community-initiatives/drupal-core/usability) می‌توانید با هدف بهبود رابط کاربری اقدام به کاربرپژوهی و مطالعاتی از این دست کنید. 
+* با جمع آوری و یک کاسه کردن الگوهای طراحی به کار گرفته شده در پروژه یک شیونه نامه (استایل گاید) متمرکز ایجاد کنید.
+* اقدام به خلق کارهای هنری مثل طراحی لوگو یا تی شرت مخصوص کنید. مثل کاری که [hapi.js](https://github.com/hapijs/contrib/issues/68) انجام داد.
 
-### Do you like to write?
+### آیا به نویسندگی در پروژه علاقه‌مند هستید؟
 
-* Write and improve the project's documentation
-* Curate a folder of examples showing how the project is used
-* Start a newsletter for the project, or curate highlights from the mailing list
-* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
-* Write a translation for the project's documentation
+* اسناد پروژه را بنویسید و اصلاح کنید
+* پوشه‌ی نمونه‌ها را تنظیم کنید تا نحوه‌ی استفاده‌ی پروژه را نشان دهد
+* برای پروژه یک خبرنامه راه‌اندازی کنید، یا شاخصه‌های آن را نوشته و تنظیم کنید
+* برای پروژه، مطالب آموزشی بنویسید، مانند مشارکت‌کننده‌هایی که برای [PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194) مطالب آموزشی نوشتند
+* مستندات پروژه را به زبانی دیگر ترجمه کنید
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
-  Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+  اسناد یک پروژه به طور جدی مهم هستند. اسناد پروژه تا به الان عالی پیش رفتند و یکی از ویژگی‌های بی‌نظیر Babel نیز بوده است. بخش‌هایی در اسناد یک پروژه وجود دارد که مطمئناً می‌تواند از آن در برخی کارها استفاده کرد، حتی افزودن یک پاراگراف در این‌جا یا آن‌جا بی‌نهایت قایل تقدیر است.
   <p markdown="1" class="pquote-credit">
 — @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
   </p>
 </aside>
 
-### Do you like organizing?
+### آیا به سازماندهی پروژه علاقه‌مند هستید؟
 
-* Link to duplicate issues, and suggest new issue labels, to keep things organized
-* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
-* Ask clarifying questions on recently opened issues to move the discussion forward
+* برای سازماندهی کردن همه چیز، مشکلات تکراری را لینک کنید و مسائل جدیدی مطرح کنید
+* با مسئله‌های (issue) باز رودرو شوید و پیشنهاد دهید مسائل قدیمی حل شوند، مانند کاری که @nzakas برای [ESLin](https://github.com/eslint/eslint/issues/6765) انجام داد
+* برای پیشبرد بحث، سوالات شفافی درباره‌ی مسائل باز اخیر بپرسید
 
-### Do you like to code?
+### آیا به کدنویسی علاقه دارید؟
 
-* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
-* Ask if you can help write a new feature
-* Automate project setup
-* Improve tooling and testing
+* مسائل باز و حل نشده را پیدا و حل کنید، مانند کاری که @dianjin برای [Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) انجام داد
+* اگر می‌توانید برای اعمال یک ویژگی جدید به پروژه کمک کنید، درخواست‌تان را مطرح کنید
+* نصب پروژه را خودکار کنید
+* ابزارهای مرتبط و تسهیل کننده و تست پروژه را تقویت کنید
 
-### Do you like helping people?
+### آیا از کمک کردن به مردم لذت می‌برید؟
 
-* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
-* Answer questions for people on open issues
-* Help moderate the discussion boards or conversation channels
+* به سوالاتی که افراد درباره‌ی پروژه در سایت‌هایی مانند Stack، Postgres، یا Reddit می‌پرسند، جواب بدهید 
+* سوالات افرادی که مسائل حل نشده‌ای دارند را جواب بدهید
+* در اداره کانال‌های گفتگو و تالارهای گفتمان مشارکت کنید
 
-### Do you like helping others code?
+### آیا دوست دارید در کدنویسی به دیگران کمک کنید؟
 
-* Review code on other people's submissions
-* Write tutorials for how a project can be used
-* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+* کدنویسی سایر افراد را بررسی کنید
+* برای نحوه‌ی استفاده‌ی یک پروژه‌ی متن باز، مطلب آموزشی بنویسید
+* یک مشارکت کننده دیگر که می‌شناسید را پیشنهاد دهید، [مثل کاری که @ereichert در Rust برای @bronzdoc کرد][like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666).
+ 
+### لازم نیست فقط روی پروژه‌های نرم‌افزاری وقت صرف کنید!
 
-### You don't just have to work on software projects!
+با اینکه بیشتر پروژه‌های متن باز به نرم‌افزارها اطلاق می‌شود، اما می‌توانید هرچیزی از جمله کتاب‌ها، دستورالعمل، لیست چیزهای مختلف و کلاس‌ها را در پروژه‌های متن باز توسعه دهید.
 
-While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+به عنوان مثال:
 
-For example:
+* @sindresorhus [لیست‌هایی موسوم به «awesome»](https://github.com/sindresorhus/awesome) گردآوری و تنظیم می‌کند
+* @h5bp [یک لیست حاوی سوالاتی جهت مصاحبه برای توسعه دهندگان فرانت اند](https://github.com/h5bp/Front-end-Developer-Interview-Questions) را نگهداری و مرتب می‌کند
+* @stuartivnn و @nicole-a-tesla [مجموعه‌ای از حقایق جالب درباره‌ی طوطی دریایی](https://github.com/stuartlynn/puffin_facts) ایجاد کرده‌اند.
 
-* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
-* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
-* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+حتی اگر توسعه‌دهنده‌ی نرم‌افزار هم باشید، کار روی اسناد یک پروژه می‌توانید به شما کمک کند تا پروژه‌ی متن بازتان را شروع کنید. کار روی پروژه‌هایی که کدنویسی کمتری دارد اغلب ترس کمتری دارد و فرآیند همکاری در آن باعث می‌شود اعتمادبه‌نفس و تجربه‌ی شما افزایش پیدا کند.
 
-Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
-
-## Orienting yourself to a new project
+## ورود و وفق دادن خودمان به یک پروژه جدید
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
-  If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+  اگر به یک ایشو ترکر (issue tracker) برخوردید و چیزهای گیج‌کننده‌ای دیدید، نگران نباشید چون شما تنها نیستید. این ابزارها به دانش ضمنی زیادی نیاز دارند، اما سایرین می‌توانند به شما کمک کند و می‌توانید از آن‌ها سوالاتی بپرسید.
   <p markdown="1" class="pquote-credit">
 — @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
   </p>
 </aside>
 
-For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+مشارکت کردن در یک پروژه‌ی متن باز که بیشتر از اصلاح غلط‌هایی املائی است، مانند وارد شدن به پارتی غریبه‌هاست. اگر در این پارتی درباره ماهی قرمز بحث عمیقی شکل گرفته، شما درباره‌ی لاماها صحبت کنید، احتمالاً نگاه عجیبی به شما می‌شود.
+
+بنابراین، قبل از اینکه کورکورانه با پیشنهادهای‌تان وارد کاری شوید، یاد بگیرید که چگونه در چت روم‌ها گفتگو کنید. این کار شانس شما را برای شنیده شدن و توجه به ایده‌هایتان را بالا می‌برد.
 
-Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
 
-### Anatomy of an open source project
+### آناتومی یک پروژه‌ی متن باز
 
-Every open source community is different.
+جامعه‌ها در پروژه‌های متن باز متفاوت هستند.
 
-Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+زمانی که سال‌ها روی یک پروژه‌ی متن باز صرف می‌کنید، باید آن پروژه‌ی متن باز را بشناسید. از طرفی، زمانی هم که به پروژه‌ی متفاوتی منتقل می‌شوید، لغات، قوائد و سبک ارتباطاتی آن که ممکن است کاملاً متفاوت باشد را باید پیدا کنید.
 
-That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+گفته می‌شود بیشتر پروژه‌های متن باز از یک ساختار سازماندهی مشابه پیروی می‌کنند. شناخت و درک نقش‌ها در جوامع مختلف و فرآیند کلی آن به شما کمک می‌کند به سرعت وارد هر پروژه‌ی جدیدی شوید.
 
-A typical open source project has the following types of people:
+افراد مختلفی در یک پروژه‌ی متن باز معمولی مشارکت می‌کنند:
 
-* **Author:** The person/s or organization that created the project
-* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
-* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
-* **Contributors:** Everyone who has contributed something back to the project
-* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+* **نویسنده:** شخص یا سازمانی که یک پروژه را خلق می‌کند
+* **صاحب مالک:** شخص یا اشخاصی که صاحب اداری آن سازمان یا مخزن هستند (البته صاحب پروژه همیشه با نویسنده‌ی اصلی یکسان نیست)
+* **مسئول‌نگهداری پروژه:** مشارکت‌کننده‌هایی که مسئول پیش بردن چشم انداز و مدیریت جنبه‌های سازمانی یک پروژه باشند (این افراد همچنین می‌توانند نویسنده یا صاحب پروژه باشند)
+* **مشارکت‌کننده:** هر کسی که در پروژه مشارکت داشته باشد
+* **اعضای انجمن:** افرادی که از پروژه استفاده می‌کنند، می‌توانند مکالمات فعالانه‌ای داشته باشند یا نظرات‌شان را برای مسیر دادن به پروژه ابراز کنند
 
-Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+پروژه‌های بزرگ‌تر همچنین ممکن است زیرکمیته‌ها یا گروه‌های کاری داشته باشند که روی وظایف متفاوتی مانند مجهز کردن، triage (تریاژ)، معتدل کردن انجمن و سازماندهی رویداد متمرکز می‌شوند. زمانی که به صفحه‌ی «تیم» پروژه‌ی یک وب‌سایت، یا مخزن مراجعه کنید، می‌توانید اطلاعات این زیرکمیته‌ها و نقش افراد کلیدی را مشاهده کنید.
 
-A project also has documentation. These files are usually listed in the top level of a repository.
+پروژه‌های متن باز اسناد مختلفی دارند که این فایل‌ها معمولا در بالای لیست مخزن قرار می‌گیرند.
 
-* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
-* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
-* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
-* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
-* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.
+* **لایسنس/ گواهینامه (LICENSE):** طبق تعریف، هر پروژه‌ی متن بازی باید لایسنس مخصوص به خود را داشته باشد. اگر یک پروژه لایسنس نداشته باشد، اصلاً متن باز محسوب نمی‌شود
+* **فایل README:** فایل README یک دستورالعمل ساختاری برای تمام اعضای جدید انجمن است که می‌توانند آن را مطالعه می‌کنند. در این فایل به خوبی آورده شده که پروژه‌ی در دست چه فوایدی دارد و چگونه باید از آن استفاده کرد
+* **فایل CONTRIBUTING:** زمانی که یک فایل README می‌تواند به مردم برای استفاده از پروژه کمک کنند، فایل CONTRIBUTING هم می‌تواند برای مشارکت افراد در پروژه به شما و به آن‌ها کمک کند. در این فایل توضیح داده شده که به چه نوع مشارکتی نیاز است و فرآیند کاری پروژه به چه نحوه است. با اینکه هر پروژه فایل CONTRIBUTING ندارد، اما در صورت وجود چنین فایلی در پروژه می‌تواند به افراد مختلف سیگنال مشارکت در پروژه بدهد.
+* **CODE_OF_CONDUCT:** در فایل code of conduct می‌توانید قوائدی که شرکت‌کنندگان باید با در نظر گرفتن آن به صورت دوستانه و راحت و در یک محیط پذیرا با سایرین برخورد کنند را بنویسید. با اینکه هر پروژه ممکن است حاوی این فایل نباشد، اما زمانی که یک پروژه‌ی متن باز این فایل را داشته باشد، به مشارکت‌کننده‌ها این سیگنال را می‌فرستد می‌توانند در پروژه مشارکت داشته باشند. این فایل تقریباً حاوی توصیه‌هایی رفتاری برای تعامل است.
+* **اسناد دیگر:** یک پروژه‌ی متن باز به خصوص پروژه‌های بزرگ‌تر ممکن است حاوی اسناد دیگری مانند فایل‌های آموزشی، بازنگری فنی، راهنمای گام به گام (walkthroughs)، یا سیاست‌های دولتی باشند.
 
-Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+در نهایت، پروژه‌های متن باز برای سازماندهی بحث‌ها از ابزارهای زیر  استفاده می‌کنند. مطالعه‌ی آرشیو پروژه‌ها می‌تواند دید خوبی از نحوه‌ی فکر و کار انجمن‌ها بدهد.
 
-* **Issue tracker:** Where people discuss issues related to the project.
-* **Pull requests:** Where people discuss and review changes that are in progress.
-* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
-* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
+* **ایشو ترکر (Issue tracker):** جایی که افراد درباره‌ی مشکلات مرتبط با پروژه بحث می‌کنند
+* **درخواست Pull (Pull requests):** جایی که افراد درباره‌ی تغییرات جاری بحث و بازبینی می‌کنند.
+* **انجمن گفتگو یا خبرنامه های ایمیلی:** برخی از پروژه ها ممکن است برای موضوعات نیازمند بحث و گفتگو از انجمن های گفتگو یا خبرنامه ایمیلی به جای ایشو ترکر استفاده کنند. البته برخی دیگر ممکن است همین کار را به صورت کامل در بخش ایشو ترکر انجام دهند.
+* **Synchronous chat channel:** بعضی از پروژه‌های از کانال‌های چت مانند Slack یا IRC برای مکالمات محاوره‌ای، همکاری یا تبادلات سریع استفاده می‌کنند.
 
-## Finding a project to contribute to
+## یافتن یک پروژه جهت مشارکت کردن در آن
 
-Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+اکنون می‌دانید نحوه‌ی کار یک پروژه‌ی متن باز چگونه است. بنابراین، زمانش رسیده تا برای مشارکت، یک پروژه‌ی متن باز پیدا کنید!
 
-If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_
+اگر قبلا در هیچ پروژه‌ی متن بازی مشارکت نداشته‌اید، نصیحت رئیس جمهور آمریکا، جان. اف. کندی را بشنوید که گفت:«نگویید کشورتان برای شما چه کار کرده– بپرسید شما برای کشورتان چه کار کرده‌اید.»
 
-Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+مشارکت‌کننده‌ها در تمام سطح‌های می‌توانند در پروژه‌های متن باز مشارکت کنند. لازم نیست بیش از حد به ذهن خود فشار بیاورید که اولین مشارکت شما در یک پروژه دقیقاً به چه صورت است، یا اولین مشارکت‌تان در آن پروژه چگونه خواهد شد. 
 
-Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+در عوض، به پروژه‌هایی فکر کنید که قبلا استفاده شده، یا می‌خواهید استفاده کنید. پروژه‌هایی که به صورت فعال در آن مشارکت می‌کنید، پروژه‌هایی هستند که برمی‌گردند.
 
-Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+هر زمان در چنین پروژه‌هایی به این موضوع فکر کردید که می‌توانستید بهتر از این یا متفاوت‌تر باشد، بهتر است از روی غریزه کار کنید.
 
-Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+فکر نکنید یک پروژه‌ی متن باز انحصاری است، چون پروژه‌های متن باز توسط افرادی مانند شما طراحی شده است. یک پروژه‌ی متن باز تنها یک لفظ فانتزی برای برطرف کردن و حل مشکلات در دنیاست.
 
-You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
+شما در پروژه‌های متن باز می‌توانید فایل README را مطالعه، لینک‌های خراب و غلط‌های املائی را پیدا و برطرف کنید. شما و کاربران جدیدتان هم می‌توانند متوجه مشکل یا مسئله‌ای شوند که فکر کی‌کند باید از اسناد پروژه باشد. به جای نادیده گرفتن، عبور کردن یا سپردن آن مسائل به افراد دیگر، برای اصلاح آن مشکلات می‌توانید کمک کنید. این تمام چیزی است که یک پروژه‌ی متن باز می‌تواند داشته باشد!
 
-> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+> [28% از مشارکت‌کننده‌های معمولی](https://www.igor.pro.br/publica/papers/saner2016.pdf) روی اسناد پروژه‌ی متن باز مانند اصلاح غلط‌های املائی، شکل ‌دهی مجدد، یا نوشتن ترجمه مشارکت می‌کنند.
 
-If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+اگر به دنبال مسائل موجود پروژه‌ی متن بازتان هستید تا آن را برطرف کنید، می‌توانید وارد صفحه‌ی `/contribute` هر پروژه‌ی متن باز شوید که مشکلات را برای تازه‌واردها برجسته می‌کند. شما می‌توانید با حل کردن آن مشکلات، در مشارکت پروژه‌ی متن باز همکاری داشته باشد. برای این منظور می‌توانید به صفحه‌ی اصلی repository (مخزن) در سایت GitHub مراجعه کنید و کلمه‌ی `/contribute` را به انتهای آدرس URL آن اضافه کنید. به عنوان مثال:
+[`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
 
-You can also use one of the following resources to help you discover and contribute to new projects:
+شما همچنین می‌توانید از منابع زیر برای کشف و مشارکت در پروژه‌های جدید کمک بگیرید:
 
 * [GitHub Explore](https://github.com/explore/)
 * [Open Source Friday](https://opensourcefriday.com)
@@ -232,304 +227,306 @@ You can also use one of the following resources to help you discover and contrib
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://www.sourcesort.com/)
 
-### A checklist before you contribute
+### بررسی چک لیست قبل از مشارکت در پروژه‌ی متن باز
 
-When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+زمانی که پروژه‌ی مورد علاقه‌تان برای مشارکت را پیدا کردید، نگاهی سریعی داشته باشید که آیا آن پروژه مناسب است تا درخواست همکاری‌تان را بفرستید. در غیر این صورت، کار پُرتلاش شما ممکن است هیچوقت به نتیجه نرسد.
 
-Here's a handy checklist to evaluate whether a project is good for new contributors.
+در ادامه می‌تواند چک لیست دستی را ببینید که می‌تواند مشارکت‌کننده‌های جدید یک پروژه را ارزیابی کند.
 
-**Meets the definition of open source**
+**پروژه با تعریف پروژه‌ی متن باز مطابقت داشته باشد**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+  پروژه‌ای که می‌خواهید در آن مشارکت کنید، لایسنس دارد؟ در هر پروژه‌ی متن باز معمولاً فایلی با نام LICENSE در روت رسپاستوری (مخزن) آن وجود دارد
   </label>
 </div>
 
-**Project actively accepts contributions**
-
-Look at the commit activity on the master branch. On GitHub, you can see this information on a repository's homepage.
+**پروژه‌ی متن باز به صورت فعالانه‌ای حضور مشارکت‌کننده‌ها را قبول می‌کند**
 
+نگاهی به کامیت های اخیر در شاخه اصلی بیاندازید. در گیت‌هاب این این مورد در صفحه اصلی مخزن دیده می‌شود.
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-  When was the latest commit?
+  آخرین کامیت چه زمانی بود؟
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-  How many contributors does the project have?
+  چه تعداد مشارکت‌کننده در پروژه حضور دارند؟
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  افراد چند بار کامیت می‌کنند؟ (در GitHub، با کلیک روی «commits» روی بالای بار می‌توانید آن را متوجه شوید.)
   </label>
 </div>
 
-Next, look at the project's issues.
+در قدم بعدی به مسائل پروژه (issue) نگاهی بیندازید.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    How many open issues are there?
+    چه تعداد مسائل حل‌نشده و باز در پروژه وجود دارد؟
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to issues when they are opened?
+    آیا نگهدارندگان به موقع به مسائلی که مطرح می‌شوند واکنش نشان می‌دهند؟
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the issues?
+    آیا بحث‌ها و گفتگوهای فعالی جهت حل مسائل وجود دارد؟
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-    Are the issues recent?
+    آیا اخیراً مسائلی گزارش شده است؟
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+    مسائل پروژه‌ی متن باز برطرف شدند؟ (می‌توانید به صفحه‌ی Issues در GitHub و تب «closed» مراجعه کنید تا مسائل حل‌شده را ببینید.)
   </label>
 </div>
 
-Now do the same for the project's pull requests.
+حالا، تمام این مراحل را برای درخواست ادغام یا Pull Request پروژه هم در نظر بگیرید.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    How many open pull requests are there?
+    چه تعداد درخواست ادغام یا Pull Request در پروژه وجود دارد؟
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox20" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to pull requests when they are opened?
+    آیا زمان دریافت درخواست‌های ادغام، مسئول‌نگهداری به سرعت به آن‌ها جواب می‌دهد؟
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the pull requests?
+    آیا بحث‌های فعالی برای درخواست‌های ادغام وجود دارد؟
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    Are the pull requests recent?
+    آیا درخواست‌های ادغام جدیدی در پروژه وجود دارد؟
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox13" class="overflow-hidden d-block text-normal">
-    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+    جدیدترین درخواست‌هایی که ادغام شدن چه بودند؟ (می‌توانید در صفحه‌ی Pull Requests و تب «closed» در سایت GitHub بروید تا درخواست‌های ادغام انجام شده را ببینید
   </label>
 </div>
 
-**Project is welcoming**
+**پروژه پذیرای مشارکت است**
 
-A project that is friendly and welcoming signals that they will be receptive to new contributors.
+زمانی که یک پروژه‌ی متن باز پذیرای مشارکت‌کننده‌های جدید باشد، سیگنال‌های دوستانه‌ای برای مشارکت‌کننده‌ها می‌فرستد.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox14" class="overflow-hidden d-block text-normal">
-    Do the maintainers respond helpfully to questions in issues?
+    آیا مسئول ‌نگهداری جواب مفیدی به سوالات در بخش مسائل (Issues) می‌دهد؟
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox15" class="overflow-hidden d-block text-normal">
-    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+    آیا افراد در صفحه‌ی issue، تالارهای گفتگو، و صفحات چت مانند IRC یا Slack به طور دوستانه‌ای رفتار می‌کنند؟
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox16" class="overflow-hidden d-block text-normal">
-    Do pull requests get reviewed?
+    آیا درخواست‌های ادغام بررسی می‌شوند؟
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox17" class="overflow-hidden d-block text-normal">
-    Do maintainers thank people for their contributions?
+    آیا مسئول ‌نگهداری از افراد به خاطر مشارکت‌شان تشکر می‌کند؟
   </label>
 </div>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-  Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+  هر زمان که با یک موضوع طولانی روبه‌رو شدید، جواب‌های توسعه‌دهندگان اصلی که در اواخر موضوع قرار دادند را بررسی کنید. آیا جواب آن‌ها به طور سازنده‌ای خلاصه است و با لحن مودبانه‌ای تصمیم می‌گیرند؟ اگر چیزهای بی‌ادبانه‌ای می‌بینید، اغلب به این خاطر است که به جای توسعه، انرژی منفی می‌دهند
   <p markdown="1" class="pquote-credit">
 — @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
   </p>
 </aside>
 
-## How to submit a contribution
+## چگونه درخواست مشارکت را ارسال کنیم
 
-You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+زمانی که پروژه‌ی مورد علاقه‌تان را پیدا کردید، آماده‌ی مشارکت در آن می‌شوید و در نهایت باید راهی برای ارسال مشارکت خود به آن پیدا کنید.
 
-### Communicating effectively
+### ارتباط موثر
 
-Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+خواه مشارکت‌کننده‌ی یک‌باره باشید، یا سعی داشته باشید در یک انجمن عضو شوید، کار کردن با دیگران می‌تواند یکی از مهم‌ترین مهارت‌هایی باشد که در مشارکت در پروژه‌ی متن باز می‌توانید آن‌ را توسعه و بهبود دهید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
-  \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+  من به عنوان یک مشارکت‌کننده‌ی جدید به سرعت متوجه شدم که اگر می‌خواهم مسائل مرتبط با پروژه متن باز را برطرف کنم، باید سوال بپرسم. کد را سرسری مطالعه کردم، به خود آمدم و خواستم من را بیشتر راهنمایی کنند. در نتیجه، بعد از دریافت تمام جزئیاتی که نیاز داشتم، توانستم مسائل پروژه را برطرف کنم
   <p markdown="1" class="pquote-credit">
 — @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
   </p>
 </aside>
 
-Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+قبل از درخواست ادغام یا باز کردن issue در بخش گزارش مسئله یا پرسیدن سوال در چت، نکته‌های زیر را در نظر داشته باشید تا به شما کمک کند تا ایده‌هایتان کارآمد و موثرتر باشد.
 
-**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+**ارائه‌ی زمینه:** به دیگران کمک کنید تا سرعت خود را افزایش دهند. اگر خطایی پیدا کردید و در حال برطرف کردن آن هستید، به دیگران توضیح دهید که سعی دارید چه کاری انجام می‌دهید و چگونه آن مشکل را حل می‌کنید. اگر ایده‌ی جدیدی هم پیشنهاد می‌دهید، نه تنها برای خود، بلکه برای دیگران توضیح دهید که چرا فکر می‌کنید این ایده‌ی شما می‌تواند برای پروژه مفید باشد.
 
-> 😇 _"X doesn't happen when I do Y"_
+> 😇 _"زمانی که Y را انجام می‌دهم، X اتفاق نمی‌افتد"_
 >
-> 😢 _"X is broken! Please fix it."_
+> 😢 _"X به مشکل برخورد کرده است! لطفا برطرفش کنید."_
 
-**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn.
+**تکالیف‌تان را از قبل انجام دهید.** اگر چیزی نمی‌دانید مشکلی نیست، اما باید نشان دهید که تلاش‌تان را می‌کنید. قبل از اینکه از دیگران کمک بخواهید، مطمئن شوید که فایل README، اسناد، مسائل حل شده یا حل نشده، لیست پست پروژه را خوانده‌اید، یا در اینترنت به دنبال جواب‌تان گشته‌اید. وقتی تلاش‌تان برای یادگیری را نشان می‌دهید، مورد توجه تحسین دیگران قرار می‌گیرید
 
-> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+> 😇 _"مطمئن نیستم چگونه X را اجرا کنم. برای پیدا کردن جواب، فایل‌ها را بررسی کردم و هیچ جوابی نگرفتم."_
 >
-> 😢 _"How do I X?"_
+> 😢 _"چگونه مسئله X را برطرف کنم؟"_
 
-**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+**درخواست‌ها را مختصر و مفید مطرح کنید** هر مشارکتی مانند ارسال یک ایمیل، بدون در نظر گرفتن ساده یا مفید بودنش، به توجه‌ی دیگران نیاز دارد. معمولاً درخواست‌ها و سوالات اکثر پروژه‌ها از افرادی که می‌خواهند به آن‌ها جواب بدهند بیشتر است. بنابراین، درخواست‌ها باید مختصر باشد. با کوتاه بودن درخواست‌ها به افراد شانس بیشتری می‌دهید تا فرصت کمک کردن به شما را پیدا کنند.
 
-> 😇 _"I'd like to write an API tutorial."_
+> 😇 _"تمایل دارم یک فایل آموزشی API بنویسم"_
 >
-> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+> 😢 _"زمانی که در بزرگ‌راه در حال رانندگی کردن بودم، کنار یک پمپ بنزین توقف کردم و ایده‌ی شگفت‌انگیزی به ذهنم رسید که باید آن را عملی کنیم، اما قبل از توضیح، اجازه دهید ایده‌ام را به شما نشان بدهم ..."_
 
-**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+**تمام ارتباطات و تعاملات را به صورت عمومی نگهدارید.** هرچند وسوسه‌کننده است، اما به طور خصوصی با مسئول‌نگهداری پروژه تماس نگیرید مگر اینکه لازم باشد اطلاعات حساس مانند مسائل امنیتی یا نقض رفتار جدیدی را رد و بدل کنید. زمانی که مکالمه‌ی شما عمومی شود، افراد بیشتری از تبادیل این ارتباطات یاد می‌گیرند و بهره می‌گیرند. بحث و گفتگوها می‌تواند خودبه خود کمک‌رسان باشد.
 
-> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+> 😇 (در کامنت) «@-مسئول‌نگهداری: سلام! چگونه درخواست ادغام را پیش ببریم؟"_
 >
-> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+> 😢 (در ایمیل) «سلام، ببخشید از طریق ایمیل مزاحم می‌شم، اما نمی‌دانم که می‌توانید درخواست ادغام من را بررسی کنید.»_
 
-**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+**سوال کردن عیب نیست (اما صبور باشید!).** هرکسی در ابتدای کار در پروژه تازه‌وارد بوده است. حتی مشارکت‌کننده‌های باتجربه زمانی که به پروژه‌ی جدیدی مراجعه می‌کنند، باید سرعت خود را افزایش دهند. با این حساب، حتی مسئول‌نگهدارهای طولانی مدت هم همیشه با تمام بخش‌های یک پروژه آشنا نیستند. بنابراین، سعی کنید صبور باشید تا فرصت نشان دادن آن را به شما بدهند.
 
-> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+> 😇 _"بابت بررسی کردن این خطا ممنونم. پیشنهادهای شما را دنبال می‌کنم. این خروجی کار است"_
 >
-> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+> 😢 _"چرا مشکل من را نمی‌توانید حل کنید؟ این پروژه مگر پروژه‌ی شما نیست؟"_
 
-**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+**به تصمیمات انجمن احترام بگذارید.** ایده‌های شما ممکن است با اولویت‌ها و دید انجمن متفاوت باشد. آن‌ها یا می‌توانند به ایده‌های شما بازخورد بدهند یا آن را دنبال نکنند. درحالی‌که باید بحث و گفتگو کنید و به دنبال مصالحه باشید، مسئول‌نگهداری باید با تصمیمات شما بیشتر از شما زندگی کند. اگر با مسیر آن‌ها مخالف هستید، همیشه می‌توانید روی کار خود تمرکز کنید و پروژه‌ی خودتان را شروع کنید.
 
-> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+> 😇 _"ناامید شدم که نمی‌توانید پرونده‌ی من را پشتیبانی کنید، اما همانطور که توضیح دادید این مسئله تنها روی بخشی از کاربران تاثیر می‌گذارد. متوجه هستم چرا. بابت شنیدن پیامم ممنون هستم"_
 >
-> 😢 _"Why won't you support my use case? This is unacceptable!"_
+> 😢 _"چرا مورد من را پشتیبانی نمی‌کنید؟ این کار شما غیرقابل قبول است!"_
 
-**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+**فراتر از همه اینها.** مشارکت‌کننده‌های سراسر دنیا پروژه‌های متن باز را می‌سازند. متن‌های پروژه‌ها می‌تواند با زبان‌ها، فرهنگ‌ها، جغرافیاها و مناطق زمانی زیادی باشد. مدل ارتباط نوشتاری رساندن لحن و حالت مشارکت‌کننده‌های یک پروژه را مشکل می‌کند. اما نیت خیر تمام این گفتگوها را در نظر داشته باشید. خوب است که ایده‌ی خود را مودبانه منتقل کنید، متن و محتوای بیشتری درخواست کنید، یا موقعیت‌تان را روشن‌تر کنید. فقط سعی کنید اینترنت را از زمانی که وارد شدید، را جای بهتری کرده باشید
 
 ### Gathering context
 
-Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+قبل از اینکه کاری انجام دهید، به سرعت بررسی کنید و مطمئن شوید که ایده‌ی شما در هیج جای مورد بحث قرار نگرفته باشد. فایل README، مسائل حل‌شده یا حل‌نشده، لیست پست و گفتگوهای Stack را به طور سرسری مطالعه کنید. لازم نیست ساعت‌ها صرف خواندن آن‌ها کنید، اما جستجوی سریع درباره‌ی کلمات کلیدی می‌تواند تا حد زیادی به شما کمک کند
 
-If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request:
+اگر ایده‌ی شما در جای دیگری مطرح نشده بود، می‌توانید آن را بیان کنید. اگر پروژه در GitHub باشد، با باز کردن Issue یا درخواست ادغام Pull Request احتمالاً می‌توانید مکالمه داشته باشید:
 
-* **Issues** are like starting a conversation or discussion
-* **Pull requests** are for starting work on a solution
-* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one
+* **Issues** مانند شروع یک مکالمه یا گفتگو است
+* **Pull Requests** برای کار روی راه‌حل است
+* **سایر راه های ارتباطی راه‌های ارتباطی** مانند شفاف‌سازی، نحوه‌ی پرسیدن سوال (How-to question)، پرسیدن سوال در Stack، IRC، Slack یا دیگر کانال‌های چت است، البته اگر یک پروژه چنین راه‌های ارتباطی را باز گذاشته باشد.
 
-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.
+قبل از باز کردن issue یا درخواست ادغام، اسناد مشارکت پروژه را بررسی کنید که معمولاً در فایل‌هایی به نام CONTRIBUTING یا README آورده شدند تا چیزهای خاصی که دنبالش هستید را مطالعه کنید. به عنوان مثال، آن‌ها ممکن است از شما درخواست کنند الگوها را پیروی کنید یا به این نیاز داشته باشند که از این تست‌ها استفاده کنند.
 
-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.
+اگر در یک پروژه مشارکت عمیق و اساسی داشته باشید، قبل از مشارکت در پروژه، یک issue باز کنید و سوال کنید. این کار مفید است و باعث می‌شود پروژه‌ی شما مدتی مشاهده شود. (در سایت GitHub می‌توانید [روی «Watch» کلیک کنید](https://help.github.com/articles/watching-repositories/) تا از تمام مکالمات مطلع شوید)، و قبل از انجام دادم کار که ممکن است پذیرفته نشود، اعضای انجمن را بشناسید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
-  You'll learn <em>a lot</em> from taking a single project you actively use, "watching" it on GitHub and reading every issue and PR.
+  با فعالیت در پروژه‌های GitHub و مطالعه‌ی تمام issue و درخواست‌های ادغام می‌توانید چیزهای زیادی یاد بگیرید.
 <p markdown="1" class="pquote-credit">
 — @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
   </p>
 </aside>
 
-### Opening an issue
+### باز کردن Issue یا طرح سوال و گفتگو
+
+در موقعیت‌های زیر معمولاً باید یک issue باز کنید:
+
+* جهت گزارش خطایی که خودتان نمی‌توانید آن را حل کنید
+* درباره‌ی موضوعات یا ایده‌ی سطح بالا بحث کنید (به عنوان مثال، درباره‎ی جامعه، دیدگاه یا سیاست‌ها)
+* ویژگی جدید یا ایده‌ی جدیدی برای پروژه پیشنهاد دهید
 
-You should usually open an issue in the following situations:
+نکاتی برای برقراری ارتباط با مشکلات issues:
 
-* Report an error you can't solve yourself
-* Discuss a high-level topic or idea (for example, community, vision or policies)
-* Propose a new feature or other project idea
+* **اگر با مسئله‌ی بازی روبه‌رو شدید که می‌خواهید آن را برطرف کنید**، کامنت کردن برای یک مسئله به افراد اجازه می‌دهد بدانند که شما این مسئله را باز کردید. به این ترتیب، افراد احتمالاً کمتر با مشکلات مشابه‌ی شما برخورد می‌کنند
+* **اگر یک issue مدتی پیش باز بوده است**، احتمال دارد جای دیگر به آن جواب داده شده باشد، یا قبلا حل شده است. بنابراین، قبل از شروع کار می‌توانید برای تایید حل شدن یا حل نشدن آن درخوست کامنت بدهید.
+* **اگر یک issue باز کردید**، اما جواب آن را بعدها متوجه شدید، روی issue کامنت بگذارید تا مردم متوجه شوند، سپس issue را ببندید. حتی با نوشتن اسناد می‌تواند سهمی در مشارکت پروژه داشته باشید.
 
-Tips for communicating on issues:
+### ارسال Pull request (درخواست ادغام)
 
-* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
-* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
-* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+شما معمولاً در موقیعت‌های زیر باید درخواست ادغام باز کنید:
 
-### Opening a pull request
+* ارائه اصلاحات ناچیز (به عنوان نمونه، غلط‌های املائی، لینک‌های خراب یا خطاهای مشهود)
+* کار کردن روی مشارکتی که قبلا درخواست شده یا درباره‌ی آن بحث و گفتگو شده باشد
 
-You should usually open a pull request in the following situations:
+درخواست ادغام لزوماً به معنای پایان کار نیست. معمولاً بهتر است درخواست ادغام را قبلا باز کنید تا دیگران بتوانند آن را مشاهده و بازخوردهای خود را برای پیشرفت شما ارسال کنند. فقط آن را به «WIP» (کار در حال انجام) در کادر عنوان نشانه‌گذاری کنید. شما بعدها می‌توانید کامیت‌های بیشتری اضافه کنید.
 
-* Submit trivial fixes (for example, a typo, a broken link or an obvious error)
-* Start work on a contribution that was already asked for, or that you've already discussed, in an issue
+اگر پروژه در GitHub باشد، با روش‌های زیر می‌توانید درخواست ادغام ارسال کنید:
 
-A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
+* **[Fork the repository](https://guides.github.com/activities/forking/)** و یک نسخه برای خودتان کپی کنید. نسخه محلی خود را به مخزن بالادستی متصل کنید. هر از چندگاهی با دستور Pull آخرین نسخه تغییرات در مخزن اصلی را دریافت کنید تا پیش از اینکه تعارضی ما بین نسخه محلی و مخزن ایجاد شد بتوانید با مشکلات احتمالی کمتری تغییرات خود را به سمت مخزن اصلی ارسال کنید. [برای کسب اطلاعات بیشتر اینجا را مرور کنید](https://help.github.com/articles/syncing-a-fork/)
+* **[ایجاد یک شاخه](https://guides.github.com/introduction/flow/)** برای اعمال ویرایش ها.
+* در حین ارسال ها **به مسائل (issue) مرتبط ارجاع دهید** یا در کامنت مربوط به تغییرات جدید به مستندات مربوطه اشاره کنید.(مثال: این تغییر مشکل مطرح شده در مسئله شماره 37 را برطرف می‌کند.)
+* اگر تغییرات شما حاوی تفاوت‌های HTML/CSS باشد، **تصاویر مربوط به قبل و بعد آن را اضافه کنید**. تصاویر را وارد بدنه‌ی درخواست ادغام کنید و رها کنید.
+* تغییرات‌تان را **تست کنید!** تغییرات خود را در برابر تست‌های موجود اجرا کنید و در صورت لزوم تغییرات جدیدی خلق کنید. اگر حتی تست‌هایی تعریف نشده بود، مطمئن شوید تغییرات‌تان پروژه‌ی موجود شما را خراب نکند.
+* با تمام توانایی‌تان ** الگوها را رعایت کرده و مطابق سبک پروژه مشارکت کنید**. این توانایی می‌تواند به معنای استفاده از تورفتگی‌ها، نقطه ویرگول (semi-colons)، یا کامنت‌های متفاوتی باشد که شما در مخزن‌تان خودتان دارید. این کار ادغام مسئول‌نگهداری را ساده می‌کند، دیگران هم متوجه آن می‌شوند و می‌توانند آن را برای زمان‌های آتی حفظ کنند.
 
-If the project is on GitHub, here's how to submit a pull request:
+اگر این اولین درخواست ادغام شماست، فیلم آموزشی [Make a Pull Request](http://makeapullrequest.com/) که @kentcdodds آن را خلق کرده، بررسی کنید. شما همچنین می‌توانید از [Make a Pull Request](https://github.com/Roshanjossey/first-contributions) که توسط @Roshanjossey ایجاد شده به عنوان یک محزن تمرینی برای اولین تجربه خود استفاده کنید.
 
-* **[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/).)
-* **[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.
-* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
-* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+## بعد از ارسال درخواست مشارکت چه اتفاقی می‌افتد
 
-If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+شما درخواست‌تان را ارسال کردید! شروع مشارکت‌تان در یک پروژه‌ی متن باز را تبریک می‌گوییم. امیدواریم این اولین قدم‌تان باشد.
 
-## What happens after you submit a contribution
+بعد از ارسال درخواست مشارکت‌تان، یکی از اتفاقات زیر رخ می‌دهد:
 
-You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
+### 😭 جوابی دریافت نمی‌کنید.
 
-After you submit a contribution, one of the following will happen:
+امیدواریم قبل از ارسال درخواست مشارکت، [چک لیست فعالیت‌های پروژه](#a-checklist-before-you-contribute) را برررسی کرده باشید. هرچند، حتی در پروژه‌ی فعال هم این احتمال وجود دارد که به درخواست مشارکت شما پاسخ ندهند.
 
-### 😭 You don't get a response.
+اگر بیش از یک هفته جوابی برایتان ارسال نشد، به طور مودبانه می‌توانید درخواست جواب دهید و از کسی بخواهید درخواست شما را بررسی کند. اگر نام کسی که می‌خواهید درخواست شما را بررسی کند می‌دانید، می توانید به اون اشاره (منشن: با گذاشتن علامت @ در ابتدای نام کاربری) کنید.
 
-Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+به صورت خصوصی با آن شخص **تماس نگیرید**. به یاد داشته باشید ارتباط عمومی برای پروژه‌ها بسیار حیاتی است.
 
-If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+اگر به طور مودبانه درخواست‌هایتان را فرستاده باشید اما هنوز هیچ‌کس پاسخگو نیست، احتمالاً هیچ‌کس هیچوقت پاسخ شما را نخواهد داد. می‌دانیم که حس خوبی ندارد، اما اجازه ندهید این موضوع شما را دلسرد کند چون این اتفاق ممکن است برای همه رخ دهد! 
 
-**Don't** reach out to that person privately; remember that public communication is vital to open source projects.
+برای برطرف کردن این مشکل دلایل زیادی وجود دارد که به شما می‌گوید چرا پاسخ درخواست‌تان داده نمی‌شود؛ دلایلی مانند شرایط شخصی که ممکن است از کنترل خارج شود. شما می‌تواند پروژه‌ی دیگر یا راهی برای مشارکت پیدا کنید. قبل از اینکه اعضای یک انجمن متهد یا پاسخگو باشند، زمان زیادی را صرف ارسال درخواست مشارکت‌تان نکنید.
 
-If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+### 🚧 یک نفر برای تغییر درخواست‌تان به شما پیام می‌دهد.
 
-### 🚧 Someone requests changes to your contribution.
+مرسوم است کسی بخواهید درخواست مشارکت خود را تغییر دهید، این درخواست تغییر می‌تواند در بازخورد ایده‌ یا در تغییرات کد شما باشد.
 
-It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+اگر کسی درخواست تغییر برای‌تان ارسال کرد، پاسخگو باشید، چون آن‌ها برای بررسی درخواست مشارکت شما زمان گذاشتند. باز گذاشتن PR (درخواست ادغام) و نادیده گرفتن آن صورت خوبی ندارد. اگر نمی‌دانید چگونه روی درخواست‌تان آن تغییرات را اعمال کنید، مشکلات را جستجو کنید و در صورت نیاز از کسی کمک بخواهید.
 
-When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it.
+اگر برای برطرف کردن مسائل پروژه دیگر زمان کافی ندارید (به عنوان نمونه، اگر مکالمه‌ی شما ماه‌ها طول کشید، و اکنون شرایط شما تغییر کند)، اجازه دهید مسئول‌نگهداری پروژه از این موضوع مطلع شود تا منتظر جواب شما نباشد. حتی کسی دیگری ممکن است جای شما را بگیرد.
 
-If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
 
-### 👎 Your contribution doesn't get accepted.
+### 👎 درخواست مشارکت‌تان پذیرفته نشد
 
-Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+در پایان، درخواست مشارکت‌تان ممکن است پذیرفته شود یا نشود. هرچند، در صورت پذیرفته نشدن درخواست‌تان امیدواریم زمان زیادی روی آن صرف نکرده باشید. اگر مطمئن نیستید که چرا درخواست‌تان پذیرفته نشده، کاملاً معقولانه است که برای درخواست بازخورد و شفاف‌سازی از مسئول‌نگهداری جواب بخواهید. در نهایت، با احترام به تصمیم آن‌ها نباید خشمگین و عصبانی شوید. همیشه می‌توانید پروژه‌ی دیگری انتخاب کنید و اگر هم نمی‌خواهید در پروژه‌ای مشرکت کنید، می‌توانید پروژه‌ی خودتان را داشته باشید!
 
-### 🎉 Your contribution gets accepted.
+### 🎉 درخواست مشارکت شما پذیرفته شد.
 
-Hooray! You've successfully made an open source contribution!
+هوررا! درخواست مشارکت شما برای پروژه‌ی متن باز موفقیت‌آمیز بوده است
 
-## You did it!
+## انجامش دادی!
 
-Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
+خواه دنبال ارسال درخواست مشارکت خود برای اولین پروژه‌تان باشد، یا دنبال راه یک جدید برای مشارکت در یک پروژه‌ی متن باز باشید، امیدواریم انگیزه این کار را داشته باشید. حتی اگر درخواست‌تان هم پذیرفته نشد، فراموش نکنید از تلاش مسئول‌نگهداری پروژه تشکر کنید که تمام تلاش خود را برای کمک به شما گذاشت. پروژه‌های متن باز، مسائل، درخواست ادغام، کامنت توسط افرادی مانند شما تولید می‌شود.

From 93a6a352b19c60492ec5154ffd3635f899f0a437 Mon Sep 17 00:00:00 2001
From: Nova <nova@suprnova.dev>
Date: Tue, 20 Apr 2021 12:45:00 -0400
Subject: [PATCH 153/749] Fix broken links

---
 _articles/best-practices.md    | 2 +-
 _articles/code-of-conduct.md   | 2 +-
 _articles/finding-users.md     | 2 +-
 _articles/getting-paid.md      | 2 +-
 _articles/how-to-contribute.md | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/_articles/best-practices.md b/_articles/best-practices.md
index c125b826beb..1d311457735 100644
--- a/_articles/best-practices.md
+++ b/_articles/best-practices.md
@@ -272,7 +272,7 @@ Just like any other type of work, taking regular breaks will keep you refreshed,
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/code-of-conduct.md b/_articles/code-of-conduct.md
index 0b21e42d458..1ee5772d1cf 100644
--- a/_articles/code-of-conduct.md
+++ b/_articles/code-of-conduct.md
@@ -37,7 +37,7 @@ In addition to communicating your expectations, a code of conduct describes the
 
 Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
 
-The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](http://citizencodeofconduct.org/) are also two good code of conduct examples.
+The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples.
 
 Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
 
diff --git a/_articles/finding-users.md b/_articles/finding-users.md
index 84ec4c6e7ca..79ac1bc37f3 100644
--- a/_articles/finding-users.md
+++ b/_articles/finding-users.md
@@ -116,7 +116,7 @@ As you write your talk, focus on what your audience will find interesting and ge
   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
   When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
   <p markdown="1" class="pquote-credit">
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
   </p>
 </aside>
 
diff --git a/_articles/getting-paid.md b/_articles/getting-paid.md
index 42d75af5b33..c150d731e57 100644
--- a/_articles/getting-paid.md
+++ b/_articles/getting-paid.md
@@ -140,7 +140,7 @@ Depending on your project, you may be able to charge for commercial support, hos
 * **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
 * **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
 
-Some popular projects, like [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
 
 ### Apply for grant funding
 
diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 81158f6f25a..f3bcf0b445f 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -230,7 +230,7 @@ You can also use one of the following resources to help you discover and contrib
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### A checklist before you contribute
 

From dedaed07d0eabea3ae3b11bbfbf0ae956eb95ffc Mon Sep 17 00:00:00 2001
From: Nova <nova@suprnova.dev>
Date: Tue, 20 Apr 2021 14:57:45 -0400
Subject: [PATCH 154/749] Update links in translated versions

---
 _articles/de/best-practices.md         | 2 +-
 _articles/de/code-of-conduct.md        | 2 +-
 _articles/de/getting-paid.md           | 2 +-
 _articles/de/how-to-contribute.md      | 2 +-
 _articles/es/best-practices.md         | 2 +-
 _articles/es/code-of-conduct.md        | 2 +-
 _articles/es/getting-paid.md           | 2 +-
 _articles/es/how-to-contribute.md      | 2 +-
 _articles/fr/best-practices.md         | 2 +-
 _articles/fr/code-of-conduct.md        | 2 +-
 _articles/fr/getting-paid.md           | 2 +-
 _articles/fr/how-to-contribute.md      | 2 +-
 _articles/hu/best-practices.md         | 2 +-
 _articles/hu/code-of-conduct.md        | 2 +-
 _articles/hu/getting-paid.md           | 2 +-
 _articles/hu/how-to-contribute.md      | 2 +-
 _articles/id/best-practices.md         | 2 +-
 _articles/id/code-of-conduct.md        | 2 +-
 _articles/id/getting-paid.md           | 2 +-
 _articles/id/how-to-contribute.md      | 2 +-
 _articles/ja/best-practices.md         | 2 +-
 _articles/ja/code-of-conduct.md        | 2 +-
 _articles/ja/getting-paid.md           | 2 +-
 _articles/ja/how-to-contribute.md      | 2 +-
 _articles/ko/best-practices.md         | 2 +-
 _articles/ko/code-of-conduct.md        | 2 +-
 _articles/ko/getting-paid.md           | 2 +-
 _articles/ko/how-to-contribute.md      | 2 +-
 _articles/ms/best-practices.md         | 2 +-
 _articles/ms/code-of-conduct.md        | 2 +-
 _articles/ms/getting-paid.md           | 2 +-
 _articles/ms/how-to-contribute.md      | 2 +-
 _articles/nl/best-practices.md         | 2 +-
 _articles/nl/code-of-conduct.md        | 2 +-
 _articles/nl/getting-paid.md           | 2 +-
 _articles/nl/how-to-contribute.md      | 2 +-
 _articles/pl/best-practices.md         | 2 +-
 _articles/pl/code-of-conduct.md        | 2 +-
 _articles/pl/getting-paid.md           | 2 +-
 _articles/pl/how-to-contribute.md      | 2 +-
 _articles/pt/best-practices.md         | 2 +-
 _articles/pt/code-of-conduct.md        | 2 +-
 _articles/pt/getting-paid.md           | 2 +-
 _articles/pt/how-to-contribute.md      | 2 +-
 _articles/ro/best-practices.md         | 2 +-
 _articles/ro/code-of-conduct.md        | 2 +-
 _articles/ro/getting-paid.md           | 2 +-
 _articles/ro/how-to-contribute.md      | 2 +-
 _articles/ta/best-practices.md         | 2 +-
 _articles/ta/code-of-conduct.md        | 2 +-
 _articles/ta/getting-paid.md           | 2 +-
 _articles/ta/how-to-contribute.md      | 2 +-
 _articles/tr/best-practices.md         | 2 +-
 _articles/tr/code-of-conduct.md        | 2 +-
 _articles/tr/getting-paid.md           | 2 +-
 _articles/tr/how-to-contribute.md      | 2 +-
 _articles/zh-hans/best-practices.md    | 2 +-
 _articles/zh-hans/code-of-conduct.md   | 2 +-
 _articles/zh-hans/how-to-contribute.md | 2 +-
 _articles/zh-hant/best-practices.md    | 2 +-
 _articles/zh-hant/code-of-conduct.md   | 2 +-
 _articles/zh-hant/how-to-contribute.md | 2 +-
 62 files changed, 62 insertions(+), 62 deletions(-)

diff --git a/_articles/de/best-practices.md b/_articles/de/best-practices.md
index 10cc7bdd7fa..ce2a28b7e53 100644
--- a/_articles/de/best-practices.md
+++ b/_articles/de/best-practices.md
@@ -297,7 +297,7 @@ Genau wie bei jeder anderen Art von Arbeit, werden Sie durch regelmäßige Pause
   _In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important._
 
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/de/code-of-conduct.md b/_articles/de/code-of-conduct.md
index 7a2c427c733..10d6bcfd834 100644
--- a/_articles/de/code-of-conduct.md
+++ b/_articles/de/code-of-conduct.md
@@ -31,7 +31,7 @@ Neben der Klarstellung Ihrer Erwartungen beschreibt ein Verhaltenskodex Folgende
 
 Wo immer Sie können, nutzen Sie Vorhandenes. Der [Contributor Covenant](https://contributor-covenant.org/) ist ein Verhaltenskodex, der von über 40.000 Open-Source-Projekten wie Kubernetes, Rails und Swift verwendet wird.
 
-Der [Django-Verhaltenskodex](https://www.djangoproject.com/conduct/) und der [Citizen Code of Conduct](http://citizencodeofconduct.org/) sind ebenfalls zwei gute Beispiele.
+Der [Django-Verhaltenskodex](https://www.djangoproject.com/conduct/) und der [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sind ebenfalls zwei gute Beispiele.
 
 Legen Sie eine CODE_OF_CONDUCT-Datei in das Stammverzeichnis Ihres Projekts und machen Sie sie für Ihre Community sichtbar, indem Sie sie von Ihrer CONTRIBUTING- oder README-Datei verlinken.
 
diff --git a/_articles/de/getting-paid.md b/_articles/de/getting-paid.md
index fb4a9413aba..13ac987f875 100644
--- a/_articles/de/getting-paid.md
+++ b/_articles/de/getting-paid.md
@@ -157,7 +157,7 @@ Abhängig von Ihrem Projekt können Sie kommerziellen Support, gehostete Optione
 * **[Travis CI](https://github.com/travis-ci)** bietet Bezahlversionen ihres Dienstes
 * **[Ghost](https://github.com/TryGhost/Ghost)** ist ein Non-Profit mit Bezahldiensten
 
-Einige populäre Projekte, wie z.B. [npm](https://github.com/npm/npm) und [Docker](https://github.com/docker/docker), sammeln sogar Wagniskapital ein, um ihr Wachstum zu unterstützen.
+Einige populäre Projekte, wie z.B. [npm](https://github.com/npm/cli) und [Docker](https://github.com/docker/docker), sammeln sogar Wagniskapital ein, um ihr Wachstum zu unterstützen.
 
 ### Fördermittel beantragen
 
diff --git a/_articles/de/how-to-contribute.md b/_articles/de/how-to-contribute.md
index b94b7043554..32345204a77 100644
--- a/_articles/de/how-to-contribute.md
+++ b/_articles/de/how-to-contribute.md
@@ -245,7 +245,7 @@ Weiterhin, können Sie auf folgenden Seiten neue Projekte zum Beitragen entdecke
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### Eine Checkliste, bevor Sie einen Beitrag leisten
 
diff --git a/_articles/es/best-practices.md b/_articles/es/best-practices.md
index 989e30a368b..fa24072845e 100644
--- a/_articles/es/best-practices.md
+++ b/_articles/es/best-practices.md
@@ -259,7 +259,7 @@ Al igual que cualquier otro tipo de trabajo, tomar pausas regulares te mantendr&
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   Durante el mantenimiento de WP-CLI, descubr&iacute; que tengo que preocuparme por mi felicidad primero, y establecer l&iacute;mites claros en mi participaci&oacute;n. El mejor equilibrio que he encontrado es 2-5 horas por semana, como parte de mi horario de trabajo normal. Esto mantiene mi participaci&oacute;n una pasi&oacute;n, y de sentirse demasiado como el trabajo. Como priorizo ​​las issues en las que estoy trabajando, puedo hacer progresos regulares en lo que creo que es lo m&aacute;s importante.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["Mis condolencias, ahora eres el mantenedor de un proyecto de c&oacute;digo abierto popular"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["Mis condolencias, ahora eres el mantenedor de un proyecto de c&oacute;digo abierto popular"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/es/code-of-conduct.md b/_articles/es/code-of-conduct.md
index 291cdbe2e1d..78db3337d3d 100644
--- a/_articles/es/code-of-conduct.md
+++ b/_articles/es/code-of-conduct.md
@@ -31,7 +31,7 @@ Adem&aacute;s de comunicar tus expectativas, un c&oacute;digo de conducta descri
 
 Siempre que sea posible, haga uso del art. El [Contributor Covenant](https://www.contributor-covenant.org/) es un c&oacute;digo de conducta usado por m&aacute;s de 40,000 proyectos de software libre, incluyendo Kubernetes, Rails, and Swift.
 
-El [Django Code of Conduct](https://www.djangoproject.com/conduct/) y el [Citizen Code of Conduct](http://citizencodeofconduct.org/) son tambi&eacute;n dos ejemplos de buenos c&oacute;digos de conducta.
+El [Django Code of Conduct](https://www.djangoproject.com/conduct/) y el [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) son tambi&eacute;n dos ejemplos de buenos c&oacute;digos de conducta.
 
 Ubica un archivo CODIGO_DE_CONDUCTA en el directorio ra&iacute;z de tu proyecto, y enl&aacute;zalo desde tu LEEME, as&iacute; el mismo se encuentra visible a tu comunidad.
 
diff --git a/_articles/es/getting-paid.md b/_articles/es/getting-paid.md
index 873b8bc7d36..178d52ae81f 100644
--- a/_articles/es/getting-paid.md
+++ b/_articles/es/getting-paid.md
@@ -130,7 +130,7 @@ Dependiendo de tu proyecto, puede que seas capaz de cobrar por soporte comercial
 * **[Travis CI](https://github.com/travis-ci)** ofrece versiones pagas de su producto.
 * **[Ghost](https://github.com/TryGhost/Ghost)** es sin fines de lucro con una gesti&oacute;n de servicio paga.
 
-Algunos proyectos populares, como [npm](https://github.com/npm/npm) y [Docker](https://github.com/docker/docker), generan capital de riesgo para soportar el crecimiento de su negocio.
+Algunos proyectos populares, como [npm](https://github.com/npm/cli) y [Docker](https://github.com/docker/docker), generan capital de riesgo para soportar el crecimiento de su negocio.
 
 ### Suscr&iacute;bete a subvenciones
 
diff --git a/_articles/es/how-to-contribute.md b/_articles/es/how-to-contribute.md
index 18e7d119845..92945d333d2 100644
--- a/_articles/es/how-to-contribute.md
+++ b/_articles/es/how-to-contribute.md
@@ -217,7 +217,7 @@ Puedes tambi&eacute;n utilizar algunos de los siguientes recursos para ayudarte
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### Una lista de verificaci&oacute;n antes de que contribuyas
 
diff --git a/_articles/fr/best-practices.md b/_articles/fr/best-practices.md
index 25f17f923c6..fc37ddaefa8 100644
--- a/_articles/fr/best-practices.md
+++ b/_articles/fr/best-practices.md
@@ -261,7 +261,7 @@ Tout comme n'importe quel autre type de travail, prendre des pauses régulières
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   En maintenant le WP-CLI, j'ai découvert que je devais d'abord me rendre heureux et fixer des limites claires sur mon implication. Le meilleur équilibre que j'ai trouvé est de 2 à 5 heures par semaine, dans le cadre de mon horaire de travail normal. Cela maintient ma participation en tant que passion, sans le sentir trop comme du travail. Parce que je priorise les problèmes sur lesquels je travaille, je peux faire des progrès réguliers sur ce que je pense être le plus important.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/fr/code-of-conduct.md b/_articles/fr/code-of-conduct.md
index 4726143d822..31fd5c870db 100644
--- a/_articles/fr/code-of-conduct.md
+++ b/_articles/fr/code-of-conduct.md
@@ -31,7 +31,7 @@ En plus de communiquer vos attentes, un code de conduite décrit ce qui suit:
 
 Quand vous le pouvez, utilisez l'existant. Le [Contributor Covenant](https://contributor-covenant.org/) est un code de conduite qui est utilisé par plus de 40 000 projets open source, y compris Kubernetes, Rails et Swift.
 
-Le [Django Code of Conduct](https://www.djangoproject.com/conduct/) et le [Citizen Code of Conduct](http://citizencodeofconduct.org/) sont également deux bons exemples de code de conduite.
+Le [Django Code of Conduct](https://www.djangoproject.com/conduct/) et le [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sont également deux bons exemples de code de conduite.
 
 Placez un fichier CODE_OF_CONDUCT dans le répertoire racine de votre projet et rendez-le visible pour votre communauté en le liant à votre fichier CONTRIBUTING ou README.
 
diff --git a/_articles/fr/getting-paid.md b/_articles/fr/getting-paid.md
index 05862fd61f8..a9aa8516c3c 100644
--- a/_articles/fr/getting-paid.md
+++ b/_articles/fr/getting-paid.md
@@ -130,7 +130,7 @@ En fonction de votre projet, vous pouvez facturer un support commercial, des opt
 * **[Travis CI](https://github.com/travis-ci)** offre des versions payantes de son produit
 * **[Ghost](https://github.com/TryGhost/Ghost)** est un organisme à but non lucratif avec un service géré payant
 
-Certains projets populaires, tels que [npm](https://github.com/npm/npm) et [Docker](https://github.com/docker/docker), permettent même de lever du capital-risque pour soutenir la croissance de leur entreprise.
+Certains projets populaires, tels que [npm](https://github.com/npm/cli) et [Docker](https://github.com/docker/docker), permettent même de lever du capital-risque pour soutenir la croissance de leur entreprise.
 
 ### Demande de financement
 
diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md
index 53f3cb81372..bd74af09175 100644
--- a/_articles/fr/how-to-contribute.md
+++ b/_articles/fr/how-to-contribute.md
@@ -217,7 +217,7 @@ Vous pouvez également utiliser l'une des ressources suivantes pour vous aider 
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### Une checklist avant de contribuer
 
diff --git a/_articles/hu/best-practices.md b/_articles/hu/best-practices.md
index c98d032a749..4f0098594bd 100644
--- a/_articles/hu/best-practices.md
+++ b/_articles/hu/best-practices.md
@@ -265,7 +265,7 @@ Mint minden más munka esetén a rendszeres pihenők tartása felfrissít, boldo
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   A WP-CLI fenntartása során felfedeztem, hogy előbb boldoggá kell tennem magam, és egyértelmű határokat kell meghúznom. A legjobb egyensúlyt számomra a hetente 2-5 óra biztosította, a normál munkám részeként. Ez megőrzi a szenvedélyemet és nem érzem azt, hogy túl sokat dolgoztam volna. Mivel priorizálom a munkákat amelyeken dolgozom, így normálisan haladok a véleményem szerint legfontosabb dolgokkal.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["Fogadd részvétem, mert Te most egy népszerű, nyílt forráskódú projekt karbantartója lettél"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["Fogadd részvétem, mert Te most egy népszerű, nyílt forráskódú projekt karbantartója lettél"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/hu/code-of-conduct.md b/_articles/hu/code-of-conduct.md
index b135eccca46..300fc1aaecc 100644
--- a/_articles/hu/code-of-conduct.md
+++ b/_articles/hu/code-of-conduct.md
@@ -31,7 +31,7 @@ Az elvárásaid mellett a magatartási kódex az alábbiakat írja még le:
 
 Lehetőség szerint használj már létező, publikus dokumentumot. A [Contributor Covenant](https://contributor-covenant.org/) egy azonnal használható magatartási kódex, amelyet már több mint 40,000 nyílt forráskódú projekt használ, mint például a Kubernetes, Rails, és a Swift.
 
-A [Django Code of Conduct](https://www.djangoproject.com/conduct/) és a [Citizen Code of Conduct](http://citizencodeofconduct.org/) szintén nagyon jó minták.
+A [Django Code of Conduct](https://www.djangoproject.com/conduct/) és a [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) szintén nagyon jó minták.
 
 Helyezd el a CODE_OF_CONDUCT állomány a projekt gyökérkönyvtárában, és hivatkozd meg őket a CONTRIBUTING és README állományokból, hogy mindenkinek látható legyen.
 
diff --git a/_articles/hu/getting-paid.md b/_articles/hu/getting-paid.md
index 6a5af345930..ea0ac67f4d0 100644
--- a/_articles/hu/getting-paid.md
+++ b/_articles/hu/getting-paid.md
@@ -136,7 +136,7 @@ A projektedtől függően kérhetsz támogatást szupportért, új funkcióért,
 * **[Travis CI](https://github.com/travis-ci)** kínál fizetős verziót privát használatra
 * **[Ghost](https://github.com/TryGhost/Ghost)** alapvetően non-profit, de a felügyelt szolgáltatásért fizetni kell
 
-Néhány híres projekt, mint az [npm](https://github.com/npm/npm) és a [Docker](https://github.com/docker/docker), még kockázati tőkét is bevontak a növekedés finanszírozásához.
+Néhány híres projekt, mint az [npm](https://github.com/npm/cli) és a [Docker](https://github.com/docker/docker), még kockázati tőkét is bevontak a növekedés finanszírozásához.
 
 ### Jelentkezz pályázatokra
 
diff --git a/_articles/hu/how-to-contribute.md b/_articles/hu/how-to-contribute.md
index 8c882058d7f..899a77272d0 100644
--- a/_articles/hu/how-to-contribute.md
+++ b/_articles/hu/how-to-contribute.md
@@ -220,7 +220,7 @@ Az alábbiakban találsz néhány oldalt, amelyek segítenek abban, hogy felfede
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### Egy ellenőrző lista, mielőtt részt vennél a projektben
 
diff --git a/_articles/id/best-practices.md b/_articles/id/best-practices.md
index 778a6100c7c..73a4b0e9ea1 100644
--- a/_articles/id/best-practices.md
+++ b/_articles/id/best-practices.md
@@ -259,7 +259,7 @@ Sama halnya seperti pekerjaan lainnya, mengambil liburan secara berkala akan mem
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   Dalam mengelola WP-CLI, Saya menemukan bahwa saya perlu membuat diri saya bahagia terlebih dahulu, dan menentukan batas keterlibatan saya dengan jelas. Keseimbangan terbaik yang saya temukan adalah 2-5 jam per minggu sebagai bagian dari jadwal pekerjaan normal saya. Hal ini menjaga keterlibatan saya sebagai sebuah gairah. Karena saya memprioritaskan masalah-masalah yang saya kerjakan, saya bisa membuat kemajuan berkala tentang apa yang saya anggap penting.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/id/code-of-conduct.md b/_articles/id/code-of-conduct.md
index 910858359b9..e52ed48e141 100644
--- a/_articles/id/code-of-conduct.md
+++ b/_articles/id/code-of-conduct.md
@@ -31,7 +31,7 @@ Selain mengkomunikasikan ekspektasi Anda, kode etik juga menjelaskan beberapa ha
 
 Apabila dimungkinkan, gunakan yang sudah ada. [Contributor Covenant](https://www.contributor-covenant.org/) adalah kode etik yang bisa digunakan dan sudah digunakan oleh lebih dari 40.000 proyek open source, termasuk Kubernetes, Rails, dan Swift.
 
-[Kode etik Django](https://www.djangoproject.com/conduct/) dan [Kode etik Warga](http://citizencodeofconduct.org/) adalah dua contoh kode etik yang bagus.
+[Kode etik Django](https://www.djangoproject.com/conduct/) dan [Kode etik Warga](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) adalah dua contoh kode etik yang bagus.
 
 Tempatkan dokumen CODE_OF_CONDUCT pada induk direktori proyek Anda, dan hubungkan dari dokumen README sehingga terlihat dengan jelas oleh komunitas Anda.
 
diff --git a/_articles/id/getting-paid.md b/_articles/id/getting-paid.md
index 7baf18e5dc5..d2b86acc681 100644
--- a/_articles/id/getting-paid.md
+++ b/_articles/id/getting-paid.md
@@ -129,7 +129,7 @@ Anda mungkin memberikan tambahan biaya untuk dukungan komersial, opsi hosting, a
 * **[Travis CI](https://github.com/travis-ci)** menawarkan versi berbayar untuk produknya
 * **[Ghost](https://github.com/TryGhost/Ghost)** bersifat nirlaba dengan layanan pembayaran
 
-Beberapa proyek yang populer, seperti [npm](https://github.com/npm/npm) dan [Docker](https://github.com/docker/docker), bahkan mengajukan pendanaan pada venture capital untuk mendukung pertumbuhan bisnisnya.
+Beberapa proyek yang populer, seperti [npm](https://github.com/npm/cli) dan [Docker](https://github.com/docker/docker), bahkan mengajukan pendanaan pada venture capital untuk mendukung pertumbuhan bisnisnya.
 
 ### Mengajukan hibah pendanaan
 
diff --git a/_articles/id/how-to-contribute.md b/_articles/id/how-to-contribute.md
index 32fb5cdd575..f47582740dc 100644
--- a/_articles/id/how-to-contribute.md
+++ b/_articles/id/how-to-contribute.md
@@ -217,7 +217,7 @@ Anda juga bisa menggunakan salah satu dari beberapa sumber daya berikut untuk me
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### Daftar sebelum Anda berkontribusi
 
diff --git a/_articles/ja/best-practices.md b/_articles/ja/best-practices.md
index f7e7aa3540b..c62c861826a 100644
--- a/_articles/ja/best-practices.md
+++ b/_articles/ja/best-practices.md
@@ -261,7 +261,7 @@ related:
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   WP-CLI をメンテナンスする中で、まずは自分自身を幸せにし、自分がどこまで関わるかの境界を明確にすることが必要であると気づきました。私が見つけた最も良いバランスは、私の通常の仕事時間の中で週に2 ~ 5時間を充てるというものです。このバランスで、私はプロジェクトに熱心に関わることができ、かつ仕事のようだと感じることもありません。取り掛かるイシューの優先順位付けをしているので、最も重要だと思うことで定期的に進捗を出すことができるのです。
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/ja/code-of-conduct.md b/_articles/ja/code-of-conduct.md
index 26a4dbf6b7c..ba6a7bb6f98 100644
--- a/_articles/ja/code-of-conduct.md
+++ b/_articles/ja/code-of-conduct.md
@@ -31,7 +31,7 @@ related:
 
 できる限り、既存の行動規範を使いましょう。 [Contributor Covenant](https://contributor-covenant.org/) は40,000以上のオープンソースプロジェクトで使われている行動規範で、 Kubernetes 、 Rails 、 Swift でも使われています。
 
-[Django Code of Conduct](https://www.djangoproject.com/conduct/) や [Citizen Code of Conduct](http://citizencodeofconduct.org/) の2つもよく使われる行動規範です。
+[Django Code of Conduct](https://www.djangoproject.com/conduct/) や [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) の2つもよく使われる行動規範です。
 
 CODE_OF_CONDUCT ファイルをプロジェクトのルートディレクトリに置き、 CONTRIBUTING や README ファイルからリンクを張ってコミュニティの皆がすぐに見れるようにしましょう。
 
diff --git a/_articles/ja/getting-paid.md b/_articles/ja/getting-paid.md
index 225eb1340d1..78873974081 100644
--- a/_articles/ja/getting-paid.md
+++ b/_articles/ja/getting-paid.md
@@ -134,7 +134,7 @@ related:
 * **[Travis CI](https://github.com/travis-ci)** は、製品の有償版を提供しています。
 * **[Ghost](https://github.com/TryGhost/Ghost)** は、有償のマネージドサービスを提供する非営利サービスです。
 
-[npm](https://github.com/npm/npm) や [Docker](https://github.com/docker/docker) のような有名なプロジェクトでは、ビジネスの成長を支えるためにベンチャーキャピタルから資金調達をしています。
+[npm](https://github.com/npm/cli) や [Docker](https://github.com/docker/docker) のような有名なプロジェクトでは、ビジネスの成長を支えるためにベンチャーキャピタルから資金調達をしています。
 
 ### 助成金に応募する
 
diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md
index 43923ef4afc..1cfd6d87701 100644
--- a/_articles/ja/how-to-contribute.md
+++ b/_articles/ja/how-to-contribute.md
@@ -217,7 +217,7 @@ README を読んで、壊れたリンクやタイポを見つけるかもしれ
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### コントリビュートする前のチェックリスト
 
diff --git a/_articles/ko/best-practices.md b/_articles/ko/best-practices.md
index 6ed20b13a3a..2295389f32f 100644
--- a/_articles/ko/best-practices.md
+++ b/_articles/ko/best-practices.md
@@ -261,7 +261,7 @@ GitHub에서는 버그 제보나 기타 평범한 기여에 사용할 [이슈 
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you’re now the maintainer of a popular open source project”](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you’re now the maintainer of a popular open source project”](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/ko/code-of-conduct.md b/_articles/ko/code-of-conduct.md
index 887ea9c8d1c..257f31a4a7f 100644
--- a/_articles/ko/code-of-conduct.md
+++ b/_articles/ko/code-of-conduct.md
@@ -31,7 +31,7 @@ related:
 
 가능한 모든 곳에서 이전 기술을 사용하십시오. [기여자 규약](https://www.contributor-covenant.org/)은 Kubernetes, Rails 및 Swift를 포함하여 40,000 개 이상의 오픈소스 프로젝트에서 사용되는 행동강령입니다.
 
-[Django 행동강령](https://www.djangoproject.com/conduct/)과 [Citizen 행동강령](http://citizencodeofconduct.org/)은 두가지 훌륭한 행동강령입니다.
+[Django 행동강령](https://www.djangoproject.com/conduct/)과 [Citizen 행동강령](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/)은 두가지 훌륭한 행동강령입니다.
 
 프로젝트의 최상단 디렉토리에 CODE_OF_CONDUCT 파일을 놓고 CONTRIBUTING 또는 README 파일에서 링크하여 커뮤니티에 표시되게 하십시오.
 
diff --git a/_articles/ko/getting-paid.md b/_articles/ko/getting-paid.md
index d616df03581..edceba299f7 100644
--- a/_articles/ko/getting-paid.md
+++ b/_articles/ko/getting-paid.md
@@ -130,7 +130,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri
 * **[Travis CI](https://github.com/travis-ci)** 는 제품의 유료 버전을 제공합니다
 * **[Ghost](https://github.com/TryGhost/Ghost)** 는 유료 관리 서비스가 있는 비영리 단체입니다
 
-[npm](https://github.com/npm/npm) 및 [Docker](https://github.com/docker/docker)와 같은 일부 인기있는 프로젝트는, 사업 성장을 지원하기 위해 벤처 캐피탈을 조성하기까지 합니다.
+[npm](https://github.com/npm/cli) 및 [Docker](https://github.com/docker/docker)와 같은 일부 인기있는 프로젝트는, 사업 성장을 지원하기 위해 벤처 캐피탈을 조성하기까지 합니다.
 
 ### 보조금 신청하기
 
diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md
index 8ba1371726b..99900325f70 100644
--- a/_articles/ko/how-to-contribute.md
+++ b/_articles/ko/how-to-contribute.md
@@ -217,7 +217,7 @@ README를 스캔하여 깨진 링크나 오타를 찾을 수 있습니다. 또
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### 기여하기 전 확인할 사항
 
diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md
index 082754401f4..345d3a9ed91 100644
--- a/_articles/ms/best-practices.md
+++ b/_articles/ms/best-practices.md
@@ -265,7 +265,7 @@ Sama seperti jenis pekerjaan lain, berehat sebentar akan membuat anda segar, gem
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   Dalam mengekalkan WP-CLI, saya mendapati bahawa saya harus membuat diri saya bahagia terlebih dahulu, dan menetapkan batasan yang jelas mengenai penglibatan saya. Imbangan terbaik yang saya dapati adalah 2-5 jam seminggu, sebagai sebahagian daripada jadual kerja biasa saya. Ini menjadikan penglibatan saya menjadi minat, dan daripada merasa terlalu suka bekerja. Kerana saya mengutamakan masalah yang sedang saya jalankan, saya dapat membuat kemajuan secara berkala terhadap perkara yang saya rasa paling penting.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["Takziah, anda sekarang menjadi penyelenggara projek sumber terbuka yang popular"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["Takziah, anda sekarang menjadi penyelenggara projek sumber terbuka yang popular"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/ms/code-of-conduct.md b/_articles/ms/code-of-conduct.md
index bb04a2b1996..fc1e3a051fa 100644
--- a/_articles/ms/code-of-conduct.md
+++ b/_articles/ms/code-of-conduct.md
@@ -37,7 +37,7 @@ Selain menyampaikan harapan anda, kod tingkah laku menerangkan perkara berikut:
 
 Di mana sahaja anda boleh, gunakan seni sebelumnya. [Contributor Covenant](https://contributor-covenant.org/) adalah tatakelakuan drop-in yang digunakan oleh lebih dari 40,000 projek sumber terbuka, termasuk Kubernetes, Rails, dan Swift.
 
-[Django Code of Conduct](https://www.djangoproject.com/conduct/) dan [Citizen Code of Conduct](http://citizencodeofconduct.org/) juga merupakan dua contoh tatakelakuan yang baik.
+[Django Code of Conduct](https://www.djangoproject.com/conduct/) dan [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) juga merupakan dua contoh tatakelakuan yang baik.
 
 Letakkan fail CODE_OF_CONDUCT di direktori root projek anda, dan jadikan ia dapat dilihat oleh komuniti anda dengan menghubungkannya dari fail CONTRIBUTING atau README anda.
 
diff --git a/_articles/ms/getting-paid.md b/_articles/ms/getting-paid.md
index f9c2c3396d9..0a501476712 100644
--- a/_articles/ms/getting-paid.md
+++ b/_articles/ms/getting-paid.md
@@ -140,7 +140,7 @@ Bergantung pada projek anda, anda mungkin dapat mengenakan bayaran untuk sokonga
 * **[Travis CI](https://github.com/travis-ci)** menawarkan versi berbayar produknya
 * **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
 
-Beberapa projek popular, seperti [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker),malah mengumpulkan modal teroka untuk menyokong pertumbuhan perniagaan mereka.
+Beberapa projek popular, seperti [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker),malah mengumpulkan modal teroka untuk menyokong pertumbuhan perniagaan mereka.
 
 ### Memohon pembiayaan geran
 
diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
index 55cd3025be8..b50c6906bc5 100644
--- a/_articles/ms/how-to-contribute.md
+++ b/_articles/ms/how-to-contribute.md
@@ -230,7 +230,7 @@ Anda juga boleh menggunakan salah satu sumber berikut untuk membantu anda menemu
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### Senarai semak sebelum anda menyumbang
 
diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index be4fd139e47..c583c50dcc4 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -288,7 +288,7 @@ Net als bij elk ander soort werk, zal het nemen van regelmatige pauzes je verfri
   
   _In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important._
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["Mijn condoleances, u bent nu de onderhouder (_maintainer_) van een populair open source-project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["Mijn condoleances, u bent nu de onderhouder (_maintainer_) van een populair open source-project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/nl/code-of-conduct.md b/_articles/nl/code-of-conduct.md
index d59157706bf..f77c2c91613 100644
--- a/_articles/nl/code-of-conduct.md
+++ b/_articles/nl/code-of-conduct.md
@@ -37,7 +37,7 @@ In addition to communicating your expectations, a code of conduct describes the
 
 Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
 
-The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](http://citizencodeofconduct.org/) are also two good code of conduct examples.
+The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples.
 
 Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
 
diff --git a/_articles/nl/getting-paid.md b/_articles/nl/getting-paid.md
index ae05b842255..7cc2851eff0 100644
--- a/_articles/nl/getting-paid.md
+++ b/_articles/nl/getting-paid.md
@@ -158,7 +158,7 @@ Afhankelijk van uw project kunt u mogelijk kosten in rekening brengen voor comme
 * **[Travis CI](https://github.com/travis-ci)** biedt betaalde versies van zijn product
 * **[Ghost](https://github.com/TryGhost/Ghost)** is een non-profitorganisatie met een betaalde beheerde service
 
-Sommige populaire projecten, zoals [npm](https://github.com/npm/npm) en [Docker](https://github.com/docker/docker), halen zelfs risicokapitaal op om de groei van hun bedrijf te ondersteunen.
+Sommige populaire projecten, zoals [npm](https://github.com/npm/cli) en [Docker](https://github.com/docker/docker), halen zelfs risicokapitaal op om de groei van hun bedrijf te ondersteunen.
 
 ### Subsidie ​​aanvragen
 
diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md
index dc7ee302cab..9b57e9aefa4 100644
--- a/_articles/nl/how-to-contribute.md
+++ b/_articles/nl/how-to-contribute.md
@@ -241,7 +241,7 @@ U kunt ook een van de volgende bronnen gebruiken om u te helpen bij het ontdekke
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### Een checklist voordat u bijdraagt
 
diff --git a/_articles/pl/best-practices.md b/_articles/pl/best-practices.md
index 0049bc18bbd..3fed2f2d00f 100644
--- a/_articles/pl/best-practices.md
+++ b/_articles/pl/best-practices.md
@@ -271,7 +271,7 @@ Podobnie jak w przypadku każdego innego rodzaju pracy, regularne przerwy sprawi
   <i>
   In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.</i>
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/pl/code-of-conduct.md b/_articles/pl/code-of-conduct.md
index 3e39fbf0d6b..1a2d7a1ef2f 100644
--- a/_articles/pl/code-of-conduct.md
+++ b/_articles/pl/code-of-conduct.md
@@ -31,7 +31,7 @@ Oprócz przekazywania swoich oczekiwań kodeks postępowania opisuje następują
 
 Gdziekolwiek możesz, skorzystaj ze stanu techniki. [Przymierze współautorów](https://contributor-covenant.org/) to rozwijany kodeks postępowania używany przez ponad 40 000 projektów open source, w tym Kubernetes, Rails i Swift.
 
-[Kodeks postępowania Django](https://www.djangoproject.com/conduct/) oraz [Kodeks postępowania obywatelskiego](http://citizencodeofconduct.org/) to także dwa przykłady dobrego kodeksu postępowania.
+[Kodeks postępowania Django](https://www.djangoproject.com/conduct/) oraz [Kodeks postępowania obywatelskiego](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) to także dwa przykłady dobrego kodeksu postępowania.
 
 Umieść plik CODE_OF_CONDUCT w katalogu głównym projektu i uczyń go widocznym dla społeczności, łącząc go z plikiem CONTRIBUTING  lub README.
 
diff --git a/_articles/pl/getting-paid.md b/_articles/pl/getting-paid.md
index d5449946bd9..32a1ea63766 100644
--- a/_articles/pl/getting-paid.md
+++ b/_articles/pl/getting-paid.md
@@ -147,7 +147,7 @@ W zależności od projektu możesz być w stanie pobierać opłaty za wsparcie k
 * **[Travis CI](https://github.com/travis-ci)** oferuje płatne wersje swojego produktu
 * **[Ghost](https://github.com/TryGhost/Ghost)** jest organizacją non-profit z płatną usługą zarządzaną
 
-Niektóre popularne projekty, takie jak [npm](https://github.com/npm/npm) oraz [Docker](https://github.com/docker/docker), nawet pozyskały kapitał wysokiego ryzyka w celu wsparcia rozwoju ich działalności.
+Niektóre popularne projekty, takie jak [npm](https://github.com/npm/cli) oraz [Docker](https://github.com/docker/docker), nawet pozyskały kapitał wysokiego ryzyka w celu wsparcia rozwoju ich działalności.
 
 ### Złóż wniosek o dofinansowanie
 
diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index 3159d01da87..169f1f50112 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -233,7 +233,7 @@ Możesz także skorzystać z jednego z następujących zasobów, aby pomóc Ci o
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### Lista kontrolna przed wniesieniem wkładu
 
diff --git a/_articles/pt/best-practices.md b/_articles/pt/best-practices.md
index 8a26836b6a2..076c3377cb7 100644
--- a/_articles/pt/best-practices.md
+++ b/_articles/pt/best-practices.md
@@ -261,7 +261,7 @@ Assim como qualquer outro tipo de trabalho, fazer pausas regulares manterão voc
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   Na manutenção do WP-CLI, descobri que preciso me tornar feliz primeiro e estabelecer limites claros sobre meu envolvimento. O melhor equilíbrio que encontrei é 2-5 horas por semana, como parte de meu horário normal de trabalho. Isso mantém meu envolvimento uma paixão, e longe de me sentir como se estivesse no trabalho. Devido a priorização dos problemas que estou trabalhando, posso fazer progressos regulares naquilo que penso ser mais importante.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/pt/code-of-conduct.md b/_articles/pt/code-of-conduct.md
index 00d4f305288..dc8554899da 100644
--- a/_articles/pt/code-of-conduct.md
+++ b/_articles/pt/code-of-conduct.md
@@ -31,7 +31,7 @@ Além de comunicar aquilo que você espera, um código de conduta descreve o seg
 
 Sempre que possível, use exemplos passados. O [Contributor Covenant](https://contributor-covenant.org/) é um código de conduta que é usado por mais de 40.000 projetos _open source_, incluindo Kubernetes, Rails, e Swift.
 
-O [Django Code of Conduct](https://www.djangoproject.com/conduct/) e o [Citizen Code of Conduct](http://citizencodeofconduct.org/) são, tambémm, outros dois bons exemplos de códigos de conduta.
+O [Django Code of Conduct](https://www.djangoproject.com/conduct/) e o [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) são, tambémm, outros dois bons exemplos de códigos de conduta.
 
 Coloque um arquivo CODE_OF_CONDUCT no diretório raiz do seu projeto, e faça-o visivel a sua comunidade criando um link para ele no arquivo CONTRIBUTING ou README.
 
diff --git a/_articles/pt/getting-paid.md b/_articles/pt/getting-paid.md
index 99df7d76e4e..057948160d4 100644
--- a/_articles/pt/getting-paid.md
+++ b/_articles/pt/getting-paid.md
@@ -135,7 +135,7 @@ Dependendo do seu projeto, você pode ser capaz de cobrar por suporte comercial,
 * **[Travis CI](https://github.com/travis-ci)** oferece versões pagas de seu produto
 * **[Ghost](https://github.com/TryGhost/Ghost)** é uma organização sem fins lucrativos, com um serviço gerenciado pago
 
-Alguns projetos populares, como o [npm](https://github.com/npm/npm) e o [Docker](https://github.com/docker/docker), conseguem até mesmo capital de risco para dar suporte ao crescimento de seu negócio.
+Alguns projetos populares, como o [npm](https://github.com/npm/cli) e o [Docker](https://github.com/docker/docker), conseguem até mesmo capital de risco para dar suporte ao crescimento de seu negócio.
 
 ### Solicite financiamento de subsídio
 
diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md
index 8d1cb746236..f1c4ffd678b 100644
--- a/_articles/pt/how-to-contribute.md
+++ b/_articles/pt/how-to-contribute.md
@@ -217,7 +217,7 @@ Você também pode usar um dos seguintes recursos para ajudá-lo a descobrir e c
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### Um checklist antes de você contribuir
 
diff --git a/_articles/ro/best-practices.md b/_articles/ro/best-practices.md
index 3cca2c80edf..97da1e968b6 100644
--- a/_articles/ro/best-practices.md
+++ b/_articles/ro/best-practices.md
@@ -323,7 +323,7 @@ Exact la fel ca oricare alt fel de muncă, luarea de pauze dese te va păstra re
     </em>
   </p>
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/ro/code-of-conduct.md b/_articles/ro/code-of-conduct.md
index 408c7c90fdf..75202870517 100644
--- a/_articles/ro/code-of-conduct.md
+++ b/_articles/ro/code-of-conduct.md
@@ -37,7 +37,7 @@ Pe lângă comunicarea așteptărilor tale, un cod de conduită descrie următoa
 
 Oricând poți, folosește stadiul cunoscut al tehnicii. [Contributor Covenant](https://contributor-covenant.org/) este un cod de conduită ușor de instalat care este folosit de peste 40.000 de proiecte cu sursă deschisă, inclusiv Kubernetes, Rails, și Swift.
 
-[Codul de conduită Django](https://www.djangoproject.com/conduct/) și [Citizen Code of Conduct](http://citizencodeofconduct.org/) sunt de asemenea două exemple bune de coduri de conduită.
+[Codul de conduită Django](https://www.djangoproject.com/conduct/) și [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sunt de asemenea două exemple bune de coduri de conduită.
 
 Amplasează un fișier CODE_OF_CONDUCT în directorul rădăcină al proiectului tău, și fă-l vizibil pentru comunitatea ta legând către el din fișierele tale CONTRIBUTING sau README.
 
diff --git a/_articles/ro/getting-paid.md b/_articles/ro/getting-paid.md
index d8443f20472..f27918d87b3 100644
--- a/_articles/ro/getting-paid.md
+++ b/_articles/ro/getting-paid.md
@@ -184,7 +184,7 @@ Depinzând de proiectul tău, ai putea să taxezi sprijin comercial, opțiuni de
 * **[Travis CI](https://github.com/travis-ci)** oferă versiuni plătite ale produsului său
 * **[Ghost](https://github.com/TryGhost/Ghost)** este un nonprofit cu un serviciu gestionat plătit
 
-Unele proiecte populare, cum ar fi [npm](https://github.com/npm/npm) și [Docker](https://github.com/docker/docker), chiar strâng capital de risc pentru a susține creșterea afacerii lor.
+Unele proiecte populare, cum ar fi [npm](https://github.com/npm/cli) și [Docker](https://github.com/docker/docker), chiar strâng capital de risc pentru a susține creșterea afacerii lor.
 
 ### Aplicați pentru finanțare nerambursabilă
 
diff --git a/_articles/ro/how-to-contribute.md b/_articles/ro/how-to-contribute.md
index 7a52bde8b7f..27e6ea50206 100644
--- a/_articles/ro/how-to-contribute.md
+++ b/_articles/ro/how-to-contribute.md
@@ -261,7 +261,7 @@ Poți de asemenea folosi una dintre următoarele resurse pentru a te ajuta să d
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### O listă de verificare înainte de a contribui
 
diff --git a/_articles/ta/best-practices.md b/_articles/ta/best-practices.md
index 1bed55f9bbf..d658f1f89c9 100644
--- a/_articles/ta/best-practices.md
+++ b/_articles/ta/best-practices.md
@@ -261,7 +261,7 @@ related:
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   WP-CLI ஐ பராமரிப்பதில், முதலில் நான் மகிழ்ச்சியடைந்தேன், என் ஈடுபாட்டின் மீது தெளிவான எல்லைகளை அமைத்தேன். என் சாதாரண பணி அட்டவணையின் ஒரு பகுதியாக, வாரத்திற்கு 2-5 மணிநேரத்தை நான் கண்டிருக்கிறேன். இது என் ஈடுபாடு ஒரு உணர்வு, மற்றும் மிகவும் வேலை உணர்கிறேன் இருந்து வைத்திருக்கிறது. நான் பணிபுரியும் பிரச்சினைகளுக்கு முன்னுரிமை அளிப்பதால், மிக முக்கியமானது என்னவென்று நான் நினைக்கிறேன். நான் பணிபுரியும் பிரச்சினைகளுக்கு முன்னுரிமை அளிப்பதால், நான் மிகவும் முக்கியம் என நினைப்பதில் நான் தொடர்ந்து முன்னேற்றம் செய்ய முடிகிறது.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["என் இரங்கல்கள், நீங்கள் இப்போது ஒரு பிரபலமான திறந்த மூல திட்டத்தின் பராமரிப்பாளர்"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["என் இரங்கல்கள், நீங்கள் இப்போது ஒரு பிரபலமான திறந்த மூல திட்டத்தின் பராமரிப்பாளர்"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/ta/code-of-conduct.md b/_articles/ta/code-of-conduct.md
index 8b8f8c1b78c..33a8c45ff23 100644
--- a/_articles/ta/code-of-conduct.md
+++ b/_articles/ta/code-of-conduct.md
@@ -31,7 +31,7 @@ related:
 
 நீங்கள் எங்கு வேண்டுமானாலும், முந்தைய உபாயத்தை பயன்படுத்தவும். [பங்களிப்பாளரின் உடன்படிக்கை](https://contributor-covenant.org/) என்பது ஒரு நடத்தை விதியாகும், இது குபெர்னீஸ், ரெயில்ஸ் மற்றும் ஸ்விஃப்ட் உள்ளிட்ட 40,000 திறந்த மூல திட்டங்களில் பயன்படுத்தப்படுகிறது.
 
-[Django நடத்தை விதித் தொகுப்பு](https://www.djangoproject.com/conduct/) மற்றும் [சிட்டிசன் நடத்தை விதித் தொகுப்பு](http://citizencodeofconduct.org/) நடத்தை விதித் தொகுப்புக்கான இரண்டு நல்ல உதாரணங்களாகும்.
+[Django நடத்தை விதித் தொகுப்பு](https://www.djangoproject.com/conduct/) மற்றும் [சிட்டிசன் நடத்தை விதித் தொகுப்பு](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) நடத்தை விதித் தொகுப்புக்கான இரண்டு நல்ல உதாரணங்களாகும்.
 
 உங்கள் திட்டத்தின் மூலம் கோப்பகத்தில் CODE_OF_CONDUCT கோப்பை வைக்கவும், மேலும் உங்கள் CONTRIBUTING அல்லது README கோப்பில் இருந்து அதை இணைப்பதன் மூலம் அதை உங்கள் சமூகத்திற்குத் தெரியப்படுத்தவும்.
 
diff --git a/_articles/ta/getting-paid.md b/_articles/ta/getting-paid.md
index e1f8322e338..29a2861e9eb 100644
--- a/_articles/ta/getting-paid.md
+++ b/_articles/ta/getting-paid.md
@@ -130,7 +130,7 @@ related:
 * **[டிராவிஸ் சிஐ](https://github.com/travis-ci)** அதன் தயாரிப்பின் கட்டண பதிப்புகள் வழங்குகிறது
 * **[கோஸ்ட்](https://github.com/TryGhost/Ghost)** ஒரு இலாப நோக்கமற்றத பணம் செலுத்திய நிர்வகிக்கப்பட்ட சேவை
 
-[என்பிஎம்](https://github.com/npm/npm) and [டாக்கர்](https://github.com/docker/docker), போன்ற சில பிரபலமான திட்டங்கள், தங்கள் வணிக வளர்ச்சியை ஆதரிப்பதற்காக துணிகர மூலதனத்தை அதிகரிக்கின்றன.
+[என்பிஎம்](https://github.com/npm/cli) and [டாக்கர்](https://github.com/docker/docker), போன்ற சில பிரபலமான திட்டங்கள், தங்கள் வணிக வளர்ச்சியை ஆதரிப்பதற்காக துணிகர மூலதனத்தை அதிகரிக்கின்றன.
 
 ### மானிய நிதிக்கு விண்ணப்பிக்கவும்
 
diff --git a/_articles/ta/how-to-contribute.md b/_articles/ta/how-to-contribute.md
index c27a34f7070..774154464c5 100644
--- a/_articles/ta/how-to-contribute.md
+++ b/_articles/ta/how-to-contribute.md
@@ -217,7 +217,7 @@ related:
 * [Up For Grabs](https://up-for-grabs.net/)
 * [பங்களிப்பாளர்-நிஞ்ஜா](https://contributor.ninja)
 * [முதல் பங்களிப்புகள்](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### பங்களிக்கும் முன் ஒரு சரிபார்ப்புப் பட்டியல்
 
diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md
index 5427fe39a07..3a264e8373a 100644
--- a/_articles/tr/best-practices.md
+++ b/_articles/tr/best-practices.md
@@ -272,7 +272,7 @@ Tıpkı diğer tüm işlerde olduğu gibi, düzenli molalar vermek de işinizi y
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   WP-CLI’yı geliştirirken, önce kendimi mutlu etmem gerektiğini ve katılımım konusunda net sınırlar koymam gerektiğini keşfettim. Bulduğum en iyi denge, normal çalışma programımın bir parçası olarak haftada 2-5 saat. Bu benim katılımımı bir tutku olarak kalmasını sağlıyor ve iş gibi hissetmekten koruyor. Üzerinde çalıştığım konulara öncelik verdiğim için, en önemli olduğunu düşündüğüm konuda düzenli ilerleme sağlayabiliyorum.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["Başınız sağolsun, şimdi popüler bir açık kaynak projesinin sorumlusunuz"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["Başınız sağolsun, şimdi popüler bir açık kaynak projesinin sorumlusunuz"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md
index 571fd442f74..afc8f06f843 100644
--- a/_articles/tr/code-of-conduct.md
+++ b/_articles/tr/code-of-conduct.md
@@ -37,7 +37,7 @@ Beklentilerinizi iletmenin yanı sıra, bir davranış kural listesi aşağıdak
 
 Nerede olursanız olun, geçmiş tecrübelerden faydalanın. [Katkıda Bulunanlar Sözleşmesi (Contributor Covenant)](https://contributor-covenant.org/) Kubernet, Rails ve Swift dahil olmak üzere 40.000'den fazla açık kaynaklı proje tarafından kullanılan ortak bir davranış kural listesidir.
 
-[Django Davranış Kuralları](https://www.djangoproject.com/conduct/) ve [Vatandaş Davranış Kuralları](http://citizencodeofconduct.org/) da aynı zamanda iki iyi davranış kural listesi örneğidir.
+[Django Davranış Kuralları](https://www.djangoproject.com/conduct/) ve [Vatandaş Davranış Kuralları](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) da aynı zamanda iki iyi davranış kural listesi örneğidir.
 
 CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTING veya README dosyanızdan bağlantılayarak topluluğunuz tarafından görülebilir hale getirin.
 
diff --git a/_articles/tr/getting-paid.md b/_articles/tr/getting-paid.md
index aad2f945d62..eb0cbd47221 100644
--- a/_articles/tr/getting-paid.md
+++ b/_articles/tr/getting-paid.md
@@ -139,7 +139,7 @@ Projenize bağlı olarak, ticari destek, barındırılan seçenekler veya ek öz
 * **[Travis CI](https://github.com/travis-ci)** ürünlerinin ücretli sürümlerini sunuyor
 * **[Ghost](https://github.com/TryGhost/Ghost)** ücretli bir yönetim servisi olan kar amacı gütmeyen bir kurumdur.
 
-[Npm](https://github.com/npm/npm) ve [Docker](https://github.com/docker/docker) gibi bazı popüler projeler iş büyümelerini desteklemek için risk sermayesini desteği arıyorlar.
+[Npm](https://github.com/npm/cli) ve [Docker](https://github.com/docker/docker) gibi bazı popüler projeler iş büyümelerini desteklemek için risk sermayesini desteği arıyorlar.
 
 ### Hibe fonu için başvur
 
diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md
index e7b2934ae27..142b1f03e22 100644
--- a/_articles/tr/how-to-contribute.md
+++ b/_articles/tr/how-to-contribute.md
@@ -230,7 +230,7 @@ Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aş
 * [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi
 
diff --git a/_articles/zh-hans/best-practices.md b/_articles/zh-hans/best-practices.md
index fd8452e4267..c19caffa01a 100644
--- a/_articles/zh-hans/best-practices.md
+++ b/_articles/zh-hans/best-practices.md
@@ -255,7 +255,7 @@ fork 一个项目不什么坏事情。能复制并且修改别人的代码是开
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   我是 WP-CLI 的维护者，我发现我需要首先让自己开心，在开源项目和其他事情之间设定清楚的界限。我发现最好的平衡点就是每周在日常的工作安排中花 2-5 小时在这上面。这会让我从感觉太累到保持持续的激情。因为我给我需要解决的 issue 标上了优先级，从而我能够在我认为重要的事情上有所进展。
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["我的悼文，你现在是一个非常流行的项目的维护者"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["我的悼文，你现在是一个非常流行的项目的维护者"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/zh-hans/code-of-conduct.md b/_articles/zh-hans/code-of-conduct.md
index bdb8c7dc97c..6e2dcf9716d 100644
--- a/_articles/zh-hans/code-of-conduct.md
+++ b/_articles/zh-hans/code-of-conduct.md
@@ -32,7 +32,7 @@ redirect_from: /zh-cn/code-of-conduct/
 
 无论你们在哪里，请使用已有的行为守则。[贡献者盟约](https://www.contributor-covenant.org/)是一个被超过40,000个开源项目（包括Kubernetes, Rails和Swift）所使用的行为守则。
 
-[Django行为守则](https://www.djangoproject.com/conduct/)和[Citizen行为守则](http://citizencodeofconduct.org/)都是非常好的行为守则。
+[Django行为守则](https://www.djangoproject.com/conduct/)和[Citizen行为守则](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/)都是非常好的行为守则。
 
 请将CODE_OF_CONDUCT文件放在你们项目的根目录，并在README中附上其链接，这样对你们的社区是可见的。
 
diff --git a/_articles/zh-hans/how-to-contribute.md b/_articles/zh-hans/how-to-contribute.md
index 59d5093a133..239d3699336 100644
--- a/_articles/zh-hans/how-to-contribute.md
+++ b/_articles/zh-hans/how-to-contribute.md
@@ -218,7 +218,7 @@ redirect_from: /zh-cn/how-to-contribute/
 * [Up For Grabs](https://up-for-grabs.net/)
 * [像忍者一样贡献](https://contributor.ninja)
 * [最初的贡献](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### 提交贡献之前的检查列表
 
diff --git a/_articles/zh-hant/best-practices.md b/_articles/zh-hant/best-practices.md
index b0401a04f8e..1a3163e7092 100644
--- a/_articles/zh-hant/best-practices.md
+++ b/_articles/zh-hant/best-practices.md
@@ -255,7 +255,7 @@ fork一個專案不什麼壞事情。能複製並且修改別人的程式是開
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   我是WP-CLI的維護者，我發現我需要首先讓自己開心，在開源專案和其他事情之間設定清楚的界限。我發現最好的平衡點就是每週在日常的工作安排中花2-5小時在這上面。這會讓我從感覺太累到保持持續的激情。因爲我給我需要解決的issue表上了優先級，從而我能夠在我認爲重要的事情上有所進展。
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["我的悼文，你現在是一個非常流行的專案的維護者"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["我的悼文，你現在是一個非常流行的專案的維護者"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/zh-hant/code-of-conduct.md b/_articles/zh-hant/code-of-conduct.md
index 10649a5de71..fd0dfc14ea0 100644
--- a/_articles/zh-hant/code-of-conduct.md
+++ b/_articles/zh-hant/code-of-conduct.md
@@ -32,7 +32,7 @@ redirect_from: /zh-tw/code-of-conduct/
 
 無論你們在哪裏，請使用已有的行爲守則。[貢獻者盟約](http://contributor-covenant.org/)是一個被超過40，000個開源專案（包括Kubernetes, Rails和Swift）所使用的行爲守則。
 
-[Django行爲守則](https://www.djangoproject.com/conduct/)和[Citizen行爲守則](http://citizencodeofconduct.org/)都是非常好的行爲守則。
+[Django行爲守則](https://www.djangoproject.com/conduct/)和[Citizen行爲守則](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/)都是非常好的行爲守則。
 
 請將CODE_OF_CONDUCT文件放在你們專案的根目錄，並在README中附上其鏈接，這樣對你們的社群是可見的。
 
diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md
index 32d16ac5969..c6eb5d96d90 100644
--- a/_articles/zh-hant/how-to-contribute.md
+++ b/_articles/zh-hant/how-to-contribute.md
@@ -218,7 +218,7 @@ redirect_from: /zh-tw/how-to-contribute/
 * [Up For Grabs](http://up-for-grabs.net/)
 * [貢獻忍者](https://contributor.ninja)
 * [最初的贡献](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### **提交貢獻前應做的檢查清單**
 

From d4b7f76dcef991b7b23dd6413de73cc8742d6819 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Sun, 25 Apr 2021 21:35:04 +0430
Subject: [PATCH 155/749] Initial translation done.

---
 _articles/fa/getting-paid.md | 160 +++++++++++++++++------------------
 1 file changed, 78 insertions(+), 82 deletions(-)

diff --git a/_articles/fa/getting-paid.md b/_articles/fa/getting-paid.md
index 42d75af5b33..ddb05d87f00 100644
--- a/_articles/fa/getting-paid.md
+++ b/_articles/fa/getting-paid.md
@@ -1,13 +1,8 @@
 ---
-lang: en
-title: Getting Paid for Open Source Work
-description: Sustain your work in open source by getting financial support for your time or your project.
+lang: fa
+title: گرفتن دستمزد برای کارهای متن باز
+description: با دریافت پشتیبانی‌های مالی در ازای زمانی که می‌گذارید یا به خاطر پروژه‌ای که پیش می‌برید، کار متن باز خود را حمایت کنید.
 class: getting-paid
-toc:
-  why-some-people-seek-financial-support: "Why some people seek financial support"
-  funding-your-own-time: "Funding your own time"
-  finding-funding-for-your-project: "Finding funding for your project"
-  building-a-case-for-financial-support: "Building a case for financial support"
 order: 7
 image: /assets/images/cards/getting-paid.png
 related:
@@ -15,178 +10,179 @@ related:
   - leadership
 ---
 
-## Why some people seek financial support
+## چرا برخی افراد به دنبال پشتیبانی‌های‌ مالی هستند
 
-Much of open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+بیشتر کارهای متن باز داوطلبانه است. به عنوان مثال، کسی ممکن است در پروژه‌ای که از آن استفاده می‌کند با ایرادی (باگ) روبرو شود و راه‌حلی آسان برای ایراد ارائه کند، یا ممکن است کسی در اوقات فراغت خود از دستکاری در پروژه‌ی متن باز لذت ببرد.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
-I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+	من به دنبال یک پروژه‌ی برنامه نویسی به دید «سرگرمی» بودم که بتواند مرا در طول هفته در ایام کریسمس به خود مشغول کند. (…) و فقط یک کامپیوتر در دست و بالم بود. تصمیم گرفتم برای «زبان اسکریپتی» جدیدی که اخیراً به آن فکر می‌کردم، مفسر بنویسم. پایتون را به عنوان اسم موقت انتخاب کردم
   <p markdown="1" class="pquote-credit">
 — @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
   </p>
 </aside>
 
-There are many reasons why a person would not want to be paid for their open source work.
+دلایل زیادی برای مایل نبودن شخص برای دریافت دستمزد در ازای کار متن باز خود، وجود دارد.
 
-* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
-* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
-* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+* ممکن است از قبل، **کار تمام وقت مورد علاقه‌ی خود را داشته باشند** که به آن‌ها این امکان را می‌دهد تا در اوقات فراغت خود در کارهای متن باز مشارکت داشته باشند.
+* آن‌ها از تصور کردن کارهای متن باز **به عنوان یک سرگرمی یا فرآیندی خلاقانه لذت می‌برند** و نمی‌خواهند از نظر مالی ملزم به کار در پروژه‌های خود باشند.
+* آن‌ها از طریق مشارکت در کارهای متن باز **از مزایای دیگری برخوردار می‌شوند**، همچون ایجاد نمونه‌کار یا شهرت و اعتباری برای خود، یادگیری مهارت جدید یا احساس نزدیک‌تر بودن و صمیمیت بیشتر با اجتماع.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
-  Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+  کمک‌های مالی باعث ایجاد احساس مسئولیت برای برخی می‌شود. (…)برای ما مهم است که در جهان شتابان و و بهم پیوسته‌ای که در آن زندگی می‌کنیم، بتوانیم بگوییم «نه، الان حس و حال انجام کار دیگه‌ای را دارم».
   <p markdown="1" class="pquote-credit">
 — @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
   </p>
 </aside>
 
-For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+برای دیگران، به ویژه هنگامی که مشارکت‌ها باید ادامه بیابد و یا به زمان قابل توجهی نیاز داشته باشد؛ اگر پروژه به آن‌ها نیاز داشته باشد یا به دلایل شخصی باید به کار ادامه دهند، پرداخت دستمزد برای مشارکت در کار متن باز، تنها راه برای مشارکت است.
+
+حفظ پروژه‌های پرطرفدار، می‌تواند مسئولیت سنگینی را بر روی دوش افراد بگذارد، می‌تواند بجای چند ساعت در ماه 10 یا 20 ساعت در هفته را به خود اختصاص دهد.
 
-Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
-  Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+  از هر نگهدارنده‌ی پروژه‌ی متن بازی که خواستید بپرسید، و آن‌ها در مورد واقعیت میزان کاری که برای مدیریت یک پروژه انجام می‌دهند، به شما می‌گویند. شما موکل‌هایی خواهید داشت. مسائلی را برای آن‌ها حل و فصل می‌کنید. ویژگی‌های جدیدی را خلق می‌کنید. و این‌ها، زمانی زیادی را از شما می‌طلبند.
   <p markdown="1" class="pquote-credit">
 — @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
   </p>
 </aside>
 
-Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+همچنین کارهای با دستمزد، این امکان برای افراد از اقشار مختلف جامعه را فراهم می‌آورد تا مشارکت‌های قابل‌توجه و معناداری انجام دهند. برخی از افراد، به سبب وضعیت مالی کنونی‌شان، بدهی یا خانواده یا سایر تعهدات، امکان مشارکت بدون دستمزد در پروژه‌های متن باز را ندارند. این بدان معناست که جهان هرگز مشارکت افراد مستعدی را که توانایی مالی برای مشارکت داوطلبانه را ندارند، نمی‌بیند.  همانطور که @ashedryden [گفته است](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)، پیامدهایی اخلاقی در این میان وجود دارد، زیرا کسانی که از قبل در زندگی دارای مزایایی هستند، شانس بیشتری در کارهایی که انجام می‌شود دارند، درنتیجه بر اساس مشارکت‌های داوطلبانه‌ی خود مزایای بیشتری کسب می‌کنند، در حالی که سایر افرادی که قادر به داوطلب شدن نیستند، فرصت‌های آتی را از دست می‌دهند، که این عدم تنوع را در اجتماع کنونی (community) متن باز گسترش می‌دهد.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
-   OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+   «OSS»، مزایای زیادی برای صنعت فناوری به همراه دارد که به نوبه‌ی خود به معنای مزایایی برای کلیه‌ی صنایع است. (…)با این حال، اگر تنها افراد خوش‌شانس (کسانی که قادر به مشارکت داوطلبانه هستند) و به شدت علاقه‌مند هستند که می‌توانند در پروژه‌های متن باز تمرکز کنند، ظرفیتی فوق‌العاده از استعدادهای استفاده نشده وجود خواهد داشت.
   <p markdown="1" class="pquote-credit">
 — @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
   </p>
 </aside>
 
-If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+اگر به دنبال حمایت‌های مالی هستید، دو راه وجود دارد. می‌توانید زمان مناسب را برای مشارکت پیدا کنید، یا می‌توانید بودجه‌ای برای پروژه‌ی خودتان پیدا کنید.
 
-## Funding your own time
+## وقت خود را سرمایه‌گذاری کنید
 
-Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+امروزه بسیاری از افراد برای کار به صورت پاره وقت یا تمام وقت در پروژه‌های متن باز دستمزد دریافت می‌کنند. متداول‌ترین راه برای دریافت دستمزد برای وقتی که صرف می‌کنید، صحبت کردن با کارفرمای خودتان است.
 
-It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+متقاعد کردن کارفرما در پروژه‌ای که واقعا از آن استفاده ‌می‌کند آسان‌تر است، اما در مورد صحبتی که با او خواهید کرد، رویه‌ای خلاقانه در نظر بگیرید. شاید کارفرمای شما از این پروژه استفاده نکند، اما آن‌ها از پایتون استفاده می‌کنند و نگهداری از  پروژه‌ی پایتون محبوب به جذب توسعه‌دهندگان جدید پایتون کمک می‌کند. شاید این امر باعث شود که کارفرمای شما به طور کلی در در ارتباط با توسعه‌دهندگان سازنده‌تر و دوستانه‌تر به نظر برسد.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.
+  مانند بسیاری پروژه‌های متن باز، با سنگینی مسئولیت نگهداری پروژه دست و پنجه نرم می‌کردم. هنگامی که من برای اولین بار شروع به انجام پروژه‌های متن باز کردم، تا در وقت سر کار می‌ماندم تا روی آن کار کنم یا درست وقتی که به خانه می‌رسیدم، کار روی آن را ادامه می‌دادم. (...) من این امکان را داشتم مسائلی را که با آن روبرو می‌شدم را با رئیس خودم در میان بگذارم و به ایده‌هایی درباره‌ی چگونگی ادغام کردن وظایف پروژه‌های متن باز با شلوغی کار خودمان دست یابیم.
   <p markdown="1" class="pquote-credit">
 — @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
   </p>
 </aside>
 
-If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+اگر در حال حاضر پروژه‌ای متن باز ندارید که بخواهید روی آن کار کنید، اما ترجیح می‌دهید که خروجی کار فعلی شما متن باز باشد، از کارفرمای خود درخواست کنید که برخی از نرم‌افزارهای داخلی خود را متن باز کند.
 
-Many companies are developing open source programs to build their brand and recruit quality talent.
+بسیاری از شرکت‌ها برنامه‌هایی متن باز توسعه می‌دهند تا اعتباری برای نام برند خود ایجاد کنند و افرادی با استعداد استخدام کنند.
 
-@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+به عنوان مثال، @hueniverse دریافت که دلایلی تجاری برای توجیه [سرمایه‌گذاری والمارت (Walmart)] (https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html)در متن باز وجود دارد. و jamesgpearce@، دریافت که برنامه‌ی متن باز فیس‌بوک، [تفاوت‌هایی را در استخدام ایجاد کرده است](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon)
 
-> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+> کاملا با فرهنگ خلاقیت‌جویانه‌ی ما و آنچه که سازمان ما با آن شناخته می‌شود، سازگار و همسو است. ما از کارمندان خود پرسیدیم، «آیا از برنامه‌ی نرم‌افزاری متن باز فیس‌بوک آگاهی داشتید؟» دو سوم آن‌ها گفتند «بله» یک دوم آن‌ها گفتند که این برنامه به تصمیم‌شان برای کار کردن در فیس‌بوک تاثیر داشت. اینها اعداد کمی نیستند و امیدواریم که این روند ادامه داشته باشد.
 
-If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+اگر شرکت شما این مسیر را طی می‌کند، مهم است که مرزهای بین اجتماع و فعالیت‌های شرکتی را روشن کنید. در آخر، پروژه‌های متن باز از طریق مشارکت‌های مردم در سرتاسر جهان از خود نگهداری می‌کند؛ این پروژه‌ها بزرگ‌تر از هر شرکت یا فضایی هستند.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
-  Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+  دریافت دستمزد برای کار در پروژه‌های متن باز فرصتی نادر و شگفت‌انگیز است، اما نباید اشتیاق خود در راه را از دست بدهید. اشتیاق شما باید چیزی باشد که شرکت به دنبال آن است.
   <p markdown="1" class="pquote-credit">
 — @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
   </p>
 </aside>
 
-If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+اگر نمی‌توانید کارفرمای کنونی خودتان را متقاعد به اولویت‌بندی کارهای متن باز بکنید، سعی کنید کارفرماهای جدیدی پیدا کنید که کارمندان را تشویق به مشارکت در متن باز می‌کنند. به دنبال شرکت‌هایی بگردید که تعهد صریحی برای کار با پروژه‌های متن باز داشته باشند. به عنوان مثال:
+
+* برخی شرکت‌ها مانند [Netflix](https://netflix.github.io/) یا [PayPal](https://paypal.github.io/)، وب‌سایت‌هایی دارند که مشارکت آن‌ها در متن باز را برجسته و نمایان می‌کند
+* 	شرکت [Zalando](https://opensource.zalando.com)، «سیاست‌های مشارکت متن باز» خود برای کارمندان را منتشر کرد
 
-* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
-* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+پروژه‌هایی که از شرکت‌های بزرگی مانند [Go](https://github.com/golang) یا [React](https://github.com/facebook/react) سرچشمه گرفته‌اند و به آن وصل‌اند نیز احتمالاً افرادی را برای کار با متن باز استخدام خواهند کرد
 
-Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+بسته به شرایط شخصی خودتان، می‌توانید به طور مستقل برای تأمین هزینه‌های کار متن باز خود، پول جمع کنید. به عنوان مثال:
 
-Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
 
-* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
-* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
-* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+* نرم‌افزار متن باز @Homebrew ([و بسیاری از نگهدارندگان و سازمان‌ها](https://github.com/sponsors/community))، کار خودشان را از طریق حامیان مالی [GitHub](https://github.com/sponsors) تأمین می‌کنند
+* @gaearon کار خود در [Redux](https://github.com/reactjs/redux) را از طریق کمپین سرمایه‌گذاری جمعی «Patreon» تأمین مالی کرد
+* @andrewgodwin از [طریق کمپین Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) کارش در مورد مایگریشن‌های دیتابیس «Django» را تأمین مالی کرد. (Schema Migration)
 
-Finally, sometimes open source projects put bounties on issues that you might consider helping with.
+در آخر اینکه گاهی اوقات پروژه‌های متن باز درمورد موضوعاتی که ممکن است در آن بخواهید کمک کنید پاداش‌هایی قرار می‌دهند.
 
-* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
-* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+* @ConnorChristie توانست بابت [کمک](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) به @MARKETProtocol در «JavaScript library» (کتابخانه‌ی جاوا اسکریپت) از طریق پاداشی‌ تعیین شده در [gitcoin](https://gitcoin.co/)، دستمزد بگیرد
+* @mamiM پس از تأمین اعتبار مربوط به مشکلِ شبکه‌ی Bounties، ترجمه‌ی ژاپنی برای @MetaMask انجام داد.
 
-## Finding funding for your project
+## یافتن بودجه برای پروژه‌
 
-Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+علاوه‌ بر توافق‌های اولیه با مشارکت‌کنندگان، گاهی اوقات پروژه‌ها از شرکت‌ها، افراد حقیقی یا دیگران برای تأمین بودجه‌ی کارهای جاری پول جمع‌آوری می‌کنند.
 
-Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing into new features or ideas.
+بودجه‌های سازمانی ممکن است به پرداخت دستمزد مشارکت‌کنندگان، تأمین هزینه‌های اجرای پروژه (مانند هزینه‌های میزبانی) یا سرمایه‌گذاری بر روی ویژگی‌ها یا ایده‌های جدید اختصاص یابد.
 
-As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+با افزایش محبوبیت ‌متن باز، هنوز هم یافتن بودجه برای پروژه‌ها به صورت تجربی و آزمایشی است، اما چندین گزینه‌ی متداول در دسترس است.
 
-### Raise money for your work through crowdfunding campaigns or sponsorships
+### جمع‌آوری سرمایه از طریق کمپین‌های سرمایه‌گذاری جمعی یا حمایت‌های مالی
 
-Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
-A few examples of sponsored projects include:
+اگر از قبل مخاطب یا اعتبار بالایی داشته باشید یا پروژه‌ی شما از محبوبیت بالایی برخوردار باشد، یافتن حمایت‌های مالی امکان‌پذیر است. چند نمونه از پروژه‌های حمایت شده:
 
-* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803)
-* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+* پروژه‌ی **[webpack](https://github.com/webpack)** از طریق [OpenCollective](https://opencollective.com/webpack) از شرکت‌ها و اشخاص پول جمع‌آوری می‌کند
+* بودجه‌ی **[Vue](https://github.com/vuejs/vue)** از طریق [Patreon](https://github.com/open-source/stories/yyx990803) تأمین می‌شود
+* **[Ruby Together](https://rubytogether.org/)،** یک سازمان غیر‌انتفاعی است که هزینه‌های کار در [bundler](https://github.com/bundler/bundler)،  [RubyGems](https://github.com/rubygems/rubygems) و سایر پروژه‌های بر پایه‌ی زیرساختی «Ruby» را پرداخت می‌کند
 
-### Create a revenue stream
+### ایجاد یک منبع درآمدی
 
-Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+بسته به پروژه‌ی خود، ممکن است بتوانید از طریق تبلیغات، گزینه‌های میزبانی شده یا ویژگی‌های اضافی کسب درآمد داشته باشید. چندین مثال در این زمینه:
 
-* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
-* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
-* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+* **[Sidekiq](https://github.com/mperham/sidekiq)**، نسخه‌هایی پولی به منظور پشتیبانی بیشتر ارائه می‌دهد
+* **[Travis CI](https://github.com/travis-ci)**، نسخه‌های پولی محصولات خود را ارائه می‌دهد
+* **[Ghost](https://github.com/TryGhost/Ghost)**، یک سازمان غیرانتفاعی است که خدمات مدیریتی پولی ارائه می‌دهد
 
-Some popular projects, like [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+بعضی از پروژه‌های محبوب مانند [npm](https://github.com/npm/npm) و [Docker](https://github.com/docker/docker)، برای حمایت از رشد کسب و کار خود، حتی سرمایه‌های مخاطره‌آمیزی را جمع‌آوری می‌کنند
 
-### Apply for grant funding
+### برای بودجه، درخواست کمک هزینه (بورسیه) دهید
 
-Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+برخی از موسسات و شرکت‌های نرم‌افزاری، کمک‌هزینه‌های مالی برای کارهای متن باز ارائه می‌دهند. گاهی اوقات، بدون ایجاد نهاد قانونی‌ای برای پروژه، کمک‌هزینه‌های مالی به افراد حقیقی پرداخت می‌شود.
 
-* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
-* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
-* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
-* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+* **نرم‌افزار [Read the Docs](https://github.com/rtfd/readthedocs.org)**، از پشتیبانی بخش متن باز [Mozilla](https://www.mozilla.org/en-US/grants/)، کمک‌هزینه دریافت کرد
+* **بودجه‌ی کار [OpenMRS](https://github.com/openmrs)** توسط [Stripe’s Open Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) تأمین شد
+* **[Libraries.io](https://github.com/librariesio)** از موسسه‌ی [Sloan](https://sloan.org/programs/digital-technology) کمک‌هزینه‌ دریافت کرد
+* **موسسه‌ی نرم‌افزار پایتون (Python Software Foundation)**، کمک‌های مالی برای کارهای مرتبط با پایتون ارائه می‌دهد
 
-For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+برای جزئیات دقیق‌تر و مطالعات موردی، @nayafia راهنمای دریافت دستمزد برای کارهای متن باز را [نوشت](https://github.com/nayafia/lemonade-stand). انواع بودجه‌ها به مهارت‌های مختلفی نیاز دارد، بنابراین نقاط قوت خود را در نظر بگیرید تا  گزینه‌ی مناسب برای کار خودتان را دریابید.
 
-## Building a case for financial support
+## ایجاد پرونده‌ی موردی (فایل) به منظور دریافت حمایت مالی
 
-Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+این که آیا پروژه‌ی شما ایده‌ی جدیدی است یا سال‌هاست که وجود دارد؛ باید برای شناسایی و مشخص کردن سرمایه‌گذار هدف و ایجاد یک پرونده‌‌ی اغواکننده، باید به خوبی راجع به آن فکر کنید.
 
-Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+چه بخواهید هزینه‌ی زمانی که صرف می‌کنید را خودتان پرداخت کنید و یا موسسه‌ای هزینه‌ی پروژه‌ی شما را پرداخت کند، باید بتوانید به سوالات زیر پاسخ دهید.
 
-### Impact
+### تاثیرگذاری
 
-Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+این پروژه به چه دردی می‌خورد؟ برای چه کاربران شما، یا کاربران بالقوه‌ی شما، پروژه‌ را دوست داشته باشند؟ پروژه‌ی خود را در پنج سال آینده چطور می‌بینید؟
 
-### Traction
+### مقبولیت
 
-Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+سعی کنید شواهدی را در مورد اهمیت پروژه‌ی خود جمع‌آوری کنید؛ چه بخواهد معیارهای سنجش، تجربه‌های گذشته، یا اظهارنظرهای مثبتی باشد. آیا شرکت‌ها یا افراد قابل ذکری وجود دارند که از پروژه‌ی شما استفاده بکنند؟ اگر نه، آیا شخص برجسته‌ای پروژه‌ی شما را تأیید کرده است؟
 
-### Value to funder
+### ارزش آن برای سرمایه‌گذار
 
-Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+سرمایه‌گذاران، چه کارفرمای شما باشد و یا چه یک موسسه‌ی اعطای کمک‌هزینه، اکثرا جذب فرصت‌ها می‌شوند. چرا آن‌ها باید از پروژه‌ی شما در برابر سایر فرصت‌ها حمایت کنند؟ از پروژه‌ی شما چه منفعت شخصی‌ای می‌برند؟
 
-### Use of funds
+### مصارف بودجه
 
-What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+با بودجه پیشنهادی، دقیقاً به چه نتیجه‌ای دست خواهید یافت؟ به جای فکر کردن به پرداخت حقوق و دستمزد، روی نقاط عطف یا نتایج پروژه متمرکز شوید.
 
-### How you'll receive the funds
+### چگونه بودجه را دریافت خواهید کرد
 
-Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+آیا سرمایه‌گذار، الزاماتی در مورد پرداخت هزینه مدنظر دارد؟ به عنوان مثال، ممکن است لازم باشد شما سازمانی غیرانتفاعی باشید یا یک حامی مالی غیرانتفاعی داشته باشید. یا شاید بودجه باید به جای سازمان به یک پیمانکار حقیقی داده شود. هر شخص سرمایه‌گذاری الزامات متفاوتی دارد، بنابراین حتماً از قبل تحقیقات خود را انجام دهید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
-  For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+  سال‌هاست که ما با داشتن بیش از 20 میلیون نفر در اجتماع‌مان، وب‌سایت برتر در زمینه‌ی نماد‌ها (آیکون) در بیش از 70 میلیون وب‌سایت، از جمله «Whitehouse.gov»، مشخص شده‌ایم. (…)نسخه‌ی 4، سه سال پیش بود. فناوری وب از آن زمان با تغییرات زیادی همراه بوده است و صادقانه بگویم، «Font Awesome»، کمی قدیمی شده است. (…)به همین دلیل است که ما «Font Awesome 5» را معرفی می‌کنیم. ما در حال مدرن‌سازی و بازنویسی «CSS» و طراحی مجدد همه‌ی نمادها هستیم. داریم درباره‌ی طراحی بهتر، سازگاری بهتر و خوانایی بهتر صحبت میکنیم.
   <p markdown="1" class="pquote-credit">
 — @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
   </p>
 </aside>
 
-## Experiment and don't give up
+## آزمایش و تجربه کنید و تسلیم نشوید
 
-Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
+جمع‌آوری پول آسان نیست، چه پروژه‌ای متن باز باشید، چه یک سازمان غیرانتفاعی و یا یک استارت‌آپ نرم‌افزاری؛ باید در بیشتر موارد با دیدی خلاقانه به موضوع نگاه کنید. با مشخص کردن اینکه چگونه می‌خواهید دستمزد بگیرید، با تحقیقات خود و قرار دادن خود به جای سرمایه‌گذار، به شما کمک می‌کند تا پرونده‌ای قانع‌کننده برای تأمین بودجه بسازید.

From 018d345ee9d8172c04594d3d9e609878ca25934c Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 3 May 2021 10:36:32 +0000
Subject: [PATCH 156/749] Bump html-proofer from 3.19.0 to 3.19.1

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.19.0 to 3.19.1.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.19.0...v3.19.1)

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 4086bbc0959..86995d3742f 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -22,7 +22,7 @@ GEM
     em-websocket (0.5.2)
       eventmachine (>= 0.12.9)
       http_parser.rb (~> 0.6.0)
-    ethon (0.13.0)
+    ethon (0.14.0)
       ffi (>= 1.15.0)
     eventmachine (1.2.7)
     execjs (2.7.0)
@@ -87,7 +87,7 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.19.0)
+    html-proofer (3.19.1)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)
@@ -213,7 +213,7 @@ GEM
       rb-fsevent (~> 0.10, >= 0.10.3)
       rb-inotify (~> 0.9, >= 0.9.10)
     mercenary (0.3.6)
-    mini_portile2 (2.5.0)
+    mini_portile2 (2.5.1)
     minima (2.5.1)
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)

From 2cb2fde9a42436ba8e4088c63caf909f7c1e2f4b Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Tue, 4 May 2021 20:21:59 +0430
Subject: [PATCH 157/749] Initial translation done.

---
 _articles/fa/leadership-and-governance.md | 127 +++++++++++-----------
 1 file changed, 61 insertions(+), 66 deletions(-)

diff --git a/_articles/fa/leadership-and-governance.md b/_articles/fa/leadership-and-governance.md
index b8006c30107..7c105727bc2 100644
--- a/_articles/fa/leadership-and-governance.md
+++ b/_articles/fa/leadership-and-governance.md
@@ -1,17 +1,8 @@
 ---
-lang: en
-title: Leadership and Governance
-description: Growing open source projects can benefit from formal rules for making decisions.
+lang: fa
+title: مدیریت و نظارت
+description: وجود نقش‌های رسمی جهت تصمیم‌گیری، منافع زیادی برای پروژه‌های متن باز در حال رشد به همراه دارد.
 class: leadership
-toc:
-  understanding-governance-for-your-growing-project: "Understanding governance for your growing project"
-  what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?"
-  how-do-i-formalize-these-leadership-roles: "How do I formalize these leadership roles?"
-  when-should-i-give-someone-commit-access: "When should I give someone commit access?"
-  what-are-some-of-the-common-governance-structures-for-open-source-projects: "What are some of the common governance structures for open source projects?"
-  do-i-need-governance-docs-when-i-launch-my-project: "Do I need governance docs when I launch my project?"
-  what-happens-if-corporate-employees-start-submitting-contributions: "What happens if corporate employees start submitting contributions?"
-  do-i-need-a-legal-entity-to-support-my-project: "Do I need a legal entity to support my project?"
 order: 6
 image: /assets/images/cards/leadership.png
 related:
@@ -19,147 +10,151 @@ related:
   - metrics
 ---
 
-## Understanding governance for your growing project
+## نظارت درست بر روی پروژه‌ی در حال رشد
 
-Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+پروژه‌ی شما رشد می‌کند، مردم درگیر پروژه‌ی شما می‌شوند، و شما به ادامه دادن این کار متعهد می‌شوید. در این مرحله، ممکن است از خود بپرسید که چگونه می‌توانید مشارکت‌کنندگان پروژه‌ی خود را منسجم و یکپارچه کنید، خواه دادن دسترسی کامیت باشد یا حل و فصل کردن بحث‌ها و گفتگوهای درون اجتماع. اگر سوالاتی دارید، جواب‌ها پیش ماست.
 
-## What are examples of formal roles used in open source projects?
+## مثال‌هایی از نقش‌های رسمی مورد استفاده در پروژه های متن باز، چه هستند؟
 
-Many projects follow a similar structure for contributor roles and recognition.
+بسیاری از پروژه‌ها، ساختار مشابهی را در حوزه‌ی نقش‌های مشارکتی و شناختی دنبال می‌کنند.
 
-What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+مضمون و معنای این نقش‌ها، در واقع کاملا به شما بستگی دارد. در اینجا، چند نوع نقشی که ممکن است آن‌ها را تشخیص دهید، نام بردیم:
 
-* **Maintainer**
-* **Contributor**
-* **Committer**
+* **نگهدارنده (Maintainer)**
+* **مشارکت‌کننده (Contributor)**
+* **کامیت کننده (Committer)**
 
-**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+**در برخی از پروژه‌ها، نگهدارندگان** تنها افرادی در پروژه هستند که دسترسی کامیت دارند. در برخی دیگر از پروژه‌ها، فقط افرادی دسترسی دارند که در «README» به عنوان نگهدارنده ذکر شده‌اند.
 
-A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+نگهدارنده لزوماً کسی نیست که برای پروژه‌ی شما کد می‌نویسد. بلکه می‌تواند کسی باشد که در تبلیغ پروژه‌ی شما کارهای زیادی انجام داده باشد یا مستنداتی را نوشته باشد که پروژه را برای دیگران قابل دسترسی‌تر کرده است. صرف نظر از کاری که آن‌ها در طی روز انجام می‌دهند، نگهدارنده کسی است که نسبت به مسیر و اجرای پروژه احساس مسئولیت می‌کند و متعهد به بهبود بخشیدن آن است.
 
-**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+**مشارکت‌کننده می‌تواند هر کسی باشد**: کسی که مسئله یا درخواست «Pull»ی را مطرح می‌کند، یا افرادی باشند که به پروژه ارزش می‌بخشند (خواه این که مسائل مربوط به اولویت‌بندی درخواست‌ها، نوشتن کد یا سازماندهی رویدادها باشد) یا هر کسی باشد که درخواست «pull»ی را ادغام (merge) بکند (جزئی‌ترین تعریف از مشارکت‌کننده)
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+  \[در پروژه‌ی Node.js\]، هر شخصی که درباره یک موضوع اظهارنظر یا کدی را ارسال کند، عضوی از پروژه است. تنها دیدن نظرات یا ارسال کد به منزله‌ی عبور آن‌ها از فقط کاربر بودن به مشارکت‌کننده بودن است.
   <p markdown="1" class="pquote-credit">
 — @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
   </p>
 </aside>
 
-**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+**اصطلاح «کامیت کننده»،** ممکن است برای وجه تمایز دسترسی کامیت، که نوع خاصی از مسئولیت در مقابل سایر اشکال مشارکت است، استفاده شود.
 
-While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+در حالی که می‌توانید نقش‌ها را در پروژه‌ی خود به هر روشی که دوست دارید تعریف کنید، استفاده از تعاریف گسترده‌تر را برای تقویت اشکال بیشتری از مشارکت، [مد نظر خود قرار دهید](../how-to-contribute/#what-it-means-to-contribute). شما می‌توانید از نقش‌های مدیریتی برای شناسایی رسمی افرادی که مشارکت برجسته‌ای به پروژه‌ی شما کرده‌اند، صرف نظر از مهارت‌های فنی آن‌ها استفاده کنید
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
-  You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+  ممکن است من را به عنوان سازنده‌ی «Django» بشناسید... اما در واقع من کسی هستم که یک سال بعد از ساخت «Django»، برای کار در بخشی از آن استخدام شدم. (...)مردم فکر می‌کنند به دلیل مهارت برنامه‌نویسی است که موفق شدم... اما در بهترین حالت می‌توان گفت که من یک برنامه‌نویس متوسط هستم.
   <p markdown="1" class="pquote-credit">
 — @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
   </p>
 </aside>
 
-## How do I formalize these leadership roles?
+## چگونه به این نقش‌های مدیریتی، رسمیت ببخشیم؟
 
-Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+رسمیت بخشیدن به نقش‌های مدیریتی، باعث می‌شود افراد احساس مالکیت کنند و به اعضای سایر اجتماع‌ها بگویند برای کمک به چه کسانی روی آورند.
 
-For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+در پروژه‌های کوچک‌تر، تعیین کردن مدیران می‌تواند به سادگی افزودن نام آن‌ها به فایل‌های «README» یا به یک فایل متنی «CONTRIBUTORS» باشد.
 
-For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+برای پروژه‌های بزرگ‌تر، اگر وب‌سایتی دارید، یک صفحه‌ی تیمی ایجاد کنید یا اسامی مدیران پروژه را در آنجا لیست کنید. به عنوان مثال، [Postgres](https://github.com/postgres/postgres/) یک [صفحه‌ی تیمی جامع](https://www.postgresql.org/community/contributors/) و فراگیر با مشخصاتی کوتاه برای هر مشارکت‌کننده دارد.
 
-If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+اگر پروژه‌ی شما دارای جامعه‌ی مشارکت‌کننده‌ی بسیار فعالی است، شما می‌توانید یک «تیم اصلی» از نگهدارنده‌ها، یا حتی کمیته‌های فرعی از افرادی که مالکیت حوزه‌های  موضوعات مختلف را دارند (به عنوان مثال، امنیت، اولویت‌بندی درخواست‌ها یا هدایت اجتماع) تشکیل دهید. به جای اینکه به هر کسی، وظایف خاصی را محول کنید، بگذارید افراد خودشان، برای نقش‌هایی که بیشتر از همه هیجان زده‌اند سازمان یابند و داوطلب شوند.
 
 <aside markdown="1" class="pquote">
-  \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+  \[ما\] تیم اصلی را با چندین «زیرگروه (گروه‌های فرعی)» تکمیل می‌کنیم. هر زیرگروه، بر روی حوزه‌ای خاص متمرکز می‌شود، به عنوان مثال، طراحی زبان یا کتابخانه‌ها. (…)به منظور اطمینان از هماهنگی کلی و داشتن چشم‌اندازی قوی و منسجم برای کل پروژه، هر زیرگروه توسط یکی از اعضای تیم اصلی هدایت می‌شود
   <p markdown="1" class="pquote-credit">
 — ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+تیم‌های مدیریت، ممکن است بخواهند کانالی مشخص (مانند IRC) ایجاد کنند یا به طور منظم برای بحث درمورد پروژه با هم ملاقات کنند (مانند Gitter یا Google Hangout). حتی می‌توانید آن جلسات را علنی برگزار کنید تا سایر افراد بتوانند گوش دهند. به عنوان مثال، [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) همچین کاری می‌کند
 
-Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+پس از اینکه نقش‌های مدیریتی را ایجاد کردید، ثبت چگونگی نحوه‌ی دسترسی افراد به آن‌ها را فراموش نکنید! فرآیند روشن و واضحی را برای چگونگی کسی که می‌خواهد نگهدارنده شود یا به کمیته‌ای فرعی در پروژه شما بپیوندد، ایجاد کنید و آن را در «GOVERNANCE.md» خود بنویسید.
 
-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.
+ابزارهایی مانند [Vossibility](https://github.com/icecrime/vossibility-stack)، می‌تواند به شما کمک کند تا به طور عمومی افرادی که در پروژه مشارکت می‌کنند (یا نمی‌کنند) را ردیابی کنید. ثبت این اطلاعات، جلوی این ذهنیت اجتماع که نگهدارندگان گروهی هستند که تصمیمات خود را به صورت خصوصی اتخاذ می‌کنند، می‌گیرد
 
-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).
+در آخر اینکه اگر پروژه‌ی شما در «GitHub» است، انتقال پروژه‌ی خود را از حساب شخصی خود به یک تشکل و اضافه کردن حداقل یک مدیر پشتیبان را مد نظر خود قرار دهید. [تشکل‌های «GitHub»](https://help.github.com/articles/creating-a-new-organization-account/)، مدیریت دسترسی‌ها و مراکز ذخیره‌سازی متعدد را آسان‌تر می‌کنند و پیشینه‌ی پروژه‌ی شما را از طریق [مالکیت مشترک](../building-community/#share-ownership-of-your-project) محافظت می‌کنند.
 
-## When should I give someone commit access?
+## چه موقع باید به کسی اجازه‌ی دسترسی کامیت بدهیم؟
 
-Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+برخی از افراد فکر می‌کنند که شما باید به هر کسی که در پروژه مشارکت می‌کند، دسترسی کامیت بدهید. با انجام این کار، افراد بیشتری ترغیب به داشتن احساس مالکیت نسبت به پروژه‌ی شما، می‌شوند.
 
-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.
+اگر پروژه‌ی شما در «GitHub» است، می توانید از شاخه‌های محافظت شده [protected branches](https://help.github.com/articles/about-protected-branches/) برای مدیریت افرادی که می‌توانند تحت شرایط خاصی در شاخه‌ای خاص عمل کنند، استفاده کنید
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
-  Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+  هر زمان کسی درخواست «pull»ی را برای شما ارسال کرد، به او اجازه‌ی دسترسی کایمت به پروژه را بدهید. اگرچه ممکن است در ابتدا بسیار احمقانه به نظر برسد، اما استفاده از این استراتژی به شما این امکان را می‌دهد تا قدرت واقعی «GitHub» را تجربه کنید. (...)به محض دسترسی کامیت افراد، آن‌ها دیگر نگران این نیستند که «patch»هاشان ادغام نشود و باعث زحمت و کار زیادی برای آن‌ها شود.
   <p markdown="1" class="pquote-credit">
 — @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
   </p>
 </aside>
 
-## What are some of the common governance structures for open source projects?
+## برخی از ساختارهای نظارتی متداول برای پروژه‌های متن باز چیست؟
 
-There are three common governance structures associated with open source projects.
+سه ساختار نظارتی متداول در ارتباط با پروژه‌های متن باز وجود دارد.
 
-* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
 
-* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+* **BDFL** مخفف «دیکتاتور خیرخواه جاویدان» است ( .(Benevolent Dictator for Lifeتحت این ساختار، یک نفر (معمولاً نویسنده‌ی اولیه‌ی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را می‌زند. [Python](https://github.com/python)، نمونه‌ای موثق در این مورد است. پروژه‌های کوچک‌تر احتمالاً به طور پیش‌فرض به صورت «BDFL» هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژه‌هایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقه‌بندی «BDFL» قرار گیرند
 
-* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
 
-Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+* **Meritocracy:** (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماع‌ها، مفهومی منفی دارد و ساختار آن [دارای پیشینه‌ی پیچیده‌ی اجتماعی و سیاسی ](http://geekfeminism.wikia.com/wiki/Meritocracy).)است.) تحت ساختار «شایسته سالاری»، به مشارکت‌کنندگان فعال پروژه (کسانی که از «شایستگی» نشان می‌دهند) نقش تصمیم‌گیرندگی رسمی داده می‌شود. تصمیم‌‌ها، معمولاً براساس اجماع رای گرفته می‌شوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد «Apache»، به وجود آمد. تمامی پروژه‌های «Apache» بر اساس شایسته سالاری هستند. مشارکت‌ها فقط توسط افراد حقیقی صورت می‌گیرد؛ نه توسط یک شرکت.
+
+
+* **Liberal contribution:** (مشارکت آزادنه) تحت مدل مشارکت آزادانه، افرادی که بیشترین کار را انجام می‌دهند به عنوان تأثیرگذارترین افراد شناخته می‌شوند، اما این مدل براساس کاری که اکنون انجام می‌دهند است و نه مشارکت‌های که در گذشته داشته‌اند. تصمیمات بزرگ‌ پروژه بر اساس فرآیندی در اجتماع به صورت اجماعی (بحث‌ در مورد مسائل اساسی) به جای رأی‌گیری تنها گرفته می‌شود، و تلاش می‌شود تا آنجا که ممکن است دیدگاه‌های بیشتری از اجتماع را شامل شود. از جمله پروژه‌هایی که از مدل مشارکت آزادانه استفاده کردند، می‌توان [Node.js](https://foundation.nodejs.org/) و [Rust](https://www.rust-lang.org/) را نام برد.
+
+از کدام مدل بهتر است استفاده کنید؟ به خودتان بستگی دارد! هر مدل، شامل نکات منفی و مثبتی می‌شود. اگرچه ممکن است این مدل‌ها در ابتدا کاملاً متفاوت به نظر برسند؛ اما هر سه مدل، اشتراکات بیشتری از آنچه که به نظر می رسد دارند:
 
 * [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
 * [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
 * [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
 
-## Do I need governance docs when I launch my project?
+## آیا هنگام راه‌اندازی پروژه‌ی خود به اسناد نظارتی نیاز دارم؟
+
+زمان مناسب و دقیقی برای نوشتن اسناد نظارتی پروژه وجود ندارد، اما هنگامی که شرایط اجتماع خود را دیدید و با جو آن آشنا گشتید، به ثبت رساندن اسناد بسیار ساده‌تر می‌شود. بهترین (و سخت‌ترین) بخش در مورد نظارت پروژه‌های متن باز این است که توسط خود اجتماع شکل می‌گیرد!
 
-There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+هر چند برخی اسناد اولیه‌ی نظارتی به طور اجتناب ناپذیری در پروژه‌ی شما خواهد بود، ولی شروع به نوشتن آنچه می‌توانید بکنید. به عنوان مثال، شما می‌توانید حتی در زمان راه‌اندازی پروژه‌ی خود، انتظارات واضح و شفاف خودتان از رفتار یا فرآیند‌ مشارکت کاری را تعریف کنید.
 
-Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+اگر شما عضوی از شرکتی هستید که پروژه‌ای متن باز راه‌اندازی می‌کند، بد نیست قبل از راه‌اندازی، بحثی درون‌سازمانی درباره نحوه‌ی نگهداری شرکت و تصمیم‌گیری در مورد پیشرفت پروژه داشته باشید. همچنین بهتر است در مورد مسیری که شرکت شما در رابطه با پروژه پیش خواهد گرفت، به صورت علنی صحبت دهید.
 
-If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
-  We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+ ما تیم‌های کوچکی را برای مدیریت پروژه‌ها در «GitHub» اختصاص می‌دهیم که در واقع در فیس‌بوک نیز بر روی آن‌ها کار می‌کنند. برای مثال، پروژه‌ی «React» توسط «React engineer»، اداره می‌شود.
   <p markdown="1" class="pquote-credit">
 — @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
   </p>
 </aside>
 
-## What happens if corporate employees start submitting contributions?
+## اگر کارمندان شاغل در شرکت شروع به ارائه‌ی خدمات کنند، چه می‌شود؟
 
-Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+پروژه‌های متن باز موفق، توسط بسیاری از افراد و شرکت‌ها مورد استفاده قرار می‌گیرند و در نهایت ممکن است برخی از شرکت‌ها شروع به کسب درآمد از آن پروژه‌ها بکنند. به عنوان مثال، شرکتی ممکن است از کدهای پروژه به عنوان یک بخش سازنده‌ی محصولات خدمات تجاری استفاده کند.
 
-As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+هنگامی که استفاده از پروژه بیشتر شود، افراد زیادی خواستار کسانی که در آن پروژه تخصص دارند می‌شوند؛ ممکن است شما یکی از آن‌ها باشید! و گاهی اوقات نیز به خاطر کاری که در پروژه‌ می‌کنید، حقوق دریافت کنید.
 
-It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+بسیار مهم است که رفتاری عادی در قبال فعالیت‌های تجاری داشت؛ درست رفتاری مانند فعالیت‌های توسعه‌ای در پروژه‌های دیگر. البته نباید برخورد خاص و رفتار ویژه‌ای با توسعه‌دهندگانی که به آن‌ها پول داده می‌شود در برابر آن‌هایی که بدون دریافت پول به کارشان مشغول هستند، قائل شد. هر یک از مشارکت‌ها باید بر اساس شایستگی‌های فنی ارزیابی شود. با این حال، افرادی که مشغول به فعالیت‌های تجاری هستند، باید احساس راحتی داشته باشند و هنگام بحث و گفتگو در مورد پیشرفت یا ویژگی خاصی، در بیان موارد کاربردی و کارهایی که قبلا داشتند، باید احساس راحتی کنند.
 
-"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+پروژه‌های «تجاری» هیچ فرقی با پروژه‌های «متن باز» ندارند. «تجاری» فقط به این معنی است که پول هم در کار است؛ به این معنی که نرم افزاری که در تجارت مورد استفاده قرار می‌گیرد، نرم‌افزاری در پروژه بوده است که در فعالیت تجاری پذیرفته شده است. (هنگامی که از یک نرم‌افزار «متن باز» به عنوان بخشی سازنده از محصولی «غیر متن باز» استفاده می‌شود، محصول نهایی همچنان نرم‌افزاری «دارای حقوق انحصاری» است، هرچند مانند «متن باز» ممکن است برای اهداف تجاری یا غیر تجاری استفاده شود.)
 
-Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+مانند هر کس دیگری، توسعه‌دهندگانی که انگیزه‌های تجاری دارند از طریق کیفیت و کمیت مشارکت‌های خودشان است که در پروژه اهمیت می‌یابند و تاثیرگذار می‌شوند. بدیهی است که توسعه‌دهنده‌ای که برای کاری که می‌کند حقوق می‌گیرد، احتمالا بیشتر از شخصی که حقوق نمی‌گیرد، توانایی کار کردن دارد ولی اهمیتی ندارد: پرداخت حقوق فقط یکی از بسیار عامل‌های احتمالی است که می‌تواند بر میزان کاری که شخص می‌کند، تأثیر بگذارد. مشارکت‌ها رو معطوف به بحث‌های مربوط به پروژه بکنید، و نه معطوف به موضوعاتی خارج از پروژه.
 
-## Do I need a legal entity to support my project?
+## آیا برای حمایت و پشتیبانی از پروژه‌ی خود به نهاد قانونی نیاز خواهم داشت؟
 
-You don't need a legal entity to support your open source project unless you're handling money.
+شما برای پشتیبانی از پروژه‌ی متن باز خود احتیاج به نهاد قانونی نخواهید داشت، مگر اینکه با پول سر و کار داشته باشید.
 
-For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+به عنوان مثال، اگر می‌خواهید کسب و کاری ایجاد کنید، باید از طریق «C Corp» یا «LLC» (اگر در ایالات متحده مستقر هستید) اقدام کنید. اگر فقط کارهای پیمانکاری مربوط به پروژه متن باز خود را انجام می‌دهید، می‌توانید به عنوان یک مالک شخصی پول را بپذیرید یا یک «LLC» (اگر در ایالات متحده مستقر هستید) ایجاد کنید.
 
-If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+اگر می‌خواهید کمک‌های مالی برای پروژه‌ی متن باز خود بپذیرید، می‌توانید بستری را برای کمک‌های مالی (مثلاً با استفاده از PayPal یا Stripe) ایجاد کنید، اما این مبلغ مشمول کسر مالیت می‌شود، مگر اینکه به عنوان یک سازمان غیرانتفاعی واجد شرایط باشید (اگر در ایالات متحده مستقر هستید).
 
-Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+بسیاری از پروژه‌ها مایل به پذیرفتن مشکلات ناشی از ایجاد سازمانی غیرانتفاعی نیستند، بنابراین در عوض یک حامی مالی غیرانتفاعی پیدا می‌کنند. یک حامی مالی، معمولاً در ازای درصدی از کمک مالی، کمک‌های مالی را از طرف شما قبول می‌کند. [Software Freedom Conservancy](https://sfconservancy.org/)،[Apache Foundation](https://www.apache.org/) ،[Eclipse Foundation](https://eclipse.org/org/foundation/) ، [Linux Foundation](https://www.linuxfoundation.org/projects) و [Open Collective](https://opencollective.com/opensource)، نمونه‌هایی از سازمان‌ها هستند که به عنوان حامی‌های مالی در پروژه‌های متن باز فعالیت می‌کنند
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
-  Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+  هدف ما فراهم آوردن زیرساختی است که اجتماع‌هامان (communities) بتوانند از آن برای پایداری خود استفاده کنند، بنابراین محیطی ایجاد می‌کنیم که همه - مشارکت‌کنندگان، پشتیبانان، حامیان مالی - از مزایای آن بهره‌مند شوند
   <p markdown="1" class="pquote-credit">
 — @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
   </p>
 </aside>
 
-If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
+اگر پروژه‌ی شما رابطه‌ی نزدیکی با زبان یا اکوسیستم خاصی داشته باشد، ممکن است پیش‌زمینه‌ی نرم‌افزاری مرتبط با آن وجود داشته باشد که بتوانید با آن کار کنید. به عنوان مثال، [Python Software Foundation](https://www.python.org/psf/) از [PyPI](https://pypi.org/) پشتیبانی می‌کند، [Python package manager](https://www.python.org/psf/) و [Node.js Foundation](https://foundation.nodejs.org/) به [Express.js](https://expressjs.com/)، که مبتنی بر Node است، کمک می‌کند.
\ No newline at end of file

From 46d5e6a6563bd362f2e5c6505596594004013974 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Wed, 5 May 2021 14:49:31 +0430
Subject: [PATCH 158/749] Initial translation done.

---
 _articles/fa/starting-a-project.md | 275 ++++++++++++++---------------
 1 file changed, 137 insertions(+), 138 deletions(-)

diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md
index 1ace069082f..bc6c3717201 100644
--- a/_articles/fa/starting-a-project.md
+++ b/_articles/fa/starting-a-project.md
@@ -1,14 +1,8 @@
 ---
-lang: en
-title: Starting an Open Source Project
-description: Learn more about the world of open source and get ready to launch your own project.
+lang: fa
+title: شروع یک پروژه‌ی متن باز / منبع باز / اوپن سورس
+description: در این مقاله چیزهای زیادی درباره‌ی دنیای متن بازها می‌آموزید و آماده‌ی انتشار پروژه‌ی متن باز خودتان می‌شوید.
 class: beginners
-toc:
-  the-what-and-why-of-open-source: "The what and why of open source"
-  should-i-launch-my-own-open-source-project: "Should I launch my own open source project?"
-  launching-your-own-open-source-project: "Launching your own open source project"
-  naming-and-branding-your-project: "Naming and branding your project"
-  your-pre-launch-checklist: "Your pre-launch checklist"
 order: 2
 image: /assets/images/cards/beginner.png
 related:
@@ -16,296 +10,300 @@ related:
   - building
 ---
 
-## The "what" and "why" of open source
+## چیستی و چرایی متن باز
 
-So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+اگر در حال فکر کردن این هستید که پروژه‌ی متن باز خودتان را شروع کنید؟ به شما تبریک می‌گوییم! دنیا قدردان کمک و مشارکت شماست. اجازه دهید در ادامه درباره پروژه‌های متن باز بیشتر صحبت کنیم و ببینیم چرا مردم پروژه‌هایشان را متن باز می‌کنند.
 
-### What does "open source" mean?
+### متن باز به چه معناست؟
 
-When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+زمانی که یک پروژه متن باز یا اوپن سورس باشد، **هر کسی می‌تواند و اجازه دارد به صورت رایگان آن را استفاده، مطالعه، ویرایش و برای هر هدفی که می‌خواهد، توزیع کند**. این اجازه‌ها در [لایسنس متن باز](https://opensource.org/licenses) قید شده و قابل اجراست
 
-Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+پروژه‌های متن باز قدرتمند هستند، چون موانعی که در اختیارات و مشارکت‌ها دیده می‌شود را کاهش و به افراد اجازه می‌دهد پروژه‌های خود را به سرعت گستردش و بهبود دهند. یکی دیگر از دلایل قدرتمند بودن متن بازها این است که پتانسیل کنترل محاسبه را بسته به منابع محدود به کاربران می‌دهد. اگر بخواهیم برای روشن شدن مطلب نمونه‌ای بیاوریم، می‌توانیم به کسب‌وکارهایی اشاره کنیم که به جای تکیه بر منابع محصور و محدود محصولات انحصاری فروشنده‌های نرم‌افزار، از نرم‌افزارهای متن بازی استفاده می‌کنند که به آن‌ها اجازه می‌دهد شخصی را استخدام کنند تا آن نرم‌افزار را برای آن‌ها شخصی‌سازی یا بهینه کند.
 
-_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+_نرم‌افزارهای رایگان_ همچنین به پروژه‌های متن باز منسوب می‌شود. گاهی هم ممکن است برنامه‌هایی ببینید که [ترکیبی](https://en.wikipedia.org/wiki/Free_and_open-source_software) از اصلاحات «نرم‌افزار متن باز و رایگان» (FOSS) یا «نرم‌افزار متن باز، آزاد و رایگان» (FLOSS) استفاده می‌کنند. خب، باید بگوییم که کلمه‌ی _Free_ (رایگان) و _libre_ (آزاد / رایگان) هر دو به معنای آزادی در استفاده و دسترسی اطلاق می‌شود، [نه قیمت آن](#does-open-source-mean-free-of-charge)
 
-### Why do people open source their work?
+### چرا مردم پروژه‌های‌شان را متن باز می‌کنند؟
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
-  One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+  یکی از رضایت‌بخش‌ترین تجربه‌هایی که از استفاده و مشارکت در پروژه‌های متن باز به دست آوردم، آشنایی با افراد و توسعه‌دهنده‌هایی بود که همان مشکلاتی را داشتند که من با آن‌ها مواجه شده بودم.
   <p markdown="1" class="pquote-credit">
 — @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
   </p>
 </aside>
 
-[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+[دلایل زیادی وجود دارد](https://ben.balter.com/2015/11/23/why-open-source/) که یک شخص یا سازمان بخواهد پروژه‌های خود را متن باز کند. این دلایل عبارتند از:
 
-* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+* **مشارکت:** هر فردی در دنیا می‌تواند پروژه‌های متن باز را تغییر دهد و در ویرایش آن مشارکت داشته باشد. به عنوان نمونه، Exercism که به عنوان یک پلتفرم متن باز برای تمرین برنامه‌نویسی شناخته می‌شود، با مشارکت افراد مختلف تا به الان بیش از 350 توزیع و ویرایش داشته است.
 
-* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **اقتباس و تغییر مجدد:** هر فردی تقریباً با هر هدفی می‌تواند از پروژه‌های متن باز استفاده کند. افراد حتی می‌توانند از یک پروژه، پروژه‌های دیگری به وجود بیاورند. به عنوان مثال می‌توانیم به [وردپرس](https://github.com/WordPress) اشاره کنیم که از پروژه موجودی به نام [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) منشعب شده است.
 
-* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+* **شفافیت:** هرکسی می‌تواند خطاها و تناقض پروژه‌های متن باز را بازرسی کند. از این رو، شفافیت برای دولت‌هایی مانند دولت [بلغارستان](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) یا [ایالات متحده آمریکا](https://sourcecode.cio.gov/) و صنایع مقرراتی مانند بانکداری، مراکز بهداشت وُ درمانی و نرم‌افزار امنیتی مانند [Let’s Encrypt](https://github.com/letsencrypt) اهمیت بالایی پیدا می‌کند تا زمان بازرسی خطاها توسط افراد مختلف، دچار مشکل نشوند.
 
-Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+ویژگی متن باز فقط مختص به نرم‌افزارها نیست، شما هر چیزی حتی مجموعه‌ای از داده‌های یک کتابخانه را می‌توانید متن باز کنید. اگر می‌خواهید بیشتر بدانید که چه چیزهای دیگری را می‌شود متن باز کرد، می‌توانید به [GitHub Explore](https://github.com/explore) مراجعه کنید.
 
-### Does open source mean "free of charge"?
+### آیا پروژ‌های متن باز «مجانی / رایگان» هستند؟
 
-One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+یکی از بزرگ‌ترین جذابیت‌های متن بازها این است که پولی نیستند. هرچند، رایگان بودن، یک محصول جانبی با ارزش کلی یک پروژه‌ی متن باز است.
 
-Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+به عبارت دیگر، [در لایسنس و گواهینامه‌ی پروژه‌های متن بازها آورده شده است](https://opensource.org/osd-annotated) که هر کسی می‌تواند آن‌ها را استفاده، ویرایش و تقریباً با هر هدفی به اشتراک بگذارد. از این رو، پروژه‌های متن باز به صورت رایگان عرضه می‌شوند و اگر هم استفاده‌ از این پروژه‌ها پولی شود، هر کسی به صورت قانونی می‌تواند از آن کپی بگیرد و درعوض، از نسخه‌ی رایگان آن استفاده کند
 
-As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+در نتیجه، بیشتر پروژه‌های متن باز به صورت رایگان ارائه می‌شوند و از طرفی هم «رایگان بودن / مجانی بودن» به عنوان بخشی از تعریف پروژه‌های متن باز به حساب نمی‌آید، یعنی پروژه‌های متن باز هم به صورت رایگان و هم به صورت پولی هستند. البته راههایی سازگار با مجوزهای متن باز مثل ارائه مجوز دوگانه یا محدودکردن ویژگی ها به دو دسته رایگان و پولی برای کسب درآمد غیرمستقیم از پروژه‌های متن باز وجود دارد.
 
-## Should I launch my own open source project?
+## آیا پروژه‌ی متن باز خودم را باید منتشر کنم؟
 
-The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+اگر بخواهیم کوتاه جواب بدهیم، بله. چون خروجی پروژه‌ی شما مهم نیست. مهم این است که پروژه‌تان منتشر شود و بهترین راه هم برای یاد گرفتن نحوه‌ی کار پروژه‌های متن باز انتشار آن‌هاست.
 
-If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+اگر هیچوقت پروژه‌ی متن بازتان را منتشر نکردید، ممکن است این نگرانی برای‌تان پیش بیاید افراد مختلف چه چیزی درباره‌ی پروژه‌تان می‌گویند یا اصلا به پروژه‌ی شما توجه می‌کنند یا خیر. اگر چنین احساسی دارید، باید بگوییم که تنها نیستید.
 
-Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+کار یک پروژه‌ی متن باز مانند هر فعالیت خلاقانه‌ی دیگری مثل نویسندگی و نقاشی است. زمانی که شما به عنوان یک هنرمند اولین اثر خود را با دنیا به اشتراک می‌گذارید، احساس ترس به سراغتان می‌آید. اما این کار را باید انجام دهید، چون تمرین تنها راه بهتر شدن است؛ حتی اگر یک مخاطب هم نداشته باشید.
 
-If you're not yet convinced, take a moment to think about what your goals might be.
 
-### Setting your goals
+اگر هنوز هم متقاعد نشدید، به این فکر کنید که اهداف‌تان چه چیزهایی می‌توانند باشند.
 
-Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself,  _why am I open sourcing this project?_
+### اهداف‌تان را مشخص کنید
 
-There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+اهداف می‌تواند به شما کمک کند تا متوجه شوید که بر روی چه چیزی کار کنید، به چه چیزی نه بگویید و کجا به کمک دیگران نیاز دارید. با سوال کردن از خودتان شروع کنید. از خودتان بپرسید: _چرا می‌خواهم این پروژه را متن باز کنم؟_
 
-If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+خب، واضح است که هیچ کس جواب درستی برای این سوال ندارد. چون ممکن است چندین هدف برای یک پروژه یا پروژه‌های مختلفی با اهداف متفاوتی وجود داشته باشد.
+
+اگر نمایش دادن کارتان تنها هدف برای متن باز کردن پروژه‌تان باشد، احتمالاً مشارکت دیگران را نمی‌خواهید و این نخواستن مشارکت را هم در فایل README پروژه‌تان نیز می‌آورید. از طرف دیگر، اگر واقعاً مشارکت دیگران را بخواهید، زمان خود را صرف مرتب کردن اسناد و صرف خوشامدگویی به افرادی می‌کنید که تازه وارد این حوزه شدند.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
-  At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+  زمانی که پروژه‌ی UIAlertView شخصی را تولید و استفاده کردم ....  و تصمیم گرفتم آن را متن باز کنم، تغییراتی در آن اعمال کردم تا پویایی بیشتری داشته باشد و آن را در GitHub آپلود کردم. من همچنین اولین سندی (که توضیح پروژه در آن نوشته می‌شود) را برای سایر توسعه‌دهنده‌ها نوشتم که نحوه‌ی کار با پروژه‌ی من چگونه است. احتمالاً به خاطر اینکه پروژه‌ی ساده‌ی بود، هیچ‌کس از آن استفاده نکرد. هرچند، اما به خاطر مشارکتم به سایر توسعه‌دهنده‌ها احساس خوبی داشتم.
   <p markdown="1" class="pquote-credit">
 — @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
   </p>
 </aside>
 
-As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+وقتی که پروژه‌ی شما رشد می‌کند، جامعه‌ی مخاطب پروژه‌هایتان احتمالاً بیشتر از یک کد به شما نیاز خواهند داشت. وظایف مهمی که در یک پروژه‌ی متن باز به شما محول می‌شود این است که برای مشکلات پاسخی داشته باشید، کدها را بررسی کنید و مژده‌ی پروژه‌ی متن بازتان را به دیگران بدهید.
+
+اگرچه مدت زمانی که صرف کارهای غیرکدنویسی می‌کنید، به اندازه و دامنه‌ی پروژه‌یتان بستگی دارد، اما به عنوان یک مسئول‌نگهداری پروژه باید خودتان را آماده کنید آن‌ها را انجام دهید یا حداقل شخصی را پیدا کنید که در کارهای غیرکدنویسی به شما کمک کند.
 
-While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
 
-**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+**اگر جزئی از یک پروژه‌ی متن باز یک شرکت هستید،** مطمئن شوید پروژه‌یتان منابع لازم داخلی برای پیشرفت را داشته باشد. از این رو، باید بدانید که چه کسی مسئول نگهداری پروژه‌ی متن بازتان است و چگونه می‌خواهید این وظایف را با جامعه‌ی خود به اشتراک بگذارید
 
-If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+اگر برای ارتقاء، بهره‌برداری و نگهداری پروژه به بودجه خاص یا کارمند نیاز دارید، می‌توانید این نیازها را در ابتدا اعلام کنید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-  As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+  زمانی که پروژه‌ی متن بازتان را شروع می‌کنید، مهم است که اطمینان حاصل کنید که فرآیندهای مدیریتی شما ظرفیت مشارکت‌ها و توانایی‌های جامعه‌ی پیرامونی و مخاطب پروژه‌تان را در برگیرد. از مشارکت دادن مشارکت‌کننده‌هایی نترسید که از جنبه‌های کلیدی پروژه کارمند کسب و کارتان نیستند، به خصوص اگر مشارکت آن‌ها با شما مکرر باشد.
   <p markdown="1" class="pquote-credit">
 — @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
   </p>
 </aside>
 
-### Contributing to other projects
+### مشارکت در سایر پروژه‌ها
 
-If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+اگر هدف‌تان این باشد که با دیگران در پروژه‌های متن باز همکاری کنید یا می‌خواهید نحوه‌ی عملکرد یک پروژ‌ه‌ی متن باز را درک کنید، همکاری و مشارکت با پروژه‌های موجود را در نظر بگیرید. با پروژه‌ای شروع کنید که قبلا به آن علاقه‌مند بودید و از آن استفاده می‌کردید. مشارکت در یک پروژه‌ی متن باز می‌تواند به سادگی اصلاح یک کد اشتباه یا آپدیت / به‌روزرسانی اسناد باشد.
 
-If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+اگر مطمئن نیستید که چگونه می‌توانید در سایر پروژه‌ها مشارکت کنید، به مقاله‌ی [راهنمای نحوه‌ی همکاری در پروژه‌ی متن باز](../how-to-contribute/) مراجعه کنید
 
-## Launching your own open source project
+## انتشار پروژه‌ی متن باز خودتان
 
-There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+زمان مناسبی برای متن باز کردن پروژه‌تان وجود ندارد. از این رو، می‌توانید یک ایده، کارهایی در دست اقدام یا پروژه‌هایی که بعد از سال‌ها بسته ماندند، را متن باز کنید.
 
-Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+به طور کلی، هر زمان که احساس کردید با دیدگاه‌ها و بازخوردهای دیگران راحت هستید، باید پروژه‌یتان را متن باز کنید.
 
-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)
+* [لایسنس متن باز](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)
 * [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change)
-* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
-* [Code of conduct](../code-of-conduct/)
+* [راهنمای مشارکت](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [آیین نامه رفتار](../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.
+اگر پروژه‌ی شما در GitHub قرار دارد، قرار دادن فایل‌های فوق به همراه نام فایل‌های توصیه‌شده در پوشه ریشه (root) می‌تواند به GitHub کمک کند تا آن‌ها را به صورت خودکار به مخاطبان‌تان شناسایی کند و نمایش دهد.
 
-If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+### انتخاب لایسنس یا مجوز
 
-### Choosing a license
+لایسنسِ یا مجوز یک پروژه‌ی متن باز به دیگران ضمانت می‌دهد از پروژه‌ی متن باز استفاده، کپی، ویرایش و بدون هیچ عواقبی در آن مشارکت کنند. لایسنس همچنین از شما در برابر موقعیت‌های سخت قانونی محافظت می‌کند. **زمانی که می‌خواهید پروژه‌ی متن بازتان را منتشر کنید، حتما لایسنس آن را هم ضمیمه کنید**.
 
-An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+کارهای ادارای و حقوقی برای گرفتن لایسنس هیچ جذابیتی ندارد، اما خبر خوب اینجاست که می‌توانید لایسنس‌های موجود و در دسترس را که از قبل توسط دیگران تدوین شده را در repository (مخزن) خود کپی و پیست کنید. برای محافظت از تلاشی که برای متن باز کردن پروژه‌تان انجام دادید، این کار تنها یک دقیقه وقت شما را می‌گیرد.
 
-Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+[MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) و [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) جزء محبوب‌ترین لایسنس‌های متن باز هستند. هرچند، لایسنس‌های دیگری هم وجود دارد که می‌توانید از آن‌ها استفاده کنید.
 
-[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 the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+زمانی که پروژه‌ی جدیدی در GitHub ایجاد می‌کنید، به شما امکان انتخاب لایسنس داده می‌شود. انتخاب کردن لایسنس باعث می‌شود GitHub پروژه‌ی شما را متن باز نشان دهد.
 
-When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+![انتخاب مجوز](/assets/images/starting-a-project/repository-license-picker.png)
 
-![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+در ادامه‌ی مقاله، سایر سوالات و نگرانی‌هایتان درباره‌ی [جنبه‌های قانونی](../legal/) مدیریت پروژه‌ی متن بازتان را بررسی خواهیم کرد.
 
-If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+### نوشتن فایل «README» (فایلی که توضیحات پروژه در آن آورده می‌شود)
 
-### Writing a README
+فایل README اطلاعات بیشتری نسبت به این دارد که نحوه‌ی استفاده از پروژه‌تان را به کاربر توضیح دهد. این فایل همچنین توضیح می‌دهد که پروژه‌ی شما چه اهمیتی دارد و کاربران‌تان با این پروژه چه کارهای می‌توانند انجام دهند.
 
-READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+سعی کنید در فایل README خودتان به سوالات زیر پاسخ دهید و جواب آن‌ها را در فایل بیاورید:
 
-In your README, try to answer the following questions:
+* پروژه‌ی شما چه کاری انجام می‌دهد؟
+* چرا این پروژه مفید است؟
+* چگونه شروع کردم؟
+* در صورت نیاز، از کجا می‌توانم کمک بیشتری دریافت کنم؟
 
-* What does this project do?
-* Why is this project useful?
-* How do I get started?
-* Where can I get more help, if I need it?
 
-You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+شما با فایل README می‌توانید به سایر سوالات نیز پاسخ دهید؛ سوالاتی مانند اینکه چگونه مشارکت‌تان را مدیریت می‌کنید، اهداف پروژه‌تان چیست و اطلاعات لایسنس و اختیارات پروژه‌تان را هم می‌توانید بیاورید. اگر مشارکت کسی را نمی‌خواهید قبول کنید، یا پروژه‌ی شما هنوز برای ارائه آماده نشده باشد، می‌توانید این توضیحات را در فایل README بیاورید
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
-  Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+  هرچه اسنادتان اعم از فایل README، راهنمای مشارکت، آیین نامه رفتار و لایسنس در پروژه‌ی متن باز شما بهتر باشد، کاربران بیشتری به شما جذب می‌شود، پشتیبانی کمتری درخواست می‌شود و مشارکت‌کننده‌های بیشتری در پروژه مشارکت می‌کنند. به یاد داشته باشید که مخاطبانتان جای شما نیستند و افرادی ممکن است وارد پروژه‌ی شما شوند که تجربه‌های کاملاً متفاوتی دارند.
   <p markdown="1" class="pquote-credit">
 — @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
   </p>
 </aside>
 
-Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+بعضی از افراد از نوشتن فایل README خودداری می‌کنند، چون فکر می‌کنند پروژه‌ی آن‌ها هنوز تکمیل نشده یا اینکه نمی‌خواهند کسی مشارکتی داشته باشد. همین‌ها دلایل خیلی خوبی برای نوشتن یک فایل README محسوب می‌شوند.
 
-For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+برای نوشتن یک فایل README کامل، می‌توانید به مقالات @dguo’s ["Make a README" guide](https://www.makeareadme.com/) یا @PurpleBooth’s [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) مراجعه کنید و از آن‌ها الهام بگیرید
 
-When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+زمانی که فایل README را در دایرکتوری ریشه خود قرار می‌دهید، GitHub به صورت خودکار آن را در صفحه‌ی اصلی repository (انبار) نشان می‌دهد.
 
-### Writing your contributing guidelines
+### نوشتن راهنمای مشارکت
 
-A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+فایل CONTRIBUTING (مشارکت) به مخاطبان‌تان می‌گوید که چگونه در پروژه‌ی شما مشارکت کنند. به عنوان مثال، می‌توانید اطلاعات زیر را در آن قید کنید:
 
-* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
-* How to suggest a new feature
-* How to set up your environment and run tests
+* چگونه یک باگ یا مشکل گزارش شود
+* چگونه ویژگی جدیدی پیشنهاد دهند
+* چگونه محیط پروژه‌تان را تنظیم و آن را برای تست اجرا کنند
 
-In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
 
-* The types of contributions you're looking for
-* Your roadmap or vision for the project
-* How contributors should (or should not) get in touch with you
+به علاوه، در فایل CONTRIBUTING می‌توانید جزئیات فنی و انتظارات‌تان را برای مشارکت‌کننده‌ها بیان کنید. به عنوان مثال:
 
-Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+* نوع مشارکتی که به دنبال آن هستید
+* نقشه‌ی راه یا دیدگاهی که به پروژه دارید
+* چگونه مشارکت‌کننده‌ها باید (یا نباید) با شما در تماس باشند
 
-For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+زمانی که با خونگرمی، حس دوستانه و دادن پیشنهادهای خاص (مانند نوشتن اسناد، یا طراحی وب‌سایت) با  مشارکت‌کننده‌هایتان برخورد می‌کنید، بیشتر راه را برای استقبال از تازه‌واردها رفته‌اید و همین کار شما باعث می‌شود آن‌ها برای همکاری با شما هیجان‌زده شوند.
 
-> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+برای روشن شدن مطلب اجازه دهید نمونه‌ای بیاوریم. به عنوان مثال، [Active Admin](https://github.com/activeadmin/activeadmin/) [راهنمای مشارکت خود](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) به مشارکت‌کننده‌ها را اینگونه شروع می‌کند
 
-In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+> در ابتدا، از شما ممنون هستم که می‌خواهید با Active Admin مشارکت کنید. افرادی مثل شما هستند که باعث می‌شوند Active Admin عملکرد خوبی داشته باشد.
 
-Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+در ابتدایی‌ترین مرحله‌ی پروژه‌تان، فایل CONTRIBUTING می‌تواند ساده باشد. شما در این فایل همیشه باید نحوه‌ی گزارش دادن باگ‌ها (خطاها) یا مشکلات فایل و هر نیاز فنی مانند تست کردن را برای مشارکت‌کننده‌ها توضیح دهید.
 
-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/).
+در طول زمان، ممکن است اطلاعات و سوالات مکرر زیادی به فایل 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.
+برای اینکه بدانید چگونه اطلاعات فایل 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 guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+[لینک فایل CONTRIBUTING خود را در فایل README قرار دهید](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) تا افرادی که آن را مطالعه می‌کنند این فایل مشارکت را هم ببینند. اگر فایل CONTRIBUTING خود را در repository (انبار) (مخزن) پروژه‌تان قرار داده باشید، زمانی که یک مشارکت‌کننده طرح مشکل یا گزارش یک باگ یا درخواست ادغام کند، GitHub به صورت خودکار او را به لینک فایل CONTRIBUTING هدایت می‌کند
 
-### Establishing a code of conduct
+![راهنماهای مشارکت](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+
+### تعیین آیین نامه‌ی رفتاری (Code of Conduct)
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
-  We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+  همه‌ی ما به عنوان یک مسئول‌نگهداری پروژه با سوءاستفاده‌هایی مواجه شده‌ایم که در آن سعی می‌کردیم توضیح دهیم چرا چیزی را باید از مسیر خاص خودش طی کنیم، یا به عنوان یک کاربر تلاش می‌کردیم یک سوال ساده بپرسیم. آیین نامه‌ی رفتاری به سندی قابل ارجاع و پیوندی تبدیل شده که نشان می‌دهد تیم شما اجرای گفتمان سازنده را بسیار جدی می‌گیرد.
   <p markdown="1" class="pquote-credit">
 — @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
   </p>
 </aside>
 
-Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+بالاخره، آیین نامه‌ی رفتاری به ما کمک می‌کند برای رفتارهای مشارکت‌کننده‌های پروژه‌تان قوائدی تعیین کنید. زمانی که بخواهید یک پروژه‌ی متن بازی را برای انجمن یا یک شرکت منتشر کنید، این قوائد می‌تواند ارزشمند باشد. آیین نامه‌ی رفتاری یا (Code of Conduct) این قدرت را به شما می‌دهد تا رفتارهای سازنده و سالم  را در بین جامعه کاربران ترویج کنید که در آینده به عنوان یک مسئول‌نگهداری پروژه احساس استرس کمتری داشته باشید.
 
-For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+برای اطلاعات بیشتر می‌توانید به [راهنمای آیین نامه‌ی رفتاری](../code-of-conduct/) مراجعه کنید.
 
-In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+علاوه بر اینکه یک آیین نامه‌ی رفتاری رفتارهایی که از شرکت‌کنند‌هایتان انتظار دارید را باید به آن‌ها بگوید، این را هم باید تعریف کنید که اجرای این انتظارات به چه کسانی و در چه زمان‌هایی باید انجام می‌شود. آیین نامه‌ی رفتاری همچنین مشخص می‌کند که درصورت بروز تخلف چه کاری باید انجام شود.
 
-Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+مشابه استفاده از مجوزهایی که از قبل توسط دیگران تدوین شده استانداردهای نوظهوری برای آیین نامه‌ی رفتاری وجود دارد که لازم نیست خودتان آن را بنویسید. (https://contributor-covenant.org/)[Contributor Covenant] یکی از جاهایی است که آیین نامه‌هایی در همین خصوص ارائه می‌کند و حاصل کار آن در [بیش از 40.000 پروژه‌ی متن باز](https://www.contributor-covenant.org/adopters) مانند Kubernetes، Rails و Swift استفاده می‌شود. مهم نیست متن آیین نامه‌ی رفتاری شما چیست، مهم این است که در صورت لزوم باید از آیین نامه‌ی رفتاری خودتان استفاده کنید
 
-Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+متن آیین نامه‌ی رفتاری خود را مستقیما در فایل CODE_OF_CONDUCT در repository (مخزن) گیت هاب خودتان کپی و پیست کنید. فایل را در دایرکتوری روت پروژه‌تان ذخیره کنید تا پیدا کردن و لینک دادن آن به فایل README راحت باشد.
 
-## Naming and branding your project
+## نام‌گذاری و برندسازی پروژه
 
-Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+برندسازی چیزی فراتر از یک لوگوی پُر زرق وُ برق یا یک نام جذاب برای پروژه‌تان است. برندسازی نحوه‌ی صبحت کردن درباره‌ی پروژه و نحوه رساندن پیام به مخاطب‌تان را نشان می‌دهد.
 
-### Choosing the right name
+### انتخاب نام درست
 
-Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+برای پروژه‌تان از نامی استفاده کنید که یادآوری آن ساده باشد. به طور ایده آل، می‌توانید بعضی از ایده‌ها را از پروژه‌های زیر مشاهده کنید. به عنوان نمونه:
 
-* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
-* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+* [Sentry](https://github.com/getsentry/sentry) اپ ها را با هدف گزارش خطاهای رخ داده در آنها پایش می کند
+* [Thin](https://github.com/macournoyer/thin) یک وب سرور ساده و سریع روبی است
 
-If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+اگر در حال طراحی پروژه‌تان هستید، به کارگیری نام آن‌ها به عنوان پیشوند می‌تواند به شفاف کردن پروژه‌تان کمک کند. به عنوان نمونه، ([node-fetch](https://github.com/bitinn/node-fetch)، Window.fetch را به Node.js می‌آورد).
 
-Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+با در نظر گرفتن توصیه بالا. می‌توان عناوین بامزه یا خوب زیادی ساخت، اما این را به یاد داشته باشید که بعضی از بازی با کلمات و جناس‌ها ممکن است در سایر فرهنگ‌ها یا افرادی که تجربه‌های متفاوتی نسبت به شما دارند، مفهوم یا ترجمه‌ی نادرستی داشته باشد. برخی از کاربران بالقوه شما هم ممکن است کارمندان یک شرکت باشند و حتما نمی‌خواهید زمانی که در حال توضیح دادن نحوه‌ی پروژه‌تان در محل کارشان هستند، احساس نامساعدی داشته باشند.
 
-### Avoiding name conflicts
+### از نام‌گذاری‌های دارای منافات خودداری کنید
 
-[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+اگر پروژه‌ی شما زبان و اکوسیستم یکسانی دارد، می‌توانید نام پروژه‌های مشابه با پروژه‌تان را [بررسی کنید](http://ivantomic.com/projects/ospnc/). اگر نام پروژه‌ی شما با پروژه‌ی دیگری شباهت زیادی داشته باشد، مخاطب شما ممکن است سردرگم شود.
 
-If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+اگر با یک وب‌سایت، توئیتر یا دیگر شبکه‌های اجتماعی می‌خواهید پروژه‌تان را نشان دهید، مطمئن شوید همان نامی را انتخاب کنید که می‌خواهید. به طور ایده آل، حتی اگر هنوز نمی‌‌خواهید از آن نام استفاده کنید و برای اینکه خیال‌تان راحت باشد، آن نام را [وارونه کنید](https://instantdomainsearch.com/)
 
-Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+مطمئن شوید نام پروژه‌ی شما هیچ برند تجاری را نقض نمی‌کند. اگر چنین باشد، آن شرکت می‌تواند بعدها از شما درخواست کند پروژه‌تان را کنسل کرده یا حتی به صورت قانونی با شما برخورد کند. بنابراین، ارزش این همه ریسک را ندارد و برای جلوگیری از چنین مشکلاتی حتما از نام مناسبی استفاده کنید.
 
-You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+برای بررسی تضاد و منافات برندهای تجاری می‌توانید به پایگاه داده برندهای جهانی [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) مراجعه کنید. اگر شما یک شخص حقوقی هستید و در یک شرکت فعالیت می‌کنید، این یکی از چیزهایی است که [تیم حقوقی‌تان می‌تواند](../legal/) به شما کمک کند
 
-Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+در نهایت، نام پروژه‌تان را به سرعت در گوگل جستجو کنید. ببینید که افراد به راحتی می‌توانند پروژه‌تان را پیدا کنند؟ در نتایج جستجوی شما چیزی دیگر پیدا می‌شود که نمی‌خواهید کاربران آن را مشاهده کنند؟
 
-### How you write (and code) affects your brand, too!
+### چگونه نوشتن و کدنویسی شما روی برندتان اثر می‌گذارد!
 
-Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+در طول عمر پروژه‌تان، در حال نوشتن چیزهای زیادی خواهید بود که می‌توان به نوشتن فایل‌های README، آموزش‌ها، اسناد انجمن، نوشتن پاسخ به مشکلات، حتی شاید نوشتن و پاسخ دادن به خبرنامه و فهرست پستی، اشاره کرد.
 
-Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+سبک نویسندگی شما چه در اسناد رسمی و چه در ایمیل‌های محاوره‌ای بخشی از برند پروژه‌تان است. به این فکر کنید چگونه می‌خواهید با مخاطب‌تان برخورد کنید و ببینید این لحن نوشتاری همان چیزی است که می‌خواهید به مخاطب فرستاده شود یا خیر.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+  زمان ارسال هر پست، تلاش می‌کردم رفتار ستوده‌ای داشته باشم، با مردم درست رفتار کنم، مشکلات‌شان را جدی بگیرم و در کل سعی می‌کردم مفید باشم. بعد از مدتی، افراد نه تنها سوال می‌پرسیدند، بلکه در جواب دادن در برخی سوالات به من کمک می‌کردند و در نهایت لذت آن‌ها از سبک نویسندگی من تقلید می‌کردند
   <p markdown="1" class="pquote-credit">
 — @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
-Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+زمانی که از یک زبان جامع و گرم استفاده می‌کنید و حتی زمانی که با یک فرد صحبت می‌کنید، به جای کلمه‌ی «تو» کلمه‌ی «شما» را به کار می‌برید، کمک زیادی به شما می‌کند تا مشارکت‌کننده‌های جدید از پروژه‌ی شما استقبال کنند. اگر می‌خواهید به زبان انگلیسی بنویسید، سعی کنید ساده باشد. چون زبان بیشتر خواننده‌های شما بومی نیست.
 
-Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+جدا از کلماتی که در نوشتن اسناد مختلف استفاده می‌کنید، سبک کدنویسی شما هم ممکن است به بخشی از برند پروژه‌تان تبدیل شود. به عنوان مثال می‌توانیم به دو نمونه پروژه به نام‌های [Angular](https://angular.io/guide/styleguide) و [jQuery](https://contribute.jquery.org/style-guide/js/) اشاره کنیم که راهنما و سبک کدنویسی سختی دارند
 
-It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+در ابتدای کار لازم نیست از راهنمای سبک نویسندگی استفاده کنید. به هر حال، به مرور از ترکیب سبک متفاوت کدنویسی خود در پروژه‌تان لذت خواهید برد. هرچند، این را باید پیش‌بینی کنید که نحوه‌ی نویسندگی و سبک کدنویسی شما ممکن است انواع مختلف افراد را جذب یا دفع کند. در ابتدای‌ترین مرحله‌ی پروژه‌تان فرصت دارید مقدماتی که می‌خواهید مخاطبان ببنند را ارائه دهید.
 
-## 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.
+خب، آماده هستید تا پروژه‌تان را متن باز کنید؟ چک لیست در این مرحله می‌تواند به شما کمک کند. تمام گزینه‌ها و تیک‌ها را بررسی کرده‌اید؟ به محض آماده شدن، روی انتشار [publish](https://help.github.com/articles/making-a-private-repository-public/) کلیک کنید و به خودتان تبریک بگویید.
 
-**Documentation**
+**مستندات**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-    Project has a LICENSE file with an open source license
+    پروژه حاوی فایل (LICENSE) و لایسنس متن باز است
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+    پروژه حاوی اسناد پایه اعم از (فایل README، CONTRIBUTING و فایل CODE_OF_CONDUCT) است
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+    نام پروژه ساده است، می‌توان آن را به راحتی به خاطر سپرد، نام پروژه این ایده را به مخاطب می‌دهد که پروژه چه کارهایی انجام می‌دهد و نام پروژه با هیچ پروژه موجودی منافات ندارد یا هیچ برند تجاری را نقض نمی‌کند.
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-    The issue queue is up-to-date, with issues clearly organized and labeled
+    صف مشکلات و مسائل گزارش شده با زدن برچسب های مناسب سازماندهی شده و بروز است.
   </label>
 </div>
 
-**Code**
+**کد**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    Project uses consistent code conventions and clear function/method/variable names
+    پروژه از توافق‌های از پیش تعیین شده در خصوص نام‌های متغیر/متدها و توابع استفاده می‌کند
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    The code is clearly commented, documenting intentions and edge cases
+	کد به خوبی کامنت‌گذاری شده و تو رفتگی‌ها و کوچکی و بزرگی حروف در جای لازم رعایت شده است.    
   </label>
 </div>
 
@@ -313,50 +311,51 @@ Ready to open source your project? Here's a checklist to help. Check all the box
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
     There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+	اطلاعات حساسی مثل کلمه های عبور یا کلیدهای خصوصی از طریق Pull Request یا گزارش مشکل و... برای عموم آشکار نشود
   </label>
 </div>
 
-**People**
+**افراد**
 
-If you're an individual:
+اگر شما شخص حقیقی هستید:
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  (اگر در جایی کارمند هستید)، با دپارتمان / بخش حقوقی خود صحبت کرده‌اید، IP و شرایط و قوانین متن باز شرکت را متوجه شده‌اید.
   </label>
 </div>
 
-If you're a company or organization:
+اگر شخص حقوقی هستید و در یک سازمان یا یک شرکت فعالیت می‌کنید:
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    You've talked to your legal department
+    با دپارتمان / بخش حقوقی صحبت کرده‌اید.
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    You have a marketing plan for announcing and promoting the project
+    برای اطلاع رسانی و ترویج پروژه‌ام برنامه‌ی بازاریابی دارم.
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
-  </label>
+	یک شخص برای مدیریت تعاملات اجتماعی (پاسخ به مشکلات، بررسی و درخواست ادغام) که متعهد باشد حضور دارد.
+    </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    At least two people have administrative access to the project
+    حداقل دو نفر دسترسی مدیریتی (Admin) به پروژه داشته باشند
   </label>
 </div>
 
-## You did it!
+## انجامش دادی!
 
-Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.
+اولین پروژه‌ی متن بازتان را تبریک می‌گوییم. بهتر است بدانید که خروجی آن مهم نیست، فقط با این کار تجربه‌ی کار در فضای جامعه را به دست آوردید. با هر کامیت (Commit)، کامنت (Comment) و پاسخ به درخواست ادغام فرصتی برای رشد و یادگیری خود و دیگران ایجاد می‌کنید.

From 92fdd15c23425f7b79c453eb6a38103607af882e Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 6 May 2021 08:52:32 +0000
Subject: [PATCH 159/749] Bump rexml from 3.2.4 to 3.2.5

Bumps [rexml](https://github.com/ruby/rexml) from 3.2.4 to 3.2.5.
- [Release notes](https://github.com/ruby/rexml/releases)
- [Changelog](https://github.com/ruby/rexml/blob/master/NEWS.md)
- [Commits](https://github.com/ruby/rexml/compare/v3.2.4...v3.2.5)

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 86995d3742f..33561394aab 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -238,7 +238,7 @@ GEM
     rb-fsevent (0.10.4)
     rb-inotify (0.10.1)
       ffi (~> 1.0)
-    rexml (3.2.4)
+    rexml (3.2.5)
     rouge (3.26.0)
     ruby-enum (0.9.0)
       i18n

From b489b3592cf3a35683bef3e356d18e57ad22d95a Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Fri, 7 May 2021 15:31:34 +0430
Subject: [PATCH 160/749] Initial translation done.

---
 _articles/fa/building-community.md | 228 ++++++++++++++---------------
 1 file changed, 114 insertions(+), 114 deletions(-)

diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md
index a86c8b26c55..906428112c8 100644
--- a/_articles/fa/building-community.md
+++ b/_articles/fa/building-community.md
@@ -1,12 +1,8 @@
 ---
-lang: en
-title: Building Welcoming Communities
-description: Building a community that encourages people to use, contribute to, and evangelize your project.
+lang: fa
+title: ساخت انجمن های پذیرا
+description: ساخت یک انجمن که افراد را به استفاده کردن ، به اشتراک گذاری و تبلیغ کردن پروژه تان ترغیب کند.
 class: building
-toc:
-  setting-your-project-up-for-success: "Setting your project up for success"
-  growing-your-community: "Growing your community"
-  resolving-conflicts: "Resolving conflicts"
 order: 4
 image: /assets/images/cards/building.png
 related:
@@ -14,267 +10,271 @@ related:
   - coc
 ---
 
-## Setting your project up for success
+## پروژه تان  را برای موفقیت راه اندازی کنید
 
-You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around?
+وقتی شما پروژه خود را راه اندازی کنید، مطالبی را پخش می کنید و افراد در حال بررسی آنها هستند. حالا سوال اینجا است که چطور باید از آنها بخواهید که در انتظار مطالب‌تان باشند؟
 
-A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back.
+یک انجمن پذیرا ، یک نوع سرمایه گذاری برای شهرت و آینده پروژه تان است. اگر پروژه تان در حال آغاز کسب مشارکتهای اولیه اش است، با اعطای یک تجربه مثبت به مشارکت کننده های اولیه شروع کنید، و برای آنها به عقب برگشتن را ساده سازید
 
-### Make people feel welcome
 
-One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+### کاری کنید تا افراد احساس پذیرفته شدن داشته باشند
+
+یک راه برای تفکر درباره انجمن پروژه تان از طریق آنچه مایک مک کویید آن را [قیف مشارکت کننده](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) می نامد میسر است.
 
 ![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
 
-As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more.
+در حین اینکه شما انجمن خود را می سازید، در نظر بگیرید چطور فردی در بالای قیف( یک کاربر بالقوه) می تواند از لحاظ نظری راهش را به ته قیف ( یک نگهدارنده فعال) هموار سازد. هدف شما این است که ناسازگاری در هر مرحله تجربه مشارکت کننده را کاهش دهید. وقتی افراد، بردهای آسانی دارند، آنها انگیزه بیشتری برای ادامه کار دارند.
+
+با مستندات خود شروع کنید:
 
-Start with your documentation:
+* **برای افراد استفاده از پروژه خود را ساده سازید:** یک مثال از آن کد واضح و [README دوستانه](../starting-a-project/#writing-a-readme) است که راه اندازی پروژه تان را برای هر کسی هموارتر می سازد.
+* **بطور واضح توضیح دهید که مشارکت چگونه است،** البته این کار با استفاده از [فایل مشارکت](../starting-a-project/#writing-your-contributing-guidelines) و به روز نگه داشتن موضوعات میسر است.
 
-* **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.
+* **موضوعات اولیه خوب:** برای کمک کردن به اینکه مشارکت کنندگان جدید کار خود را شروع کنند، [برچسب زدن به موضوعاتی که برای موفقیت مبتدی ها به قدر کافی ساده هستند](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) را بطور آشکار لحاظ کنید. سپس GitHub، این موضوعات را در محل های مختلف روی پلتفورم هموار می سازد، و مشارکت های مفید را افزایش می دهد و سپس ناسازگاری از کاربران مختلف در فائق آمدن بر موضوعاتی که در سطح آنها خیلی دشوار است را کاهش می دهد.
 
-[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.
+{نظرسنجی منبع باز( اوپن سورس) 2017 GitHub][GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) که مستندات ناقص و گیچ کننده ای را نشان می داد، بزرگترین مشکل برای کاربران منبع باز می باشد. مستندات خوب، افراد را دعوت می کند که با پروژه‌تان تعامل کنند. در نهایت افراد یک موضوع یا یک درخواست pull( ادغام یا یکپارچگی) را باز خواهند کرد. از این تعاملات به عنوان فرصتهایی برای سوق دادن آنها به پایین قیف استفاده کنید.
 
-* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
-* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
-* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
-* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+* **وقتی شخص جدیدی وارد پروژه شما می شود، از وی از روی علاقه تشکر کنید!** این یک تجربه منفی خواهد بود که از فردی بخواهید که از پروژه تان خارج نشود.
+* **پاسخگو باشید:** اگر شما به موضوعاتشان در عرض یک ماه پاسخ نمی دهید، شانس اینکه پروژه تان را فراموش کنند بالا می رود.
+* **درباره انواع مشارکت هایی که خواهید پذیرفت ، پذیرای عقاید و افکار جدید باشید.** بسیاری از مشارکت کننده ها با یک گزارش باگ یا ترمیم جزئی آغاز می کنند. راه های زیادی برای مشارکت در یک پروژه وجود دارد. به افراد اجازه دهید تا بازگو کنند [چطور می خواهند مساعدت کنند](../how-to-contribute/#what-it-means-to-contribute).
+* **اگر یک مشارکتی وجود دارد که شما با آن مخالف هستید،** از آنها به خاطر بیان ایده تشکر کرده و [توضیح دهید](../best-practices/#learning-to-say-no) چرا آن ایده با محدوده پروژه تان تناسب ندارد، و اگر مستندات خوبی دارید رو کنید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns.
+  مشارکت کردن در پروژه منبع باز برای برخی نسبت به دیگران آسانتر است. ترس زیادی از مورد سرزنش قرار گرفتن به خاطر انجام غلط کاری یا کار نامتناسب وجود دارد، با اعطای یک محل به مشارکت کنندگان با مهارت فنی خیلی کم ( از لحاظ مستندات و محتوای وب و غیره) تا در پروژه تان کمک کنند می توانید تا حد زیادی این نگرانی ها را کاهش دهید.
   <p markdown="1" class="pquote-credit">
 — @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
   </p>
 </aside>
 
-The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute.
+اکثریت مشارکت کنندگان منبع باز، مشارکت کنندگان اتفاقی هستند: افرادی که تنها گهگاه در یک پروژه مشارکت می کنند. یک مشارکت کننده اتفاقی شاید زمان کافی برای همگامی با پروژه تان را نداشته باشد، پس کارتان این است که مشارکت را برای او تا حد ممکن ساده تر سازید.
 
-Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself.
+ترغیب کردن مشارکت کنندگان دیگر یک سرمایه گذاری روی خودتان می باشد. وقتی شما بزرگترین طرفدارانتان را توانمند می سازید تا با کاری که آنها با انجامش هیجان زده می شوند همگام شوند، فشار کمی برای انجام کامل کار توسط خودتان اعمال می شود.
 
-### Document everything
+### مستند کردن همه چیز
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
+  آیا شما تاکنون در یک رویداد (فناوری) بوده اید که در آن  هیچ کس را نشناسید، اما افراد دیگر همدیگر را می شناسند و با دوستان قدیمیشان چت می کنند؟ (...) حالا  تصور کنید می خواهید که در یک پروژه منبع باز مشارکت کنید، اما چرایی و چگونگی رخ دادن آن را نمی بینید.
   <p markdown="1" class="pquote-credit">
 — @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
-When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public.
+وقتی شما یک پروژه جدید را آغاز می کنید، شاید احساس طبیعی تان این باشد که کارتان را باید خصوصی ادامه دهید. اما پروژه های منبع باز هنگامی شما را برمی انگیزند که شما پروسه تان را بطور علنی مستند می سازید.
 
-When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed.
+وقتی شما کارها را می نویسید، افراد بیشتری می توانند در هر مرحله از رویه ها مشارکت کنند. شما ممکن است درباره چیزی کمک بخواهید چیزی که حتی در حد لزوم هم آن را نمی دانستید.
 
-Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public.
+مکتوب کردن چیزها معنایی بیشتر از مستندسازی فنی صرف دارد. هر زمان شما احساس می کنید که مصر هستید تا کاری را مکتوب کنید یا بطور خصوصی پروژه تان را بحث کنید، از خودتان بپرسید که آیا می توانید آنرا علنی کنید یا نه؟
 
-Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions.
+درباره نقشه مسیر پروژه تان ، انواع مشارکت هایی که شما در پی آنها هستید، اینکه چطور مشارکت ها بررسی می شوند یا اینکه چرا تصمیمات خاصی را اتخاذ می کنید ، شفاف سازی کنید.
 
-If you notice multiple users running into the same problem, document the answers in the README.
+اگر شما کاربران متعددی را مطلع سازید تا مسئله مشابهی را بررسی کنند، جوابها را در README مستند سازید. 
 
-For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you.
+برای جلسات، منتشر کردن یادداشت ها و نقشه های مسیر خود در یک موضوع مرتبط را مدنظر قرار دهید. بازخوردی که از این سطح از شفافیت کسب می کنید شاید شما را شگفت زده کند.
 
-Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on.
+مستندسازی همه چیزها با کاری که شما انجام می دهید نیز همگام است. اگر شما در حال کار بر روی آپدیت کردن پروژه تان در حجم زیاد هستید، برای آن یک بخش درخواست pull اعمال کنید و آن را به عنوان کاری که در حال پیشرفت است نمره دهید(WIP). از این طریق، افراد دیگر می توانند در پروسه شما اعمال نظر کنند
 
-### Be responsive
+### پاسخگو باشید
 
-As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started.
+در حین اینکه شما [پروژه تان را ارتقا می دهید](../finding-users)، افراد شاید بازخوردهایی برای شما داشته باشند. آنها ممکن است درباره اینکه چطور موارد کار می کنند سوالاتی داشته باشند، یا برای شروع نیاز به کمک داشته باشند.
 
-Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating.
+سعی کنید که هنگامی که شخصی یک موضوع را پیوست می کند، تحویل می دهد یا درخواستی دارد یا درباره پروژه تان سوالی می پرسد پاسخگو باشید. وقتی شما به سرعت پاسخ دهید، افراد احساس خواهند کرد که آنها بخشی از یک گفتگو هستند و درباره مشارکت با شما مشتاق تر خواهند بود.
 
-Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466):
+حتی اگر نمی توانید درخواستشان را فوراً بررسی کنید،حداقل از آنها تشکر کنید تا به افزایش مشارکت کمک کرده باشید. اینجا بیان می شود چطور @tdreyno به یک درخواست pull در سایت [Middleman](https://github.com/middleman/middleman/pull/1466) پاسخ داده است:
 
 ![Middleman pull request](/assets/images/building-community/middleman_pr.png)
 
-[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution.
+[یک مطالعه موزیلا](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) پی برده است که مشارکت کنندگانی که بررسی های کدگونه را در ظرف 48 ساعت دریافت کرده بودند میزان برگشت و تکرار مشارکت خیلی بیشتری داشتند
 
-Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project.
+همچنین مکالمات درباره پروژه تان می تواند در محل های د Oیگری در اینترنت مانند Stackverflow ، توییتر، یا Reddit روی دهد. شما می توانید در برخی از این محل ها نوتیفیکیشن هایی را اجرا کنید و بدین طریق هنگامی که شخصی به پروژه تان اشاره می کند، با خبر شوید.
 
-### Give your community a place to congregate
+### به انجمن تان یک محلی برای مشارکت کردن اختصاص دهید
 
-There are two reasons to give your community a place to congregate.
+دو دلیل برای اعطای یک محل برای مشارکت در انجمن‌تان وجود دارد.
 
-The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate.
+اولین دلیل به خاطر مشارکت کنندگان است. به افراد کمک کنید تا همدیگر را بشناسند. افراد دارای منافع مشترک، بطور اجتناب ناپذیری می خواهند که محلی برای گفتگو درباره آن منافع داشته باشند. و وقتی ارتباطات علنی و قابل دسترس باشد، هر کسی می تواند آرشیوهای گذشته را بخواند تا به مشارکت خود شتاب بخشد. 
 
-The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel.
+دلیل دوم به خاطر خود شما است. اگر شما به افراد محل عمومی برای صحبت درباره پروژه تان ندهید، آنها احتمالاً با شما مستقیماً تماس خواهند گرفت. در شروع، ظاهراً ساده است که به پیامهای خصوصی  با موضوع « فقط اینبار»پاسخ دهید. اما در طول زمان مخصوصاً اگر پروژه تان معروف شود، شما کلافه خواهید شد.  در برابر وسوسه ارتباط برقرار کردن با افراد درباره پروژه تان بطور خصوصی مقاومت کنید. در عوض آنها را به یک کانال عمومی معین هدایت کنید.
 
-Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above!
+ارتباطات عمومی می تواند در حقیقت هدایت کردن مردم برای باز کردن یک موضوع به جای ایمیل مستقیم یا اظهار نظر کردن روی وبلاگ‌تان باشد. همچنین شما می توانید یک لیست مِیلی داشته باشید، یا یک حساب توییتر، Slack یا کانال IRC برای افراد راه بیاندازید تا درباره پروژه تان گفتگو کنند. یا همه موارد بالا را با هم اعمال کنید!
 
-[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members:
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) هر هفته وقت خود را در ساعات اداری به کمک به اعضای انجمن اختصاص می دهد:
 
-> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.
+> همچنین کاپس هر هفته زمانی را برای پیشنهاد دادن کمک و راهنمایی به انجمن اختصاص می دهد. مالکان کاپس با اختصاص زمان اختصاصی برای کار کردن با تازه واردها، کمک به PRs ، و بحث درباره ویژگی های جدید موافقت کرده اند.
 
-Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address.
+استثنائات قابل توجهی در مورد ارتباطات عمومی وجود دارد از قبیلِ: موضوعات امنیتی و نقض کدهای رفتاری حساس. شما باید همیشه راهی پیش پای افراد بگذارید تا این موضوعات را بطور خصوصی گزارش کنند. اگر نمی خواهید که از ایمیل شخصی خود استفاده کنید، یک آدرس ایمیل اختصاصی ایجاد کنید.
 
-## Growing your community
+## انجمن‌تان را رشد دهید
 
-Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction.
+انجمنها بی نهایت قدرتمند هستند. این قدرت می تواند مفید یا مضر باشد که به این بستگی دارد که چطور آن را اعمال می کنید. در حین اینکه انجمن پروژه تان رشد می کند، راه هایی برای کمک به آن وجود دارد تا به جای نیروی مخرب یک نیروی سازنده باشد.
 
-### Don't tolerate bad actors
+### بازیگران بد را تحمل نکنید
 
-Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others.
+هر پروژه معروفی ناگزیر افرادی که ضرررسان هستند را نیز جذب خواهد کرد. آنها شاید بحثهای غیرضروری را شروع کنند، درباره ویژگی های جزئی خرده گیری کنند یا برای بقیه قلدری کنند. 
 
-Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave.
+شما به بهترین نحو تلاش کنید تا یک خطی مشی تحمل-صفر نسبت به این نوع افراد اقتباس کنید. اگر افراد منفی را چک نکنید ، افراد دیگر در جامعه تان را نیز ناراحت خواهند ساخت. آنها حتی شاید پروژه تان را ترک کنند.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
-  The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.
+  حقیقت این است که داشتن یک جامعه حامی بسیار حیاتی است. من هرگز قادر به انجام چنین کاری بدون کمک همکارانم، غریبه هایی که در اینترنت و کانال های IRC چت با آنها دوست شدم نبودم(...). البته نباید به دون مایه ها و عوضی ها اکتفا نمود.
   <p markdown="1" class="pquote-credit">
 — @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
   </p>
 </aside>
 
-Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
+بحثهای دائمی بر روی جنبه های جزئی پروژه تان، افرا دیگر از جمله خود شما را از تمرکز روی کارهای مهم دیگر بازمی دارد. افراد جدیدی که وارد پروژه تان می شوند شاید این مکالمات را ببینند و در نتیجه مشارکت نکنند.
 
-When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations.
+وقتی می بینید رفتار منفی‌ای در پروژه تان رخ می دهد، آن را علنی کنید. با لحن قاطع توضیح  دهید که چرا رفتارشان قابل قبول نیست. اگر این مسئله دائماً وجود داشت شاید نیاز داشته باشید که از [آنها بخواهید تا پروژه تان را ترک کنند](../code-of-conduct/#enforcing-your-code-of-conduct). [کد رفتاری‌تان](../code-of-conduct/) می تواند یک رهنمود سازنده برای این مکالمات باشد.
 
-### Meet contributors where they're at
+### با مشارکت کنندگان تماس بگیرید و در جریان قرار بگیرید که آنها در کجای کار هستند
 
-Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need.
+مستندسازی خوب تنها هنگامی مهمتر می شود که انجمن تان رشد می کند. مشارکت کنندگان اتفاقی که ممکن است با پروژه تان آشنا نباشند ، مستنداتتان را می خوانند تا به سرعت متنی که آنها نیاز دارند را بدست آورند.
 
-In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors.
+در فایل Contributing خود، بطور آشکار به مشارکت کنندگان جدید بگویید که چگونه کار خود را شروع کنند. شما شاید حتی بخواهید که یک بخش اختصاصی برای این منظور بسازید. برای مثال [Django](https://github.com/django/django) یک صفحه ویژه برای خوشامدگویی به مشارکت کنندگان جدید دارد
 
 ![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
 
-In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started.
+در صف موضوعتان ، باگهایی که برای انواع مختلف مشارکت کنندگان مناسب هستند، وجود دارد: برای مثال [_تنها اولین دفعه_](https://kentcdodds.com/blog/first-timers-only) ، « اولین موضوع خوب» یا « مستندات» را برچسب بزنید. این برچسب ها برای فرد جدید، بررسی سریع پروژه و شروع به کار بر روی موضوعاتتان را آسان می سازد
 
-Finally, use your documentation to make people feel welcome at every step of the way.
+سرانجام از مستندات‌تان استفاده کنید تا افراد را در هر مرحله از این رویه خرسند سازید.
 
-You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration.
+شما هرگز با اکثر افرادی که وارد پروژه تان می شوند تعامل نخواهید کرد. شاید مشارکتهایی وجود داشته باشد که آنها را دریافت نکرده اید چون برخی از افراد نمی دانند از کجا باید مشارکت خود را شروع کنند. حتی کلمات کمی وجود دارند که با آن می توان افراد را از ترک کردن پروژه تان به خاطر اشباع شدن بازداشت.
 
-For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+برای مثال، در اینجا ما [رهنمودهای مشارکت](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) پروژه [روبینیوس]https://github.com/rubinius/rubinius/) را می آوریم:
 
-> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
+> ما می خواهیم که کار خود را با قدردانی از شما برای استفاده از روبینیوس شروع کنیم. این پروژه یک کار عاشقانه است و ما از همه کاربرانی که باگها را معرفی می کنند، عملکردها را بهبود می دهند و به مستندسازی کمک می کنند، قدردانی می کنیم. هر مشارکتی مهم است پس از شما برای مشارکت سپاسگزاری می کنیم. اینکه گفته می شود اینجا رهنمودهای کمی وجود دارند که ما از شما بخواهیم تا از آنها پیروی کنید، می تواند باعث موفقیت رسیدگی به موضوعتان شود.
 
-### Share ownership of your project
+### مالکیت پروژه تان را به اشتراک گذارید
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
-  Your leaders will have different opinions, as all healthy communities should! However, you need to take steps to ensure the loudest voice doesn't always win by tiring people out, and that less prominent and minority voices are heard.
+  رهبرانتان، عقاید متفاوتی دارند همانطوری که همه جوامع سالم آن را می طلبند! البته شما باید گامهایی را برای تضمین این مطلب بردارید که بلندترین صدا همیشه به خاطر رنجاندن مردم همیشه پیروز نیست و اینکه صداهای اقلیت و کمتر برجسته نیز شنیده خواهند شد.
   <p markdown="1" class="pquote-credit">
 — @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
   </p>
 </aside>
 
-People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around.
+افراد با مشارکت در پروژه هایتان هنگام احساس مالکیت بر آن هیجان زده می شوند. این بدان معنی نیست که شما باید چشم انداز پروژه تان را تغییر دهید یا مشارکتهایی که شما نمی خواهید را بپذیرید. اما هرچه به دیگران اعتبار بیشتری ببخشید، آنها بیشتر انتظار آن را می کشند.
 
-See if you can find ways to share ownership with your community as much as possible. Here are some ideas:
+ببینید آیا می توانید تا آنجا که ممکن است راه هایی را برای تسهیم مالکیت با انجمن تان بیابید. در اینجا بعضی ایده ها در این باره ارائه می شوند:
+
+* **در برابر رفع باگ های ( غیرسرنوشت ساز) ساده مقاومت کنید:** در عوض از آنها به عنوان فرصتهایی برای پذیرش مشارکت کنندگان جدید استفاده کنید، یا شخصی که تمایل به مشارکت دارد، را راهنمایی کنید. شاید در اول غیرطبیعی به نظر برسد، اما سرمایه گذاری‌تان در طول زمان بازدهی‌اش را به تدریج بدست خواهد داد. برای مثال، @michaeljoseph از یک مشارکت کننده خواست تا درخواست Pull خود را درباره موضوع [Cookiecutter](https://github.com/audreyr/cookiecutter) به جای تعمیر آن توسط خودش ارائه دهد.
 
-* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself.
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
+* **یک فایل مشارکت کننده یا مولف در پروژه تان را شروع کنید** تا همه افرادی که به پروژه تان کمک می کردند مانند [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) را لیست کنید.
 
-* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+* **اگر شما یک انجمن بزرگ دارید، یک خبرنامه منتشر کنید یا یک پست وبلاگی بنویسید** که قدردان مشارکت کنندگان هستید. خبرنامه های [This Week in Rust](https://this-week-in-rust.org/) و [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) هودی دو نمونه خوب از این موارد هستند.
 
-* **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.
+* **به همه مشارکت کنندگان دسترسی Commit کردن بدهید.** @fleixge پی برد که این کار، [افراد را وادار می کند](https://felixge.de/2013/03/11/the-pull-request-hack.html) تا با هیجان بیشتری patch هایشان را اصلاح کنند و حتی باعث می شود اعضای جدید برای پروژه هایی بیابید که روی آنها سرمایه گذاری نکرده بودید.
 
-* 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.
+* اگر پروژه تان روی گیت هاب است، **آن را از حساب شخصی خود به یک [سازمان](https://help.github.com/articles/creating-a-new-organization-account/) انتقال دهید** و حداقل یک ادمین پشتیبان به آن بیافزایید. سازمان ها کار کردن روی پروژه هایی با همکاران خارجی را آسانتر می سازند.
 
-The reality is that [most projects only have](https://peerj.com/preprints/1233.pdf) 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.
+واقعیت این است که [اکثر پروژه ها](https://peerj.com/preprints/1233.pdf) تنها دارای یک یا دو عضو هستند کسانی که اکثر کار را انجام می دهند. هرچه پروژه تان بزرگتر باشد، و هرچه انجمن تان بزرگتر باشد، دستیابی به کمک ساده تر خواهد بود.
 
-While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help.
+در حالی که شاید همیشه شخصی را برای جواب دادن به تماس ها نیابید، اما فرستادن سیگنالهایی به آنجا شانسی که افراد دیگر در پروژه همکاری بکنند را افزایش خواهد داد. و اینکه هرچه زودتر اقدام کنید، افراد زودتر می توانند به شما کمک کنند.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
-  \[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it.
+  به بهترین وجه به نفعتان است که مشارکت کنندگانی را به عضویت بگیرید که از کارشان لذت می برند و کسانی که قادر به انجام کارهایی هستند که شما نمی توانید انجام دهید. آیا شما از کدگذاری لذت می برید، اما از جواب دادن به موضوعات لذت نمی برید؟ پس آن افرادی را در انجمن خود شناسایی کنید که این کارها را انجام می دهند.
   <p markdown="1" class="pquote-credit">
 — @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
   </p>
 </aside>
 
-## Resolving conflicts
+## حل و فصل تضادها
 
-In the early stages of your project, making major decisions is easy. When you want to do something, you just do it.
+در مراحل اولیۀ پروژه تان، اتخاذ کردن تصمیمات بزرگ ساده است. وقتی می خواهید که کاری را انجام دهید، شما فقط مشغول انجام آن شوید.
 
-As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own.
+در حین اینکه پروژه تان معروف تر می شود، مردم بیشتری از تصمیماتی که شما اتخاذ می کنید سود می برند. حتی اگر انجمن بزرگی از مشارکت کنندگان را ندارید، و اگر پروژه تان دارای کاربران زیادی نیست، شما افرادی را خواهید یافت که تصمیمات را می سنجند و موضوعاتی مرتبط با خودشان را مطرح می کنند.
 
-For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address.
+برای اکثر بخش ها، اگر شما یک انجمن محترم و صمیمی را پرورش می دهید و پروسه تان را علنی مستندسازی کنید، انجمن تان باید قادر باشد تا راه حل را پیدا کند. اما گاهی اوقات شما موضوعی را مطرح می کنید که پرداختن به آن یک کمی دشوارتر است.
 
-### Set the bar for kindness
+### قالبی برای نوع دوستی تعیین کنید
 
-When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you.
+وقتی انجمن تان با یک موضوع خاص مواجه است، مجرب ها ممکن است داوطلب شوند. افراد ممکن است عصبی شوند یا اشباع شوند و آن وظیفه را به شما یا دیگری محول کنند.
 
-Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive.
+کارتان به عنوان یک نگاهدارنده آن است که از وخیم تر شدن شرایط جلوگیری کنید. حتی اگر شما عقیده قوی‌ای به این موضوع دارید، سعی کنید که جایگاه یک میانجی یا تسهیل کننده را داشته باشید به جای اینکه به نبرد با دیدگاه تان وارد شوید. اگر شخصی در حال بی مهر شدن است یا دارد مکالمات را انحصاری می سازد، [فوراً اقدام کنید](../building-community/#dont-tolerate-bad-actors) تا مباحثات را مدنی و سودمند نگه دارید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
-  As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
+  به عنوان یک نگهدارنده پروژه، بی نهایت مهم است که نسبت به مشارکت کنندگانتان فروتن باشید. اغلب آنها آنچه شما خیلی شخصی می پندارید را محرمانه نگه می دارند.
   <p markdown="1" class="pquote-credit">
 — @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
-Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly.
+افراد دیگر به رهنمودهای شما نگاه می کنند. یک نمونه خوب را تعیین کنید، شما هنوز می توانید ناامیدی، ناراحتی یا نگرانی را اظهار کنید اما آرامش خود را کاملاً حفظ کنید.
 
-Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you.
+خونسرد بودن آسان نیست، اما نشان دادن رهبری ، سلامت انجمن تان را بهبود می بخشد. اینترنت از شما تشکر می کند.
 
-### Treat your README as a constitution
+### فایل README خود را به عنوان یک قانون اساسی در نظر بگیرید
 
-Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion.
+فایل README تان [بیشتر از یک مجموعه رهنمودها است](../starting-a-project/#writing-a-readme)، همچنین یک محلی برای گفتگو درباره اهداف، دیدگاه و نقشه مسیرتان است. اگر افراد آشکارا روی بحث درباره ارزش یک ویژگی خاص تمرکز می کنند، این کار به تجدیدنظر درباره README تان و صحبت درباره دیدگاه بهتر درباره پروژه تان کمک می کند. تمرکز روی README تان همچنین این مکالمات را غیرمحرمانه می سازد، بنابراین شما می توانید یک بحث سازنده را دنبال کنید.
 
-### Focus on the journey, not the destination
+### تمرکز روی سفر نه مقصد
 
-Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns.
+برخی پروژه ها از یک فرایند رای گیری استفاده می کنند تا تصمیمات بزرگی را اتخاذ کنند. در حالی که در نگاه اول معقول به نظر می رسد، اما رای گیری به جای گوش دادن و پرداختن به نگرانی های همدیگر روی دستیابی به یک جواب تاکید می کند.
 
-Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place.
+رای گیری می تواند سیاسی باشد، که در آن اعضای انجمن برای انجام منافع همدیگر یا رای دادن در یک راه خاص احساس تحت فشار قرار داشتن کنند. البته همه رای نمی دهند، چه [اکثریت انجمن تان سکوت پیشه کنند](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) چه کاربران فعلی که از رای آگاهی ندارند در حال جایگزین شدن باشند.
 
-Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus.
+گاهی اوقات، رای گیری یک رهگشای ضروری است. هرچه شما بیشتر توانمند باشید به جای خودِ اجماع بیشتر روی « اجماع‌جویی» تاکید می کنید.
 
-Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion.
+تحت یک فرایند اجماع جویی ، اعضای انجمن، نگرانی های بزرگ خود را بحث می کنند تا آنها احساس کنند که حرفهایشان شنیده می شود. وقتی تنها نگرانی های کوچک باقی می ماند، انجمن روی به جلو حرکت می کند.« اجماع جویی مهر تاییدی بر این مطلب است که یک انجمن شاید قادر نباشد که به یک جواب جامع دست یابد. در عوض، آن به گوش سپاری و مباحثه اولویت می دهد.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
-  Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
+  بخشی از دلیل اینکه چرا یک سامانه رای گیری برای موضوعات اتمی وجود ندارد بدین خاطر است که تیم اتمی قصد ندارد که از یک سیستم رای گیری در همه موارد بهره گیرد. گاهی اوقات ما باید آنچیزی را انتخاب کنیم که درست است حتی اگر آن معروف نباشد. (...) آنچه من می توانم پیشنهاد کنم و برای انجام آن تقاضا کنم این است که کار من این است که به انجمن گوش فرا دهم.
   <p markdown="1" class="pquote-credit">
 — @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
   </p>
 </aside>
 
-Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions.
+حتی اگر شما در عمل به عنوان یک نگهدارنده پروژه یک فرایند اجماع‌جویی را اقتباس کنید، مهم است که بدانید چه افرادی در حال گوش دادن هستند. وادار کنید دیگر افراد احساس کنند که شنیده می شوند و متعهد شوید که نگرانی هایشان را حل می کنید، و راه طولانی انتشار شرایط حساس را طی می کنید. سپس حرفهایتان را با اقداماتتان مقایسه کنید.
+
+با به خاطر داشتن یک راه حل به یک تصمیم متمایل نشوید. مطمئن شوید که همه افراد احساس شنیده شدن می کنند و اینکه همه اطلاعات قبل از حرکت به سوی راه حل علنی شده اند.
 
-Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution.
+### مکالمه را بطور متمرکز روی کار عملی حفظ کرده و پیش ببرید
 
-### Keep the conversation focused on action
+مباحثه مهم است اما یک تفاوت بین مکالمات سودمند و غیرمفید وجود دارد.
 
-Discussion is important, but there is a difference between productive and unproductive conversations.
+مباحثات مادامی که فعالانه به سوی راه حل سوق می یابند را تشویق کنید. اگر واضح است که مکالمه بی فروغ شده یا به خارج از موضوع هدایت شده، گفتگوها دارد شخصی می شود یا افراد وارد بحثهای جزئی و حاشیه ای می شوند، زمان آن فرا رسیده که به مباحثات خاتمه دهید.
 
-Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down.
 
-Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues.
+اجازه دادن به این مکالمات که همچنان ادامه یابد نه تنها برای موضوع تحت بررسی بد است بلکه برای سلامت انجمن تان نیز بد است. این کار پیامی می فرستد مبنی بر اینکه این نوع مکالمات مجاز هستند یا حتی انجام آنها مورد تشویق قرار می گیرد و در نتیجه می تواند روحیه افراد را از مطرح کردن و حل کردن موضوعات آتی تضعیف کند.
 
-With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_
+با ذکر هر نکته توسط دیگران یا خودتان، از خود بپرسید که _«چطور این نکته ما را به راه حل نزدیکتر می کند؟»_
 
-If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation.
+اگر مکالمه به سوی حل شدن سوق یافته است از گروه بپرسید که در مرحله بعد باید _چه گامهایی را انتخاب کنید؟_ تا دوباره روی مکالمه متمرکز شوید.
 
-If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it.
+اگر یک مکالمه بطور واضح هیچ روزنه ای به سوی راه حل نیافته یا هیچ اقدام واضحی برای عملیاتی شدن وجود ندارد یا اقدام مناسب قبلا اتخاذ شده، موضوع را ببندید و توضیح دهید چرا شما آن را بسته اید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-  Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
+  رهنمون سازی یک رشته جریانات به سوی راه حلی مفید بدون تحت فشار قرار گرفتن یک هنر ناب است. این کار برای سرزنش کردن افراد که تلف کردن زمانشان را متوقف کنند یا برای خواستن از آنها که اگر چیز سازنده ای برای گفتن ندارند مطلبی پست نکنند، کارساز نیست. در عوض شما باید شرایط برای پیشرفت بیشتر را پیشنهاد کنید: به افراد یک مسیر بدهید، مسیری که دنبال کنند تا آنها را به نتایجی که شما می خواهید هدایت کند با وجود این، این کار باید بدون رفتار مستبدانه صورت گیرد.
   <p markdown="1" class="pquote-credit">
 — @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
   </p>
 </aside>
 
-### Pick your battles wisely
+### نبردهایتان را عاقلانه سازید
 
-Context is important. Consider who is involved in the discussion and how they represent the rest of the community.
+متن مهم است، در نظر بگیرید چه کسانی در بحث درگیر می شوند و چطور آنها بقیه انجمن را تحت تاثیر قرار می دهند.
 
-Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices.
+آیا همه افراد در انجمن در این باره ناراحت هستند یا حتی درگیر این موضوع هستند؟ یا آیا یک دردسرساز منحصر به فرد وجود دارد؟ فراموش نکنید که فقط صداهای فعال را در نظر نگیرید و اعضای ساکت جامعه تان را نیز لحاظ کنید.
 
-If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread.
+اگر موضوع ، نیازهای گسترده تر انجمن تان را متجلی نمی سازد، شما شاید نیاز به تایید نگرانی های افراد کمی از انجمن تان داشته باشید. اگر این یک موضوع تکرار شونده بدون یک راه حل واضح باشد، آنها را به مباحثات قبلی درباره این موضوع ارجاع دهید و موضوع را ببندید.
 
-### Identify a community tiebreaker
+###  راهگشای انجمن تان را شناسایی کنید
 
-With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker.
+با یک نگرش خوب و ارتباطات واضح، اکثر شرایط دشوار قابل حل هستند. البته حتی در مکالمه سودمند، می تواند یک تفاوت در عقیده درباره چگونگی پیشرفت رویه ها وجود داشته باشد. در این موارد، یک فرد یا گروه از افرادی را شناسایی کنید که می توانند به عنوان رهگشا عمل کنند.
 
-A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it.
+یک رهگشا می تواند نگه دارنده اولیه پروژه باشد یا می تواند یک گروه کوچک از کسانی باشند که مبتنی بر رای گیری تصمیم می گیرند. بطور ایده آل شما یک رهگشا و یک فرایند مرتبط در یک فایل GOVERNANCE  را شناسایی کرده اید قبل از اینکه ملزم باشید که از آن استفاده کنید.
 
-Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible.
+رهگشایتان، باید یک تصمیم گیرنده نهایی باشد. موضوعات نفاق انگیز فرصتی برای انجمن تان است تا درس بگیرد و تکامل یابد. در آغوش کشیدن این فرصتها و استفاده از یک فرایند همکارانه برای حرکت به سوی یک راه حل هرجایی شدنی است.
 
-## Community is the ❤️ of open source
+## اجتماع ها و انجمن ها ❤️ متن باز هستند
 
-Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience.
+انجمنهای سالم اما کوشا هزاران ساعت را برای منبع باز در هر هفته اختصاص می دهند. خیلی از مشارکت کنندگان به افراد دیگر به عنوان دلیلی برای کار کردن یا نکردن روی منبع باز اشاره می کنند. با یادگیری اینکه چطور از قدرت بطور سازنده بهره برداری کنید شما باید به افراد خارج از آنجا کمک کنید تا از یک تجربه منبع باز فراموش نشدنی برخوردار شوند.

From faabd571cb77a8557540f150236fed9cbaa4f9a9 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Sat, 8 May 2021 02:20:05 +0430
Subject: [PATCH 161/749] Initial translation done.

---
 _articles/fa/code-of-conduct.md | 111 ++++++++++++++++----------------
 1 file changed, 54 insertions(+), 57 deletions(-)

diff --git a/_articles/fa/code-of-conduct.md b/_articles/fa/code-of-conduct.md
index 0b21e42d458..563ad07cbd4 100644
--- a/_articles/fa/code-of-conduct.md
+++ b/_articles/fa/code-of-conduct.md
@@ -1,14 +1,8 @@
 ---
-lang: en
-title: Your Code of Conduct
-description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct.
+lang: fa
+title: منشور اخلاقی
+description: با تصویب و اجرای منشور اخلاقی، رفتار سالم و سازنده را در انجمن (community) خود تسهیل کنید.
 class: coc
-toc:
-  why-do-i-need-a-code-of-conduct: "Why do I need a code of conduct?"
-  establishing-a-code-of-conduct: "Establishing a code of conduct"
-  deciding-how-youll-enforce-your-code-of-conduct: "Deciding how you’ll enforce your code of conduct"
-  enforcing-your-code-of-conduct: "Enforcing your code of conduct"
-  your-responsibilities-as-a-maintainer: "Your responsibilities as a maintainer"
 order: 8
 image: /assets/images/cards/coc.png
 related:
@@ -16,105 +10,108 @@ related:
   - leadership
 ---
 
-## Why do I need a code of conduct?
+## چرا به منشور اخلاقی نیاز داریم؟
 
-A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.
+منشور اخلاقی سندی است که انتظارات مربوط به رفتار را برای شرکت‌کنندگان پروژه تعیین می‌کند.   تصویب و اجرای منشور اخلاقی می‌تواند به ایجاد جو اجتماعی مثبت و سازنده برای انجمن شما کمک کند.
 
-Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.
+منشور اخلاقی نه تنها از شرکت‌کنندگان پروژه بلکه از شما هم محافظت می‌کند. اگر شما از پروژه‌ای نگهداری می‌کنید، ممکن است متوجه شده باشید که نگرش‌های مخرب از طرف دیگر شرکت‌کنندگان باعث می‌شود در طول کار از کار خود خسته یا ناراضی شوید.
 
-A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with.
+منشور اخلاقی این امکان را به شما می‌دهد تا رفتاری سالم و سازنده را در جامعه تسهیل کنید. داشتن نگرشی پیشگیرانه، احتمال اینکه شما یا دیگران از پروژه خسته شوید را کاهش می‌دهد و این امکان را برای شما فراهم می‌سازد تا وقتی کسی کاری را اشتباه انجام داد بتوانید با آن مقابله و جلوی آن را بگیرید.
 
-## Establishing a code of conduct
+## ایجاد منشور اخلاقی
 
-Try to establish a code of conduct as early as possible: ideally, when you first create your project.
+سعی کنید هر چه زودتر منشور اخلاق را ایجاد کنید: در حالت ایده‌آل، هنگامی که پروژۀ خود را شروع می‌کنید.
 
-In addition to communicating your expectations, a code of conduct describes the following:
+علاوه بر ابلاغ انتظاراتی که دارید، منشور اخلاقی موارد زیر را شرح می‌دهد:
 
-* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_
-* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_
-* What happens if someone violates the code of conduct
-* How someone can report violations
+* منشور اخلاقی در چه جاهایی اعمال می‌شود _(فقط در مورد مشکلات و درخواست‌های pull، یا دیگر فعالیت‌های انجمن مانند رویدادها؟)_
+* منشور اخلاقی برای چه کسانی اعمال می‌شود _(اعضای انجمن و نگه‌دارندگان، در مورد حامیان مالی چطور؟)_
+* اگر کسی منشور اخلاقی را نقض کند چه اتفاقی می‌افتد؟
+* چگونه می‌توان تخلفات را گزارش داد؟
 
-Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
+در هر جا که می‌توانید، از دانش پیشین خود استفاده کنید. [عهدنامۀ مشارکت‌کنندگان](https://contributor-covenant.org/) نوعی منشور اخلاقی جا افتاده و مقبول است که بیش از 40،000 پروژۀ متن باز از جمله «Kubernetes»، « «Rails و «Swift» از آن استفاده می‌کنند.
 
-The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](http://citizencodeofconduct.org/) are also two good code of conduct examples.
+[منشور اخلاقی Django](https://www.djangoproject.com/conduct/) و [منشور اخلاقی Citizen](http://citizencodeofconduct.org/) نیز دو نمونۀ خوب دیگر هستند.
 
-Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
+فایل «منشور اخلاقی» را در فهرست اصلی پروژه قرار دهید و با لینک کردن آن با فایل‌های CONTRIBUTING یا README، آن را در دیدگاه انجمن خود قرار دهید.
 
-## Deciding how you'll enforce your code of conduct
+## تصمیم‌گیری در مورد نحوۀ پیش بردن منشور اخلاقی
 
 <aside markdown="1" class="pquote">
-  A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
+  منشور اخلاقی‌ای که اجرا نمی‌شود (یا نمی‌توان آن را اجرا کرد) بدتر از نبود هیچ منشور اخلاقی‌ای می‌باشد: نبود منشور اخلاقی این پیام را با خود به همراه دارد که ارزش‌های درج شده در منشور اخلاقی در انجمن شما مهم نیستد و مورد احترام واقع نمی‌شوند.
   <p markdown="1" class="pquote-credit">
 — [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
   </p>
 </aside>
 
-You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:
+شما باید **قبل از وقوع** هر گونه تخلفی ابتدا توضیح دهید که منشور اخلاقی شما چگونه عملیاتی می‌شود. چندین دلیل برای اینکار وجود دارد:
 
-* It demonstrates that you are serious about taking action when it's needed.
+* نشان می‌دهد که شما جدی هستید و در صورت لزوم اقدام می‌کنید.
 
-* Your community will feel more reassured that complaints actually get reviewed.
+* انجمن‌تان نسبت به بررسی شدن شکایات، اطمینان بیشتری پیدا می‌کند.
 
-* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.
+* به انجمن خود در صورت مرتکب شدن به تخلفی اطمینان خواهید داد که روند بازبینی منصفانه و شفاف خواهد بود.
 
-You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
+شما باید روشی ویژه‌ای (مانند آدرس ایمیل) برای مردم فراهم آورید تا بتوانند تخلفات ناشی از منشور اخلاقی را گزارش دهند و توضیح دهند که چه کسی مرتکب تخلفات شده است. می‌تواند یک نگهدارنده، گروهی از نگهدارنده‌ها یا یک کارگروه ویژۀ منشور اخلاقی باشد.
 
-Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+فراموش نکنید که ممکن است کسی بخواهد در مورد شخصی که این گزارشات را دریافت می‌کند تخلفی را گزارش دهد. در این صورت، برای آن‌ها گزینه‌ای تعبیه کنید تا بتوانند تخلفات را به شخص دیگری گزارش دهند. به عنوان مثال، @ctb و @mr-c در مورد [پروژۀ خود «khmer»](https://github.com/dib-lab/khmer) می‌گویند: 
 
-> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+> مواردی از سوءرفتار، آزار و اذیت و رفتارهای غیر‌قابل‌قبول را می توان با ایمیل زدن به **khmer project@idyll.org** گزارش داد که فقط «C. Titus Brown» و Michael R. Crusoe» به آن دسترسی دارند. برای گزارش مسئله‌ای در رابطه با هر کدام از آن‌ها، لطفاً به **Judi Brown Clarke** دکترای مدیریت در مرکز «BEACON» برای مطالعۀ تکامل در عمل، مرکز علوم و فناوری «NSF» ایمیل بزنید.
 
-For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+برای ایده گرفتن، به [کتابچۀ راهنمای اجرای](https://www.djangoproject.com/conduct/enforcement-manual/) «Django» مراجعه کنید (اگرچه ممکن است بنا به اندازه پروژۀ خود، نیازی به چنین کتابچۀ جامعی نداشته باشید).
 
-## Enforcing your code of conduct
+## عملیاتی کردن منشور اخلاقی
 
-Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up.
+گاهی اوقات علی‌رغم تلاشی که می‌کنید، شخصی کاری خلاف منشور اخلاقی انجام می‌دهد. روش‌های مختلفی برای پرداختن و عکس‌العمل نشان دادن به رفتار منفی و مضر در هنگام بروز آن وجود دارد.
 
-### Gather information about the situation
+### جمع‌آوری اطلاعات در مورد وضعیت
 
-Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment.
+با هر یک از اعضای انجمن خود، رفتاری یکسان داشته باشید. اگر گزارشی منوط بر نقص منشور اخلاقی دریافت کردید، آن را جدی بگیرید و موضوع را بررسی کنید، حتی اگر با آن شخص رابطه‌ای نزدیک دارید. با این کار به انجمن خود نشان می‌دهید که برای دیدگاه آن‌ها ارزش قائل هستید و به قضاوت آن‌ها اعتماد دارید.
 
-The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context.
+آن عضو خطاکار انجمن ممکن است اولین بار نباشد که مرتکب به خطایی شده و به طور مداوم دیگران را ناراحت می‌کند، یا ممکن است اولین بار آن‌ها باشد. بسته به خطایی که مرتکب می‌شوند، اقدامات لازمی باید اجرا شود.
+
+قبل از عکس‌العمل نشان دادن، زمان کافی را برای فهمیدن کامل ماجرا صرف کنید. نظرات و گفتگوهای مربوط به گذشتۀ شخص را بررسی کنید تا آن‌ها را بهتر بشناسید و  متوجه شوید چرا ممکن است چنین رفتاری از آن‌ها سر بزند. سعی کنید دیدگاه‌های دیگری را غیر از دیدگاه‌های خودتان دربارۀ این فرد و رفتار او جمع‌آوری کنید.
 
-Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
 
 <aside markdown="1" class="pquote">
-  Don’t get pulled into an argument. Don’t get sidetracked into dealing with someone else’s behavior before you’ve finished dealing with the matter at hand. Focus on what you need.
+  وارد بحث و جدل با شخص نشوید. قبل از اتمام شدن رسیدگی به موضوع مورد بحث، وارد موضوع دیگر و رسیدگی به شخص دیگری نشوید. بر آنچه که نیاز هست تمرکز کنید.
   <p markdown="1" class="pquote-credit">
 — Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
   </p>
 </aside>
 
-### Take appropriate action
+### اقداماتی مناسب به کار ببرید
+
+پس از جمع آوری و بررسی اطلاعات کافی، باید تصمیم بگیرید که چه کاری انجام دهید. همانطور که به قدم بعدی می‌اندیشید، به یاد داشته باشید که هدف شما به عنوان ناظر، ایجاد محیطی امن، محترم و فضایی مشارکتی است. در نظر داشته باشید که تنها مسئلۀ چگونگی برخورد در آن موقعیت مهم نیست، بلکه چگونگی پاسخ و عکس‌العمل شما در آینده‌ی رفتار و انتظارات افراد حاضر در انجمن شما تأثیر می‌گذارد.
+
+وقتی کسی گزارشی منوط بر تخلف در منشور اخلاقی می‌دهد، رسیدگی به آن وظیفۀ شماست و نه خود او. گاهی اوقات، فرد گزارش‌دهنده با افشای این اطلاعات، آیندۀ شغلی، اعتبار یا ایمنی خود را ممکن است در معرض خطر بزرگی قرار دهد. وادار کردن آن‌ها به مقابله کردن با فرد مزاحم و خاطی می‌تواند فرد گزارش‌دهنده را در موقعیتی مخاطره‌آمیز قرار دهد. شما باید شخصا ارتباط مستقیم با فرد خاطی مورد نظر را مدیریت کنید، مگر اینکه فرد گزارش‌دهنده صریحاً خلاف آن را درخواست کند.
 
-After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward.
 
-When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise.
+چند روش وجود دارد که شما می‌توانید با استفاده از آن‌ها با موارد نقض منشور اخلاقی برخورد کنید:
 
-There are a few ways you might respond to a code of conduct violation:
+* **به شخص مورد نظر ترجیحاً به طور مشخص‌ و واضح اخطار عمومی دهید** و توضیح دهید که چگونه رفتار او بر دیگران تأثیر منفی می‌گذارد. اخطار به صورت عمومی به بقیۀ افراد انجمن این پیام را می‌رساند که منشور اخلاقی را جدی می‌گیرید. در مکالمه‌های خود خوش‌برخود باشید ولی جدی بمانید.
 
-* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication.
+* **به طور خصوصی با شخص مورد نظر صحبت بکنید** تا توضیح دهید که چگونه رفتار او بر دیگران تأثیر منفی می‌گذارد. اگر موقعیت طوری باشد که اطلاعات حساس شخصی فرد در میان باشد، بهتر است از کانال‌های ارتباطی خصوصی استفاده کنید. اگر با شخص به طور خصوصی صحبت می‌کنید، بهتر است کسانی را که برای اولین بار وضعیت را گزارش کرده‌اند مطلع کنید تا بدانند که اقدام کرده‌اید. قبل از پیگیری کردن گزارش مربوطه، از شخص گزارش‌دهنده رضایت بگیرید.
 
-* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them.
+گاهی اوقات، نمی‌توان به نتیجه‌ای قطعی رسید. فرد مورد نظر ممکن است در مواجهه با او پرخاشگر یا خصمانه برخورد کند یا  تغییری در رفتار خود ایجاد نکند. در این شرایط، ممکن است بخواهید اقدامات جدی‌تری را در نظر بگیرید. مثلا:
 
-Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example:
+* **فرد مورد نظر را از ادامۀ همکاری در پروژه تعلیق کنید**، که از طریق منع موقت یا شرکت در هر جنبه‌ای از پروژه اعمال می‌شود
 
-* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project
+* **فرد مورد نظر را به طور دائمی** از ادامۀ همکاری در پروژه تعلیق کنید
 
-* **Permanently ban** the person from the project
+منع کردن اعضا نباید امری ساده تلقی شود و باید نشان‌دهندۀ اختلاف دائمی در دیدگاه و آشتی‌ناپذیری تلقی شود. این اقدامات را فقط باید در مواقعی پیش بگیرید که مشخص باشد امکان دستیابی به نتیجه‌ای قطعی وجود ندارد.
 
-Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached.
+## وظایف شما به عنوان یک نگهدارنده
 
-## Your responsibilities as a maintainer
+منشور اخلاقی آیین‌نامه‌ای نیست که به صورت خودسرانه اجرا شود. شما مجری منشور اخلاقی هستید و مسئولیت پیروی از قوانین تعیین شده به وسیله‌ی منشور اخلاقی از وظایف شماست.
 
-A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes.
+شما به عنوان نگهدارنده، دستورالعمل‌هایی را برای انجمن خود تعیین می‌کنید و آن دستورالعمل‌ها را مطابق با قوانین مندرج در منشور اخلاقی اجرا می‌کنید. این به معنای جدی گرفتن هر گونه گزارش مربوطی به نقض منشور اخلاقی است. گزارش فرد گزارش‌دهنده باید کاملا جامع و منصفانه بررسی شود. اگر تشخیص دادید رفتاری که آن‌ها گزارش داده‌اند، نقض منشور اخلاقی نیست، این مسئله را به وضوح با آن‌ها در میان بگذارید و توضیح دهید که چرا در این زمینه اقدامی نمی‌کنید. عکس‌العملی که نشان می‌دهند به خودشان مربوط است: باید رفتاری که آن‌ها با آن روبرو بوده‌اند را تحمل کنند یا مشارکت‌شان در انجمن را متوقف سازند.
 
-As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community.
+گزارش رفتاری که در واقع منشور اخلاقی شما را نقض نمی‌کند، همچنان نشان‌دهندۀ مشکلی در انجمن شما است و شما باید این مشکل بالقوه را بررسی کرده و چاره‌ای برای آن پیدا کنید.  که این ممکن است شامل بازنگری در منشور اخلاقی برای روشن ساختن رفتار قابل‌قبول یا صحبت با شخصی باشد که رفتار وی گزارش شده است و شما باید به فرد بگویید که اگرچه منشور اخلاقی را نقض نکرده‌اند، اما دارند در لبۀ آنچه که از آن‌ها انتظار می‌رود راه می‌روند و موجب ناراحتی در برخی از شرکت‌کنندگان شده‌اند.
 
-A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable.
+موضوع مهم این است که شما به عنوان یک نگهدارنده، باید استانداردهای رفتار قابل‌قبول را تعیین و عملیاتی کنید. شما توانایی شکل دادن به ارزش‌های اجتماعی پروژه را دارید و شرکت‌کنندگان انتظار دارند که شما این ارزش‌ها را به صورت منصفانه و یکسان اجرا کنید.
 
-In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way.
 
-## Encourage the behavior you want to see in the world 🌎
+## ترغیب‌کنندۀ رفتاری باشید که می‌خواهید در دنیا آن را مشاهده کنید 🌎
 
-When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow.
+هنگامی که یک پروژه خصمانه یا ناخوشایند به نظر می‌رسد، حتی اگر فقط یک نفر باشد که رفتار او غیرقابل‌تحمل باشد، ممکن است مشارکت‌کنندگان بیشتری را از دست بدهید که حتی ممکن است بعضی از آن‌ها را هرگز ملاقات نکرده باشید. اتخاذ یا اجرای منشور اخلاقی همیشه ساده نیست، اما ایجاد فضایی دوستانه به رشد انجمن شما کمک می کند.

From e6bac70d8a1ff4e68979cacbaa27ca90244a974e Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Sun, 9 May 2021 20:05:55 +0430
Subject: [PATCH 162/749] Initial translation done.

---
 _articles/fa/metrics.md | 123 +++++++++++++++++++---------------------
 1 file changed, 59 insertions(+), 64 deletions(-)

diff --git a/_articles/fa/metrics.md b/_articles/fa/metrics.md
index 080b3eea9d4..d7274ce79b5 100644
--- a/_articles/fa/metrics.md
+++ b/_articles/fa/metrics.md
@@ -1,14 +1,8 @@
 ---
 lang: en
-title: Open Source Metrics
-description: Make informed decisions to help your open source project thrive by measuring and tracking its success.
+title: سنجه‌های پروژه‌های متن باز
+description: آگاهانه تصمیم‌گیری کنید تا با ارزیابی و پیگیری موفقیت، به پیشرفت پروژۀ متن باز خود کمک کنید.
 class: metrics
-toc:
-  why-measure-anything: "Why measure anything?"
-  discovery: "Discovery"
-  usage: "Usage"
-  retention: "Retention"
-  maintainer-activity: "Maintainer activity"
 order: 9
 image: /assets/images/cards/metrics.png
 related:
@@ -16,117 +10,118 @@ related:
   - best-practices
 ---
 
-## Why measure anything?
+## چرا چیزی را ارزیابی کنیم؟
 
-Data, when used wisely, can help you make better decisions as an open source maintainer.
+هنگامی که داده‌ها هوشمندانه استفاده شوند، به شما کمک می‌کنند تا به عنوان یک نگهدارندۀ متن باز تصمیمات بهتری بگیرید.
 
-With more information, you can:
+با اطلاعات بیشتر، می‌توانید:
 
-* Understand how users respond to a new feature
-* Figure out where new users come from
-* Identify, and decide whether to support, an outlier use case or functionality
-* Quantify your project's popularity
-* Understand how your project is used
-* Raise money through sponsorships and grants
+* درک بهتری از واکنش کاربران به ویژگی‌های جدید داشته باشید
+* بفهمید کاربران جدید از کجا آمده‌اند
+* موارد کاربردی برجسته و قابلیت‌ها را شناسایی کنید و تصمیم بگیرید که آیا به پشتیبانی از آن‌ها ادامه می‌دهید یا خیر
+* محبوبیت پروژۀ خود را بسنجید
+* جنبه‌های کاربردی پروژه را درک کنید
+* از طریق اسپانسرها و کمک‌هزینه‌ها، پول جمع‌آوری کنید
 
-For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+به عنوان مثال، پروژۀ متن باز [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) دریافت که «Google Analytics» به آن‌ها در اولویت‌بندی کارها کمک می‌کند.
 
-> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+> «Homebrew» بصورت رایگان در اختیار کاربران قرار می‌گیرد و توسط داوطلبان در اوقات فراغت‌شان اداره می‌شود. در نتیجه، ما منابع لازم برای انجام مطالعات دقیق دربارۀ کاربران «Homebrew» را نداریم تا در مورد چگونگی بهترین طراحی برای ‌آینده و اولویت‌بندی کارهای فعلی تصمیم بگیریم. تجزیه و تحلیل کلی و ناشناس در رابطه با کاربران به ما امکان می‌دهد اصلاحات و ویژگی‌ها را بر اساس شیوه، مکان و زمان استفادۀ کاربران از «Homebrew» اولویت‌بندی کنیم.
 
-Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+محبوبیت، همه چیز نیست. دلایل متفاوت زیادی برای ورود افراد در پروژه‌های متن باز وجود دارد. اگر هدف شما به عنوان نگهدارندۀ متن باز این است که کار خود را در معرض نمایش بگذارید، پس همینطور برخورد کنید یا فقط از آن لذت ببرید؛ معیارها برای شما آنچنان مهم نیستند.
 
-If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+اگر _می‌خواهید_ به سطح درک عمیق‌تری دربارۀ پروژۀ خودتان برسید، روش‌های تجزیه و تحلیل فعالیت‌های پروژه خود را بدانید.
 
-## Discovery
 
-Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+## کشف و پیدا کردن
+
+قبل از اینکه کسی بتواند از پروژۀ شما استفاده کند یا در آن مشارکت داشته باشد، باید بداند که همچین پروژه‌ای وجود دارد. از خودتان بپرسید: _آیا مردم می‌توانند این پروژه را پیدا کنند؟_
 
 ![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:
+اگر پروژۀ شما در «GitHub» قرار دارد، [می‌توانید ببینید](https://help.github.com/articles/about-repository-graphs/#traffic) افرادی که در پروژۀ شما هستند از کجا آمده‌اند؟ در صفحه پروژۀ خود، روی «Insights» و سپس «Traffic» کلیک کنید. در این صفحه، این موارد را می‌توانید ببینید:
 
-* **Total page views:** Tells you how many times your project was viewed
+* **تعداد بازدیدها از صفحه:** به شما می‌گوید پروژه چند بار دیده شده است
 
-* **Total unique visitors:** Tells you how many people viewed your project
+* **تعداد بازدیدکنندگان منحصر به فرد:** به شما می‌گوید چند نفر پروژه را دیده‌اند
 
-* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+* **سایت‌های ارجاع دهنده یا معرفی‌کننده:** به شما می‌گوید، بازدیدکنندگان از کجا آمده‌اند. این معیار به شما کمک می‌کند تا بفهمید در کجا می‌توانید به مخاطب خود دسترسی پیدا کنید و آیا تلاش‌های تبلیغاتی شما موثر واقع شده است یا خیر.
 
-* **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://help.github.com/articles/about-stars/) هم می‌تواند به صورت معیاری برای محبوبیت عمل کند.اگرچه «GitHub stars» لزوماً با تعداد دانلودها و استفاده از محتوا ارتباط مستقیمی ندارد، اما این قسمت می‌تواند به شما بگوید که چه تعدادی از آدم‌ها متوجه پروژۀ شما شده‌اند..
 
-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.
+همچنین شاید بخواهید قابلیت کشف شدن (شناخته‌ شدن) را در [بخش‌های مشخصی ردیابی کنید](https://opensource.com/business/16/6/pirate-metrics): به عنوان مثال، «Google PageRank»، ترافیک رجوعی به وب‌سایت پروژۀ شما، یا مراجعات از سایر پروژه‌های متنباز یا سایر وب‌سایت‌ها.
 
-## Usage
+## استفاده
 
-People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+مردم پروژۀ شما را در این دنیای عجیب‌غریبی که اینترنت می‌نامیم، پیدا می‌کنند. در بهترین حالت، وقتی پروژۀ شما را ببینند، به آن مشتاق می‌شوند و می‌خواهند کاری انجام دهند. دومین سوالی که باید از خود بپرسید این است که: _آیا مردم از این پروژه استفاده می‌کنند؟_
 
-If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+اگر از یک برنامۀ مدیریت پکیج (package manager) مانند «npm» یا «RubyGems.org» برای انتشار پروژۀ خود استفاده می‌کنید، می‌توانید دانلودهای مربوط به پروژه را ردیابی کنید.
 
-Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+هر برنامۀ  مدیریت پکیجی ممکن است تعریف متفاوتی از دانلود داشته باشد و دانلود لزوماً با نصب یا استفاده ارتباط داشته باشد، اما مبنایی را برای مقایسه فراهم می‌کند. برای پیگیری آمارهای مختلف می‌توانید در میان بسیاری از مدیریت‌های محبوب پیکیج، از [Libraries.io](https://libraries.io/) استفاده کنید.
 
-If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+اگر پروژۀ شما در «GitHub» است، دوباره به صفحۀ «Traffic» بروید. می‌توانید از نمودار کلون [clone graph](https://github.com/blog/1873-clone-graphs) استفاده کنید تا ببینید چند بار پروژۀ شما در یک روز مشخص کپی شده است، که این نمودار براساس کل کلون‌ها (کپی‌ها) و کپی‌های منحصر به فرد مشخص شده است.
 
 ![Clone graph](/assets/images/metrics/clone_graph.png)
 
-If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+اگر میزان استفاده در مقایسه با تعداد افرادی که پروژۀ شما را پیدا می‌کنند کم است، دو مسئله وجود دارد که باید در نظر بگیرید:
+
+* مخاطبان به طور موفقیت‌آمیز با پروژۀ شما ارتباط نمی‌گیرند
+* یا مخاطبان اشتباهی را جذب کرده‌اید
 
-* Your project isn't successfully converting your audience, or
-* You're attracting the wrong audience
+به عنوان مثال، اگر پروژۀ شما در صفحۀ اول «Hacker News» قرار گیرد، احتمالاً جهشی در میزان کشف (ترافیک) اما با نرخ گرایش پایینی را مشاهده خواهید کرد؛ زیرا در Hacker News، افراد زیادی پروژۀ شما را پیدا می‌کنند. اگر پروژۀ «Ruby» شما در یک مجمع «Ruby» ارائه شده باشد، به احتمال زیاد نرخ گرایش بالایی از مخاطبان هدف را شاهد خواهید بود.
 
-For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+سعی کنید بفهمید مخاطبان شما از کجا می‌آیند و از نظرات دیگران در مورد صفحۀ پروژۀ خود بهره ببرید تا متوجه شوید با کدام یک از این دو مسئله روبرو هستید.
 
-Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+وقتی با مخاطبان و افرادی که از پروژۀ شما استفاده می‌کنند آشنا شدید، بهتر است بفهمید که آن‌ها چه استفاده‌ای از پروژه می‌کنند. آیا آن‌ها با فورک کردن کد شما و افزودن ویژگی‌های مختلف، بر روی آن کار می‌کنند؟ آیا آن‌ها از آن برای مصارف علمی یا تجاری استفاده می‌کنند؟
 
-Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
 
-## Retention
+## استمرار و نگهداری
 
-People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+مردم پروژۀ شما را پیدا می‌کنند و از آن استفاده می‌کنند. سوالی که باید از خودتان بپرسید این است که: _آیا مردم در آن مشارکت هم می‌کنند یا خیر؟_
 
-It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+هیچ‌وقت برای فکر کردن به مشارکت‌کنندگان دیر نیست. اگر پروژۀ شما محبوب باشد (بسیاری از از آن استفاده کنند) و سایر افراد دست به کار نشوند و از آن _پشتیبانی نکنند_ خود را در موقعیتی ناسالم قرار می‌دهید (به اندازۀ کافی نگهدارنده نداشته باشید).
 
-Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+نگهداری، مستلزم [ورود مشارکت‌کنندگان جدید](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2) است، زیرا مشارکت‌کنندگان فعال قبلی در نهایت به سراغ کارهای دیگر می‌روند.
 
-Examples of community metrics that you may want to regularly track include:
+نمونه‌هایی از معیارهای انجمن که باید مرتباً آن‌ها را بررسی کنید، شامل این موارد می‌شود:
 
-* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+* **تعداد کل مشارکت‌کنندگان و تعداد تعهدات هر مشارکت‌کننده:** به شما می‌گوید چه تعداد مشارکت‌کننده دارید و چه کسانی کم و بیش فعال هستند. این بخش را می‌توانید در «GitHub» در قسمت «Insights -> Contributors» مشاهده کنید. در حال حاضر، این نمودار فقط مشارکت‌کنندگانی که متعهد به شاخۀ پیش‌فرض مرکز ذخیره‌سازی شده‌اند را مشخص می‌کند.
 
 ![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
 
-* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+* **مشارکت‌کنندگان تازه‌کار، عادی، همیشگی:**  کمک می‌کند تا پیگیری کنید که آیا مشارکت‌کنندگان جدیدی دریافت می‌کنید یا خیر. (مشارکت‌کنندگان عادی، مشارکت‌کنندگانی با تعهدات کم هستند که البته تعریف «تعهدات کم» به خود شما بستگی دارد و می‌تواند یک یا پنج یا کمتر باشد) بدون مشارکت‌کنندگان جدید، انجمن پروژه راکد و کم‌رونق می‌شود.
 
-* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+* **تعداد مسائل در جریان و درخواست‌های باز pull:** اگر بیش از حد زیاد شوند، ممکن است در اولویت‌بندی مسائل و بررسی کدها به کمک نیاز داشته باشید.
 
-* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+* **تعداد مسائل باز شده (open issued)  و درخواست های باز شدۀ pull:** مسائل باز شده، یعنی کسی به اندازه کافی به پروژۀ شما اهمیت بدهد تا مسئله‌ای را باز کند. اگر این تعداد با گذشت زمان افزایش یابد، نشان‌دهندۀ این است که مردم به پروژۀ شما علاقه‌مند هستند.
 
-* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+* **انواع مشارکت‌ها:** به عنوان مثال، نوع تعهدها، رفع اشتباهات یا اشکالات یا اظهار نظر در مورد یک موضوع.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
-  Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+  پروژه‌های متن باز، چیزی فراتر از کد هستند. پروژه‌های متن باز موفق شامل مشارکت در کد و مستند سازی به همراه مکالماتی در مورد این تغییرات هستند.
   <p markdown="1" class="pquote-credit">
 — @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
   </p>
 </aside>
 
-## Maintainer activity
+## فعالیت‌های شخص نگهدارنده
 
-Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+نگهدارنده‌هایی که پاسخگو نیستند به نقطۀ ضعف پروژه‌های متن باز تبدیل می‌شوند. اگر کسی مشارکتی از خود به جای بگذارد اما هرگز از یک نگهدارنده پاسخی دریافت نکند، ممکن است احساس دلسردی کرده و آنجا را ترک کند.
 
-Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+[تحقیقات که در Mozilla شکل گرفت](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) نشان می‌دهد که پاسخگو بودن نگهدارنده عاملی حیاتی در تشویق به مشارکت‌های بیشتر است.
 
-[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+در نظر بگیرید که چه مدت طول می‌کشد تا شما (یا نگهدارنده‌ای دیگر) به مشارکت‌ها پاسخ دهید، خواه مسئله‌ای باشد یا درخواست pull. پاسخگو بودن نیاز به اقدام خاصی ندارد. می‌تواند به این سادگی باشد: _«ممنون از درخواست شما! در عرض یک هفته آن را بررسی می‌کنم.»_
 
-Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+همچنین می‌توانید مدت زمانی که برای تکمیل مراحل مختلف فرآیند مشارکت لازم است را اندازه بگیرید، همچون:
 
-You could also measure the time it takes to move between stages in the contribution process, such as:
+* متوسط زمان باز ماندن مسئله
+* بسته شدن مسئله توسط روابط عمومی (PR)
+* بسته شدن مسائل قدیمی
+* متوسط زمان ادغام کردن درخواست‌های pull
 
-* Average time an issue remains open
-* Whether issues get closed by PRs
-* Whether stale issues get closed
-* Average time to merge a pull request
 
-## Use 📊 to learn about people
+## از آمار 📊 برای درک مردم استفاده کنید
 
-Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+درک معیارها (استانداردها) به شما کمک می‌کند تا پروژۀ متن باز فعال و رو به‌ رشدی داشته باشید. حتی اگر هم تمامی معیارها را پیگیری نمی‌کنید، از چارچوب بالا استفاده کنید تا توجه خود را به نوع رفتاری که به پیشرفت پروژه کمک می‌کند متمرکز کنید.

From c9a3449e79b25502be76af0a5d232ed5673188ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Sun, 9 May 2021 23:54:41 +0000
Subject: [PATCH 163/749] Translate how-to-contribute.md via GitLocalize

---
 _articles/tr/how-to-contribute.md | 244 +++++++++++++-----------------
 1 file changed, 101 insertions(+), 143 deletions(-)

diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md
index 142b1f03e22..0f79a454a87 100644
--- a/_articles/tr/how-to-contribute.md
+++ b/_articles/tr/how-to-contribute.md
@@ -10,22 +10,16 @@ toc:
   finding-a-project-to-contribute-to: Katkıda bulunacak bir proje bulma
   how-to-submit-a-contribution: Katkı nasıl gönderilir?
   what-happens-after-you-submit-a-contribution: Bir katkı gönderdikten sonra ne olur?
-order: 1
-image: /assets/images/cards/contribute.png
+order: '1'
+image: "/assets/images/cards/contribute.png"
 related:
-- beginners
-- building
+  - beginners
+  - building
 ---
 
 ## Açık kaynağa neden katkıda bulunmalıyım?
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
-  \[Freenode\] üzerinde çalışmak, daha sonra üniversitedeki çalışmalarımda ve gerçek işimde kullandığım becerilerin çoğunu kazanmama yardımcı oldu. Açık kaynak kodlu projeler üzerinde çalışmanın projeye yardım ettiği kadar yapana da yardımcı olacağını düşünüyorum!
-  <p markdown="1" class="pquote-credit">
-- @errietta, ["Açık kaynaklı yazılımlara katkıda bulunmayı neden seviyorum"](https://www.errietta.me/blog/open-source/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">   \[Freenode\] üzerinde çalışmak, daha sonra üniversitedeki çalışmalarımda ve gerçek işimde kullandığım becerilerin çoğunu kazanmama yardımcı oldu. Açık kaynak kodlu projeler üzerinde çalışmanın projeye yardım ettiği kadar yapana da yardımcı olacağını düşünüyorum!   <p markdown="1" class="pquote-credit"> - @errietta, ["Açık kaynaklı yazılımlara katkıda bulunmayı neden seviyorum"](https://www.errietta.me/blog/open-source/)   </p> </aside>
 
 Açık kaynağa katkıda bulunmak, hayal edebileceğiniz herhangi bir konuyu öğrenmek, öğretmek ve deneyim geliştirmek için faydalı bir yol olabilir.
 
@@ -67,79 +61,61 @@ Endişe etmeyin! Açık kaynak kodlu bir projeye dahil olmanın çok farklı yol
 
 ### Kod yazarak katkıda bulunmak zorunda değilsin
 
-Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye _büyük bir_ iyilik yapacaksınız!
+Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye *büyük bir* iyilik yapacaksınız!
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
-  CocoaPods'taki çalışmamla ünlüydüm, ama çoğu insan CocoaPods aracının kendisinde gerçek bir iş yapmadığımı bilmiyor. Projedeki zamanım çoğunlukla belgeleme ve markalaşma gibi şeyler yapmakla geçiyor.
-  <p markdown="1" class="pquote-credit">
-- @orta, ["Varsayılan olarak OSS’ye taşıma"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">   CocoaPods'taki çalışmamla ünlüydüm, ama çoğu insan CocoaPods aracının kendisinde gerçek bir iş yapmadığımı bilmiyor. Projedeki zamanım çoğunlukla belgeleme ve markalaşma gibi şeyler yapmakla geçiyor.   <p markdown="1" class="pquote-credit"> - @orta, ["Varsayılan olarak OSS’ye taşıma"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)   </p> </aside>
 
 Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve diğer topluluk üyeleriyle tanışmak için harika bir yoldur. Bu ilişkileri kurmak size projenin diğer bölümlerinde de çalışma fırsatı verecektir.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  İlk önce 17 Haziran 2002 tarihinde düzeltme yamamı e-postayla gönderdiğimde Python geliştirme ekibine (aka python-dev) ulaştım. Hızlı bir şekilde hatayı yakaladım ve grubun e-posta özetlerini iyileştirmeye başladım. Bir konu hakkında net bilgi almak için bana büyük bir bahane verdiler, ama daha kritik olarak, birinin düzeltilmesi gereken bir şeyi işaret ettiğini fark ettim.
-  <p markdown="1" class="pquote-credit">
-- @brettcannon, ["Geliştirme Hikayeleri"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">   İlk önce 17 Haziran 2002 tarihinde düzeltme yamamı e-postayla gönderdiğimde Python geliştirme ekibine (aka python-dev) ulaştım. Hızlı bir şekilde hatayı yakaladım ve grubun e-posta özetlerini iyileştirmeye başladım. Bir konu hakkında net bilgi almak için bana büyük bir bahane verdiler, ama daha kritik olarak, birinin düzeltilmesi gereken bir şeyi işaret ettiğini fark ettim.   <p markdown="1" class="pquote-credit"> - @brettcannon, ["Geliştirme Hikayeleri"](https://github.com/open-source/stories/brettcannon)   </p> </aside>
 
 ### Etkinlik planlamayı sever misiniz?
 
-* [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin
-* Projenin konferansını düzenleyin (eğer varsa)
-* Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun
+- [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin
+- Projenin konferansını düzenleyin (eğer varsa)
+- Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun
 
 ### Tasarlamayı sever misiniz?
 
-* Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın
-* [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın
-* Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın
-* [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın
+- Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın
+- [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın
+- Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın
+- [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın
 
 ### Yazmayı sever misin?
 
-* Proje dokümantasyonunu yazın ve geliştirin
-* Projenin nasıl kullanıldığını gösteren örnekler oluşturun
-* Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın
-* [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın
-* Projenin dokümantasyonu için çeviri yapın
+- Proje dokümantasyonunu yazın ve geliştirin
+- Projenin nasıl kullanıldığını gösteren örnekler oluşturun
+- Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın
+- [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın
+- Projenin dokümantasyonu için çeviri yapın
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
-  Cidden, \[belgeleme\] çok önemlidir. Şu ana kadarki belgeler mükemmeldi ve Babil'in keskin bir özelliği oldu. Bazı özellikleri kesinlikle kullanabilecek bölümler var, hatta burada bir paragrafın eklenmesi bile çok beğeni topluyor.
-  <p markdown="1" class="pquote-credit">
-- @kittens, ["Katkıda bulunanlar için çağrı"](https://github.com/babel/babel/issues/1347)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">   Cidden, \[belgeleme\] çok önemlidir. Şu ana kadarki belgeler mükemmeldi ve Babil'in keskin bir özelliği oldu. Bazı özellikleri kesinlikle kullanabilecek bölümler var, hatta burada bir paragrafın eklenmesi bile çok beğeni topluyor.   <p markdown="1" class="pquote-credit"> - @kittens, ["Katkıda bulunanlar için çağrı"](https://github.com/babel/babel/issues/1347)   </p> </aside>
 
 ### Organize etmeyi sever misiniz?
 
-* Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin
-* Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765)
-* Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun.
+- Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin
+- Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765)
+- Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun.
 
 ### Kod yazmayı sever misiniz?
 
-* [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun
-* Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun
-* Proje kurulumunu otomatikleştirin
-* Araçları ve testleri geliştirin
+- [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun
+- Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun
+- Proje kurulumunu otomatikleştirin
+- Araçları ve testleri geliştirin
 
 ### İnsanlara yardım etmeyi sever misiniz?
 
-* Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te
-* İnsanlar için açık konulardaki soruları cevaplayın
-* Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun
+- Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te
+- İnsanlar için açık konulardaki soruları cevaplayın
+- Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun
 
 ### Başkalarına kod yazarken yardım etmeyi sever misiniz?
 
-* Diğer kişilerin gönderimlerindeki kodu inceleyin
-* Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın
-* Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+- Diğer kişilerin gönderimlerindeki kodu inceleyin
+- Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın
+- Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
 
 ### Sadece yazılım projeleri üzerinde çalışmak zorunda değilsiniz!
 
@@ -147,21 +123,15 @@ Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve d
 
 Örneğin:
 
-* @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome)
-* @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor
-* @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts)
+- @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome)
+- @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor
+- @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts)
 
 Bir yazılım geliştiricisi olsanız bile, bir dokümantasyon projesi üzerinde çalışmak açık kaynak kodla başlamanıza yardımcı olabilir. Kod içermeyen projeler üzerinde çalışmak genellikle daha az korkutucu olur ve işbirliği süreci sizin güven ve deneyiminizi artırır.
 
 ## Kendinizi yeni bir projeye yönlendirmek
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
-  Bir sorun listesine giderseniz ve işler kafa karıştırıcı görünür, yalnız değilsiniz. Bu araçlar çok fazla bilgi gerektirir, ancak insanlar size yardımcı olabilir ve onlara sorular sorabilirsiniz.
-  <p markdown="1" class="pquote-credit">
-- @shaunagm, ["Açık Kaynağa Nasıl Katkıda Bulunulur"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">   Bir sorun listesine giderseniz ve işler kafa karıştırıcı görünür, yalnız değilsiniz. Bu araçlar çok fazla bilgi gerektirir, ancak insanlar size yardımcı olabilir ve onlara sorular sorabilirsiniz.   <p markdown="1" class="pquote-credit"> - @shaunagm, ["Açık Kaynağa Nasıl Katkıda Bulunulur"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)   </p> </aside>
 
 Bir yazım hatasının düzeltilmesinden daha fazla olarak, açık kaynağa katkıda bulunmak, partideki bir grup yabancıyla konuşmaya çalışmak gibidir. Lamalar hakkında konuşmaya başlarsanız, akvaryum balığı ile ilgili derin bir tartışma yapıyorlarsa, muhtemelen size biraz garip bakarlar.
 
@@ -177,34 +147,34 @@ Bununla birlikte, birçok açık kaynak projenin benzer organizasyon yapıların
 
 Tipik bir açık kaynak projesi aşağıdaki insan türlerine sahiptir:
 
-* **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar)
-* **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir)
-* **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler)
-* **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes
-* **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler.
+- **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar)
+- **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir)
+- **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler)
+- **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes
+- **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler.
 
 Daha büyük projeler ayrıca araç yönetimi, öncelik yönetimi, topluluk yönetimi ve etkinlik organizasyonu gibi farklı görevlere odaklanmış alt komitelere veya çalışma gruplarına sahip olabilir. Bu bilgileri bulmak için bir projenin "ekip" sayfasına veya yönetim dokümantasyon deposuna bakın.
 
 Projelerin belgeleri de vardır. Bu dosyalar genellikle bir kütüphanenin dizin yapısının en üst seviyelerinde listelenir.
 
-* **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir.
-* **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar.
-* **CONTRIBUTING:** README dosyaları projeyi insanların _kullanmalarına_ yardımcı olurken, CONTRIBUTING dökümanları insanların projeye _katkıda_ bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder.
-* **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir.
-* **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir.
+- **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir.
+- **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar.
+- **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder.
+- **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir.
+- **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir.
 
 Son olarak, açık kaynak projeler tartışmaları yönetmek için aşağıdaki araçları kullanır. Arşivleri okumak, topluluğun nasıl düşündüğü ve çalıştığı hakkında size iyi bir fikir verecektir.
 
-* **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler.
-* **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler.
-* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine _"Nasıl ...?"_ veya _"Ne düşünüyorsunuz ...?" gibi_). Diğerleri, tüm konuşmalar için sorun listesini kullanır.
-* **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır.
+- **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler.
+- **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler.
+- **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır.
+- **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır.
 
 ## Katkıda bulunacak bir proje bulma
 
 Açık kaynak projelerin nasıl çalıştığını çözdüğünüze göre, katkıda bulunacak bir proje bulma zamanı!
 
-Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, _"Ülkenizin sizin için neler yapabileceğini değil - ülkeniz için neler yapabileceğinizi sorun"_ diyen ABD Başkanı John F. Kennedy'yi  örnek alın.
+Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, *"Ülkenizin sizin için neler yapabileceğini değil - ülkeniz için neler yapabileceğinizi sorun"* diyen ABD Başkanı John F. Kennedy'yi  örnek alın.
 
 Açık kaynağa katkıda bulunmak, farklı projelerde her seviyede gerçekleşir. İlk katkınızın tam olarak ne olacağını veya nasıl görüneceğini düşünmeniz gerekmez.
 
@@ -222,15 +192,15 @@ Düzeltebileceğiniz açık sorunları arıyorsanız, her açık kaynak projenin
 
 Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aşağıdaki kaynaklardan birini de kullanabilirsiniz:
 
-* [GitHub Explore](https://github.com/explore/)
-* [Open Source Friday](https://opensourcefriday.com)
-* [First Timers Only](https://www.firsttimersonly.com/)
-* [CodeTriage](https://www.codetriage.com/)
-* [24 Pull Requests](https://24pullrequests.com/)
-* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
-* [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+- [GitHub Explore](https://github.com/explore/)
+- [Open Source Friday](https://opensourcefriday.com)
+- [First Timers Only](https://www.firsttimersonly.com/)
+- [CodeTriage](https://www.codetriage.com/)
+- [24 Pull Requests](https://24pullrequests.com/)
+- [Up For Grabs](https://up-for-grabs.net/)
+- [Contributor-ninja](https://contributor.ninja)
+- [First Contributions](https://firstcontributions.github.io)
+- [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi
 
@@ -342,13 +312,7 @@ Arkadaş canlısı ve misafirperver bir proje, yeni katılımcılara açık olac
   <label for="cbox17" class="overflow-hidden d-block text-normal">     Geliştiriciler insanlara katkılarından dolayı teşekkür eder mi?   </label>
 </div>
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-  Ne zaman uzun bir tartışma görüyorsanız, çekirdek geliştiricilerin konu başından geç gelen cevaplarını anında kontrol edin. Yapıcı bir şekilde özetliyorlar mı ve kibarlıklarını korurken bir karar vermek için adımlar atıyorlar mı? Çok fazla söz savaşı yaşandığını görüyorsanız, bu genellikle enerjinin gelişme yerine tartışmaya girdiğinin işaretidir.
-  <p markdown="1" class="pquote-credit">
-- @kfogel, [_OPS_ üretiliyor](https://producingoss.com/en/evaluating-oss-projects.html)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">   Ne zaman uzun bir tartışma görüyorsanız, çekirdek geliştiricilerin konu başından geç gelen cevaplarını anında kontrol edin. Yapıcı bir şekilde özetliyorlar mı ve kibarlıklarını korurken bir karar vermek için adımlar atıyorlar mı? Çok fazla söz savaşı yaşandığını görüyorsanız, bu genellikle enerjinin gelişme yerine tartışmaya girdiğinin işaretidir.   <p markdown="1" class="pquote-credit"> - @kfogel, [_OPS_ üretiliyor](https://producingoss.com/en/evaluating-oss-projects.html)   </p> </aside>
 
 ## Nasıl katkı yapılır?
 
@@ -358,45 +322,45 @@ Hoşunuza giden bir proje buldunuz ve katkıda bulunmaya hazırsınız. En sonun
 
 İster bir kerelik bir katkı yapan, ister bir topluluğa katılmaya çalışan biri olun, başkalarıyla çalışmak açık kaynak dünyasında geliştireceğiniz en önemli becerilerden biridir.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
-  \[Yeni bir katılımcı olarak \] ben bir sorunu çözmek istediğimde hemen soru sormam gerektiğini fark ettim. Kod tabanında dolaştım. Bir konunun ne olduğunu anladığıma dair bir şeyler hissettiğimde, daha fazla yardım istemiştim. Ve voilà! İhtiyacım olan tüm detayları aldıktan sonra sorunu çözebildim.
-  <p markdown="1" class="pquote-credit">
-- @shubheksha, [Yeni Başlayanlar İçin Açık Kaynak Dünyasında İnişli Çıkışlı Yolculuk](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">   \[Yeni bir katılımcı olarak \] ben bir sorunu çözmek istediğimde hemen soru sormam gerektiğini fark ettim. Kod tabanında dolaştım. Bir konunun ne olduğunu anladığıma dair bir şeyler hissettiğimde, daha fazla yardım istemiştim. Ve voilà! İhtiyacım olan tüm detayları aldıktan sonra sorunu çözebildim.   <p markdown="1" class="pquote-credit"> - @shubheksha, [Yeni Başlayanlar İçin Açık Kaynak Dünyasında İnişli Çıkışlı Yolculuk](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)   </p> </aside>
 
 Bir sorunu açmadan veya bir PR oluşturmadan ya da sohbette bir soru sormadan önce, fikirlerinizi etkili bir şekilde ortaya çıkarmak için bu noktaları aklınızda bulundurun.
 
 **Bağlam ver.** Başkalarının sizi anlamada hızlanmalarına yardımcı olun. Bir hatayla karşılaşıyorsanız, ne yapmaya çalıştığınızı ve nasıl tekrarlanabileceğini açıklayın. Yeni bir fikir önerecekseniz, neden projeye faydalı olacağını düşündüğünüzü açıklayın (sadece sizin için değil!).
 
-> 😇 _"Y yaptığımda X olmuyor"_
-> X _"X çalışmıyor! Lütfen düzeltin."_
+> 😇 *"Y yaptığımda X olmuyor"*
+>
+> 😢 *"X çalışmıyor! Lütfen düzeltin."*
 
 **Ödevini önceden yap.** Bir şeyleri bilmemek normaldir, ama denediğini göster. Yardım istemeden önce, bir projenin README'sini, belgelerini, sorun listesini (açık veya kapalı), e-posta listesini kontrol ettiğinizden ve bir cevap için interneti aradığınızdan emin olun. Öğrenmeye çalıştığını gösterdiğin zaman insanlar takdir edeceklerdir.
 
-> X _"X'in nasıl uygulanacağından emin değilim. Yardım belgelerini kontrol ettim ve herhangi bir yerde bulamadım."_
-> 😢 _"X nasıl yapılır?"_
+> 😇 *"X'in nasıl uygulanacağından emin değilim. Yardım belgelerini kontrol ettim ve herhangi bir yerde bulamadım."*
+>
+> 😢 <em>"X nasıl yapılır?"</em>
 
 **İstekleri kısa ve öz tutun.** Bir e-posta göndermek gibi, ne kadar basit veya yararlı olursa olsun, her katkı başkasının incelemesini gerektirir. Birçok projenin, yardım için uygunların yapabileceklerinden daha fazla gelen talebi olur. Basit olun. Birinin size yardım edebilme şansını artıracaksınız.
 
-> 😇 _"Bir API öğretici belgesi yazmak istiyorum."_
-> 😢 _"Geçen gün otoyoldan aşağı iniyordum ve benzin için durdum ve sonra aklıma yapmamız gereken bir şey için inanılmaz bir fikir geldi, ama bunu açıklamadan önce sana göstereyim ..."_
+> 😇 *"Bir API öğretici belgesi yazmak istiyorum."*
+>
+> 😢 *"Geçen gün otoyoldan aşağı iniyordum ve benzin için durdum ve sonra aklıma yapmamız gereken bir şey için inanılmaz bir fikir geldi, ama bunu açıklamadan önce sana göstereyim ..."*
 
 **Tüm iletişimi herkese açık tutun.** Her ne kadar cazip olsa da, hassas bilgileri (güvenlik sorunu veya ciddi davranış ihlali gibi) paylaşmanız gerekmedikçe, geliştiricilere özel olarak ulaşmayın. Sohbeti herkese açık tuttuğunuzda, daha fazla kişi alış verişinizden öğrenebilir ve bundan faydalanabilir. Tartışmalar da kendi başlarına katkı sayılabilir.
 
-> 😇 _(yorum olarak) "@-maintainer Merhabalar! Bu PR'a nasıl devam edelim?"_
-> 😢 _(bir e-posta olarak) "Hey, e-posta yüzünden sizi rahatsız ettiğim için özür dilerim, ancak PR'mi gözden geçirme şansınız olup olmadığını merak ediyordum"_
+> 😇 *(yorum olarak) "@-maintainer Merhabalar! Bu PR'a nasıl devam edelim?"*
+>
+> 😢 *(bir e-posta olarak) "Hey, e-posta yüzünden sizi rahatsız ettiğim için özür dilerim, ancak PR'mi gözden geçirme şansınız olup olmadığını merak ediyordum"*
 
 **Soru sormak sorun değil (ama sabırlı olun!).** Herkes bir zamanlar projede yeniydi ve deneyimli katılımcıların bile yeni bir projeye bakarken hız kazanmaları gerekiyor. Aynı şekilde, uzun süredir devam edenler bile, projenin her bölümüne aşina değildir. Onlara size göstermelerini istediğiniz sabrı gösterin.
 
-> 😇 _"Bu hatayı incelediğiniz için teşekkür ederiz. Önerilerinizi takip ettim. İşte sonuç."_
-> 😢 _"Neden sorunumu çözemiyorsun? Bu senin projen değil mi?"_
+> 😇 *"Bu hatayı incelediğiniz için teşekkür ederiz. Önerilerinizi takip ettim. İşte sonuç."*
+>
+> 😢 *"Neden sorunumu çözemiyorsun? Bu senin projen değil mi?"*
 
 **Topluluk kararlarına saygı gösterin.** Fikirleriniz, toplumun öncelikleri veya vizyonundan farklı olabilir. Geri bildirim sunabilir veya fikrinizi sürdürmemeye karar verebilirler. Tartışmanız ve uzlaşı aramanız gerekirken, geliştiriciler kararınızla sizden daha uzun yaşamak zorundadır. Düşüncelerine katılmıyorsanız, her zaman kendi çatalınızla çalışabilir veya kendi projenizi başlatabilirsiniz.
 
-> 😇 _"Fikrimi destekleyemediğiniz için hayal kırıklığına uğradım, ancak bunun sadece kullanıcıların küçük bir bölümünü etkilediğini açıkladığınızdan, nedenini anlıyorum. Dinlediğiniz için teşekkürler."_
-> 😢 _"Neden fikrimi desteklemiyorsun? Bu kabul edilemez!"_
+> 😇 *"Fikrimi destekleyemediğiniz için hayal kırıklığına uğradım, ancak bunun sadece kullanıcıların küçük bir bölümünü etkilediğini açıkladığınızdan, nedenini anlıyorum. Dinlediğiniz için teşekkürler."*
+>
+> 😢 *"Neden fikrimi desteklemiyorsun? Bu kabul edilemez!"*
 
 **Her şeyden önce, zarif olun.** Açık kaynak dünyanın her yerinden ortak çalışanlardan oluşur. Bağlam diller, kültürler, coğrafyalar ve zaman dilimleri arasında kaybolur. Ek olarak, yazılı iletişim bir ton veya ruh halini iletmeyi zorlaştırır. Bu konuşmaların niyetlerinin iyi olduğunu düşünün. Bir fikre kibarca geri dönmek, daha fazla içerik istemek veya konumunuzu daha da netleştirmek iyi bir şey. İnterneti bulduğunuzdan daha iyi bir yer bırakmaya çalışın.
 
@@ -406,53 +370,47 @@ Herhangi bir şey yapmadan önce, fikrinizin başka bir yerde tartışılmadığ
 
 Fikrinizi başka bir yerde bulamazsanız, harekete geçmeye hazırsınız. Proje GitHub'taysa, muhtemelen bir sorun açarak veya PR oluşturarak iletişim kurarsınız:
 
-* **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir
-* **PR** bir çözüm üzerinde çalışmaya başlamak içindir
-* **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin.
+- **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir
+- **PR** bir çözüm üzerinde çalışmaya başlamak içindir
+- **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin.
 
 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.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
-  Aktif olarak kullandığınız bir projeyi seçmek, GitHub'da “izlemek” ve her konuyu ve PR'ı okumaktan <em>çok şey</em> öğreneceksiniz.
-  <p markdown="1" class="pquote-credit">
-- @gaearon [birleştirme projelerinde](https://twitter.com/dan_abramov/status/819555257055322112)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">   Aktif olarak kullandığınız bir projeyi seçmek, GitHub'da “izlemek” ve her konuyu ve PR'ı okumaktan <em>çok şey</em> öğreneceksiniz.   <p markdown="1" class="pquote-credit"> - @gaearon [birleştirme projelerinde](https://twitter.com/dan_abramov/status/819555257055322112)   </p> </aside>
 
 ### Bir istek/sorun açmak
 
 Genellikle aşağıdaki durumlarda bir sorun açmalısınız:
 
-* Çözemediğiniz bir hatayı bildirmek için
-* Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar)
-* Yeni bir özellik veya başka bir proje fikri önermek için
+- Çözemediğiniz bir hatayı bildirmek için
+- Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar)
+- Yeni bir özellik veya başka bir proje fikri önermek için
 
 Sorunlar üzerinde iletişim kurmak için ipuçları:
 
-* **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır.
-* **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın.
-* **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır.
+- **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır.
+- **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın.
+- **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır.
 
 ### PR açma
 
 Genellikle aşağıdaki durumlarda bir PR açmalısınız:
 
-* Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata)
-* Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda
+- Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata)
+- Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda
 
 Bir PR, bitmiş işi temsil etmek zorunda değildir. PR'ı erkenden açmak genellikle daha iyidir, bu nedenle diğerleri ilerlemeniz hakkında fikir sahibi olabilir veya geribildirimde bulunabilir. Sadece konu satırında bir "WIP" (Çalışmakta Olan Çalışma) etiketi ile işaretlemeniz yeterlidir. Daha sonra her zaman daha fazla geliştirme ekleyebilirsiniz.
 
 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.)
-* 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.
-* **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun.
-* **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır.
+- **[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.)
+- 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.
+- **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun.
+- **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır.
 
 Bu ilk PR ise, @kentcdodds'ın bir örnek video eğitimi olarak oluşturduğu [Bir PR Yap](http://makeapullrequest.com/)'ı izleyin. Ayrıca, @Roshanjossey tarafından oluşturulan [First Contributions](https://github.com/Roshanjossey/first-contributions) deposunda çekme isteği yapmayı da deneyebilirsiniz.
 
@@ -464,7 +422,7 @@ Katkınızı gönderdikten sonra, aşağıdakilerden biri olacaktır:
 
 ### 😭 Hiç bir cevap almazsınız.
 
-Umarım bir katkı yapmadan önce [projeyi faaliyet belirtileri açısından kontrol](#katkıda-bulunmadan-önce-üzerinden-geçilebilecek-bir-kontrol-listesi) ettiniz. Ancak aktif bir projede bile, katkınızın yanıt alamaması olası.
+Umarım bir katkı yapmadan önce [projeyi faaliyet belirtileri açısından kontrol](#katk%C4%B1da-bulunmadan-%C3%B6nce-%C3%BCzerinden-ge%C3%A7ilebilecek-bir-kontrol-listesi) ettiniz. Ancak aktif bir projede bile, katkınızın yanıt alamaması olası.
 
 Bir haftadan uzun bir süredir yanıt alamadıysanız, aynı konuya kibarca yorum yazmak, birinden inceleme istemek doğru olur. Katkınızı gözden geçirecek doğru kişinin adını biliyorsanız, bunları o konuya ekleyebilirsiniz (@).
 

From 1969f16cf07f1a3ac3c7b9bb47e9c11491124399 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Sun, 9 May 2021 23:56:02 +0000
Subject: [PATCH 164/749] Translate code-of-conduct.md via GitLocalize

---
 _articles/tr/code-of-conduct.md | 46 +++++++++++++--------------------
 1 file changed, 18 insertions(+), 28 deletions(-)

diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md
index afc8f06f843..9ba8ff26e3b 100644
--- a/_articles/tr/code-of-conduct.md
+++ b/_articles/tr/code-of-conduct.md
@@ -7,9 +7,9 @@ toc:
   why-do-i-need-a-code-of-conduct: Neden bir davranış kural listesine ihtiyacım var?
   establishing-a-code-of-conduct: Davranış kuralları oluşturmak
   deciding-how-youll-enforce-your-code-of-conduct: Davranış kurallarınızı nasıl uygulayacağınıza karar verme
-  enforcing-your-code-of-conduct: Davranış kurallarınızı güçlendirmek
+  enforcing-your-code-of-conduct: Davranış kurallarınızı uygulama
   your-responsibilities-as-a-maintainer: Bir koruyucu olarak sorumluluklarınız
-order: 8
+order: '8'
 image: "/assets/images/cards/coc.png"
 related:
   - building
@@ -30,10 +30,10 @@ Mümkün olduğunca en erken zamanda bir davranış kural listesi oluşturmaya 
 
 Beklentilerinizi iletmenin yanı sıra, bir davranış kural listesi aşağıdakileri de açıklar:
 
-* Davranış kuralları nerede yürürlüğe girer _(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)_?
-* Davranış kuralları kimin için geçerlidir _(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)_?
-* Birisi davranış kurallarını ihlal ederse ne olur?
-* İhlaller nasıl rapor edilebilir?
+- Davranış kuralları nerede yürürlüğe girer *(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)*?
+- Davranış kuralları kimin için geçerlidir *(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)*?
+- Birisi davranış kurallarını ihlal ederse ne olur?
+- İhlaller nasıl rapor edilebilir?
 
 Nerede olursanız olun, geçmiş tecrübelerden faydalanın. [Katkıda Bulunanlar Sözleşmesi (Contributor Covenant)](https://contributor-covenant.org/) Kubernet, Rails ve Swift dahil olmak üzere 40.000'den fazla açık kaynaklı proje tarafından kullanılan ortak bir davranış kural listesidir.
 
@@ -43,20 +43,15 @@ CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTIN
 
 ## Davranış kurallarınızı nasıl uygulayacağınıza karar verme
 
-<aside markdown="1" class="pquote">
-  Uygulanmayan (veya uygulanamayan) bir davranış kural listesi, hiçbir davranış kuralı olmamasından daha kötüdür: davranış kurallarındaki değerlerin, sizin toplumunuzda gerçekten önemli veya saygı duyulmadığı mesajını gönderir.
-  <p markdown="1" class="pquote-credit">
-- [Ada Girişimi](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   Uygulanmayan (veya uygulanamayan) bir davranış kural listesi, hiçbir davranış kuralı olmamasından daha kötüdür: davranış kurallarındaki değerlerin, sizin toplumunuzda gerçekten önemli veya saygı duyulmadığı mesajını gönderir.   <p markdown="1" class="pquote-credit"> - [Ada Girişimi](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)   </p> </aside>
 
-Bir ihlal meydana _gelmeden önce_ davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var:
+Bir ihlal meydana *gelmeden önce* davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var:
 
-* İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir.
+- İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir.
 
-* Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir.
+- Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir.
 
-* Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz.
+- Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz.
 
 İnsanlara davranış kuralları ihlalini bildirebilmeleri için özel bir yol (e-posta adresi gibi) vermelisiniz ve bu raporun kimlere ulaştığını açıklamalısınız. Bu bir kurucu, bir geliştirme grubu veya bir davranış kuralları çalışma grubu olabilir.
 
@@ -66,7 +61,7 @@ Birisinin, bu raporları alan bir kişi hakkındaki ihlali bildirmek isteyebilec
 
 İlham almak için Django'nun [uygulama kılavuzunu inceleyin](https://www.djangoproject.com/conduct/enforcement-manual/) (ancak projenizin büyüklüğüne bağlı olarak bu kadar kapsamlı bir şeye ihtiyacınız olmayabilir).
 
-## Davranış kural listesini güçlendirmek
+## Davranış kurallarınızı güçlendirmek
 
 Bazen, en iyi çabalarınıza rağmen, birileri bu kodu ihlal eden bir şey yapabilir. Olay ortaya çıktığında olumsuz ya da zararlı davranışları ele almanın birkaç yolu vardır.
 
@@ -78,12 +73,7 @@ Söz konusu topluluk üyesi, sürekli olarak başkalarını rahatsız hissetmesi
 
 Cevap vermeden önce, neler olduğunu anlamak için biraz zaman harcayın. Kim olduklarını ve neden böyle davrandıklarını daha iyi anlamak için, kişi ya da kişilerin geçmiş yorumlarını ve konuşmalarını okuyun. Bu kişi ve davranışları hakkındaki kendi görüşleriniz dışında başka bakış açıları da toplamaya çalışın.
 
-<aside markdown="1" class="pquote">
-  Bir tartışmaya girmeyin. Eldeki konuyla ilgilenmeyi bitirmeden önce başkasının davranışlarıyla başa çıkmayın. İhtiyacınız olana odaklanın.
-  <p markdown="1" class="pquote-credit">
-- Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   Bir tartışmaya girmeyin. Eldeki konuyla ilgilenmeyi bitirmeden önce başkasının davranışlarıyla başa çıkmayın. İhtiyacınız olana odaklanın.   <p markdown="1" class="pquote-credit"> - Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)   </p> </aside>
 
 ### Uygun işlemi yapın
 
@@ -93,15 +83,15 @@ Birisi bir davranış kuralları ihlali bildirdiğinde, bu durumla yüzleşmesi
 
 Bir davranış kural ihlaline yanıt vermenin birkaç yolu vardır:
 
-* **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun.
+- **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun.
 
-* Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin.
+- Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin.
 
 Bazen bir çözüme ulaşılamaz. Söz konusu kişi karşı karşıya geldiğinde saldırgan veya düşmanca olabilir veya davranışlarını değiştirmez. Bu durumda, daha güçlü bir işlem yapmayı düşünebilirsiniz. Örneğin:
 
-* Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz**
+- Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz**
 
-* Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz**
+- Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz**
 
 Kalıcı olarak yasaklama üyeleri kolayca alınmamalı ve kalıcı uzlaşmaz bir bakış açısı farklılığını temsil etmelidir. Bu önlemleri yalnızca bir çözüme ulaşılamayacağı açıksa almalısınız.
 
@@ -111,7 +101,7 @@ Davranış kuralları, keyfi olarak uygulanan bir yasa değildir. Davranış kur
 
 Proje sahibi olarak, topluluğunuz için kılavuz ilkeler belirler ve bu ilkeleri davranış kurallarınızda belirtilen kurallara uygun olarak uygularsınız. Bu, herhangi bir davranış kuralları ihlali raporunu ciddiye almak anlamına gelir. İhbar eden şikayeti hakkında kapsamlı ve adil bir inceleme yapılmasını hak eder. Bildirdikleri davranışların bir ihlal olmadığını belirlerseniz, bunu açıkça belirtin ve neden bu konuda harekete geçmeyeceğinizi açıklayın. Bununla ne yapacakları onlara bağlı: Sorunlu olduğunu düşündükleri davranışlara hoşgörü gösterirler veya topluluktan ayrılabilirler.
 
-_Teknik_ olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir.
+*Teknik* olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir.
 
 Sonunda, bir proje sahibi olarak, kabul edilebilir davranış için standartları belirler ve uygularsınız. Projenin topluluk değerlerini şekillendirme yetkiniz var ve katılımcılar bu değerleri adil ve eşit bir şekilde uygulamanızı beklerler.
 

From 49fbda6b00bfbffed71b9465b23e6986373b0953 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Sun, 9 May 2021 23:57:36 +0000
Subject: [PATCH 165/749] Translate finding-users.md via GitLocalize

---
 _articles/tr/finding-users.md | 79 +++++++----------------------------
 1 file changed, 16 insertions(+), 63 deletions(-)

diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md
index a3753a58406..914ee05a185 100644
--- a/_articles/tr/finding-users.md
+++ b/_articles/tr/finding-users.md
@@ -10,7 +10,7 @@ toc:
   go-where-your-projects-audience-is-online: Projenizin izleyicisinin (çevrimiçi) olduğu yere gidin
   go-where-your-projects-audience-is-offline: Projenizin kitlesinin (çevrimdışı) olduğu yere gidin
   build-a-reputation: Bir itibar oluşturun
-order: 3
+order: '3'
 image: "/assets/images/cards/finding.png"
 related:
   - beginners
@@ -27,7 +27,7 @@ Projenizi tanıtmaya yönelik asıl çalışmaya başlamadan önce, ne yaptığ
 
 Projenizi farklı veya ilginç kılan nedir? Neden yarattınız? Bu soruları kendiniz cevaplamak, projenizin önemini bildirmenize yardımcı olacaktır.
 
-İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, _kullanıcıların ve katkıda bulunanların_ ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın.
+İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, *kullanıcıların ve katkıda bulunanların* ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın.
 
 Örneğin, @robb, projesi olan [Cartography'nin](https://github.com/robb/Cartography) neden faydalı olduğunu açıkça belirtmek için kod örnekleri kullanır:
 
@@ -37,12 +37,7 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa
 
 ## İnsanların projenizi bulmasına ve takip etmesine yardımcı olun
 
-<aside markdown="1" class="pquote">
-  İdeal olarak, insanları projenizle ilgili olarak tanıtabileceğiniz ve işaret edebileceğiniz tek bir "anasayfa" URL'sine ihtiyacınız var. Süslü bir şablona, hatta etkili bir alan adına sahip olmanıza gerek yoktur, ancak projenizin bir odak noktasına ihtiyacı vardır.
-  <p markdown="1" class="pquote-credit">
-- Peter Cooper ve Robert Nyman, ["Kodunuzun Mesajı Nasıl Yayılır"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   İdeal olarak, insanları projenizle ilgili olarak tanıtabileceğiniz ve işaret edebileceğiniz tek bir "anasayfa" URL'sine ihtiyacınız var. Süslü bir şablona, hatta etkili bir alan adına sahip olmanıza gerek yoktur, ancak projenizin bir odak noktasına ihtiyacı vardır.   <p markdown="1" class="pquote-credit"> - Peter Cooper ve Robert Nyman, ["Kodunuzun Mesajı Nasıl Yayılır"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)   </p> </aside>
 
 İnsanların projenizi tek bir alana işaret ederek bulup hatırlamalarına yardımcı olun.
 
@@ -50,17 +45,11 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa
 
 Henüz projeniz için iletişim noktaları kurmak istemiyorsanız, yaptığınız her şeyde kendi Twitter veya GitHub hesabınızı tanıtın. Twitter veya GitHub hesabınızı tanıtmak, insanların sizinle nasıl iletişim kurabileceklerini veya işlerinizi takip etmelerini sağlayacaktır. Bir buluşma veya etkinlikte konuşuyorsanız, iletişim bilgilerinizin biyo veya slaytlarınıza eklendiğinden emin olun.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
-  Bu ilk günlerde yaptığım bir hata (...) proje için Twitter hesabı oluşturmamaktı. Twitter, insanları bir proje hakkında güncel tutmak ve insanları projeyle sürekli iletişimde bırakmak için harika bir yol.
-  <p markdown="1" class="pquote-credit">
-- @nathanmarz, ["Apache Storm'un ve Öğrenilen Derslerin Tarihi"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">   Bu ilk günlerde yaptığım bir hata (...) proje için Twitter hesabı oluşturmamaktı. Twitter, insanları bir proje hakkında güncel tutmak ve insanları projeyle sürekli iletişimde bırakmak için harika bir yol.   <p markdown="1" class="pquote-credit"> - @nathanmarz, ["Apache Storm'un ve Öğrenilen Derslerin Tarihi"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)   </p> </aside>
 
 **Projeniz için bir web sitesi oluşturmayı düşünün.** Bir web sitesi, projenizi daha net hale getirir ve özellikle açık belgeler ve eğitimlerle desteklendiğinde gezinmeyi kolaylaştırır. Bir web sitesine sahip olmak, projenizin aktif olduğunu ve bu sayede hedef kitlenizin kendisini daha rahat hissetmesini sağlayacaktır. İnsanlara projenizi nasıl kullanacakları hakkında fikir vermek için örnekler verin.
 
-Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin _"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi_.
+Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin *"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi*.
 
 Projeniz GitHub'da barındırıyorsanız, kolayca web sitesi yapmak için [GitHub Pages](https://pages.github.com/) kullanabilirsiniz. [Yeoman](http://yeoman.io/) , [Vagrant](https://www.vagrantup.com/) ve [Middleman](https://middlemanapp.com/) mükemmel, kapsamlı web sitelerine [birkaç örnektir](https://github.com/showcases/github-pages-examples) .
 
@@ -68,31 +57,25 @@ Projeniz GitHub'da barındırıyorsanız, kolayca web sitesi yapmak için [GitHu
 
 Artık projeniz için bir mesajınız ve insanların projenizi bulmaları için kolay bir yolu olsun, haydi çıkıp izleyicilerinizle konuşun!
 
-## Projenizin izleyicisinin (çevrimiçi) olduğu yere gidin
+## Projenizin hedef kitlesinin olduğu yere gidin (çevrimiçi olarak)
 
 Çevrimiçi sosyal yardım, mesajınızı hızla paylaşmanın ve yaymanın harika bir yoludur. Çevrimiçi kanalları kullanarak, çok geniş bir kitleye ulaşma potansiyeline sahip olursunuz.
 
 Hedef kitlenize ulaşmak için mevcut çevrimiçi topluluklardan ve platformlardan yararlanın. Açık kaynaklı projeniz bir yazılım projesiyse, kitlenizi [Stack Overflow](https://stackoverflow.com/) , [Reddit](https://www.reddit.com) , [Hacker News](https://news.ycombinator.com/) veya [Quora](https://www.quora.com/)'da bulabilirsiniz. İnsanların işinizden en çok faydalanabileceğini veya heyecanlanacağını düşündüğünüz kanalları bulun.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
-  Her programın, kullanıcıların yalnızca bir kısmının yararlı bulacağı çok özel işlevleri vardır. Mümkün olduğunca çok insana spam yapmayın. Bunun yerine, çabalarınızı projeniz hakkında bilgi sahibi olmaktan yararlanacak topluluklara hedefleyin.
-  <p markdown="1" class="pquote-credit">
-- @pazdera, ["Açık kaynak projeleri için pazarlama"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">   Her programın, kullanıcıların yalnızca bir kısmının yararlı bulacağı çok özel işlevleri vardır. Mümkün olduğunca çok insana spam yapmayın. Bunun yerine, çabalarınızı projeniz hakkında bilgi sahibi olmaktan yararlanacak topluluklara hedefleyin.   <p markdown="1" class="pquote-credit"> - @pazdera, ["Açık kaynak projeleri için pazarlama"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)   </p> </aside>
 
 Projenizi ilgili kanallarda paylaşmanın yollarını bulabilecek misiniz bir bakın:
 
-* **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır.
-* **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun.
-* **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: _"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum_ ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin.
+- **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır.
+- **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun.
+- **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin.
 
 Genel olarak konuşursak, karşılığında bir şey istemeden önce başkalarına yardım etmeye odaklanın. Herkes bir projeyi çevrimiçi olarak kolayca tanıtabildiğinden, çok fazla gürültü çıkacaktır. Kalabalıktan sıyrılmak için, insanlara sadece ne istediğinizi değil, kim olduğunuzu anlatmaya çalışın.
 
 İlk duyurularınız hiç kimsesin dikkatini çekmiyorsa veya kimse cevap vermiyorsa, cesaretini kırmayın! Çoğu proje lansmanı aylar veya yıllar alabilen yinelemeli bir süreçtir. İlk kez bir yanıt alamazsanız, farklı bir taktik deneyin veya başkalarının çalışmalarına ilk olarak değer katmanın yollarını arayın. Projenizi tanıtmak ve başlatmak zaman ve özveri gerektirir.
 
-## Projenizin kitlesinin (çevrimdışı) olduğu yere gidin
+## Projenizin hedef kitlesinin olduğu yere gidin (çevrimdışı)
 
 ![Public speaking](/assets/images/finding-users/public_speaking.jpg)
 
@@ -100,37 +83,19 @@ Genel olarak konuşursak, karşılığında bir şey istemeden önce başkaları
 
 [Topluluk karşısında konuşma konusunda](https://speaking.io/) yeniyseniz, projenizin dili veya ekosistemiyle ilgili yerel bir buluşma bularak başlayın.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
-  PyCon'a giderken oldukça gergindim. Bir konuşma yapıyordum, sadece birkaç kişiyi tanıyacaktım, bir hafta boyunca gidecektim. (...) Yine de bu kadar endişelenmemeliydim. PyCon olağanüstü bir harikaydı! (...) Herkes inanılmaz derecede cana yakın ve paylaşımcıydı, o kadar ki nadiren ben de konuşmak için fırsat bulabildim!
-  <p markdown="1" class="pquote-credit">
-- @jhamrick, ["Endişelenmeyi Durdurmayı ve PyCon'u Sevmeyi Nasıl Öğreniyorum"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">   PyCon'a giderken oldukça gergindim. Bir konuşma yapıyordum, sadece birkaç kişiyi tanıyacaktım, bir hafta boyunca gidecektim. (...) Yine de bu kadar endişelenmemeliydim. PyCon olağanüstü bir harikaydı! (...) Herkes inanılmaz derecede cana yakın ve paylaşımcıydı, o kadar ki nadiren ben de konuşmak için fırsat bulabildim!   <p markdown="1" class="pquote-credit"> - @jhamrick, ["Endişelenmeyi Durdurmayı ve PyCon'u Sevmeyi Nasıl Öğreniyorum"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)   </p> </aside>
 
 Daha önce topluluk önünde konuşmadıysanız, gergin hissetmek tamamen normaldir! İzleyicilerinizin sizin için orada olduğunu unutmayın, çünkü işinizi gerçekten duymak istiyorlar.
 
 Konuşmanızı yazarken, izleyicilerinizin ilginç bulacağı ve değer kazanacağı şeylere odaklanın. Dilinizi arkadaşça ve ulaşılabilir tutun. Gülümseyin, nefes alın ve eğlenin.
 
-<aside markdown="1" class="pquote">
-  <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
-  Konuşmanızı yazmaya başladığınızda, konunuz ne olursa olsun, konuşmanızı insanlara anlattığınız bir hikaye olarak görmeniz yararlı olabilir.
-  <p markdown="1" class="pquote-credit">
-- Lena Reinhard, ["Teknik Konferans Konuşması Nasıl Hazırlanır ve Yazılır"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">   Konuşmanızı yazmaya başladığınızda, konunuz ne olursa olsun, konuşmanızı insanlara anlattığınız bir hikaye olarak görmeniz yararlı olabilir.   <p markdown="1" class="pquote-credit"> - Lena Reinhard, ["Teknik Konferans Konuşması Nasıl Hazırlanır ve Yazılır"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)   </p> </aside>
 
 Hazır olduğunuzda, projenizi tanıtmak için bir konferansta konuşmayı düşünün. Konferanslar, bazen dünyanın her yerinden daha fazla insana ulaşmanıza yardımcı olabilir.
 
 Dilinize veya ekosisteminize özgü konferansları arayın. Konuşmanızı göndermeden önce, konuşmanızı katılımcılar için uyarlamak ve konferansta konuşma kabul etme şansınızı artırmak için konferansı araştırın. Konferansın konuşmacılarına bakarak, izleyicilerinizi daha kolay anlayabilirsiniz.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
-  JSConf insanlarına çok hoş bir şekilde yazdım ve bana JSConf AB'de sunabileceğim bir yer vermeleri için yalvardım. (...) Altı aydır üzerinde çalıştığım bu şeyi sunarken son derece korktum. (...) Bütün konuşma sırasında şunu düşündüm. Aman tanrım, burada ne yapıyorum?
-  <p markdown="1" class="pquote-credit">
-- @ry, ["Node.js'nin Hikayesi" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">   JSConf insanlarına çok hoş bir şekilde yazdım ve bana JSConf AB'de sunabileceğim bir yer vermeleri için yalvardım. (...) Altı aydır üzerinde çalıştığım bu şeyi sunarken son derece korktum. (...) Bütün konuşma sırasında şunu düşündüm. Aman tanrım, burada ne yapıyorum?   <p markdown="1" class="pquote-credit"> - @ry, ["Node.js'nin Hikayesi" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&amp;t=24m57s)   </p> </aside>
 
 ## Bir itibar oluşturun
 
@@ -138,25 +103,13 @@ Yukarıda belirtilen stratejilere ek olarak, insanları projenizi paylaşmaya ve
 
 Yeni gelenlere yardım etmek, kaynakları paylaşmak ve başkalarının projelerine anlamlı katkılar yapmak olumlu bir itibara kavuşmanıza yardımcı olacaktır. Açık kaynak topluluğunda aktif bir üye olmak, insanların çalışmanız için bağlam oluşturmasına yardımcı olacak ve projenize dikkat etme ve paylaşma olasılıkları artacaktır. Diğer açık kaynaklı projelerle ilişkilerin geliştirilmesi resmi ortaklıklara yol açabilir.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
-  Urllib3'ün günümüzdeki en popüler üçüncü parti Python kütüphanesi olmasının tek nedeni isteklerin parçası olmasıdır.
-  <p markdown="1" class="pquote-credit">
-- @shazow, ["Açık kaynak projeniz nasıl gelişir?"](Https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">   Urllib3'ün günümüzdeki en popüler üçüncü parti Python kütüphanesi olmasının tek nedeni isteklerin parçası olmasıdır.   <p markdown="1" class="pquote-credit"> - @shazow, ["Açık kaynak projeniz nasıl gelişir?"](Https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)   </p> </aside>
 
 İtibarınızı oluşturmak için asla çok erken veya geç değildir. Kendi projenizi daha önce başlatmış olsanız bile, başkalarına yardım etmenin yollarını aramaya devam edin.
 
 Kitle oluşturmak için bir gecede çözüm yoktur. Başkalarının güvenini ve saygısını kazanmak zaman alır ve itibarınızı geliştirmek hiç tamamlanmayan bir iştir.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS ilk kez 2011 yılının başında piyasaya sürüldü. (...) Mesajını her zamanki gibi yaydım: Tweetledim, yapabileceğin şeyler hakkında blog yazıları yazdım, buluşmalarda çeşitli tartışmalar sırasında bahsettim. 2014 yılında daha iyi tanındığında, onunla ilgili sunumlar yapmaya başladım.
-  <p markdown="1" class="pquote-credit">
-- @ariya, ["Geliştirici Hikayeleri"](https://github.com/open-source/stories/ariya) 
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">   PhantomJS ilk kez 2011 yılının başında piyasaya sürüldü. (...) Mesajını her zamanki gibi yaydım: Tweetledim, yapabileceğin şeyler hakkında blog yazıları yazdım, buluşmalarda çeşitli tartışmalar sırasında bahsettim. 2014 yılında daha iyi tanındığında, onunla ilgili sunumlar yapmaya başladım.   <p markdown="1" class="pquote-credit"> - @ariya, ["Geliştirici Hikayeleri"](https://github.com/open-source/stories/ariya)    </p> </aside>
 
 ## Devam et!
 

From a1a39d7ee96ac9136dc68ecce7a28f4cb5e033c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 10 May 2021 00:06:28 +0000
Subject: [PATCH 166/749] Translate starting-a-project.md via GitLocalize

---
 _articles/tr/starting-a-project.md | 184 ++++++++++-------------------
 1 file changed, 62 insertions(+), 122 deletions(-)

diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index a466eb48bd2..b5d1598305a 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -9,11 +9,11 @@ toc:
   launching-your-own-open-source-project: Kendi açık kaynak projenizi başlatmak
   naming-and-branding-your-project: Projenizi isimlendirme ve markalama
   your-pre-launch-checklist: Lansman öncesi kontrol listeniz
-order: 2
-image: /assets/images/cards/beginner.png
+order: '2'
+image: "/assets/images/cards/beginner.png"
 related:
-- finding
-- building
+  - finding
+  - building
 ---
 
 ## Açık kaynağın "nedir"i ve "neden"i
@@ -26,25 +26,19 @@ Bir proje açık kaynak olduğunda, **herhangi biri herhangi bir amaç için pro
 
 Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek, benimseme engellerini azaltır. Ayrıca, kullanıcılara kapalı kaynağa göre kendi bilgisayarlarını ve bilgisayarlarında çalışan işlemleri kontrol etme imkanı da verir. Örneğin, açık kaynak yazılım kullanan bir işletme, yalnızca kapalı kaynak satıcısının ürün kararlarına güvenmek yerine, bir kişiyi yazılımda özel iyileştirmeler yapması için işe alma seçeneğine sahiptir.
 
-_Özgür yazılım_ , _açık kaynak ile_ aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. _Free_ ve  _Libre_ özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor).
+*Özgür yazılım* , *açık kaynak ile* aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. *Free* ve  *Libre* özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor).
 
 ### İnsanlar neden işlerini açık kaynak olarak sunarlar?
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
-  Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.
-  <p markdown="1" class="pquote-credit">
-— @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">   Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.   <p markdown="1" class="pquote-credit"> — @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)   </p> </aside>
 
 Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler:
 
-* **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur.
+- **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur.
 
-* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
+- **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
 
-* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
+- **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
 
 Açık kaynak sadece yazılım için değil. Veri kümelerinden kitaplara kadar her şeyi açık kaynak koduyla açabilirsiniz. Açık kaynak başka neler yapabileceğiniz hakkında fikir edinmek için [GitHub Explore](https://github.com/explore)'a göz atın.
 
@@ -68,19 +62,13 @@ Henüz ikna olmadıysanız, hedeflerinizin ne olabileceğini düşünmek için b
 
 ### Hedeflerinizi belirlemek
 
-Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, _neden bu projeye kaynak açıyorum?_
+Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, *neden bu projeye kaynak açıyorum?*
 
 Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahip farklı projeler için birden fazla hedefiniz olabilir.
 
 Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
-  Bir noktada kullandığım özel bir UIAlertView yarattım ... ve açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca diğer geliştiricilere projelerinde nasıl kullanacaklarını açıklayan ilk belgelerimi yazdım. Muhtemelen hiç kimse onu kullanmamıştı çünkü basit bir projeydi ama katkım konusunda kendimi iyi hissediyordum.
-  <p markdown="1" class="pquote-credit">
-— @mavris, ["Kendi Kendine Öğrenen Yazılım Geliştiricileri: Açık Kaynak Neden Bizim İçin Önemli?"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">   Bir noktada kullandığım özel bir UIAlertView işlevi oluşturdum ... ve onu açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca, diğer geliştiricilere projelerinde nasıl kullanılacağını açıklayan ilk belgelerimi de yazdım. Muhtemelen hiç kimse bunu kullanmamıştı çünkü bu basit bir projeydi ama katkım hakkında kendimi iyi hissediyordum.   <p markdown="1" class="pquote-credit"> — @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)   </p></aside>
 
 Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir.
 
@@ -90,13 +78,7 @@ Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve
 
 Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-  Projeyi açmaya başladığınızda, yönetim süreçlerinizin projenizdeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. İşletmenizde istihdam edilmeyen katılımcıları, projenin kilit noktalarına dahil etmekten korkmayın - özellikle de sık sık katkıda bulunanlarsa.
-  <p markdown="1" class="pquote-credit">
-— @captainsafia, ["Öyleyse bir açık kaynak proje açmak istiyorsun, ha?"](Https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">   Projeyi açık kaynak yapmaya başladığınızda, yönetim süreçlerinizin projenizin çevresindeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. Şirketinizde çalışmayan katılımcıları projenin kilit yönlerine dahil etmekten korkmayın - özellikle de sık sık katkıda bulunanlarsa.   <p markdown="1" class="pquote-credit"> — @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)   </p></aside>
 
 ### Diğer projelere katkıda bulunmak
 
@@ -112,24 +94,24 @@ 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/)
-* [Davranış kuralları](../code-of-conduct/)
+- [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/)
+- [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.
 
-Projeniz GitHub'taysa, bu dosyaları önerilen dosya adlarıyla kök dizininize koymak GitHub'ın onları okuyucularınıza tanıtmasına ve otomatik olarak göstermesine yardımcı olacaktır.
+Projeniz GitHub'daysa, bu dosyaları önerilen dosya adlarıyla kök dizininize koymak, GitHub'ın bunları tanımasına ve okuyucularınız için otomatik olarak ortaya çıkarmasına yardımcı olur.
 
 ### Bir lisans seçimi
 
-Açık kaynaklı lisans, başkalarının projenize yanıt vermeden kullanabileceğini, kopyalayabileceğini, değiştirebileceğini ve katkıda bulunabileceğini garanti eder. Aynı zamanda sizi kötü yasal durumlardan korur. **Açık kaynak kodlu bir proje başlatırken projenize bir lisans eklemelisiniz.**
+Projeniz GitHub'taysa, bu dosyaları önerilen dosya adlarıyla kök dizininize koymak GitHub'ın onları okuyucularınıza tanıtmasına ve otomatik olarak göstermesine yardımcı olacaktır.
 
 Açık kaynaklı lisans, başkalarının projenize yanıt vermeden kullanabileceğini, kopyalayabileceğini, değiştirebileceğini ve katkıda bulunabileceğini garanti eder. Aynı zamanda sizi kötü yasal durumlardan korur. **Açık kaynak kodlu bir proje başlatırken projenize bir lisans eklemelisiniz.**
 
-[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](https://choosealicense.com) de vardır.
+[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 kaynak lisanslarıdır, ancak [aralarından seçim yapabileceğiniz başka seçenekler](https://choosealicense.com) de vardır.
 
-GitHub'da yeni bir proje oluşturduğunuzda, size bir lisans seçme seçeneği sunulur. Açık kaynak lisansı eklemek GitHub projenizi açık kaynak yapar.
+[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](https://choosealicense.com) de vardır.
 
 ![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
 
@@ -137,28 +119,22 @@ Açık kaynak kodlu bir projeyi yönetmenin yasal yönleri hakkında başka soru
 
 ### README Yazma
 
-README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar.
+README'ler, projenizi nasıl kullanılacağını açıklamadan fazlasını yapar. Ayrıca projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini açıklarlar.
 
 README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar.
 
-* Bu proje ne yapıyor?
-* Bu proje neden faydalıdır?
-* Kullanmaya nasıl başlarım?
-* İhtiyacım olursa nereden daha fazla yardım alabilirim?
+- Bu proje ne yapıyor?
+- Bu proje neden faydalıdır?
+- Kullanmaya nasıl başlarım?
+- İhtiyacım olursa nereden daha fazla yardım alabilirim?
 
 README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
-  Daha iyi belgeler, daha fazla kullanıcı, daha az destek talebi ve daha fazla katkıda bulunan anlamına gelir. (...) Unutma ki okuyucuların sen değilsin. Tamamen farklı deneyimlerle projeye gelebilecek insanlar var.
-  <p markdown="1" class="pquote-credit">
-- @tracymakes, ["Yazdıkların okunuyor (video)")(https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">   Daha iyi dokümantasyon, daha fazla kullanıcı, daha az destek talebi ve daha fazla katılımcı anlamına gelir. (...) Okuyucularınızın siz olmadığını unutmayın. Tamamen farklı deneyimleri olan ve projeye gelebilecek insanlar var.   <p markdown="1" class="pquote-credit"> — @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&amp;list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&amp;index=10)   </p></aside>
 
-Bazen, insanlar bir README yazmaktan kaçınırlar çünkü proje bitmemiş gibi hissederler veya katkı kabul etmek istemezler. Bunların hepsi yazmak için çok iyi nedenler.
+README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin.
 
-Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make a README" kılavuzunu](https://www.makeareadme.com/) veya @PurpleBooth'ın [README şablonunu](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) kullanmayı deneyin.
+Bazen, insanlar bir README yazmaktan kaçınırlar çünkü proje bitmemiş gibi hissederler veya katkı kabul etmek istemezler. Bunların hepsi yazmak için çok iyi nedenler.
 
 Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make a README" kılavuzunu](https://www.makeareadme.com/) veya @PurpleBooth'ın [README şablonunu](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) kullanmayı deneyin.
 
@@ -166,27 +142,27 @@ Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make
 
 Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler.
 
-* Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin)
-* Yeni bir özellik nasıl önerilir
-* Proje ortamı nasıl kurulur ve testler nasıl yapılır
+- Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin)
+- Yeni bir özellik nasıl önerilir
+- Proje ortamı nasıl kurulur ve testler nasıl yapılır
 
 Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır:
 
-* Aradığınız katkı türleri
-* Proje için yol haritanız veya vizyonunuz
-* Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli)
+- Aradığınız katkı türleri
+- Proje için yol haritanız veya vizyonunuz
+- Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli)
 
-Sıcak, arkadaşça bir ton kullanmak ve katkılar için özel önerilerde bulunmak (örneğin, dokümantasyon yazmak veya bir web sitesi yapmak gibi) yeni gelenlerin kendilerini memnun ve istekli hissetmelerini sağlama konusunda yardımcı olabilir.
+Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır:
 
-Örneğin, [Active Admin](https://github.com/activeadmin/activeadmin/) [katkıda bulunan rehberine](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) şu şekilde başlar:
+Sıcak, arkadaşça bir ton kullanmak ve katkılar için özel önerilerde bulunmak (örneğin, dokümantasyon yazmak veya bir web sitesi yapmak gibi) yeni gelenlerin kendilerini memnun ve istekli hissetmelerini sağlama konusunda yardımcı olabilir.
 
 > Öncelikle, Active Admin’e katkıda bulunduğunuz için teşekkür ederiz. Active Admin'i harika bir araç yapan sizin gibi insanlar.
 
 Projenizin ilk aşamalarında, CONTRIBUTING dosyanız basit olabilir. Hataların veya dosya sorunlarının nasıl bildirileceğini ve katkı sağlamak için teknik gereksinimleri (testler gibi) her zaman açıklamalısınız.
 
-Zamanla, CONTRIBUTING dosyanıza sıkça sorulan diğer soruları ekleyebilirsiniz. Bu bilgileri yazmak, daha az kişinin size aynı soruları tekrar soracağı anlamına gelir.
+Projenizin ilk aşamalarında, CONTRIBUTING dosyanız basit olabilir. Hataların veya dosya sorunlarının nasıl bildirileceğini ve katkı sağlamak için teknik gereksinimleri (testler gibi) her zaman açıklamalısınız.
 
-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.
+Zamanla, CONTRIBUTING dosyanıza sıkça sorulan diğer soruları ekleyebilirsiniz. Bu bilgileri yazmak, daha az kişinin size aynı soruları tekrar soracağı anlamına gelir.
 
 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.
 
@@ -194,23 +170,17 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan
 
 ### Davranış kural listesi oluşturmak
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
-  Hepimiz, muhtemelen bir şeyin neden belli bir şekilde olması gerektiğini açıklamaya çalışan bir geliştirici olarak ya da bir kullanıcı olarak... basit bir soru sormakla ... ... kötüye kullanılan şeyin yaşadığı deneyimlerimiz oldu. (...) Davranış kuralları, ekibinizin yapıcı söylemleri çok ciddiye aldığını gösteren, kolayca referans verilen ve bağlanabilir bir belge haline gelir.
-  <p markdown="1" class="pquote-credit">
-— @mlynch, ["Açık Kaynağı Daha Mutlu Bir Yer Yapma"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">   Hepimiz, muhtemelen bir şeyin neden belirli bir şekilde olması gerektiğini açıklamaya çalışan bir proje sahibi olarak ya da bir kullanıcı olarak basit bir soru gibi sorulan istismarla karşılaştığımız deneyimler yaşadık. (...) Davranış kuralları, ekibinizin yapıcı söylemi çok ciddiye aldığını gösteren, kolayca atıfta bulunulabilir ve bağlanabilir bir belge haline gelir.  <p markdown="1" class="pquote-credit"> — @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)   </p></aside>
 
 Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır.
 
-Daha fazla bilgi için [Davranış Kuralları kılavuzumuza](../code-of-conduct/) göz atın.
+Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır.
 
-Katılımcıların _nasıl_ davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir.
+Katılımcıların *nasıl* davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir.
 
 Açık kaynaklı lisanslara benzer şekilde, davranış kuralları için de yeni ortaya çıkan standartlar vardır, bu yüzden kendiniz yazmak zorunda değilsiniz. [Contributor Covenant](https://contributor-covenant.org/), Kubernet, Rails ve Swift dahil olmak üzere [40.000'den fazla açık kaynaklı proje](https://www.contributor-covenant.org/adopters) tarafından kullanılan bir davranış kural listesi şablonudur. Hangi metni kullanırsanız kullanın, gerektiğinde davranış kurallarınızı uygulamak için hazırlıklı olmalısınız.
 
-Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosyayı projenizin kök dizininde tutun, böylece README'nizden kolayca bulabilir ve linkleyebilirsiniz.
+Açık kaynaklı lisanslara benzer şekilde, davranış kuralları için de yeni ortaya çıkan standartlar vardır, bu yüzden kendiniz yazmak zorunda değilsiniz. [Contributor Covenant](https://contributor-covenant.org/), Kubernet, Rails ve Swift dahil olmak üzere [40.000'den fazla açık kaynaklı proje](https://www.contributor-covenant.org/adopters) tarafından kullanılan bir davranış kural listesi şablonudur. Hangi metni kullanırsanız kullanın, gerektiğinde davranış kurallarınızı uygulamak için hazırlıklı olmalısınız.
 
 ## Projenizi isimlendirme ve markalama
 
@@ -220,44 +190,38 @@ Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosy
 
 Marka, gösterişli bir logo veya çekici bir proje adından daha fazlasıdır. Projeniz hakkında nasıl konuştuğunuzla ve mesajınızla kime ulaştığınızla ilgilidir.
 
-* [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler
-* [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur
+- [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler
+- [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur
 
 Mevcut bir projenin üzerine inşa ediyorsanız, adlarını ön ek olarak kullanmak projenizin ne yaptığını netleştirmeye yardımcı olabilir (örneğin, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` komutunu getirir).
 
-Her şeyden önce netlik düşünün. Püf noktaları eğlencelidir, ancak bazı şakaların diğer kültürlere veya sizden farklı deneyimlere sahip insanlara tercüme edilemeyebileceğini unutmayın. Potansiyel kullanıcılarınızdan bazıları şirket çalışanları olabilir: projenizi işte açıklamak zorunda kaldıklarında onları rahatsız etmek istemezsiniz!
+Mevcut bir projenin üzerine inşa ediyorsanız, adlarını ön ek olarak kullanmak projenizin ne yaptığını netleştirmeye yardımcı olabilir (örneğin, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` komutunu getirir).
 
 ### Benzersiz isim bulmak
 
+Her şeyden önce netlik düşünün. Püf noktaları eğlencelidir, ancak bazı şakaların diğer kültürlere veya sizden farklı deneyimlere sahip insanlara tercüme edilemeyebileceğini unutmayın. Potansiyel kullanıcılarınızdan bazıları şirket çalışanları olabilir: projenizi işte açıklamak zorunda kaldıklarında onları rahatsız etmek istemezsiniz!
+
 Özellikle aynı dili veya ekosistemi paylaşıyorsanız, [benzer bir adla açık kaynaklı projeleri kontrol edin](http://ivantomic.com/projects/ospnc/). İsminiz popüler bir projeyle örtüşüyorsa, takipçilerinizin kafaları karışabilir.
 
 Bir web sitesi, Twitter hesabı veya projenizi temsil eden diğer özellikleri istiyorsanız, istediğiniz adları aldığınızdan emin olun. İdeal olarak, [bu isimleri](https://instantdomainsearch.com/) henüz kullanmak istemediğiniz zamanlarda bile, rahat etmek için şimdiden alın.
 
 Projenizin adının herhangi bir ticari markayı ihlal etmediğinden emin olun. Bir şirket sizden projenizi kapatmanızı isteyebilir veya hatta aleyhinize yasal işlem başlatabilir. Bu riske değmez.
 
-Projenizin adının herhangi bir ticari markayı ihlal etmediğinden emin olun. Bir şirket sizden projenizi kapatmanızı isteyebilir veya hatta aleyhinize yasal işlem başlatabilir. Bu riske değmez.
-
 [WIPO Global Marka Veritabanını](http://www.wipo.int/branddb/en/) ticari marka çakışmaları için kontrol edebilirsiniz. Eğer bir şirketteyseniz, bu [hukuk ekibinizin size yardımcı olabileceği](../legal/) şeylerden biridir.
 
 ### Nasıl yazdığın (ve kodladığın) markanı da etkiler!
 
-Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri.
+Projenizin ömrü boyunca birçok yazı yazacaksınız; README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri.
 
 Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.
-  <p markdown="1" class="pquote-credit">
-— [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
-  </p>
-</aside>
+<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">   Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.   <p markdown="1" class="pquote-credit"> — [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)   </p> </aside>
 
 Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün.
 
 Kelimeleri nasıl yazdığınızın ötesinde, kodlama stiliniz de projenizin markasının bir parçası olabilir. [Angular](https://angular.io/guide/styleguide) ve [jQuery](https://contribute.jquery.org/style-guide/js/) titiz kodlama stilleri ve yönergeleri olan projelere iki örnektir.
 
-Yeni başladığınızda, projeniz için bir stil rehberi yazmak gerekli değildir ve yine de projenize farklı kodlama stilleri eklemekten zevk aldığınızı fark edebilirsiniz. Ancak, yazma ve kodlama stilinizin farklı insanları nasıl çekebileceğini veya caydıracağını tahmin etmelisiniz. Projenizin ilk aşamaları, görmek istediğiniz emsali belirleme fırsatınızdır.
+Kelimeleri nasıl yazdığınızın ötesinde, kodlama stiliniz de projenizin markasının bir parçası olabilir. [Angular](https://angular.io/guide/styleguide) ve [jQuery](https://contribute.jquery.org/style-guide/js/) titiz kodlama stilleri ve yönergeleri olan projelere iki örnektir.
 
 ## Lansman öncesi kontrol listeniz
 
@@ -267,53 +231,39 @@ Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol l
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox1" class="overflow-hidden d-block text-normal">
-    Projenin açık kaynak lisanslı LICENSE dosyası var
-  </label>
+  <label for="cbox1" class="overflow-hidden d-block text-normal">     Projenin açık kaynak lisanslı LICENSE dosyası var   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox2" class="overflow-hidden d-block text-normal">
-    Proje temel dokümantasyona sahiptir (README, CONTRIBUTING, CODE_OF_CONDUCT)
-  </label>
+  <label for="cbox2" class="overflow-hidden d-block text-normal">     Proje temel dokümantasyona sahiptir (README, CONTRIBUTING, CODE_OF_CONDUCT)   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox3" class="overflow-hidden d-block text-normal">
-    Adı hatırlamak kolaydır, projenin ne yaptığı hakkında bir fikir verir ve mevcut bir projeyle çelişmez veya ticari markaları ihlal etmez
-  </label>
+  <label for="cbox3" class="overflow-hidden d-block text-normal">     Adı hatırlamak kolaydır, projenin ne yaptığı hakkında bir fikir verir ve mevcut bir projeyle çelişmez veya ticari markaları ihlal etmez   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox4" class="overflow-hidden d-block text-normal">
-    Sorun listesi, açıkça düzenlenmiş ve etiketlenmiş konularla birlikte güncel
-  </label>
+  <label for="cbox4" class="overflow-hidden d-block text-normal">     Sorun listesi, açıkça düzenlenmiş ve etiketlenmiş konularla birlikte güncel   </label>
 </div>
 
 **Kod**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox5" class="overflow-hidden d-block text-normal">
-    Proje tutarlı kod kuralları ve temiz işlev/yöntem/değişken adlarını kullanıyor
-  </label>
+  <label for="cbox5" class="overflow-hidden d-block text-normal">     Proje tutarlı kod kuralları ve temiz işlev/yöntem/değişken adlarını kullanıyor   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox6" class="overflow-hidden d-block text-normal">
-    Kod açıkça yorumlanmış, amaçları ve aykırı vakaları belgelemektedir.
-  </label>
+  <label for="cbox6" class="overflow-hidden d-block text-normal">     Kod açıkça yorumlanmış, amaçları ve aykırı vakaları belgelemektedir.   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox7" class="overflow-hidden d-block text-normal">
-    Revizyon geçmişinde, sorunlarda veya PR isteklerinde (örneğin şifreler veya kamuya açık olmayan diğer bilgiler) hassas bilgi yok
-  </label>
+  <label for="cbox7" class="overflow-hidden d-block text-normal">     Revizyon geçmişinde, sorunlarda veya PR isteklerinde (örneğin şifreler veya kamuya açık olmayan diğer bilgiler) hassas bilgi yok   </label>
 </div>
 
 **İnsanlar**
@@ -322,39 +272,29 @@ Bireyseniz:
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox8" class="overflow-hidden d-block text-normal">
-    Hukuk departmanıyla konuştunuz ve/veya şirketinizin IP ve açık kaynaklı politikalarını anladınız (eğer bir yerde çalışansanız).
-  </label>
+  <label for="cbox8" class="overflow-hidden d-block text-normal">     Hukuk departmanıyla konuştunuz ve/veya şirketinizin IP ve açık kaynaklı politikalarını anladınız (eğer bir yerde çalışansanız).   </label>
 </div>
 
 Bir şirket veya kuruluşsanız:
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox9" class="overflow-hidden d-block text-normal">
-    Hukuk departmanınızla konuştunuz
-  </label>
+  <label for="cbox9" class="overflow-hidden d-block text-normal">     Hukuk departmanınızla konuştunuz   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox10" class="overflow-hidden d-block text-normal">
-    Projeyi duyurmak ve tanıtmak için bir pazarlama planınız var
-  </label>
+  <label for="cbox10" class="overflow-hidden d-block text-normal">     Projeyi duyurmak ve tanıtmak için bir pazarlama planınız var   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Birisi topluluk etkileşimlerini yönetmeyi taahhüt eder (sorunlara cevap verme, çekme isteklerini gözden geçirme ve birleştirme)
-  </label>
+  <label for="cbox11" class="overflow-hidden d-block text-normal">     Birisi topluluk etkileşimlerini yönetmeyi taahhüt eder (sorunlara cevap verme, çekme isteklerini gözden geçirme ve birleştirme)   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox12" class="overflow-hidden d-block text-normal">
-    En az iki kişinin projeye yönetici erişimi var
-  </label>
+  <label for="cbox12" class="overflow-hidden d-block text-normal">     En az iki kişinin projeye yönetici erişimi var   </label>
 </div>
 
 ## Başardınız!

From 20d86932785458cd1c687f0d3cfde1b376107408 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 10 May 2021 00:10:48 +0000
Subject: [PATCH 167/749] Translate starting-a-project.md via GitLocalize

---
 _articles/tr/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index b5d1598305a..c0dd38a4479 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -174,7 +174,7 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan
 
 Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır.
 
-Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır.
+Daha fazla bilgi için [Davranış Kuralları kılavuzumuza](../code-of-conduct/) göz atın.
 
 Katılımcıların *nasıl* davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir.
 

From 9547d757b56c58232bb3d42dcdfe624a7415263d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 10 May 2021 00:13:36 +0000
Subject: [PATCH 168/749] Translate starting-a-project.md via GitLocalize

---
 _articles/tr/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index c0dd38a4479..7c8076466bc 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -128,7 +128,7 @@ README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını
 - Kullanmaya nasıl başlarım?
 - İhtiyacım olursa nereden daha fazla yardım alabilirim?
 
-README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin.
+README'nizi, katkıları nasıl ele aldığınız, projenin hedeflerinin ne olduğu ve lisanslar ve atıfla ilgili bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkıları kabul etmek istemiyorsanız veya projeniz henüz üretime hazır değilse, bu bilgileri not edin.
 
 <aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">   Daha iyi dokümantasyon, daha fazla kullanıcı, daha az destek talebi ve daha fazla katılımcı anlamına gelir. (...) Okuyucularınızın siz olmadığını unutmayın. Tamamen farklı deneyimleri olan ve projeye gelebilecek insanlar var.   <p markdown="1" class="pquote-credit"> — @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&amp;list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&amp;index=10)   </p></aside>
 

From f505bc844147675fd9769709c9a376dc083093df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 10 May 2021 03:57:26 +0300
Subject: [PATCH 169/749] Fix formating errors created by Gitlocalize

---
 _articles/tr/code-of-conduct.md    |  38 ++--
 _articles/tr/finding-users.md      |  73 ++++++--
 _articles/tr/how-to-contribute.md  | 274 +++++++++++++++++++----------
 _articles/tr/starting-a-project.md | 134 ++++++++++----
 4 files changed, 360 insertions(+), 159 deletions(-)

diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md
index 9ba8ff26e3b..886e0c91a85 100644
--- a/_articles/tr/code-of-conduct.md
+++ b/_articles/tr/code-of-conduct.md
@@ -30,10 +30,10 @@ Mümkün olduğunca en erken zamanda bir davranış kural listesi oluşturmaya 
 
 Beklentilerinizi iletmenin yanı sıra, bir davranış kural listesi aşağıdakileri de açıklar:
 
-- Davranış kuralları nerede yürürlüğe girer *(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)*?
-- Davranış kuralları kimin için geçerlidir *(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)*?
-- Birisi davranış kurallarını ihlal ederse ne olur?
-- İhlaller nasıl rapor edilebilir?
+* Davranış kuralları nerede yürürlüğe girer _(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)_?
+* Davranış kuralları kimin için geçerlidir _(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)_?
+* Birisi davranış kurallarını ihlal ederse ne olur?
+* İhlaller nasıl rapor edilebilir?
 
 Nerede olursanız olun, geçmiş tecrübelerden faydalanın. [Katkıda Bulunanlar Sözleşmesi (Contributor Covenant)](https://contributor-covenant.org/) Kubernet, Rails ve Swift dahil olmak üzere 40.000'den fazla açık kaynaklı proje tarafından kullanılan ortak bir davranış kural listesidir.
 
@@ -43,15 +43,20 @@ CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTIN
 
 ## Davranış kurallarınızı nasıl uygulayacağınıza karar verme
 
-<aside markdown="1" class="pquote">   Uygulanmayan (veya uygulanamayan) bir davranış kural listesi, hiçbir davranış kuralı olmamasından daha kötüdür: davranış kurallarındaki değerlerin, sizin toplumunuzda gerçekten önemli veya saygı duyulmadığı mesajını gönderir.   <p markdown="1" class="pquote-credit"> - [Ada Girişimi](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  Uygulanmayan (veya uygulanamayan) bir davranış kural listesi, hiçbir davranış kuralı olmamasından daha kötüdür: davranış kurallarındaki değerlerin, sizin toplumunuzda gerçekten önemli veya saygı duyulmadığı mesajını gönderir.
+  <p markdown="1" class="pquote-credit">
+- [Ada Girişimi](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+  </p>
+</aside>
 
 Bir ihlal meydana *gelmeden önce* davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var:
 
-- İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir.
+* İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir.
 
-- Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir.
+* Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir.
 
-- Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz.
+* Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz.
 
 İnsanlara davranış kuralları ihlalini bildirebilmeleri için özel bir yol (e-posta adresi gibi) vermelisiniz ve bu raporun kimlere ulaştığını açıklamalısınız. Bu bir kurucu, bir geliştirme grubu veya bir davranış kuralları çalışma grubu olabilir.
 
@@ -73,7 +78,12 @@ Söz konusu topluluk üyesi, sürekli olarak başkalarını rahatsız hissetmesi
 
 Cevap vermeden önce, neler olduğunu anlamak için biraz zaman harcayın. Kim olduklarını ve neden böyle davrandıklarını daha iyi anlamak için, kişi ya da kişilerin geçmiş yorumlarını ve konuşmalarını okuyun. Bu kişi ve davranışları hakkındaki kendi görüşleriniz dışında başka bakış açıları da toplamaya çalışın.
 
-<aside markdown="1" class="pquote">   Bir tartışmaya girmeyin. Eldeki konuyla ilgilenmeyi bitirmeden önce başkasının davranışlarıyla başa çıkmayın. İhtiyacınız olana odaklanın.   <p markdown="1" class="pquote-credit"> - Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  Bir tartışmaya girmeyin. Eldeki konuyla ilgilenmeyi bitirmeden önce başkasının davranışlarıyla başa çıkmayın. İhtiyacınız olana odaklanın.
+  <p markdown="1" class="pquote-credit">
+- Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+  </p>
+</aside>
 
 ### Uygun işlemi yapın
 
@@ -83,15 +93,15 @@ Birisi bir davranış kuralları ihlali bildirdiğinde, bu durumla yüzleşmesi
 
 Bir davranış kural ihlaline yanıt vermenin birkaç yolu vardır:
 
-- **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun.
+* **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun.
 
-- Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin.
+* Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin.
 
 Bazen bir çözüme ulaşılamaz. Söz konusu kişi karşı karşıya geldiğinde saldırgan veya düşmanca olabilir veya davranışlarını değiştirmez. Bu durumda, daha güçlü bir işlem yapmayı düşünebilirsiniz. Örneğin:
 
-- Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz**
+* Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz**
 
-- Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz**
+* Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz**
 
 Kalıcı olarak yasaklama üyeleri kolayca alınmamalı ve kalıcı uzlaşmaz bir bakış açısı farklılığını temsil etmelidir. Bu önlemleri yalnızca bir çözüme ulaşılamayacağı açıksa almalısınız.
 
@@ -101,7 +111,7 @@ Davranış kuralları, keyfi olarak uygulanan bir yasa değildir. Davranış kur
 
 Proje sahibi olarak, topluluğunuz için kılavuz ilkeler belirler ve bu ilkeleri davranış kurallarınızda belirtilen kurallara uygun olarak uygularsınız. Bu, herhangi bir davranış kuralları ihlali raporunu ciddiye almak anlamına gelir. İhbar eden şikayeti hakkında kapsamlı ve adil bir inceleme yapılmasını hak eder. Bildirdikleri davranışların bir ihlal olmadığını belirlerseniz, bunu açıkça belirtin ve neden bu konuda harekete geçmeyeceğinizi açıklayın. Bununla ne yapacakları onlara bağlı: Sorunlu olduğunu düşündükleri davranışlara hoşgörü gösterirler veya topluluktan ayrılabilirler.
 
-*Teknik* olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir.
+_Teknik_ olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir.
 
 Sonunda, bir proje sahibi olarak, kabul edilebilir davranış için standartları belirler ve uygularsınız. Projenin topluluk değerlerini şekillendirme yetkiniz var ve katılımcılar bu değerleri adil ve eşit bir şekilde uygulamanızı beklerler.
 
diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md
index 914ee05a185..20d8e3c976e 100644
--- a/_articles/tr/finding-users.md
+++ b/_articles/tr/finding-users.md
@@ -27,7 +27,7 @@ Projenizi tanıtmaya yönelik asıl çalışmaya başlamadan önce, ne yaptığ
 
 Projenizi farklı veya ilginç kılan nedir? Neden yarattınız? Bu soruları kendiniz cevaplamak, projenizin önemini bildirmenize yardımcı olacaktır.
 
-İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, *kullanıcıların ve katkıda bulunanların* ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın.
+İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, _kullanıcıların ve katkıda bulunanların_ ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın.
 
 Örneğin, @robb, projesi olan [Cartography'nin](https://github.com/robb/Cartography) neden faydalı olduğunu açıkça belirtmek için kod örnekleri kullanır:
 
@@ -37,7 +37,12 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa
 
 ## İnsanların projenizi bulmasına ve takip etmesine yardımcı olun
 
-<aside markdown="1" class="pquote">   İdeal olarak, insanları projenizle ilgili olarak tanıtabileceğiniz ve işaret edebileceğiniz tek bir "anasayfa" URL'sine ihtiyacınız var. Süslü bir şablona, hatta etkili bir alan adına sahip olmanıza gerek yoktur, ancak projenizin bir odak noktasına ihtiyacı vardır.   <p markdown="1" class="pquote-credit"> - Peter Cooper ve Robert Nyman, ["Kodunuzun Mesajı Nasıl Yayılır"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  İdeal olarak, insanları projenizle ilgili olarak tanıtabileceğiniz ve işaret edebileceğiniz tek bir "anasayfa" URL'sine ihtiyacınız var. Süslü bir şablona, hatta etkili bir alan adına sahip olmanıza gerek yoktur, ancak projenizin bir odak noktasına ihtiyacı vardır.
+  <p markdown="1" class="pquote-credit">
+- Peter Cooper ve Robert Nyman, ["Kodunuzun Mesajı Nasıl Yayılır"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+  </p>
+</aside>
 
 İnsanların projenizi tek bir alana işaret ederek bulup hatırlamalarına yardımcı olun.
 
@@ -45,11 +50,17 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa
 
 Henüz projeniz için iletişim noktaları kurmak istemiyorsanız, yaptığınız her şeyde kendi Twitter veya GitHub hesabınızı tanıtın. Twitter veya GitHub hesabınızı tanıtmak, insanların sizinle nasıl iletişim kurabileceklerini veya işlerinizi takip etmelerini sağlayacaktır. Bir buluşma veya etkinlikte konuşuyorsanız, iletişim bilgilerinizin biyo veya slaytlarınıza eklendiğinden emin olun.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">   Bu ilk günlerde yaptığım bir hata (...) proje için Twitter hesabı oluşturmamaktı. Twitter, insanları bir proje hakkında güncel tutmak ve insanları projeyle sürekli iletişimde bırakmak için harika bir yol.   <p markdown="1" class="pquote-credit"> - @nathanmarz, ["Apache Storm'un ve Öğrenilen Derslerin Tarihi"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
+  Bu ilk günlerde yaptığım bir hata (...) proje için Twitter hesabı oluşturmamaktı. Twitter, insanları bir proje hakkında güncel tutmak ve insanları projeyle sürekli iletişimde bırakmak için harika bir yol.
+  <p markdown="1" class="pquote-credit">
+- @nathanmarz, ["Apache Storm'un ve Öğrenilen Derslerin Tarihi"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+  </p>
+</aside>
 
 **Projeniz için bir web sitesi oluşturmayı düşünün.** Bir web sitesi, projenizi daha net hale getirir ve özellikle açık belgeler ve eğitimlerle desteklendiğinde gezinmeyi kolaylaştırır. Bir web sitesine sahip olmak, projenizin aktif olduğunu ve bu sayede hedef kitlenizin kendisini daha rahat hissetmesini sağlayacaktır. İnsanlara projenizi nasıl kullanacakları hakkında fikir vermek için örnekler verin.
 
-Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin *"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi*.
+Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin _"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi_.
 
 Projeniz GitHub'da barındırıyorsanız, kolayca web sitesi yapmak için [GitHub Pages](https://pages.github.com/) kullanabilirsiniz. [Yeoman](http://yeoman.io/) , [Vagrant](https://www.vagrantup.com/) ve [Middleman](https://middlemanapp.com/) mükemmel, kapsamlı web sitelerine [birkaç örnektir](https://github.com/showcases/github-pages-examples) .
 
@@ -63,13 +74,19 @@ Artık projeniz için bir mesajınız ve insanların projenizi bulmaları için
 
 Hedef kitlenize ulaşmak için mevcut çevrimiçi topluluklardan ve platformlardan yararlanın. Açık kaynaklı projeniz bir yazılım projesiyse, kitlenizi [Stack Overflow](https://stackoverflow.com/) , [Reddit](https://www.reddit.com) , [Hacker News](https://news.ycombinator.com/) veya [Quora](https://www.quora.com/)'da bulabilirsiniz. İnsanların işinizden en çok faydalanabileceğini veya heyecanlanacağını düşündüğünüz kanalları bulun.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">   Her programın, kullanıcıların yalnızca bir kısmının yararlı bulacağı çok özel işlevleri vardır. Mümkün olduğunca çok insana spam yapmayın. Bunun yerine, çabalarınızı projeniz hakkında bilgi sahibi olmaktan yararlanacak topluluklara hedefleyin.   <p markdown="1" class="pquote-credit"> - @pazdera, ["Açık kaynak projeleri için pazarlama"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
+  Her programın, kullanıcıların yalnızca bir kısmının yararlı bulacağı çok özel işlevleri vardır. Mümkün olduğunca çok insana spam yapmayın. Bunun yerine, çabalarınızı projeniz hakkında bilgi sahibi olmaktan yararlanacak topluluklara hedefleyin.
+  <p markdown="1" class="pquote-credit">
+- @pazdera, ["Açık kaynak projeleri için pazarlama"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+  </p>
+</aside>
 
 Projenizi ilgili kanallarda paylaşmanın yollarını bulabilecek misiniz bir bakın:
 
-- **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır.
-- **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun.
-- **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin.
+* **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır.
+* **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun.
+* **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin.
 
 Genel olarak konuşursak, karşılığında bir şey istemeden önce başkalarına yardım etmeye odaklanın. Herkes bir projeyi çevrimiçi olarak kolayca tanıtabildiğinden, çok fazla gürültü çıkacaktır. Kalabalıktan sıyrılmak için, insanlara sadece ne istediğinizi değil, kim olduğunuzu anlatmaya çalışın.
 
@@ -83,19 +100,37 @@ Genel olarak konuşursak, karşılığında bir şey istemeden önce başkaları
 
 [Topluluk karşısında konuşma konusunda](https://speaking.io/) yeniyseniz, projenizin dili veya ekosistemiyle ilgili yerel bir buluşma bularak başlayın.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">   PyCon'a giderken oldukça gergindim. Bir konuşma yapıyordum, sadece birkaç kişiyi tanıyacaktım, bir hafta boyunca gidecektim. (...) Yine de bu kadar endişelenmemeliydim. PyCon olağanüstü bir harikaydı! (...) Herkes inanılmaz derecede cana yakın ve paylaşımcıydı, o kadar ki nadiren ben de konuşmak için fırsat bulabildim!   <p markdown="1" class="pquote-credit"> - @jhamrick, ["Endişelenmeyi Durdurmayı ve PyCon'u Sevmeyi Nasıl Öğreniyorum"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
+  PyCon'a giderken oldukça gergindim. Bir konuşma yapıyordum, sadece birkaç kişiyi tanıyacaktım, bir hafta boyunca gidecektim. (...) Yine de bu kadar endişelenmemeliydim. PyCon olağanüstü bir harikaydı! (...) Herkes inanılmaz derecede cana yakın ve paylaşımcıydı, o kadar ki nadiren ben de konuşmak için fırsat bulabildim!
+  <p markdown="1" class="pquote-credit">
+- @jhamrick, ["Endişelenmeyi Durdurmayı ve PyCon'u Sevmeyi Nasıl Öğreniyorum"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)   
+  </p>
+</aside>
 
 Daha önce topluluk önünde konuşmadıysanız, gergin hissetmek tamamen normaldir! İzleyicilerinizin sizin için orada olduğunu unutmayın, çünkü işinizi gerçekten duymak istiyorlar.
 
 Konuşmanızı yazarken, izleyicilerinizin ilginç bulacağı ve değer kazanacağı şeylere odaklanın. Dilinizi arkadaşça ve ulaşılabilir tutun. Gülümseyin, nefes alın ve eğlenin.
 
-<aside markdown="1" class="pquote">   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">   Konuşmanızı yazmaya başladığınızda, konunuz ne olursa olsun, konuşmanızı insanlara anlattığınız bir hikaye olarak görmeniz yararlı olabilir.   <p markdown="1" class="pquote-credit"> - Lena Reinhard, ["Teknik Konferans Konuşması Nasıl Hazırlanır ve Yazılır"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
+  Konuşmanızı yazmaya başladığınızda, konunuz ne olursa olsun, konuşmanızı insanlara anlattığınız bir hikaye olarak görmeniz yararlı olabilir.
+  <p markdown="1" class="pquote-credit">
+- Lena Reinhard, ["Teknik Konferans Konuşması Nasıl Hazırlanır ve Yazılır"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+  </p>
+</aside>
 
 Hazır olduğunuzda, projenizi tanıtmak için bir konferansta konuşmayı düşünün. Konferanslar, bazen dünyanın her yerinden daha fazla insana ulaşmanıza yardımcı olabilir.
 
 Dilinize veya ekosisteminize özgü konferansları arayın. Konuşmanızı göndermeden önce, konuşmanızı katılımcılar için uyarlamak ve konferansta konuşma kabul etme şansınızı artırmak için konferansı araştırın. Konferansın konuşmacılarına bakarak, izleyicilerinizi daha kolay anlayabilirsiniz.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">   JSConf insanlarına çok hoş bir şekilde yazdım ve bana JSConf AB'de sunabileceğim bir yer vermeleri için yalvardım. (...) Altı aydır üzerinde çalıştığım bu şeyi sunarken son derece korktum. (...) Bütün konuşma sırasında şunu düşündüm. Aman tanrım, burada ne yapıyorum?   <p markdown="1" class="pquote-credit"> - @ry, ["Node.js'nin Hikayesi" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&amp;t=24m57s)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
+  JSConf insanlarına çok hoş bir şekilde yazdım ve bana JSConf AB'de sunabileceğim bir yer vermeleri için yalvardım. (...) Altı aydır üzerinde çalıştığım bu şeyi sunarken son derece korktum. (...) Bütün konuşma sırasında şunu düşündüm. Aman tanrım, burada ne yapıyorum?
+  <p markdown="1" class="pquote-credit">
+- @ry, ["Node.js'nin Hikayesi" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&amp;t=24m57s)
+  </p>
+</aside>
 
 ## Bir itibar oluşturun
 
@@ -103,13 +138,25 @@ Yukarıda belirtilen stratejilere ek olarak, insanları projenizi paylaşmaya ve
 
 Yeni gelenlere yardım etmek, kaynakları paylaşmak ve başkalarının projelerine anlamlı katkılar yapmak olumlu bir itibara kavuşmanıza yardımcı olacaktır. Açık kaynak topluluğunda aktif bir üye olmak, insanların çalışmanız için bağlam oluşturmasına yardımcı olacak ve projenize dikkat etme ve paylaşma olasılıkları artacaktır. Diğer açık kaynaklı projelerle ilişkilerin geliştirilmesi resmi ortaklıklara yol açabilir.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">   Urllib3'ün günümüzdeki en popüler üçüncü parti Python kütüphanesi olmasının tek nedeni isteklerin parçası olmasıdır.   <p markdown="1" class="pquote-credit"> - @shazow, ["Açık kaynak projeniz nasıl gelişir?"](Https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
+  Urllib3'ün günümüzdeki en popüler üçüncü parti Python kütüphanesi olmasının tek nedeni isteklerin parçası olmasıdır.
+  <p markdown="1" class="pquote-credit">
+- @shazow, ["Açık kaynak projeniz nasıl gelişir?"](Https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+  </p>
+</aside>
 
 İtibarınızı oluşturmak için asla çok erken veya geç değildir. Kendi projenizi daha önce başlatmış olsanız bile, başkalarına yardım etmenin yollarını aramaya devam edin.
 
 Kitle oluşturmak için bir gecede çözüm yoktur. Başkalarının güvenini ve saygısını kazanmak zaman alır ve itibarınızı geliştirmek hiç tamamlanmayan bir iştir.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">   PhantomJS ilk kez 2011 yılının başında piyasaya sürüldü. (...) Mesajını her zamanki gibi yaydım: Tweetledim, yapabileceğin şeyler hakkında blog yazıları yazdım, buluşmalarda çeşitli tartışmalar sırasında bahsettim. 2014 yılında daha iyi tanındığında, onunla ilgili sunumlar yapmaya başladım.   <p markdown="1" class="pquote-credit"> - @ariya, ["Geliştirici Hikayeleri"](https://github.com/open-source/stories/ariya)    </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
+  PhantomJS ilk kez 2011 yılının başında piyasaya sürüldü. (...) Mesajını her zamanki gibi yaydım: Tweetledim, yapabileceğin şeyler hakkında blog yazıları yazdım, buluşmalarda çeşitli tartışmalar sırasında bahsettim. 2014 yılında daha iyi tanındığında, onunla ilgili sunumlar yapmaya başladım.
+  <p markdown="1" class="pquote-credit">
+- @ariya, ["Geliştirici Hikayeleri"](https://github.com/open-source/stories/ariya)
+  </p>
+</aside>
 
 ## Devam et!
 
diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md
index 0f79a454a87..487e228f428 100644
--- a/_articles/tr/how-to-contribute.md
+++ b/_articles/tr/how-to-contribute.md
@@ -19,7 +19,13 @@ related:
 
 ## Açık kaynağa neden katkıda bulunmalıyım?
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">   \[Freenode\] üzerinde çalışmak, daha sonra üniversitedeki çalışmalarımda ve gerçek işimde kullandığım becerilerin çoğunu kazanmama yardımcı oldu. Açık kaynak kodlu projeler üzerinde çalışmanın projeye yardım ettiği kadar yapana da yardımcı olacağını düşünüyorum!   <p markdown="1" class="pquote-credit"> - @errietta, ["Açık kaynaklı yazılımlara katkıda bulunmayı neden seviyorum"](https://www.errietta.me/blog/open-source/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar"> 
+  \[Freenode\] üzerinde çalışmak, daha sonra üniversitedeki çalışmalarımda ve gerçek işimde kullandığım becerilerin çoğunu kazanmama yardımcı oldu. Açık kaynak kodlu projeler üzerinde çalışmanın projeye yardım ettiği kadar yapana da yardımcı olacağını düşünüyorum!
+  <p markdown="1" class="pquote-credit">
+- @errietta, ["Açık kaynaklı yazılımlara katkıda bulunmayı neden seviyorum"](https://www.errietta.me/blog/open-source/)
+  </p>
+</aside>
 
 Açık kaynağa katkıda bulunmak, hayal edebileceğiniz herhangi bir konuyu öğrenmek, öğretmek ve deneyim geliştirmek için faydalı bir yol olabilir.
 
@@ -63,59 +69,77 @@ Endişe etmeyin! Açık kaynak kodlu bir projeye dahil olmanın çok farklı yol
 
 Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye *büyük bir* iyilik yapacaksınız!
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">   CocoaPods'taki çalışmamla ünlüydüm, ama çoğu insan CocoaPods aracının kendisinde gerçek bir iş yapmadığımı bilmiyor. Projedeki zamanım çoğunlukla belgeleme ve markalaşma gibi şeyler yapmakla geçiyor.   <p markdown="1" class="pquote-credit"> - @orta, ["Varsayılan olarak OSS’ye taşıma"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
+  CocoaPods'taki çalışmamla ünlüydüm, ama çoğu insan CocoaPods aracının kendisinde gerçek bir iş yapmadığımı bilmiyor. Projedeki zamanım çoğunlukla belgeleme ve markalaşma gibi şeyler yapmakla geçiyor.
+  <p markdown="1" class="pquote-credit">
+- @orta, ["Varsayılan olarak OSS’ye taşıma"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+  </p>
+</aside>
 
 Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve diğer topluluk üyeleriyle tanışmak için harika bir yoldur. Bu ilişkileri kurmak size projenin diğer bölümlerinde de çalışma fırsatı verecektir.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">   İlk önce 17 Haziran 2002 tarihinde düzeltme yamamı e-postayla gönderdiğimde Python geliştirme ekibine (aka python-dev) ulaştım. Hızlı bir şekilde hatayı yakaladım ve grubun e-posta özetlerini iyileştirmeye başladım. Bir konu hakkında net bilgi almak için bana büyük bir bahane verdiler, ama daha kritik olarak, birinin düzeltilmesi gereken bir şeyi işaret ettiğini fark ettim.   <p markdown="1" class="pquote-credit"> - @brettcannon, ["Geliştirme Hikayeleri"](https://github.com/open-source/stories/brettcannon)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
+  İlk önce 17 Haziran 2002 tarihinde düzeltme yamamı e-postayla gönderdiğimde Python geliştirme ekibine (aka python-dev) ulaştım. Hızlı bir şekilde hatayı yakaladım ve grubun e-posta özetlerini iyileştirmeye başladım. Bir konu hakkında net bilgi almak için bana büyük bir bahane verdiler, ama daha kritik olarak, birinin düzeltilmesi gereken bir şeyi işaret ettiğini fark ettim.
+  <p markdown="1" class="pquote-credit">
+- @brettcannon, ["Geliştirme Hikayeleri"](https://github.com/open-source/stories/brettcannon)
+  </p>
+</aside>
 
 ### Etkinlik planlamayı sever misiniz?
 
-- [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin
-- Projenin konferansını düzenleyin (eğer varsa)
-- Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun
+* [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin
+* Projenin konferansını düzenleyin (eğer varsa)
+* Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun
 
 ### Tasarlamayı sever misiniz?
 
-- Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın
-- [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın
-- Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın
-- [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın
+* Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın
+* [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın
+* Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın
+* [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın
 
 ### Yazmayı sever misin?
 
-- Proje dokümantasyonunu yazın ve geliştirin
-- Projenin nasıl kullanıldığını gösteren örnekler oluşturun
-- Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın
-- [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın
-- Projenin dokümantasyonu için çeviri yapın
+* Proje dokümantasyonunu yazın ve geliştirin
+* Projenin nasıl kullanıldığını gösteren örnekler oluşturun
+* Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın
+* [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın
+* Projenin dokümantasyonu için çeviri yapın
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">   Cidden, \[belgeleme\] çok önemlidir. Şu ana kadarki belgeler mükemmeldi ve Babil'in keskin bir özelliği oldu. Bazı özellikleri kesinlikle kullanabilecek bölümler var, hatta burada bir paragrafın eklenmesi bile çok beğeni topluyor.   <p markdown="1" class="pquote-credit"> - @kittens, ["Katkıda bulunanlar için çağrı"](https://github.com/babel/babel/issues/1347)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
+  Cidden, \[belgeleme\] çok önemlidir. Şu ana kadarki belgeler mükemmeldi ve Babil'in keskin bir özelliği oldu. Bazı özellikleri kesinlikle kullanabilecek bölümler var, hatta burada bir paragrafın eklenmesi bile çok beğeni topluyor.
+  <p markdown="1" class="pquote-credit">
+- @kittens, ["Katkıda bulunanlar için çağrı"](https://github.com/babel/babel/issues/1347)
+  </p>
+</aside>
 
 ### Organize etmeyi sever misiniz?
 
-- Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin
-- Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765)
-- Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun.
+* Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin
+* Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765)
+* Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun.
 
 ### Kod yazmayı sever misiniz?
 
-- [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun
-- Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun
-- Proje kurulumunu otomatikleştirin
-- Araçları ve testleri geliştirin
+* [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun
+* Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun
+* Proje kurulumunu otomatikleştirin
+* Araçları ve testleri geliştirin
 
 ### İnsanlara yardım etmeyi sever misiniz?
 
-- Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te
-- İnsanlar için açık konulardaki soruları cevaplayın
-- Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun
+* Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te
+* İnsanlar için açık konulardaki soruları cevaplayın
+* Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun
 
 ### Başkalarına kod yazarken yardım etmeyi sever misiniz?
 
-- Diğer kişilerin gönderimlerindeki kodu inceleyin
-- Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın
-- Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+* Diğer kişilerin gönderimlerindeki kodu inceleyin
+* Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın
+* Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
 
 ### Sadece yazılım projeleri üzerinde çalışmak zorunda değilsiniz!
 
@@ -123,15 +147,21 @@ Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve d
 
 Örneğin:
 
-- @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome)
-- @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor
-- @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts)
+* @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome)
+* @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor
+* @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts)
 
 Bir yazılım geliştiricisi olsanız bile, bir dokümantasyon projesi üzerinde çalışmak açık kaynak kodla başlamanıza yardımcı olabilir. Kod içermeyen projeler üzerinde çalışmak genellikle daha az korkutucu olur ve işbirliği süreci sizin güven ve deneyiminizi artırır.
 
 ## Kendinizi yeni bir projeye yönlendirmek
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">   Bir sorun listesine giderseniz ve işler kafa karıştırıcı görünür, yalnız değilsiniz. Bu araçlar çok fazla bilgi gerektirir, ancak insanlar size yardımcı olabilir ve onlara sorular sorabilirsiniz.   <p markdown="1" class="pquote-credit"> - @shaunagm, ["Açık Kaynağa Nasıl Katkıda Bulunulur"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
+  Bir sorun listesine giderseniz ve işler kafa karıştırıcı görünür, yalnız değilsiniz. Bu araçlar çok fazla bilgi gerektirir, ancak insanlar size yardımcı olabilir ve onlara sorular sorabilirsiniz.
+  <p markdown="1" class="pquote-credit">
+- @shaunagm, ["Açık Kaynağa Nasıl Katkıda Bulunulur"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/) 
+  </p>
+</aside>
 
 Bir yazım hatasının düzeltilmesinden daha fazla olarak, açık kaynağa katkıda bulunmak, partideki bir grup yabancıyla konuşmaya çalışmak gibidir. Lamalar hakkında konuşmaya başlarsanız, akvaryum balığı ile ilgili derin bir tartışma yapıyorlarsa, muhtemelen size biraz garip bakarlar.
 
@@ -147,34 +177,34 @@ Bununla birlikte, birçok açık kaynak projenin benzer organizasyon yapıların
 
 Tipik bir açık kaynak projesi aşağıdaki insan türlerine sahiptir:
 
-- **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar)
-- **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir)
-- **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler)
-- **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes
-- **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler.
+* **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar)
+* **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir)
+* **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler)
+* **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes
+* **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler.
 
 Daha büyük projeler ayrıca araç yönetimi, öncelik yönetimi, topluluk yönetimi ve etkinlik organizasyonu gibi farklı görevlere odaklanmış alt komitelere veya çalışma gruplarına sahip olabilir. Bu bilgileri bulmak için bir projenin "ekip" sayfasına veya yönetim dokümantasyon deposuna bakın.
 
 Projelerin belgeleri de vardır. Bu dosyalar genellikle bir kütüphanenin dizin yapısının en üst seviyelerinde listelenir.
 
-- **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir.
-- **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar.
-- **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder.
-- **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir.
-- **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir.
+* **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir.
+* **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar.
+* **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder.
+* **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir.
+* **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir.
 
 Son olarak, açık kaynak projeler tartışmaları yönetmek için aşağıdaki araçları kullanır. Arşivleri okumak, topluluğun nasıl düşündüğü ve çalıştığı hakkında size iyi bir fikir verecektir.
 
-- **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler.
-- **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler.
-- **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır.
-- **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır.
+* **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler.
+* **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler.
+* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır.
+* **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır.
 
 ## Katkıda bulunacak bir proje bulma
 
 Açık kaynak projelerin nasıl çalıştığını çözdüğünüze göre, katkıda bulunacak bir proje bulma zamanı!
 
-Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, *"Ülkenizin sizin için neler yapabileceğini değil - ülkeniz için neler yapabileceğinizi sorun"* diyen ABD Başkanı John F. Kennedy'yi  örnek alın.
+Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, *"Ülkenizin sizin için neler yapabileceğini değil * ülkeniz için neler yapabileceğinizi sorun"* diyen ABD Başkanı John F. Kennedy'yi  örnek alın.
 
 Açık kaynağa katkıda bulunmak, farklı projelerde her seviyede gerçekleşir. İlk katkınızın tam olarak ne olacağını veya nasıl görüneceğini düşünmeniz gerekmez.
 
@@ -192,15 +222,15 @@ Düzeltebileceğiniz açık sorunları arıyorsanız, her açık kaynak projenin
 
 Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aşağıdaki kaynaklardan birini de kullanabilirsiniz:
 
-- [GitHub Explore](https://github.com/explore/)
-- [Open Source Friday](https://opensourcefriday.com)
-- [First Timers Only](https://www.firsttimersonly.com/)
-- [CodeTriage](https://www.codetriage.com/)
-- [24 Pull Requests](https://24pullrequests.com/)
-- [Up For Grabs](https://up-for-grabs.net/)
-- [Contributor-ninja](https://contributor.ninja)
-- [First Contributions](https://firstcontributions.github.io)
-- [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi
 
@@ -212,7 +242,9 @@ Katkıda bulunmak istediğiniz bir proje bulduğunuzda, projenin katkıları kab
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox1" class="overflow-hidden d-block text-normal">   Lisans var mı? Genellikle, proje kök dizininde LICENCE adlı bir dosya vardır.   </label>
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Lisans var mı? Genellikle, proje kök dizininde LICENCE adlı bir dosya vardır.
+  </label>
 </div>
 
 **Proje aktif olarak katkı kabul ediyor**
@@ -221,71 +253,97 @@ Ana daldaki geliştirici faaliyetine bakın. GitHub'da, bu bilgiyi bir kütüpha
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox2" class="overflow-hidden d-block text-normal">   En son kod değişikliği ne zaman yapılmış?   </label>
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    En son kod değişikliği ne zaman yapılmış?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox3" class="overflow-hidden d-block text-normal">   Projenin kaç katılımcısı var? </label>
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    Projenin kaç katılımcısı var?
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox4" class="overflow-hidden d-block text-normal">   İnsanlar ne sıklıkta geliştirme yapıyor? (GitHub'da, bunu üstteki çubukta "Commits" i tıklayarak bulabilirsiniz.)   </label>
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    İnsanlar ne sıklıkta geliştirme yapıyor? (GitHub'da, bunu üstteki çubukta "Commits" i tıklayarak bulabilirsiniz.)
+  </label>
 </div>
 
 Ardından, projenin sorun listesine bakın.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox5" class="overflow-hidden d-block text-normal">   Kaç tane açık sorun var?   </label>
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Kaç tane açık sorun var?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox6" class="overflow-hidden d-block text-normal">   Geliştiriciler sorunlara hızlı bir şekilde yanıt veriyor mu?   </label>
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Geliştiriciler sorunlara hızlı bir şekilde yanıt veriyor mu?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox7" class="overflow-hidden d-block text-normal">   Sorunların altında aktif tartışma var mı?   </label>
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Sorunların altında aktif tartışma var mı?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox8" class="overflow-hidden d-block text-normal">   Sorunlar yeni mi?   </label>
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Sorunlar yeni mi?
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox9" class="overflow-hidden d-block text-normal">   Sorunlar kapanıyor mu? (GitHub'da kapalı sorunları görmek için Konular sayfasındaki "kapalı" sekmesine tıklayın.)   </label>
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Sorunlar kapanıyor mu? (GitHub'da kapalı sorunları görmek için Konular sayfasındaki "kapalı" sekmesine tıklayın.)
+  </label>
 </div>
 
 Şimdi aynısını projenin PR listesi için yapın.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox10" class="overflow-hidden d-block text-normal">   Kaç tane açık PR var?   </label>
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    Kaç tane açık PR var?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox20" class="overflow-hidden d-block text-normal">   Sağlayıcılar PR'ları hızlı bir şekilde yanıtlıyor mu?   </label>
+  <label for="cbox20" class="overflow-hidden d-block text-normal">
+    Sağlayıcılar PR'ları hızlı bir şekilde yanıtlıyor mu?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox11" class="overflow-hidden d-block text-normal">     PR'lar üzerinde aktif tartışma var mı?   </label>
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    PR'lar üzerinde aktif tartışma var mı?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox12" class="overflow-hidden d-block text-normal">     PR yeni mi gelmiş?   </label>
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    PR yeni mi gelmiş?
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox13" class="overflow-hidden d-block text-normal">     Yakındazamanda ne kadar PR birleştirilmiş? (GitHub'da kapalı PR'leri görmek için PR sayfasındaki "kapalı" sekmesine tıklayın.)   </label>
+  <label for="cbox13" class="overflow-hidden d-block text-normal">
+    Yakındazamanda ne kadar PR birleştirilmiş? (GitHub'da kapalı PR'leri görmek için PR sayfasındaki "kapalı" sekmesine tıklayın.)
+  </label>
 </div>
 
 **Proje katkı bekliyor mu?**
@@ -294,25 +352,39 @@ Arkadaş canlısı ve misafirperver bir proje, yeni katılımcılara açık olac
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox14" class="overflow-hidden d-block text-normal">     Geliştiriciler, sorunlardaki sorulara yardımcı oluyor mu?   </label>
+  <label for="cbox14" class="overflow-hidden d-block text-normal">
+    Geliştiriciler, sorunlardaki sorulara yardımcı oluyor mu?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox15" class="overflow-hidden d-block text-normal">     İnsanlar konularda, tartışma forumunda ve sohbette (örneğin, IRC veya Slack) arkadaş canlısı mı?   </label>
+  <label for="cbox15" class="overflow-hidden d-block text-normal">
+    İnsanlar konularda, tartışma forumunda ve sohbette (örneğin, IRC veya Slack) arkadaş canlısı mı?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox16" class="overflow-hidden d-block text-normal">     PR'lar inceleniyor mu?   </label>
+  <label for="cbox16" class="overflow-hidden d-block text-normal">
+    PR'lar inceleniyor mu?
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox17" class="overflow-hidden d-block text-normal">     Geliştiriciler insanlara katkılarından dolayı teşekkür eder mi?   </label>
+  <label for="cbox17" class="overflow-hidden d-block text-normal">
+    Geliştiriciler insanlara katkılarından dolayı teşekkür eder mi?
+  </label>
 </div>
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">   Ne zaman uzun bir tartışma görüyorsanız, çekirdek geliştiricilerin konu başından geç gelen cevaplarını anında kontrol edin. Yapıcı bir şekilde özetliyorlar mı ve kibarlıklarını korurken bir karar vermek için adımlar atıyorlar mı? Çok fazla söz savaşı yaşandığını görüyorsanız, bu genellikle enerjinin gelişme yerine tartışmaya girdiğinin işaretidir.   <p markdown="1" class="pquote-credit"> - @kfogel, [_OPS_ üretiliyor](https://producingoss.com/en/evaluating-oss-projects.html)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Ne zaman uzun bir tartışma görüyorsanız, çekirdek geliştiricilerin konu başından geç gelen cevaplarını anında kontrol edin. Yapıcı bir şekilde özetliyorlar mı ve kibarlıklarını korurken bir karar vermek için adımlar atıyorlar mı? Çok fazla söz savaşı yaşandığını görüyorsanız, bu genellikle enerjinin gelişme yerine tartışmaya girdiğinin işaretidir.
+  <p markdown="1" class="pquote-credit">
+- @kfogel, [_OPS_ üretiliyor](https://producingoss.com/en/evaluating-oss-projects.html)
+  </p>
+</aside>
 
 ## Nasıl katkı yapılır?
 
@@ -322,7 +394,13 @@ Hoşunuza giden bir proje buldunuz ve katkıda bulunmaya hazırsınız. En sonun
 
 İster bir kerelik bir katkı yapan, ister bir topluluğa katılmaya çalışan biri olun, başkalarıyla çalışmak açık kaynak dünyasında geliştireceğiniz en önemli becerilerden biridir.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">   \[Yeni bir katılımcı olarak \] ben bir sorunu çözmek istediğimde hemen soru sormam gerektiğini fark ettim. Kod tabanında dolaştım. Bir konunun ne olduğunu anladığıma dair bir şeyler hissettiğimde, daha fazla yardım istemiştim. Ve voilà! İhtiyacım olan tüm detayları aldıktan sonra sorunu çözebildim.   <p markdown="1" class="pquote-credit"> - @shubheksha, [Yeni Başlayanlar İçin Açık Kaynak Dünyasında İnişli Çıkışlı Yolculuk](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
+  \[Yeni bir katılımcı olarak \] ben bir sorunu çözmek istediğimde hemen soru sormam gerektiğini fark ettim. Kod tabanında dolaştım. Bir konunun ne olduğunu anladığıma dair bir şeyler hissettiğimde, daha fazla yardım istemiştim. Ve voilà! İhtiyacım olan tüm detayları aldıktan sonra sorunu çözebildim.
+  <p markdown="1" class="pquote-credit">
+- @shubheksha, [Yeni Başlayanlar İçin Açık Kaynak Dünyasında İnişli Çıkışlı Yolculuk](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+  </p>
+</aside>
 
 Bir sorunu açmadan veya bir PR oluşturmadan ya da sohbette bir soru sormadan önce, fikirlerinizi etkili bir şekilde ortaya çıkarmak için bu noktaları aklınızda bulundurun.
 
@@ -370,47 +448,53 @@ Herhangi bir şey yapmadan önce, fikrinizin başka bir yerde tartışılmadığ
 
 Fikrinizi başka bir yerde bulamazsanız, harekete geçmeye hazırsınız. Proje GitHub'taysa, muhtemelen bir sorun açarak veya PR oluşturarak iletişim kurarsınız:
 
-- **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir
-- **PR** bir çözüm üzerinde çalışmaya başlamak içindir
-- **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin.
+* **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir
+* **PR** bir çözüm üzerinde çalışmaya başlamak içindir
+* **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin.
 
 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.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">   Aktif olarak kullandığınız bir projeyi seçmek, GitHub'da “izlemek” ve her konuyu ve PR'ı okumaktan <em>çok şey</em> öğreneceksiniz.   <p markdown="1" class="pquote-credit"> - @gaearon [birleştirme projelerinde](https://twitter.com/dan_abramov/status/819555257055322112)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
+  Aktif olarak kullandığınız bir projeyi seçmek, GitHub'da “izlemek” ve her konuyu ve PR'ı okumaktan <em>çok şey</em> öğreneceksiniz.
+  <p markdown="1" class="pquote-credit">
+- @gaearon [birleştirme projelerinde](https://twitter.com/dan_abramov/status/819555257055322112)
+  </p>
+</aside>
 
 ### Bir istek/sorun açmak
 
 Genellikle aşağıdaki durumlarda bir sorun açmalısınız:
 
-- Çözemediğiniz bir hatayı bildirmek için
-- Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar)
-- Yeni bir özellik veya başka bir proje fikri önermek için
+* Çözemediğiniz bir hatayı bildirmek için
+* Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar)
+* Yeni bir özellik veya başka bir proje fikri önermek için
 
 Sorunlar üzerinde iletişim kurmak için ipuçları:
 
-- **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır.
-- **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın.
-- **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır.
+* **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır.
+* **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın.
+* **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır.
 
 ### PR açma
 
 Genellikle aşağıdaki durumlarda bir PR açmalısınız:
 
-- Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata)
-- Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda
+* Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata)
+* Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda
 
 Bir PR, bitmiş işi temsil etmek zorunda değildir. PR'ı erkenden açmak genellikle daha iyidir, bu nedenle diğerleri ilerlemeniz hakkında fikir sahibi olabilir veya geribildirimde bulunabilir. Sadece konu satırında bir "WIP" (Çalışmakta Olan Çalışma) etiketi ile işaretlemeniz yeterlidir. Daha sonra her zaman daha fazla geliştirme ekleyebilirsiniz.
 
 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.)
-- 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.
-- **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun.
-- **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır.
+* **[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.)
+* 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.
+* **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun.
+* **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır.
 
 Bu ilk PR ise, @kentcdodds'ın bir örnek video eğitimi olarak oluşturduğu [Bir PR Yap](http://makeapullrequest.com/)'ı izleyin. Ayrıca, @Roshanjossey tarafından oluşturulan [First Contributions](https://github.com/Roshanjossey/first-contributions) deposunda çekme isteği yapmayı da deneyebilirsiniz.
 
diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index 7c8076466bc..e577a4289a3 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -30,15 +30,21 @@ Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek
 
 ### İnsanlar neden işlerini açık kaynak olarak sunarlar?
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">   Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.   <p markdown="1" class="pquote-credit"> — @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+  Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.
+  <p markdown="1" class="pquote-credit">
+— @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+  </p>
+</aside>
 
 Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler:
 
-- **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur.
+* **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur.
 
-- **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
+* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
 
-- **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
+* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
 
 Açık kaynak sadece yazılım için değil. Veri kümelerinden kitaplara kadar her şeyi açık kaynak koduyla açabilirsiniz. Açık kaynak başka neler yapabileceğiniz hakkında fikir edinmek için [GitHub Explore](https://github.com/explore)'a göz atın.
 
@@ -68,7 +74,13 @@ Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahi
 
 Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">   Bir noktada kullandığım özel bir UIAlertView işlevi oluşturdum ... ve onu açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca, diğer geliştiricilere projelerinde nasıl kullanılacağını açıklayan ilk belgelerimi de yazdım. Muhtemelen hiç kimse bunu kullanmamıştı çünkü bu basit bir projeydi ama katkım hakkında kendimi iyi hissediyordum.   <p markdown="1" class="pquote-credit"> — @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)   </p></aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+  Bir noktada kullandığım özel bir UIAlertView işlevi oluşturdum ... ve onu açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca, diğer geliştiricilere projelerinde nasıl kullanılacağını açıklayan ilk belgelerimi de yazdım. Muhtemelen hiç kimse bunu kullanmamıştı çünkü bu basit bir projeydi ama katkım hakkında kendimi iyi hissediyordum.
+  <p markdown="1" class="pquote-credit">
+— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+  </p>
+</aside>
 
 Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir.
 
@@ -78,7 +90,13 @@ Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve
 
 Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">   Projeyi açık kaynak yapmaya başladığınızda, yönetim süreçlerinizin projenizin çevresindeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. Şirketinizde çalışmayan katılımcıları projenin kilit yönlerine dahil etmekten korkmayın - özellikle de sık sık katkıda bulunanlarsa.   <p markdown="1" class="pquote-credit"> — @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)   </p></aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+  Projeyi açık kaynak yapmaya başladığınızda, yönetim süreçlerinizin projenizin çevresindeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. Şirketinizde çalışmayan katılımcıları projenin kilit yönlerine dahil etmekten korkmayın * özellikle de sık sık katkıda bulunanlarsa.
+  <p markdown="1" class="pquote-credit">
+— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+  </p>
+</aside>
 
 ### Diğer projelere katkıda bulunmak
 
@@ -94,10 +112,10 @@ 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/)
-- [Davranış kuralları](../code-of-conduct/)
+* [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/)
+* [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.
 
@@ -123,14 +141,20 @@ README'ler, projenizi nasıl kullanılacağını açıklamadan fazlasını yapar
 
 README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar.
 
-- Bu proje ne yapıyor?
-- Bu proje neden faydalıdır?
-- Kullanmaya nasıl başlarım?
-- İhtiyacım olursa nereden daha fazla yardım alabilirim?
+* Bu proje ne yapıyor?
+* Bu proje neden faydalıdır?
+* Kullanmaya nasıl başlarım?
+* İhtiyacım olursa nereden daha fazla yardım alabilirim?
 
 README'nizi, katkıları nasıl ele aldığınız, projenin hedeflerinin ne olduğu ve lisanslar ve atıfla ilgili bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkıları kabul etmek istemiyorsanız veya projeniz henüz üretime hazır değilse, bu bilgileri not edin.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">   Daha iyi dokümantasyon, daha fazla kullanıcı, daha az destek talebi ve daha fazla katılımcı anlamına gelir. (...) Okuyucularınızın siz olmadığını unutmayın. Tamamen farklı deneyimleri olan ve projeye gelebilecek insanlar var.   <p markdown="1" class="pquote-credit"> — @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&amp;list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&amp;index=10)   </p></aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+  Daha iyi dokümantasyon, daha fazla kullanıcı, daha az destek talebi ve daha fazla katılımcı anlamına gelir. (...) Okuyucularınızın siz olmadığını unutmayın. Tamamen farklı deneyimleri olan ve projeye gelebilecek insanlar var.
+  <p markdown="1" class="pquote-credit">
+— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&amp;list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&amp;index=10)
+  </p>
+</aside>
 
 README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin.
 
@@ -142,15 +166,15 @@ Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make
 
 Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler.
 
-- Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin)
-- Yeni bir özellik nasıl önerilir
-- Proje ortamı nasıl kurulur ve testler nasıl yapılır
+* Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin)
+* Yeni bir özellik nasıl önerilir
+* Proje ortamı nasıl kurulur ve testler nasıl yapılır
 
 Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır:
 
-- Aradığınız katkı türleri
-- Proje için yol haritanız veya vizyonunuz
-- Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli)
+* Aradığınız katkı türleri
+* Proje için yol haritanız veya vizyonunuz
+* Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli)
 
 Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır:
 
@@ -170,7 +194,13 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan
 
 ### Davranış kural listesi oluşturmak
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">   Hepimiz, muhtemelen bir şeyin neden belirli bir şekilde olması gerektiğini açıklamaya çalışan bir proje sahibi olarak ya da bir kullanıcı olarak basit bir soru gibi sorulan istismarla karşılaştığımız deneyimler yaşadık. (...) Davranış kuralları, ekibinizin yapıcı söylemi çok ciddiye aldığını gösteren, kolayca atıfta bulunulabilir ve bağlanabilir bir belge haline gelir.  <p markdown="1" class="pquote-credit"> — @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)   </p></aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+  Hepimiz, muhtemelen bir şeyin neden belirli bir şekilde olması gerektiğini açıklamaya çalışan bir proje sahibi olarak ya da bir kullanıcı olarak basit bir soru gibi sorulan istismarla karşılaştığımız deneyimler yaşadık. (...) Davranış kuralları, ekibinizin yapıcı söylemi çok ciddiye aldığını gösteren, kolayca atıfta bulunulabilir ve bağlanabilir bir belge haline gelir.
+  <p markdown="1" class="pquote-credit">
+— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+  </p>
+</aside>
 
 Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır.
 
@@ -190,8 +220,8 @@ Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosy
 
 Marka, gösterişli bir logo veya çekici bir proje adından daha fazlasıdır. Projeniz hakkında nasıl konuştuğunuzla ve mesajınızla kime ulaştığınızla ilgilidir.
 
-- [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler
-- [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur
+* [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler
+* [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur
 
 Mevcut bir projenin üzerine inşa ediyorsanız, adlarını ön ek olarak kullanmak projenizin ne yaptığını netleştirmeye yardımcı olabilir (örneğin, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` komutunu getirir).
 
@@ -215,7 +245,13 @@ Projenizin ömrü boyunca birçok yazı yazacaksınız; README'ler, öğretici b
 
 Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">   Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.   <p markdown="1" class="pquote-credit"> — [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.
+  <p markdown="1" class="pquote-credit">
+— [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
 
 Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün.
 
@@ -231,39 +267,53 @@ Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol l
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox1" class="overflow-hidden d-block text-normal">     Projenin açık kaynak lisanslı LICENSE dosyası var   </label>
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Projenin açık kaynak lisanslı LICENSE dosyası var
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox2" class="overflow-hidden d-block text-normal">     Proje temel dokümantasyona sahiptir (README, CONTRIBUTING, CODE_OF_CONDUCT)   </label>
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    Proje temel dokümantasyona sahiptir (README, CONTRIBUTING, CODE_OF_CONDUCT)
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox3" class="overflow-hidden d-block text-normal">     Adı hatırlamak kolaydır, projenin ne yaptığı hakkında bir fikir verir ve mevcut bir projeyle çelişmez veya ticari markaları ihlal etmez   </label>
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    Adı hatırlamak kolaydır, projenin ne yaptığı hakkında bir fikir verir ve mevcut bir projeyle çelişmez veya ticari markaları ihlal etmez
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox4" class="overflow-hidden d-block text-normal">     Sorun listesi, açıkça düzenlenmiş ve etiketlenmiş konularla birlikte güncel   </label>
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    Sorun listesi, açıkça düzenlenmiş ve etiketlenmiş konularla birlikte güncel
+  </label>
 </div>
 
 **Kod**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox5" class="overflow-hidden d-block text-normal">     Proje tutarlı kod kuralları ve temiz işlev/yöntem/değişken adlarını kullanıyor   </label>
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Proje tutarlı kod kuralları ve temiz işlev/yöntem/değişken adlarını kullanıyor
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox6" class="overflow-hidden d-block text-normal">     Kod açıkça yorumlanmış, amaçları ve aykırı vakaları belgelemektedir.   </label>
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Kod açıkça yorumlanmış, amaçları ve aykırı vakaları belgelemektedir.
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox7" class="overflow-hidden d-block text-normal">     Revizyon geçmişinde, sorunlarda veya PR isteklerinde (örneğin şifreler veya kamuya açık olmayan diğer bilgiler) hassas bilgi yok   </label>
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Revizyon geçmişinde, sorunlarda veya PR isteklerinde (örneğin şifreler veya kamuya açık olmayan diğer bilgiler) hassas bilgi yok
+  </label>
 </div>
 
 **İnsanlar**
@@ -272,29 +322,39 @@ Bireyseniz:
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox8" class="overflow-hidden d-block text-normal">     Hukuk departmanıyla konuştunuz ve/veya şirketinizin IP ve açık kaynaklı politikalarını anladınız (eğer bir yerde çalışansanız).   </label>
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Hukuk departmanıyla konuştunuz ve/veya şirketinizin IP ve açık kaynaklı politikalarını anladınız (eğer bir yerde çalışansanız).
+  </label>
 </div>
 
 Bir şirket veya kuruluşsanız:
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox9" class="overflow-hidden d-block text-normal">     Hukuk departmanınızla konuştunuz   </label>
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Hukuk departmanınızla konuştunuz
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox10" class="overflow-hidden d-block text-normal">     Projeyi duyurmak ve tanıtmak için bir pazarlama planınız var   </label>
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    Projeyi duyurmak ve tanıtmak için bir pazarlama planınız var
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox11" class="overflow-hidden d-block text-normal">     Birisi topluluk etkileşimlerini yönetmeyi taahhüt eder (sorunlara cevap verme, çekme isteklerini gözden geçirme ve birleştirme)   </label>
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Birisi topluluk etkileşimlerini yönetmeyi taahhüt eder (sorunlara cevap verme, çekme isteklerini gözden geçirme ve birleştirme)
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox12" class="overflow-hidden d-block text-normal">     En az iki kişinin projeye yönetici erişimi var   </label>
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    En az iki kişinin projeye yönetici erişimi var
+  </label>
 </div>
 
 ## Başardınız!

From 06c7506fdee312aa1816e1d22ca659449fcef07e Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 12 May 2021 08:07:42 +0000
Subject: [PATCH 170/749] Bump actions/setup-ruby from 1 to 1.1.3

Bumps [actions/setup-ruby](https://github.com/actions/setup-ruby) from 1 to 1.1.3.
- [Release notes](https://github.com/actions/setup-ruby/releases)
- [Commits](https://github.com/actions/setup-ruby/compare/v1...v1.1.3)

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 27f8a14d6a8..0eb22ebf388 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
       uses: actions/checkout@v2.3.4
 
     - name: Set up Ruby
-      uses: actions/setup-ruby@v1
+      uses: actions/setup-ruby@v1.1.3
 
     - name: Set up Node
       uses: actions/setup-node@v2.1.5

From 5470c2f44c3d8d8c01c66d9f7c6b019b4baa8b5b Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Fri, 14 May 2021 16:20:21 +0430
Subject: [PATCH 171/749] Initial translation done.

---
 _articles/fa/legal.md | 152 +++++++++++++++++++++---------------------
 1 file changed, 76 insertions(+), 76 deletions(-)

diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index ed6cf093fd5..fe8c35ec5f4 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -1,16 +1,8 @@
 ---
-lang: en
-title: The Legal Side of Open Source
-description: Everything you've ever wondered about the legal side of open source, and a few things you didn't.
+lang: fa
+title: جنبه‌های حقوقی پروژه‌های متن باز
+description: تمامی چیزهایی که در مورد جنبه‌های حقوقی متن باز برای شما سوال شده و چیزهایی که سوال نشده.
 class: legal
-toc:
-  why-do-people-care-so-much-about-the-legal-side-of-open-source: "Why do people care so much about the legal side of open source?"
-  are-public-github-projects-open-source: "Are public GitHub projects open source?"
-  just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Just give me the TL;DR on what I need to protect my project"
-  which-open-source-license-is-appropriate-for-my-project: "Which open source license is appropriate for my project?"
-  what-if-i-want-to-change-the-license-of-my-project: "What if I want to change the license of my project?"
-  does-my-project-need-an-additional-contributor-agreement: "Does my project need an additional contributor agreement?"
-  what-does-my-companys-legal-team-need-to-know: "What does my company’s legal team need to know?"
 order: 10
 image: /assets/images/cards/legal.png
 related:
@@ -18,149 +10,157 @@ related:
   - leadership
 ---
 
-## Understanding the legal implications of open source
+## درک پیامدهای حقوقی پروژه‌های منبع آزاد
 
-Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+اشتراک گذاشتن کارهای خلاقانه با جهانیان می‌تواند تجربه‌ای هیجان‌انگیز و ارزشمند باشد. همچنین می‌تواند به معنای درگیر شدن با یک سری موارد حقوقی باشد در رابطه با آن‌ها چیزی نمی‌دانید. خوشبختانه، نیازی نیست از ابتدا شروع کنید. ما نیازهای حقوقی شما را برآورده کرده و پوشش داده‌ایم. (قبل از شروع، حتماً متن [سلب مسئولیت](/notices/) ما را بخوانید.) 
 
-## Why do people care so much about the legal side of open source?
+## چرا مردم اینقدر به جنبه‌های حقوقی متن آزاد اهمیت می‌دهند؟
 
-Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+به طور کلی، به این معنی است که هیچ کس دیگری نمی‌تواند از اثر شما استفاده کند، کپی کند، پخش کند یا اصلاحاتی روی آن انجام دهد؛ بدون اینکه در معرض ریسک دعوی قضایی و پیگیری قرار بگیرد.
 
-In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+هرچند پروژه‌های متن باز شرایطی غیرمعمول دارند، زیرا خالق اثر انتظار دارد که دیگران از اثر استفاده کنند و آن را اصلاح نمایند و به اشتراک بگذارند. اما از آنجا که پیش‌فرض قانونی همچنان شامل حقق نشر می‌شود، شما به مجوزی نیاز دارید که صریحاً این دسترسی‌ها را میسر سازد.
 
-Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+اگر مجوز (لایسنس) مربوط به پروژه‌های متن باز را اعمال نکنید، همه کسانی که در پروژۀ شما مشارکت می‌کنند نیز به عنوان دارندۀ حق نشر برای کارهای منحصر به فرد خود شناخته می‌شوند. این بدان معناست که هیچ کس نمی‌تواند از مشارکت‌های خود استفاده یا کپی کند و آن را توزیع یا اصلاح نماید و این «هیچ کس» شامل شما هم می‌شود.
 
-If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+در آخر اینکه ممکن است پروژۀ شما وابستگی‌هایی با ملزومات مجوز داشته باشد که از آن‌ها اطلاع نداشته باشید. انجمن (community) پروژه یا سیاست‌های کارفرمایی شما نیز ممکن است پروژه را ملزم به استفاده از مجوز‌های متن باز خاصی بکند. در زیر دربارۀ آن توضیح می‌دهیم.
 
-Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
 
-## Are public GitHub projects open source?
+## آیا پروژه‌های عمومی «GitHub» متن باز محسوب می‌شوند؟
 
-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**.
+هنگام ایجاد [پروژه‌ای جدید](https://help.github.com/articles/creating-a-new-repository/) در «GitHub»، این انتخاب را دارید که منبع را **خصوصی** یا **عمومی** مشخص کنید
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+**عمومی کردن پروژه‌تان در «GitHub» به منزلۀ مجوزدار کردن پروژه نیست.** پروژه‌های عمومی‌ای که [تحت شرایط خدمات «GitHub»](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) قرار می‌گیرند این امکان را برای افراد میسر می‌سازد که پروژه شما را مشاهده کنند و آن را فورک (fork) کنند، اما در غیر این افراد همچین اجازه‌ای ندارند.
 
-If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+اگر می‌خواهید دیگران از پروژۀ شما استفاده کنند، آن را توزیع دهند یا اصلاح نمایند و در آن مشارکت کنند، باید پروانۀ مخصوص پروژه‌های متن باز داشته باشید. به عنوان مثال، کسی قانونا نمی‌تواند از هر بخشی از پروژۀ «GitHub» شما در کد خود استفاده کند، حتی اگر عمومی باشد؛ مگر اینکه صریحاً به او اجازۀ چنین کاری را بدهید.
 
-## Just give me the TL;DR on what I need to protect my project.
+## به من توضیحات تکمیلی را در مورد چگونگی مراقبت از پروژه بدهید
 
-You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+امروزه کار خیلی ساده‌تر شده است زیرا مجوز‌های پروژه‌های متن باز استاندارد شده و استفاده از آن‌ها آسان است. می‌توانید مجوزهای (پروانه‌های) موجود را مستقیماً در پروژۀ خود کپی کنید.
 
-[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 the most popular open source 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/).
+[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] پیدا کنید.
 
-When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/).
+وقتی پروژۀ جدیدی را در «GitHub» ایجاد می‌کنید، [از شما خواسته می‌شود مجوزی را انتخاب کرده و به پروژه اضافه کنید](https://help.github.com/articles/open-source-licensing/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
-  A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+  یک مجوز استاندارد به عنوان جایگزینی برای کسانی که اطلاعات کافی از مسائل حقوقی ندارند و نمی‌دانند چه کارهایی می‌توانند با این نرم‌افزار انجام دهند، عمل می‌کند. تا جایی که می‌توانید از شرایط و ضوابط دستکاری شده، اصلاح شده یا غیراستاندارد اجتناب کنید، چونکه آن‌ها در آینده به صورت مانعی در استفاده و دریافت کدها عمل می‌کنند.
   <p markdown="1" class="pquote-credit">
 — @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
   </p>
 </aside>
 
-## Which open source license is appropriate for my project?
+## چه مجوز متن بازی برای پروژۀ من مناسب است؟
 
-If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+اگر تازه‌کار هستید، [مجوز MIT](https://choosealicense.com/licenses/mit/) به درد شما می‌خورد. کوتاه است، درک آن بسیار آسان می‌باشد و به هر کسی اجازه می‌دهد هر کاری انجام دهد تا زمانی که کپی مجوز، از جمله اخطار حق نشر شما را نگه دارند. در صورت نیاز، می‌توانید پروژه را تحت هر مجوز دیگری انتشار دهید.
 
-Otherwise, picking the right open source license for your project depends on your objectives.
+در غیر این صورت، انتخاب مجوز متن باز مناسب برای پروژۀ شما به اهداف‌تان بستگی دارد.
 
-Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+پروژۀ شما به احتمال زیاد **وابستگی‌ها** و مولفه‌های فراوانی داشته باشد (یا خواهد داشت). به عنوان مثال، اگر در پروژۀ متن باز خود از «Node.js» استفاده می‌کنید، احتمالاً از کتابخانه‌های Node Package Manager (npm) (مدیریت پکیج Node) استفاده خواهید کرد. هر کدام از این کتابخانه‌هایی که به آن‌ها وابسته هستید، مجوز (لایسنس، پروانه) متن باز مخصوص به خود را دارند. اگر هر یک از مجوزهای آن‌ها «اختیاری» باشد (بدون هیچ گونه شرطی برای فعالیت‌های آینده، اجازۀ استفاده، اصلاح، تغییر و اشتراک‌گذاری را به عموم مردم می‌دهد)، می‌توانید از هر مجوزی که می‌خواهید استفاده کنید. مجوزهای اختیاری متداول شامل «MIT»، «Apache 2.0»، «ISC» و «BSD» می‌شوند.
 
-On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+از طرف دیگر، اگر هر یک از مجوزهای وابستگی شما، «کپی‌لفت قوی» باشند (مشروط به استفاده از همان مجوز در آینده، مجوزهای عمومی مشابهی را می‌دهد)، در این صورت پروژۀ شما باید از همان مجوز استفاده کند. مجوزهای متداول کپی‌لفت ((Copyleft (تعریف: کپی‌لفت نوعی بازی با کلمهٔ کپی‌رایت است. کپی‌لفت عملی را توصیف می‌کند که در آن تضمین می‌شود که اجازهٔ نسخه‌برداری و ویرایش یک اثر برای همگان محفوظ می‌مانَد و هیچ شخصی اجازه ندارد حق ویرایش و نسخه‌برداری را از دیگر افراد سلب کند.) قوی شامل «GPLv2»، «GPLv3»  و «AGPLv3» می‌شوند.
 
-You may also want to consider the **communities** you hope will use and contribute to your project:
+همچنین ممکن است بخواهید **انجمن‌هایی** را در نظر بگیرید که امیدوار هستید از پروژۀ شما استفاده کنند و در آن مشارکت کنند:
 
-* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
-* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
-* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+* **آیا می‌خواهید پروژۀ شما به عنوان وابستگی توسط سایر پروژه‌ها مورد استفاده قرار گیرد؟** بهتر است محبوب‌ترین نوع مجوز را در انجمن‌تان استفاده کنید. به عنوان مثال، [MIT](https://choosealicense.com/licenses/mit/) محبوب‌ترین مجوز برای [کتابخانه‌های npm](https://libraries.io/search?platforms=NPM) است.
 
-Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+* **آیا می‌خواهید پروژۀ شما مورد توجه کسب و کارهای بزرگ قرار بگیرد؟** کسب‌وکارهای بزرگ احتمالاً سریعا مجوز ثبت اختراع را از تمامی مشارکت‌کنندگان می‌خواهند. در این صورت، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) به درد شما و آن‌ها می‌خورد.
 
-When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+* **آیا می‌خواهید پروژه شما مورد توجه مشارکت‌کنندگانی قرار بگیرد که نمی‌خواهند مشارکت‌های آن‌ها در نرم‌افزارهای متن بسته مورد استفاده قرار بگیرد؟** [GPLv3] یا (همچنین اگر آن‌ها تمایلی به مشارکت در خدمات متن بسته ندارند) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) به درد خواهد خورد.
 
-## What if I want to change the license of my project?
+ممکن است **شرکت** شما در پروژه‌های متن باز، شرایط خاصی برای مجوزها داشته باشد. به عنوان مثال، ممکن است به مجوز اختیاری نیاز داشته باشد تا شرکت بتواند از پروژۀ شما در محصول متن بستۀ خود استفاده کند. یا ممکن است شرکت شما به یک مجوز کپی‌لفت قوی و یک توافق‌نامۀ همکاری اضافی نیاز داشته باشد (به زیر مراجعه کنید) تا فقط منحصرا شرکت شما بتواند از پروژه در نرم‌افزارهای متن بسته استفاده کند. یا ممکن است شرکت شما نیازها و شرایط خاصی در رابطه با استانداردها، مسئولیت‌های اجتماعی یا شفافیت داشته باشد، که هر یک از آن‌ها ممکن است به یک استراتژی خاص دیگری در ارتباط با مجوز نیاز داشته باشد. با [بخش حقوقی شرکت] خود در رابطه با این موارد صحبت کنید.
 
-Most projects never need to change licenses. But occasionally circumstances change.
+هنگام ایجاد پروژه جدید در «GitHub»، به شما امکان انتخاب نوع مجوز داده می‌شود. انتخاب یکی از مجوزهایی که در بالا ذکر شد، پروژۀ «GitHub» شما را متن باز می‌کند. اگر مایل به دیدن گزینه‌های دیگه‌ای هستید، [choosealicense.com](https://choosealicense.com) را بررسی کنید تا مجوز مناسب‌تان را پیدا کنید حتی اگر برای [نرم‌افزار](https://choosealicense.com/non-software/) نباشد.
 
-For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+## اگر بخواهم مجوز پروژۀ خود را تغییر دهم چه کاری باید بکنم؟
 
-**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+اکثر پروژه‌ها به تغییر دادن مجوز خود، نیازی پیدا نمی‌کنند. ولی گاهی اوقات شرایط فرق می‌کند.
 
-**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+به عنوان مثال، با رشد پروژۀ شما، وابستگی‌ها یا کاربران آن اضافه می‌شود یا شرکت شما استراتژی‌های خود را تغییر می‌دهد که هرکدام از آن‌ها نیاز به مجوز دیگری دارند. همچنین، اگر از ابتدا مجوزی برای پروژۀ خود انتخاب نکردید، افزودن مجوز در واقع تفاوتی با تغییر مجوز ندارد. هنگام افزودن یا تغییر مجوز پروژه، سه نکتۀ اساسی باید در نظر گرفته شود:
 
-**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+**کاری پیچیده است.** تعیین سازگاری و انطباق مجوز و حق نشر می تواند خیلی زود پیچیده و گیج‌کننده شود. تغییر مجوز به مجوزی جدید و سازگار برای نسخه‌های جدید و مشارکت‌ها با تغییر مجوز تمامی مشارکت‌های موجود، تفاوت‌هایی دارد. در اولین قدم، در صورت تمایل به تغییر مجوزها، تیم حقوقی شما درگیر می‌شود. حتی اگر برای تغییر مجوز از دارندگان حق نشر پروژه خود اجازه دارید یا می‌توانید از آن‌ها اجازه بگیرید، تأثیر این تغییر را بر سایر کاربران و مشارکت‌کنندگان پروژۀ خود در نظر داشته باشید. تغییر مجوز را به صورت یک «رویداد مدیریتی» برای پروژۀ خود تصور کنید که به احتمال زیاد با برقراری ارتباط صریح و مشورت با ذی‌نفعان پروژه، هموارتر پیش خواهد رفت. بنابراین بهتر است از بدو تأسیس، مجوزی مناسب را برای پروژۀ خودتان انتخاب کنید!
 
-Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+**مجوز موجود و فعلی پروژه‌تان.** در صورتی که مجوز کنونی پروژۀ شما با مجوزی که می‌خواهید به آن تغییر دهید سازگار باشد، می‌توانید از مجوز جدید استفاده کنید. به این دلیل که اگر مجوز A با مجوز B سازگار باشد، در حالی که با شرایط B مطابقت دارید، با شرایط A نیز منطبق خواهید بود (اما لزوما برعکس آن درست نیست). بنابراین اگر در حال حاضر از مجوزی اختیاری استفاده می‌کنید (به عنوان مثال، «MIT»)، می‌توانید به مجوزی با شرایط بیشتری تغییر مجوز دهید، به شرطی که نسخه‌ای از مجوز «MIT» و هرگونه شرط حق نشر دیگۀ مربوط به آن را حفظ کنید (یعنی همچنان با حداقل شرایط مجوز «MIT» سازگار باشید). اما اگر مجوز فعلی شما اختیاری نباشد (به عنوان مثال کپی‌لفت باشد یا مجوزی نداشته باشید) و تنها دارندۀ حق نشر نیستید، نمی‌توانید مجوز پروژۀ خود را به «MIT» تغییر دهید. اساساً، صاحبان حق نشر پروژه با داشتن مجوز اختیاری از قبل اجازۀ تغییر مجوزها را داده‌اند.
 
-## Does my project need an additional contributor agreement?
+**صاحبان کنونی حق‌نشر پروژه‌تان.** اگر تنها مشارکت‌کننده در پروژه‌تان هستید، شما یا شرکت شما تنها صاحبان حق‌نشر این پروژه خواهید بود. خودتان یا شرکت می‌توانید، مجوز را تغییر دهید یا مجوز جدیدی اضافه کنید. در غیر این صورت ممکن است باید قبل از تغییر مجوز، با دیگر صاحبان حق‌نشر به توافق برسید. آن‌ها چه کسانی هستند؟ افرادی که در متعهد به پروژه هستند، نفطۀ خوبی برای شروع است. اما در برخی موارد حق‌نشر توسط افراد بالادستی این افراد حفظ می‌شود. در برخی موارد افراد مشارکت کم و حداقلی داشته‌اند، اما هیچ قانون سخت و جدی وجود ندارد که بگوید افرادی که مشارکتی در برخی از خطوط کد داشته‌اند مشمول حق‌نشر نباشد. چه کار باید کرد؟ بستگی دارد. برای پروژه‌ای نسبتاً کوچک و تازه‌شکل گرفته، ممکن است امکان‌پذیر باشد که همۀ مشارکت‌کنندگان موجود با تغییر مجوز در طرح مسئله‌ای یا در درخواست pullی موافقت کنند. برای پروژه‌های بزرگ و قدیمی، ممکن است برای مثلا تغییر مجوز مجبور شوید به جستجوی بسیاری از مشارکت‌کنندگان و حتی ورثه‌های آن‌ها مشغول شوید. موزیلا سال‌ها به طول انجامید (2001 تا 2006) تا مجوز «Firefox»، «Thunderbird» و دیگر نرم‌افزارهای مربوطه را تغییر دهد.
 
-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).
+همچنین می‌توانید موافقت مشارکت‌کنندگان را از قبل جلب کنید (از طریق توافق‌نامه‌های مشارکتی اضافی - به زیر مراجعه کنید) تا بتوانید کارتان را در مورد برخی از تغییرات مجوز تحت شرایط خاصی را فراتر از شرایط مجاز مجوز متن باز موجود پیش ببرید. این موضوع پیچیدگی تغییر مجوزها را کمی تغییر می‌دهد. برای اینکار به کمک وکلای خود بیشتر احتیاج خواهید داشت و هنوز هم باید در هنگام اجرای تغییر مجوز، به طور واضح با ذی‌نفعان پروژۀ خود صحبت کنید.
 
-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.
+## آیا پروژۀ من به توافق‌نامه‌های همکاری (مشارکتی) اضافی نیاز دارد؟
+
+به احتمال زیاد نه. برای اکثریت قریب به اتفاق پروژه‌های متن باز، یک مجوز متن آزاد به طور ضمنی به عنوان مجوز درونی (برای مشارکت‌کنندگان) و مجوز خارجی (برای سایر مشارکت‌کنندگان و کاربران) عمل می‌کند. اگر پروژۀ شما در «GitHub» میزبانی می‌شود، شرایط خدمات‌دهی «GitHub»، «مجوزهای درونی و مجوزهای خروجی را [صریحا پیش‌فرض](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license) درنظر می‌گیرد.
+
+توافق‌نامه‌های همکاری اضافی - که اغلب به آن توافق‌نامه مجوز مشارکت‌کننده (CLA) گفته می‌شود - برای نگهدارندگان پروژه می‌تواند کارهای مدیریتی ایجاد کند. اینکه توافق‌نامه چه مقدار کار اضافه می‌کند به پروژه و نحوۀ اجرای آن بستگی دارد. یک توافق‌نامه‌ی ساده ممکن است نیاز داشته باشد که مشارکت‌کنندگان با یک کلیک تأیید کنند که از حقوق لازم برای مشارکت در مجوز پروژه متن باز برخوردار هستند. یک توافق‌نامه‌ی پیچیده‌تر ممکن است نیاز به بررسی قانونی داشته باشد و مربوط به کارفرمایان مشارکت‌کنندگان شود.
+
+همچنین، با افزودن «تشریفات اداری» که به عقیدۀ برخی غیرضروری می‌باشد و فهم آن سخت یا ناعادلانه است (وقتی که ذی‌نفعان توافق‌نامه حقوق و مزایای بیشتری از مشارکت‌کنندگان یا عموم مردمی که کارهایی در پروژه‌ی متن باز انجام می‌دهند، به دست می‌آورند)؛ به همین خاطر ممکن است یک توافق‌نامه‌ی همکاری اضافی غیرمنصفانه نسبت به انجمن پروژه تلقی شود.
 
-Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
-    We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+    ما «توافق‌نامه مجوز مشارکت‌کننده» را برای «Node.js» حذف کردیم. انجام این کار موانع ورود مشارکت‌کنندگان به Node.js را کاهش می‌دهد و در نتیجه میزان مشارکت‌کنندگان را گسترش می‌دهد.
   <p markdown="1" class="pquote-credit">
 — @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
-Some situations where you may want to consider an additional contributor agreement for your project include:
+برخی از شرایطی که ممکن است بخواهید یک توافق‌نامه‌ی همکاری اضافی را برای پروژۀ خود در نظر بگیرید، شامل این موارد می‌شود:
+
+* وکلای شما می‌خواهند که تمامی مشارکت‌کنندگان به طور صریح شرایط مشارکت (آنلاین یا آفلاین) را بپذیرند، شاید به این دلیل که فکر می‌کنند مجوز متن باز به خودی خود کافی نیست (با اینکه هست!). اگر این تنها نگرانی است، توافق‌نامه‌ی مشارکت‌کننده که مجوز پروژۀ متن باز را تأیید می‌کند باید کافی باشد. [توافق‌نامۀ مجوز مشارکت‌کنند‌ۀ حقیقی jQuery] نمونۀ خوبی از توافق‌نامۀ همکاری اضافی خفیف است.
+
+* شما یا وکیل‌هاتان بخواهید توسعه‌دهندگان نشان دهند که هر تعهدی که روی آن کار می‌کنند مجاز است. الزام [گواهی مبدا توسعه‌دهنده](https://developercertificate.org/) برای این است که چه تعداد پروژه به این صورت هستند. به عنوان مثال، انجمن «Node.js» به جای «توافق‌نامۀ مجوز مشارکت‌کننده» قبلی خود از «گواهی مبدا توسعه‌دهنده» استفاده می کند. راهکار ساده برای اجرای خودکار «گواهی مبدا توسعه‌دهنده» در منبع (repository) شما، «ربات گواهی مبدا توسعه‌دهنده» است.
 
-* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
-* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
-* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
-* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
-* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
+* پروژۀ شما از یک مجوز متن باز استفاده بکند که شامل امتیاز ثبت اختراع (مانند MIT) نباشد و شما به داشتن سریع امتیاز ثبت اختراع  مشارکت‌کنندگان نیاز داشته باشید؛ برخی از آن‌ها ممکن است در شرکت‌هایی با مجموعه‌های بزرگ حق ثبت اختراع کار کنند که می‌تواند شما یا سایر مشارکت‌کنندگان و کاربران پروژه را مورد هدف قرار دهد. [توافق‌نامۀ مجوز مشارکت‌کنندگان حقیقی Apache]https://www.apache.org/licenses/icla.pdf)، یک توافق‌نامۀ همکاری اضافی است که معمولاً مورد استفاده قرار می‌گیرد و شامل امتیاز ثبت اختراع است که همانند آنچه در مجوز «Apache 2.0» یافت می‌شود، است.
 
-If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+* پروژۀ شما تحت مجوز کپی‌لفت باشد ، اما شما همچنین باید نسخه‌ای اختصاصی از پروژه را توزیع و پخش کنید. هر مشارکت‌کننده باید به شما حق نشر اختصاص دهد یا به شما (اما نه به عموم) مجوز اختیاری بدهد. [توافق‌نامۀ همکاری MongoDB](https://www.mongodb.com/legal/contributor-agreement) نمونه‌ای از این نوع توافق‌نامه است.
 
-## What does my company's legal team need to know?
+* ممکن باشد پروژۀ شما در طول عمر خود مجوزهایش را تغییر بدهد و بخواهید مشارکت‌کنندگان از قبل با چنین تغییراتی موافقت کنند.
 
-If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+اگر در پروژۀ خود نیازی به استفاده از توافق‌نامه‌های همکاری اضافی داشته باشید، استفاده از توافق‌نامه‌های یکپارچه‌سازی مانند [توافق‌نامۀ مجوز مشارکت‌کننده](https://github.com/cla-assistant/cla-assistant) را برای به حداقل رساندن حواس‌پرتی مشارکت‌کنندگان در نظر بگیرید.
 
-For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+## تیم حقوقی شرکت من چه چیزهایی را باید بداند؟
 
-**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+اگر به عنوان کارمند شرکت پروژه‌ای متن باز را منتشر می‌کنید، ابتدا تیم حقوقی باید بداند که شما در حال تهیۀ پروژه‌ای متن باز هستید.
 
-* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+حتما این موضوع را به آن‌ها بگویید حتی اگر این پروژه‌ای شخصی باشد. شما احتمالاً با شرکت خود «توافق‌نامۀ کارمندی» دارید که به آن‌ها تا حدودی کنترلی بر روی پروژه های شما می‌دهد، به خصوص اگر مربوط به شرکت باشند یا از منابع شرکت برای توسعۀ پروژه استفاده کرده باشید. شرکت شما _باید_ به شما اجازه دهد و ممکن است از قبل از طریق توافق‌نامه‌ی کارمندی یا سایر سیاست‌های شرکت مجوز داشته باشد. در غیر این صورت، می‌توانید مذاکره کنید (به عنوان مثال، توضیح دهید که پروژۀ شما اهداف یادگیری و توسعۀ حرفه‌ای شرکت را دنبال می‌کند)، یا تا زمانی که شرکت بهتری پیدا نکردید از کار بر روی پروژۀ خودتان خودداری کنید..
 
-* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+**اگر در جستجوی پروژه‌ای برای شرکت هستید،** قطعاً آن‌ها را در جریان بگذارید. تیم حقوقی شما احتمالاً قبلاً سیاست‌هایی را برای استفاده از مجوزهای متن باز (و شاید توافق‌نامه‌های همکاری اضافی) برای استفاده بر اساس الزامات تجاری و تخصصی شرکت در مورد اطمینان از مطابقت پروژۀ شما با مجوزهای وابستگی شرکت، در نظر گرفته است. اگر نه، به نفع هم شما و هم شرکت است! تیم حقوقی شما باید مشتاق همکاری با شما برای مشخص کردن این موارد باشد. چند مسئلۀ مهم:
 
-* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
+* **نهادهای واسط**  آیا پروژه شما وابستگی‌هایی به کار دیگران دارد یا در غیر این صورت کد دیگران را شامل می شود یا از آن‌ها استفاده می‌کند؟ اگر پروژه متن باز باشد، باید پروژۀ شما با مجوزهای متن باز مطابقت داشته باشد. این کار با انتخاب مجوز شروع می‌شود که مربوط به مجوزهای متن باز واسط می‌شود (نگاه کنید به بالا). اگر پروژۀ شما پروژه‌های متن باز واسط دیگر را اصلاح یا توزیع می‌کند، تیم حقوقی شما همچنین می‌خواهد بداند که شما سایر شرایط‌های مجوزهای متن باز واسط مانند حفظ اخطارهای حق نشر را رعایت می‌کنید یا خیر. اگر پروژۀ شما از کدهای دیگران استفاده می‌کند که فاقد مجوز متن باز هستند، احتمالاً باید از نگهدارندگان واسط بخواهید که [مجوز متن باز را اضافه کنند](https://choosealicense.com/no-license/#for-users) و اگر نمی‌توانید مجوز را دریافت کنید، استفاده از کد دیگران را در پروژۀ خوتان متوقف کنید.
 
-* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+* **اسرار کاری:** به این توجه داشته باشید که آیا چیزی در پروژه وجود دارد که شرکت نخواهد آن را در دسترس عموم قرار دهد. در این صورت، پس از مشخص کردن مطالبی که می‌خواهید خصوصی نگه دارید، می‌توانید بقیۀ پروژۀ خود را با متن باز کنید.
 
-* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+* **حق ثبت اختراع:** آیا شرکت شما متقاضی ثبت اختراعی است که متن باز آن پروژه در [دسترس عموم](https://en.wikipedia.org/wiki/Public_disclosure) است؟ متأسفانه، ممکن است از شما خواسته شود صبر کنید (یا شاید این شرکت در دیدگاه خود تجدید نظر کند). اگر انتظار دارید که کارمندان شرکت‌های بزرگی که دارای حق ثبت اختراع هستند، به پروژۀ شما کمک کنند و در آن مشارکت داشته باشند، ممکن است تیم حقوقی از شما بخواهد از یک مجوز با امتیاز ثبت اختراع سریع (از جمله Apache 2.0 یا GPLv3) یا توافق‌نامۀ همکاری اضافی استفاده کنید ( به بالا نگاه کنید).
 
-If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+* **نشان تجاری:** بررسی کنید تا نام پروژۀ شما با [هیچ نشان تجاری موجودی مغایرت نداشته باشد](../starting-a-project/#avoiding-name-conflicts). اگر از نشان‌های تجاری شرکت خود در پروژه استفاده می‌کنید، بررسی کنید تا هیچ مشکلی ایجاد نکند. [FOSSmarks](http://fossmarks.org/) یک راهنمای جامع برای شناخت نشان‌های تجاری در زمینه‌ی پروژه‌های متن باز و رایگان است.
 
-Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+* **حریم خصوصی:** آیا پروژۀ شما اطلاعات مربوط به کاربران را جمع‌آوری می‌کند؟ سرورهای شرکت، مکالمات را ضبط می‌کند؟ تیم حقوقی می‌تواند به شما در زمینه‌ی پیروی از سیاست‌های شرکت و آیین‌نامه‌های خارجی کمک کند.
 
-* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+اگر دارید اولین پروژه متن باز شرکت خود را منتشر می‌کنید، رعایت موارد فوق کافی است (اما نگران نباشید، اکثر پروژه‌ها نگرانی‌های اساسی خاصی نباید ایجاد کنند).
+
+در بلند مدت، تیم حقوقی می‌تواند کمک بیشتری به شرکت کند تا از مشارکت خود در پروژه‌های متن باز بهره‌ی بیشتری ببرد و در امان بماند:
+
+* سیاست های مربوط به مشارکت کارمندان سیاست‌هایی را تدوین کنید که مشخص سازد کارمندان شما در پروژه‌های متن باز چه نوع مشارکتی داشته باشند. داشتن سیاست‌های مشخص و واضح باعث کاهش سردرگمی در بین کارمندان و کمک به آن‌ها در مشارکت هرچه بهتر در پروژه‌های متن باز شرکت می‌شود؛ چه به عنوان بخشی از شغل آنها و چه به صورت فعالیت در اوقات فراغت‌شان. یک مثال خوب، [مدل‌های استاندارد و سیاست‌های همکاری در پروژه‌های متن باز](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) «Rackspace» است.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
-  Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+  منتشر کردن شناسه همراه با مشخصات سازندۀ پَچ، باعث ایجاد اعتبار و شناخته شدن کارمند می‌شود. این کار نشان می‌دهد که شرکت در توسعۀ کارمندان سرمایه‌گذاری کرده و باعث به وجود آمدن حس اختیار و استقلال کارمندان می‌شود. تمامی این منفعت‌ها، منجر به روحیۀ بالاتر و حفظ بهتر کارمندان می‌شود.
   <p markdown="1" class="pquote-credit">
 — @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
-* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
-* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+* **چه چیزهایی را منتشر کنیم:** [(تقریبا) همه چیز؟](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) اگر تیم حقوقی شما استراتژی متن باز شرکت شما را درک کرده و در آن سرمایه‌گذاری کرده باشد، به جای جلوگیری از تلاش‌هایتان، به بهترین وجه به شما کمک می‌کند.
+
+* **سازگاری:** حتی اگر شرکت شما هیچ پروژۀ متن بازی را منتشر نکند، از دیگر نرم‌افزارهای متن باز استفاده می‌کند. [داشتن آگاهی از روند کار](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) می‌تواند از بروز مشکلات بی‌جا، تأخیر در محصول و شکایات جلوگیری کند.
 
 <aside markdown="1" class="pquote">
-  Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+ شرکت‌ها باید دارای مجوزها و استراتژی‌های انطباقی باشند که متناسب با هر دو دستۀ [«اختیاری» و «کپی‌لفت»] باشد. این کار با ثبت سوابق مجوزهایی که برای نرم‌افزارهای متن باز مورد استفاده شما اعمال می‌شود - از جمله موءلفه‌های فرعی و وابستگی‌ها - آغاز می‌شود.
   <p markdown="1" class="pquote-credit">
 — Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
   </p>
 </aside>
 
-* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
-* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
+* **امتیاز ثبت اختراع:** ممکن است شرکت شما مایل باشد به شبکۀ [Open Invention Network](https://www.openinventionnetwork.com/)، که یک مجموعۀ ثبت اختراع مشترک برای محافظت از اعضا و استفادۀ آن‌ها از از پروژه‌های بزرگ متن باز یا جستجوی سایر [مجوزهای اختراع ثبت جایگزین](https://www.eff.org/document/hacking-patent-system-2016) است، بپیوندد.
+
+* **نظارت:** مخصوصاً زمانی منطقی است که پروژه‌ای را به یک [شخص حقوقی خارج از شرکت](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project) منتقل کنید.
\ No newline at end of file

From 6d1e0aa720aa1b876d0836df366826d3df5401f9 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Fri, 14 May 2021 16:41:14 +0430
Subject: [PATCH 172/749] Language abbreviation updated.

---
 _data/locales/fa.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_data/locales/fa.yml b/_data/locales/fa.yml
index dd41c8e0717..9a17d1650ef 100644
--- a/_data/locales/fa.yml
+++ b/_data/locales/fa.yml
@@ -1,4 +1,4 @@
-en:
+fa:
   locale_name: Farsi
   nav:
     about: درباره

From ec476224d3874771bf1284f8e48f69a5246c4ebd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Wed, 19 May 2021 02:18:00 +0300
Subject: [PATCH 173/749] Fix formating errors created by Gitlocalize (#35)

---
 _articles/tr/code-of-conduct.md    |  38 ++--
 _articles/tr/finding-users.md      |  73 ++++++--
 _articles/tr/how-to-contribute.md  | 274 +++++++++++++++++++----------
 _articles/tr/starting-a-project.md | 134 ++++++++++----
 4 files changed, 360 insertions(+), 159 deletions(-)

diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md
index 9ba8ff26e3b..886e0c91a85 100644
--- a/_articles/tr/code-of-conduct.md
+++ b/_articles/tr/code-of-conduct.md
@@ -30,10 +30,10 @@ Mümkün olduğunca en erken zamanda bir davranış kural listesi oluşturmaya 
 
 Beklentilerinizi iletmenin yanı sıra, bir davranış kural listesi aşağıdakileri de açıklar:
 
-- Davranış kuralları nerede yürürlüğe girer *(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)*?
-- Davranış kuralları kimin için geçerlidir *(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)*?
-- Birisi davranış kurallarını ihlal ederse ne olur?
-- İhlaller nasıl rapor edilebilir?
+* Davranış kuralları nerede yürürlüğe girer _(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)_?
+* Davranış kuralları kimin için geçerlidir _(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)_?
+* Birisi davranış kurallarını ihlal ederse ne olur?
+* İhlaller nasıl rapor edilebilir?
 
 Nerede olursanız olun, geçmiş tecrübelerden faydalanın. [Katkıda Bulunanlar Sözleşmesi (Contributor Covenant)](https://contributor-covenant.org/) Kubernet, Rails ve Swift dahil olmak üzere 40.000'den fazla açık kaynaklı proje tarafından kullanılan ortak bir davranış kural listesidir.
 
@@ -43,15 +43,20 @@ CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTIN
 
 ## Davranış kurallarınızı nasıl uygulayacağınıza karar verme
 
-<aside markdown="1" class="pquote">   Uygulanmayan (veya uygulanamayan) bir davranış kural listesi, hiçbir davranış kuralı olmamasından daha kötüdür: davranış kurallarındaki değerlerin, sizin toplumunuzda gerçekten önemli veya saygı duyulmadığı mesajını gönderir.   <p markdown="1" class="pquote-credit"> - [Ada Girişimi](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  Uygulanmayan (veya uygulanamayan) bir davranış kural listesi, hiçbir davranış kuralı olmamasından daha kötüdür: davranış kurallarındaki değerlerin, sizin toplumunuzda gerçekten önemli veya saygı duyulmadığı mesajını gönderir.
+  <p markdown="1" class="pquote-credit">
+- [Ada Girişimi](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+  </p>
+</aside>
 
 Bir ihlal meydana *gelmeden önce* davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var:
 
-- İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir.
+* İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir.
 
-- Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir.
+* Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir.
 
-- Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz.
+* Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz.
 
 İnsanlara davranış kuralları ihlalini bildirebilmeleri için özel bir yol (e-posta adresi gibi) vermelisiniz ve bu raporun kimlere ulaştığını açıklamalısınız. Bu bir kurucu, bir geliştirme grubu veya bir davranış kuralları çalışma grubu olabilir.
 
@@ -73,7 +78,12 @@ Söz konusu topluluk üyesi, sürekli olarak başkalarını rahatsız hissetmesi
 
 Cevap vermeden önce, neler olduğunu anlamak için biraz zaman harcayın. Kim olduklarını ve neden böyle davrandıklarını daha iyi anlamak için, kişi ya da kişilerin geçmiş yorumlarını ve konuşmalarını okuyun. Bu kişi ve davranışları hakkındaki kendi görüşleriniz dışında başka bakış açıları da toplamaya çalışın.
 
-<aside markdown="1" class="pquote">   Bir tartışmaya girmeyin. Eldeki konuyla ilgilenmeyi bitirmeden önce başkasının davranışlarıyla başa çıkmayın. İhtiyacınız olana odaklanın.   <p markdown="1" class="pquote-credit"> - Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  Bir tartışmaya girmeyin. Eldeki konuyla ilgilenmeyi bitirmeden önce başkasının davranışlarıyla başa çıkmayın. İhtiyacınız olana odaklanın.
+  <p markdown="1" class="pquote-credit">
+- Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+  </p>
+</aside>
 
 ### Uygun işlemi yapın
 
@@ -83,15 +93,15 @@ Birisi bir davranış kuralları ihlali bildirdiğinde, bu durumla yüzleşmesi
 
 Bir davranış kural ihlaline yanıt vermenin birkaç yolu vardır:
 
-- **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun.
+* **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun.
 
-- Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin.
+* Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin.
 
 Bazen bir çözüme ulaşılamaz. Söz konusu kişi karşı karşıya geldiğinde saldırgan veya düşmanca olabilir veya davranışlarını değiştirmez. Bu durumda, daha güçlü bir işlem yapmayı düşünebilirsiniz. Örneğin:
 
-- Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz**
+* Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz**
 
-- Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz**
+* Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz**
 
 Kalıcı olarak yasaklama üyeleri kolayca alınmamalı ve kalıcı uzlaşmaz bir bakış açısı farklılığını temsil etmelidir. Bu önlemleri yalnızca bir çözüme ulaşılamayacağı açıksa almalısınız.
 
@@ -101,7 +111,7 @@ Davranış kuralları, keyfi olarak uygulanan bir yasa değildir. Davranış kur
 
 Proje sahibi olarak, topluluğunuz için kılavuz ilkeler belirler ve bu ilkeleri davranış kurallarınızda belirtilen kurallara uygun olarak uygularsınız. Bu, herhangi bir davranış kuralları ihlali raporunu ciddiye almak anlamına gelir. İhbar eden şikayeti hakkında kapsamlı ve adil bir inceleme yapılmasını hak eder. Bildirdikleri davranışların bir ihlal olmadığını belirlerseniz, bunu açıkça belirtin ve neden bu konuda harekete geçmeyeceğinizi açıklayın. Bununla ne yapacakları onlara bağlı: Sorunlu olduğunu düşündükleri davranışlara hoşgörü gösterirler veya topluluktan ayrılabilirler.
 
-*Teknik* olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir.
+_Teknik_ olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir.
 
 Sonunda, bir proje sahibi olarak, kabul edilebilir davranış için standartları belirler ve uygularsınız. Projenin topluluk değerlerini şekillendirme yetkiniz var ve katılımcılar bu değerleri adil ve eşit bir şekilde uygulamanızı beklerler.
 
diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md
index 914ee05a185..20d8e3c976e 100644
--- a/_articles/tr/finding-users.md
+++ b/_articles/tr/finding-users.md
@@ -27,7 +27,7 @@ Projenizi tanıtmaya yönelik asıl çalışmaya başlamadan önce, ne yaptığ
 
 Projenizi farklı veya ilginç kılan nedir? Neden yarattınız? Bu soruları kendiniz cevaplamak, projenizin önemini bildirmenize yardımcı olacaktır.
 
-İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, *kullanıcıların ve katkıda bulunanların* ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın.
+İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, _kullanıcıların ve katkıda bulunanların_ ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın.
 
 Örneğin, @robb, projesi olan [Cartography'nin](https://github.com/robb/Cartography) neden faydalı olduğunu açıkça belirtmek için kod örnekleri kullanır:
 
@@ -37,7 +37,12 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa
 
 ## İnsanların projenizi bulmasına ve takip etmesine yardımcı olun
 
-<aside markdown="1" class="pquote">   İdeal olarak, insanları projenizle ilgili olarak tanıtabileceğiniz ve işaret edebileceğiniz tek bir "anasayfa" URL'sine ihtiyacınız var. Süslü bir şablona, hatta etkili bir alan adına sahip olmanıza gerek yoktur, ancak projenizin bir odak noktasına ihtiyacı vardır.   <p markdown="1" class="pquote-credit"> - Peter Cooper ve Robert Nyman, ["Kodunuzun Mesajı Nasıl Yayılır"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  İdeal olarak, insanları projenizle ilgili olarak tanıtabileceğiniz ve işaret edebileceğiniz tek bir "anasayfa" URL'sine ihtiyacınız var. Süslü bir şablona, hatta etkili bir alan adına sahip olmanıza gerek yoktur, ancak projenizin bir odak noktasına ihtiyacı vardır.
+  <p markdown="1" class="pquote-credit">
+- Peter Cooper ve Robert Nyman, ["Kodunuzun Mesajı Nasıl Yayılır"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+  </p>
+</aside>
 
 İnsanların projenizi tek bir alana işaret ederek bulup hatırlamalarına yardımcı olun.
 
@@ -45,11 +50,17 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa
 
 Henüz projeniz için iletişim noktaları kurmak istemiyorsanız, yaptığınız her şeyde kendi Twitter veya GitHub hesabınızı tanıtın. Twitter veya GitHub hesabınızı tanıtmak, insanların sizinle nasıl iletişim kurabileceklerini veya işlerinizi takip etmelerini sağlayacaktır. Bir buluşma veya etkinlikte konuşuyorsanız, iletişim bilgilerinizin biyo veya slaytlarınıza eklendiğinden emin olun.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">   Bu ilk günlerde yaptığım bir hata (...) proje için Twitter hesabı oluşturmamaktı. Twitter, insanları bir proje hakkında güncel tutmak ve insanları projeyle sürekli iletişimde bırakmak için harika bir yol.   <p markdown="1" class="pquote-credit"> - @nathanmarz, ["Apache Storm'un ve Öğrenilen Derslerin Tarihi"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
+  Bu ilk günlerde yaptığım bir hata (...) proje için Twitter hesabı oluşturmamaktı. Twitter, insanları bir proje hakkında güncel tutmak ve insanları projeyle sürekli iletişimde bırakmak için harika bir yol.
+  <p markdown="1" class="pquote-credit">
+- @nathanmarz, ["Apache Storm'un ve Öğrenilen Derslerin Tarihi"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+  </p>
+</aside>
 
 **Projeniz için bir web sitesi oluşturmayı düşünün.** Bir web sitesi, projenizi daha net hale getirir ve özellikle açık belgeler ve eğitimlerle desteklendiğinde gezinmeyi kolaylaştırır. Bir web sitesine sahip olmak, projenizin aktif olduğunu ve bu sayede hedef kitlenizin kendisini daha rahat hissetmesini sağlayacaktır. İnsanlara projenizi nasıl kullanacakları hakkında fikir vermek için örnekler verin.
 
-Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin *"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi*.
+Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin _"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi_.
 
 Projeniz GitHub'da barındırıyorsanız, kolayca web sitesi yapmak için [GitHub Pages](https://pages.github.com/) kullanabilirsiniz. [Yeoman](http://yeoman.io/) , [Vagrant](https://www.vagrantup.com/) ve [Middleman](https://middlemanapp.com/) mükemmel, kapsamlı web sitelerine [birkaç örnektir](https://github.com/showcases/github-pages-examples) .
 
@@ -63,13 +74,19 @@ Artık projeniz için bir mesajınız ve insanların projenizi bulmaları için
 
 Hedef kitlenize ulaşmak için mevcut çevrimiçi topluluklardan ve platformlardan yararlanın. Açık kaynaklı projeniz bir yazılım projesiyse, kitlenizi [Stack Overflow](https://stackoverflow.com/) , [Reddit](https://www.reddit.com) , [Hacker News](https://news.ycombinator.com/) veya [Quora](https://www.quora.com/)'da bulabilirsiniz. İnsanların işinizden en çok faydalanabileceğini veya heyecanlanacağını düşündüğünüz kanalları bulun.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">   Her programın, kullanıcıların yalnızca bir kısmının yararlı bulacağı çok özel işlevleri vardır. Mümkün olduğunca çok insana spam yapmayın. Bunun yerine, çabalarınızı projeniz hakkında bilgi sahibi olmaktan yararlanacak topluluklara hedefleyin.   <p markdown="1" class="pquote-credit"> - @pazdera, ["Açık kaynak projeleri için pazarlama"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
+  Her programın, kullanıcıların yalnızca bir kısmının yararlı bulacağı çok özel işlevleri vardır. Mümkün olduğunca çok insana spam yapmayın. Bunun yerine, çabalarınızı projeniz hakkında bilgi sahibi olmaktan yararlanacak topluluklara hedefleyin.
+  <p markdown="1" class="pquote-credit">
+- @pazdera, ["Açık kaynak projeleri için pazarlama"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+  </p>
+</aside>
 
 Projenizi ilgili kanallarda paylaşmanın yollarını bulabilecek misiniz bir bakın:
 
-- **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır.
-- **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun.
-- **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin.
+* **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır.
+* **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun.
+* **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin.
 
 Genel olarak konuşursak, karşılığında bir şey istemeden önce başkalarına yardım etmeye odaklanın. Herkes bir projeyi çevrimiçi olarak kolayca tanıtabildiğinden, çok fazla gürültü çıkacaktır. Kalabalıktan sıyrılmak için, insanlara sadece ne istediğinizi değil, kim olduğunuzu anlatmaya çalışın.
 
@@ -83,19 +100,37 @@ Genel olarak konuşursak, karşılığında bir şey istemeden önce başkaları
 
 [Topluluk karşısında konuşma konusunda](https://speaking.io/) yeniyseniz, projenizin dili veya ekosistemiyle ilgili yerel bir buluşma bularak başlayın.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">   PyCon'a giderken oldukça gergindim. Bir konuşma yapıyordum, sadece birkaç kişiyi tanıyacaktım, bir hafta boyunca gidecektim. (...) Yine de bu kadar endişelenmemeliydim. PyCon olağanüstü bir harikaydı! (...) Herkes inanılmaz derecede cana yakın ve paylaşımcıydı, o kadar ki nadiren ben de konuşmak için fırsat bulabildim!   <p markdown="1" class="pquote-credit"> - @jhamrick, ["Endişelenmeyi Durdurmayı ve PyCon'u Sevmeyi Nasıl Öğreniyorum"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
+  PyCon'a giderken oldukça gergindim. Bir konuşma yapıyordum, sadece birkaç kişiyi tanıyacaktım, bir hafta boyunca gidecektim. (...) Yine de bu kadar endişelenmemeliydim. PyCon olağanüstü bir harikaydı! (...) Herkes inanılmaz derecede cana yakın ve paylaşımcıydı, o kadar ki nadiren ben de konuşmak için fırsat bulabildim!
+  <p markdown="1" class="pquote-credit">
+- @jhamrick, ["Endişelenmeyi Durdurmayı ve PyCon'u Sevmeyi Nasıl Öğreniyorum"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)   
+  </p>
+</aside>
 
 Daha önce topluluk önünde konuşmadıysanız, gergin hissetmek tamamen normaldir! İzleyicilerinizin sizin için orada olduğunu unutmayın, çünkü işinizi gerçekten duymak istiyorlar.
 
 Konuşmanızı yazarken, izleyicilerinizin ilginç bulacağı ve değer kazanacağı şeylere odaklanın. Dilinizi arkadaşça ve ulaşılabilir tutun. Gülümseyin, nefes alın ve eğlenin.
 
-<aside markdown="1" class="pquote">   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">   Konuşmanızı yazmaya başladığınızda, konunuz ne olursa olsun, konuşmanızı insanlara anlattığınız bir hikaye olarak görmeniz yararlı olabilir.   <p markdown="1" class="pquote-credit"> - Lena Reinhard, ["Teknik Konferans Konuşması Nasıl Hazırlanır ve Yazılır"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
+  Konuşmanızı yazmaya başladığınızda, konunuz ne olursa olsun, konuşmanızı insanlara anlattığınız bir hikaye olarak görmeniz yararlı olabilir.
+  <p markdown="1" class="pquote-credit">
+- Lena Reinhard, ["Teknik Konferans Konuşması Nasıl Hazırlanır ve Yazılır"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+  </p>
+</aside>
 
 Hazır olduğunuzda, projenizi tanıtmak için bir konferansta konuşmayı düşünün. Konferanslar, bazen dünyanın her yerinden daha fazla insana ulaşmanıza yardımcı olabilir.
 
 Dilinize veya ekosisteminize özgü konferansları arayın. Konuşmanızı göndermeden önce, konuşmanızı katılımcılar için uyarlamak ve konferansta konuşma kabul etme şansınızı artırmak için konferansı araştırın. Konferansın konuşmacılarına bakarak, izleyicilerinizi daha kolay anlayabilirsiniz.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">   JSConf insanlarına çok hoş bir şekilde yazdım ve bana JSConf AB'de sunabileceğim bir yer vermeleri için yalvardım. (...) Altı aydır üzerinde çalıştığım bu şeyi sunarken son derece korktum. (...) Bütün konuşma sırasında şunu düşündüm. Aman tanrım, burada ne yapıyorum?   <p markdown="1" class="pquote-credit"> - @ry, ["Node.js'nin Hikayesi" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&amp;t=24m57s)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
+  JSConf insanlarına çok hoş bir şekilde yazdım ve bana JSConf AB'de sunabileceğim bir yer vermeleri için yalvardım. (...) Altı aydır üzerinde çalıştığım bu şeyi sunarken son derece korktum. (...) Bütün konuşma sırasında şunu düşündüm. Aman tanrım, burada ne yapıyorum?
+  <p markdown="1" class="pquote-credit">
+- @ry, ["Node.js'nin Hikayesi" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&amp;t=24m57s)
+  </p>
+</aside>
 
 ## Bir itibar oluşturun
 
@@ -103,13 +138,25 @@ Yukarıda belirtilen stratejilere ek olarak, insanları projenizi paylaşmaya ve
 
 Yeni gelenlere yardım etmek, kaynakları paylaşmak ve başkalarının projelerine anlamlı katkılar yapmak olumlu bir itibara kavuşmanıza yardımcı olacaktır. Açık kaynak topluluğunda aktif bir üye olmak, insanların çalışmanız için bağlam oluşturmasına yardımcı olacak ve projenize dikkat etme ve paylaşma olasılıkları artacaktır. Diğer açık kaynaklı projelerle ilişkilerin geliştirilmesi resmi ortaklıklara yol açabilir.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">   Urllib3'ün günümüzdeki en popüler üçüncü parti Python kütüphanesi olmasının tek nedeni isteklerin parçası olmasıdır.   <p markdown="1" class="pquote-credit"> - @shazow, ["Açık kaynak projeniz nasıl gelişir?"](Https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
+  Urllib3'ün günümüzdeki en popüler üçüncü parti Python kütüphanesi olmasının tek nedeni isteklerin parçası olmasıdır.
+  <p markdown="1" class="pquote-credit">
+- @shazow, ["Açık kaynak projeniz nasıl gelişir?"](Https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+  </p>
+</aside>
 
 İtibarınızı oluşturmak için asla çok erken veya geç değildir. Kendi projenizi daha önce başlatmış olsanız bile, başkalarına yardım etmenin yollarını aramaya devam edin.
 
 Kitle oluşturmak için bir gecede çözüm yoktur. Başkalarının güvenini ve saygısını kazanmak zaman alır ve itibarınızı geliştirmek hiç tamamlanmayan bir iştir.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">   PhantomJS ilk kez 2011 yılının başında piyasaya sürüldü. (...) Mesajını her zamanki gibi yaydım: Tweetledim, yapabileceğin şeyler hakkında blog yazıları yazdım, buluşmalarda çeşitli tartışmalar sırasında bahsettim. 2014 yılında daha iyi tanındığında, onunla ilgili sunumlar yapmaya başladım.   <p markdown="1" class="pquote-credit"> - @ariya, ["Geliştirici Hikayeleri"](https://github.com/open-source/stories/ariya)    </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
+  PhantomJS ilk kez 2011 yılının başında piyasaya sürüldü. (...) Mesajını her zamanki gibi yaydım: Tweetledim, yapabileceğin şeyler hakkında blog yazıları yazdım, buluşmalarda çeşitli tartışmalar sırasında bahsettim. 2014 yılında daha iyi tanındığında, onunla ilgili sunumlar yapmaya başladım.
+  <p markdown="1" class="pquote-credit">
+- @ariya, ["Geliştirici Hikayeleri"](https://github.com/open-source/stories/ariya)
+  </p>
+</aside>
 
 ## Devam et!
 
diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md
index 0f79a454a87..487e228f428 100644
--- a/_articles/tr/how-to-contribute.md
+++ b/_articles/tr/how-to-contribute.md
@@ -19,7 +19,13 @@ related:
 
 ## Açık kaynağa neden katkıda bulunmalıyım?
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">   \[Freenode\] üzerinde çalışmak, daha sonra üniversitedeki çalışmalarımda ve gerçek işimde kullandığım becerilerin çoğunu kazanmama yardımcı oldu. Açık kaynak kodlu projeler üzerinde çalışmanın projeye yardım ettiği kadar yapana da yardımcı olacağını düşünüyorum!   <p markdown="1" class="pquote-credit"> - @errietta, ["Açık kaynaklı yazılımlara katkıda bulunmayı neden seviyorum"](https://www.errietta.me/blog/open-source/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar"> 
+  \[Freenode\] üzerinde çalışmak, daha sonra üniversitedeki çalışmalarımda ve gerçek işimde kullandığım becerilerin çoğunu kazanmama yardımcı oldu. Açık kaynak kodlu projeler üzerinde çalışmanın projeye yardım ettiği kadar yapana da yardımcı olacağını düşünüyorum!
+  <p markdown="1" class="pquote-credit">
+- @errietta, ["Açık kaynaklı yazılımlara katkıda bulunmayı neden seviyorum"](https://www.errietta.me/blog/open-source/)
+  </p>
+</aside>
 
 Açık kaynağa katkıda bulunmak, hayal edebileceğiniz herhangi bir konuyu öğrenmek, öğretmek ve deneyim geliştirmek için faydalı bir yol olabilir.
 
@@ -63,59 +69,77 @@ Endişe etmeyin! Açık kaynak kodlu bir projeye dahil olmanın çok farklı yol
 
 Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye *büyük bir* iyilik yapacaksınız!
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">   CocoaPods'taki çalışmamla ünlüydüm, ama çoğu insan CocoaPods aracının kendisinde gerçek bir iş yapmadığımı bilmiyor. Projedeki zamanım çoğunlukla belgeleme ve markalaşma gibi şeyler yapmakla geçiyor.   <p markdown="1" class="pquote-credit"> - @orta, ["Varsayılan olarak OSS’ye taşıma"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
+  CocoaPods'taki çalışmamla ünlüydüm, ama çoğu insan CocoaPods aracının kendisinde gerçek bir iş yapmadığımı bilmiyor. Projedeki zamanım çoğunlukla belgeleme ve markalaşma gibi şeyler yapmakla geçiyor.
+  <p markdown="1" class="pquote-credit">
+- @orta, ["Varsayılan olarak OSS’ye taşıma"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+  </p>
+</aside>
 
 Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve diğer topluluk üyeleriyle tanışmak için harika bir yoldur. Bu ilişkileri kurmak size projenin diğer bölümlerinde de çalışma fırsatı verecektir.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">   İlk önce 17 Haziran 2002 tarihinde düzeltme yamamı e-postayla gönderdiğimde Python geliştirme ekibine (aka python-dev) ulaştım. Hızlı bir şekilde hatayı yakaladım ve grubun e-posta özetlerini iyileştirmeye başladım. Bir konu hakkında net bilgi almak için bana büyük bir bahane verdiler, ama daha kritik olarak, birinin düzeltilmesi gereken bir şeyi işaret ettiğini fark ettim.   <p markdown="1" class="pquote-credit"> - @brettcannon, ["Geliştirme Hikayeleri"](https://github.com/open-source/stories/brettcannon)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
+  İlk önce 17 Haziran 2002 tarihinde düzeltme yamamı e-postayla gönderdiğimde Python geliştirme ekibine (aka python-dev) ulaştım. Hızlı bir şekilde hatayı yakaladım ve grubun e-posta özetlerini iyileştirmeye başladım. Bir konu hakkında net bilgi almak için bana büyük bir bahane verdiler, ama daha kritik olarak, birinin düzeltilmesi gereken bir şeyi işaret ettiğini fark ettim.
+  <p markdown="1" class="pquote-credit">
+- @brettcannon, ["Geliştirme Hikayeleri"](https://github.com/open-source/stories/brettcannon)
+  </p>
+</aside>
 
 ### Etkinlik planlamayı sever misiniz?
 
-- [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin
-- Projenin konferansını düzenleyin (eğer varsa)
-- Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun
+* [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin
+* Projenin konferansını düzenleyin (eğer varsa)
+* Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun
 
 ### Tasarlamayı sever misiniz?
 
-- Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın
-- [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın
-- Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın
-- [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın
+* Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın
+* [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın
+* Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın
+* [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın
 
 ### Yazmayı sever misin?
 
-- Proje dokümantasyonunu yazın ve geliştirin
-- Projenin nasıl kullanıldığını gösteren örnekler oluşturun
-- Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın
-- [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın
-- Projenin dokümantasyonu için çeviri yapın
+* Proje dokümantasyonunu yazın ve geliştirin
+* Projenin nasıl kullanıldığını gösteren örnekler oluşturun
+* Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın
+* [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın
+* Projenin dokümantasyonu için çeviri yapın
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">   Cidden, \[belgeleme\] çok önemlidir. Şu ana kadarki belgeler mükemmeldi ve Babil'in keskin bir özelliği oldu. Bazı özellikleri kesinlikle kullanabilecek bölümler var, hatta burada bir paragrafın eklenmesi bile çok beğeni topluyor.   <p markdown="1" class="pquote-credit"> - @kittens, ["Katkıda bulunanlar için çağrı"](https://github.com/babel/babel/issues/1347)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
+  Cidden, \[belgeleme\] çok önemlidir. Şu ana kadarki belgeler mükemmeldi ve Babil'in keskin bir özelliği oldu. Bazı özellikleri kesinlikle kullanabilecek bölümler var, hatta burada bir paragrafın eklenmesi bile çok beğeni topluyor.
+  <p markdown="1" class="pquote-credit">
+- @kittens, ["Katkıda bulunanlar için çağrı"](https://github.com/babel/babel/issues/1347)
+  </p>
+</aside>
 
 ### Organize etmeyi sever misiniz?
 
-- Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin
-- Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765)
-- Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun.
+* Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin
+* Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765)
+* Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun.
 
 ### Kod yazmayı sever misiniz?
 
-- [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun
-- Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun
-- Proje kurulumunu otomatikleştirin
-- Araçları ve testleri geliştirin
+* [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun
+* Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun
+* Proje kurulumunu otomatikleştirin
+* Araçları ve testleri geliştirin
 
 ### İnsanlara yardım etmeyi sever misiniz?
 
-- Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te
-- İnsanlar için açık konulardaki soruları cevaplayın
-- Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun
+* Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te
+* İnsanlar için açık konulardaki soruları cevaplayın
+* Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun
 
 ### Başkalarına kod yazarken yardım etmeyi sever misiniz?
 
-- Diğer kişilerin gönderimlerindeki kodu inceleyin
-- Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın
-- Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+* Diğer kişilerin gönderimlerindeki kodu inceleyin
+* Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın
+* Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
 
 ### Sadece yazılım projeleri üzerinde çalışmak zorunda değilsiniz!
 
@@ -123,15 +147,21 @@ Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve d
 
 Örneğin:
 
-- @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome)
-- @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor
-- @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts)
+* @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome)
+* @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor
+* @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts)
 
 Bir yazılım geliştiricisi olsanız bile, bir dokümantasyon projesi üzerinde çalışmak açık kaynak kodla başlamanıza yardımcı olabilir. Kod içermeyen projeler üzerinde çalışmak genellikle daha az korkutucu olur ve işbirliği süreci sizin güven ve deneyiminizi artırır.
 
 ## Kendinizi yeni bir projeye yönlendirmek
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">   Bir sorun listesine giderseniz ve işler kafa karıştırıcı görünür, yalnız değilsiniz. Bu araçlar çok fazla bilgi gerektirir, ancak insanlar size yardımcı olabilir ve onlara sorular sorabilirsiniz.   <p markdown="1" class="pquote-credit"> - @shaunagm, ["Açık Kaynağa Nasıl Katkıda Bulunulur"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
+  Bir sorun listesine giderseniz ve işler kafa karıştırıcı görünür, yalnız değilsiniz. Bu araçlar çok fazla bilgi gerektirir, ancak insanlar size yardımcı olabilir ve onlara sorular sorabilirsiniz.
+  <p markdown="1" class="pquote-credit">
+- @shaunagm, ["Açık Kaynağa Nasıl Katkıda Bulunulur"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/) 
+  </p>
+</aside>
 
 Bir yazım hatasının düzeltilmesinden daha fazla olarak, açık kaynağa katkıda bulunmak, partideki bir grup yabancıyla konuşmaya çalışmak gibidir. Lamalar hakkında konuşmaya başlarsanız, akvaryum balığı ile ilgili derin bir tartışma yapıyorlarsa, muhtemelen size biraz garip bakarlar.
 
@@ -147,34 +177,34 @@ Bununla birlikte, birçok açık kaynak projenin benzer organizasyon yapıların
 
 Tipik bir açık kaynak projesi aşağıdaki insan türlerine sahiptir:
 
-- **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar)
-- **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir)
-- **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler)
-- **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes
-- **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler.
+* **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar)
+* **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir)
+* **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler)
+* **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes
+* **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler.
 
 Daha büyük projeler ayrıca araç yönetimi, öncelik yönetimi, topluluk yönetimi ve etkinlik organizasyonu gibi farklı görevlere odaklanmış alt komitelere veya çalışma gruplarına sahip olabilir. Bu bilgileri bulmak için bir projenin "ekip" sayfasına veya yönetim dokümantasyon deposuna bakın.
 
 Projelerin belgeleri de vardır. Bu dosyalar genellikle bir kütüphanenin dizin yapısının en üst seviyelerinde listelenir.
 
-- **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir.
-- **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar.
-- **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder.
-- **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir.
-- **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir.
+* **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir.
+* **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar.
+* **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder.
+* **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir.
+* **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir.
 
 Son olarak, açık kaynak projeler tartışmaları yönetmek için aşağıdaki araçları kullanır. Arşivleri okumak, topluluğun nasıl düşündüğü ve çalıştığı hakkında size iyi bir fikir verecektir.
 
-- **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler.
-- **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler.
-- **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır.
-- **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır.
+* **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler.
+* **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler.
+* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır.
+* **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır.
 
 ## Katkıda bulunacak bir proje bulma
 
 Açık kaynak projelerin nasıl çalıştığını çözdüğünüze göre, katkıda bulunacak bir proje bulma zamanı!
 
-Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, *"Ülkenizin sizin için neler yapabileceğini değil - ülkeniz için neler yapabileceğinizi sorun"* diyen ABD Başkanı John F. Kennedy'yi  örnek alın.
+Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, *"Ülkenizin sizin için neler yapabileceğini değil * ülkeniz için neler yapabileceğinizi sorun"* diyen ABD Başkanı John F. Kennedy'yi  örnek alın.
 
 Açık kaynağa katkıda bulunmak, farklı projelerde her seviyede gerçekleşir. İlk katkınızın tam olarak ne olacağını veya nasıl görüneceğini düşünmeniz gerekmez.
 
@@ -192,15 +222,15 @@ Düzeltebileceğiniz açık sorunları arıyorsanız, her açık kaynak projenin
 
 Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aşağıdaki kaynaklardan birini de kullanabilirsiniz:
 
-- [GitHub Explore](https://github.com/explore/)
-- [Open Source Friday](https://opensourcefriday.com)
-- [First Timers Only](https://www.firsttimersonly.com/)
-- [CodeTriage](https://www.codetriage.com/)
-- [24 Pull Requests](https://24pullrequests.com/)
-- [Up For Grabs](https://up-for-grabs.net/)
-- [Contributor-ninja](https://contributor.ninja)
-- [First Contributions](https://firstcontributions.github.io)
-- [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
 ### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi
 
@@ -212,7 +242,9 @@ Katkıda bulunmak istediğiniz bir proje bulduğunuzda, projenin katkıları kab
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox1" class="overflow-hidden d-block text-normal">   Lisans var mı? Genellikle, proje kök dizininde LICENCE adlı bir dosya vardır.   </label>
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Lisans var mı? Genellikle, proje kök dizininde LICENCE adlı bir dosya vardır.
+  </label>
 </div>
 
 **Proje aktif olarak katkı kabul ediyor**
@@ -221,71 +253,97 @@ Ana daldaki geliştirici faaliyetine bakın. GitHub'da, bu bilgiyi bir kütüpha
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox2" class="overflow-hidden d-block text-normal">   En son kod değişikliği ne zaman yapılmış?   </label>
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    En son kod değişikliği ne zaman yapılmış?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox3" class="overflow-hidden d-block text-normal">   Projenin kaç katılımcısı var? </label>
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    Projenin kaç katılımcısı var?
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox4" class="overflow-hidden d-block text-normal">   İnsanlar ne sıklıkta geliştirme yapıyor? (GitHub'da, bunu üstteki çubukta "Commits" i tıklayarak bulabilirsiniz.)   </label>
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    İnsanlar ne sıklıkta geliştirme yapıyor? (GitHub'da, bunu üstteki çubukta "Commits" i tıklayarak bulabilirsiniz.)
+  </label>
 </div>
 
 Ardından, projenin sorun listesine bakın.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox5" class="overflow-hidden d-block text-normal">   Kaç tane açık sorun var?   </label>
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Kaç tane açık sorun var?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox6" class="overflow-hidden d-block text-normal">   Geliştiriciler sorunlara hızlı bir şekilde yanıt veriyor mu?   </label>
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Geliştiriciler sorunlara hızlı bir şekilde yanıt veriyor mu?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox7" class="overflow-hidden d-block text-normal">   Sorunların altında aktif tartışma var mı?   </label>
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Sorunların altında aktif tartışma var mı?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox8" class="overflow-hidden d-block text-normal">   Sorunlar yeni mi?   </label>
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Sorunlar yeni mi?
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox9" class="overflow-hidden d-block text-normal">   Sorunlar kapanıyor mu? (GitHub'da kapalı sorunları görmek için Konular sayfasındaki "kapalı" sekmesine tıklayın.)   </label>
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Sorunlar kapanıyor mu? (GitHub'da kapalı sorunları görmek için Konular sayfasındaki "kapalı" sekmesine tıklayın.)
+  </label>
 </div>
 
 Şimdi aynısını projenin PR listesi için yapın.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox10" class="overflow-hidden d-block text-normal">   Kaç tane açık PR var?   </label>
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    Kaç tane açık PR var?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox20" class="overflow-hidden d-block text-normal">   Sağlayıcılar PR'ları hızlı bir şekilde yanıtlıyor mu?   </label>
+  <label for="cbox20" class="overflow-hidden d-block text-normal">
+    Sağlayıcılar PR'ları hızlı bir şekilde yanıtlıyor mu?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox11" class="overflow-hidden d-block text-normal">     PR'lar üzerinde aktif tartışma var mı?   </label>
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    PR'lar üzerinde aktif tartışma var mı?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox12" class="overflow-hidden d-block text-normal">     PR yeni mi gelmiş?   </label>
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    PR yeni mi gelmiş?
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox13" class="overflow-hidden d-block text-normal">     Yakındazamanda ne kadar PR birleştirilmiş? (GitHub'da kapalı PR'leri görmek için PR sayfasındaki "kapalı" sekmesine tıklayın.)   </label>
+  <label for="cbox13" class="overflow-hidden d-block text-normal">
+    Yakındazamanda ne kadar PR birleştirilmiş? (GitHub'da kapalı PR'leri görmek için PR sayfasındaki "kapalı" sekmesine tıklayın.)
+  </label>
 </div>
 
 **Proje katkı bekliyor mu?**
@@ -294,25 +352,39 @@ Arkadaş canlısı ve misafirperver bir proje, yeni katılımcılara açık olac
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox14" class="overflow-hidden d-block text-normal">     Geliştiriciler, sorunlardaki sorulara yardımcı oluyor mu?   </label>
+  <label for="cbox14" class="overflow-hidden d-block text-normal">
+    Geliştiriciler, sorunlardaki sorulara yardımcı oluyor mu?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox15" class="overflow-hidden d-block text-normal">     İnsanlar konularda, tartışma forumunda ve sohbette (örneğin, IRC veya Slack) arkadaş canlısı mı?   </label>
+  <label for="cbox15" class="overflow-hidden d-block text-normal">
+    İnsanlar konularda, tartışma forumunda ve sohbette (örneğin, IRC veya Slack) arkadaş canlısı mı?
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox16" class="overflow-hidden d-block text-normal">     PR'lar inceleniyor mu?   </label>
+  <label for="cbox16" class="overflow-hidden d-block text-normal">
+    PR'lar inceleniyor mu?
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox17" class="overflow-hidden d-block text-normal">     Geliştiriciler insanlara katkılarından dolayı teşekkür eder mi?   </label>
+  <label for="cbox17" class="overflow-hidden d-block text-normal">
+    Geliştiriciler insanlara katkılarından dolayı teşekkür eder mi?
+  </label>
 </div>
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">   Ne zaman uzun bir tartışma görüyorsanız, çekirdek geliştiricilerin konu başından geç gelen cevaplarını anında kontrol edin. Yapıcı bir şekilde özetliyorlar mı ve kibarlıklarını korurken bir karar vermek için adımlar atıyorlar mı? Çok fazla söz savaşı yaşandığını görüyorsanız, bu genellikle enerjinin gelişme yerine tartışmaya girdiğinin işaretidir.   <p markdown="1" class="pquote-credit"> - @kfogel, [_OPS_ üretiliyor](https://producingoss.com/en/evaluating-oss-projects.html)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Ne zaman uzun bir tartışma görüyorsanız, çekirdek geliştiricilerin konu başından geç gelen cevaplarını anında kontrol edin. Yapıcı bir şekilde özetliyorlar mı ve kibarlıklarını korurken bir karar vermek için adımlar atıyorlar mı? Çok fazla söz savaşı yaşandığını görüyorsanız, bu genellikle enerjinin gelişme yerine tartışmaya girdiğinin işaretidir.
+  <p markdown="1" class="pquote-credit">
+- @kfogel, [_OPS_ üretiliyor](https://producingoss.com/en/evaluating-oss-projects.html)
+  </p>
+</aside>
 
 ## Nasıl katkı yapılır?
 
@@ -322,7 +394,13 @@ Hoşunuza giden bir proje buldunuz ve katkıda bulunmaya hazırsınız. En sonun
 
 İster bir kerelik bir katkı yapan, ister bir topluluğa katılmaya çalışan biri olun, başkalarıyla çalışmak açık kaynak dünyasında geliştireceğiniz en önemli becerilerden biridir.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">   \[Yeni bir katılımcı olarak \] ben bir sorunu çözmek istediğimde hemen soru sormam gerektiğini fark ettim. Kod tabanında dolaştım. Bir konunun ne olduğunu anladığıma dair bir şeyler hissettiğimde, daha fazla yardım istemiştim. Ve voilà! İhtiyacım olan tüm detayları aldıktan sonra sorunu çözebildim.   <p markdown="1" class="pquote-credit"> - @shubheksha, [Yeni Başlayanlar İçin Açık Kaynak Dünyasında İnişli Çıkışlı Yolculuk](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
+  \[Yeni bir katılımcı olarak \] ben bir sorunu çözmek istediğimde hemen soru sormam gerektiğini fark ettim. Kod tabanında dolaştım. Bir konunun ne olduğunu anladığıma dair bir şeyler hissettiğimde, daha fazla yardım istemiştim. Ve voilà! İhtiyacım olan tüm detayları aldıktan sonra sorunu çözebildim.
+  <p markdown="1" class="pquote-credit">
+- @shubheksha, [Yeni Başlayanlar İçin Açık Kaynak Dünyasında İnişli Çıkışlı Yolculuk](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+  </p>
+</aside>
 
 Bir sorunu açmadan veya bir PR oluşturmadan ya da sohbette bir soru sormadan önce, fikirlerinizi etkili bir şekilde ortaya çıkarmak için bu noktaları aklınızda bulundurun.
 
@@ -370,47 +448,53 @@ Herhangi bir şey yapmadan önce, fikrinizin başka bir yerde tartışılmadığ
 
 Fikrinizi başka bir yerde bulamazsanız, harekete geçmeye hazırsınız. Proje GitHub'taysa, muhtemelen bir sorun açarak veya PR oluşturarak iletişim kurarsınız:
 
-- **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir
-- **PR** bir çözüm üzerinde çalışmaya başlamak içindir
-- **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin.
+* **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir
+* **PR** bir çözüm üzerinde çalışmaya başlamak içindir
+* **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin.
 
 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.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">   Aktif olarak kullandığınız bir projeyi seçmek, GitHub'da “izlemek” ve her konuyu ve PR'ı okumaktan <em>çok şey</em> öğreneceksiniz.   <p markdown="1" class="pquote-credit"> - @gaearon [birleştirme projelerinde](https://twitter.com/dan_abramov/status/819555257055322112)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
+  Aktif olarak kullandığınız bir projeyi seçmek, GitHub'da “izlemek” ve her konuyu ve PR'ı okumaktan <em>çok şey</em> öğreneceksiniz.
+  <p markdown="1" class="pquote-credit">
+- @gaearon [birleştirme projelerinde](https://twitter.com/dan_abramov/status/819555257055322112)
+  </p>
+</aside>
 
 ### Bir istek/sorun açmak
 
 Genellikle aşağıdaki durumlarda bir sorun açmalısınız:
 
-- Çözemediğiniz bir hatayı bildirmek için
-- Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar)
-- Yeni bir özellik veya başka bir proje fikri önermek için
+* Çözemediğiniz bir hatayı bildirmek için
+* Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar)
+* Yeni bir özellik veya başka bir proje fikri önermek için
 
 Sorunlar üzerinde iletişim kurmak için ipuçları:
 
-- **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır.
-- **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın.
-- **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır.
+* **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır.
+* **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın.
+* **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır.
 
 ### PR açma
 
 Genellikle aşağıdaki durumlarda bir PR açmalısınız:
 
-- Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata)
-- Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda
+* Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata)
+* Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda
 
 Bir PR, bitmiş işi temsil etmek zorunda değildir. PR'ı erkenden açmak genellikle daha iyidir, bu nedenle diğerleri ilerlemeniz hakkında fikir sahibi olabilir veya geribildirimde bulunabilir. Sadece konu satırında bir "WIP" (Çalışmakta Olan Çalışma) etiketi ile işaretlemeniz yeterlidir. Daha sonra her zaman daha fazla geliştirme ekleyebilirsiniz.
 
 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.)
-- 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.
-- **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun.
-- **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır.
+* **[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.)
+* 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.
+* **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun.
+* **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır.
 
 Bu ilk PR ise, @kentcdodds'ın bir örnek video eğitimi olarak oluşturduğu [Bir PR Yap](http://makeapullrequest.com/)'ı izleyin. Ayrıca, @Roshanjossey tarafından oluşturulan [First Contributions](https://github.com/Roshanjossey/first-contributions) deposunda çekme isteği yapmayı da deneyebilirsiniz.
 
diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index 7c8076466bc..e577a4289a3 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -30,15 +30,21 @@ Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek
 
 ### İnsanlar neden işlerini açık kaynak olarak sunarlar?
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">   Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.   <p markdown="1" class="pquote-credit"> — @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+  Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.
+  <p markdown="1" class="pquote-credit">
+— @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+  </p>
+</aside>
 
 Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler:
 
-- **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur.
+* **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur.
 
-- **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
+* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
 
-- **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
+* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
 
 Açık kaynak sadece yazılım için değil. Veri kümelerinden kitaplara kadar her şeyi açık kaynak koduyla açabilirsiniz. Açık kaynak başka neler yapabileceğiniz hakkında fikir edinmek için [GitHub Explore](https://github.com/explore)'a göz atın.
 
@@ -68,7 +74,13 @@ Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahi
 
 Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">   Bir noktada kullandığım özel bir UIAlertView işlevi oluşturdum ... ve onu açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca, diğer geliştiricilere projelerinde nasıl kullanılacağını açıklayan ilk belgelerimi de yazdım. Muhtemelen hiç kimse bunu kullanmamıştı çünkü bu basit bir projeydi ama katkım hakkında kendimi iyi hissediyordum.   <p markdown="1" class="pquote-credit"> — @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)   </p></aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+  Bir noktada kullandığım özel bir UIAlertView işlevi oluşturdum ... ve onu açık kaynak yapmaya karar verdim. Bu yüzden daha dinamik olacak şekilde değiştirdim ve GitHub'a yükledim. Ayrıca, diğer geliştiricilere projelerinde nasıl kullanılacağını açıklayan ilk belgelerimi de yazdım. Muhtemelen hiç kimse bunu kullanmamıştı çünkü bu basit bir projeydi ama katkım hakkında kendimi iyi hissediyordum.
+  <p markdown="1" class="pquote-credit">
+— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+  </p>
+</aside>
 
 Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir.
 
@@ -78,7 +90,13 @@ Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve
 
 Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">   Projeyi açık kaynak yapmaya başladığınızda, yönetim süreçlerinizin projenizin çevresindeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. Şirketinizde çalışmayan katılımcıları projenin kilit yönlerine dahil etmekten korkmayın - özellikle de sık sık katkıda bulunanlarsa.   <p markdown="1" class="pquote-credit"> — @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)   </p></aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+  Projeyi açık kaynak yapmaya başladığınızda, yönetim süreçlerinizin projenizin çevresindeki topluluğun katkılarını ve yeteneklerini göz önünde bulundurmasını sağlamak önemlidir. Şirketinizde çalışmayan katılımcıları projenin kilit yönlerine dahil etmekten korkmayın * özellikle de sık sık katkıda bulunanlarsa.
+  <p markdown="1" class="pquote-credit">
+— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+  </p>
+</aside>
 
 ### Diğer projelere katkıda bulunmak
 
@@ -94,10 +112,10 @@ 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/)
-- [Davranış kuralları](../code-of-conduct/)
+* [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/)
+* [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.
 
@@ -123,14 +141,20 @@ README'ler, projenizi nasıl kullanılacağını açıklamadan fazlasını yapar
 
 README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar.
 
-- Bu proje ne yapıyor?
-- Bu proje neden faydalıdır?
-- Kullanmaya nasıl başlarım?
-- İhtiyacım olursa nereden daha fazla yardım alabilirim?
+* Bu proje ne yapıyor?
+* Bu proje neden faydalıdır?
+* Kullanmaya nasıl başlarım?
+* İhtiyacım olursa nereden daha fazla yardım alabilirim?
 
 README'nizi, katkıları nasıl ele aldığınız, projenin hedeflerinin ne olduğu ve lisanslar ve atıfla ilgili bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkıları kabul etmek istemiyorsanız veya projeniz henüz üretime hazır değilse, bu bilgileri not edin.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">   Daha iyi dokümantasyon, daha fazla kullanıcı, daha az destek talebi ve daha fazla katılımcı anlamına gelir. (...) Okuyucularınızın siz olmadığını unutmayın. Tamamen farklı deneyimleri olan ve projeye gelebilecek insanlar var.   <p markdown="1" class="pquote-credit"> — @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&amp;list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&amp;index=10)   </p></aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+  Daha iyi dokümantasyon, daha fazla kullanıcı, daha az destek talebi ve daha fazla katılımcı anlamına gelir. (...) Okuyucularınızın siz olmadığını unutmayın. Tamamen farklı deneyimleri olan ve projeye gelebilecek insanlar var.
+  <p markdown="1" class="pquote-credit">
+— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&amp;list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&amp;index=10)
+  </p>
+</aside>
 
 README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin.
 
@@ -142,15 +166,15 @@ Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make
 
 Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler.
 
-- Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin)
-- Yeni bir özellik nasıl önerilir
-- Proje ortamı nasıl kurulur ve testler nasıl yapılır
+* Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin)
+* Yeni bir özellik nasıl önerilir
+* Proje ortamı nasıl kurulur ve testler nasıl yapılır
 
 Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır:
 
-- Aradığınız katkı türleri
-- Proje için yol haritanız veya vizyonunuz
-- Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli)
+* Aradığınız katkı türleri
+* Proje için yol haritanız veya vizyonunuz
+* Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli)
 
 Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır:
 
@@ -170,7 +194,13 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan
 
 ### Davranış kural listesi oluşturmak
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">   Hepimiz, muhtemelen bir şeyin neden belirli bir şekilde olması gerektiğini açıklamaya çalışan bir proje sahibi olarak ya da bir kullanıcı olarak basit bir soru gibi sorulan istismarla karşılaştığımız deneyimler yaşadık. (...) Davranış kuralları, ekibinizin yapıcı söylemi çok ciddiye aldığını gösteren, kolayca atıfta bulunulabilir ve bağlanabilir bir belge haline gelir.  <p markdown="1" class="pquote-credit"> — @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)   </p></aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+  Hepimiz, muhtemelen bir şeyin neden belirli bir şekilde olması gerektiğini açıklamaya çalışan bir proje sahibi olarak ya da bir kullanıcı olarak basit bir soru gibi sorulan istismarla karşılaştığımız deneyimler yaşadık. (...) Davranış kuralları, ekibinizin yapıcı söylemi çok ciddiye aldığını gösteren, kolayca atıfta bulunulabilir ve bağlanabilir bir belge haline gelir.
+  <p markdown="1" class="pquote-credit">
+— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+  </p>
+</aside>
 
 Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır.
 
@@ -190,8 +220,8 @@ Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosy
 
 Marka, gösterişli bir logo veya çekici bir proje adından daha fazlasıdır. Projeniz hakkında nasıl konuştuğunuzla ve mesajınızla kime ulaştığınızla ilgilidir.
 
-- [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler
-- [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur
+* [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler
+* [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur
 
 Mevcut bir projenin üzerine inşa ediyorsanız, adlarını ön ek olarak kullanmak projenizin ne yaptığını netleştirmeye yardımcı olabilir (örneğin, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` komutunu getirir).
 
@@ -215,7 +245,13 @@ Projenizin ömrü boyunca birçok yazı yazacaksınız; README'ler, öğretici b
 
 Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri.
 
-<aside markdown="1" class="pquote">   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">   Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.   <p markdown="1" class="pquote-credit"> — [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)   </p> </aside>
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  Posta listesindeki her konuya katılmaya ve örnek davranış göstermeye, insanlara iyi davranmaya, sorunlarını ciddiye almaya ve genel olarak yardımcı olmaya çalıştım. Bir süre sonra, insanlar sadece soru sormakla kalmayıp aynı zamanda yanıtlamada da yardımcı olmak için tarzımı taklit ettiler.
+  <p markdown="1" class="pquote-credit">
+— [CouchDB](https://github.com/apache/couchdb)'deki @janl, ["Sürdürülebilir Açık Kaynak"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
 
 Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün.
 
@@ -231,39 +267,53 @@ Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol l
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox1" class="overflow-hidden d-block text-normal">     Projenin açık kaynak lisanslı LICENSE dosyası var   </label>
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Projenin açık kaynak lisanslı LICENSE dosyası var
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox2" class="overflow-hidden d-block text-normal">     Proje temel dokümantasyona sahiptir (README, CONTRIBUTING, CODE_OF_CONDUCT)   </label>
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    Proje temel dokümantasyona sahiptir (README, CONTRIBUTING, CODE_OF_CONDUCT)
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox3" class="overflow-hidden d-block text-normal">     Adı hatırlamak kolaydır, projenin ne yaptığı hakkında bir fikir verir ve mevcut bir projeyle çelişmez veya ticari markaları ihlal etmez   </label>
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    Adı hatırlamak kolaydır, projenin ne yaptığı hakkında bir fikir verir ve mevcut bir projeyle çelişmez veya ticari markaları ihlal etmez
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox4" class="overflow-hidden d-block text-normal">     Sorun listesi, açıkça düzenlenmiş ve etiketlenmiş konularla birlikte güncel   </label>
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    Sorun listesi, açıkça düzenlenmiş ve etiketlenmiş konularla birlikte güncel
+  </label>
 </div>
 
 **Kod**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox5" class="overflow-hidden d-block text-normal">     Proje tutarlı kod kuralları ve temiz işlev/yöntem/değişken adlarını kullanıyor   </label>
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Proje tutarlı kod kuralları ve temiz işlev/yöntem/değişken adlarını kullanıyor
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox6" class="overflow-hidden d-block text-normal">     Kod açıkça yorumlanmış, amaçları ve aykırı vakaları belgelemektedir.   </label>
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Kod açıkça yorumlanmış, amaçları ve aykırı vakaları belgelemektedir.
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox7" class="overflow-hidden d-block text-normal">     Revizyon geçmişinde, sorunlarda veya PR isteklerinde (örneğin şifreler veya kamuya açık olmayan diğer bilgiler) hassas bilgi yok   </label>
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Revizyon geçmişinde, sorunlarda veya PR isteklerinde (örneğin şifreler veya kamuya açık olmayan diğer bilgiler) hassas bilgi yok
+  </label>
 </div>
 
 **İnsanlar**
@@ -272,29 +322,39 @@ Bireyseniz:
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox8" class="overflow-hidden d-block text-normal">     Hukuk departmanıyla konuştunuz ve/veya şirketinizin IP ve açık kaynaklı politikalarını anladınız (eğer bir yerde çalışansanız).   </label>
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Hukuk departmanıyla konuştunuz ve/veya şirketinizin IP ve açık kaynaklı politikalarını anladınız (eğer bir yerde çalışansanız).
+  </label>
 </div>
 
 Bir şirket veya kuruluşsanız:
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox9" class="overflow-hidden d-block text-normal">     Hukuk departmanınızla konuştunuz   </label>
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Hukuk departmanınızla konuştunuz
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox10" class="overflow-hidden d-block text-normal">     Projeyi duyurmak ve tanıtmak için bir pazarlama planınız var   </label>
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    Projeyi duyurmak ve tanıtmak için bir pazarlama planınız var
+  </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox11" class="overflow-hidden d-block text-normal">     Birisi topluluk etkileşimlerini yönetmeyi taahhüt eder (sorunlara cevap verme, çekme isteklerini gözden geçirme ve birleştirme)   </label>
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Birisi topluluk etkileşimlerini yönetmeyi taahhüt eder (sorunlara cevap verme, çekme isteklerini gözden geçirme ve birleştirme)
+  </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox12" class="overflow-hidden d-block text-normal">     En az iki kişinin projeye yönetici erişimi var   </label>
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    En az iki kişinin projeye yönetici erişimi var
+  </label>
 </div>
 
 ## Başardınız!

From 95b66da2f678846e87bde4772b0254c555bc8190 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Wed, 19 May 2021 02:26:17 +0300
Subject: [PATCH 174/749] Fetch From Upstream (#36)

* Bump actions/setup-ruby from 1 to 1.1.3

Bumps [actions/setup-ruby](https://github.com/actions/setup-ruby) from 1 to 1.1.3.
- [Release notes](https://github.com/actions/setup-ruby/releases)
- [Commits](https://github.com/actions/setup-ruby/compare/v1...v1.1.3)

Signed-off-by: dependabot[bot] <support@github.com>

* Fix formating errors created by Gitlocalize (#35)

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Blake Williams <blakewilliams@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 27f8a14d6a8..0eb22ebf388 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
       uses: actions/checkout@v2.3.4
 
     - name: Set up Ruby
-      uses: actions/setup-ruby@v1
+      uses: actions/setup-ruby@v1.1.3
 
     - name: Set up Node
       uses: actions/setup-node@v2.1.5

From 5fd0351050ac5b3dbe070f5c4e56033b8791db54 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 19 May 2021 07:26:51 +0000
Subject: [PATCH 175/749] Bump nokogiri from 1.11.3 to 1.11.4

Bumps [nokogiri](https://github.com/sparklemotion/nokogiri) from 1.11.3 to 1.11.4.
- [Release notes](https://github.com/sparklemotion/nokogiri/releases)
- [Changelog](https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md)
- [Commits](https://github.com/sparklemotion/nokogiri/compare/v1.11.3...v1.11.4)

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 33561394aab..3029fa9f9cc 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -220,7 +220,7 @@ GEM
       jekyll-seo-tag (~> 2.1)
     minitest (5.14.4)
     multipart-post (2.1.1)
-    nokogiri (1.11.3)
+    nokogiri (1.11.4)
       mini_portile2 (~> 2.5.0)
       racc (~> 1.4)
     nokogumbo (2.0.5)

From 10a1bdbd7166982df5e2ced14ebddf2b1c4d7d60 Mon Sep 17 00:00:00 2001
From: Bart <bartdong@qq.com>
Date: Thu, 20 May 2021 12:05:44 +0800
Subject: [PATCH 176/749] Modify 2 incorrect words
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Modify 2 incorrect words' translation, function and variable always stand for 函数 and 变量
---
 _articles/zh-hans/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md
index 897a26d9232..3a8113891a5 100644
--- a/_articles/zh-hans/starting-a-project.md
+++ b/_articles/zh-hans/starting-a-project.md
@@ -300,7 +300,7 @@ redirect_from: /zh-cn/starting-a-project/
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    项目使用一致的代码风格和明确的功能/方法/可用的名字
+    项目使用一致的代码风格和明确的函数/方法/变量的名字
   </label>
 </div>
 

From a2c53e912d2aa0cfeef243ada78b7d9a7f5e0b3a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E7=AB=AB=E6=B3=93?= <jinghong@hong.local>
Date: Thu, 27 May 2021 11:46:49 +0800
Subject: [PATCH 177/749] Fix typo in article "how to contribute"

---
 _articles/zh-hant/how-to-contribute.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md
index c6eb5d96d90..c29fd8b182e 100644
--- a/_articles/zh-hant/how-to-contribute.md
+++ b/_articles/zh-hant/how-to-contribute.md
@@ -57,7 +57,7 @@ redirect_from: /zh-tw/how-to-contribute/
 
 ### **你不一定要會寫程式才能貢獻**
 
-對開源做出貢獻常見的誤解之一就是：要寫程式纔算貢獻。其實專案裡不需編碼的工作也是[經常被忽視](https://github.com/blog/2195-the-shape-of-open-source)的部分。你對專案所做的非程式類貢獻，其實是對專案來說莫大的幫助！
+對開源做出貢獻常見的誤解之一就是：要寫程式才算貢獻。其實專案裡不需編碼的工作也是[經常被忽視](https://github.com/blog/2195-the-shape-of-open-source)的部分。你對專案所做的非程式類貢獻，其實是對專案來說莫大的幫助！
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars1.githubusercontent.com/u/49038?v=3&s=460" class="pquote-avatar" alt="avatar">
@@ -141,7 +141,7 @@ redirect_from: /zh-tw/how-to-contribute/
 * @h5bp 維護了針對前端開發者的[面試題](https://github.com/h5bp/Front-end-Developer-Interview-Questions)
 * @stuartlynn 和 @nicole-a-tesla 蒐集了[關於海鸚的小知識](https://github.com/stuartlynn/puffin_facts)
 
-即使你是一個軟體開法者，撰寫說明文件也能幫助剛加入開源的你去更加的認識它。這通常也能讓你以一個不用接觸程式碼的方式自在的參與專案，當中協作的過程亦能建立你的信心與經驗。
+即使你是一個軟體開發者，撰寫說明文件也能幫助剛加入開源的你去更加的認識它。這通常也能讓你以一個不用接觸程式碼的方式自在的參與專案，當中協作的過程亦能建立你的信心與經驗。
 
 ## **根據專案定位自我**
 
@@ -179,7 +179,7 @@ redirect_from: /zh-tw/how-to-contribute/
 
 * **許可協議（LICENSE）:** 根據定義，每個開源專案都必須有個[開源許可協議](https://choosealicense.com)。如果專案沒有的話，那它不能算是個開源社群。
 * **README:**  README 是一個引導手冊，對剛加入社群的人們表示歡迎，它通常會解釋專案有何用處，為何發起，以及如何快速入門等。
-* **貢獻（CONTRIBUTING）:**  READMES 幫助人認識與使用專案，「貢獻」這個文件則是針對想對專案貢獻的人寫的指南。它會說明目前專案需要怎樣類型的貢獻者，並介紹貢獻時的流程是如何進行。並非所有的專案都會有這個文件，但如果有的話某種程度上也是向有意貢獻的人表達友善的意思。
+* **貢獻（CONTRIBUTING）:**  README 幫助人認識與使用專案，「貢獻」這個文件則是針對想對專案貢獻的人寫的指南。它會說明目前專案需要怎樣類型的貢獻者，並介紹貢獻時的流程是如何進行。並非所有的專案都會有這個文件，但如果有的話某種程度上也是向有意貢獻的人表達友善的意思。
 * **行爲準則（CODE_OF_CONDUCT）:** 這份文件裡頭設立了基本規範來約束參與者的行為以及提醒應有的禮儀，並非所有的專案都會有這個文件，但如果有的話某種程度上也是向有意貢獻的人表達友善的意思。
 * **其它文件:** 有些專案也許還有其它文件，例如教學、專案導覽，或者是管理政策，這在大型專案中常見。
 
@@ -196,7 +196,7 @@ redirect_from: /zh-tw/how-to-contribute/
 
 如果你從來都沒有爲開源做過貢獻的話，那麼請謹記來自美國總統約翰 F.肯尼迪的這段話：「**不問國家能爲你做什麼，要問你能爲國家做什麼。**」
 
-開源專案的每個面向與跨專案間都需要貢獻者，先不用太專牛角尖的去想你一定要先在那做貢獻，或是做得好不好。
+開源專案的每個面向與跨專案間都需要貢獻者，先不用太鑽牛角尖的去想你一定要先在那做貢獻，或是做得好不好。
 
 不如從你使用過的或將來會使用到的專案開始貢獻，你特別關注的專案才會是你會自願積極參與的專案。
 

From 138ecdc3637f687c3dcf0657f6832fae47932dbf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E7=AB=AB=E6=B3=93?= <jinghong@hong.local>
Date: Thu, 27 May 2021 11:52:40 +0800
Subject: [PATCH 178/749] Make the sentence fluent in Chinese

---
 _articles/zh-hant/how-to-contribute.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md
index c29fd8b182e..490ae36cbe8 100644
--- a/_articles/zh-hant/how-to-contribute.md
+++ b/_articles/zh-hant/how-to-contribute.md
@@ -133,7 +133,7 @@ redirect_from: /zh-tw/how-to-contribute/
 
 ### **其實不一定要是開源軟體的專案！**
 
-雖然很多人提到「開源」兩字是指「開源軟體」，其實不盡是如此，許多事物你都可以你可以開源協作，你可以開源一本書、開源食譜、開源一張你整理的清單，都可以像開源軟體一樣發展你想製作的東西。
+雖然很多人提到「開源」兩字是指「開源軟體」，其實不盡是如此，許多事物你都可以開源協作，你可以開源一本書、開源食譜、開源一張你整理的清單，都可以像開源軟體一樣發展你想製作的東西。
 
 舉例來說：
 
@@ -392,7 +392,7 @@ redirect_from: /zh-tw/how-to-contribute/
 
 在你提出一個 issue 或 PR 之前，或者是在聊天室提問之前，請謹記下面所列出的幾點建議，會讓你的工作更有效率。
 
-**交代來龍去脈。** 以便於讓其他人能夠快速的理解。比方說執行程式時遇到一個錯誤，你要解釋你是當時是想做甚麼，並描述如何做才能重現錯誤。又比方說你是提交一個新的想法，你要解釋爲什麼這麼想，為什麼你認為這點子對專案會有幫助（而不是只對你有幫助！）
+**交代來龍去脈。** 以便於讓其他人能夠快速的理解。比方說執行程式時遇到一個錯誤，你要解釋你當時是想做甚麼，並描述如何做才能重現錯誤。又比方說你是提交一個新的想法，你要解釋爲什麼這麼想，為什麼你認為這點子對專案會有幫助（而不是只對你有幫助！）
 
 > 😇 _"當我做 Y 的時候 X 功能沒有正常運作"_
 >

From 318cfab47e2208c1bdecb902776ec1baa8cee0a7 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 27 May 2021 08:05:13 +0000
Subject: [PATCH 179/749] Bump github-pages from 214 to 215

Bumps [github-pages](https://github.com/github/pages-gem) from 214 to 215.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v214...v215)

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 30 +++++++++++++++++++-----------
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 3029fa9f9cc..d341f41640b 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (6.0.3.6)
+    activesupport (6.0.3.7)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
@@ -25,17 +25,25 @@ GEM
     ethon (0.14.0)
       ffi (>= 1.15.0)
     eventmachine (1.2.7)
-    execjs (2.7.0)
-    faraday (1.3.0)
+    execjs (2.8.1)
+    faraday (1.4.2)
+      faraday-em_http (~> 1.0)
+      faraday-em_synchrony (~> 1.0)
+      faraday-excon (~> 1.1)
       faraday-net_http (~> 1.0)
+      faraday-net_http_persistent (~> 1.1)
       multipart-post (>= 1.2, < 3)
-      ruby2_keywords
+      ruby2_keywords (>= 0.0.4)
+    faraday-em_http (1.0.0)
+    faraday-em_synchrony (1.0.0)
+    faraday-excon (1.1.0)
     faraday-net_http (1.0.1)
-    ffi (1.15.0)
+    faraday-net_http_persistent (1.1.0)
+    ffi (1.15.1)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (214)
-      github-pages-health-check (= 1.17.0)
+    github-pages (215)
+      github-pages-health-check (= 1.17.2)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
       jekyll-coffeescript (= 1.1.1)
@@ -78,7 +86,7 @@ GEM
       nokogiri (>= 1.10.4, < 2.0)
       rouge (= 3.26.0)
       terminal-table (~> 1.4)
-    github-pages-health-check (1.17.0)
+    github-pages-health-check (1.17.2)
       addressable (~> 2.3)
       dnsruby (~> 1.60)
       octokit (~> 4.0)
@@ -220,12 +228,12 @@ GEM
       jekyll-seo-tag (~> 2.1)
     minitest (5.14.4)
     multipart-post (2.1.1)
-    nokogiri (1.11.4)
+    nokogiri (1.11.6)
       mini_portile2 (~> 2.5.0)
       racc (~> 1.4)
     nokogumbo (2.0.5)
       nokogiri (~> 1.8, >= 1.8.4)
-    octokit (4.20.0)
+    octokit (4.21.0)
       faraday (>= 0.9)
       sawyer (~> 0.8.0, >= 0.5.3)
     parallel (1.20.1)
@@ -235,7 +243,7 @@ GEM
     racc (1.5.2)
     rainbow (3.0.0)
     rake (13.0.3)
-    rb-fsevent (0.10.4)
+    rb-fsevent (0.11.0)
     rb-inotify (0.10.1)
       ffi (~> 1.0)
     rexml (3.2.5)

From 5ffb174ea59ec87f701205054f1ff2c3cd6e1958 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 28 May 2021 08:09:42 +0000
Subject: [PATCH 180/749] Bump actions/cache from 2.1.5 to 2.1.6

Bumps [actions/cache](https://github.com/actions/cache) from 2.1.5 to 2.1.6.
- [Release notes](https://github.com/actions/cache/releases)
- [Commits](https://github.com/actions/cache/compare/v2.1.5...v2.1.6)

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 0eb22ebf388..eaf4eeda1a7 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -17,7 +17,7 @@ jobs:
       uses: actions/setup-node@v2.1.5
 
     - name: Restore bundler cache
-      uses: actions/cache@v2.1.5
+      uses: actions/cache@v2.1.6
       with:
         path: vendor/gems
         key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}

From eaa2e65479e74f92aa79c8174f7c325feb031cb6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E7=AB=AB=E6=B3=93?= <jinghong@hong.local>
Date: Sat, 29 May 2021 11:47:01 +0800
Subject: [PATCH 181/749] =?UTF-8?q?Fix=20typo=20There=20is=20no=20word=20"?=
 =?UTF-8?q?=E8=BF=B4=E6=87=89".=20The=20word=20"=E8=BF=B4=E6=87=89"=20shou?=
 =?UTF-8?q?ld=20be=20"=E5=9B=9E=E6=87=89".?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 _articles/zh-hant/code-of-conduct.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/zh-hant/code-of-conduct.md b/_articles/zh-hant/code-of-conduct.md
index fd0dfc14ea0..bff385c7ae4 100644
--- a/_articles/zh-hant/code-of-conduct.md
+++ b/_articles/zh-hant/code-of-conduct.md
@@ -71,7 +71,7 @@ redirect_from: /zh-tw/code-of-conduct/
 
 有的社群成員可能是讓大家一直不舒服的慣犯，或者他們只是說了或做了一次。這都需要依據實際情況進行處理。
 
-在你們做出迴應之前，請認真思考發生了什麼事。通過閱讀他們過去的評論和對話可以更好地理解他們爲什麼要那樣做。儘量收集其他人對他們行爲的看法。
+在你們做出回應之前，請認真思考發生了什麼事。通過閱讀他們過去的評論和對話可以更好地理解他們爲什麼要那樣做。儘量收集其他人對他們行爲的看法。
 
 <aside markdown="1" class="pquote">
   不要陷入爭論。在你們處理完手頭上的事情之前，不要側重於處理別人的行爲。專注於你們需要什麼。
@@ -86,7 +86,7 @@ redirect_from: /zh-tw/code-of-conduct/
 
 當有人報告違規時，處理它是你們的工作，而不是他們的。有時，報告者透露他們的資訊會給他們的職業生涯，聲譽和人生安全帶來很大的風險。迫使報告者面對騷擾者會將他們置於妥協的位置。除非報告者有特別的要求，你們應該直接和有問題的人溝通。
 
-這裏有些方法幫助你們迴應違規行爲：
+這裏有些方法幫助你們回應違規行爲：
 
 * **向相關人員發出公開警告**以及解釋他們的行爲產生了怎樣的負面影響，最好在發生問題的地方。在可能的情況下，公開溝通會向社群的其他人傳達你們認真對待行爲守則。要友善，但堅定的溝通。
 

From c77ffee0d1fe50c12f990b03cfd16904cc767677 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 31 May 2021 19:01:50 +0300
Subject: [PATCH 182/749] Fix the order values.

The order values in the articales should be integer.
See: https://github.com/github/opensource.guide/pull/2411#discussion_r642570267
---
 _articles/tr/code-of-conduct.md    | 2 +-
 _articles/tr/finding-users.md      | 2 +-
 _articles/tr/how-to-contribute.md  | 2 +-
 _articles/tr/starting-a-project.md | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md
index 886e0c91a85..2684e206fe1 100644
--- a/_articles/tr/code-of-conduct.md
+++ b/_articles/tr/code-of-conduct.md
@@ -9,7 +9,7 @@ toc:
   deciding-how-youll-enforce-your-code-of-conduct: Davranış kurallarınızı nasıl uygulayacağınıza karar verme
   enforcing-your-code-of-conduct: Davranış kurallarınızı uygulama
   your-responsibilities-as-a-maintainer: Bir koruyucu olarak sorumluluklarınız
-order: '8'
+order: 8
 image: "/assets/images/cards/coc.png"
 related:
   - building
diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md
index 20d8e3c976e..bce84ae8e80 100644
--- a/_articles/tr/finding-users.md
+++ b/_articles/tr/finding-users.md
@@ -10,7 +10,7 @@ toc:
   go-where-your-projects-audience-is-online: Projenizin izleyicisinin (çevrimiçi) olduğu yere gidin
   go-where-your-projects-audience-is-offline: Projenizin kitlesinin (çevrimdışı) olduğu yere gidin
   build-a-reputation: Bir itibar oluşturun
-order: '3'
+order: 3
 image: "/assets/images/cards/finding.png"
 related:
   - beginners
diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md
index 487e228f428..d576a8f38c0 100644
--- a/_articles/tr/how-to-contribute.md
+++ b/_articles/tr/how-to-contribute.md
@@ -10,7 +10,7 @@ toc:
   finding-a-project-to-contribute-to: Katkıda bulunacak bir proje bulma
   how-to-submit-a-contribution: Katkı nasıl gönderilir?
   what-happens-after-you-submit-a-contribution: Bir katkı gönderdikten sonra ne olur?
-order: '1'
+order: 1
 image: "/assets/images/cards/contribute.png"
 related:
   - beginners
diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index e577a4289a3..bb125850cba 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -9,7 +9,7 @@ toc:
   launching-your-own-open-source-project: Kendi açık kaynak projenizi başlatmak
   naming-and-branding-your-project: Projenizi isimlendirme ve markalama
   your-pre-launch-checklist: Lansman öncesi kontrol listeniz
-order: '2'
+order: 2
 image: "/assets/images/cards/beginner.png"
 related:
   - finding

From 04365d9682a78f3963bc8bcf81637b3e2448f7b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 31 May 2021 19:11:39 +0300
Subject: [PATCH 183/749] Fix linter issues

Emphasis should use `_` as a marker
---
 _articles/tr/code-of-conduct.md    |  2 +-
 _articles/tr/finding-users.md      |  2 +-
 _articles/tr/how-to-contribute.md  | 30 +++++++++++++++---------------
 _articles/tr/starting-a-project.md |  6 +++---
 4 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md
index 2684e206fe1..7fd904dfa0b 100644
--- a/_articles/tr/code-of-conduct.md
+++ b/_articles/tr/code-of-conduct.md
@@ -50,7 +50,7 @@ CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTIN
   </p>
 </aside>
 
-Bir ihlal meydana *gelmeden önce* davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var:
+Bir ihlal meydana _gelmeden önce_ davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var:
 
 * İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir.
 
diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md
index bce84ae8e80..967bd8c3461 100644
--- a/_articles/tr/finding-users.md
+++ b/_articles/tr/finding-users.md
@@ -86,7 +86,7 @@ Projenizi ilgili kanallarda paylaşmanın yollarını bulabilecek misiniz bir ba
 
 * **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır.
 * **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun.
-* **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin.
+* **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: _"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum_ ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin.
 
 Genel olarak konuşursak, karşılığında bir şey istemeden önce başkalarına yardım etmeye odaklanın. Herkes bir projeyi çevrimiçi olarak kolayca tanıtabildiğinden, çok fazla gürültü çıkacaktır. Kalabalıktan sıyrılmak için, insanlara sadece ne istediğinizi değil, kim olduğunuzu anlatmaya çalışın.
 
diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md
index d576a8f38c0..27ca581694b 100644
--- a/_articles/tr/how-to-contribute.md
+++ b/_articles/tr/how-to-contribute.md
@@ -67,7 +67,7 @@ Endişe etmeyin! Açık kaynak kodlu bir projeye dahil olmanın çok farklı yol
 
 ### Kod yazarak katkıda bulunmak zorunda değilsin
 
-Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye *büyük bir* iyilik yapacaksınız!
+Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye _büyük bir_ iyilik yapacaksınız!
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
@@ -189,7 +189,7 @@ Projelerin belgeleri de vardır. Bu dosyalar genellikle bir kütüphanenin dizin
 
 * **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir.
 * **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar.
-* **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder.
+* **CONTRIBUTING:** README dosyaları projeyi insanların _kullanmalarına_ yardımcı olurken, CONTRIBUTING dökümanları insanların projeye _katkıda_ bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder.
 * **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir.
 * **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir.
 
@@ -197,14 +197,14 @@ Son olarak, açık kaynak projeler tartışmaları yönetmek için aşağıdaki
 
 * **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler.
 * **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler.
-* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır.
+* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine _"Nasıl ...?"_ veya _"Ne düşünüyorsunuz ...?" gibi_). Diğerleri, tüm konuşmalar için sorun listesini kullanır.
 * **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır.
 
 ## Katkıda bulunacak bir proje bulma
 
 Açık kaynak projelerin nasıl çalıştığını çözdüğünüze göre, katkıda bulunacak bir proje bulma zamanı!
 
-Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, *"Ülkenizin sizin için neler yapabileceğini değil * ülkeniz için neler yapabileceğinizi sorun"* diyen ABD Başkanı John F. Kennedy'yi  örnek alın.
+Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, _"Ülkenizin sizin için neler yapabileceğini değil, ülkeniz için neler yapabileceğinizi sorun"_ diyen ABD Başkanı John F. Kennedy'yi  örnek alın.
 
 Açık kaynağa katkıda bulunmak, farklı projelerde her seviyede gerçekleşir. İlk katkınızın tam olarak ne olacağını veya nasıl görüneceğini düşünmeniz gerekmez.
 
@@ -406,39 +406,39 @@ Bir sorunu açmadan veya bir PR oluşturmadan ya da sohbette bir soru sormadan 
 
 **Bağlam ver.** Başkalarının sizi anlamada hızlanmalarına yardımcı olun. Bir hatayla karşılaşıyorsanız, ne yapmaya çalıştığınızı ve nasıl tekrarlanabileceğini açıklayın. Yeni bir fikir önerecekseniz, neden projeye faydalı olacağını düşündüğünüzü açıklayın (sadece sizin için değil!).
 
-> 😇 *"Y yaptığımda X olmuyor"*
+> 😇 _"Y yaptığımda X olmuyor"_
 >
-> 😢 *"X çalışmıyor! Lütfen düzeltin."*
+> 😢 _"X çalışmıyor! Lütfen düzeltin."_
 
 **Ödevini önceden yap.** Bir şeyleri bilmemek normaldir, ama denediğini göster. Yardım istemeden önce, bir projenin README'sini, belgelerini, sorun listesini (açık veya kapalı), e-posta listesini kontrol ettiğinizden ve bir cevap için interneti aradığınızdan emin olun. Öğrenmeye çalıştığını gösterdiğin zaman insanlar takdir edeceklerdir.
 
-> 😇 *"X'in nasıl uygulanacağından emin değilim. Yardım belgelerini kontrol ettim ve herhangi bir yerde bulamadım."*
+> 😇 _"X'in nasıl uygulanacağından emin değilim. Yardım belgelerini kontrol ettim ve herhangi bir yerde bulamadım."_
 >
 > 😢 <em>"X nasıl yapılır?"</em>
 
 **İstekleri kısa ve öz tutun.** Bir e-posta göndermek gibi, ne kadar basit veya yararlı olursa olsun, her katkı başkasının incelemesini gerektirir. Birçok projenin, yardım için uygunların yapabileceklerinden daha fazla gelen talebi olur. Basit olun. Birinin size yardım edebilme şansını artıracaksınız.
 
-> 😇 *"Bir API öğretici belgesi yazmak istiyorum."*
+> 😇 _"Bir API öğretici belgesi yazmak istiyorum."_
 >
-> 😢 *"Geçen gün otoyoldan aşağı iniyordum ve benzin için durdum ve sonra aklıma yapmamız gereken bir şey için inanılmaz bir fikir geldi, ama bunu açıklamadan önce sana göstereyim ..."*
+> 😢 _"Geçen gün otoyoldan aşağı iniyordum ve benzin için durdum ve sonra aklıma yapmamız gereken bir şey için inanılmaz bir fikir geldi, ama bunu açıklamadan önce sana göstereyim ..."_
 
 **Tüm iletişimi herkese açık tutun.** Her ne kadar cazip olsa da, hassas bilgileri (güvenlik sorunu veya ciddi davranış ihlali gibi) paylaşmanız gerekmedikçe, geliştiricilere özel olarak ulaşmayın. Sohbeti herkese açık tuttuğunuzda, daha fazla kişi alış verişinizden öğrenebilir ve bundan faydalanabilir. Tartışmalar da kendi başlarına katkı sayılabilir.
 
-> 😇 *(yorum olarak) "@-maintainer Merhabalar! Bu PR'a nasıl devam edelim?"*
+> 😇 _(yorum olarak) "@-maintainer Merhabalar! Bu PR'a nasıl devam edelim?"_
 >
-> 😢 *(bir e-posta olarak) "Hey, e-posta yüzünden sizi rahatsız ettiğim için özür dilerim, ancak PR'mi gözden geçirme şansınız olup olmadığını merak ediyordum"*
+> 😢 _(bir e-posta olarak) "Hey, e-posta yüzünden sizi rahatsız ettiğim için özür dilerim, ancak PR'mi gözden geçirme şansınız olup olmadığını merak ediyordum"_
 
 **Soru sormak sorun değil (ama sabırlı olun!).** Herkes bir zamanlar projede yeniydi ve deneyimli katılımcıların bile yeni bir projeye bakarken hız kazanmaları gerekiyor. Aynı şekilde, uzun süredir devam edenler bile, projenin her bölümüne aşina değildir. Onlara size göstermelerini istediğiniz sabrı gösterin.
 
-> 😇 *"Bu hatayı incelediğiniz için teşekkür ederiz. Önerilerinizi takip ettim. İşte sonuç."*
+> 😇 _"Bu hatayı incelediğiniz için teşekkür ederiz. Önerilerinizi takip ettim. İşte sonuç."_
 >
-> 😢 *"Neden sorunumu çözemiyorsun? Bu senin projen değil mi?"*
+> 😢 _"Neden sorunumu çözemiyorsun? Bu senin projen değil mi?"_
 
 **Topluluk kararlarına saygı gösterin.** Fikirleriniz, toplumun öncelikleri veya vizyonundan farklı olabilir. Geri bildirim sunabilir veya fikrinizi sürdürmemeye karar verebilirler. Tartışmanız ve uzlaşı aramanız gerekirken, geliştiriciler kararınızla sizden daha uzun yaşamak zorundadır. Düşüncelerine katılmıyorsanız, her zaman kendi çatalınızla çalışabilir veya kendi projenizi başlatabilirsiniz.
 
-> 😇 *"Fikrimi destekleyemediğiniz için hayal kırıklığına uğradım, ancak bunun sadece kullanıcıların küçük bir bölümünü etkilediğini açıkladığınızdan, nedenini anlıyorum. Dinlediğiniz için teşekkürler."*
+> 😇 _"Fikrimi destekleyemediğiniz için hayal kırıklığına uğradım, ancak bunun sadece kullanıcıların küçük bir bölümünü etkilediğini açıkladığınızdan, nedenini anlıyorum. Dinlediğiniz için teşekkürler."_
 >
-> 😢 *"Neden fikrimi desteklemiyorsun? Bu kabul edilemez!"*
+> 😢 _"Neden fikrimi desteklemiyorsun? Bu kabul edilemez!"_
 
 **Her şeyden önce, zarif olun.** Açık kaynak dünyanın her yerinden ortak çalışanlardan oluşur. Bağlam diller, kültürler, coğrafyalar ve zaman dilimleri arasında kaybolur. Ek olarak, yazılı iletişim bir ton veya ruh halini iletmeyi zorlaştırır. Bu konuşmaların niyetlerinin iyi olduğunu düşünün. Bir fikre kibarca geri dönmek, daha fazla içerik istemek veya konumunuzu daha da netleştirmek iyi bir şey. İnterneti bulduğunuzdan daha iyi bir yer bırakmaya çalışın.
 
diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index bb125850cba..1ee05533c1f 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -26,7 +26,7 @@ Bir proje açık kaynak olduğunda, **herhangi biri herhangi bir amaç için pro
 
 Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek, benimseme engellerini azaltır. Ayrıca, kullanıcılara kapalı kaynağa göre kendi bilgisayarlarını ve bilgisayarlarında çalışan işlemleri kontrol etme imkanı da verir. Örneğin, açık kaynak yazılım kullanan bir işletme, yalnızca kapalı kaynak satıcısının ürün kararlarına güvenmek yerine, bir kişiyi yazılımda özel iyileştirmeler yapması için işe alma seçeneğine sahiptir.
 
-*Özgür yazılım* , *açık kaynak ile* aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. *Free* ve  *Libre* özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor).
+_Özgür yazılım_ , _açık kaynak ile_ aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. *Free* ve  *Libre* özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor).
 
 ### İnsanlar neden işlerini açık kaynak olarak sunarlar?
 
@@ -68,7 +68,7 @@ Henüz ikna olmadıysanız, hedeflerinizin ne olabileceğini düşünmek için b
 
 ### Hedeflerinizi belirlemek
 
-Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, *neden bu projeye kaynak açıyorum?*
+Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, _neden bu projeye kaynak açıyorum?_
 
 Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahip farklı projeler için birden fazla hedefiniz olabilir.
 
@@ -206,7 +206,7 @@ Son olarak, bir davranış kural listesi projenizin katılımcı davranışları
 
 Daha fazla bilgi için [Davranış Kuralları kılavuzumuza](../code-of-conduct/) göz atın.
 
-Katılımcıların *nasıl* davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir.
+Katılımcıların _nasıl_ davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir.
 
 Açık kaynaklı lisanslara benzer şekilde, davranış kuralları için de yeni ortaya çıkan standartlar vardır, bu yüzden kendiniz yazmak zorunda değilsiniz. [Contributor Covenant](https://contributor-covenant.org/), Kubernet, Rails ve Swift dahil olmak üzere [40.000'den fazla açık kaynaklı proje](https://www.contributor-covenant.org/adopters) tarafından kullanılan bir davranış kural listesi şablonudur. Hangi metni kullanırsanız kullanın, gerektiğinde davranış kurallarınızı uygulamak için hazırlıklı olmalısınız.
 

From 9c45412fe008a65ef4bb6ac226f06266435e9746 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 31 May 2021 19:14:42 +0300
Subject: [PATCH 184/749] Fix linter issue on
 _articles/tr/starting-a-project.md

Emphasis should use `_` as a marker
---
 _articles/tr/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index 1ee05533c1f..9d6550a2aaf 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -26,7 +26,7 @@ Bir proje açık kaynak olduğunda, **herhangi biri herhangi bir amaç için pro
 
 Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek, benimseme engellerini azaltır. Ayrıca, kullanıcılara kapalı kaynağa göre kendi bilgisayarlarını ve bilgisayarlarında çalışan işlemleri kontrol etme imkanı da verir. Örneğin, açık kaynak yazılım kullanan bir işletme, yalnızca kapalı kaynak satıcısının ürün kararlarına güvenmek yerine, bir kişiyi yazılımda özel iyileştirmeler yapması için işe alma seçeneğine sahiptir.
 
-_Özgür yazılım_ , _açık kaynak ile_ aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. *Free* ve  *Libre* özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor).
+_Özgür yazılım_ , _açık kaynak ile_ aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. _Free_ ve  _Libre_ özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor).
 
 ### İnsanlar neden işlerini açık kaynak olarak sunarlar?
 

From c31b9195b98611f5ba777b835192c563f7ed9966 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= <umutphp@gmail.com>
Date: Mon, 31 May 2021 19:21:00 +0300
Subject: [PATCH 185/749] Fix internal broken link to code of conduct file

---
 _articles/tr/building-community.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md
index 27a71fc056a..ca3f25f42bb 100644
--- a/_articles/tr/building-community.md
+++ b/_articles/tr/building-community.md
@@ -127,7 +127,7 @@ Bu tür insanlara karşı sıfır tolerans politikası benimsemek için elinizde
 
 Projenizin önemsiz yönleriyle ilgili düzenli tartışmalar, sizin de dahil olmak üzere diğerlerini önemli görevlere odaklanmaktan alıkoyuyor. Projenize gelen yeni insanlar bu konuşmaları görebilir ve katılmak istemeyebilir.
 
-Projenizde olumsuz davranışlar olduğunu gördüğünüzde, herkese açık olarak uyarın. Nazikçe ama sert bir tonda, davranışlarının neden kabul edilebilir olmadığını açıklayın. Sorun devam ederse, [onlardan gitmelerini istemeniz](../code-of-conduct/#davran%C4%B1%C5%9F-kural-listesini-g%C3%BC%C3%A7lendirmek) gerekebilir. [Davranış kuralları listeniz](../code-of-conduct/) bu konuşmalar için yapıcı bir rehber olabilir.
+Projenizde olumsuz davranışlar olduğunu gördüğünüzde, herkese açık olarak uyarın. Nazikçe ama sert bir tonda, davranışlarının neden kabul edilebilir olmadığını açıklayın. Sorun devam ederse, [onlardan gitmelerini istemeniz](../code-of-conduct/#davran%C4%B1%C5%9F-kurallar%C4%B1n%C4%B1z%C4%B1-g%C3%BC%C3%A7lendirmek) gerekebilir. [Davranış kuralları listeniz](../code-of-conduct/) bu konuşmalar için yapıcı bir rehber olabilir.
 
 ### Katkıda bulunan katılımcılarla oldukları yerde tanışın
 

From 3c35bd433cab3b3f9d83d581cc6e7fd319faf328 Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Tue, 1 Jun 2021 13:29:25 +0100
Subject: [PATCH 186/749] script/html-proofer: ignore more URLs.

These are causing CI failures:
https://github.com/github/opensource.guide/pull/2424/checks?check_run_id=2712132660#step:7:37
---
 script/html-proofer | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/script/html-proofer b/script/html-proofer
index 0aecc9353ac..b9b25649176 100755
--- a/script/html-proofer
+++ b/script/html-proofer
@@ -7,7 +7,9 @@ url_ignores = [
   "https://okdistribute.xyz/post/okf-de",
   "https://www.drupal.org/community-initiatives/drupal-core/usability",
   "https://scripts.sil.org/ofl",
+  "https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/",
   %r{^https?://twitter\.com/},
+  %r{^https?://kickstarter\.com/},
 ]
 
 HTMLProofer::Runner.new(

From dd2493bf185852d74686b419995900ccd50c9272 Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Thu, 3 Jun 2021 13:04:04 +0100
Subject: [PATCH 187/749] CODEOWNERS: tweak teams

Adjust teams based on GitHub internal changes.
---
 CODEOWNERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CODEOWNERS b/CODEOWNERS
index c2ae4268f1e..4bbc6f01f99 100644
--- a/CODEOWNERS
+++ b/CODEOWNERS
@@ -1 +1 @@
-*  @github/communities-heart-reviewers @github/devrel
+*  @github/communities-oss-reviewers

From a5f742836ec496a77b5edb54a667f655d686ac36 Mon Sep 17 00:00:00 2001
From: Adrian Sanchis Gallego <sanchis1992@gmail.com>
Date: Wed, 23 Jun 2021 18:55:48 +0200
Subject: [PATCH 188/749] fix: spelling problem

---
 _articles/es/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/es/legal.md b/_articles/es/legal.md
index 29a307f5e41..96b7627fff2 100644
--- a/_articles/es/legal.md
+++ b/_articles/es/legal.md
@@ -18,7 +18,7 @@ Compartir tu trabajo creativo con el mundo puede ser una experiencia excitante y
 
 ¡Me alegro que lo preguntes! Cuando realizas trabajo creativo (como escritura, dibujo, o c&oacute;digo), ese trabajo se encuentra bajo derechos de autor por defecto. Es decir, la ley asume que, como autor de tu trabajo, tienes poder de decisi&oacute;n sobre lo que los otros pueden o no hacer con ello.
 
-En general, estoy significa que nadie m&aacute;s  puede usar, copiar, distribuir, o modificar tu trabajo sin tener riesgo de sufrir bajas, ser investigado o demandado.
+En general, esto significa que nadie m&aacute;s  puede usar, copiar, distribuir, o modificar tu trabajo sin tener riesgo de sufrir bajas, ser investigado o demandado.
 
 Sin embargo, el c&oacute;digo abierto es una circunstancia inusual debido a que el autor espera que otros usen, modifiquen, y compartan el trabajo. Pero, debido a que legalmente por defecto los derechos de autor son exclusivos, se necesita una licencia que enuncie expl&iacute;citamente estos permisos.
 

From d280e00f6886dac9a860cb8e6ab40921eceb61fc Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Mon, 28 Jun 2021 12:23:49 +0100
Subject: [PATCH 189/749] script/html-proofer: ignore more Kickstarter URLs.

These are failing in HTML Proofer but working in Safari.
---
 script/html-proofer | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/script/html-proofer b/script/html-proofer
index b9b25649176..a1344df4c5e 100755
--- a/script/html-proofer
+++ b/script/html-proofer
@@ -9,7 +9,7 @@ url_ignores = [
   "https://scripts.sil.org/ofl",
   "https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/",
   %r{^https?://twitter\.com/},
-  %r{^https?://kickstarter\.com/},
+  %r{^https?://(www\.)?kickstarter\.com/},
 ]
 
 HTMLProofer::Runner.new(

From a3a41bfdf917e8f37adc9ea8cbe0dff57f573533 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 28 Jun 2021 11:37:27 +0000
Subject: [PATCH 190/749] Bump html-proofer from 3.19.1 to 3.19.2

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.19.1 to 3.19.2.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.19.1...v3.19.2)

---
updated-dependencies:
- dependency-name: html-proofer
  dependency-type: direct:development
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index d341f41640b..f0220e5b72e 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -39,7 +39,7 @@ GEM
     faraday-excon (1.1.0)
     faraday-net_http (1.0.1)
     faraday-net_http_persistent (1.1.0)
-    ffi (1.15.1)
+    ffi (1.15.3)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
     github-pages (215)
@@ -95,7 +95,7 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.19.1)
+    html-proofer (3.19.2)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)
@@ -221,14 +221,14 @@ GEM
       rb-fsevent (~> 0.10, >= 0.10.3)
       rb-inotify (~> 0.9, >= 0.9.10)
     mercenary (0.3.6)
-    mini_portile2 (2.5.1)
+    mini_portile2 (2.5.3)
     minima (2.5.1)
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
     minitest (5.14.4)
     multipart-post (2.1.1)
-    nokogiri (1.11.6)
+    nokogiri (1.11.7)
       mini_portile2 (~> 2.5.0)
       racc (~> 1.4)
     nokogumbo (2.0.5)

From 762446976494e868523637cc4aa175838ae3ca82 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 1 Jul 2021 08:09:23 +0000
Subject: [PATCH 191/749] Bump actions/setup-node from 2.1.5 to 2.2.0

Bumps [actions/setup-node](https://github.com/actions/setup-node) from 2.1.5 to 2.2.0.
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/v2.1.5...v2.2.0)

---
updated-dependencies:
- dependency-name: actions/setup-node
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index eaf4eeda1a7..221c82c753c 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -14,7 +14,7 @@ jobs:
       uses: actions/setup-ruby@v1.1.3
 
     - name: Set up Node
-      uses: actions/setup-node@v2.1.5
+      uses: actions/setup-node@v2.2.0
 
     - name: Restore bundler cache
       uses: actions/cache@v2.1.6

From 29c124e89a1e31669fcfde479dd0aa422acef362 Mon Sep 17 00:00:00 2001
From: Raphael-MOUQUIN <86474028+Raphael-MOUQUIN@users.noreply.github.com>
Date: Wed, 7 Jul 2021 15:48:55 +0200
Subject: [PATCH 192/749] Update starting-a-project.md

---
 _articles/fr/starting-a-project.md | 52 +++++++++++++++---------------
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/_articles/fr/starting-a-project.md b/_articles/fr/starting-a-project.md
index 24b40e13a61..dd62eb8b68b 100644
--- a/_articles/fr/starting-a-project.md
+++ b/_articles/fr/starting-a-project.md
@@ -12,22 +12,22 @@ related:
 
 ## Le &quot;quoi&quot; et le &quot;pourquoi&quot; de l'open source
 
-Donc, vous songez à commencer avec l'open source ? Toutes nos félicitations ! Le monde apprécie votre contribution. Parlons de ce qu'est l'open source et pourquoi les gens le font.
+Donc, vous songez à commencer avec l'open source ? Toutes nos félicitations ! Le monde va apprécier votre contribution. Parlons de ce qu'est l'open source et pourquoi les gens le font.
 
 ### Que signifie "open source" ?
 
-Lorsqu'un projet est open source, cela signifie que **n'importe qui peut voir, utiliser, modifier et distribuer votre projet pour n'importe quel but.** Ces autorisations sont appliquées via [une licence open source](https://opensource.org/licenses).
+Lorsqu'un projet est open source, cela signifie que **n'importe qui peut voir, utiliser, modifier et distribuer votre projet dans n'importe quel but.** Ces autorisations sont appliquées via [une licence open source](https://opensource.org/licenses).
 
 L'open source est puissant car il abaisse les barrières à l'adoption, permettant aux idées de se propager rapidement.
 
-Pour comprendre comment cela fonctionne, imaginez que votre ami a un potluck, et que vous apportez une tarte aux cerises.
+Pour comprendre comment cela fonctionne, imaginez qu'un ami organise une collation, et que vous apportez une tarte aux cerises.
 
 * Tout le monde goûte la tarte (_utiliser_)
 * La tarte est un succès ! Ils vous demandent la recette que vous leur fournissez (_voir_)
 * Un ami, Alex, qui est chef pâtissier, suggère de réduire le sucre (_modifier_)
 * Une autre amie, Lisa, demande à l'utiliser pour un dîner la semaine prochaine (_distribuer_)
 
-Par comparaison, un processus de source fermée serait de se rendre dans un restaurant et commander une tranche de tarte aux cerises. Vous devez payer des frais pour manger la tarte, et le restaurant ne vous donnera probablement pas leur recette. Si vous avez copié leur tarte exactement et l'avez vendue sous votre propre nom, le restaurant pourrait prendre des mesures contre vous.
+Par comparaison, un processus de source fermée serait de se rendre dans un restaurant et commander une tranche de tarte aux cerises. Vous devez payer des frais pour manger la tarte, et le restaurant ne vous donnera probablement pas leur recette. Si vous avez copié leur tarte exactement et l'avez vendue sous votre propre nom, le restaurant pourrait même prendre des mesures légales contre vous.
 
 ### Pourquoi les gens ouvrent-ils leur travail ?
 
@@ -39,13 +39,13 @@ Par comparaison, un processus de source fermée serait de se rendre dans un rest
   </p>
 </aside>
 
-[Il y a plein de raisons](https://ben.balter.com/2015/11/23/why-open-source/) pour une personne ou une organisation de vouloir ouvrir un projet. Par exemple :
+[Il y a de nombreuses raisons](https://ben.balter.com/2015/11/23/why-open-source/) pour une personne ou une organisation de vouloir ouvrir un projet. Parmi celles-ci :
 
 * **Collaboration :** Les projets open source peuvent accepter des changements de n'importe qui dans le monde. [Exercism](https://github.com/exercism/), par exemple, est une plate-forme d'exercices de programmation avec plus de 350 contributeurs.
 
-* **Adoption et remixage :** Les projets open source peuvent être utilisés par n'importe qui pour presque n'importe quel but. Les gens peuvent même l'utiliser pour construire d'autres choses. [WordPress](https://github.com/WordPress), par exemple, a commencé en tant que fork d'un projet existant appelé [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **Adoption et remixage :** Les projets open source peuvent être utilisés par n'importe qui dans presque n'importe quel but. Les gens peuvent même l'utiliser pour construire d'autres choses. [WordPress](https://github.com/WordPress), par exemple, a commencé en tant que fork (nous verrons plus tard ce qu'on appelle un fork, pour le moment voyez ceci comme une copie à un instant donné) d'un projet existant appelé [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparence :** Tout le monde peut inspecter un projet open source pour y chercher des erreurs ou des incohérences. La transparence est importante pour des gouvernements comme celui de [Bulgarie](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou des [États-Unis](https://sourcecode.cio.gov/), les industries réglementées comme la banque ou les soins de santé, et les logiciels de sécurité comme [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparence :** Tout le monde peut inspecter un projet open source pour y chercher des erreurs ou des incohérences. La transparence est importante pour des gouvernements comme celui de [Bulgarie](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou des [États-Unis](https://sourcecode.cio.gov/), les industries réglementées comme les banques ou les soins de santé, et les logiciels de sécurité comme [Let's Encrypt](https://github.com/letsencrypt).
 
 L'open source n'est pas seulement pour les logiciels. Vous pouvez tout rendre open source depuis les jeux de données aux livres. Jetez un coup d'œil sur [GitHub Explore](https://github.com/explore) pour trouver des idées sur ce que vous pouvez faire d'autre.
 
@@ -61,7 +61,7 @@ En conséquence, la plupart des projets open source sont gratuits, mais la "grat
 
 La réponse courte est oui, car peu importe le résultat, le lancement de votre propre projet est une excellente façon d'apprendre comment fonctionne l'open source.
 
-Si vous n'avez jamais ouvert un projet auparavant, vous pourriez être nerveux à propos de ce que les gens diront, ou du risque que personne ne le remarque. Si cela vous ressemble, vous n'êtes pas seul !
+Si vous n'avez jamais ouvert aux autres un projet auparavant, vous pourriez vous demander ce que les gens vont penser, ou être inquiet du risque que personne ne le remarquera. Si cela vous parle, sachez que vous n'êtes pas seul !
 
 Le travail open source est comme toute autre activité créative, que ce soit l'écriture ou la peinture. Cela peut être effrayant de partager votre travail avec le reste du monde, mais la seule façon de s'améliorer est de pratiquer - même si vous n'avez pas de public.
 
@@ -73,27 +73,27 @@ Les objectifs peuvent vous aider à déterminer ce sur quoi vous devez travaille
 
 Il n'y a pas de bonne réponse à cette question. Vous pouvez avoir plusieurs objectifs pour un même projet ou différents projets avec des objectifs différents.
 
-Si votre seul objectif est de montrer votre travail, vous ne voulez peut-être même pas de contributions, et même le dire dans votre fichier README. D'un autre côté, si vous voulez des contributeurs, vous allez investir du temps dans une documentation claire et faire en sorte que les nouveaux arrivants se sentent les bienvenus.
+Si votre seul objectif est de montrer votre travail, vous ne voulez peut-être même pas de contributions, et vous pouvez alors même le dire dans votre fichier README. D'un autre côté, si vous voulez des contributeurs, vous allez investir du temps dans une documentation claire et faire en sorte que les nouveaux arrivants se sentent les bienvenus.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
-  A un certain moment, j'ai créé un UIAlertView personnalisé que j'utilisais... et j'ai décidé de le rendre open source. Je l'ai donc modifié pour être plus dynamique et l'ai téléchargé sur GitHub. J'ai également écrit ma première documentation expliquant aux autres développeurs comment l'utiliser sur leurs projets. Probablement personne ne l'a jamais utilisé parce que c'était un projet simple mais je me sentais bien dans ma contribution.
+  A un certain moment, j'ai créé un UIAlertView personnalisé que j'utilisais... et j'ai décidé de le rendre open source. Je l'ai donc modifié pour être plus dynamique et l'ai mis à disposition sur GitHub. J'ai également écrit ma première documentation expliquant aux autres développeurs comment l'utiliser dans leurs projets. Probablement personne ne l'a jamais utilisé parce que c'était un projet simple mais je me sentais satisfait de ma contribution.
   <p markdown="1" class="pquote-credit">
 — @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
   </p>
 </aside>
 
-Au fur et à mesure que votre projet grandit, votre communauté peut avoir besoin de plus que du code. Répondre aux problèmes, réviser le code et promouvoir votre projet sont des tâches importantes dans un projet open source.
+Au fur et à mesure que votre projet grandit, votre communauté peut commencer à avoir besoin de plus que du code. Gardez bien à l'esprit que répondre aux problèmes, réviser le code et promouvoir votre projet sont des tâches importantes dans un projet open source.
 
 Bien que le temps que vous consacrez à des tâches sans code dépende de la taille et de la portée de votre projet, vous devez vous préparer en tant que responsable à les résoudre par vous-même ou à trouver quelqu'un pour vous aider.
 
 **Si vous faites partie d'une entreprise qui ouvre le code source d'un projet,** assurez-vous que votre projet dispose des ressources internes dont il a besoin pour prospérer. Vous voudrez identifier qui est responsable de la maintenance du projet après son lancement et comment vous allez partager ces tâches avec votre communauté.
 
-Si vous avez besoin d'un budget ou d'un personnel dédié pour la promotion, les opérations et la maintenance du projet, commencez ces conversations aussi tôt que possible.
+Si vous avez besoin d'un budget ou d'un personnel dédié pour la promotion, les opérations et la maintenance du projet, commencez ces discussions au sein de votre entreprise aussi tôt que possible.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-  Lorsque vous commencez à ouvrir le projet, il est important de vous assurer que vos processus de gestion prennent en compte les contributions et les capacités de la communauté autour de votre projet. N'ayez pas peur d'impliquer des contributeurs qui ne sont pas employés dans votre entreprise dans les aspects clés du projet — surtout s'ils sont des contributeurs fréquents.
+  Lorsque vous commencez à ouvrir le projet, il est important de vous assurer que vos processus de gestion prennent en compte les contributions et les capacités de la communauté autour de votre projet. N'ayez pas peur d'impliquer des contributeurs qui ne sont pas employés dans votre entreprise dans les aspects clés du projet — surtout s'ils sont des contributeurs réguliers.
   <p markdown="1" class="pquote-credit">
 — @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
   </p>
@@ -124,7 +124,7 @@ Si votre projet est sur GitHub, placer ces fichiers dans votre répertoire racin
 
 ### Choisir une licence
 
-Une licence open source garantit que d'autres utilisateurs peuvent utiliser, copier, modifier et contribuer à votre projet sans aucune répercussion. Il vous protège également contre les situations juridiques épineuses. **Vous devez inclure une licence lorsque vous lancez un projet open source.**
+Une licence open source garantit que d'autres utilisateurs peuvent utiliser, copier, modifier et contribuer à votre projet sans aucune répercussion. Elle vous protège également contre les situations juridiques épineuses. **Vous devez inclure une licence lorsque vous lancez un projet open source.**
 
 Le travail juridique n'est pas amusant. La bonne nouvelle est que vous pouvez copier et coller une licence existante dans votre dépôt. Cela ne prendra qu'une minute pour protéger votre dur labeur.
 
@@ -151,13 +151,13 @@ Vous pouvez utiliser votre fichier README pour répondre à d'autres questions,
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
-  Une meilleure documentation signifie plus d'utilisateurs, moins de demandes de support et plus de contributeurs. (...) Rappelez-vous que vos lecteurs ne sont pas vous. Il y a des gens qui pourraient participer à un projet et qui ont des expériences complètement différentes.
+  Une meilleure documentation signifie plus d'utilisateurs, moins de demandes de support et plus de contributeurs. (...) Rappelez-vous que vos lecteurs ne sont pas vous. Il y a des gens avec des expériences complètement différentes qui pourraient participer à votre projet.
   <p markdown="1" class="pquote-credit">
 — @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
   </p>
 </aside>
 
-Parfois, les gens évitent d'écrire un fichier README parce qu'ils ont l'impression que le projet n'est pas terminé ou qu'ils ne veulent pas de contributions. Ce sont toutes de très bonnes raisons d'en écrire une.
+Parfois, les gens évitent d'écrire un fichier README parce qu'ils ont l'impression que le projet n'est pas terminé ou qu'ils ne veulent pas de contributions. En fait ce sont toutes de très bonnes raisons d'en écrire un.
 
 Pour plus d'inspiration, essayez d'utiliser celui de @18F ["Making READMEs Readable"](https://pages.18f.gov/open-source-guide/making-readmes-readable/) ou le [modèle de README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) de @PurpleBooth pour écrire un fichier README complet.
 
@@ -185,7 +185,7 @@ Par exemple, [Active Admin](https://github.com/activeadmin/activeadmin/) démarr
 
 Dans les premières étapes de votre projet, votre fichier CONTRIBUTING peut être simple. Vous devez toujours expliquer comment signaler les bogues ou les problèmes de fichiers, ainsi que les exigences techniques (comme les tests) pour apporter une contribution.
 
-Au fil du temps, vous pouvez ajouter d'autres questions fréquemment posées à votre fichier CONTRIBUTING. L'écriture de cette information signifie que moins de personnes vous poseront les mêmes questions encore et encore.
+Au fil du temps, vous pouvez ajouter d'autres questions fréquemment posées à votre fichier CONTRIBUTING. La rédaction de ce genre d'informations signifie que moins de personnes vous poseront les mêmes questions encore et encore.
 
 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/).
 
@@ -207,15 +207,15 @@ Enfin, un code de conduite permet de définir des règles de base pour le compor
 
 Pour plus d'informations, consultez notre [Code de conduite](../code-of-conduct/).
 
-En plus de d'indiquer _comment_ vous souhaitez que les participants se comportent, un code de conduite a également tendance à décrire à qui s'appliquent ces attentes, quand elles s'appliquent, et que faire en cas de violation.
+En plus d'indiquer _comment_ vous souhaitez que les participants se comportent, un code de conduite a également tendance à décrire à qui s'appliquent ces attentes, quand elles s'appliquent, et que faire en cas de violation.
 
 Tout comme les licences open source, il existe également des normes émergentes pour les codes de conduite, vous n'avez donc pas besoin d'écrire les vôtres. Le [Contributor Covenant](https://contributor-covenant.org/)) est un code de conduite qui est utilisé par [plus de 40 000 projets open source](https://www.contributor-covenant.org/adopters) , y compris Kubernetes, Rails et Swift. Quel que soit le texte que vous utilisez, vous devez être prêt à appliquer votre code de conduite si nécessaire.
 
-Collez le texte directement dans un fichier CODE_OF_CONDUCT dans votre repository. Conservez le fichier dans le répertoire racine de votre projet pour qu'il soit facile à trouver et liez-le à partir de votre fichier README.
+Collez le texte directement dans un fichier CODE_OF_CONDUCT dans votre repository. Conservez le fichier dans le répertoire racine de votre projet pour qu'il soit facile à trouver et mettez un lien vers lui dans votre fichier README.
 
 ## Nommer et créer l'image de marque de votre projet
 
-La marque est plus qu'un logo flashy ou un nom de projet accrocheur. Il s'agit de la façon dont vous parlez de votre projet et de qui vous parlez avec votre message.
+La marque est plus qu'un logo flashy ou un nom de projet accrocheur. Il s'agit de la façon dont vous parlez de votre projet et à qui est destiné votre message.
 
 ### Choisir le bon nom
 
@@ -228,15 +228,15 @@ Si vous construisez sur un projet existant, l'utilisation de leur nom comme pré
 
 Pensez à la clarté avant tout. Faire des jeux de mots, c'est amusant, mais rappelez-vous que certaines blagues peuvent ne pas se traduire dans d'autres cultures et des personnes ayant des expériences différentes de vous peuvent ne pas les comprendre. Certains de vos utilisateurs potentiels peuvent être des employés dans une entreprise : vous ne voulez pas les mettre mal à l'aise quand ils devront expliquer votre projet au travail !
 
-### Eviter les conflits de noms
+### Éviter les conflits de noms
 
 [Vérifiez les projets open source avec un nom similaire](http://ivantomic.com/projects/ospnc/), surtout si vous partagez le même langage ou écosystème. Si votre nom est trop proche de celui d'un projet existant populaire, vous risquez de perturber votre auditoire.
 
 Si vous souhaitez un site Web, un pseudo Twitter ou d'autres entités pour représenter votre projet, assurez-vous de pouvoir obtenir les noms souhaités. Idéalement, [réservez ces noms maintenant](https://instantdomainsearch.com/) pour votre tranquillité d'esprit, même si vous n'avez pas l'intention de les utiliser pour l'instant.
 
-Assurez-vous que le nom de votre projet ne porte atteinte à aucune marque. Une entreprise pourrait vous demander d'arrêter votre projet dans le futur, ou même intenter une action en justice contre vous. Cela ne vaut tout simplement pas le risque.
+Assurez-vous que le nom de votre projet ne porte pas atteinte à une marque. Une entreprise pourrait vous demander d'arrêter votre projet dans le futur, ou même intenter une action en justice contre vous. Cela ne vaut tout simplement pas le risque.
 
-Vous pouvez consulter la [Base de données mondiale de l'OMPI sur les marques](http://www.wipo.int/branddb/en/) pour les conflits de marques. Si vous êtes dans une entreprise, c'est un des sujets sur lesquels [votre équipe juridique peut vous aider](../legal/).
+Vous pouvez consulter la [Base de données mondiale de l'OMPI sur les marques](https://www.wipo.int/branddb/fr/) pour obtenir des informations sur les marques provenant de différentes sources aux niveaux national et international. Si vous êtes dans une entreprise, c'est un des sujets sur lesquels [votre équipe juridique peut vous aider](../legal/).
 
 Enfin, recherchez le nom de votre projet sur Google. Les gens pourront-ils trouver facilement votre projet ? Est-ce que quelque chose d'autre apparaît dans les résultats de recherche que vous ne voudriez pas qu'ils voient ?
 
@@ -248,13 +248,13 @@ Qu'il s'agisse d'une documentation officielle ou d'un courriel occasionnel, votr
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  J'ai essayé de m'impliquer dans tous les sujets de la liste de diffusion, de montrer un comportement exemplaire, d'être gentil avec les gens, de prendre leurs problèmes au sérieux et d'essayer d'être utile dans l'ensemble. Au bout d'un moment, les gens sont restés non seulement à poser des questions, mais aussi à répondre aux questions, et à mon plus grand plaisir, ils ont imité mon style.
+  J'ai essayé de m'impliquer dans tous les sujets de la liste de diffusion, de montrer un comportement exemplaire, d'être gentil avec les gens, de prendre leurs problèmes au sérieux et d'essayer d'être utile dans l'ensemble. Au bout d'un moment, les gens sont restés non seulement à poser des questions, mais aussi à répondre aux questions, et pour mon plus grand plaisir, ils ont imité mon style.
   <p markdown="1" class="pquote-credit">
 — @janl sur [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
-L'utilisation d'un langage chaleureux et inclusif (tel que «eux», même en faisant référence à la personne seule) peut faire beaucoup pour rendre votre projet accueillant pour les nouveaux contributeurs. Tenez-vous-en à un langage simple, car bon nombre de vos lecteurs ne sont peut-être pas francophones.
+L'utilisation d'un langage chaleureux et inclusif (tel que l'utilisation de «eux», même en faisant référence à la personne seule) peut faire beaucoup pour rendre votre projet accueillant pour les nouveaux contributeurs. Tenez-vous-en à un langage simple, car bon nombre de vos lecteurs ne sont peut-être pas francophones.
 
 Au-delà de votre façon d'écrire, votre style de codage peut également faire partie de la marque de votre projet. [Angular](https://github.com/johnpapa/angular-styleguide) et [jQuery](https://contribute.jquery.org/style-guide/js/) sont deux exemples de projets avec des lignes directrices et des styles de codage rigoureux.
 
@@ -299,7 +299,7 @@ Prêt à lancer votre projet open source ? Voici une checklist pour vous aider.
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    Le projet utilise des conventions de code cohérentes et les noms de fonction / méthode / variable sont clairs
+    Le projet utilise des conventions de code cohérentes et les noms des fonctions / méthodes / variables sont clairs
   </label>
 </div>
 

From 3462ac4d533b7e41620edb43ebd6feb0eacf3486 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 9 Jul 2021 08:05:09 +0000
Subject: [PATCH 193/749] Bump rake from 13.0.3 to 13.0.6

Bumps [rake](https://github.com/ruby/rake) from 13.0.3 to 13.0.6.
- [Release notes](https://github.com/ruby/rake/releases)
- [Changelog](https://github.com/ruby/rake/blob/master/History.rdoc)
- [Commits](https://github.com/ruby/rake/compare/v13.0.3...v13.0.6)

---
updated-dependencies:
- dependency-name: rake
  dependency-type: direct:development
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index f0220e5b72e..efc3703ddda 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -242,7 +242,7 @@ GEM
     public_suffix (4.0.6)
     racc (1.5.2)
     rainbow (3.0.0)
-    rake (13.0.3)
+    rake (13.0.6)
     rb-fsevent (0.11.0)
     rb-inotify (0.10.1)
       ffi (~> 1.0)

From a2b33e07d1b011c6e13c0210a4ce9779aabbb563 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 12 Jul 2021 21:48:49 +0000
Subject: [PATCH 194/749] Bump addressable from 2.7.0 to 2.8.0

Bumps [addressable](https://github.com/sporkmonger/addressable) from 2.7.0 to 2.8.0.
- [Release notes](https://github.com/sporkmonger/addressable/releases)
- [Changelog](https://github.com/sporkmonger/addressable/blob/main/CHANGELOG.md)
- [Commits](https://github.com/sporkmonger/addressable/compare/addressable-2.7.0...addressable-2.8.0)

---
updated-dependencies:
- dependency-name: addressable
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index f0220e5b72e..10340c2aa27 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -7,7 +7,7 @@ GEM
       minitest (~> 5.1)
       tzinfo (~> 1.1)
       zeitwerk (~> 2.2, >= 2.2.2)
-    addressable (2.7.0)
+    addressable (2.8.0)
       public_suffix (>= 2.0.2, < 5.0)
     coffee-script (2.4.1)
       coffee-script-source

From bffae31105aad41cd44673efb0c270d5d6f1328d Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 21 Jul 2021 08:08:39 +0000
Subject: [PATCH 195/749] Bump actions/setup-node from 2.2.0 to 2.3.0

Bumps [actions/setup-node](https://github.com/actions/setup-node) from 2.2.0 to 2.3.0.
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/v2.2.0...v2.3.0)

---
updated-dependencies:
- dependency-name: actions/setup-node
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 221c82c753c..6077f47a4e0 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -14,7 +14,7 @@ jobs:
       uses: actions/setup-ruby@v1.1.3
 
     - name: Set up Node
-      uses: actions/setup-node@v2.2.0
+      uses: actions/setup-node@v2.3.0
 
     - name: Restore bundler cache
       uses: actions/cache@v2.1.6

From 09d6da1dfdd7d57ab4840b93d357d6b0314ea9cd Mon Sep 17 00:00:00 2001
From: Jared Tan <jian.tan@daocloud.io>
Date: Mon, 26 Jul 2021 14:06:50 +0800
Subject: [PATCH 196/749] fix mirror typo

---
 _articles/zh-hans/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md
index 3a8113891a5..b7b8b02b893 100644
--- a/_articles/zh-hans/starting-a-project.md
+++ b/_articles/zh-hans/starting-a-project.md
@@ -54,7 +54,7 @@ redirect_from: /zh-cn/starting-a-project/
 
 开源最大的吸引之一是它不花钱。 但是，"免费"只是开源的总体价值的一个副产品。
 
-因为[开源许可证要求](https://opensource.org/osd-annotated)任何人可以几乎出于任何目使用，修改和共享您的项目，项目本身往往是免费的。 如果该项目花钱使用，任何人也都可以合法地复制和使用免费版本。
+因为[开源许可证要求](https://opensource.org/osd-annotated)任何人可以几乎出于任何目的使用，修改和共享您的项目，项目本身往往是免费的。 如果该项目花钱使用，任何人也都可以合法地复制和使用免费版本。
 
 因此，大多数开源项目是免费的，但"免费"不是开源定义的一部分。 有些方法可以通过双重许可或有限功能间接地为开源项目收费，同时仍然遵守开源的官方定义。
 

From 13bc4fdd09dd21c462340736267fc148c1c7df9f Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 30 Jul 2021 08:04:16 +0000
Subject: [PATCH 197/749] Bump github-pages from 215 to 218

Bumps [github-pages](https://github.com/github/pages-gem) from 215 to 218.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v215...v218)

---
updated-dependencies:
- dependency-name: github-pages
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 96 +++++++++++++++++++++++++++-------------------------
 1 file changed, 50 insertions(+), 46 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 811ecb68ffc..d0c0ea4d793 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (6.0.3.7)
+    activesupport (6.0.4)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
@@ -16,8 +16,8 @@ GEM
     colorator (1.1.0)
     commonmarker (0.17.13)
       ruby-enum (~> 0.5)
-    concurrent-ruby (1.1.8)
-    dnsruby (1.61.5)
+    concurrent-ruby (1.1.9)
+    dnsruby (1.61.7)
       simpleidn (~> 0.1)
     em-websocket (0.5.2)
       eventmachine (>= 0.12.9)
@@ -26,23 +26,27 @@ GEM
       ffi (>= 1.15.0)
     eventmachine (1.2.7)
     execjs (2.8.1)
-    faraday (1.4.2)
+    faraday (1.5.1)
       faraday-em_http (~> 1.0)
       faraday-em_synchrony (~> 1.0)
       faraday-excon (~> 1.1)
+      faraday-httpclient (~> 1.0.1)
       faraday-net_http (~> 1.0)
       faraday-net_http_persistent (~> 1.1)
+      faraday-patron (~> 1.0)
       multipart-post (>= 1.2, < 3)
       ruby2_keywords (>= 0.0.4)
     faraday-em_http (1.0.0)
     faraday-em_synchrony (1.0.0)
     faraday-excon (1.1.0)
+    faraday-httpclient (1.0.1)
     faraday-net_http (1.0.1)
-    faraday-net_http_persistent (1.1.0)
+    faraday-net_http_persistent (1.2.0)
+    faraday-patron (1.0.0)
     ffi (1.15.3)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (215)
+    github-pages (218)
       github-pages-health-check (= 1.17.2)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
@@ -63,19 +67,19 @@ GEM
       jekyll-seo-tag (= 2.7.1)
       jekyll-sitemap (= 1.4.0)
       jekyll-swiss (= 1.0.0)
-      jekyll-theme-architect (= 0.1.1)
-      jekyll-theme-cayman (= 0.1.1)
-      jekyll-theme-dinky (= 0.1.1)
-      jekyll-theme-hacker (= 0.1.2)
-      jekyll-theme-leap-day (= 0.1.1)
-      jekyll-theme-merlot (= 0.1.1)
-      jekyll-theme-midnight (= 0.1.1)
-      jekyll-theme-minimal (= 0.1.1)
-      jekyll-theme-modernist (= 0.1.1)
-      jekyll-theme-primer (= 0.5.4)
-      jekyll-theme-slate (= 0.1.1)
-      jekyll-theme-tactile (= 0.1.1)
-      jekyll-theme-time-machine (= 0.1.1)
+      jekyll-theme-architect (= 0.2.0)
+      jekyll-theme-cayman (= 0.2.0)
+      jekyll-theme-dinky (= 0.2.0)
+      jekyll-theme-hacker (= 0.2.0)
+      jekyll-theme-leap-day (= 0.2.0)
+      jekyll-theme-merlot (= 0.2.0)
+      jekyll-theme-midnight (= 0.2.0)
+      jekyll-theme-minimal (= 0.2.0)
+      jekyll-theme-modernist (= 0.2.0)
+      jekyll-theme-primer (= 0.6.0)
+      jekyll-theme-slate (= 0.2.0)
+      jekyll-theme-tactile (= 0.2.0)
+      jekyll-theme-time-machine (= 0.2.0)
       jekyll-titles-from-headings (= 0.5.3)
       jemoji (= 0.12.0)
       kramdown (= 2.3.1)
@@ -164,45 +168,45 @@ GEM
     jekyll-sitemap (1.4.0)
       jekyll (>= 3.7, < 5.0)
     jekyll-swiss (1.0.0)
-    jekyll-theme-architect (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-architect (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-cayman (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-cayman (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-dinky (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-dinky (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-hacker (0.1.2)
+    jekyll-theme-hacker (0.2.0)
       jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-leap-day (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-leap-day (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-merlot (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-merlot (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-midnight (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-midnight (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-minimal (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-minimal (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-modernist (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-modernist (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-primer (0.5.4)
+    jekyll-theme-primer (0.6.0)
       jekyll (> 3.5, < 5.0)
       jekyll-github-metadata (~> 2.9)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-slate (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-slate (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-tactile (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-tactile (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-time-machine (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-time-machine (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
     jekyll-titles-from-headings (0.5.3)
       jekyll (>= 3.3, < 5.0)
@@ -217,7 +221,7 @@ GEM
     kramdown-parser-gfm (1.1.0)
       kramdown (~> 2.0)
     liquid (4.0.3)
-    listen (3.5.1)
+    listen (3.6.0)
       rb-fsevent (~> 0.10, >= 0.10.3)
       rb-inotify (~> 0.9, >= 0.9.10)
     mercenary (0.3.6)
@@ -250,8 +254,8 @@ GEM
     rouge (3.26.0)
     ruby-enum (0.9.0)
       i18n
-    ruby2_keywords (0.0.4)
-    rubyzip (2.3.0)
+    ruby2_keywords (0.0.5)
+    rubyzip (2.3.2)
     safe_yaml (1.0.5)
     sass (3.7.4)
       sass-listen (~> 4.0.0)

From caf434188933dece397f1c14fefa89b1e7d63f1a Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Mon, 2 Aug 2021 04:27:55 -0400
Subject: [PATCH 198/749] Update legal.md

---
 _articles/fr/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index 7342d22995e..6c7412b7682 100644
--- a/_articles/fr/legal.md
+++ b/_articles/fr/legal.md
@@ -125,7 +125,7 @@ Pour le meilleur ou pour le pire, envisagez de les informer même s'il s'agit d'
 
 * **Brevets :** Votre entreprise demande-t-elle un brevet dont l'open source de votre projet constituerait [divulgation publique](https://en.wikipedia.org/wiki/Public_disclosure) ? Malheureusement, vous pourriez être invité à attendre (ou peut-être que l'entreprise reconsidérera la maturité de l'application). Si vous attendez des contributions d'employés d'entreprises ayant de grands portefeuilles de brevets, votre équipe juridique voudra peut-être utiliser une licence avec un brevet spécialement pour les contributeurs (comme Apache 2.0 ou GPLv3) ou un accord de contribution supplémentaire (voir au dessus).
 
-* **Marques :** Vérifiez que le nom de votre projet [n'est pas en conflit avec les marques existantes](../starting-a-project/#eviter-les-conflits-de-noms). Si vous utilisez les marques de votre propre entreprise dans le projet, vérifiez qu'il ne provoque aucun conflit. [FOSSmarks](http://fossmarks.org/) est un guide pratique pour comprendre les marques dans le contexte de projets libres et open source.
+* **Marques :** Vérifiez que le nom de votre projet [n'est pas en conflit avec les marques existantes](../starting-a-project/#%E9viter-les-conflits-de-noms). Si vous utilisez les marques de votre propre entreprise dans le projet, vérifiez qu'il ne provoque aucun conflit. [FOSSmarks](http://fossmarks.org/) est un guide pratique pour comprendre les marques dans le contexte de projets libres et open source.
 
 * **Confidentialité :** Votre projet recueille-t-il des données sur les utilisateurs ? "Téléphone Maison" aux serveurs de l'entreprise ? Votre équipe juridique peut vous aider à respecter les politiques de l'entreprise et les réglementations externes.
 

From 4ddc9aae969b46a1460a521f59f332d90e6ac4d1 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Mon, 2 Aug 2021 10:31:47 +0200
Subject: [PATCH 199/749] Update _articles/fr/legal.md

---
 _articles/fr/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index 6c7412b7682..f1ca789143c 100644
--- a/_articles/fr/legal.md
+++ b/_articles/fr/legal.md
@@ -125,7 +125,7 @@ Pour le meilleur ou pour le pire, envisagez de les informer même s'il s'agit d'
 
 * **Brevets :** Votre entreprise demande-t-elle un brevet dont l'open source de votre projet constituerait [divulgation publique](https://en.wikipedia.org/wiki/Public_disclosure) ? Malheureusement, vous pourriez être invité à attendre (ou peut-être que l'entreprise reconsidérera la maturité de l'application). Si vous attendez des contributions d'employés d'entreprises ayant de grands portefeuilles de brevets, votre équipe juridique voudra peut-être utiliser une licence avec un brevet spécialement pour les contributeurs (comme Apache 2.0 ou GPLv3) ou un accord de contribution supplémentaire (voir au dessus).
 
-* **Marques :** Vérifiez que le nom de votre projet [n'est pas en conflit avec les marques existantes](../starting-a-project/#%E9viter-les-conflits-de-noms). Si vous utilisez les marques de votre propre entreprise dans le projet, vérifiez qu'il ne provoque aucun conflit. [FOSSmarks](http://fossmarks.org/) est un guide pratique pour comprendre les marques dans le contexte de projets libres et open source.
+* **Marques :** Vérifiez que le nom de votre projet [n'est pas en conflit avec les marques existantes](../starting-a-project/#éviter-les-conflits-de-noms). Si vous utilisez les marques de votre propre entreprise dans le projet, vérifiez qu'il ne provoque aucun conflit. [FOSSmarks](http://fossmarks.org/) est un guide pratique pour comprendre les marques dans le contexte de projets libres et open source.
 
 * **Confidentialité :** Votre projet recueille-t-il des données sur les utilisateurs ? "Téléphone Maison" aux serveurs de l'entreprise ? Votre équipe juridique peut vous aider à respecter les politiques de l'entreprise et les réglementations externes.
 

From a88db4eeda113f4e08321efc46ac4da4dd20dd02 Mon Sep 17 00:00:00 2001
From: Iman Ghasrfakhri <ghasrfakhri@gmail.com>
Date: Thu, 5 Aug 2021 11:23:26 +0430
Subject: [PATCH 200/749] Fix unneeded new lines and spaces

---
 _articles/fa/best-practices.md | 17 +----------------
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md
index 8a7a7b9006d..3992c5c131b 100644
--- a/_articles/fa/best-practices.md
+++ b/_articles/fa/best-practices.md
@@ -18,7 +18,6 @@ related:
 
 نگهداری یک پروژه، به چیزی بیشتر از کدنویسی نیاز دارد. این وظایف اغلب به صورت ناگهانی پیش می‌آیند؛ اما آن‌ها به همان اندازه‌ی پروژه‌ی در حال رشد مهم هستند. ما برای آسان‌تر کردن زندگی‌تان چند روش آماده کرده‌ایم؛ از مراحل ثبت کردن فرآیند گرفته تا بهره‌بردن از اجتماع‌تان.
 
-
 ## ثبت کردن فرآیندها
 
 نوشتن مطالب، یکی از مهم‌ترین کارهایی است که می‌توانید به عنوان نگهدارنده انجام دهید.
@@ -31,7 +30,6 @@ related:
 
 به یاد داشته باشید که نوشتن مطالب را به روز نگه دارید. اگر همیشه قادر به انجام این کار نیستید، مطالب قدیمی خود را حذف کنید یا مشخص کنید که این مطالب  منسوخ شده‌اند تا مانع به روز رسانی‌های مشارکت‌کنندگان نشوید.
 
-
 ### چشم انداز خودتان از پروژه را یادداشت کنید
 
 با نوشتن هدف‌های خودتان از پروژه، شروع کنید. آن‌ها را به «README» (من را بخوانید) خود اضافه کنید یا یک فایل جداگانه به نام  «VISION » (چشم انداز) ایجاد کنید. اگر موارد دیگری وجود دارد که می‌تواند به شما کمک کند؛ مانند نقشه‌ی راه پروژه، آن‌ها را نیز به صورت عمومی منتشر کنید.
@@ -77,7 +75,6 @@ related:
 
 به این ترتیب، هر کسی که به انجمن شما بپیوندد به همان اطلاعاتی که سال‌ها در آنجا بوده است، دسترسی خواهد داشت.
 
-
 ## نه گفتن، را یاد بگیرید
 
 شما مطالب خود را ثبت کردید. در حالت ایده آل، همه نوشته‌ها و مستندات شما را می‌خوانند، اما در واقع، شما باید به دیگران وجود این اطلاعات را نیز یادآوری کنید.
@@ -88,7 +85,6 @@ related:
 
 نه گفتن در بسیاری از شرایطی که به عنوان نگهدارنده با آن روبرو خواهید شد، به کار می‌آید: درخواست‌هایی که با ویژگی‌های پروژه‌ی شما متناسب نیستند، کسی که بحث را به بیراهه می‌کشاند، انجام کارهای غیرضروری برای دیگران.
 
-
 ### دوستانه با دیگران ارتباط برقرار کنید
 
 یکی از مهم‌ترین جاهایی که شما باید تمرین نه گفتن را انجام دهید، در سر برخی از مسائل و «درخواست‌های pull» ای است که از شما می‌شود. به عنوان نگهدارنده‌ی پروژه، ناگزیر پیشنهادهایی دریافت خواهید کرد که نمی‌خواهید آن‌ها را بپذیرید.
@@ -128,7 +124,7 @@ related:
 
 > من با نگهدارنده‌هایی از پروژه‌های اوپن سورس مختلف مانندMesos» ،«Kubernetes» «Chromium صحبت کرده‌ام و همه موافق هستند که یکی از سخت‌ترین قسمت‌های نگهدارنده بودن، «نه» گفتن به اصلاحاتی است که نمی‌خواهید.
 
-در نپذیرفتن پیشنهاد مشارکت کسی، احساس گناه نکنید. [طبق گفته‌ی](https://twitter.com/solomonstre/status/715277134978113536) @shykes، اولین قانون پروژه‌های اوپن سورس این است که: «نه موقتی‌ست، بله برای همیشه».  در حالی که همدردی با اشتیاق فرد دیگر، چیز پسندیده‌ای است؛ اما رد کردن پیشنهاد مشارکت به معنای رد کردن هویت فرد پشت سر آن پیشنهاد نیست.
+در نپذیرفتن پیشنهاد مشارکت کسی، احساس گناه نکنید. [طبق گفته‌ی](https://twitter.com/solomonstre/status/715277134978113536) @shykes، اولین قانون پروژه‌های اوپن سورس این است که: «نه موقتی‌ست، بله برای همیشه». در حالی که همدردی با اشتیاق فرد دیگر، چیز پسندیده‌ای است؛ اما رد کردن پیشنهاد مشارکت به معنای رد کردن هویت فرد پشت سر آن پیشنهاد نیست.
 
 ختم کلام این است که اگر مشارکت با دیگری به اندازه کافی خوب نباشد، شما ملزم به پذیرفتن هیچ تعهدی نیستید. وقتی دیگران در پروژه‌ی شما مشارکت می‌کنند، مهربان و پاسخگو باشید؛ اما فقط تغییراتی را قبول کنید که واقعاً معتقد هستید پروژه‌ی شما را بهتر می‌کند. هر چه در نه گفتن، تمرین بیشتری داشته باشید؛ گفتن آن راحت‌تر می‌شود. به شما قول می‌دهم.
 
@@ -138,7 +134,6 @@ related:
 
 اگر درخواست‌های مشارکت بسیار کم کیفیت دریافت می‌کنید، از افراد متقاضی بخواهید کمی قبل از ارسال پیشنهاد، کارهایی انجام دهند؛ به عنوان مثال:
 
-
 * Fill out a issue or PR template/checklist
 * قبل از ارسال درخواست Pull یک گزارش اشکال ارسال کنند.
 
@@ -162,7 +157,6 @@ related:
 
 اگر دیدید کسی مشتاق پروژه‌ی شما است، اما به کمی پیشرفت نیاز دارد، صبور باشید. در هر شرایطی به روشنی توضیح دهید که چرا مشارکت آن‌ها متناسب با انتظارات پروژه‌ی شما نیست. سعی کنید ابتدا وظایفی ساده‌تر و با ابهامات کمتر به آن‌ها بسپرید تا به قول معروف «آماده‌ی کار شوند». اگر وقت داشتید، در اولین مشارکت، آن‌ها را راهنمایی کنید، یا شخص دیگری را در اجتماع خود پیدا کنید که تمایل به راهنمایی کردن آن‌ها داشته باشد.
 
-
 ## از اجتماع خود بهره ببرید
 
 لازم نیست همه‌ی کارها را خودتان انجام دهید. دلیلی دارد که پروژه‌ی شما، اجتماعی برای خود دارد! حتی اگر هنوز اجتماعی فعال ندارید، اگر کاربران زیادی دارید، کارها را به آن‌ها بسپرید.
@@ -175,10 +169,8 @@ related:
 
 وقتی مشاهده کردید که مشارکت‌کنندگان جدید به صورت مکرر همکاری می‌کنند، با دادن مسئولیت‌های بیشتر، آن‌ها را تصدیق کنید و به رسمیت بشناسید. مشخص کنید که چگونه دیگران می‌توانند در صورت اشتیاق به جایگاه‌های رهبری دست یابند.
 
-
 همانطور که @lmccart در پروژه‌ی خود متوجه شد، تشویق دیگران [به اشتراک گذاشتن مالکیت پروژه](../building-community/#share-ownership-of-your-project) می‌تواند حجم کاری شما را بسیار کاهش دهد[p5.js](https://github.com/processing/p5.js).
 
-
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
   من می‌گفتم، «هر کسی می‌تواند در پروژه سهیم شود، لازم نیست که حتما مهارت زیادی در زمینه‌ی کدنویسی داشته باشید [...]» افرادی بودند که برای ورود به رویداد ما ثبت‌نام کردند و آن وقت بود که من واقعاً با خودم فکر کردم «آیا حرف‌هایی که می‌زدم واقعیت دارند؟» قرار هست که 40 نفر در رویداد حضور پیدا کنند و اینطور نیست که من بتوانم با هرکدام بنشینم و با آن‌ها صحبت کنم... اما مردم دور هم جمع شدند و خود به خود همه چی به خوبی پیش رفت. به محض اینکه یک نفر یاد گرفت، آن‌ها می‌توانند به یکدیگر یاد دهند.
@@ -191,10 +183,8 @@ related:
 
 اگر افراد دیگری مشتاق این هستند، به آن‌ها اجازه‌ی دسترسی دهید یا کنترل پروژه را به طور رسمی به شخص دیگری بسپارید. اگر کسی پروژه‌ی شما را به چند شاخه تبدیل کرد و به طور فعال آن را در جای دیگری نگهداری کرد، پیوند دادن پروژه‌ی اصلی خود به شاخه را مد نظر قرار دهید. این خیلی خوب است که مردم می‌خواهند پروژه شما ادامه یابد!
 
-
 @progrium [متوجه شد]( https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) که ثبت کردن چشم‌انداز [پروژه](https://github.com/dokku/dokku)، کمک کرد تا آن اهداف حتی پس از کنار کشیدن او ادامه یابند:
 
-
 > من یک صفحه‌ در ویکی نوشتم و آنچه را که می‌خواهم و چرایی آن را توصیف کردم. بنا به دلایلی برای من تعجب‌آور بود که نگهدارندگان شروع به انتقال پروژه به سمت و سوی دلخواه خود کردند! آیا آنطور که می‌خواستم، پیش رفت؟ نه همیشه. ولی پروژه را به آنچه که نوشته‌ بودم، نزدیک‌تر کرد.
 
 ### به دیگران اجازه دهید تا راه‎‌حل‌های مورد نیاز خودشان را طراحی کنند
@@ -203,7 +193,6 @@ related:
 
 به چند شاخه تقسیم کردن پروژه، الزاما چیز بدی نیست. امکان کپی و اصلاح پروژه‌ها، یکی از بهترین ویژگی‌های اوپن سورس بودن است. تشویق اجتماع (community) خودتان به کار بر روی شاخه‌های خودشان می‌تواند فضای خلاقانه‌ی مورد نیاز را فراهم آورد، بدون اینکه با چشم‌اندازهای پروژه‌ی شما تداخلی ایجاد کند.
 
-
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
   من زمینه‌ی 80% موارد کاربردی را فراهم می‌کنم.  اگر از کار خود اطمینان دارید، لطفا شاخه‌ای از پروژه‌ی من را بردارید. دلخور نخواهم شد! پروژه‌های عمومی من اکثرا برای حل رایج‌ترین مشکلات هستند؛ سعی می‌کنم با شاخه شاخه کردن کارم یا بسط دادن، آن را کاربردی‌تر بکنم.
@@ -214,7 +203,6 @@ related:
 
 این موضوع همچنین درمورد کاربری صدق می‌کند که واقعاً نیاز به راه‌حلی دارد که ظرفیت طراحی آن را ندارید. ارائه‌ی APIها و هوک‌های سفارشی‌سازی (customization hooks)، بدون نیاز به تغییر مستقیم سورس، می‌توانند به دیگران در تأمین نیازهاشان کمک کنند. @orta [متوجه شد](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) که افزونه‌های پرورشی برای «CocoaPods» منجر به «برخی از جالب‌ترین ایده‌ها» شد:
 
-
 > تقریباً اجتناب‌ناپذیر به نظر می‌رسد که به محض بزرگ‌تر شدن پروژه، نگهدارنده‌ها باید در مورد نحوه تعریف کدهای جدید بسیار محافظه‌کارانه‌تر عمل کنند. شاید در گفتن «نه» تبحر پیدا کرده باشید، اما هنوز بسیاری از مردم نیازهایی معقول و منطقی دارند. بنابراین، در نهایت ابزار شما به یک پلتفرم تبدیل می‌شود.
 
 ## از ربات‌ها استفاده کنید
@@ -245,7 +233,6 @@ related:
 
 [ابزارهای متنوعی برای کمک](https://github.com/showcases/tools-for-open-source) به اتوماتیک کردن برخی جنبه‌های کار نگهداری وجود دارد. به عنوان مثال:
 
-
 * ابزار [emantic-release](https://github.com/semantic-release/semantic-release)، عرضه نسخه‌های جدید شما را اتوماتیک می‌کند.
 * ابزار [mention-bot](https://github.com/facebook/mention-bot)، به بازبین‌های بالقوه برای «درخواست pull»ها خبر می دهد.
 * ابزار [Danger](https://github.com/danger/danger)، به بررسی و بازبینی اتوماتیک کد کمک می‌کند.
@@ -262,7 +249,6 @@ related:
 
 اگر مطمئن نیستید که از چه ابزاری استفاده کنید، به سایر پروژه‌های معروف به ویژه آن پروژه‌هایی که مربوط به اکوسیستم خودتان است، توجه کنید. به عنوان مثال، فرآیند مشارکت برای سایر ماژول‌های «Node»، چگونه است؟ همچنین استفاده از ابزارها و رویکردهای مشابه، فرآیند کارتان را برای مشارکت‌کنندگان‌ شما آشناتر می‌کند.
 
-
 ## اشکالی ندارد اگر که وقفه‌ای در کار خود ایجاد کنید
 
 کار کردن به صورت اوپن سورس برای شما شادی آورد. شاید اکنون باعث شده است شما احساس انزواطلبی داشته باشید یا احساس گناه کنید.
@@ -289,7 +275,6 @@ related:
 
 فاصله گرفتن، فقط منحصر به تعطیلات می‌شود. اگر نمی‌خواهید آخر هفته‌ یا در ساعات کاری، پروژه‌های اوپن سورس انجام دهید، این را به اطلاع دیگران برسانید تا بدانند که در آن اوقات مزاحم شما نشوند.
 
-
 ## ابتدا به فکر خودتان باشید!
 
 نگهداری یک پروژه‌ی محبوب به مهارت‌های متفاوتی در مقایسه با مهارت‌های مراحل اولیه‌ی رشد نیاز دارد، اما به همان میزان پاداش بیشتری هم خواهد داشت. به عنوان یک نگهدارنده، شما باید مهارت‌های رهبری و شخصی در سطحی فرای دیگران داشته باشید. اگرچه مدیریت آن همیشه آسان نیست، اما تعیین مرزهای مشخص و تنها پذیرفتن آنچه که با آن راحت هستید به شما کمک می‌کند تا شاد، سرحال و کارآمد باشید.

From fbafb73112ef0ac3aba2f0df15faca0c97dee92c Mon Sep 17 00:00:00 2001
From: Iman Ghasrfakhri <ghasrfakhri@gmail.com>
Date: Thu, 5 Aug 2021 11:28:33 +0430
Subject: [PATCH 201/749] Remove Unneeded Spaces and new line

---
 _articles/fa/building-community.md | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md
index 906428112c8..54f26fbb2e0 100644
--- a/_articles/fa/building-community.md
+++ b/_articles/fa/building-community.md
@@ -16,7 +16,6 @@ related:
 
 یک انجمن پذیرا ، یک نوع سرمایه گذاری برای شهرت و آینده پروژه تان است. اگر پروژه تان در حال آغاز کسب مشارکتهای اولیه اش است، با اعطای یک تجربه مثبت به مشارکت کننده های اولیه شروع کنید، و برای آنها به عقب برگشتن را ساده سازید
 
-
 ### کاری کنید تا افراد احساس پذیرفته شدن داشته باشند
 
 یک راه برای تفکر درباره انجمن پروژه تان از طریق آنچه مایک مک کویید آن را [قیف مشارکت کننده](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) می نامد میسر است.
@@ -95,7 +94,7 @@ related:
 
 اولین دلیل به خاطر مشارکت کنندگان است. به افراد کمک کنید تا همدیگر را بشناسند. افراد دارای منافع مشترک، بطور اجتناب ناپذیری می خواهند که محلی برای گفتگو درباره آن منافع داشته باشند. و وقتی ارتباطات علنی و قابل دسترس باشد، هر کسی می تواند آرشیوهای گذشته را بخواند تا به مشارکت خود شتاب بخشد. 
 
-دلیل دوم به خاطر خود شما است. اگر شما به افراد محل عمومی برای صحبت درباره پروژه تان ندهید، آنها احتمالاً با شما مستقیماً تماس خواهند گرفت. در شروع، ظاهراً ساده است که به پیامهای خصوصی  با موضوع « فقط اینبار»پاسخ دهید. اما در طول زمان مخصوصاً اگر پروژه تان معروف شود، شما کلافه خواهید شد.  در برابر وسوسه ارتباط برقرار کردن با افراد درباره پروژه تان بطور خصوصی مقاومت کنید. در عوض آنها را به یک کانال عمومی معین هدایت کنید.
+دلیل دوم به خاطر خود شما است. اگر شما به افراد محل عمومی برای صحبت درباره پروژه تان ندهید، آنها احتمالاً با شما مستقیماً تماس خواهند گرفت. در شروع، ظاهراً ساده است که به پیامهای خصوصی  با موضوع « فقط اینبار»پاسخ دهید. اما در طول زمان مخصوصاً اگر پروژه تان معروف شود، شما کلافه خواهید شد. در برابر وسوسه ارتباط برقرار کردن با افراد درباره پروژه تان بطور خصوصی مقاومت کنید. در عوض آنها را به یک کانال عمومی معین هدایت کنید.
 
 ارتباطات عمومی می تواند در حقیقت هدایت کردن مردم برای باز کردن یک موضوع به جای ایمیل مستقیم یا اظهار نظر کردن روی وبلاگ‌تان باشد. همچنین شما می توانید یک لیست مِیلی داشته باشید، یا یک حساب توییتر، Slack یا کانال IRC برای افراد راه بیاندازید تا درباره پروژه تان گفتگو کنند. یا همه موارد بالا را با هم اعمال کنید!
 
@@ -141,7 +140,7 @@ related:
 
 شما هرگز با اکثر افرادی که وارد پروژه تان می شوند تعامل نخواهید کرد. شاید مشارکتهایی وجود داشته باشد که آنها را دریافت نکرده اید چون برخی از افراد نمی دانند از کجا باید مشارکت خود را شروع کنند. حتی کلمات کمی وجود دارند که با آن می توان افراد را از ترک کردن پروژه تان به خاطر اشباع شدن بازداشت.
 
-برای مثال، در اینجا ما [رهنمودهای مشارکت](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) پروژه [روبینیوس]https://github.com/rubinius/rubinius/) را می آوریم:
+برای مثال، در اینجا ما [رهنمودهای مشارکت](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) پروژه [روبینیوس](https://github.com/rubinius/rubinius/) را می آوریم:
 
 > ما می خواهیم که کار خود را با قدردانی از شما برای استفاده از روبینیوس شروع کنیم. این پروژه یک کار عاشقانه است و ما از همه کاربرانی که باگها را معرفی می کنند، عملکردها را بهبود می دهند و به مستندسازی کمک می کنند، قدردانی می کنیم. هر مشارکتی مهم است پس از شما برای مشارکت سپاسگزاری می کنیم. اینکه گفته می شود اینجا رهنمودهای کمی وجود دارند که ما از شما بخواهیم تا از آنها پیروی کنید، می تواند باعث موفقیت رسیدگی به موضوعتان شود.
 
@@ -161,7 +160,6 @@ related:
 
 * **در برابر رفع باگ های ( غیرسرنوشت ساز) ساده مقاومت کنید:** در عوض از آنها به عنوان فرصتهایی برای پذیرش مشارکت کنندگان جدید استفاده کنید، یا شخصی که تمایل به مشارکت دارد، را راهنمایی کنید. شاید در اول غیرطبیعی به نظر برسد، اما سرمایه گذاری‌تان در طول زمان بازدهی‌اش را به تدریج بدست خواهد داد. برای مثال، @michaeljoseph از یک مشارکت کننده خواست تا درخواست Pull خود را درباره موضوع [Cookiecutter](https://github.com/audreyr/cookiecutter) به جای تعمیر آن توسط خودش ارائه دهد.
 
-
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
 * **یک فایل مشارکت کننده یا مولف در پروژه تان را شروع کنید** تا همه افرادی که به پروژه تان کمک می کردند مانند [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) را لیست کنید.
@@ -242,7 +240,6 @@ related:
 
 مباحثات مادامی که فعالانه به سوی راه حل سوق می یابند را تشویق کنید. اگر واضح است که مکالمه بی فروغ شده یا به خارج از موضوع هدایت شده، گفتگوها دارد شخصی می شود یا افراد وارد بحثهای جزئی و حاشیه ای می شوند، زمان آن فرا رسیده که به مباحثات خاتمه دهید.
 
-
 اجازه دادن به این مکالمات که همچنان ادامه یابد نه تنها برای موضوع تحت بررسی بد است بلکه برای سلامت انجمن تان نیز بد است. این کار پیامی می فرستد مبنی بر اینکه این نوع مکالمات مجاز هستند یا حتی انجام آنها مورد تشویق قرار می گیرد و در نتیجه می تواند روحیه افراد را از مطرح کردن و حل کردن موضوعات آتی تضعیف کند.
 
 با ذکر هر نکته توسط دیگران یا خودتان، از خود بپرسید که _«چطور این نکته ما را به راه حل نزدیکتر می کند؟»_
@@ -267,7 +264,7 @@ related:
 
 اگر موضوع ، نیازهای گسترده تر انجمن تان را متجلی نمی سازد، شما شاید نیاز به تایید نگرانی های افراد کمی از انجمن تان داشته باشید. اگر این یک موضوع تکرار شونده بدون یک راه حل واضح باشد، آنها را به مباحثات قبلی درباره این موضوع ارجاع دهید و موضوع را ببندید.
 
-###  راهگشای انجمن تان را شناسایی کنید
+### راهگشای انجمن تان را شناسایی کنید
 
 با یک نگرش خوب و ارتباطات واضح، اکثر شرایط دشوار قابل حل هستند. البته حتی در مکالمه سودمند، می تواند یک تفاوت در عقیده درباره چگونگی پیشرفت رویه ها وجود داشته باشد. در این موارد، یک فرد یا گروه از افرادی را شناسایی کنید که می توانند به عنوان رهگشا عمل کنند.
 

From 3e5a7624f32103ab9e4af717b74f874a4bef6ab8 Mon Sep 17 00:00:00 2001
From: Iman Ghasrfakhri <ghasrfakhri@gmail.com>
Date: Thu, 5 Aug 2021 11:32:23 +0430
Subject: [PATCH 202/749] Remove unneeded spaces and new lines

---
 _articles/fa/code-of-conduct.md | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/_articles/fa/code-of-conduct.md b/_articles/fa/code-of-conduct.md
index 563ad07cbd4..8fe34e93cf7 100644
--- a/_articles/fa/code-of-conduct.md
+++ b/_articles/fa/code-of-conduct.md
@@ -12,7 +12,7 @@ related:
 
 ## چرا به منشور اخلاقی نیاز داریم؟
 
-منشور اخلاقی سندی است که انتظارات مربوط به رفتار را برای شرکت‌کنندگان پروژه تعیین می‌کند.   تصویب و اجرای منشور اخلاقی می‌تواند به ایجاد جو اجتماعی مثبت و سازنده برای انجمن شما کمک کند.
+منشور اخلاقی سندی است که انتظارات مربوط به رفتار را برای شرکت‌کنندگان پروژه تعیین می‌کند. تصویب و اجرای منشور اخلاقی می‌تواند به ایجاد جو اجتماعی مثبت و سازنده برای انجمن شما کمک کند.
 
 منشور اخلاقی نه تنها از شرکت‌کنندگان پروژه بلکه از شما هم محافظت می‌کند. اگر شما از پروژه‌ای نگهداری می‌کنید، ممکن است متوجه شده باشید که نگرش‌های مخرب از طرف دیگر شرکت‌کنندگان باعث می‌شود در طول کار از کار خود خسته یا ناراضی شوید.
 
@@ -72,7 +72,6 @@ related:
 
 قبل از عکس‌العمل نشان دادن، زمان کافی را برای فهمیدن کامل ماجرا صرف کنید. نظرات و گفتگوهای مربوط به گذشتۀ شخص را بررسی کنید تا آن‌ها را بهتر بشناسید و  متوجه شوید چرا ممکن است چنین رفتاری از آن‌ها سر بزند. سعی کنید دیدگاه‌های دیگری را غیر از دیدگاه‌های خودتان دربارۀ این فرد و رفتار او جمع‌آوری کنید.
 
-
 <aside markdown="1" class="pquote">
   وارد بحث و جدل با شخص نشوید. قبل از اتمام شدن رسیدگی به موضوع مورد بحث، وارد موضوع دیگر و رسیدگی به شخص دیگری نشوید. بر آنچه که نیاز هست تمرکز کنید.
   <p markdown="1" class="pquote-credit">
@@ -86,7 +85,6 @@ related:
 
 وقتی کسی گزارشی منوط بر تخلف در منشور اخلاقی می‌دهد، رسیدگی به آن وظیفۀ شماست و نه خود او. گاهی اوقات، فرد گزارش‌دهنده با افشای این اطلاعات، آیندۀ شغلی، اعتبار یا ایمنی خود را ممکن است در معرض خطر بزرگی قرار دهد. وادار کردن آن‌ها به مقابله کردن با فرد مزاحم و خاطی می‌تواند فرد گزارش‌دهنده را در موقعیتی مخاطره‌آمیز قرار دهد. شما باید شخصا ارتباط مستقیم با فرد خاطی مورد نظر را مدیریت کنید، مگر اینکه فرد گزارش‌دهنده صریحاً خلاف آن را درخواست کند.
 
-
 چند روش وجود دارد که شما می‌توانید با استفاده از آن‌ها با موارد نقض منشور اخلاقی برخورد کنید:
 
 * **به شخص مورد نظر ترجیحاً به طور مشخص‌ و واضح اخطار عمومی دهید** و توضیح دهید که چگونه رفتار او بر دیگران تأثیر منفی می‌گذارد. اخطار به صورت عمومی به بقیۀ افراد انجمن این پیام را می‌رساند که منشور اخلاقی را جدی می‌گیرید. در مکالمه‌های خود خوش‌برخود باشید ولی جدی بمانید.
@@ -107,11 +105,10 @@ related:
 
 شما به عنوان نگهدارنده، دستورالعمل‌هایی را برای انجمن خود تعیین می‌کنید و آن دستورالعمل‌ها را مطابق با قوانین مندرج در منشور اخلاقی اجرا می‌کنید. این به معنای جدی گرفتن هر گونه گزارش مربوطی به نقض منشور اخلاقی است. گزارش فرد گزارش‌دهنده باید کاملا جامع و منصفانه بررسی شود. اگر تشخیص دادید رفتاری که آن‌ها گزارش داده‌اند، نقض منشور اخلاقی نیست، این مسئله را به وضوح با آن‌ها در میان بگذارید و توضیح دهید که چرا در این زمینه اقدامی نمی‌کنید. عکس‌العملی که نشان می‌دهند به خودشان مربوط است: باید رفتاری که آن‌ها با آن روبرو بوده‌اند را تحمل کنند یا مشارکت‌شان در انجمن را متوقف سازند.
 
-گزارش رفتاری که در واقع منشور اخلاقی شما را نقض نمی‌کند، همچنان نشان‌دهندۀ مشکلی در انجمن شما است و شما باید این مشکل بالقوه را بررسی کرده و چاره‌ای برای آن پیدا کنید.  که این ممکن است شامل بازنگری در منشور اخلاقی برای روشن ساختن رفتار قابل‌قبول یا صحبت با شخصی باشد که رفتار وی گزارش شده است و شما باید به فرد بگویید که اگرچه منشور اخلاقی را نقض نکرده‌اند، اما دارند در لبۀ آنچه که از آن‌ها انتظار می‌رود راه می‌روند و موجب ناراحتی در برخی از شرکت‌کنندگان شده‌اند.
+گزارش رفتاری که در واقع منشور اخلاقی شما را نقض نمی‌کند، همچنان نشان‌دهندۀ مشکلی در انجمن شما است و شما باید این مشکل بالقوه را بررسی کرده و چاره‌ای برای آن پیدا کنید. که این ممکن است شامل بازنگری در منشور اخلاقی برای روشن ساختن رفتار قابل‌قبول یا صحبت با شخصی باشد که رفتار وی گزارش شده است و شما باید به فرد بگویید که اگرچه منشور اخلاقی را نقض نکرده‌اند، اما دارند در لبۀ آنچه که از آن‌ها انتظار می‌رود راه می‌روند و موجب ناراحتی در برخی از شرکت‌کنندگان شده‌اند.
 
 موضوع مهم این است که شما به عنوان یک نگهدارنده، باید استانداردهای رفتار قابل‌قبول را تعیین و عملیاتی کنید. شما توانایی شکل دادن به ارزش‌های اجتماعی پروژه را دارید و شرکت‌کنندگان انتظار دارند که شما این ارزش‌ها را به صورت منصفانه و یکسان اجرا کنید.
 
-
 ## ترغیب‌کنندۀ رفتاری باشید که می‌خواهید در دنیا آن را مشاهده کنید 🌎
 
 هنگامی که یک پروژه خصمانه یا ناخوشایند به نظر می‌رسد، حتی اگر فقط یک نفر باشد که رفتار او غیرقابل‌تحمل باشد، ممکن است مشارکت‌کنندگان بیشتری را از دست بدهید که حتی ممکن است بعضی از آن‌ها را هرگز ملاقات نکرده باشید. اتخاذ یا اجرای منشور اخلاقی همیشه ساده نیست، اما ایجاد فضایی دوستانه به رشد انجمن شما کمک می کند.

From 12161d858577cb1a1c5fe33d77826e42011fc4eb Mon Sep 17 00:00:00 2001
From: Iman Ghasrfakhri <ghasrfakhri@gmail.com>
Date: Thu, 5 Aug 2021 11:35:21 +0430
Subject: [PATCH 203/749] Remove unneeded spaces and new lines

---
 _articles/fa/finding-users.md | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/_articles/fa/finding-users.md b/_articles/fa/finding-users.md
index b45a68c823f..86da3a98df0 100644
--- a/_articles/fa/finding-users.md
+++ b/_articles/fa/finding-users.md
@@ -22,7 +22,6 @@ related:
 
 به یاد داشته باشید به این دلیل که پروژه‌ی شما مشکلی را برای کاربران برطرف می‌کند؛ افراد به عنوان کاربر به پروژه‌ی شما ملحق می‌شوند و در نهایت به عنوان یک مشارکت‌کننده معرفی می‌شوند. همانطور که درباره‌ی پیام و ارزش پروژه‌‌ی خود فکر می‌کنید، سعی کنید آن‌ها را از دریچه‌ی آنچه که کاربران و مشارکت‌کنندگان می‌خواهند نظاره کنید.
 
-
 به عنوان مثال، @robb از کدها استفاده می‌کند تا به طور واضح اهمیت پروژه‌ی خود را نشان دهد؛ نقشه‌نگاری [Cartography](https://github.com/robb/Cartography) مفید واقع می‌شود:
 
 ![Cartography README](/assets/images/finding-users/cartography.jpg)
@@ -40,11 +39,10 @@ related:
 
 طوری باشد که با اشاره‌ای کوچک، مردم پروژه‌ی شما را به یاد بیاورند.
 
-**برای توسعه‌ی پروژه‌ی خود، کاملا بر کار خویش آگاه و از آن اطمینان داشته باشید. ** یک آدرس توییتری، آدرس GitHub یا کانال IRC راهی آسان برای مشایعت و هدایت افراد به سمت پروژه‌ی خودتان است. این رسانه‌ها همچنین به اجتماع در حال رشد پروژه‌ی شما، محلی برای تجمع و تبادل نظر می‌دهند.
+**برای توسعه‌ی پروژه‌ی خود، کاملا بر کار خویش آگاه و از آن اطمینان داشته باشید.** یک آدرس توییتری، آدرس GitHub یا کانال IRC راهی آسان برای مشایعت و هدایت افراد به سمت پروژه‌ی خودتان است. این رسانه‌ها همچنین به اجتماع در حال رشد پروژه‌ی شما، محلی برای تجمع و تبادل نظر می‌دهند.
 
 اگر هنوز مایل به راه‌اندازی رسانه‌هایی برای پروژه‌ی خودتان نیستید، در همه‌ی کارهایی که انجام می‌دهید Twitter یا GitHub خود را ترویج دهید. توسعه و تبلیغ Twitter یا GitHub به مردم این امکان را می‌دهد تا با شما در ارتباط باشند یا کارهای شما را دنبال کنند. اگر در جلسه یا رویدادی صحبت می‌کنید، اطمینان حاصل کنید تا اطلاعات تماس شما در مشخصات شما یا اسلایدها آمده باشد.
  
-
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
   اشتباهی که در همان روزهای اولیه مرتکب به آن شدم، افتتاح نکردن یک حساب توییتر برای پروژه بود. توییتر راهی عالی برای به روز نگه داشتن مردم در مورد پروژه و همچنین نشان دادن پروژه به آدم‌های جدید است.
@@ -78,14 +76,13 @@ related:
 ببینید آیا می‌توانید روش‌هایی برای به اشتراک گذاشتن پروژه خود به صورت متناسبی پیدا کنید:
 
 * **با پروژه‌ها و انجمن‌های اوپن سورس مرتبط و مدنظرتان آشنا شوید.** گاهی اوقات، لازم نیست که مستقیماً پروژه‌ی خود را تبلیغ کنید. اگر پروژه‌ی شما برای متخصصین علم داده که از پایتون استفاده می‌کنند عالی است، با انجمن علوم داده‌ی پایتون ملاقات کنید و آشنا شوید. هنگامی که مردم با شما آشنا شوند، فرصت‌ها به صورت خودکار و طبیعی برای بحث و گقت و گو و به اشتراک گذاشتن کارهای شما بوجود می‌آید.
-* **افرادی که مشکلاتی دارند و پروژه‌ی شما، آن مشکلات را حل و فصل می‌کند را پیدا کنید. ** از طریق تالارهای گفتگوی (فروم‌ها) مرتبط، به جستجوی افرادی که می‌توانند مخاطبانِ هدفِ پروژه‌ی شما باشند، بپردازید. به سوالات آن‌ها پاسخ دهید و در زمانی مناسب، روشی مدبرانه تعبیه کنید تا پروژه‌ی خود را به عنوان یک راه‌حل پیشنهاد دهید.
+* **افرادی که مشکلاتی دارند و پروژه‌ی شما، آن مشکلات را حل و فصل می‌کند را پیدا کنید. **از طریق تالارهای گفتگوی (فروم‌ها) مرتبط، به جستجوی افرادی که می‌توانندمخاطبانِ هدفِ پروژه‌ی شما باشند، بپردازید. به سوالات آن‌ها پاسخ دهید و در زمانی مناسب، روشی مدبرانه تعبیه کنید تا پروژه‌ی خود را به عنوان یک راه‌حل پیشنهاد دهید.
 * **از انتقادات و پیشنهادات روی‌گردان نباشید.** خود و کارهایتان را به مخاطب‌هایی مرتبط و متناسب که به کار شما علاقه دارند، معرفی کنید. مخاطبان خود را بشناسید و کسانی که از پروژه‌ی شما سود و منفعت حاصل می‌کنند را مشخص کنید. سعی کنید این جمله را کامل کنید:  «من فکر می‌کنم پروژه‌ی من واقعاً به X، که در تلاش برای انجام کار Y است، کمک خواهد کرد». به جای اینکه صرفاً فقط کار خود را تبلیغ کنید، به بازخورد دیگران گوش دهید و پاسخگو باشید.
 
 به طور کلی، به کمک کردن به دیگران تمرکز کنید قبل از اینکه چیزهایی را در عوض درخواست کنید؛ چونکه که اگر هر کسی بخواهد پروژه‌های خودش را به صورت آنلاین تبلیغ کند، همهمه و شلوغی زیادی بر پا خواهد شد. برای اینکه در جمعی شناخته شوید، سعی کنید خود را به دیگران معرفی کنید و نه اینکه فقط آنچه که می‌خواهید را بازگو کنید.
 
 اگر کسی به فعالیت‌های اولیه‌ی شما پاسخی نداد و یا توجه نکرد، ناامید نشوید! اکثر راه‌اندازی‌های پروژه‌ها، فرآیندهایی هستند که باید چندین و چندین بار تکرار شوند که ممکن است ماه‌ها یا سال‌ها به طول انجامد. اگر بار اول پاسخی دریافت نکردید، تاکتیک دیگری را امتحان کنید یا ابتدا به دنبال روش‌هایی برای افزودن ارزش به کار دیگران باشید. راه‌اندازی و توسعه‌ی پروژه، به وقت و تعهد نیاز دارد.
 
-
 ## هر جا که مخاطبان شما بودند، شما هم به آنجا بروید (آفلاین)
 
 ![Public speaking](/assets/images/finding-users/public_speaking.jpg)

From 695c3bd76d601b4ac38a2c97e5ee4c6d0e614263 Mon Sep 17 00:00:00 2001
From: Iman Ghasrfakhri <ghasrfakhri@gmail.com>
Date: Thu, 5 Aug 2021 11:37:25 +0430
Subject: [PATCH 204/749] Remove unneeded spaces and new lines

---
 _articles/fa/getting-paid.md | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/_articles/fa/getting-paid.md b/_articles/fa/getting-paid.md
index ddb05d87f00..ca2cc68fb61 100644
--- a/_articles/fa/getting-paid.md
+++ b/_articles/fa/getting-paid.md
@@ -40,7 +40,6 @@ related:
 
 حفظ پروژه‌های پرطرفدار، می‌تواند مسئولیت سنگینی را بر روی دوش افراد بگذارد، می‌تواند بجای چند ساعت در ماه 10 یا 20 ساعت در هفته را به خود اختصاص دهد.
 
-
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
   از هر نگهدارنده‌ی پروژه‌ی متن بازی که خواستید بپرسید، و آن‌ها در مورد واقعیت میزان کاری که برای مدیریت یک پروژه انجام می‌دهند، به شما می‌گویند. شما موکل‌هایی خواهید داشت. مسائلی را برای آن‌ها حل و فصل می‌کنید. ویژگی‌های جدیدی را خلق می‌کنید. و این‌ها، زمانی زیادی را از شما می‌طلبند.
@@ -49,7 +48,7 @@ related:
   </p>
 </aside>
 
-همچنین کارهای با دستمزد، این امکان برای افراد از اقشار مختلف جامعه را فراهم می‌آورد تا مشارکت‌های قابل‌توجه و معناداری انجام دهند. برخی از افراد، به سبب وضعیت مالی کنونی‌شان، بدهی یا خانواده یا سایر تعهدات، امکان مشارکت بدون دستمزد در پروژه‌های متن باز را ندارند. این بدان معناست که جهان هرگز مشارکت افراد مستعدی را که توانایی مالی برای مشارکت داوطلبانه را ندارند، نمی‌بیند.  همانطور که @ashedryden [گفته است](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)، پیامدهایی اخلاقی در این میان وجود دارد، زیرا کسانی که از قبل در زندگی دارای مزایایی هستند، شانس بیشتری در کارهایی که انجام می‌شود دارند، درنتیجه بر اساس مشارکت‌های داوطلبانه‌ی خود مزایای بیشتری کسب می‌کنند، در حالی که سایر افرادی که قادر به داوطلب شدن نیستند، فرصت‌های آتی را از دست می‌دهند، که این عدم تنوع را در اجتماع کنونی (community) متن باز گسترش می‌دهد.
+همچنین کارهای با دستمزد، این امکان برای افراد از اقشار مختلف جامعه را فراهم می‌آورد تا مشارکت‌های قابل‌توجه و معناداری انجام دهند. برخی از افراد، به سبب وضعیت مالی کنونی‌شان، بدهی یا خانواده یا سایر تعهدات، امکان مشارکت بدون دستمزد در پروژه‌های متن باز را ندارند. این بدان معناست که جهان هرگز مشارکت افراد مستعدی را که توانایی مالی برای مشارکت داوطلبانه را ندارند، نمی‌بیند. همانطور که @ashedryden [گفته است](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)، پیامدهایی اخلاقی در این میان وجود دارد، زیرا کسانی که از قبل در زندگی دارای مزایایی هستند، شانس بیشتری در کارهایی که انجام می‌شود دارند، درنتیجه بر اساس مشارکت‌های داوطلبانه‌ی خود مزایای بیشتری کسب می‌کنند، در حالی که سایر افرادی که قادر به داوطلب شدن نیستند، فرصت‌های آتی را از دست می‌دهند، که این عدم تنوع را در اجتماع کنونی (community) متن باز گسترش می‌دهد.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
@@ -102,7 +101,6 @@ related:
 
 بسته به شرایط شخصی خودتان، می‌توانید به طور مستقل برای تأمین هزینه‌های کار متن باز خود، پول جمع کنید. به عنوان مثال:
 
-
 * نرم‌افزار متن باز @Homebrew ([و بسیاری از نگهدارندگان و سازمان‌ها](https://github.com/sponsors/community))، کار خودشان را از طریق حامیان مالی [GitHub](https://github.com/sponsors) تأمین می‌کنند
 * @gaearon کار خود در [Redux](https://github.com/reactjs/redux) را از طریق کمپین سرمایه‌گذاری جمعی «Patreon» تأمین مالی کرد
 * @andrewgodwin از [طریق کمپین Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) کارش در مورد مایگریشن‌های دیتابیس «Django» را تأمین مالی کرد. (Schema Migration)
@@ -143,7 +141,7 @@ related:
 برخی از موسسات و شرکت‌های نرم‌افزاری، کمک‌هزینه‌های مالی برای کارهای متن باز ارائه می‌دهند. گاهی اوقات، بدون ایجاد نهاد قانونی‌ای برای پروژه، کمک‌هزینه‌های مالی به افراد حقیقی پرداخت می‌شود.
 
 * **نرم‌افزار [Read the Docs](https://github.com/rtfd/readthedocs.org)**، از پشتیبانی بخش متن باز [Mozilla](https://www.mozilla.org/en-US/grants/)، کمک‌هزینه دریافت کرد
-* **بودجه‌ی کار [OpenMRS](https://github.com/openmrs)** توسط [Stripe’s Open Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) تأمین شد
+* **بودجه‌ی کار [OpenMRS](https://github.com/openmrs)** توسط [Stripe's Open Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) تأمین شد
 * **[Libraries.io](https://github.com/librariesio)** از موسسه‌ی [Sloan](https://sloan.org/programs/digital-technology) کمک‌هزینه‌ دریافت کرد
 * **موسسه‌ی نرم‌افزار پایتون (Python Software Foundation)**، کمک‌های مالی برای کارهای مرتبط با پایتون ارائه می‌دهد
 

From 4a37677860572dba1c9da5168c437c18bd990798 Mon Sep 17 00:00:00 2001
From: Iman Ghasrfakhri <ghasrfakhri@gmail.com>
Date: Thu, 5 Aug 2021 11:45:16 +0430
Subject: [PATCH 205/749] Remove unneeded spaces, new lines and fix ref

---
 _articles/fa/how-to-contribute.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 71ff96fd79c..86532f9c2d1 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -132,7 +132,7 @@ related:
 
 * کدنویسی سایر افراد را بررسی کنید
 * برای نحوه‌ی استفاده‌ی یک پروژه‌ی متن باز، مطلب آموزشی بنویسید
-* یک مشارکت کننده دیگر که می‌شناسید را پیشنهاد دهید، [مثل کاری که @ereichert در Rust برای @bronzdoc کرد][like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666).
+* یک مشارکت کننده دیگر که می‌شناسید را پیشنهاد دهید، [مثل کاری که @ereichert در Rust برای @bronzdoc کرد](https://github.com/rust-lang/book/issues/123#issuecomment-238049666).
  
 ### لازم نیست فقط روی پروژه‌های نرم‌افزاری وقت صرف کنید!
 
@@ -245,6 +245,7 @@ related:
 **پروژه‌ی متن باز به صورت فعالانه‌ای حضور مشارکت‌کننده‌ها را قبول می‌کند**
 
 نگاهی به کامیت های اخیر در شاخه اصلی بیاندازید. در گیت‌هاب این این مورد در صفحه اصلی مخزن دیده می‌شود.
+
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
@@ -488,7 +489,7 @@ related:
 * در حین ارسال ها **به مسائل (issue) مرتبط ارجاع دهید** یا در کامنت مربوط به تغییرات جدید به مستندات مربوطه اشاره کنید.(مثال: این تغییر مشکل مطرح شده در مسئله شماره 37 را برطرف می‌کند.)
 * اگر تغییرات شما حاوی تفاوت‌های HTML/CSS باشد، **تصاویر مربوط به قبل و بعد آن را اضافه کنید**. تصاویر را وارد بدنه‌ی درخواست ادغام کنید و رها کنید.
 * تغییرات‌تان را **تست کنید!** تغییرات خود را در برابر تست‌های موجود اجرا کنید و در صورت لزوم تغییرات جدیدی خلق کنید. اگر حتی تست‌هایی تعریف نشده بود، مطمئن شوید تغییرات‌تان پروژه‌ی موجود شما را خراب نکند.
-* با تمام توانایی‌تان ** الگوها را رعایت کرده و مطابق سبک پروژه مشارکت کنید**. این توانایی می‌تواند به معنای استفاده از تورفتگی‌ها، نقطه ویرگول (semi-colons)، یا کامنت‌های متفاوتی باشد که شما در مخزن‌تان خودتان دارید. این کار ادغام مسئول‌نگهداری را ساده می‌کند، دیگران هم متوجه آن می‌شوند و می‌توانند آن را برای زمان‌های آتی حفظ کنند.
+* با تمام توانایی‌تان  **الگوها را رعایت کرده و مطابق سبک پروژه مشارکت کنید**. این توانایی می‌تواند به معنای استفاده از تورفتگی‌ها، نقطه ویرگول (semi-colons)، یا کامنت‌های متفاوتی باشد که شما در مخزن‌تان خودتان دارید. این کار ادغام مسئول‌نگهداری را ساده می‌کند، دیگران هم متوجه آن می‌شوند و می‌توانند آن را برای زمان‌های آتی حفظ کنند.
 
 اگر این اولین درخواست ادغام شماست، فیلم آموزشی [Make a Pull Request](http://makeapullrequest.com/) که @kentcdodds آن را خلق کرده، بررسی کنید. شما همچنین می‌توانید از [Make a Pull Request](https://github.com/Roshanjossey/first-contributions) که توسط @Roshanjossey ایجاد شده به عنوان یک محزن تمرینی برای اولین تجربه خود استفاده کنید.
 
@@ -518,7 +519,6 @@ related:
 
 اگر برای برطرف کردن مسائل پروژه دیگر زمان کافی ندارید (به عنوان نمونه، اگر مکالمه‌ی شما ماه‌ها طول کشید، و اکنون شرایط شما تغییر کند)، اجازه دهید مسئول‌نگهداری پروژه از این موضوع مطلع شود تا منتظر جواب شما نباشد. حتی کسی دیگری ممکن است جای شما را بگیرد.
 
-
 ### 👎 درخواست مشارکت‌تان پذیرفته نشد
 
 در پایان، درخواست مشارکت‌تان ممکن است پذیرفته شود یا نشود. هرچند، در صورت پذیرفته نشدن درخواست‌تان امیدواریم زمان زیادی روی آن صرف نکرده باشید. اگر مطمئن نیستید که چرا درخواست‌تان پذیرفته نشده، کاملاً معقولانه است که برای درخواست بازخورد و شفاف‌سازی از مسئول‌نگهداری جواب بخواهید. در نهایت، با احترام به تصمیم آن‌ها نباید خشمگین و عصبانی شوید. همیشه می‌توانید پروژه‌ی دیگری انتخاب کنید و اگر هم نمی‌خواهید در پروژه‌ای مشرکت کنید، می‌توانید پروژه‌ی خودتان را داشته باشید!

From 7c4723be47527704aa9705811b27d247fb80e529 Mon Sep 17 00:00:00 2001
From: Iman Ghasrfakhri <ghasrfakhri@gmail.com>
Date: Thu, 5 Aug 2021 11:50:36 +0430
Subject: [PATCH 206/749] Remove unneeded spaces and new lines

---
 _articles/fa/leadership-and-governance.md | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/_articles/fa/leadership-and-governance.md b/_articles/fa/leadership-and-governance.md
index 7c105727bc2..2aa7c8a70b4 100644
--- a/_articles/fa/leadership-and-governance.md
+++ b/_articles/fa/leadership-and-governance.md
@@ -95,8 +95,7 @@ related:
 
 سه ساختار نظارتی متداول در ارتباط با پروژه‌های متن باز وجود دارد.
 
-
-* **BDFL** مخفف «دیکتاتور خیرخواه جاویدان» است ( .(Benevolent Dictator for Lifeتحت این ساختار، یک نفر (معمولاً نویسنده‌ی اولیه‌ی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را می‌زند. [Python](https://github.com/python)، نمونه‌ای موثق در این مورد است. پروژه‌های کوچک‌تر احتمالاً به طور پیش‌فرض به صورت «BDFL» هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژه‌هایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقه‌بندی «BDFL» قرار گیرند
+* **BDFL** مخفف "Benevolent Dictator for Life" یا «دیکتاتور خیرخواه جاویدان» است تحت این ساختار،  یک نفر (معمولاً نویسنده‌ی اولیه‌ی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را می‌زند. [Python](https://github.com/python)، نمونه‌ای موثق در این مورد است. پروژه‌های کوچک‌تر احتمالاً به طور پیش‌فرض به صورت «BDFL» هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژه‌هایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقه‌بندی «BDFL» قرار گیرند
 
 
 * **Meritocracy:** (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماع‌ها، مفهومی منفی دارد و ساختار آن [دارای پیشینه‌ی پیچیده‌ی اجتماعی و سیاسی ](http://geekfeminism.wikia.com/wiki/Meritocracy).)است.) تحت ساختار «شایسته سالاری»، به مشارکت‌کنندگان فعال پروژه (کسانی که از «شایستگی» نشان می‌دهند) نقش تصمیم‌گیرندگی رسمی داده می‌شود. تصمیم‌‌ها، معمولاً براساس اجماع رای گرفته می‌شوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد «Apache»، به وجود آمد. تمامی پروژه‌های «Apache» بر اساس شایسته سالاری هستند. مشارکت‌ها فقط توسط افراد حقیقی صورت می‌گیرد؛ نه توسط یک شرکت.
@@ -118,7 +117,6 @@ related:
 
 اگر شما عضوی از شرکتی هستید که پروژه‌ای متن باز راه‌اندازی می‌کند، بد نیست قبل از راه‌اندازی، بحثی درون‌سازمانی درباره نحوه‌ی نگهداری شرکت و تصمیم‌گیری در مورد پیشرفت پروژه داشته باشید. همچنین بهتر است در مورد مسیری که شرکت شما در رابطه با پروژه پیش خواهد گرفت، به صورت علنی صحبت دهید.
 
-
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
  ما تیم‌های کوچکی را برای مدیریت پروژه‌ها در «GitHub» اختصاص می‌دهیم که در واقع در فیس‌بوک نیز بر روی آن‌ها کار می‌کنند. برای مثال، پروژه‌ی «React» توسط «React engineer»، اداره می‌شود.
@@ -157,4 +155,4 @@ related:
   </p>
 </aside>
 
-اگر پروژه‌ی شما رابطه‌ی نزدیکی با زبان یا اکوسیستم خاصی داشته باشد، ممکن است پیش‌زمینه‌ی نرم‌افزاری مرتبط با آن وجود داشته باشد که بتوانید با آن کار کنید. به عنوان مثال، [Python Software Foundation](https://www.python.org/psf/) از [PyPI](https://pypi.org/) پشتیبانی می‌کند، [Python package manager](https://www.python.org/psf/) و [Node.js Foundation](https://foundation.nodejs.org/) به [Express.js](https://expressjs.com/)، که مبتنی بر Node است، کمک می‌کند.
\ No newline at end of file
+اگر پروژه‌ی شما رابطه‌ی نزدیکی با زبان یا اکوسیستم خاصی داشته باشد، ممکن است پیش‌زمینه‌ی نرم‌افزاری مرتبط با آن وجود داشته باشد که بتوانید با آن کار کنید. به عنوان مثال، [Python Software Foundation](https://www.python.org/psf/) از [PyPI](https://pypi.org/) پشتیبانی می‌کند، [Python package manager](https://www.python.org/psf/) و [Node.js Foundation](https://foundation.nodejs.org/) به [Express.js](https://expressjs.com/)، که مبتنی بر Node است، کمک می‌کند.

From cc2a82d82f12db6ec504499bb4c99f6599d403e9 Mon Sep 17 00:00:00 2001
From: Iman Ghasrfakhri <ghasrfakhri@gmail.com>
Date: Thu, 5 Aug 2021 12:08:26 +0430
Subject: [PATCH 207/749] Remove unneeded spaces and new lines

---
 _articles/fa/legal.md | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index fe8c35ec5f4..7cd3a53f2e8 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -24,7 +24,6 @@ related:
 
 در آخر اینکه ممکن است پروژۀ شما وابستگی‌هایی با ملزومات مجوز داشته باشد که از آن‌ها اطلاع نداشته باشید. انجمن (community) پروژه یا سیاست‌های کارفرمایی شما نیز ممکن است پروژه را ملزم به استفاده از مجوز‌های متن باز خاصی بکند. در زیر دربارۀ آن توضیح می‌دهیم.
 
-
 ## آیا پروژه‌های عمومی «GitHub» متن باز محسوب می‌شوند؟
 
 هنگام ایجاد [پروژه‌ای جدید](https://help.github.com/articles/creating-a-new-repository/) در «GitHub»، این انتخاب را دارید که منبع را **خصوصی** یا **عمومی** مشخص کنید
@@ -39,7 +38,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] پیدا کنید.
+[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/).
 
@@ -67,9 +66,9 @@ related:
 
 * **آیا می‌خواهید پروژۀ شما مورد توجه کسب و کارهای بزرگ قرار بگیرد؟** کسب‌وکارهای بزرگ احتمالاً سریعا مجوز ثبت اختراع را از تمامی مشارکت‌کنندگان می‌خواهند. در این صورت، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) به درد شما و آن‌ها می‌خورد.
 
-* **آیا می‌خواهید پروژه شما مورد توجه مشارکت‌کنندگانی قرار بگیرد که نمی‌خواهند مشارکت‌های آن‌ها در نرم‌افزارهای متن بسته مورد استفاده قرار بگیرد؟** [GPLv3] یا (همچنین اگر آن‌ها تمایلی به مشارکت در خدمات متن بسته ندارند) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) به درد خواهد خورد.
+* **آیا می‌خواهید پروژه شما مورد توجه مشارکت‌کنندگانی قرار بگیرد که نمی‌خواهند مشارکت‌های آن‌ها در نرم‌افزارهای متن بسته مورد استفاده قرار بگیرد؟** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) یا (همچنین اگر آن‌ها تمایلی به مشارکت در خدمات متن بسته ندارند) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) به درد خواهد خورد.
 
-ممکن است **شرکت** شما در پروژه‌های متن باز، شرایط خاصی برای مجوزها داشته باشد. به عنوان مثال، ممکن است به مجوز اختیاری نیاز داشته باشد تا شرکت بتواند از پروژۀ شما در محصول متن بستۀ خود استفاده کند. یا ممکن است شرکت شما به یک مجوز کپی‌لفت قوی و یک توافق‌نامۀ همکاری اضافی نیاز داشته باشد (به زیر مراجعه کنید) تا فقط منحصرا شرکت شما بتواند از پروژه در نرم‌افزارهای متن بسته استفاده کند. یا ممکن است شرکت شما نیازها و شرایط خاصی در رابطه با استانداردها، مسئولیت‌های اجتماعی یا شفافیت داشته باشد، که هر یک از آن‌ها ممکن است به یک استراتژی خاص دیگری در ارتباط با مجوز نیاز داشته باشد. با [بخش حقوقی شرکت] خود در رابطه با این موارد صحبت کنید.
+ممکن است **شرکت** شما در پروژه‌های متن باز، شرایط خاصی برای مجوزها داشته باشد. به عنوان مثال، ممکن است به مجوز اختیاری نیاز داشته باشد تا شرکت بتواند از پروژۀ شما در محصول متن بستۀ خود استفاده کند. یا ممکن است شرکت شما به یک مجوز کپی‌لفت قوی و یک توافق‌نامۀ همکاری اضافی نیاز داشته باشد (به زیر مراجعه کنید) تا فقط منحصرا شرکت شما بتواند از پروژه در نرم‌افزارهای متن بسته استفاده کند. یا ممکن است شرکت شما نیازها و شرایط خاصی در رابطه با استانداردها، مسئولیت‌های اجتماعی یا شفافیت داشته باشد، که هر یک از آن‌ها ممکن است به یک استراتژی خاص دیگری در ارتباط با مجوز نیاز داشته باشد. با [بخش حقوقی شرکت](#what-does-my-companys-legal-team-need-to-know) خود در رابطه با این موارد صحبت کنید.
 
 هنگام ایجاد پروژه جدید در «GitHub»، به شما امکان انتخاب نوع مجوز داده می‌شود. انتخاب یکی از مجوزهایی که در بالا ذکر شد، پروژۀ «GitHub» شما را متن باز می‌کند. اگر مایل به دیدن گزینه‌های دیگه‌ای هستید، [choosealicense.com](https://choosealicense.com) را بررسی کنید تا مجوز مناسب‌تان را پیدا کنید حتی اگر برای [نرم‌افزار](https://choosealicense.com/non-software/) نباشد.
 
@@ -95,7 +94,6 @@ related:
 
 همچنین، با افزودن «تشریفات اداری» که به عقیدۀ برخی غیرضروری می‌باشد و فهم آن سخت یا ناعادلانه است (وقتی که ذی‌نفعان توافق‌نامه حقوق و مزایای بیشتری از مشارکت‌کنندگان یا عموم مردمی که کارهایی در پروژه‌ی متن باز انجام می‌دهند، به دست می‌آورند)؛ به همین خاطر ممکن است یک توافق‌نامه‌ی همکاری اضافی غیرمنصفانه نسبت به انجمن پروژه تلقی شود.
 
-
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     ما «توافق‌نامه مجوز مشارکت‌کننده» را برای «Node.js» حذف کردیم. انجام این کار موانع ورود مشارکت‌کنندگان به Node.js را کاهش می‌دهد و در نتیجه میزان مشارکت‌کنندگان را گسترش می‌دهد.
@@ -106,11 +104,9 @@ related:
 
 برخی از شرایطی که ممکن است بخواهید یک توافق‌نامه‌ی همکاری اضافی را برای پروژۀ خود در نظر بگیرید، شامل این موارد می‌شود:
 
-* وکلای شما می‌خواهند که تمامی مشارکت‌کنندگان به طور صریح شرایط مشارکت (آنلاین یا آفلاین) را بپذیرند، شاید به این دلیل که فکر می‌کنند مجوز متن باز به خودی خود کافی نیست (با اینکه هست!). اگر این تنها نگرانی است، توافق‌نامه‌ی مشارکت‌کننده که مجوز پروژۀ متن باز را تأیید می‌کند باید کافی باشد. [توافق‌نامۀ مجوز مشارکت‌کنند‌ۀ حقیقی jQuery] نمونۀ خوبی از توافق‌نامۀ همکاری اضافی خفیف است.
-
 * شما یا وکیل‌هاتان بخواهید توسعه‌دهندگان نشان دهند که هر تعهدی که روی آن کار می‌کنند مجاز است. الزام [گواهی مبدا توسعه‌دهنده](https://developercertificate.org/) برای این است که چه تعداد پروژه به این صورت هستند. به عنوان مثال، انجمن «Node.js» به جای «توافق‌نامۀ مجوز مشارکت‌کننده» قبلی خود از «گواهی مبدا توسعه‌دهنده» استفاده می کند. راهکار ساده برای اجرای خودکار «گواهی مبدا توسعه‌دهنده» در منبع (repository) شما، «ربات گواهی مبدا توسعه‌دهنده» است.
 
-* پروژۀ شما از یک مجوز متن باز استفاده بکند که شامل امتیاز ثبت اختراع (مانند MIT) نباشد و شما به داشتن سریع امتیاز ثبت اختراع  مشارکت‌کنندگان نیاز داشته باشید؛ برخی از آن‌ها ممکن است در شرکت‌هایی با مجموعه‌های بزرگ حق ثبت اختراع کار کنند که می‌تواند شما یا سایر مشارکت‌کنندگان و کاربران پروژه را مورد هدف قرار دهد. [توافق‌نامۀ مجوز مشارکت‌کنندگان حقیقی Apache]https://www.apache.org/licenses/icla.pdf)، یک توافق‌نامۀ همکاری اضافی است که معمولاً مورد استفاده قرار می‌گیرد و شامل امتیاز ثبت اختراع است که همانند آنچه در مجوز «Apache 2.0» یافت می‌شود، است.
+* پروژه شما از یک مجوز متن باز استفاده بکند که شامل امتیاز ثبت اختراع (مانند MIT) نباشد و شما به داشتن سریع امتیاز ثبت اختراع  مشارکت‌کنندگان نیاز داشته باشید؛ برخی از آن‌ها ممکن است در شرکت‌هایی با مجموعه‌های بزرگ حق ثبت اختراع کار کنند که می‌تواند شما یا سایر مشارکت‌کنندگان و کاربران پروژه را مورد هدف قرار دهد. [توافق‌نامۀ مجوز مشارکت‌کنندگان حقیقی Apache](https://www.apache.org/licenses/icla.pdf)، یک توافق‌نامۀ همکاری اضافی است که معمولاً مورد استفاده قرار می‌گیرد و شامل امتیاز ثبت اختراع است که همانند آنچه در مجوز «Apache 2.0» یافت می‌شود، است.
 
 * پروژۀ شما تحت مجوز کپی‌لفت باشد ، اما شما همچنین باید نسخه‌ای اختصاصی از پروژه را توزیع و پخش کنید. هر مشارکت‌کننده باید به شما حق نشر اختصاص دهد یا به شما (اما نه به عموم) مجوز اختیاری بدهد. [توافق‌نامۀ همکاری MongoDB](https://www.mongodb.com/legal/contributor-agreement) نمونه‌ای از این نوع توافق‌نامه است.
 
@@ -163,4 +159,4 @@ related:
 
 * **امتیاز ثبت اختراع:** ممکن است شرکت شما مایل باشد به شبکۀ [Open Invention Network](https://www.openinventionnetwork.com/)، که یک مجموعۀ ثبت اختراع مشترک برای محافظت از اعضا و استفادۀ آن‌ها از از پروژه‌های بزرگ متن باز یا جستجوی سایر [مجوزهای اختراع ثبت جایگزین](https://www.eff.org/document/hacking-patent-system-2016) است، بپیوندد.
 
-* **نظارت:** مخصوصاً زمانی منطقی است که پروژه‌ای را به یک [شخص حقوقی خارج از شرکت](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project) منتقل کنید.
\ No newline at end of file
+* **نظارت:** مخصوصاً زمانی منطقی است که پروژه‌ای را به یک [شخص حقوقی خارج از شرکت](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project) منتقل کنید.

From b6a426cf07cbd1a034ea2165f14525ae39dfe945 Mon Sep 17 00:00:00 2001
From: Iman Ghasrfakhri <ghasrfakhri@gmail.com>
Date: Thu, 5 Aug 2021 12:09:10 +0430
Subject: [PATCH 208/749] Remove unneeded new lines

---
 _articles/fa/metrics.md | 2 --
 1 file changed, 2 deletions(-)

diff --git a/_articles/fa/metrics.md b/_articles/fa/metrics.md
index d7274ce79b5..ed8169a2a85 100644
--- a/_articles/fa/metrics.md
+++ b/_articles/fa/metrics.md
@@ -31,7 +31,6 @@ related:
 
 اگر _می‌خواهید_ به سطح درک عمیق‌تری دربارۀ پروژۀ خودتان برسید، روش‌های تجزیه و تحلیل فعالیت‌های پروژه خود را بدانید.
 
-
 ## کشف و پیدا کردن
 
 قبل از اینکه کسی بتواند از پروژۀ شما استفاده کند یا در آن مشارکت داشته باشد، باید بداند که همچین پروژه‌ای وجود دارد. از خودتان بپرسید: _آیا مردم می‌توانند این پروژه را پیدا کنند؟_
@@ -75,7 +74,6 @@ related:
 
 وقتی با مخاطبان و افرادی که از پروژۀ شما استفاده می‌کنند آشنا شدید، بهتر است بفهمید که آن‌ها چه استفاده‌ای از پروژه می‌کنند. آیا آن‌ها با فورک کردن کد شما و افزودن ویژگی‌های مختلف، بر روی آن کار می‌کنند؟ آیا آن‌ها از آن برای مصارف علمی یا تجاری استفاده می‌کنند؟
 
-
 ## استمرار و نگهداری
 
 مردم پروژۀ شما را پیدا می‌کنند و از آن استفاده می‌کنند. سوالی که باید از خودتان بپرسید این است که: _آیا مردم در آن مشارکت هم می‌کنند یا خیر؟_

From 55f2d24a0185ffa045750d3632a5b246386219e5 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 6 Aug 2021 08:08:26 +0000
Subject: [PATCH 209/749] Bump actions/setup-node from 2.3.0 to 2.4.0

Bumps [actions/setup-node](https://github.com/actions/setup-node) from 2.3.0 to 2.4.0.
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/v2.3.0...v2.4.0)

---
updated-dependencies:
- dependency-name: actions/setup-node
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 6077f47a4e0..0157bc35d0e 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -14,7 +14,7 @@ jobs:
       uses: actions/setup-ruby@v1.1.3
 
     - name: Set up Node
-      uses: actions/setup-node@v2.3.0
+      uses: actions/setup-node@v2.4.0
 
     - name: Restore bundler cache
       uses: actions/cache@v2.1.6

From 4b94ec8e3d9a444065c55ab57703e8b9253c0db4 Mon Sep 17 00:00:00 2001
From: vkay11 <vinaykhanduri2001@gmail.com>
Date: Mon, 9 Aug 2021 21:41:35 +0530
Subject: [PATCH 210/749] Fixing editorial inconsistencies

---
 CODE_OF_CONDUCT.md              | 2 +-
 CONTRIBUTING.md                 | 2 +-
 _articles/best-practices.md     | 6 +++---
 _articles/building-community.md | 2 +-
 _articles/getting-paid.md       | 4 ++--
 _articles/how-to-contribute.md  | 4 ++--
 docs/content-model.md           | 2 +-
 docs/personas.md                | 2 +-
 docs/styleguide.md              | 6 +++---
 docs/translations.md            | 4 ++--
 10 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index 00c27e923e6..419c8a40892 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -3,7 +3,7 @@
 ## Our Pledge
 
 In the interest of fostering an open and welcoming environment, we as
-contributors and maintainers pledge to making participation in our project and
+contributors and maintainers pledge to make participation in our project and
 our community a harassment-free experience for everyone, regardless of age, body
 size, disability, ethnicity, gender identity and expression, level of experience,
 nationality, personal appearance, race, religion, or sexual identity and
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index a58a16a23fd..7be27de5935 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -24,7 +24,7 @@ There are many ways you can directly contribute to the guides (in descending ord
 * Fix editorial inconsistencies or inaccuracies
 * [Translate guides into other languages](docs/translations.md)
 
-Interested in making a contribution? Read on!
+Interested in contributing to this Open Source Guide? Read on!
 
 ## Ground rules & expectations
 
diff --git a/_articles/best-practices.md b/_articles/best-practices.md
index 1d311457735..bb8e694cec3 100644
--- a/_articles/best-practices.md
+++ b/_articles/best-practices.md
@@ -47,7 +47,7 @@ For example, @lord discovered that having a project vision helped him figure out
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
-  I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of an half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
+  I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of a half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
   <p markdown="1" class="pquote-credit">
 — @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
   </p>
@@ -104,7 +104,7 @@ If you receive a contribution you don't want to accept, your first reaction migh
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
-  The key to handle support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS.
+  The key to handling support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS.
   <p markdown="1" class="pquote-credit">
 — @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
   </p>
@@ -236,7 +236,7 @@ If you add tests, make sure to explain how they work in your CONTRIBUTING file.
 
 ### Use tools to automate basic maintenance tasks
 
-The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for it.
+The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for them.
 
 There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples:
 
diff --git a/_articles/building-community.md b/_articles/building-community.md
index a86c8b26c55..241eb1a5956 100644
--- a/_articles/building-community.md
+++ b/_articles/building-community.md
@@ -38,7 +38,7 @@ Start with your documentation:
 
 * **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
 * **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
-* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
+* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or a small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
 * **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/getting-paid.md b/_articles/getting-paid.md
index c150d731e57..456bd8644f9 100644
--- a/_articles/getting-paid.md
+++ b/_articles/getting-paid.md
@@ -17,7 +17,7 @@ related:
 
 ## Why some people seek financial support
 
-Much of open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+Much of the open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
@@ -119,7 +119,7 @@ Finally, sometimes open source projects put bounties on issues that you might co
 
 Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
 
-Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing into new features or ideas.
+Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas.
 
 As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
 
diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index f3bcf0b445f..a80f6a2160f 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -410,7 +410,7 @@ Before you open an issue or pull request, or ask a question in chat, keep these
 >
 > 😢 _"X is broken! Please fix it."_
 
-**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn.
+**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn.
 
 > 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
 >
@@ -494,7 +494,7 @@ If the project is on GitHub, here's how to submit a pull request:
 * **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.
 * **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
-* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+* **Contribute to the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
 
 If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
 
diff --git a/docs/content-model.md b/docs/content-model.md
index 5dc4f1ccc68..e4015ae6054 100644
--- a/docs/content-model.md
+++ b/docs/content-model.md
@@ -39,6 +39,6 @@ Historical vignettes are fun anecdotes that keep a reader's attention. They make
 
 We use bulleted lists to keep articles approachable and skim-able, and to group examples and checklists. However, avoid:
 
-- Articles consisting almost entirely of lists; lists should enhance narrative rather than serve as the main attraction.
+- Articles consisting almost entirely of lists; lists should enhance the narrative rather than serve as the main attraction.
 - Exhaustive or canonical lists; follows from above. If such a list is relevant, [link](styleguide.md#content-principles) to one maintained elsewhere.
 - Lists consisting of only links; a guide is not an awesome list. Check out how we link to the main awesome list in a list, [for example](https://opensource.guide/how-to-contribute/#you-dont-just-have-to-work-on-software-projects).
\ No newline at end of file
diff --git a/docs/personas.md b/docs/personas.md
index bf53d4a4242..625269e06a9 100644
--- a/docs/personas.md
+++ b/docs/personas.md
@@ -10,7 +10,7 @@
 
 * Sees self as ultimate decisionmaker
 
-* Still building community reputation
+* Still building a community reputation
 
 * Has never open sourced a project before
 
diff --git a/docs/styleguide.md b/docs/styleguide.md
index dc3b30875ca..e46025a3249 100644
--- a/docs/styleguide.md
+++ b/docs/styleguide.md
@@ -2,7 +2,7 @@
 
 From the GitHub Manual of Style, which this style guide inherits from:
 
-> Words are an important part of how software works. Just as we have a style guide for our code, we have a style guide for our tone and our voice. Even though there may be dozens of people creating a product, it should still sound like we speak in one consistent voice.
+> Words are an important part of how the software works. Just as we have a style guide for our code, we have a style guide for our tone and our voice. Even though there may be dozens of people creating a product, it should still sound like we speak in one consistent voice.
 >
 > In other words, the way we write is just as important as the way we design. Consider these things when writing copy.
 
@@ -11,7 +11,7 @@ Where possible, [automated tests](../test/prose) enforce style rules.
 ## Content principles
 All written content should follow these principles:
 
-* **Approachability:** Don't assume reader has prior knowledge
+* **Approachability:** Don't assume the reader has prior knowledge
 * **Brevity:** Keep it simple, link to outside content for deeper dives
 * **Curation:** Amplify community best practices vs. any individual's point of view
 
@@ -34,7 +34,7 @@ When referring to a project on GitHub, link to the repository so others can dive
 "Guides" is capitalized when referring to the "Open Source Guides", but not when saying "the guide" or "this guide".
 
 - :smile: Welcome to Open Source Guides!
-- :smile: The guide is meant to..
+- :smile: The guide is meant to...
 - :cry: The goal of this Guide is to...
 
 ## More guidance
diff --git a/docs/translations.md b/docs/translations.md
index 52364df202d..5f029967c3d 100644
--- a/docs/translations.md
+++ b/docs/translations.md
@@ -1,6 +1,6 @@
 # Translations
 
-Thanks for your interest in helping translating the guides!
+Thanks for your interest in helping to translate the guides!
 
 ## Starting a translation
 
@@ -15,7 +15,7 @@ If there's not, then today is your day to lead this effort! Here's how to start:
 1. Create a new directory in `_articles/` for your language e.g. `_articles/es/`, copy each guide from `_articles/` into that folder and translate the content in each guide, except for the field names in the front matter between the `---`s at the top of each file, e.g., `title:` should remain unchanged. Remove the `toc:` fields (they are only used for English).
 1. Copy `index.html` to your target language index file e.g. `[_articles/es/index.html](https://github.com/github/opensource.guide/blob/HEAD/_articles/es/index.html)` and update the `lang:` and add the `permalink:` fields. Example: `lang: es` and `permalink: /es/`. All other fields' values must remain unchanged.
 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.)
+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.
 

From 27316c773046a2922fab618bbb2ba2fe54af9d4f Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Mon, 9 Aug 2021 09:20:12 -0700
Subject: [PATCH 211/749] Exclude package-lock.json

---
 _config.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/_config.yml b/_config.yml
index b9075e8af22..f4d797a2ebe 100644
--- a/_config.yml
+++ b/_config.yml
@@ -10,6 +10,7 @@ exclude:
   - Gemfile*
   - node_modules
   - package.json
+  - package-lock.json
   - Rakefile
   - README.md
   - script

From 8ce6e415b4e8013fbefbf9baa6107f8b8a8e4da1 Mon Sep 17 00:00:00 2001
From: vkay11 <vinaykhanduri2001@gmail.com>
Date: Tue, 10 Aug 2021 20:22:21 +0530
Subject: [PATCH 212/749] Updating two files

Reflecting the changes suggested by other contributors.
---
 _articles/how-to-contribute.md | 2 +-
 docs/styleguide.md             | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index a80f6a2160f..e0260143094 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -494,7 +494,7 @@ If the project is on GitHub, here's how to submit a pull request:
 * **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.
 * **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
-* **Contribute to the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
 
 If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
 
diff --git a/docs/styleguide.md b/docs/styleguide.md
index e46025a3249..0954814617b 100644
--- a/docs/styleguide.md
+++ b/docs/styleguide.md
@@ -2,7 +2,7 @@
 
 From the GitHub Manual of Style, which this style guide inherits from:
 
-> Words are an important part of how the software works. Just as we have a style guide for our code, we have a style guide for our tone and our voice. Even though there may be dozens of people creating a product, it should still sound like we speak in one consistent voice.
+> Words are an important part of how software works. Just as we have a style guide for our code, we have a style guide for our tone and our voice. Even though there may be dozens of people creating a product, it should still sound like we speak in one consistent voice.
 >
 > In other words, the way we write is just as important as the way we design. Consider these things when writing copy.
 

From 6949de26a6f8df7d46fc23d86b9b8b341d08b24a Mon Sep 17 00:00:00 2001
From: vkay11 <vinaykhanduri2001@gmail.com>
Date: Wed, 11 Aug 2021 07:19:41 +0530
Subject: [PATCH 213/749] Update getting-paid.md

---
 _articles/getting-paid.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/getting-paid.md b/_articles/getting-paid.md
index 456bd8644f9..9b80feb12a2 100644
--- a/_articles/getting-paid.md
+++ b/_articles/getting-paid.md
@@ -17,7 +17,7 @@ related:
 
 ## Why some people seek financial support
 
-Much of the open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">

From 2c80be8bb3e0a054224e7aa980690bb7daceaf3d Mon Sep 17 00:00:00 2001
From: Kyoungae Kim <kyoungae.kim@lge.com>
Date: Tue, 24 Aug 2021 14:47:21 +0900
Subject: [PATCH 214/749] Update legal.md

refine
---
 _articles/ko/legal.md | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index a29e73a35ad..14f606e5646 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -16,7 +16,7 @@ related:
 
 ## Why do people care so much about the legal side of open source?
 
-물어봤다는건 다행입니다! 창의적인 작업(작성, 그래픽 또는 코드)을 할 때, 그 저작물은 기본적으로 독점적인 저작권하에 있습니다. 즉, 법은 귀하를 저작물의 작성자로서 다른 사람들이 할 수 있는 것에 대해 귀하가 말하고있는 것으로 간주합니다.
+물어봤다는건 다행입니다! 창의적인 작업(작성, 그래픽 또는 코드)을 할 때, 그 저작물은 기본적으로 독점적인 저작권 하에 있습니다. 즉, 법은 귀하를 저작물의 작성자로서 다른 사람들이 할 수 있는 것에 대해 귀하가 말하고 있는 것으로 간주합니다.
 
 일반적으로, 이는 타인이 인계, 훼손 또는 소송의 위험이 없이 작업을 사용, 복사, 배포 또는 수정할 수 없음을 의미합니다.
 
@@ -34,13 +34,13 @@ related:
 
 **GitHub 프로젝트를 공개하는 것은 프로젝트 라이센싱과 동일하지 않습니다.** 공개 프로젝트는 [GitHub의 서비스 약관](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)에 명시되어 있으며, 다른 사람들이 프로젝트를 보거나 포크할 수는 있지만, 다른 권한은 없습니다.
 
-다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게하려면, 오픈소스 라이선스를 포함해야합니다. 예를 들어, GitHub 프로젝트가 공개되어 있다 하더라도 명시적으로 권한을 부여하지 않는다면, 그 코드의 어느 부분도 사용할 수 없습니다. 
+다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게 하려면, 오픈소스 라이선스를 포함해야 합니다. 예를 들어, GitHub 프로젝트가 공개되어 있다 하더라도 명시적으로 권한을 부여하지 않는다면, 그 코드의 어느 부분도 사용할 수 없습니다. 
 
 ## Just give me the TL;DR on what I need to protect my project.
 
 운이 좋았습니다. 오늘날 오픈소스 라이선스는 표준화되어 있고 사용하기 쉽기 때문입니다. 기존 라이선스를 프로젝트에 직접 복사하여 붙여넣을 수 있습니다.
 
-[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/)에서 이러한 라이선스의 전체 텍스트 및 사용 방법에 대한 지침을 찾을 수 있습니다.
+[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/).
 
@@ -54,19 +54,19 @@ GitHub에서 새로운 프로젝트를 만들 때, [라이선스를 추가할 
 
 ## Which open source license is appropriate for my project?
 
-빈 슬레이트에서 시작한다면, [MIT 라이선스](https://choosealicense.com/licenses/mit/)를 잘못 읽는 것은 어렵습니다. MIT 라이선스는 짧고 이해하기 쉬우며, 저작권 고지를 포함하여 라이선스 사본을 보관하는 한 누구나 모든 것을 할 수 있도록 허락합니다.필요한 경우 다른 라이선스로 프로젝트를 릴리스 할 수 있습니다.
+빈 슬레이트에서 시작한다면, [MIT 라이선스](https://choosealicense.com/licenses/mit/)를 잘못 읽는 것은 어렵습니다. MIT 라이선스는 짧고 이해하기 쉬우며, 저작권 고지를 포함하여 라이선스 사본을 보관하는 한 누구나 모든 것을 할 수 있도록 허락합니다. 필요한 경우 다른 라이선스로 프로젝트를 릴리스 할 수 있습니다.
 
-그렇지 않으면 프로젝트에 적합한 오픈소스 라이선스를 선택하는 것이 목적에 달려 있습니다.
+그렇지 않으면 프로젝트에 적합한 오픈소스 라이선스를 선택하는 것은 목적에 달려 있습니다.
 
 프로젝트에 **의존성**이 있을 가능성이 큽니다. 예를 들어, Node.js 프로젝트를 오픈소스로 사용하는 경우 노드 패키지 관리자(npm)의 라이브러리를 사용할 수 있습니다. 의존하는 각 라이브러리에는 자체 오픈소스 라이선스가 있습니다. 각 라이선스가 "허용"(다운스트림 라이선스의 조건없이 공용 사용, 수정 및 공유할 수 있는 권한 부여)되어 있으면, 원하는 라이선스를 사용할 수 있습니다. 일반적인 허용 라이선스에는 MIT, Apache 2.0, ISC 및 BSD가 포함됩니다.
 
-반대로, 종속성 라이선스가 "강력한 카피레프트"(동일한 라이선스를 다운스트림으로 사용하는 조건하에 공개 권한을 부여하는 경우)인 경우, 프로젝트는 동일한 라이선스를 사용해야 합니다. 일반적인 강력한 카피레프트 라이선스에는 GPLv2, GPLv3 및 AGPLv3이 포함됩니다.
+반대로, 의존하는 라이선스가 "강력한 카피레프트"(동일한 라이선스를 다운스트림으로 사용하는 조건 하에 동일한 권한을 부여하는 경우)인 경우, 프로젝트는 동일한 라이선스를 사용해야 합니다. 일반적인 강력한 카피레프트 라이선스에는 GPLv2, GPLv3 및 AGPLv3이 포함됩니다.
 
 프로젝트를 사용하고 기여할 수 있는 **커뮤니티**를 고려해보십시오:
 
 * **프로젝트를 다른 프로젝트의 종속성으로 사용 하시겠습니까?** 관련 커뮤니티에서 가장 많이 사용되는 라이선스를 사용하는 것이 가장 좋습니다. 예시로, [MIT](https://choosealicense.com/licenses/mit/)는 [npm libraries](https://libraries.io/search?platforms=NPM)에서 가장 인기있는 라이선스입니다.
 * **프로젝트를 대기업에 어필하고 싶습니까?** 대기업은 모든 참여자의 명시적인 특허 라이선스를 원할 것입니다. 이 경우, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)는 귀하(그리고 그들)을 커버해 줄것 입니다.
-* **독점 소스 소프트웨어에서 기여를 사용하고 싶지 않은 기여자에게 프로젝트를 어필하고 싶습니까?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) 혹은 (또한 독점 소스 서비스에 기여하지 않으려는 경우) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/)은 잘될 것 입니다.
+* **독점 소스 소프트웨어에 기여를 하고 싶지 않은 기여자에게 프로젝트를 어필하고 싶습니까?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) 혹은 (또한 독점 소스 서비스에 기여하지 않으려는 경우) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/)은 잘될 것입니다.
 
 귀하의 **회사**는 오픈소스 프로젝트에 대한 특정 라이선스 요구 사항을 가지고 있을 수 있습니다. 예를 들어, 회사에서 회사의 독점 소스 제품에서 프로젝트를 사용할 수 있도록 허용 라이선스가 필요할 수 있습니다. 또는 귀사만 독점 소스 소프트웨어에서 프로젝트를 사용할 수 있도록 강력한 카피 레프트 라이선스와 추가 기여자 계약(아래 참조)이 필요할 수 있습니다. 또는 표준, 사회적 책임 또는 투명성과 관련된 특정 요구 사항이 있을 수 있습니다. 이러한 요구 사항에는 특정 라이선스 전략이 필요할 수 있습니다. 귀하의 [회사 법률 부서](#what-does-my-companys-legal-team-need-to-know)에 이야기하십시오.
 
@@ -76,13 +76,13 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
 
 대부분의 프로젝트는 라이선스를 변경할 필요가 없습니다. 그러나 때때로 상황이 바뀝니다.
 
-예를 들어, 프로젝트가 커짐에 따라 종속성이나 사용자가 추가되거나 회사에서 전략을 변경합니다. 전략 중 하나는 다른 라이선스를 요구하거나 원할 수 있습니다. 또한 처음부터 프로젝트 라이선스를 소홀히했다면, 라이선스를 추가하는 것은 사실상 라이선스를 변경하는 것과 같습니다. 프로젝트 라이선스를 추가하거나 변경할 때 고려해야 할 세 가지 기본 사항이 있습니다.
+예를 들어, 프로젝트가 커짐에 따라 종속성이나 사용자가 추가되거나 회사에서 전략을 변경합니다. 전략 중 하나는 다른 라이선스를 요구하거나 원할 수 있습니다. 또한 처음부터 프로젝트 라이선스를 소홀히 했다면, 라이선스를 추가하는 것은 사실상 라이선스를 변경하는 것과 같습니다. 프로젝트 라이선스를 추가하거나 변경할 때 고려해야 할 세 가지 기본 사항이 있습니다.
 
-**복잡합니다.** 라이선스 호환성 및 규정 준수 여부를 결정하고 저작권을 보유한 사람은 매우 복잡하고 혼란스러울 수 있습니다. 새로운 릴리즈 및 기여용으로 새롭지만 호환되는 라이선스로 전환하는 것은 기존 기여를 모두 재 라이선스하는 것과 다릅니다. 법률팀에 라이선스 변경 희망의 첫 번째 힌트를 포함시키십시오. 프로젝트의 저작권 소유자로부터 라이선스 변경에 대한 허가를 받았거나 취득할 수있는 경우에도 변경 사항이 프로젝트의 다른 사용자 및 제공자에게 미치는 영향을 고려하십시오. 라이선스 변경은 프로젝트의 이해 관계자와 명확한 커뮤니케이션 및 협의를 통해 원활하게 진행될 수 있는 프로젝트의 "거버넌스 이벤트"라고 생각하십시오. 프로젝트를 시작할 때부터 적절한 라이선스를 선택하여 사용하는 더 많은 이유가 있습니다!
+**복잡합니다.** 라이선스 호환성 및 규정 준수 여부를 결정하고 저작권을 보유한 사람은 매우 복잡하고 혼란스러울 수 있습니다. 새로운 릴리즈 및 기여용으로 새롭지만 호환되는 라이선스로 전환하는 것은 기존 기여를 모두 재 라이선스하는 것과 다릅니다. 법률팀에 라이선스 변경 희망의 첫 번째 힌트를 포함시키십시오. 프로젝트의 저작권 소유자로부터 라이선스 변경에 대한 허가를 받았거나 취득할 수있는 경우에도 변경 사항이 프로젝트의 다른 사용자 및 제공자에게 미치는 영향을 고려하십시오. 라이선스 변경은 프로젝트의 이해 관계자와 명확한 커뮤니케이션 및 협의를 통해 원활하게 진행될 수 있는 프로젝트의 "거버넌스 이벤트"라고 생각하십시오. 프로젝트를 시작할 때부터 적절한 라이선스를 선택하여 사용하는데는 더 많은 이유가 있습니다!
 
-**프로젝트의 기존 라이선스가 있습니다.** 프로젝트의 기존 라이선스가 변경하려는 라이선스와 호환되는 경우, 새 라이선스를 사용하기만 하면됩니다. 라이선스 A가 라이선스 B와 호환되면 B의 조건을 준수하면서 A의 조건을 준수하게됩니다(반대의 경우도 가능). 따라서 현재 MIT와 같은 허가된 라이선스를 사용하고 있다면 MIT 라이선스 사본 및 관련 저작권 고지를 보유하는 한 더 많은 조건으로 라이선스로 변경할 수 있습니다(즉, 계속해서 MIT 라이선스의 최소 조건 준수). 그러나 현재 라이선스가 허용되지 않는 경우(예:카피 레프트 또는 라이선스가 없는 경우), 저작권자가 유일하지 않은 경우, 프로젝트 라이선스를 MIT로 변경할 수 없습니다. 근본적으로 허가된 라이선스로 프로젝트의 저작권 소유자는 라이선스 변경을 사전 허가합니다.
+**프로젝트의 기존 라이선스가 있습니다.** 프로젝트의 기존 라이선스가 변경하려는 라이선스와 호환되는 경우, 새 라이선스를 사용하기만 하면 됩니다. 라이선스 A가 라이선스 B와 호환되면 B의 조건을 준수하면서 A의 조건을 준수하게 됩니다(반대의 경우도 가능). 따라서 현재 MIT와 같은 허가된 라이선스를 사용하고 있다면 MIT 라이선스 사본 및 관련 저작권 고지를 보유하는 한 더 많은 조건으로 라이선스로 변경할 수 있습니다(즉, 계속해서 MIT 라이선스의 최소 조건 준수). 그러나 현재 라이선스가 허용되지 않는 경우(예:카피 레프트 또는 라이선스가 없는 경우), 저작권자가 유일하지 않은 경우, 프로젝트 라이선스를 MIT로 변경할 수 없습니다. 근본적으로 허가된 라이선스로 프로젝트의 저작권 소유자는 라이선스 변경을 사전 허가합니다.
 
-**프로젝트의 기존 저작권 보유자가 있습니다.** 귀하가 프로젝트에 단독으로 기여한 경우, 귀하 또는 귀하의 회사는 프로젝트의 유일한 저작권자입니다. 귀하 또는 귀하의 회사에서 원하는 모든 라이선스를 추가하거나 변경할 수 있습니다. 그렇지 않으면 라이선스를 변경하기 위해 동의해야하는 다른 저작권 소유자가 있을 수 있습니다. 그들은 누구입니까? 프로젝트에 커밋을 한 사람은 시작하기 좋은 곳입니다. 그러나 어떤 경우, 저작권은 해당 사용자의 고용주가 보유하게됩니다. 어떤 경우에는 사람들이 최소한의 기여를 했을 뿐이지만, 몇 줄의 코드가 저작권의 대상이 되지않는다는 단호하고 신속한 규칙은 없습니다. 그럼 무엇을 해야합니까? 상대적으로 규모가 작고 젊은 프로젝트의 경우에는, 기존의 모든 기여자가 문제의 라이선스 변경에 동의하거나 이슈 혹은 pull request할 수 있습니다. 크고 수명이 긴 프로젝트의 경우, 많은 기여가와 소유인을 찾아야 할 수도 있습니다. 모질라는 파이어폭스, 썬더버드 및 관련 소프트웨어를 재 라이선스하기 위해 수년(2001-2006)을 보냈습니다.
+**프로젝트의 기존 저작권 보유자가 있습니다.** 귀하가 프로젝트에 단독으로 기여한 경우, 귀하 또는 귀하의 회사는 프로젝트의 유일한 저작권자입니다. 귀하 또는 귀하의 회사에서 원하는 모든 라이선스를 추가하거나 변경할 수 있습니다. 그렇지 않으면 라이선스를 변경하기 위해 동의해야하는 다른 저작권 소유자가 있을 수 있습니다. 그들은 누구입니까? 프로젝트에 커밋을 한 사람은 시작하기 좋은 곳입니다. 그러나 어떤 경우, 저작권은 해당 사용자의 고용주가 보유하게 됩니다. 어떤 경우에는 사람들이 최소한의 기여를 했을 뿐이지만, 몇 줄의 코드가 저작권의 대상이 되지 않는다는 단호하고 신속한 규칙은 없습니다. 그럼 무엇을 해야합니까? 상대적으로 규모가 작고 젊은 프로젝트의 경우에는, 기존의 모든 기여자가 문제의 라이선스 변경에 동의하거나 이슈 혹은 pull request할 수 있습니다. 크고 수명이 긴 프로젝트의 경우, 많은 기여자와 상속인을 찾아야 할 수도 있습니다. 모질라는 파이어폭스, 썬더버드 및 관련 소프트웨어를 재 라이선스하기 위해 수년(2001-2006)을 보냈습니다.
 
 또는 기여자가 기존 오픈소스 라이선스에서 허용하는 것 이상으로 특정 조건하에서 특정 라이선스 변경 사항에 대해 사전에 동의할 수 있습니다 (추가 기여자 계약 - 아래 참조). 이렇게하면 라이선스 변경의 복잡성이 조금씩 바뀝니다. 변호사의 도움이 더 필요합니다. 라이선스 변경을 수행할 때는, 프로젝트의 이해 관계자와 명확하게 의견을 나눌 수 있습니다.
 
@@ -90,9 +90,9 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
 
 아마도 그렇지 않습니다. 대다수의 오픈소스 프로젝트에서 공개 소스 라이선스는 인바운드(기여자)와 아웃바운드(다른 참여자 및 사용자) 라이선스로 암묵적으로 사용됩니다. 프로젝트가 GitHub에 있는 경우, GitHub 서비스 약관은 "인바운드 = 아웃 바운드" [명시적 기본값](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license)으로 지정합니다.
 
-기여자 라이선스 계약(CLA)이라고도 부르는 추가 기여자 계약은 프로젝트 메인테이너를 위한 관리 작업을 생성할 수 있습니다. 계약서에 얼마나 많은 작업을 추가할지는 프로젝트와 구현에 달려 있습니다. 간단한 동의는 프로젝트 참여자가 프로젝트 오픈소스 라이선스하에 기여할 수 있는 권리를 클릭으로 확인해야 할 수도 있습니다. 보다 복잡한 합의는 법적 검토와 기여자 고용주의 서명을 요구할 수 있습니다.
+기여자 라이선스 계약(CLA)이라고도 부르는 추가 기여자 계약은 프로젝트 메인테이너를 위한 관리 작업을 생성할 수 있습니다. 계약서에 얼마나 많은 작업을 추가할지는 프로젝트와 구현에 달려 있습니다. 간단한 동의는 프로젝트 참여자가 프로젝트 오픈소스 라이선스 하에 기여할 수 있는 권리를 클릭으로 확인해야 할 수도 있습니다. 보다 복잡한 합의는 법적 검토와 기여자 고용주의 서명을 요구할 수 있습니다.
 
-또한 일부 사람들은 불필요하거나 이해하기 힘들거나 불공정하다고 생각되는 "서류 작업"을 추가함으로써 (계약 수령자가 프로젝트 참여자보다 더 많은 권리를 얻거나 일반인이 프로젝트의 오픈소스 라이선스를 통해 수행 할 때) 추가 기여자 계약이  프로젝트의 커뮤니티에 비우호적이라고 인식될 수 있습니다.
+또한 일부 사람들은 불필요하거나 이해하기 힘들거나 불공정하다고 생각되는 "서류 작업"을 추가함으로써 (계약 수령자가 프로젝트 참여자보다 더 많은 권리를 얻거나 일반인이 프로젝트의 오픈소스 라이선스를 통해 수행 할 때) 추가 기여자 계약이 프로젝트의 커뮤니티에 비우호적이라고 인식될 수 있습니다.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
@@ -105,17 +105,17 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
 프로젝트에 대한 추가 기여자 계약을 고려할 수 있는 몇 가지 상황은 다음과 같습니다:
 
 * 변호사는 기여자가 오픈소스 라이선스 자체가 충분하지 않다고 생각하기 때문에 모든 기여자가 기여 조항을 명시적으로 (_sign_, 온라인 또는 오프라인) 받아들이기를 원합니다. 이것이 유일한 관심사라면, 프로젝트의 오픈소스 라이선스를 인정하는 기여자 계약만으로 충분할 것입니다. [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/)는 경량 추가 제공자 계약의 좋은 예입니다. 일부 프로젝트의 경우, [개발자 인증서 발급](https://github.com/probot/dco)을 사용할 수 있습니다.
-* 귀하의 프로젝트는 익스프레스 특허 부여 (MIT 등)가 포함되지 않은 오픈소스 라이선스를 사용하며, 모든 기여자의 특허 보조금이 필요합니다. 그 중 일부는 귀하를 타겟으로 삼을 수있는 대규모 특허 포트폴리오를 보유한 회사 또는 프로젝트의 다른 참여자 및 사용자에서 사용할 수 있습니다. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)는 일반적으로 사용되는 추가 기여자 계약으로 Apache License 2.0에서 발견된 특허권 부여를 미러링합니다.
-* 프로젝트에 카피레프트 라이선스가 있지만, 프로젝트의 독점 버전을 배포해야합니다. 모든 저작자가 저작권을 양도하거나 관할권을 부여할 수 있는 허가권을 사용자에게 부여해야합니다. [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement)는 이러한 유형의 계약입니다.
+* 귀하의 프로젝트는 익스프레스 특허 부여 (MIT 등)가 포함되지 않은 오픈소스 라이선스를 사용하며, 모든 기여자의 특허 허여가 필요합니다. 그 중 일부는 귀하를 타겟으로 삼을 수 있는 대규모 특허 포트폴리오를 보유한 회사 또는 프로젝트의 다른 참여자 및 사용자가 사용할 수 있습니다. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)는 일반적으로 사용되는 추가 기여자 계약으로 Apache License 2.0에서 발견된 특허권 부여를 미러링합니다.
+* 프로젝트에 카피레프트 라이선스가 있지만, 프로젝트의 독점 버전을 배포해야 합니다. 모든 저작권자가 저작권을 양도하거나 관할권을 부여할 수 있는 허가권을 사용자에게 부여해야합니다. [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement)는 이러한 유형의 계약입니다.
 * 평생동안 프로젝트를 변경하고 기여자가 그러한 변경 사항에 동의하기를 원한다고 생각하십시오.
 
 프로젝트에 기여자 계약을 추가로 사용해야하는 경우 기여자 산만을 최소화하기 위해 [CLA 어시스턴트](https://github.com/cla-assistant/cla-assistant)와 같은 통합 사용을 고려하십시오.
 
 ## What does my company's legal team need to know?
 
-오픈소스 프로젝트를 회사 직원으로 공개하는 경우, 먼저 법률팀이 오픈소스 프로젝트임을 알고 있어야합니다.
+오픈소스 프로젝트를 회사 직원으로 공개하는 경우, 먼저 법률팀이 오픈소스 프로젝트임을 알고 있어야 합니다.
 
-더 좋든 나쁘든, 개인 프로젝트일지라도 알려주도록하십시오. 특히 회사의 비즈니스와 관련이 있거나 프로젝트를 개발하기 위해 회사 자원을 사용하는 경우, 프로젝트 관리를 제공하는 회사와 "직원 IP 계약"을 체결했을 수도 있습니다. 귀사는 귀사에게 쉽게 허가권을 부여해야하며, 직원 친화적인 IP 계약 또는 회사 방침을 이미 거쳐야 할 수도 있습니다. 그렇지 않은 경우, 협상을 통해 (예 : 프로젝트가 회사의 전문 학습 및 개발 목표를 제공한다고 설명), 또는 더 나은 회사를 찾을 때까지 프로젝트 작업을 하지 않을 수 있습니다.
+더 좋든 나쁘든, 개인 프로젝트일지라도 알려주도록 하십시오. 특히 회사의 비즈니스와 관련이 있거나 프로젝트를 개발하기 위해 회사 자원을 사용하는 경우, 프로젝트 관리를 제공하는 회사와 "직원 IP 계약"을 체결했을 수도 있습니다. 귀사는 귀사에게 쉽게 허가권을 부여해야하며, 직원 친화적인 IP 계약 또는 회사 방침을 이미 거쳐야 할 수도 있습니다. 그렇지 않은 경우, 협상을 통해 (예 : 프로젝트가 회사의 전문 학습 및 개발 목표를 제공한다고 설명), 또는 더 나은 회사를 찾을 때까지 프로젝트 작업을 하지 않을 수 있습니다.
 
 **당신이 회사를 위해 프로젝트를 오픈소스화하고 있다면,** 분명히 알려주십시오. 법무팀은 이미 귀사의 비즈니스 요구 사항 및 전문성을 토대로 프로젝트가 종속성의 라이선스를 준수하는지 확인하기 위해 오픈 소스 라이선스 (및 추가로 제공되는 계약자 계약)에 대한 정책을 이미 가지고 있습니다. 그렇지 않다면, 당신과 그들은 운에 따라야 합니다! 귀하의 법률팀은 당신과 함께 이 일을 이해하기 위해 열심히 노력해야 합니다. 생각해야될 몇 가지 사항이 있습니다:
 

From 33639a2709d3264ba42e8b34b259a858625a3b88 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@gmail.com>
Date: Tue, 24 Aug 2021 11:05:39 +0200
Subject: [PATCH 215/749] Update ada links to point to google cached version

---
 _articles/code-of-conduct.md         | 2 +-
 _articles/de/code-of-conduct.md      | 2 +-
 _articles/es/code-of-conduct.md      | 2 +-
 _articles/fr/code-of-conduct.md      | 2 +-
 _articles/hu/code-of-conduct.md      | 2 +-
 _articles/id/code-of-conduct.md      | 2 +-
 _articles/ja/code-of-conduct.md      | 2 +-
 _articles/ko/code-of-conduct.md      | 2 +-
 _articles/ms/code-of-conduct.md      | 2 +-
 _articles/nl/code-of-conduct.md      | 2 +-
 _articles/pl/code-of-conduct.md      | 2 +-
 _articles/pt/code-of-conduct.md      | 2 +-
 _articles/ro/code-of-conduct.md      | 2 +-
 _articles/ta/code-of-conduct.md      | 2 +-
 _articles/tr/code-of-conduct.md      | 2 +-
 _articles/zh-hans/code-of-conduct.md | 2 +-
 _articles/zh-hant/code-of-conduct.md | 2 +-
 17 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/_articles/code-of-conduct.md b/_articles/code-of-conduct.md
index 1ee5772d1cf..0d606e8e168 100644
--- a/_articles/code-of-conduct.md
+++ b/_articles/code-of-conduct.md
@@ -46,7 +46,7 @@ Place a CODE_OF_CONDUCT file in your project's root directory, and make it visib
 <aside markdown="1" class="pquote">
   A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/de/code-of-conduct.md b/_articles/de/code-of-conduct.md
index 10d6bcfd834..5014da00061 100644
--- a/_articles/de/code-of-conduct.md
+++ b/_articles/de/code-of-conduct.md
@@ -44,7 +44,7 @@ Legen Sie eine CODE_OF_CONDUCT-Datei in das Stammverzeichnis Ihres Projekts und
   _A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community._
 
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/es/code-of-conduct.md b/_articles/es/code-of-conduct.md
index 78db3337d3d..654c9213658 100644
--- a/_articles/es/code-of-conduct.md
+++ b/_articles/es/code-of-conduct.md
@@ -40,7 +40,7 @@ Ubica un archivo CODIGO_DE_CONDUCTA en el directorio ra&iacute;z de tu proyecto,
 <aside markdown="1" class="pquote">
   Un c&oacute;digo de conducta que no es (o no puede) ser aplicado, es incluso peor que no tener un c&oacute;digo de conducta: Esto demostrar&iacute;a que los valores en el c&oacute;digo de conducta no son importantes o no son respetados en tu comunidad.
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/fr/code-of-conduct.md b/_articles/fr/code-of-conduct.md
index 31fd5c870db..cc3b654023f 100644
--- a/_articles/fr/code-of-conduct.md
+++ b/_articles/fr/code-of-conduct.md
@@ -40,7 +40,7 @@ Placez un fichier CODE_OF_CONDUCT dans le répertoire racine de votre projet et
 <aside markdown="1" class="pquote">
   Un code de conduite qui n'est pas (ou ne peut pas être) appliqué est pire qu'aucun code de conduite: il envoie le message que les valeurs du code de conduite ne sont pas vraiment importantes ou respectées dans votre communauté.
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/hu/code-of-conduct.md b/_articles/hu/code-of-conduct.md
index 300fc1aaecc..e6418c8bc83 100644
--- a/_articles/hu/code-of-conduct.md
+++ b/_articles/hu/code-of-conduct.md
@@ -40,7 +40,7 @@ Helyezd el a CODE_OF_CONDUCT állomány a projekt gyökérkönyvtárában, és h
 <aside markdown="1" class="pquote">
   Az a magatartási kódex, amelyet nem (vagy nem tudnak) betartatni rosszabb, mintha nem lenne: azt üzeni, hogy az értékek, amelyek benne megfogalmazásra kerültek nem fontosak és lényegtelenek a közösség számára.
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/id/code-of-conduct.md b/_articles/id/code-of-conduct.md
index e52ed48e141..c6c1dce206d 100644
--- a/_articles/id/code-of-conduct.md
+++ b/_articles/id/code-of-conduct.md
@@ -40,7 +40,7 @@ Tempatkan dokumen CODE_OF_CONDUCT pada induk direktori proyek Anda, dan hubungka
 <aside markdown="1" class="pquote">
   Kode etik yang tidak (bisa) diterapkan jauh lebih jelek dibandingkan tanpa kode etik sama sekali: hal ini mengirimkan pesan bahwa nilai dari kode etik tidaklah penting atau dihargai pada komunitas Anda.
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/ja/code-of-conduct.md b/_articles/ja/code-of-conduct.md
index ba6a7bb6f98..b97a1f92d74 100644
--- a/_articles/ja/code-of-conduct.md
+++ b/_articles/ja/code-of-conduct.md
@@ -40,7 +40,7 @@ CODE_OF_CONDUCT ファイルをプロジェクトのルートディレクトリ
 <aside markdown="1" class="pquote">
   遵守されていない行動規範は、全く行動指針がない状態よりも悪い状態です： 行動規範が遵守されていない状態は、行動規範に記載されている価値観が実際は重要でないか尊重されていないというメッセージをコミュニティの人々に与えてしまうからです。
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/ko/code-of-conduct.md b/_articles/ko/code-of-conduct.md
index 257f31a4a7f..4839651e9fb 100644
--- a/_articles/ko/code-of-conduct.md
+++ b/_articles/ko/code-of-conduct.md
@@ -40,7 +40,7 @@ related:
 <aside markdown="1" class="pquote">
   A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
   <p markdown="1" class="pquote-credit">
-— [Ada 발의](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada 발의](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/ms/code-of-conduct.md b/_articles/ms/code-of-conduct.md
index fc1e3a051fa..d4f1ea0d7ac 100644
--- a/_articles/ms/code-of-conduct.md
+++ b/_articles/ms/code-of-conduct.md
@@ -46,7 +46,7 @@ Letakkan fail CODE_OF_CONDUCT di direktori root projek anda, dan jadikan ia dapa
 <aside markdown="1" class="pquote">
   Kod tingkah laku yang tidak (atau tidak dapat) ditegakkan lebih buruk daripada tidak ada kod tingkah laku sama sekali: ia menghantar mesej bahawa nilai-nilai dalam kod tingkah laku sebenarnya tidak penting atau dihormati dalam komuniti anda.
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/nl/code-of-conduct.md b/_articles/nl/code-of-conduct.md
index f77c2c91613..ec41ca22b77 100644
--- a/_articles/nl/code-of-conduct.md
+++ b/_articles/nl/code-of-conduct.md
@@ -48,7 +48,7 @@ Place a CODE_OF_CONDUCT file in your project's root directory, and make it visib
   
   _A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community._
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/pl/code-of-conduct.md b/_articles/pl/code-of-conduct.md
index 1a2d7a1ef2f..6a8c980e889 100644
--- a/_articles/pl/code-of-conduct.md
+++ b/_articles/pl/code-of-conduct.md
@@ -40,7 +40,7 @@ Umieść plik CODE_OF_CONDUCT w katalogu głównym projektu i uczyń go widoczny
 <aside markdown="1" class="pquote">
   A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/pt/code-of-conduct.md b/_articles/pt/code-of-conduct.md
index dc8554899da..bc54236b47a 100644
--- a/_articles/pt/code-of-conduct.md
+++ b/_articles/pt/code-of-conduct.md
@@ -40,7 +40,7 @@ Coloque um arquivo CODE_OF_CONDUCT no diretório raiz do seu projeto, e faça-o
 <aside markdown="1" class="pquote">
   Um código de conduta que não é (ou não pode ser) aplicado é pior do que não ter nenhum código de conduta: isso passa a mensagem de que os valores no código de conduta não são, na verdade, importantes ou respeitados em sua comunidade.
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/ro/code-of-conduct.md b/_articles/ro/code-of-conduct.md
index 75202870517..732f7bf0a4a 100644
--- a/_articles/ro/code-of-conduct.md
+++ b/_articles/ro/code-of-conduct.md
@@ -53,7 +53,7 @@ Amplasează un fișier CODE_OF_CONDUCT în directorul rădăcină al proiectului
     </em>
   </p>
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/ta/code-of-conduct.md b/_articles/ta/code-of-conduct.md
index 33a8c45ff23..9908515abf3 100644
--- a/_articles/ta/code-of-conduct.md
+++ b/_articles/ta/code-of-conduct.md
@@ -40,7 +40,7 @@ related:
 <aside markdown="1" class="pquote">
   நடமுறைப்படுத்தாத (அல்லது நடமுறைப்படுத்த முடியாத) ஒரு நடத்தை விதி, நடத்தை விதித் தொகுப்பு இல்லாமலிருப்பதை விட மோசமானதாகும்: நடத்தை விதிகளில் உள்ள மதிப்புகள் உண்மையிலேயே முக்கியம் அல்ல, உங்கள் சமூகத்தில் மதிக்கப்படுவதில்லை என்று குறிப்பை அனுப்புகிறது.
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md
index 7fd904dfa0b..6a55964f5bb 100644
--- a/_articles/tr/code-of-conduct.md
+++ b/_articles/tr/code-of-conduct.md
@@ -46,7 +46,7 @@ CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTIN
 <aside markdown="1" class="pquote">
   Uygulanmayan (veya uygulanamayan) bir davranış kural listesi, hiçbir davranış kuralı olmamasından daha kötüdür: davranış kurallarındaki değerlerin, sizin toplumunuzda gerçekten önemli veya saygı duyulmadığı mesajını gönderir.
   <p markdown="1" class="pquote-credit">
-- [Ada Girişimi](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Girişimi](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/zh-hans/code-of-conduct.md b/_articles/zh-hans/code-of-conduct.md
index 6e2dcf9716d..98fb751b1d4 100644
--- a/_articles/zh-hans/code-of-conduct.md
+++ b/_articles/zh-hans/code-of-conduct.md
@@ -41,7 +41,7 @@ redirect_from: /zh-cn/code-of-conduct/
 <aside markdown="1" class="pquote">
   一份行为守则没有（或者不能）执行会比没有行为守则更糟糕。它释放这样一个信息：行为守则或者尊重在你们的社区并不重要。
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
diff --git a/_articles/zh-hant/code-of-conduct.md b/_articles/zh-hant/code-of-conduct.md
index bff385c7ae4..d92260bbebf 100644
--- a/_articles/zh-hant/code-of-conduct.md
+++ b/_articles/zh-hant/code-of-conduct.md
@@ -41,7 +41,7 @@ redirect_from: /zh-tw/code-of-conduct/
 <aside markdown="1" class="pquote">
   一份行爲守則沒有（或者不能）執行會比沒有行爲守則更糟糕。它釋放這樣一個資訊：行爲守則或者尊重在你們的社群並不重要。
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 

From 048e7ab76ce1e5001539c31a391e7d569418510b Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 25 Aug 2021 08:05:49 +0000
Subject: [PATCH 216/749] Bump github-pages from 218 to 219

Bumps [github-pages](https://github.com/github/pages-gem) from 218 to 219.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v218...v219)

---
updated-dependencies:
- dependency-name: github-pages
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index d0c0ea4d793..2485486f3c8 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (6.0.4)
+    activesupport (6.0.4.1)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
@@ -26,7 +26,7 @@ GEM
       ffi (>= 1.15.0)
     eventmachine (1.2.7)
     execjs (2.8.1)
-    faraday (1.5.1)
+    faraday (1.7.0)
       faraday-em_http (~> 1.0)
       faraday-em_synchrony (~> 1.0)
       faraday-excon (~> 1.1)
@@ -34,6 +34,7 @@ GEM
       faraday-net_http (~> 1.0)
       faraday-net_http_persistent (~> 1.1)
       faraday-patron (~> 1.0)
+      faraday-rack (~> 1.0)
       multipart-post (>= 1.2, < 3)
       ruby2_keywords (>= 0.0.4)
     faraday-em_http (1.0.0)
@@ -43,11 +44,12 @@ GEM
     faraday-net_http (1.0.1)
     faraday-net_http_persistent (1.2.0)
     faraday-patron (1.0.0)
+    faraday-rack (1.0.0)
     ffi (1.15.3)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (218)
-      github-pages-health-check (= 1.17.2)
+    github-pages (219)
+      github-pages-health-check (= 1.17.7)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
       jekyll-coffeescript (= 1.1.1)
@@ -90,11 +92,11 @@ GEM
       nokogiri (>= 1.10.4, < 2.0)
       rouge (= 3.26.0)
       terminal-table (~> 1.4)
-    github-pages-health-check (1.17.2)
+    github-pages-health-check (1.17.7)
       addressable (~> 2.3)
       dnsruby (~> 1.60)
       octokit (~> 4.0)
-      public_suffix (>= 2.0.2, < 5.0)
+      public_suffix (>= 3.0, < 5.0)
       typhoeus (~> 1.3)
     html-pipeline (2.14.0)
       activesupport (>= 2)
@@ -221,19 +223,19 @@ GEM
     kramdown-parser-gfm (1.1.0)
       kramdown (~> 2.0)
     liquid (4.0.3)
-    listen (3.6.0)
+    listen (3.7.0)
       rb-fsevent (~> 0.10, >= 0.10.3)
       rb-inotify (~> 0.9, >= 0.9.10)
     mercenary (0.3.6)
-    mini_portile2 (2.5.3)
+    mini_portile2 (2.6.1)
     minima (2.5.1)
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
     minitest (5.14.4)
     multipart-post (2.1.1)
-    nokogiri (1.11.7)
-      mini_portile2 (~> 2.5.0)
+    nokogiri (1.12.3)
+      mini_portile2 (~> 2.6.1)
       racc (~> 1.4)
     nokogumbo (2.0.5)
       nokogiri (~> 1.8, >= 1.8.4)

From f44b68c2d9208f705bb35ea1d97c063bdbddafa4 Mon Sep 17 00:00:00 2001
From: zzt <zhuangzhutao@gmail.com>
Date: Sat, 28 Aug 2021 00:38:23 +0800
Subject: [PATCH 217/749] make translation more native

update zh-hans translation of starting-a-project.md ane make it more readable and more native to a native Chinese.
---
 _articles/zh-hans/starting-a-project.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/_articles/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md
index b7b8b02b893..f8aae2ee1bb 100644
--- a/_articles/zh-hans/starting-a-project.md
+++ b/_articles/zh-hans/starting-a-project.md
@@ -1,6 +1,6 @@
 ---
 lang: zh-hans
-title: 开启一个开源项目
+title: 开始一个开源项目
 description: 从开源的世界汲取智慧，然后开始准备着手发起开源项目。
 class: beginners
 order: 2
@@ -13,15 +13,15 @@ redirect_from: /zh-cn/starting-a-project/
 
 ## 什么是开源,为什么要开源
 
-那你在考虑开始参与开源？恭喜！世界赞赏你的贡献。我们来谈谈开源是什么以及为什么人们这样做。
+如果你正在考虑开始参与开源，那么恭喜你！世界会感激你的贡献。首先我们来谈谈什么是开源以及为什么我们要开源。
 
 ### "开源"是什么意思？
 
 当一个项目被开源，这意味着**任何人都可以出于任何目的查看，使用，修改和分发你的项目**。 这些权限通过[开源许可](https://opensource.org/licenses)强制实施。
 
-开源是强大的，因为它降低了事物被采纳的障碍，允许想法迅速传播。
+开源是强大的，因为它降低了事物被采纳的障碍，使得我们的想法可以被迅速传播。
 
-要了解它的工作原理，想象你的朋友组织了一场聚餐，而你带去了一个樱桃派。
+接下来我们通过一个例子了解它的工作原理。想象你的朋友组织了一场聚餐，而你带去了一个樱桃派。
 
 * 每个人都尝了那个派（_使用_)
 * 派的味道棒极了！大家请你分享它的配方（_view_）
@@ -48,19 +48,19 @@ redirect_from: /zh-cn/starting-a-project/
 
 * **透明度：** 任何人都可以检查开源项目是否有错误或不一致。 透明度对[保加利亚](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美国](https://sourcecode.cio.gov/)等政府，银行或医疗保健等受监管行业以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全软件都很重要。
 
-开源并不仅仅限于软件。您可以开源任何事物，从数据集到书本。查看 [GitHub Explore](https://github.com/explore) 开找找有什么是你可以开源的。
+开源并不仅仅限于软件。您可以开源任何事物，从数据集到书本。查看 [GitHub Explore](https://github.com/explore) 来找找有什么是你可以开源的。
 
 ### 开源是指"免费"吗？
 
-开源最大的吸引之一是它不花钱。 但是，"免费"只是开源的总体价值的一个副产品。
+开源最大的吸引之一是它不花钱。 但是，"免费"只是开源的总体价值的一小部分。
 
 因为[开源许可证要求](https://opensource.org/osd-annotated)任何人可以几乎出于任何目的使用，修改和共享您的项目，项目本身往往是免费的。 如果该项目花钱使用，任何人也都可以合法地复制和使用免费版本。
 
 因此，大多数开源项目是免费的，但"免费"不是开源定义的一部分。 有些方法可以通过双重许可或有限功能间接地为开源项目收费，同时仍然遵守开源的官方定义。
 
-## 我应该启动自己的开源项目吗？
+## 我应该开始自己的开源项目吗？
 
-简单来说，答案是肯定的，因为无论结果如何，启动您自己的项目来了解开源的工作原理是一个好方法。
+简单来说，答案是肯定的，因为无论结果如何，开始一个您自己的开源项目来了解开源的工作原理是一个好方法。
 
 如果你从来没有创建过一个项目，你可能会担心人们会说什么，或者是否有人会注意到。 如果这听起来像你现在的状态，别担心，你并不孤独！
 

From e819bf3377aeae4e6e5b65f706169ad8e03e48e7 Mon Sep 17 00:00:00 2001
From: 180909 <734461790@qq.com>
Date: Fri, 3 Sep 2021 15:21:36 +0800
Subject: [PATCH 218/749] make translation more native

---
 _articles/zh-hans/building-community.md |  2 +-
 _articles/zh-hans/how-to-contribute.md  | 20 ++++++++++----------
 _articles/zh-hans/starting-a-project.md | 10 +++++-----
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/_articles/zh-hans/building-community.md b/_articles/zh-hans/building-community.md
index 00e8961b2fa..ac65ba58346 100644
--- a/_articles/zh-hans/building-community.md
+++ b/_articles/zh-hans/building-community.md
@@ -84,7 +84,7 @@ redirect_from: /zh-cn/building-community/
 
 ![middleman pull request](/assets/images/building-community/middleman_pr.png)
 
-[一份Mozilla研究发现](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) 如果贡献者在48小时内收到代码审查，他们会有很大的回头率，且极有可能会再次贡献。
+[Mozilla的一份研究发现](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) 如果贡献者在48小时内收到代码审查，他们会有很大的回头率，且极有可能会再次贡献。
 
 与项目有关的话题也可能发生在互联网的其它地方，例如Stack Overflow，Twitter，或者Reddit。你可以在像这样的一些网站设置通知，这样当有人提及项目时，可以即时的收到提醒。
 
diff --git a/_articles/zh-hans/how-to-contribute.md b/_articles/zh-hans/how-to-contribute.md
index 239d3699336..9e929be9807 100644
--- a/_articles/zh-hans/how-to-contribute.md
+++ b/_articles/zh-hans/how-to-contribute.md
@@ -15,7 +15,7 @@ redirect_from: /zh-cn/how-to-contribute/
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
-  在 \[自由代码\] 下工作，让我学习到了职业生涯中非常重要的技能，无论是大学还是实际的工作，我认为从开源项目中得到的收获的远大於我的贡献！
+  在 \[自由代码\] 下工作，让我学习到了职业生涯中非常重要的技能，无论是大学还是实际的工作，我认为从开源项目中得到的收获的远大于我的贡献！
   <p markdown="1" class="pquote-credit">
 — @errietta, ["我为何是如此的热衷于为开源软件贡献力量"](https://www.errietta.me/blog/open-source/)
   </p>
@@ -27,7 +27,7 @@ redirect_from: /zh-cn/how-to-contribute/
 
 ### 巩固现有技能
 
-无论是撰写代码、设计用户界面、图形设计、撰写文档、亦或是组织活动，假如你有实践的愿望，你总能在开源项目中找到自己的位置。
+无论是撰写代码、设计用户界面、图形设计、撰写文档、亦或是组织活动，只要你想做，你总能在开源项目中找到自己的位置。
 
 ### 遇见那些和你志趣相投之人
 
@@ -35,7 +35,7 @@ redirect_from: /zh-cn/how-to-contribute/
 
 ### 寻找导师，并且尝试帮助他人
 
-和他人共同在一个共享的项目下工作，这意味着需要向他人解释清楚自己是如何做的，同理，也需要向他人求助，询问别人是如何做的。相互学习和彼此教学对于每位参与者都能满载而归。
+和他人共同在一个共享的项目下工作，这意味着需要向他人解释清楚自己是如何做的，同理，也需要向他人求助，询问别人是如何做的。相互学习和彼此教学可以让每位参与者都能满载而归。
 
 ### 在公众间建立你的声誉（职业口碑）
 
@@ -109,12 +109,12 @@ redirect_from: /zh-cn/how-to-contribute/
 ### 你喜欢组织活动吗？
 
 * 链接重复的问题，并建议新的问题标签，使事物井井有条
-* 通过开放的问题，并建议关闭旧的，[就像 @nzakas 为 eslint 做的](https://github.com/eslint/eslint/issues/6765)
+* 通过开放新的问题，并建议关闭旧的，[就像 @nzakas 为 eslint 做的](https://github.com/eslint/eslint/issues/6765)
 * 把最近开放的问题阐述清晰，以推动讨论
 
 ### 享受编码的乐趣？
 
-* 找到一个开放的问题并解决它，[就像 @dianjin 为 Leaflet 做的](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* 找到一个打开的问题并解决它，[就像 @dianjin 为 Leaflet 做的](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
 * 想一想你是否可以帮忙写一个新的功能
 * 自动化项目设置
 * 改进工具和测试
@@ -129,7 +129,7 @@ redirect_from: /zh-cn/how-to-contribute/
 
 * 为他人的提交审核代码
 * 为如何利用项目撰写教程
-* 为其他贡献者做导师，[正如 @ereichert 为 @bronzdoc 所做的那样，哦，是 Rust 项目](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+* 为其他贡献者做导师，[正如 @ereichert 为 @bronzdoc 在 Rust 项目中所做的那样](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
 
 ### 其实不必一定是软件项目！
 
@@ -169,8 +169,8 @@ redirect_from: /zh-cn/how-to-contribute/
 
 * **作者:** 项目的创始人或创始组织
 * **归属者:** 代码仓库或组织的管理员（不一定和作者是同一个人）
-* **维护者:** 贡献者，负责项目的未来走向和组织的管理（他们通常也是项目的作者或归属者。）
-* **贡献者:** 只要是为项目做出了贡献，就算。
+* **维护者:** 贡献者，负责项目的未来走向和组织的管理（他们通常也是项目的作者或归属者）
+* **贡献者:** 只要是为项目做出了贡献，就算是贡献者
 * **社区成员:** 那些使用项目的人们。他们或许是积极的讨论者，又或者是为项目的方向提出意见的人。
 
 一个较大的项目，可能下面还会细分子社区，或者是针对不同的任务分成不同的小组，比如工具小组、分流、社区事务、以及活动组织等。径直到项目到网站，找到"团队"页面，或者是查看治理文档，从而获得类似到信息。
@@ -422,7 +422,7 @@ redirect_from: /zh-cn/how-to-contribute/
 >
 > 😢 _"你为什么不修复我的问题？这难道不是你的项目吗？"_
 
-**尊重社区的决定。** 你的想法可能会和社区的优先级、愿景等有差异，他们可能对于你的想法提供了反馈和最后决定的理由，这时你应该去积极的讨论，并寻求妥协的办法，维护者必须慎重的考虑你的想法。但是如果你实在是不能同意社区的做法，你可以坚持下去！继续维护自己的分支，或者另起炉灶。
+**尊重社区的决定。** 你的想法可能会和社区的优先级、远景等有差异，他们可能对于你的想法提供了反馈和最后决定的理由，这时你应该去积极的讨论，并寻求妥协的办法，维护者必须慎重的考虑你的想法。但是如果你实在是不能同意社区的做法，你可以坚持下去！继续维护自己的分支，或者另起炉灶。
 
 > 😇 _"你不能支持我的用例，我很失望，但是你的解释仅仅是对一小部分用户起作用，我理解为什么。感谢你的耐心倾听。"_
 >
@@ -446,7 +446,7 @@ redirect_from: /zh-cn/how-to-contribute/
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
-  你能够从单个的项目学习到 <em>很多</em> ，只要你踊跃的去使用，在GitHub上密切观察项目，并阅读每一个 issue 和 PR。
+  你能够从单个的项目学习到 <em>很多</em> ，只要你踊跃的去使用，在 GitHub 上密切观察项目，并阅读每一个 issue 和 PR。
 <p markdown="1" class="pquote-credit">
 — @gaearon [参与项目](https://twitter.com/dan_abramov/status/819555257055322112)
   </p>
diff --git a/_articles/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md
index f8aae2ee1bb..e1dd6ae8a63 100644
--- a/_articles/zh-hans/starting-a-project.md
+++ b/_articles/zh-hans/starting-a-project.md
@@ -70,7 +70,7 @@ redirect_from: /zh-cn/starting-a-project/
 
 ### 设置你的目标
 
-目标可以帮助你弄清该做什么，不应该说什么，以及你在哪方面需要其他人的帮助。 首先问自己，_我是为什么开源这个项目？_
+目标可以帮助你弄清该做什么，不应该说什么，以及你在哪方面需要其他人的帮助。 首先问自己，_我为什么要开源这个项目？_
 
 这个问题没有标准答案。 对于一个项目你可以有多个目标，或者具有不同目标的不同项目。
 
@@ -104,7 +104,7 @@ redirect_from: /zh-cn/starting-a-project/
 
 如果你的目标是学习如何与他人合作或了解开源的工作方式，请考虑为现有项目做出贡献。从你已经使用并喜欢的项目开始。像修复拼写错误或更新文档简单的事也能为项目做出贡献。
 
-如果你不知道如何开始作为贡献者，请查看我们的[如何贡献开源指南](../how-to-contribute/)。
+如果你不知道如何开始成为贡献者，请查看我们的[如何贡献开源指南](../how-to-contribute/)。
 
 ## 发起你自己的开源项目
 
@@ -131,7 +131,7 @@ redirect_from: /zh-cn/starting-a-project/
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/),  和 [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) 都是非常流行的开源许可证， 但你可以选择[其他选项](https://choosealicense.com).
 
-当你在GitHub上创建新项目时，你可以选择许可证。包括开源许可证将使你的GitHub项目成为开源。
+当你在GitHub上创建新项目时，你可以选择许可证。包括开源许可证将使你的GitHub项目成为开源项目。
 
 ![挑选一个许可证](/assets/images/starting-a-project/repository-license-picker.png)
 
@@ -148,7 +148,7 @@ redirect_from: /zh-cn/starting-a-project/
 * 如何开始？
 * 如果需要，我可以在哪里获得更多的帮助？
 
-您可以使用自己的README回答其他问题，例如处理贡献，项目的目标以及许可证和归属信息。 如果您不想接受他人的贡献，或者您的项目尚未准备好作为产品提供使用，请将这些信息写下来。
+您可以使用自己的 README 回答其他问题，例如处理贡献，项目的目标以及许可证和归属信息。 如果您不想接受他人的贡献，或者您的项目尚未准备好作为产品提供使用，请将这些信息写下来。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
@@ -166,7 +166,7 @@ redirect_from: /zh-cn/starting-a-project/
 
 ### 编写你的贡献指南
 
-贡献文件 (CONTRIBUTING file) 告诉你的受众如何参与你的项目. 例如，你可以包括一下信息:
+贡献文件 (CONTRIBUTING 文件) 告诉你的受众如何参与你的项目. 例如，你可以包括以下信息:
 
 * 如何提交错误报告（尝试使用[issue 和 pull request 模板](https://github.com/blog/2111-issue-and-pull-request-templates)）
 * 如何建议一个新功能

From e1c019f55d44eb2800da16517b6670a3422538a6 Mon Sep 17 00:00:00 2001
From: Yumin Wong <itsbagpack@github.com>
Date: Wed, 8 Sep 2021 15:44:36 +0000
Subject: [PATCH 219/749] Add stale action, remove stale bot

---
 .github/stale.yml           | 22 ----------------------
 .github/workflows/stale.yml | 22 ++++++++++++++++++++++
 2 files changed, 22 insertions(+), 22 deletions(-)
 delete mode 100644 .github/stale.yml
 create mode 100644 .github/workflows/stale.yml

diff --git a/.github/stale.yml b/.github/stale.yml
deleted file mode 100644
index a1337918988..00000000000
--- a/.github/stale.yml
+++ /dev/null
@@ -1,22 +0,0 @@
-# Configuration for probot-stale - https://github.com/probot/stale
-
-# Number of days of inactivity before an Issue or Pull Request becomes stale
-daysUntilStale: 60
-# Number of days of inactivity before a stale Issue or Pull Request is closed
-daysUntilClose: 7
-# Issues or Pull Requests with these labels will never be considered stale
-exemptLabels:
-  - pinned
-  - security
-  - translation
-# Label to use when marking as stale
-staleLabel: stale
-# Comment to post when marking as stale. Set to `false` to disable
-markComment: >
-  This issue has been automatically marked as stale because it has not had
-  recent activity. It will be closed if no further activity occurs. Thank you
-  for your contributions.
-# Comment to post when closing a stale Issue or Pull Request. Set to `false` to disable
-closeComment: false
-# Limit to only `issues` or `pulls`
-# only: issues
diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
new file mode 100644
index 00000000000..24ed59cf5c7
--- /dev/null
+++ b/.github/workflows/stale.yml
@@ -0,0 +1,22 @@
+name: Mark stale issues
+on:
+  workflow_dispatch:
+  schedule:
+  - cron: "0 12 * * *"
+
+jobs:
+  stale:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/stale@v3
+      with:
+        stale-issue-message: >
+          This issue has been automatically marked as stale because it has not
+          had recent activity. It will be closed if no further activity occurs.
+          Thank you for your contributions.
+        stale-issue-label: "stale"
+        exempt-issue-labels: "pinned,security,translation"
+        days-before-issue-stale: 60
+        days-before-issue-close: 7
+        ascending: true
+        operations-per-run: 100

From f7c07af100f324afa50a0a564a794d5ce8fc871b Mon Sep 17 00:00:00 2001
From: Hamed Takmil <silvercover@users.noreply.github.com>
Date: Thu, 9 Sep 2021 01:07:44 +0430
Subject: [PATCH 220/749] Fixed typo.

---
 _articles/fa/code-of-conduct.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/fa/code-of-conduct.md b/_articles/fa/code-of-conduct.md
index 8fe34e93cf7..c007dd7224b 100644
--- a/_articles/fa/code-of-conduct.md
+++ b/_articles/fa/code-of-conduct.md
@@ -12,7 +12,7 @@ related:
 
 ## چرا به منشور اخلاقی نیاز داریم؟
 
-منشور اخلاقی سندی است که انتظارات مربوط به رفتار را برای شرکت‌کنندگان پروژه تعیین می‌کند. تصویب و اجرای منشور اخلاقی می‌تواند به ایجاد جو اجتماعی مثبت و سازنده برای انجمن شما کمک کند.
+منشور اخلاقی سندی است که انتظارات مربوط به رفتار را برای شرکت‌کنندگان پروژه تعیین میکند. تصویب و اجرای منشور اخلاقی می‌تواند به ایجاد جو اجتماعی مثبت و سازنده برای انجمن شما کمک کند.
 
 منشور اخلاقی نه تنها از شرکت‌کنندگان پروژه بلکه از شما هم محافظت می‌کند. اگر شما از پروژه‌ای نگهداری می‌کنید، ممکن است متوجه شده باشید که نگرش‌های مخرب از طرف دیگر شرکت‌کنندگان باعث می‌شود در طول کار از کار خود خسته یا ناراضی شوید.
 
@@ -27,7 +27,7 @@ related:
 * منشور اخلاقی در چه جاهایی اعمال می‌شود _(فقط در مورد مشکلات و درخواست‌های pull، یا دیگر فعالیت‌های انجمن مانند رویدادها؟)_
 * منشور اخلاقی برای چه کسانی اعمال می‌شود _(اعضای انجمن و نگه‌دارندگان، در مورد حامیان مالی چطور؟)_
 * اگر کسی منشور اخلاقی را نقض کند چه اتفاقی می‌افتد؟
-* چگونه می‌توان تخلفات را گزارش داد؟
+* چگونه می‌توان تخلفها را گزارش داد؟
 
 در هر جا که می‌توانید، از دانش پیشین خود استفاده کنید. [عهدنامۀ مشارکت‌کنندگان](https://contributor-covenant.org/) نوعی منشور اخلاقی جا افتاده و مقبول است که بیش از 40،000 پروژۀ متن باز از جمله «Kubernetes»، « «Rails و «Swift» از آن استفاده می‌کنند.
 

From 4950925b36775b4f3a855107014f26eb606093e6 Mon Sep 17 00:00:00 2001
From: Yumin Wong <itsbagpack@github.com>
Date: Thu, 9 Sep 2021 15:38:40 -0500
Subject: [PATCH 221/749] Apply suggestions from code review

Co-authored-by: Mike McQuaid <mike@mikemcquaid.com>
---
 .github/workflows/stale.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
index 24ed59cf5c7..701d12368e8 100644
--- a/.github/workflows/stale.yml
+++ b/.github/workflows/stale.yml
@@ -15,8 +15,8 @@ jobs:
           had recent activity. It will be closed if no further activity occurs.
           Thank you for your contributions.
         stale-issue-label: "stale"
-        exempt-issue-labels: "pinned,security,translation"
-        days-before-issue-stale: 60
+        exempt-issue-labels: "pinned,security"
+        days-before-issue-stale: 30
         days-before-issue-close: 7
         ascending: true
         operations-per-run: 100

From 8a1853bb8c0b7868366d9c463f21d3006c4c76e9 Mon Sep 17 00:00:00 2001
From: Yumin Wong <itsbagpack@github.com>
Date: Thu, 9 Sep 2021 21:30:48 +0000
Subject: [PATCH 222/749] Replace issue with pull request

---
 .github/workflows/stale.yml | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
index 701d12368e8..9afa085d578 100644
--- a/.github/workflows/stale.yml
+++ b/.github/workflows/stale.yml
@@ -1,4 +1,4 @@
-name: Mark stale issues
+name: Mark stale PRs
 on:
   workflow_dispatch:
   schedule:
@@ -10,13 +10,13 @@ jobs:
     steps:
     - uses: actions/stale@v3
       with:
-        stale-issue-message: >
-          This issue has been automatically marked as stale because it has not
+        stale-pr-message: >
+          This pull request has been automatically marked as stale because it has not
           had recent activity. It will be closed if no further activity occurs.
           Thank you for your contributions.
-        stale-issue-label: "stale"
-        exempt-issue-labels: "pinned,security"
-        days-before-issue-stale: 30
-        days-before-issue-close: 7
+        stale-pr-label: "stale"
+        exempt-pr-labels: "pinned,security"
+        days-before-pr-stale: 30
+        days-before-pr-close: 7
         ascending: true
         operations-per-run: 100

From 125d36c116d7b84dc90f216f9d17ceb9d56ddacc Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 13 Sep 2021 08:08:27 +0000
Subject: [PATCH 223/749] Bump actions/stale from 3 to 4

Bumps [actions/stale](https://github.com/actions/stale) from 3 to 4.
- [Release notes](https://github.com/actions/stale/releases)
- [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/stale/compare/v3...v4)

---
updated-dependencies:
- dependency-name: actions/stale
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/stale.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
index 9afa085d578..b3a482739c9 100644
--- a/.github/workflows/stale.yml
+++ b/.github/workflows/stale.yml
@@ -8,7 +8,7 @@ jobs:
   stale:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/stale@v3
+    - uses: actions/stale@v4
       with:
         stale-pr-message: >
           This pull request has been automatically marked as stale because it has not

From 4d0c3dfff264c92cd7cf7c240742809406a4a331 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <silvercover@users.noreply.github.com>
Date: Tue, 14 Sep 2021 17:40:14 +0430
Subject: [PATCH 224/749] 2 unnecessary characters removed.

---
 _articles/fa/code-of-conduct.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/fa/code-of-conduct.md b/_articles/fa/code-of-conduct.md
index c007dd7224b..bffbfda5e87 100644
--- a/_articles/fa/code-of-conduct.md
+++ b/_articles/fa/code-of-conduct.md
@@ -12,7 +12,7 @@ related:
 
 ## چرا به منشور اخلاقی نیاز داریم؟
 
-منشور اخلاقی سندی است که انتظارات مربوط به رفتار را برای شرکت‌کنندگان پروژه تعیین میکند. تصویب و اجرای منشور اخلاقی می‌تواند به ایجاد جو اجتماعی مثبت و سازنده برای انجمن شما کمک کند.
+منشور اخلاقی سندی است که انتظارات مربوط به رفتار را برای شرکت‌کنندگان پروژه تعیین میکند. تصویب و اجرای منشور اخلاقی می‌تواند به ایجاد جو اجتماعی مثبت و سازنده برای انجمن شما کمک کند.
 
 منشور اخلاقی نه تنها از شرکت‌کنندگان پروژه بلکه از شما هم محافظت می‌کند. اگر شما از پروژه‌ای نگهداری می‌کنید، ممکن است متوجه شده باشید که نگرش‌های مخرب از طرف دیگر شرکت‌کنندگان باعث می‌شود در طول کار از کار خود خسته یا ناراضی شوید.
 
@@ -27,7 +27,7 @@ related:
 * منشور اخلاقی در چه جاهایی اعمال می‌شود _(فقط در مورد مشکلات و درخواست‌های pull، یا دیگر فعالیت‌های انجمن مانند رویدادها؟)_
 * منشور اخلاقی برای چه کسانی اعمال می‌شود _(اعضای انجمن و نگه‌دارندگان، در مورد حامیان مالی چطور؟)_
 * اگر کسی منشور اخلاقی را نقض کند چه اتفاقی می‌افتد؟
-* چگونه می‌توان تخلفها را گزارش داد؟
+* چگونه می‌توان تخلفها را گزارش داد؟
 
 در هر جا که می‌توانید، از دانش پیشین خود استفاده کنید. [عهدنامۀ مشارکت‌کنندگان](https://contributor-covenant.org/) نوعی منشور اخلاقی جا افتاده و مقبول است که بیش از 40،000 پروژۀ متن باز از جمله «Kubernetes»، « «Rails و «Swift» از آن استفاده می‌کنند.
 

From 239498b55f73adedf3899f2280abcd14fbbb964d Mon Sep 17 00:00:00 2001
From: Hamed Takmil <silvercover@users.noreply.github.com>
Date: Tue, 14 Sep 2021 17:56:53 +0430
Subject: [PATCH 225/749] Language abbreviation changed.

---
 _articles/fa/metrics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/metrics.md b/_articles/fa/metrics.md
index ed8169a2a85..c9ea1afd70a 100644
--- a/_articles/fa/metrics.md
+++ b/_articles/fa/metrics.md
@@ -1,5 +1,5 @@
 ---
-lang: en
+lang: fa
 title: سنجه‌های پروژه‌های متن باز
 description: آگاهانه تصمیم‌گیری کنید تا با ارزیابی و پیگیری موفقیت، به پیشرفت پروژۀ متن باز خود کمک کنید.
 class: metrics

From 96275029f05efc17498a10a7064300780e7c191d Mon Sep 17 00:00:00 2001
From: Hamed Takmil <silvercover@users.noreply.github.com>
Date: Tue, 14 Sep 2021 17:58:38 +0430
Subject: [PATCH 226/749] Apostrophes replaced with straight apostrophes.

---
 _articles/fa/metrics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/metrics.md b/_articles/fa/metrics.md
index c9ea1afd70a..ed8169a2a85 100644
--- a/_articles/fa/metrics.md
+++ b/_articles/fa/metrics.md
@@ -1,5 +1,5 @@
 ---
-lang: fa
+lang: en
 title: سنجه‌های پروژه‌های متن باز
 description: آگاهانه تصمیم‌گیری کنید تا با ارزیابی و پیگیری موفقیت، به پیشرفت پروژۀ متن باز خود کمک کنید.
 class: metrics

From d50cab314e096e2686e7a2cd97b3d1868e4906c8 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <silvercover@users.noreply.github.com>
Date: Tue, 14 Sep 2021 17:59:04 +0430
Subject: [PATCH 227/749] Update metrics.md

---
 _articles/fa/metrics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/metrics.md b/_articles/fa/metrics.md
index ed8169a2a85..c9ea1afd70a 100644
--- a/_articles/fa/metrics.md
+++ b/_articles/fa/metrics.md
@@ -1,5 +1,5 @@
 ---
-lang: en
+lang: fa
 title: سنجه‌های پروژه‌های متن باز
 description: آگاهانه تصمیم‌گیری کنید تا با ارزیابی و پیگیری موفقیت، به پیشرفت پروژۀ متن باز خود کمک کنید.
 class: metrics

From 2db518a2192b78e93391031050171d16bd05319a Mon Sep 17 00:00:00 2001
From: Hamed Takmil <silvercover@users.noreply.github.com>
Date: Tue, 14 Sep 2021 18:12:05 +0430
Subject: [PATCH 228/749] Language abbreviation changed.

---
 _articles/fa/finding-users.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/finding-users.md b/_articles/fa/finding-users.md
index 86da3a98df0..4ad030f8af4 100644
--- a/_articles/fa/finding-users.md
+++ b/_articles/fa/finding-users.md
@@ -1,5 +1,5 @@
 ---
-lang: en
+lang: fa
 title: پیدا کردن کاربر برای پروژه‌هایتان
 description: با داشتن کاربرانی راضی و خوشحال، به پروژه‌ی اوپن سورس خود کمک کنید تا رشد کند..
 class: finding

From bc40f4fd6973b086ac76336ef21b54ff70a09616 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <info@daneshfarm.com>
Date: Tue, 14 Sep 2021 18:46:18 +0430
Subject: [PATCH 229/749] Inner space in strong removed

---
 _articles/fa/finding-users.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/finding-users.md b/_articles/fa/finding-users.md
index 4ad030f8af4..28e6316e9d5 100644
--- a/_articles/fa/finding-users.md
+++ b/_articles/fa/finding-users.md
@@ -76,7 +76,7 @@ related:
 ببینید آیا می‌توانید روش‌هایی برای به اشتراک گذاشتن پروژه خود به صورت متناسبی پیدا کنید:
 
 * **با پروژه‌ها و انجمن‌های اوپن سورس مرتبط و مدنظرتان آشنا شوید.** گاهی اوقات، لازم نیست که مستقیماً پروژه‌ی خود را تبلیغ کنید. اگر پروژه‌ی شما برای متخصصین علم داده که از پایتون استفاده می‌کنند عالی است، با انجمن علوم داده‌ی پایتون ملاقات کنید و آشنا شوید. هنگامی که مردم با شما آشنا شوند، فرصت‌ها به صورت خودکار و طبیعی برای بحث و گقت و گو و به اشتراک گذاشتن کارهای شما بوجود می‌آید.
-* **افرادی که مشکلاتی دارند و پروژه‌ی شما، آن مشکلات را حل و فصل می‌کند را پیدا کنید. **از طریق تالارهای گفتگوی (فروم‌ها) مرتبط، به جستجوی افرادی که می‌توانندمخاطبانِ هدفِ پروژه‌ی شما باشند، بپردازید. به سوالات آن‌ها پاسخ دهید و در زمانی مناسب، روشی مدبرانه تعبیه کنید تا پروژه‌ی خود را به عنوان یک راه‌حل پیشنهاد دهید.
+* **افرادی که مشکلاتی دارند و پروژه‌ی شما، آن مشکلات را حل و فصل می‌کند را پیدا کنید.**از طریق تالارهای گفتگوی (فروم‌ها) مرتبط، به جستجوی افرادی که می‌توانندمخاطبانِ هدفِ پروژه‌ی شما باشند، بپردازید. به سوالات آن‌ها پاسخ دهید و در زمانی مناسب، روشی مدبرانه تعبیه کنید تا پروژه‌ی خود را به عنوان یک راه‌حل پیشنهاد دهید.
 * **از انتقادات و پیشنهادات روی‌گردان نباشید.** خود و کارهایتان را به مخاطب‌هایی مرتبط و متناسب که به کار شما علاقه دارند، معرفی کنید. مخاطبان خود را بشناسید و کسانی که از پروژه‌ی شما سود و منفعت حاصل می‌کنند را مشخص کنید. سعی کنید این جمله را کامل کنید:  «من فکر می‌کنم پروژه‌ی من واقعاً به X، که در تلاش برای انجام کار Y است، کمک خواهد کرد». به جای اینکه صرفاً فقط کار خود را تبلیغ کنید، به بازخورد دیگران گوش دهید و پاسخگو باشید.
 
 به طور کلی، به کمک کردن به دیگران تمرکز کنید قبل از اینکه چیزهایی را در عوض درخواست کنید؛ چونکه که اگر هر کسی بخواهد پروژه‌های خودش را به صورت آنلاین تبلیغ کند، همهمه و شلوغی زیادی بر پا خواهد شد. برای اینکه در جمعی شناخته شوید، سعی کنید خود را به دیگران معرفی کنید و نه اینکه فقط آنچه که می‌خواهید را بازگو کنید.

From fde61ad0a33932f3e850c2e2e1afb263f535e1db Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Tue, 14 Sep 2021 18:57:52 +0430
Subject: [PATCH 230/749] Inner space removed in link.

---
 _articles/fa/leadership-and-governance.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/leadership-and-governance.md b/_articles/fa/leadership-and-governance.md
index 2aa7c8a70b4..36c285aa8be 100644
--- a/_articles/fa/leadership-and-governance.md
+++ b/_articles/fa/leadership-and-governance.md
@@ -98,7 +98,7 @@ related:
 * **BDFL** مخفف "Benevolent Dictator for Life" یا «دیکتاتور خیرخواه جاویدان» است تحت این ساختار،  یک نفر (معمولاً نویسنده‌ی اولیه‌ی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را می‌زند. [Python](https://github.com/python)، نمونه‌ای موثق در این مورد است. پروژه‌های کوچک‌تر احتمالاً به طور پیش‌فرض به صورت «BDFL» هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژه‌هایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقه‌بندی «BDFL» قرار گیرند
 
 
-* **Meritocracy:** (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماع‌ها، مفهومی منفی دارد و ساختار آن [دارای پیشینه‌ی پیچیده‌ی اجتماعی و سیاسی ](http://geekfeminism.wikia.com/wiki/Meritocracy).)است.) تحت ساختار «شایسته سالاری»، به مشارکت‌کنندگان فعال پروژه (کسانی که از «شایستگی» نشان می‌دهند) نقش تصمیم‌گیرندگی رسمی داده می‌شود. تصمیم‌‌ها، معمولاً براساس اجماع رای گرفته می‌شوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد «Apache»، به وجود آمد. تمامی پروژه‌های «Apache» بر اساس شایسته سالاری هستند. مشارکت‌ها فقط توسط افراد حقیقی صورت می‌گیرد؛ نه توسط یک شرکت.
+* **Meritocracy:** (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماع‌ها، مفهومی منفی دارد و ساختار آن [دارای پیشینه‌ی پیچیده‌ی اجتماعی و سیاسی](http://geekfeminism.wikia.com/wiki/Meritocracy).)است.) تحت ساختار «شایسته سالاری»، به مشارکت‌کنندگان فعال پروژه (کسانی که از «شایستگی» نشان می‌دهند) نقش تصمیم‌گیرندگی رسمی داده می‌شود. تصمیم‌‌ها، معمولاً براساس اجماع رای گرفته می‌شوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد «Apache»، به وجود آمد. تمامی پروژه‌های «Apache» بر اساس شایسته سالاری هستند. مشارکت‌ها فقط توسط افراد حقیقی صورت می‌گیرد؛ نه توسط یک شرکت.
 
 
 * **Liberal contribution:** (مشارکت آزادنه) تحت مدل مشارکت آزادانه، افرادی که بیشترین کار را انجام می‌دهند به عنوان تأثیرگذارترین افراد شناخته می‌شوند، اما این مدل براساس کاری که اکنون انجام می‌دهند است و نه مشارکت‌های که در گذشته داشته‌اند. تصمیمات بزرگ‌ پروژه بر اساس فرآیندی در اجتماع به صورت اجماعی (بحث‌ در مورد مسائل اساسی) به جای رأی‌گیری تنها گرفته می‌شود، و تلاش می‌شود تا آنجا که ممکن است دیدگاه‌های بیشتری از اجتماع را شامل شود. از جمله پروژه‌هایی که از مدل مشارکت آزادانه استفاده کردند، می‌توان [Node.js](https://foundation.nodejs.org/) و [Rust](https://www.rust-lang.org/) را نام برد.

From c6a08a5bca07d02c00545fade34d1732c8282f07 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Tue, 14 Sep 2021 18:59:00 +0430
Subject: [PATCH 231/749] Apostrophes replaced with straight apostrophes.

---
 _articles/fa/starting-a-project.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md
index bc6c3717201..c6a2ab0165f 100644
--- a/_articles/fa/starting-a-project.md
+++ b/_articles/fa/starting-a-project.md
@@ -38,7 +38,7 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 * **اقتباس و تغییر مجدد:** هر فردی تقریباً با هر هدفی می‌تواند از پروژه‌های متن باز استفاده کند. افراد حتی می‌توانند از یک پروژه، پروژه‌های دیگری به وجود بیاورند. به عنوان مثال می‌توانیم به [وردپرس](https://github.com/WordPress) اشاره کنیم که از پروژه موجودی به نام [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) منشعب شده است.
 
-* **شفافیت:** هرکسی می‌تواند خطاها و تناقض پروژه‌های متن باز را بازرسی کند. از این رو، شفافیت برای دولت‌هایی مانند دولت [بلغارستان](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) یا [ایالات متحده آمریکا](https://sourcecode.cio.gov/) و صنایع مقرراتی مانند بانکداری، مراکز بهداشت وُ درمانی و نرم‌افزار امنیتی مانند [Let’s Encrypt](https://github.com/letsencrypt) اهمیت بالایی پیدا می‌کند تا زمان بازرسی خطاها توسط افراد مختلف، دچار مشکل نشوند.
+* **شفافیت:** هرکسی می‌تواند خطاها و تناقض پروژه‌های متن باز را بازرسی کند. از این رو، شفافیت برای دولت‌هایی مانند دولت [بلغارستان](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) یا [ایالات متحده آمریکا](https://sourcecode.cio.gov/) و صنایع مقرراتی مانند بانکداری، مراکز بهداشت وُ درمانی و نرم‌افزار امنیتی مانند [Let's Encrypt](https://github.com/letsencrypt) اهمیت بالایی پیدا می‌کند تا زمان بازرسی خطاها توسط افراد مختلف، دچار مشکل نشوند.
 
 ویژگی متن باز فقط مختص به نرم‌افزارها نیست، شما هر چیزی حتی مجموعه‌ای از داده‌های یک کتابخانه را می‌توانید متن باز کنید. اگر می‌خواهید بیشتر بدانید که چه چیزهای دیگری را می‌شود متن باز کرد، می‌توانید به [GitHub Explore](https://github.com/explore) مراجعه کنید.
 
@@ -155,7 +155,7 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 بعضی از افراد از نوشتن فایل README خودداری می‌کنند، چون فکر می‌کنند پروژه‌ی آن‌ها هنوز تکمیل نشده یا اینکه نمی‌خواهند کسی مشارکتی داشته باشد. همین‌ها دلایل خیلی خوبی برای نوشتن یک فایل README محسوب می‌شوند.
 
-برای نوشتن یک فایل README کامل، می‌توانید به مقالات @dguo’s ["Make a README" guide](https://www.makeareadme.com/) یا @PurpleBooth’s [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) مراجعه کنید و از آن‌ها الهام بگیرید
+برای نوشتن یک فایل README کامل، می‌توانید به مقالات @dguo's ["Make a README" guide](https://www.makeareadme.com/) یا @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) مراجعه کنید و از آن‌ها الهام بگیرید
 
 زمانی که فایل README را در دایرکتوری ریشه خود قرار می‌دهید، GitHub به صورت خودکار آن را در صفحه‌ی اصلی repository (انبار) نشان می‌دهد.
 
@@ -184,7 +184,7 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 در طول زمان، ممکن است اطلاعات و سوالات مکرر زیادی به فایل CONTRIBUTING خود اضافه کنید. از این رو، افراد کمتری پیدا می‌شوند که سوالات تکراری از شما بپرسند.
 
-برای اینکه بدانید چگونه اطلاعات فایل 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 خود را بنویسید، می‌توانید به مقالات @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 هدایت می‌کند
 

From c923223032c9ccf1ffbb7e246b46d4a55c50eb47 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Tue, 14 Sep 2021 19:30:09 +0430
Subject: [PATCH 232/749] Unnecessary lines removed.

---
 _articles/fa/how-to-contribute.md  | 1 -
 _articles/fa/metrics.md            | 1 -
 _articles/fa/starting-a-project.md | 4 ----
 3 files changed, 6 deletions(-)

diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 86532f9c2d1..7a5a5571da4 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -160,7 +160,6 @@ related:
 
 بنابراین، قبل از اینکه کورکورانه با پیشنهادهای‌تان وارد کاری شوید، یاد بگیرید که چگونه در چت روم‌ها گفتگو کنید. این کار شانس شما را برای شنیده شدن و توجه به ایده‌هایتان را بالا می‌برد.
 
-
 ### آناتومی یک پروژه‌ی متن باز
 
 جامعه‌ها در پروژه‌های متن باز متفاوت هستند.
diff --git a/_articles/fa/metrics.md b/_articles/fa/metrics.md
index c9ea1afd70a..e00f8661e86 100644
--- a/_articles/fa/metrics.md
+++ b/_articles/fa/metrics.md
@@ -119,7 +119,6 @@ related:
 * بسته شدن مسائل قدیمی
 * متوسط زمان ادغام کردن درخواست‌های pull
 
-
 ## از آمار 📊 برای درک مردم استفاده کنید
 
 درک معیارها (استانداردها) به شما کمک می‌کند تا پروژۀ متن باز فعال و رو به‌ رشدی داشته باشید. حتی اگر هم تمامی معیارها را پیگیری نمی‌کنید، از چارچوب بالا استفاده کنید تا توجه خود را به نوع رفتاری که به پیشرفت پروژه کمک می‌کند متمرکز کنید.
diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md
index c6a2ab0165f..7db8ce6a79c 100644
--- a/_articles/fa/starting-a-project.md
+++ b/_articles/fa/starting-a-project.md
@@ -58,7 +58,6 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 کار یک پروژه‌ی متن باز مانند هر فعالیت خلاقانه‌ی دیگری مثل نویسندگی و نقاشی است. زمانی که شما به عنوان یک هنرمند اولین اثر خود را با دنیا به اشتراک می‌گذارید، احساس ترس به سراغتان می‌آید. اما این کار را باید انجام دهید، چون تمرین تنها راه بهتر شدن است؛ حتی اگر یک مخاطب هم نداشته باشید.
 
-
 اگر هنوز هم متقاعد نشدید، به این فکر کنید که اهداف‌تان چه چیزهایی می‌توانند باشند.
 
 ### اهداف‌تان را مشخص کنید
@@ -81,7 +80,6 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 اگرچه مدت زمانی که صرف کارهای غیرکدنویسی می‌کنید، به اندازه و دامنه‌ی پروژه‌یتان بستگی دارد، اما به عنوان یک مسئول‌نگهداری پروژه باید خودتان را آماده کنید آن‌ها را انجام دهید یا حداقل شخصی را پیدا کنید که در کارهای غیرکدنویسی به شما کمک کند.
 
-
 **اگر جزئی از یک پروژه‌ی متن باز یک شرکت هستید،** مطمئن شوید پروژه‌یتان منابع لازم داخلی برای پیشرفت را داشته باشد. از این رو، باید بدانید که چه کسی مسئول نگهداری پروژه‌ی متن بازتان است و چگونه می‌خواهید این وظایف را با جامعه‌ی خود به اشتراک بگذارید
 
 اگر برای ارتقاء، بهره‌برداری و نگهداری پروژه به بودجه خاص یا کارمند نیاز دارید، می‌توانید این نیازها را در ابتدا اعلام کنید.
@@ -142,7 +140,6 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 * چگونه شروع کردم؟
 * در صورت نیاز، از کجا می‌توانم کمک بیشتری دریافت کنم؟
 
-
 شما با فایل README می‌توانید به سایر سوالات نیز پاسخ دهید؛ سوالاتی مانند اینکه چگونه مشارکت‌تان را مدیریت می‌کنید، اهداف پروژه‌تان چیست و اطلاعات لایسنس و اختیارات پروژه‌تان را هم می‌توانید بیاورید. اگر مشارکت کسی را نمی‌خواهید قبول کنید، یا پروژه‌ی شما هنوز برای ارائه آماده نشده باشد، می‌توانید این توضیحات را در فایل README بیاورید
 
 <aside markdown="1" class="pquote">
@@ -167,7 +164,6 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 * چگونه ویژگی جدیدی پیشنهاد دهند
 * چگونه محیط پروژه‌تان را تنظیم و آن را برای تست اجرا کنند
 
-
 به علاوه، در فایل CONTRIBUTING می‌توانید جزئیات فنی و انتظارات‌تان را برای مشارکت‌کننده‌ها بیان کنید. به عنوان مثال:
 
 * نوع مشارکتی که به دنبال آن هستید

From 39ded204c436f3f27034a7ddc57878561e57f444 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Tue, 14 Sep 2021 19:43:00 +0430
Subject: [PATCH 233/749] Fixed typos.

---
 _articles/fa/starting-a-project.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md
index 7db8ce6a79c..ae40ceb8f7b 100644
--- a/_articles/fa/starting-a-project.md
+++ b/_articles/fa/starting-a-project.md
@@ -180,7 +180,7 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 در طول زمان، ممکن است اطلاعات و سوالات مکرر زیادی به فایل CONTRIBUTING خود اضافه کنید. از این رو، افراد کمتری پیدا می‌شوند که سوالات تکراری از شما بپرسند.
 
-برای اینکه بدانید چگونه اطلاعات فایل 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 خود را بنویسید، می‌توانید به مقالات @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 هدایت می‌کند
 
@@ -202,9 +202,9 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 علاوه بر اینکه یک آیین نامه‌ی رفتاری رفتارهایی که از شرکت‌کنند‌هایتان انتظار دارید را باید به آن‌ها بگوید، این را هم باید تعریف کنید که اجرای این انتظارات به چه کسانی و در چه زمان‌هایی باید انجام می‌شود. آیین نامه‌ی رفتاری همچنین مشخص می‌کند که درصورت بروز تخلف چه کاری باید انجام شود.
 
-مشابه استفاده از مجوزهایی که از قبل توسط دیگران تدوین شده استانداردهای نوظهوری برای آیین نامه‌ی رفتاری وجود دارد که لازم نیست خودتان آن را بنویسید. (https://contributor-covenant.org/)[Contributor Covenant] یکی از جاهایی است که آیین نامه‌هایی در همین خصوص ارائه می‌کند و حاصل کار آن در [بیش از 40.000 پروژه‌ی متن باز](https://www.contributor-covenant.org/adopters) مانند Kubernetes، Rails و Swift استفاده می‌شود. مهم نیست متن آیین نامه‌ی رفتاری شما چیست، مهم این است که در صورت لزوم باید از آیین نامه‌ی رفتاری خودتان استفاده کنید
+مشابه استفاده از مجوزهایی که از قبل توسط دیگران تدوین شده استانداردهای نوظهوری برای آیین نامه‌ی رفتاری وجود دارد که لازم نیست خودتان آن را بنویسید. [Contributor Covenant](https://contributor-covenant.org/) یکی از جاهایی است که آیین نامه‌هایی در همین خصوص ارائه می‌کند و حاصل کار آن در [بیش از 40.000 پروژه‌ی متن باز](https://www.contributor-covenant.org/adopters) مانند Kubernetes، Rails و Swift استفاده می‌شود. مهم نیست متن آیین نامه‌ی رفتاری شما چیست، مهم این است که در صورت لزوم باید از آیین نامه‌ی رفتاری خودتان استفاده کنید
 
-متن آیین نامه‌ی رفتاری خود را مستقیما در فایل CODE_OF_CONDUCT در repository (مخزن) گیت هاب خودتان کپی و پیست کنید. فایل را در دایرکتوری روت پروژه‌تان ذخیره کنید تا پیدا کردن و لینک دادن آن به فایل README راحت باشد.
+متن آیین نامه‌ی رفتاری خود را مستقیما در فایل CODE_OF_CONDUCT در مخزن گیت هاب خودتان کپی و پیست کنید. فایل را در دایرکتوری روت پروژه‌تان ذخیره کنید تا پیدا کردن و لینک دادن آن به فایل README راحت باشد.
 
 ## نام‌گذاری و برندسازی پروژه
 

From 0af4d363a59d4d5f9aea335fc3a9f6cae7ba1e14 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Tue, 14 Sep 2021 19:46:19 +0430
Subject: [PATCH 234/749] Fixed typo.

---
 _articles/fa/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 7a5a5571da4..e3ea019cc09 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -52,7 +52,7 @@ related:
 
 لازم نیست برای لذت بردن از همکاری در یک پروژه‌ی متن باز، به یک مشارکت‌کننده‌ی درازمدت تبدیل شوید. تا حالا شده در یک وب‌سایت چند غلط‌های املائی ببینید و دوست داشتید یک نفر آن را اصلاح کند؟ خب، گر چنین حالتی برای پروژه‌تان به وجود بیاید، به راحتی می‌توانید آن را برطرف کنید. پروژه‌ی متن باز می‌تواند به افراد کمک کند تا شرکتی که در آن فعالیت می‌کنند و نحوه‌ی کسب کردن تجربه‌شان را از زندگی خود مهم‌تر بدانند و همین مسئله حس رضایت‌بخشی به آن‌ها می‌دهد.
 
-## مشارکت به چه معناست؟
+### مشارکت به چه معناست؟
 
 اگر در مشارکت یک پروژه‌ی متن باز تازه‌وارد هستید، فرآیند آن می‌تواند ترسناک باشد. شما چگونه یک پروژه درست برای مشارکت کردن در آن را انتخاب می‌کنید؟ اگر چیزی از کد نویسی ندانید، چی؟ اگر چیزی درست پیش نرود، چی؟
 

From 0471388a49f4a8a13ea20adef08dd1a267fff062 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Tue, 14 Sep 2021 19:55:46 +0430
Subject: [PATCH 235/749] Update how-to-contribute.md

---
 _articles/fa/how-to-contribute.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index e3ea019cc09..4535ea1be7f 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -52,7 +52,8 @@ related:
 
 لازم نیست برای لذت بردن از همکاری در یک پروژه‌ی متن باز، به یک مشارکت‌کننده‌ی درازمدت تبدیل شوید. تا حالا شده در یک وب‌سایت چند غلط‌های املائی ببینید و دوست داشتید یک نفر آن را اصلاح کند؟ خب، گر چنین حالتی برای پروژه‌تان به وجود بیاید، به راحتی می‌توانید آن را برطرف کنید. پروژه‌ی متن باز می‌تواند به افراد کمک کند تا شرکتی که در آن فعالیت می‌کنند و نحوه‌ی کسب کردن تجربه‌شان را از زندگی خود مهم‌تر بدانند و همین مسئله حس رضایت‌بخشی به آن‌ها می‌دهد.
 
-### مشارکت به چه معناست؟
+## مشارکت به چه معناست؟
+
 
 اگر در مشارکت یک پروژه‌ی متن باز تازه‌وارد هستید، فرآیند آن می‌تواند ترسناک باشد. شما چگونه یک پروژه درست برای مشارکت کردن در آن را انتخاب می‌کنید؟ اگر چیزی از کد نویسی ندانید، چی؟ اگر چیزی درست پیش نرود، چی؟
 

From 2bd3655e257ffd2393d918010d47cd9c48bcfd86 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Tue, 14 Sep 2021 20:00:29 +0430
Subject: [PATCH 236/749] Update how-to-contribute.md

---
 _articles/fa/how-to-contribute.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 4535ea1be7f..7a5a5571da4 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -54,7 +54,6 @@ related:
 
 ## مشارکت به چه معناست؟
 
-
 اگر در مشارکت یک پروژه‌ی متن باز تازه‌وارد هستید، فرآیند آن می‌تواند ترسناک باشد. شما چگونه یک پروژه درست برای مشارکت کردن در آن را انتخاب می‌کنید؟ اگر چیزی از کد نویسی ندانید، چی؟ اگر چیزی درست پیش نرود، چی؟
 
 خب، نگران نباشید! راه‌های زیادی برای مشارکت در پروژه‌های متن باز وجود دارد که در ادامه‌ی مقاله مواردی از آن‌ها را می‌آوریم که می‌تواند به بدست آوردن تجربه‌های بیشتر به شما کمک کند.

From 6fef34d366847272b6e9a21c516e54c20302ad57 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Tue, 14 Sep 2021 20:37:18 +0430
Subject: [PATCH 237/749] Space removed.

---
 _articles/fa/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 7a5a5571da4..566da47c8aa 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -133,7 +133,7 @@ related:
 * کدنویسی سایر افراد را بررسی کنید
 * برای نحوه‌ی استفاده‌ی یک پروژه‌ی متن باز، مطلب آموزشی بنویسید
 * یک مشارکت کننده دیگر که می‌شناسید را پیشنهاد دهید، [مثل کاری که @ereichert در Rust برای @bronzdoc کرد](https://github.com/rust-lang/book/issues/123#issuecomment-238049666).
- 
+
 ### لازم نیست فقط روی پروژه‌های نرم‌افزاری وقت صرف کنید!
 
 با اینکه بیشتر پروژه‌های متن باز به نرم‌افزارها اطلاق می‌شود، اما می‌توانید هرچیزی از جمله کتاب‌ها، دستورالعمل، لیست چیزهای مختلف و کلاس‌ها را در پروژه‌های متن باز توسعه دهید.

From 3903d5a2671be326d9fc3f429891abf52b81a16c Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Tue, 14 Sep 2021 20:55:52 +0430
Subject: [PATCH 238/749] Update building-community.md

---
 _articles/fa/building-community.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md
index 54f26fbb2e0..e1fbec1692f 100644
--- a/_articles/fa/building-community.md
+++ b/_articles/fa/building-community.md
@@ -194,7 +194,7 @@ related:
 
 وقتی انجمن تان با یک موضوع خاص مواجه است، مجرب ها ممکن است داوطلب شوند. افراد ممکن است عصبی شوند یا اشباع شوند و آن وظیفه را به شما یا دیگری محول کنند.
 
-کارتان به عنوان یک نگاهدارنده آن است که از وخیم تر شدن شرایط جلوگیری کنید. حتی اگر شما عقیده قوی‌ای به این موضوع دارید، سعی کنید که جایگاه یک میانجی یا تسهیل کننده را داشته باشید به جای اینکه به نبرد با دیدگاه تان وارد شوید. اگر شخصی در حال بی مهر شدن است یا دارد مکالمات را انحصاری می سازد، [فوراً اقدام کنید](../building-community/#dont-tolerate-bad-actors) تا مباحثات را مدنی و سودمند نگه دارید.
+کارتان به عنوان یک نگاهدارنده آن است که از وخیم تر شدن شرایط جلوگیری کنید. حتی اگر شما عقیده قوی‌ای به این موضوع دارید، سعی کنید که جایگاه یک میانجی یا تسهیل کننده را داشته باشید به جای اینکه به نبرد با دیدگاه تان وارد شوید. اگر شخصی در حال بی مهر شدن است یا دارد مکالمات را انحصاری می سازد، [فوراً اقدام کنید](../building-community/#بازیگران-بد-را-تحمل-نکنید) تا مباحثات را مدنی و سودمند نگه دارید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">

From a2b036061bdef29bed9223272d81cf0da9bf6206 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Tue, 14 Sep 2021 21:02:58 +0430
Subject: [PATCH 239/749] Update building-community.md

---
 _articles/fa/building-community.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md
index e1fbec1692f..d105f112438 100644
--- a/_articles/fa/building-community.md
+++ b/_articles/fa/building-community.md
@@ -26,7 +26,7 @@ related:
 
 با مستندات خود شروع کنید:
 
-* **برای افراد استفاده از پروژه خود را ساده سازید:** یک مثال از آن کد واضح و [README دوستانه](../starting-a-project/#writing-a-readme) است که راه اندازی پروژه تان را برای هر کسی هموارتر می سازد.
+* **برای افراد استفاده از پروژه خود را ساده سازید:** یک مثال از آن کد واضح و [README دوستانه](../starting-a-project/#نوشتن-راهنمای-مشارکت) است که راه اندازی پروژه تان را برای هر کسی هموارتر می سازد.
 * **بطور واضح توضیح دهید که مشارکت چگونه است،** البته این کار با استفاده از [فایل مشارکت](../starting-a-project/#writing-your-contributing-guidelines) و به روز نگه داشتن موضوعات میسر است.
 
 * **موضوعات اولیه خوب:** برای کمک کردن به اینکه مشارکت کنندگان جدید کار خود را شروع کنند، [برچسب زدن به موضوعاتی که برای موفقیت مبتدی ها به قدر کافی ساده هستند](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) را بطور آشکار لحاظ کنید. سپس GitHub، این موضوعات را در محل های مختلف روی پلتفورم هموار می سازد، و مشارکت های مفید را افزایش می دهد و سپس ناسازگاری از کاربران مختلف در فائق آمدن بر موضوعاتی که در سطح آنها خیلی دشوار است را کاهش می دهد.
@@ -36,7 +36,7 @@ related:
 * **وقتی شخص جدیدی وارد پروژه شما می شود، از وی از روی علاقه تشکر کنید!** این یک تجربه منفی خواهد بود که از فردی بخواهید که از پروژه تان خارج نشود.
 * **پاسخگو باشید:** اگر شما به موضوعاتشان در عرض یک ماه پاسخ نمی دهید، شانس اینکه پروژه تان را فراموش کنند بالا می رود.
 * **درباره انواع مشارکت هایی که خواهید پذیرفت ، پذیرای عقاید و افکار جدید باشید.** بسیاری از مشارکت کننده ها با یک گزارش باگ یا ترمیم جزئی آغاز می کنند. راه های زیادی برای مشارکت در یک پروژه وجود دارد. به افراد اجازه دهید تا بازگو کنند [چطور می خواهند مساعدت کنند](../how-to-contribute/#what-it-means-to-contribute).
-* **اگر یک مشارکتی وجود دارد که شما با آن مخالف هستید،** از آنها به خاطر بیان ایده تشکر کرده و [توضیح دهید](../best-practices/#learning-to-say-no) چرا آن ایده با محدوده پروژه تان تناسب ندارد، و اگر مستندات خوبی دارید رو کنید.
+* **اگر یک مشارکتی وجود دارد که شما با آن مخالف هستید،** از آنها به خاطر بیان ایده تشکر کرده و [توضیح دهید](../best-practices/#نه-گفتن-را-یاد-بگیرید) چرا آن ایده با محدوده پروژه تان تناسب ندارد، و اگر مستندات خوبی دارید رو کنید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">

From 09e3dc095030aca8fb60e3dad610542119d0037b Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Tue, 14 Sep 2021 21:08:14 +0430
Subject: [PATCH 240/749] Update building-community.md

---
 _articles/fa/building-community.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md
index d105f112438..811e2ab046f 100644
--- a/_articles/fa/building-community.md
+++ b/_articles/fa/building-community.md
@@ -27,7 +27,7 @@ related:
 با مستندات خود شروع کنید:
 
 * **برای افراد استفاده از پروژه خود را ساده سازید:** یک مثال از آن کد واضح و [README دوستانه](../starting-a-project/#نوشتن-راهنمای-مشارکت) است که راه اندازی پروژه تان را برای هر کسی هموارتر می سازد.
-* **بطور واضح توضیح دهید که مشارکت چگونه است،** البته این کار با استفاده از [فایل مشارکت](../starting-a-project/#writing-your-contributing-guidelines) و به روز نگه داشتن موضوعات میسر است.
+* **بطور واضح توضیح دهید که مشارکت چگونه است،** البته این کار با استفاده از [فایل مشارکت](../starting-a-project/#نوشتن-راهنمای-مشارکت) و به روز نگه داشتن موضوعات میسر است.
 
 * **موضوعات اولیه خوب:** برای کمک کردن به اینکه مشارکت کنندگان جدید کار خود را شروع کنند، [برچسب زدن به موضوعاتی که برای موفقیت مبتدی ها به قدر کافی ساده هستند](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) را بطور آشکار لحاظ کنید. سپس GitHub، این موضوعات را در محل های مختلف روی پلتفورم هموار می سازد، و مشارکت های مفید را افزایش می دهد و سپس ناسازگاری از کاربران مختلف در فائق آمدن بر موضوعاتی که در سطح آنها خیلی دشوار است را کاهش می دهد.
 
@@ -210,7 +210,7 @@ related:
 
 ### فایل README خود را به عنوان یک قانون اساسی در نظر بگیرید
 
-فایل README تان [بیشتر از یک مجموعه رهنمودها است](../starting-a-project/#writing-a-readme)، همچنین یک محلی برای گفتگو درباره اهداف، دیدگاه و نقشه مسیرتان است. اگر افراد آشکارا روی بحث درباره ارزش یک ویژگی خاص تمرکز می کنند، این کار به تجدیدنظر درباره README تان و صحبت درباره دیدگاه بهتر درباره پروژه تان کمک می کند. تمرکز روی README تان همچنین این مکالمات را غیرمحرمانه می سازد، بنابراین شما می توانید یک بحث سازنده را دنبال کنید.
+فایل README تان [بیشتر از یک مجموعه رهنمودها است](../starting-a-project/#نوشتن-رهنمای-مشارکت)، همچنین یک محلی برای گفتگو درباره اهداف، دیدگاه و نقشه مسیرتان است. اگر افراد آشکارا روی بحث درباره ارزش یک ویژگی خاص تمرکز می کنند، این کار به تجدیدنظر درباره README تان و صحبت درباره دیدگاه بهتر درباره پروژه تان کمک می کند. تمرکز روی README تان همچنین این مکالمات را غیرمحرمانه می سازد، بنابراین شما می توانید یک بحث سازنده را دنبال کنید.
 
 ### تمرکز روی سفر نه مقصد
 

From d412ef751235b20b6002f1651b7656d93c828232 Mon Sep 17 00:00:00 2001
From: Hamed Takmil <ham55464@yahoo.com>
Date: Tue, 14 Sep 2021 21:13:54 +0430
Subject: [PATCH 241/749] Broken links fixed.

---
 _articles/fa/building-community.md | 2 +-
 _articles/fa/code-of-conduct.md    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md
index 811e2ab046f..ad31d19e706 100644
--- a/_articles/fa/building-community.md
+++ b/_articles/fa/building-community.md
@@ -210,7 +210,7 @@ related:
 
 ### فایل README خود را به عنوان یک قانون اساسی در نظر بگیرید
 
-فایل README تان [بیشتر از یک مجموعه رهنمودها است](../starting-a-project/#نوشتن-رهنمای-مشارکت)، همچنین یک محلی برای گفتگو درباره اهداف، دیدگاه و نقشه مسیرتان است. اگر افراد آشکارا روی بحث درباره ارزش یک ویژگی خاص تمرکز می کنند، این کار به تجدیدنظر درباره README تان و صحبت درباره دیدگاه بهتر درباره پروژه تان کمک می کند. تمرکز روی README تان همچنین این مکالمات را غیرمحرمانه می سازد، بنابراین شما می توانید یک بحث سازنده را دنبال کنید.
+فایل README تان [بیشتر از یک مجموعه رهنمودها است](../starting-a-project/#نوشتن-راهنمای-مشارکت)، همچنین یک محلی برای گفتگو درباره اهداف، دیدگاه و نقشه مسیرتان است. اگر افراد آشکارا روی بحث درباره ارزش یک ویژگی خاص تمرکز می کنند، این کار به تجدیدنظر درباره README تان و صحبت درباره دیدگاه بهتر درباره پروژه تان کمک می کند. تمرکز روی README تان همچنین این مکالمات را غیرمحرمانه می سازد، بنابراین شما می توانید یک بحث سازنده را دنبال کنید.
 
 ### تمرکز روی سفر نه مقصد
 
diff --git a/_articles/fa/code-of-conduct.md b/_articles/fa/code-of-conduct.md
index bffbfda5e87..219a6e62d23 100644
--- a/_articles/fa/code-of-conduct.md
+++ b/_articles/fa/code-of-conduct.md
@@ -40,7 +40,7 @@ related:
 <aside markdown="1" class="pquote">
   منشور اخلاقی‌ای که اجرا نمی‌شود (یا نمی‌توان آن را اجرا کرد) بدتر از نبود هیچ منشور اخلاقی‌ای می‌باشد: نبود منشور اخلاقی این پیام را با خود به همراه دارد که ارزش‌های درج شده در منشور اخلاقی در انجمن شما مهم نیستد و مورد احترام واقع نمی‌شوند.
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/)
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 

From 2526e21a103e4bbdfbe06f3a88fdd1729cee84ab Mon Sep 17 00:00:00 2001
From: aparus <rustamapaev@gmail.com>
Date: Fri, 7 Feb 2020 11:02:11 +0300
Subject: [PATCH 242/749] Russian translation

---
 _articles/ru/best-practices.md            | 287 ++++++++++++
 _articles/ru/building-community.md        | 280 ++++++++++++
 _articles/ru/code-of-conduct.md           | 120 +++++
 _articles/ru/finding-users.md             | 163 +++++++
 _articles/ru/getting-paid.md              | 191 ++++++++
 _articles/ru/how-to-contribute.md         | 534 ++++++++++++++++++++++
 _articles/ru/index.html                   |   6 +
 _articles/ru/leadership-and-governance.md | 153 +++++++
 _articles/ru/legal.md                     | 166 +++++++
 _articles/ru/metrics.md                   | 130 ++++++
 _articles/ru/starting-a-project.md        | 361 +++++++++++++++
 _data/locales/ru.yml                      |  31 ++
 _layouts/article.html                     |   8 +-
 13 files changed, 2426 insertions(+), 4 deletions(-)
 create mode 100644 _articles/ru/best-practices.md
 create mode 100644 _articles/ru/building-community.md
 create mode 100644 _articles/ru/code-of-conduct.md
 create mode 100644 _articles/ru/finding-users.md
 create mode 100644 _articles/ru/getting-paid.md
 create mode 100644 _articles/ru/how-to-contribute.md
 create mode 100644 _articles/ru/index.html
 create mode 100644 _articles/ru/leadership-and-governance.md
 create mode 100644 _articles/ru/legal.md
 create mode 100644 _articles/ru/metrics.md
 create mode 100644 _articles/ru/starting-a-project.md
 create mode 100644 _data/locales/ru.yml

diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md
new file mode 100644
index 00000000000..f782436bbca
--- /dev/null
+++ b/_articles/ru/best-practices.md
@@ -0,0 +1,287 @@
+---
+lang: ru
+title: Хорошие практики для сопровождающих
+description: Облегчите вашу жизнь в качестве сопровождающего открытого исходного кода, от документирования процессов до использования вашего сообщества.
+class: best-practices
+toc:
+  что-значит-быть-сопровождающим: 'Что значит быть сопровождающим?'
+  документирование-ваших-процессов: 'Документирование ваших процессов'
+  учитесь-говорить-нет: 'Учитесь говорить "нет"'
+  используйте-свое-сообщество: 'Используйте свое сообщество'
+  принесите-роботов: 'Принесите роботов'
+  нажать-паузу---это-нормально: 'Нажать паузу - это нормально'
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+  - metrics
+  - leadership
+---
+
+## Что значит быть сопровождающим?
+
+Если вы поддерживаете проект с открытым исходным кодом, которым пользуется множество людей, возможно, вы заметили, что меньше кодируете и больше отвечаете на проблемы.
+
+На ранних стадиях проекта вы экспериментируете с новыми идеями и принимаете решения, основанные на ваших желаниях. По мере роста популярности вашего проекта вы обнаружите, что больше работаете со своими пользователями и участниками.
+
+Для поддержки проекта требуется нечто большее, чем просто код. Эти задачи часто бывают неожиданными, но они не менее важны для растущего проекта. Мы собрали несколько способов облегчить вашу жизнь - от документирования процессов до привлечения вашего сообщества.
+
+## Документирование ваших процессов
+
+Записывать вещи - одна из самых важных вещей, которую вы можете делать как сопровождающий.
+
+Документация не только проясняет ваше собственное мышление, но и помогает другим людям понять, что вам нужно или чего вы ждете, еще до того, как они спросят.
+
+Записывая вещи, легче сказать «нет», когда что-то не вписывается в ваши рамки. Это также облегчает людям участие и помощь. Вы никогда не знаете, кто может читать или использовать ваш проект.
+
+Даже если вы не используете полные абзацы, лучше писать тезисы, чем не писать вообще.
+
+Не забывайте обновлять документацию. Если вы не можете делать это всегда, удалите устаревшую документацию или укажите, что она устарела, чтобы участники знали, что обновления приветствуются.
+
+### Запишите видение вашего проекта
+
+Начните с записи целей вашего проекта. Добавьте их в свой README или создайте отдельный файл с именем VISION. Если есть другие артефакты, которые могут помочь, например дорожная карта проекта, также сделайте их общедоступными.
+
+Наличие четкого, задокументированного видения позволяет вам сосредоточиться и избежать «расползания по масштабам» от вкладов других людей.
+
+Например, @lord обнаружил, что видение проекта помогло ему понять, на какие запросы следует потратить время. Как новый сопровождающий, он сожалел, что не придерживался масштабов своего проекта, когда получил свой первый запрос функции для [Slate](https://github.com/lord/slate).
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/lord?s=180" class = "pquote-avatar" alt = "avatar">
+  Я нащупал это. Я не прилагал усилий, чтобы найти полное решение. Вместо полупродуманного решения я хотел бы сказать: «У меня сейчас нет на это времени, но я добавлю его в долгосрочный список, который принято иметь».
+  <p markdown = "1" class = "pquote-credit">
+- @lord, [«Советы для новых разработчиков ПО с открытым исходным кодом»](https://lord.io/blog/2014/oss-tips/)
+  </p>
+</aside>
+
+### Сообщите о своих ожиданиях
+
+Написание правил может утомлять вас. Иногда вам может казаться, что вы следите за поведением других людей или убиваете все самое интересное.
+
+Однако хорошие правила написаны и соблюдаются справедливо и расширяют возможности специалистов по сопровождению. Они не дают вам быть втянутыми в дела, которые вы не хотите делать.
+
+Большинство людей, которые сталкиваются с вашим проектом, ничего не знают ни о вас, ни о ваших обстоятельствах. Они могут предположить, что вам платят за работу над этим, особенно если это то, чем они регулярно пользуются и от чего зависят. Может быть, в какой-то момент вы потратили много времени на свой проект, но теперь вы заняты новой работой или членом семьи.
+
+Все это нормально! Просто убедитесь, что об этом знают другие люди.
+
+Если поддержка вашего проекта осуществляется неполный рабочий день или осуществляется исключительно на добровольной основе, скажите честно, сколько у вас времени. Это не то же самое, сколько времени, по вашему мнению, требуется для проекта, или сколько времени другие хотят, чтобы вы потратили на него.
+
+Вот несколько правил, которые стоит записать:
+
+* Как отзыв рассматривается и принимается (_Нужны ли им тесты? Шаблон задачи?_)
+* Типы вклада, которые вы примете (_Вам нужна помощь только с определенной частью вашего кода?_)
+* Когда уместно следить (_например, «Вы можете ожидать ответа от сопровождающего в течение 7 дней. Если к тому времени вы ничего не услышали, не стесняйтесь пинговать тему»._)
+* Сколько времени вы тратите на проект (_например, «Мы тратим на этот проект всего около 5 часов в неделю»_)
+
+[Джекилл](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), и [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) - несколько примеров проектов с основными правилами для сопровождающих и участников.
+
+### Поддерживайте общедоступность
+
+Не забывайте также документировать свое общение. Везде, где вы можете, делитесь информацией о своем проекте публично. Если кто-то пытается связаться с вами в частном порядке, чтобы обсудить запрос функции или потребность в поддержке, вежливо направьте его на общедоступный канал связи, такой как список рассылки или средство отслеживания проблем (issues).
+
+Если вы встречаетесь с другими сопровождающими или принимаете важное решение в частном порядке, документируйте эти разговоры публично, даже если это просто публикация ваших заметок.
+
+Таким образом, любой, кто присоединится к вашему сообществу, будет иметь доступ к той же информации, что и тот, кто был там много лет.
+
+## Учитесь говорить "нет"
+
+Вы все записали. В идеале все бы читали вашу документацию, но на самом деле вам придется напоминать другим, что эти знания существуют.
+
+Однако если все записать, это поможет обезличить ситуации, когда вам действительно нужно обеспечить соблюдение своих правил.
+
+Сказать «нет» - это не весело, но _«Ваш вклад не соответствует критериям этого проекта»_ кажется менее личным, чем _«Мне не нравится ваш вклад»_.
+
+Сказать «нет» применимо ко многим ситуациям, с которыми вы столкнетесь как сопровождающий: запросы функций, которые не соответствуют проекту, кто-то срывает обсуждение, выполняет ненужную для других работу.
+
+### Поддерживайте дружескую беседу
+
+Одно из самых важных мест, где вы будете практиковаться, говоря «нет», - это проблемы (issues) и очередь запросов на перенос. Как сопровождающий проекта, вы неизбежно получите предложения, которые не захотите принимать.
+
+Возможно, чей-то вклад изменяет масштаб проекта или не соответствует вашему видению. Может идея хорошая, но реализация оставляет желать лучшего.
+
+Независимо от причины, можно тактично обращаться с материалами, которые не соответствуют стандартам вашего проекта.
+
+Если вы получаете вклад, который не хотите принимать, ваша первая реакция может заключаться в том, чтобы проигнорировать его или притвориться, что вы его не видели. Это может задеть чувства другого человека и даже лишить мотивации других потенциальных участников в вашем сообществе.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/krausefx?s=180" class = "pquote-avatar" alt = "avatar">
+  Ключ к поддержке крупномасштабных проектов с открытым исходным кодом - это решение проблем. Старайтесь избегать простаивания проблем (issues). Если вы разработчик iOS, вы знаете, как может быть неприятно отправлять сообщение об ошибке на "радар". Возможно, вы услышите ответ через 2 года и вам предложат повторить попытку с последней версией iOS.
+  <p markdown = "1" class = "pquote-credit">
+- @KrauseFx, [«Масштабирование сообществ с открытым исходным кодом»](https://krausefx.com/blog/scaling-open-source-communities)
+  </p>
+</aside>
+
+Не оставляйте нежелательный вклад открытым, потому что вы чувствуете себя виноватым или хотите вести себя хорошо. Со временем ваши оставшиеся без ответа вопросы и PR сделают работу над вашим проектом намного более напряженной и пугающей.
+
+Лучше сразу закрыть те взносы, которые вы не хотите принимать. Если ваш проект уже страдает от большого отставания, у @steveklabnik есть предложения [как эффективно сортировать проблемы](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+
+Во-вторых, игнорирование вкладов посылает негативный сигнал вашему сообществу. Участие в проекте может быть пугающим, особенно если это кто-то впервые. Даже если вы не принимаете их вклад, поблагодарите человека, стоящего за ним, за проявленный интерес. Это большой комплимент!
+
+Если вы не хотите принимать вклад:
+
+* **Поблагодарите их** за их вклад
+* **Объясните, почему это не вписывается** в рамки проекта, и, если можете, предложите четкие предложения по улучшению. Будьте добрыми, но твердыми.
+* **Ссылка на соответствующую документацию**, если она у вас есть. Если вы замечаете повторяющиеся запросы о вещах, которые не хотите принимать, добавьте их в свою документацию, чтобы не повторяться.
+* **Закройте заявку**
+
+Для ответа не должно быть более 1-2 предложений. Например, когда пользователь [celery](https://github.com/celery/celery/) сообщил об ошибке, связанной с Windows, @berkerpeksag [ответил](https://github.com/celery/celery/issues/3383):
+
+![Снимок экрана с сельдереем](/assets/images/best-practices/celery.png)
+
+Если мысль о том, чтобы сказать «нет», пугает вас, вы не одиноки. Как сказал @jessfraz [выразился](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> Я разговаривал с сопровождающими из нескольких различных проектов с открытым исходным кодом, Mesos, Kubernetes, Chromium, и все они согласны с тем, что одна из самых сложных частей работы сопровождающего - это сказать «нет» патчам, которые вам не нужны.
+
+Не чувствуйте себя виноватым из-за того, что не хотите принимать чей-то вклад. Первое правило открытого исходного кода, [согласно](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _«Нет - временно, да - навсегда»._ Сочувствовать энтузиазму другого человека - это хорошо. Отказ от вклада - это не то же самое, что отказ от человека, стоящего за ним.
+
+В конечном итоге, если вклад недостаточно хорош, вы не обязаны его принимать. Будьте добры и отзывчивы, когда люди вносят свой вклад в ваш проект, но принимайте только те изменения, которые, по вашему мнению, сделают ваш проект лучше. Чем чаще вы практикуетесь говорить «нет», тем легче это становится. Обещаю.
+
+### Быть инициативным
+
+Чтобы уменьшить объем нежелательных вкладов, в первую очередь, объясните процесс отправки и принятия вкладов в вашем проекте в своем руководстве по участию.
+
+Если вы получаете слишком много некачественных материалов, потребуйте от участников заранее поработать, например:
+
+* Заполнить шаблон/контрольный список для проблемы (issue) и запроса на перенос (pull request)
+* Открыть проблему перед отправкой запроса на перенос
+
+Если они не соблюдают ваши правила, немедленно закройте проблему и укажите на свою документацию.
+
+Поначалу такой подход может показаться недобрым, но на самом деле проактивность полезна для обеих сторон. Это снижает вероятность того, что кто-то потратит впустую много часов работы на запрос на перенос (pull request), который вы не собираетесь принимать. И это упрощает управление вашей рабочей нагрузкой.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/mikemcquaid?s=180" class = "pquote-avatar" alt = "avatar">
+  В идеале, объясните им в файле CONTRIBUTING.md, как они могут получить в будущем лучшее представление о том, что будет или не будет принято, до того, как они начнут работу.
+  <p markdown = "1" class = "pquote-credit">
+- @MikeMcQuaid, [«Любезно завершающие запросы на включение»](https://github.com/blog/2124-kindly-closing-pull-requests)
+  </p>
+</aside>
+
+Иногда, когда вы говорите «нет», ваш потенциальный участник может расстроиться или раскритиковать ваше решение. Если их поведение становится враждебным, [примите меры, чтобы разрядить ситуацию](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или даже удалите их из вашего сообщества, если они не желают конструктивного сотрудничества.
+
+### Примите наставничество
+
+Возможно, кто-то из вашего сообщества регулярно отправляет материалы, не соответствующие стандартам вашего проекта. Для обеих сторон могут быть неприятны неоднократные отказы.
+
+Если вы видите, что кто-то с энтузиазмом относится к вашему проекту, но требует немного доработки, наберитесь терпения. Четко объясните в каждой ситуации, почему их вклад не соответствует ожиданиям проекта. Попробуйте указать им на более легкую или менее двусмысленную задачу, например, на проблему с пометкой _"первая хорошая проблема"_, чтобы они приспособились. Если у вас есть время, подумайте о том, чтобы наставлять их с помощью их первого вклада, или найдите кого-нибудь еще в вашем сообществе, который может быть готов наставлять их.
+
+## Используйте свое сообщество
+
+Необязательно все делать самому. Сообщество вашего проекта существует не зря! Даже если у вас еще нет активного сообщества участников, если у вас много пользователей, заставьте их работать.
+
+### Разделите рабочую нагрузку
+
+Если вы ищете других, кто может принять участие, начните с расспросов.
+
+Один из способов привлечь новых участников - явно [обозначить проблемы, которые достаточно просты для начинающих](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Затем GitHub будет отображать эти проблемы в различных местах платформы, делая их более заметными.
+
+Когда вы видите, что новые участники неоднократно вносят свой вклад, признайте их работу, предложив больше ответственности. Задокументируйте, как другие могут стать лидерами, если захотят.
+
+Поощрение других [разделить право собственности на проект](../building-community/#совместное-владение-вашим-проектом) может значительно снизить вашу рабочую нагрузку, как обнаружила @lmccart в своем проекте [p5.js](https://github.com/processing/p5.js).
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/lmccart?s=180" class = "pquote-avatar" alt = "avatar">
+  Я говорил: «Да, любой может участвовать, вам не обязательно иметь большой опыт программирования [...]». У нас были люди, которые записывались, чтобы прийти [на мероприятие], и тогда я по-настоящему задумался: правда ли это то, что я говорю? Придет 40 человек, и я не могу сидеть с каждым из них... Но люди собрались вместе, и это вроде как сработало. Как только один человек понимал что-то, он мог научить своего соседа.
+  <p markdown = "1" class = "pquote-credit">
+- @lmccart, [«Что вообще означает« открытый исходный код »? P5.js Edition»](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+  </p>
+</aside>
+
+Если вам нужно отказаться от проекта, будь то на перерыв или навсегда, нет ничего постыдного в том, чтобы попросить кого-то другого взять на себя ответственность за вас.
+
+Если другие люди с энтузиазмом относятся к его направлению, предоставьте им доступ к правкам (to commit) или официально передайте контроль кому-то другому. Если кто-то разветвил (fork) ваш проект и активно поддерживает его в другом месте, подумайте о том, чтобы сделать ссылку на ответвление из вашего исходного проекта. Здорово, что так много людей хотят, чтобы ваш проект продолжал жить!
+
+@progrium [обнаружил, что](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) документирование видения его проекта [Dokku](https://github.com/dokku/dokku) помогло достичь этих целей даже после того, как он ушел из проекта:
+
+> Я написал вики-страницу с описанием того, что я хотел и почему я этого хотел. Почему-то для меня стало неожиданностью, что сопровождающие начали продвигать проект в этом направлении! Произошло ли это именно так, как я хотел? Не всегда. Но это все же приблизило проект к тому, что я написал.
+
+### Позвольте другим создавать нужные им решения
+
+Если потенциальный участник придерживается другого мнения о том, что должен делать ваш проект, вы можете мягко поощрить его к работе над собственным ответвлением (fork).
+
+Разветвление проекта не должно считаться плохим. Возможность копировать и изменять проекты - одна из лучших сторон открытого исходного кода. Поощрение членов вашего сообщества к работе над собственным форком может дать им необходимый творческий выход, не противореча видению вашего проекта.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/geerlingguy?s=180" class = "pquote-avatar" alt = "avatar">
+  Я стремлюсь к покрытию 80% потребностей. Если вы один из единорогов, пожалуйста, ответвите мою работу. Я не обижусь! Мои публичные проекты почти всегда предназначены для решения самых распространенных проблем; я стараюсь сделать так, чтобы было легче идти глубже, либо разветвляя свою работу, либо расширяя ее.
+  <p markdown = "1" class = "pquote-credit">
+- @geerlingguy, [«Почему я закрываю запрос за перенос (pull request)](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+  </p>
+</aside>
+
+То же самое относится к пользователю, которому действительно нужно решение, для создания которого у вас просто нет пропускной способности. Предлагая API-интерфейсы и хуки настройки, можно помочь другим удовлетворить их собственные потребности без необходимости напрямую изменять исходный код. @orta [обнаружил, что](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) поощрение плагинов для CocoaPods привело к «некоторым из самых интересных идей»:
+
+> Почти неизбежно, что когда проект становится большим, сопровождающие должны стать более консервативными в том, как они вводят новый код. Вы научитесь говорить «нет», но у многих людей есть законные потребности. Таким образом, вместо этого вы превращаете свой инструмент в платформу.
+
+## Принесите роботов
+
+Подобно тому, как есть задачи, с которыми вам могут помочь другие люди, есть также задачи, которые ни один человек никогда не должен выполнять. Роботы - ваш друг. Используйте их, чтобы облегчить себе жизнь в качестве сопровождающего.
+
+### Требовать тесты и другие проверки для улучшения качества вашего кода
+
+Один из наиболее важных способов автоматизации проекта - это добавление тестов.
+
+Тесты помогают участникам быть уверенными в том, что они ничего не сломают. Они также облегчают вам быстрый просмотр и принятие материалов. Чем более отзывчивым вы будете, тем более заинтересованным может быть ваше сообщество.
+
+Настройте автоматические тесты, которые будут запускаться для всех входящих вкладов, и убедитесь, что ваши тесты могут легко запускаться локально участниками. Требуйте, чтобы все дополнения кода прошли ваши тесты, прежде чем их можно будет отправить. Вы поможете установить минимальный стандарт качества для всех представленных материалов. [Обязательные проверки статуса](https://help.github.com/articles/about-required-status-checks/) на GitHub могут помочь гарантировать, что никакие изменения не будут объединены без прохождения ваших тестов.
+
+Если вы добавляете тесты, обязательно объясните, как они работают в вашем файле CONTRIBUTING (руководство участника).
+
+<aside markdown = "1" class = "pquote">
+  <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)
+  </p>
+</aside>
+
+### Используйте инструменты для автоматизации основных задач сопровождения
+
+Хорошая новость о поддержке популярного проекта заключается в том, что другие сопровождающие, вероятно, сталкивались с аналогичными проблемами и создали для них решение.
+
+Существует [множество доступных инструментов](https://github.com/showcases/tools-for-open-source), которые помогают автоматизировать некоторые аспекты работ по сопровождению. Несколько примеров:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) автоматизирует ваши выпуски (release).
+* [mention-bot](https://github.com/facebook/mention-bot) упоминает потенциальных рецензентов для запросов на перенос (pull request).
+* [Danger](https://github.com/danger/danger) помогает автоматизировать проверку кода.
+* [no-response](https://github.com/probot/no-response) закрывает проблемы, когда автор не ответил на запрос дополнительной информации.
+* [dependabot-preview](https://github.com/marketplace/dependabot-preview) проверяет ваши файлы зависимостей каждый день на наличие устаревших требований и если находит, то открывает для них индивидуальные запросы на перенос.
+
+Для отчетов об ошибках и других общих материалов на GitHub есть [Шаблоны проблем (issue) и шаблоны запросов на перенос (pull request)](https://github.com/blog/2111-issue-and-pull-request-templates), которые вы можете создать для упрощения взаимодействия с сообществом. @TalAter создал [Руководство по выбору своего собственного приключения](https://www.talater.com/open-source-templates/#/), чтобы помочь вам написать свою проблему и шаблоны запросов на перенос (pull request).
+
+Для управления уведомлениями по электронной почте вы можете настроить [фильтры электронной почты](https://github.com/blog/2203-email-updates-about-your-own-activity) для сортировки по приоритету.
+
+Если вы хотите стать немного более продвинутым, руководства по стилю и линтеры могут стандартизировать вклады в проект и упростить их просмотр и принятие.
+
+Однако, если ваши стандарты слишком сложны, они могут увеличить препятствия на пути к участию. Убедитесь, что вы добавляете достаточно правил, чтобы облегчить всем жизнь.
+
+Если вы не знаете, какие инструменты использовать, посмотрите, что делают другие популярные проекты, особенно в вашей экосистеме. Например, как выглядит процесс участия для других модулей Node? Использование подобных инструментов и подходов также сделает ваш процесс более знакомым для ваших целевых участников.
+
+## Нажать паузу - это нормально
+
+Когда-то работа с открытым исходным кодом приносила вам радость. Может быть, теперь вы начинаете чувствовать себя избегающим или виноватым.
+
+Возможно, вы чувствуете себя подавленным или чувствуете растущее чувство страха, когда думаете о своих проектах. А между тем проблемы (issues) и запросы на перенос (pull request) накапливаются.
+
+Выгорание - реальная и распространенная проблема в работе с открытым исходным кодом, особенно среди сопровождающих. Ваше счастье как сопровождающего - непреложное условие для выживания любого проекта с открытым исходным кодом.
+
+Это ясно без слов, если устали - сделайте перерыв! Вам не нужно ждать, пока вы почувствуете выгорание, чтобы взять отпуск. @brettcannon, разработчик ядра Python, решил взять [отпуск на месяц](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) после 14 лет волонтерской работы в открытом исходном коде.
+
+Как и любой другой вид работы, регулярные перерывы будут держать вас бодрым, счастливым и воодушевленным своей работой.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/danielbachhuber?s=180" class = "pquote-avatar" alt = "avatar">
+  Поддерживая WP-CLI, я обнаружил, что мне нужно сначала сделать себя счастливым, и установить четкие границы своего участия. Наилучший баланс, который я нашел, - это 2-5 часов в неделю как часть моего обычного рабочего графика. Это сохраняет мое увлечение страстью, и не возникает ощущения работы. Поскольку я уделяю приоритетное внимание вопросам, над которыми работаю, я могу регулярно добиваться прогресса в том, что считаю наиболее важным.
+  <p markdown = "1" class = "pquote-credit">
+- @danielbachhuber, [«Мои соболезнования, теперь вы поддерживаете популярный проект с открытым исходным кодом»](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+  </p>
+</aside>
+
+Иногда бывает трудно сделать перерыв в работе с открытым исходным кодом, когда кажется, что вы нужны всем. Люди могут даже попытаться заставить вас почувствовать себя виноватым за то, что вы отступили.
+
+Сделайте все возможное, чтобы найти поддержку для своих пользователей и сообщества, пока вы не участвуете в проекте. Если вы не можете найти необходимую поддержку, все равно сделайте перерыв. Обязательно предупреждайте, перед тем как стать недоступным, чтобы людей не смущало отсутствие вашей реакции.
+
+Перерывы относятся не только к отпуску. Если вы не хотите заниматься разработкой с открытым исходным кодом по выходным или в рабочее время, сообщите об этих ожиданиях другим, чтобы они знали, что вас не надо беспокоить.
+
+## Береги себя в первую очередь!
+
+Поддержание популярного проекта требует иных навыков, чем на ранних этапах развития, но это не уменьшает пользу описанных выше советов. Как сопровождающий, вы будете практиковать лидерство и личные навыки на уровне, который мало кто сможет испытать. Хотя этим не всегда легко управлять, установление четких границ и принятие только того, что вам удобно, помогут вам оставаться счастливыми, бодрыми и продуктивными.
diff --git a/_articles/ru/building-community.md b/_articles/ru/building-community.md
new file mode 100644
index 00000000000..80bf767c10f
--- /dev/null
+++ b/_articles/ru/building-community.md
@@ -0,0 +1,280 @@
+---
+lang: ru
+title: Создание дружного сообщества
+description: Создание сообщества, которое побуждает людей использовать ваш проект, вносить свой вклад и пропагандировать его.
+class: building
+toc:
+  настройка-вашего-проекта-на-успех: 'Настройка вашего проекта на успех'
+  развитие-вашего-сообщества: 'Развитие вашего сообщества'
+  разрешение-конфликтов: 'Разрешение конфликтов'
+order: 4
+image: /assets/images/cards/building.png
+related:
+  - best-practices
+  - coc
+---
+
+## Настройка вашего проекта на успех
+
+Вы запустили свой проект, распространяете информацию, и люди пробуют его. Потрясающе! Как убедить их остаться?
+
+Доброжелательное сообщество - это инвестиция в будущее и репутацию вашего проекта. Если ваш проект только начинает получать вклад посторонних разработчиков, начните с того, чтобы дать первым участникам положительный опыт, чтобы им хотелось возвращаться.
+
+### Сделайте так, чтобы люди чувствовали себя желанными гостями
+
+Один из способов подумать о сообществе вашего проекта - это то, что @MikeMcQuaid называет [воронкой участника](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+![воронка участника](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+
+Создавая свое сообщество, подумайте, как кто-то наверху воронки (потенциальный пользователь) теоретически может добраться до конца (активный сопровождающий). Ваша цель - уменьшить трение на каждом этапе взаимодействия с участником. Когда у людей легкие победы, они будут чувствовать стимул делать больше.
+
+Начните с вашей документации:
+
+* **Облегчите использование вашего проекта для любого желающего.** [Дружественное 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 за 2017 год](http://opensourcesurvey.org/2017/) показал, что неполная или запутанная документация является самой большой проблемой для пользователей открытого исходного кода. Хорошая документация побуждает людей взаимодействовать с вашим проектом. В конце концов, кто-то откроет вопрос (issue) или запрос на изменение (pull request). Используйте эти взаимодействия как возможности для продвижения их по воронке.
+
+* **Когда кто-то новый попадает в ваш проект, поблагодарите его за проявленный интерес!** Достаточно одного негативного опыта, чтобы кто-то не захотел возвращаться.
+* **Будьте отзывчивы.** Если вы не отвечаете на их вопрос в течение месяца, скорее всего, они уже забыли о вашем проекте.
+* **Будьте открыты в отношении помощи, которую вы примете.** Многие участники начинают с отчета об ошибке или небольшого исправления. Есть [много способов внести свой вклад](../how-to-contribute/#что-значит-внести-свой-вклад-to-contribute) в проект. Позвольте людям помочь так, как они хотят помочь.
+* **Если есть предложение, с которым вы не согласны,** поблагодарите их за идею и [объясните, почему](../best-practices/#учитесь-говорить-нет), это не вписывается в рамки проекта со ссылкой на соответствующую документацию, если она у вас есть.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/mikeal?s=180" class = "pquote-avatar" alt = "avatar">
+  Некоторым легче внести свой вклад в развитие открытого исходного кода, чем другим. Есть много опасений, что на них будут кричать за то, что они что-то не делают правильно или просто не подходят. (...) Предоставляя участникам возможность вносить свой вклад с очень низким уровнем технической подготовки (документация, разметка веб-контента и т.д.), вы можете значительно сократить эти проблемы.
+  <p markdown = "1" class = "pquote-credit">
+- @mikeal, [«Расширение базы участников в современном открытом исходном коде»](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+  </p>
+</aside>
+
+Большинство участников открытого исходного кода являются «случайными»: людьми, которые вносят свой вклад в проект лишь от случая к случаю. У случайного участника может не быть времени, чтобы полностью освоить ваш проект, поэтому ваша задача - упростить для него участие.
+
+Поощрение других участников - тоже вложение в себя. Когда вы позволяете своим самым большим поклонникам заниматься тем, чем они увлечены, становится меньше необходимости делать все самостоятельно.
+
+### Документируйте все
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/janl?s=180" class = "pquote-avatar" alt = "avatar">
+  Вы когда-нибудь были на (техническом) мероприятии, где вы никого не знали, но все остальные, казалось, собирались группами и болтали, как старые друзья? (...) Теперь представьте, что вы хотите внести свой вклад в проект с открытым исходным кодом, но вы не понимаете, почему и как это происходит.
+  <p markdown = "1" class = "pquote-credit">
+- @janl, [«Устойчивый открытый исходный код»](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+Когда вы начинаете новый проект, может показаться естественным сохранить конфиденциальность своей работы. Но проекты с открытым исходным кодом процветают, когда вы публично документируете свой процесс.
+
+Когда вы что-то записываете, на каждом этапе пути может участвовать больше людей. Вы можете получить помощь в том, о чем даже не подозревали.
+
+Запись означает больше, чем просто техническая документация. Каждый раз, когда вы чувствуете желание записать что-то или обсудить свой проект в частном порядке, спросите себя, можете ли вы сделать его общедоступным.
+
+Будьте прозрачны в отношении дорожной карты вашего проекта, типов вкладов, которые вы ищете, того, как оцениваются вклады, или почему вы приняли определенные решения.
+
+Если вы заметили, что несколько пользователей сталкиваются с одной и той же проблемой, задокументируйте ответы в README.
+
+Для встреч рассмотрите возможность публикации заметок или выводов по актуальному вопросу. Отзывы, которые вы получите от такого уровня прозрачности, могут вас удивить.
+
+Документирование всего относится и к вашей работе. Если вы работаете над существенным обновлением своего проекта, поместите его в запрос на перенос и отметьте его как незавершенное (WIP). Таким образом, другие люди могут почувствовать себя вовлеченными в процесс на ранней стадии.
+
+### Будьте отзывчивы
+
+По мере того, как вы [продвигаете свой проект](../finding-users), люди будут получать от вас обратную связь. У них могут быть вопросы о том, как все работает, или им может потребоваться помощь для начала работы.
+
+Постарайтесь оперативно реагировать, когда кто-то задаёт вопрос, отправляет запрос на перенос или задает вопрос о вашем проекте. Если вы ответите быстро, люди почувствуют себя участниками диалога и будут с большим энтузиазмом участвовать.
+
+Даже если вы не можете сразу просмотреть запрос, заблаговременное признание его поможет повысить вовлеченность. Вот как @tdreyno ответил на запрос на перенос [Middleman](https://github.com/middleman/middleman/pull/1466):
+
+![Запрос на включение посредника](/assets/images/building-community/middleman_pr.png)
+
+[Исследование Mozilla показало, что](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) участники, получившие гораздо более высокую оценку кода в течение 48 часов, совершили повторный вклад.
+
+Разговоры о вашем проекте также могут происходить в других местах в Интернете, таких как Stack Overflow, Twitter или Reddit. Вы можете настроить уведомления в некоторых из этих мест, чтобы получать их, когда кто-то упоминает ваш проект.
+
+### Дайте вашему сообществу место для собраний
+
+Есть две причины, чтобы дать вашему сообществу место для собраний.
+
+Первая причина - для них. Помогите людям узнать друг друга. Люди с общими интересами неизбежно захотят, об этом поговорить. А когда общение открыто и доступно, любой может читать прошлые архивы, чтобы быть в курсе и участвовать.
+
+Вторая причина - для вас. Если вы не предоставите людям публичное место для обсуждения вашего проекта, они, скорее всего, свяжутся с вами напрямую. Вначале может показаться достаточно простым ответить на личные сообщения «только один раз». Но со временем, особенно если ваш проект станет популярным, вы почувствуете себя истощенным. Не поддавайтесь искушению поговорить с людьми о своем проекте наедине. Вместо этого направьте их на назначенный общедоступный канал.
+
+Публичное общение может быть таким же простым, как указание людям открыть проблему вместо того, чтобы писать вам напрямую или комментировать ваш блог. Вы также можете настроить список рассылки или создать учетную запись Twitter, Slack или IRC-канал, чтобы люди говорили о вашем проекте. Или попробуйте все вышеперечисленное!
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) каждые две недели выделяет рабочие часы, чтобы помочь участникам сообщества:
+
+> Копы также выделяют время раз в две недели, чтобы предложить помощь и руководство сообществу. Сопровождающие Копов согласились выделить время, специально предназначенное для работы с новичками, помощи с PR и обсуждения новых функций.
+
+Заметными исключениями из публичного общения являются: 1) проблемы безопасности и 2) конфиденциальные нарушения кодекса поведения. У вас всегда должна быть возможность сообщить об этих проблемах в частном порядке. Если вы не хотите использовать свою личную электронную почту, создайте специальный адрес электронной почты.
+
+## Развитие вашего сообщества
+
+Сообщества чрезвычайно сильны. Эта сила может быть благословением или проклятием, в зависимости от того, как вы ею владеете. По мере роста сообщества вашего проекта есть способы помочь ему стать силой созидания, а не разрушения.
+
+### Не терпите плохих участников
+
+Любой популярный проект неизбежно привлечет людей, которые скорее вредят, чем помогают вашему сообществу. Они могут начать ненужные споры, спорить о тривиальных особенностях или запугать других.
+
+Сделайте все возможное, чтобы принять политику нулевой терпимости по отношению к этим типам людей. Если оставить это без внимания, негативные люди создадут дискомфорт другим людям в вашем сообществе. Они могут даже уйти.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/okdistribute?s=180" class = "pquote-avatar" alt = "avatar">
+  Правда в том, что наличие поддерживающего сообщества является ключевым моментом. Я бы никогда не справилась с этой работой без помощи моих коллег, дружелюбных незнакомцев в Интернете и болтливых каналов IRC. (...) Не соглашайтесь на меньшее. Не соглашайтесь на придурков.
+  <p markdown = "1" class = "pquote-credit">
+- @okdistribute, [«Как запустить проект с открытым исходным кодом»](https://okdistribute.xyz/post/okf-de)
+  </p>
+</aside>
+
+Регулярные дебаты о тривиальных аспектах вашего проекта отвлекают других, в том числе вас, от сосредоточения на важных задачах. Новые люди, которые приходят на ваш проект, могут видеть эти разговоры и не хотят участвовать.
+
+Когда вы видите негативное поведение в своем проекте, объявите об этом публично. Объясните добрым, но твердым тоном, почему их поведение неприемлемо. Если проблема не исчезнет, ​​вам может потребоваться [попросить их уйти](../code-of-conduct/#обеспечение-соблюдения-вашего-кодекса-поведения). Ваш [кодекс поведения](../code-of-conduct/) может быть конструктивным руководством для этих разговоров.
+
+### Познакомьтесь с участниками там, где они есть
+
+Хорошая документация становится только важнее по мере роста вашего сообщества. Случайные участники, которые иначе могут не быть знакомы с вашим проектом, читают вашу документацию, чтобы быстро получить контекст, в котором они нуждаются.
+
+В вашем файле CONTRIBUTING явным образом сообщите новым участникам, как начать работу. Возможно, вы даже захотите создать для этой цели специальный раздел. [Django](https://github.com/django/django), например, имеет специальную целевую страницу, чтобы приветствовать новых участников.
+
+![Страница новых участников Django](/assets/images/building-community/django_new_contributors.png)
+
+В очереди задач пометьте ошибки, которые подходят для разных типов участников: например, [_"только для новичков"_](https://kentcdodds.com/blog/first-timers-only), _"как составить первый вопрос"_, или _"документацию"_. [Эти ярлыки](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) упрощают быстрое сканирование ваших вопросов для новичков в вашем проекте, чтобы начать действовать.
+
+Наконец, используйте свою документацию, чтобы люди чувствовали себя желанными на каждом этапе пути.
+
+Вы никогда не будете взаимодействовать с большинством людей, которые попадают в ваш проект. Могут быть вклады, которые вы не получили, потому что кто-то испугался или не знал, с чего начать. Даже несколько добрых слов могут удержать кого-то от разочарования.
+
+Например, вот как [Rubinius](https://github.com/rubinius/rubinius/) запускает [его руководство](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+> Мы хотим начать с того, чтобы поблагодарить вас за использование Rubinius. Этот проект - плод любви, и мы ценим всех пользователей, которые вылавливают ошибки, улучшают производительность и помогают с документацией. Каждый вклад значим, поэтому спасибо за участие. При этом вот несколько рекомендаций, которым мы просим вас следовать, чтобы мы могли успешно решить вашу проблему.
+
+### Совместное владение вашим проектом
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/sagesharp?s=180" class = "pquote-avatar" alt = "avatar">
+  У ваших лидеров будут разные мнения, как и должно быть у всех здоровых сообществ! Однако вам необходимо предпринять шаги для обеспечения того, чтобы самый громкий голос не всегда побеждал, утомляя людей, и чтобы были слышны менее заметные голоса и голоса меньшинства.
+  <p markdown = "1" class = "pquote-credit">
+- @sagesharp, [«Что делает хорошее сообщество?»](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+  </p>
+</aside>
+
+Люди рады вносить свой вклад в проекты, когда они чувствуют свою причастность. Это не значит, что вам нужно изменить видение своего проекта или принимать нежелательные вклады. Но чем больше вы доверяете другим, тем больше они остаются с вами.
+
+Посмотрите, сможете ли вы найти способы как можно больше поделиться собственностью со своим сообществом. Вот несколько идей:
+
+* **Не поддавайтесь исправлению простых (некритических) ошибок.** Вместо этого используйте их как возможности для привлечения новых участников или наставничества тех, кто хотел бы внести свой вклад. Сначала это может показаться неестественным, но со временем ваши вложения окупятся. Например, @michaeljoseph попросил участника отправить запрос на перенос по проблеме [Cookiecutter](https://github.com/audreyr/cookiecutter), а не исправить ее сам.
+
+![Проблема с Cookiecutter](/assets/images/building-community/cookiecutter_submit_pr.png)
+
+* **Запустите файл УЧАСТНИКИ или АВТОРЫ в своем проекте**, в котором перечислены все, кто внес свой вклад в ваш проект, как, например, [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
+
+* Если у вас большое сообщество, **разошлите информационный бюллетень или напишите сообщение в блоге** с благодарностью участникам. [Эта неделя на Rust](https://this-week-in-rust.org/) от Rust и [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) от Hoodie - два хороших примера.
+
+* **Предоставьте каждому участнику доступ к коммитам.** @felixge обнаружил, что это заставило людей [с большим энтузиазмом оттачивать свои патчи](https://felixge.de/2013/03/11/the-pull-request-hack.html), и он даже нашел новых сопровождающих для проектов, над которыми давно не работал.
+
+* Если ваш проект размещен на GitHub, **переместите его из своей личной учетной записи в [Организацию](https://help.github.com/articles/creating-a-new-organization-account/)** и добавьте хотя бы одного администратора резервного копирования. Организации упрощают работу над проектами с внешними соавторами.
+
+Реальность такова, что [в большинстве проектов есть](https://peerj.com/preprints/1233.pdf) один или два сопровождающих, которые делают большую часть работы. Чем крупнее ваш проект и чем больше ваше сообщество, тем легче найти помощь.
+
+Хотя вы не всегда можете найти кого-то, кто ответит на призыв, подача сигнала увеличивает шансы, что другие люди вмешаются. И чем раньше вы начнете, тем скорее люди смогут помочь.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/gr2m?s=180" class = "pquote-avatar" alt = "avatar">
+  \[В ваших\] интересах набирать участников, которым нравится и которые способны делать то, что вам не нравится. Вам нравится писать код, но вы не любите отвечать на вопросы? Определите людей в вашем сообществе, которые это делают, и дайте им это.
+  <p markdown = "1" class = "pquote-credit">
+- @gr2m, ["Приветливые сообщества"](http://hood.ie/blog/welcoming-communities.html)
+  </p>
+</aside>
+
+## Разрешение конфликтов
+
+На ранних стадиях проекта легко принимать важные решения. Когда вы хотите что-то сделать, вы просто делаете это.
+
+По мере того, как ваш проект становится более популярным, все больше людей будут интересоваться вашими решениями. Даже если у вас нет большого сообщества участников, если у вашего проекта много пользователей, вы найдете людей, которые взвешивают решения или поднимают собственные проблемы.
+
+По большей части, если вы создали дружелюбное, уважительное сообщество и открыто задокументировали свои процессы, ваше сообщество должно найти решение. Но иногда вы сталкиваетесь с проблемой, которую немного сложнее решить.
+
+### Установите планку доброты
+
+Когда ваше сообщество борется с трудной проблемой, может подняться накал страстей. Люди могут рассердиться или расстроиться и обидеться друг на друга или на вас.
+
+Ваша задача как сопровождающего - не допустить обострения подобных ситуаций. Даже если у вас есть твердое мнение по теме, постарайтесь занять позицию модератора или фасилитатора, вместо того, чтобы вступать в борьбу и продвигать свои взгляды. Если кто-то ведет себя недоброжелательно или монополизирует беседу, [действуйте немедленно](../building-community/#не-терпите-плохих-участников), чтобы обсуждение было вежливым и продуктивным.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/kennethreitz?s=180" class = "pquote-avatar" alt = "avatar">
+  Сопровождающему проекта, чрезвычайно важно относиться с уважением к своим участникам. Они часто принимают то, что вы говорите, очень близко к сердцу.
+  <p markdown = "1" class = "pquote-credit">
+- @kennethreitz, [«Будьте сердечны или идите своим путем»](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+  </p>
+</aside>
+
+Другие люди ждут от вас совета. Подавайте хороший пример. Вы по-прежнему можете выражать разочарование, несчастье или беспокойство, но делайте это спокойно.
+
+Сохранять хладнокровие непросто, но демонстрация лидерства улучшает здоровье вашего сообщества. Интернет благодарит вас.
+
+### Относитесь к README как к конституции
+
+Ваш README - это [больше, чем просто набор инструкций](../starting-a-project/#составление-readme). Это также место, где можно поговорить о ваших целях, видении продукта и планах развития. Если люди слишком сосредоточены на обсуждении достоинств той или иной функции, возможно, будет полезно вернуться к README и поговорить о более высоком видении вашего проекта. Сосредоточение внимания на README также обезличивает разговор, поэтому вы можете провести конструктивное обсуждение.
+
+### Сосредоточьтесь на путешествии, а не на пункте назначения
+
+В некоторых проектах для принятия важных решений используется процесс голосования. Хотя на первый взгляд разумно, голосование делает упор на поиске «ответа», а не на том, чтобы выслушивать и решать проблемы друг друга.
+
+Голосование может стать политическим, когда члены сообщества чувствуют давление, чтобы они оказали друг другу услуги или проголосовали определенным образом. Также не все голосуют, будь то [молчаливое большинство](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) в вашем сообществе или пользователи, которые не знали, что голосование происходит.
+
+Иногда голосование является необходимым условием разрешения конфликтов. Однако, насколько вы можете, делайте упор на [«поиск консенсуса»](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), а не на консенсусе.
+
+В процессе поиска консенсуса члены сообщества обсуждают основные проблемы до тех пор, пока не почувствуют, что их должным образом выслушали. Когда остаются лишь незначительные проблемы, сообщество движется вперед. «Поиск консенсуса» признает, что сообщество не может прийти к идеальному ответу. Вместо этого он отдает приоритет слушанию и обсуждению.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/lee-dohm?s=180" class = "pquote-avatar" alt = "avatar">
+  Отчасти причина того, что система голосования не существует для проблем Atom, заключается в том, что команда Atom не собирается следовать системе голосования во всех случаях. Иногда нам приходится выбирать то, что мы считаем правильным, даже если это непопулярно. (...) Что я могу предложить и обещаю сделать... это то, что моя работа - слушать сообщество.
+  <p markdown = "1" class = "pquote-credit">
+- @lee-dohm о [процессе принятия решений Atom](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+  </p>
+</aside>
+
+Даже если вы на самом деле не применяете процесс поиска консенсуса, как сопровождающий проекта, важно, чтобы люди знали, что вы их слушаете. Заставить других почувствовать себя услышанными и что вы стараетесь разрешить их проблемы в значительной степени помогает избавиться от деликатных ситуаций. Затем подкрепите свои слова действиями.
+
+Не торопитесь с решением ради разрешения. Убедитесь, что все чувствуют себя услышанными и что вся информация предана гласности, прежде чем переходить к решению.
+
+### Сосредоточьте разговор на действии
+
+Обсуждение важно, но есть разница между продуктивным и непродуктивным разговором.
+
+Поощряйте обсуждение, пока оно активно движется к разрешению. Если ясно, что разговор вялится или уходит не по теме, уколы становятся личными или люди придираются к мелочам, пора его закрыть.
+
+Продолжение этих разговоров плохо не только для решения рассматриваемой проблемы, но и для здоровья вашего сообщества. Он посылает сообщение о том, что такие разговоры разрешены или даже поощряются, и может оттолкнуть людей поднимать или решать будущие проблемы.
+
+С каждым замечанием, сделанным вами или другими, спрашивайте себя: _"Как это приближает нас к решению?"_
+
+Если разговор начинает распадаться, спросите группу: _«Какие шаги мы должны предпринять дальше?»_, чтобы переориентировать разговор.
+
+Если разговор явно никуда не придёт, нет четких действий, которые нужно предпринять, или соответствующие действия уже были предприняты, закройте проблему и объясните, почему вы ее закрыли.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/kfogel?s=180" class = "pquote-avatar" alt = "avatar">
+  Направлять нить к полезности без навязчивости - это искусство. Не сработает просто увещевать людей перестать тратить свое время или просить их не публиковать сообщения, если у них нет чего-то конструктивного. (...) Вместо этого вы должны предложить условия для дальнейшего прогресса: дать людям маршрут, путь, по которому следует следовать, который приведет к желаемым результатам, но чтобы это не звучало, будто вы диктуете поведение.
+  <p markdown = "1" class = "pquote-credit">
+- @kfogel, [_Proroduction OSS_](https://produdingoss.com/en/produdingoss.html#common-pitfalls)
+  </p>
+</aside>
+
+### Выбирайте битвы с умом
+
+Контекст важен. Подумайте, кто участвует в обсуждении и как они представляют остальную часть сообщества.
+
+Все в сообществе расстроены или даже вовлечены в эту проблему? Или одинокий нарушитель спокойствия? Не забывайте принимать во внимание молчаливых членов вашего сообщества, а не только активные голоса.
+
+Если проблема не отражает более широкие потребности вашего сообщества, возможно, вам просто нужно признать озабоченность нескольких человек. Если это повторяющаяся проблема без четкого решения, укажите на предыдущие обсуждения по этой теме и закройте ветку.
+
+### Определите, кто разрешает конфликты в сообществе
+
+При хорошем отношении и четком общении самые сложные ситуации разрешимы. Однако даже в продуктивной беседе могут просто быть разные мнения о том, как действовать дальше. В этих случаях определите человека или группу людей, которые могут решить проблему.
+
+Решающим фактором может быть основной сопровождающий проекта или небольшая группа людей, которые принимают решение на основе голосования. В идеале вы определили средство разрешения конфликтов и связанный с ним процесс в файле GOVERNANCE, прежде чем вам когда-либо придется его использовать.
+
+Тай-брейк должен быть последним средством. Спорные вопросы - это возможность для вашего сообщества расти и учиться. Воспользуйтесь этими возможностями и используйте совместный процесс, чтобы найти решение везде, где это возможно.
+
+## Сообщество - это ❤️ открытого исходного кода
+
+Здоровые и процветающие сообщества каждую неделю тратят тысячи часов на разработку программного обеспечения с открытым исходным кодом. Многие участники указывают на других людей как на причину работы - или не работы - над открытым исходным кодом. Узнав, как использовать эту силу конструктивно, вы поможете кому-то получить незабываемый опыт с открытым исходным кодом.
diff --git a/_articles/ru/code-of-conduct.md b/_articles/ru/code-of-conduct.md
new file mode 100644
index 00000000000..74c127b4686
--- /dev/null
+++ b/_articles/ru/code-of-conduct.md
@@ -0,0 +1,120 @@
+---
+lang: ru
+title: Ваш кодекс поведения
+description: Содействуйте здоровому и конструктивному поведению в сообществе, приняв и обеспечив соблюдение кодекса поведения.
+class: coc
+toc:
+  зачем-мне-нужен-кодекс-поведения: 'Зачем мне нужен кодекс поведения?'
+  установление-кодекса-поведения: 'Установление кодекса поведения'
+  решите-как-вы-будете-обеспечивать-соблюдение-своего-кодекса-поведения: 'Решите, как вы будете обеспечивать соблюдение своего кодекса поведения'
+  обеспечение-соблюдения-вашего-кодекса-поведения: 'Обеспечение соблюдения вашего кодекса поведения'
+  ваши-обязанности-как-сопровождающего: 'Ваши обязанности как сопровождающего'
+order: 8
+image: /assets/images/cards/coc.png
+related:
+  - building
+  - leadership
+---
+
+## Зачем мне нужен кодекс поведения?
+
+Кодекс поведения - это документ, который устанавливает ожидания в отношении поведения участников вашего проекта. Принятие и соблюдение кодекса поведения может помочь создать позитивную социальную атмосферу в вашем сообществе.
+
+Кодексы поведения помогают защитить не только участников, но и вас самих. Если вы поддерживаете проект, вы можете обнаружить, что непродуктивное отношение других участников со временем может привести вас к истощению или недовольству своей работой.
+
+Кодекс поведения дает вам возможность способствовать здоровому и конструктивному поведению в обществе. Проактивность снижает вероятность того, что вы или другие люди устанете от своего проекта, и помогает вам действовать, когда кто-то делает что-то, с чем вы не согласны.
+
+## Установление кодекса поведения
+
+Постарайтесь установить кодекс поведения как можно раньше: в идеале, когда вы впервые создаете свой проект.
+
+Кодекс поведения описывает не только ваши ожидания, но и следующее:
+
+* Где вступает в силу кодекс поведения _(только в отношении issues и pull requests, или действий сообщества, таких как мероприятия?)_
+* К кому применяется кодекс поведения _(члены сообщества и сопровождающие (maintainers), а как насчет спонсоров?)_
+* Что произойдет, если кто-то нарушит кодекс поведения
+* Как можно сообщить о нарушениях
+
+Везде, где можно, используйте прошлые достижения. [Соглашение авторов](https://contributor-covenant.org/) - это готовый кодекс поведения, используется более чем 40 000 проектов с открытым исходным кодом, включая Kubernetes, Rails и Swift.
+
+[Кодекс поведения Django](https://www.djangoproject.com/conduct/) и [Кодекс поведения гражданина](http://citizencodeofconduct.org/) также являются двумя хорошими примерами кодекса поведения.
+
+Поместите файл CODE_OF_CONDUCT в корневой каталог вашего проекта и сделайте его видимым для вашего сообщества, связав его из файла CONTRIBUTING или README.
+
+## Решите, как вы будете обеспечивать соблюдение своего кодекса поведения
+
+<aside markdown="1" class="pquote">
+ Кодекс поведения, который не соблюдается (или не может быть соблюден) - хуже, чем отсутствие кодекса поведения вообще: он посылает сигнал о том, что ценности в кодексе поведения на самом деле не важны и не уважаются в вашем сообществе.
+  <p markdown="1" class="pquote-credit">
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+  </p>
+</aside>
+
+Вы должны объяснить, как будет применяться ваш кодекс поведения, **_прежде чем_** произойдет нарушение. Для этого есть несколько причин:
+
+* Это демонстрирует, что вы серьезно относитесь к действиям, когда это необходимо.
+
+* Ваше сообщество будет более уверено, что жалобы действительно будут рассмотрены.
+
+* Вы убедите свое сообщество, что процесс проверки является справедливым и прозрачным, если они когда-либо обнаружат, что их расследуют на предмет нарушения.
+
+Вы должны предоставить людям возможность в частном порядке (например, на адрес электронной почты) сообщить о нарушении кодекса поведения и объяснить, кто получает это сообщение. Это может быть сопровождающий, группа сопровождающих или рабочая группа по кодексу поведения.
+
+Не забывайте, что кто-то может захотеть сообщить о нарушении в отношении человека, получившего эти сообщения. В этом случае дайте им возможность сообщить о нарушениях кому-то другому. Например, @ctb и @ mr-c [объясняют свой проект](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> О случаях оскорбления, домогательства или иного неприемлемого поведения можно сообщать по электронной почте **khmer-project@idyll.org**, которая отправляется только К. Титусу Брауну и Майклу Р. Крузо. Чтобы сообщить о проблеме, связанной с любым из них, отправьте электронное письмо **Джуди Браун Кларк, доктору философии**, директору по разнообразию Центра изучения эволюции в действии BEACON, Центра науки и технологий NSF.\*
+
+Для вдохновения ознакомьтесь с [руководством по применению](https://www.djangoproject.com/conduct/enforcement-manual/) Django (хотя в зависимости от размера вашего проекта вам может не понадобиться что-то настолько всеобъемлющее).
+
+## Обеспечение соблюдения вашего кодекса поведения
+
+Иногда, несмотря на все ваши усилия, кто-то будет делать что-то, нарушающее этот код. Есть несколько способов справиться с негативным или вредным поведением, когда оно возникает.
+
+### Соберите информацию о ситуации
+
+Относитесь к голосу каждого члена сообщества так же важно, как и к своему собственному. Если вы получили сообщение о том, что кто-то нарушил кодекс поведения, отнеситесь к этому серьезно и расследуйте этот вопрос, даже если он не соответствует вашему собственному опыту общения с этим человеком. Это сигнализирует вашему сообществу, что вы цените их точку зрения и доверяете их мнению.
+
+Рассматриваемый член сообщества может быть рецидивистом, который постоянно заставляет других чувствовать себя некомфортно, или он мог сказать или сделать что-то только один раз. И то, и другое может быть основанием для принятия мер, в зависимости от контекста.
+
+Прежде чем ответить, дайте себе время понять, что произошло. Прочтите прошлые комментарии и разговоры этого человека, чтобы лучше понять, кто он и почему он мог поступить таким образом. Постарайтесь собрать другие точки зрения об этом человеке и его поведении.
+
+<aside markdown = "1" class = "pquote">
+  Не ввязывайтесь в споры. Не отвлекайтесь, пытаясь разобраться с чужим поведением, пока вы не закончите разбираться с текущим вопросом. Сосредоточьтесь на том, что вам нужно.
+  <p markdown = "1" class = "pquote-credit">
+- Стефани Зван, [«Итак, у вас есть политика. Что теперь?»](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+  </p>
+</aside>
+
+### Примите соответствующие меры
+
+После сбора и обработки достаточного количества информации вам нужно будет решить, что делать. Обдумывая свои следующие шаги, помните, что ваша цель как модератора - создать безопасную, уважительную среду для совместной работы. Подумайте не только о том, как поступить в рассматриваемой ситуации, но и о том, как ваш ответ повлияет на поведение и ожидания остальной части вашего сообщества в будущем.
+
+Когда кто-то сообщает о нарушении кодекса поведения, это ваша, а не их работа - разбираться с этим. Иногда репортер раскрывает информацию с большим риском для своей карьеры, репутации или физической безопасности. Принуждение их к противостоянию преследователям может поставить репортера в компромиссное положение. Вам следует вести прямое общение с этим человеком, если репортер явно не потребует иного.
+
+Есть несколько способов отреагировать на нарушение кодекса поведения:
+
+* **Сделайте этому человеку публичное предупреждение** и объясните, как его поведение негативно повлияло на других, желательно в том канале, где оно произошло. По возможности, публичная коммуникация сообщает остальной части сообщества о том, что вы серьезно относитесь к кодексу поведения. Будьте добры, но тверды в общении.
+
+* **Наедине поговорите с человеком**, о котором идет речь, и объясните, как его поведение негативно повлияло на других. Вы можете использовать частный канал связи, если ситуация связана с конфиденциальной личной информацией. Если вы общаетесь с кем-то в частном порядке, рекомендуется отправить копию ваших сообщений тем, кто первым сообщил о ситуации, чтобы они знали, что вы приняли меры. Прежде чем отправлять им копию, попросите согласие того, с кем вы переписывались.
+
+Иногда решение не может быть достигнуто. Человек, о котором идет речь, может стать агрессивным или враждебным при столкновении или не изменит своего поведения. В этой ситуации вы можете подумать о более решительных действиях. Например:
+
+* **Отстранить лицо** от участия в проекте с помощью временного запрета на участие в любом аспекте проекта.
+
+* **Забанить навсегда** человека из проекта
+
+К запрету членов нельзя относиться легкомысленно, поскольку это представляет собой постоянное и непримиримое различие точек зрения. Вы должны принимать эти меры только тогда, когда ясно, что решение не может быть достигнуто.
+
+## Ваши обязанности как сопровождающего
+
+Кодекс поведения - это не закон, который применяется произвольно. Вы являетесь исполнителем кодекса поведения и обязаны соблюдать правила, установленные кодексом поведения.
+
+Как сопровождающий, вы устанавливаете правила для своего сообщества и обеспечиваете их соблюдение в соответствии с правилами, изложенными в вашем кодексе поведения. Это означает серьезное отношение к любому сообщению о нарушении кодекса поведения. Репортер должен тщательно и беспристрастно перепроверить свою жалобу. Если вы решите, что поведение, о котором они сообщили, не является нарушением, четко сообщите им об этом и объясните, почему вы не собираетесь принимать меры по этому поводу. Что они будут с этим делать, зависит от них: терпеть поведение, с которым у них возникла проблема, или прекращать участие в жизни сообщества.
+
+Сообщение о поведении, которое _технически_ не нарушает кодекс поведения, может указывать на наличие проблемы в вашем сообществе, и вам следует изучить эту потенциальную проблему и действовать соответствующим образом. Это может включать пересмотр вашего кодекса поведения, чтобы прояснить приемлемое поведение и/или поговорить с человеком, о поведении которого было сообщено, и сообщить ему, что, хотя он и не нарушал кодекс поведения, он выходит за рамки и создаёт дискомфорт другим участникам.
+
+В конце концов, как сопровождающий, вы устанавливаете и обеспечиваете соблюдение стандартов приемлемого поведения. У вас есть возможность формировать общественные ценности проекта, и участники ожидают, что вы будете придерживаться этих ценностей справедливо и беспристрастно.
+
+## Поощряйте поведение, которое вы хотите видеть в мире 🌎
+
+Когда проект кажется враждебным или нежелательным, даже если это всего лишь один человек, поведение которого терпят другие, вы рискуете потерять гораздо больше участников, с некоторыми из которых вы, возможно, даже никогда не встретитесь. Не всегда легко принять или обеспечить соблюдение кодекса поведения, но создание благоприятной атмосферы поможет вашему сообществу расти.
diff --git a/_articles/ru/finding-users.md b/_articles/ru/finding-users.md
new file mode 100644
index 00000000000..59227e72d99
--- /dev/null
+++ b/_articles/ru/finding-users.md
@@ -0,0 +1,163 @@
+---
+lang: ru
+title: Поиск пользователей для вашего проекта
+description: Помогите своему проекту с открытым исходным кодом расти, передав его в руки счастливых пользователей.
+class: finding
+toc:
+  распространение-информации: 'Распространение информации'
+  разберитесь-в-своем-послании: 'Разберитесь в своем послании'
+  помогите-людям-найти-ваш-проект-и-подписаться-на-него: 'Помогите людям найти ваш проект и подписаться на него'
+  идите-туда-где-аудитория-вашего-проекта-онлайн: 'Идите туда, где аудитория вашего проекта (онлайн)'
+  идите-туда-где-аудитория-вашего-проекта-офлайн: 'Идите туда, где аудитория вашего проекта (офлайн)'
+  создайте-репутацию: 'Создайте репутацию'
+order: 3
+image: /assets/images/cards/finding.png
+related:
+  - beginners
+  - building
+---
+
+## Распространение информации
+
+Нет правила, согласно которому вы должны продвигать проект с открытым исходным кодом при запуске. Есть много веских причин для работы с открытым исходным кодом, которые не имеют ничего общего с популярностью. Вместо того, чтобы надеяться, что другие найдут и воспользуются вашим проектом с открытым исходным кодом, вы должны рассказать о своей тяжелой работе!
+
+## Разберитесь в своем послании
+
+Прежде чем приступить к реальной работе по продвижению своего проекта, вы должны быть в состоянии объяснить, что он делает и почему это важно.
+
+Что делает ваш проект особенным или интересным? Зачем вы его создали? Ответив на эти вопросы для себя, вы сможете понять важность вашего проекта.
+
+Помните, что люди участвуют в качестве пользователей и в конечном итоге становятся участниками, потому что ваш проект решает для них проблему. Когда вы думаете о послании и ценности вашего проекта, попробуйте взглянуть на них через призму того, что могут захотеть _пользователи и участники_.
+
+Например, @robb использует примеры кода, чтобы четко объяснить, почему его проект [Cartography](https://github.com/robb/Cartography) полезен:
+
+![README картографии](/assets/images/finding-users/cartography.jpg)
+
+Чтобы глубже погрузиться в послание, ознакомьтесь с упражнением Mozilla [«Персоны и пути»](https://mozillascience.github.io/working-open-workshop/personas_pathways/) по развитию образов пользователей.
+
+## Помогите людям найти ваш проект и подписаться на него
+
+<aside markdown = "1" class = "pquote">
+  В идеале вам понадобится единый «домашний» URL-адрес, который вы можете продвигать и указывать людям в связи с вашим проектом. Вам не нужно вдаваться в причудливый шаблон или даже доменное имя, но вашему проекту нужен фокус.
+  <p markdown = "1" class = "pquote-credit">
+- Питер Купер и Роберт Найман, [«Как рассказать о своем коде»](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/ )
+  </p>
+</aside>
+
+Помогите людям найти и запомнить ваш проект, указав им единое пространство имен.
+
+**Имейте четкое представление о продвижении своей работы.** Ник в Twitter, ссылка на GitHub или канал IRC - это простой способ указать людям на ваш проект. Эти выходы также дают возможность собраться растущему сообществу вашего проекта.
+
+Если вы еще не хотите создавать выходы для своего проекта, продвигайте свой собственный Twitter или GitHub во всем, что вы делаете. Продвижение вашего аккаунта в Twitter или GitHub позволит людям узнать, как с вами связаться или следить за вашей работой. Если вы выступаете на встрече или мероприятии, убедитесь, что ваша контактная информация указана в вашей биографии или слайдах.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/nathanmarz?s=180" class = "pquote-avatar" alt = "avatar">
+  Ошибка, которую я совершил в те первые дни (...), заключалась в том, что я не создал аккаунт в Твиттере для проекта. Twitter - отличный способ держать людей в курсе о проекте, а также постоянно знакомить людей с проектом.
+  <p markdown = "1" class = "pquote-credit">
+- @nathanmarz, [«История Apache Storm и извлеченные уроки»](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+  </p>
+</aside>
+
+**Рассмотрите возможность создания веб-сайта для вашего проекта.** Веб-сайт делает ваш проект более дружелюбным и легким для навигации, особенно когда он сочетается с понятной документацией и руководствами. Наличие веб-сайта также предполагает, что ваш проект активен, что позволит вашей аудитории чувствовать себя более комфортно при его использовании. Приведите примеры, чтобы дать людям представление о том, как использовать ваш проект.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), соавтор Django, сказал, что веб-сайт был _"безусловно лучшим, что мы делали с Django в первые дни"_.
+
+Если ваш проект размещен на GitHub, вы можете использовать [GitHub Pages](https://pages.github.com/), чтобы легко создать веб-сайт. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) и [Middleman](https://middlemanapp.com/) [несколько примеров](https://github.com/showcases/github-pages-examples) отличных, всеобъемлющих веб-сайтов.
+
+![Домашняя страница Vagrant](/assets/images/finding-users/vagrant_homepage.png)
+
+Теперь, когда у вас есть сообщение для вашего проекта и простой способ для людей найти ваш проект, давайте выберемся и поговорим с вашей аудиторией!
+
+## Идите туда, где аудитория вашего проекта (онлайн)
+
+Информационно-пропагандистская деятельность в Интернете - отличный способ быстро поделиться и распространить информацию. Используя онлайн-каналы, вы можете охватить очень широкую аудиторию.
+
+Воспользуйтесь преимуществами существующих онлайн-сообществ и платформ, чтобы охватить свою аудиторию. Если ваш проект с открытым исходным кодом представляет собой программный проект, вы, вероятно, сможете найти свою аудиторию на [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/) или [Quora](https://www.quora.com/). Найдите каналы, по которым, по вашему мнению, люди получат наибольшую пользу от вашей работы или будут в восторге от нее.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/pazdera?s=180" class = "pquote-avatar" alt = "avatar">
+  Каждая программа имеет очень специфические функции, которые могут оказаться полезными лишь небольшой части пользователей. Не рассылайте спам как можно большему количеству людей. Вместо этого направьте свои усилия на те сообщества, которым будет полезно знать о вашем проекте.
+  <p markdown = "1" class = "pquote-credit">
+- @pazdera, [«Маркетинг для проектов с открытым исходным кодом»](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+  </p>
+</aside>
+
+Посмотрите, сможете ли вы найти способы поделиться своим проектом соответствующими способами:
+
+* **Познакомьтесь с соответствующими проектами и сообществами с открытым исходным кодом.** Иногда вам не нужно напрямую продвигать свой проект. Если ваш проект идеально подходит для специалистов по обработке данных, использующих Python, познакомьтесь с сообществом специалистов по науке о данных Python. По мере того, как люди узнают вас, у них появится естественная возможность рассказать о вашей работе и поделиться ею.
+* **Найдите людей, у которых возникла проблема, которую решает ваш проект.** Поищите на соответствующих форумах людей, которые попадают в целевую аудиторию вашего проекта. Ответьте на их вопрос и найдите тактичный способ, когда это уместно, предложить свой проект в качестве решения.
+* **Попросите обратную связь.** Представьте себя и свою работу аудитории, которая сочтет ее актуальной и интересной. Определите, кто, по вашему мнению, получит пользу от вашего проекта. Попытайтесь закончить предложение: _"Я думаю, что мой проект действительно поможет X, который пытается сделать Y_". Слушайте и отвечайте на отзывы других, а не просто продвигайте свою работу.
+
+Вообще говоря, сосредоточьтесь на помощи другим, прежде чем просить что-то взамен. Поскольку любой может легко продвигать проект в Интернете, будет много шума. Чтобы выделиться из толпы, дайте людям понять, кто вы есть, а не только то, чего вы хотите.
+
+Если никто не обращает внимания или не отвечает на вашу первоначальную просьбу, не расстраивайтесь! Запуск большинства проектов - это итеративный процесс, который может занять месяцы или годы. Если вы не получаете ответа с первого раза, попробуйте другую тактику или сначала найдите способы повысить ценность работы других. Продвижение и запуск вашего проекта требует времени и преданности делу.
+
+## Идите туда, где аудитория вашего проекта (офлайн)
+
+![Публичное выступление](/assets/images/finding-users/public_speaking.jpg)
+
+Офлайн-мероприятия - популярный способ продвигать новые проекты среди аудитории. Это отличный способ привлечь заинтересованную аудиторию и наладить более глубокие человеческие связи, особенно если вы заинтересованы в контакте с разработчиками.
+
+Если вы [новичок в публичных выступлениях](https://speaking.io/), начните с поиска местной встречи, которая связана с языком или экосистемой вашего проекта.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/jhamrick?s=180" class = "pquote-avatar" alt = "avatar">
+  Я очень нервничал перед посещением PyCon. Я выступал с докладом, я собирался познакомиться там только с парочкой людей, я ехал на целую неделю. (...) Но я не должен был волноваться. PyCon был феноменально потрясающим! (...) Все были невероятно дружелюбны и общительны, настолько, что я редко находил время, чтобы не разговаривать с людьми!
+  <p markdown = "1" class = "pquote-credit">
+- @jhamrick, [«Как я научился перестать беспокоиться и полюбить PyCon»](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+  </p>
+</aside>
+
+Если вы никогда раньше не выступали на мероприятии, нервничать - это нормально! Помните, что ваша аудитория здесь, потому что они искренне хотят услышать о вашей работе.
+
+Когда вы пишете доклад, сосредоточьтесь на том, что ваша аудитория найдет интересным и от чего получит пользу. Держите свой язык дружелюбным и доступным. Улыбайтесь, дышите и получайте удовольствие.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "/assets/images/finding-users/lena.jpg" class = "pquote-avatar" alt = "avatar">
+  Когда вы начинаете писать свое выступление, независимо от того, какая у вас тема, может помочь, если вы будете рассматривать его как историю, которую вы рассказываете людям.
+  <p markdown = "1" class = "pquote-credit">
+- Лена Рейнхард, [«Как подготовить и написать доклад на технической конференции»](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+  </p>
+</aside>
+
+Когда вы будете готовы, подумайте о том, чтобы выступить на конференции для продвижения вашего проекта. Конференции могут помочь вам охватить больше людей, иногда со всего мира.
+
+Ищите конференции, относящиеся к вашему языку или экосистеме. Перед тем, как представить доклад, изучите конференцию, чтобы настроить доклад для участников и повысить свои шансы быть допущенным к выступлению на конференции. Часто вы можете составить представление о своей аудитории, посмотрев на докладчиков конференции.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/ry?s=180" class = "pquote-avatar" alt = "avatar">
+  Я очень хорошо написал людям JSConf и умолял их дать мне место, где я мог бы представить его на JSConf EU. (...) Я был очень напуган, представляя то, над чем работал шесть месяцев. (...) Все это время я просто думал, Боже мой. Что я здесь делаю?
+  <p markdown = "1" class = "pquote-credit">
+- @ry, ["История Node.js" (видео)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+  </p>
+</aside>
+
+## Создайте репутацию
+
+В дополнение к стратегиям, описанным выше, лучший способ пригласить людей делиться вашим проектом и вносить в него вклад - это делиться их проектами и вносить в них свой вклад.
+
+Помощь новичкам, обмен ресурсами и вдумчивый вклад в проекты других помогут вам заработать положительную репутацию. Если вы будете активным членом сообщества разработчиков ПО с открытым исходным кодом, это поможет людям понять контекст вашей работы и с большей вероятностью обратит внимание на ваш проект и поделится им. Развитие отношений с другими проектами с открытым исходным кодом может даже привести к официальному партнерству.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/shazow?s=180" class = "pquote-avatar" alt = "avatar">
+  Единственная причина, по которой urllib3 является сегодня самой популярной сторонней библиотекой Python, заключается в том, что она является частью запросов.
+  <p markdown = "1" class = "pquote-credit">
+- @shazow, [«Как сделать так, чтобы ваш проект с открытым исходным кодом процветал»](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+  </p>
+</aside>
+
+Никогда не рано и не поздно начать укреплять свою репутацию. Даже если вы уже запустили собственный проект, продолжайте искать способы помочь другим.
+
+Не существует мгновенного решения для создания аудитории. Чтобы завоевать доверие и уважение окружающих, нужно время, а создание вашей репутации никогда не заканчивается.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/ariya?s=180" class = "pquote-avatar" alt = "avatar">
+  PhantomJS был выпущен впервые в начале 2011 года. (...) Я распространял информацию обычными способами: я писал об этом в Твиттере, я писал сообщения в блогах о том, что вы можете с ним делать, я упоминал об этом во время различных обсуждений на митапах. Когда об этом стало больше известно в 2014 году, я начал делать презентации об этом.
+  <p markdown = "1" class = "pquote-credit">
+- @ariya, ["Истории сопровождающих"](https://github.com/open-source/stories/ariya)
+  </p>
+</aside>
+
+## Держись! Не сдавайся!
+
+Может пройти много времени, прежде чем люди заметят ваш проект с открытым исходным кодом. Это нормально! Некоторым из самых популярных сегодня проектов потребовались годы, чтобы достичь высокого уровня активности. Сосредоточьтесь на построении отношений, а не на надежде, что ваш проект спонтанно станет популярным. Будьте терпеливы и продолжайте делиться своей работой с теми, кто ее ценит.
diff --git a/_articles/ru/getting-paid.md b/_articles/ru/getting-paid.md
new file mode 100644
index 00000000000..81a91459fae
--- /dev/null
+++ b/_articles/ru/getting-paid.md
@@ -0,0 +1,191 @@
+---
+lang: ru
+title: Получение денег за работу над открытым кодом
+description: Подкрепите свою работу над открытым кодом, получая финансовую поддержку за ваше время и ваш проект
+class: getting-paid
+toc:
+  почему-некоторые-люди-ищут-финансовую-поддержку: 'Почему некоторые люди ищут финансовую поддержку'
+  финансирование-собственного-времени: 'Вложение собственного времени'
+  поиск-финансирования-для-вашего-проекта: 'Поиск финансирования для вашего проекта'
+  создание-аргументов-в-пользу-финансовой-поддержки: 'Создание причин для финансовой поддержки'
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+  - best-practices
+  - leadership
+---
+
+## Почему некоторые люди ищут финансовую поддержку
+
+Большая часть работы с открытым кодом осуществляется добровольцами. Например, кто-то может столкнуться с ошибкой в используемом им проекте и отправить исправление. А кому-то нравится заниматься проектом в свободное время.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
+Мне нужно было хобби на неделю перед рождеством (...) У меня под рукой был только домашний компьютер. Я решил написать интерпретатор для нового языка сценариев, о котором думал в последнее время. (...) В качестве рабочего названия я выбрал "питон".
+  <p markdown="1" class="pquote-credit">
+— @gvanrossum, ["Программирование на питоне"](https://www.python.org/doc/essays/foreword/)
+  </p>
+</aside>
+
+Есть много причин, по которым человек не хотел бы получать деньги за свою работу с открытым исходным кодом.
+
+* **Возможно, у них уже есть любимая работа на полный рабочий день,** которая позволяет им вносить свой вклад в разработку открытого исходного кода в свободное время.
+* **Им нравится думать об открытом исходном коде как об увлечении** или творческом пути, и они не хотят чувствовать себя финансово обязанными работая над своими проектами.
+* **Они получают другие преимущества от участия в разработке открытого исходного кода**, такие как создание своей репутации или портфолио, обучение новым навыкам или чувство близости к сообществу.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
+  Финансовые пожертвования действительно добавляют некоторым людям чувство ответственности. (...) Для нас, в глобально связанном, быстро меняющемся мире, в котором мы живем, важно иметь возможность сказать: «Не сейчас. Я чувствую, что хочу сделать что-то совершенно другое».
+  <p markdown="1" class="pquote-credit">
+— @alloy, ["Почему мы не принимаем финансовые пожертвования"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+  </p>
+</aside>
+
+Для других, особенно когда сообщество активно пишет код и требуется тратить много времени, получение оплаты за участие в проекте с открытым кодом - единственный способ участвовать, либо потому, что этого требует проект, либо по личным причинам.
+
+Поддержка популярных проектов может стать серьезной обязанностью, занимающей 10 или 20 часов в неделю вместо нескольких часов в месяц.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
+Спросите любого сопровождающего проект с открытым кодом, и он расскажет вам, какой объем работы уходит на управление проектом. У вас есть клиенты. Вы решаете для них проблемы. Вы создаете новые функции. Возникает большая потребность в вашем времени.  
+<p markdown="1" class="pquote-credit">
+— @ashedryden, ["Этика неоплачиваемого труда в сообществах открытого кода"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+  </p>
+</aside>
+
+Оплачиваемая работа также позволяет людям из разных слоев общества вносить значимый вклад. Некоторые люди не могут позволить себе тратить неоплачиваемое время на проекты с открытым исходным кодом из-за своего текущего финансового положения, долга, семейных или других обязанностей по уходу. Это означает, что мир никогда не увидит вклада талантливых людей, которые не могут позволить себе добровольно тратить свое время. Это имеет этические последствия, как @ashedryden [описал](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), поскольку выполняемая работа смещена в пользу тех, кто уже имеет преимущества в жизни, которые затем получают дополнительные преимущества на основе их добровольного вклада, в то время как другие, которые не могут быть волонтерами, не получают более поздних возможностей, что усиливает текущий недостаток разнообразия в сообществе открытого исходного кода.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
+   Сообщества открытых проектов приносят огромные выгоды технологической отрасли, что, в свою очередь, приносит пользу всем отраслям. (...) Однако, если сосредоточиться на этом могут только удачливые и одержимые, то возникает огромный неиспользованный потенциал.
+  <p markdown="1" class="pquote-credit">
+— @isaacs, ["Деньги и открытый код"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+  </p>
+</aside>
+
+Если вам нужна финансовая поддержка, можно рассмотреть два пути. Вы можете финансировать свое собственное время в качестве участника или можете найти организационное финансирование для проекта.
+
+## Финансирование собственного времени
+
+Сегодня многим людям платят за работу над открытым кодом неполный или полный рабочий день. Самый распространенный способ получить деньги за свое время - поговорить со своим работодателем.
+
+Если ваш работодатель действительно использует проект, будет проще обосновать необходимость работы над открытым кодом, но подойдите к делу творчески. Возможно, ваш работодатель не использует этот проект, но он использует питон, а поддержка популярного проекта питон помогает привлечь новых разработчиков питон. Может быть, это в целом делает вашего работодателя более дружелюбным к разработчикам.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
+Как и многие другие разработчики ПО с открытым кодом, я боролся с бременем поддержки проекта. Когда я только начинал заниматься открытым кодом, я просто задерживался допоздна, чтобы поработать над ним, или прямо по возвращении домой. (...) Я смог обсудить со своим начальником проблемы, с которыми я столкнулся, и мы пришли к идее о том, что мы могли бы включить в работу задачи с открытым кодом, учитывая наше собственное использование Babel.  
+<p markdown="1" class="pquote-credit">
+— @hzoo, ["Истории сопровождающих"](https://github.com/open-source/stories/hzoo)
+  </p>
+</aside>
+
+Если у вас нет существующего проекта с открытым кодом, над которым вы хотели бы работать, но вы предпочитаете, чтобы ваши текущие результаты работы были с открытым кодом, попросите вашего работодателя открыть код некоторых внутренних программ.
+
+Многие компании разрабатывают программы с открытым кодом, чтобы создать свой бренд и нанять квалифицированных специалистов.
+
+@hueniverse, например, обнаружил финансовые причины [инвестиций Walmart в открытый код](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). А @jamesgpearce обнаружил, что инициативы открытого кода Facebook [изменили](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) кадровую политику:
+
+> Это тесно связано с нашей хакерской культурой и тем, как воспринималась наша организация. Мы спросили наших сотрудников: «Вы знали о программе с открытым исходным кодом Facebook?». Две трети ответили «Да». Половина сказала, что программа положительно повлияла на их решение работать на нас. Это не маргинальные цифры, и я надеюсь, что тенденция сохранится.
+
+Если ваша компания идет по этому пути, важно сохранять четкие границы между общественной и корпоративной деятельностью. В конечном итоге открытый код поддерживает себя за счет вклада людей со всего мира, и это больше, чем любая другая компания или место.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
+  Получать деньги за работу с открытым исходным кодом - редкая и прекрасная возможность, но вы не должны отказываться от своей страсти в процессе. Ваша страсть должна быть причиной, почему компании хотят платить вам.
+  <p markdown="1" class="pquote-credit">
+— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+  </p>
+</aside>
+
+Если не получается убедить работодателя в важности работы над открытым кодом, можете подумать о поиске нового работодателя, который будет поощрять вклад сотрудников в разработку открытого кода. Ищите компании, которые открыто заявляют о своей приверженности работе с открытым кодом. Например:
+
+* Некоторые компании как [Netflix](https://netflix.github.io/) или [PayPal](https://paypal.github.io/), имеют веб-сайты, которые подчеркивают их участие в открытых проектах
+* [Zalando](https://opensource.zalando.com) опубликовали свою [политику участия в открытых проектах](https://opensource.zalando.com/docs/using/contributing/) для работников.
+
+Проекты, инициированные крупной компанией вроде [Go](https://github.com/golang) или [React](https://github.com/facebook/react), также, вероятно, будут нанимать людей для работы с открытым кодом.
+
+В зависимости от ваших личных обстоятельств вы можете попытаться собрать деньги самостоятельно для финансирования своей работы с открытым исходным кодом. Например:
+
+* @gaearon нашёл финансирование для [Redux](https://github.com/reactjs/redux) через [кампанию краудфайндинга на Patreon](https://redux.js.org/)
+* @andrewgodwin нашёл финансирование миграции схемы Django [через кампанию на Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django).
+
+Иногда открытые проекты размещают вознаграждение за задачи, над которыми вы могли бы поработать.
+
+* @ConnorChristie получал оплату, [помогая](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol над иж JavaScript библиотекой через [gitcoin.co](https://gitcoin.co/).
+* @mamiM сделал перевод на японский @MetaMask за вознаграждение на [Bounties Network](https://explorer.bounties.network/bounty/134).
+
+## Поиск финансирования для вашего проекта
+
+Помимо договоренностей с отдельными разработчиками, иногда проекты собирают деньги от компаний и частных лиц для финансирования текущей работы.
+
+Организационное финансирование может быть направлено на оплату текущим разработчикам, покрытие расходов на ведение проекта (например, плату за хостинг) или инвестирование в новые функции или идеи.
+
+Поскольку популярность открытого исходного кода растет, поиск финансирования для проектов все еще является экспериментальным, но есть несколько общих доступных вариантов.
+
+### Краудфайндинг и спонсоры
+
+Поиск спонсоров хорошо работает, если к вам есть сильный интерес, или у вас есть репутация, или ваш проект очень популярен.
+Вот несколько примеров спонсируемых проектов:
+
+* **[webpack](https://github.com/webpack)** привлекает деньги от компаний и частных лиц [through OpenCollective](https://opencollective.com/webpack)
+* **[Vue](https://github.com/vuejs/vue)** [спонсируется через Patreon](https://github.com/open-source/stories/yyx990803)
+* **[вместе с Ruby](https://rubytogether.org/),** - некоммерческая организация, которая платит за работу над [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), и над другими проектами инфраструктуры Ruby
+
+### Создайте поток доходов
+
+В зависимости от вашего проекта вы можете взимать плату за коммерческую поддержку, варианты размещения или дополнительные функции. Вот несколько примеров:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** предлагает платные версии за дополнительную плату
+* **[Travis CI](https://github.com/travis-ci)** предлагает платные версии своего продукта
+* **[Ghost](https://github.com/TryGhost/Ghost)** - это некоммерческая организация с платными услугами
+
+Некоторые популярные проекты как [npm](https://github.com/npm/npm) и [Docker](https://github.com/docker/docker), даже привлекают венчурные инвестиции для поддержания роста своих проектов.
+
+### Подайте заявку на грант
+
+Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** получил [грант поддержки открытого кода Mozilla](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)** был профинансирован [приютом открытого кода от Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** получил грант от [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* **[Python Software Foundation](https://www.python.org/psf/grants/)** предлагает гранты на работу, связанную с питоном
+
+Более подробные варианты и тематические исследования вы можете прочитать в [руководстве](https://github.com/nayafia/lemonade-stand) по получению оплаты за работу с открытым кодом от @nayafia. Для разных типов финансирования требуются разные навыки, поэтому определите свои сильные стороны, чтобы выяснить, какой вариант лучше всего подходит для вас.
+
+## Создание аргументов в пользу финансовой поддержки
+
+Независимо от того, является ли ваш проект новой идеей или уже существует много лет, вы должны серьезно подумать, чтобы определить своего целевого спонсора и представить убедительные доводы.
+
+Независимо от того, хотите ли вы оплачивать свое собственное время или собрать средства для проекта, вы должны ответить на следующие вопросы.
+
+### Влияние
+
+Чем полезен этот проект? Почему вашим пользователям или потенциальным пользователям он так нравится? Где он будет через пять лет?
+
+### Притягательность для людей
+
+Постарайтесь собрать доказательства того, что ваш проект значимый, будь то показатели, анекдоты или отзывы. Есть ли какие-нибудь компании или известные люди, использующие ваш проект прямо сейчас? Если нет, то одобрил ли это известный человек?
+
+### Ценность для спонсора
+
+К спонсорам, будь то ваш работодатель или грантодательский фонд, часто обращаются с предложениями. Почему они должны поддерживать именно ваш проект? Какую выгоду они получат лично?
+
+### Использование денежных средств
+
+Чего именно вы добьетесь с предложенным финансированием? Сосредоточьтесь на вехах или результатах проекта, а не на зарплате.
+
+### Как вы получите средства
+
+Есть ли у спонсора какие-либо требования относительно выплаты грантов? Например, вам может потребоваться быть некоммерческой организацией или иметь некоммерческого финансового спонсора. Или, возможно, средства должны быть переданы индивидуальному подрядчику, а не организации. Эти требования различаются в зависимости от спонсора, поэтому не забудьте заранее изучить вопрос.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
+В течение многих лет мы были ведущим источником удобных для сайтов иконок, с сообществом более 20 миллионов человек и были представлены на более чем 70 миллионах веб-сайтов, включая сайт Белого дома Whitehouse.gov. (...) Версия 4 была три года назад. С тех пор веб-технологии сильно изменились, и, честно говоря, Font Awesome немного устарел. (...) Вот почему мы представляем Font Awesome 5. Мы модернизируем и переписываем CSS и переделываем каждый значок сверху донизу. Мы говорим о лучшем дизайне, большей согласованности и лучшей читаемости.
+<p markdown="1" class="pquote-credit">
+— @davegandy, [видео на Kickstarter о Font Awesome](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+  </p>
+</aside>
+
+## Экспериментируйте и не сдавайтесь
+
+Собирать деньги непросто, будь то проект с открытым кодом, некоммерческая организация или стартап программного обеспечения, и в большинстве случаев от вас требуется проявить творческий подход. Определив, как вы хотите получать деньги, проведя исследования и поставив себя на место спонсора, вы сможете убедительно обосновать необходимость финансирования.
diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
new file mode 100644
index 00000000000..97980e8d6b1
--- /dev/null
+++ b/_articles/ru/how-to-contribute.md
@@ -0,0 +1,534 @@
+---
+lang: ru
+title: Как участвовать в открытых проектах
+description: Хотите участвовать в открытых проектах? Руководство по участию для новичков и ветеранов.
+class: contribute
+toc:
+  зачем-участвовать-в-открытых-проектах: 'Зачем участвовать в открытых проектах'
+  что-значит-внести-свой-вклад-to-contribute: 'Что значит внести свой вклад (to contribute)'
+  ориентация-на-новый-проект: 'Ориентация на новый проект'
+  поиск-проекта-в-который-можно-внести-свой-вклад: 'Поиск проекта, в который можно внести свой вклад'
+  как-отправить-вклад: 'Как отправить вклад'
+  что-происходит-после-того-как-вы-отправите-свой-вклад: 'Что происходит после того, как вы отправите свой вклад'
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+  - beginners
+  - building
+---
+
+## Зачем участвовать в открытых проектах?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
+  Работа над \[freenode\] помогла мне приобрести многие навыки, которые я позже использовал в учебе в университете и в текущей работе. Я думаю, что работа над проектами с открытым исходным кодом помогает мне не меньше, чем самому проекту!
+  <p markdown="1" class="pquote-credit">
+— @errietta, ["Почему я люблю участвовать в работе над открытым софтом"](https://www.errietta.me/blog/open-source/)
+  </p>
+</aside>
+
+Участие в разработке программного обеспечения с открытым исходным кодом может быть полезным способом изучать, обучать и приобретать опыт практически в любом навыке, который вы можете себе представить.
+
+Почему люди вносят свой вклад в открытый исходный код? Множество причин!
+
+### Улучшайте программное обеспечение, на которое вы полагаетесь
+
+Многие участники открытого кода начинают с того, что являются пользователями программного обеспечения, в которое они вносят свой вклад. Когда вы обнаружите ошибку в программном обеспечении с открытым исходным кодом, которое вы используете, вы можете посмотреть в исходный код, чтобы узнать, можете ли вы исправить его самостоятельно. Если это так, то возвращение патча - лучший способ убедиться, что ваши друзья (и вы сами, когда вы обновитесь до следующего выпуска) смогут извлечь из него пользу.
+
+### Улучшить существующие навыки
+
+Будь то программирование, дизайн пользовательского интерфейса, графический дизайн, написание текста или организационная работа, если вы ищете практику, для вас найдётся задача в проекте с открытым исходным кодом.
+
+### Знакомьтесь с людьми, которым интересны похожие вещи
+
+Проекты с открытым исходным кодом с теплыми, гостеприимными сообществами заставляют людей возвращаться долгие годы. Многие люди завязывают дружбу на всю жизнь благодаря участию в открытых проектах, будь то встреча друг с другом на конференциях или поздних ночных онлайн-чатах о буррито.
+
+### Найдите наставников и научите других
+
+Работа с другими над общим проектом означает, что вам придется объяснять, как вы это делаете, а также просить помощи у других. Акты обучения и преподавания могут быть полезными для всех участников.
+
+### Создавайте общедоступные артефакты, которые помогут вам повысить репутацию (и карьеру)
+
+По определению, вся ваша работа с открытым исходным кодом является общедоступной, что означает, что вы получаете бесплатные примеры, которые можно использовать где угодно в качестве демонстрации того, что вы можете делать.
+
+### Изучите навыки работы с людьми
+
+Открытый исходный код предлагает возможности практиковать лидерские и управленческие навыки, такие как разрешение конфликтов, организация групп людей и определение приоритетов в работе.
+
+### Это дает возможность вносить изменения, даже небольшие.
+
+Необязательно становиться участником на протяжении всей жизни, чтобы получать удовольствие от участия в проектах с открытым исходным кодом. Вы когда-нибудь видели опечатку на сайте и хотели бы, чтобы кто-нибудь ее исправил? В проекте с открытым исходным кодом вы можете это сделать. Открытый исходный код помогает людям чувствовать свободу в своей жизни и в том, как они воспринимают мир, и это само по себе отрадно.
+
+## Что значит внести свой вклад (to contribute)
+
+Если вы новичок в open source, процесс может быть пугающим. Как найти подходящий проект? Что делать, если вы не умеете программировать? Что если что-то пойдет не так?
+
+Не беспокойтесь! Есть много способов принять участие в проекте с открытым исходным кодом, и несколько советов помогут вам извлечь максимальную пользу из вашего опыта.
+
+### Вам не нужно вносить код
+
+Распространенное заблуждение об участии в разработке открытого исходного кода состоит в том, что вам нужно писать код. Зачастую есть другие части проекта, [наиболее игнорируемые или упускаемые из виду](https://github.com/blog/2195-the-shape-of-open-source). Вы окажете проекту огромную услугу, предложив поработать над этим!
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
+  Я известен своей работой над CocoaPods, но большинство людей не знают, что я на самом деле не работаю над самим инструментом CocoaPods. В основном я занимаюсь документацией и брендингом.
+  <p markdown="1" class="pquote-credit">
+— @orta, ["Переход на открытый исходный код по умолчанию"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+  </p>
+</aside>
+
+Даже если вам нравится писать код, другие виды участия - отличный способ поучаствовать в проекте и познакомиться с другими членами сообщества. Построение этих отношений даст вам возможность работать над другими частями проекта.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
+Я впервые обратился к команде разработчиков Python (также известной как python-dev), когда 17 июня 2002 года отправил по электронной почте список рассылки с просьбой принять мой патч. Я быстро заметил ошибку в открытом исходном кода и решил начать готовить дайджесты электронной почты для группы. Они дали мне отличный повод попросить разъяснений по теме, но, что более важно, я мог заметить, когда кто-то указывал на что-то, что требовало исправления.  <p markdown="1" class="pquote-credit">
+— @brettcannon, ["Истории сопровождающего"](https://github.com/open-source/stories/brettcannon)
+  </p>
+</aside>
+
+### Вы любите планировать мероприятия?
+
+* Организуйте семинары или встречи по проекту, [как @fzamperin сделал для NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Организуйте конференцию проекта (если она есть)
+* Помогите участникам сообщества найти подходящие конференции и подать предложения для выступления
+
+### Любите проектировать?
+
+* Реструктурируйте макетов для повышения удобства использования проекта.
+* Проведите исследование пользователей, чтобы реорганизовать и уточнить навигацию или меню проекта [как предлагает Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Составьте руководство по стилю, чтобы помочь проекту иметь единый визуальный дизайн.
+* Создайте изображения для футболок или новый логотип [как это сделали участники hapi.js](https://github.com/hapijs/contrib/issues/68)
+
+### Любите писать?
+
+* Напишите и улучшите документацию по проекту
+* Создайте папку с примерами, показывающими, как используется проект
+* Начните рассылку новостей по проекту или отредактируйте основные моменты из списка рассылки
+* Напишите учебники для проекта [как это сделали участники PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Напишите перевод документации по проекту
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/kittens?s=180" class = "pquote-avatar" alt = "avatar">
+  Кроме шуток, \[документация\] мега важна. Документация до сих пор была отличной и была ключевой особенностью Бабеля (Babel). Есть разделы, которые требуют доработку, и даже добавление параграфа здесь или там чрезвычайно приветствуется.
+  <p markdown = "1" class = "pquote-credit">
+- @kittens, ["Призыв участников"](https://github.com/babel/babel/issues/1347)
+  </p>
+</aside>
+
+### Любите организовывать?
+
+* Выставляйте ссылки на повторяющиеся вопросы (issues) и предлагайте новые ярлыки для вопросов, чтобы все было организовано
+* Просмотрите открытые вопросы и предложите закрыть старые [например, @nzakas для ESLint](https://github.com/eslint/eslint/issues/6765)
+* Задавайте уточняющие вопросы по недавно открывшимся вопросам, чтобы продвинуть обсуждение вперед
+
+### Любите кодить?
+
+* Найдите открытую проблему для решения [например, @dianjin сделал для Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Спросите, можете ли вы помочь написать новую функцию
+* Автоматизируйте настройку проекта
+* Улучшите инструменты и тестирование
+
+### Любите помогать людям?
+
+* Ответьте на вопросы о проекте, например, на Stack Overflow ([как в этом примере Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) или Reddit
+* Отвечайте на вопросы людей по открытым вопросам
+* Помогите модерировать доски обсуждений или каналы в чатах
+
+### Нравится ли вам помогать другим кодить?
+
+* Проверяйте код других людей
+* Напишите учебные пособия по использованию проекта
+* Предложите стать наставником другого участника [как @ereichert сделал для @bronzdoc на Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### Можно работать не только над программными проектами!
+
+Хотя «открытый исходник» часто относится к программному обеспечению, вы можете сотрудничать практически над чем угодно. Есть книги, рецепты, списки и классы, которые разрабатываются как проекты с открытым исходным кодом.
+
+Например:
+
+* @sindresorhus создает [список "классных" списков](https://github.com/sindresorhus/awesome)
+* @h5bp ведет [список потенциальных вопросов на собеседовании](https://github.com/h5bp/Front-end-Developer-Interview-Questions) для кандидатов в разработчики интерфейсов.
+* @stuartlynn и @ nicole-a-tesla сделали [сборник забавных фактов о тупиках](https://github.com/stuartlynn/puffin_facts)
+
+Даже если вы разработчик программного обеспечения, работа над документацией проекта может помочь вам начать работу с открытым проектом. Работать над проектами, не использующими код, зачастую не так страшно, и процесс совместной работы укрепит вашу уверенность и опыт.
+
+## Ориентация на новый проект
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/shaunagm?s=180" class = "pquote-avatar" alt = "avatar">
+  Если вы обращаетесь к системе отслеживания вопросов (issue), и вас она сбивает с толку, дело не только в вас. Эти инструменты требуют большого количества неявных знаний, но люди могут помочь вам сориентироваться в них, и вы можете задать им вопросы.
+  <p markdown = "1" class = "pquote-credit">
+- @shaunagm, [«Как внести свой вклад в разработку открытого исходного кода»](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+  </p>
+</aside>
+
+Для чего-то большего, чем исправление опечатки, участие в открытом проекте похоже на поход к группе незнакомцев на вечеринке. Если вы начнете говорить о ламах, когда они были увлечены дискуссией о золотых рыбках, они, вероятно, будут смотреть на вас немного странно.
+
+Прежде чем вслепую приступить к своим собственным предложениям, начните с изучения обстановки в сообществе. Это увеличивает шансы на то, что ваши идеи будут замечены и услышаны.
+
+### Анатомия проекта с открытым исходным кодом
+
+Каждое сообщество с открытым исходным кодом отличается.
+
+Потратить годы на один открытый проект означает, что вы познакомились с одним открытым проектом. Переходите к другому проекту, и вы можете обнаружить, что словарный запас, нормы и стили общения совершенно другие.
+
+Тем не менее, многие проекты с открытым исходным кодом следуют схожей организационной структуре. Понимание различных ролей сообщества и общего процесса поможет вам быстро сориентироваться в любом новом проекте.
+
+Типичный проект с открытым исходным кодом состоит из следующих типов людей:
+
+* **Автор:** Человек или организация, создавшие проект.
+* **Владелец:** Лицо, которое имеет административное право собственности на организацию или репозиторий (не всегда то же самое, что и первоначальный автор).
+* **Сопровождающие:** Соавторы, которые несут ответственность за формирование видения и управление организационными аспектами проекта (они также могут быть авторами или владельцами проекта).
+* **Соавторы:** Все, кто внес свой вклад в проект.
+* **Участники сообщества:** Люди, которые используют проект. Они могут быть активными в беседах или высказывать свое мнение о направлении проекта.
+
+В более крупных проектах также могут быть подкомитеты или рабочие группы, занимающиеся различными задачами, такими как инструменты, сортировка, модерация сообщества и организация мероприятий. Поищите на веб-сайте проекта или репозитории "командную" или "организационную" страницу, чтобы найти эту информацию.
+
+У проекта также есть документация. Эти файлы обычно перечислены на верхнем уровне репозитория.
+
+* **ЛИЦЕНЗИЯ:** По определению, каждый проект с открытым исходным кодом должен иметь [лицензию с открытым исходным кодом](https://choosealicense.com). Если у проекта нет лицензии, он не является открытым исходным кодом.
+* **README:** README * это инструкция, которая приветствует новых членов сообщества в проекте. В нем объясняется, почему проект полезен и с чего начать.
+* **УЧАСТИЕ (CONTRIBUTING):** В то время как README помогают людям _использовать_ проект, документация участников помогает людям _вносить_ свой вклад в проект. В нем объясняется, какие виды помощи необходимы и как работает этот процесс. Хотя не у каждого проекта есть файл CONTRIBUTING, его наличие свидетельствует о дружелюбном отношении к участникам.
+* **КОДЕКС ПОВЕДЕНИЯ (CODE_OF_CONDUCT):** Кодекс поведения устанавливает основные правила поведения участников и помогает создать дружелюбную, гостеприимную атмосферу. Хотя не в каждом проекте есть файл CODE_OF_CONDUCT, его наличие свидетельствует о том, что это хороший проект, в который можно внести свой вклад.
+* **Другая документация:** Может быть дополнительная документация, такая как учебные пособия, пошаговые руководства или политики управления, особенно для более крупных проектов.
+
+Наконец, в проектах с открытым исходным кодом для организации обсуждения используются следующие инструменты. Чтение архивов даст вам хорошее представление о том, как сообщество думает и работает.
+
+* **Отслеживание проблем (issue tracker):** Где люди обсуждают вопросы, связанные с проектом.
+* **Запросы на исправление (pull request):** Где люди обсуждают и просматривают запросы на изменение кода.
+* **Дискуссионные форумы или списки рассылки:** Некоторые проекты могут использовать эти каналы для разговорных тем (например, _"Как мне ..."_ или _"Что вы думаете о ..."_ вместо отчётов об ошибках и просьбе новых функций). Другие используют issues для всех разговоров.
+* **Синхронный канал чата:** Некоторые проекты используют каналы чата (например, Slack или IRC) для спонтанного общения, совместной работы и быстрого обмена мнениями.
+
+## Поиск проекта, в который можно внести свой вклад
+
+Теперь, когда вы разобрались, как работают проекты с открытым исходным кодом, пришло время найти проект, в который вы можете внести свой вклад!
+
+Если вы никогда раньше не участвовали в разработке открытого исходного кода, прислушайтесь к совету президента США Джона Ф. Кеннеди, который однажды сказал: «Не спрашивайте, что ваша страна может сделать для вас - спросите, что вы можете сделать для своей страны».
+
+Содействие развитию открытого исходного кода происходит на всех уровнях, в рамках проектов. Вам не нужно задумываться, какой именно будет ваш первый вклад или как он будет выглядеть.
+
+Вместо этого начните с размышлений о проектах, которые вы уже используете или хотите использовать. Проекты, в которых вы будете активно участвовать, - это те, к которым вы вернетесь.
+
+В рамках этих проектов, когда вы ловите себя на мысли, что что-то может быть лучше или иначе, действуйте в соответствии со своим инстинктом.
+
+Открытый исходный код - это не эксклюзивный клуб; это делают такие же люди, как вы. «Открытый исходный код» - это всего лишь причудливый термин для обозначения мировых проблем как решаемых.
+
+Вы можете просканировать README и найти неработающую ссылку или опечатку. Или вы новый пользователь, и вы заметили, что что-то сломано, или недостаток в документации. Вместо того, чтобы игнорировать это и двигаться дальше или просить кого-нибудь исправить это, посмотрите, можете ли вы помочь, приняв участие. Вот в чем суть открытого исходного кода!
+
+> [28% случайных вкладов](https://www.igor.pro.br/publica/papers/saner2016.pdf) в открытый исходный код представляют собой документацию, такую ​​как исправление опечатки, переформатирование или написание перевода.
+
+Если вы ищете существующие проблемы, которые можно исправить, в каждом проекте с открытым исходным кодом есть страница `/contribute`, на которой освещаются проблемы, удобные для начинающих, с которых вы можете начать. Перейдите на главную страницу репозитория на GitHub и добавьте в конец URL-адреса «/contribute (например, [https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+Вы также можете использовать один из следующих ресурсов, чтобы открыть для себя новые проекты и внести свой вклад в них:
+
+* [Обзор GitHub](https://github.com/explore/)
+* [Пятница с открытым исходным кодом](https://opensourcefriday.com)
+* [Только для новичков](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 запроса на слияние](https://24pullrequests.com/)
+* [Готово](https://up-for-grabs.net/)
+* [Contributor-ninja](https://contributor.ninja)
+* [Первые взносы](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
+
+### Контрольный список перед тем, как внести свой вклад
+
+Когда вы нашли проект, в который хотели бы внести свой вклад, сделайте быстрый обзор, чтобы убедиться, что проект принимает стороннюю помощь. В противном случае ваш упорный труд может никогда не получить отклика.
+
+Вот удобный контрольный список, чтобы оценить, подходит ли проект для новых участников.
+
+**Соответствует определению открытого исходного кода**
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox1" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox1" class = "overflow-hidden d-block text-normal">
+  Есть ли у него лицензия? Обычно в корне репозитория находится файл LICENSE.
+  </label>
+</div>
+
+**Проект активно принимает взносы**
+
+Посмотрите на изменения (commits) в основной ветке. На GitHub вы можете увидеть эту информацию на домашней странице репозитория.
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox2" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox2" class = "overflow-hidden d-block text-normal">
+  Когда было последнее изменение?
+  </label>
+</div>
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox3" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox3" class = "overflow-hidden d-block text-normal">
+  Сколько участников у проекта?
+  </label>
+</div>
+
+<div class = "clearfix mb-4">
+  <input type = "checkbox" id = "cbox4" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox4" class = "overflow-hidden d-block text-normal">
+  Как часто люди совершают правки? (На GitHub вы можете найти это, щелкнув «Commits» на верхней панели.)
+  </label>
+</div>
+
+Затем посмотрите на проблемы (issues) проекта.
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox5" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox5" class = "overflow-hidden d-block text-normal">
+    Сколько сейчас открытых вопросов?
+  </label>
+</div>
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox6" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox6" class = "overflow-hidden d-block text-normal">
+    Насколько быстро сопровождающие реагируют на проблемы, когда они открываются?
+  </label>
+</div>
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox7" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox7" class = "overflow-hidden d-block text-normal">
+    Идет ли активное обсуждение вопросов?
+  </label>
+</div>
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox8" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox8" class = "overflow-hidden d-block text-normal">
+    Проблемы недавние?
+  </label>
+</div>
+
+<div class = "clearfix mb-4">
+  <input type = "checkbox" id = "cbox9" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox9" class = "overflow-hidden d-block text-normal">
+    Проблемы закрываются? (На GitHub щелкните вкладку «закрытые» на странице «Проблемы» (issues), чтобы увидеть закрытые проблемы.)
+  </label>
+</div>
+
+Теперь проделайте то же самое с запросами на изменение проекта.
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox10" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox10" class = "overflow-hidden d-block text-normal">
+    Сколько существует открытых запросов на изменение?
+  </label>
+</div>
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox20" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox20" class = "overflow-hidden d-block text-normal">
+    Быстро ли реагируют сопровождающие на запросы на изменение, когда они открываются?
+  </label>
+</div>
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox11" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox11" class = "overflow-hidden d-block text-normal">
+    Есть ли активное обсуждение запросов на изменение?
+  </label>
+</div>
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox12" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox12" class = "overflow-hidden d-block text-normal">
+    Были ли запросы на изменение недавно?
+  </label>
+</div>
+
+<div class = "clearfix mb-4">
+  <input type = "checkbox" id = "cbox13" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox13" class = "overflow-hidden d-block text-normal">
+    Как недавно были объединены запросы на изменение? (На GitHub щелкните вкладку «закрытые» на странице «Запросы на изменение, чтобы увидеть закрытые PR.)
+  </label>
+</div>
+
+**Проект приветливый**
+
+Дружелюбный и приветливый проект сигнализирует о том, что они будут восприимчивы к новым участникам.
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox14" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox14" class = "overflow-hidden d-block text-normal">
+    Отвечают ли сопровождающие услужливо на вопросы в проблемах (issues)?
+  </label>
+</div>
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox15" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox15" class = "overflow-hidden d-block text-normal">
+    Дружелюбны ли люди в вопросах, дискуссионном форуме и чате (например, IRC или Slack)?
+  </label>
+</div>
+
+<div class = "clearfix mb-2">
+  <input type = "checkbox" id = "cbox16" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox16" class = "overflow-hidden d-block text-normal">
+    Проверяются ли запросы на изменение?
+  </label>
+</div>
+
+<div class = "clearfix mb-4">
+  <input type = "checkbox" id = "cbox17" class = "d-block float-left mt-1 mr-2" value = "checkbox">
+  <label for = "cbox17" class = "overflow-hidden d-block text-normal">
+    Сопровождающие благодарят людей за их вклад?
+  </label>
+</div>
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/kfogel?s=180" class = "pquote-avatar" alt = "avatar">
+  Всякий раз, когда вы видите длинное обсуждение, выборочно проверяйте ответы основных разработчиков, которые приходят в конце обсуждения. Подводят ли они конструктивные выводы и предпринимают ли шаги, чтобы довести обсуждение до решения, оставаясь при этом вежливыми? Если вы видите, что идет много пламенных войн, это часто является признаком того, что энергия идет на споры, а не на развитие.
+  <p markdown = "1" class = "pquote-credit">
+- @kfogel, [_Proroduction OSS_](https://prodingoss.com/en/evaluating-oss-projects.html)
+  </p>
+</aside>
+
+## Как отправить вклад
+
+Вы нашли проект, который вам нравится, и готовы внести свой вклад. Наконец-то! Вот как правильно получить свой вклад.
+
+### Эффективное общение
+
+Независимо от того, являетесь ли вы единовременным участником или пытаетесь присоединиться к сообществу, работа с другими - один из самых важных навыков, которые вы разовьете в работе с открытым исходным кодом.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/shubheksha?s=180" class = "pquote-avatar" alt = "avatar">
+  \[Как новый участник\] я быстро понял, что мне нужно задавать вопросы, если я хочу иметь возможность закрыть проблему. Я просмотрел кодовую базу. Как только я получил некоторое представление о том, что происходит, я попросил дополнительных указаний. И вуаля! Я смог решить проблему после получения всей необходимой мне информации.
+  <p markdown = "1" class = "pquote-credit">
+- @shubheksha, [Очень ухабистое путешествие новичка по миру открытого исходного кода](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+  </p>
+</aside>
+
+Прежде чем открывать проблему, запрос на изменение или задавать вопрос в чате, помните об этих моментах, чтобы ваши идеи могли эффективно воплощаться в жизнь.
+
+**Дайте контекст.** Помогите другим быстро освоиться. Если вы столкнулись с ошибкой, объясните, что вы пытаетесь сделать и как ее воспроизвести. Если вы предлагаете новую идею, объясните, почему вы думаете, что она будет полезна для проекта (не только для вас!).
+
+> 😇 _"Х не происходит, когда я делаю Y"_
+>
+> 😢 _"X не работает! Исправьте это."_
+
+**Сделайте домашнее задание заранее.** Это нормально не знать что-то, но показать, что вы пробовали. Прежде чем обращаться за помощью, обязательно проверьте README проекта, документацию, проблемы (открытые или закрытые), список рассылки и поищите ответ в Интернете. Люди оценят, когда вы продемонстрируете, что пытаетесь учиться.
+
+> 😇 _"Я не знаю, как реализовать X. Я проверил справочную документацию и не нашел никаких упоминаний."_
+>
+> 😢 _"Как мне сделать X?"_
+
+**Делайте запросы краткими и прямыми.** Как и при отправке электронного письма, каждое сообщение, независимо от того, насколько оно простое или полезное, требует чьей-то проверки. Многие проекты имеют больше поступающих запросов, чем людей, готовых помочь. Будьте лаконичны. Вы увеличите шанс того, что кто-то сможет вам помочь.
+
+> 😇 _"Я хотел бы написать руководство по API."_
+>
+> 😢 _"На днях я ехал по шоссе и остановился заправиться, и тогда у меня возникла замечательная идея, чем мы должны заняться, но прежде чем я это объясню, позвольте мне показать вам ..."_
+
+**Держите все сообщения общедоступными.** Хотя это заманчиво, не обращайтесь к сопровождающим в частном порядке, если вам не нужно делиться конфиденциальной информацией (например, о проблеме безопасности или серьезном нарушении поведения). Если вы сделаете общение публичным, больше людей смогут узнать о нем и извлечь из него пользу. Обсуждения сами по себе могут быть вкладом.
+
+> 😇 _(в качестве комментария) «@-сопровождающий Привет! Как нам обработать этот запрос на изменение?»_
+>
+> 😢 _(по электронной почте) «Привет, извини, что побеспокоил тебя по электронной почте, но мне было интересно, была ли у тебя возможность просмотреть мой PR»_
+
+**Можно задавать вопросы (но будьте терпеливы!).** В какой-то момент каждый был новичком в проекте, и даже опытным участникам нужно время освоиться, когда они смотрят на новую задачу. Даже давние сопровождающие не всегда знакомы со всеми частями проекта. Проявите к ним такое же терпение, какое вы бы хотели, чтобы они проявили к вам.
+
+> 😇 _"Спасибо, что разобрались с этой ошибкой. Я последовал вашим предложениям. Вот результат."_
+>
+> 😢 _"Почему вы не можете решить мою проблему? Разве это не ваш проект?"_
+
+**Уважайте решения сообщества.** Ваши идеи могут отличаться от приоритетов или видения сообщества. Они могут предложить обратную связь или отказаться от реализации вашей идеи. Хотя вам следует обсуждать и искать компромисс, сопровождающие должны жить с вашим решением дольше, чем вы. Если вы не согласны с их направлением, вы всегда можете работать над собственным ответвлением проекта (fork) или начать собственный проект.
+
+> 😇 _"Я разочарован, что вы не можете поддержать мой вариант использования, но, как вы объяснили, он затрагивает только небольшую часть пользователей, я понимаю почему. Спасибо за внимание."_
+>
+> 😢 _"Почему вы не поддерживаете мой вариант использования? Это недопустимо!"_
+
+**Главное, чтобы он был стильным.** Открытый исходный код состоит из соавторов со всего мира. Контекст теряется из-за языков, культур, географических регионов и часовых поясов. Кроме того, письменное общение затрудняет передачу тона или настроения. В этих разговорах предполагайте добрые намерения. Это нормально - вежливо оттолкнуть идею, попросить более подробный контекст или дополнительно прояснить свою позицию. Просто постарайтесь сделать Интернет лучше, чем когда вы его нашли.
+
+### Сбор контекста
+
+Прежде чем что-либо делать, сделайте быструю проверку, чтобы убедиться, что ваша идея больше нигде не обсуждалась. Просмотрите README проекта, проблемы (открытые и закрытые), список рассылки и Stack Overflow. Вам не нужно тратить часы на все, но быстрый поиск нескольких ключевых слов имеет большое значение.
+
+Если вы не можете найти свою идею в другом месте, вы готовы к действию. Если проект находится на GitHub, вы, скорее всего, будете общаться, открыв задачу или запрос на изменение:
+
+* **Проблемы** похожи на начало разговора или обсуждения
+* **Запросы на изменение** предназначены для начала работы над решением.
+* **Для легкого общения**, например, уточняющего или практического вопроса, попробуйте задать вопрос в Stack Overflow, IRC, Slack или других каналах чата, если он есть в проекте.
+
+Прежде чем открывать задачу или запрос на изменение (pull request), проверьте документацию проекта (обычно это файл с именем CONTRIBUTING или README), чтобы узнать, нужно ли вам включать что-нибудь конкретное. Например, они могут попросить вас следовать шаблону или потребовать, чтобы вы использовали тесты.
+
+Если вы хотите внести существенный вклад, задайте вопрос, прежде чем работать над ним. Полезно некоторое время понаблюдать за проектом (на GitHub [вы можете нажать «Смотреть»](https://help.github.com/articles/watching-repositories/), чтобы получать уведомления обо всех разговорах) и перейти знакомству с членами сообщества, прежде чем выполнять работу, которую могут не принять.
+
+<aside markdown = "1" class = "pquote">
+  <img src = "https://avatars.githubusercontent.com/gaearon?s=180" class = "pquote-avatar" alt = "avatar">
+  Вы научитесь <em>многому</em>, взяв один проект, который вы активно используете, "посмотрев" его на GitHub и прочитав все выпуски и PR.
+<p markdown = "1" class = "pquote-credit">
+- @gaearon [о присоединении к проектам](https://twitter.com/dan_abramov/status/819555257055322112)
+  </p>
+</aside>
+
+### Открытие проблемы (issue)
+
+Обычно вам следует открывать проблему в следующих ситуациях:
+
+* Сообщить об ошибке, которую вы не можете решить самостоятельно
+* Обсудить общую тему или идею (например, сообщество, видение или политику)
+* Предложить новую функцию или другую идею проекта
+
+Советы по общению по проблемам (issue):
+
+* **Если вы видите открытую проблему, которую хотите решить,** прокомментируйте проблему, чтобы люди знали, что вы ее решаете. Таким образом, люди с меньшей вероятностью будут дублировать вашу работу.
+* **Если проблема была открыта некоторое время назад,** возможно, что она решается где-то в другом месте или уже решена, поэтому прокомментируйте, чтобы запросить подтверждение перед началом работы.
+* **Если вы открыли вопрос, но позже самостоятельно выяснили ответ,** прокомментируйте проблему, чтобы люди знали, а затем закройте ее. Даже документирование этого результата является вкладом в проект.
+
+### Открытие запроса на изменение (pull request)
+
+Обычно вы должны открывать запрос на изменение в следующих ситуациях:
+
+* Отправляйте тривиальные исправления (например, опечатку, неработающую ссылку или очевидную ошибку)
+* Начните работать над тем, что уже было запрошено или что вы уже обсуждали в вопросе (issue)
+
+Запрос на исправление не обязательно должен представлять законченную работу. Обычно лучше открывать запрос на изменение на раннем этапе, чтобы другие могли наблюдать за вашим прогрессом или оставлять отзывы о нем. Просто отметьте это как "WIP" (Work in Progress) «незавершенное производство» в строке темы. Вы всегда можете добавить больше коммитов позже.
+
+Если проект находится на GitHub, вот как отправить запрос на перенос:
+
+* **[Скопируйте репозиторий](https://guides.github.com/activities/forking/)** и клонируйте его локально. Подключите ваш локальный компьютер к исходному «вышестоящему» репозиторию, добавив его как удаленный. Часто вносите изменения из «восходящего потока», чтобы оставаться в курсе последних событий, чтобы при отправке запроса на включение конфликты слияния были менее вероятными. (См. Более подробные инструкции [здесь](https://help.github.com/articles/syncing-a-fork/).)
+* **[Создать ветку](https://guides.github.com/introduction/flow/)** для ваших правок.
+* **Ссылайтесь на любые относящиеся к делу проблемы (issues)** или подтверждающую документацию в своем PR (например, Закрывает #37»).
+* **Включите скриншоты до и после**, если ваши изменения включают различия в HTML/CSS. Перетащите изображения в тело запроса на изменение.
+* **Протестируйте свои изменения!** Запустите свои изменения в сравнении с любыми существующими тестами, если они существуют, и при необходимости создайте новые. Независимо от того, существуют тесты или нет, убедитесь, что ваши изменения не нарушают существующий проект.
+* **Внесите свой вклад в стиль проекта** в меру своих возможностей. Это может означать использование отступов, точек с запятой или комментариев иначе, чем в вашем собственном репозитории, но упрощает для сопровождающего объединение, а другим - для понимания и поддержки в будущем.
+
+Если это ваш первый запрос на изменение, ознакомьтесь с [Сделать запрос на извлечение](http://makeapullrequest.com/), который @kentcdodds создал как пошаговое видео-руководство. Вы также можете попрактиковаться в создании запроса на изменение в репозитории [Первые вклады](https://github.com/Roshanjossey/first-contributions), созданном @Roshanjossey.
+
+## Что происходит после того, как вы отправите свой вклад
+
+Вы сделали это! Поздравляем, вы стали участником программы с открытым исходным кодом. Надеемся, это первый из многих.
+
+После того, как вы отправите вклад, произойдет одно из следующих событий:
+
+### 😭 Вы не получите ответ.
+
+Надеюсь, вы [проверили проект на наличие признаков активности](#контрольный-список-перед-тем-как-внести-свой-вклад) перед тем, как внести свой вклад. Однако даже в активном проекте возможно, что ваш вклад не получит отклика.
+
+Если вы не получили ответа в течение недели, будет справедливо вежливо ответить в той же теме и попросить кого-нибудь дать отзыв. Если вы знаете имя человека, который рассмотрит ваш вклад, вы можете @-упомянуть его в этой ветке.
+
+**Не** обращайтесь к этому человеку в частном порядке; помните, что публичное общение жизненно важно для проектов с открытым исходным кодом.
+
+Если вы сделаете вежливое напоминание, но никто не ответит, возможно, что никто и никогда не ответит. Это не самое приятное чувство, но пусть это вас не расстраивает. Это случилось со всеми! Существует множество возможных причин, по которым вы не получили ответа, в том числе личные обстоятельства, которые вы не можете контролировать. Попробуйте найти другой проект или способ внести свой вклад. Во всяком случае, это хорошая причина не тратить слишком много времени на внесение вклада, прежде чем другие члены сообщества будут вовлечены и откликнутся.
+
+### 🚧 Кто-то просит изменить ваш вклад.
+
+Часто вас просят внести изменения в свой вклад, будь то отзывы о масштабах вашей идеи или изменения в вашем коде.
+
+Когда кто-то просит изменений, будьте отзывчивы. Они нашли время, чтобы проанализировать ваш вклад. Открывать PR и уходить - дурной тон. Если вы не знаете, как внести изменения, изучите проблему, а затем обратитесь за помощью, если она вам понадобится.
+
+Если у вас больше нет времени работать над проблемой (например, если разговор продолжается в течение нескольких месяцев и ваши обстоятельства изменились), сообщите об этом специалисту по сопровождению, чтобы он не ожидал ответа. Кто-то другой может быть счастлив взять на себя управление.
+
+### 👎 Ваш вклад не принят.
+
+Ваш вклад может быть принят или не принят в конце. Надеюсь, вы уже не вложили в это слишком много усилий. Если вы не уверены, почему он не был принят, вполне разумно попросить разработчика оставить отзыв и разъяснения. В конечном итоге, однако, вам нужно будет уважать, что это их решение. Не спорьте и не становитесь враждебными. Вы всегда можете сделать ответвление (fork) и работать над своей собственной версией, если не согласны!
+
+### 🎉 Ваш вклад принят.
+
+Ура! Вы успешно сделали вклад с открытым исходным кодом!
+
+## Вы сделали это!
+
+Независимо от того, сделали ли вы свой первый вклад с открытым исходным кодом или ищете новые способы внести свой вклад, мы надеемся, что вы вдохновитесь на действия. Даже если ваш вклад не был принят, не забудьте сказать спасибо, когда сопровождающий приложит усилия, чтобы вам помочь. Открытый исходный код создается такими же людьми, как вы: одна проблема, запрос на изменение, комментарий или пять за раз.
diff --git a/_articles/ru/index.html b/_articles/ru/index.html
new file mode 100644
index 00000000000..095fca6f0ef
--- /dev/null
+++ b/_articles/ru/index.html
@@ -0,0 +1,6 @@
+---
+layout: index
+title: Руководство по открытому программному обеспечению
+lang: ru
+permalink: /ru/
+---
diff --git a/_articles/ru/leadership-and-governance.md b/_articles/ru/leadership-and-governance.md
new file mode 100644
index 00000000000..7ae0f6319a8
--- /dev/null
+++ b/_articles/ru/leadership-and-governance.md
@@ -0,0 +1,153 @@
+---
+lang: ru
+title: Лидерство и управление
+description: Растущие проекты с открытым исходным кодом могут выиграть от формализации правил принятия решений.
+class: leadership
+toc:
+  понимание-механизмов-управления-вашим-растущим-проектом: Понимание механизмов управления для вашего растущего проекта
+  какие-примеры-формальных-ролей-используются-в-проектах-с-открытым-исходным-кодом: Какие примеры формальных ролей используются в проектах с открытым исходным кодом?
+  как-формализовать-эти-лидерские-роли: Как мне формализовать эти лидерские роли?
+  когда-я-должен-предоставить-кому-то-доступ-на-правки-commit: Когда я должен предоставить кому-то commit доступ?
+  какие-существуют-структуры-управления-для-проектов-с-открытым-исходным-кодом: Каковы некоторые общие структуры управления для проектов с открытым исходным кодом?
+  нужна-ли-мне-документация-по-управлению-когда-я-запускаю-свой-проект: Нужна ли мне документация по управлению, когда я запускаю свой проект?
+  что-если-сотрудники-корпорации-участвуют-в-проекте: Что произойдет, если сотрудники компании начнут делать контрибуции?
+  нужно-ли-мне-юридическое-лицо-для-поддержки-моего-проекта: Нужно ли мне юридическое лицо для поддержки моего проекта?
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+  - best-practices
+  - metrics
+---
+
+## Понимание механизмов управления вашим растущим проектом
+
+Ваш проект растет, люди вовлечены в него, и вы полны решимости поддерживать его. На этом этапе вы, возможно, задаетесь вопросом, как включить постоянных участников проекта в свой рабочий процесс, будь то предоставление кому-то доступа к правкам кода (commit) или модерацию дебатов в сообществе. Если у вас есть вопросы, у нас есть ответы.
+
+## Какие примеры формальных ролей используются в проектах с открытым исходным кодом?
+
+Многие проекты имеют схожую структуру распределения ролей и признания заслуг участников.
+
+Однако что на самом деле означают эти роли, зависит только от вас. Вот несколько типов ролей, которые вы можете узнать:
+
+* **Сопровождающий (maintainer)**
+* **Участник (contributor)**
+* **Правщик (committer)**
+
+**Для некоторых проектов "сопровождающие"** - это единственные люди в проекте, имеющие доступ к правкам (commit). В других проектах это просто люди, которые указаны в README как сопровождающие.
+
+Сопровождающий не обязательно должен быть тем, кто пишет код для вашего проекта. Это может быть человек, который проделал большую работу по пропаганде вашего проекта или написал документацию, которая сделала проект более доступным для других. Независимо от того, чем он занимается ежедневно, сопровождающий - это человек, который чувствует ответственность за направление развития проекта и стремится его улучшить.
+
+**"Участником" может быть любой**, кто комментирует проблему (issue) или запрос на перенос (pull request), люди, которые добавляют ценность проекту (будь то устранение проблем, написание кода или организация мероприятий), или любой, у кого есть принятый запрос на перенос (возможно, это самое узкое определение участника).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  \[Для Node.js,\] каждый человек, который появляется, чтобы прокомментировать проблему или прислать код, является членом сообщества проекта. Просто возможность видеть их означает, что они из пользователя превратились в участника.
+  <p markdown="1" class="pquote-credit">— @mikeal, ["Здоровый Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)</p>
+</aside>
+
+**Термин "правщик"** может быть использован для того, чтобы отличить доступ к правкам, который является особым видом ответственности, от других форм вклада.
+
+Хотя вы можете определять роли в проекте как угодно, [рассмотрите возможность использования более широких определений](../how-to-contribute/#что-значит-внести-свой-вклад-to-contribute), чтобы воодушевить людей на большее количество разновидностей вклада. Вы можете использовать лидерские роли для официального признания людей, которые внесли выдающийся вклад в ваш проект, независимо от их технических навыков.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
+  Вы можете знать меня как "изобретателя" Django... но на самом деле я парень, которого наняли для работы над вещью через год после того, как она уже была сделана. (...) Люди предполагают, что я добился успеха благодаря своим навыкам программирования... но я в лучшем случае средний программист.
+  <p markdown="1" class="pquote-credit">— @jacobian, ["PyCon 2015 Keynote" (видео)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)</p>
+</aside>
+
+## Как формализовать эти лидерские роли?
+
+Формализация лидерских ролей помогает людям почувствовать свою сопричастность и подсказывает другим членам сообщества, к кому обращаться за помощью.
+
+В небольших проектах назначение лидеров может быть простым - достаточно добавить их имена в README или текстовый файл CONTRIBUTORS.
+
+Для более крупного проекта, если у вас есть веб-сайт, создайте страницу команды или перечислите на ней руководителей проекта. Например, у [Postgres](https://github.com/postgres/postgres/) есть [страница полной команды](https://www.postgresql.org/community/contributors/) с краткими профилями для каждого участника.
+
+Если ваш проект имеет очень активное сообщество участников, вы можете сформировать "ядро" сопровождающих (maintainers) или даже группы людей, которые будут отвечать за различные области проблем (например, безопасность, устранение проблем или поведение сообщества). Позвольте людям самоорганизоваться и стать добровольцами на те роли, которые им больше всего нравятся, а не назначайте их.
+
+<aside markdown="1" class="pquote">
+  \[Мы\] дополняем основную команду несколькими "подкомандами". Каждая подкоманда занимается конкретной областью, например, разработкой языка или библиотек. (...) Для обеспечения глобальной координации и сильного, последовательного видения проекта в целом, каждая подгруппа возглавляется одним из членов основной команды.
+  <p markdown="1" class="pquote-credit">— [Rust Governance RFC](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)</p>
+</aside>
+
+Команды руководителей могут захотеть создать специальный канал (например, на IRC) или регулярно встречаться для обсуждения проекта (например, на Gitter или Google Hangout). Вы даже можете сделать эти встречи публичными, чтобы другие люди могли послушать. Например, [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)[проводит офисные часы каждую неделю](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+
+После того как вы установили руководящие роли, не забудьте задокументировать, как люди могут их получить! Установите четкий процесс того, как кто-то может стать сопровождающим или присоединиться к группе в вашем проекте, и запишите его в файле GOVERNANCE.md.
+
+Такие инструменты, как [Vossibility](https://github.com/icecrime/vossibility-stack), могут помочь вам публично отслеживать, кто вносит (или не вносит) вклад в проект. Документирование этой информации позволяет избежать восприятия сообществом того, что сопровождающие - это клика, которая принимает решения втайне от всех.
+
+Наконец, если ваш проект находится на GitHub, подумайте о переносе проекта из личного аккаунта в Организацию и добавлении хотя бы одного резервного администратора. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) облегчают управление разрешениями и несколькими репозиториями и защищают наследие вашего проекта благодаря [общему владению](../building-community/#совместное-владение-вашим-проектом).
+
+## Когда я должен предоставить кому-то доступ на правки (commit)?
+
+Некоторые люди считают, что вы должны предоставлять доступ на правки всем, кто вносит свой вклад. Это может способствовать тому, что больше людей будут чувствовать себя причастными к вашему проекту.
+
+С другой стороны, особенно для больших, более сложных проектов, вы можете захотеть предоставить commit доступ только тем людям, которые продемонстрировали свою приверженность. Не существует единственно правильного способа - делайте то, что вам удобнее всего!
+
+Если ваш проект находится на GitHub, вы можете использовать [защищенные ветки](https://help.github.com/articles/about-protected-branches/), чтобы управлять тем, кто и при каких обстоятельствах может отправлять правки (push) в определенную ветку.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
+  Каждый раз, когда кто-то отправляет вам запрос на принятие (pull request), дайте ему доступ на правки (commit) к вашему проекту. Хотя поначалу это может показаться невероятно глупым, использование этой стратегии позволит вам раскрыть истинную мощь GitHub. (...) Когда люди получают доступ на правки, они больше не беспокоятся о том, что их патч может остаться незамеченным... что заставляет их приложить гораздо больше усилий.
+  <p markdown="1" class="pquote-credit">— @felixge, ["Взлом запроса на перенос (pull request)"](https://felixge.de/2013/03/11/the-pull-request-hack.html)</p>
+</aside>
+
+## Какие существуют структуры управления для проектов с открытым исходным кодом?
+
+Существуют три общие структуры управления, связанные с проектами с открытым исходным кодом.
+
+* **BDFL:** (Benevolent dictator for life) - "пожизненный доброжелательный диктатор". При такой структуре один человек (обычно первоначальный автор проекта) имеет право окончательного голоса при принятии всех основных решений по проекту. [Python](https://github.com/python) - классический пример. Небольшие проекты, вероятно, по умолчанию являются BDFL, потому что в них есть только один или два сопровождающих (maintainer). Проект, созданный в компании, также может попасть в категорию BDFL.
+
+* **Меритократия:** (Примечание: термин "меритократия" несет негативные коннотации для некоторых сообществ и имеет [сложную социальную и политическую историю](http://geekfeminism.wikia.com/wiki/Meritocracy).) При меритократии активным участникам проекта (тем, кто демонстрирует "заслуги") отводится формальная роль в принятии решений. Решения обычно принимаются на основе чистого консенсусного голосования. Концепция меритократии была впервые предложена [Apache Foundation](https://www.apache.org/); [все проекты Apache](https://www.apache.org/index.html#projects-list) являются меритократиями. Вклад может быть сделан только людьми, представляющими самих себя, а не компанию.
+
+* **Либеральный вклад:** Согласно модели либерального вклада, наиболее влиятельными признаются люди, которые делают больше всего работы, но это основано на текущей работе, а не на историческом вкладе. Основные решения по проекту принимаются на основе процесса поиска консенсуса (обсуждение основных претензий), а не прямого голосования, и стремятся охватить как можно больше точек зрения сообщества. Популярные примеры проектов, использующих либеральную модель вклада, включают [Node.js](https://foundation.nodejs.org/) и [Rust](https://www.rust-lang.org/).
+
+Какой из них использовать? Это зависит от вас! У каждой модели есть свои преимущества и компромиссы. И хотя поначалу они могут показаться совершенно разными, все три модели имеют больше общего, чем кажется. Если вы заинтересованы в принятии одной из этих моделей, ознакомьтесь с этими шаблонами:
+
+* [шаблон модели BDFL](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Шаблон модели меритократии](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Либеральная политика Node.js в отношении вклада участников](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Нужна ли мне документация по управлению, когда я запускаю свой проект?
+
+Не существует подходящего времени для написания документации для вашего проекта, но его гораздо легче определить, когда вы увидите динамику развития вашего сообщества. Самое лучшее (и самое трудное) в управлении открытым исходным кодом - это то, что оно формируется сообществом!
+
+Однако некоторая ранняя документация неизбежно будет способствовать управлению проектом, поэтому начинайте записывать все, что можно. Например, вы можете определить четкие ожидания в отношении поведения или того, как работает ваш процесс привлечения участников, еще на этапе запуска проекта.
+
+Если вы являетесь частью компании, запускающей проект с открытым исходным кодом, стоит провести внутреннее обсуждение перед запуском о том, как ваша компания собирается поддерживать проект и принимать решения по его дальнейшему развитию. Возможно, вы также захотите публично объяснить все особенности того, как ваша компания будет (или не будет!) участвовать в проекте.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
+  Для управления проектами на GitHub мы назначаем небольшие команды, которые на самом деле работают над ними в Facebook. Например, React управляется инженером по React.
+  <p markdown="1" class="pquote-credit">— @caabernathy, ["Взгляд изнутри на открытый исходный код в Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)</p>
+</aside>
+
+## Что если сотрудники корпорации участвуют в проекте?
+
+Успешные проекты с открытым исходным кодом используются многими людьми и компаниями, и некоторые компании в конечном итоге могут иметь потоки доходов, связанные с проектом. Например, компания может использовать код проекта в качестве одного из компонентов коммерческого предложения услуг.
+
+По мере того как проект получает все более широкое распространение, люди, обладающие опытом в этой области, становятся более востребованными - вы можете быть одним из них! - и иногда будут получать деньги за работу, которую они выполняют в проекте.
+
+Важно относиться к коммерческой деятельности как к норме и как к еще одному источнику энергии для развития. Конечно, платные разработчики не должны получать особое отношение к себе по сравнению с бесплатными; каждый вклад должен оцениваться по его техническим достоинствам. Однако люди должны чувствовать себя комфортно, занимаясь коммерческой деятельностью, и не стесняться приводить свои примеры использования, аргументируя свою позицию в пользу того или иного усовершенствования или функции.
+
+"Коммерческое" полностью совместимо с "открытым исходным кодом". "Коммерческий" означает лишь то, что где-то вовлечены деньги - что программное обеспечение используется в коммерции, что становится все более вероятным по мере того, как проект получает распространение. (Когда программное обеспечение с открытым исходным кодом используется как часть продукта без открытого исходного кода, общий продукт все равно является "проприетарным" программным обеспечением, хотя, как и открытый исходный код, он может использоваться в коммерческих или некоммерческих целях).
+
+Как и любой другой человек, коммерчески мотивированные разработчики приобретают влияние в проекте за счет качества и количества своего вклада. Очевидно, что разработчик, которому платят за его время, может сделать больше, чем тот, кому не платят, но это нормально: оплата - это лишь один из многих возможных факторов, которые могут повлиять на то, как много кто-то делает. Обсуждая проект, сосредоточьтесь на вкладе, а не на внешних факторах, которые позволяют людям делать этот вклад.
+
+## Нужно ли мне юридическое лицо для поддержки моего проекта?
+
+Вам не нужно юридическое лицо для поддержки вашего проекта с открытым исходным кодом, если только вы не работаете с деньгами.
+
+Например, если вы хотите создать коммерческий бизнес, вам нужно будет учредить C Corp или LLC (если вы находитесь в США). Если вы просто выполняете контрактную работу, связанную с вашим проектом с открытым исходным кодом, вы можете принимать деньги как индивидуальный предприниматель или учредить LLC (если вы находитесь в США).
+
+Если вы хотите принимать пожертвования для своего проекта с открытым исходным кодом, вы можете установить кнопку для пожертвований (например, с помощью PayPal или Stripe), но деньги не будут подлежать налогообложению, если вы не являетесь квалифицированной некоммерческой организацией (501c3, если вы находитесь в США).
+
+Многие проекты не хотят заниматься созданием некоммерческой организации, поэтому вместо этого они находят фискального спонсора некоммерческой организации. Фискальный спонсор принимает пожертвования от вашего имени, обычно в обмен на процент от пожертвования. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) и [Open Collective](https://opencollective.com/opensource) являются примерами организаций, выступающих в качестве фискальных спонсоров проектов с открытым исходным кодом.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
+  Наша цель - предоставить инфраструктуру, которую сообщества могут использовать для самоокупаемости, создавая таким образом среду, в которой все - и участники и спонсоры - получают конкретную выгоду.
+  <p markdown="1" class="pquote-credit">— @piamancini, ["Выходя за рамки благотворительности"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)</p>
+</aside>
+
+Если ваш проект тесно связан с определенным языком или экосистемой, может существовать и соответствующий фонд программного обеспечения, с которым вы можете работать. Например, [Python Software Foundation](https://www.python.org/psf/) помогает поддерживать [PyPI](https://pypi.org/), менеджер пакетов Python, а [Node.js Foundation](https://foundation.nodejs.org/) помогает поддерживать [Express.js](https://expressjs.com/), фреймворк на основе Node.
diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md
new file mode 100644
index 00000000000..037ece916d1
--- /dev/null
+++ b/_articles/ru/legal.md
@@ -0,0 +1,166 @@
+---
+lang: ru
+title: Юридические аспекты открытого программного кода
+description: Все, что вас когда-либо интересовало о правовой стороне открытого исходного кода, и кое-что, чего вы не знали.
+class: legal
+toc:
+  почему-людей-так-волнует-правовая-сторона-открытого-кода: 'Почему людей так волнует юридическая сторона открытого кода?'
+  открыты-ли-общедоступные-проекты-github: 'Являются ли общедоступные проекты GitHub - открытыми?'
+  просто-дайте-мне-чтобытонибыло-что-нужно-для-защиты-моего-проекта: 'Просто дайте мне ЧтоБыТоНиБыло, что нужно для защиты моего проекта'
+  какая-лицензия-с-открытым-исходным-кодом-подходит-для-моего-проекта: 'Какая лицензия с открытым исходным кодом подходит для моего проекта?'
+  что-если-я-хочу-изменить-лицензию-своего-проекта: 'Что, если я захочу изменить лицензию своего проекта?'
+  требуется-ли-для-моего-проекта-дополнительное-соглашение-с-участниками: 'Требуется ли для моего проекта дополнительное соглашение с участниками?'
+  что-нужно-знать-юридическому-отделу-моей-компании: 'Что нужно знать юридическому отделу моей компании?'
+order: 10
+image: /assets/images/cards/legal.png
+related:
+  - contribute
+  - leadership
+---
+
+## Понимание юридических последствий открытого исходного кода
+
+Поделиться своим творчеством со всем миром может быть захватывающим и полезным опытом. Это также может означать множество юридических аспектов, о которых вы даже не подозревали. К счастью, вам не нужно начинать с нуля. Мы позаботимся о ваших юридических потребностях. (Прежде чем углубляться, обязательно прочтите наш [отказ от ответственности](/notices/).)
+
+## Почему людей так волнует правовая сторона открытого кода?
+
+Рад, что вы спросили! Когда вы создаете творческую работу (например, текст, графику или код), эта работа по умолчанию находится под исключительным авторским правом. То есть закон предполагает, что как автор вашей работы вы имеете право голоса в отношении того, что другие могут с ней делать.
+
+В общем, это означает, что никто другой не может использовать, копировать, распространять или изменять вашу работу, не подвергаясь риску изъятия, замены или судебного разбирательства.
+
+Однако открытый исходный код - это необычная ситуация, поскольку автор ожидает, что другие будут использовать, изменять и делиться работой. Но поскольку юридическое значение по умолчанию по-прежнему является исключительным авторским правом, вам нужна лицензия, в которой явно указаны эти разрешения.
+
+Если вы не примените лицензию с открытым исходным кодом, каждый, кто вносит свой вклад в ваш проект, также становится эксклюзивным правообладателем своей работы. Это означает, что никто не может использовать, копировать, распространять или изменять их материалы - и эти «никто» включает и вас.
+
+Наконец, ваш проект может иметь зависимости от лицензионных требований, о которых вы не знали. Сообщество вашего проекта или политика вашего работодателя также могут требовать от вашего проекта использования определенных лицензий с открытым исходным кодом. Мы рассмотрим эти ситуации ниже.
+
+## Открыты ли общедоступные проекты GitHub?
+
+Когда вы [создаете новый проект](https://help.github.com/articles/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 в своем коде, даже если он общедоступен, если вы явно не дадите ему на это право.
+
+## Просто дайте мне ЧтоБыТоНиБыло, что нужно для защиты моего проекта.
+
+Вам повезло, потому что сегодня лицензии с открытым исходным кодом стандартизированы и просты в использовании. Вы можете скопировать и вставить существующую лицензию прямо в свой проект.
+
+[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/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
+Стандартизированная лицензия важна для тех, кто не имеет юридического образования, чтобы точно знать, что они могут и не могут делать с программным обеспечением. Если нет крайней необходимости, избегайте самодеятельности, измененных или нестандартных условий, которые станут препятствием для последующего использования кода.
+  <p markdown="1" class="pquote-credit">
+— @benbalter, ["Все, что нужно знать государственному прокурору о лицензировании программного обеспечения с открытым исходным кодом"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+  </p>
+</aside>
+
+## Какая лицензия с открытым исходным кодом подходит для моего проекта?
+
+Если вы начинаете с чистого листа, трудно ошибиться с [лицензией MIT](https://choosealicense.com/licenses/mit/). Он короткий, очень простой для понимания и позволяет любому делать всё, что угодно, если у него есть копия лицензии и упоминание вашего авторства. Вы сможете выпустить проект под другой лицензией, если понадобится.
+
+В противном случае выбор правильной лицензии для открытого исходного кода вашего проекта зависит от ваших целей.
+
+Ваш проект, скорее всего, имеет (или будет иметь) **зависимости**. Например, если вы открываете исходный код проекта Node.js, вы, вероятно, будете использовать библиотеки из диспетчера пакетов узлов (npm). Каждая из этих библиотек, от которых вы зависите, будет иметь собственную лицензию с открытым исходным кодом. Если каждая из их лицензий является «разрешающей» (дает общедоступное разрешение на использование, изменение и совместное использование без каких-либо условий для последующего лицензирования), вы можете использовать любую лицензию, которую хотите. Общие разрешительные лицензии включают MIT, Apache 2.0, ISC и BSD.
+
+С другой стороны, если какая-либо из лицензий ваших зависимостей является «строгим авторским левом» (strong copyleft) (также дает такие же общедоступные разрешения при условии использования той же лицензии ниже по течению), тогда ваш проект должен будет использовать ту же лицензию. Общие лицензии с сильным авторским левом включают GPLv2, GPLv3 и AGPLv3.
+
+Вы также можете рассмотреть **сообщества**, которые, как вы надеетесь, будут использовать и вносить свой вклад в ваш проект:
+
+* **Вы хотите, чтобы ваш проект использовался в качестве зависимости другими проектами?** Вероятно, лучше всего использовать самую популярную лицензию в вашем соответствующем сообществе. Например, [MIT](https://choosealicense.com/licenses/mit/) - самая популярная лицензия для [библиотек npm](https://libraries.io/search?platforms=NPM).
+* **Вы хотите, чтобы ваш проект понравился крупным предприятиям?** Крупному бизнесу, скорее всего, потребуется явная патентная лицензия от всех участников. В этом случае [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) поможет вам (и им).
+* **Вы хотите, чтобы ваш проект привлек участников, которые не хотят, чтобы их вклад использовался в программном обеспечении с закрытым исходным кодом?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) или (если они также не хотят участвовать в службах с закрытым исходным кодом) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) подойдет.
+
+Ваша **компания** может иметь особые лицензионные требования для своих проектов с открытым исходным кодом. Например, может потребоваться разрешительная лицензия, чтобы компания могла использовать ваш проект в продукте компании с закрытым исходным кодом. Или ваша компания может потребовать сильную лицензию с авторским левом и дополнительное соглашение с участниками (см. Ниже), чтобы только ваша компания и никто другой могли использовать ваш проект в программном обеспечении с закрытым исходным кодом. Или у вашей компании могут быть определенные потребности, связанные со стандартами, социальной ответственностью или прозрачностью, любая из которых может потребовать определенной стратегии лицензирования. Поговорите с юридическим отделом вашей [компании](#что-нужно-знать-юридическому-отделу-моей-компании).
+
+Когда вы создаете новый проект на GitHub, вам предоставляется возможность выбрать лицензию. Включение одной из упомянутых выше лицензий сделает ваш проект GitHub открытым. Если вы хотите увидеть другие варианты, посетите [choosealicense.com](https://choosealicense.com), чтобы найти подходящую лицензию для своего проекта, даже если это [не программное обеспечение](https://choosealicense.com/non-software/).
+
+## Что, если я хочу изменить лицензию своего проекта?
+
+Для большинства проектов не требуется менять лицензии. Но иногда обстоятельства меняются.
+
+Например, по мере роста вашего проекта он добавляет зависимости или пользователей, или ваша компания меняет стратегии, для любой из которых может потребоваться другая лицензия. Кроме того, если вы пренебрегали лицензированием своего проекта с самого начала, добавление лицензии фактически аналогично изменению лицензий. При добавлении или изменении лицензии на проект необходимо учитывать три основных момента:
+
+**Это сложно.** Определение совместимости и соответствия лицензий, а также обладателей авторских прав может очень быстро стать сложным и запутанным. Переход на новую, но совместимую лицензию для новых выпусков и дополнений отличается от перелицензирования всех существующих дополнений. Привлекайте свою команду юристов при первом намеке на желание сменить лицензию. Даже если у вас есть или вы можете получить разрешение от правообладателей вашего проекта на изменение лицензии, учитывайте влияние этого изменения на других пользователей и участников вашего проекта. Думайте о смене лицензии как об «управленческом событии» для вашего проекта, которое, скорее всего, пройдет гладко при четком общении и консультациях с заинтересованными сторонами вашего проекта. Еще одна причина выбрать и использовать соответствующую лицензию для вашего проекта с самого начала!
+
+**Существующая лицензия вашего проекта.** Если существующая лицензия вашего проекта совместима с лицензией, на которую вы хотите перейти, вы можете просто начать использовать новую лицензию. Это потому, что если лицензия A совместима с лицензией B, вы будете соблюдать условия A, соблюдая условия B (но не обязательно наоборот). Поэтому, если вы в настоящее время используете разрешительную лицензию (например, MIT), вы можете перейти на лицензию с дополнительными условиями, при условии, что вы сохраняете копию лицензии MIT и любые связанные уведомления об авторских правах (т.е. продолжаете соблюдать минимальные условия лицензии MIT). Но если ваша текущая лицензия не разрешающая (например, авторское лево или у вас нет лицензии) и вы не являетесь единственным владельцем авторских прав, вы не можете просто изменить лицензию вашего проекта на MIT. По сути, с разрешающей лицензией правообладатели проекта заранее дали разрешение на изменение лицензий.
+
+**Существующие правообладатели вашего проекта.** Если вы являетесь единственным участником своего проекта, то вы или ваша компания являетесь единственным правообладателем проекта. Вы можете добавить или изменить любую лицензию, которую захотите вы или ваша компания. В противном случае могут быть другие правообладатели, с которыми вам потребуется согласие для изменения лицензий. Кто они? Люди, у которых есть коммиты в вашем проекте, - хорошее место для начала. Но в некоторых случаях авторские права принадлежат работодателям этих людей. В некоторых случаях люди будут вносить только минимальный вклад, но не существует жесткого правила, согласно которому вклады с использованием определенного количества строк кода не подлежат авторскому праву. Что делать? Это зависит. Для относительно небольшого и молодого проекта может оказаться целесообразным убедить всех существующих участников согласиться на изменение лицензии в issue или pull request. Для крупных и долгоживущих проектов вам, возможно, придется искать множество участников и даже их наследников. Mozilla потребовались годы (2001-2006), чтобы перелицензировать Firefox, Thunderbird и сопутствующее программное обеспечение.
+
+В качестве альтернативы вы можете попросить участников заранее согласиться (посредством дополнительного соглашения с участниками - см. Ниже) на определенные изменения лицензии при определенных условиях, помимо тех, которые разрешены вашей существующей лицензией с открытым исходным кодом. Это немного меняет сложность изменения лицензий. Вам заранее понадобится дополнительная помощь юристов, и вы все равно захотите четко общаться с заинтересованными сторонами вашего проекта при изменении лицензии.
+
+## Требуется ли для моего проекта дополнительное соглашение с участниками?
+
+Возможно нет. Для подавляющего большинства проектов лицензия для открытого исходного кода неявно служит как входящей (от участников), так и исходящей (для других участников и пользователей) лицензией. Если ваш проект размещен на GitHub, Условия использования GitHub делают "inbound = outbound" [явным значением по умолчанию](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+
+Дополнительное соглашение с участником, часто называемое лицензионным соглашением участника (CLA), может создавать административную работу для сопровождающих проект. Сколько работы добавляет соглашение, зависит от проекта и реализации. Простое соглашение может требовать, чтобы участники подтвердили одним щелчком мыши, что у них есть права, необходимые для внесения вклада в соответствии с лицензией проекта с открытым исходным кодом. Более сложное соглашение может потребовать юридической проверки и подписания со стороны работодателей участников.
+
+Кроме того, добавление «бумажной работы», которая, по мнению некоторых, является ненужной, трудной для понимания или несправедливой (когда получатель соглашения получает больше прав, чем участники или общественность через лицензию проекта с открытым исходным кодом), дополнительное соглашение с участниками может быть воспринято как недружественное сообществу проекта.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
+    Мы удалили CLA для Node.js. Это снижает барьер для входа в Node.js, тем самым расширяя базу участников.
+  <p markdown="1" class="pquote-credit">
+— @bcantrill, ["Расширение сообщества Node.js"](https://www.joyent.com/blog/broadening-node-js-contributions)
+  </p>
+</aside>
+
+Вот некоторые ситуации, когда вы можете захотеть рассмотреть вопрос о дополнительном соглашении с участниками для вашего проекта:
+
+* Ваши юристы хотят, чтобы все участники явным образом приняли (подписать, онлайн или офлайн) условия вклада, возможно, потому, что они считают, что самой лицензии с открытым исходным кодом недостаточно (даже если это так!). Если это единственная проблема, должно быть достаточно соглашения с участником, подтверждающего лицензию проекта с открытым исходным кодом. [Лицензионное соглашение с индивидуальным участником jQuery](https://contribute.jquery.org/CLA/) является хорошим примером облегченного соглашения с дополнительным участником.
+* Вы или ваши юристы хотите, чтобы разработчики доказали, что каждое совершаемое ими действие санкционировано. Требование [Сертификат разработчика](https://developercertificate.org/) - это количество проектов, которые этого достигают. Например, сообщество Node.js [использует](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо этого](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) их предыдущего CLA. Простым вариантом автоматизации принудительного применения DCO в вашем репозитории является [DCO Probot](https://github.com/probot/dco).
+* В вашем проекте используется лицензия с открытым исходным кодом, которая не включает прямую выдачу патента (например, MIT), и вам нужен патент от всех участников, некоторые из которых могут работать в компаниях с большими портфелями патентов, которые могут быть использованы для вашего таргетинга. или других участников и пользователей проекта. [Лицензионное соглашение с индивидуальным участником Apache](https://www.apache.org/licenses/icla.pdf) является часто используемым соглашением с дополнительным участником, в котором выдача патента является копией той, которая содержится в лицензии Apache License 2.0.
+* Ваш проект находится под лицензией с авторским левом, но вам также необходимо распространять проприетарную версию проекта. Вам потребуется, чтобы каждый участник назначил вам авторские права или предоставил вам (но не общественности) разрешительную лицензию. [Соглашение с участником MongoDB](https://www.mongodb.com/legal/contributor-agreement) является примером такого типа соглашения.
+* Вы думаете, что вашему проекту может потребоваться изменить лицензии в течение его срока службы, и хотите, чтобы участники заранее согласились на такие изменения.
+
+Если вам действительно нужно заключить с вашим проектом дополнительное соглашение с участниками, рассмотрите возможность использования такой интеграции, как [помощник CLA](https://github.com/cla-assistant/cla-assistant), чтобы свести к минимуму отвлечение участников.
+
+## Что нужно знать юридическому отделу моей компании?
+
+Если вы выпускаете проект с открытым исходным кодом в качестве сотрудника компании, во-первых, ваша юридическая группа должна знать, что вы открываете исходный код проекта.
+
+Хорошо это или плохо, пусть они знают, даже если это личный проект. У вас, вероятно, есть «соглашение об интеллектуальной собственности сотрудников» с вашей компанией, которое дает им некоторый контроль над вашими проектами, особенно если они вообще связаны с бизнесом компании или вы используете какие-либо ресурсы компании для разработки проекта. Ваша компания _должна_ легко дать вам разрешение, и, возможно, оно уже было получено в рамках благоприятного для сотрудников соглашения об интеллектуальной собственности или политики компании. В противном случае вы можете вести переговоры (например, объяснить, что ваш проект служит целям профессионального обучения и вашего развития в целях компании) или не работать над своим проектом, пока не найдете лучшую компанию.
+
+**Если вы открываете исходный код проекта своей компании,** обязательно сообщите им об этом. У вашей юридической группы, вероятно, уже есть политика в отношении того, какую лицензию с открытым исходным кодом (и, возможно, дополнительное соглашение с участником) использовать, в зависимости от бизнес-требований и опыта компании в отношении обеспечения соответствия вашего проекта лицензиям зависимостей. Если нет, то вам с ними повезло! Ваша юридическая команда должна быть готова работать с вами, чтобы разобраться в этом вопросе. Некоторые вещи для размышления:
+
+* **Сторонние материалы:** Содержит ли ваш проект зависимости, созданные другими, или иным образом включает или использует чужой код? Если это открытый исходный код, вам необходимо соблюдать лицензии на открытый исходный код материалов. Это начинается с выбора лицензии, которая работает со сторонними лицензиями с открытым исходным кодом (см. Выше). Если ваш проект изменяет или распространяет сторонние материалы с открытым исходным кодом, то ваша юридическая группа также захочет знать, что вы выполняете другие условия сторонних лицензий с открытым исходным кодом, такие как сохранение уведомлений об авторских правах. Если в вашем проекте используется чужой код, не имеющий лицензии с открытым исходным кодом, вам, вероятно, придется попросить сторонних разработчиков [добавить лицензию с открытым исходным кодом](https://choosealicense.com/no-license/#for-users), а если вы не можете его получить, прекратите использовать их код в своем проекте.
+
+* **Коммерческая тайна:** Подумайте, есть ли в проекте что-то, что компания не хочет делать доступным для широкой публики. Если это так, вы можете открыть исходный код остальной части вашего проекта после извлечения материала, который хотите сохранить конфиденциальным.
+
+* **Патенты:** Подает ли ваша компания заявку на патент, открытый исходный код которого ваш проект будет представлять собой [публичное раскрытие](https://en.wikipedia.org/wiki/Public_disclosure)? К сожалению, вас могут попросить подождать (или, возможно, компания пересмотрит мудрость приложения). Если вы ожидаете участия в своем проекте сотрудников компаний с большим портфелем патентов, ваша группа юристов может пожелать, чтобы вы использовали лицензию с явным предоставлением патента от участников (например, Apache 2.0 или GPLv3) или дополнительное соглашение с участником (см. выше).
+
+* **Торговые марки:** Дважды проверьте, что название вашего проекта [не конфликтует с существующими торговыми марками](../starting-a-project/#конфликт-имён). Если вы используете в проекте товарные знаки собственной компании, убедитесь, что это не вызывает конфликтов. [FOSSmarks](http://fossmarks.org/) - это практическое руководство по пониманию товарных знаков в контексте проектов с бесплатным и открытым исходным кодом.
+
+* **Конфиденциальность:** Собирает ли ваш проект данные о пользователях? "Звонит домой" на серверы компании? Ваш юридический отдел может помочь вам в соблюдении политики компании и внешних нормативных требований.
+
+Если вы выпускаете первый проект своей компании с открытым исходным кодом, вышеуказанного более чем достаточно для выполнения (но не волнуйтесь, большинство проектов не должны вызывать серьезных проблем).
+
+В долгосрочной перспективе ваша команда юристов может сделать больше, чтобы помочь компании получить больше от своего участия в проектах с открытым исходным кодом и оставаться в безопасности:
+
+* **Политики участия сотрудников:** Рассмотрите возможность разработки корпоративной политики, определяющей, как ваши сотрудники вносят вклад в проекты с открытым исходным кодом. Четкая политика уменьшит путаницу среди ваших сотрудников и поможет им внести свой вклад в проекты с открытым исходным кодом в интересах компании, будь то в рамках своей работы или в свободное время. Хорошим примером является политика Rackspace [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
+Предоставление IP-адреса, связанного с патчем, создает базу знаний и репутацию сотрудника. Это показывает, что компания инвестирует в развитие этого сотрудника, и создает ощущение полномочий и автономии. Все эти преимущества также приводят к повышению морального духа и лучшему удержанию сотрудников.  
+<p markdown="1" class="pquote-credit">
+— @vanl, ["Типовая IP-политика и политика участия в открытым исходном коде"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+  </p>
+</aside>
+
+* **Что выпустить:** [(Почти) все?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Если ваша юридическая группа понимает и вкладывается в стратегию открытого исходного кода вашей компании, они смогут лучше помочь, а не препятствовать вашим усилиям.
+* **Соответствие:** Даже если ваша компания не выпускает проекты с открытым исходным кодом, она использует чужое программное обеспечение с открытым исходным кодом. [Осведомленность и процесс](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) могут предотвратить головные боли, задержки продукта, и судебные иски.
+
+<aside markdown="1" class="pquote">
+Организации должны иметь лицензию и стратегию соответствия, которая подходит как для категорий \["разрешающий", так и "авторское лево"\]. Это начинается с записи условий лицензирования, которые применяются к программному обеспечению с открытым исходным кодом, которое вы используете, включая субкомпоненты и зависимости.
+  <p markdown="1" class="pquote-credit">
+— Heather Meeker, ["Программное обеспечение с открытым исходным кодом: основы соответствия и передовой опыт"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+  </p>
+</aside>
+
+* **Патенты:** Ваша компания может пожелать присоединиться к [Открытой сети изобретений](https://www.openinventionnetwork.com/), общему защищенному пулу патентов, чтобы защитить использование участниками крупных проектов с открытым исходным кодом, или изучить другое [альтернативное лицензирование патентов](https://www.eff.org/document/hacking-patent-system-2016).
+* **Управление:** Когда имеет смысл передать проект [юридическому лицу за пределами компании](../leadership-and-governance/#нужно-ли-мне-юридическое-лицо-для-поддержки-моего-проекта).
diff --git a/_articles/ru/metrics.md b/_articles/ru/metrics.md
new file mode 100644
index 00000000000..1e57c2eea00
--- /dev/null
+++ b/_articles/ru/metrics.md
@@ -0,0 +1,130 @@
+---
+lang: ru
+title: Метрики для Open Source
+description: Принимайте обоснованные решения, чтобы помочь вашему проекту с открытым исходным кодом процветать, измеряя и отслеживая его успех.
+class: metrics
+toc:
+  зачем-что-то-измерять: 'Зачем что-то измерять?'
+  обнаруживаемость: 'Обнаруживаемость'
+  использование: 'Использование'
+  удержание: 'Удержание'
+  активность-сопровождающих: 'Активность сопровождающих'
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+  - finding
+  - best-practices
+---
+
+## Зачем что-то измерять?
+
+Данные, при разумном использовании, могут помочь вам принимать лучшие решения в качестве сопровождающего (maintainer) открытого исходного кода.
+
+Имея больше информации, вы можете:
+
+* Понять, как пользователи реагируют на новую функцию
+* Выяснить, откуда приходят новые пользователи
+* Определить и решить, стоит ли поддерживать новую функциональность
+* Оценить популярность вашего проекта
+* Понять, как используется ваш проект
+* Привлечь инвестиции через спонсорство и гранты
+
+Например, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) обнаружил, что Google Analytics помогает ему определять приоритеты в работе:
+
+> Homebrew предоставляется бесплатно и управляется исключительно добровольцами в свободное время. В результате у нас нет ресурсов для проведения детальных исследований пользователей Homebrew, чтобы решить, как лучше разработать будущие функции и определить приоритеты текущей работы. Анонимная совокупная аналитика пользователей позволяет нам определять приоритетность фиксов и фич на основе того, как, где и когда люди используют Homebrew.
+
+Популярность - это еще не все. Все приходят в open source по разным причинам. Если ваша цель как сопровождающего open source - показать свою работу, свой код или просто развлечься, то метрики могут быть для вас не важны.
+
+Если вы _заинтересованы_ в более глубоком понимании своего проекта, читайте далее о способах анализа активности вашего проекта.
+
+## Обнаруживаемость
+
+Прежде чем кто-то сможет воспользоваться вашим проектом или внести в него свой вклад, он должен узнать о его существовании. Спросите себя: _могут ли люди найти этот проект?_
+
+![График трафика](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
+
+Если ваш проект размещен на GitHub, [вы можете посмотреть](https://help.github.com/articles/about-repository-graphs/#traffic), сколько людей заходит на ваш проект и откуда они приходят. На странице вашего проекта нажмите **Insights**, затем **Traffic**. На этой странице вы можете увидеть:
+
+* **Общее количество просмотров страниц:** показывает, сколько раз был просмотрен ваш проект.
+
+* **Общее количество уникальных посетителей:** показывает, сколько человек просмотрело ваш проект.
+
+* **Сайты-источники:** Рассказывает о том, откуда пришли посетители. Эта метрика может помочь вам определить, где можно привлечь аудиторию и работают ли ваши усилия по продвижению.
+
+* **Популярный контент:** Рассказывает о том, куда заходят посетители на вашем проекте, в разбивке по просмотрам страниц и уникальным посетителям.
+
+[GitHub stars](https://help.github.com/articles/about-stars/) также может помочь определить базовый показатель популярности. Хотя звезды GitHub не обязательно коррелируют с загрузками и использованием, они могут сказать вам, сколько людей обращают внимание на вашу работу.
+
+Вы также можете захотеть [отслеживать открываемость в определенных местах](https://opensource.com/business/16/6/pirate-metrics): например, Google PageRank, реферальный трафик с сайта вашего проекта или рефералы с других проектов с открытым исходным кодом или сайтов.
+
+## Использование
+
+Люди находят ваш проект в этой дикой и безумной штуке, которую мы называем Интернетом. В идеале, когда они увидят ваш проект, у них возникнет желание что-то сделать. Второй вопрос, который вы хотите задать, это: _используют ли люди этот проект?_
+
+Если вы используете менеджер пакетов, такой как npm или RubyGems.org, для распространения вашего проекта, вы можете отслеживать скачивания пакета.
+
+Каждый пакетный менеджер может использовать несколько иное определение "скачивания", и скачивания не обязательно коррелируют с установками или использованием, но это дает некоторую базу для сравнения. Попробуйте использовать [Libraries.io](https://libraries.io/) для отслеживания статистики использования многих популярных менеджеров пакетов.
+
+Если ваш проект находится на GitHub, снова перейдите на страницу **Traffic**. Вы можете использовать [График git clone](https://github.com/blog/1873-clone-graphs), чтобы увидеть, сколько раз ваш проект был клонирован в определенный день, с разбивкой по общему количеству клонирований и уникальным клонирователям.
+
+![График git clone](/assets/images/metrics/clone_graph.png)
+
+Если использование низкое по сравнению с количеством людей, которые находят ваш проект, есть два аспекта, которые следует рассмотреть. Либо:
+
+* Ваш проект плохо конвертирует вашу аудиторию, или
+* Вы привлекаете не ту аудиторию
+
+Например, если ваш проект попадет на первую страницу Hacker News, вы, вероятно, увидите всплеск посещений (трафика), но более низкий коэффициент конверсии, поскольку вы охватите всех пользователей Hacker News. Однако если ваш Ruby-проект будет представлен на Ruby-конференции, вы, скорее всего, получите высокий коэффициент конверсии от целевой аудитории.
+
+Попытайтесь понять, откуда приходит ваша аудитория, и попросите других людей оставить отзыв на странице вашего проекта, чтобы выяснить, с какой из этих двух проблем вы столкнулись.
+
+Как только вы узнаете, что люди используют ваш проект, вы можете попытаться выяснить, что они с ним делают. Создают ответвления (fork) вашего кода и добавляют функции? Используют для науки или бизнеса?
+
+## Удержание
+
+Люди находят ваш проект и используют его. Следующий вопрос, который вы захотите задать себе: _участвуют (to contribute) ли люди в этом проекте?_
+
+Никогда не рано начинать думать об участниках. Без участия других людей вы рискуете оказаться в нездоровой ситуации, когда ваш проект _популярен_ (многие используют его), но не _поддерживается_ (не хватает времени сопровождающих (maintainers) для удовлетворения спроса).
+
+Для удержания также необходим [приток новых участников](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), так как ранее активные участники со временем переходят на другие виды деятельности.
+
+Вот ещё показатели для отслеживания:
+
+* **Общее количество участников (contributor) и количество правок (commit) на одного участника:** Позволяет узнать, сколько у вас участников и кто из них более или менее активен. На GitHub это можно посмотреть в разделе **Insights** -> **Contributors**. В настоящее время этот график учитывает только тех участников, которые сделали правку (commit) в ветку репозитория по умолчанию.
+
+![График вкладчиков](/assets/images/metrics/repo_contributors_specific_graph.png)
+
+* **Первоначальные, случайные и повторные участники:** Помогает вам отслеживать, привлекаете ли вы новых участников и возвращаются ли они. (Случайные участники - те, у кого мало правок (commit). Будет ли это одна правка, менее пяти или что-то другое - решать вам). Без новых участников сообщество вашего проекта может стать застойным.
+
+* **Количество текущих открытых проблем (issue) и запросов на перенос (pull request)** Если эти показатели слишком высоки, вам может понадобиться помощь в устранении проблем и проверке кода.
+
+* **Общее количество проблем (issues) и запросов на перенос (pull request) (включая закрытые)** Открытые когда-то проблемы (issues) означают, что ваш проект кому-то достаточно интересен, чтобы открыть проблему (issue). Если это число увеличивается со временем, это говорит о том, что люди заинтересованы в вашем проекте.
+
+* **Типы вклада (contribution):** Например, правки (commit), исправление опечаток или ошибок, или комментирование проблемы (issue).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
+  Открытый исходный код - это больше, чем просто код. Успешные проекты с открытым исходным кодом включают написание кода и документации вместе с обсуждением этих изменений.
+  <p markdown="1" class="pquote-credit">— @arfon, ["Как выглядит Open Source"](https://github.com/blog/2195-the-shape-of-open-source)</p>
+</aside>
+
+## Активность сопровождающих
+
+Наконец, вы захотите замкнуть цикл, убедившись, что участники (contributors) вашего проекта в состоянии справиться с объемом получаемых вкладов (contributions). Последний вопрос, который вы хотите задать себе, это: _отвечаю ли я (или мы) на запросы нашего сообщества?_
+
+Неотзывчивые сопровождающие (maintainer) становятся узким местом для open source проектов. Если кто-то вносит свой вклад, но так и не получает ответа от сопрождающего, он может почувствовать себя демотивированным и уйти.
+
+[Исследование компании Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) предполагает, что отзывчивость сопровождающих является критическим фактором поощрения повторного участия.
+
+Отслеживайте, сколько времени требуется вам (или другому сопровождающему), чтобы ответить на вклад, будь то проблема (issue) или запрос на перенос (pull request). Для ответа не обязательно предпринимать какие-либо действия. Можно просто сказать: _"Спасибо за ваш вклад! Я рассмотрю его в течение следующей недели."_
+
+Можно также измерять время, необходимое для перехода от одного этапа процесса внесения вклада к другому, например:
+
+* Среднее время, в течение которого проблема (issue) остается открытой
+* Закрываются ли проблемы (issue) в запросе на перенос (pull request)
+* Закрываются ли неактуальные проблемы (issue)
+* Среднее время для слияния запроса на перенос (pull request)
+
+## Используйте 📊, чтобы узнать о людях
+
+Понимание метрик поможет вам построить активный, растущий проект с открытым исходным кодом. Даже если вы не отслеживаете каждую метрику на панели инструментов, используйте описанный выше алгоритм действий, чтобы сосредоточить свое внимание на том типе поведения, который поможет вашему проекту процветать.
diff --git a/_articles/ru/starting-a-project.md b/_articles/ru/starting-a-project.md
new file mode 100644
index 00000000000..b27533cae6e
--- /dev/null
+++ b/_articles/ru/starting-a-project.md
@@ -0,0 +1,361 @@
+---
+lang: ru
+title: Запуск проекта с открытым исходным кодом
+description: Узнайте больше о мире открытого исходного кода и подготовьте к запуску собственный проект.
+class: beginners
+toc:
+  открытый-исходный-код-что-это-и-зачем: 'Что это и зачем - открытый исходный код'
+  стоит-ли-мне-запускать-свой-open-source-проект: 'Стоит ли мне запускать свой проект с открытым исходным кодом?'
+  запуск-собственного-open-source-проекта: 'Запуск собственного проекта с открытым исходным кодом'
+  именование-и-брендирование-вашего-проекта: 'Название и брендинг вашего проекта'
+  проверочный-лист-перед-запуском: 'Ваш контрольный список перед запуском'
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+  - finding
+  - building
+---
+
+## Открытый исходный код: что это и зачем?
+
+Итак, вы думаете о запуске своего проекта с открытым исходным кодом (open source)? Поздравляем! Мир ценит ваш участие. Давайте поговорим о том, что такое open source и почему люди это делают.
+
+### Что означает "open source"?
+
+Когда код проекта открыт, это означает, что **любой может свободно использовать, изучать, изменять и распространять ваш проект для любых целей.** Эти разрешения даются через [лицензию с открытым исходным кодом](https://opensource.org/licenses).
+
+Преимущество открытого кода в том, что он снижает барьеры для выбора вашей программы и сотрудничества, позволяя людям быстро распространять и улучшать проекты. Кроме того, это дает пользователям возможность контролировать код, в отличии от закрытого. Компания, использующая программное обеспечение (ПО) с открытым исходным кодом, может нанять кого-то для внесения улучшений в ПО, а не полагаться исключительно на решение поставщика с закрытым исходным кодом.
+
+_Свободное ПО (Free software)_ ссылается на те же проекты, что и _открытое ПО (open source)_. Иногда вы можете встретить комбинации этих [терминов](https://en.wikipedia.org/wiki/Free_and_open-source_software): "Свободное и открытое ПО" (free and open source software FOSS или free, libre, and open source software FLOSS). Слова free и libre здесь означают "свободное", а не ["бесплатное"](#open-source---значит-бесплатно).
+
+### Почему люди делают свою работу открытой?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+  Одно из самых больших вознаграждений, которое я получил от open source - это отношения, установившиеся с другими разработчиками, столкнувшимися с такими же проблемами как и я. 
+  <p markdown="1" class="pquote-credit">
+— @kentcdodds, ["Как мне было здорово войти в Open Source"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+  </p>
+</aside>
+
+[Есть много причин](https://ben.balter.com/2015/11/23/why-open-source/) почему индивид или организация открывают исходники своего проекта. Вот некоторые из них:
+
+* **Сотрудничество:** Open source проект может получать доработки от любого человека из любой страны мира. Например, платформа для упражнений программированию [Exercism](https://github.com/exercism/), делается усилиями 350 авторов.
+
+* **Адаптация и ремиксы:** Open source проект может быть использован кем угодно, почти для чего угодно. Люди могут использовать ваш проект совершенно по-новому. [WordPress](https://github.com/WordPress), например, стартовал как ответвление уже существовавшего проекта [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
+
+* **Прозрачность:** Любой может проверять open source проект на ошибки и несоответствия. Прозрачность важна даже на государственном уровне. Например, правительство [Болгарии](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) и [США](https://sourcecode.cio.gov/) законодательно предписали прозрачность для таких отраслей как: банковское дело, здравоохранение, и ПО безопасности, вроде [Let's Encrypt](https://github.com/letsencrypt).
+
+Open source (открытый исходник) применимо не только к ПО, но и ко всему остальному: от наборов данных до книг. В [Обзоре GitHub](https://github.com/explore) вы можете почерпнуть больше идей насчёт того, что можно заопенсорсить.
+
+### Open source - значит бесплатно?
+
+Бесплатность open source - это одно из его самых больших преимуществ, но не единственное, а скорее - побочный продукт его совокупной ценности.
+
+Поскольку [открытая лицензия предполагает](https://opensource.org/osd-annotated), что кто угодно может использовать, модифицировать, и распространять ваш проект почти для любых целей, то в большинстве случаев это подразумевает бесплатность. Потому что, если бы вы просили плату, то люди бы скачивали проект и использовали его бесплатно, абсолютно легально.
+
+Поэтому большинство open source проектов бесплатны, но это не входит в определение open source. Существуют способы взимания платы за проекты с открытым исходным кодом косвенно, через двойное лицензирование или ограниченные функции, но при этом они соответствуют официальному определению open source.
+
+## Стоит ли мне запускать свой open source проект?
+
+Краткий ответ - да, потому что независимо от результата, запуск своего проекта - это хороший способ понять, как работает open source.
+
+Если вы никогда прежде не запускали подобных проектов, вы можете переживать: "что скажут люди?", "а вдруг вообще никто его не заметит?". Если вам это знакомо, не беспокойтесь, вы не один такой!
+
+Open source, как и любая творческая работа, будь то писательство или рисование, вызывает волнение прежде чем поделиться ей с миром. Но единственный способ улучшить её - практиковаться, даже если у вас не будет аудитории.
+
+Если вы ещё не решились, найдите время подумать о ваших возможных целях.
+
+### Постановка целей
+
+Цели помогут вам определиться, над чем работать, от чего отказаться, и где вам понадобится помощь со стороны. Спросите себя: _"зачем я опенсорсю этот проект?"_.
+
+Единого ответа на этот вопрос не существует. Вы можете иметь много целей для одного проекта, или разные проекты с разными целями.
+
+Если ваша цель просто показать свою работу и нет нужды в сотрудничестве, вы можете так и написать в файле README. С другой стороны, если вы заинтересованы в помощниках, то вам следует вложить своё время в написание понятной документации и проявлять заботу о новичках.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+Однажды я сделал настраиваемый UIAlertView для своих нужд... и решил сделать его open source. Я сделал его более динамичным и загрузил на GitHub. Я так же написал свою первую документацию, объясняющую другим разработчикам, как они могут использовать мою работу в своих проектах. Возможно, ей так никто и не воспользовался из-за её простоты. Но зато я испытал хорошее чувство от всего этого процесса. 
+  <p markdown="1" class="pquote-credit">
+— @mavris, ["Программисты самоучки: Почему Open Source важен для нас"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+  </p>
+</aside>
+
+По мере роста проекта ваше сообщество будет нуждаться не только в коде. Ответы на вопросы (issues), проверка кода, распространение информации о себе - всё это важные задачи open source проекта.
+
+Хотя количество времени на непрограммистские задачи зависит от размера и масштаба вашего проекта, вы должны быть готовы решать их сами или найти для этого помощника.
+
+**Если вы - часть компании, запускающей open source проект,**, убедитесь заранее, что вы имеете внутренние ресурсы для его развития. Назначьте ответственного за сопровождение после запуска и определите, как будут распределяться задачи внутри сообщества.
+
+Если вам нужен выделенный бюджет или персонал для продвижения, эксплуатации и поддержки проекта, обговорите это как можно раньше.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+Когда вы начинаете open source проект, важно, чтобы процессы управления в организации учитывали вклад и возможности сообщества, образовавшегося вокруг проекта. Не бойтесь вовлекать посторонних людей, даже в ключевых аспектах, особенно если они активно участвуют. 
+  <p markdown="1" class="pquote-credit">
+— @captainsafia, ["Чё, хочешь открыть код проекта?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+  </p>
+</aside>
+
+### Участие в чужих проектах
+
+Если ваша цель - понять как взаимодействовать с другими и как работает open source, рассмотрите возможность участия в уже существующем проекте, который вы используете и любите. Вашим участием могут быть такие простые вещи, как исправление опечаток и обновление документации.
+
+Если вы не понимаете, как начать участие в чужом проекте, ознакомьтесь с нашим руководством [Как участвовать в open source проекте](../how-to-contribute/).
+
+## Запуск собственного open source проекта
+
+Нет идеального момента, когда нужно открывать исходники своей работы. Вы можете открыть их на стадии идеи, в процессе работы или после нескольких лет закрытости.
+
+В общем случае, открывать исходники можно, когда вы чувствуете себя уверенно настолько, чтобы показать свою работу посторонним людям и получать их отзывы.
+
+Каждый проект вне зависимости от стадии, на которой вы решили открыть исходники, должен иметь следующую документацию:
+
+* [Лицензию 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)
+* [Руководство для участников](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Кодекс поведения](../code-of-conduct/)
+
+Они помогут вам донести ожидания, принимать правки других участников, и защитить законные права всех соавторов, включая себя. Это значительно увеличивает вероятность позитивного опыта.
+
+Если ваш проект на Гитхабе и вы разместите эти файлы в корневой категории с рекомендованными названиями, Гитхаб распознает их и будет автоматически отображать для ваших читателей.
+
+### Выбор лицензии
+
+Лицензия для открытого исходного кода гарантирует, что другие могут использовать, копировать, изменять и вносить правки в ваш проект без каких-либо последствий. Она также защищает вас от неприятных юридических ситуаций. **Вы должны включить лицензию при запуске проекта с открытым исходным кодом.**
+
+Юридическая работа - не из легких. Но есть хорошие новости: вы можете скопировать существующую лицензию и разместить её в своём репозитории, за одну минуту защитив ваш тяжелый труд.
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), и [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) - это самые популярные лицензии, но [есть и другие варианты](https://choosealicense.com) для выбора.
+
+Когда вы создаёте новый проект на Гитхабе, вам дается на выбор несколько лицензий. Выбрав open source лицензию, вы сделаете свой проект * открытым.
+
+![Выберете лицензию](/assets/images/starting-a-project/repository-license-picker.png)
+
+Если у вас есть другие вопросы или беспокойства относительно юридических аспектов open source, [мы описали их здесь](../legal/).
+
+### Составление README
+
+Файл README ("прочитай меня") не только рассказывает, как использовать ваш проект, но и объясняет, почему он важен, и что пользователи могут с ним делать.
+
+Постарайтесь ответить в README на следующие вопросы:
+
+* Что делает этот проект?
+* Чем этот проект полезен?
+* Как я могу начать работать с ним?
+* Где я могу получить помощь, если понадобится?
+
+Вы можете указать в README: как участвовать в вашем проекте, каковы его цели, рассказать о лицензии и авторстве. Если вы не планируете принимать доработки других людей, или он ещё не готов для запуска - так и напишите об этом.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+  Хорошая документация - это больше пользователей, меньше просьб о помощи, и больше соавторов. (...) Помните, что ваши пользователи - не вы. Это могут быть люди с опытом - сильно отличным от вашего. 
+  <p markdown="1" class="pquote-credit">
+— @tracymakes, ["Писать так, чтобы ваши слова читали (видео)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+  </p>
+</aside>
+
+Иногда люди откладывают написание README, потому что чувствуют, что проект не завершен, или не хотят принимать доработки других людей. Но это как раз хороший повод написать об этом.
+
+Для вдохновения, можете почитать @dguo's ["Сделай README" - руководство](https://www.makeareadme.com/) или @PurpleBooth's [Шаблон README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2).
+
+Когда вы добавляете файл README в корневую директорию проекта, Гитхаб автоматически отображает его на главной странице репозитория.
+
+### Написание руководства для участников
+
+Файл CONTRIBUTING говорит вашей аудитории, как стать участником вашего проекта. Например:
+
+* Как сообщить об ошибке (попробуйте использовать [шаблоны для issue и pull request](https://github.com/blog/2111-issue-and-pull-request-templates))
+* Как предложить новую функцию
+* Как настроить среду выполнения и запустить тесты
+
+Помимо технических деталей, файл CONTRIBUTING - хорошее место, чтобы изложить свои ожидания относительно участия других людей. Например:
+
+* Какого рода участие вы ждёте?
+* Ваши планы и видение развития проекта
+* Как участники могут (и не могут) связываться с вами
+
+Ваш тёплый дружеский тон и конкретные предложения по участию, вроде написания документации или создания сайта, могут иметь большое значение для привлечения новичков к работе над проектом.
+
+Например, [Active Admin](https://github.com/activeadmin/activeadmin/) начинает [своё руководство по участию](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) с таких слов:
+
+> В первую очередь хотим выразить вам благодарность за то, что подумываете об участии в развитии Active Admin. Именно такие люди как вы делают Active Admin прекрасным инструментом.
+
+На ранних стадиях проекта ваш файл CONTRIBUTING может быть простым. Вы всегда должны объяснить как сообщать об ошибках и оформлять вопросы, а так же описать технические требования к правкам участников (например, тесты).
+
+Со временем вы можете дополнить его ответами на часто задаваемые вопросы. Благодаря этому меньше людей будут спрашивать вас об одном и том же снова и снова.
+
+Чтобы вам было проще составить файл CONTRIBUTING, ознакомьтесь с @nayafia's [шаблоном руководства по сотрудничеству](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) или @mozilla's ["Как составить файл CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
+
+Поставьте ссылку на файл CONTRIBUTING внутри README, так больше людей увидят его. Если вы [разместите файл CONTRIBUTING.md в корне вашего проекта](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), то Гитхаб будет автоматически ссылаться на него, когда кто-то открывает новый вопрос (issue) или добавляет правку в проект (pull request).
+
+![руководство по сотрудничеству](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+
+### Разработка кодекса поведения
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+ Все мы сталкивались с неприятными ситуациями, когда хозяин проекта грубо объяснял что-то или пользователи задавали элементарные вопросы. (...) Кодекс поведения становится документом, на который легко ссылаться, и который говорит, что ваша команда очень серьезно относится к конструктивному диалогу. 
+  <p markdown="1" class="pquote-credit">
+— @mlynch, [Делаем open source более счастливым местом](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+  </p>
+</aside>
+
+В итоге, кодекс поведения задаёт базовые правила поведения для участников вашего проекта. Это особенно важно, если вы запускаете проект для компании или сообщества. Кодекс поведения способствует установлению здорового, конструктивного поведения в сообществе, что снижает стресс для вас, как для ответственного за проект.
+
+Подробнее смотрите: [Кодекс поведения - руководство](../code-of-conduct/).
+
+Помимо описания _каким_ вы хотите видеть поведение участников, кодекс поведения также разъясняет, к кому и когда он применяется, и что будет в случае его нарушения.
+
+По аналогии с лицензией, вам не обязательно писать кодекс самим, а можно скопировать один из существующих вариантов. [Соглашение участника](https://contributor-covenant.org/) используется в [более 40,000 open source проектах](https://www.contributor-covenant.org/adopters), включая Kubernetes, Rails, и Swift. Какой бы кодекс вы не использовали, вы должны быть готовы применить его при необходимости.
+
+Поместите файл CODE_OF_CONDUCT.md в корень вашего проекта, так его будет проще находить и ссылаться на него, например, из README.
+
+## Именование и брендирование вашего проекта
+
+Брендирование - это не только броский логотип и запоминающееся название, но и то, как вы говорите о своём проекте и до кого доходит ваше послание.
+
+### Выбор правильного названия
+
+Выберите название, которое легко запомнить и, в идеале, даёт представление о сути проекта. Например:
+
+* [Караул](https://github.com/getsentry/sentry) оповещает о падении приложения.
+* [Дрищ](https://github.com/macournoyer/thin) быстрый и простой веб-сервер на Ruby.
+
+Если ваш проект - это дополнение к существующему проекту, то используйте его название как префикс, это поможет понять, что делает ваш проект. Например [node-fetch](https://github.com/bitinn/node-fetch) привносит `window.fetch` в Node.js).
+
+Выбирайте в пользу понятности. Каламбуры могут быть забавными, но подумайте о людях из других культур или с отличным от вашего опытом, которые могут не понять шутку. Ваши потенциальные пользователи могут быть работниками компаний, которые будут рассказывать о вашем проекте начальству. Не заставляйте их краснеть при этом.
+
+### Конфликт имён
+
+[Проверьте наличие open source проектов с таким же названием](http://ivantomic.com/projects/ospnc/), особенно если вы используете один и тот же язык или экосистему. Если ваше название совпадёт с популярным существующим проектом, вы можете запутать свою аудиторию.
+
+Если вы планируете завести сайт, твиттер или любую площадку для публикаций, убедитесь, что нужное вам название там свободно. И лучше [зарезервируйте эти имена сейчас](https://instantdomainsearch.com/) для душевного спокойствия, даже если пока не планируете ими пользоваться.
+
+Убедитесь, что вы не посягаете на торговую марку какой-нибудь компании. В будущем она сможет попросить вас закрыть проект или даже подать в суд. Это неоправданный риск.
+
+Вы можете проверить конфликт брендов по [всемирной базе брендов WIPO](http://www.wipo.int/branddb/en/). Если вы делаете проект от лица компании, то [юридический отдел может помочь вам с этим](../legal/).
+
+Напоследок, сделайте быстрый поиск в Google по названию вашего проекта. Смогут ли люди по нему легко найти ваш проект? А может быть, по этому запросу появляется что-то нежелательное?
+
+### То, как вы пишите (и кодите) тоже влияет на ваш бренд!
+
+За всю жизнь проекта вы будете много писать: README, руководства, документы сообщества, ответы на вопросы, возможно даже информационные бюллетени и списки рассылки.
+
+Будь то официальная документация или обычное сообщение, ваш стиль письма - это часть бренда проекта. Подумайте о том, в каком свете вы выглядите перед аудиторией, и правильный ли подобрали тон.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+Я старался участвовать в каждой теме в списке рассылки и показывать образцовое поведение, быть доброжелательным к людям, серьезно относиться к их проблемам и быть полезным в общем. Через некоторое время люди стали не только задавать вопросы, но и помогать с ответами, и, к моему полному восторгу, они подражали моему стилю.
+  <p markdown="1" class="pquote-credit">
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+Добрый и вежливый язык создаст приятную атмосферу для новых участников. Следите так же за простотой изложения, так как для многих читателей английский может быть не родным.
+
+Не только слова, что вы пишете, но и стиль кода может стать частью бренда вашего проекта. [Angular](https://angular.io/guide/styleguide) и [jQuery](https://contribute.jquery.org/style-guide/js/) два примера проектов со строгими стилями и рекомендациями.
+
+Нет необходимости составлять руководство по стилю, когда вы только начинаете, и в любом случае вы наверняка захотите включать в свой проект разные стили. Но вы должны заранее понимать, что ваш стиль письма и кода будет привлекать одних людей и отталкивать других. Ранние стадии проекта - это возможность создать прецедент, из которого будет расти проект в желаемом для вас виде.
+
+## Проверочный лист перед запуском
+
+Вы готовы открыть свой проект? Вот вам проверочный лист в помощь. Когда отметите все пункты, [нажмите "опубликовать"](https://help.github.com/articles/making-a-private-repository-public/) и похвалите себя.
+
+**Документация**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    В проекте есть файл LICENSE с лицензией open source 
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    В проекте есть базовая документация (README, CONTRIBUTING, CODE_OF_CONDUCT)
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    Название легко запоминается, даёт представление о сути проекта, не конфликтует с существующими проектами и не посягает на торговые марки. 
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+  Список задач (issues) актуальный, хорошо организованный и помечен ярлыками
+  </label>
+</div>
+
+**Код**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+  Проект использует согласованные договорённости по коду и понятные названия функций/методов/переменных
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+  Код понятно комментируется, документируются замыслы и особые случаи. 
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+  Нигде нет чувствительных данных вроде паролей или другой не публичной информации - в истории ревизий, вопросах (issues) и запросах на правки (pull requests). 
+  </label>
+</div>
+
+**Люди**
+
+Если вы частное лицо:
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+  Вы поговорили с юридическим отделом и/или поняли правила интеллектуальной собственности и политику open source вашей компании (если вы где-то трудоустроены)
+  </label>
+</div>
+
+Если вы юридическое лицо:
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+   Вы поговорили с юридическим отделом 
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    У вас есть маркетинговый план для запуска и продвижения проекта 
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+  Кто-то назначен ответственным за взаимодействие с сообществом: отвечать на вопросы (issues), проверять запросы на правки (pull requests) и присоединять их к проекту
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    Как минимум два человека имеют административный доступ к проекту
+  </label>
+</div>
+
+## Вы сделали это!
+
+Поздравляем с открытием исходников вашего первого проекта! Вне зависимости от результата, работа на виду у людей - это подарок для сообщества. Каждый коммит, комментарий и запрос на правку - это возможность учиться и расти для вас и других.
diff --git a/_data/locales/ru.yml b/_data/locales/ru.yml
new file mode 100644
index 00000000000..2c6d12a55c0
--- /dev/null
+++ b/_data/locales/ru.yml
@@ -0,0 +1,31 @@
+ru:
+  locale_name: Русский
+  nav:
+    about: О проекте
+    contribute: Сотрудничество
+  index:
+    lead: Программы с отрытым кодом создают такие же люди как вы. Узнайте, как запустить и развить свой проект.
+    opensourcefriday: Сегодня пятница! Посвятите несколько часов программе, которую вы любите и используете
+  article:
+    table_of_contents: Содержание
+    back_to_all_guides: На главную
+    related_guides: Связанные темы
+  footer:
+    contribute:
+      heading: Сотрудничество
+      description: Есть что предложить? Эти материалы открыты для редактирования. Помогите улучшить их.
+      button: Сотрудничать
+    subscribe:
+      heading: Оставайтесь на связи
+      description: Будьте первым, кто узнает последние новости открытого кода
+      label: Электронная почта
+      button: Подписаться
+    byline:
+      # [code], [love], and [github] will be replaced by octicons
+      format: '[программируйте] с [любовью] вместе с [github] и [друзьями]'
+      # Label for code octicon
+      code_label: программируйте
+      # Label for love octicon
+      love_label: любовью
+      # Label for the contributors link
+      friends_label: друзьями
diff --git a/_layouts/article.html b/_layouts/article.html
index a2302afb8a3..4a01b1f5a4c 100644
--- a/_layouts/article.html
+++ b/_layouts/article.html
@@ -9,7 +9,7 @@
 
     <h1 class="h0-mktg lh-condensed text-center mb-3">{{ page.title }}</h1>
     <p class="lead text-center text-gray col-md-8 mx-auto mb-4 position-relative">{{ page.description }}</p>
-    {% if page.lang == "en" %}
+    {% if page.lang == "en" or page.lang == "ru" %}
     <nav class="toc mb-4 mb-md-6">
       <div class="Box col-sm-8 col-md-4 col-lg-3 mx-auto">
         <a class="toc-trigger d-block text-center p-3">
@@ -46,7 +46,7 @@ <h1 class="h0-mktg lh-condensed text-center mb-3">{{ page.title }}</h1>
 <div class="container-lg p-responsive mx-auto border-top text-center pt-5">
   <h2 class="h2-mktg">{{ t.article.related_guides }}</h2>
   <div class="gutter-sm d-flex flex-wrap flex-items-stretch pb-md-6">
-  {% for related in page.related %}
+    {% for related in page.related %}
     {% assign article = site.articles | where: 'lang', page.lang | where: 'class', related | first %}
     <div class="col-12 col-sm-9 mx-auto col-md-6 mt-4 mt-lg-5">
       <a href="{{ article.url | relative_url }}" class="guide-cover {{ article.class }} Box height-full d-block">
@@ -66,9 +66,9 @@ <h3 class="h3-mktg text-bold lh-condensed mb-2 text-black">
 
       </a>
     </div>
-  {% endfor %}
+    {% endfor %}
   </div>
 </div>
 {% endif %}
 
-{% include footer.html %}
+{% include footer.html %}
\ No newline at end of file

From 028613a465f1916b73d2451e03a23b68b1ec2733 Mon Sep 17 00:00:00 2001
From: jiahua wang <wjh180909@gmail.com>
Date: Fri, 17 Sep 2021 10:45:10 +0800
Subject: [PATCH 243/749] make translation more native

---
 _articles/zh-hans/code-of-conduct.md           | 4 ++--
 _articles/zh-hans/finding-users.md             | 2 +-
 _articles/zh-hans/getting-paid.md              | 6 +++---
 _articles/zh-hans/leadership-and-governance.md | 6 +++---
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/_articles/zh-hans/code-of-conduct.md b/_articles/zh-hans/code-of-conduct.md
index 98fb751b1d4..4d0478080cb 100644
--- a/_articles/zh-hans/code-of-conduct.md
+++ b/_articles/zh-hans/code-of-conduct.md
@@ -21,7 +21,7 @@ redirect_from: /zh-cn/code-of-conduct/
 
 ## 建立一个行为守则
 
-尽可能早地建立行为守则，当你们第一次创建项目的时候。
+当你们第一次创建项目的时候，尽可能早的建立行为守则。
 
 此外，说出你们的要求。行为守则的描述遵循如下几点：
 
@@ -57,7 +57,7 @@ redirect_from: /zh-cn/code-of-conduct/
 
 请不要忘记了有人可能想要报告某些人违规接受了这些报告。在这样的情况下，也给他们举报那些人的机会。例如，@ctb和@mr-c [在他们的项目上解释](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst)， [khmer](https://github.com/dib-lab/khmer)：
 
-> 对于滥用现象，扰乱或者其他不可接受的行为都可以向**khmer-project@idyll.org**（仅由C. Titus Brown和Michael R. Crusoe处理）发送邮件。要报告涉及其中任何一个的问题，请电邮**Judi Brown Clarke，Ph.D.** BEACON行动进化研究中心的多元化主任，NSF科学技术中心。
+> 对于滥用现象，扰乱或者其他不可接受的行为都可以向**khmer-project@idyll.org**（仅由C. Titus Brown和Michael R. Crusoe处理）发送邮件。要报告涉及其中任何一个的问题，请发送邮件给**Judi Brown Clarke，Ph.D.** BEACON行动进化研究中心的多元化主任，NSF科学技术中心。
 
 为了获得灵感，可以查阅Django的[执行手册](https://www.djangoproject.com/conduct/enforcement-manual/)（你们是否需要如此详细的手册，这取决于你们的项目）。
 
diff --git a/_articles/zh-hans/finding-users.md b/_articles/zh-hans/finding-users.md
index 2ab573437c8..9c2f10443dd 100644
--- a/_articles/zh-hans/finding-users.md
+++ b/_articles/zh-hans/finding-users.md
@@ -108,7 +108,7 @@ redirect_from: /zh-cn/finding-users/
 
 <aside markdown="1" class="pquote">
   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
-  当你开始写你的演讲稿的时候，不管你的主题是什么，如果你能把你的演讲当成是给别人讲故事的话，效果会更更好。
+  当你开始写你的演讲稿的时候，不管你的主题是什么，如果你能把你的演讲当成是给别人讲故事的话，效果会更好。
   <p markdown="1" class="pquote-credit">
 — Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
   </p>
diff --git a/_articles/zh-hans/getting-paid.md b/_articles/zh-hans/getting-paid.md
index 4fae2b29ddd..8ffbf583b9c 100644
--- a/_articles/zh-hans/getting-paid.md
+++ b/_articles/zh-hans/getting-paid.md
@@ -79,7 +79,7 @@ redirect_from: /zh-cn/getting-paid/
 
 很多公司都在开发开源项目，从而能够打造自己的品牌，以及希望雇佣到高质量的人才。
 
-@hueniverse ，举例来说，有充足的证据证明 [沃尔玛对开源的投资](https://hueniverse.com/2014/08/15/open-source-aint-charity/)是合理的。 @jamesgpearce 同样，脸谱网的开源项目让它的招聘显得[与众不同](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) :
+@hueniverse ，举例来说，有充足的证据证明 [沃尔玛对开源的投资](https://hueniverse.com/2014/08/15/open-source-aint-charity/)是合理的。 @jamesgpearce 同样，Facebook 的开源项目让它的招聘显得[与众不同](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) :
 
 > 开源能够与我们 Hacker 文化密切配合，也能够和我们的组织融洽。我们询问员工："在 Facebook 真的那么的在意开源软件？" 超过2/3的人的回答是"yes"。一半的人表示，该计划对他们为我们工作的决定作出了积极的贡献。这可不是一个戏谑的数字，我们希望继续保持这样。
 
@@ -93,7 +93,7 @@ redirect_from: /zh-cn/getting-paid/
   </p>
 </aside>
 
-如果你实在无法在当前的雇主下开展相关开源的工作，那么是该考虑换老板的时候，应到找个支持想开源作贡献的老板！寻找那些致力于开源工作的公司。比如：
+如果你实在无法在当前的雇主下开展相关开源的工作，那么是到了该考虑换老板的时候，应到找个支持想为开源作贡献的老板！寻找那些致力于开源工作的公司。比如：
 
 * [Ghost](https://ghost.org/)  就是一家围绕很多[开源项目](https://github.com/tryghost/ghost)的好公司
 * [Zalando](https://opensource.zalando.com) 甚至为其员工提供了[贡献开源守则](https://opensource.zalando.com/docs/using/contributing/)
@@ -146,7 +146,7 @@ redirect_from: /zh-cn/getting-paid/
 
 ### 利用风投
 
-您将如何用拟议的资金完成什么？专注于项目里程碑或成果，而不是支付工资。
+您将如何分配拟议的资金？专注于项目里程碑或成果，而不是支付工资。
 
 ### 你将以何种方式接受资助
 
diff --git a/_articles/zh-hans/leadership-and-governance.md b/_articles/zh-hans/leadership-and-governance.md
index b837d84b9d2..d2a92ca1d74 100644
--- a/_articles/zh-hans/leadership-and-governance.md
+++ b/_articles/zh-hans/leadership-and-governance.md
@@ -25,9 +25,9 @@ redirect_from: /zh-cn/leadership-and-governance/
 * **贡献者**
 * **修订者**
 
-**对于某些项目来说， "维护者"** 就是唯一拥有提交权限的人。然而在其它的一些项目中， they're simply the people who are listed in the README as maintainers.
+**对于某些项目来说， "维护者"** 就是唯一拥有提交权限的人。然而在其它的一些项目中，他们只是在 README 文件中列为维护者的人。
 
-作为一名维护者，不一定非得一定要为项目撰写代码。Ta有可能是项目的布道师，为项目的宣传做了很多的工作，又或者是撰写文档让更多的人参与进来。不管他们每天做什么，维护者就是那些对项目方向负责的人，并致力于项目的改进。
+作为一名维护者，不一定非得要为项目撰写代码。Ta有可能是项目的布道师，为项目的宣传做了很多的工作，又或者是撰写文档让更多的人参与进来。不管他们每天做什么，维护者就是那些对项目方向负责的人，并致力于项目的改进。
 
 **作为 "贡献者" 可以是任何人** ，只要Ta提出issue或PR 就叫做贡献者，那些为项目作出有价值的都算（无论是分类问题，编写代码还是组织会议），又或者是将他们的PR合并进主干的（或许这个定义是最接近所谓的贡献者的）。
 
@@ -57,7 +57,7 @@ redirect_from: /zh-cn/leadership-and-governance/
 
 对于一个较小的项目来讲，指定领导者，只需要在 README 或 CONTRIBUTORS 文本文件中写上他们的名字即可。
 
-对于稍大型点的项目，如果你已经拥有了网页的话，那么请创建一个团队的页面，或者创建一个团队领导的页面。举例来说， [PostgreSQL](https://github.com/postgres/postgres/) 就拥有一个[很全面地团队页面](https://www.postgresql.org/community/contributors/) ，而且每位贡献者都拥有简短的介绍。
+对于稍大型点的项目，如果你已经拥有了网页的话，那么请创建一个团队的页面，或者创建一个团队领导的页面。举例来说， [PostgreSQL](https://github.com/postgres/postgres/) 就拥有一个[很全面的团队页面](https://www.postgresql.org/community/contributors/) ，而且每位贡献者都拥有简短的介绍。
 
 如果你的项目拥有非常活跃的贡献者社区，你或许会专门建立一个维护者的"核心团队"，甚至是根据不同的话题所有者成立子的委员会（例如，安全，问题筛选，或者是社区准则）。让人们自行组织、且能够让志愿者自行找到自己喜欢的角色，而不是去分配他们。
 

From dabe79b0fcefd620db8fe77217aefaa87a0579dc Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Wed, 22 Sep 2021 18:29:22 +0300
Subject: [PATCH 244/749] Improve Russian translation of "How to Contribute to
 Open Source"

---
 _articles/ru/how-to-contribute.md | 509 +++++++++++++++---------------
 1 file changed, 255 insertions(+), 254 deletions(-)

diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index 97980e8d6b1..b9db034def4 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -1,15 +1,15 @@
 ---
 lang: ru
-title: Как участвовать в открытых проектах
-description: Хотите участвовать в открытых проектах? Руководство по участию для новичков и ветеранов.
+title: Как участвовать в опенсорс-проектах
+description: Хотите внести свой вклад в опенсорс? Руководство по участию для новичков и не только.
 class: contribute
 toc:
-  зачем-участвовать-в-открытых-проектах: 'Зачем участвовать в открытых проектах'
-  что-значит-внести-свой-вклад-to-contribute: 'Что значит внести свой вклад (to contribute)'
-  ориентация-на-новый-проект: 'Ориентация на новый проект'
-  поиск-проекта-в-который-можно-внести-свой-вклад: 'Поиск проекта, в который можно внести свой вклад'
-  как-отправить-вклад: 'Как отправить вклад'
-  что-происходит-после-того-как-вы-отправите-свой-вклад: 'Что происходит после того, как вы отправите свой вклад'
+  зачем-участвовать-в-опенсорс-проектах: 'Зачем участвовать в опенсорс-проектах'
+  что-значит-внести-свой-вклад: 'Что значит внести свой вклад'
+  подготовка-к-новому-проекту: 'Подготовка к новому проекту'
+  поиск-проекта-в-который-можно-поучаствовать: 'Поиск проекта, в котором можно поучаствовать'
+  как-сделать-вклад: 'Как сделать вклад'
+  что-будет-дальше-после-принятия-участия: 'Что будет дальше после принятия участия'
 order: 1
 image: /assets/images/cards/contribute.png
 related:
@@ -17,57 +17,57 @@ related:
   - building
 ---
 
-## Зачем участвовать в открытых проектах?
+## Зачем участвовать в опенсорс-проектах?
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
   Работа над \[freenode\] помогла мне приобрести многие навыки, которые я позже использовал в учебе в университете и в текущей работе. Я думаю, что работа над проектами с открытым исходным кодом помогает мне не меньше, чем самому проекту!
   <p markdown="1" class="pquote-credit">
-— @errietta, ["Почему я люблю участвовать в работе над открытым софтом"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Почему я люблю участвовать в работе над опенсорс-софтом"](https://www.errietta.me/blog/open-source/)
   </p>
 </aside>
 
-Участие в разработке программного обеспечения с открытым исходным кодом может быть полезным способом изучать, обучать и приобретать опыт практически в любом навыке, который вы можете себе представить.
+Участие в опенсорс-проектах может быть полезным способом изучать, обучать и приобретать опыт практически в любом навыке, который вы можете себе представить.
 
-Почему люди вносят свой вклад в открытый исходный код? Множество причин!
+Зачем люди участвуют в опенсорсе? На то есть множество причин!
 
-### Улучшайте программное обеспечение, на которое вы полагаетесь
+### Улучшить используемые проекты
 
-Многие участники открытого кода начинают с того, что являются пользователями программного обеспечения, в которое они вносят свой вклад. Когда вы обнаружите ошибку в программном обеспечении с открытым исходным кодом, которое вы используете, вы можете посмотреть в исходный код, чтобы узнать, можете ли вы исправить его самостоятельно. Если это так, то возвращение патча - лучший способ убедиться, что ваши друзья (и вы сами, когда вы обновитесь до следующего выпуска) смогут извлечь из него пользу.
+Многие опенсорс-контрибьюторы перед тем, как внести свой вклад в продукт, были обычными его пользователями. Если вы обнаружите баг в используемой вами опенсорс-программе вы, возможно, захотите заглянуть в её исходный код, чтобы узнать, сможете ли вы исправить его самостоятельно. Если это так, то отправка патча — лучший способ убедиться, что ваши друзья (и вы сами, когда вы обновитесь до следующего релиза) смогут извлечь из него пользу.
 
 ### Улучшить существующие навыки
 
 Будь то программирование, дизайн пользовательского интерфейса, графический дизайн, написание текста или организационная работа, если вы ищете практику, для вас найдётся задача в проекте с открытым исходным кодом.
 
-### Знакомьтесь с людьми, которым интересны похожие вещи
+### Познакомиться с людьми с общими интересами
 
-Проекты с открытым исходным кодом с теплыми, гостеприимными сообществами заставляют людей возвращаться долгие годы. Многие люди завязывают дружбу на всю жизнь благодаря участию в открытых проектах, будь то встреча друг с другом на конференциях или поздних ночных онлайн-чатах о буррито.
+Опенсорс-проекты с теплыми, гостеприимными сообществами заставляют людей возвращаться долгие годы. Многие люди завязывают дружбу на всю жизнь благодаря участию в открытых проектах, будь то встреча друг с другом на конференциях или поздних ночных онлайн-чатах о буррито.
 
-### Найдите наставников и научите других
+### Найти наставников и научить других
 
 Работа с другими над общим проектом означает, что вам придется объяснять, как вы это делаете, а также просить помощи у других. Акты обучения и преподавания могут быть полезными для всех участников.
 
-### Создавайте общедоступные артефакты, которые помогут вам повысить репутацию (и карьеру)
+### Создать общедоступные проекты, которые помогут вам повысить репутацию (и карьеру)
 
-По определению, вся ваша работа с открытым исходным кодом является общедоступной, что означает, что вы получаете бесплатные примеры, которые можно использовать где угодно в качестве демонстрации того, что вы можете делать.
+По определению, вся ваша работа с открытым исходным кодом является общедоступной, это значит, что у вас появляются примеры, которые можно использовать где угодно в качестве демонстрации того, что вы можете делать.
 
-### Изучите навыки работы с людьми
+### Изучить навыки работы с людьми
 
-Открытый исходный код предлагает возможности практиковать лидерские и управленческие навыки, такие как разрешение конфликтов, организация групп людей и определение приоритетов в работе.
+Опенсорс предлагает возможности практиковать лидерские и управленческие навыки, такие как разрешение конфликтов, организация групп людей и определение приоритетов в работе.
 
-### Это дает возможность вносить изменения, даже небольшие.
+### Возможность внести изменения, пусть даже небольшие
 
-Необязательно становиться участником на протяжении всей жизни, чтобы получать удовольствие от участия в проектах с открытым исходным кодом. Вы когда-нибудь видели опечатку на сайте и хотели бы, чтобы кто-нибудь ее исправил? В проекте с открытым исходным кодом вы можете это сделать. Открытый исходный код помогает людям чувствовать свободу в своей жизни и в том, как они воспринимают мир, и это само по себе отрадно.
+Необязательно становиться контрибьютором на протяжении всей жизни, чтобы получать удовольствие от участия в опенсорс-проектах. Вы когда-нибудь видели опечатку на сайте и хотели бы, чтобы кто-нибудь её исправил? В проекте с открытым исходным кодом вы можете это сделать. Опенсорс помогает людям чувствовать хозяевами своей жизни и того  , как они воспринимают мир, и это само по себе отрадно.
 
-## Что значит внести свой вклад (to contribute)
+## Что значит внести свой вклад 
 
-Если вы новичок в open source, процесс может быть пугающим. Как найти подходящий проект? Что делать, если вы не умеете программировать? Что если что-то пойдет не так?
+Если вы новичок в опенсорсе, процедура участия в нём может быть пугающей. Как найти подходящий проект? Что делать, если вы не умеете программировать? Что если что-то пойдет не так?
 
-Не беспокойтесь! Есть много способов принять участие в проекте с открытым исходным кодом, и несколько советов помогут вам извлечь максимальную пользу из вашего опыта.
+Не беспокойтесь! Много чем можно заняться в опенсорс-проекте, и вот несколько подсказок, которые помогут вам определиться, чтобы извлечь максимальную пользу.
 
-### Вам не нужно вносить код
+### Необязательно помогать кодом
 
-Распространенное заблуждение об участии в разработке открытого исходного кода состоит в том, что вам нужно писать код. Зачастую есть другие части проекта, [наиболее игнорируемые или упускаемые из виду](https://github.com/blog/2195-the-shape-of-open-source). Вы окажете проекту огромную услугу, предложив поработать над этим!
+Распространенное заблуждение, касающиеся участия в опенсорсе, состоит в том, что вам нужно писать код. Зачастую есть другие части проекта, которым [наиболее всего принебрегают или упускают из виду](https://github.com/blog/2195-the-shape-of-open-source). Вы окажете проекту _огромную_ услугу, предложив поработать над ними!
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
@@ -77,88 +77,89 @@ related:
   </p>
 </aside>
 
-Даже если вам нравится писать код, другие виды участия - отличный способ поучаствовать в проекте и познакомиться с другими членами сообщества. Построение этих отношений даст вам возможность работать над другими частями проекта.
+Даже если вам нравится писать код, другие виды помощи — отличный способ поучаствовать в проекте и познакомиться с другими членами сообщества. Налаживание таких отношений даст вам возможность работать над другими частями проекта.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-Я впервые обратился к команде разработчиков Python (также известной как python-dev), когда 17 июня 2002 года отправил по электронной почте список рассылки с просьбой принять мой патч. Я быстро заметил ошибку в открытом исходном кода и решил начать готовить дайджесты электронной почты для группы. Они дали мне отличный повод попросить разъяснений по теме, но, что более важно, я мог заметить, когда кто-то указывал на что-то, что требовало исправления.  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Истории сопровождающего"](https://github.com/open-source/stories/brettcannon)
+Я впервые обратился к команде разработчиков Python (также известной как python-dev), когда 17 июня 2002 года в список рассылки отправил электронное письмо с просьбой принять мой патч. Я быстро заметил баг в коде и решил начать готовить почтовые дайджесты для группы. Это послужило отличным предлогом попросить разъяснений по теме, но, что более важно, я мог заметить, когда кто-то указывал на то, что требовало исправления.
+<p markdown="1" class="pquote-credit">
+— @brettcannon, ["Истории мейнтейнера"](https://github.com/open-source/stories/brettcannon)
   </p>
 </aside>
 
-### Вы любите планировать мероприятия?
+### Нравится планировать мероприятия?
 
-* Организуйте семинары или встречи по проекту, [как @fzamperin сделал для NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Организуйте семинары или митапы по проекту, [что и сделал @fzamperin в NodeSchool](https://github.com/nodeschool/organizers/issues/406)
 * Организуйте конференцию проекта (если она есть)
-* Помогите участникам сообщества найти подходящие конференции и подать предложения для выступления
+* Помогите участникам сообщества найти подходящие конференции и подать заявку на доклад
 
-### Любите проектировать?
+### Нравится дизайнить?
 
-* Реструктурируйте макетов для повышения удобства использования проекта.
-* Проведите исследование пользователей, чтобы реорганизовать и уточнить навигацию или меню проекта [как предлагает Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability)
-* Составьте руководство по стилю, чтобы помочь проекту иметь единый визуальный дизайн.
-* Создайте изображения для футболок или новый логотип [как это сделали участники hapi.js](https://github.com/hapijs/contrib/issues/68)
+* Переделайте макеты, чтобы повысить удобство использования проекта
+* Проведите исследование поведения пользователей, чтобы реорганизовать и улучшить навигацию или меню проекта, [например, как предлагает Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Составьте руководство по стилю оформления, чтобы помочь проекту с соблюдением единообразного визуального дизайна
+* Создайте принты для футболок или новый логотип, [как это сделали участники hapi.js](https://github.com/hapijs/contrib/issues/68)
 
-### Любите писать?
+### Нравится писать?
 
 * Напишите и улучшите документацию по проекту
-* Создайте папку с примерами, показывающими, как используется проект
-* Начните рассылку новостей по проекту или отредактируйте основные моменты из списка рассылки
-* Напишите учебники для проекта [как это сделали участники PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
-* Напишите перевод документации по проекту
-
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/kittens?s=180" class = "pquote-avatar" alt = "avatar">
-  Кроме шуток, \[документация\] мега важна. Документация до сих пор была отличной и была ключевой особенностью Бабеля (Babel). Есть разделы, которые требуют доработку, и даже добавление параграфа здесь или там чрезвычайно приветствуется.
-  <p markdown = "1" class = "pquote-credit">
-- @kittens, ["Призыв участников"](https://github.com/babel/babel/issues/1347)
+* Создайте папку с примерами по использованию проекта
+* Запустите рассылку новостей по проекту или освещайте самое важное из списка рассылки
+* Составьте обучающие руководства по проекту, [как это сделали участники PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Переведите документацию проекта
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
+  Кроме шуток, \[документация\] крайней важна. Документация до сих пор была отличной и была ключевой особенностью Babel. Есть разделы, которые требуют доработку, и даже добавление параграфа здесь или там чрезвычайно приветствуется.
+  <p markdown="1" class="pquote-credit">
+- @kittens, ["Призыв контрибьюторов"](https://github.com/babel/babel/issues/1347)
   </p>
 </aside>
 
-### Любите организовывать?
+### Нравится организовывать?
 
-* Выставляйте ссылки на повторяющиеся вопросы (issues) и предлагайте новые ярлыки для вопросов, чтобы все было организовано
-* Просмотрите открытые вопросы и предложите закрыть старые [например, @nzakas для ESLint](https://github.com/eslint/eslint/issues/6765)
-* Задавайте уточняющие вопросы по недавно открывшимся вопросам, чтобы продвинуть обсуждение вперед
+* Давайте ссылки на повторяющиеся ишью, предлагайте новые ярлыки для ишью, чтобы они были лучше огранизованы
+* Пройдитесь по открытым ишью и предложите закрыть старые, как [например сделал @nzakas в ESLint](https://github.com/eslint/eslint/issues/6765)
+* Задавайте уточняющие вопросы по недавно открывшимся ишью, чтобы продвинуть обсуждение вперед
 
-### Любите кодить?
+### Нравится кодить?
 
-* Найдите открытую проблему для решения [например, @dianjin сделал для Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
-* Спросите, можете ли вы помочь написать новую функцию
+* Найдите открытую проблему для решения, что [например @dianjin сделал в Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Спросите, можете ли вы помочь с разработкой новой функциональности
 * Автоматизируйте настройку проекта
 * Улучшите инструменты и тестирование
 
-### Любите помогать людям?
+### Нравится помогать людям?
 
-* Ответьте на вопросы о проекте, например, на Stack Overflow ([как в этом примере Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) или Reddit
-* Отвечайте на вопросы людей по открытым вопросам
+* Ответьте на вопросы о проекте, например, на Stack Overflow ([как в этом примере с Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) или Reddit
+* Отвечайте на вопросы людей по открытым ишью
 * Помогите модерировать доски обсуждений или каналы в чатах
 
 ### Нравится ли вам помогать другим кодить?
 
 * Проверяйте код других людей
-* Напишите учебные пособия по использованию проекта
-* Предложите стать наставником другого участника [как @ereichert сделал для @bronzdoc на Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+* Напишите учебные руководства по использованию проекта
+* Предложите наставничество другому контрибьютору, [как @ereichert сделал для @bronzdoc в Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
 
 ### Можно работать не только над программными проектами!
 
-Хотя «открытый исходник» часто относится к программному обеспечению, вы можете сотрудничать практически над чем угодно. Есть книги, рецепты, списки и классы, которые разрабатываются как проекты с открытым исходным кодом.
+Хотя «опенсорс» часто относится к программному обеспечению, вы можете совместно работать практически над чем угодно. Есть книги, рецепты, списки и курсы, которые разрабатываются как опенсорс-проекты.
 
 Например:
 
-* @sindresorhus создает [список "классных" списков](https://github.com/sindresorhus/awesome)
-* @h5bp ведет [список потенциальных вопросов на собеседовании](https://github.com/h5bp/Front-end-Developer-Interview-Questions) для кандидатов в разработчики интерфейсов.
-* @stuartlynn и @ nicole-a-tesla сделали [сборник забавных фактов о тупиках](https://github.com/stuartlynn/puffin_facts)
+* @sindresorhus курирует [список "классных" списков](https://github.com/sindresorhus/awesome)
+* @h5bp ведет [список потенциальных вопросов на собеседовании](https://github.com/h5bp/Front-end-Developer-Interview-Questions) для кандидатов в разработчики интерфейсов
+* @stuartlynn и @nicole-a-tesla сделали [сборник забавных фактов о тупиках](https://github.com/stuartlynn/puffin_facts)
 
-Даже если вы разработчик программного обеспечения, работа над документацией проекта может помочь вам начать работу с открытым проектом. Работать над проектами, не использующими код, зачастую не так страшно, и процесс совместной работы укрепит вашу уверенность и опыт.
+Даже если вы разработчик программного обеспечения, работа над документацией проекта может помочь вам войти в опенсорс. Зачастую работа над проектами, не связанными с кодом, не так пугает, а процесс совместной работы поможет вам обрести уверенность и опыт.
 
-## Ориентация на новый проект
+## Подготовка к новому проекту
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/shaunagm?s=180" class = "pquote-avatar" alt = "avatar">
-  Если вы обращаетесь к системе отслеживания вопросов (issue), и вас она сбивает с толку, дело не только в вас. Эти инструменты требуют большого количества неявных знаний, но люди могут помочь вам сориентироваться в них, и вы можете задать им вопросы.
-  <p markdown = "1" class = "pquote-credit">
-- @shaunagm, [«Как внести свой вклад в разработку открытого исходного кода»](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
+  Когда вы просматриваете список ишью, который сбивает вас с толку, дело не только в вас. Эти инструменты требуют большого количества неявных знаний, но люди могут помочь вам сориентироваться в них, вы можете задать им вопросы.
+  <p markdown="1" class="pquote-credit">
+- @shaunagm, [«Как внести свой вклад в опенсорс»](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
   </p>
 </aside>
 
@@ -166,242 +167,242 @@ related:
 
 Прежде чем вслепую приступить к своим собственным предложениям, начните с изучения обстановки в сообществе. Это увеличивает шансы на то, что ваши идеи будут замечены и услышаны.
 
-### Анатомия проекта с открытым исходным кодом
+### Анатомия опенсорс-проекта
 
 Каждое сообщество с открытым исходным кодом отличается.
 
-Потратить годы на один открытый проект означает, что вы познакомились с одним открытым проектом. Переходите к другому проекту, и вы можете обнаружить, что словарный запас, нормы и стили общения совершенно другие.
+Потратить годы на один открытый проект означает, что вы познакомились с одним открытым проектом. Переходите к другому проекту, и вы можете обнаружить, что терминология, нормы и стили общения совершенно другие.
 
 Тем не менее, многие проекты с открытым исходным кодом следуют схожей организационной структуре. Понимание различных ролей сообщества и общего процесса поможет вам быстро сориентироваться в любом новом проекте.
 
 Типичный проект с открытым исходным кодом состоит из следующих типов людей:
 
 * **Автор:** Человек или организация, создавшие проект.
-* **Владелец:** Лицо, которое имеет административное право собственности на организацию или репозиторий (не всегда то же самое, что и первоначальный автор).
-* **Сопровождающие:** Соавторы, которые несут ответственность за формирование видения и управление организационными аспектами проекта (они также могут быть авторами или владельцами проекта).
-* **Соавторы:** Все, кто внес свой вклад в проект.
-* **Участники сообщества:** Люди, которые используют проект. Они могут быть активными в беседах или высказывать свое мнение о направлении проекта.
+* **Владелец:** Лицо, которое имеет административные права на организацию или репозиторий (не всегда те же самые, что и первоначальный автор).
+* **Мейнтейнеры:** Контрибьюторы, которые несут ответственность за формирование видения и управление организационными аспектами проекта (они также могут быть авторами или владельцами проекта).
+* **Контрибьюторы:** Все, кто внес свой вклад в проект.
+* **Участники сообщества:** Люди, использующие проект. Они могут быть активными в беседах или высказывать свое мнение о направлении проекта.
 
-В более крупных проектах также могут быть подкомитеты или рабочие группы, занимающиеся различными задачами, такими как инструменты, сортировка, модерация сообщества и организация мероприятий. Поищите на веб-сайте проекта или репозитории "командную" или "организационную" страницу, чтобы найти эту информацию.
+В более крупных проектах также могут быть подкомитеты или рабочие группы, занимающиеся различными задачами, такими как инструменты, сортировка, модерация сообщества и организация мероприятий. Поищите на сайте проекта или репозитории "командную" или "организационную" страницу, чтобы найти эту информацию.
 
-У проекта также есть документация. Эти файлы обычно перечислены на верхнем уровне репозитория.
+У проекта также есть документация. Эти файлы обычно находятся в корне репозитория.
 
-* **ЛИЦЕНЗИЯ:** По определению, каждый проект с открытым исходным кодом должен иметь [лицензию с открытым исходным кодом](https://choosealicense.com). Если у проекта нет лицензии, он не является открытым исходным кодом.
-* **README:** README * это инструкция, которая приветствует новых членов сообщества в проекте. В нем объясняется, почему проект полезен и с чего начать.
-* **УЧАСТИЕ (CONTRIBUTING):** В то время как README помогают людям _использовать_ проект, документация участников помогает людям _вносить_ свой вклад в проект. В нем объясняется, какие виды помощи необходимы и как работает этот процесс. Хотя не у каждого проекта есть файл CONTRIBUTING, его наличие свидетельствует о дружелюбном отношении к участникам.
-* **КОДЕКС ПОВЕДЕНИЯ (CODE_OF_CONDUCT):** Кодекс поведения устанавливает основные правила поведения участников и помогает создать дружелюбную, гостеприимную атмосферу. Хотя не в каждом проекте есть файл CODE_OF_CONDUCT, его наличие свидетельствует о том, что это хороший проект, в который можно внести свой вклад.
-* **Другая документация:** Может быть дополнительная документация, такая как учебные пособия, пошаговые руководства или политики управления, особенно для более крупных проектов.
+* **LICENSE:** По определению, каждый опенсорс-проект должен иметь [соответствующую лицензию](https://choosealicense.com). Если у проекта нет лицензии, его нельзя перечислить к опенсорсу.
+* **README:** README — это руководство-инструкция, которая приветствует новых членов сообщества в проекте. В этой файле объясняется назначение и применение проекта.
+* **CONTRIBUTING:** В то время как README помогают людям _использовать_ проект, документация по участию помогает людям _вносить_ вклад в проект. В нем объясняется, какие виды помощи необходимы и как устроен процесс. Хотя не у каждого проекта есть файл CONTRIBUTING, его наличие свидетельствует о дружелюбном отношении к участникам.
+* **CODE_OF_CONDUCT:** Кодекс поведения устанавливает основные правила поведения участников и помогает создать дружелюбную, гостеприимную атмосферу. Хотя не в каждом проекте есть файл CODE_OF_CONDUCT, его наличие свидетельствует о том, что это хороший проект, в который можно внести свой вклад.
+* **Другая документация:** Может быть дополнительная документация, например обучающие материалы, пошаговые руководства или политики управления, особенно для более крупных проектов.
 
 Наконец, в проектах с открытым исходным кодом для организации обсуждения используются следующие инструменты. Чтение архивов даст вам хорошее представление о том, как сообщество думает и работает.
 
-* **Отслеживание проблем (issue tracker):** Где люди обсуждают вопросы, связанные с проектом.
-* **Запросы на исправление (pull request):** Где люди обсуждают и просматривают запросы на изменение кода.
-* **Дискуссионные форумы или списки рассылки:** Некоторые проекты могут использовать эти каналы для разговорных тем (например, _"Как мне ..."_ или _"Что вы думаете о ..."_ вместо отчётов об ошибках и просьбе новых функций). Другие используют issues для всех разговоров.
-* **Синхронный канал чата:** Некоторые проекты используют каналы чата (например, Slack или IRC) для спонтанного общения, совместной работы и быстрого обмена мнениями.
+* **Список ишью (issue tracker):** Место, где происходят обсуждения, связанные с проектом.
+* **Пул-реквесты (pull requests):** Место, где рассматриваются запросы на изменение кода.
+* **Дискуссионные форумы или списки рассылки:** Некоторые проекты могут использовать эти каналы для разговорных тем (например, _"Как мне ..."_ или _"Что вы думаете о ..."_ вместо отчётов об ошибках и внесения предложений с новыми возможностями). Другие используют ишью для всех дискуссий.
+* **Синхронный чат-канал:** Некоторые проекты используют чаты (например, Slack или IRC) для спонтанного общения, совместной работы и быстрого обмена информацией.
 
-## Поиск проекта, в который можно внести свой вклад
+## Поиск проекта, в котором можно поучаствовать
 
-Теперь, когда вы разобрались, как работают проекты с открытым исходным кодом, пришло время найти проект, в который вы можете внести свой вклад!
+Теперь, когда вы разобрались, как устроены опенсорс-проекты, пришло время найти проект, в который вы сможете внести свой вклад!
 
-Если вы никогда раньше не участвовали в разработке открытого исходного кода, прислушайтесь к совету президента США Джона Ф. Кеннеди, который однажды сказал: «Не спрашивайте, что ваша страна может сделать для вас - спросите, что вы можете сделать для своей страны».
+Если вы никогда раньше не имели дело с опенсорсом, прислушайтесь к совету президента США Джона Ф. Кеннеди, который однажды сказал: _«Не спрашивайте, что ваша страна может сделать для вас, спросите, что вы можете сделать для своей страны»_.
 
-Содействие развитию открытого исходного кода происходит на всех уровнях, в рамках проектов. Вам не нужно задумываться, какой именно будет ваш первый вклад или как он будет выглядеть.
+Участвовать в опенсорсе могут все, независимо от уровня подготовки. Не ломайте сильно голову над тем, каким будет ваш первый вклад в опенсорс.
 
-Вместо этого начните с размышлений о проектах, которые вы уже используете или хотите использовать. Проекты, в которых вы будете активно участвовать, - это те, к которым вы вернетесь.
+Вместо этого подумайте о проектах, которые вы уже используете или собираетесь использовать. Проекты, в которых вы будете активно участвовать, — это те, к которым вы будете возвращаться.
 
-В рамках этих проектов, когда вы ловите себя на мысли, что что-то может быть лучше или иначе, действуйте в соответствии со своим инстинктом.
+В этих проектах всякий раз, когда вы ловите себя на мысли, что что-то может быть лучше или иначе, действуйте в соответствии со своим инстинктом.
 
-Открытый исходный код - это не эксклюзивный клуб; это делают такие же люди, как вы. «Открытый исходный код» - это всего лишь причудливый термин для обозначения мировых проблем как решаемых.
+Опенсорс — это не закрытый клуб; им занимаются такие же люди, как вы. «Опенсорс» — это всего лишь причудливый термин для обозначения решаемых мировых проблем.
 
-Вы можете просканировать README и найти неработающую ссылку или опечатку. Или вы новый пользователь, и вы заметили, что что-то сломано, или недостаток в документации. Вместо того, чтобы игнорировать это и двигаться дальше или просить кого-нибудь исправить это, посмотрите, можете ли вы помочь, приняв участие. Вот в чем суть открытого исходного кода!
+Можно просмотреть файл README, чтобы найти неработающую ссылку или опечатку. Или вы как новый пользователь заметили, что что-то работает неправильно, либо есть неточность в документации. Вместо игнорирования таких проблем или просить кого-нибудь исправить их, посмотрите, удастся ли вам помочь и тем самым поучаствовать в проекте. В этом как раз и смысл опенсорса!
 
-> [28% случайных вкладов](https://www.igor.pro.br/publica/papers/saner2016.pdf) в открытый исходный код представляют собой документацию, такую ​​как исправление опечатки, переформатирование или написание перевода.
+> [28% случайных вкладов](https://www.igor.pro.br/publica/papers/saner2016.pdf) в опенсорс представляют собой документацию, например, исправление опечатки, переформатирование или перевод.
 
-Если вы ищете существующие проблемы, которые можно исправить, в каждом проекте с открытым исходным кодом есть страница `/contribute`, на которой освещаются проблемы, удобные для начинающих, с которых вы можете начать. Перейдите на главную страницу репозитория на GitHub и добавьте в конец URL-адреса «/contribute (например, [https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+Если вы ищете существующие ишью, которые можно исправить, то в каждом опенсорс-проекте есть страница `/contribute`, где вы перечислены ишью, специально предназначенные для начинающих. Перейдите на главную страницу репозитория на GitHub и добавьте в конец URL-адреса `/contribute` (например, [https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
 
 Вы также можете использовать один из следующих ресурсов, чтобы открыть для себя новые проекты и внести свой вклад в них:
 
-* [Обзор GitHub](https://github.com/explore/)
-* [Пятница с открытым исходным кодом](https://opensourcefriday.com)
-* [Только для новичков](https://www.firsttimersonly.com/)
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
 * [CodeTriage](https://www.codetriage.com/)
-* [24 запроса на слияние](https://24pullrequests.com/)
-* [Готово](https://up-for-grabs.net/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
-* [Первые взносы](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
-### Контрольный список перед тем, как внести свой вклад
+### Контрольный список перед тем, как принять участие
 
-Когда вы нашли проект, в который хотели бы внести свой вклад, сделайте быстрый обзор, чтобы убедиться, что проект принимает стороннюю помощь. В противном случае ваш упорный труд может никогда не получить отклика.
+Когда вы нашли проект, в который хотели бы внести свой вклад, бегло осмотритесь проект, чтобы убедиться, что он принимает стороннюю помощь. В противном случае ваш упорный труд может остаться незамеченным.
 
-Вот удобный контрольный список, чтобы оценить, подходит ли проект для новых участников.
+Вот удобный контрольный список, чтобы понять, подходит ли проект для новых контрибьюторов.
 
-**Соответствует определению открытого исходного кода**
+**Попадает под определение опенсорса**
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox1" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox1" class = "overflow-hidden d-block text-normal">
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
   Есть ли у него лицензия? Обычно в корне репозитория находится файл LICENSE.
   </label>
 </div>
 
-**Проект активно принимает взносы**
+**Проект активно принимает стороннюю помощь**
 
-Посмотрите на изменения (commits) в основной ветке. На GitHub вы можете увидеть эту информацию на домашней странице репозитория.
+Посмотрите на коммиты в основной ветке. Узнать это вы можете на главной странице репозитория на GitHub.
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox2" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox2" class = "overflow-hidden d-block text-normal">
-  Когда было последнее изменение?
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+  Когда был последний коммит?
   </label>
 </div>
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox3" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox3" class = "overflow-hidden d-block text-normal">
-  Сколько участников у проекта?
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+  Сколько контрибьюторов у проекта?
   </label>
 </div>
 
-<div class = "clearfix mb-4">
-  <input type = "checkbox" id = "cbox4" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox4" class = "overflow-hidden d-block text-normal">
-  Как часто люди совершают правки? (На GitHub вы можете найти это, щелкнув «Commits» на верхней панели.)
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+  Как часто люди коммитят в репозиторий? (На GitHub выяснить это можно, кликнув по ссылке «Commits» в верхней панели.)
   </label>
 </div>
 
-Затем посмотрите на проблемы (issues) проекта.
+Затем посмотрите на ишью проекта.
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox5" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox5" class = "overflow-hidden d-block text-normal">
-    Сколько сейчас открытых вопросов?
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Сколько сейчас открытых ишью?
   </label>
 </div>
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox6" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox6" class = "overflow-hidden d-block text-normal">
-    Насколько быстро сопровождающие реагируют на проблемы, когда они открываются?
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Быстро ли мейнтейнеры реагируют на ишью после того, когда они открываются?
   </label>
 </div>
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox7" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox7" class = "overflow-hidden d-block text-normal">
-    Идет ли активное обсуждение вопросов?
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Ведётся ли активное обсуждение ишью?
   </label>
 </div>
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox8" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox8" class = "overflow-hidden d-block text-normal">
-    Проблемы недавние?
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Есть ли недавно созданные ишью?
   </label>
 </div>
 
-<div class = "clearfix mb-4">
-  <input type = "checkbox" id = "cbox9" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox9" class = "overflow-hidden d-block text-normal">
-    Проблемы закрываются? (На GitHub щелкните вкладку «закрытые» на странице «Проблемы» (issues), чтобы увидеть закрытые проблемы.)
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Есть ли закрытые ишью? (На странице Issues GitHub-репозитория щелкните на вкладку «Closed», чтобы увидеть закрытые ишью.)
   </label>
 </div>
 
-Теперь проделайте то же самое с запросами на изменение проекта.
+Теперь выясните такую информацию про пул-реквесты проекта.
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox10" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox10" class = "overflow-hidden d-block text-normal">
-    Сколько существует открытых запросов на изменение?
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    Сколько сейчас открытых пул-реквестов?
   </label>
 </div>
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox20" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox20" class = "overflow-hidden d-block text-normal">
-    Быстро ли реагируют сопровождающие на запросы на изменение, когда они открываются?
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox20" class="overflow-hidden d-block text-normal">
+    Быстро ли мейнтейнеры реагируют на пул-реквесты после того, когда они открываются?
   </label>
 </div>
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox11" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox11" class = "overflow-hidden d-block text-normal">
-    Есть ли активное обсуждение запросов на изменение?
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Ведётся ли активное обсуждение пул-реквестов?
   </label>
 </div>
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox12" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox12" class = "overflow-hidden d-block text-normal">
-    Были ли запросы на изменение недавно?
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    Есть ли недавно отправленные пул-реквесты?
   </label>
 </div>
 
-<div class = "clearfix mb-4">
-  <input type = "checkbox" id = "cbox13" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox13" class = "overflow-hidden d-block text-normal">
-    Как недавно были объединены запросы на изменение? (На GitHub щелкните вкладку «закрытые» на странице «Запросы на изменение, чтобы увидеть закрытые PR.)
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox13" class="overflow-hidden d-block text-normal">
+    Как давно были объединены пул-реквесты? (На странице Pull Request GitHub-репозитория щелкните на вкладку «Closed», чтобы увидеть закрытые пул-реквесты.)
   </label>
 </div>
 
 **Проект приветливый**
 
-Дружелюбный и приветливый проект сигнализирует о том, что они будут восприимчивы к новым участникам.
+Дружелюбный и доброжелательный проект свидетельствует о том, что в нём будут с пониманием относится к новыми контрибьюторам.
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox14" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox14" class = "overflow-hidden d-block text-normal">
-    Отвечают ли сопровождающие услужливо на вопросы в проблемах (issues)?
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox14" class="overflow-hidden d-block text-normal">
+    Отвечают ли охотно мейнтейнеры на вопросы в ишью?
   </label>
 </div>
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox15" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox15" class = "overflow-hidden d-block text-normal">
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox15" class="overflow-hidden d-block text-normal">
     Дружелюбны ли люди в вопросах, дискуссионном форуме и чате (например, IRC или Slack)?
   </label>
 </div>
 
-<div class = "clearfix mb-2">
-  <input type = "checkbox" id = "cbox16" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox16" class = "overflow-hidden d-block text-normal">
-    Проверяются ли запросы на изменение?
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox16" class="overflow-hidden d-block text-normal">
+    Проверяются ли пул-реквесты?
   </label>
 </div>
 
-<div class = "clearfix mb-4">
-  <input type = "checkbox" id = "cbox17" class = "d-block float-left mt-1 mr-2" value = "checkbox">
-  <label for = "cbox17" class = "overflow-hidden d-block text-normal">
-    Сопровождающие благодарят людей за их вклад?
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox17" class="overflow-hidden d-block text-normal">
+    Благодарят ли мейнтейнеры людей за их помощь?
   </label>
 </div>
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/kfogel?s=180" class = "pquote-avatar" alt = "avatar">
-  Всякий раз, когда вы видите длинное обсуждение, выборочно проверяйте ответы основных разработчиков, которые приходят в конце обсуждения. Подводят ли они конструктивные выводы и предпринимают ли шаги, чтобы довести обсуждение до решения, оставаясь при этом вежливыми? Если вы видите, что идет много пламенных войн, это часто является признаком того, что энергия идет на споры, а не на развитие.
-  <p markdown = "1" class = "pquote-credit">
-- @kfogel, [_Proroduction OSS_](https://prodingoss.com/en/evaluating-oss-projects.html)
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Всякий раз, когда вы видите длинное обсуждение, выборочно проверяйте ответы основных разработчиков, которые приходят в конце обсуждения. Подводят ли они конструктивные выводы и предпринимают ли шаги, чтобы довести обсуждение до решения, оставаясь при этом вежливыми? Если вы видите, что идет много разборок, это часто является признаком того, что энергия идет на споры, а не на развитие.
+  <p markdown="1" class="pquote-credit">
+- @kfogel, [_Создание OSS_](https://prodingoss.com/en/evaluating-oss-projects.html)
   </p>
 </aside>
 
-## Как отправить вклад
+## Как сделать вклад
 
-Вы нашли проект, который вам нравится, и готовы внести свой вклад. Наконец-то! Вот как правильно получить свой вклад.
+Вы нашли понравившийся проект, и уже готовы поучаствовать в нём. Наконец-то! И вот как правильно это сделать.
 
 ### Эффективное общение
 
-Независимо от того, являетесь ли вы единовременным участником или пытаетесь присоединиться к сообществу, работа с другими - один из самых важных навыков, которые вы разовьете в работе с открытым исходным кодом.
+Независимо от того, поучаствуете ли вы только один раз или же попытаетесь присоединиться к сообществу, совместная работа с другими люди  — один из самых важных навыков, который вы приобретете, занимаясь опенсорсом.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/shubheksha?s=180" class = "pquote-avatar" alt = "avatar">
-  \[Как новый участник\] я быстро понял, что мне нужно задавать вопросы, если я хочу иметь возможность закрыть проблему. Я просмотрел кодовую базу. Как только я получил некоторое представление о том, что происходит, я попросил дополнительных указаний. И вуаля! Я смог решить проблему после получения всей необходимой мне информации.
-  <p markdown = "1" class = "pquote-credit">
-- @shubheksha, [Очень ухабистое путешествие новичка по миру открытого исходного кода](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
+  \[Как новый контрибьютор\] я быстро понял, что мне нужно задавать вопросы, если я хочу закрыть ишью. Я бегло просмотрел кодовую базу. Как только я немного понял код, я попросил дополнительных указаний. И вуаля! Я смог разобраться с ишью после получения всей необходимой мне информации.
+  <p markdown="1" class="pquote-credit">
+- @shubheksha, [Очень ухабистое путешествие новичка по миру опенсорса](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
   </p>
 </aside>
 
-Прежде чем открывать проблему, запрос на изменение или задавать вопрос в чате, помните об этих моментах, чтобы ваши идеи могли эффективно воплощаться в жизнь.
+Прежде чем открывать ишью, пул-реквест, или задать вопрос в чате, запомните эти советы, которые помогут эффективно реализовать ваши идеи в жизнь.
 
 **Дайте контекст.** Помогите другим быстро освоиться. Если вы столкнулись с ошибкой, объясните, что вы пытаетесь сделать и как ее воспроизвести. Если вы предлагаете новую идею, объясните, почему вы думаете, что она будет полезна для проекта (не только для вас!).
 
@@ -409,126 +410,126 @@ related:
 >
 > 😢 _"X не работает! Исправьте это."_
 
-**Сделайте домашнее задание заранее.** Это нормально не знать что-то, но показать, что вы пробовали. Прежде чем обращаться за помощью, обязательно проверьте README проекта, документацию, проблемы (открытые или закрытые), список рассылки и поищите ответ в Интернете. Люди оценят, когда вы продемонстрируете, что пытаетесь учиться.
+**Попробуйте сначала разобраться сами.** Не знать чего-то — это нормально, но покажите, что вы пробовали разобраться. Прежде чем обращаться за помощью, обязательно изучите README-файл проекта, документацию, ишью (открытые или закрытые), список рассылки и поищите ответ в Интернете. Люди оценят, когда вы продемонстрируете, что попытались что-то узнать.
 
-> 😇 _"Я не знаю, как реализовать X. Я проверил справочную документацию и не нашел никаких упоминаний."_
+> 😇 _"Я не знаю, как реализовать X. Я посмотрел документацию и не нашел никаких упоминаний об этом."_
 >
 > 😢 _"Как мне сделать X?"_
 
-**Делайте запросы краткими и прямыми.** Как и при отправке электронного письма, каждое сообщение, независимо от того, насколько оно простое или полезное, требует чьей-то проверки. Многие проекты имеют больше поступающих запросов, чем людей, готовых помочь. Будьте лаконичны. Вы увеличите шанс того, что кто-то сможет вам помочь.
+**Пишите коротко и по делу.** Как и при отправке электронного письма, каждая сторонняя работа, независимо от того, насколько она была простой или полезной, требует чьей-то проверки. Во многих проектах входящих запросов больше, чем людей, готовых помочь. Будьте лаконичны. Так вы увеличите шанс того, что кто-то сможет вам помочь.
 
 > 😇 _"Я хотел бы написать руководство по API."_
 >
 > 😢 _"На днях я ехал по шоссе и остановился заправиться, и тогда у меня возникла замечательная идея, чем мы должны заняться, но прежде чем я это объясню, позвольте мне показать вам ..."_
 
-**Держите все сообщения общедоступными.** Хотя это заманчиво, не обращайтесь к сопровождающим в частном порядке, если вам не нужно делиться конфиденциальной информацией (например, о проблеме безопасности или серьезном нарушении поведения). Если вы сделаете общение публичным, больше людей смогут узнать о нем и извлечь из него пользу. Обсуждения сами по себе могут быть вкладом.
+**Ведите все обсуждения публично.** Хотя это заманчиво, не обращайтесь к мейнтейнерам напрямую, если вам не нужно делиться конфиденциальной информацией (например, о проблеме безопасности или серьезном нарушении поведения). Если вы сделаете беседу публичной, больше людей смогут узнать о ней и извлечь из неё пользу. Обсуждения сами по себе могут быть вкладом.
 
-> 😇 _(в качестве комментария) «@-сопровождающий Привет! Как нам обработать этот запрос на изменение?»_
+> 😇 _(в качестве комментария) «@-мейнтейнер Привет! Как нам поступить с этим пул-реквестом?»_
 >
 > 😢 _(по электронной почте) «Привет, извини, что побеспокоил тебя по электронной почте, но мне было интересно, была ли у тебя возможность просмотреть мой PR»_
 
-**Можно задавать вопросы (но будьте терпеливы!).** В какой-то момент каждый был новичком в проекте, и даже опытным участникам нужно время освоиться, когда они смотрят на новую задачу. Даже давние сопровождающие не всегда знакомы со всеми частями проекта. Проявите к ним такое же терпение, какое вы бы хотели, чтобы они проявили к вам.
+**Не стесняйтесь задавать вопросы (но будьте терпеливы!).** В какой-то момент каждый был новичком в проекте, и даже опытным контрибьютором нужно время освоиться, когда они приходят в новый проект. Точно так же уже давние мейнтейнеры не всегда знакомы со всеми частями проекта. Проявите к ним такое же терпение, какое вы бы хотели, чтобы они проявили к вам.
 
 > 😇 _"Спасибо, что разобрались с этой ошибкой. Я последовал вашим предложениям. Вот результат."_
 >
 > 😢 _"Почему вы не можете решить мою проблему? Разве это не ваш проект?"_
 
-**Уважайте решения сообщества.** Ваши идеи могут отличаться от приоритетов или видения сообщества. Они могут предложить обратную связь или отказаться от реализации вашей идеи. Хотя вам следует обсуждать и искать компромисс, сопровождающие должны жить с вашим решением дольше, чем вы. Если вы не согласны с их направлением, вы всегда можете работать над собственным ответвлением проекта (fork) или начать собственный проект.
+**Уважайте решения сообщества.** Ваши идеи могут отличаться от приоритетов или видения сообщества. Они могут высказать свои мнения или отказаться от реализации вашей идеи. Хотя всегда нужно обсуждать и искать компромисс, последнее слово за мейнтейнерами, потому что им в дальнейшем предстоит работать с вашим кодом. Если вы не согласны с их направлением, вы всегда можете работать над собственным ответвлением проекта (форком) или начать собственный проект.
 
 > 😇 _"Я разочарован, что вы не можете поддержать мой вариант использования, но, как вы объяснили, он затрагивает только небольшую часть пользователей, я понимаю почему. Спасибо за внимание."_
 >
 > 😢 _"Почему вы не поддерживаете мой вариант использования? Это недопустимо!"_
 
-**Главное, чтобы он был стильным.** Открытый исходный код состоит из соавторов со всего мира. Контекст теряется из-за языков, культур, географических регионов и часовых поясов. Кроме того, письменное общение затрудняет передачу тона или настроения. В этих разговорах предполагайте добрые намерения. Это нормально - вежливо оттолкнуть идею, попросить более подробный контекст или дополнительно прояснить свою позицию. Просто постарайтесь сделать Интернет лучше, чем когда вы его нашли.
+**Главное, держите себя в руках.** Опенсорсом занимаются люди со всего мира. Контекст теряется из-за разных языков, культур, регионов и часовых поясов. Кроме того, письменное общение затрудняет передачу тона или настроения. В таких обсуждениях исходите из благих намерений. Нет ничего плохого в том, чтобы вежливо оттолкнуться от идеи, попросить больше информации или дополнительно прояснить свою позицию. Просто постарайтесь сделать интернет лучше, чем когда вы его нашли.
 
-### Сбор контекста
+### Изучение обстановки
 
-Прежде чем что-либо делать, сделайте быструю проверку, чтобы убедиться, что ваша идея больше нигде не обсуждалась. Просмотрите README проекта, проблемы (открытые и закрытые), список рассылки и Stack Overflow. Вам не нужно тратить часы на все, но быстрый поиск нескольких ключевых слов имеет большое значение.
+Прежде чем что-либо делать, убедитесь, что это больше нигде не обсуждалась. Пройдитесь по README-файлу проекта, ишью (открытые и закрытые), списку рассылки и Stack Overflow. Не тратьте много времени на это, достаточно поискать по нескольким ключевым словам.
 
-Если вы не можете найти свою идею в другом месте, вы готовы к действию. Если проект находится на GitHub, вы, скорее всего, будете общаться, открыв задачу или запрос на изменение:
+Если вы не нашли обсуждение вашей идеи, можно начать действовать. Если проект находится на GitHub, вы, скорее всего, будете общаться, открывая ишью или пул-реквест:
 
-* **Проблемы** похожи на начало разговора или обсуждения
+* **Ишью** отлично подходят, чтобы завести беседу или обсуждение
 * **Запросы на изменение** предназначены для начала работы над решением.
-* **Для легкого общения**, например, уточняющего или практического вопроса, попробуйте задать вопрос в Stack Overflow, IRC, Slack или других каналах чата, если он есть в проекте.
+* **Для легкого общения**, например, уточняющего или практического вопроса, попробуйте задать вопрос в Stack Overflow, IRC, Slack или других чат-каналах, если он есть в проекте
 
-Прежде чем открывать задачу или запрос на изменение (pull request), проверьте документацию проекта (обычно это файл с именем CONTRIBUTING или README), чтобы узнать, нужно ли вам включать что-нибудь конкретное. Например, они могут попросить вас следовать шаблону или потребовать, чтобы вы использовали тесты.
+Прежде чем открывать ишью или пул-реквест, ознакомьтесь с руководством по участию (обычно ему посвящен отдельный файл с именем CONTRIBUTING или соответствующий раздел в файле README), чтобы сделать всё правильно. Например, вас могут попросить представить информацию согласно шаблону или потребовать, чтобы вы написали тесты.
 
-Если вы хотите внести существенный вклад, задайте вопрос, прежде чем работать над ним. Полезно некоторое время понаблюдать за проектом (на GitHub [вы можете нажать «Смотреть»](https://help.github.com/articles/watching-repositories/), чтобы получать уведомления обо всех разговорах) и перейти знакомству с членами сообщества, прежде чем выполнять работу, которую могут не принять.
+Если вы планируете сделать большое изменение, перед этим лучше откройте ишью. Полезно некоторое время понаблюдать за проектом (на GitHub [для этого можно кликнуть по кнопке «Watch»](https://help.github.com/articles/watching-repositories/), чтобы получать уведомления обо всех активностях), а также познакомиться с некоторыми участниками сообщества.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/gaearon?s=180" class = "pquote-avatar" alt = "avatar">
-  Вы научитесь <em>многому</em>, взяв один проект, который вы активно используете, "посмотрев" его на GitHub и прочитав все выпуски и PR.
-<p markdown = "1" class = "pquote-credit">
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
+  Вы многое узнаете <em>многому</em> о проекте, который вы активно используете, если "понаблюдаете" за ним на GitHub и просмотрите все ишью и PR.
+<p markdown="1" class="pquote-credit">
 - @gaearon [о присоединении к проектам](https://twitter.com/dan_abramov/status/819555257055322112)
   </p>
 </aside>
 
-### Открытие проблемы (issue)
+### Открытие ишью
 
-Обычно вам следует открывать проблему в следующих ситуациях:
+Как правило, следует создать ишью чтобы:
 
-* Сообщить об ошибке, которую вы не можете решить самостоятельно
-* Обсудить общую тему или идею (например, сообщество, видение или политику)
-* Предложить новую функцию или другую идею проекта
+* Сообщить об ошибке, которую вы нельзя исправить самостоятельно
+* Обсудить общую тему или идею (например, связанную с сообществом, развитием или политикой проекта)
+* Предложить реализовать новую функциональность или другую идею проекта
 
-Советы по общению по проблемам (issue):
+Советы по общению в ишью:
 
-* **Если вы видите открытую проблему, которую хотите решить,** прокомментируйте проблему, чтобы люди знали, что вы ее решаете. Таким образом, люди с меньшей вероятностью будут дублировать вашу работу.
-* **Если проблема была открыта некоторое время назад,** возможно, что она решается где-то в другом месте или уже решена, поэтому прокомментируйте, чтобы запросить подтверждение перед началом работы.
-* **Если вы открыли вопрос, но позже самостоятельно выяснили ответ,** прокомментируйте проблему, чтобы люди знали, а затем закройте ее. Даже документирование этого результата является вкладом в проект.
+* **Если видите открытую ишью, которую хотите решить** прокомментируйте её, чтобы люди знали, что вы занимаетесь ею. Таким образом, снизится вероятность, что кто-то ещё будет работать над ней.
+* **Если ишью была открыта давно,** возможно, что она рассматривается в другом месте, либо уже решена, поэтому прокомментируйте её, чтобы подтвердить её актуальность.
+* **Если вы открыли ишью, но позже самостоятельно нашли ответ,** прокомментируйте её, чтобы сообщить об этом людям, а затем закройте её. Даже фиксирование такого результата является вкладом в проект.
 
-### Открытие запроса на изменение (pull request)
+### Открытие пул-реквеста
 
-Обычно вы должны открывать запрос на изменение в следующих ситуациях:
+Как правило, следует создать пул-реквест чтобы:
 
-* Отправляйте тривиальные исправления (например, опечатку, неработающую ссылку или очевидную ошибку)
-* Начните работать над тем, что уже было запрошено или что вы уже обсуждали в вопросе (issue)
+* Сделать незначительное исправление (например, исправить опечатку, неработающую ссылку или очевидную ошибку)
+* Начать работать над тем, о чём уже было договорено или что обсуждалось в ишью
 
-Запрос на исправление не обязательно должен представлять законченную работу. Обычно лучше открывать запрос на изменение на раннем этапе, чтобы другие могли наблюдать за вашим прогрессом или оставлять отзывы о нем. Просто отметьте это как "WIP" (Work in Progress) «незавершенное производство» в строке темы. Вы всегда можете добавить больше коммитов позже.
+Пул-реквест не обязательно должен представлять законченную работу. Обычно лучше пул-реквест на раннем этапе, чтобы люди могли наблюдать за вашим прогрессом или оставлять отзывы о нем. Только в названии таком пул-реквесте укажите "WIP" (от англ. Work in Progress — в процессе выполнения). Всегда позже можно отправить дополнительные коммиты.
 
-Если проект находится на GitHub, вот как отправить запрос на перенос:
+Если проект находится на GitHub, выполните следующие шаги, чтобы создать пул-реквест:
 
-* **[Скопируйте репозиторий](https://guides.github.com/activities/forking/)** и клонируйте его локально. Подключите ваш локальный компьютер к исходному «вышестоящему» репозиторию, добавив его как удаленный. Часто вносите изменения из «восходящего потока», чтобы оставаться в курсе последних событий, чтобы при отправке запроса на включение конфликты слияния были менее вероятными. (См. Более подробные инструкции [здесь](https://help.github.com/articles/syncing-a-fork/).)
-* **[Создать ветку](https://guides.github.com/introduction/flow/)** для ваших правок.
-* **Ссылайтесь на любые относящиеся к делу проблемы (issues)** или подтверждающую документацию в своем PR (например, Закрывает #37»).
-* **Включите скриншоты до и после**, если ваши изменения включают различия в HTML/CSS. Перетащите изображения в тело запроса на изменение.
-* **Протестируйте свои изменения!** Запустите свои изменения в сравнении с любыми существующими тестами, если они существуют, и при необходимости создайте новые. Независимо от того, существуют тесты или нет, убедитесь, что ваши изменения не нарушают существующий проект.
-* **Внесите свой вклад в стиль проекта** в меру своих возможностей. Это может означать использование отступов, точек с запятой или комментариев иначе, чем в вашем собственном репозитории, но упрощает для сопровождающего объединение, а другим - для понимания и поддержки в будущем.
+* **[Форкните репозиторий](https://guides.github.com/activities/forking/)** и склонируйте его к себе локально. Затем в этом локальном репозитории добавьте оригинальный (upstream) репозиторий. Почаще загружайте изменения из исходного репозиторий, чтобы ваш локальный репозиторий оставался в актуальном состоянии, — это снизит появление конфликтов при создании пул-реквеста. (См. более подробные инструкции [здесь](https://help.github.com/articles/syncing-a-fork/).)
+* **[Создайте ветку](https://guides.github.com/introduction/flow/)** для ваших правок.
+* **Ссылайтесь на любые относящиеся к делу ишью** или подтверждающую документацию в своем PR (например, «Closes #37»).
+* **Добавьте скриншоты до и после**, если ваши изменения включают затрагивает файлы HTML/CSS. Перетащите изображения в текстовую область пул-реквеста.
+* **Протестируйте свои изменения!** Например, если есть, запустите тесты, и при необходимости напишите новые. Даже если нет тестов, проверьте сами, что после ваших изменений всё работает, как и раньше.
+* **Соблюдайте стиль написания кода проекта** в меру своих возможностей. Это может быть использование отступов, точек с запятой или комментариев иначе, чем вы привыкли, но мейнтейнерам это упросит слияние вашего пул-реквеста, а другим — облегчит понимание и поддержку в будущем.
 
-Если это ваш первый запрос на изменение, ознакомьтесь с [Сделать запрос на извлечение](http://makeapullrequest.com/), который @kentcdodds создал как пошаговое видео-руководство. Вы также можете попрактиковаться в создании запроса на изменение в репозитории [Первые вклады](https://github.com/Roshanjossey/first-contributions), созданном @Roshanjossey.
+Если это ваш первый пул-реквест, ознакомьтесь с сайтом [Make a Pull Request](http://makeapullrequest.com/), которую @kentcdodds сделал в виде пошагового видео-руководства. Вы также можете попрактиковаться в создании пул-реквеста в репозитории [First Contributions](https://github.com/Roshanjossey/first-contributions), созданном @Roshanjossey.
 
-## Что происходит после того, как вы отправите свой вклад
+## Что будет дальше после принятия участия
 
-Вы сделали это! Поздравляем, вы стали участником программы с открытым исходным кодом. Надеемся, это первый из многих.
+Вы сделали это! Поздравляем, вы стали контрибьютором в опенсорс. Надеемся, это будет далеко не первый раз.
 
 После того, как вы отправите вклад, произойдет одно из следующих событий:
 
 ### 😭 Вы не получите ответ.
 
-Надеюсь, вы [проверили проект на наличие признаков активности](#контрольный-список-перед-тем-как-внести-свой-вклад) перед тем, как внести свой вклад. Однако даже в активном проекте возможно, что ваш вклад не получит отклика.
+Предполагаем, вы [проверили проект на наличие признаков активности](#контрольный-список-перед-тем-как-внести-свой-вклад) перед тем, как внести свою лепту. Однако даже в активном проекте возможно, что ваш вклад не получит отклика.
 
-Если вы не получили ответа в течение недели, будет справедливо вежливо ответить в той же теме и попросить кого-нибудь дать отзыв. Если вы знаете имя человека, который рассмотрит ваш вклад, вы можете @-упомянуть его в этой ветке.
+Если вы не получили ответа в течение недели, вполне нормально вежливо ответить в той же теме и попросить кого-нибудь проверить вашу работу. Если вы знаете, кто может посмотреть ваш пул-реквест, упомяните его через @ в этой ветке.
 
-**Не** обращайтесь к этому человеку в частном порядке; помните, что публичное общение жизненно важно для проектов с открытым исходным кодом.
+**Не** обращайтесь напрямую к этому человеку; помните, что публичное общение жизненно важно для опенсорс-проектов.
 
-Если вы сделаете вежливое напоминание, но никто не ответит, возможно, что никто и никогда не ответит. Это не самое приятное чувство, но пусть это вас не расстраивает. Это случилось со всеми! Существует множество возможных причин, по которым вы не получили ответа, в том числе личные обстоятельства, которые вы не можете контролировать. Попробуйте найти другой проект или способ внести свой вклад. Во всяком случае, это хорошая причина не тратить слишком много времени на внесение вклада, прежде чем другие члены сообщества будут вовлечены и откликнутся.
+Если после вежливого напоминания, так и никто не ответил, есть вероятность, что никто и никогда не ответит. Это не самое приятное ощущение, но пусть оно вас не расстраивает. Такое с каждым случалось! Есть множество возможных причин, по которым вам не ответили, в том числе личные обстоятельства, на которые вы можете повлиять. Попробуйте найти другой проект или способ участия. Во всяком случае, нет больше смысла вкладываться в такие проекты, по крайней мере до того момента, когда объявляться другие члены сообщества.
 
-### 🚧 Кто-то просит изменить ваш вклад.
+### 🚧 У вас могут запросить внести изменения.
 
-Часто вас просят внести изменения в свой вклад, будь то отзывы о масштабах вашей идеи или изменения в вашем коде.
+Зачастую вас могут попросить что-то изменить, это может быть связано с самой идеей или её реализацией.
 
-Когда кто-то просит изменений, будьте отзывчивы. Они нашли время, чтобы проанализировать ваш вклад. Открывать PR и уходить - дурной тон. Если вы не знаете, как внести изменения, изучите проблему, а затем обратитесь за помощью, если она вам понадобится.
+Когда кто-то запрашивает сделать изменения, относитесь к этому с пониманием и воспринимайте это должным образом. Люди нашли время, чтобы оценить ваш вклад. Открывать PR и бросать его на произвол судьбы — дурной тон. Если вы не знаете, как внести изменения, изучите проблему, а затем обратитесь за помощью, если она вам нужна.
 
-Если у вас больше нет времени работать над проблемой (например, если разговор продолжается в течение нескольких месяцев и ваши обстоятельства изменились), сообщите об этом специалисту по сопровождению, чтобы он не ожидал ответа. Кто-то другой может быть счастлив взять на себя управление.
+Если у вас больше нет времени работать над проблемой (например, обсуждение длится уже несколько месяцев, а за это время обстоятельства поменялись), сообщите об этом мейнтейнеру, чтобы он не ожидал ответа. Возможно кто-то другой с радостью завершит начатую вами работу.
 
 ### 👎 Ваш вклад не принят.
 
-Ваш вклад может быть принят или не принят в конце. Надеюсь, вы уже не вложили в это слишком много усилий. Если вы не уверены, почему он не был принят, вполне разумно попросить разработчика оставить отзыв и разъяснения. В конечном итоге, однако, вам нужно будет уважать, что это их решение. Не спорьте и не становитесь враждебными. Вы всегда можете сделать ответвление (fork) и работать над своей собственной версией, если не согласны!
+В итоге ваш вклад может быть принят или нет. Надеюсь, вы не потратили слишком много усилий на него. Если для вас не было понятно, почему он не был принят, разумно попросить мейнтейнера дать пояснения. В конечном итоге, однако, вам нужно стоит понять и смирится с их решением. Не спорьте и не злитесь по этому поводу. В случае чего вы всегда можете форкнуть репозиторий, чтобы работать над своей собственной версией продукта!
 
 ### 🎉 Ваш вклад принят.
 
-Ура! Вы успешно сделали вклад с открытым исходным кодом!
+Ура! Вы успешно сделали вклад в опенсорс!
 
 ## Вы сделали это!
 
-Независимо от того, сделали ли вы свой первый вклад с открытым исходным кодом или ищете новые способы внести свой вклад, мы надеемся, что вы вдохновитесь на действия. Даже если ваш вклад не был принят, не забудьте сказать спасибо, когда сопровождающий приложит усилия, чтобы вам помочь. Открытый исходный код создается такими же людьми, как вы: одна проблема, запрос на изменение, комментарий или пять за раз.
+Независимо от того, сделали ли вы свой первый вклад в опенсорс или ищете новые способы сделать это, мы надеемся, что вы вдохновитесь на действия. Даже если ваш вклад был отклонён, не забудьте сказать спасибо, когда мейнтейнер постарался вам помочь. Опенсорс создается такими же людьми, которые создают ишью, отправляют пул-реквест, оставляют комментарии или приветствуют друг друга одновременно.

From 5ebad71097bd8938fc2f2d59afad48fb71ba6639 Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Wed, 22 Sep 2021 18:34:21 +0300
Subject: [PATCH 245/749] Fix markup

---
 _articles/ru/how-to-contribute.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index b9db034def4..715ab1d21d3 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -81,9 +81,9 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-Я впервые обратился к команде разработчиков Python (также известной как python-dev), когда 17 июня 2002 года в список рассылки отправил электронное письмо с просьбой принять мой патч. Я быстро заметил баг в коде и решил начать готовить почтовые дайджесты для группы. Это послужило отличным предлогом попросить разъяснений по теме, но, что более важно, я мог заметить, когда кто-то указывал на то, что требовало исправления.
-<p markdown="1" class="pquote-credit">
-— @brettcannon, ["Истории мейнтейнера"](https://github.com/open-source/stories/brettcannon)
+  Я впервые обратился к команде разработчиков Python (также известной как python-dev), когда 17 июня 2002 года в список рассылки отправил электронное письмо с просьбой принять мой патч. Я быстро заметил баг в коде и решил начать готовить почтовые дайджесты для группы. Это послужило отличным предлогом попросить разъяснений по теме, но, что более важно, я мог заметить, когда кто-то указывал на то, что требовало исправления.
+  <p markdown="1" class="pquote-credit">
+  — @brettcannon, ["Истории мейнтейнера"](https://github.com/open-source/stories/brettcannon)
   </p>
 </aside>
 

From c95e46cc809fb149ff1434bf5448de54a4933c10 Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Wed, 22 Sep 2021 18:59:08 +0300
Subject: [PATCH 246/749] Fix links

---
 _articles/ru/building-community.md        | 2 +-
 _articles/ru/how-to-contribute.md         | 8 ++++----
 _articles/ru/leadership-and-governance.md | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/_articles/ru/building-community.md b/_articles/ru/building-community.md
index 80bf767c10f..9a829452ded 100644
--- a/_articles/ru/building-community.md
+++ b/_articles/ru/building-community.md
@@ -38,7 +38,7 @@ related:
 
 * **Когда кто-то новый попадает в ваш проект, поблагодарите его за проявленный интерес!** Достаточно одного негативного опыта, чтобы кто-то не захотел возвращаться.
 * **Будьте отзывчивы.** Если вы не отвечаете на их вопрос в течение месяца, скорее всего, они уже забыли о вашем проекте.
-* **Будьте открыты в отношении помощи, которую вы примете.** Многие участники начинают с отчета об ошибке или небольшого исправления. Есть [много способов внести свой вклад](../how-to-contribute/#что-значит-внести-свой-вклад-to-contribute) в проект. Позвольте людям помочь так, как они хотят помочь.
+* **Будьте открыты в отношении помощи, которую вы примете.** Многие участники начинают с отчета об ошибке или небольшого исправления. Есть [много способов внести свой вклад](../how-to-contribute/#что-значит-внести-свой-вклад) в проект. Позвольте людям помочь так, как они хотят помочь.
 * **Если есть предложение, с которым вы не согласны,** поблагодарите их за идею и [объясните, почему](../best-practices/#учитесь-говорить-нет), это не вписывается в рамки проекта со ссылкой на соответствующую документацию, если она у вас есть.
 
 <aside markdown = "1" class = "pquote">
diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index 715ab1d21d3..12f525aa41b 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -7,7 +7,7 @@ toc:
   зачем-участвовать-в-опенсорс-проектах: 'Зачем участвовать в опенсорс-проектах'
   что-значит-внести-свой-вклад: 'Что значит внести свой вклад'
   подготовка-к-новому-проекту: 'Подготовка к новому проекту'
-  поиск-проекта-в-который-можно-поучаствовать: 'Поиск проекта, в котором можно поучаствовать'
+  поиск-проекта-в-котором-можно-поучаствовать: 'Поиск проекта, в котором можно поучаствовать'
   как-сделать-вклад: 'Как сделать вклад'
   что-будет-дальше-после-принятия-участия: 'Что будет дальше после принятия участия'
 order: 1
@@ -232,11 +232,11 @@ related:
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
-### Контрольный список перед тем, как принять участие
+### Чеклист перед тем, как принять участие
 
 Когда вы нашли проект, в который хотели бы внести свой вклад, бегло осмотритесь проект, чтобы убедиться, что он принимает стороннюю помощь. В противном случае ваш упорный труд может остаться незамеченным.
 
-Вот удобный контрольный список, чтобы понять, подходит ли проект для новых контрибьюторов.
+Вот удобный чеклист список, чтобы понять, подходит ли проект для новых контрибьюторов.
 
 **Попадает под определение опенсорса**
 
@@ -506,7 +506,7 @@ related:
 
 ### 😭 Вы не получите ответ.
 
-Предполагаем, вы [проверили проект на наличие признаков активности](#контрольный-список-перед-тем-как-внести-свой-вклад) перед тем, как внести свою лепту. Однако даже в активном проекте возможно, что ваш вклад не получит отклика.
+Предполагаем, вы [проверили проект на наличие признаков активности](#чеклист-перед-тем-как-принять-участие) перед тем, как внести свою лепту. Однако даже в активном проекте возможно, что ваш вклад не получит отклика.
 
 Если вы не получили ответа в течение недели, вполне нормально вежливо ответить в той же теме и попросить кого-нибудь проверить вашу работу. Если вы знаете, кто может посмотреть ваш пул-реквест, упомяните его через @ в этой ветке.
 
diff --git a/_articles/ru/leadership-and-governance.md b/_articles/ru/leadership-and-governance.md
index 7ae0f6319a8..7a16881e453 100644
--- a/_articles/ru/leadership-and-governance.md
+++ b/_articles/ru/leadership-and-governance.md
@@ -47,7 +47,7 @@ related:
 
 **Термин "правщик"** может быть использован для того, чтобы отличить доступ к правкам, который является особым видом ответственности, от других форм вклада.
 
-Хотя вы можете определять роли в проекте как угодно, [рассмотрите возможность использования более широких определений](../how-to-contribute/#что-значит-внести-свой-вклад-to-contribute), чтобы воодушевить людей на большее количество разновидностей вклада. Вы можете использовать лидерские роли для официального признания людей, которые внесли выдающийся вклад в ваш проект, независимо от их технических навыков.
+Хотя вы можете определять роли в проекте как угодно, [рассмотрите возможность использования более широких определений](../how-to-contribute/#что-значит-внести-свой-вклад), чтобы воодушевить людей на большее количество разновидностей вклада. Вы можете использовать лидерские роли для официального признания людей, которые внесли выдающийся вклад в ваш проект, независимо от их технических навыков.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">

From 86ed05ba455e260a2ac4aa1a37384b2c65d9f73d Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Thu, 23 Sep 2021 19:27:16 +0300
Subject: [PATCH 247/749] Improve Russian translation of "Starting an Open
 Source Project"

---
 _articles/ru/starting-a-project.md | 207 +++++++++++++++--------------
 1 file changed, 104 insertions(+), 103 deletions(-)

diff --git a/_articles/ru/starting-a-project.md b/_articles/ru/starting-a-project.md
index b27533cae6e..9fc60363382 100644
--- a/_articles/ru/starting-a-project.md
+++ b/_articles/ru/starting-a-project.md
@@ -1,14 +1,14 @@
 ---
 lang: ru
-title: Запуск проекта с открытым исходным кодом
-description: Узнайте больше о мире открытого исходного кода и подготовьте к запуску собственный проект.
+title: Запуск опенсорс-проекта
+description: Узнайте подробнее о мире опенсорса и подготовьте к запуску собственный проект.
 class: beginners
 toc:
-  открытый-исходный-код-что-это-и-зачем: 'Что это и зачем - открытый исходный код'
-  стоит-ли-мне-запускать-свой-open-source-проект: 'Стоит ли мне запускать свой проект с открытым исходным кодом?'
-  запуск-собственного-open-source-проекта: 'Запуск собственного проекта с открытым исходным кодом'
-  именование-и-брендирование-вашего-проекта: 'Название и брендинг вашего проекта'
-  проверочный-лист-перед-запуском: 'Ваш контрольный список перед запуском'
+  что-означает-опенсорс: 'Что означает "опенсорс"'
+  стоит-ли-мне-запускать-свой-опенсорс-проект: 'Стоит ли мне запускать свой опенсорс-проект?'
+  запуск-собственного-опенсорс-проекта: 'Запуск собственного опенсорс-проекта'
+  название-и-брендирование-вашего-проекта: 'Название и брендирование вашего проекта'
+  чеклист-перед-запуском: 'Чеклист перед запуском'
 order: 2
 image: /assets/images/cards/beginner.png
 related:
@@ -16,126 +16,126 @@ related:
   - building
 ---
 
-## Открытый исходный код: что это и зачем?
+## Опенсорс — что это и зачем?
 
-Итак, вы думаете о запуске своего проекта с открытым исходным кодом (open source)? Поздравляем! Мир ценит ваш участие. Давайте поговорим о том, что такое open source и почему люди это делают.
+Итак, вы думаете о запуске своего опенсорс-проекта? Поздравляем! Мир ценит ваше участие. Давайте поговорим о том, что такое опенсорс и почему люди им занимаются.
 
-### Что означает "open source"?
+### Что означает "опенсорс"?
 
-Когда код проекта открыт, это означает, что **любой может свободно использовать, изучать, изменять и распространять ваш проект для любых целей.** Эти разрешения даются через [лицензию с открытым исходным кодом](https://opensource.org/licenses).
+Опенсорс-проект означает, что **кто-угодно может свободного его использовать, изучать, изменять и распространять независимо от цели.** Эти разрешения даются через [опенсорс-лицензию](https://opensource.org/licenses).
 
-Преимущество открытого кода в том, что он снижает барьеры для выбора вашей программы и сотрудничества, позволяя людям быстро распространять и улучшать проекты. Кроме того, это дает пользователям возможность контролировать код, в отличии от закрытого. Компания, использующая программное обеспечение (ПО) с открытым исходным кодом, может нанять кого-то для внесения улучшений в ПО, а не полагаться исключительно на решение поставщика с закрытым исходным кодом.
+Преимущество опенсорса в том, что он снижает барьеры для выбора и сотрудничества, позволяя людям быстро распространять и улучшать проекты. Кроме того, по сравнению с закрытым кодом, он дает пользователям возможность контролировать код. Компания, использующая программное обеспечение (ПО) с открытым исходным кодом, может нанять кого-то для доработки этого ПО, а не полагаться исключительно на решение поставщика с закрытым кодом.
 
-_Свободное ПО (Free software)_ ссылается на те же проекты, что и _открытое ПО (open source)_. Иногда вы можете встретить комбинации этих [терминов](https://en.wikipedia.org/wiki/Free_and_open-source_software): "Свободное и открытое ПО" (free and open source software FOSS или free, libre, and open source software FLOSS). Слова free и libre здесь означают "свободное", а не ["бесплатное"](#open-source---значит-бесплатно).
+_Свободное ПО_ относится к тем же проектам, что и _опенсорс_. Иногда вы можете встретить комбинации этих [терминов](https://en.wikipedia.org/wiki/Free_and_open-source_software): "Свободное и открытое ПО" (free and open source software FOSS или free, libre, and open source software FLOSS). Слова free и libre здесь означают "свободное", а не ["бесплатное"](#опенсорс---значит-бесплатно).
 
 ### Почему люди делают свою работу открытой?
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
-  Одно из самых больших вознаграждений, которое я получил от open source - это отношения, установившиеся с другими разработчиками, столкнувшимися с такими же проблемами как и я. 
+  Одним из самых приятных впечатлений, которое я получил от работы над опенсорсом — это отношения, установившиеся с другими разработчиками, столкнувшимися с такими же проблемами как и я. 
   <p markdown="1" class="pquote-credit">
 — @kentcdodds, ["Как мне было здорово войти в Open Source"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
   </p>
 </aside>
 
-[Есть много причин](https://ben.balter.com/2015/11/23/why-open-source/) почему индивид или организация открывают исходники своего проекта. Вот некоторые из них:
+[Есть много причин](https://ben.balter.com/2015/11/23/why-open-source/) почему человек или организация открывают исходники своего проекта. Вот некоторые из них:
 
-* **Сотрудничество:** Open source проект может получать доработки от любого человека из любой страны мира. Например, платформа для упражнений программированию [Exercism](https://github.com/exercism/), делается усилиями 350 авторов.
+* **Сотрудничество:** В опенсорс-проект может внести изменения любой человек, где бы он ни находился. Например, платформа для упражнений по программированию [Exercism](https://github.com/exercism/) насчитывает 350 контрибьюторов.
 
-* **Адаптация и ремиксы:** Open source проект может быть использован кем угодно, почти для чего угодно. Люди могут использовать ваш проект совершенно по-новому. [WordPress](https://github.com/WordPress), например, стартовал как ответвление уже существовавшего проекта [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
+* **Адаптация и доработки:** Опенсорс-проекты могут использоваться кем угодно практически для любой цели. Люди могут использовать ваш проект для создания чего-то нового. [WordPress](https://github.com/WordPress), например, стартовал как форк (ответвление) уже существовавшего проекта [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
 
-* **Прозрачность:** Любой может проверять open source проект на ошибки и несоответствия. Прозрачность важна даже на государственном уровне. Например, правительство [Болгарии](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) и [США](https://sourcecode.cio.gov/) законодательно предписали прозрачность для таких отраслей как: банковское дело, здравоохранение, и ПО безопасности, вроде [Let's Encrypt](https://github.com/letsencrypt).
+* **Прозрачность:** Любой может проверить опенсорс-проект на наличие ошибок и несоответствий. Прозрачность важна даже на государственном уровне. Например, правительство [Болгарии](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) и [США](https://sourcecode.cio.gov/) законодательно предписали прозрачность для таких отраслей как банковское дело, здравоохранение, и программ безопасности, вроде [Let's Encrypt](https://github.com/letsencrypt).
 
-Open source (открытый исходник) применимо не только к ПО, но и ко всему остальному: от наборов данных до книг. В [Обзоре GitHub](https://github.com/explore) вы можете почерпнуть больше идей насчёт того, что можно заопенсорсить.
+Опенсорсом может быть не только ПО, но и многое другое: от наборов данных до книг. В разделе [GitHub Explore](https://github.com/explore) можно ознакомится с идеями проектов, которые можно заопенсорсить.
 
-### Open source - значит бесплатно?
+### Опенсорс — значит бесплатно?
 
-Бесплатность open source - это одно из его самых больших преимуществ, но не единственное, а скорее - побочный продукт его совокупной ценности.
+Бесплатность опенсорс — это одно из самых больших преимуществ, которое скорее является побочным продуктом его совокупной ценности.
 
-Поскольку [открытая лицензия предполагает](https://opensource.org/osd-annotated), что кто угодно может использовать, модифицировать, и распространять ваш проект почти для любых целей, то в большинстве случаев это подразумевает бесплатность. Потому что, если бы вы просили плату, то люди бы скачивали проект и использовали его бесплатно, абсолютно легально.
+Поскольку [опенсорс-лицензия предполагает](https://opensource.org/osd-annotated), что кто угодно может использовать, модифицировать, и распространять ваш проект почти для любых целей, то в большинстве случаев это означает бесплатность. Потому что, если бы проект стоит денег, то любой мог абсолютно легально скопировать его и тем самым использовать его бесплатно.
 
-Поэтому большинство open source проектов бесплатны, но это не входит в определение open source. Существуют способы взимания платы за проекты с открытым исходным кодом косвенно, через двойное лицензирование или ограниченные функции, но при этом они соответствуют официальному определению open source.
+Поэтому большинство опенсорс-проектов бесплатны, хотя это свойство не входит в определение само опенсорса. Есть способы оплаты взимания оплаты за пользование опенсорс-проектов косвенным образом через двойное лицензирование или ограничение функциональности, при этом такие проекты по-прежнему будут соответствовать официальному определению опенсорса.
 
-## Стоит ли мне запускать свой open source проект?
+## Стоит ли мне запускать свой опенсорс-проект?
 
-Краткий ответ - да, потому что независимо от результата, запуск своего проекта - это хороший способ понять, как работает open source.
+Краткий ответ — да, потому что независимо от результата, запуск собстенного проекта — это отличный способ узнать, как работает опенсорс.
 
-Если вы никогда прежде не запускали подобных проектов, вы можете переживать: "что скажут люди?", "а вдруг вообще никто его не заметит?". Если вам это знакомо, не беспокойтесь, вы не один такой!
+Если вы никогда ранее не запускали подобных проектов, вы можете переживать по поводу того, что скажут люди, и заметит ли кто-нибудь его вообще. Если вам знакомо это ощущение, не беспокойтесь, вы не один такой!
 
-Open source, как и любая творческая работа, будь то писательство или рисование, вызывает волнение прежде чем поделиться ей с миром. Но единственный способ улучшить её - практиковаться, даже если у вас не будет аудитории.
+Опенсорс похож на любую другую творческую работу, будь то писательство или рисование. Может быть страшно показывать свою работу всему миру. Но как известно, практика — это путь к совершенству, даже если у вас пока нет своей аудитории.
 
 Если вы ещё не решились, найдите время подумать о ваших возможных целях.
 
 ### Постановка целей
 
-Цели помогут вам определиться, над чем работать, от чего отказаться, и где вам понадобится помощь со стороны. Спросите себя: _"зачем я опенсорсю этот проект?"_.
+Цели помогут вам определиться, над чем работать, от чего отказаться, и где вам понадобится помощь со стороны. Спросите себя: _"зачем мне нужен этот опенсорс-проект?"_.
 
-Единого ответа на этот вопрос не существует. Вы можете иметь много целей для одного проекта, или разные проекты с разными целями.
+Единого ответа на этот вопрос не существует. Может быть сразу несколько целей на один проект, или разные проекты с разными целями.
 
-Если ваша цель просто показать свою работу и нет нужды в сотрудничестве, вы можете так и написать в файле README. С другой стороны, если вы заинтересованы в помощниках, то вам следует вложить своё время в написание понятной документации и проявлять заботу о новичках.
+Если ваша единственная цель — показать свою работу, скорее всего вы не нуждаетесь в сторонней помощи, о чём стоит явно можно указать в файле README. С другой стороны, если вы заинтересованы в помощниках, то следует потратить время на написание понятной документации и проявить заботу о новичках.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
-Однажды я сделал настраиваемый UIAlertView для своих нужд... и решил сделать его open source. Я сделал его более динамичным и загрузил на GitHub. Я так же написал свою первую документацию, объясняющую другим разработчикам, как они могут использовать мою работу в своих проектах. Возможно, ей так никто и не воспользовался из-за её простоты. Но зато я испытал хорошее чувство от всего этого процесса. 
+  Однажды я сделал кастомный UIAlertView для своих нужд... и решил выложить его в опенсорс. Я сделал его более динамическим и опубликовал на GitHub. Я также написал свою первую документацию, объясняющую другим разработчикам, как они могут использовать мою работу в своих проектах. Возможно, ей так никто и не воспользовался из-за её простоты. Но зато получил удовольствие от всего этого процесса. 
   <p markdown="1" class="pquote-credit">
-— @mavris, ["Программисты самоучки: Почему Open Source важен для нас"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+— @mavris, ["Программисты-самоучки: почему опенсорс важен для нас"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
   </p>
 </aside>
 
-По мере роста проекта ваше сообщество будет нуждаться не только в коде. Ответы на вопросы (issues), проверка кода, распространение информации о себе - всё это важные задачи open source проекта.
+По мере роста проекта ваше сообщество будет нуждаться не только в коде. Ответы в ишью, проверка кода и реклама собственного проекта — всё это важные задачи любого опенсорс-проекта.
 
 Хотя количество времени на непрограммистские задачи зависит от размера и масштаба вашего проекта, вы должны быть готовы решать их сами или найти для этого помощника.
 
-**Если вы - часть компании, запускающей open source проект,**, убедитесь заранее, что вы имеете внутренние ресурсы для его развития. Назначьте ответственного за сопровождение после запуска и определите, как будут распределяться задачи внутри сообщества.
+**Если вы работаете в компании, запускающей опенсорс-проект,**, убедитесь заранее, у вас есть внутренние ресурсы для его развития. Вам нужно определить, кто будет отвечать за поддержку проекта после его запуска, и как будете распределять задачи внутри сообщества.
 
-Если вам нужен выделенный бюджет или персонал для продвижения, эксплуатации и поддержки проекта, обговорите это как можно раньше.
+Если вам нужен выделенный бюджет или люди для продвижения, работы и поддержки проекта, обговорите это как можно раньше.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-Когда вы начинаете open source проект, важно, чтобы процессы управления в организации учитывали вклад и возможности сообщества, образовавшегося вокруг проекта. Не бойтесь вовлекать посторонних людей, даже в ключевых аспектах, особенно если они активно участвуют. 
+  Когда вы начинаете опенсорс-проект, важно, чтобы процессы управления в организации учитывали вклад и возможности сообщества, образовавшегося вокруг проекта. Не бойтесь вовлекать посторонних людей в работе над основными аспектами проекта, особенно если они активно участвуют. 
   <p markdown="1" class="pquote-credit">
-— @captainsafia, ["Чё, хочешь открыть код проекта?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+— @captainsafia, ["Хочешь открыть код проекта, не так ли?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
   </p>
 </aside>
 
 ### Участие в чужих проектах
 
-Если ваша цель - понять как взаимодействовать с другими и как работает open source, рассмотрите возможность участия в уже существующем проекте, который вы используете и любите. Вашим участием могут быть такие простые вещи, как исправление опечаток и обновление документации.
+Если ваша цель — понять как взаимодействовать с другими и как работает опенсорс, рассмотрите возможность участия в уже существующем проекте, который вы используете и любите. Вашим участием может быть что-то простое, вроде исправление опечаток и обновление документации.
 
-Если вы не понимаете, как начать участие в чужом проекте, ознакомьтесь с нашим руководством [Как участвовать в open source проекте](../how-to-contribute/).
+Если вы не понимаете, как войти в чужой проект, ознакомьтесь с нашим руководством [Как участвовать в опенсорс-проекте](../how-to-contribute/).
 
-## Запуск собственного open source проекта
+## Запуск собственного опенсорс-проекта
 
 Нет идеального момента, когда нужно открывать исходники своей работы. Вы можете открыть их на стадии идеи, в процессе работы или после нескольких лет закрытости.
 
-В общем случае, открывать исходники можно, когда вы чувствуете себя уверенно настолько, чтобы показать свою работу посторонним людям и получать их отзывы.
+В общем случае, открывать исходники можно, когда вы чувствуете себя уверенно настолько, что посторонние люди будут смотреть вашу работу и высказываться о ней.
 
-Каждый проект вне зависимости от стадии, на которой вы решили открыть исходники, должен иметь следующую документацию:
+В каждом проекте вне зависимости от стадии, на которой вы решили открыть исходники, должна быть следующая документация:
 
-* [Лицензию open source](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)
+* [Опенсорс-лицензию](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/)
-* [Кодекс поведения](../code-of-conduct/)
+* [Нормы поведения](../code-of-conduct/)
 
-Они помогут вам донести ожидания, принимать правки других участников, и защитить законные права всех соавторов, включая себя. Это значительно увеличивает вероятность позитивного опыта.
+Эти файлы помогут вам донести ожидания, определить процесс по участию, и защитить законные права всех, включая вас самих. Всё это значительно увеличивает шансы, что всё пойдёт хорошо.
 
-Если ваш проект на Гитхабе и вы разместите эти файлы в корневой категории с рекомендованными названиями, Гитхаб распознает их и будет автоматически отображать для ваших читателей.
+Если ваш проект на GitHub и вы разместите эти файлы в корневой категории с рекомендованными названиями, GitHub распознает их и автоматически отобразит посетителям репозитория.
 
 ### Выбор лицензии
 
-Лицензия для открытого исходного кода гарантирует, что другие могут использовать, копировать, изменять и вносить правки в ваш проект без каких-либо последствий. Она также защищает вас от неприятных юридических ситуаций. **Вы должны включить лицензию при запуске проекта с открытым исходным кодом.**
+Лицензия для открытого исходного кода гарантирует, что другие могут использовать, копировать, изменять и вносить правки в ваш проект без каких-либо последствий. Она также защищает вас от неприятных юридических ситуаций. **Вы должны добавить лицензию при запуске опенсорс-проекта.**
 
-Юридическая работа - не из легких. Но есть хорошие новости: вы можете скопировать существующую лицензию и разместить её в своём репозитории, за одну минуту защитив ваш тяжелый труд.
+Юридическая работа — не из легких. Но есть хорошие новости: вы можете скопировать существующую лицензию и разместить её в своём репозитории, за одну минуту защитив ваш тяжелый труд.
 
-[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), и [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) - это самые популярные лицензии, но [есть и другие варианты](https://choosealicense.com) для выбора.
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), и [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) — это самые популярные лицензии, но [есть и другие варианты](https://choosealicense.com).
 
-Когда вы создаёте новый проект на Гитхабе, вам дается на выбор несколько лицензий. Выбрав open source лицензию, вы сделаете свой проект * открытым.
+Когда вы создаёте новый проект на GitHub, вам дается на выбор несколько лицензий. Выбрав опенсорс-лицензию, вы сделаете свой проект открытым.
 
 ![Выберете лицензию](/assets/images/starting-a-project/repository-license-picker.png)
 
-Если у вас есть другие вопросы или беспокойства относительно юридических аспектов open source, [мы описали их здесь](../legal/).
+Если у вас есть другие вопросы или беспокойства относительно юридических аспектов опенсорса, [мы описали их здесь](../legal/).
 
-### Составление README
+### Написание README
 
 Файл README ("прочитай меня") не только рассказывает, как использовать ваш проект, но и объясняет, почему он важен, и что пользователи могут с ним делать.
 
@@ -143,34 +143,34 @@ Open source, как и любая творческая работа, будь т
 
 * Что делает этот проект?
 * Чем этот проект полезен?
-* Как я могу начать работать с ним?
-* Где я могу получить помощь, если понадобится?
+* Как начать работать с ним?
+* Где получить помощь, если понадобится?
 
-Вы можете указать в README: как участвовать в вашем проекте, каковы его цели, рассказать о лицензии и авторстве. Если вы не планируете принимать доработки других людей, или он ещё не готов для запуска - так и напишите об этом.
+Также можно в README можно дать ответы на другие вопросы, например, как поучаствовать в проекте, каковы его цели, а также рассказать о лицензии и авторстве. Если вы не планируете принимать помощь от других людей, или он ещё не готов для запуска — так и напишите об этом.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
-  Хорошая документация - это больше пользователей, меньше просьб о помощи, и больше соавторов. (...) Помните, что ваши пользователи - не вы. Это могут быть люди с опытом - сильно отличным от вашего. 
+  Хорошая документация — это больше пользователей, меньше просьб о помощи, и больше контрибьюторов. (...) Помните, что ваши пользователи — это не вы. Это могут быть люди с опытом, совершенно отличающийся от вашего. 
   <p markdown="1" class="pquote-credit">
 — @tracymakes, ["Писать так, чтобы ваши слова читали (видео)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
   </p>
 </aside>
 
-Иногда люди откладывают написание README, потому что чувствуют, что проект не завершен, или не хотят принимать доработки других людей. Но это как раз хороший повод написать об этом.
+Иногда люди откладывают написание README, потому что чувствуют, что проект не завершен, или не хотят, чтобы другие в нём участвовали. Но это как раз хороший повод написать об этом.
 
-Для вдохновения, можете почитать @dguo's ["Сделай README" - руководство](https://www.makeareadme.com/) или @PurpleBooth's [Шаблон README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2).
+Для вдохновения, можете ознакомиться с [руководством "Сделай README"](https://www.makeareadme.com/) от @dguo или взять на вооружение [Шаблон README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) от @PurpleBooth.
 
-Когда вы добавляете файл README в корневую директорию проекта, Гитхаб автоматически отображает его на главной странице репозитория.
+Если вы добавите файл README в корневую директорию проекта, GitHub автоматически заметит его и покажет на главной странице репозитория.
 
 ### Написание руководства для участников
 
 Файл CONTRIBUTING говорит вашей аудитории, как стать участником вашего проекта. Например:
 
-* Как сообщить об ошибке (попробуйте использовать [шаблоны для issue и pull request](https://github.com/blog/2111-issue-and-pull-request-templates))
-* Как предложить новую функцию
+* Как сообщить об ошибке (попробуйте использовать [шаблоны для ишью и пул-реквестов](https://github.com/blog/2111-issue-and-pull-request-templates))
+* Как предложить реализацию новой функциональности
 * Как настроить среду выполнения и запустить тесты
 
-Помимо технических деталей, файл CONTRIBUTING - хорошее место, чтобы изложить свои ожидания относительно участия других людей. Например:
+Помимо технических деталей, в файле CONTRIBUTING только приветствуется изложить свои ожидания относительно участия других людей. Например:
 
 * Какого рода участие вы ждёте?
 * Ваши планы и видение развития проекта
@@ -182,92 +182,93 @@ Open source, как и любая творческая работа, будь т
 
 > В первую очередь хотим выразить вам благодарность за то, что подумываете об участии в развитии Active Admin. Именно такие люди как вы делают Active Admin прекрасным инструментом.
 
-На ранних стадиях проекта ваш файл CONTRIBUTING может быть простым. Вы всегда должны объяснить как сообщать об ошибках и оформлять вопросы, а так же описать технические требования к правкам участников (например, тесты).
+На ранних стадиях проекта ваш файл CONTRIBUTING может быть простым. Вы всегда следует объяснить, как сообщать о багах и оформлять ишью, а также описать технические требования к контрибьюторам (например, написание тестов).
 
 Со временем вы можете дополнить его ответами на часто задаваемые вопросы. Благодаря этому меньше людей будут спрашивать вас об одном и том же снова и снова.
 
-Чтобы вам было проще составить файл CONTRIBUTING, ознакомьтесь с @nayafia's [шаблоном руководства по сотрудничеству](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) или @mozilla's ["Как составить файл CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
+Чтобы вам было проще написать файл 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/), то Гитхаб будет автоматически ссылаться на него, когда кто-то открывает новый вопрос (issue) или добавляет правку в проект (pull request).
+Поставьте ссылку на файл CONTRIBUTING внутри README, так больше людей увидят его. Если вы [разместите файл CONTRIBUTING.md в корне вашего проекта](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), то GitHub автоматически предложит ознакомиться с ним когда кто-то открывает ишью или отправляет пул-реквест.
 
-![руководство по сотрудничеству](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+![Руководство по сотрудничеству](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
-### Разработка кодекса поведения
+### Разработка норм поведения
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
- Все мы сталкивались с неприятными ситуациями, когда хозяин проекта грубо объяснял что-то или пользователи задавали элементарные вопросы. (...) Кодекс поведения становится документом, на который легко ссылаться, и который говорит, что ваша команда очень серьезно относится к конструктивному диалогу. 
+  Все мы сталкивались с неприятными ситуациями, когда хозяин проекта грубо объяснял что-то или пользователи задавали элементарные вопросы. (...) Норм поведения становится документом, на который легко ссылаться, и который говорит, что ваша команда очень серьезно относится к конструктивному диалогу. 
   <p markdown="1" class="pquote-credit">
-— @mlynch, [Делаем open source более счастливым местом](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+— @mlynch, [Делаем опенсорс намного лучше](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
   </p>
 </aside>
 
-В итоге, кодекс поведения задаёт базовые правила поведения для участников вашего проекта. Это особенно важно, если вы запускаете проект для компании или сообщества. Кодекс поведения способствует установлению здорового, конструктивного поведения в сообществе, что снижает стресс для вас, как для ответственного за проект.
+В итоге, нормы поведения определяют базовые правила поведения участников вашего проекта. Это особенно важно, если вы запускаете проект для компании или сообщества. Нормы поведения способствует установлению здорового, конструктивного поведения в сообществе, снижая стресс для вас, как для мейнтейнера проекта.
 
-Подробнее смотрите: [Кодекс поведения - руководство](../code-of-conduct/).
+Подробнее смотрите на странице [Руководство по нормам поведения](../code-of-conduct/).
 
-Помимо описания _каким_ вы хотите видеть поведение участников, кодекс поведения также разъясняет, к кому и когда он применяется, и что будет в случае его нарушения.
+Помимо описания _каким_ вы хотите видеть поведение участников, нормы поведения также разъясняют, к кому и когда они применяется, и что будет в случае их нарушения.
 
-По аналогии с лицензией, вам не обязательно писать кодекс самим, а можно скопировать один из существующих вариантов. [Соглашение участника](https://contributor-covenant.org/) используется в [более 40,000 open source проектах](https://www.contributor-covenant.org/adopters), включая Kubernetes, Rails, и Swift. Какой бы кодекс вы не использовали, вы должны быть готовы применить его при необходимости.
+По аналогии с лицензией, вам не обязательно писать нормы самим, а можно скопировать один из существующих вариантов. [Contributor Covenant](https://contributor-covenant.org/) используется в [более 40.000 опенсорс-проектах](https://www.contributor-covenant.org/adopters), включая Kubernetes, Rails, и Swift. Какие бы нормы вы не выбрали, будьте готовы применить их при необходимости.
 
-Поместите файл CODE_OF_CONDUCT.md в корень вашего проекта, так его будет проще находить и ссылаться на него, например, из README.
+Вставьте текст в файл CODE_OF_CONDUCT.md в корне проекта, так его будет проще находить и ссылаться на него, например, из README.
 
-## Именование и брендирование вашего проекта
+## Название и брендирование вашего проекта
 
-Брендирование - это не только броский логотип и запоминающееся название, но и то, как вы говорите о своём проекте и до кого доходит ваше послание.
+Брендинг — это не только броский логотип и запоминающееся название, но и то, как вы говорите о своём проекте и кому хотите обратиться с ним.
 
 ### Выбор правильного названия
 
-Выберите название, которое легко запомнить и, в идеале, даёт представление о сути проекта. Например:
+Придумайте название, которое легко запоминается и, в идеале, даёт представление о сути проекта. Например:
 
-* [Караул](https://github.com/getsentry/sentry) оповещает о падении приложения.
-* [Дрищ](https://github.com/macournoyer/thin) быстрый и простой веб-сервер на Ruby.
+* [Sentry](https://github.com/getsentry/sentry) (с англ. — караул) — сервис для мониторинга приложения
+* [Thin](https://github.com/macournoyer/thin) (с англ. — худой) — быстрый и простой веб-сервер на Ruby
 
-Если ваш проект - это дополнение к существующему проекту, то используйте его название как префикс, это поможет понять, что делает ваш проект. Например [node-fetch](https://github.com/bitinn/node-fetch) привносит `window.fetch` в Node.js).
+Если вы создаете что-то, опираясь на уже существующий проект, то добавьте его название в виде префикса к своему проекту, — это даст больше деталей о нём. Например [node-fetch](https://github.com/bitinn/node-fetch) реализует `window.fetch` в Node.js.
 
-Выбирайте в пользу понятности. Каламбуры могут быть забавными, но подумайте о людях из других культур или с отличным от вашего опытом, которые могут не понять шутку. Ваши потенциальные пользователи могут быть работниками компаний, которые будут рассказывать о вашем проекте начальству. Не заставляйте их краснеть при этом.
+Выбирайте понятное название проекта прежде всего. Каламбуры могут быть забавными, но подумайте о людях из других культур или опытом, которые могут не понять шутку. Ваши потенциальные пользователи могут быть работниками компаний, которые будут рассказывать о проекте на работе. Не заставляйте их краснеть при этом!
 
 ### Конфликт имён
 
-[Проверьте наличие open source проектов с таким же названием](http://ivantomic.com/projects/ospnc/), особенно если вы используете один и тот же язык или экосистему. Если ваше название совпадёт с популярным существующим проектом, вы можете запутать свою аудиторию.
+[Проверьте наличие опенсорс-проектов с таким же названием](http://ivantomic.com/projects/ospnc/), особенно если вы используете один и тот же язык или экосистему. Если ваше название совпадёт с популярным существующим проектом, вы можете запутать свою аудиторию.
 
-Если вы планируете завести сайт, твиттер или любую площадку для публикаций, убедитесь, что нужное вам название там свободно. И лучше [зарезервируйте эти имена сейчас](https://instantdomainsearch.com/) для душевного спокойствия, даже если пока не планируете ими пользоваться.
+Если вы планируете завести сайт, твиттер или любую площадку для публикаций, убедитесь, что нужное вам название там свободно. Лучше всего [зарегистрируйте все аккаунты сейчас](https://instantdomainsearch.com/), хотя просто для душевного спокойствия, даже если пока не планируете ими пользоваться.
 
-Убедитесь, что вы не посягаете на торговую марку какой-нибудь компании. В будущем она сможет попросить вас закрыть проект или даже подать в суд. Это неоправданный риск.
+Убедитесь, что вы не посягаете на торговую марку какой-нибудь компании. В будущем она сможет попросить вас закрыть проект или даже подать в суд на вас. Это неоправданный риск.
 
-Вы можете проверить конфликт брендов по [всемирной базе брендов WIPO](http://www.wipo.int/branddb/en/). Если вы делаете проект от лица компании, то [юридический отдел может помочь вам с этим](../legal/).
+Проверьте имя во [всемирной базе брендов WIPO](http://www.wipo.int/branddb/en/), чтобы избежать конфликта по поводу авторских прав. Если вы делаете проект от лица компании, то [юридический отдел может помочь вам с этим](../legal/).
 
-Напоследок, сделайте быстрый поиск в Google по названию вашего проекта. Смогут ли люди по нему легко найти ваш проект? А может быть, по этому запросу появляется что-то нежелательное?
+Напоследок, выполнит быстрый поиск в Google по названию вашего проекта. Смогут ли люди по нему легко найти ваш проект? А может быть, по этому запросу появляется что-то нежелательное?
 
 ### То, как вы пишите (и кодите) тоже влияет на ваш бренд!
 
 За всю жизнь проекта вы будете много писать: README, руководства, документы сообщества, ответы на вопросы, возможно даже информационные бюллетени и списки рассылки.
 
-Будь то официальная документация или обычное сообщение, ваш стиль письма - это часть бренда проекта. Подумайте о том, в каком свете вы выглядите перед аудиторией, и правильный ли подобрали тон.
+Будь то официальная документация или обычное сообщение, стиль письма также является частью бренда проекта. Подумайте о том, в каком свете вы выглядите перед аудиторией, и правильный ли подобрали тон.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-Я старался участвовать в каждой теме в списке рассылки и показывать образцовое поведение, быть доброжелательным к людям, серьезно относиться к их проблемам и быть полезным в общем. Через некоторое время люди стали не только задавать вопросы, но и помогать с ответами, и, к моему полному восторгу, они подражали моему стилю.
+  Я старался участвовать в каждой теме в списке рассылки и показывать образцовое поведение, быть доброжелательным к людям, серьезно относиться к их проблемам и быть полезным в общем. Через некоторое время люди стали не только задавать вопросы, но и помогать с ответами, и, к моему полному восторгу, они подражали моему стилю.
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl в [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
-Добрый и вежливый язык создаст приятную атмосферу для новых участников. Следите так же за простотой изложения, так как для многих читателей английский может быть не родным.
 
-Не только слова, что вы пишете, но и стиль кода может стать частью бренда вашего проекта. [Angular](https://angular.io/guide/styleguide) и [jQuery](https://contribute.jquery.org/style-guide/js/) два примера проектов со строгими стилями и рекомендациями.
+Добрый и вежливый тон создаст приятную атмосферу для новых участников. Следите так же за простотой изложения, так как для многих читателей английский может быть не родным.
 
-Нет необходимости составлять руководство по стилю, когда вы только начинаете, и в любом случае вы наверняка захотите включать в свой проект разные стили. Но вы должны заранее понимать, что ваш стиль письма и кода будет привлекать одних людей и отталкивать других. Ранние стадии проекта - это возможность создать прецедент, из которого будет расти проект в желаемом для вас виде.
+Не только слова, что вы пишете, но и стиль кода может стать частью бренда вашего проекта. [Angular](https://angular.io/guide/styleguide) и [jQuery](https://contribute.jquery.org/style-guide/js/) — только два примера проектов со строгими стилями написания кода и рекомендациями.
 
-## Проверочный лист перед запуском
+Нет необходимости составлять руководство по стилю, когда вы только начинаете, возможно вам понравится совмещать в своём проекте разные стили. Но стоит заранее предвидеть, что стиль написания и кода может как привлекать, так и отталкивать людей. На ранних стадиях проекта формируется то, каким в дальнейшем станет ваш проект, и зависит от вас, каким вы хотите его видеть.
 
-Вы готовы открыть свой проект? Вот вам проверочный лист в помощь. Когда отметите все пункты, [нажмите "опубликовать"](https://help.github.com/articles/making-a-private-repository-public/) и похвалите себя.
+## Чеклист перед запуском
+
+Вы готовы открыть свой проект? Вот вам проверочный лист в помощь. Когда отметите все пункты, [откройте ваш проект](https://help.github.com/articles/making-a-private-repository-public/) и похвалите себя.
 
 **Документация**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-    В проекте есть файл LICENSE с лицензией open source 
+    В проекте есть файл LICENSE с опенсорс-лицензией 
   </label>
 </div>
 
@@ -288,7 +289,7 @@ Open source, как и любая творческая работа, будь т
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-  Список задач (issues) актуальный, хорошо организованный и помечен ярлыками
+  Список ишью актуальный, хорошо организован и помечен ярлыками
   </label>
 </div>
 
@@ -297,21 +298,21 @@ Open source, как и любая творческая работа, будь т
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-  Проект использует согласованные договорённости по коду и понятные названия функций/методов/переменных
+  В проекте установлены определённые стили оформления кода и функции/методы/переменны имеют понятные названия
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-  Код понятно комментируется, документируются замыслы и особые случаи. 
+  Код хорошо прокомментирован, документируются замыслы и особые случаи. 
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-  Нигде нет чувствительных данных вроде паролей или другой не публичной информации - в истории ревизий, вопросах (issues) и запросах на правки (pull requests). 
+  В истории коммитов, ишью, пул-реквестах не хранится конфиденциальные данные вроде паролей или другой непубличной информации.
   </label>
 </div>
 
@@ -322,11 +323,11 @@ Open source, как и любая творческая работа, будь т
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-  Вы поговорили с юридическим отделом и/или поняли правила интеллектуальной собственности и политику open source вашей компании (если вы где-то трудоустроены)
+  Вы поговорили с юридическим отделом и/или поняли правила интеллектуальной собственности и политику в отношении опенсорса в вашей компании (если вы где-то трудоустроены)
   </label>
 </div>
 
-Если вы юридическое лицо:
+Если вы компания или организация:
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
@@ -345,7 +346,7 @@ Open source, как и любая творческая работа, будь т
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-  Кто-то назначен ответственным за взаимодействие с сообществом: отвечать на вопросы (issues), проверять запросы на правки (pull requests) и присоединять их к проекту
+  Кто-то назначен ответственным за взаимодействие с сообществом (отвечать в ишью, проверять и принимать пул-реквесты)
   </label>
 </div>
 
@@ -358,4 +359,4 @@ Open source, как и любая творческая работа, будь т
 
 ## Вы сделали это!
 
-Поздравляем с открытием исходников вашего первого проекта! Вне зависимости от результата, работа на виду у людей - это подарок для сообщества. Каждый коммит, комментарий и запрос на правку - это возможность учиться и расти для вас и других.
+Поздравляем с открытием исходников вашего первого проекта! Вне зависимости от результата, работа на виду у людей — это подарок для сообщества. Каждый коммит, комментарий и запрос на правку — это возможность учиться и расти для себя и других.

From 7613d7d80e37076bb95cf22e3604f3e024cbab70 Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Thu, 23 Sep 2021 19:36:33 +0300
Subject: [PATCH 248/749] Replace master branch mentions with main

---
 _articles/de/how-to-contribute.md      | 2 +-
 _articles/how-to-contribute.md         | 2 +-
 _articles/zh-hant/how-to-contribute.md | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/de/how-to-contribute.md b/_articles/de/how-to-contribute.md
index 32345204a77..4b42858fafa 100644
--- a/_articles/de/how-to-contribute.md
+++ b/_articles/de/how-to-contribute.md
@@ -268,7 +268,7 @@ Hier ist eine praktische Checkliste, um zu beurteilen, ob ein Projekt für neue
 
 **Das Projekt nimmt aktiv Beiträge entgegen**
 
-Sehen Sie sich die Commit-Aktivität auf dem Master-Branch an. Auf GitHub können Sie diese Informationen auf der Repository-Hauptsite sehen.
+Sehen Sie sich die Commit-Aktivität auf dem Main Branch an. Auf GitHub können Sie diese Informationen auf der Repository-Hauptsite sehen.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index e0260143094..d74f183bf03 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -249,7 +249,7 @@ Here's a handy checklist to evaluate whether a project is good for new contribut
 
 **Project actively accepts contributions**
 
-Look at the commit activity on the master branch. On GitHub, you can see this information on a repository's homepage.
+Look at the commit activity on the main branch. On GitHub, you can see this information on a repository's homepage.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md
index 490ae36cbe8..26629548e1e 100644
--- a/_articles/zh-hant/how-to-contribute.md
+++ b/_articles/zh-hant/how-to-contribute.md
@@ -237,7 +237,7 @@ redirect_from: /zh-tw/how-to-contribute/
 
 **專案是否積極地接受各方的貢獻**
 
-在 master branch 上看看提交的活躍度。在 GitHub 上託管的開源專案，你可以在專案主頁上看到這些訊息。
+在 main branch 上看看提交的活躍度。在 GitHub 上託管的開源專案，你可以在專案主頁上看到這些訊息。
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">

From 09e97030518ca2ab2b3e115a88d835fa747a02af Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Thu, 23 Sep 2021 19:43:46 +0300
Subject: [PATCH 249/749] Fix links

---
 _articles/ru/building-community.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/ru/building-community.md b/_articles/ru/building-community.md
index 9a829452ded..aa203b46a45 100644
--- a/_articles/ru/building-community.md
+++ b/_articles/ru/building-community.md
@@ -30,7 +30,7 @@ related:
 
 Начните с вашей документации:
 
-* **Облегчите использование вашего проекта для любого желающего.** [Дружественное README](../starting-a-project/#составление-readme) а понятные примеры кода помогут любому, кто прикоснется к вашему проекту, начать работу.
+* **Облегчите использование вашего проекта для любого желающего.** [Дружественное README](../starting-a-project/#написание-readme) а понятные примеры кода помогут любому, кто прикоснется к вашему проекту, начать работу.
 * **Объясните, как участвовать**, используя [руководство для участников](../starting-a-project/#написание-руководства-для-участников) и оперативно отвечая на вопросы (issues).
 * **Хорошие первые вопросы (issues)**: чтобы помочь новым участникам начать работу, явно рассмотрите [ярлыки вопросов, которые достаточно просты для начинающих](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Затем Гитхаб выведет эти вопросы в различных местах платформы, увеличивая полезный вклад и уменьшая трение пользователей, решающих проблемы, которые слишком сложны для их уровня.
 
@@ -213,7 +213,7 @@ related:
 
 ### Относитесь к README как к конституции
 
-Ваш README - это [больше, чем просто набор инструкций](../starting-a-project/#составление-readme). Это также место, где можно поговорить о ваших целях, видении продукта и планах развития. Если люди слишком сосредоточены на обсуждении достоинств той или иной функции, возможно, будет полезно вернуться к README и поговорить о более высоком видении вашего проекта. Сосредоточение внимания на README также обезличивает разговор, поэтому вы можете провести конструктивное обсуждение.
+Ваш README - это [больше, чем просто набор инструкций](../starting-a-project/#написание-readme). Это также место, где можно поговорить о ваших целях, видении продукта и планах развития. Если люди слишком сосредоточены на обсуждении достоинств той или иной функции, возможно, будет полезно вернуться к README и поговорить о более высоком видении вашего проекта. Сосредоточение внимания на README также обезличивает разговор, поэтому вы можете провести конструктивное обсуждение.
 
 ### Сосредоточьтесь на путешествии, а не на пункте назначения
 

From 4dd22dffc4796f794acbd5a77cb70427d44867e2 Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Thu, 23 Sep 2021 19:48:14 +0300
Subject: [PATCH 250/749] Fix link

---
 _articles/ru/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/ru/starting-a-project.md b/_articles/ru/starting-a-project.md
index 9fc60363382..8f73301def6 100644
--- a/_articles/ru/starting-a-project.md
+++ b/_articles/ru/starting-a-project.md
@@ -26,7 +26,7 @@ related:
 
 Преимущество опенсорса в том, что он снижает барьеры для выбора и сотрудничества, позволяя людям быстро распространять и улучшать проекты. Кроме того, по сравнению с закрытым кодом, он дает пользователям возможность контролировать код. Компания, использующая программное обеспечение (ПО) с открытым исходным кодом, может нанять кого-то для доработки этого ПО, а не полагаться исключительно на решение поставщика с закрытым кодом.
 
-_Свободное ПО_ относится к тем же проектам, что и _опенсорс_. Иногда вы можете встретить комбинации этих [терминов](https://en.wikipedia.org/wiki/Free_and_open-source_software): "Свободное и открытое ПО" (free and open source software FOSS или free, libre, and open source software FLOSS). Слова free и libre здесь означают "свободное", а не ["бесплатное"](#опенсорс---значит-бесплатно).
+_Свободное ПО_ относится к тем же проектам, что и _опенсорс_. Иногда вы можете встретить комбинации этих [терминов](https://en.wikipedia.org/wiki/Free_and_open-source_software): "Свободное и открытое ПО" (free and open source software FOSS или free, libre, and open source software FLOSS). Слова free и libre здесь означают "свободное", а не ["бесплатное"](#опенсорс--значит-бесплатно).
 
 ### Почему люди делают свою работу открытой?
 

From f501533b752a9a8740096dfd7127d485263e6529 Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Fri, 24 Sep 2021 17:53:43 +0300
Subject: [PATCH 251/749] Generate TOC automatically

---
 _articles/best-practices.md               |   7 -
 _articles/building-community.md           |   4 -
 _articles/code-of-conduct.md              |   6 -
 _articles/finding-users.md                |   7 -
 _articles/getting-paid.md                 |   5 -
 _articles/how-to-contribute.md            |   7 -
 _articles/leadership-and-governance.md    |   9 --
 _articles/legal.md                        |   8 -
 _articles/metrics.md                      |   6 -
 _articles/ms/building-community.md        |   4 -
 _articles/ms/code-of-conduct.md           |   6 -
 _articles/ms/finding-users.md             |   7 -
 _articles/ms/getting-paid.md              |   5 -
 _articles/ms/how-to-contribute.md         |   7 -
 _articles/ms/leadership-and-governance.md |   9 --
 _articles/ms/legal.md                     |   8 -
 _articles/ms/metrics.md                   |   6 -
 _articles/ms/starting-a-project.md        |   6 -
 _articles/nl/best-practices.md            |   7 -
 _articles/nl/building-community.md        |   4 -
 _articles/nl/code-of-conduct.md           |   6 -
 _articles/nl/finding-users.md             |   7 -
 _articles/nl/getting-paid.md              |   5 -
 _articles/nl/how-to-contribute.md         |   7 -
 _articles/nl/leadership-and-governance.md |   9 --
 _articles/nl/legal.md                     |   8 -
 _articles/nl/metrics.md                   |   6 -
 _articles/nl/starting-a-project.md        |   6 -
 _articles/ro/best-practices.md            |   7 -
 _articles/ro/building-community.md        |   4 -
 _articles/ro/code-of-conduct.md           |   6 -
 _articles/ro/finding-users.md             |   7 -
 _articles/ro/getting-paid.md              |   5 -
 _articles/ro/how-to-contribute.md         |   7 -
 _articles/ro/leadership-and-governance.md |   9 --
 _articles/ro/legal.md                     |   8 -
 _articles/ro/metrics.md                   |   6 -
 _articles/ro/starting-a-project.md        |   6 -
 _articles/ru/best-practices.md            |   7 -
 _articles/ru/building-community.md        |   4 -
 _articles/ru/code-of-conduct.md           |   6 -
 _articles/ru/finding-users.md             |   7 -
 _articles/ru/getting-paid.md              |   5 -
 _articles/ru/how-to-contribute.md         |   7 -
 _articles/ru/leadership-and-governance.md |   9 --
 _articles/ru/legal.md                     |   8 -
 _articles/ru/metrics.md                   |   6 -
 _articles/ru/starting-a-project.md        |   6 -
 _articles/starting-a-project.md           |   6 -
 _articles/tr/best-practices.md            |   7 -
 _articles/tr/building-community.md        |   4 -
 _articles/tr/code-of-conduct.md           |   6 -
 _articles/tr/finding-users.md             |   7 -
 _articles/tr/getting-paid.md              |   5 -
 _articles/tr/how-to-contribute.md         |   7 -
 _articles/tr/leadership-and-governance.md |   9 --
 _articles/tr/legal.md                     |   8 -
 _articles/tr/metrics.md                   |   6 -
 _articles/tr/starting-a-project.md        |   6 -
 _data/fields.yml                          |   3 -
 _includes/toc.html                        | 186 ++++++++++++++++++++++
 _layouts/article.html                     |  10 +-
 docs/translations.md                      |   2 +-
 63 files changed, 188 insertions(+), 396 deletions(-)
 create mode 100644 _includes/toc.html

diff --git a/_articles/best-practices.md b/_articles/best-practices.md
index bb8e694cec3..7d0821e5b17 100644
--- a/_articles/best-practices.md
+++ b/_articles/best-practices.md
@@ -3,13 +3,6 @@ lang: en
 title: Best Practices for Maintainers
 description: Making your life easier as an open source maintainer, from documenting processes to leveraging your community.
 class: best-practices
-toc:
-  what-does-it-mean-to-be-a-maintainer: "What does it mean to be a maintainer?"
-  documenting-your-processes: "Documenting your processes"
-  learning-to-say-no: "Learning to say no"
-  leverage-your-community: "Leverage your community"
-  bring-in-the-robots: "Bring in the robots"
-  its-okay-to-hit-pause: "It’s okay to hit pause"
 order: 5
 image: /assets/images/cards/best-practices.png
 related:
diff --git a/_articles/building-community.md b/_articles/building-community.md
index 241eb1a5956..c71d7356dc6 100644
--- a/_articles/building-community.md
+++ b/_articles/building-community.md
@@ -3,10 +3,6 @@ lang: en
 title: Building Welcoming Communities
 description: Building a community that encourages people to use, contribute to, and evangelize your project.
 class: building
-toc:
-  setting-your-project-up-for-success: "Setting your project up for success"
-  growing-your-community: "Growing your community"
-  resolving-conflicts: "Resolving conflicts"
 order: 4
 image: /assets/images/cards/building.png
 related:
diff --git a/_articles/code-of-conduct.md b/_articles/code-of-conduct.md
index 0d606e8e168..3c3d187ae79 100644
--- a/_articles/code-of-conduct.md
+++ b/_articles/code-of-conduct.md
@@ -3,12 +3,6 @@ lang: en
 title: Your Code of Conduct
 description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct.
 class: coc
-toc:
-  why-do-i-need-a-code-of-conduct: "Why do I need a code of conduct?"
-  establishing-a-code-of-conduct: "Establishing a code of conduct"
-  deciding-how-youll-enforce-your-code-of-conduct: "Deciding how you’ll enforce your code of conduct"
-  enforcing-your-code-of-conduct: "Enforcing your code of conduct"
-  your-responsibilities-as-a-maintainer: "Your responsibilities as a maintainer"
 order: 8
 image: /assets/images/cards/coc.png
 related:
diff --git a/_articles/finding-users.md b/_articles/finding-users.md
index 79ac1bc37f3..969d092df03 100644
--- a/_articles/finding-users.md
+++ b/_articles/finding-users.md
@@ -3,13 +3,6 @@ lang: en
 title: Finding Users for Your Project
 description: Help your open source project grow by getting it in the hands of happy users.
 class: finding
-toc:
-  spreading-the-word: "Spreading the word"
-  figure-out-your-message: "Figure out your message"
-  help-people-find-and-follow-your-project: "Help people find and follow your project"
-  go-where-your-projects-audience-is-online: "Go where your project’s audience is (online)"
-  go-where-your-projects-audience-is-offline: "Go where your project’s audience is (offline)"
-  build-a-reputation: "Build a reputation"
 order: 3
 image: /assets/images/cards/finding.png
 related:
diff --git a/_articles/getting-paid.md b/_articles/getting-paid.md
index 9b80feb12a2..cd865dc9a45 100644
--- a/_articles/getting-paid.md
+++ b/_articles/getting-paid.md
@@ -3,11 +3,6 @@ lang: en
 title: Getting Paid for Open Source Work
 description: Sustain your work in open source by getting financial support for your time or your project.
 class: getting-paid
-toc:
-  why-some-people-seek-financial-support: "Why some people seek financial support"
-  funding-your-own-time: "Funding your own time"
-  finding-funding-for-your-project: "Finding funding for your project"
-  building-a-case-for-financial-support: "Building a case for financial support"
 order: 7
 image: /assets/images/cards/getting-paid.png
 related:
diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index e0260143094..093915507a4 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -3,13 +3,6 @@ lang: en
 title: How to Contribute to Open Source
 description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans.
 class: contribute
-toc:
-  why-contribute-to-open-source: "Why contribute to open source?"
-  what-it-means-to-contribute: "What it means to contribute"
-  orienting-yourself-to-a-new-project: "Orienting yourself to a new project"
-  finding-a-project-to-contribute-to: "Finding a project to contribute to"
-  how-to-submit-a-contribution: "How to submit a contribution"
-  what-happens-after-you-submit-a-contribution: "What happens after you submit a contribution"
 order: 1
 image: /assets/images/cards/contribute.png
 related:
diff --git a/_articles/leadership-and-governance.md b/_articles/leadership-and-governance.md
index b8006c30107..6fd75930d5d 100644
--- a/_articles/leadership-and-governance.md
+++ b/_articles/leadership-and-governance.md
@@ -3,15 +3,6 @@ lang: en
 title: Leadership and Governance
 description: Growing open source projects can benefit from formal rules for making decisions.
 class: leadership
-toc:
-  understanding-governance-for-your-growing-project: "Understanding governance for your growing project"
-  what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?"
-  how-do-i-formalize-these-leadership-roles: "How do I formalize these leadership roles?"
-  when-should-i-give-someone-commit-access: "When should I give someone commit access?"
-  what-are-some-of-the-common-governance-structures-for-open-source-projects: "What are some of the common governance structures for open source projects?"
-  do-i-need-governance-docs-when-i-launch-my-project: "Do I need governance docs when I launch my project?"
-  what-happens-if-corporate-employees-start-submitting-contributions: "What happens if corporate employees start submitting contributions?"
-  do-i-need-a-legal-entity-to-support-my-project: "Do I need a legal entity to support my project?"
 order: 6
 image: /assets/images/cards/leadership.png
 related:
diff --git a/_articles/legal.md b/_articles/legal.md
index ed6cf093fd5..2a5d5ccb982 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -3,14 +3,6 @@ lang: en
 title: The Legal Side of Open Source
 description: Everything you've ever wondered about the legal side of open source, and a few things you didn't.
 class: legal
-toc:
-  why-do-people-care-so-much-about-the-legal-side-of-open-source: "Why do people care so much about the legal side of open source?"
-  are-public-github-projects-open-source: "Are public GitHub projects open source?"
-  just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Just give me the TL;DR on what I need to protect my project"
-  which-open-source-license-is-appropriate-for-my-project: "Which open source license is appropriate for my project?"
-  what-if-i-want-to-change-the-license-of-my-project: "What if I want to change the license of my project?"
-  does-my-project-need-an-additional-contributor-agreement: "Does my project need an additional contributor agreement?"
-  what-does-my-companys-legal-team-need-to-know: "What does my company’s legal team need to know?"
 order: 10
 image: /assets/images/cards/legal.png
 related:
diff --git a/_articles/metrics.md b/_articles/metrics.md
index 080b3eea9d4..5b266ccf8cc 100644
--- a/_articles/metrics.md
+++ b/_articles/metrics.md
@@ -3,12 +3,6 @@ lang: en
 title: Open Source Metrics
 description: Make informed decisions to help your open source project thrive by measuring and tracking its success.
 class: metrics
-toc:
-  why-measure-anything: "Why measure anything?"
-  discovery: "Discovery"
-  usage: "Usage"
-  retention: "Retention"
-  maintainer-activity: "Maintainer activity"
 order: 9
 image: /assets/images/cards/metrics.png
 related:
diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
index 0ec63d1514e..eb6dc37e4ef 100644
--- a/_articles/ms/building-community.md
+++ b/_articles/ms/building-community.md
@@ -3,10 +3,6 @@ lang: ms
 title: Membina Komuniti Sambutan
 description: Membangun komuniti yang mendorong orang untuk menggunakan, menyumbang, dan menginjil projek anda.
 class: building
-toc:
-  setting-your-project-up-for-success: "Menyiapkan projek anda untuk berjaya"
-  growing-your-community: "Memperkembangkan komuniti anda"
-  resolving-conflicts: "Menyelesaikan konflik"
 order: 4
 image: /assets/images/cards/building.png
 related:
diff --git a/_articles/ms/code-of-conduct.md b/_articles/ms/code-of-conduct.md
index d4f1ea0d7ac..80766cbeef3 100644
--- a/_articles/ms/code-of-conduct.md
+++ b/_articles/ms/code-of-conduct.md
@@ -3,12 +3,6 @@ lang: ms
 title: Tatakelakuan Anda
 description: Memudahkan tingkah laku masyarakat yang sihat dan konstruktif dengan menerapkan dan menguatkuasakan tatakelakuan.
 class: coc
-toc:
-  why-do-i-need-a-code-of-conduct: "Mengapa saya memerlukan tatakelakuan?"
-  establishing-a-code-of-conduct: "Menetapkan tatakelakuan"
-  deciding-how-youll-enforce-your-code-of-conduct: "Memutuskan bagaimana anda akan melaksanakan tatakelakuan anda"
-  enforcing-your-code-of-conduct: "Menguatkuasakan tatakelakuan anda"
-  your-responsibilities-as-a-maintainer: "Tanggungjawab anda sebagai penjaga"
 order: 8
 image: /assets/images/cards/coc.png
 related:
diff --git a/_articles/ms/finding-users.md b/_articles/ms/finding-users.md
index 5cdd59c702e..ebfc6ec9040 100644
--- a/_articles/ms/finding-users.md
+++ b/_articles/ms/finding-users.md
@@ -3,13 +3,6 @@ lang: ms
 title: Mencari Pengguna untuk Projek Anda
 description: Bantu projek sumber terbuka anda berkembang dengan mendapatkannya di tangan pengguna yang gembira.
 class: finding
-toc:
-  spreading-the-word: "Menyebarkan berita"
-  figure-out-your-message: "Cari tahu mesej anda"
-  help-people-find-and-follow-your-project: "Bantu orang mencari dan mengikuti projek anda"
-  go-where-your-projects-audience-is-online: "Pergi ke tempat penonton projek anda (dalam talian)"
-  go-where-your-projects-audience-is-offline: "Pergi ke tempat khalayak projek anda (luar talian)"
-  build-a-reputation: "Membina reputasi"
 order: 3
 image: /assets/images/cards/finding.png
 related:
diff --git a/_articles/ms/getting-paid.md b/_articles/ms/getting-paid.md
index 0a501476712..aa74e27d818 100644
--- a/_articles/ms/getting-paid.md
+++ b/_articles/ms/getting-paid.md
@@ -3,11 +3,6 @@ lang: ms
 title: Mendapat Bayaran untuk Kerja Sumber Terbuka
 description: Pertahankan kerja anda dalam sumber terbuka dengan mendapatkan sokongan kewangan untuk masa atau projek anda.
 class: getting-paid
-toc:
-  why-some-people-seek-financial-support: "Mengapa sebilangan orang meminta sokongan kewangan"
-  funding-your-own-time: "Membiayai masa anda sendiri"
-  finding-funding-for-your-project: "Mencari dana untuk projek anda"
-  building-a-case-for-financial-support: "Membina kes untuk sokongan kewangan"
 order: 7
 image: /assets/images/cards/getting-paid.png
 related:
diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
index b50c6906bc5..6e1e863869b 100644
--- a/_articles/ms/how-to-contribute.md
+++ b/_articles/ms/how-to-contribute.md
@@ -3,13 +3,6 @@ lang: ms
 title: Cara Menyumbang kepada Sumber Terbuka
 description: Ingin menyumbang kepada sumber terbuka? Panduan untuk membuat sumbangan sumber terbuka, untuk pertama kali dan untuk veteran.
 class: contribute
-toc:
-  why-contribute-to-open-source: "Mengapa menyumbang kepada sumber terbuka?"
-  what-it-means-to-contribute: "Apa maksudnya menyumbang"
-  orienting-yourself-to-a-new-project: "Mengarahkan diri anda ke projek baru"
-  finding-a-project-to-contribute-to: "Mencari projek untuk disumbangkan"
-  how-to-submit-a-contribution: "Cara menghantar sumbangan"
-  what-happens-after-you-submit-a-contribution: "Apa yang berlaku setelah anda menghantar sumbangan"
 order: 1
 image: /assets/images/cards/contribute.png
 related:
diff --git a/_articles/ms/leadership-and-governance.md b/_articles/ms/leadership-and-governance.md
index 5b5ab1fb9a5..e2eac332dae 100644
--- a/_articles/ms/leadership-and-governance.md
+++ b/_articles/ms/leadership-and-governance.md
@@ -3,15 +3,6 @@ lang: ms
 title: Kepimpinan dan Pemerintahan
 description: Projek sumber terbuka yang berkembang dapat memanfaatkan peraturan formal untuk membuat keputusan.
 class: leadership
-toc:
-  understanding-governance-for-your-growing-project: "Memahami tadbir urus untuk projek anda yang sedang berkembang"
-  what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?"
-  how-do-i-formalize-these-leadership-roles: "Bagaimana saya memformalkan peranan kepemimpinan ini?"
-  when-should-i-give-someone-commit-access: "Bilakah saya harus memberikan akses kepada seseorang?"
-  what-are-some-of-the-common-governance-structures-for-open-source-projects: "Apakah beberapa struktur pemerintahan biasa untuk projek sumber terbuka?"
-  do-i-need-governance-docs-when-i-launch-my-project: "Adakah saya memerlukan dokumen tadbir urus semasa melancarkan projek saya?"
-  what-happens-if-corporate-employees-start-submitting-contributions: "Apa yang berlaku sekiranya pekerja korporat mula menghantar sumbangan?"
-  do-i-need-a-legal-entity-to-support-my-project: "Adakah saya memerlukan entiti undang-undang untuk menyokong projek saya?"
 order: 6
 image: /assets/images/cards/leadership.png
 related:
diff --git a/_articles/ms/legal.md b/_articles/ms/legal.md
index 6ac6d8a0a2a..cf9fba9e94a 100644
--- a/_articles/ms/legal.md
+++ b/_articles/ms/legal.md
@@ -3,14 +3,6 @@ lang: ms
 title: Bahagian Undang-Undang Sumber Terbuka
 description: Semua perkara yang pernah anda terfikir mengenai sisi undang-undang sumber terbuka, dan beberapa perkara yang tidak anda lakukan.
 class: legal
-toc:
-  why-do-people-care-so-much-about-the-legal-side-of-open-source: "Mengapa orang begitu mementingkan sisi undang-undang sumber terbuka?"
-  are-public-github-projects-open-source: "Adakah projek GitHub awam adalah sumber terbuka?"
-  just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Beri saya ringkasan mengenai perkara yang saya perlukan untuk melindungi projek saya"
-  which-open-source-license-is-appropriate-for-my-project: "Lesen sumber terbuka mana yang sesuai untuk projek saya?"
-  what-if-i-want-to-change-the-license-of-my-project: "Bagaimana jika saya mahu menukar lesen projek saya?"
-  does-my-project-need-an-additional-contributor-agreement: "Adakah projek saya memerlukan perjanjian penyumbang tambahan?"
-  what-does-my-companys-legal-team-need-to-know: "Apa yang perlu diketahui oleh pasukan undang-undang syarikat saya?"
 order: 10
 image: /assets/images/cards/legal.png
 related:
diff --git a/_articles/ms/metrics.md b/_articles/ms/metrics.md
index 192aa8441cb..f7ea0bf3b22 100644
--- a/_articles/ms/metrics.md
+++ b/_articles/ms/metrics.md
@@ -3,12 +3,6 @@ lang: ms
 title: Metrik Sumber Terbuka
 description: Buat keputusan yang tepat untuk membantu projek sumber terbuka anda berkembang dengan mengukur dan mengesan kejayaannya.
 class: metrics
-toc:
-  why-measure-anything: "Mengapa mengukur apa-apa?"
-  discovery: "Penemuan"
-  usage: "Penggunaan"
-  retention: "Pengekalan"
-  maintainer-activity: "Aktiviti penyelenggara"
 order: 9
 image: /assets/images/cards/metrics.png
 related:
diff --git a/_articles/ms/starting-a-project.md b/_articles/ms/starting-a-project.md
index 38a3a5e0ab7..0c3209277d4 100644
--- a/_articles/ms/starting-a-project.md
+++ b/_articles/ms/starting-a-project.md
@@ -3,12 +3,6 @@ lang: ms
 title: Memulakan Projek Sumber Terbuka
 description: Ketahui lebih lanjut mengenai dunia sumber terbuka dan bersiap sedia untuk melancarkan projek anda sendiri.
 class: beginners
-toc:
-  the-what-and-why-of-open-source: "Apa dan mengapa sumber terbuka"
-  should-i-launch-my-own-open-source-project: "Sekiranya saya melancarkan projek sumber terbuka saya sendiri?"
-  launching-your-own-open-source-project: "Melancarkan projek sumber terbuka anda sendiri"
-  naming-and-branding-your-project: "Menamakan dan menjenamakan projek anda"
-  your-pre-launch-checklist: "Senarai semak pra-pelancaran anda"
 order: 2
 image: /assets/images/cards/beginner.png
 related:
diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index c583c50dcc4..165e15bff98 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -3,13 +3,6 @@ lang: nl
 title: Tips voor een open source-beheerder
 description: Uw leven gemakkelijker maken als open source-beheerder, van het documenteren van processen tot het benutten van uw gemeenschap.
 class: best-practices
-toc:
-  what-does-it-mean-to-be-a-maintainer: "Wat betekent het om een open source-onderhouder te zijn?"
-  documenting-your-processes: "Documenteren van uw processen"
-  learning-to-say-no: "Nee leren zeggen"
-  leverage-your-community: "Maak gebruik van uw community"
-  bring-in-the-robots: "Breng de robots"
-  its-okay-to-hit-pause: "Het is oké om op pauze te drukken"
 order: 5
 image: /assets/images/cards/best-practices.png
 related:
diff --git a/_articles/nl/building-community.md b/_articles/nl/building-community.md
index a40f0830d2f..f4e5363c56d 100644
--- a/_articles/nl/building-community.md
+++ b/_articles/nl/building-community.md
@@ -3,10 +3,6 @@ lang: nl
 title: Bouwen aan gastvrije gemeenschappen
 description: Een gemeenschap opbouwen die mensen aanmoedigt om uw project te gebruiken, eraan bij te dragen en het te evangeliseren.
 class: building
-toc:
-  setting-your-project-up-for-success: "Uw project opzetten voor succes"
-  growing-your-community: "Je community laten groeien"
-  resolving-conflicts: "Conflicten oplossen"
 order: 4
 image: /assets/images/cards/building.png
 related:
diff --git a/_articles/nl/code-of-conduct.md b/_articles/nl/code-of-conduct.md
index ec41ca22b77..dff390dd81a 100644
--- a/_articles/nl/code-of-conduct.md
+++ b/_articles/nl/code-of-conduct.md
@@ -3,12 +3,6 @@ lang: nl
 title: Uw gedragscode
 description: Faciliteer gezond en constructief gedrag in de gemeenschap door een gedragscode aan te nemen en af te dwingen.
 class: coc
-toc:
-  why-do-i-need-a-code-of-conduct: "Waarom heb ik een gedragscode nodig?"
-  establishing-a-code-of-conduct: "Opstellen van een gedragscode"
-  deciding-how-youll-enforce-your-code-of-conduct: "Beslissen hoe u uw gedragscode handhaaft"
-  enforcing-your-code-of-conduct: "Handhaving van uw gedragscode"
-  your-responsibilities-as-a-maintainer: "Uw verantwoordelijkheden als open source-onderhouder"
 order: 8
 image: /assets/images/cards/coc.png
 related:
diff --git a/_articles/nl/finding-users.md b/_articles/nl/finding-users.md
index 195d1b50e06..c8a2c87201a 100644
--- a/_articles/nl/finding-users.md
+++ b/_articles/nl/finding-users.md
@@ -3,13 +3,6 @@ lang: nl
 title: Gebruikers zoeken voor uw project
 description: Help uw open source-project te groeien door het in handen te krijgen van tevreden gebruikers.
 class: finding
-toc:
-  spreading-the-word: "Het woord verspreiden"
-  figure-out-your-message: "Zoek uit wat je bericht is"
-  help-people-find-and-follow-your-project: "Help mensen uw project te vinden en te volgen"
-  go-where-your-projects-audience-is-online: "Ga waar het publiek van uw project is (online)"
-  go-where-your-projects-audience-is-offline: "Ga waar het publiek van uw project is (offline)"
-  build-a-reputation: "Bouw een reputatie op"
 order: 3
 image: /assets/images/cards/finding.png
 related:
diff --git a/_articles/nl/getting-paid.md b/_articles/nl/getting-paid.md
index 7cc2851eff0..404eac9f95a 100644
--- a/_articles/nl/getting-paid.md
+++ b/_articles/nl/getting-paid.md
@@ -3,11 +3,6 @@ lang: nl
 title: Betaald worden voor open source-werk
 description: Ondersteun uw werk in open source door financiële steun te krijgen voor uw tijd of uw project.
 class: getting-paid
-toc:
-  why-some-people-seek-financial-support: "Waarom sommige mensen financiële steun zoeken"
-  funding-your-own-time: "Je eigen tijd financieren"
-  finding-funding-for-your-project: "Financiering vinden voor uw project"
-  building-a-case-for-financial-support: "Het bouwen van een case voor financiële steun"
 order: 7
 image: /assets/images/cards/getting-paid.png
 related:
diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md
index 9b57e9aefa4..3d06316591b 100644
--- a/_articles/nl/how-to-contribute.md
+++ b/_articles/nl/how-to-contribute.md
@@ -3,13 +3,6 @@ lang: nl
 title: Hoe u kunt bijdragen aan Open Source
 description: Wil je bijdragen aan open source? Een gids voor het maken van open source-bijdragen, voor beginners en veteranen.
 class: contribute
-toc:
-  why-contribute-to-open-source: "Waarom bijdragen aan open source?"
-  what-it-means-to-contribute: "Wat het betekent om bij te dragen"
-  orienting-yourself-to-a-new-project: "Je oriënteren op een nieuw project"
-  finding-a-project-to-contribute-to: "Een project vinden om aan bij te dragen"
-  how-to-submit-a-contribution: "Hoe u een bijdrage kunt indienen"
-  what-happens-after-you-submit-a-contribution: "Wat gebeurt er nadat u een bijdrage heeft ingeleverd?"
 order: 1
 image: /assets/images/cards/contribute.png
 related:
diff --git a/_articles/nl/leadership-and-governance.md b/_articles/nl/leadership-and-governance.md
index cfc12b71160..b73d6926d66 100644
--- a/_articles/nl/leadership-and-governance.md
+++ b/_articles/nl/leadership-and-governance.md
@@ -3,15 +3,6 @@ lang: nl
 title: Leiderschap en bestuur
 description: Groeiende open source-projecten kunnen profiteren van formele regels voor het nemen van beslissingen.
 class: leadership
-toc:
-  understanding-governance-for-your-growing-project: "Inzicht in governance voor uw groeiende project"
-  what-are-examples-of-formal-roles-used-in-open-source-projects: "Wat zijn voorbeelden van formele rollen die worden gebruikt in open source-projecten?"
-  how-do-i-formalize-these-leadership-roles: "Hoe formaliseer ik deze leiderschapsrollen?"
-  when-should-i-give-someone-commit-access: "Wanneer moet ik iemand commit-toegang geven?"
-  what-are-some-of-the-common-governance-structures-for-open-source-projects: "Wat zijn enkele van de algemene bestuursstructuren voor open source-projecten?"
-  do-i-need-governance-docs-when-i-launch-my-project: "Heb ik beheersdocumenten nodig wanneer ik mijn project start?"
-  what-happens-if-corporate-employees-start-submitting-contributions: "Wat gebeurt er als bedrijfsmedewerkers bijdragen beginnen in te dienen?"
-  do-i-need-a-legal-entity-to-support-my-project: "Heb ik een juridische entiteit nodig om mijn project te ondersteunen?"
 order: 6
 image: /assets/images/cards/leadership.png
 related:
diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
index 68c73cf9194..66881b615df 100644
--- a/_articles/nl/legal.md
+++ b/_articles/nl/legal.md
@@ -3,14 +3,6 @@ lang: nl
 title: De juridische kant van open source
 description: Alles wat je je ooit hebt afgevraagd over de juridische kant van open source, en een paar dingen die je niet deed.
 class: legal
-toc:
-  why-do-people-care-so-much-about-the-legal-side-of-open-source: "Waarom geven mensen zoveel om de juridische kant van open source?"
-  are-public-github-projects-open-source: "Zijn openbare GitHub-projecten open source?"
-  just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Geef me gewoon de TL;DR over wat ik nodig heb om mijn project te beschermen"
-  which-open-source-license-is-appropriate-for-my-project: "Welke open source-licentie is geschikt voor mijn project?"
-  what-if-i-want-to-change-the-license-of-my-project: "Wat moet ik doen als ik de licentie van mijn project wil wijzigen?"
-  does-my-project-need-an-additional-contributor-agreement: "Heeft mijn project een aanvullende contribuantenovereenkomst nodig?"
-  what-does-my-companys-legal-team-need-to-know: "Wat moet het juridische team van mijn bedrijf weten?"
 order: 10
 image: /assets/images/cards/legal.png
 related:
diff --git a/_articles/nl/metrics.md b/_articles/nl/metrics.md
index 3a755bff52f..26712b18123 100644
--- a/_articles/nl/metrics.md
+++ b/_articles/nl/metrics.md
@@ -3,12 +3,6 @@ lang: nl
 title: Open source-statistieken
 description: Neem weloverwogen beslissingen om uw open source-project te laten gedijen door het succes ervan te meten en bij te houden.
 class: metrics
-toc:
-  why-measure-anything: "Waarom iets meten?"
-  discovery: "Ontdekking"
-  usage: "Gebruik"
-  retention: "Retention"
-  maintainer-activity: "open source beheerdersactiviteit"
 order: 9
 image: /assets/images/cards/metrics.png
 related:
diff --git a/_articles/nl/starting-a-project.md b/_articles/nl/starting-a-project.md
index 3d76a165378..ec42aa7bd21 100644
--- a/_articles/nl/starting-a-project.md
+++ b/_articles/nl/starting-a-project.md
@@ -3,12 +3,6 @@ lang: nl
 title: Een open source-project starten
 description: Leer meer over de wereld van open source en bereid je voor om je eigen project te lanceren.
 class: beginners
-toc:
-  the-what-and-why-of-open-source: "Het wat en waarom van open source"
-  should-i-launch-my-own-open-source-project: "Moet ik mijn eigen open source-project lanceren?"
-  launching-your-own-open-source-project: "Uw eigen open source-project lanceren"
-  naming-and-branding-your-project: "Geef uw project een naam en branding"
-  your-pre-launch-checklist: "Uw checklist vóór de lancering"
 order: 2
 image: /assets/images/cards/beginner.png
 related:
diff --git a/_articles/ro/best-practices.md b/_articles/ro/best-practices.md
index 97da1e968b6..6673e92d831 100644
--- a/_articles/ro/best-practices.md
+++ b/_articles/ro/best-practices.md
@@ -3,13 +3,6 @@ lang: ro
 title: Cele mai bune practici pentru întreținători
 description: Ușurarea vieții tale în calitate de întreținător open source, de la documentarea proceselor la mobilizarea comunității
 class: best-practices
-toc:
-  what-does-it-mean-to-be-a-maintainer: "Ce înseamnă să fii un întreținător?"
-  documenting-your-processes: "Documentarea proceselor tale"
-  learning-to-say-no: "Învățând să spui „nu”"
-  leverage-your-community: "Mobilizarea comunității tale"
-  bring-in-the-robots: "Cheamă roboții"
-  its-okay-to-hit-pause: "Este OK să apeși pauză"
 order: 5
 image: /assets/images/cards/best-practices.png
 related:
diff --git a/_articles/ro/building-community.md b/_articles/ro/building-community.md
index e62f141234f..5be062cf3ab 100644
--- a/_articles/ro/building-community.md
+++ b/_articles/ro/building-community.md
@@ -3,10 +3,6 @@ lang: ro
 title: Clădirea comunităților primitoare
 description: Construirea unei comunități care încurajează oamenii să folosească, să contribuie la, și să promoveze proiectul tău
 class: building
-toc:
-  setting-your-project-up-for-success: "Configurarea proiectului tău pentru succes"
-  growing-your-community: "Dezvoltarea comunității tale"
-  resolving-conflicts: "Rezolvarea conflictelor"
 order: 4
 image: /assets/images/cards/building.png
 related:
diff --git a/_articles/ro/code-of-conduct.md b/_articles/ro/code-of-conduct.md
index 732f7bf0a4a..87ed2fd92a3 100644
--- a/_articles/ro/code-of-conduct.md
+++ b/_articles/ro/code-of-conduct.md
@@ -3,12 +3,6 @@ lang: ro
 title: Codul tău de conduită
 description: Facilitează comportamente constructive și sănătoase în comunitate prin adoptarea și impunerea unui cod de conduită.
 class: coc
-toc:
-  why-do-i-need-a-code-of-conduct: "De ce am nevoie de un cod de conduită?"
-  establishing-a-code-of-conduct: "Stabilirea unui cod de conduită"
-  deciding-how-youll-enforce-your-code-of-conduct: "Decizând cum îți vei impune codul de conduită"
-  enforcing-your-code-of-conduct: "Impunerea codului tău de conduită"
-  your-responsibilities-as-a-maintainer: "Responsabilitățile tale în calitate de întreținător"
 order: 8
 image: /assets/images/cards/coc.png
 related:
diff --git a/_articles/ro/finding-users.md b/_articles/ro/finding-users.md
index c9173a5268e..45f0aa42697 100644
--- a/_articles/ro/finding-users.md
+++ b/_articles/ro/finding-users.md
@@ -3,13 +3,6 @@ lang: ro
 title: Găsirea de utilizatori pentru proiectul tău
 description: Ajută-ți proiectul cu sursă deschisă să crească punându-l în mâinile utilizatorilor fericiți.
 class: finding
-toc:
-  spreading-the-word: "Răspândirea cuvântului"
-  figure-out-your-message: "Găsește-ți mesajul"
-  help-people-find-and-follow-your-project: "Ajută oamenii să-ți găsească și să-ți urmeze proiectul"
-  go-where-your-projects-audience-is-online: "Mergi acolo unde este audiența proiectului tău (online)"
-  go-where-your-projects-audience-is-offline: "Mergi acolo unde este audiența proiectului tău (offline)"
-  build-a-reputation: "Construiește-ți o reputație"
 order: 3
 image: /assets/images/cards/finding.png
 related:
diff --git a/_articles/ro/getting-paid.md b/_articles/ro/getting-paid.md
index f27918d87b3..0077dae8563 100644
--- a/_articles/ro/getting-paid.md
+++ b/_articles/ro/getting-paid.md
@@ -3,11 +3,6 @@ lang: ro
 title: Cum să fii plătit pentru muncă open source
 description: Susține-ți munca în open source obținând sprijin financiar pentru timpul sau proiectul tău.
 class: getting-paid
-toc:
-  why-some-people-seek-financial-support: "De ce unii oameni caută sprijin financiar"
-  funding-your-own-time: "Finanțarea propriului tău timp"
-  finding-funding-for-your-project: "Găsirea de finanțare pentru proiectul tău"
-  building-a-case-for-financial-support: "Construirea unui caz pentru sprijin financiar"
 order: 7
 image: /assets/images/cards/getting-paid.png
 related:
diff --git a/_articles/ro/how-to-contribute.md b/_articles/ro/how-to-contribute.md
index 27e6ea50206..33c67e44a2b 100644
--- a/_articles/ro/how-to-contribute.md
+++ b/_articles/ro/how-to-contribute.md
@@ -3,13 +3,6 @@ lang: ro
 title: Cum să contribui la open source?
 description: Dorești să contribui la open source? Un ghid pentru facerea de contribuții open source, pentru începători și pentru veterani.
 class: contribute
-toc:
-  why-contribute-to-open-source: "De ce să contribui la open source?"
-  what-it-means-to-contribute: "Ce înseamnă să contribui"
-  orienting-yourself-to-a-new-project: "Orientându-te către un nou proiect"
-  finding-a-project-to-contribute-to: "Găsind un proiect la care să contribui"
-  how-to-submit-a-contribution: "Cum să trimiți o contribuție?"
-  what-happens-after-you-submit-a-contribution: "Ce are loc după ce trimiți o contribuție?"
 order: 1
 image: /assets/images/cards/contribute.png
 related:
diff --git a/_articles/ro/leadership-and-governance.md b/_articles/ro/leadership-and-governance.md
index ddbc06a2d36..418db1f86f8 100644
--- a/_articles/ro/leadership-and-governance.md
+++ b/_articles/ro/leadership-and-governance.md
@@ -3,15 +3,6 @@ lang: ro
 title: Conducere și guvernare
 description: Proiectele în creștere cu sursă deschisă pot beneficia de reguli formale pentru luarea deciziilor.
 class: leadership
-toc:
-  understanding-governance-for-your-growing-project: "Înțelegerea guvernării pentru proiectul tău în creștere"
-  what-are-examples-of-formal-roles-used-in-open-source-projects: "Care sunt exemplele de roluri formale utilizate în proiecte cu sursă deschisă?"
-  how-do-i-formalize-these-leadership-roles: "Cum formalizez aceste roluri de conducere?"
-  when-should-i-give-someone-commit-access: "Când ar trebui să dau cuiva acces de commit?"
-  what-are-some-of-the-common-governance-structures-for-open-source-projects: "Care sunt unele dintre structurile obișnuite de guvernanță pentru proiectele cu sursă deschisă?"
-  do-i-need-governance-docs-when-i-launch-my-project: "Am nevoie de documente de guvernare atunci când lansez proiectul meu?"
-  what-happens-if-corporate-employees-start-submitting-contributions: "Ce se întâmplă dacă angajați din companii încep să trimită contribuții?"
-  do-i-need-a-legal-entity-to-support-my-project: "Am nevoie de o entitate juridică pentru a-mi susține proiectul?"
 order: 6
 image: /assets/images/cards/leadership.png
 related:
diff --git a/_articles/ro/legal.md b/_articles/ro/legal.md
index 4c405604fa2..ecf5a8c2b47 100644
--- a/_articles/ro/legal.md
+++ b/_articles/ro/legal.md
@@ -3,14 +3,6 @@ lang: ro
 title: Latura juridică a open source
 description: Tot ce te-ai întrebat vreodată de latura juridică a open source, și câteva lucruri de care nu te-ai întrebat.
 class: legal
-toc:
-  why-do-people-care-so-much-about-the-legal-side-of-open-source: "De ce oamenilor le pasă atât de mult de partea juridică a open source?"
-  are-public-github-projects-open-source: "Sunt proiectele GitHub publice open source?"
-  just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Doar dă-mi TL;DR-ul a ce-mi trebuie pentru a-mi proteja proiectul."
-  which-open-source-license-is-appropriate-for-my-project: "Ce licență open source este potrivită pentru proiectul meu?"
-  what-if-i-want-to-change-the-license-of-my-project: "Ce se întâmplă dacă vreau să schimb licența proiectului meu?"
-  does-my-project-need-an-additional-contributor-agreement: "Proiectul meu are nevoie de o înțelegere cu contributorii în plus?"
-  what-does-my-companys-legal-team-need-to-know: "Ce trebuie să știe echipa juridică a companiei mele?"
 order: 10
 image: /assets/images/cards/legal.png
 related:
diff --git a/_articles/ro/metrics.md b/_articles/ro/metrics.md
index 6755a3f0765..536645dc2c0 100644
--- a/_articles/ro/metrics.md
+++ b/_articles/ro/metrics.md
@@ -3,12 +3,6 @@ lang: ro
 title: Măsurători Open Source
 description: Ia decizii în cunoștință de cauză pentru a-ți ajuta proiectul cu sursă deschisă să prospere măsurând și urmărindu-i succesul.
 class: metrics
-toc:
-  why-measure-anything: "De ce să măsori totul?"
-  discovery: "Descoperire"
-  usage: "Folosire"
-  retention: "Retenție"
-  maintainer-activity: "Activitatea întreținătorilor"
 order: 9
 image: /assets/images/cards/metrics.png
 related:
diff --git a/_articles/ro/starting-a-project.md b/_articles/ro/starting-a-project.md
index c3060ede64a..4b59148bda0 100644
--- a/_articles/ro/starting-a-project.md
+++ b/_articles/ro/starting-a-project.md
@@ -3,12 +3,6 @@ lang: ro
 title: Pornind un proiect cu sursă deschisă
 description: Învață mai multe despre lumea open source și pregătește-te să-ți lansezi primul proiect.
 class: beginners
-toc:
-  the-what-and-why-of-open-source: "„Care”-urile și „de ce”-urile open source"
-  should-i-launch-my-own-open-source-project: "Ar trebui să-mi lansez propriul meu proiect cu sursă deschisă?"
-  launching-your-own-open-source-project: "Lansându-ți propriul tău proiect cu sursă deschisă"
-  naming-and-branding-your-project: "Numirea și marcarea proiectului tău"
-  your-pre-launch-checklist: "Lista ta de verificări înainte de lansare"
 order: 2
 image: /assets/images/cards/beginner.png
 related:
diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md
index f782436bbca..c10164eeec1 100644
--- a/_articles/ru/best-practices.md
+++ b/_articles/ru/best-practices.md
@@ -3,13 +3,6 @@ lang: ru
 title: Хорошие практики для сопровождающих
 description: Облегчите вашу жизнь в качестве сопровождающего открытого исходного кода, от документирования процессов до использования вашего сообщества.
 class: best-practices
-toc:
-  что-значит-быть-сопровождающим: 'Что значит быть сопровождающим?'
-  документирование-ваших-процессов: 'Документирование ваших процессов'
-  учитесь-говорить-нет: 'Учитесь говорить "нет"'
-  используйте-свое-сообщество: 'Используйте свое сообщество'
-  принесите-роботов: 'Принесите роботов'
-  нажать-паузу---это-нормально: 'Нажать паузу - это нормально'
 order: 5
 image: /assets/images/cards/best-practices.png
 related:
diff --git a/_articles/ru/building-community.md b/_articles/ru/building-community.md
index 9a829452ded..79e10b9895b 100644
--- a/_articles/ru/building-community.md
+++ b/_articles/ru/building-community.md
@@ -3,10 +3,6 @@ lang: ru
 title: Создание дружного сообщества
 description: Создание сообщества, которое побуждает людей использовать ваш проект, вносить свой вклад и пропагандировать его.
 class: building
-toc:
-  настройка-вашего-проекта-на-успех: 'Настройка вашего проекта на успех'
-  развитие-вашего-сообщества: 'Развитие вашего сообщества'
-  разрешение-конфликтов: 'Разрешение конфликтов'
 order: 4
 image: /assets/images/cards/building.png
 related:
diff --git a/_articles/ru/code-of-conduct.md b/_articles/ru/code-of-conduct.md
index 74c127b4686..bbd32c5f52c 100644
--- a/_articles/ru/code-of-conduct.md
+++ b/_articles/ru/code-of-conduct.md
@@ -3,12 +3,6 @@ lang: ru
 title: Ваш кодекс поведения
 description: Содействуйте здоровому и конструктивному поведению в сообществе, приняв и обеспечив соблюдение кодекса поведения.
 class: coc
-toc:
-  зачем-мне-нужен-кодекс-поведения: 'Зачем мне нужен кодекс поведения?'
-  установление-кодекса-поведения: 'Установление кодекса поведения'
-  решите-как-вы-будете-обеспечивать-соблюдение-своего-кодекса-поведения: 'Решите, как вы будете обеспечивать соблюдение своего кодекса поведения'
-  обеспечение-соблюдения-вашего-кодекса-поведения: 'Обеспечение соблюдения вашего кодекса поведения'
-  ваши-обязанности-как-сопровождающего: 'Ваши обязанности как сопровождающего'
 order: 8
 image: /assets/images/cards/coc.png
 related:
diff --git a/_articles/ru/finding-users.md b/_articles/ru/finding-users.md
index 59227e72d99..20f9016eeb6 100644
--- a/_articles/ru/finding-users.md
+++ b/_articles/ru/finding-users.md
@@ -3,13 +3,6 @@ lang: ru
 title: Поиск пользователей для вашего проекта
 description: Помогите своему проекту с открытым исходным кодом расти, передав его в руки счастливых пользователей.
 class: finding
-toc:
-  распространение-информации: 'Распространение информации'
-  разберитесь-в-своем-послании: 'Разберитесь в своем послании'
-  помогите-людям-найти-ваш-проект-и-подписаться-на-него: 'Помогите людям найти ваш проект и подписаться на него'
-  идите-туда-где-аудитория-вашего-проекта-онлайн: 'Идите туда, где аудитория вашего проекта (онлайн)'
-  идите-туда-где-аудитория-вашего-проекта-офлайн: 'Идите туда, где аудитория вашего проекта (офлайн)'
-  создайте-репутацию: 'Создайте репутацию'
 order: 3
 image: /assets/images/cards/finding.png
 related:
diff --git a/_articles/ru/getting-paid.md b/_articles/ru/getting-paid.md
index 81a91459fae..602964b3d40 100644
--- a/_articles/ru/getting-paid.md
+++ b/_articles/ru/getting-paid.md
@@ -3,11 +3,6 @@ lang: ru
 title: Получение денег за работу над открытым кодом
 description: Подкрепите свою работу над открытым кодом, получая финансовую поддержку за ваше время и ваш проект
 class: getting-paid
-toc:
-  почему-некоторые-люди-ищут-финансовую-поддержку: 'Почему некоторые люди ищут финансовую поддержку'
-  финансирование-собственного-времени: 'Вложение собственного времени'
-  поиск-финансирования-для-вашего-проекта: 'Поиск финансирования для вашего проекта'
-  создание-аргументов-в-пользу-финансовой-поддержки: 'Создание причин для финансовой поддержки'
 order: 7
 image: /assets/images/cards/getting-paid.png
 related:
diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index 12f525aa41b..39bac8a96bb 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -3,13 +3,6 @@ lang: ru
 title: Как участвовать в опенсорс-проектах
 description: Хотите внести свой вклад в опенсорс? Руководство по участию для новичков и не только.
 class: contribute
-toc:
-  зачем-участвовать-в-опенсорс-проектах: 'Зачем участвовать в опенсорс-проектах'
-  что-значит-внести-свой-вклад: 'Что значит внести свой вклад'
-  подготовка-к-новому-проекту: 'Подготовка к новому проекту'
-  поиск-проекта-в-котором-можно-поучаствовать: 'Поиск проекта, в котором можно поучаствовать'
-  как-сделать-вклад: 'Как сделать вклад'
-  что-будет-дальше-после-принятия-участия: 'Что будет дальше после принятия участия'
 order: 1
 image: /assets/images/cards/contribute.png
 related:
diff --git a/_articles/ru/leadership-and-governance.md b/_articles/ru/leadership-and-governance.md
index 7a16881e453..c5c59c15f29 100644
--- a/_articles/ru/leadership-and-governance.md
+++ b/_articles/ru/leadership-and-governance.md
@@ -3,15 +3,6 @@ lang: ru
 title: Лидерство и управление
 description: Растущие проекты с открытым исходным кодом могут выиграть от формализации правил принятия решений.
 class: leadership
-toc:
-  понимание-механизмов-управления-вашим-растущим-проектом: Понимание механизмов управления для вашего растущего проекта
-  какие-примеры-формальных-ролей-используются-в-проектах-с-открытым-исходным-кодом: Какие примеры формальных ролей используются в проектах с открытым исходным кодом?
-  как-формализовать-эти-лидерские-роли: Как мне формализовать эти лидерские роли?
-  когда-я-должен-предоставить-кому-то-доступ-на-правки-commit: Когда я должен предоставить кому-то commit доступ?
-  какие-существуют-структуры-управления-для-проектов-с-открытым-исходным-кодом: Каковы некоторые общие структуры управления для проектов с открытым исходным кодом?
-  нужна-ли-мне-документация-по-управлению-когда-я-запускаю-свой-проект: Нужна ли мне документация по управлению, когда я запускаю свой проект?
-  что-если-сотрудники-корпорации-участвуют-в-проекте: Что произойдет, если сотрудники компании начнут делать контрибуции?
-  нужно-ли-мне-юридическое-лицо-для-поддержки-моего-проекта: Нужно ли мне юридическое лицо для поддержки моего проекта?
 order: 6
 image: /assets/images/cards/leadership.png
 related:
diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md
index 037ece916d1..2a5272247ee 100644
--- a/_articles/ru/legal.md
+++ b/_articles/ru/legal.md
@@ -3,14 +3,6 @@ lang: ru
 title: Юридические аспекты открытого программного кода
 description: Все, что вас когда-либо интересовало о правовой стороне открытого исходного кода, и кое-что, чего вы не знали.
 class: legal
-toc:
-  почему-людей-так-волнует-правовая-сторона-открытого-кода: 'Почему людей так волнует юридическая сторона открытого кода?'
-  открыты-ли-общедоступные-проекты-github: 'Являются ли общедоступные проекты GitHub - открытыми?'
-  просто-дайте-мне-чтобытонибыло-что-нужно-для-защиты-моего-проекта: 'Просто дайте мне ЧтоБыТоНиБыло, что нужно для защиты моего проекта'
-  какая-лицензия-с-открытым-исходным-кодом-подходит-для-моего-проекта: 'Какая лицензия с открытым исходным кодом подходит для моего проекта?'
-  что-если-я-хочу-изменить-лицензию-своего-проекта: 'Что, если я захочу изменить лицензию своего проекта?'
-  требуется-ли-для-моего-проекта-дополнительное-соглашение-с-участниками: 'Требуется ли для моего проекта дополнительное соглашение с участниками?'
-  что-нужно-знать-юридическому-отделу-моей-компании: 'Что нужно знать юридическому отделу моей компании?'
 order: 10
 image: /assets/images/cards/legal.png
 related:
diff --git a/_articles/ru/metrics.md b/_articles/ru/metrics.md
index 1e57c2eea00..00e632615ec 100644
--- a/_articles/ru/metrics.md
+++ b/_articles/ru/metrics.md
@@ -3,12 +3,6 @@ lang: ru
 title: Метрики для Open Source
 description: Принимайте обоснованные решения, чтобы помочь вашему проекту с открытым исходным кодом процветать, измеряя и отслеживая его успех.
 class: metrics
-toc:
-  зачем-что-то-измерять: 'Зачем что-то измерять?'
-  обнаруживаемость: 'Обнаруживаемость'
-  использование: 'Использование'
-  удержание: 'Удержание'
-  активность-сопровождающих: 'Активность сопровождающих'
 order: 9
 image: /assets/images/cards/metrics.png
 related:
diff --git a/_articles/ru/starting-a-project.md b/_articles/ru/starting-a-project.md
index b27533cae6e..c1e86973b69 100644
--- a/_articles/ru/starting-a-project.md
+++ b/_articles/ru/starting-a-project.md
@@ -3,12 +3,6 @@ lang: ru
 title: Запуск проекта с открытым исходным кодом
 description: Узнайте больше о мире открытого исходного кода и подготовьте к запуску собственный проект.
 class: beginners
-toc:
-  открытый-исходный-код-что-это-и-зачем: 'Что это и зачем - открытый исходный код'
-  стоит-ли-мне-запускать-свой-open-source-проект: 'Стоит ли мне запускать свой проект с открытым исходным кодом?'
-  запуск-собственного-open-source-проекта: 'Запуск собственного проекта с открытым исходным кодом'
-  именование-и-брендирование-вашего-проекта: 'Название и брендинг вашего проекта'
-  проверочный-лист-перед-запуском: 'Ваш контрольный список перед запуском'
 order: 2
 image: /assets/images/cards/beginner.png
 related:
diff --git a/_articles/starting-a-project.md b/_articles/starting-a-project.md
index 1ace069082f..15b01773ef7 100644
--- a/_articles/starting-a-project.md
+++ b/_articles/starting-a-project.md
@@ -3,12 +3,6 @@ lang: en
 title: Starting an Open Source Project
 description: Learn more about the world of open source and get ready to launch your own project.
 class: beginners
-toc:
-  the-what-and-why-of-open-source: "The what and why of open source"
-  should-i-launch-my-own-open-source-project: "Should I launch my own open source project?"
-  launching-your-own-open-source-project: "Launching your own open source project"
-  naming-and-branding-your-project: "Naming and branding your project"
-  your-pre-launch-checklist: "Your pre-launch checklist"
 order: 2
 image: /assets/images/cards/beginner.png
 related:
diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md
index 3a264e8373a..8df08cf5adc 100644
--- a/_articles/tr/best-practices.md
+++ b/_articles/tr/best-practices.md
@@ -3,13 +3,6 @@ lang: tr
 title: Geliştiriciler İçin Örnek Yöntemler
 description: Belgelendirme işlemlerinden topluluğunuzu güçlendirmeye kadar açık bir kaynak geliştiricisi olarak hayatınızı kolaylaştırın.
 class: best-practices
-toc:
-  what-does-it-mean-to-be-a-maintainer: Geliştirici olmak ne demektir?
-  documenting-your-processes: İşlemlerinizi belgeleme
-  learning-to-say-no: Hayır demeyi öğrenme
-  leverage-your-community: Topluluğunuzdan yararlanma
-  bring-in-the-robots: Robotları kullanın
-  its-okay-to-hit-pause: Duraklatmak sorun değildir
 order: 5
 image: /assets/images/cards/best-practices.png
 related:
diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md
index ca3f25f42bb..1addd0dc400 100644
--- a/_articles/tr/building-community.md
+++ b/_articles/tr/building-community.md
@@ -3,10 +3,6 @@ lang: tr
 title: Misafirperver Topluluklar Oluşturma
 description: İnsanları projenizi kullanmaya, katkıda bulunmaya ve uyarlamaya teşvik eden bir topluluk oluşturmak.
 class: building
-toc:
-  setting-your-project-up-for-success: Projenizi başarı için hazırlamak
-  growing-your-community: Topluluğunuzu büyütmek
-  resolving-conflicts: Çatışmaları çözmek
 order: 4
 image: /assets/images/cards/building.png
 related:
diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md
index 6a55964f5bb..a543e8a20a9 100644
--- a/_articles/tr/code-of-conduct.md
+++ b/_articles/tr/code-of-conduct.md
@@ -3,12 +3,6 @@ lang: tr
 title: Davranış Kurallarınız
 description: Bir davranış kuralını benimseyerek ve uygulayarak sağlıklı ve yapıcı topluluk davranışını kolaylaştırın.
 class: coc
-toc:
-  why-do-i-need-a-code-of-conduct: Neden bir davranış kural listesine ihtiyacım var?
-  establishing-a-code-of-conduct: Davranış kuralları oluşturmak
-  deciding-how-youll-enforce-your-code-of-conduct: Davranış kurallarınızı nasıl uygulayacağınıza karar verme
-  enforcing-your-code-of-conduct: Davranış kurallarınızı uygulama
-  your-responsibilities-as-a-maintainer: Bir koruyucu olarak sorumluluklarınız
 order: 8
 image: "/assets/images/cards/coc.png"
 related:
diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md
index 967bd8c3461..01486a9d4a9 100644
--- a/_articles/tr/finding-users.md
+++ b/_articles/tr/finding-users.md
@@ -3,13 +3,6 @@ lang: tr
 title: Projeniz için Kullanıcı Bulma
 description: Açık kaynaklı projenizin, mutlu kullanıcıların eline geçerek büyümesini sağlayın.
 class: finding
-toc:
-  spreading-the-word: Duyurmak
-  figure-out-your-message: Mesajını ilet
-  help-people-find-and-follow-your-project: İnsanların projenizi bulmasına ve takip etmesine yardımcı olun
-  go-where-your-projects-audience-is-online: Projenizin izleyicisinin (çevrimiçi) olduğu yere gidin
-  go-where-your-projects-audience-is-offline: Projenizin kitlesinin (çevrimdışı) olduğu yere gidin
-  build-a-reputation: Bir itibar oluşturun
 order: 3
 image: "/assets/images/cards/finding.png"
 related:
diff --git a/_articles/tr/getting-paid.md b/_articles/tr/getting-paid.md
index eb0cbd47221..c35fe6d7b34 100644
--- a/_articles/tr/getting-paid.md
+++ b/_articles/tr/getting-paid.md
@@ -3,11 +3,6 @@ lang: tr
 title: Açık Kaynak Çalışmalar İçin Ödeme Alma
 description: Zamanınız veya projeniz için maddi destek alarak açık kaynak çabanızı sürdürün.
 class: getting-paid
-toc:
-  why-some-people-seek-financial-support: Neden bazı insanlar finansal destek ister?
-  funding-your-own-time: Kendi zamanınızı finanse etme
-  finding-funding-for-your-project: Projeniz için finansman bulma
-  building-a-case-for-financial-support: Finansal destek için bir süreç oluşturma
 order: 7
 image: /assets/images/cards/getting-paid.png
 related:
diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md
index 27ca581694b..53044406517 100644
--- a/_articles/tr/how-to-contribute.md
+++ b/_articles/tr/how-to-contribute.md
@@ -3,13 +3,6 @@ lang: tr
 title: Açık Kaynağa Nasıl Katkıda Bulunulur
 description: Açık kaynağa katkıda bulunmak ister misiniz? İlk defa yapacaklar ve tecrübeliler için katkı yapma rehberi.
 class: contribute
-toc:
-  why-contribute-to-open-source: Açık kaynağa neden katkıda bulunmalıyım?
-  what-it-means-to-contribute: Katkıda bulunmak ne demektir?
-  orienting-yourself-to-a-new-project: Kendinizi yeni bir projeye yönlendirmek
-  finding-a-project-to-contribute-to: Katkıda bulunacak bir proje bulma
-  how-to-submit-a-contribution: Katkı nasıl gönderilir?
-  what-happens-after-you-submit-a-contribution: Bir katkı gönderdikten sonra ne olur?
 order: 1
 image: "/assets/images/cards/contribute.png"
 related:
diff --git a/_articles/tr/leadership-and-governance.md b/_articles/tr/leadership-and-governance.md
index 1adb235e572..2644b379a7c 100644
--- a/_articles/tr/leadership-and-governance.md
+++ b/_articles/tr/leadership-and-governance.md
@@ -3,15 +3,6 @@ lang: tr
 title: Liderlik ve Yönetim
 description: Büyüyen açık kaynak projeleri, karar almak için resmi kurallardan yararlanabilir.
 class: leadership
-toc:
-  understanding-governance-for-your-growing-project: Büyüyen projeniz için yönetimi anlama
-  what-are-examples-of-formal-roles-used-in-open-source-projects: Açık kaynak projelerde kullanılan resmi rol türleri nelerdir?
-  how-do-i-formalize-these-leadership-roles: Bu liderlik rollerini nasıl formalize ederim?
-  when-should-i-give-someone-commit-access: Ne zaman birine commit izni vermeliyim?
-  what-are-some-of-the-common-governance-structures-for-open-source-projects: Açık kaynaklı projeler için ortak yönetim yapılarının bazıları nelerdir?
-  do-i-need-governance-docs-when-i-launch-my-project: Projemi başlattığımda yönetim belgelerine ihtiyacım var mı?
-  what-happens-if-corporate-employees-start-submitting-contributions: Şirket çalışanları katkı göndermeye başlarsa ne olur?
-  do-i-need-a-legal-entity-to-support-my-project: Projemi desteklemek için tüzel kişiliğe ihtiyacım var mı?
 order: 6
 image: "/assets/images/cards/leadership.png"
 related:
diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index 4ca577da3f2..1fc8a7718e4 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -3,14 +3,6 @@ lang: tr
 title: Açık Kaynağın Hukuki Tarafı
 description: Açık kaynağın yasal yönü hakkında merak ettiğiniz her şey ve merak etmediğiniz birkaç şey.
 class: legal
-toc:
-  why-do-people-care-so-much-about-the-legal-side-of-open-source: İnsanlar neden açık kaynağın yasal tarafını bu kadar önemsiyorlar?
-  are-public-github-projects-open-source: Açık GitHub projeleri açık kaynak mı?
-  just-give-me-the-tldr-on-what-i-need-to-protect-my-project: Sadece bana projemi korumak için ihtiyacım olan karışık metni verin.
-  which-open-source-license-is-appropriate-for-my-project: Projem için hangi açık kaynak lisansı uygundur?
-  what-if-i-want-to-change-the-license-of-my-project: Projemin lisansını değiştirmek istersem ne olur?
-  does-my-project-need-an-additional-contributor-agreement: Projemin ek bir katkı sözleşmesine ihtiyacı var mı?
-  what-does-my-companys-legal-team-need-to-know: Şirketimin hukuk ekibinin neleri bilmesi gerekiyor?
 order: 10
 image: /assets/images/cards/legal.png
 related:
diff --git a/_articles/tr/metrics.md b/_articles/tr/metrics.md
index e77b511c247..753ff7060fd 100644
--- a/_articles/tr/metrics.md
+++ b/_articles/tr/metrics.md
@@ -3,12 +3,6 @@ lang: tr
 title: Açık Kaynak Ölçümleri
 description: Açık kaynaklı projenizin başarısını ölçüp izleyerek gelişmesine yardımcı olmak için bilinçli kararlar alın.
 class: metrics
-toc:
-  why-measure-anything: Neden her şeyi ölçmeli?
-  discovery: Keşif
-  usage: Kullanım
-  retention: Akılda tutma
-  maintainer-activity: Geliştirici etkinliği
 order: 9
 image: "/assets/images/cards/metrics.png"
 related:
diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index 9d6550a2aaf..1f19b0efcf1 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -3,12 +3,6 @@ lang: tr
 title: Açık Kaynaklı bir Projeye Başlamak
 description: Açık kaynak dünyası hakkında daha fazla bilgi edinin ve kendinizi proje başlatmaya hazırlayın.
 class: beginners
-toc:
-  the-what-and-why-of-open-source: Açık kaynağın nediri ve nedeni
-  should-i-launch-my-own-open-source-project: Kendi açık kaynak projemi başlatmalı mıyım?
-  launching-your-own-open-source-project: Kendi açık kaynak projenizi başlatmak
-  naming-and-branding-your-project: Projenizi isimlendirme ve markalama
-  your-pre-launch-checklist: Lansman öncesi kontrol listeniz
 order: 2
 image: "/assets/images/cards/beginner.png"
 related:
diff --git a/_data/fields.yml b/_data/fields.yml
index 76822144172..89b0d0e539a 100644
--- a/_data/fields.yml
+++ b/_data/fields.yml
@@ -19,9 +19,6 @@ description:
 class:
   type: String
 
-toc:
-  type: Hash
-
 order:
   type: Integer
 
diff --git a/_includes/toc.html b/_includes/toc.html
new file mode 100644
index 00000000000..78aa4ab2a9c
--- /dev/null
+++ b/_includes/toc.html
@@ -0,0 +1,186 @@
+{% capture tocWorkspace %}
+    {% comment %}
+        Copyright (c) 2017 Vladimir "allejo" Jimenez
+
+        Permission is hereby granted, free of charge, to any person
+        obtaining a copy of this software and associated documentation
+        files (the "Software"), to deal in the Software without
+        restriction, including without limitation the rights to use,
+        copy, modify, merge, publish, distribute, sublicense, and/or sell
+        copies of the Software, and to permit persons to whom the
+        Software is furnished to do so, subject to the following
+        conditions:
+
+        The above copyright notice and this permission notice shall be
+        included in all copies or substantial portions of the Software.
+
+        THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+        EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+        OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+        NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+        HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+        WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+        FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+        OTHER DEALINGS IN THE SOFTWARE.
+    {% endcomment %}
+    {% comment %}
+        Version 1.2.0
+          https://github.com/allejo/jekyll-toc
+
+        "...like all things liquid - where there's a will, and ~36 hours to spare, there's usually a/some way" ~jaybe
+
+        Usage:
+            {% include toc.html html=content sanitize=true class="inline_toc" id="my_toc" h_min=2 h_max=3 %}
+
+        Parameters:
+            * html         (string) - the HTML of compiled markdown generated by kramdown in Jekyll
+
+        Optional Parameters:
+            * sanitize      (bool)   : false  - when set to true, the headers will be stripped of any HTML in the TOC
+            * class         (string) :   ''   - a CSS class assigned to the TOC
+            * id            (string) :   ''   - an ID to assigned to the TOC
+            * h_min         (int)    :   1    - the minimum TOC header level to use; any header lower than this value will be ignored
+            * h_max         (int)    :   6    - the maximum TOC header level to use; any header greater than this value will be ignored
+            * ordered       (bool)   : false  - when set to true, an ordered list will be outputted instead of an unordered list
+            * item_class    (string) :   ''   - add custom class(es) for each list item; has support for '%level%' placeholder, which is the current heading level
+            * submenu_class (string) :   ''   - add custom class(es) for each child group of headings; has support for '%level%' placeholder which is the current "submenu" heading level
+            * base_url      (string) :   ''   - add a base url to the TOC links for when your TOC is on another page than the actual content
+            * anchor_class  (string) :   ''   - add custom class(es) for each anchor element
+            * skip_no_ids   (bool)   : false  - skip headers that do not have an `id` attribute
+
+        Output:
+            An ordered or unordered list representing the table of contents of a markdown block. This snippet will only
+            generate the table of contents and will NOT output the markdown given to it
+    {% endcomment %}
+
+    {% capture newline %}
+    {% endcapture %}
+    {% assign newline = newline | rstrip %} <!-- Remove the extra spacing but preserve the newline -->
+
+    {% capture deprecation_warnings %}{% endcapture %}
+
+    {% if include.baseurl %}
+        {% capture deprecation_warnings %}{{ deprecation_warnings }}<!-- jekyll-toc :: "baseurl" has been deprecated, use "base_url" instead -->{{ newline }}{% endcapture %}
+    {% endif %}
+
+    {% if include.skipNoIDs %}
+        {% capture deprecation_warnings %}{{ deprecation_warnings }}<!-- jekyll-toc :: "skipNoIDs" has been deprecated, use "skip_no_ids" instead -->{{ newline }}{% endcapture %}
+    {% endif %}
+
+    {% capture jekyll_toc %}{% endcapture %}
+    {% assign orderedList = include.ordered | default: false %}
+    {% assign baseURL = include.base_url | default: include.baseurl | default: '' %}
+    {% assign skipNoIDs = include.skip_no_ids | default: include.skipNoIDs | default: false %}
+    {% assign minHeader = include.h_min | default: 1 %}
+    {% assign maxHeader = include.h_max | default: 6 %}
+    {% assign nodes = include.html | strip | split: '<h' %}
+
+    {% assign firstHeader = true %}
+    {% assign currLevel = 0 %}
+    {% assign lastLevel = 0 %}
+
+    {% capture listModifier %}{% if orderedList %}ol{% else %}ul{% endif %}{% endcapture %}
+
+    {% for node in nodes %}
+        {% if node == "" %}
+            {% continue %}
+        {% endif %}
+        
+        {% if forloop.last == true %}
+            {% continue %}
+        {% endif %}
+
+        {% assign currLevel = node | replace: '"', '' | slice: 0, 1 | times: 1 %}
+
+        {% if currLevel < minHeader or currLevel > maxHeader %}
+            {% continue %}
+        {% endif %}
+
+        {% assign _workspace = node | split: '</h' %}
+
+        {% assign _idWorkspace = _workspace[0] | split: 'id="' %}
+        {% assign _idWorkspace = _idWorkspace[1] | split: '"' %}
+        {% assign htmlID = _idWorkspace[0] %}
+
+        {% assign _classWorkspace = _workspace[0] | split: 'class="' %}
+        {% assign _classWorkspace = _classWorkspace[1] | split: '"' %}
+        {% assign htmlClass = _classWorkspace[0] %}
+
+        {% if htmlClass contains "no_toc" %}
+            {% continue %}
+        {% endif %}
+
+        {% if firstHeader %}
+            {% assign minHeader = currLevel %}
+        {% endif %}
+
+        {% capture _hAttrToStrip %}{{ _workspace[0] | split: '>' | first }}>{% endcapture %}
+        {% assign header = _workspace[0] | replace: _hAttrToStrip, '' %}
+
+        {% if include.item_class and include.item_class != blank %}
+            {% capture listItemClass %} class="{{ include.item_class | replace: '%level%', currLevel | split: '.' | join: ' ' }}"{% endcapture %}
+        {% endif %}
+
+        {% if include.submenu_class and include.submenu_class != blank %}
+            {% assign subMenuLevel = currLevel | minus: 1 %}
+            {% capture subMenuClass %} class="{{ include.submenu_class | replace: '%level%', subMenuLevel | split: '.' | join: ' ' }}"{% endcapture %}
+        {% endif %}
+
+        {% capture anchorBody %}{% if include.sanitize %}{{ header | strip_html }}{% else %}{{ header }}{% endif %}{% endcapture %}
+
+        {% if htmlID %}
+            {% capture anchorAttributes %} href="{% if baseURL %}{{ baseURL }}{% endif %}#{{ htmlID }}"{% endcapture %}
+
+            {% if include.anchor_class %}
+                {% capture anchorAttributes %}{{ anchorAttributes }} class="{{ include.anchor_class | split: '.' | join: ' ' }}"{% endcapture %}
+            {% endif %}
+
+            {% capture listItem %}<a{{ anchorAttributes }}>{{ anchorBody }}</a>{% endcapture %}
+        {% elsif skipNoIDs == true %}
+            {% continue %}
+        {% else %}
+            {% capture listItem %}{{ anchorBody }}{% endcapture %}
+        {% endif %}
+
+        {% if currLevel > lastLevel %}
+            {% capture jekyll_toc %}{{ jekyll_toc }}<{{ listModifier }}{{ subMenuClass }}>{% endcapture %}
+        {% elsif currLevel < lastLevel %}
+            {% assign repeatCount = lastLevel | minus: currLevel %}
+
+            {% for i in (1..repeatCount) %}
+                {% capture jekyll_toc %}{{ jekyll_toc }}</li></{{ listModifier }}>{% endcapture %}
+            {% endfor %}
+
+            {% capture jekyll_toc %}{{ jekyll_toc }}</li>{% endcapture %}
+        {% else %}
+            {% capture jekyll_toc %}{{ jekyll_toc }}</li>{% endcapture %}
+        {% endif %}
+
+        {% capture jekyll_toc %}{{ jekyll_toc }}<li{{ listItemClass }}>{{ listItem }}{% endcapture %}
+
+        {% assign lastLevel = currLevel %}
+        {% assign firstHeader = false %}
+    {% endfor %}
+
+    {% assign repeatCount = minHeader | minus: 1 %}
+    {% assign repeatCount = lastLevel | minus: repeatCount %}
+    {% for i in (1..repeatCount) %}
+        {% capture jekyll_toc %}{{ jekyll_toc }}</li></{{ listModifier }}>{% endcapture %}
+    {% endfor %}
+
+    {% if jekyll_toc != '' %}
+        {% assign rootAttributes = '' %}
+        {% if include.class and include.class != blank %}
+            {% capture rootAttributes %} class="{{ include.class | split: '.' | join: ' ' }}"{% endcapture %}
+        {% endif %}
+
+        {% if include.id and include.id != blank %}
+            {% capture rootAttributes %}{{ rootAttributes }} id="{{ include.id }}"{% endcapture %}
+        {% endif %}
+
+        {% if rootAttributes %}
+            {% assign nodes = jekyll_toc | split: '>' %}
+            {% capture jekyll_toc %}<{{ listModifier }}{{ rootAttributes }}>{{ nodes | shift | join: '>' }}>{% endcapture %}
+        {% endif %}
+    {% endif %}
+{% endcapture %}{% assign tocWorkspace = '' %}{{ deprecation_warnings }}{{ jekyll_toc -}}
diff --git a/_layouts/article.html b/_layouts/article.html
index 4a01b1f5a4c..63a966170b5 100644
--- a/_layouts/article.html
+++ b/_layouts/article.html
@@ -9,22 +9,14 @@
 
     <h1 class="h0-mktg lh-condensed text-center mb-3">{{ page.title }}</h1>
     <p class="lead text-center text-gray col-md-8 mx-auto mb-4 position-relative">{{ page.description }}</p>
-    {% if page.lang == "en" or page.lang == "ru" %}
     <nav class="toc mb-4 mb-md-6">
       <div class="Box col-sm-8 col-md-4 col-lg-3 mx-auto">
         <a class="toc-trigger d-block text-center p-3">
           <span class="text-black">{{ t.article.table_of_contents }}</span><svg height="18" class="octicon octicon-triangle-down ml-2 fill-blue v-align-middle icon-flip" viewBox="0 0 12 16" version="1.1" width="13" role="img"><path fill-rule="evenodd" d="M0 5l6 6 6-6z"></path></svg>
         </a>
-        <ol class="toc-list list-style-none">
-          {% for section in page.toc %}
-          <li class="border-top">
-            <a href="#{{ section[0] }}" class="d-block py-3 px-3">{{ section[1] }}</a>
-          </li>
-          {% endfor %}
-        </ol>
+        {% include toc.html html=content h_max=2 ordered=true class="toc-list list-style-none" item_class="border-top" anchor_class="d-block py-3 px-3" %}
       </div>
     </nav>
-    {% endif %}
     <div class="col-sm-10 mx-auto lh-none cover-img">
       <img src="{{ site.baseurl }}/assets/images/illos/{{ page.class }}.svg" alt="{{ page.title }}">
     </div>
diff --git a/docs/translations.md b/docs/translations.md
index 5f029967c3d..96233cc9e83 100644
--- a/docs/translations.md
+++ b/docs/translations.md
@@ -12,7 +12,7 @@ If there's not, then today is your day to lead this effort! Here's how to start:
 1. [Set up your environment](../CONTRIBUTING.md#setting-up-your-environment)
 1. Create a new branch for your translation work e.g. `es`.
 1. Copy `_data/locales/en.yml` to your target language file e.g. `_data/locales/es.yml` and translate all the strings.
-1. Create a new directory in `_articles/` for your language e.g. `_articles/es/`, copy each guide from `_articles/` into that folder and translate the content in each guide, except for the field names in the front matter between the `---`s at the top of each file, e.g., `title:` should remain unchanged. Remove the `toc:` fields (they are only used for English).
+1. Create a new directory in `_articles/` for your language e.g. `_articles/es/`, copy each guide from `_articles/` into that folder and translate the content in each guide, except for the field names in the front matter between the `---`s at the top of each file, e.g., `title:` should remain unchanged.
 1. Copy `index.html` to your target language index file e.g. `[_articles/es/index.html](https://github.com/github/opensource.guide/blob/HEAD/_articles/es/index.html)` and update the `lang:` and add the `permalink:` fields. Example: `lang: es` and `permalink: /es/`. All other fields' values must remain unchanged.
 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.)

From 127b1d02d86e4e164fcd3b4c7feba8ddfde99f1b Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Sun, 26 Sep 2021 23:38:25 +0300
Subject: [PATCH 252/749] Improve Russian translation of "Finding Users for
 Your Project"

---
 _articles/ru/finding-users.md | 156 +++++++++++++++++-----------------
 1 file changed, 78 insertions(+), 78 deletions(-)

diff --git a/_articles/ru/finding-users.md b/_articles/ru/finding-users.md
index 59227e72d99..c99f6496545 100644
--- a/_articles/ru/finding-users.md
+++ b/_articles/ru/finding-users.md
@@ -1,15 +1,15 @@
 ---
 lang: ru
 title: Поиск пользователей для вашего проекта
-description: Помогите своему проекту с открытым исходным кодом расти, передав его в руки счастливых пользователей.
+description: Помогите своему опенсорс-проекту расти, передав его в руки счастливых пользователей.
 class: finding
 toc:
   распространение-информации: 'Распространение информации'
   разберитесь-в-своем-послании: 'Разберитесь в своем послании'
-  помогите-людям-найти-ваш-проект-и-подписаться-на-него: 'Помогите людям найти ваш проект и подписаться на него'
-  идите-туда-где-аудитория-вашего-проекта-онлайн: 'Идите туда, где аудитория вашего проекта (онлайн)'
-  идите-туда-где-аудитория-вашего-проекта-офлайн: 'Идите туда, где аудитория вашего проекта (офлайн)'
-  создайте-репутацию: 'Создайте репутацию'
+  помогите-людям-найти-ваш-проект-и-следить-за-ним: 'Помогите людям найти ваш проект и следить за ним'
+  ищите-пользователей-для-вашего-проекта-онлайн: 'Ищите пользователей для вашего проекта (онлайн)'
+  ищите-пользователей-для-вашего-проекта-офлайн: 'Ищите пользователей для вашего проекта (офлайн)'
+  заработайте-репутацию: 'Заработайте репутацию'
 order: 3
 image: /assets/images/cards/finding.png
 related:
@@ -19,145 +19,145 @@ related:
 
 ## Распространение информации
 
-Нет правила, согласно которому вы должны продвигать проект с открытым исходным кодом при запуске. Есть много веских причин для работы с открытым исходным кодом, которые не имеют ничего общего с популярностью. Вместо того, чтобы надеяться, что другие найдут и воспользуются вашим проектом с открытым исходным кодом, вы должны рассказать о своей тяжелой работе!
+Нет правила, согласно которому вы должны продвигать опенсорс-проект при запуске. Есть много веских причин для работы с опенсорсом, которые не имеют ничего общего с популярностью. Вместо того, чтобы надеяться, что люди найдут и воспользуются вашим опенсорсом-проектом, вы следует самому рассказать о своей тяжелой работе!
 
 ## Разберитесь в своем послании
 
-Прежде чем приступить к реальной работе по продвижению своего проекта, вы должны быть в состоянии объяснить, что он делает и почему это важно.
+Прежде чем приступить к работе по продвижению своего проекта, вам нужно уметь объяснить, для чего он нужен и почему так важен.
 
-Что делает ваш проект особенным или интересным? Зачем вы его создали? Ответив на эти вопросы для себя, вы сможете понять важность вашего проекта.
+Что делает ваш проект особенным или интересным? Почему его создали? Ответив на эти вопросы для себя, вы сможете донести важность вашего проекта до остальных.
 
-Помните, что люди участвуют в качестве пользователей и в конечном итоге становятся участниками, потому что ваш проект решает для них проблему. Когда вы думаете о послании и ценности вашего проекта, попробуйте взглянуть на них через призму того, что могут захотеть _пользователи и участники_.
+Помните, что люди сначала приходят в ваш проекте в качестве пользователей, а затем становятся его контрибьюторами, если проект решает их проблему. Размышляя о послании и ценности вашего проекта, попробуйте взглянуть на них через призму того, что могут захотеть _пользователи и контрибьюторы_.
 
-Например, @robb использует примеры кода, чтобы четко объяснить, почему его проект [Cartography](https://github.com/robb/Cartography) полезен:
+Например, @robb приводит примеры кода, чтобы четко объяснить, почему его проект [Cartography](https://github.com/robb/Cartography) полезен:
 
-![README картографии](/assets/images/finding-users/cartography.jpg)
+![README-файл Cartography](/assets/images/finding-users/cartography.jpg)
 
-Чтобы глубже погрузиться в послание, ознакомьтесь с упражнением Mozilla [«Персоны и пути»](https://mozillascience.github.io/working-open-workshop/personas_pathways/) по развитию образов пользователей.
+Чтобы глубже погрузиться в послание, ознакомьтесь с упражнением Mozilla [«Personas and Pathways»](https://mozillascience.github.io/working-open-workshop/personas_pathways/) по развитию образов пользователей.
 
-## Помогите людям найти ваш проект и подписаться на него
+## Помогите людям найти ваш проект и следить за ним
 
-<aside markdown = "1" class = "pquote">
-  В идеале вам понадобится единый «домашний» URL-адрес, который вы можете продвигать и указывать людям в связи с вашим проектом. Вам не нужно вдаваться в причудливый шаблон или даже доменное имя, но вашему проекту нужен фокус.
-  <p markdown = "1" class = "pquote-credit">
+<aside markdown="1" class="pquote">
+  В идеале вам понадобится «домашний» URL-адрес, который вы можете рекламировать и давать людям для связи с вашим проектом. Не нужно тратиться на модный шаблон или даже доменное имя, но вашему проекту нужна точка опоры.
+  <p markdown="1" class="pquote-credit">
 - Питер Купер и Роберт Найман, [«Как рассказать о своем коде»](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/ )
   </p>
 </aside>
 
-Помогите людям найти и запомнить ваш проект, указав им единое пространство имен.
+Людям будет проще найти и запомнить ваш проект, если вы будете направлять их в одно русло.
 
-**Имейте четкое представление о продвижении своей работы.** Ник в Twitter, ссылка на GitHub или канал IRC - это простой способ указать людям на ваш проект. Эти выходы также дают возможность собраться растущему сообществу вашего проекта.
+**Создайте ясные каналы связи для рекламы своей работы.** Аккаунт в Twitter, ссылка на GitHub или канал IRC — это простой способ направить людей на ваш проект. Эти площадки также дают возможность собраться растущему сообществу проекта.
 
-Если вы еще не хотите создавать выходы для своего проекта, продвигайте свой собственный Twitter или GitHub во всем, что вы делаете. Продвижение вашего аккаунта в Twitter или GitHub позволит людям узнать, как с вами связаться или следить за вашей работой. Если вы выступаете на встрече или мероприятии, убедитесь, что ваша контактная информация указана в вашей биографии или слайдах.
+Если вы еще не хотите создавать каналы для своего проекта, продвигайте свой собственный Twitter или GitHub во всех своих начинаниях. Продвижение аккаунта в Twitter или GitHub позволит людям узнать, как с вами связаться или следить за вашей работой. Если вы выступаете на митапе или конференции, расскажите о себе или включите контактную информацию в слайдах.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/nathanmarz?s=180" class = "pquote-avatar" alt = "avatar">
-  Ошибка, которую я совершил в те первые дни (...), заключалась в том, что я не создал аккаунт в Твиттере для проекта. Twitter - отличный способ держать людей в курсе о проекте, а также постоянно знакомить людей с проектом.
-  <p markdown = "1" class = "pquote-credit">
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
+  Ошибка, которую я совершил в те первые дни (...), заключалась в том, что я не создал аккаунт в Твиттере для проекта. Twitter — отличный способ держать людей в курсе событий о проекте, а также постоянно знакомить их с проектом.
+  <p markdown="1" class="pquote-credit">
 - @nathanmarz, [«История Apache Storm и извлеченные уроки»](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
   </p>
 </aside>
 
-**Рассмотрите возможность создания веб-сайта для вашего проекта.** Веб-сайт делает ваш проект более дружелюбным и легким для навигации, особенно когда он сочетается с понятной документацией и руководствами. Наличие веб-сайта также предполагает, что ваш проект активен, что позволит вашей аудитории чувствовать себя более комфортно при его использовании. Приведите примеры, чтобы дать людям представление о том, как использовать ваш проект.
+**Подумайте о создании сайта для вашего проекта.** Сайт делает ваш проект более дружелюбным и легким для поиска, особенно если он дополнен понятной документацией и обучающими руководствами. Наличие сайта также указывает на активность вашего проекта, заставляя пользователей чувствовать себя более увереннее при его использовании. Добавьте примеры, которые помогут пользователям понять, как использовать ваш проект.
 
-[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), соавтор Django, сказал, что веб-сайт был _"безусловно лучшим, что мы делали с Django в первые дни"_.
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), соавтор Django, сказал, что сайт был _"безусловно самым правильным решением в первые дни Django"_.
 
-Если ваш проект размещен на GitHub, вы можете использовать [GitHub Pages](https://pages.github.com/), чтобы легко создать веб-сайт. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) и [Middleman](https://middlemanapp.com/) [несколько примеров](https://github.com/showcases/github-pages-examples) отличных, всеобъемлющих веб-сайтов.
+Если ваш проект размещён на GitHub, вы можете использовать [GitHub Pages](https://pages.github.com/) при создании сайта. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) и [Middleman](https://middlemanapp.com/) — только [несколько примеров](https://github.com/showcases/github-pages-examples) отличных, полноценных сайтов.
 
-![Домашняя страница Vagrant](/assets/images/finding-users/vagrant_homepage.png)
+![Главная страница Vagrant](/assets/images/finding-users/vagrant_homepage.png)
 
-Теперь, когда у вас есть сообщение для вашего проекта и простой способ для людей найти ваш проект, давайте выберемся и поговорим с вашей аудиторией!
+Теперь, когда вы знаете, что рассказать о своём проекте, и вы создали канал для связи, самое время выйти и поговорить с вашими пользователями!
 
-## Идите туда, где аудитория вашего проекта (онлайн)
+## Ищите пользователей для вашего проекта (онлайн)
 
-Информационно-пропагандистская деятельность в Интернете - отличный способ быстро поделиться и распространить информацию. Используя онлайн-каналы, вы можете охватить очень широкую аудиторию.
+Через интернет можно быстро поделиться и распространить информацию. Используя онлайн-каналы, можно выйти на очень широкую аудиторию.
 
-Воспользуйтесь преимуществами существующих онлайн-сообществ и платформ, чтобы охватить свою аудиторию. Если ваш проект с открытым исходным кодом представляет собой программный проект, вы, вероятно, сможете найти свою аудиторию на [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/) или [Quora](https://www.quora.com/). Найдите каналы, по которым, по вашему мнению, люди получат наибольшую пользу от вашей работы или будут в восторге от нее.
+Воспользуйтесь преимуществами существующих онлайн-сообществ и платформ, чтобы охватить свою аудиторию. Если ваш опенсорс-проект представляет собой программу, вы, вероятно, сможете найти заинтересованных пользователей на [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/) или [Quora](https://www.quora.com/). Найдите каналы, где, по вашему мнению, люди получат наибольшую пользу от вашей работы или будут в восторге от неё.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/pazdera?s=180" class = "pquote-avatar" alt = "avatar">
-  Каждая программа имеет очень специфические функции, которые могут оказаться полезными лишь небольшой части пользователей. Не рассылайте спам как можно большему количеству людей. Вместо этого направьте свои усилия на те сообщества, которым будет полезно знать о вашем проекте.
-  <p markdown = "1" class = "pquote-credit">
-- @pazdera, [«Маркетинг для проектов с открытым исходным кодом»](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
+  Каждая программа имеет очень узкое применение, которое нужно лишь небольшой части пользователей. Не рассылайте спам как можно большему числу людей. Вместо этого направьте свои усилия на те сообщества, которым будет полезно знать о вашем проекте.
+  <p markdown="1" class="pquote-credit">
+- @pazdera, [«Маркетинг для опенсорс-проектов»](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
   </p>
 </aside>
 
-Посмотрите, сможете ли вы найти способы поделиться своим проектом соответствующими способами:
+Попробуйте рассказать о своём проекте следующими способами:
 
-* **Познакомьтесь с соответствующими проектами и сообществами с открытым исходным кодом.** Иногда вам не нужно напрямую продвигать свой проект. Если ваш проект идеально подходит для специалистов по обработке данных, использующих Python, познакомьтесь с сообществом специалистов по науке о данных Python. По мере того, как люди узнают вас, у них появится естественная возможность рассказать о вашей работе и поделиться ею.
-* **Найдите людей, у которых возникла проблема, которую решает ваш проект.** Поищите на соответствующих форумах людей, которые попадают в целевую аудиторию вашего проекта. Ответьте на их вопрос и найдите тактичный способ, когда это уместно, предложить свой проект в качестве решения.
-* **Попросите обратную связь.** Представьте себя и свою работу аудитории, которая сочтет ее актуальной и интересной. Определите, кто, по вашему мнению, получит пользу от вашего проекта. Попытайтесь закончить предложение: _"Я думаю, что мой проект действительно поможет X, который пытается сделать Y_". Слушайте и отвечайте на отзывы других, а не просто продвигайте свою работу.
+* **Познакомьтесь с соответствующими опенсорс-проектами и сообществами.** Необязательно всегда напрямую продвигать свой проект. Если проект идеально подходит для специалистов по обработке данных, использующих Python, познакомьтесь с сообществом специалистов по науке о данных на Python. Когда люди будут знакомиться с вами, вы слово за слово можете рассказать о своей работе.
+* **Найдите людей, сталкивающихся с проблемой, которую решает ваш проект.** Поищите на соответствующих форумах людей, которые попадают в целевую аудиторию вашего проекта. Отвечайте на их вопросы и найдите тактичный способ (когда это уместно) предложить свой проект в качестве решения.
+* **Попросите обратную связь.** Представьте себя и свою работу пользователям, которые сочтет её актуальной и интересной. Чётко обозначьте, кому, по вашему мнению, принесет пользу ваш проект. Попытайтесь закончить предложение: _"Я думаю, что мой проект действительно поможет X, который пытается сделать Y_". Слушайте и отвечайте на отзывы других, а не просто рекламируйте свою работу.
 
-Вообще говоря, сосредоточьтесь на помощи другим, прежде чем просить что-то взамен. Поскольку любой может легко продвигать проект в Интернете, будет много шума. Чтобы выделиться из толпы, дайте людям понять, кто вы есть, а не только то, чего вы хотите.
+Вообще говоря, сосредоточьтесь на помощи другим, прежде чем просить что-то взамен. Поскольку каждый может легко продвигать проект в интернете, то ваше детище может потеряться в информационном шуме. Чтобы выделиться из толпы, дайте людям понять, кто вы есть, а не только то, чего вы хотите.
 
-Если никто не обращает внимания или не отвечает на вашу первоначальную просьбу, не расстраивайтесь! Запуск большинства проектов - это итеративный процесс, который может занять месяцы или годы. Если вы не получаете ответа с первого раза, попробуйте другую тактику или сначала найдите способы повысить ценность работы других. Продвижение и запуск вашего проекта требует времени и преданности делу.
+Если никто не обращает внимания или не отвечает на вашу первоначальную просьбу, не расстраивайтесь! Запуск большинства проектов — это итеративный процесс, который может занять месяцы или даже годы. Если не удалось добиться ответа с первого раза, попробуйте другую тактику или сначала найдите способы помочь повысить эффективность другим. Продвижение и запуск проекта требует времени и преданности делу.
 
-## Идите туда, где аудитория вашего проекта (офлайн)
+## Ищите пользователей для вашего проекта (офлайн)
 
 ![Публичное выступление](/assets/images/finding-users/public_speaking.jpg)
 
-Офлайн-мероприятия - популярный способ продвигать новые проекты среди аудитории. Это отличный способ привлечь заинтересованную аудиторию и наладить более глубокие человеческие связи, особенно если вы заинтересованы в контакте с разработчиками.
+Офлайн-мероприятия — популярный способ продвижения новых проектов перед публикой. Это отличная возможность привлечь заинтересованных людей и наладить более глубокие человеческие отношения, особенно если вы заинтересованы в привлечении разработчиков.
 
-Если вы [новичок в публичных выступлениях](https://speaking.io/), начните с поиска местной встречи, которая связана с языком или экосистемой вашего проекта.
+Если вы [новичок в публичных выступлениях](https://speaking.io/), начните с поиска местного митапа, связанного с языком или экосистемой вашего проекта.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/jhamrick?s=180" class = "pquote-avatar" alt = "avatar">
-  Я очень нервничал перед посещением PyCon. Я выступал с докладом, я собирался познакомиться там только с парочкой людей, я ехал на целую неделю. (...) Но я не должен был волноваться. PyCon был феноменально потрясающим! (...) Все были невероятно дружелюбны и общительны, настолько, что я редко находил время, чтобы не разговаривать с людьми!
-  <p markdown = "1" class = "pquote-credit">
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
+  Я очень нервничала перед посещением PyCon. Я выступала с докладом, собиралась познакомиться там только с парочкой людей, ехала на целую неделю. (...) Однако мне не стоило волноваться. PyCon был необычайно классным! (...) Все были невероятно так дружелюбны и общительны, что я едва находила время побыть наедине!
+  <p markdown="1" class="pquote-credit">
 - @jhamrick, [«Как я научился перестать беспокоиться и полюбить PyCon»](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
   </p>
 </aside>
 
-Если вы никогда раньше не выступали на мероприятии, нервничать - это нормально! Помните, что ваша аудитория здесь, потому что они искренне хотят услышать о вашей работе.
+Если вы никогда раньше не выступали перед публикой, вы можете нервничать, — это совершенно нормально! Помните, что люди собрались, потому что они искренне хотят послушать о вашей работе.
 
-Когда вы пишете доклад, сосредоточьтесь на том, что ваша аудитория найдет интересным и от чего получит пользу. Держите свой язык дружелюбным и доступным. Улыбайтесь, дышите и получайте удовольствие.
+Когда вы пишете доклад, сосредоточьтесь на том, что будет интересно и полезно слушателям. Сохраняйте дружелюбный тон и говорите доступным языком. Улыбайтесь, дышите и получайте удовольствие.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "/assets/images/finding-users/lena.jpg" class = "pquote-avatar" alt = "avatar">
-  Когда вы начинаете писать свое выступление, независимо от того, какая у вас тема, может помочь, если вы будете рассматривать его как историю, которую вы рассказываете людям.
-  <p markdown = "1" class = "pquote-credit">
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
+  При подготовке к своему докладу, независимо от его темы, попробуйте представить его как историю, которые вы рассказываете людям.
+  <p markdown="1" class="pquote-credit">
 - Лена Рейнхард, [«Как подготовить и написать доклад на технической конференции»](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
   </p>
 </aside>
 
-Когда вы будете готовы, подумайте о том, чтобы выступить на конференции для продвижения вашего проекта. Конференции могут помочь вам охватить больше людей, иногда со всего мира.
+Когда вы будете готовы, подумайте о выступлении на конференции, чтобы прорекламировать собственный проект. Через конференции можно донести свою мысль до большого количества людей, иногда со всего мира.
 
-Ищите конференции, относящиеся к вашему языку или экосистеме. Перед тем, как представить доклад, изучите конференцию, чтобы настроить доклад для участников и повысить свои шансы быть допущенным к выступлению на конференции. Часто вы можете составить представление о своей аудитории, посмотрев на докладчиков конференции.
+Ищите конференции, посвященные вашему языку или экосистеме. Перед подачей заявки на доклад, изучите конференцию, чтобы адаптировать доклад для участников и повысить свои шансы к выступлению на конференции. Часто составить представление о своей аудитории можно по докладчикам конференции.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/ry?s=180" class = "pquote-avatar" alt = "avatar">
-  Я очень хорошо написал людям JSConf и умолял их дать мне место, где я мог бы представить его на JSConf EU. (...) Я был очень напуган, представляя то, над чем работал шесть месяцев. (...) Все это время я просто думал, Боже мой. Что я здесь делаю?
-  <p markdown = "1" class = "pquote-credit">
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
+  Я очень вежливо написал людям из JSConf и умолял их дать мне возможность выступить на JSConf EU. (...) Я был очень напуган, представляя то, над чем работал шесть месяцев. (...) Всё это время я просто думал: «Боже мой. Что я здесь делаю?».
+  <p markdown="1" class="pquote-credit">
 - @ry, ["История Node.js" (видео)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
   </p>
 </aside>
 
-## Создайте репутацию
+## Заработайте репутацию
 
-В дополнение к стратегиям, описанным выше, лучший способ пригласить людей делиться вашим проектом и вносить в него вклад - это делиться их проектами и вносить в них свой вклад.
+В дополнение к стратегиям, описанным выше, лучший способ побудить людей делиться вашим проектом и вносить в него вклад — это делиться их проектами и вносить в них свой вклад.
 
-Помощь новичкам, обмен ресурсами и вдумчивый вклад в проекты других помогут вам заработать положительную репутацию. Если вы будете активным членом сообщества разработчиков ПО с открытым исходным кодом, это поможет людям понять контекст вашей работы и с большей вероятностью обратит внимание на ваш проект и поделится им. Развитие отношений с другими проектами с открытым исходным кодом может даже привести к официальному партнерству.
+Помощь новичкам, обмен ресурсами и содержательный вклад в проекты других людей помогут вам заработать положительную репутацию. Активное участие в опенсорс-сообществе поможет людям понять суть вашей работы и с большей вероятностью обратить внимание на ваш проект и поделится им. Развитие отношений с другими опенсорс-проектами может даже привести к официальному партнерству.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/shazow?s=180" class = "pquote-avatar" alt = "avatar">
-  Единственная причина, по которой urllib3 является сегодня самой популярной сторонней библиотекой Python, заключается в том, что она является частью запросов.
-  <p markdown = "1" class = "pquote-credit">
-- @shazow, [«Как сделать так, чтобы ваш проект с открытым исходным кодом процветал»](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
+  Единственная причина, по которой urllib3 является сегодня самой популярной сторонней библиотекой Python, заключается в том, что люди часто предлагают её использовать в других проектах.
+  <p markdown="1" class="pquote-credit">
+- @shazow, [«Как сделать так, чтобы ваш опенсорс-проект процветал»](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
   </p>
 </aside>
 
-Никогда не рано и не поздно начать укреплять свою репутацию. Даже если вы уже запустили собственный проект, продолжайте искать способы помочь другим.
+Никогда не рано и не поздно начать укреплять свою репутацию. Даже если вы уже запустили собственный проект, стремитесь разными способами помогать другим.
 
-Не существует мгновенного решения для создания аудитории. Чтобы завоевать доверие и уважение окружающих, нужно время, а создание вашей репутации никогда не заканчивается.
+Невозможно в одночасье нарастить аудиторию. Чтобы заслужить доверие и уважение окружающих нужно время, а созданию репутации нет конца и края.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/ariya?s=180" class = "pquote-avatar" alt = "avatar">
-  PhantomJS был выпущен впервые в начале 2011 года. (...) Я распространял информацию обычными способами: я писал об этом в Твиттере, я писал сообщения в блогах о том, что вы можете с ним делать, я упоминал об этом во время различных обсуждений на митапах. Когда об этом стало больше известно в 2014 году, я начал делать презентации об этом.
-  <p markdown = "1" class = "pquote-credit">
-- @ariya, ["Истории сопровождающих"](https://github.com/open-source/stories/ariya)
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
+  Впервые PhantomJS был выпущен в начале 2011 года. (...) Я рекламировал его обычными способами: писал в Twitter, публиковал посты в блоге о том, что с ним можно сделать, упоминал во время различных обсуждений на митапах. Когда о нём стало больше известно в 2014 году, я начал выступать с докладами.
+  <p markdown="1" class="pquote-credit">
+- @ariya, ["Истории мейнтейнеров"](https://github.com/open-source/stories/ariya)
   </p>
 </aside>
 
-## Держись! Не сдавайся!
+## Не останавливайтесь на достигнутом!
 
-Может пройти много времени, прежде чем люди заметят ваш проект с открытым исходным кодом. Это нормально! Некоторым из самых популярных сегодня проектов потребовались годы, чтобы достичь высокого уровня активности. Сосредоточьтесь на построении отношений, а не на надежде, что ваш проект спонтанно станет популярным. Будьте терпеливы и продолжайте делиться своей работой с теми, кто ее ценит.
+Может пройти много времени, прежде чем люди заметят ваш опенсорс-проект. Это нормально! Некоторым из самых популярных сегодня проектов потребовались годы, чтобы достичь высокого уровня активности. Сосредоточьтесь на выстраивании отношений, а не на надежде, что ваш проект внезапно станет популярным. Будьте терпеливы и продолжайте делиться своей работой с теми, кто её ценит.

From fb8f393fca61207d5724f09a82f2630fe3953716 Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Mon, 27 Sep 2021 21:54:14 +0300
Subject: [PATCH 253/749] Improve Russian translation of "Best Practices for
 Maintainers"

---
 _articles/ru/best-practices.md | 286 ++++++++++++++++-----------------
 1 file changed, 143 insertions(+), 143 deletions(-)

diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md
index f782436bbca..14630a589b5 100644
--- a/_articles/ru/best-practices.md
+++ b/_articles/ru/best-practices.md
@@ -1,15 +1,15 @@
 ---
 lang: ru
-title: Хорошие практики для сопровождающих
-description: Облегчите вашу жизнь в качестве сопровождающего открытого исходного кода, от документирования процессов до использования вашего сообщества.
+title: Хорошие практики для мейнтейнеров
+description: Облегчите вашу жизнь как мейнтейнера опенсорс-проекта — от документирования процессов до привлечения вашего сообщества.
 class: best-practices
 toc:
-  что-значит-быть-сопровождающим: 'Что значит быть сопровождающим?'
-  документирование-ваших-процессов: 'Документирование ваших процессов'
-  учитесь-говорить-нет: 'Учитесь говорить "нет"'
-  используйте-свое-сообщество: 'Используйте свое сообщество'
-  принесите-роботов: 'Принесите роботов'
-  нажать-паузу---это-нормально: 'Нажать паузу - это нормально'
+  что-значит-быть-мейнтейнером: 'Что значит быть мейнтейнером?'
+  документирование-процессов: 'Документирование процессов'
+  учитесь-говорить-нет: 'Учитесь говорить «нет»'
+  используйте-силу-сообщества: 'Используйте силу сообщества'
+  задействуйте-роботов: 'Задействуйте роботов'
+  взять-паузу---это-нормально: 'Взять паузу — это нормально'
 order: 5
 image: /assets/images/cards/best-practices.png
 related:
@@ -17,271 +17,271 @@ related:
   - leadership
 ---
 
-## Что значит быть сопровождающим?
+## Что значит быть мейнтейнером?
 
-Если вы поддерживаете проект с открытым исходным кодом, которым пользуется множество людей, возможно, вы заметили, что меньше кодируете и больше отвечаете на проблемы.
+Если вы поддерживаете опенсорс-проект, которым пользуется множество людей, возможно, вы заметили, что меньше пишите код и больше отвечаете в ишью.
 
-На ранних стадиях проекта вы экспериментируете с новыми идеями и принимаете решения, основанные на ваших желаниях. По мере роста популярности вашего проекта вы обнаружите, что больше работаете со своими пользователями и участниками.
+На ранних стадиях проекта вы экспериментируете с новыми идеями и принимаете решения, основываясь на собственных предпочтениях. По мере роста популярности вашего проекта вы будете больше работать со своими пользователями и контрибьюторами.
 
-Для поддержки проекта требуется нечто большее, чем просто код. Эти задачи часто бывают неожиданными, но они не менее важны для растущего проекта. Мы собрали несколько способов облегчить вашу жизнь - от документирования процессов до привлечения вашего сообщества.
+Для поддержки проекта требуется нечто большее, чем просто код. Эти задачи часто бывают неожиданными, но они не менее важны для растущего проекта. Мы собрали несколько способов облегчить вашу жизнь — от документирования процессов до привлечения вашего сообщества.
 
 ## Документирование ваших процессов
 
-Записывать вещи - одна из самых важных вещей, которую вы можете делать как сопровождающий.
+Как мейнтейнеру вам предстоит много писать, — это одна из наиболее главных ваших задач.
 
-Документация не только проясняет ваше собственное мышление, но и помогает другим людям понять, что вам нужно или чего вы ждете, еще до того, как они спросят.
+Документация не только проясняет вашу голову, но и помогает другим людям понять, что вам нужно или чего вы ждете, еще до того, как они спросят.
 
-Записывая вещи, легче сказать «нет», когда что-то не вписывается в ваши рамки. Это также облегчает людям участие и помощь. Вы никогда не знаете, кто может читать или использовать ваш проект.
+На письме легче сказать «нет», когда что-то не вписывается в рамки проекта. Это также поможет людям присоединиться и помочь вам. Ведь никогда не знаешь, кто может интересоваться или использовать ваш проект.
 
-Даже если вы не используете полные абзацы, лучше писать тезисы, чем не писать вообще.
+Даже если вы не собираетесь писать много текста, наброска с основными тезисами будет вполне достаточно, по крайней мере это лучше, чем ничего.
 
-Не забывайте обновлять документацию. Если вы не можете делать это всегда, удалите устаревшую документацию или укажите, что она устарела, чтобы участники знали, что обновления приветствуются.
+Не забывайте обновлять документацию. Если не всегда получается это сделать, удалите устаревшую документацию или укажите, что она устарела, таким образом участники могут помочь с этим.
 
-### Запишите видение вашего проекта
+### Запишите видение проекта
 
-Начните с записи целей вашего проекта. Добавьте их в свой README или создайте отдельный файл с именем VISION. Если есть другие артефакты, которые могут помочь, например дорожная карта проекта, также сделайте их общедоступными.
+Начните с составления целей вашего проекта. Добавьте их в свой README или создайте отдельный файл с именем VISION. Если есть другая похожая информация, которая может помочь, например план развития (дорожная карта) проекта, то также сделайте их общедоступными.
 
-Наличие четкого, задокументированного видения позволяет вам сосредоточиться и избежать «расползания по масштабам» от вкладов других людей.
+Наличие четкого и задокументированной концепции проекта поможет вам сосредоточиться на главном и избежать «неконтролируемого роста проекта» от участия других людей.
 
-Например, @lord обнаружил, что видение проекта помогло ему понять, на какие запросы следует потратить время. Как новый сопровождающий, он сожалел, что не придерживался масштабов своего проекта, когда получил свой первый запрос функции для [Slate](https://github.com/lord/slate).
+Например, @lord обнаружил, что видение проекта помогло ему понять правильно расставить приоритеты. Как новый мейнтейнер, он сожалел, что проследил за расползанием границ проекта, когда получил свой первый запрос на реализацию новой функциональности в [Slate](https://github.com/lord/slate).
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/lord?s=180" class = "pquote-avatar" alt = "avatar">
-  Я нащупал это. Я не прилагал усилий, чтобы найти полное решение. Вместо полупродуманного решения я хотел бы сказать: «У меня сейчас нет на это времени, но я добавлю его в долгосрочный список, который принято иметь».
-  <p markdown = "1" class = "pquote-credit">
-- @lord, [«Советы для новых разработчиков ПО с открытым исходным кодом»](https://lord.io/blog/2014/oss-tips/)
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
+  Я не справился. Я не приложил достаточно усилий, чтобы найти полное решение. Вместо половинчатого решения мне было бы сказать: «У меня сейчас нет на это времени, но я добавлю его в список пожеланий».
+  <p markdown="1" class="pquote-credit">
+- @lord, [«Советы новым опенсорс-мейнтейнерам»](https://lord.io/blog/2014/oss-tips/)
   </p>
 </aside>
 
 ### Сообщите о своих ожиданиях
 
-Написание правил может утомлять вас. Иногда вам может казаться, что вы следите за поведением других людей или убиваете все самое интересное.
+Написание правил может утомлять вас. Иногда вам может показаться, что вы следите за поведением других людей или убиваете все самое интересное.
 
-Однако хорошие правила написаны и соблюдаются справедливо и расширяют возможности специалистов по сопровождению. Они не дают вам быть втянутыми в дела, которые вы не хотите делать.
+Однако справедливое выполнение хорошо составленных правил расширяют возможности мейнтейнеров. Это избавит вас от вовлечения в малоприятные дела.
 
-Большинство людей, которые сталкиваются с вашим проектом, ничего не знают ни о вас, ни о ваших обстоятельствах. Они могут предположить, что вам платят за работу над этим, особенно если это то, чем они регулярно пользуются и от чего зависят. Может быть, в какой-то момент вы потратили много времени на свой проект, но теперь вы заняты новой работой или членом семьи.
+Большинство людей, сталкивающиеся с вашим проектом, ничего не знают о вас или ваших обстоятельствах. Они могут предположить, что вам платят за работу над проектом, особенно если они его регулярно используют и полагаются на него. Может быть, когда-то вы уделили много времени своему проекту, но теперь заняты новой работой или семейными занятиями.
 
-Все это нормально! Просто убедитесь, что об этом знают другие люди.
+Всё это абсолютно нормально! Только дайте знать об этом другим людям.
 
-Если поддержка вашего проекта осуществляется неполный рабочий день или осуществляется исключительно на добровольной основе, скажите честно, сколько у вас времени. Это не то же самое, сколько времени, по вашему мнению, требуется для проекта, или сколько времени другие хотят, чтобы вы потратили на него.
+Если вы занимаетесь проектом нерегулярно или на добровольных началах, честно признайте, сколько у вас есть времени. Не стоит путать имеющиеся у вас время и время, которое, по вашему мнению, требуется для проекта или от вас ожидают другие.
 
-Вот несколько правил, которые стоит записать:
+Вот несколько правил, которые стоит установить:
 
-* Как отзыв рассматривается и принимается (_Нужны ли им тесты? Шаблон задачи?_)
-* Типы вклада, которые вы примете (_Вам нужна помощь только с определенной частью вашего кода?_)
-* Когда уместно следить (_например, «Вы можете ожидать ответа от сопровождающего в течение 7 дней. Если к тому времени вы ничего не услышали, не стесняйтесь пинговать тему»._)
+* Как рассматривается и принимается вклад (_Нужно ли написать тесты? Шаблон ишью?_)
+* Типы вкладов, которые вы принимаете (_Вам нужна помощь только с определенной частью вашего кода?_)
+* Когда следует предпринять последующие действия (_например, «Вы можете ожидать ответа от мейнтейнера в течение 7 дней. Если после этого времени вы не получили ответ, не стесняйтесь поднимать тему»._)
 * Сколько времени вы тратите на проект (_например, «Мы тратим на этот проект всего около 5 часов в неделю»_)
 
-[Джекилл](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), и [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) - несколько примеров проектов с основными правилами для сопровождающих и участников.
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) и [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) — это лишь несколько примеров проектов с основными правилами для мейнтейнеров и контрибьюторов.
 
-### Поддерживайте общедоступность
+### Поддерживайте публичность обсуждений
 
-Не забывайте также документировать свое общение. Везде, где вы можете, делитесь информацией о своем проекте публично. Если кто-то пытается связаться с вами в частном порядке, чтобы обсудить запрос функции или потребность в поддержке, вежливо направьте его на общедоступный канал связи, такой как список рассылки или средство отслеживания проблем (issues).
+Не забывайте также фиксировать свои беседы. Там, где это возможно, делитесь информацией о своем проекте публично. Если кто-то пытается связаться с вами напрямую, чтобы обсудить реализацию новой функциональности или получить помощь, вежливо направьте его на общедоступный канал связи, такой как список рассылки или ишью.
 
-Если вы встречаетесь с другими сопровождающими или принимаете важное решение в частном порядке, документируйте эти разговоры публично, даже если это просто публикация ваших заметок.
+Если вы встречаетесь с другими мейнтейнерами или принимаете важное решение в частном порядке, записывайте всё, даже если это просто публикация ваших заметок.
 
-Таким образом, любой, кто присоединится к вашему сообществу, будет иметь доступ к той же информации, что и тот, кто был там много лет.
+Таким образом, любой, кто присоединится к вашему сообществу, будет иметь доступ к той же информации, что и тот, кто был там годами.
 
-## Учитесь говорить "нет"
+## Научитесь говорить «нет»
 
-Вы все записали. В идеале все бы читали вашу документацию, но на самом деле вам придется напоминать другим, что эти знания существуют.
+Вы всё записали. В идеальном мире все бы прочитали документацию, но вот только в реальности вам придется напоминать людям об её существовании.
 
-Однако если все записать, это поможет обезличить ситуации, когда вам действительно нужно обеспечить соблюдение своих правил.
+Однако ссылка на письменные объяснения поможет обезличить ситуации, когда нужно обеспечить соблюдение правил.
 
-Сказать «нет» - это не весело, но _«Ваш вклад не соответствует критериям этого проекта»_ кажется менее личным, чем _«Мне не нравится ваш вклад»_.
+Также сам отказ следует сделать как можно менее личным, например, вместо  _«Мне не нравится ваш вклад»_ намного лучше написать _«Ваш вклад не соответствует критериям этого проекта»_.
 
-Сказать «нет» применимо ко многим ситуациям, с которыми вы столкнетесь как сопровождающий: запросы функций, которые не соответствуют проекту, кто-то срывает обсуждение, выполняет ненужную для других работу.
+Отказывать применимо во многих ситуациях, с которыми вы столкнетесь как мейнтейнер, например, когда кто-то просит реализовать новую функциональность, которая не вписывается в проект, или мешает обсуждению, либо выполняет ненужную для других работу.
 
 ### Поддерживайте дружескую беседу
 
-Одно из самых важных мест, где вы будете практиковаться, говоря «нет», - это проблемы (issues) и очередь запросов на перенос. Как сопровождающий проекта, вы неизбежно получите предложения, которые не захотите принимать.
+Как правило, в ишью и пул-реквестах вы будете практиковаться отказывать людям. Как мейнтейнер проекта, вы неизбежно будете получать ненужные предложения.
 
-Возможно, чей-то вклад изменяет масштаб проекта или не соответствует вашему видению. Может идея хорошая, но реализация оставляет желать лучшего.
+Возможно вклад сильно меняет суть проекта или не соответствует вашему видению. Может идея хорошая, но реализация оставляет желать лучшего.
 
-Независимо от причины, можно тактично обращаться с материалами, которые не соответствуют стандартам вашего проекта.
+Независимо от причины, нужно с пониманием относится к предлагаемым изменениям, которые не соответствуют стандартам вашего проекта.
 
-Если вы получаете вклад, который не хотите принимать, ваша первая реакция может заключаться в том, чтобы проигнорировать его или притвориться, что вы его не видели. Это может задеть чувства другого человека и даже лишить мотивации других потенциальных участников в вашем сообществе.
+Если видите вклад, который не собираетесь принимать, первой реакцией может быть проигнорировать его или притвориться, что его нет. Однако это может обидеть автора, и даже демотивировать потенциальных контрибьюторов.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/krausefx?s=180" class = "pquote-avatar" alt = "avatar">
-  Ключ к поддержке крупномасштабных проектов с открытым исходным кодом - это решение проблем. Старайтесь избегать простаивания проблем (issues). Если вы разработчик iOS, вы знаете, как может быть неприятно отправлять сообщение об ошибке на "радар". Возможно, вы услышите ответ через 2 года и вам предложат повторить попытку с последней версией iOS.
-  <p markdown = "1" class = "pquote-credit">
-- @KrauseFx, [«Масштабирование сообществ с открытым исходным кодом»](https://krausefx.com/blog/scaling-open-source-communities)
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
+  Ключ к поддержке крупномасштабных опенсорс-проектов — это постоянное решение ишью. Старайтесь избегать простаивания ишью. Если вы iOS-разработчик, вы знаете, как может быть неприятно отправлять сообщение об ошибке в баг-трекер Apple. Вам могут ответить спустя 2 года, и предложат повторить всё сначала, только используя последнюю версию iOS.
+  <p markdown="1" class="pquote-credit">
+- @KrauseFx, [«Масштабирование опенсорс-сообществ»](https://krausefx.com/blog/scaling-open-source-communities)
   </p>
 </aside>
 
-Не оставляйте нежелательный вклад открытым, потому что вы чувствуете себя виноватым или хотите вести себя хорошо. Со временем ваши оставшиеся без ответа вопросы и PR сделают работу над вашим проектом намного более напряженной и пугающей.
+Не оставляйте ненужным вклад открытым из-за чувства вины или вежливости. Со временем все оставшиеся без ответа ишью и PR только усложнят и замедлят вашу работу над проектом.
 
-Лучше сразу закрыть те взносы, которые вы не хотите принимать. Если ваш проект уже страдает от большого отставания, у @steveklabnik есть предложения [как эффективно сортировать проблемы](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Если вы понимаете, что не сможете принять вклад, лучше сразу его закройте. Если в вашем проекте уже накопилось большое количество нерассмотренных заявок, у @steveklabnik есть предложения по [эффективной сортировке ишью](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
 
-Во-вторых, игнорирование вкладов посылает негативный сигнал вашему сообществу. Участие в проекте может быть пугающим, особенно если это кто-то впервые. Даже если вы не принимаете их вклад, поблагодарите человека, стоящего за ним, за проявленный интерес. Это большой комплимент!
+Кроме того, игнорирование вкладов оказывает отрицательное воздействие на ваше сообщество. Участие в проекте может быть пугающим, особенно в первый раз. Даже если вы не собираетесь принимать вклад, поблагодарите его автора за проявленный интерес. Это большой комплимент!
 
 Если вы не хотите принимать вклад:
 
-* **Поблагодарите их** за их вклад
-* **Объясните, почему это не вписывается** в рамки проекта, и, если можете, предложите четкие предложения по улучшению. Будьте добрыми, но твердыми.
-* **Ссылка на соответствующую документацию**, если она у вас есть. Если вы замечаете повторяющиеся запросы о вещах, которые не хотите принимать, добавьте их в свою документацию, чтобы не повторяться.
-* **Закройте заявку**
+* **Поблагодарите автора** за работу
+* **Объясните, почему он вписывается** в рамки проекта, и, если можете, подготовьте четкие предложения по улучшению. Будьте добрым, но строгим.
+* **Прикрепите ссылку на соответствующую документацию**, если она у вас есть. Если вы замечаете повторяющиеся нежелательные пул-реквесты, напишите об этом в документации.
+* **Закройте пул-реквест**
 
-Для ответа не должно быть более 1-2 предложений. Например, когда пользователь [celery](https://github.com/celery/celery/) сообщил об ошибке, связанной с Windows, @berkerpeksag [ответил](https://github.com/celery/celery/issues/3383):
+Для ответа достаточно будет 1-2 предложений. Например, когда пользователь [celery](https://github.com/celery/celery/) сообщил об ошибке, связанной с Windows, @berkerpeksag [ответил](https://github.com/celery/celery/issues/3383):
 
-![Снимок экрана с сельдереем](/assets/images/best-practices/celery.png)
+![Скриншот из Celery](/assets/images/best-practices/celery.png)
 
-Если мысль о том, чтобы сказать «нет», пугает вас, вы не одиноки. Как сказал @jessfraz [выразился](https://blog.jessfraz.com/post/the-art-of-closing/):
+Если мысль о том, чтобы сказать «нет», пугает вас, вы не одиноки. Как @jessfraz [выразился](https://blog.jessfraz.com/post/the-art-of-closing/):
 
-> Я разговаривал с сопровождающими из нескольких различных проектов с открытым исходным кодом, Mesos, Kubernetes, Chromium, и все они согласны с тем, что одна из самых сложных частей работы сопровождающего - это сказать «нет» патчам, которые вам не нужны.
+> Я разговаривал с мейнтейнерами из нескольких различных опенсорс-проектов, Mesos, Kubernetes, Chromium, и все они согласны с тем, что одна из самых сложных частей работы мейнтейнера — это отказаться от ненужных патчей.
 
-Не чувствуйте себя виноватым из-за того, что не хотите принимать чей-то вклад. Первое правило открытого исходного кода, [согласно](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _«Нет - временно, да - навсегда»._ Сочувствовать энтузиазму другого человека - это хорошо. Отказ от вклада - это не то же самое, что отказ от человека, стоящего за ним.
+Не чувствуйте себя виноватым из-за того, что не хотите принимать чей-то вклад. Первое правило опенсорса, [согласно](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _«Нет — временно, да — навсегда»._ Сочувствовать энтузиазму другого человека - это хорошо, отказываться от его вклада — не значит отвергать его автора.
 
-В конечном итоге, если вклад недостаточно хорош, вы не обязаны его принимать. Будьте добры и отзывчивы, когда люди вносят свой вклад в ваш проект, но принимайте только те изменения, которые, по вашему мнению, сделают ваш проект лучше. Чем чаще вы практикуетесь говорить «нет», тем легче это становится. Обещаю.
+В конечном итоге, если вклад недостаточно хорош, вы не обязаны его принимать. Будьте добры и отзывчивы, когда люди вносят свой вклад в ваш проект, но принимайте только те изменения, которые, по вашему мнению, сделают ваш проект лучше. Чем чаще вы будете говорить «нет», тем легче будет это получаться. Обещаю.
 
-### Быть инициативным
+### Будьте инициативным
 
-Чтобы уменьшить объем нежелательных вкладов, в первую очередь, объясните процесс отправки и принятия вкладов в вашем проекте в своем руководстве по участию.
+Прежде всего, чтобы уменьшить количество нежелательных вкладов, распишите процесс отправки и принятия вкладов в своем руководстве по участию вашего проекта.
 
-Если вы получаете слишком много некачественных материалов, потребуйте от участников заранее поработать, например:
+Если вам приходят слишком много некачественных вкладов, потребуйте от контрибьюторов выполнить ряд условий, например:
 
-* Заполнить шаблон/контрольный список для проблемы (issue) и запроса на перенос (pull request)
-* Открыть проблему перед отправкой запроса на перенос
+* Заполнить шаблон/контрольный список для в ишью или пул-реквесте
+* Открыть ишью перед отправкой пул-реквеста
 
-Если они не соблюдают ваши правила, немедленно закройте проблему и укажите на свою документацию.
+Если люди не соблюдают ваши правила, немедленно закройте ишью и укажите им на предварительные требования.
 
-Поначалу такой подход может показаться недобрым, но на самом деле проактивность полезна для обеих сторон. Это снижает вероятность того, что кто-то потратит впустую много часов работы на запрос на перенос (pull request), который вы не собираетесь принимать. И это упрощает управление вашей рабочей нагрузкой.
+Поначалу такой подход может показаться недобрым, но на самом деле проактивность полезна для обеих сторон. Это снижает вероятность того, что кто-то потратит впустую много часов работы на ненужный для вас пул-реквест. А ещё для вас снизится нагрузка.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/mikemcquaid?s=180" class = "pquote-avatar" alt = "avatar">
-  В идеале, объясните им в файле CONTRIBUTING.md, как они могут получить в будущем лучшее представление о том, что будет или не будет принято, до того, как они начнут работу.
-  <p markdown = "1" class = "pquote-credit">
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+  По-хорошему, в файле CONTRIBUTING.md объясните людям, как они могут получить в будущем лучшее представление о том, что будет или не будет принято, до того, как они начнут работу.
+  <p markdown="1" class="pquote-credit">
 - @MikeMcQuaid, [«Любезно завершающие запросы на включение»](https://github.com/blog/2124-kindly-closing-pull-requests)
   </p>
 </aside>
 
-Иногда, когда вы говорите «нет», ваш потенциальный участник может расстроиться или раскритиковать ваше решение. Если их поведение становится враждебным, [примите меры, чтобы разрядить ситуацию](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или даже удалите их из вашего сообщества, если они не желают конструктивного сотрудничества.
+Иногда, когда вы говорите «нет», потенциальный контрибьютор может расстроиться или раскритиковать ваше решение. Если его поведение становится враждебным, [примите меры, чтобы разрядить ситуацию](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или даже удалите его из вашего сообщества, если он не готов к конструктивному сотрудничеству.
 
 ### Примите наставничество
 
-Возможно, кто-то из вашего сообщества регулярно отправляет материалы, не соответствующие стандартам вашего проекта. Для обеих сторон могут быть неприятны неоднократные отказы.
+Возможно, кто-то из вашего сообщества регулярно отправляет вклады, не соответствующие стандартам вашего проекта. Не только автор, но мейнтейнер может быть разочарован, если постоянно приходится отказывать в принятии вклада.
 
-Если вы видите, что кто-то с энтузиазмом относится к вашему проекту, но требует немного доработки, наберитесь терпения. Четко объясните в каждой ситуации, почему их вклад не соответствует ожиданиям проекта. Попробуйте указать им на более легкую или менее двусмысленную задачу, например, на проблему с пометкой _"первая хорошая проблема"_, чтобы они приспособились. Если у вас есть время, подумайте о том, чтобы наставлять их с помощью их первого вклада, или найдите кого-нибудь еще в вашем сообществе, который может быть готов наставлять их.
+Если вы видите, что кто-то с энтузиазмом подходит к вашему проекту, но его работа требует доработки, будьте терпеливы. Четко объясните в каждой ситуации, почему их вклад не соответствует ожиданиям проекта. Попробуйте предложить людям более легкую или менее расплывчатую задачу, например, ишью с ярлыком _"good first issue"_, чтобы набраться опыта и попробовать себя. Если у вас есть время, подумайте о наставничестве в их первом вкладе, или найдите кого-нибудь в вашем сообществе, кто согласился стать ментором.
 
-## Используйте свое сообщество
+## Используйте силу сообщества
 
-Необязательно все делать самому. Сообщество вашего проекта существует не зря! Даже если у вас еще нет активного сообщества участников, если у вас много пользователей, заставьте их работать.
+Необязательно все делать самому. Сообщество вашего проекта существует не просто так! Даже если у вас еще нет активных контрибьюторов, но зато есть много пользователей, попробуйте привлечь их.
 
-### Разделите рабочую нагрузку
+### Распределите рабочую нагрузку
 
-Если вы ищете других, кто может принять участие, начните с расспросов.
+Если вы ищете, кто мог бы помочь, начните с расспросов.
 
-Один из способов привлечь новых участников - явно [обозначить проблемы, которые достаточно просты для начинающих](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Затем GitHub будет отображать эти проблемы в различных местах платформы, делая их более заметными.
+Один из способов привлечь новых контрибьюторов — [добавить ярлык на те ишью, которые достаточно просты для начинающих](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Затем GitHub будет отображать их в различных местах сайта, делая тем самым их более заметными.
 
-Когда вы видите, что новые участники неоднократно вносят свой вклад, признайте их работу, предложив больше ответственности. Задокументируйте, как другие могут стать лидерами, если захотят.
+Когда вы видите, что новые контрибьюторы неоднократно вносят свой вклад, признайте их работу, предложив больше ответственности. Задокументируйте, как люди могут занять руководящие роли, если захотят.
 
-Поощрение других [разделить право собственности на проект](../building-community/#совместное-владение-вашим-проектом) может значительно снизить вашу рабочую нагрузку, как обнаружила @lmccart в своем проекте [p5.js](https://github.com/processing/p5.js).
+Побуждение других [разделить владение проектом](../building-community/#совместное-владение-вашим-проектом) может значительно снизить вашу нагрузку, как обнаружила @lmccart в своем проекте [p5.js](https://github.com/processing/p5.js).
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/lmccart?s=180" class = "pquote-avatar" alt = "avatar">
-  Я говорил: «Да, любой может участвовать, вам не обязательно иметь большой опыт программирования [...]». У нас были люди, которые записывались, чтобы прийти [на мероприятие], и тогда я по-настоящему задумался: правда ли это то, что я говорю? Придет 40 человек, и я не могу сидеть с каждым из них... Но люди собрались вместе, и это вроде как сработало. Как только один человек понимал что-то, он мог научить своего соседа.
-  <p markdown = "1" class = "pquote-credit">
-- @lmccart, [«Что вообще означает« открытый исходный код »? P5.js Edition»](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
+  Я говорила: «Да, любой может поучаствовать, не обязательно обладать большим опытом программирования [...]». У нас были люди, которые записывались, чтобы прийти [на мероприятие], и тогда я по-настоящему задумалась: справлюсь ли я этим? Придёт 40 человек, и я не могу сидеть с каждым из них... Но люди собрались вместе, и вроде всё прошло хорошо. Как только один человек понимал что-то, он мог научить своего соседа.
+  <p markdown="1" class="pquote-credit">
+- @lmccart, [«Что вообще означает «опенсорс»? P5.js Edition»](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
   </p>
 </aside>
 
-Если вам нужно отказаться от проекта, будь то на перерыв или навсегда, нет ничего постыдного в том, чтобы попросить кого-то другого взять на себя ответственность за вас.
+Если вам нужно отойти от проекта, будь то сделать перерыв или навсегда покинуть его, нет ничего постыдного в том, чтобы попросить кого-то другого взять на себя ваши обязанности.
 
-Если другие люди с энтузиазмом относятся к его направлению, предоставьте им доступ к правкам (to commit) или официально передайте контроль кому-то другому. Если кто-то разветвил (fork) ваш проект и активно поддерживает его в другом месте, подумайте о том, чтобы сделать ссылку на ответвление из вашего исходного проекта. Здорово, что так много людей хотят, чтобы ваш проект продолжал жить!
+Если другие люди полны энтузиазма относительно направления развития проекта, предоставьте им доступ к отправке коммитов или официально передайте контроль кому-то другому. Если кто-то форкнул ваш проект и начал активно заниматься его копией, подумайте о том, чтобы указать ссылку на него в уже вашем (оригинальном) проекте. Здорово, что так много людей хотят, чтобы ваш проект продолжал развиваться!
 
 @progrium [обнаружил, что](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) документирование видения его проекта [Dokku](https://github.com/dokku/dokku) помогло достичь этих целей даже после того, как он ушел из проекта:
 
-> Я написал вики-страницу с описанием того, что я хотел и почему я этого хотел. Почему-то для меня стало неожиданностью, что сопровождающие начали продвигать проект в этом направлении! Произошло ли это именно так, как я хотел? Не всегда. Но это все же приблизило проект к тому, что я написал.
+> Я написал вики-страницу с описанием того, что я хотел сделать и почему. Почему-то для меня стало неожиданностью, что мейнтейнеры начали двигать проект в этом направлении! Всё происходило именно так, как я хотел? Не всегда. Но все же приблизило проект к тому, что я написал.
 
 ### Позвольте другим создавать нужные им решения
 
-Если потенциальный участник придерживается другого мнения о том, что должен делать ваш проект, вы можете мягко поощрить его к работе над собственным ответвлением (fork).
+Если потенциальный контрибьютор придерживается другого мнения, что должен делать ваш проект, вы можете мягко подтолкнуть его к работе над собственным форком.
 
-Разветвление проекта не должно считаться плохим. Возможность копировать и изменять проекты - одна из лучших сторон открытого исходного кода. Поощрение членов вашего сообщества к работе над собственным форком может дать им необходимый творческий выход, не противореча видению вашего проекта.
+Не следует воспринимать копии проекта чем-то плохим. Возможность копировать и изменять проекты — одна из лучших особенностей опенсорса. Содействие членов вашего сообщества к работе над собственным форком может дать им необходимую творческую отдушину, без ущерба вашему проекту.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/geerlingguy?s=180" class = "pquote-avatar" alt = "avatar">
-  Я стремлюсь к покрытию 80% потребностей. Если вы один из единорогов, пожалуйста, ответвите мою работу. Я не обижусь! Мои публичные проекты почти всегда предназначены для решения самых распространенных проблем; я стараюсь сделать так, чтобы было легче идти глубже, либо разветвляя свою работу, либо расширяя ее.
-  <p markdown = "1" class = "pquote-credit">
-- @geerlingguy, [«Почему я закрываю запрос за перенос (pull request)](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
+  Я стремлюсь к покрытию 80% потребностей. Если вы один из единорогов, пожалуйста, ответвите мою работу. Я не обижусь! Мои публичные проекты почти всегда предназначены для решения самых распространенных проблем; я стараюсь сделать так, чтобы было легче углубиться, либо путём форка моей работы, либо расширив её.
+  <p markdown="1" class="pquote-credit">
+- @geerlingguy, [«Почему я закрываю пул-реквесты](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
   </p>
 </aside>
 
-То же самое относится к пользователю, которому действительно нужно решение, для создания которого у вас просто нет пропускной способности. Предлагая API-интерфейсы и хуки настройки, можно помочь другим удовлетворить их собственные потребности без необходимости напрямую изменять исходный код. @orta [обнаружил, что](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) поощрение плагинов для CocoaPods привело к «некоторым из самых интересных идей»:
+То же самое относится к пользователю, которому действительно нужно решение, но для создания которого у вас просто нет ресурсов. Предлагая API-интерфейсы и хуки для кастомизации, можно помочь другим пользователям решить их задачи без необходимости напрямую изменять исходный код. @orta [обнаружил, что](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) поощрение плагинов для CocoaPods привело к «некоторым из самых интересных идей»:
 
-> Почти неизбежно, что когда проект становится большим, сопровождающие должны стать более консервативными в том, как они вводят новый код. Вы научитесь говорить «нет», но у многих людей есть законные потребности. Таким образом, вместо этого вы превращаете свой инструмент в платформу.
+> Почти неизбежно, что когда проект становится большим, мейнтейнеры должны стать более консервативными касательно нового кода. Вы научитесь отказывать, несмотря, что у многих людей есть разумные причины. Так что в итоге вы превращаете свой инструмент в платформу.
 
-## Принесите роботов
+## Задействуйте роботов
 
-Подобно тому, как есть задачи, с которыми вам могут помочь другие люди, есть также задачи, которые ни один человек никогда не должен выполнять. Роботы - ваш друг. Используйте их, чтобы облегчить себе жизнь в качестве сопровождающего.
+Подобно тому, как есть задачи, с которыми вам могут помочь другие люди, так и есть задачи, которые не должен выполнять ни один человек. Роботы — ваши друзья. Используйте их, чтобы облегчить себе жизнь в качестве мейнтейнера.
 
-### Требовать тесты и другие проверки для улучшения качества вашего кода
+### Требуйте тесты и другие проверки для улучшения качества кода
 
-Один из наиболее важных способов автоматизации проекта - это добавление тестов.
+Один из наиболее важных способов автоматизации проекта — это написание тестов.
 
-Тесты помогают участникам быть уверенными в том, что они ничего не сломают. Они также облегчают вам быстрый просмотр и принятие материалов. Чем более отзывчивым вы будете, тем более заинтересованным может быть ваше сообщество.
+Тесты помогают участникам чувствовать себя уверенно в том, что в результате новых изменений ничего не было сломано. Они также облегчают рассмотрение и принятие вкладов. Чем активнее вы будете реагировать, тем более заинтересованным может быть ваше сообщество.
 
-Настройте автоматические тесты, которые будут запускаться для всех входящих вкладов, и убедитесь, что ваши тесты могут легко запускаться локально участниками. Требуйте, чтобы все дополнения кода прошли ваши тесты, прежде чем их можно будет отправить. Вы поможете установить минимальный стандарт качества для всех представленных материалов. [Обязательные проверки статуса](https://help.github.com/articles/about-required-status-checks/) на GitHub могут помочь гарантировать, что никакие изменения не будут объединены без прохождения ваших тестов.
+Настройте автотесты, которые будут запускаться на всех входящих вкладов, и убедитесь, что они могут быть выполнены контрибьюторами локально. Требуйте, чтобы весь код от контрибьюторов проходил тесты, до того, как они отправлять сам вклад. Вы поможете установить минимальный стандарт качества для всех отправляемых вкладов. [Обязательные проверки статуса](https://help.github.com/articles/about-required-status-checks/) на GitHub помогут проследить за тем, что никакие изменения не будут объединены без прохождения тестов.
 
-Если вы добавляете тесты, обязательно объясните, как они работают в вашем файле CONTRIBUTING (руководство участника).
+Если вы добавляете тесты, обязательно объясните, как они работают в файле CONTRIBUTING.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/edunham?s=180" class = "pquote-avatar" alt = "avatar">
-  Я считаю, что тесты необходимы для всего кода, над которым работают люди. Если бы код был полностью и совершенно правильным, он не нуждался бы в изменениях - мы пишем код только тогда, когда что-то не так, будь то «сбой» или «в нем отсутствует такая-то функция». И независимо от того, какие изменения вы вносите, тесты необходимы для выявления любых регрессий, которые вы можете случайно ввести.
-  <p markdown = "1" class = "pquote-credit">
+<aside markdown="1" class="pquote">
+  <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)
   </p>
 </aside>
 
 ### Используйте инструменты для автоматизации основных задач сопровождения
 
-Хорошая новость о поддержке популярного проекта заключается в том, что другие сопровождающие, вероятно, сталкивались с аналогичными проблемами и создали для них решение.
+Что хорошо в поддержке популярного проекта, так это то, что другие мейнтейнеры, вероятно, сталкивались с аналогичными проблемами и решили их.
 
-Существует [множество доступных инструментов](https://github.com/showcases/tools-for-open-source), которые помогают автоматизировать некоторые аспекты работ по сопровождению. Несколько примеров:
+Существует [множество инструментов](https://github.com/showcases/tools-for-open-source), которые помогают автоматизировать некоторые аспекты работ по сопровождению. Несколько примеров:
 
-* [semantic-release](https://github.com/semantic-release/semantic-release) автоматизирует ваши выпуски (release).
-* [mention-bot](https://github.com/facebook/mention-bot) упоминает потенциальных рецензентов для запросов на перенос (pull request).
-* [Danger](https://github.com/danger/danger) помогает автоматизировать проверку кода.
-* [no-response](https://github.com/probot/no-response) закрывает проблемы, когда автор не ответил на запрос дополнительной информации.
-* [dependabot-preview](https://github.com/marketplace/dependabot-preview) проверяет ваши файлы зависимостей каждый день на наличие устаревших требований и если находит, то открывает для них индивидуальные запросы на перенос.
+* [semantic-release](https://github.com/semantic-release/semantic-release) автоматизирует ваши релизы
+* [mention-bot](https://github.com/facebook/mention-bot) упоминает потенциальных ревьюеров для пул-реквеста
+* [Danger](https://github.com/danger/danger) помогает автоматизировать проверку кода
+* [no-response](https://github.com/probot/no-response) закрывает ишью, если автор не не предоставил дополнительную информацию
+* [dependabot-preview](https://github.com/marketplace/dependabot-preview) ежедневно следует за актуальностью зависимостей, и если находит что-то новое, то открывает отдельные пул-реквесты
 
-Для отчетов об ошибках и других общих материалов на GitHub есть [Шаблоны проблем (issue) и шаблоны запросов на перенос (pull request)](https://github.com/blog/2111-issue-and-pull-request-templates), которые вы можете создать для упрощения взаимодействия с сообществом. @TalAter создал [Руководство по выбору своего собственного приключения](https://www.talater.com/open-source-templates/#/), чтобы помочь вам написать свою проблему и шаблоны запросов на перенос (pull request).
+Для сообщений об ошибках и других общих проблем на GitHub есть [шаблоны для ишью и пул-реквеста](https://github.com/blog/2111-issue-and-pull-request-templates), которые можно создать для упрощения взаимодействия с сообществом. @TalAter создал [руководство Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/), чтобы помочь вам написать собственные шаблоны ишью и пул-реквеста.
 
-Для управления уведомлениями по электронной почте вы можете настроить [фильтры электронной почты](https://github.com/blog/2203-email-updates-about-your-own-activity) для сортировки по приоритету.
+Для управления уведомлениями по электронной почте вы можете настроить [фильтры электронной почты](https://github.com/blog/2203-email-updates-about-your-own-activity), чтобы отсортировать их по приоритету.
 
-Если вы хотите стать немного более продвинутым, руководства по стилю и линтеры могут стандартизировать вклады в проект и упростить их просмотр и принятие.
+Если вы хотите ещё немного продвинуться, руководства по стилю и линтеры помогут стандартизировать вклады в проект и упростить их просмотр и принятие.
 
-Однако, если ваши стандарты слишком сложны, они могут увеличить препятствия на пути к участию. Убедитесь, что вы добавляете достаточно правил, чтобы облегчить всем жизнь.
+Однако, если ваши стандарты слишком сложные, они могут увеличить препятствия на пути к участию. Убедитесь, что вы добавляете только необходимые правила, чтобы облегчить всем жизнь.
 
-Если вы не знаете, какие инструменты использовать, посмотрите, что делают другие популярные проекты, особенно в вашей экосистеме. Например, как выглядит процесс участия для других модулей Node? Использование подобных инструментов и подходов также сделает ваш процесс более знакомым для ваших целевых участников.
+Если вы не знаете, какие инструменты использовать, посмотрите на опыт других популярных проектов, особенно в вашей экосистеме. Например, как выглядит процесс участия в других модулей Node? Использование похожих инструментов и подходов также сделает ваш процесс более знакомым для потенциальных контрибьюторов.
 
-## Нажать паузу - это нормально
+## Взять паузу — это нормально
 
-Когда-то работа с открытым исходным кодом приносила вам радость. Может быть, теперь вы начинаете чувствовать себя избегающим или виноватым.
+Когда-то опенсорс-работа приносила вам радость. А возможно теперь вы начинаете чувствовать себя виноватым или не идите на контакт.
 
-Возможно, вы чувствуете себя подавленным или чувствуете растущее чувство страха, когда думаете о своих проектах. А между тем проблемы (issues) и запросы на перенос (pull request) накапливаются.
+Возможно, вы чувствуете себя разбитым или вас не покидает растущее чувство страха, когда думаете о своих проектах. А между тем ишью и пул-реквесты накапливаются.
 
-Выгорание - реальная и распространенная проблема в работе с открытым исходным кодом, особенно среди сопровождающих. Ваше счастье как сопровождающего - непреложное условие для выживания любого проекта с открытым исходным кодом.
+Выгорание — реальная и распространенная проблема при работе над опенсорсом, особенно среди мейнтейнеов. Ваше счастье как мейнтейнера — непреложное условие для выживания любого опенсорс-проекта.
 
-Это ясно без слов, если устали - сделайте перерыв! Вам не нужно ждать, пока вы почувствуете выгорание, чтобы взять отпуск. @brettcannon, разработчик ядра Python, решил взять [отпуск на месяц](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) после 14 лет волонтерской работы в открытом исходном коде.
+Хотя это само собой разумеется, но делайте перерыв! Не нужно ждать, пока вы почувствуете выгорание, чтобы взять отпуск. @brettcannon, разработчик ядра Python, решил взять [отпуск на месяц](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) после 14 лет волонтерской работы в опенсорсе.
 
-Как и любой другой вид работы, регулярные перерывы будут держать вас бодрым, счастливым и воодушевленным своей работой.
+Как и любой другой вид работы, регулярные перерывы позволяют вам оставаться бодрым, счастливым и увлечённым своей работой.
 
-<aside markdown = "1" class = "pquote">
-  <img src = "https://avatars.githubusercontent.com/danielbachhuber?s=180" class = "pquote-avatar" alt = "avatar">
-  Поддерживая WP-CLI, я обнаружил, что мне нужно сначала сделать себя счастливым, и установить четкие границы своего участия. Наилучший баланс, который я нашел, - это 2-5 часов в неделю как часть моего обычного рабочего графика. Это сохраняет мое увлечение страстью, и не возникает ощущения работы. Поскольку я уделяю приоритетное внимание вопросам, над которыми работаю, я могу регулярно добиваться прогресса в том, что считаю наиболее важным.
-  <p markdown = "1" class = "pquote-credit">
-- @danielbachhuber, [«Мои соболезнования, теперь вы поддерживаете популярный проект с открытым исходным кодом»](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
+  Поддерживая WP-CLI, я обнаружил, что мне нужно сначала сделать себя счастливым, и установить четкие границы своего участия. Наилучший баланс, который я нашел, — это 2-5 часов в неделю из моего обычного рабочего графика. Таким образом я остаюсь увлечённым и не слишком перенапрягаюсь. Поскольку я расставляю приоритеты в ишью, над которыми работаю, я могу регулярно добиваться прогресса в том, что считаю наиболее важным.
+  <p markdown="1" class="pquote-credit">
+- @danielbachhuber, [«Мои соболезнования, теперь вы поддерживаете популярный опенсорс-проект»](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
-Иногда бывает трудно сделать перерыв в работе с открытым исходным кодом, когда кажется, что вы нужны всем. Люди могут даже попытаться заставить вас почувствовать себя виноватым за то, что вы отступили.
+Иногда бывает трудно сделать перерыв в опенсорс-работе, когда кажется, что вы нужны всем. Люди могут даже попытаться заставить вас почувствовать себя виноватым за то, что вы временно отошли от дел.
 
-Сделайте все возможное, чтобы найти поддержку для своих пользователей и сообщества, пока вы не участвуете в проекте. Если вы не можете найти необходимую поддержку, все равно сделайте перерыв. Обязательно предупреждайте, перед тем как стать недоступным, чтобы людей не смущало отсутствие вашей реакции.
+Постарайтесь найти поддержку для своих пользователей и сообщества на время вашего отсутствия в проекте. Если вы не можете найти необходимую поддержку, всё равно возьмите паузу. Но обязательно предупредите людей об вашем отпуске, чтобы их не смущало отсутствие вашей реакции.
 
-Перерывы относятся не только к отпуску. Если вы не хотите заниматься разработкой с открытым исходным кодом по выходным или в рабочее время, сообщите об этих ожиданиях другим, чтобы они знали, что вас не надо беспокоить.
+Перерывы относятся не только к отпуску. Если вы не хотите заниматься опенсорсом по выходным или в рабочее время, сообщите об этом людям, чтобы они знали, что вас не надо беспокоить.
 
 ## Береги себя в первую очередь!
 
-Поддержание популярного проекта требует иных навыков, чем на ранних этапах развития, но это не уменьшает пользу описанных выше советов. Как сопровождающий, вы будете практиковать лидерство и личные навыки на уровне, который мало кто сможет испытать. Хотя этим не всегда легко управлять, установление четких границ и принятие только того, что вам удобно, помогут вам оставаться счастливыми, бодрыми и продуктивными.
+Поддержка популярного проекта требует иных навыков, чем на ранних этапах развития, но это не уменьшает пользу описанных выше советов. Как мейнтейнер, вы будете практиковать лидерские и личные навыки на таком уровне, который мало кому удаётся испытать. Хотя управлять проектом не всегда легко, выстраивание чётких границ и адекватная оценка своих сил, помогут вам оставаться счастливыми, бодрыми и продуктивными.

From 5e34577630f0b2bfe9cdb199309d441120cbefcd Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Mon, 27 Sep 2021 22:02:41 +0300
Subject: [PATCH 254/749] Fix links

---
 _articles/ru/best-practices.md     | 8 ++++----
 _articles/ru/building-community.md | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md
index 14630a589b5..c86b4b4b52e 100644
--- a/_articles/ru/best-practices.md
+++ b/_articles/ru/best-practices.md
@@ -6,10 +6,10 @@ class: best-practices
 toc:
   что-значит-быть-мейнтейнером: 'Что значит быть мейнтейнером?'
   документирование-процессов: 'Документирование процессов'
-  учитесь-говорить-нет: 'Учитесь говорить «нет»'
+  научитесь-говорить-нет: 'Научитесь говорить «нет»'
   используйте-силу-сообщества: 'Используйте силу сообщества'
   задействуйте-роботов: 'Задействуйте роботов'
-  взять-паузу---это-нормально: 'Взять паузу — это нормально'
+  взять-паузу-это-нормально: 'Взять паузу — это нормально'
 order: 5
 image: /assets/images/cards/best-practices.png
 related:
@@ -25,7 +25,7 @@ related:
 
 Для поддержки проекта требуется нечто большее, чем просто код. Эти задачи часто бывают неожиданными, но они не менее важны для растущего проекта. Мы собрали несколько способов облегчить вашу жизнь — от документирования процессов до привлечения вашего сообщества.
 
-## Документирование ваших процессов
+## Документирование процессов
 
 Как мейнтейнеру вам предстоит много писать, — это одна из наиболее главных ваших задач.
 
@@ -243,7 +243,7 @@ related:
 * [semantic-release](https://github.com/semantic-release/semantic-release) автоматизирует ваши релизы
 * [mention-bot](https://github.com/facebook/mention-bot) упоминает потенциальных ревьюеров для пул-реквеста
 * [Danger](https://github.com/danger/danger) помогает автоматизировать проверку кода
-* [no-response](https://github.com/probot/no-response) закрывает ишью, если автор не не предоставил дополнительную информацию
+* [no-response](https://github.com/probot/no-response) закрывает ишью, если автор не предоставил дополнительную информацию
 * [dependabot-preview](https://github.com/marketplace/dependabot-preview) ежедневно следует за актуальностью зависимостей, и если находит что-то новое, то открывает отдельные пул-реквесты
 
 Для сообщений об ошибках и других общих проблем на GitHub есть [шаблоны для ишью и пул-реквеста](https://github.com/blog/2111-issue-and-pull-request-templates), которые можно создать для упрощения взаимодействия с сообществом. @TalAter создал [руководство Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/), чтобы помочь вам написать собственные шаблоны ишью и пул-реквеста.
diff --git a/_articles/ru/building-community.md b/_articles/ru/building-community.md
index 9a829452ded..0b701777cd6 100644
--- a/_articles/ru/building-community.md
+++ b/_articles/ru/building-community.md
@@ -39,7 +39,7 @@ related:
 * **Когда кто-то новый попадает в ваш проект, поблагодарите его за проявленный интерес!** Достаточно одного негативного опыта, чтобы кто-то не захотел возвращаться.
 * **Будьте отзывчивы.** Если вы не отвечаете на их вопрос в течение месяца, скорее всего, они уже забыли о вашем проекте.
 * **Будьте открыты в отношении помощи, которую вы примете.** Многие участники начинают с отчета об ошибке или небольшого исправления. Есть [много способов внести свой вклад](../how-to-contribute/#что-значит-внести-свой-вклад) в проект. Позвольте людям помочь так, как они хотят помочь.
-* **Если есть предложение, с которым вы не согласны,** поблагодарите их за идею и [объясните, почему](../best-practices/#учитесь-говорить-нет), это не вписывается в рамки проекта со ссылкой на соответствующую документацию, если она у вас есть.
+* **Если есть предложение, с которым вы не согласны,** поблагодарите их за идею и [объясните, почему](../best-practices/#научитесь-говорить-нет), это не вписывается в рамки проекта со ссылкой на соответствующую документацию, если она у вас есть.
 
 <aside markdown = "1" class = "pquote">
   <img src = "https://avatars.githubusercontent.com/mikeal?s=180" class = "pquote-avatar" alt = "avatar">

From 3478d673347e626906cdfce8f6433aecae114d77 Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Mon, 27 Sep 2021 22:06:55 +0300
Subject: [PATCH 255/749] Fixes

---
 _articles/ru/best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md
index c86b4b4b52e..344c29106fe 100644
--- a/_articles/ru/best-practices.md
+++ b/_articles/ru/best-practices.md
@@ -9,7 +9,7 @@ toc:
   научитесь-говорить-нет: 'Научитесь говорить «нет»'
   используйте-силу-сообщества: 'Используйте силу сообщества'
   задействуйте-роботов: 'Задействуйте роботов'
-  взять-паузу-это-нормально: 'Взять паузу — это нормально'
+  взять-паузу--это-нормально: 'Взять паузу — это нормально'
 order: 5
 image: /assets/images/cards/best-practices.png
 related:

From 6bddd846fcdac084972a938b7549c30aa4dfbfe6 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 27 Sep 2021 21:29:29 +0000
Subject: [PATCH 256/749] Bump nokogiri from 1.12.3 to 1.12.5

Bumps [nokogiri](https://github.com/sparklemotion/nokogiri) from 1.12.3 to 1.12.5.
- [Release notes](https://github.com/sparklemotion/nokogiri/releases)
- [Changelog](https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md)
- [Commits](https://github.com/sparklemotion/nokogiri/compare/v1.12.3...v1.12.5)

---
updated-dependencies:
- dependency-name: nokogiri
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 2485486f3c8..277074e4049 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -234,7 +234,7 @@ GEM
       jekyll-seo-tag (~> 2.1)
     minitest (5.14.4)
     multipart-post (2.1.1)
-    nokogiri (1.12.3)
+    nokogiri (1.12.5)
       mini_portile2 (~> 2.6.1)
       racc (~> 1.4)
     nokogumbo (2.0.5)

From 50ab44ce4e67d92edede3b5d77634c2e7cfa83e5 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 28 Sep 2021 08:06:22 +0000
Subject: [PATCH 257/749] Bump actions/setup-node from 2.4.0 to 2.4.1

Bumps [actions/setup-node](https://github.com/actions/setup-node) from 2.4.0 to 2.4.1.
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/v2.4.0...v2.4.1)

---
updated-dependencies:
- dependency-name: actions/setup-node
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 0157bc35d0e..ce7f850bf40 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -14,7 +14,7 @@ jobs:
       uses: actions/setup-ruby@v1.1.3
 
     - name: Set up Node
-      uses: actions/setup-node@v2.4.0
+      uses: actions/setup-node@v2.4.1
 
     - name: Restore bundler cache
       uses: actions/cache@v2.1.6

From 5cc6e27f85a26d1b31835c158715d15fbe7a252d Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 4 Oct 2021 08:05:16 +0000
Subject: [PATCH 258/749] Bump github-pages from 219 to 220

Bumps [github-pages](https://github.com/github/pages-gem) from 219 to 220.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v219...v220)

---
updated-dependencies:
- dependency-name: github-pages
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 277074e4049..05aaed1e9b4 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -26,7 +26,7 @@ GEM
       ffi (>= 1.15.0)
     eventmachine (1.2.7)
     execjs (2.8.1)
-    faraday (1.7.0)
+    faraday (1.8.0)
       faraday-em_http (~> 1.0)
       faraday-em_synchrony (~> 1.0)
       faraday-excon (~> 1.1)
@@ -45,11 +45,11 @@ GEM
     faraday-net_http_persistent (1.2.0)
     faraday-patron (1.0.0)
     faraday-rack (1.0.0)
-    ffi (1.15.3)
+    ffi (1.15.4)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (219)
-      github-pages-health-check (= 1.17.7)
+    github-pages (220)
+      github-pages-health-check (= 1.17.9)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
       jekyll-coffeescript (= 1.1.1)
@@ -92,7 +92,7 @@ GEM
       nokogiri (>= 1.10.4, < 2.0)
       rouge (= 3.26.0)
       terminal-table (~> 1.4)
-    github-pages-health-check (1.17.7)
+    github-pages-health-check (1.17.9)
       addressable (~> 2.3)
       dnsruby (~> 1.60)
       octokit (~> 4.0)
@@ -278,8 +278,8 @@ GEM
       thread_safe (~> 0.1)
     unf (0.1.4)
       unf_ext
-    unf_ext (0.0.7.7)
-    unicode-display_width (1.7.0)
+    unf_ext (0.0.8)
+    unicode-display_width (1.8.0)
     yell (2.2.2)
     zeitwerk (2.4.2)
 

From 7763dc509754d8fec3a7a02b54cc2b7f987cbee3 Mon Sep 17 00:00:00 2001
From: Alexey Pyltsyn <lex61rus@gmail.com>
Date: Mon, 4 Oct 2021 17:56:22 +0300
Subject: [PATCH 259/749] Rename toc.html to jekyll-toc.html

---
 _includes/{toc.html => jekyll-toc.html} | 2 +-
 _layouts/article.html                   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename _includes/{toc.html => jekyll-toc.html} (98%)

diff --git a/_includes/toc.html b/_includes/jekyll-toc.html
similarity index 98%
rename from _includes/toc.html
rename to _includes/jekyll-toc.html
index 78aa4ab2a9c..662fe88ba7e 100644
--- a/_includes/toc.html
+++ b/_includes/jekyll-toc.html
@@ -30,7 +30,7 @@
         "...like all things liquid - where there's a will, and ~36 hours to spare, there's usually a/some way" ~jaybe
 
         Usage:
-            {% include toc.html html=content sanitize=true class="inline_toc" id="my_toc" h_min=2 h_max=3 %}
+            {% include jekyll-toc.html html=content sanitize=true class="inline_toc" id="my_toc" h_min=2 h_max=3 %}
 
         Parameters:
             * html         (string) - the HTML of compiled markdown generated by kramdown in Jekyll
diff --git a/_layouts/article.html b/_layouts/article.html
index 63a966170b5..328bbcbb3ec 100644
--- a/_layouts/article.html
+++ b/_layouts/article.html
@@ -14,7 +14,7 @@ <h1 class="h0-mktg lh-condensed text-center mb-3">{{ page.title }}</h1>
         <a class="toc-trigger d-block text-center p-3">
           <span class="text-black">{{ t.article.table_of_contents }}</span><svg height="18" class="octicon octicon-triangle-down ml-2 fill-blue v-align-middle icon-flip" viewBox="0 0 12 16" version="1.1" width="13" role="img"><path fill-rule="evenodd" d="M0 5l6 6 6-6z"></path></svg>
         </a>
-        {% include toc.html html=content h_max=2 ordered=true class="toc-list list-style-none" item_class="border-top" anchor_class="d-block py-3 px-3" %}
+        {% include jekyll-toc.html html=content h_max=2 ordered=true class="toc-list list-style-none" item_class="border-top" anchor_class="d-block py-3 px-3" %}
       </div>
     </nav>
     <div class="col-sm-10 mx-auto lh-none cover-img">

From 6ea796549063ed8b785a29be65d3f24a954c4fd4 Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Fri, 8 Oct 2021 08:38:06 +0330
Subject: [PATCH 260/749] =?UTF-8?q?=D9=88=DB=8C=D8=B1=D8=A7=DB=8C=D8=B4=20?=
 =?UTF-8?q?=DA=A9=D9=84=D9=85=D8=A7=D8=AA=20=D9=88=20=D8=AC=D9=85=D9=84?=
 =?UTF-8?q?=D9=87=20=D9=87=D8=A7?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

سلام
در ابتدا از ترجمه خوبتان تشکر میکنم
املای بعضی کلمه ها را تصحیح کردم و همچنین برای اصلاح بهم ریختگی جملات کلمه های انگلیسی را در تگ قرار دادم.
موفق و پیروز باشید.
---
 _articles/fa/how-to-contribute.md | 120 +++++++++++++++---------------
 1 file changed, 60 insertions(+), 60 deletions(-)

diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 566da47c8aa..7c7ead6cc3d 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -14,7 +14,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
-  کار کردن در Freenode به من در یادگیری بسیاری از مهارت‌ها کمک کرد و توانستم از آن‌ها در تحقیقات دانشگاهی و شغلم استفاده کنم. فکر می‌کنم به همان اندازه که کار کردن روی پروژه‌های متن باز به پیشبرد پروژه کمک می‌کند به همان اندازه به من هم کمک می‌کند!
+  کار کردن در <span dir="rtl">Freenode</span> به من در یادگیری بسیاری از مهارت‌ها کمک کرد و توانستم از آن‌ها در تحقیقات دانشگاهی و شغلم استفاده کنم. فکر می‌کنم به همان اندازه که کار کردن روی پروژه‌های متن باز به پیشبرد پروژه کمک می‌کند به همان اندازه به من هم کمک می‌کند!
   <p markdown="1" class="pquote-credit">
 — @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
   </p>
@@ -26,7 +26,7 @@ related:
 
 ### نرم‌افزاری که به آن متکی هستید را بهبود می‌دهید
 
-مشارکت‌کننده‌ها مشارکت خود از پروژه‌هایی شروع می‌کنند که کاربر آن می‌شوند. زمانی که در نرم‌افزار یک پروژه‌ی متن باز باگ یا خطایی مشاهده کردید، در صورتی که توانایی برطرف کردن آن را داشته باشید می‌توانید به سرس کد آن نگاهی بیندازید و خودتان اصلاحیه‌ای برایش بنویسید. اگر با چنین موردی روبه‌رو شدید، مشارکت در اصلاح آن باگ بهترین راه برای مطمئن کردن دوستان (و خودتان مخصوصاً زمانی که نسخه‌ی بعدی آن به روز شود) باشد که می‌تواند مزیت‌های داشته باشد.
+مشارکت‌کننده‌ها مشارکت خود از پروژه‌هایی شروع می‌کنند که کاربر آن می‌شوند. زمانی که در نرم‌افزار یک پروژه‌ی متن باز باگ یا خطایی مشاهده کردید، در صورتی که توانایی برطرف کردن آن را داشته باشید می‌توانید به سورس کد آن نگاهی بیندازید و خودتان اصلاحیه‌ای برایش بنویسید. اگر با چنین موردی روبه‌رو شدید، مشارکت در اصلاح آن باگ بهترین راه برای مطمئن کردن دوستان (و خودتان مخصوصاً زمانی که نسخه‌ی بعدی آن به روز شود) باشد که می‌تواند مزیت‌های داشته باشد.
 
 ### مهارت‌های موجودتان تقویت می‌شود
 
@@ -34,11 +34,11 @@ related:
 
 ### با افرادی ملاقات می‌کنید که علایق‌شان با شما مشابه است
 
-پروژه‌های متن باز با انجمن‌های گرم و گیرایش باعث می‌شود افرادی که در آن حضور دارند برای سال‌ها به آن مراجعه کنند. حتی بسیاری هستند که به واسطه‌ی همکاری‌شان در راه‌اندازی کنفرانس‌ها یا چت‌های آنلاین شبانه‌شان درباره‌ی burritos ، روابط دوستانه‌ی طولانی مدتی دارند.
+پروژه‌های متن باز با انجمن‌های گرم و گیرایش باعث می‌شود افرادی که در آن حضور دارند برای سال‌ها به آن مراجعه کنند. حتی بسیاری هستند که به واسطه‌ی همکاری‌شان در راه‌اندازی کنفرانس‌ها یا چت‌های آنلاین شبانه‌شان درباره‌ی <span dir="rtl">burritos</span> ، روابط دوستانه‌ی طولانی مدتی دارند.
 
 ### استاد پیدا می‌کنید و به دیگران آموزش می‌دهید
 
-کار کردن با دیگران در پروژه‌های مشترک شما را مجبور می‌کند نحوه‌ی انجام دادن کارها را توضیح دهید و به همان اندازه هم از دیگران کمک بخواهید. هر کسی می‌تواند خود را درگیری فعالیت‌های یادگیری و آموزشی کند.
+کار کردن با دیگران در پروژه‌های مشترک شما را مجبور می‌کند نحوه‌ی انجام دادن کارها را توضیح دهید و به همان اندازه هم از دیگران کمک بخواهید. هر کسی می‌تواند خود را درگیرِ فعالیت‌های یادگیری و آموزشی کند.
 
 ### محصولی عمومی تولید کنید که به رشد اعتبار و حرفه‌ی کاری‌تان کمک کند
 
@@ -46,11 +46,11 @@ related:
 
 ### مهارت‌های دیگران را یاد می‌گیرید
 
-روژه‌های متن باز فرصتی فراهم می‌کنند که به واسطه‌ی آن می‌توانید مهارت‌های مدیریت و رهبری پروژه‌ی خود مانند برطرف کردن تضادها، سازماندهی کردن تیم و اولیت بندی کارها، را تقویت کنید.
+پروژه‌های متن باز فرصتی فراهم می‌کنند که به واسطه‌ی آن می‌توانید مهارت‌های مدیریت و رهبری پروژه‌ی خود مانند برطرف کردن تضادها، سازماندهی کردن تیم و اولویت بندی کارها، را تقویت کنید.
 
 ### به شما قدرت اعمال تغییرات هرچند کوچک را می‌دهد
 
-لازم نیست برای لذت بردن از همکاری در یک پروژه‌ی متن باز، به یک مشارکت‌کننده‌ی درازمدت تبدیل شوید. تا حالا شده در یک وب‌سایت چند غلط‌های املائی ببینید و دوست داشتید یک نفر آن را اصلاح کند؟ خب، گر چنین حالتی برای پروژه‌تان به وجود بیاید، به راحتی می‌توانید آن را برطرف کنید. پروژه‌ی متن باز می‌تواند به افراد کمک کند تا شرکتی که در آن فعالیت می‌کنند و نحوه‌ی کسب کردن تجربه‌شان را از زندگی خود مهم‌تر بدانند و همین مسئله حس رضایت‌بخشی به آن‌ها می‌دهد.
+لازم نیست برای لذت بردن از همکاری در یک پروژه‌ی متن باز، به یک مشارکت‌کننده‌ی درازمدت تبدیل شوید. تا حالا شده در یک وب‌سایت چند غلط‌ املائی ببینید و دوست داشتید یک نفر آن را اصلاح کند؟ خب، اگر چنین حالتی برای پروژه‌تان به وجود بیاید، به راحتی می‌توانید آن را برطرف کنید. پروژه‌ی متن باز می‌تواند به افراد کمک کند تا شرکتی که در آن فعالیت می‌کنند و نحوه‌ی کسب کردن تجربه‌شان را از زندگی خود مهم‌تر بدانند و همین مسئله حس رضایت‌بخشی به آن‌ها می‌دهد.
 
 ## مشارکت به چه معناست؟
 
@@ -64,7 +64,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
-  من شهرتم را از کار در CocoaPods به دست آوردم، اما بیشتر مردم نمی‌دانند که من واقعاً هیچ کار واقعی با ابزار CocoaPods انجام نمی‌دادم. زمانم در آن پروژه بیشتر روی چیزهایی مانند اسناد یا کار روی برندسازی صرف می‌شد.
+  من شهرتم را از کار در <span dir="rtl">CocoaPods</span> به دست آوردم، اما بیشتر مردم نمی‌دانند که من واقعاً هیچ کار واقعی با ابزار <span dir="rtl">CocoaPods</span> انجام نمی‌دادم. زمانم در آن پروژه بیشتر روی چیزهایی مانند اسناد یا کار روی برندسازی صرف می‌شد.
   <p markdown="1" class="pquote-credit">
 — @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
   </p>
@@ -74,7 +74,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  زمانی که درخواست مشارکتم را در 17 ژوئن سال 2002 به تیم توسعه‌ی پایتون با نام مستعار (python-dev) ارسال کردم، توانستم اولین مشارکتم را با آن‌ها شروع کنم. به سرعت باگ‌ها و خطاهای پروژه‌ی متن باز را پیدا می‌کردم و تصمیم می‌گرفتم خلاصه‌های آن را برای گروه تنظیم کردم. آن‌ها بهانه‌های زیادی می‌آوردند که یک موضوع را روشن کنم، اما با تمام انتقادات، زمانی که هر کسی برای برطرف کردن یک مشکل به کمک نیاز داشت، من آن را متوجه می‌شدم.
+  زمانی که درخواست مشارکتم را در 17 ژوئن سال 2002 به تیم توسعه‌ی پایتون با نام مستعار <span dir="rtl">(python-dev)</span> ارسال کردم، توانستم اولین مشارکتم را با آن‌ها شروع کنم. به سرعت باگ‌ها و خطاهای پروژه‌ی متن باز را پیدا می‌کردم و تصمیم می‌گرفتم خلاصه‌های آن را برای گروه تنظیم کنم. آن‌ها بهانه‌های زیادی می‌آوردند که یک موضوع را روشن کنم، اما با تمام انتقادات، زمانی که هر کسی برای برطرف کردن یک مشکل به کمک نیاز داشت، من آن را متوجه می‌شدم.
   <p markdown="1" class="pquote-credit">
 — @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
   </p>
@@ -82,15 +82,15 @@ related:
 
 ### آیا به برگزاری رویدادها علاقه‌مند هستید؟
 
-* ورکشاپ (کارگاه‌ها) را سازماندهی یا جلسات پروژه را برگزار کنید، مانند کاری که @fzamperin برای [NodeSchool](https://github.com/nodeschool/organizers/issues/406) انجام داد
-* در صورت داشتن، برای یک پروژه کنفرانس برگزار کنید
+* ورکشاپ‌ها (کارگاه‌ها) را سازماندهی یا جلسات پروژه را برگزار کنید، مانند کاری که @fzamperin برای  [NodeSchool](https://github.com/nodeschool/organizers/issues/406) انجام داد
+* در صورت امکان، برای یک پروژه کنفرانس برگزار کنید
 * به اعضای انجمن کمک کنید تا کنفرانس‌های درستی پیدا و برای کنفرانس پرپوزال خود را ارسال کنند.
 
 ### آیا به طراحی علاقه‌مند هستید؟
 
 * با هدف افزایش قابلیت استفاده به بهبود ساختار برنامه ها کمک کنید.
 * مشابه [دروپال](https://www.drupal.org/community-initiatives/drupal-core/usability) می‌توانید با هدف بهبود رابط کاربری اقدام به کاربرپژوهی و مطالعاتی از این دست کنید. 
-* با جمع آوری و یک کاسه کردن الگوهای طراحی به کار گرفته شده در پروژه یک شیونه نامه (استایل گاید) متمرکز ایجاد کنید.
+* با جمع آوری و یک کاسه کردن الگوهای طراحی به کار گرفته شده در پروژه یک شیوه‌نامه (استایل گاید) متمرکز ایجاد کنید.
 * اقدام به خلق کارهای هنری مثل طراحی لوگو یا تی شرت مخصوص کنید. مثل کاری که [hapi.js](https://github.com/hapijs/contrib/issues/68) انجام داد.
 
 ### آیا به نویسندگی در پروژه علاقه‌مند هستید؟
@@ -103,7 +103,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
-  اسناد یک پروژه به طور جدی مهم هستند. اسناد پروژه تا به الان عالی پیش رفتند و یکی از ویژگی‌های بی‌نظیر Babel نیز بوده است. بخش‌هایی در اسناد یک پروژه وجود دارد که مطمئناً می‌تواند از آن در برخی کارها استفاده کرد، حتی افزودن یک پاراگراف در این‌جا یا آن‌جا بی‌نهایت قایل تقدیر است.
+  اسناد یک پروژه به طور جدی مهم هستند. اسناد پروژه تا به الان عالی پیش رفتند و یکی از ویژگی‌های بی‌نظیر<span dir="rtl">Babel</span> نیز بوده است. بخش‌هایی در اسناد یک پروژه وجود دارد که مطمئناً می‌تواند از آن در برخی کارها استفاده کرد، حتی افزودن یک پاراگراف در این‌جا یا آن‌جا بی‌نهایت قایل تقدیر است.
   <p markdown="1" class="pquote-credit">
 — @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
   </p>
@@ -112,19 +112,19 @@ related:
 ### آیا به سازماندهی پروژه علاقه‌مند هستید؟
 
 * برای سازماندهی کردن همه چیز، مشکلات تکراری را لینک کنید و مسائل جدیدی مطرح کنید
-* با مسئله‌های (issue) باز رودرو شوید و پیشنهاد دهید مسائل قدیمی حل شوند، مانند کاری که @nzakas برای [ESLin](https://github.com/eslint/eslint/issues/6765) انجام داد
+* با مسئله‌های (issue) باز رودرو شوید و پیشنهاد دهید مسائل قدیمی حل شوند، مانند کاری که <span dir="rtl">@nzakas</span> برای [ESLin](https://github.com/eslint/eslint/issues/6765) انجام داد
 * برای پیشبرد بحث، سوالات شفافی درباره‌ی مسائل باز اخیر بپرسید
 
 ### آیا به کدنویسی علاقه دارید؟
 
-* مسائل باز و حل نشده را پیدا و حل کنید، مانند کاری که @dianjin برای [Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) انجام داد
+* مسائل باز و حل نشده را پیدا و حل کنید، مانند کاری که <span dir="rtl">@dianjin</span> برای [Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) انجام داد
 * اگر می‌توانید برای اعمال یک ویژگی جدید به پروژه کمک کنید، درخواست‌تان را مطرح کنید
 * نصب پروژه را خودکار کنید
 * ابزارهای مرتبط و تسهیل کننده و تست پروژه را تقویت کنید
 
 ### آیا از کمک کردن به مردم لذت می‌برید؟
 
-* به سوالاتی که افراد درباره‌ی پروژه در سایت‌هایی مانند Stack، Postgres، یا Reddit می‌پرسند، جواب بدهید 
+* به سوالاتی که افراد درباره‌ی پروژه در سایت‌هایی مانند <span dir="rtl">Stack، Postgres، یا Reddit</span> می‌پرسند، جواب بدهید 
 * سوالات افرادی که مسائل حل نشده‌ای دارند را جواب بدهید
 * در اداره کانال‌های گفتگو و تالارهای گفتمان مشارکت کنید
 
@@ -150,7 +150,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
-  اگر به یک ایشو ترکر (issue tracker) برخوردید و چیزهای گیج‌کننده‌ای دیدید، نگران نباشید چون شما تنها نیستید. این ابزارها به دانش ضمنی زیادی نیاز دارند، اما سایرین می‌توانند به شما کمک کند و می‌توانید از آن‌ها سوالاتی بپرسید.
+  اگر به یک ایشو ترکر <span dir="rtl">(issue tracker)</span> برخوردید و چیزهای گیج‌کننده‌ای دیدید، نگران نباشید چون شما تنها نیستید. این ابزارها به دانش ضمنی زیادی نیاز دارند، اما سایرین می‌توانند به شما کمک کند و می‌توانید از آن‌ها سوالاتی بپرسید.
   <p markdown="1" class="pquote-credit">
 — @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
   </p>
@@ -176,22 +176,22 @@ related:
 * **مشارکت‌کننده:** هر کسی که در پروژه مشارکت داشته باشد
 * **اعضای انجمن:** افرادی که از پروژه استفاده می‌کنند، می‌توانند مکالمات فعالانه‌ای داشته باشند یا نظرات‌شان را برای مسیر دادن به پروژه ابراز کنند
 
-پروژه‌های بزرگ‌تر همچنین ممکن است زیرکمیته‌ها یا گروه‌های کاری داشته باشند که روی وظایف متفاوتی مانند مجهز کردن، triage (تریاژ)، معتدل کردن انجمن و سازماندهی رویداد متمرکز می‌شوند. زمانی که به صفحه‌ی «تیم» پروژه‌ی یک وب‌سایت، یا مخزن مراجعه کنید، می‌توانید اطلاعات این زیرکمیته‌ها و نقش افراد کلیدی را مشاهده کنید.
+پروژه‌های بزرگ‌تر همچنین ممکن است زیرکمیته‌ها یا گروه‌های کاری داشته باشند که روی وظایف متفاوتی مانند مجهز کردن، <span dir="rtl">triage</span> (تریاژ)، معتدل کردن انجمن و سازماندهی رویداد متمرکز می‌شوند. زمانی که به صفحه‌ی «تیم» پروژه‌ی یک وب‌سایت، یا مخزن مراجعه کنید، می‌توانید اطلاعات این زیرکمیته‌ها و نقش افراد کلیدی را مشاهده کنید.
 
 پروژه‌های متن باز اسناد مختلفی دارند که این فایل‌ها معمولا در بالای لیست مخزن قرار می‌گیرند.
 
 * **لایسنس/ گواهینامه (LICENSE):** طبق تعریف، هر پروژه‌ی متن بازی باید لایسنس مخصوص به خود را داشته باشد. اگر یک پروژه لایسنس نداشته باشد، اصلاً متن باز محسوب نمی‌شود
-* **فایل README:** فایل README یک دستورالعمل ساختاری برای تمام اعضای جدید انجمن است که می‌توانند آن را مطالعه می‌کنند. در این فایل به خوبی آورده شده که پروژه‌ی در دست چه فوایدی دارد و چگونه باید از آن استفاده کرد
-* **فایل CONTRIBUTING:** زمانی که یک فایل README می‌تواند به مردم برای استفاده از پروژه کمک کنند، فایل CONTRIBUTING هم می‌تواند برای مشارکت افراد در پروژه به شما و به آن‌ها کمک کند. در این فایل توضیح داده شده که به چه نوع مشارکتی نیاز است و فرآیند کاری پروژه به چه نحوه است. با اینکه هر پروژه فایل CONTRIBUTING ندارد، اما در صورت وجود چنین فایلی در پروژه می‌تواند به افراد مختلف سیگنال مشارکت در پروژه بدهد.
-* **CODE_OF_CONDUCT:** در فایل code of conduct می‌توانید قوائدی که شرکت‌کنندگان باید با در نظر گرفتن آن به صورت دوستانه و راحت و در یک محیط پذیرا با سایرین برخورد کنند را بنویسید. با اینکه هر پروژه ممکن است حاوی این فایل نباشد، اما زمانی که یک پروژه‌ی متن باز این فایل را داشته باشد، به مشارکت‌کننده‌ها این سیگنال را می‌فرستد می‌توانند در پروژه مشارکت داشته باشند. این فایل تقریباً حاوی توصیه‌هایی رفتاری برای تعامل است.
-* **اسناد دیگر:** یک پروژه‌ی متن باز به خصوص پروژه‌های بزرگ‌تر ممکن است حاوی اسناد دیگری مانند فایل‌های آموزشی، بازنگری فنی، راهنمای گام به گام (walkthroughs)، یا سیاست‌های دولتی باشند.
+* **فایل README:** فایل <span dir="rtl">README</span> یک دستورالعمل ساختاری برای تمام اعضای جدید انجمن است که می‌توانند آن را مطالعه می‌کنند. در این فایل به خوبی آورده شده که پروژه‌ی در دست چه فوایدی دارد و چگونه باید از آن استفاده کرد
+* **فایل CONTRIBUTING:** زمانی که یک فایل <span dir="rtl">README</span> می‌تواند به مردم برای استفاده از پروژه کمک کنند، فایل <span dir="rtl">CONTRIBUTING</span> هم می‌تواند برای مشارکت افراد در پروژه به شما و به آن‌ها کمک کند. در این فایل توضیح داده شده که به چه نوع مشارکتی نیاز است و فرآیند کاری پروژه به چه نحوه است. با اینکه هر پروژه فایل <span dir="rtl">CONTRIBUTING</span> ندارد، اما در صورت وجود چنین فایلی در پروژه می‌تواند به افراد مختلف سیگنال مشارکت در پروژه بدهد.
+* **CODE_OF_CONDUCT:** در فایل <span dir="rtl">code of conduct</span> می‌توانید قوائدی که شرکت‌کنندگان باید با در نظر گرفتن آن به صورت دوستانه و راحت و در یک محیط پذیرا با سایرین برخورد کنند را بنویسید. با اینکه هر پروژه ممکن است حاوی این فایل نباشد، اما زمانی که یک پروژه‌ی متن باز این فایل را داشته باشد، به مشارکت‌کننده‌ها این سیگنال را می‌فرستد می‌توانند در پروژه مشارکت داشته باشند. این فایل تقریباً حاوی توصیه‌هایی رفتاری برای تعامل است.
+* **اسناد دیگر:** یک پروژه‌ی متن باز به خصوص پروژه‌های بزرگ‌تر ممکن است حاوی اسناد دیگری مانند فایل‌های آموزشی، بازنگری فنی، راهنمای گام به گام <span dir="rtl">(walkthroughs)</span> ، یا سیاست‌های دولتی باشند.
 
 در نهایت، پروژه‌های متن باز برای سازماندهی بحث‌ها از ابزارهای زیر  استفاده می‌کنند. مطالعه‌ی آرشیو پروژه‌ها می‌تواند دید خوبی از نحوه‌ی فکر و کار انجمن‌ها بدهد.
 
 * **ایشو ترکر (Issue tracker):** جایی که افراد درباره‌ی مشکلات مرتبط با پروژه بحث می‌کنند
 * **درخواست Pull (Pull requests):** جایی که افراد درباره‌ی تغییرات جاری بحث و بازبینی می‌کنند.
 * **انجمن گفتگو یا خبرنامه های ایمیلی:** برخی از پروژه ها ممکن است برای موضوعات نیازمند بحث و گفتگو از انجمن های گفتگو یا خبرنامه ایمیلی به جای ایشو ترکر استفاده کنند. البته برخی دیگر ممکن است همین کار را به صورت کامل در بخش ایشو ترکر انجام دهند.
-* **Synchronous chat channel:** بعضی از پروژه‌های از کانال‌های چت مانند Slack یا IRC برای مکالمات محاوره‌ای، همکاری یا تبادلات سریع استفاده می‌کنند.
+* **Synchronous chat channel:** بعضی از پروژه‌های از کانال‌های چت مانند <span dir="rtl">Slack</span> یا <span dir="rtl">IRC</span> برای مکالمات محاوره‌ای، همکاری یا تبادلات سریع استفاده می‌کنند.
 
 ## یافتن یک پروژه جهت مشارکت کردن در آن
 
@@ -207,11 +207,11 @@ related:
 
 فکر نکنید یک پروژه‌ی متن باز انحصاری است، چون پروژه‌های متن باز توسط افرادی مانند شما طراحی شده است. یک پروژه‌ی متن باز تنها یک لفظ فانتزی برای برطرف کردن و حل مشکلات در دنیاست.
 
-شما در پروژه‌های متن باز می‌توانید فایل README را مطالعه، لینک‌های خراب و غلط‌های املائی را پیدا و برطرف کنید. شما و کاربران جدیدتان هم می‌توانند متوجه مشکل یا مسئله‌ای شوند که فکر کی‌کند باید از اسناد پروژه باشد. به جای نادیده گرفتن، عبور کردن یا سپردن آن مسائل به افراد دیگر، برای اصلاح آن مشکلات می‌توانید کمک کنید. این تمام چیزی است که یک پروژه‌ی متن باز می‌تواند داشته باشد!
+شما در پروژه‌های متن باز می‌توانید فایل <span dir="rtl">README</span> را مطالعه، لینک‌های خراب و غلط‌های املائی را پیدا و برطرف کنید. شما و کاربران جدیدتان هم می‌توانند متوجه مشکل یا مسئله‌ای شوند که فکر کی‌کند باید از اسناد پروژه باشد. به جای نادیده گرفتن، عبور کردن یا سپردن آن مسائل به افراد دیگر، برای اصلاح آن مشکلات می‌توانید کمک کنید. این تمام چیزی است که یک پروژه‌ی متن باز می‌تواند داشته باشد!
 
 > [28% از مشارکت‌کننده‌های معمولی](https://www.igor.pro.br/publica/papers/saner2016.pdf) روی اسناد پروژه‌ی متن باز مانند اصلاح غلط‌های املائی، شکل ‌دهی مجدد، یا نوشتن ترجمه مشارکت می‌کنند.
 
-اگر به دنبال مسائل موجود پروژه‌ی متن بازتان هستید تا آن را برطرف کنید، می‌توانید وارد صفحه‌ی `/contribute` هر پروژه‌ی متن باز شوید که مشکلات را برای تازه‌واردها برجسته می‌کند. شما می‌توانید با حل کردن آن مشکلات، در مشارکت پروژه‌ی متن باز همکاری داشته باشد. برای این منظور می‌توانید به صفحه‌ی اصلی repository (مخزن) در سایت GitHub مراجعه کنید و کلمه‌ی `/contribute` را به انتهای آدرس URL آن اضافه کنید. به عنوان مثال:
+اگر به دنبال مسائل موجود پروژه‌ی متن بازتان هستید تا آن را برطرف کنید، می‌توانید وارد صفحه‌ی <span dir="rtl">`/contribute`</span> هر پروژه‌ی متن باز شوید که مشکلات را برای تازه‌واردها برجسته می‌کند. شما می‌توانید با حل کردن آن مشکلات، در مشارکت پروژه‌ی متن باز همکاری داشته باشد. برای این منظور می‌توانید به صفحه‌ی اصلی <span dir="rtl">repository</span>  (مخزن) در سایت <span dir="rtl">GitHub</span> مراجعه کنید و کلمه‌ی <span dir="rtl">`/contribute`</span> را به انتهای آدرس URL آن اضافه کنید. به عنوان مثال:
 [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
 
 شما همچنین می‌توانید از منابع زیر برای کشف و مشارکت در پروژه‌های جدید کمک بگیرید:
@@ -230,14 +230,14 @@ related:
 
 زمانی که پروژه‌ی مورد علاقه‌تان برای مشارکت را پیدا کردید، نگاهی سریعی داشته باشید که آیا آن پروژه مناسب است تا درخواست همکاری‌تان را بفرستید. در غیر این صورت، کار پُرتلاش شما ممکن است هیچوقت به نتیجه نرسد.
 
-در ادامه می‌تواند چک لیست دستی را ببینید که می‌تواند مشارکت‌کننده‌های جدید یک پروژه را ارزیابی کند.
+در ادامه می‌توانید چک لیست دستی را ببینید که می‌تواند مشارکت‌کننده‌های جدید یک پروژه را ارزیابی کند.
 
 **پروژه با تعریف پروژه‌ی متن باز مطابقت داشته باشد**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-  پروژه‌ای که می‌خواهید در آن مشارکت کنید، لایسنس دارد؟ در هر پروژه‌ی متن باز معمولاً فایلی با نام LICENSE در روت رسپاستوری (مخزن) آن وجود دارد
+  پروژه‌ای که می‌خواهید در آن مشارکت کنید، لایسنس دارد؟ در هر پروژه‌ی متن باز معمولاً فایلی با نام <span dir="rtl">LICENSE</span> در روت ریپاستوری (مخزن) آن وجود دارد
   </label>
 </div>
 
@@ -262,11 +262,11 @@ related:
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-  افراد چند بار کامیت می‌کنند؟ (در GitHub، با کلیک روی «commits» روی بالای بار می‌توانید آن را متوجه شوید.)
+  افراد چند بار کامیت می‌کنند؟ (در <span dir="rtl">GitHub</span> ، با کلیک روی <span dir="rtl">«commits»</span> روی بالای بار می‌توانید آن را متوجه شوید.)
   </label>
 </div>
 
-در قدم بعدی به مسائل پروژه (issue) نگاهی بیندازید.
+در قدم بعدی به مسائل پروژه <span dir="rtl">(issue)</span> نگاهی بیندازید.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
@@ -299,16 +299,16 @@ related:
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    مسائل پروژه‌ی متن باز برطرف شدند؟ (می‌توانید به صفحه‌ی Issues در GitHub و تب «closed» مراجعه کنید تا مسائل حل‌شده را ببینید.)
+    مسائل پروژه‌ی متن باز برطرف شدند؟ (می‌توانید به صفحه‌ی <span dir="rtl">Issues</span> در <span dir="rtl">GitHub</span> و تب <span dir="rtl">«closed»</span> مراجعه کنید تا مسائل حل‌شده را ببینید.)
   </label>
 </div>
 
-حالا، تمام این مراحل را برای درخواست ادغام یا Pull Request پروژه هم در نظر بگیرید.
+حالا، تمام این مراحل را برای درخواست ادغام یا <span dir="rtl">Pull Request</span> پروژه هم در نظر بگیرید.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    چه تعداد درخواست ادغام یا Pull Request در پروژه وجود دارد؟
+    چه تعداد درخواست ادغام یا <span dir="rtl">Pull Request</span> در پروژه وجود دارد؟
   </label>
 </div>
 
@@ -336,7 +336,7 @@ related:
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox13" class="overflow-hidden d-block text-normal">
-    جدیدترین درخواست‌هایی که ادغام شدن چه بودند؟ (می‌توانید در صفحه‌ی Pull Requests و تب «closed» در سایت GitHub بروید تا درخواست‌های ادغام انجام شده را ببینید
+    جدیدترین درخواست‌هایی که ادغام شدن چه بودند؟ (می‌توانید در صفحه‌ی <span dir="rtl">Pull Request</span> و تب <span dir="rtl">«closed»</span> در سایت <span dir="rtl">GitHub</span> بروید تا درخواست‌های ادغام انجام شده را ببینید
   </label>
 </div>
 
@@ -347,14 +347,14 @@ related:
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox14" class="overflow-hidden d-block text-normal">
-    آیا مسئول ‌نگهداری جواب مفیدی به سوالات در بخش مسائل (Issues) می‌دهد؟
+    آیا مسئول ‌نگهداری جواب مفیدی به سوالات در بخش مسائل <span dir="rtl">(Issues)</span> می‌دهد؟
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox15" class="overflow-hidden d-block text-normal">
-    آیا افراد در صفحه‌ی issue، تالارهای گفتگو، و صفحات چت مانند IRC یا Slack به طور دوستانه‌ای رفتار می‌کنند؟
+    آیا افراد در صفحه‌ی issue، تالارهای گفتگو، و صفحات چت مانند <span dir="rtl">IRC</span> یا <span dir="rtl">Slack</span> به طور دوستانه‌ای رفتار می‌کنند؟
   </label>
 </div>
 
@@ -396,27 +396,27 @@ related:
   </p>
 </aside>
 
-قبل از درخواست ادغام یا باز کردن issue در بخش گزارش مسئله یا پرسیدن سوال در چت، نکته‌های زیر را در نظر داشته باشید تا به شما کمک کند تا ایده‌هایتان کارآمد و موثرتر باشد.
+قبل از درخواست ادغام یا باز کردن <span dir="rtl">issue</span> در بخش گزارش مسئله یا پرسیدن سوال در چت، نکته‌های زیر را در نظر داشته باشید تا به شما کمک کند تا ایده‌هایتان کارآمد و موثرتر باشد.
 
 **ارائه‌ی زمینه:** به دیگران کمک کنید تا سرعت خود را افزایش دهند. اگر خطایی پیدا کردید و در حال برطرف کردن آن هستید، به دیگران توضیح دهید که سعی دارید چه کاری انجام می‌دهید و چگونه آن مشکل را حل می‌کنید. اگر ایده‌ی جدیدی هم پیشنهاد می‌دهید، نه تنها برای خود، بلکه برای دیگران توضیح دهید که چرا فکر می‌کنید این ایده‌ی شما می‌تواند برای پروژه مفید باشد.
 
-> 😇 _"زمانی که Y را انجام می‌دهم، X اتفاق نمی‌افتد"_
+> 😇 _"زمانی که <span dir="rtl">Y</span> را انجام می‌دهم، <span dir="rtl">X</span> اتفاق نمی‌افتد"_
 >
 > 😢 _"X به مشکل برخورد کرده است! لطفا برطرفش کنید."_
 
-**تکالیف‌تان را از قبل انجام دهید.** اگر چیزی نمی‌دانید مشکلی نیست، اما باید نشان دهید که تلاش‌تان را می‌کنید. قبل از اینکه از دیگران کمک بخواهید، مطمئن شوید که فایل README، اسناد، مسائل حل شده یا حل نشده، لیست پست پروژه را خوانده‌اید، یا در اینترنت به دنبال جواب‌تان گشته‌اید. وقتی تلاش‌تان برای یادگیری را نشان می‌دهید، مورد توجه تحسین دیگران قرار می‌گیرید
+**تکالیف‌تان را از قبل انجام دهید.** اگر چیزی نمی‌دانید مشکلی نیست، اما باید نشان دهید که تلاش‌تان را می‌کنید. قبل از اینکه از دیگران کمک بخواهید، مطمئن شوید که فایل <span dir="rtl">README</span>، اسناد، مسائل حل شده یا حل نشده، لیست پست پروژه را خوانده‌اید، یا در اینترنت به دنبال جواب‌تان گشته‌اید. وقتی تلاش‌تان برای یادگیری را نشان می‌دهید، مورد توجه تحسین دیگران قرار می‌گیرید
 
-> 😇 _"مطمئن نیستم چگونه X را اجرا کنم. برای پیدا کردن جواب، فایل‌ها را بررسی کردم و هیچ جوابی نگرفتم."_
+> 😇 _"مطمئن نیستم چگونه <span dir="rtl">X</span> را اجرا کنم. برای پیدا کردن جواب، فایل‌ها را بررسی کردم و هیچ جوابی نگرفتم."_
 >
-> 😢 _"چگونه مسئله X را برطرف کنم؟"_
+> 😢 _"چگونه مسئله <span dir="rtl">X</span> را برطرف کنم؟"_
 
 **درخواست‌ها را مختصر و مفید مطرح کنید** هر مشارکتی مانند ارسال یک ایمیل، بدون در نظر گرفتن ساده یا مفید بودنش، به توجه‌ی دیگران نیاز دارد. معمولاً درخواست‌ها و سوالات اکثر پروژه‌ها از افرادی که می‌خواهند به آن‌ها جواب بدهند بیشتر است. بنابراین، درخواست‌ها باید مختصر باشد. با کوتاه بودن درخواست‌ها به افراد شانس بیشتری می‌دهید تا فرصت کمک کردن به شما را پیدا کنند.
 
-> 😇 _"تمایل دارم یک فایل آموزشی API بنویسم"_
+> 😇 _"تمایل دارم یک فایل آموزشی <span dir="rtl">API</span> بنویسم"_
 >
 > 😢 _"زمانی که در بزرگ‌راه در حال رانندگی کردن بودم، کنار یک پمپ بنزین توقف کردم و ایده‌ی شگفت‌انگیزی به ذهنم رسید که باید آن را عملی کنیم، اما قبل از توضیح، اجازه دهید ایده‌ام را به شما نشان بدهم ..."_
 
-**تمام ارتباطات و تعاملات را به صورت عمومی نگهدارید.** هرچند وسوسه‌کننده است، اما به طور خصوصی با مسئول‌نگهداری پروژه تماس نگیرید مگر اینکه لازم باشد اطلاعات حساس مانند مسائل امنیتی یا نقض رفتار جدیدی را رد و بدل کنید. زمانی که مکالمه‌ی شما عمومی شود، افراد بیشتری از تبادیل این ارتباطات یاد می‌گیرند و بهره می‌گیرند. بحث و گفتگوها می‌تواند خودبه خود کمک‌رسان باشد.
+**تمام ارتباطات و تعاملات را به صورت عمومی نگهدارید.** هرچند وسوسه‌کننده است، اما به طور خصوصی با مسئول‌نگهداری پروژه تماس نگیرید مگر اینکه لازم باشد اطلاعات حساس مانند مسائل امنیتی یا نقض رفتار جدیدی را رد و بدل کنید. زمانی که مکالمه‌ی شما عمومی شود، افراد بیشتری از تبادل این ارتباطات یاد می‌گیرند و بهره می‌گیرند. بحث و گفتگوها می‌تواند خودبه خود کمک‌رسان باشد.
 
 > 😇 (در کامنت) «@-مسئول‌نگهداری: سلام! چگونه درخواست ادغام را پیش ببریم؟"_
 >
@@ -438,39 +438,39 @@ related:
 
 ### Gathering context
 
-قبل از اینکه کاری انجام دهید، به سرعت بررسی کنید و مطمئن شوید که ایده‌ی شما در هیج جای مورد بحث قرار نگرفته باشد. فایل README، مسائل حل‌شده یا حل‌نشده، لیست پست و گفتگوهای Stack را به طور سرسری مطالعه کنید. لازم نیست ساعت‌ها صرف خواندن آن‌ها کنید، اما جستجوی سریع درباره‌ی کلمات کلیدی می‌تواند تا حد زیادی به شما کمک کند
+قبل از اینکه کاری انجام دهید، به سرعت بررسی کنید و مطمئن شوید که ایده‌ی شما در هیج جای مورد بحث قرار نگرفته باشد. فایل <span dir="rtl">README</span>، مسائل حل‌شده یا حل‌نشده، لیست پست و گفتگوهای <span dir="rtl">Stack</span> را به طور سرسری مطالعه کنید. لازم نیست ساعت‌ها صرف خواندن آن‌ها کنید، اما جستجوی سریع درباره‌ی کلمات کلیدی می‌تواند تا حد زیادی به شما کمک کند
 
-اگر ایده‌ی شما در جای دیگری مطرح نشده بود، می‌توانید آن را بیان کنید. اگر پروژه در GitHub باشد، با باز کردن Issue یا درخواست ادغام Pull Request احتمالاً می‌توانید مکالمه داشته باشید:
+اگر ایده‌ی شما در جای دیگری مطرح نشده بود، می‌توانید آن را بیان کنید. اگر پروژه در <span dir="rtl">GitHub</span> باشد، با باز کردن <span dir="rtl">Issue</span> یا درخواست ادغام <span dir="rtl">Pull Request</span> احتمالاً می‌توانید مکالمه داشته باشید:
 
 * **Issues** مانند شروع یک مکالمه یا گفتگو است
 * **Pull Requests** برای کار روی راه‌حل است
-* **سایر راه های ارتباطی راه‌های ارتباطی** مانند شفاف‌سازی، نحوه‌ی پرسیدن سوال (How-to question)، پرسیدن سوال در Stack، IRC، Slack یا دیگر کانال‌های چت است، البته اگر یک پروژه چنین راه‌های ارتباطی را باز گذاشته باشد.
+* **سایر راه های ارتباطی راه‌های ارتباطی** مانند شفاف‌سازی، نحوه‌ی پرسیدن سوال <span dir="rtl">(How-to question)</span>، پرسیدن سوال در <span dir="rtl">Stack</span> ، <span dir="rtl">IRC</span> ، <span dir="rtl">Slack</span> یا دیگر کانال‌های چت است، البته اگر یک پروژه چنین راه‌های ارتباطی را باز گذاشته باشد.
 
-قبل از باز کردن issue یا درخواست ادغام، اسناد مشارکت پروژه را بررسی کنید که معمولاً در فایل‌هایی به نام CONTRIBUTING یا README آورده شدند تا چیزهای خاصی که دنبالش هستید را مطالعه کنید. به عنوان مثال، آن‌ها ممکن است از شما درخواست کنند الگوها را پیروی کنید یا به این نیاز داشته باشند که از این تست‌ها استفاده کنند.
+قبل از باز کردن <span dir="rtl">issue</span> یا درخواست ادغام، اسناد مشارکت پروژه را بررسی کنید که معمولاً در فایل‌هایی به نام  <span dir="rtl">CONTRIBUTING</span> یا <span dir="rtl">README</span> آورده شدند تا چیزهای خاصی که دنبالش هستید را مطالعه کنید. به عنوان مثال، آن‌ها ممکن است از شما درخواست کنند الگوها را پیروی کنید یا به این نیاز داشته باشند که از این تست‌ها استفاده کنند.
 
-اگر در یک پروژه مشارکت عمیق و اساسی داشته باشید، قبل از مشارکت در پروژه، یک issue باز کنید و سوال کنید. این کار مفید است و باعث می‌شود پروژه‌ی شما مدتی مشاهده شود. (در سایت GitHub می‌توانید [روی «Watch» کلیک کنید](https://help.github.com/articles/watching-repositories/) تا از تمام مکالمات مطلع شوید)، و قبل از انجام دادم کار که ممکن است پذیرفته نشود، اعضای انجمن را بشناسید.
+اگر در یک پروژه مشارکت عمیق و اساسی داشته باشید، قبل از مشارکت در پروژه، یک <span dir="rtl">issue</span> باز کنید و سوال کنید. این کار مفید است و باعث می‌شود پروژه‌ی شما مدتی مشاهده شود. (در سایت <span dir="rtl">GitHub</span> می‌توانید [روی «Watch» کلیک کنید](https://help.github.com/articles/watching-repositories/) تا از تمام مکالمات مطلع شوید)، و قبل از انجام دادم کار که ممکن است پذیرفته نشود، اعضای انجمن را بشناسید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
-  با فعالیت در پروژه‌های GitHub و مطالعه‌ی تمام issue و درخواست‌های ادغام می‌توانید چیزهای زیادی یاد بگیرید.
+  با فعالیت در پروژه‌های <span dir="rtl">GitHub</span> و مطالعه‌ی تمام <span dir="rtl">issue</span> و درخواست‌های ادغام می‌توانید چیزهای زیادی یاد بگیرید.
 <p markdown="1" class="pquote-credit">
 — @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
   </p>
 </aside>
 
-### باز کردن Issue یا طرح سوال و گفتگو
+### باز کردن <span dir="rtl">issue</span> یا طرح سوال و گفتگو
 
-در موقعیت‌های زیر معمولاً باید یک issue باز کنید:
+در موقعیت‌های زیر معمولاً باید یک <span dir="rtl">issue</span> باز کنید:
 
 * جهت گزارش خطایی که خودتان نمی‌توانید آن را حل کنید
 * درباره‌ی موضوعات یا ایده‌ی سطح بالا بحث کنید (به عنوان مثال، درباره‎ی جامعه، دیدگاه یا سیاست‌ها)
 * ویژگی جدید یا ایده‌ی جدیدی برای پروژه پیشنهاد دهید
 
-نکاتی برای برقراری ارتباط با مشکلات issues:
+نکاتی برای برقراری ارتباط با مشکلات <span dir="rtl">issue</span> :
 
 * **اگر با مسئله‌ی بازی روبه‌رو شدید که می‌خواهید آن را برطرف کنید**، کامنت کردن برای یک مسئله به افراد اجازه می‌دهد بدانند که شما این مسئله را باز کردید. به این ترتیب، افراد احتمالاً کمتر با مشکلات مشابه‌ی شما برخورد می‌کنند
 * **اگر یک issue مدتی پیش باز بوده است**، احتمال دارد جای دیگر به آن جواب داده شده باشد، یا قبلا حل شده است. بنابراین، قبل از شروع کار می‌توانید برای تایید حل شدن یا حل نشدن آن درخوست کامنت بدهید.
-* **اگر یک issue باز کردید**، اما جواب آن را بعدها متوجه شدید، روی issue کامنت بگذارید تا مردم متوجه شوند، سپس issue را ببندید. حتی با نوشتن اسناد می‌تواند سهمی در مشارکت پروژه داشته باشید.
+* **اگر یک issue باز کردید**، اما جواب آن را بعدها متوجه شدید، روی issue کامنت بگذارید تا مردم متوجه شوند، سپس <span dir="rtl">issue</span> را ببندید. حتی با نوشتن اسناد می‌تواند سهمی در مشارکت پروژه داشته باشید.
 
 ### ارسال Pull request (درخواست ادغام)
 
@@ -479,16 +479,16 @@ related:
 * ارائه اصلاحات ناچیز (به عنوان نمونه، غلط‌های املائی، لینک‌های خراب یا خطاهای مشهود)
 * کار کردن روی مشارکتی که قبلا درخواست شده یا درباره‌ی آن بحث و گفتگو شده باشد
 
-درخواست ادغام لزوماً به معنای پایان کار نیست. معمولاً بهتر است درخواست ادغام را قبلا باز کنید تا دیگران بتوانند آن را مشاهده و بازخوردهای خود را برای پیشرفت شما ارسال کنند. فقط آن را به «WIP» (کار در حال انجام) در کادر عنوان نشانه‌گذاری کنید. شما بعدها می‌توانید کامیت‌های بیشتری اضافه کنید.
+درخواست ادغام لزوماً به معنای پایان کار نیست. معمولاً بهتر است درخواست ادغام را قبلا باز کنید تا دیگران بتوانند آن را مشاهده و بازخوردهای خود را برای پیشرفت شما ارسال کنند. فقط آن را به <span dir="rtl">«WIP»</span> (کار در حال انجام) در کادر عنوان نشانه‌گذاری کنید. شما بعدها می‌توانید کامیت‌های بیشتری اضافه کنید.
 
-اگر پروژه در GitHub باشد، با روش‌های زیر می‌توانید درخواست ادغام ارسال کنید:
+اگر پروژه در <span dir="rtl">GitHub</span> باشد، با روش‌های زیر می‌توانید درخواست ادغام ارسال کنید:
 
-* **[Fork the repository](https://guides.github.com/activities/forking/)** و یک نسخه برای خودتان کپی کنید. نسخه محلی خود را به مخزن بالادستی متصل کنید. هر از چندگاهی با دستور Pull آخرین نسخه تغییرات در مخزن اصلی را دریافت کنید تا پیش از اینکه تعارضی ما بین نسخه محلی و مخزن ایجاد شد بتوانید با مشکلات احتمالی کمتری تغییرات خود را به سمت مخزن اصلی ارسال کنید. [برای کسب اطلاعات بیشتر اینجا را مرور کنید](https://help.github.com/articles/syncing-a-fork/)
+* **[Fork the repository](https://guides.github.com/activities/forking/)** و یک نسخه برای خودتان کپی کنید. نسخه محلی خود را به مخزن بالادستی متصل کنید. هر از چندگاهی با دستور <span dir="rtl">Pull</span> آخرین نسخه تغییرات در مخزن اصلی را دریافت کنید تا پیش از اینکه تعارضی ما بین نسخه محلی و مخزن ایجاد شد بتوانید با مشکلات احتمالی کمتری تغییرات خود را به سمت مخزن اصلی ارسال کنید. [برای کسب اطلاعات بیشتر اینجا را مرور کنید](https://help.github.com/articles/syncing-a-fork/)
 * **[ایجاد یک شاخه](https://guides.github.com/introduction/flow/)** برای اعمال ویرایش ها.
-* در حین ارسال ها **به مسائل (issue) مرتبط ارجاع دهید** یا در کامنت مربوط به تغییرات جدید به مستندات مربوطه اشاره کنید.(مثال: این تغییر مشکل مطرح شده در مسئله شماره 37 را برطرف می‌کند.)
-* اگر تغییرات شما حاوی تفاوت‌های HTML/CSS باشد، **تصاویر مربوط به قبل و بعد آن را اضافه کنید**. تصاویر را وارد بدنه‌ی درخواست ادغام کنید و رها کنید.
+* در حین ارسال ها **به مسائل <span dir="rtl">(issue)</span> مرتبط ارجاع دهید** یا در کامنت مربوط به تغییرات جدید به مستندات مربوطه اشاره کنید.(مثال: این تغییر مشکل مطرح شده در مسئله شماره 37 را برطرف می‌کند.)
+* اگر تغییرات شما حاوی تفاوت‌های <span dir="rtl">HTML/CSS</span> باشد، **تصاویر مربوط به قبل و بعد آن را اضافه کنید**. تصاویر را وارد بدنه‌ی درخواست ادغام کنید و رها کنید.
 * تغییرات‌تان را **تست کنید!** تغییرات خود را در برابر تست‌های موجود اجرا کنید و در صورت لزوم تغییرات جدیدی خلق کنید. اگر حتی تست‌هایی تعریف نشده بود، مطمئن شوید تغییرات‌تان پروژه‌ی موجود شما را خراب نکند.
-* با تمام توانایی‌تان  **الگوها را رعایت کرده و مطابق سبک پروژه مشارکت کنید**. این توانایی می‌تواند به معنای استفاده از تورفتگی‌ها، نقطه ویرگول (semi-colons)، یا کامنت‌های متفاوتی باشد که شما در مخزن‌تان خودتان دارید. این کار ادغام مسئول‌نگهداری را ساده می‌کند، دیگران هم متوجه آن می‌شوند و می‌توانند آن را برای زمان‌های آتی حفظ کنند.
+* با تمام توانایی‌تان  **الگوها را رعایت کرده و مطابق سبک پروژه مشارکت کنید**. این توانایی می‌تواند به معنای استفاده از تورفتگی‌ها، نقطه ویرگول <span dir="rtl">(semi-colons)</span> ، یا کامنت‌های متفاوتی باشد که شما در مخزن‌تان خودتان دارید. این کار ادغام مسئول‌نگهداری را ساده می‌کند، دیگران هم متوجه آن می‌شوند و می‌توانند آن را برای زمان‌های آتی حفظ کنند.
 
 اگر این اولین درخواست ادغام شماست، فیلم آموزشی [Make a Pull Request](http://makeapullrequest.com/) که @kentcdodds آن را خلق کرده، بررسی کنید. شما همچنین می‌توانید از [Make a Pull Request](https://github.com/Roshanjossey/first-contributions) که توسط @Roshanjossey ایجاد شده به عنوان یک محزن تمرینی برای اولین تجربه خود استفاده کنید.
 
@@ -508,13 +508,13 @@ related:
 
 اگر به طور مودبانه درخواست‌هایتان را فرستاده باشید اما هنوز هیچ‌کس پاسخگو نیست، احتمالاً هیچ‌کس هیچوقت پاسخ شما را نخواهد داد. می‌دانیم که حس خوبی ندارد، اما اجازه ندهید این موضوع شما را دلسرد کند چون این اتفاق ممکن است برای همه رخ دهد! 
 
-برای برطرف کردن این مشکل دلایل زیادی وجود دارد که به شما می‌گوید چرا پاسخ درخواست‌تان داده نمی‌شود؛ دلایلی مانند شرایط شخصی که ممکن است از کنترل خارج شود. شما می‌تواند پروژه‌ی دیگر یا راهی برای مشارکت پیدا کنید. قبل از اینکه اعضای یک انجمن متهد یا پاسخگو باشند، زمان زیادی را صرف ارسال درخواست مشارکت‌تان نکنید.
+برای برطرف کردن این مشکل دلایل زیادی وجود دارد که به شما می‌گوید چرا پاسخ درخواست‌تان داده نمی‌شود؛ دلایلی مانند شرایط شخصی که ممکن است از کنترل خارج شود. شما می‌تواند پروژه‌ی دیگر یا راهی برای مشارکت پیدا کنید. قبل از اینکه اعضای یک انجمن متعهد یا پاسخگو باشند، زمان زیادی را صرف ارسال درخواست مشارکت‌تان نکنید.
 
 ### 🚧 یک نفر برای تغییر درخواست‌تان به شما پیام می‌دهد.
 
 مرسوم است کسی بخواهید درخواست مشارکت خود را تغییر دهید، این درخواست تغییر می‌تواند در بازخورد ایده‌ یا در تغییرات کد شما باشد.
 
-اگر کسی درخواست تغییر برای‌تان ارسال کرد، پاسخگو باشید، چون آن‌ها برای بررسی درخواست مشارکت شما زمان گذاشتند. باز گذاشتن PR (درخواست ادغام) و نادیده گرفتن آن صورت خوبی ندارد. اگر نمی‌دانید چگونه روی درخواست‌تان آن تغییرات را اعمال کنید، مشکلات را جستجو کنید و در صورت نیاز از کسی کمک بخواهید.
+اگر کسی درخواست تغییر برای‌تان ارسال کرد، پاسخگو باشید، چون آن‌ها برای بررسی درخواست مشارکت شما زمان گذاشتند. باز گذاشتن <span dir="rtl">PR</span> (درخواست ادغام) و نادیده گرفتن آن صورت خوبی ندارد. اگر نمی‌دانید چگونه روی درخواست‌تان آن تغییرات را اعمال کنید، مشکلات را جستجو کنید و در صورت نیاز از کسی کمک بخواهید.
 
 اگر برای برطرف کردن مسائل پروژه دیگر زمان کافی ندارید (به عنوان نمونه، اگر مکالمه‌ی شما ماه‌ها طول کشید، و اکنون شرایط شما تغییر کند)، اجازه دهید مسئول‌نگهداری پروژه از این موضوع مطلع شود تا منتظر جواب شما نباشد. حتی کسی دیگری ممکن است جای شما را بگیرد.
 
@@ -528,4 +528,4 @@ related:
 
 ## انجامش دادی!
 
-خواه دنبال ارسال درخواست مشارکت خود برای اولین پروژه‌تان باشد، یا دنبال راه یک جدید برای مشارکت در یک پروژه‌ی متن باز باشید، امیدواریم انگیزه این کار را داشته باشید. حتی اگر درخواست‌تان هم پذیرفته نشد، فراموش نکنید از تلاش مسئول‌نگهداری پروژه تشکر کنید که تمام تلاش خود را برای کمک به شما گذاشت. پروژه‌های متن باز، مسائل، درخواست ادغام، کامنت توسط افرادی مانند شما تولید می‌شود.
+خواه دنبال ارسال درخواست مشارکت خود برای اولین پروژه‌تان باشید، یا دنبال یک راه جدید برای مشارکت در پروژه‌ای متن باز، امیدواریم انگیزه این کار را داشته باشید. حتی اگر درخواست‌تان هم پذیرفته نشد، فراموش نکنید از تلاش مسئول‌نگهداری پروژه تشکر کنید که تمام تلاش خود را برای کمک به شما گذاشت. پروژه‌های متن باز، مسائل، درخواست ادغام، کامنت توسط افرادی مانند شما تولید می‌شود.

From 5b1805a9421c42c3e0e862666b33b1d84b1bc1da Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Mon, 11 Oct 2021 09:28:34 +0330
Subject: [PATCH 261/749] Improvement translate

Hi
I I changed the text for more readability.
Good luck :)
---
 _articles/fa/starting-a-project.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md
index ae40ceb8f7b..af534e3d336 100644
--- a/_articles/fa/starting-a-project.md
+++ b/_articles/fa/starting-a-project.md
@@ -12,11 +12,11 @@ related:
 
 ## چیستی و چرایی متن باز
 
-اگر در حال فکر کردن این هستید که پروژه‌ی متن باز خودتان را شروع کنید؟ به شما تبریک می‌گوییم! دنیا قدردان کمک و مشارکت شماست. اجازه دهید در ادامه درباره پروژه‌های متن باز بیشتر صحبت کنیم و ببینیم چرا مردم پروژه‌هایشان را متن باز می‌کنند.
+اگر به این فکر میکنید که پروژه‌ی متن باز خودتان را شروع کنید؟ به شما تبریک می‌گوییم! دنیا قدردان کمک و مشارکت شماست. اجازه دهید در ادامه درباره پروژه‌های متن باز بیشتر صحبت کنیم و ببینیم چرا مردم پروژه‌هایشان را متن باز می‌کنند.
 
 ### متن باز به چه معناست؟
 
-زمانی که یک پروژه متن باز یا اوپن سورس باشد، **هر کسی می‌تواند و اجازه دارد به صورت رایگان آن را استفاده، مطالعه، ویرایش و برای هر هدفی که می‌خواهد، توزیع کند**. این اجازه‌ها در [لایسنس متن باز](https://opensource.org/licenses) قید شده و قابل اجراست
+زمانی که یک پروژه متن باز یا اوپن سورس باشد، **هر کسی می‌تواند و اجازه دارد به صورت رایگان از آن استفاده، مطالعه، ویرایش و برای هر هدفی که می‌خواهد، توزیع کند**. این اجازه‌ها در [لایسنس متن باز](https://opensource.org/licenses) قید شده و قابل اجراست
 
 پروژه‌های متن باز قدرتمند هستند، چون موانعی که در اختیارات و مشارکت‌ها دیده می‌شود را کاهش و به افراد اجازه می‌دهد پروژه‌های خود را به سرعت گستردش و بهبود دهند. یکی دیگر از دلایل قدرتمند بودن متن بازها این است که پتانسیل کنترل محاسبه را بسته به منابع محدود به کاربران می‌دهد. اگر بخواهیم برای روشن شدن مطلب نمونه‌ای بیاوریم، می‌توانیم به کسب‌وکارهایی اشاره کنیم که به جای تکیه بر منابع محصور و محدود محصولات انحصاری فروشنده‌های نرم‌افزار، از نرم‌افزارهای متن بازی استفاده می‌کنند که به آن‌ها اجازه می‌دهد شخصی را استخدام کنند تا آن نرم‌افزار را برای آن‌ها شخصی‌سازی یا بهینه کند.
 
@@ -52,9 +52,9 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 ## آیا پروژه‌ی متن باز خودم را باید منتشر کنم؟
 
-اگر بخواهیم کوتاه جواب بدهیم، بله. چون خروجی پروژه‌ی شما مهم نیست. مهم این است که پروژه‌تان منتشر شود و بهترین راه هم برای یاد گرفتن نحوه‌ی کار پروژه‌های متن باز انتشار آن‌هاست.
+اگر بخواهیم کوتاه جواب بدهیم، بله. چون خروجی پروژه‌ی شما مهم نیست. مهم این است که پروژه‌تان منتشر شود و بهترین راه برای یاد گرفتن نحوه‌ی کار پروژه‌های متن باز انتشار آن‌هاست.
 
-اگر هیچوقت پروژه‌ی متن بازتان را منتشر نکردید، ممکن است این نگرانی برای‌تان پیش بیاید افراد مختلف چه چیزی درباره‌ی پروژه‌تان می‌گویند یا اصلا به پروژه‌ی شما توجه می‌کنند یا خیر. اگر چنین احساسی دارید، باید بگوییم که تنها نیستید.
+اگر هیچوقت پروژه‌ی متن بازتان را منتشر نکرده‌اید، ممکن است این نگرانی برای‌تان پیش بیاید افراد مختلف چه چیزی درباره‌ی پروژه‌تان می‌گویند یا اصلا به پروژه‌ی شما توجه می‌کنند یا خیر. اگر چنین احساسی دارید، باید بگوییم که تنها نیستید.
 
 کار یک پروژه‌ی متن باز مانند هر فعالیت خلاقانه‌ی دیگری مثل نویسندگی و نقاشی است. زمانی که شما به عنوان یک هنرمند اولین اثر خود را با دنیا به اشتراک می‌گذارید، احساس ترس به سراغتان می‌آید. اما این کار را باید انجام دهید، چون تمرین تنها راه بهتر شدن است؛ حتی اگر یک مخاطب هم نداشته باشید.
 
@@ -70,7 +70,7 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
-  زمانی که پروژه‌ی UIAlertView شخصی را تولید و استفاده کردم ....  و تصمیم گرفتم آن را متن باز کنم، تغییراتی در آن اعمال کردم تا پویایی بیشتری داشته باشد و آن را در GitHub آپلود کردم. من همچنین اولین سندی (که توضیح پروژه در آن نوشته می‌شود) را برای سایر توسعه‌دهنده‌ها نوشتم که نحوه‌ی کار با پروژه‌ی من چگونه است. احتمالاً به خاطر اینکه پروژه‌ی ساده‌ی بود، هیچ‌کس از آن استفاده نکرد. هرچند، اما به خاطر مشارکتم به سایر توسعه‌دهنده‌ها احساس خوبی داشتم.
+  زمانی که پروژه‌ی UIAlertView شخصی را تولید و استفاده کردم ....  و تصمیم گرفتم آن را متن باز کنم، تغییراتی در آن اعمال کردم تا پویایی بیشتری داشته باشد و آن را در GitHub آپلود کردم. من همچنین اولین سندی (که توضیح پروژه در آن نوشته می‌شود) را برای سایر توسعه‌دهنده‌ها نوشتم که نحوه‌ی کار با پروژه‌ی من چگونه است. احتمالاً به خاطر اینکه پروژه‌ی ساده‌ای بود، هیچ‌کس از آن استفاده نکرد. هرچند، اما به خاطر مشارکتم به سایر توسعه‌دهنده‌ها احساس خوبی داشتم.
   <p markdown="1" class="pquote-credit">
 — @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
   </p>
@@ -86,7 +86,7 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-  زمانی که پروژه‌ی متن بازتان را شروع می‌کنید، مهم است که اطمینان حاصل کنید که فرآیندهای مدیریتی شما ظرفیت مشارکت‌ها و توانایی‌های جامعه‌ی پیرامونی و مخاطب پروژه‌تان را در برگیرد. از مشارکت دادن مشارکت‌کننده‌هایی نترسید که از جنبه‌های کلیدی پروژه کارمند کسب و کارتان نیستند، به خصوص اگر مشارکت آن‌ها با شما مکرر باشد.
+  زمانی که پروژه‌ی متن بازتان را شروع می‌کنید، مهم است که اطمینان حاصل کنید که فرآیندهای مدیریتی شما ظرفیت مشارکت‌ها و توانایی‌های جامعه‌ی پیرامونی و مخاطب پروژه‌تان را در برگیرد. از مشارکت دادن مشارکت‌کننده‌هایی نترسید که از جنبه‌های کلیدی پروژه، کارمند کسب و کارتان نیستند، به خصوص اگر مشارکت آن‌ها با شما مکرر باشد.
   <p markdown="1" class="pquote-credit">
 — @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
   </p>
@@ -225,7 +225,7 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 اگر پروژه‌ی شما زبان و اکوسیستم یکسانی دارد، می‌توانید نام پروژه‌های مشابه با پروژه‌تان را [بررسی کنید](http://ivantomic.com/projects/ospnc/). اگر نام پروژه‌ی شما با پروژه‌ی دیگری شباهت زیادی داشته باشد، مخاطب شما ممکن است سردرگم شود.
 
-اگر با یک وب‌سایت، توئیتر یا دیگر شبکه‌های اجتماعی می‌خواهید پروژه‌تان را نشان دهید، مطمئن شوید همان نامی را انتخاب کنید که می‌خواهید. به طور ایده آل، حتی اگر هنوز نمی‌‌خواهید از آن نام استفاده کنید و برای اینکه خیال‌تان راحت باشد، آن نام را [وارونه کنید](https://instantdomainsearch.com/)
+اگر در یک وب‌سایت، توئیتر یا دیگر شبکه‌های اجتماعی می‌خواهید پروژه‌تان را نشان دهید، مطمئن شوید همان نامی را انتخاب کنید که می‌خواهید. به طور ایده آل، حتی اگر هنوز نمی‌‌خواهید از آن نام استفاده کنید و برای اینکه خیال‌تان راحت باشد، آن نام را [وارونه کنید](https://instantdomainsearch.com/)
 
 مطمئن شوید نام پروژه‌ی شما هیچ برند تجاری را نقض نمی‌کند. اگر چنین باشد، آن شرکت می‌تواند بعدها از شما درخواست کند پروژه‌تان را کنسل کرده یا حتی به صورت قانونی با شما برخورد کند. بنابراین، ارزش این همه ریسک را ندارد و برای جلوگیری از چنین مشکلاتی حتما از نام مناسبی استفاده کنید.
 
@@ -262,7 +262,7 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-    پروژه حاوی فایل (LICENSE) و لایسنس متن باز است
+    پروژه حاوی فایل (LICENSE)  لایسنس متن باز است
   </label>
 </div>
 

From 0cc15db9ca563d07c89904acecb666bfb2521da8 Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Mon, 11 Oct 2021 19:41:07 +0330
Subject: [PATCH 262/749] Improve readability

Hi
Improve the readability of translations and edit sentences.
Good luck!
---
 _articles/fa/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 7c7ead6cc3d..1b1268ae35c 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -140,7 +140,7 @@ related:
 
 به عنوان مثال:
 
-* @sindresorhus [لیست‌هایی موسوم به «awesome»](https://github.com/sindresorhus/awesome) گردآوری و تنظیم می‌کند
+* @sindresorhus [لیست‌هایی موسوم به <span dir="rtl">«awesome»</span>](https://github.com/sindresorhus/awesome) گردآوری و تنظیم می‌کند
 * @h5bp [یک لیست حاوی سوالاتی جهت مصاحبه برای توسعه دهندگان فرانت اند](https://github.com/h5bp/Front-end-Developer-Interview-Questions) را نگهداری و مرتب می‌کند
 * @stuartivnn و @nicole-a-tesla [مجموعه‌ای از حقایق جالب درباره‌ی طوطی دریایی](https://github.com/stuartlynn/puffin_facts) ایجاد کرده‌اند.
 

From 790fa932f6023bb54983e059c4ef8963c93513c1 Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Wed, 13 Oct 2021 08:54:12 +0330
Subject: [PATCH 263/749] update for more readability

hi
changed for more readability
Good time :)
---
 _articles/fa/building-community.md | 48 +++++++++++++++---------------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md
index ad31d19e706..27aa282782e 100644
--- a/_articles/fa/building-community.md
+++ b/_articles/fa/building-community.md
@@ -1,7 +1,7 @@
 ---
 lang: fa
 title: ساخت انجمن های پذیرا
-description: ساخت یک انجمن که افراد را به استفاده کردن ، به اشتراک گذاری و تبلیغ کردن پروژه تان ترغیب کند.
+description: ساخت یک انجمن که افراد را به استفاده کردن ، اشتراک گذاری و تبلیغ کردن پروژه تان ترغیب کند.
 class: building
 order: 4
 image: /assets/images/cards/building.png
@@ -29,11 +29,11 @@ related:
 * **برای افراد استفاده از پروژه خود را ساده سازید:** یک مثال از آن کد واضح و [README دوستانه](../starting-a-project/#نوشتن-راهنمای-مشارکت) است که راه اندازی پروژه تان را برای هر کسی هموارتر می سازد.
 * **بطور واضح توضیح دهید که مشارکت چگونه است،** البته این کار با استفاده از [فایل مشارکت](../starting-a-project/#نوشتن-راهنمای-مشارکت) و به روز نگه داشتن موضوعات میسر است.
 
-* **موضوعات اولیه خوب:** برای کمک کردن به اینکه مشارکت کنندگان جدید کار خود را شروع کنند، [برچسب زدن به موضوعاتی که برای موفقیت مبتدی ها به قدر کافی ساده هستند](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) را بطور آشکار لحاظ کنید. سپس GitHub، این موضوعات را در محل های مختلف روی پلتفورم هموار می سازد، و مشارکت های مفید را افزایش می دهد و سپس ناسازگاری از کاربران مختلف در فائق آمدن بر موضوعاتی که در سطح آنها خیلی دشوار است را کاهش می دهد.
+* **موضوعات اولیه خوب:** برای کمک کردن به اینکه مشارکت کنندگان جدید کار خود را شروع کنند، [برچسب زدن به موضوعاتی که برای موفقیت مبتدی ها به قدر کافی ساده هستند](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) را بطور آشکار لحاظ کنید. سپس <span dir="rtl">GitHub</span> ، این موضوعات را در محل های مختلف روی پلتفورم هموار می سازد، و مشارکت های مفید را افزایش می دهد و سپس ناسازگاری از کاربران مختلف در فائق آمدن بر موضوعاتی که در سطح آنها خیلی دشوار است را کاهش می دهد.
 
-{نظرسنجی منبع باز( اوپن سورس) 2017 GitHub][GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) که مستندات ناقص و گیچ کننده ای را نشان می داد، بزرگترین مشکل برای کاربران منبع باز می باشد. مستندات خوب، افراد را دعوت می کند که با پروژه‌تان تعامل کنند. در نهایت افراد یک موضوع یا یک درخواست pull( ادغام یا یکپارچگی) را باز خواهند کرد. از این تعاملات به عنوان فرصتهایی برای سوق دادن آنها به پایین قیف استفاده کنید.
+[نظرسنجی منبع باز( اوپن سورس) 2017 <span dir="rtl">GitHub</span>](http://opensourcesurvey.org/2017/) که مستندات ناقص و گیچ کننده ای را نشان می داد، بزرگترین مشکل برای کاربران منبع باز می باشد. مستندات خوب، افراد را دعوت می کند که با پروژه‌تان تعامل کنند. در نهایت افراد یک موضوع یا یک درخواست <span dir="rtl">pull</span>( ادغام یا یکپارچگی) را باز خواهند کرد. از این تعاملات به عنوان فرصتهایی برای سوق دادن آنها به پایین قیف استفاده کنید.
 
-* **وقتی شخص جدیدی وارد پروژه شما می شود، از وی از روی علاقه تشکر کنید!** این یک تجربه منفی خواهد بود که از فردی بخواهید که از پروژه تان خارج نشود.
+* **وقتی شخص جدیدی وارد پروژه شما می شود، از وی از روی علاقه تشکر کنید!** این یک تجربه منفی خواهد بود که از فردی بخواهید که به پروژه تان برنگردد.
 * **پاسخگو باشید:** اگر شما به موضوعاتشان در عرض یک ماه پاسخ نمی دهید، شانس اینکه پروژه تان را فراموش کنند بالا می رود.
 * **درباره انواع مشارکت هایی که خواهید پذیرفت ، پذیرای عقاید و افکار جدید باشید.** بسیاری از مشارکت کننده ها با یک گزارش باگ یا ترمیم جزئی آغاز می کنند. راه های زیادی برای مشارکت در یک پروژه وجود دارد. به افراد اجازه دهید تا بازگو کنند [چطور می خواهند مساعدت کنند](../how-to-contribute/#what-it-means-to-contribute).
 * **اگر یک مشارکتی وجود دارد که شما با آن مخالف هستید،** از آنها به خاطر بیان ایده تشکر کرده و [توضیح دهید](../best-practices/#نه-گفتن-را-یاد-بگیرید) چرا آن ایده با محدوده پروژه تان تناسب ندارد، و اگر مستندات خوبی دارید رو کنید.
@@ -54,7 +54,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  آیا شما تاکنون در یک رویداد (فناوری) بوده اید که در آن  هیچ کس را نشناسید، اما افراد دیگر همدیگر را می شناسند و با دوستان قدیمیشان چت می کنند؟ (...) حالا  تصور کنید می خواهید که در یک پروژه منبع باز مشارکت کنید، اما چرایی و چگونگی رخ دادن آن را نمی بینید.
+  آیا شما تاکنون در یک رویداد (فناوری) بوده اید که در آن  هیچ کس را نشناسید، اما افراد دیگر همدیگر را می شناسند و با دوستان قدیمیشان چت می کنند؟ (...) حالا  تصور کنید می خواهید در یک پروژه منبع باز مشارکت کنید، اما چرایی و چگونگی رخ دادن آن را نمی بینید.
   <p markdown="1" class="pquote-credit">
 — @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
@@ -68,11 +68,11 @@ related:
 
 درباره نقشه مسیر پروژه تان ، انواع مشارکت هایی که شما در پی آنها هستید، اینکه چطور مشارکت ها بررسی می شوند یا اینکه چرا تصمیمات خاصی را اتخاذ می کنید ، شفاف سازی کنید.
 
-اگر شما کاربران متعددی را مطلع سازید تا مسئله مشابهی را بررسی کنند، جوابها را در README مستند سازید. 
+اگر شما کاربران متعددی را مطلع سازید تا مسئله مشابهی را بررسی کنند، جوابها را در <span dir="rtl">README</span> مستند سازید. 
 
 برای جلسات، منتشر کردن یادداشت ها و نقشه های مسیر خود در یک موضوع مرتبط را مدنظر قرار دهید. بازخوردی که از این سطح از شفافیت کسب می کنید شاید شما را شگفت زده کند.
 
-مستندسازی همه چیزها با کاری که شما انجام می دهید نیز همگام است. اگر شما در حال کار بر روی آپدیت کردن پروژه تان در حجم زیاد هستید، برای آن یک بخش درخواست pull اعمال کنید و آن را به عنوان کاری که در حال پیشرفت است نمره دهید(WIP). از این طریق، افراد دیگر می توانند در پروسه شما اعمال نظر کنند
+مستندسازی همه چیزها با کاری که شما انجام می دهید نیز همگام است. اگر شما در حال کار بر روی آپدیت کردن پروژه تان در حجم زیاد هستید، برای آن یک بخش درخواست <span dir="rtl">pull</span> اعمال کنید و آن را به عنوان کاری که در حال پیشرفت است نمره دهید <span dir="rtl">(WIP)</span> .از این طریق، افراد دیگر می توانند در پروسه شما اعمال نظر کنند
 
 ### پاسخگو باشید
 
@@ -80,27 +80,27 @@ related:
 
 سعی کنید که هنگامی که شخصی یک موضوع را پیوست می کند، تحویل می دهد یا درخواستی دارد یا درباره پروژه تان سوالی می پرسد پاسخگو باشید. وقتی شما به سرعت پاسخ دهید، افراد احساس خواهند کرد که آنها بخشی از یک گفتگو هستند و درباره مشارکت با شما مشتاق تر خواهند بود.
 
-حتی اگر نمی توانید درخواستشان را فوراً بررسی کنید،حداقل از آنها تشکر کنید تا به افزایش مشارکت کمک کرده باشید. اینجا بیان می شود چطور @tdreyno به یک درخواست pull در سایت [Middleman](https://github.com/middleman/middleman/pull/1466) پاسخ داده است:
+حتی اگر نمی توانید درخواستشان را فوراً بررسی کنید،حداقل از آنها تشکر کنید تا به افزایش مشارکت کمک کرده باشید. اینجا بیان می شود چطور @tdreyno به یک درخواست <span dir="rtl">pull</span> در سایت [Middleman](https://github.com/middleman/middleman/pull/1466) پاسخ داده است:
 
 ![Middleman pull request](/assets/images/building-community/middleman_pr.png)
 
-[یک مطالعه موزیلا](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) پی برده است که مشارکت کنندگانی که بررسی های کدگونه را در ظرف 48 ساعت دریافت کرده بودند میزان برگشت و تکرار مشارکت خیلی بیشتری داشتند
+[در‌یک مطالعه موزیلا](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) پی برده است که مشارکت کنندگانی که بررسی های کدگونه را در ظرف 48 ساعت دریافت کرده بودند میزان برگشت و تکرار مشارکت خیلی بیشتری داشتند
 
-همچنین مکالمات درباره پروژه تان می تواند در محل های د Oیگری در اینترنت مانند Stackverflow ، توییتر، یا Reddit روی دهد. شما می توانید در برخی از این محل ها نوتیفیکیشن هایی را اجرا کنید و بدین طریق هنگامی که شخصی به پروژه تان اشاره می کند، با خبر شوید.
+همچنین مکالمات درباره پروژه تان می تواند در محل های دیگری در اینترنت مانند <span dir="rtl">Stackverflow</span> ، توییتر، یا <span dir="rtl">Reddit</span> روی دهد. شما می توانید در برخی از این محل ها نوتیفیکیشن هایی را اجرا کنید و بدین طریق هنگامی که شخصی به پروژه تان اشاره می کند، با خبر شوید.
 
-### به انجمن تان یک محلی برای مشارکت کردن اختصاص دهید
+### محلی برای مشارکت کردن انجمن تان اختصاص دهید
 
 دو دلیل برای اعطای یک محل برای مشارکت در انجمن‌تان وجود دارد.
 
-اولین دلیل به خاطر مشارکت کنندگان است. به افراد کمک کنید تا همدیگر را بشناسند. افراد دارای منافع مشترک، بطور اجتناب ناپذیری می خواهند که محلی برای گفتگو درباره آن منافع داشته باشند. و وقتی ارتباطات علنی و قابل دسترس باشد، هر کسی می تواند آرشیوهای گذشته را بخواند تا به مشارکت خود شتاب بخشد. 
+اولین دلیل به خاطر مشارکت کنندگان است. به افراد کمک کنید تا همدیگر را بشناسند. افراد دارای منافع مشترک، بطور اجتناب ناپذیری می خواهند که محلی برای گفتگو درباره آن منافع داشته باشند و وقتی ارتباطات علنی و قابل دسترس باشد، هر کسی می تواند آرشیوهای گذشته را بخواند تا به مشارکت خود شتاب بخشد. 
 
-دلیل دوم به خاطر خود شما است. اگر شما به افراد محل عمومی برای صحبت درباره پروژه تان ندهید، آنها احتمالاً با شما مستقیماً تماس خواهند گرفت. در شروع، ظاهراً ساده است که به پیامهای خصوصی  با موضوع « فقط اینبار»پاسخ دهید. اما در طول زمان مخصوصاً اگر پروژه تان معروف شود، شما کلافه خواهید شد. در برابر وسوسه ارتباط برقرار کردن با افراد درباره پروژه تان بطور خصوصی مقاومت کنید. در عوض آنها را به یک کانال عمومی معین هدایت کنید.
+دلیل دوم به خاطر خود شما است. اگر شما به افراد محل عمومی برای صحبت درباره پروژه تان ندهید، آنها احتمالاً با شما مستقیماً تماس خواهند گرفت. در شروع، ظاهراً ساده است که به پیامهای خصوصی  با موضوع « فقط این بار»پاسخ دهید. اما در طول زمان مخصوصاً اگر پروژه تان معروف شود، شما کلافه خواهید شد. در برابر وسوسه ارتباط برقرار کردن با افراد درباره پروژه تان بطور خصوصی مقاومت کنید. در عوض آنها را به یک کانال عمومی معین هدایت کنید.
 
-ارتباطات عمومی می تواند در حقیقت هدایت کردن مردم برای باز کردن یک موضوع به جای ایمیل مستقیم یا اظهار نظر کردن روی وبلاگ‌تان باشد. همچنین شما می توانید یک لیست مِیلی داشته باشید، یا یک حساب توییتر، Slack یا کانال IRC برای افراد راه بیاندازید تا درباره پروژه تان گفتگو کنند. یا همه موارد بالا را با هم اعمال کنید!
+ارتباطات عمومی می تواند در حقیقت هدایت کردن مردم برای باز کردن یک موضوع به جای ایمیل مستقیم یا اظهار نظر کردن روی وبلاگ‌تان باشد. همچنین شما می توانید یک لیست مِیلی داشته باشید، یا یک حساب توییتر، <span dir="rtl">Slack</span> یا کانال <span dir="rtl">IRC</span> برای افراد راه بیاندازید تا درباره پروژه تان گفتگو کنند. یا همه موارد بالا را با هم اعمال کنید!
 
 [Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) هر هفته وقت خود را در ساعات اداری به کمک به اعضای انجمن اختصاص می دهد:
 
-> همچنین کاپس هر هفته زمانی را برای پیشنهاد دادن کمک و راهنمایی به انجمن اختصاص می دهد. مالکان کاپس با اختصاص زمان اختصاصی برای کار کردن با تازه واردها، کمک به PRs ، و بحث درباره ویژگی های جدید موافقت کرده اند.
+> همچنین کاپس هر هفته زمانی را برای پیشنهاد دادن کمک و راهنمایی به انجمن اختصاص می دهد. مالکان کاپس با اختصاص زمان اختصاصی برای کار کردن با تازه واردها، کمک به <span dir="rtl">PRs</span> ، و بحث درباره ویژگی های جدید موافقت کرده اند.
 
 استثنائات قابل توجهی در مورد ارتباطات عمومی وجود دارد از قبیلِ: موضوعات امنیتی و نقض کدهای رفتاری حساس. شما باید همیشه راهی پیش پای افراد بگذارید تا این موضوعات را بطور خصوصی گزارش کنند. اگر نمی خواهید که از ایمیل شخصی خود استفاده کنید، یک آدرس ایمیل اختصاصی ایجاد کنید.
 
@@ -116,7 +116,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
-  حقیقت این است که داشتن یک جامعه حامی بسیار حیاتی است. من هرگز قادر به انجام چنین کاری بدون کمک همکارانم، غریبه هایی که در اینترنت و کانال های IRC چت با آنها دوست شدم نبودم(...). البته نباید به دون مایه ها و عوضی ها اکتفا نمود.
+  حقیقت این است که داشتن یک جامعه حامی بسیار حیاتی است. من هرگز قادر به انجام چنین کاری بدون کمک همکارانم، غریبه هایی که در اینترنت و کانال های <span dir="rtl">IRC</span> چت با آنها دوست شدم نبودم(...). البته نباید به دون مایه ها و عوضی ها اکتفا نمود.
   <p markdown="1" class="pquote-credit">
 — @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
   </p>
@@ -130,7 +130,7 @@ related:
 
 مستندسازی خوب تنها هنگامی مهمتر می شود که انجمن تان رشد می کند. مشارکت کنندگان اتفاقی که ممکن است با پروژه تان آشنا نباشند ، مستنداتتان را می خوانند تا به سرعت متنی که آنها نیاز دارند را بدست آورند.
 
-در فایل Contributing خود، بطور آشکار به مشارکت کنندگان جدید بگویید که چگونه کار خود را شروع کنند. شما شاید حتی بخواهید که یک بخش اختصاصی برای این منظور بسازید. برای مثال [Django](https://github.com/django/django) یک صفحه ویژه برای خوشامدگویی به مشارکت کنندگان جدید دارد
+در فایل <span dir="rtl">Contributing</span> خود، بطور آشکار به مشارکت کنندگان جدید بگویید که چگونه کار خود را شروع کنند. شما شاید حتی بخواهید که یک بخش اختصاصی برای این منظور بسازید. برای مثال [Django](https://github.com/django/django) یک صفحه ویژه برای خوشامدگویی به مشارکت کنندگان جدید دارد
 
 ![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
 
@@ -144,7 +144,7 @@ related:
 
 > ما می خواهیم که کار خود را با قدردانی از شما برای استفاده از روبینیوس شروع کنیم. این پروژه یک کار عاشقانه است و ما از همه کاربرانی که باگها را معرفی می کنند، عملکردها را بهبود می دهند و به مستندسازی کمک می کنند، قدردانی می کنیم. هر مشارکتی مهم است پس از شما برای مشارکت سپاسگزاری می کنیم. اینکه گفته می شود اینجا رهنمودهای کمی وجود دارند که ما از شما بخواهیم تا از آنها پیروی کنید، می تواند باعث موفقیت رسیدگی به موضوعتان شود.
 
-### مالکیت پروژه تان را به اشتراک گذارید
+### مالکیت پروژه تان را به اشتراک بگذارید
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
@@ -154,11 +154,11 @@ related:
   </p>
 </aside>
 
-افراد با مشارکت در پروژه هایتان هنگام احساس مالکیت بر آن هیجان زده می شوند. این بدان معنی نیست که شما باید چشم انداز پروژه تان را تغییر دهید یا مشارکتهایی که شما نمی خواهید را بپذیرید. اما هرچه به دیگران اعتبار بیشتری ببخشید، آنها بیشتر انتظار آن را می کشند.
+افراد با مشارکت در پروژه هایتان هنگام احساس مالکیت بر آن، هیجان زده می شوند. این بدان معنی نیست که شما باید چشم انداز پروژه تان را تغییر دهید یا مشارکتهایی که شما نمی خواهید را بپذیرید. اما هرچه به دیگران اعتبار بیشتری ببخشید، آنها بیشتر انتظار آن را می کشند.
 
 ببینید آیا می توانید تا آنجا که ممکن است راه هایی را برای تسهیم مالکیت با انجمن تان بیابید. در اینجا بعضی ایده ها در این باره ارائه می شوند:
 
-* **در برابر رفع باگ های ( غیرسرنوشت ساز) ساده مقاومت کنید:** در عوض از آنها به عنوان فرصتهایی برای پذیرش مشارکت کنندگان جدید استفاده کنید، یا شخصی که تمایل به مشارکت دارد، را راهنمایی کنید. شاید در اول غیرطبیعی به نظر برسد، اما سرمایه گذاری‌تان در طول زمان بازدهی‌اش را به تدریج بدست خواهد داد. برای مثال، @michaeljoseph از یک مشارکت کننده خواست تا درخواست Pull خود را درباره موضوع [Cookiecutter](https://github.com/audreyr/cookiecutter) به جای تعمیر آن توسط خودش ارائه دهد.
+* **در برابر رفع باگ های ( غیرسرنوشت ساز) ساده مقاومت کنید:** در عوض از آنها به عنوان فرصتهایی برای پذیرش مشارکت کنندگان جدید استفاده کنید، یا شخصی که تمایل به مشارکت دارد، را راهنمایی کنید. شاید در اول غیرطبیعی به نظر برسد، اما سرمایه گذاری‌تان در طول زمان بازدهی‌اش را به تدریج بدست خواهد داد. برای مثال،<span dir="rtl">@michaeljoseph</span> از یک مشارکت کننده خواست تا درخواست <span dir="rtl">pull</span> خود را درباره موضوع [Cookiecutter](https://github.com/audreyr/cookiecutter) به جای تعمیر آن توسط خودش ارائه دهد.
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
@@ -166,7 +166,7 @@ related:
 
 * **اگر شما یک انجمن بزرگ دارید، یک خبرنامه منتشر کنید یا یک پست وبلاگی بنویسید** که قدردان مشارکت کنندگان هستید. خبرنامه های [This Week in Rust](https://this-week-in-rust.org/) و [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) هودی دو نمونه خوب از این موارد هستند.
 
-* **به همه مشارکت کنندگان دسترسی Commit کردن بدهید.** @fleixge پی برد که این کار، [افراد را وادار می کند](https://felixge.de/2013/03/11/the-pull-request-hack.html) تا با هیجان بیشتری patch هایشان را اصلاح کنند و حتی باعث می شود اعضای جدید برای پروژه هایی بیابید که روی آنها سرمایه گذاری نکرده بودید.
+* **به همه مشارکت کنندگان دسترسی <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/) انتقال دهید** و حداقل یک ادمین پشتیبان به آن بیافزایید. سازمان ها کار کردن روی پروژه هایی با همکاران خارجی را آسانتر می سازند.
 
@@ -208,9 +208,9 @@ related:
 
 خونسرد بودن آسان نیست، اما نشان دادن رهبری ، سلامت انجمن تان را بهبود می بخشد. اینترنت از شما تشکر می کند.
 
-### فایل README خود را به عنوان یک قانون اساسی در نظر بگیرید
+### فایل <span dir="rtl">README</span> خود را به عنوان یک قانون اساسی در نظر بگیرید
 
-فایل README تان [بیشتر از یک مجموعه رهنمودها است](../starting-a-project/#نوشتن-راهنمای-مشارکت)، همچنین یک محلی برای گفتگو درباره اهداف، دیدگاه و نقشه مسیرتان است. اگر افراد آشکارا روی بحث درباره ارزش یک ویژگی خاص تمرکز می کنند، این کار به تجدیدنظر درباره README تان و صحبت درباره دیدگاه بهتر درباره پروژه تان کمک می کند. تمرکز روی README تان همچنین این مکالمات را غیرمحرمانه می سازد، بنابراین شما می توانید یک بحث سازنده را دنبال کنید.
+فایل <span dir="rtl">README</span> تان [بیشتر از یک مجموعه رهنمودها است](../starting-a-project/#نوشتن-راهنمای-مشارکت)، همچنین یک محلی برای گفتگو درباره اهداف، دیدگاه و نقشه مسیرتان است. اگر افراد آشکارا روی بحث درباره ارزش یک ویژگی خاص تمرکز می کنند، این کار به تجدیدنظر درباره <span dir="rtl">README</span> تان و صحبت درباره دیدگاه بهتر درباره پروژه تان کمک می کند. تمرکز روی <span dir="rtl">README</span> تان همچنین این مکالمات را غیرمحرمانه می سازد، بنابراین شما می توانید یک بحث سازنده را دنبال کنید.
 
 ### تمرکز روی سفر نه مقصد
 
@@ -268,7 +268,7 @@ related:
 
 با یک نگرش خوب و ارتباطات واضح، اکثر شرایط دشوار قابل حل هستند. البته حتی در مکالمه سودمند، می تواند یک تفاوت در عقیده درباره چگونگی پیشرفت رویه ها وجود داشته باشد. در این موارد، یک فرد یا گروه از افرادی را شناسایی کنید که می توانند به عنوان رهگشا عمل کنند.
 
-یک رهگشا می تواند نگه دارنده اولیه پروژه باشد یا می تواند یک گروه کوچک از کسانی باشند که مبتنی بر رای گیری تصمیم می گیرند. بطور ایده آل شما یک رهگشا و یک فرایند مرتبط در یک فایل GOVERNANCE  را شناسایی کرده اید قبل از اینکه ملزم باشید که از آن استفاده کنید.
+یک رهگشا می تواند نگه دارنده اولیه پروژه باشد یا می تواند یک گروه کوچک از کسانی باشند که مبتنی بر رای گیری تصمیم می گیرند. بطور ایده آل شما یک رهگشا و یک فرایند مرتبط در یک فایل <span dir="rtl">GOVERNANCE</span> را شناسایی کرده اید قبل از اینکه ملزم باشید که از آن استفاده کنید.
 
 رهگشایتان، باید یک تصمیم گیرنده نهایی باشد. موضوعات نفاق انگیز فرصتی برای انجمن تان است تا درس بگیرد و تکامل یابد. در آغوش کشیدن این فرصتها و استفاده از یک فرایند همکارانه برای حرکت به سوی یک راه حل هرجایی شدنی است.
 

From 7dbb5f0a5a69facfb4ca312b9b411cb798592846 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 14 Oct 2021 08:04:55 +0000
Subject: [PATCH 264/749] Bump github-pages from 220 to 221

Bumps [github-pages](https://github.com/github/pages-gem) from 220 to 221.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v220...v221)

---
updated-dependencies:
- dependency-name: github-pages
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 05aaed1e9b4..70c1c375a38 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -22,7 +22,7 @@ GEM
     em-websocket (0.5.2)
       eventmachine (>= 0.12.9)
       http_parser.rb (~> 0.6.0)
-    ethon (0.14.0)
+    ethon (0.15.0)
       ffi (>= 1.15.0)
     eventmachine (1.2.7)
     execjs (2.8.1)
@@ -48,7 +48,7 @@ GEM
     ffi (1.15.4)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (220)
+    github-pages (221)
       github-pages-health-check (= 1.17.9)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
@@ -89,7 +89,7 @@ GEM
       liquid (= 4.0.3)
       mercenary (~> 0.3)
       minima (= 2.5.1)
-      nokogiri (>= 1.10.4, < 2.0)
+      nokogiri (>= 1.12.5, < 2.0)
       rouge (= 3.26.0)
       terminal-table (~> 1.4)
     github-pages-health-check (1.17.9)

From bf50939dc272b2ccbaf9946c564399c110f3d047 Mon Sep 17 00:00:00 2001
From: lunarwhite <57584831+lunarwhite@users.noreply.github.com>
Date: Sat, 16 Oct 2021 17:39:40 +0800
Subject: [PATCH 265/749] Fix typo

Word "iuuse" should be "issue".
---
 _articles/zh-hans/metrics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/metrics.md b/_articles/zh-hans/metrics.md
index da2b857ccf7..5f5b00baf5c 100644
--- a/_articles/zh-hans/metrics.md
+++ b/_articles/zh-hans/metrics.md
@@ -119,7 +119,7 @@ redirect_from: /zh-cn/metrics/
 
 * 一个issue保持打开状态的时间（也就代表一个问题保持没有被解决状态的时间）。
 * 一个issue是否因为一个PR得到了解决。
-* 陈旧的iuuse是否被关闭了（被解决的问题应该关闭）。
+* 陈旧的issue是否被关闭了（被解决的问题应该关闭）。
 * 合并一个PR的时间。
 
 ## 通过统计 📊 来了解人们的习惯

From fb29f2efb9029016f2bdff4adfb9f79776fd3f7e Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 18 Oct 2021 08:10:37 +0000
Subject: [PATCH 266/749] Bump actions/checkout from 2.3.4 to 2.3.5

Bumps [actions/checkout](https://github.com/actions/checkout) from 2.3.4 to 2.3.5.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v2.3.4...v2.3.5)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index ce7f850bf40..8916562e180 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -8,7 +8,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
     - name: Set up Git repository
-      uses: actions/checkout@v2.3.4
+      uses: actions/checkout@v2.3.5
 
     - name: Set up Ruby
       uses: actions/setup-ruby@v1.1.3

From bad0f7261202a2674b99583879ef719711ea5e08 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dar=C3=ADo=20Here=C3=B1=C3=BA?= <magallania@gmail.com>
Date: Fri, 22 Oct 2021 20:46:32 -0300
Subject: [PATCH 267/749] Minor proposals (line 07)

---
 _data/locales/es.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_data/locales/es.yml b/_data/locales/es.yml
index 3eb1c235f37..428378c7125 100644
--- a/_data/locales/es.yml
+++ b/_data/locales/es.yml
@@ -4,7 +4,7 @@ es:
     about: Acerca de
     contribute: Contribuir
   index:
-    lead: El software de código abierto es desarrollado por personas como tu, aprende cómo crear y hacer que tu proyecto crezca.
+    lead: El software de código abierto es desarrollado por personas como tú, aprende cómo crear y hacer que tu proyecto crezca.
     opensourcefriday: ¡Es viernes! Invierte unas cuántas horas para contribuir al software que usas y amas
   article:
     table_of_contents: Tabla de contenidos

From 49bc7322bcb81cf591c53ed79a0a9306bd98a5fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dar=C3=ADo=20Here=C3=B1=C3=BA?= <magallania@gmail.com>
Date: Fri, 22 Oct 2021 21:48:08 -0300
Subject: [PATCH 268/749] Minor fixes (paragraph 49, lines 57)

- minor proposal of translation (line 61, paragraph 156)
- typos fixed line 62, 63, paragraph 172
- syntax issue (line 117)
---
 _articles/es/best-practices.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/_articles/es/best-practices.md b/_articles/es/best-practices.md
index fa24072845e..2d4125b72ee 100644
--- a/_articles/es/best-practices.md
+++ b/_articles/es/best-practices.md
@@ -46,7 +46,7 @@ Por ejemplo, @lord descubri&oacute; que tener la visi&oacute;n de un proyecto lo
 
 ### Comunicar tus expectativas
 
-Algunas veces puede que sea complicado detallar las reglas para que otra gente pueda contribuir. Puedes llegar a sentir que est&aacute;s comport&aacute;ndote como un policia o arruinando la diversi&oacute;n para los dem&aacute;s.
+Algunas veces puede que sea complicado detallar las reglas para que otra gente pueda contribuir. Puedes llegar a sentir que est&aacute;s comport&aacute;ndote como un policía o arruinando la diversi&oacute;n para los dem&aacute;s.
 
 Escritas y aplicadas de manera justa, sin embargo, las buenas reglas dan poder a los mantenedores de c&oacute;digo. Evitan que te arrastren a hacer cosas que no quieres hacer.
 
@@ -54,13 +54,13 @@ La mayor&iacute;a de las personas que se encuentran con tu proyecto no saben nad
 
 ¡Est&aacute; perfectamente bien! S&oacute;lo aseg&uacute;rate de que la gente lo sepa.
 
-Si el mantenimiento de tu proyecto es a tiempo parcial o simplemente ser voluntario, se honesto acerca de cu&aacute;nto tiempo tienes. Esto no es lo mismo que cu&aacute;nto tiempo piensas que el proyecto requiere, o cu&aacute;nto tiempo otros quieren que gastes.
+Si el mantenimiento de tu proyecto es a tiempo parcial o simplemente ser voluntario, sé honesto acerca de cu&aacute;nto tiempo tienes. Esto no es lo mismo que cu&aacute;nto tiempo piensas que el proyecto requiere, o cu&aacute;nto tiempo otros quieren que gastes.
 
 Aqu&iacute; hay algunas reglas que vale la pena anotar:
 
-* C&oacute;mo se revisa y acepta una contribuci&oacute;n (_¿Necesitan hacer testing? ¿Alguna plantilla que deban utilizar para las issues?_)
-* Los tipos de contribuciones que acepatar&aacute;s (_¿S&oacute;lo quieres ayuda con una parte del c&oacute;digo?_)
-* Cuando es apropieado hacer seguimiento (_eg. "Puede esperar una respuesta de un mantenedor de c&oacute;digo dentro de los pr&oacute;ximos 7 d&iacute;as. Si no ha o&iacute;do nada para entonces, no dude en hacer ping al hilo."_)
+* C&oacute;mo se revisa y acepta una contribuci&oacute;n (_¿Necesitan hacer pruebas? ¿Alguna plantilla que deban utilizar para las issues?_)
+* Los tipos de contribuciones que aceptar&aacute;s (_¿S&oacute;lo quieres ayuda con una parte del c&oacute;digo?_)
+* Cuando es apropiado hacer seguimiento (_eg. "Puede esperar una respuesta de un mantenedor de c&oacute;digo dentro de los pr&oacute;ximos 7 d&iacute;as. Si no ha o&iacute;do nada para entonces, no dude en hacer ping al hilo."_)
 * Cuanto tiempo dedicas al proyecto (_eg. "S&oacute;lo invertimos unas 5 horas semanales en este proyecto"_)
 
 [Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), y [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) son algunos ejemplos de proyectos con reglas claras para mantenedores y colaboradores.
@@ -114,7 +114,7 @@ Si no quieres aceptar una contribuci&oacute;n:
 * **Comparte informaci&oacute;n relevante**, si la tienes. Si notas peticiones repetidas de cosas que no deseas aceptar, agr&eacute;galas a tu documentaci&oacute;n para evitar explicar siempre lo mismo.
 * **Cierra la solicitud**
 
-no deber&iacute;as necesitar m&aacute;s de 1-2 oraciones para responder. por ejemplo, cuando un usuario de [celery](https://github.com/celery/celery/) report&oacute; un error relacionado a Windows, @berkerpeksag [respondi&oacute; con](https://github.com/celery/celery/issues/3383):
+no deber&iacute;as necesitar m&aacute;s de 1-2 oraciones para responder. Por ejemplo, cuando un usuario de [celery](https://github.com/celery/celery/) report&oacute; un error relacionado a Windows, @berkerpeksag [respondi&oacute; con](https://github.com/celery/celery/issues/3383):
 
 [celery screenshot](/assets/images/best-practices/celery.png)
 
@@ -153,7 +153,7 @@ A veces, cuando dices que no, tu contribuyente potencial puede molestarse o crit
 
 Tal vez alguien en tu comunidad env&iacute;e regularmente contribuciones que no cumplen con los est&aacute;ndares de tu proyecto. Puede ser frustrante para ambas partes pasar repetidamente por el proceso de rechazo.
 
-Si ves que alguien est&aacute; entusiasmado con tu proyecto, pero necesita un poco de pr&aacute;ctica, ten paciencia. Explica claramente en cada situaci&oacute;n por qu&eacute; sus contribuciones no cumplen con las expectativas del proyecto. Trata de asignarles una tarea m&aacute;s f&aacute;cil o menos ambigua, como una issue marcada como _"good first issue,"_ , para entrar en calor. Si tienes tiempo, considera mentorearlos a trav&eacute;s de su primera contribuci&oacute;n, o encuentra a alguien m&aacute;s en tu comunidad que est&eacute; dispuesto a ser mentor de ellos.
+Si ves que alguien est&aacute; entusiasmado con tu proyecto, pero necesita un poco de pr&aacute;ctica, ten paciencia. Explica claramente en cada situaci&oacute;n por qu&eacute; sus contribuciones no cumplen con las expectativas del proyecto. Trata de asignarles una tarea m&aacute;s f&aacute;cil o menos ambigua, como una issue marcada como _"good first issue,"_ , para entrar en calor. Si tienes tiempo, considera asesorando a trav&eacute;s de su primera contribuci&oacute;n, o encuentra a alguien m&aacute;s en tu comunidad que est&eacute; dispuesto a ser mentor de ellos.
 
 ## Aprovechando la comunidad
 
@@ -169,7 +169,7 @@ Alentar a otros a [compartir la propiedad del proyecto](../building-community/#c
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
-  Estuve diciendo, "Si, cualquier persona puede formar parte, no necesitas tener mucha experiencia en programaci&oacute;n [...]." Hemos tenido personas incriptas [a eventos] y ah&iacute; fue cuando me pregunt&eacute;: es esto cierto, lo que estuve diciendo? Habr&aacute;n 40 personas que se presentar&aacute;n, y no es como si pudiera sentarme con cada uno de ellos...Pero la gente se reuni&oacute;, y funcion&oacute;. tan pronto como una persona lo consiguiera, podr&iacute;a ense&ntilde;arle a sus vecinos.
+  Estuve diciendo, "Si, cualquier persona puede formar parte, no necesitas tener mucha experiencia en programaci&oacute;n [...]." Hemos tenido personas inscriptas [a eventos] y ah&iacute; fue cuando me pregunt&eacute;: es esto cierto, lo que estuve diciendo? Habr&aacute;n 40 personas que se presentar&aacute;n, y no es como si pudiera sentarme con cada uno de ellos...Pero la gente se reuni&oacute;, y funcion&oacute;. tan pronto como una persona lo consiguiera, podr&iacute;a ense&ntilde;arle a sus vecinos.
   <p markdown="1" class="pquote-credit">
 —  @lmccart, ["¿Qu&eacute; significa, al fin y al cabo, "C&oacute;digo Abierto"? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
   </p>

From fc971e9dc3ae36423afc12a0901327efa61f980d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dar=C3=ADo=20Here=C3=B1=C3=BA?= <magallania@gmail.com>
Date: Sat, 23 Oct 2021 18:32:12 -0300
Subject: [PATCH 269/749] Typos fixed (lines 25, 32, 34)

- typo fixed (paragraph 41, 95, 107, 123, 125, 160, 234, 262; paragraph 198, 228)
- semantic issue (at final of paragraph 77)
---
 _articles/es/building-community.md | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/_articles/es/building-community.md b/_articles/es/building-community.md
index a0e3273dfc3..a84128a2299 100644
--- a/_articles/es/building-community.md
+++ b/_articles/es/building-community.md
@@ -22,23 +22,23 @@ Una manera de pensar acerca de la comunidad del proyecto es a trav&eacute;s de l
 
 ![contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
 
-A medida que construyes tu comunidad, considera c&oacute;mo &aacute;lguien que se encuentra en la parte superior del embudo (un usuario potencial) puede te&oacute;ricamente hacer su camino hacia abajo (un mantenedor activo). Tu objetivo es reducir la fricci&oacute;n en cada etapa de la experiencia del colaborador. Cuando las personas  obtienen victorias f&aacute;ciles, se sentir&aacute;n incentivadas a hacer m&aacute;s.
+A medida que construyes tu comunidad, considera c&oacute;mo alguien que se encuentra en la parte superior del embudo (un usuario potencial) puede te&oacute;ricamente hacer su camino hacia abajo (un mantenedor activo). Tu objetivo es reducir la fricci&oacute;n en cada etapa de la experiencia del colaborador. Cuando las personas  obtienen victorias f&aacute;ciles, se sentir&aacute;n incentivadas a hacer m&aacute;s.
 
 Comienza con tu documentaci&oacute;n:
 
 * **Hazlo sencillo para quienes tienen que utilizar el proyecto.** [Un documento README amigable](../starting-a-project/#escribiendo-un-readme) y c&oacute;digos de ejemplo claros har&aacute;n m&aacute;s f&aacute;cil el comienzo para cualquiera que aterrice en tu proyecto.
 * **Explica claramente c&oacute;mo contribuir**, utilizando [un archivo CONTRIBUTING](../starting-a-project/#escribiendo-las-pautas-para-contribuir) y manteniendo tus problemas al d&iacute;a.
 
-Una buena documentaci&oacute;n invita a las personas a interactuar con tu proyecto. Eventualmente, &aacute;lguien abrir&aacute; un problema o un pull request.
+Una buena documentaci&oacute;n invita a las personas a interactuar con tu proyecto. Eventualmente, alguien abrir&aacute; un problema o un pull request.
 
-* **¡Cuando &aacute;lguien nuevo aterrice en tu proyecto, agrad&eacute;cele por su inter&eacute;s!** Es suficiente una sola experiencia negativa para que &aacute;lguien no quiera regresar.
+* **¡Cuando alguien nuevo aterrice en tu proyecto, agrad&eacute;cele por su inter&eacute;s!** Es suficiente una sola experiencia negativa para que alguien no quiera regresar.
 * **Comp&oacute;rtate de manera sensible.** Si no respondes a sus problemas por un mes, lo m&aacute;s probable es que ya se hayan olvidado de tu proyecto.
 * **Tener la mente abierta acerca de los tipos de contribuciones que aceptar&aacute;.** Muchos colaboradores comienzan reportando un error o con un arreglo peque&ntilde;o. Hay [muchas maneras de contribuir](../how-to-contribute/#qué-significa-contribuir) con un proyecto. Permite que las personas ayuden de la manera que ellos quieran ayudar.
 * **Si existe alguna contribuci&oacute;n con la que est&aacute;s en desacuerdo,** agrad&eacute;cele por su idea y [expl&iacute;cale porqu&eacute;](../best-practices/#aprendiendo-a-decir-no) no encaja en la incumbencia del proyecto, enlazando con documentaci&oacute;n relevante si la tienes.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  Contribuir con c&oacute;digo abierto es m&aacute;s f&aacute;cil para algunos que para otros. Hay mucho miedo de recibir un alarido por no haber hecho algo bien o simplemente por no encajar. (...) Al dar a los colaboradores un lugar para contribuir con aspectos de muy baja competencia t&eacute;cnica (documentaci&oacute;n, reducci&oacute;n del contenido web, etc) puedes ayudar a reducir esas preocupaciones significat&iacute;vamente.
+  Contribuir con c&oacute;digo abierto es m&aacute;s f&aacute;cil para algunos que para otros. Hay mucho miedo de recibir un alarido por no haber hecho algo bien o simplemente por no encajar. (...) Al dar a los colaboradores un lugar para contribuir con aspectos de muy baja competencia t&eacute;cnica (documentaci&oacute;n, reducci&oacute;n del contenido web, etc) puedes ayudar a reducir esas preocupaciones significativamente.
   <p markdown="1" class="pquote-credit">
 — @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
   </p>
@@ -74,7 +74,7 @@ Documentar todo tambi&eacute;n se aplica al trabajo que tu haces. Si est&aacute;
 
 ### Comp&oacute;rtate de manera sensible
 
-A medida que [promocionas tu proyecto](../finding-users),las personas te har&aacute;n llegar sus comentarios. Pueden tener preguntas acerca de c&oacute;mo funcionan las cosas, o necesitar ayuda para comenzar
+A medida que [promocionas tu proyecto](../finding-users),las personas te har&aacute;n llegar sus comentarios. Pueden tener preguntas acerca de c&oacute;mo funcionan las cosas, o necesitar ayuda para comenzar.
 
 Trata de responder cuando &aacute;lguien presenta un problema, env&iacute;a un pull request o realiza una pregunta acerca de tu proyecto. Cuando respondes r&aacute;pidamente, logras que las personas se sientan parte del di&aacute;logo, y estar&aacute;n m&aacute;s entusiasmadas de participar.
 
@@ -92,7 +92,7 @@ Existen dos razones para brindar a tu comunidad un lugar para congregarse.
 
 La primera raz&oacute;n es para ellos. Ayuda a las personas a conocerse. Las personas con intereses comunes querr&aacute;n inevitablemente  un lugar para hablar de ello. Y cuando la comunicaci&oacute;n es p&uacute;blica y accesible, cualquiera puede leer los archivos pasados para ponerse al d&iacute;a y participar.
 
-La segunda raz&oacute;n es para t&iacute;. Si no brindas a las personas un lugar p&uacute;blico para conversar acerca de tu proyecto, probablemente te contactar&aacute;n directamente. Al comienzo puede no parecer demasiado responder a mensajes privados "s&oacute;lo por &eacute;sta vez". Pero con el tiempo, especialmente si tu proyecto se hace conocido, te sentir&aacute;s agotado. Evita la tentaci&oacute;n de comunicarte con las personas acerca de tu proyecto en privado. En su lugar, dir&iacute;gelos al canal p&uacute;blico designado.
+La segunda raz&oacute;n es para t&iacute;. Si no brindas a las personas un lugar p&uacute;blico para conversar acerca de tu proyecto, probablemente te contactar&aacute;n directamente. Al comienzo puede no parecer demasiado responder a mensajes privados "s&oacute;lo por esta vez". Pero con el tiempo, especialmente si tu proyecto se hace conocido, te sentir&aacute;s agotado. Evita la tentaci&oacute;n de comunicarte con las personas acerca de tu proyecto en privado. En su lugar, dir&iacute;gelos al canal p&uacute;blico designado.
 
 La comunicaci&oacute;n p&uacute;blica puede ser tan simple como dirigir a las personas a abrir un tema en lugar de enviarle un correo electr&oacute;nico a usted directamente o comentar en su blog. Podr&iacute;as incluso configurar una lista de correos electr&oacute;nicos, o crear una cuenta en Twitter, Slack o un canal IRC para que las personas puedan comentar sobre tu proyecto. ¡O prueba todo lo anterior!
 
@@ -104,7 +104,7 @@ Las excepciones notables a la comunicaci&oacute;n p&uacute;blica son: 1) cuestio
 
 ## Haciendo crecer tu comunidad
 
-Las comunidades son extremadamente poderosas. Ese poder puede ser una bendici&oacute;n o una maldici&oacute;ni, dependiendo de c&oacute;mo lo maneje. A medida que la comunidad de tu proyecto crece, existen maneras para ayudar a que se convierta en una fuerza de construcci&oacute;n, no de destrucci&oacute;n.
+Las comunidades son extremadamente poderosas. Ese poder puede ser una bendici&oacute;n o una maldici&oacute;n, dependiendo de c&oacute;mo lo maneje. A medida que la comunidad de tu proyecto crece, existen maneras para ayudar a que se convierta en una fuerza de construcci&oacute;n, no de destrucci&oacute;n.
 
 ### No toleres a los malos actores
 
@@ -120,9 +120,9 @@ Haz todo lo posible para adoptar una pol&iacute;tica de tolerancia cero hacia es
   </p>
 </aside>
 
-Los debates regulares sobre aspectos triviales de tu proyecto distrae a otros, incluy&eacute;ndote tambi&eacute;n a t&iacute;, de enfocarte en tareas importantes. Las nuevas personas que llegan a tu proyecto pueden ver estas conversaciones y pueden &oacute; no querer participar.
+Los debates regulares sobre aspectos triviales de tu proyecto distrae a otros, incluy&eacute;ndote tambi&eacute;n a t&iacute;, de enfocarte en tareas importantes. Las nuevas personas que llegan a tu proyecto pueden ver estas conversaciones y pueden o no querer participar.
 
-Cuando ves que ocurrre alg&uacute;n comportamiento negativo, haz la observaci&oacute;n correspondiente de manera p&uacute;blica. Expl&iacute;cale, en un tono amable, porqu&eacute; dicho comportamiento no es aceptable. Si el problema persiste, puedes necesitar [solicitarle que se retire](../code-of-conduct/#aplicando-tu-código-de-conducta). Tu [c&oacute;digo de conducta](../code-of-conduct/) puede ser una gu&iacute;a constructiva para estas conversaciones.
+Cuando ves que ocurre alg&uacute;n comportamiento negativo, haz la observaci&oacute;n correspondiente de manera p&uacute;blica. Expl&iacute;cale, en un tono amable, porqu&eacute; dicho comportamiento no es aceptable. Si el problema persiste, puedes necesitar [solicitarle que se retire](../code-of-conduct/#aplicando-tu-código-de-conducta). Tu [c&oacute;digo de conducta](../code-of-conduct/) puede ser una gu&iacute;a constructiva para estas conversaciones.
 
 ### Re&uacute;nete con los colaboradores donde ellos est&aacute;n
 
@@ -157,7 +157,7 @@ Las personas se entusiasman por contribuir con proyectos cuando perciben un sent
 
 Observa si puedes encontrar maneras de compartir la propiedad de tu comunidad tanto como te sea posible. Aqu&iacute; hay algunas ideas:
 
-* **Evita corregir errores sencillos (no cr&iacute;ticos).** En su lugar, utilizalos como oportunidades para reclutar nuevos colaboradores, o mentorear a &aacute;lguien que quiere contribuir. Puede parecer antinatural al principio, pero tu inversi&oacute;n se ver&aacute; compensada en el tiempo. Por ejemplo,  @michaeljoseph le pidi&oacute; a un colaborador que enviara un pull request de un problema detallado a continuaci&oacute;n [Cookiecutter](https://github.com/audreyr/cookiecutter) en lugar de arreglarlo &eacute;l mismo.
+* **Evita corregir errores sencillos (no cr&iacute;ticos).** En su lugar, utilizalos como oportunidades para reclutar nuevos colaboradores, o mentorear a alguien que quiere contribuir. Puede parecer antinatural al principio, pero tu inversi&oacute;n se ver&aacute; compensada en el tiempo. Por ejemplo,  @michaeljoseph le pidi&oacute; a un colaborador que enviara un pull request de un problema detallado a continuaci&oacute;n [Cookiecutter](https://github.com/audreyr/cookiecutter) en lugar de arreglarlo &eacute;l mismo.
 
 ![cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
@@ -195,7 +195,7 @@ En su mayor parte, si has cultivado una comunidad amistosa y que se maneja con r
 
 Cuando tu comunidad se encuentre lidiando con una cuesti&oacute;n dif&iacute;cil, los &aacute;nimos pueden subir. Las personas pueden enojarse o verse frustradas y tomar las cr&iacute;ticas como algo personal, incluso provenientes de t&iacute;.
 
-Tu trabajo como encargado es evitar que estas situaciones escalen. Incluso si tienes una fuerte opini&oacute;n sobre un tema, trata de mantener una posici&oacute;n de moderador o de facilitador, en lugar de ir a la lucha y empujar tus propios puntos de vista. Si &aacute;lguien est&aacute; comport&aacute;ndose de manera poco educada o monopolizando la conversaci&oacute;n, [act&uacute;a inmediatamente](../building-community/#no-toleres-a-los-malos-actores) para mantener una discusi&oacute;n civilizada y productiva.
+Tu trabajo como encargado es evitar que estas situaciones escalen. Incluso si tienes una fuerte opini&oacute;n sobre un tema, trata de mantener una posici&oacute;n de moderador o de facilitador, en lugar de ir a la lucha y empujar tus propios puntos de vista. Si alguien est&aacute; comport&aacute;ndose de manera poco educada o monopolizando la conversaci&oacute;n, [act&uacute;a inmediatamente](../building-community/#no-toleres-a-los-malos-actores) para mantener una discusi&oacute;n civilizada y productiva.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
@@ -225,13 +225,13 @@ Bajo un proceso de b&uacute;squeda de concenso, los miembros de la comunidad dis
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
-  Parte de la raz&oacute;n por la que la votaci&oacute;n no existe para Cuestiones At&oacute;micas es porque un Grupo At&oacute;mico no llevar&aacute; adelante un sistema de votac&iacute;on en todos los casos. Algunas veces tenemos que elegir lo que nos parece correcto incluso aunque no sea popular. (...) Lo que puedo ofrecer y prometo hacer... es escuchar a la comunidad.
+  Parte de la raz&oacute;n por la que la votaci&oacute;n no existe para Cuestiones At&oacute;micas es porque un Grupo At&oacute;mico no llevar&aacute; adelante un sistema de votaci&oacute;n en todos los casos. Algunas veces tenemos que elegir lo que nos parece correcto incluso aunque no sea popular. (...) Lo que puedo ofrecer y prometo hacer... es escuchar a la comunidad.
   <p markdown="1" class="pquote-credit">
 — @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
   </p>
 </aside>
 
-Incluso si no adopta un proceso de b&uacute;squeda de concenso, como responsable del proyecto, es importante que las personas sepan que est&aacute;s escuchando. Hacer que las personas se sientan escuchadas y comprometerte a resolver sus preocupaciones, facilita gran parte del camino para resolver situaciones delicadas. Luego, contin&uacute;a tus palabras con acciones.
+Incluso si no adopta un proceso de b&uacute;squeda de consenso, como responsable del proyecto, es importante que las personas sepan que est&aacute;s escuchando. Hacer que las personas se sientan escuchadas y comprometerte a resolver sus preocupaciones, facilita gran parte del camino para resolver situaciones delicadas. Luego, contin&uacute;a tus palabras con acciones.
 
 No te apresures a tomar una decisi&oacute;n por el bien de tener una soluci&oacute;n. Aseg&uacute;rate de que todos se sientan escuchados y que toda la informaci&oacute;n se ha hecho p&uacute;blica antes de avanzar hacia una soluci&oacute;n.
 
@@ -259,7 +259,7 @@ Si la conversaci&oacute;n claramente no va a ning&uacute;n lado, no existen acci
 
 ### Elige tus batallas sabiamente
 
-El contexto es importante. Considera qui&eacute;n est&aacute; involucrado en una discusi&oacute;n y c&oacute;mo representa &eacute;sta al resto de la comunidad.
+El contexto es importante. Considera qui&eacute;n est&aacute; involucrado en una discusi&oacute;n y c&oacute;mo representa esta al resto de la comunidad.
 
 ¿Est&aacute;n todos en la comunidad molestos, o incluso involucrados en un problema? ¿O es un provocador solitario? No te olvides de considerar a los miembros silenciosos de la comunidad, no solo a las voces activas.
 

From 27f860827d9f233584985ddcc30fb9f3ff369d1f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dar=C3=ADo=20Here=C3=B1=C3=BA?= <magallania@gmail.com>
Date: Sat, 23 Oct 2021 21:48:23 -0300
Subject: [PATCH 270/749] Minor translated word (paragraph 32, 55, 59)

- what does it mean the term `art` in paragraph 32?
- typos fixed (lines 53, 65, 71; paragraph 84, 90, 106, 108, 114)
- syntax issue (line 76)
---
 _articles/es/code-of-conduct.md | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/_articles/es/code-of-conduct.md b/_articles/es/code-of-conduct.md
index 654c9213658..e6b1b908a79 100644
--- a/_articles/es/code-of-conduct.md
+++ b/_articles/es/code-of-conduct.md
@@ -29,7 +29,7 @@ Adem&aacute;s de comunicar tus expectativas, un c&oacute;digo de conducta descri
 *	Que sucede si alguien viola el c&oacute;digo de conducta
 *	De qu&eacute; manera alguien puede reportar una violaci&oacute;n
 
-Siempre que sea posible, haga uso del art. El [Contributor Covenant](https://www.contributor-covenant.org/) es un c&oacute;digo de conducta usado por m&aacute;s de 40,000 proyectos de software libre, incluyendo Kubernetes, Rails, and Swift.
+Siempre que sea posible, haga uso del art. El [Contributor Covenant](https://www.contributor-covenant.org/) es un c&oacute;digo de conducta usado por m&aacute;s de 40,000 proyectos de software libre, incluyendo Kubernetes, Rails y Swift.
 
 El [Django Code of Conduct](https://www.djangoproject.com/conduct/) y el [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) son tambi&eacute;n dos ejemplos de buenos c&oacute;digos de conducta.
 
@@ -50,30 +50,30 @@ Deber&iacute;as explicar de qu&eacute; manera tu c&oacute;digo de conducta va a
 
 *	Tu comunidad se sentir&aacute; m&aacute;s segura de que sus reclamos son realmente revisados.
 
-*	Brindaras a tu comunidad la seguridad de que el proceso de revisi&oacute;n es justo y transparente, en el caso en que se encuentren siendo investigados por una violaci&oacute;n.
+*	Brindar&aacute;s a tu comunidad la seguridad de que el proceso de revisi&oacute;n es justo y transparente, en el caso en que se encuentren siendo investigados por una violaci&oacute;n.
 
-Deber&iacute;as brindar a las personas, una manera privada (por ejemplo, mediante una direcci&oacute;n de email) de reportar una violaci&oacute;n al c&oacute;digo de conducta y explicar qui&eacute;n recibe dicho reporte. Puede ser un responsable de mantenimiento, un grupo de tales responsables, o un grupo de trabajo de c&oacute;digo de conducta.
+Deber&iacute;as brindar a las personas, una manera privada (por ejemplo, mediante una direcci&oacute;n de correo electrónico) de reportar una violaci&oacute;n al c&oacute;digo de conducta y explicar qui&eacute;n recibe dicho reporte. Puede ser un responsable de mantenimiento, un grupo de tales responsables, o un grupo de trabajo de c&oacute;digo de conducta.
 
 Recuerda que alguien puede que desee reportar una violaci&oacute;n acerca de la persona que recibe dichos reportes. En tal caso, br&iacute;ndales la posibilidad de que dichos reportes, sean revisados por alguien m&aacute;s. Por ejemplo, @ctb y @mr-c [explican en su proyecto](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
-> Instancias de abuso, acoso o similares comportamientos inaceptables pueden ser reportados mandando un email a **khmer-project@idyll.org** el cual solamente se dirigir&aacute; a C. Titus Brown and Michael R. Crusoe. Para reportar una cuesti&oacute;n que involucra a ambos, por favor env&iacute;a un email a **Judi Brown Clarke, Ph.D.** el Director de Diversidad en el BEACON Center for the Study of Evolution in Action, un centro de la Fundaci&oacute;n de Ciencia Nacional para la Ciencia y Tecnologia.*
+> Instancias de abuso, acoso o similares comportamientos inaceptables pueden ser reportados mandando un correo electrónico a **khmer-project@idyll.org** el cual solamente se dirigir&aacute; a C. Titus Brown y Michael R. Crusoe. Para reportar una cuesti&oacute;n que involucra a ambos, por favor env&iacute;a un correo electrónico a **Judi Brown Clarke, Ph.D.** el Director de Diversidad en el BEACON Center for the Study of Evolution in Action, un centro de la Fundaci&oacute;n de Ciencia Nacional para la Ciencia y Tecnologia.*
 
 Para inspirarte, mira el [manual de ejecuci&oacute;n de Django](https://www.djangoproject.com/conduct/enforcement-manual/)  (aunque quiz&aacute;s no necesites algo tan amplio, dependiendo del tama&ntilde;o de tu proyecto).
 
 ## Aplicando tu c&oacute;digo de conducta
 
-En ocasiones, a pesar de tus mayores esfuerzos, alguien har&aacute; algo que violara este c&oacute;digo. Existen diferentes maneras de abordar el comportamiento negativo o da&ntilde;ino en la pr&aacute;ctica.
+En ocasiones, a pesar de tus mayores esfuerzos, alguien har&aacute; algo que violar&aacute; este c&oacute;digo. Existen diferentes maneras de abordar el comportamiento negativo o da&ntilde;ino en la pr&aacute;ctica.
 
 ### Recolectar informaci&oacute;n acerca de la situaci&oacute;n
 
 Ot&oacute;rgale la importancia a lo que cada miembro de la comunidad tiene para decir como se la dar&iacute;as a lo que t&uacute; tienes para decir. Si recibes un reporte de que alguien ha violado el c&oacute;digo de conducta, t&oacute;matelo seriamente e investiga el asunto, incluso si no condice con tu experiencia con dicha persona. De esta manera, demuestras a tu comunidad que valoras su perspectiva y conf&iacute;as en su juicio.
 
-El miembro de la comunidad puede ser un reincidente quien constantemente hace sentir incomodos a los dem&aacute;s o puede haber hecho o dicho algo por &uacute;nica vez. En ambas situaciones podemos tomar acciones, dependiendo del contexto.
+El miembro de la comunidad puede ser un reincidente quien constantemente hace sentir inc&oacute;modos a los dem&aacute;s o puede haber hecho o dicho algo por &uacute;nica vez. En ambas situaciones podemos tomar acciones, dependiendo del contexto.
 
 Antes de que respondas, t&oacute;mate tu tiempo para entender lo que sucedi&oacute;. Lee los comentarios y conversaciones pasados de la persona para entender mejor quienes son y por qu&eacute; podr&iacute;an haber actuado de tal manera. Intenta recolectar perspectivas de otros acerca de dicha persona y su comportamiento.
 
 <aside markdown="1" class="pquote">
-  No entres en discusiones. No se desv&iacute;e a tratar con el comportamiento de otra persona antes de que haya terminado de tratar con el asunto en cuesti&oacute;n. Enf&oacute;cate en lo que necesitas.
+  No entres en discusiones. No te desv&iacute;es a tratar con el comportamiento de otra persona antes de que haya terminado de tratar con el asunto en cuesti&oacute;n. Enf&oacute;cate en lo que necesitas.
   <p markdown="1" class="pquote-credit">
 — Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
   </p>
@@ -81,13 +81,13 @@ Antes de que respondas, t&oacute;mate tu tiempo para entender lo que sucedi&oacu
 
 ### Toma acciones apropiadas
 
-Luego de recolectar y procesar suficiente informaci&oacute;n, necesitaras decidirte que hacer. Mientras consideras tus siguientes pasos, recuerda que tu objetivo como moderador es fomentar un ambiente seguro, respetuoso y colaborativo. Considera no solamente como tratar la situaci&oacute;n en cuesti&oacute;n, sino tambi&eacute;n como tu respuesta afectara al comportamiento y expectativas del resto de tu comunidad.
+Luego de recolectar y procesar suficiente informaci&oacute;n, necesitaras decidirte que hacer. Mientras consideras tus siguientes pasos, recuerda que tu objetivo como moderador es fomentar un ambiente seguro, respetuoso y colaborativo. Considera no solamente como tratar la situaci&oacute;n en cuesti&oacute;n, sino tambi&eacute;n como tu respuesta afectar&aacute; al comportamiento y expectativas del resto de tu comunidad.
 
 Cuando alguien reporta una violaci&oacute;n al c&oacute;digo de conducta, es tu trabajo ocuparte de ella, y no de otra persona. A veces, quien reporta est&aacute; revelando la informaci&oacute;n con gran riesgo para su carrera, reputaci&oacute;n o integridad f&iacute;sica. Forzarlos a confrontar a su acosador puede poner en una posici&oacute;n comprometedora a quien reporta. Debes comunicarte de manera directa con la persona en cuesti&oacute;n, a menos que quien reporta expl&iacute;citamente solicite lo contrario.
 
 Existen varias maneras de responder a una violaci&oacute;n del c&oacute;digo de conducta:
 
-* **Dar a la persona en cuesti&oacute;n una advertencia p&uacute;blica** y explicarle de que manera su comportamiento ha impactado negativamente en los dem&aacute;s, preferiblemente en el canal en donde ocurri&oacute;. Siempre que sea posible, la comunicaci&oacute;n p&uacute;blica transmite a la comunidad la seriedad con la que consideras al c&oacute;digo de conducta. Se amable, pero firme, en la manera en que te comunicas.
+* **Dar a la persona en cuesti&oacute;n una advertencia p&uacute;blica** y explicarle de que manera su comportamiento ha impactado negativamente en los dem&aacute;s, preferiblemente en el canal en donde ocurri&oacute;. Siempre que sea posible, la comunicaci&oacute;n p&uacute;blica transmite a la comunidad la seriedad con la que consideras al c&oacute;digo de conducta. S&eacute; amable, pero firme, en la manera en que te comunicas.
 
 * **Acercarse de forma privada a la persona** en cuesti&oacute;n para explicarle de que manera su comportamiento impacto negativamente en los dem&aacute;s. Puedes usar un canal de comunicaci&oacute;n privado si la situaci&oacute;n involucra informaci&oacute;n personal. Si te comunicas de manera privada con alguien, es una buena idea realizar una copia carb&oacute;n a los primeros que hayan reportado la situaci&oacute;n, de esta manera sabr&aacute;n que tomaste acciones. P&iacute;dele consentimiento a quien reporta antes de enviarle una copia carb&oacute;n.
 
@@ -103,12 +103,12 @@ La expulsi&oacute;n de miembros no debe ser tomado a la ligera y representa una
 
 Un c&oacute;digo de conducta no es una ley aplicada arbitrariamente. T&uacute; eres quien aplica el c&oacute;digo de conducta y es tu responsabilidad seguir las reglas que el c&oacute;digo de conducta establece.
 
-Como encargado de mantenimiento, t&uacute; estableces las directrices de tu comunidad y las aplicas de acuerdo a las reglas establecidas en tu c&oacute;digo de conducta. Esto implica considerar seriamente a cualquier violaci&oacute;n al c&oacute;digo de conducta. Quien reporta merece una justa y total revisi&oacute;n de su reclamo. Si determinas que el comportamiento reportado no es una violaci&oacute;n, comun&iacute;cate de manera clara con ellos y expl&iacute;cales por qu&eacute; no tomaras ninguna acci&oacute;n. Lo que hacen con eso depende de ellos: tolerar el comportamiento con el cual ten&iacute;an un problema, o dejar de participar en la comunidad.
+Como encargado de mantenimiento, t&uacute; estableces las directrices de tu comunidad y las aplicas de acuerdo a las reglas establecidas en tu c&oacute;digo de conducta. Esto implica considerar seriamente a cualquier violaci&oacute;n al c&oacute;digo de conducta. Quien reporta merece una justa y total revisi&oacute;n de su reclamo. Si determinas que el comportamiento reportado no es una violaci&oacute;n, comun&iacute;cate de manera clara con ellos y expl&iacute;cales por qu&eacute; no tomar&aacute;s ninguna acci&oacute;n. Lo que hacen con eso depende de ellos: tolerar el comportamiento con el cual ten&iacute;an un problema, o dejar de participar en la comunidad.
 
-Un reporte de comportamiento que _t&eacute;cnicamente_ no viola el c&oacute;digo de conducta puede indicar que hay un problema en tu comunidad, y deber&iacute;as investigar este problema potencial y actuar acorde. Esto puede incluir revisar tu c&oacute;digo de conducta para clarificar comportamientos aceptables y/o hablar con la persona cuyo comportamiento fue reportado y explicarles que si bien no han violado el c&oacute;digo de conducta, est&aacute;n rozando el borde de lo que se espera y est&aacute;n haciendo sentir incomodos a ciertos participantes.
+Un reporte de comportamiento que _t&eacute;cnicamente_ no viola el c&oacute;digo de conducta puede indicar que hay un problema en tu comunidad, y deber&iacute;as investigar este problema potencial y actuar acorde. Esto puede incluir revisar tu c&oacute;digo de conducta para clarificar comportamientos aceptables y/o hablar con la persona cuyo comportamiento fue reportado y explicarles que si bien no han violado el c&oacute;digo de conducta, est&aacute;n rozando el borde de lo que se espera y est&aacute;n haciendo sentir inc&oacute;modos a ciertos participantes.
 
 Finalmente, como responsable de mantenimiento, t&uacute; estableces y aplicas los est&aacute;ndares de comportamiento aceptable. Tienes la habilidad para moldear los valores de la comunidad del proyecto, y los participantes cuentan con que apliques dichos valores de manera justa e imparcial.
 
 ## Promover el comportamiento que quieres ver en el mundo 🌎
 
-Cuando un proyecto parece hostil y poco acogedor, incluso cuando se trata solamente de una persona cuyo comportamiento es tolerado por los dem&aacute;s, te arriesgas a perder mucho m&aacute;s contribuidores, algunos de los cuales quiz&aacute;s no conozcas jam&aacute;s. No siempre es f&aacute;cil adoptar o aplicar un c&oacute;digo de conducta, pero fomentar un ambiente acogedor ayudara a que tu comunidad crezca.
+Cuando un proyecto parece hostil y poco acogedor, incluso cuando se trata solamente de una persona cuyo comportamiento es tolerado por los dem&aacute;s, te arriesgas a perder mucho m&aacute;s contribuidores, algunos de los cuales quiz&aacute;s no conozcas jam&aacute;s. No siempre es f&aacute;cil adoptar o aplicar un c&oacute;digo de conducta, pero fomentar un ambiente acogedor ayudar&aacute; a que tu comunidad crezca.

From a40721b5f4865d605840ab6f3585c505e73204d9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dar=C3=ADo=20Here=C3=B1=C3=BA?= <magallania@gmail.com>
Date: Sun, 24 Oct 2021 15:26:12 -0300
Subject: [PATCH 271/749] Typo fixed (paragraph 55)

- semantic issue (paragraph 57)
- typo fixed (line 67, 71, paragraph 121, 149, 157)
---
 _articles/es/finding-users.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/_articles/es/finding-users.md b/_articles/es/finding-users.md
index ceda208fa3b..3b204056e2e 100644
--- a/_articles/es/finding-users.md
+++ b/_articles/es/finding-users.md
@@ -52,9 +52,9 @@ Si todav&iacute;a  no deseas establecer estos canales para tu proyecto, promocio
 </aside>
 
 **Considera crear un sitio web para tu proyecto.** Un sitio web hace más amigable a tu proyecto y más fácil de navegar, especialmente cuando se acompaña de documentación clara y de tutoriales. También sugiere que tu proyecto está activo, lo que hará que su audiencia se sienta más confortable usándolo. Utiliza ejemplos para dar a las personas ideas de cómo usar tu proyecto.
-[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creador of Django, dijo que un sitio web fue _"por lejos lo mejor que hicimos con Django en los promeros días"_.
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creador of Django, dijo que un sitio web fue _"por lejos lo mejor que hicimos con Django en los primeros días"_.
 
-Si el proyecto está alojado en GitHub, puedes utilizar [GitHub Pages](https://pages.github.com/) para construir un sitio web facilmente.[Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), y [Middleman](https://middlemanapp.com/) son [algunos ejemplos](https://github.com/showcases/github-pages-examples) de excelentes y completos sitios web.
+Si el proyecto está alojado en GitHub, puedes utilizar [GitHub Pages](https://pages.github.com/) para construir un sitio web facilmente. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), y [Middleman](https://middlemanapp.com/) son [algunos ejemplos](https://github.com/showcases/github-pages-examples) de excelentes y completos sitios web.
 
 ![vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
 
@@ -64,11 +64,11 @@ Ahora que ya tienes un mensaje para tu proyecto, y una manera sencilla para que
 
 El alcance en l&iacute;nea es una gran manera de compartir y diseminar la palabra r&aacute;pidamente
 
-Saca ventaja de las comunidades en l&iacute;nea existentes y sus plataformas para alcanzar tu audiencia. Si tu proyecto es de codigo abierto es un proyecto de software, probablemente puedas encontrar tu audiencia en [Stack Overflow](https://stackoverflow.com/), [reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), o [Quora](https://www.quora.com/). Encuentra los canales donde pienses que las personas obtendrán los mayores beneficios o se sentir&aacute;n más entusiasmadas acerca de tu trabajo.
+Saca ventaja de las comunidades en l&iacute;nea existentes y sus plataformas para alcanzar tu audiencia. Si tu proyecto es de c&oacute;digo abierto es un proyecto de software, probablemente puedas encontrar tu audiencia en [Stack Overflow](https://stackoverflow.com/), [reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), o [Quora](https://www.quora.com/). Encuentra los canales donde pienses que las personas obtendrán los mayores beneficios o se sentir&aacute;n más entusiasmadas acerca de tu trabajo.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
-Cada programa tiene funciones muy espec&iacute;ficas, que solamente una fracci&oacute;n de los usuarios encontra &uacute;til. No env&iacute;es masivamente correo a todas las personas posibles. En su lugar, enfoca tus esfuerzos en comunidades que se beneficiar&aacute;n de conocer sobre tu trabajo.
+Cada programa tiene funciones muy espec&iacute;ficas, que solamente una fracci&oacute;n de los usuarios encontrar&aacute; &uacute;til. No env&iacute;es masivamente correo a todas las personas posibles. En su lugar, enfoca tus esfuerzos en comunidades que se beneficiar&aacute;n de conocer sobre tu trabajo.
   <p markdown="1" class="pquote-credit">
 — @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
   </p>
@@ -118,7 +118,7 @@ Busca conferencias que sean espec&iacute;ficas de tu lenguaje o ecosistema. Ante
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
-  Escribí muy amablemente a la gente de JSConf y les supliqué que me dieran un espacio donde pudiera presentarme en la JSConf EU. (...) Estaba extremadamente asustada, presentando esta cosa en la que había estado trabajando por seis meses. (...) Todo el tiempo estaba pensando ¡Oh Di&oacute;s m&iacute;o! ¿Qu&eacute; estoy haciendo aqu&iacute;?
+  Escribí muy amablemente a la gente de JSConf y les supliqué que me dieran un espacio donde pudiera presentarme en la JSConf EU. (...) Estaba extremadamente asustada, presentando esta cosa en la que había estado trabajando por seis meses. (...) Todo el tiempo estaba pensando ¡Oh Dios m&iacute;o! ¿Qu&eacute; estoy haciendo aqu&iacute;?
   <p markdown="1" class="pquote-credit">
 — @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
   </p>
@@ -146,7 +146,7 @@ No hay una soluci&oacute;n para construir una audiencia en una noche. Ganarse la
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS fue lanzado por primera vez a comienzos del 2011. (...)  Yo pas&eacute; la voz utilizando maneras convencionales: envi&eacute; posts en Tweeter sobre el mismo, escrib&iacute; posts en blogs sobre cosas que pod&iacute;an hacerse con &eacute;l, lo nombr&eacute; durante varias discuciones en encuentros. Cuando se hizo más conocido en el 2014, comenc&eacute; a hacer presentaciones sobre &eacute;l.
+  PhantomJS fue lanzado por primera vez a comienzos del 2011. (...)  Yo pas&eacute; la voz utilizando maneras convencionales: envi&eacute; posts en Tweeter sobre el mismo, escrib&iacute; posts en blogs sobre cosas que pod&iacute;an hacerse con &eacute;l, lo nombr&eacute; durante varias discusiones en encuentros. Cuando se hizo más conocido en el 2014, comenc&eacute; a hacer presentaciones sobre &eacute;l.
   <p markdown="1" class="pquote-credit">
 — @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
   </p>
@@ -154,4 +154,4 @@ No hay una soluci&oacute;n para construir una audiencia en una noche. Ganarse la
 
 ## S&iacute;guelo!
 
-Algunas veces, lleva mucho tiempo antes de que la gente note tu proyecto de c&oacute;digo abierto. ¡Está bien! Algunos de los proyectos más populares de hoy en día, tardaron años en alcanzar altos niveles de actividad. Enfócate en construir relaciones en lugar de una bala mágica. S&eacute; paciente, y continua compartiendo tu trabajo con aquellos que lo aprecian.
+Algunas veces, lleva mucho tiempo antes de que la gente note tu proyecto de c&oacute;digo abierto. ¡Está bien! Algunos de los proyectos más populares de hoy en día, tardaron años en alcanzar altos niveles de actividad. Enfócate en construir relaciones en lugar de una bala mágica. S&eacute; paciente, y contin&uacute;a compartiendo tu trabajo con aquellos que lo aprecian.

From de7841d55ace8f4824480ce6474299aab8aaa0b3 Mon Sep 17 00:00:00 2001
From: Wang Qilin <qilin.wang@huawei.com>
Date: Mon, 25 Oct 2021 08:51:12 +0800
Subject: [PATCH 272/749] fix chinese translation typo

fix chinese translation typo
---
 _articles/zh-hans/leadership-and-governance.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/leadership-and-governance.md b/_articles/zh-hans/leadership-and-governance.md
index d2a92ca1d74..a27615e9bd8 100644
--- a/_articles/zh-hans/leadership-and-governance.md
+++ b/_articles/zh-hans/leadership-and-governance.md
@@ -102,7 +102,7 @@ redirect_from: /zh-cn/leadership-and-governance/
 
 * **精英制:** **(注: 术语 "精英制" 对于一些社群可能具有消极的含义，其拥有较[复杂的社会和政治的历史](http://geekfeminism.wikia.com/wiki/Meritocracy).)** 在精英制下，活跃的项目贡献者（他们用行动证明自己是"精英"）给一个正式的决策作用，决定通常会基于纯粹的投票一致性。精英制的概念首次由[Apache Foundation](https://www.apache.org/)提出；[所有的Apache 项目](https://www.apache.org/index.html#projects-list) 都是基于精英制的。贡献者只能代表自己是独立的个体，不可以是公司。
 
-* **自由贡献:** 在自由贡献的模式下，做最多工作的人通常被认为是最具影响力的，但是是基于当前的工作，而不是历史的共享。项目的重大决策是基于寻求共识的过程（对不同的声音要讨论）而不是纯粹的投票，尽可能的努力的去囊括多的社区观点。较流行的使用自由贡献模式的项目有[Node.js](https://foundation.nodejs.org/) 和 [Rust](https://www.rust-lang.org/)。
+* **自由贡献:** 在自由贡献的模式下，做最多工作的人通常被认为是最具影响力的，但是是基于当前的工作，而不是历史的贡献。项目的重大决策是基于寻求共识的过程（对不同的声音要讨论）而不是纯粹的投票，尽可能的努力的去囊括多的社区观点。较流行的使用自由贡献模式的项目有[Node.js](https://foundation.nodejs.org/) 和 [Rust](https://www.rust-lang.org/)。
 
 应该选择哪一种模式了呢？由你自己来做决定！每个模式都有优点，也有缺点。虽然上面的描述乍一看，这三种模式有着很大的不同，其实不然，它们还是有着共同点的。如果你对上述三种模式有兴趣，可以采用下面的模版：
 

From dae26c226fc2868e2e50822ea50544c43e4abb9b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dar=C3=ADo=20Here=C3=B1=C3=BA?= <magallania@gmail.com>
Date: Sun, 24 Oct 2021 21:54:47 -0300
Subject: [PATCH 273/749] Typos fixed (lines 29, 61, 65, 67, 98; paragraph 77)

- translated paragraph 104
- typos fixed (line 105, 150; paragraph 170)
---
 _articles/es/getting-paid.md | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/_articles/es/getting-paid.md b/_articles/es/getting-paid.md
index 178d52ae81f..deb595bded9 100644
--- a/_articles/es/getting-paid.md
+++ b/_articles/es/getting-paid.md
@@ -25,7 +25,7 @@ Estaba buscando un proyecto de programaci&oacute;n para tenerlo como "hobby" y q
 Hay muchas razones por las cuales a una persona no le gustar&iacute;a que le pagaran por su trabajo en c&oacute;digo abierto.
 
 * **Ellos pueden llegar a tener ya un trabajo de tiempo completo que disfruten**, que los habilite a contribuir al c&oacute;digo abierto en su tiempo libre.
-* **Les gusta contribuir a los proyectos de c&oacute;digo abierto como un hobby** o escape creativo y no quieren sentise financieramente obligados a trabajar.
+* **Les gusta contribuir a los proyectos de c&oacute;digo abierto como un hobby** o escape creativo y no quieren sentirse financieramente obligados a trabajar.
 * **Reciben otros beneficios al contribuir al c&oacute;digo abierto,** como construir su portfolio de reputaci&oacute;n, obtener nuevas habilidades, o sentirse cercanos a una comunidad.
 
 <aside markdown="1" class="pquote">
@@ -58,13 +58,13 @@ El trabajo pagado tambi&eacute;n habilita a todo tipo de personas a aportar sign
   </p>
 </aside>
 
-Si tu estas buscando apoyo financiero, hay dos posibles caminos a seguir: puedes pagar por tu propio tiempo como contribuyente, o puedes encontrar organizaciones que aporten a tu proyecto.
+Si tu est&aacute;s buscando apoyo financiero, hay dos posibles caminos a seguir: puedes pagar por tu propio tiempo como contribuyente, o puedes encontrar organizaciones que aporten a tu proyecto.
 
 ## Financiando tu propio tiempo
 
-Hoy en d&iacute;a, muchas personas reciben pagos por trabajos a tiempo parcial o tiempo completo  en c&oacute;digo abierto. El modo mas com&uacute;n de recibir una paga por tu tiempo es hablar con tu empleador.
+Hoy en d&iacute;a, muchas personas reciben pagos por trabajos a tiempo parcial o tiempo completo en c&oacute;digo abierto. El modo m&aacute;s com&uacute;n de recibir una paga por tu tiempo es hablar con tu empleador.
 
-Es mas f&aacute;cil establecer un trabajo en c&oacute;digo abierto si tu empleador usa el proyecto, pero ponte creativo. Puede que tu empleador no use el proyecto, pero usa Python, y mantener un proyecto popular de Python puede atraer nuevos desarrolladores de Python. Tambi&eacute;n puede que haga que tu empleador se vea m&aacute;s desarrollador-amigable en general.
+Es m&aacute;s f&aacute;cil establecer un trabajo en c&oacute;digo abierto si tu empleador usa el proyecto, pero ponte creativo. Puede que tu empleador no use el proyecto, pero usa Python, y mantener un proyecto popular de Python puede atraer nuevos desarrolladores de Python. Tambi&eacute;n puede que haga que tu empleador se vea m&aacute;s desarrollador-amigable en general.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
@@ -74,7 +74,7 @@ Es mas f&aacute;cil establecer un trabajo en c&oacute;digo abierto si tu emplead
   </p>
 </aside>
 
-Si tu no tienes un excitante proyecto de c&oacute;digo abierto en el que quisieras trabajar, pero te gustar&iacute;a que tu actual trabajo genere aportes al c&oacute;digo abierto, establece un acuerdo con tu empleador para aportar algo del software interno de la organizacion a la comunidad de c&oacute;digo abierto.
+Si tu no tienes un excitante proyecto de c&oacute;digo abierto en el que quisieras trabajar, pero te gustar&iacute;a que tu actual trabajo genere aportes al c&oacute;digo abierto, establece un acuerdo con tu empleador para aportar algo del software interno de la organizaci&oacute;n a la comunidad de c&oacute;digo abierto.
 
 Muchas empresas est&aacute;n desarrollando programas de c&oacute;digo abierto para construir su marca y reclutar talentos de calidad.
 
@@ -95,14 +95,14 @@ Si tu empresa va por esta ruta, es importante mantener clara la relaci&oacute;n
 Si no pueden convencer a tu actual empleador de priorizar un trabajo de c&oacute;digo abierto, considera encontrar un nuevo empleador que motive a los empleados a contribuir. Busca empresas que hagan su dedicaci&oacute;n al c&oacute;digo abierto expl&iacute;cita. Por ejemplo:
 
 * Algunas empresas, como [Netflix](https://netflix.github.io/) o [PayPal](https://paypal.github.io/), tienen p&aacute;ginas web que resaltan su participaci&oacute;n en el c&oacute;digo abierto.
-* [Zalando](https://opensource.zalando.com) publico su [pol&iacute;ticas de contribuci&oacute;n al c&oacute;digo abierto](https://opensource.zalando.com/docs/using/contributing/) para empleados.
+* [Zalando](https://opensource.zalando.com) public&oacute; su [pol&iacute;ticas de contribuci&oacute;n al c&oacute;digo abierto](https://opensource.zalando.com/docs/using/contributing/) para empleados.
 
 Proyectos que se originaron en una empresa grande, como [Go](https://github.com/golang) o [React](https://github.com/facebook/react), ser&aacute;n susceptibles a contratar personas que trabajen en c&oacute;digo abierto.
 
 Finalmente, dependiendo de tus circunstancias personales, puedes probar generar dinero de forma independiente para financiar tu trabajo de c&oacute;digo abierto. Por ejemplo:
 
-* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
-* @gaearon financio su propio trabajo [Redux](https://github.com/reactjs/redux) a trav&eacute;s de [Patreon crowdfunding campaign](https://redux.js.org/)
+* @Homebrew (y [varios mantenedores y organizaciones](https://github.com/sponsors/community)) financian su trabajo a través de [GitHub Sponsors](https://github.com/sponsors)
+* @gaearon financi&oacute; su propio trabajo [Redux](https://github.com/reactjs/redux) a trav&eacute;s de [Patreon crowdfunding campaign](https://redux.js.org/)
 * @andrewgodwin financi&oacute; su trabajo de migraci&oacute;n de esquemas de Django [a trav&eacute;s de una campa&ntilde;a kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
 ## Encontrando financiaci&oacute;n para tu proyecto.
@@ -147,7 +147,7 @@ Por m&aacute;s opciones y casos de estudio, @nayafia [escribi&oacute; una gu&iac
 
 Sin importar si tu proyecto es una nueva idea, o estuvo dando vueltas por a&ntilde;os, deber&iacute;as preveer que tendr&aacute;s que ponerle mucho esfuerzo en identificar a tu financiador objetivo y construir un caso acorde.
 
-Sin importar si estas buscando pagar por tu propio tiempo, o invertir/generar en un proyecto, deber&iacute;as poder responderte las siguientes preguntas:
+Sin importar si est&aacute;s buscando pagar por tu propio tiempo, o invertir/generar en un proyecto, deber&iacute;as poder responderte las siguientes preguntas:
 
 ### Impacto
 
@@ -167,7 +167,7 @@ Los financiadores, sin importar si tu empleador o tu fundaci&oacute;n generadora
 
 ### Como recibir&aacute;s la financiaci&oacute;n.
 
-¿El financiador tiene algun requisito de como recibir&aacute;s el dinero? Por ejemplo, puede que necesites ser un sponsor o tener un sponsor fiscal sin fines de lucro. O tal vez la financiaci&oacute;n debe ser entraga a un contratador individual en vez de a una organizaci&oacute;n. Estos requisitos var&iacute;an entre los financiadores, as&iacute; que asegurate de hacer averiguaciones de antemano.
+¿El financiador tiene algun requisito de como recibir&aacute;s el dinero? Por ejemplo, puede que necesites ser un sponsor o tener un sponsor fiscal sin fines de lucro. O tal vez la financiaci&oacute;n debe ser entregada a un contratador individual en vez de a una organizaci&oacute;n. Estos requisitos var&iacute;an entre los financiadores, as&iacute; que asegurate de hacer averiguaciones de antemano.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">

From ef72e3bc644993cfa739b63600c6eabd62308563 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dar=C3=ADo=20Here=C3=B1=C3=BA?= <magallania@gmail.com>
Date: Mon, 25 Oct 2021 22:30:22 -0300
Subject: [PATCH 274/749] Syntax issues (paragraphs 29, 170)

- typo fixed (paragraph 49, 73, 102, 181, 206, 406, 414, 418, 498)
- semantic issue (line 171)
- minor proposal on translation (paragraph 472)
---
 _articles/es/how-to-contribute.md | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/_articles/es/how-to-contribute.md b/_articles/es/how-to-contribute.md
index 92945d333d2..4df58790356 100644
--- a/_articles/es/how-to-contribute.md
+++ b/_articles/es/how-to-contribute.md
@@ -26,7 +26,7 @@ Contribuir en proyectos de c&oacute;digo abierto puede ser una provechosa manera
 
 ### Mejora tus habilidades existentes
 
-Ya sea codificaci&oacute;n, diseño interfaces de usuario, dise&ntilde;o gr&aacute;fico, redacci&oacute;n u organizaci&oacute;n, si lo que est&aacute;s buscando es pr&aacute;ctica, hay una tarea esper&aacute;ndote en un proyecto de c&oacute;digo abierto.
+Ya sea codificaci&oacute;n, diseño de interfaces de usuario, dise&ntilde;o gr&aacute;fico, redacci&oacute;n u organizaci&oacute;n, si lo que est&aacute;s buscando es pr&aacute;ctica, hay una tarea esper&aacute;ndote en un proyecto de c&oacute;digo abierto.
 
 ### Conoce personas que están interesadas en temas similares
 
@@ -46,7 +46,7 @@ El c&oacute;digo abierto ofrece oportunidades para practicar habilidades de lide
 
 ### Es poderoso ser capaz de hacer cambios, incluso pequeños
 
-No necesitas convertirte en un colaborador de toda la vida para disfrutar la participaci&oacute;n con el c&oacute;digo abierto. ¿Alguna vez viste un error de tipograf&iacute;a, y deseaste que &aacute;lguien pudiera corregirlo? En un proyecto de c&oacute;digo abierto, es justamente lo que puedes hacer. El c&oacute;digo abierto ayuda a las personas a sentir acci&oacute;n en sus vidas, en la forma en que experimentan al mundo y eso en si mismo es gratificante.
+No necesitas convertirte en un colaborador de toda la vida para disfrutar la participaci&oacute;n con el c&oacute;digo abierto. ¿Alguna vez viste un error de tipograf&iacute;a, y deseaste que alguien pudiera corregirlo? En un proyecto de c&oacute;digo abierto, es justamente lo que puedes hacer. El c&oacute;digo abierto ayuda a las personas a sentir acci&oacute;n en sus vidas, en la forma en que experimentan al mundo y eso en si mismo es gratificante.
 
 ## Qu&eacute; significa contribuir
 
@@ -70,7 +70,7 @@ Incluso si te gusta codificar, otro tipo de contribuciones son una gran manera d
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  Llegu&eacute; por primera vez al equipo de desarrollo de Python (alias python-dev) cuando envi&eacute; un correo electr&oacute;nico a su lista de correos el 17 de junio de 2002, aceptando mi parche. R&aacute;pidamente me encontr&eacute; con un error de c&oacute;digo abierto, y decid&iacute; comenzar a limpiar el resumen de correos electr&oacute;nicos para el grupo. Me dieron una gran excusa para pedir aclaraciones sobre un tema, pero principalmente pude notar cu&aacute;ndo &aacute;lguien señalaba algo que necesitaba ser reparado.
+  Llegu&eacute; por primera vez al equipo de desarrollo de Python (alias python-dev) cuando envi&eacute; un correo electr&oacute;nico a su lista de correos el 17 de junio de 2002, aceptando mi parche. R&aacute;pidamente me encontr&eacute; con un error de c&oacute;digo abierto, y decid&iacute; comenzar a limpiar el resumen de correos electr&oacute;nicos para el grupo. Me dieron una gran excusa para pedir aclaraciones sobre un tema, pero principalmente pude notar cu&aacute;ndo alguien señalaba algo que necesitaba ser reparado.
   <p markdown="1" class="pquote-credit">
 — @brettcannon, ["Hostorias de un encargado"](https://github.com/open-source/stories/brettcannon)
   </p>
@@ -99,7 +99,7 @@ Incluso si te gusta codificar, otro tipo de contribuciones son una gran manera d
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
-  De verdad, \[documentation\] es s&uacute;per-importante. Por lejos la documentaci&oacute;n ha sido enorme y fue el factor que termin&oacute; con la torre de Babel. Hay secciones que ciertamente podr&iacute;an mejorar con algo de trabajo e incluso la adici&oacute;n de un p&aacute;rrafo aqu&iacute; o all&aacute; es extremadamente apreciada.
+  De verdad, \[documentation\] es super-importante. Por lejos la documentaci&oacute;n ha sido enorme y fue el factor que termin&oacute; con la torre de Babel. Hay secciones que ciertamente podr&iacute;an mejorar con algo de trabajo e incluso la adici&oacute;n de un p&aacute;rrafo aqu&iacute; o all&aacute; es extremadamente apreciada.
   <p markdown="1" class="pquote-credit">
 — @kittens, ["Llamado a los colaboradores"](https://github.com/babel/babel/issues/1347)
   </p>
@@ -167,8 +167,8 @@ Dicho esto, muchos proyectos de c&oacute;digo abierto siguen una estructura orga
 Un proyecto de c&oacute;digo abierto tiene los siguientes tipos de personas:
 
 * **Autor:** La/s persona/s u organizaci&oacute;n que cre&oacute;/crearon el proyecto.
-* **Dueño:** La/s persona/s que tiene/n la propiedad administrativa sobre la organizaci&oacute;n o el repositorio(no siempre es la misma que el autor original)
-* **Encargados:** Colaboradores que son responsables de dirigir la visi&oacute;n y la administrar aspectos organizacionales del proyecto. (Pueden tambi&eacute;n ser autores o dueños del proyecto.)
+* **Dueño:** La/s persona/s que tiene/n la propiedad administrativa sobre la organizaci&oacute;n o el repositorio (no siempre es la misma que el autor original)
+* **Encargados:** Colaboradores que son responsables de dirigir la visi&oacute;n y de administrar aspectos organizacionales del proyecto. (Pueden tambi&eacute;n ser autores o dueños del proyecto.)
 * **Colaboradores:** Cualquiera que haya contribuido con algo al proyecto.
 * **Miembros de la comunidad:** Las personas que utilizan al proyecto. Pueden tener un rol activo en las conversaciones o expresar su opini&oacute;n sobre la direcci&oacute;n que toma el proyecto.
 
@@ -178,7 +178,7 @@ Un proyecto tambi&eacute;n tiene documentaci&oacute;n. Estos archivos est&aacute
 
 * **LICENSE:** Por definici&oacute;n, cada proyecto de c&oacute;digo abierto debe tener una [licencia open source](https://choosealicense.com). Si el proyecto no tiene una licencia, entonces no es de c&oacute;digo abierto.
 * **README:** El archivo README es un manual de instrucci&oacute;n que da la bienvenida al proyecto a los nuevos miembros de la comunidad. Explica por qu&eacute; el proyecto es &uacute;til y c&oacute;mo comenzar.
-* **CONTRIBUTING:** Mientras que el archivo READMES ayuda a las personas a _usar_ el proyecto, el archivo CONTRIBUTING ayuda a las personas a _contribuir_ con el proyecto. Explica qu&eacute; tipo de contribuciones son necesarias y c&oacute;mo llevar adelante el trabajo. Si bien no todos los proyectos tienen un archivo CONTRIBUTING, su presencia señala que se trata de un buen proyecto para contribuir.
+* **CONTRIBUTING:** Mientras que el archivo README ayuda a las personas a _usar_ el proyecto, el archivo CONTRIBUTING ayuda a las personas a _contribuir_ con el proyecto. Explica qu&eacute; tipo de contribuciones son necesarias y c&oacute;mo llevar adelante el trabajo. Si bien no todos los proyectos tienen un archivo CONTRIBUTING, su presencia señala que se trata de un buen proyecto para contribuir.
 * **CODE_OF_CONDUCT:** Sienta s&oacute;lidas reglas sobre la conducta de los participantes asociados y ayuda a facilitar un entorno acogedor y amistoso. Si bien no todos los proyectos tienen un archivo CODE_OF_CONDUCT, su presencia señala que se trata de un buen proyecto para contribuir.
 * **Otra documentaci&oacute;n:** Puede haber documentaci&oacute;n adicional, como tutoriales, recorridos o pol&iacute;ticas de gobierno, especialmente en proyectos de mayor envergadura.
 
@@ -203,7 +203,7 @@ En esos proyectos, cuando te encuentres pensando que algo podr&iacute;a hacerse
 
 El c&oacute;digo abierto no es un club exclusivo; est&aacute; hecho de personas igual a t&iacute;. El t&eacute;rmino de fantas&iacute;a  "C&oacute;digo abierto" es solo un nombre para tratar a los problemas del mundo como resolubles.
 
-Puedes recorrer un archivo README y encontrar un v&iacute;nculo roto o un error tipogr&aacute;fico. O tal vez eres un nuevo usuario y te diste cuenta de que algo est&aacute; roto, o hay un problema que crees que realmente deber&iacute;a estar en la documentaci&oacute;n. En lugar de ignorarlo y continuar, o solicitar que &aacute;lguien lo solucione, observa si puedes ayudar lanz&aacute;ndote sobre &eacute;l. ¡De eso se trata el c&oacute;digo abierto!
+Puedes recorrer un archivo README y encontrar un v&iacute;nculo roto o un error tipogr&aacute;fico. O tal vez eres un nuevo usuario y te diste cuenta de que algo est&aacute; roto, o hay un problema que crees que realmente deber&iacute;a estar en la documentaci&oacute;n. En lugar de ignorarlo y continuar, o solicitar que alguien lo solucione, observa si puedes ayudar lanz&aacute;ndote sobre &eacute;l. ¡De eso se trata el c&oacute;digo abierto!
 
 > [El 28% de las contribuciones casuales](https://www.igor.pro.br/publica/papers/saner2016.pdf) a la documentaci&oacute;n del c&oacute;digo abierto se trata de documentaci&oacute;n, como correcciones tipogr&aacute;ficas, reformateos o redacci&oacute;n de una traducci&oacute;n.
 
@@ -403,7 +403,7 @@ Antes de abrir un problema o un pull request, o de hacer una pregunta en un chat
 >
 > 😢 _"¿C&oacute;mo soluciono X?"_
 
-**Mant&eacute;n tus solicitudes cortas y directas.** Al igual que el env&iacute;o de un correo, cualquier contribuci&oacute;n, sin importar lo simple o &uacute;til que sea, requiere la revisi&oacute;n de parte de otra persona. Muchos proyectos tienen m&aacute;s solicitudes de entrada que personas disponibles para ayudar. Se conciso. Aumentar&aacute;s las probabilidades de que &aacute;lguien pueda ayudarte.
+**Mant&eacute;n tus solicitudes cortas y directas.** Al igual que el env&iacute;o de un correo, cualquier contribuci&oacute;n, sin importar lo simple o &uacute;til que sea, requiere la revisi&oacute;n de parte de otra persona. Muchos proyectos tienen m&aacute;s solicitudes de entrada que personas disponibles para ayudar. S&eacute; conciso. Aumentar&aacute;s las probabilidades de que alguien pueda ayudarte.
 
 > 😇 _"Me gustar&iacute;a escribir un tutorial para una API."_
 >
@@ -411,11 +411,11 @@ Antes de abrir un problema o un pull request, o de hacer una pregunta en un chat
 
 **Mant&eacute;n todas las comunicaciones p&uacute;blicas.** Pese a que es tentador, no te dirijas a los responsables de manera privada a menos que necesites compartir informaci&oacute;n sensible (como un problema de seguridad o violaciones a la conducta serias). Cuando mantienes las conversaciones p&uacute;blicas, m&aacute;s personas pueden aprender y verse beneficiadas de tu intercambio. La discusi&oacute;n puede ser, en s&iacute; misma, una contribuci&oacute;n.
 
-> 😇 _(como un comentario) "@-responsable ¡Qu&eacute; tal! ¿C&oacute;mo deber&iacute;amos proceder con &eacute;ste PR?"_
+> 😇 _(como un comentario) "@-responsable ¡Qu&eacute; tal! ¿C&oacute;mo deber&iacute;amos proceder con este PR?"_
 >
 > 😢 _(como un correo electr&oacute;nico) "Que tal, disculpa que te moleste con un correo electr&oacute;nico, pero me estaba preguntando si tendr&aacute;s la oportunidad de revisar mi PR"_
 
-**Est&aacute; bien hacer preguntas (¡pero se paciente!).** Todos fueron nuevos en el proyecto en alg&uacute;n momento, e incluso los colaboradores experimentados necesitan ponerse al d&iacute;a cuando miran un nuevo proyecto. Por lo mismo, incluso responsables de mucha antig&uuml;edad no est&aacute;n siempre familiarizados con todas las partes del proyecto. Mu&eacute;strales la misma paciencia que quieres que ellos tengan contigo.
+**Est&aacute; bien hacer preguntas (¡pero s&eacute; paciente!).** Todos fueron nuevos en el proyecto en alg&uacute;n momento, e incluso los colaboradores experimentados necesitan ponerse al d&iacute;a cuando miran un nuevo proyecto. Por lo mismo, incluso responsables de mucha antig&uuml;edad no est&aacute;n siempre familiarizados con todas las partes del proyecto. Mu&eacute;strales la misma paciencia que quieres que ellos tengan contigo.
 
 > 😇 _"Gracias por estudiar &eacute;ste error. Segu&iacute; tus sugerencias. Esta es la salida."_
 >
@@ -469,7 +469,7 @@ Consejos para comunicar los problemas:
 
 Usualmente deber&iacute;as abrir un pull request en las siguientes situaciones:
 
-* Enviar arreglos triviales (por ejemplo una correcci&oacute;n tipogr&aacute;fica, un link ca&iacute;do o un error obvio).
+* Enviar arreglos triviales (por ejemplo una correcci&oacute;n tipogr&aacute;fica, un enlace ca&iacute;do o un error obvio).
 * Comenzar a trabajar en una contribuci&oacute;n que ya fue solicitada, o que ya discutiste en un problema.
 
 Un pull request no representa trabajo terminado. Usualmente es mejor abrir un pull request de forma temprana, de manera que otros puedan observar o dar retroalimentaci&oacute;n a tu progreso. Solo m&aacute;rcalo como "trabajo en proceso" (WIP por sus siglas en ingl&eacute;s, work in progress) en la l&iacute;nea del tema. Siempre puedes agregar m&aacute;s commits despu&eacute;s.
@@ -495,7 +495,7 @@ Luego de que enviaste tu contribuci&oacute;n, una de las siguientes situaciones
 
 Ojal&aacute; que  [hayas verificado el proyecto buscando signos de actividad](#una-lista-de-verificación-antes-de-que-contribuyas) antes de hacer cualquier contribuci&oacute;n. Incluso en proyectos activos, de cualquier manera, es posible que tu contribuci&oacute;n no tenga una respuesta.
 
-Si no tuviste una respuesta en m&aacute;s de una semana, es justo responder en el mismo hilo, preguntando a &aacute;lguien por una revisi&oacute;n. Si conoces el nombre de la persona correcta para que revise tu contribuci&oacute;n, puedes hacer una @-menci&oacute;n en ese hilo.
+Si no tuviste una respuesta en m&aacute;s de una semana, es justo responder en el mismo hilo, preguntando a alguien por una revisi&oacute;n. Si conoces el nombre de la persona correcta para que revise tu contribuci&oacute;n, puedes hacer una @-menci&oacute;n en ese hilo.
 
 **No contactes a esa persona** de manera privada; recuerda que las comunicaciones p&uacute;blicas son vitales para los proyectos de c&oacute;digo abierto.
 

From 34725b57ba0c723501e8630f9917ec954dee4fbe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dar=C3=ADo=20Here=C3=B1=C3=BA?= <magallania@gmail.com>
Date: Tue, 26 Oct 2021 13:26:00 -0300
Subject: [PATCH 275/749] Typo fixed (paragraph 15, 21, 27, 31, 59, 78)

- semantic & syntax proposals (paragraph 100)
- syntax issue (paragraph 132)
---
 _articles/es/leadership-and-governance.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/_articles/es/leadership-and-governance.md b/_articles/es/leadership-and-governance.md
index 851bdb87850..db7c75c3eb0 100644
--- a/_articles/es/leadership-and-governance.md
+++ b/_articles/es/leadership-and-governance.md
@@ -12,23 +12,23 @@ related:
 
 ## Entendiendo el gobierno de su proyecto en crecimiento
 
-Tu proyecto est&aacute; creciendo, la gente est&aacute; comprometida, y estas comprometido a mantener esto en marcha. En esta etapa, es posible que te preguntes c&oacute;mo incorporar a los contribuyentes regulares de proyectos en su flujo de trabajo, ya sea para darle a alguien el compromiso de acceso o para resolver los debates de la comunidad. Si tiene preguntas, tenemos respuestas.
+Tu proyecto est&aacute; creciendo, la gente est&aacute; comprometida, y est&aacute;s comprometido a mantener esto en marcha. En esta etapa, es posible que te preguntes c&oacute;mo incorporar a los contribuyentes regulares de proyectos en su flujo de trabajo, ya sea para darle a alguien el compromiso de acceso o para resolver los debates de la comunidad. Si tiene preguntas, tenemos respuestas.
 
 ## &iquest;Cu&aacute;les son ejemplos de roles formales utilizados en proyectos de c&oacute;digo abierto?
 
 Muchos proyectos siguen estructuras similares para reconocer y asignar roles a los contribuyentes.
 
-El significado de estos roles queda a tu criterio. Aqu&iacute; puedes encontrar algunos tipos de rol que quiz&iacute;s reconozcas:
+El significado de estos roles queda a tu criterio. Aqu&iacute; puedes encontrar algunos tipos de rol que quiz&aacute;s reconozcas:
 
 * **Mantenedor**
 * **Contribuyente**
 * **Committer**
 
-**Para algunos proyectos, los "mantenedores"** son las únicas personas en el proyecto con permisos de commit. En otros proyectos, son simplemente personas que estan listadas en el archivo README.md como mantenedores.
+**Para algunos proyectos, los "mantenedores"** son las únicas personas en el proyecto con permisos de commit. En otros proyectos, son simplemente personas que est&aacute;n listadas en el archivo README.md como mantenedores.
 
 Un mantenedor no necesariamente tiene que ser alguien que escribe c&oacute;digo para su proyecto. Podr&iacute;a ser alguien que ha hecho mucho trabajo evangelizando su proyecto, o documentaci&oacute;n escrita que hizo el proyecto m&aacute;s accesible a los dem&aacute;s. Independientemente de lo que hacen d&iacute;a a d&iacute;a, un mantenedor es probablemente alguien que se siente responsable sobre la direcci&oacute;n del proyecto y se ha comprometido a mejorarlo.
 
-**Un "contribuyente" puede ser cualquiera** que comente en una issue o un pull request, personas que agreguen valor al proyecto (sin importar si sólo está clasificando issues, escribiendo c&oacute;digo u organizando eventos), o cualquiera con un merged pull request (esta es la definici&oacute;n mas estrecha de un contribuyente).
+**Un "contribuyente" puede ser cualquiera** que comente en una issue o un pull request, personas que agreguen valor al proyecto (sin importar si sólo está clasificando issues, escribiendo c&oacute;digo u organizando eventos), o cualquiera con un merged pull request (esta es la definici&oacute;n m&aacute;s estrecha de un contribuyente).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -56,7 +56,7 @@ La formalizaci&oacute;n de tus funciones de liderazgo ayuda a las personas a sen
 
 Para un proyecto m&aacute;s peque&ntilde;o, designar l&iacute;deres puede ser tan simple como agregar sus nombres a su archivo de texto README o CONTRIBUTORS.
 
-Por un proyecto mas grande, si tienes una pagina web, crea una p&aacute;gina de equipo o lista tus l&iacute;deres de proyecto all&iacute;. Por ejemplo, [PostgreSQL](https://github.com/postgres/postgres/) tiene una [p&aacute;gina exhaustiva de equipo](https://www.postgresql.org/community/contributors/) con perfiles cortos para cada contribuyente.
+Por un proyecto m&aacute;s grande, si tienes una p&aacute;gina web, crea una p&aacute;gina de equipo o lista tus l&iacute;deres de proyecto all&iacute;. Por ejemplo, [PostgreSQL](https://github.com/postgres/postgres/) tiene una [p&aacute;gina exhaustiva de equipo](https://www.postgresql.org/community/contributors/) con perfiles cortos para cada contribuyente.
 
 Si tu proyecto tiene una comunidad de contribuidores muy activa, puede formar un "equipo central" de mantenedores, o incluso subcomisiones de personas que se apropian de diferentes &aacute;reas tem&aacute;ticas (por ejemplo, seguridad, clasificaci&oacute;n de temas o conducta comunitaria). Permite que la gente se auto-organice y se ofrezca como voluntaria para los papeles que m&aacute;s le entusiasman, en lugar de asignarlos.
 
@@ -75,7 +75,7 @@ Herramientas como [Vossibility](https://github.com/icecrime/vossibility-stack) p
 
 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).
 
-## &iquest;Cuando le puedo dar acceso a hacer commits a alguien?
+## &iquest;Cu&aacute;ndo le puedo dar acceso a hacer commits a alguien?
 
 Algunas personas piensan que debe dar acceso de commits a todos los que hacen una contribuci&oacute;n. Hacerlo podr&iacute;a alentar a m&aacute;s personas a sentirse due&ntilde;as de su proyecto.
 
@@ -97,7 +97,7 @@ Hay tres estructuras de gobierno comunes asociadas a los proyectos de c&oacute;d
 
 * **BDFL:** BDFL significa "Benevolent Dictator for Life" (en espa&ntilde;ol, "Dictador benevolente para la vida"). Bajo esta estructura, una persona (generalmente el autor inicial del proyecto) tiene la palabra final en todas las decisiones importantes del proyecto. [Python](https://github.com/python) es un ejemplo cl&aacute;sico. Los proyectos m&aacute;s peque&ntilde;os son probablemente BDFL por defecto, porque s&oacute;lo hay uno o dos mantenedores. Un proyecto que se origin&oacute; en una empresa tambi&eacute;n podr&iacute;a caer en la categor&iacute;a BDFL.
 
-* **Meritocracia:** **(Nota: el t&eacute;rmino "meritocracia" tiene connotaciones negativas para algunas comunidades y tiene un [historia social y pol&iacute;tico compleja](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Bajo una meritocracia, a los contribuyentes activos del proyecto (Aquellos que demuestran "m&eacute;rito") se les da un papel formal de toma de decisiones. Las decisiones se toman generalmente en base a un consenso de voto puro. El concepto de meritocracia fue iniciado por la [Fundaci&oacute;n Apache](https://www.apache.org/); [Todos los proyectos de Apache](https://www.apache.org/index.html#projects-list) son meritocracias. Las contribuciones s&oacute;lo pueden ser hechas por individuos que representan a s&iacute; mismos, no por una empresa.
+* **Meritocracia:** **(Nota: el t&eacute;rmino "meritocracia" tiene connotaciones negativas para algunas comunidades y tiene un [historia social y pol&iacute;tico compleja](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Bajo una meritocracia, a los contribuyentes activos del proyecto (aquellos que demuestran "m&eacute;rito") se les da un papel formal de toma de decisiones. Las decisiones se toman generalmente en base a un consenso de voto puro. El concepto de meritocracia fue iniciado por la [Fundaci&oacute;n Apache](https://www.apache.org/); [Todos los proyectos de Apache](https://www.apache.org/index.html#projects-list) son meritocracias. Las contribuciones s&oacute;lo pueden ser hechas por individuos que se representan a s&iacute; mismos, no por una empresa.
 
 * **Contribuci&oacute;n liberal:** Bajo un modelo de contribuci&oacute;n liberal, las personas que hacen m&aacute;s trabajo son reconocidas como las m&aacute;s influyentes, pero esto se basa en el trabajo actual y no en contribuciones hist&oacute;ricas. Las decisiones importantes del proyecto se toman sobre la base de un proceso de b&uacute;squeda de consenso (discutir quejas mayores) en lugar de voto puro, y tratar de incluir tantas perspectivas de la comunidad como sea posible. Ejemplos populares de proyectos que utilizan un modelo de contribuci&oacute;n liberal incluyen [Node.js](https://foundation.nodejs.org/) y [Rust](https://www.rust-lang.org/).
 
@@ -129,7 +129,7 @@ Los proyectos exitosos de c&oacute;digo abierto se utilizan por muchas personas
 
 A medida que el proyecto se utiliza m&aacute;s ampliamente, las personas que tienen experiencia en ella comienzan a estar m&aacute;s demandados - ¡puedes ser uno de ellos! - y a veces se les paga por el trabajo que realizan en el proyecto.
 
-Es importante tratar la actividad comercial como algo normal y como otra fuente de energ&iacute;a de desarrollo. Por supuesto, los desarrolladores pagados no deben recibir un trato especial sobre los no pagados; Cada contribuci&oacute;n debe ser evaluada por sus m&eacute;ritos t&eacute;cnicos. Sin embargo, la gente debe sentirse c&oacute;moda participando en la actividad comercial, y sentirse c&oacute;moda diciendo sus casos de uso al argumentar a favor de una mejora o caracter&iacute;stica en particular.
+Es importante tratar la actividad comercial como algo normal y como otra fuente de energ&iacute;a de desarrollo. Por supuesto, los desarrolladores pagados no deben recibir un trato especial sobre los no pagados. Cada contribuci&oacute;n debe ser evaluada por sus m&eacute;ritos t&eacute;cnicos. Sin embargo, la gente debe sentirse c&oacute;moda participando en la actividad comercial, y sentirse c&oacute;moda diciendo sus casos de uso al argumentar a favor de una mejora o caracter&iacute;stica en particular.
 
 "Comercial" es completamente compatible con "c&oacute;digo abierto". "Comercial" s&oacute;lo significa que existe dinero involucrado en alguna parte - que el software se utiliza en el comercio, que es cada vez m&aacute;s probable como un proyecto gana la adopci&oacute;n. (Cuando se utiliza software de c&oacute;digo abierto como parte de un producto que no es de c&oacute;digo abierto, el producto general sigue siendo un software "propietario", aunque, al igual que el c&oacute;digo abierto, podr&iacute;a utilizarse con fines comerciales o no comerciales).
 

From 86c20219ed64fb7362559cfda6cc7b1a3939bca7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dar=C3=ADo=20Here=C3=B1=C3=BA?= <magallania@gmail.com>
Date: Tue, 26 Oct 2021 15:37:00 -0300
Subject: [PATCH 276/749] Typo fixed (paragraph 31, 58, 62, 66, 70, 74, 82, 84,
 86, 88, 94, 100, 108, 114, 132)

- syntax issue (paragraph 35)
- duplicate word (paragraph 41)
- syntax issue (paragraph 72)
- syntax issue (paragraph 82, 92)
- duplicate ? (paragraph 136)
---
 _articles/es/legal.md | 44 +++++++++++++++++++++----------------------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/_articles/es/legal.md b/_articles/es/legal.md
index 96b7627fff2..7fce874610a 100644
--- a/_articles/es/legal.md
+++ b/_articles/es/legal.md
@@ -28,19 +28,19 @@ 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 **publico**.
+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**.
 
 ![crear repositorio](/assets/images/legal/repo-create-name.png)
 
-**Hacer tu proyecto de GitHub p&uacute;blico, no es lo mismo que licenciar tu proyecto.** Los proyectos p&uacute;blicos son cubiertos por [Los T&eacute;rminos de Servicio de GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), lo que les permite a otros ver y bifurcar el proyecto, pero su trabajo viene de otra manera sin permisos.
+**Hacer tu proyecto de GitHub p&uacute;blico, no es lo mismo que licenciar tu proyecto.** Los proyectos p&uacute;blicos son cubiertos por [los T&eacute;rminos de Servicio de GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), lo que les permite a otros ver y bifurcar el proyecto, pero su trabajo viene de otra manera sin permisos.
 
 Si quieres que otros usen, copien, modifiquen, o contribuyan a tu proyecto, debes incluir una licencia de c&oacute;digo abierto. Por ejemplo, nadie puede usar legalmente cualquier parte de tu proyecto de GitHub en su c&oacute;digo, incluso si es p&uacute;blico, a menos que expl&iacute;citamente le concedas dicho derecho.
 
 ## Solo dame un resumen acerca de lo que necesito para proteger mi proyecto.
 
-Tienes suerte, porque hoy, las licencias de c&oacute;digo abierto est&aacute;n estandarizadas y son f&aacute;ciles de usar. Puedes copiar copiar-pegar una licencia existente directamente en tu proyecto.
+Tienes suerte, porque hoy, las licencias de c&oacute;digo abierto est&aacute;n estandarizadas y son f&aacute;ciles de usar. Puedes copiar-pegar una licencia existente directamente en tu proyecto.
 
-[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/).
+[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/).
 
@@ -55,23 +55,23 @@ A menos que sea absolutamente necesario, evita t&eacute;rminos personalizados, m
 
 ## ¿Cu&aacute;l licencia de c&oacute;digo abierto es apropiada para mi proyecto?
 
-Si estas comenzando desde cero, es dif&iacute;cil equivocarse al elegir la [Licencia MIT](https://choosealicense.com/licenses/mit/). Es corta, muy f&aacute;cil de entender, y permite a cualquiera hacer lo que sea, siempre y cuando guarde una copia de la licencia, incluyendo tu aviso de derechos de autor. Tendr&aacute;s la posibilidad de lanzar el proyecto bajo otra licencia si alguna vez as&iacute; lo necesitas.
+Si est&aacute;s comenzando desde cero, es dif&iacute;cil equivocarse al elegir la [Licencia MIT](https://choosealicense.com/licenses/mit/). Es corta, muy f&aacute;cil de entender, y permite a cualquiera hacer lo que sea, siempre y cuando guarde una copia de la licencia, incluyendo tu aviso de derechos de autor. Tendr&aacute;s la posibilidad de lanzar el proyecto bajo otra licencia si alguna vez as&iacute; lo necesitas.
 
 Elegir la licencia de c&oacute;digo abierto correcta para tu proyecto, depende de tus objetivos.
 
-Muy probablemente, tu proyecto tiene (o tendr&aacute;) **dependencias**. Por ejemplo, si es un proyecto de c&oacute;digo abierto de Node.js, seguramente utilizaras librer&iacute;as del Node Package Manager (npm). Cada una de esas librer&iacute;as que utilizas, tendr&aacute;n su propia licencia de c&oacute;digo abierto. Si cada una de dichas licencias es "permisiva" (otorga permiso p&uacute;blico de uso, modificaci&oacute;n, y distribuci&oacute;n, sin ninguna condici&oacute;n de bajada), puedes usar cualquier licencia que quieras. Las licencias permisivas m&aacute;s comunes son MIT, Apache 2.0, ISC, y BSD.
+Muy probablemente, tu proyecto tiene (o tendr&aacute;) **dependencias**. Por ejemplo, si es un proyecto de c&oacute;digo abierto de Node.js, seguramente utilizar&aacute;s librer&iacute;as del Node Package Manager (npm). Cada una de esas librer&iacute;as que utilizas, tendr&aacute;n su propia licencia de c&oacute;digo abierto. Si cada una de dichas licencias es "permisiva" (otorga permiso p&uacute;blico de uso, modificaci&oacute;n, y distribuci&oacute;n, sin ninguna condici&oacute;n de bajada), puedes usar cualquier licencia que quieras. Las licencias permisivas m&aacute;s comunes son MIT, Apache 2.0, ISC, y BSD.
 
 Por otro lado, si cualquiera de las licencias de tus dependencias son copyleft "fuerte" (tambi&eacute;n brindan los mismos permisos, siempre y cuando se utilice la misma licencia consecuente), en este caso, tu proyecto deber&aacute; usar la misma licencia. Las licencias strong copyleft m&aacute;s comunes son GPLv2, GPLv3, and AGPLv3.
 
-Deber&iacute;as considerar tambi&eacute;n a las **comunidades** qu&eacute; esperas que usaran y contribuir&aacute;n a tu proyecto:
+Deber&iacute;as considerar tambi&eacute;n a las **comunidades** qu&eacute; esperas que usar&aacute;n y contribuir&aacute;n a tu proyecto:
 
 * **¿Quieres que tu proyecto sea usado como dependencia por otros proyectos?** Probablemente, la mejor opci&oacute;n sea usar la licencia m&aacute;s popular en tu comunidad. Por ejemplo, [MIT](https://choosealicense.com/licenses/mit/) es la licencia m&aacute;s popular para [npm libraries](https://libraries.io/search?platforms=NPM).
 * **¿Quieres que tu proyecto atraiga a grandes empresas?** Una gran empresa seguramente querr&aacute; una licencia de patente expresa por parte de todos los contribuyentes. En este caso, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) te tiene a ti (y a ellos) cubiertos.
-* **¿Quieres que tu proyecto atraiga a colaboradores los cuales no quieren que sus contribuciones sean usado en software de c&oacute;digo cerrado?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) o (si tampoco quieren contribuir a servicios de c&oacute;digo cerrado) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) Seria el m&aacute;s apropiado.
+* **¿Quieres que tu proyecto atraiga a colaboradores los cuales no quieren que sus contribuciones sean usado en software de c&oacute;digo cerrado?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) o (si tampoco quieren contribuir a servicios de c&oacute;digo cerrado) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) ser&iacute;a el m&aacute;s apropiado.
 
-Tu **empresa** puede que tenga requisitos espec&iacute;ficos para licencias de proyectos de c&oacute;digo abierto. Por ejemplo, tal vez requiera una licencia permisiva de modo que dicho proyecto pueda utilizarse en el producto de c&oacute;digo cerrado de dicha empresa. O tu empresa puede requerir una licencia strong copyleft y un acuerdo de colaboradores adicional (leer m&aacute;s abajo) para que solo tu empresa, y nadie m&aacute;s, pueda usar tu proyecto en software de c&oacute;digo cerrado. O tal vez, tu empresa tiene ciertas necesidades relacionadas con est&aacute;ndares, responsabilidad social, o transparencia, tales casos, requerir&aacute;n una estrategia de licencia particular. Habla con el [departamento legal de tu empresa](#qué-necesita-saber-el-equipo-legal-de-mi-empresa).
+Tu **empresa** puede que tenga requisitos espec&iacute;ficos para licencias de proyectos de c&oacute;digo abierto. Por ejemplo, tal vez requiera una licencia permisiva de modo que dicho proyecto pueda utilizarse en el producto de c&oacute;digo cerrado de dicha empresa. O tu empresa puede requerir una licencia strong copyleft y un acuerdo de colaboradores adicional (leer m&aacute;s abajo) para que solo tu empresa, y nadie m&aacute;s, pueda usar tu proyecto en software de c&oacute;digo cerrado. O tal vez, tu empresa tiene ciertas necesidades relacionadas con est&aacute;ndares, responsabilidad social, o transparencia; en tales casos requerir&aacute;n una estrategia de licencia particular. Habla con el [departamento legal de tu empresa](#qué-necesita-saber-el-equipo-legal-de-mi-empresa).
 
-Cuando creas un Nuevo proyecto en GitHub, te son brindadas opciones para elegir una licencia. Incluir cualquiera de las licencias enunciadas anteriormente, har&aacute;n de tu proyecto de GitHub, un proyecto de c&oacute;digo abierto. Si quisieras considerar otras opciones, revisa [choosealicense.com](https://choosealicense.com) en donde encontraras licencias adecuadas para tu proyecto, incluso si el mismo [no es software](https://choosealicense.com/non-software/).
+Cuando creas un Nuevo proyecto en GitHub, te son brindadas opciones para elegir una licencia. Incluir cualquiera de las licencias enunciadas anteriormente, har&aacute;n de tu proyecto de GitHub, un proyecto de c&oacute;digo abierto. Si quisieras considerar otras opciones, revisa [choosealicense.com](https://choosealicense.com) en donde encontrar&aacute;s licencias adecuadas para tu proyecto, incluso si el mismo [no es software](https://choosealicense.com/non-software/).
 
 ## Y si quieres cambiar la licencia de tu proyecto
 
@@ -79,25 +79,25 @@ La mayor&iacute;a de los proyectos no necesitan cambios de licencias. Pero ocasi
 
 Por ejemplo, a medida que tu proyecto crezca se a&ntilde;adir&aacute;n dependencias y usuarios, o tu empresa modifica estrategias, cualquiera de estos escenarios requerir&aacute;n diferentes licencias. Tambi&eacute;n, si te negaste a establecer una licencia a tu proyecto desde el comienzo, agregar una licencia es efectivamente lo mismo que cambiar las licencias. Hay tres aspectos fundamentales que debes considerar al a&ntilde;adir o cambiar la licencia de tu proyecto:
 
-**Es complicado.** Determinar la compatibilidad y conformidad de la licencia con quienes son propietarios de sus derechos de autor puede volverse complicado y confuso muy r&aacute;pidamente. Cambiar a una nueva pero compatible licencia para nuevos lanzamientos y colaboradores es diferente a cambiar la licencia de todos los colaboradores ya existentes. Involucre a su equipo legal frente a cualquier deseo de cambiar licencias. Incluso si t&uacute; tienes o puedes obtener permiso de los titulares de derechos de autor de su proyecto para un cambio de licencia, considera el impacto de los cambios en los colaboradores y usuarios de tu proyecto. Imagina al cambio de licencia como un "evento de gobierno" para tu proyecto que probablemente marchara sin contratiempos mediante la comunicaci&oacute;n y consultas claras con las partes interesadas en el proyecto. ¡M&aacute;s razones para elegir y utilizar una licencia adecuada para su proyecto desde el comienzo!
+**Es complicado.** Determinar la compatibilidad y conformidad de la licencia con quienes son propietarios de sus derechos de autor puede volverse complicado y confuso muy r&aacute;pidamente. Cambiar a una nueva pero a una licencia compatible para nuevos lanzamientos y colaboradores es diferente a cambiar la licencia de todos los colaboradores ya existentes. Involucre a su equipo legal frente a cualquier deseo de cambiar licencias. Incluso si t&uacute; tienes o puedes obtener permiso de los titulares de derechos de autor de su proyecto para un cambio de licencia, considera el impacto de los cambios en los colaboradores y usuarios de tu proyecto. Imagina al cambio de licencia como un "evento de gobierno" para tu proyecto que probablemente marchar&aacute; sin contratiempos mediante la comunicaci&oacute;n y consultas claras con las partes interesadas en el proyecto. ¡M&aacute;s razones para elegir y utilizar una licencia adecuada para su proyecto desde el comienzo!
 
-**La licencia existente de su proyecto.** Si la licencia existente de su proyecto es compatible con la licencia a la que quieres cambiar, puedes simplemente empezar a usar la nueva licencia. Esto sucede debido a que si la licencia A es compatible con la licencia B, vas a estar cumpliendo con los t&eacute;rminos de A mientras cumples con los t&eacute;rminos de B (pero no necesariamente viceversa). As&iacute; que, si estas utilizando una licencia permisiva (Por ejemplo, MIT), puedes cambiar a una licencia con m&aacute;s condiciones, siempre y cuando mantengas una copia de la licencia MIT y cualquier aviso de derechos de autos asociado (esto implicar&iacute;a, continuar cumpliendo con las condiciones m&iacute;nimas de la licencia MIT). Pero si tu licencia actual no es permisiva (por ejemplo, copyleft, o si no tienes licencia) y no eres el &uacute;nico propietario de los derechos de autor, no podr&iacute;as simplemente cambiar la licencia del proyecto a MIT. Esencialmente, con una licencia permisiva del proyecto, en la cual los propietarios de derechos de autor han dado permiso por adelantado de cambiar licencias.
+**La licencia existente de su proyecto.** Si la licencia existente de su proyecto es compatible con la licencia a la que quieres cambiar, puedes simplemente empezar a usar la nueva licencia. Esto sucede debido a que si la licencia A es compatible con la licencia B, vas a estar cumpliendo con los t&eacute;rminos de A mientras cumples con los t&eacute;rminos de B (pero no necesariamente viceversa). As&iacute; que, si est&aacute;s utilizando una licencia permisiva (por ejemplo, MIT), puedes cambiar a una licencia con m&aacute;s condiciones, siempre y cuando mantengas una copia de la licencia MIT y cualquier aviso de derechos de autos asociado (esto implicar&iacute;a, continuar cumpliendo con las condiciones m&iacute;nimas de la licencia MIT). Pero si tu licencia actual no es permisiva (por ejemplo, copyleft, o si no tienes licencia) y no eres el &uacute;nico propietario de los derechos de autor, no podr&iacute;as simplemente cambiar la licencia del proyecto a MIT. Esencialmente, con una licencia permisiva del proyecto, en la cual los propietarios de derechos de autor han dado permiso por adelantado de cambiar licencias.
 
-**Los propietarios de derechos de autor de tu proyecto.** Si eres el &uacute;nico contribuyente a tu proyecto, entonces tu o tu empresa es el &uacute;nico titular de los derechos de autor del proyecto. Puedes a&ntilde;adir o cambiar a cualquier licencia que tu o tu empresa deseen. En otros casos, podr&iacute;a haber propietarios de derechos de autor de los cuales necesitar&iacute;as realizar un acuerdo para poder cambiar las licencias. ¿Qui&eacute;nes? Personas que hayan realizado commits a tu proyecto es una buena forma de comenzar. Pero en algunos casos los derechos de autor estar&aacute;n en propiedad de los empleadores de dichas personas. En algunos casos las personas solo habr&aacute;n hecho _la menor parte_ de las contribuciones, pero no hay una regla r&aacute;pida y firme que establezca a partir de que cantidad de l&iacute;neas de c&oacute;digo est&aacute;n o no sujetos a derechos de autor dichos colaboradores. Para proyectos j&oacute;venes y peque&ntilde;os, puede ser factible lograr que todos los colaboradores acepten un cambio de licencia en una issue o un pull request. Para proyectos largos y de larga vida, tendr&aacute;s que buscar a muchos contribuyentes e incluso sus herederos. Mozilla tardo a&ntilde;os (2001-2006) para cambiar de licencia a Firefox, Thunderbird, y software relacionado.
+**Los propietarios de derechos de autor de tu proyecto.** Si eres el &uacute;nico contribuyente a tu proyecto, entonces t&uacute; o tu empresa es el &uacute;nico titular de los derechos de autor del proyecto. Puedes a&ntilde;adir o cambiar a cualquier licencia que t&uacute; o tu empresa deseen. En otros casos, podr&iacute;a haber propietarios de derechos de autor de los cuales necesitar&iacute;as realizar un acuerdo para poder cambiar las licencias. ¿Qui&eacute;nes? Personas que hayan realizado commits a tu proyecto es una buena forma de comenzar. Pero en algunos casos los derechos de autor estar&aacute;n en propiedad de los empleadores de dichas personas. En algunos casos las personas solo habr&aacute;n hecho _la menor parte_ de las contribuciones, pero no hay una regla r&aacute;pida y firme que establezca a partir de que cantidad de l&iacute;neas de c&oacute;digo est&aacute;n o no sujetos a derechos de autor dichos colaboradores. Para proyectos j&oacute;venes y peque&ntilde;os, puede ser factible lograr que todos los colaboradores acepten un cambio de licencia en una issue o un pull request. Para proyectos largos y de larga vida, tendr&aacute;s que buscar a muchos contribuyentes e incluso sus herederos. Mozilla tard&oacute; a&ntilde;os (2001-2006) para cambiar de licencia a Firefox, Thunderbird, y software relacionado.
 
-De manera alternativa, puedes tener colaboradores que est&eacute;n de acuerdo por adelantado (mediante un acuerdo adicional de colaboradores – ver m&aacute;s abajo) con cambios de licencia bajo ciertas condiciones, m&aacute;s all&aacute; de los permitidos por tu licencia de c&oacute;digo abierto existente. Esto cambia la complejidad de cambiar la licencia. Necesitaras m&aacute;s ayuda por parte de tus abogados, y aun deber&aacute;s comunicarte claramente con las partes interesadas en su proyecto al ejecutar un cambio de licencia.
+De manera alternativa, puedes tener colaboradores que est&eacute;n de acuerdo por adelantado (mediante un acuerdo adicional de colaboradores – ver m&aacute;s abajo) con cambios de licencia bajo ciertas condiciones, m&aacute;s all&aacute; de los permitidos por tu licencia de c&oacute;digo abierto existente. Esto cambia la complejidad de cambiar la licencia. Necesitar&aacute;s m&aacute;s ayuda por parte de tus abogados, y aun deber&aacute;s comunicarte claramente con las partes interesadas en su proyecto al ejecutar un cambio de licencia.
 
 ## ¿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 al 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://help.github.com/en/github/site-policy/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 click, que tienen los derechos necesarios para contribuir bajo la licencia de condigo 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.
+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.
 
 Tambi&eacute;n, al a&ntilde;adir "papeleo" que algunos consideran innecesario, dif&iacute;cil de entender, o injusto (cuando el beneficiario del acuerdo obtiene m&aacute;s derechos que los colaboradores o el p&uacute;blico a trav&eacute;s de la licencia de c&oacute;digo abierto del proyecto), un acuerdo adicional de colaboradores puede ser percibido poco amigable a la comunidad del proyecto.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
-    Hemos eliminado la CLA para Node.js. Esto, reduce la barrera de entrada para colaboradores de Node.js, ampliando asi la base de contribuyentes.
+    Hemos eliminado la CLA para Node.js. Esto, reduce la barrera de entrada para colaboradores de Node.js, ampliando as&iacute; la base de contribuyentes.
   <p markdown="1" class="pquote-credit">
 — @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
   </p>
@@ -105,13 +105,13 @@ Tambi&eacute;n, al a&ntilde;adir "papeleo" que algunos consideran innecesario, d
 
 Algunas situaciones en las cuales deber&iacute;as considerar un acuerdo adicional de colaboradores pueden ser:
 
-* Tus abogados quieren que todos los colaboradores acepten expresamente (_firma_, online o offline) los t&eacute;rminos de contribuci&oacute;n, quiz&aacute;s porque sienten que una licencia de c&oacute;digo abierto no es suficiente (incluso cuando lo sea!). Si este es la &uacute;nica preocupaci&oacute;n, un acuerdo adicional de colaboradores que afirme la licencia de c&oacute;digo abierto del proyecto, deber&iacute;a ser suficiente. El [Acuerdo Adicional de colaboradores Individual de jQuery](https://contribute.jquery.org/CLA/) es un buen ejemplo de un acuerdo adicional de colaboradores ligero. Para algunos proyectos, un [Certificado de Origen del Desarrollador](https://GitHub.com/probot/dco) puede ser una alternativa a&uacute;n m&aacute;s simple.
+* Tus abogados quieren que todos los colaboradores acepten expresamente (_firma_, online o offline) los t&eacute;rminos de contribuci&oacute;n, quiz&aacute;s porque sienten que una licencia de c&oacute;digo abierto no es suficiente (incluso cuando lo sea!). Si esta es la &uacute;nica preocupaci&oacute;n, un acuerdo adicional de colaboradores que afirme la licencia de c&oacute;digo abierto del proyecto, deber&iacute;a ser suficiente. El [Acuerdo Adicional de colaboradores Individual de jQuery](https://contribute.jquery.org/CLA/) es un buen ejemplo de un acuerdo adicional de colaboradores ligero. Para algunos proyectos, un [Certificado de Origen del Desarrollador](https://GitHub.com/probot/dco) puede ser una alternativa a&uacute;n m&aacute;s simple.
 
 * Tu proyecto usa una licencia de c&oacute;digo abierto que no incluye una concesi&oacute;n de patentes explicita (como MIT), y necesitas una concesi&oacute;n de patentes por parte de todos los colaboradores, algunos de los cuales quiz&aacute;s trabajen para empresas con grandes cantidades de patentes que podr&iacute;an utilizarse para dirigirse a usted o a otros contribuyentes y usuarios del proyecto. El [Acuerdo Adicional de colaboradores Individual de Apache](https://www.apache.org/licenses/icla.pdf) es un acuerdo adicional de colaboradores que posee una concesi&oacute;n de patentes reflejando el que se encuentra en Apache License 2.0.
 
 * Tu proyecto est&aacute; bajo una licencia copyleft, pero tambi&eacute;n necesitas distribuir una versi&oacute;n propietaria del proyecto. Necesitaras que cada colaborador te asigne sus derechos de autor o te garantice a ti (pero no al p&uacute;blico) una licencia permisiva. El [Acuerdo de colaboradores MongoDB](https://www.mongodb.com/legal/contributor-agreement) es un ejemplo de este tipo de acuerdo.
 
-* Crees que el proyecto necesitara cambiar la licencia durante su tiempo de vida y quieres que los colaboradores acepten por adelantado esos cambios.
+* Crees que el proyecto necesitar&aacute; cambiar la licencia durante su tiempo de vida y quieres que los colaboradores acepten por adelantado esos cambios.
 
 Si necesitas usar un acuerdo adicional de colaboradores para tu proyecto, considere el uso de una integraci&oacute;n como [CLA assistant](https://GitHub.com/cla-assistant/cla-assistant) para minimizar la distracci&oacute;n de los contribuyentes.
 
@@ -123,17 +123,17 @@ Para mejor, o peor, considera comentarles incluso en el caso en que sea un proye
 
 Probablemente tengas un "acuerdo IP de empleado" con tu empresa que les da cierto tipo de control sobre tus proyectos, especialmente si ellos est&aacute;n relacionados con el negocio de la empresa o si utilizan recursos de la empresa para desarrollar el proyecto. Tu empresa _deber&iacute;a_ brindarte f&aacute;cilmente permisos, y tal vez ya cuentes con ellos a trav&eacute;s de un acuerdo de IP amigable hacia los empleados o mediante pol&iacute;ticas empresariales. Si no es el caso, puedes negociar (por ejemplo, explicar que su proyecto posee objetivos profesionales de aprendizaje y desarrollo de la empresa para ti), o evitar trabajar en proyectos hasta que encuentres una mejor empresa.
 
-**Si est&aacute;s trabajando en un proyecto de c&oacute;digo abierto para tu empresa** entonces definitivamente debes hacerles saber. Tu equipo legal seguramente ya cuenta con pol&iacute;ticas para esa licencia de c&oacute;digo abierto (y puede que tambi&eacute;n un acuerdo adicional de colaboradores) para usar basado en los requisitos y pericia del negocio de la empresa para asegurar que tu proyecto cumple con la licencia de sus dependencias. De lo contrario, tanto tu como ellos, est&aacute;n de suerte! tu equipo legal deber&iacute;a estar ansioso por trabajar con usted para acordar estas cosas. Algunos aspectos a considerar:
+**Si est&aacute;s trabajando en un proyecto de c&oacute;digo abierto para tu empresa** entonces definitivamente debes hacerles saber. Tu equipo legal seguramente ya cuenta con pol&iacute;ticas para esa licencia de c&oacute;digo abierto (y puede que tambi&eacute;n un acuerdo adicional de colaboradores) para usar basado en los requisitos y pericia del negocio de la empresa para asegurar que tu proyecto cumple con la licencia de sus dependencias. De lo contrario, tanto t&uacute; como ellos, est&aacute;n de suerte! tu equipo legal deber&iacute;a estar ansioso por trabajar con usted para acordar estas cosas. Algunos aspectos a considerar:
 
 * **Material de terceros**   ¿tiene tu proyecto dependencias creadas por otros o bien incluye o usa c&oacute;digos ajenos? Esto comienza con la elecci&oacute;n de una licencia que funcione con las licencias de c&oacute;digo abierto de terceros (ver arriba). Si su proyecto modifica o distribuye c&oacute;digo abierto de terceros, su equipo legal tambi&eacute;n querr&aacute; saber si cumple con otras condiciones de las licencias de c&oacute;digo abierto de terceros, como la retenci&oacute;n de avisos de derechos de autor. Si tu proyecto utiliza c&oacute;digo de otros que no tienen una licencia de c&oacute;digo abierto, probablemente tendr&aacute;s que pedirle a los mantenedores que [agreguen una licencia de c&oacute;digo abierto](https://choosealicense.com/no-license/#for-users), y si no puedes conseguir una, deja de usar su c&oacute;digo en tu proyecto.
 
 * **Secretos comerciales:**   Considera si hay algo en el proyecto que la empresa no quiere poner a disposici&oacute;n del p&uacute;blico en general. Si es as&iacute;, puedes hacer de c&oacute;digo abierto al resto del proyecto, despu&eacute;s de extraer el material que desea mantener privado.
 
-* **Patentes:** ¿Esta tu empresa solicitando una patente, cuya liberaci&oacute;n del c&oacute;digo fuente del proyecto implique una [revelaci&oacute;n p&uacute;blica](https://en.wikipedia.org/wiki/Public_disclosure)? Tristemente, puede que te pidan que esperes (o tal vez, la empresa volver&aacute; a considerar la sabidur&iacute;a de la aplicaci&oacute;n). Si est&aacute;s esperando contribuciones a tu proyecto de los empleados de empresas con cantidades grandes de patentes, tu equipo legal puede que desee que utilices una licencia con una concesi&oacute;n de patente expresa de los contribuyentes (como Apache 2.0 o GPLv3), o un acuerdo adicional de colaboradores (ver m&aacute;s arriba).
+* **Patentes:** ¿Est&aacute; tu empresa solicitando una patente, cuya liberaci&oacute;n del c&oacute;digo fuente del proyecto implique una [revelaci&oacute;n p&uacute;blica](https://en.wikipedia.org/wiki/Public_disclosure)? Tristemente, puede que te pidan que esperes (o tal vez, la empresa volver&aacute; a considerar la sabidur&iacute;a de la aplicaci&oacute;n). Si est&aacute;s esperando contribuciones a tu proyecto de los empleados de empresas con cantidades grandes de patentes, tu equipo legal puede que desee que utilices una licencia con una concesi&oacute;n de patente expresa de los contribuyentes (como Apache 2.0 o GPLv3), o un acuerdo adicional de colaboradores (ver m&aacute;s arriba).
 
 * **Marca comercial** Verifica que el nombre de tu proyecto [no entre en conflicto con alguna marca existente](../starting-a-project/#evitando-conflictos-con-los-nombres). Si utilizas marcas comerciales de tu empresa en el proyecto, comprueba que no genere ning&uacute;n conflicto. [FOSSmarks](http://fossmarks.org/) es una gu&iacute;a pr&aacute;ctica para la comprensi&oacute;n de las marcas en el contexto de los proyectos de c&oacute;digo libre y abierto.
 
-* **Privacidad** ¿Recolecta tu proyecto datos de sus usuarios? ¿Recopila su proyecto datos en los servidores de la empresa sin el consentimiento de los usuarios??  tu equipo legal puede ayudarte a cumplir con las pol&iacute;ticas de la empresa y las regulaciones externas.
+* **Privacidad** ¿Recolecta tu proyecto datos de sus usuarios? ¿Recopila su proyecto datos en los servidores de la empresa sin el consentimiento de los usuarios?  Tu equipo legal puede ayudarte a cumplir con las pol&iacute;ticas de la empresa y las regulaciones externas.
 
 Si est&aacute;s lanzando el primer proyecto de c&oacute;digo abierto de tu empresa, lo anterior es m&aacute;s que suficiente para conseguirlo.
 

From 8227288a6aba3b2ea95480a24da622315031f382 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Wed, 27 Oct 2021 10:13:34 +0200
Subject: [PATCH 277/749] Update _articles/es/legal.md

---
 _articles/es/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/es/legal.md b/_articles/es/legal.md
index 7fce874610a..6d47f7791c3 100644
--- a/_articles/es/legal.md
+++ b/_articles/es/legal.md
@@ -133,7 +133,7 @@ Probablemente tengas un "acuerdo IP de empleado" con tu empresa que les da ciert
 
 * **Marca comercial** Verifica que el nombre de tu proyecto [no entre en conflicto con alguna marca existente](../starting-a-project/#evitando-conflictos-con-los-nombres). Si utilizas marcas comerciales de tu empresa en el proyecto, comprueba que no genere ning&uacute;n conflicto. [FOSSmarks](http://fossmarks.org/) es una gu&iacute;a pr&aacute;ctica para la comprensi&oacute;n de las marcas en el contexto de los proyectos de c&oacute;digo libre y abierto.
 
-* **Privacidad** ¿Recolecta tu proyecto datos de sus usuarios? ¿Recopila su proyecto datos en los servidores de la empresa sin el consentimiento de los usuarios?  Tu equipo legal puede ayudarte a cumplir con las pol&iacute;ticas de la empresa y las regulaciones externas.
+* **Privacidad** ¿Recolecta tu proyecto datos de sus usuarios? ¿Recopila su proyecto datos en los servidores de la empresa sin el consentimiento de los usuarios? Tu equipo legal puede ayudarte a cumplir con las pol&iacute;ticas de la empresa y las regulaciones externas.
 
 Si est&aacute;s lanzando el primer proyecto de c&oacute;digo abierto de tu empresa, lo anterior es m&aacute;s que suficiente para conseguirlo.
 

From 1d245c812b56a2f8db0c4e2ef612cb19ddc0804e Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Mon, 1 Nov 2021 09:28:14 +0330
Subject: [PATCH 278/749] Update finding-users.md

changed for more readability
---
 _articles/fa/finding-users.md | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/_articles/fa/finding-users.md b/_articles/fa/finding-users.md
index 28e6316e9d5..d5ff6ed0547 100644
--- a/_articles/fa/finding-users.md
+++ b/_articles/fa/finding-users.md
@@ -22,16 +22,16 @@ related:
 
 به یاد داشته باشید به این دلیل که پروژه‌ی شما مشکلی را برای کاربران برطرف می‌کند؛ افراد به عنوان کاربر به پروژه‌ی شما ملحق می‌شوند و در نهایت به عنوان یک مشارکت‌کننده معرفی می‌شوند. همانطور که درباره‌ی پیام و ارزش پروژه‌‌ی خود فکر می‌کنید، سعی کنید آن‌ها را از دریچه‌ی آنچه که کاربران و مشارکت‌کنندگان می‌خواهند نظاره کنید.
 
-به عنوان مثال، @robb از کدها استفاده می‌کند تا به طور واضح اهمیت پروژه‌ی خود را نشان دهد؛ نقشه‌نگاری [Cartography](https://github.com/robb/Cartography) مفید واقع می‌شود:
+به عنوان مثال، <span dir="rtl">@robb</span> از کدها استفاده می‌کند تا به طور واضح اهمیت پروژه‌ی خود را نشان دهد؛ نقشه‌نگاری [Cartography](https://github.com/robb/Cartography) مفید واقع می‌شود:
 
 ![Cartography README](/assets/images/finding-users/cartography.jpg)
 
-برای درک بهتر مفهوم، مورد [Personas and Pathways](https://mozillascience.github.io/working-open-workshop/personas_pathways/) موزیلا (Mozilla) را برای توسعه‌ی پرسونای کاربران بررسی کنید
+برای درک بهتر مفهوم، مورد [Personas and Pathways](https://mozillascience.github.io/working-open-workshop/personas_pathways/) موزیلا <span dir="rtl">(Mozilla)</span> را برای توسعه‌ی پرسونای کاربران بررسی کنید
 
 ## مردم را در پیدا کردن و دنبال کردن پروژه‌ی خودتان یاری کنید
 
 <aside markdown="1" class="pquote">
-  شما ترجیحاً به یک URL (نشانی وب) نیاز دارید تا بتوانید پروژه‌ی خود را تبلیغ کنید و مردم را به آن مشتاق سازید. لازم نیست که قالب و یا حتی یک آدرس اینترنتی شیک و فانتزی داشته باشید، اما پروژه‌ی شما به یک نقطه‌ی توجه (مطلب اصلی و مهم) نیاز دارد.
+  شما ترجیحاً به یک <span dir="rtl">URL</span> (نشانی وب) نیاز دارید تا بتوانید پروژه‌ی خود را تبلیغ کنید و مردم را به آن مشتاق سازید. لازم نیست که قالب و یا حتی یک آدرس اینترنتی شیک و فانتزی داشته باشید، اما پروژه‌ی شما به یک نقطه‌ی توجه (مطلب اصلی و مهم) نیاز دارد.
   <p markdown="1" class="pquote-credit">
 — Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
   </p>
@@ -39,9 +39,9 @@ related:
 
 طوری باشد که با اشاره‌ای کوچک، مردم پروژه‌ی شما را به یاد بیاورند.
 
-**برای توسعه‌ی پروژه‌ی خود، کاملا بر کار خویش آگاه و از آن اطمینان داشته باشید.** یک آدرس توییتری، آدرس GitHub یا کانال IRC راهی آسان برای مشایعت و هدایت افراد به سمت پروژه‌ی خودتان است. این رسانه‌ها همچنین به اجتماع در حال رشد پروژه‌ی شما، محلی برای تجمع و تبادل نظر می‌دهند.
+**برای توسعه‌ی پروژه‌ی خود، کاملا بر کار خویش آگاه و از آن اطمینان داشته باشید.** یک آدرس توییتری، آدرس <span dir="rtl">GitHub</span> یا کانال <span dir="rtl">IRC</span> راهی آسان برای مشایعت و هدایت افراد به سمت پروژه‌ی خودتان است. این رسانه‌ها همچنین به اجتماع در حال رشد پروژه‌ی شما، محلی برای تجمع و تبادل نظر می‌دهند.
 
-اگر هنوز مایل به راه‌اندازی رسانه‌هایی برای پروژه‌ی خودتان نیستید، در همه‌ی کارهایی که انجام می‌دهید Twitter یا GitHub خود را ترویج دهید. توسعه و تبلیغ Twitter یا GitHub به مردم این امکان را می‌دهد تا با شما در ارتباط باشند یا کارهای شما را دنبال کنند. اگر در جلسه یا رویدادی صحبت می‌کنید، اطمینان حاصل کنید تا اطلاعات تماس شما در مشخصات شما یا اسلایدها آمده باشد.
+اگر هنوز مایل به راه‌اندازی رسانه‌هایی برای پروژه‌ی خودتان نیستید، در همه‌ی کارهایی که انجام می‌دهید <span dir="rtl">Twitter</span> یا <span dir="rtl">GitHub</span> خود را ترویج دهید. توسعه و تبلیغ <span dir="rtl">Twitter</span> یا <span dir="rtl">GitHub</span> به مردم این امکان را می‌دهد تا با شما در ارتباط باشند یا کارهای شما را دنبال کنند. اگر در جلسه یا رویدادی صحبت می‌کنید، اطمینان حاصل کنید تا اطلاعات تماس شما در مشخصات شما یا اسلایدها آمده باشد.
  
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
@@ -53,7 +53,7 @@ related:
 
 **ساخت وب‌سایتی را برای پروژه‌ی خود مد نظر قرار دهید.** داشتن وب‌سایت، پروژه‌ی شما را دوستانه‌تر و برای وب‌گردی و گشت‌زنی ساده‌تر می‌کند؛ به ویژه هنگامی که با مستندات و آموزش‌های واضح همراه باشد. داشتن یک وب سایت همچنین بیانگر این است که پروژه‌ی شما فعال است که همین باعث می‌شود مخاطبان شما احساس راحتی بیشتری در استفاده از آن داشته باشند. مثال‌هایی را ارائه دهید تا به افراد در مورد چگونگی استفاده از پروژه‌تان ایده بدهد.
 
-[@Adrianholovaty](https://news.ycombinator.com/item?id=7531689)، یکی از سازند‌گان شرکت «Django» گفت که وب‌سایت «بهترین کاری بود که می‌توانستیم برای Django در آن روزهای اولیه انجام دهیم». اگر پروژه‌ی شما در GitHub باشد، می‌توانید با استفاده از [GitHub Pages](https://pages.github.com/)، به راحتی وب‌سایت ایجاد کنید. [Yeoman](http://yeoman.io/)، [Vagrant](https://www.vagrantup.com/)  و [Middleman](https://middlemanapp.com/) چند نمونه از وب‌سایت‌های عالی و جامع هستند.                                      
+[@Adrianholovaty](https://news.ycombinator.com/item?id=7531689)، یکی از سازند‌گان شرکت <span dir="rtl">Django</span> گفت که وب‌سایت «بهترین کاری بود که می‌توانستیم برای <span dir="rtl">Django</span> در آن روزهای اولیه انجام دهیم». اگر پروژه‌ی شما در <span dir="rtl">GitHub</span> باشد، می‌توانید با استفاده از [GitHub Pages](https://pages.github.com/)، به راحتی وب‌سایت ایجاد کنید. [Yeoman](http://yeoman.io/)، [Vagrant](https://www.vagrantup.com/)  و [Middleman](https://middlemanapp.com/) چند نمونه از وب‌سایت‌های عالی و جامع هستند.                                      
 
 ![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
 
@@ -75,13 +75,13 @@ related:
 
 ببینید آیا می‌توانید روش‌هایی برای به اشتراک گذاشتن پروژه خود به صورت متناسبی پیدا کنید:
 
-* **با پروژه‌ها و انجمن‌های اوپن سورس مرتبط و مدنظرتان آشنا شوید.** گاهی اوقات، لازم نیست که مستقیماً پروژه‌ی خود را تبلیغ کنید. اگر پروژه‌ی شما برای متخصصین علم داده که از پایتون استفاده می‌کنند عالی است، با انجمن علوم داده‌ی پایتون ملاقات کنید و آشنا شوید. هنگامی که مردم با شما آشنا شوند، فرصت‌ها به صورت خودکار و طبیعی برای بحث و گقت و گو و به اشتراک گذاشتن کارهای شما بوجود می‌آید.
+* **با پروژه‌ها و انجمن‌های اوپن سورس مرتبط و مدنظرتان آشنا شوید.** گاهی اوقات، لازم نیست که مستقیماً پروژه‌ی خود را تبلیغ کنید. اگر پروژه‌ی شما برای متخصصین علم داده که از پایتون استفاده می‌کنند عالی است، با انجمن علوم داده‌ی پایتون ملاقات کنید و آشنا شوید. هنگامی که مردم با شما آشنا شوند، فرصت‌ها به صورت خودکار و طبیعی برای بحث و گفت و گو و به اشتراک گذاشتن کارهای شما بوجود می‌آید.
 * **افرادی که مشکلاتی دارند و پروژه‌ی شما، آن مشکلات را حل و فصل می‌کند را پیدا کنید.**از طریق تالارهای گفتگوی (فروم‌ها) مرتبط، به جستجوی افرادی که می‌توانندمخاطبانِ هدفِ پروژه‌ی شما باشند، بپردازید. به سوالات آن‌ها پاسخ دهید و در زمانی مناسب، روشی مدبرانه تعبیه کنید تا پروژه‌ی خود را به عنوان یک راه‌حل پیشنهاد دهید.
-* **از انتقادات و پیشنهادات روی‌گردان نباشید.** خود و کارهایتان را به مخاطب‌هایی مرتبط و متناسب که به کار شما علاقه دارند، معرفی کنید. مخاطبان خود را بشناسید و کسانی که از پروژه‌ی شما سود و منفعت حاصل می‌کنند را مشخص کنید. سعی کنید این جمله را کامل کنید:  «من فکر می‌کنم پروژه‌ی من واقعاً به X، که در تلاش برای انجام کار Y است، کمک خواهد کرد». به جای اینکه صرفاً فقط کار خود را تبلیغ کنید، به بازخورد دیگران گوش دهید و پاسخگو باشید.
+* **از انتقادات و پیشنهادات روی‌گردان نباشید.** خود و کارهایتان را به مخاطب‌هایی مرتبط و متناسب که به کار شما علاقه دارند، معرفی کنید. مخاطبان خود را بشناسید و کسانی که از پروژه‌ی شما سود و منفعت حاصل می‌کنند را مشخص کنید. سعی کنید این جمله را کامل کنید:  «من فکر می‌کنم پروژه‌ی من واقعاً به <span dir="rtl">X</span>، که در تلاش برای انجام کار <span dir="rtl">Y</span> است، کمک خواهد کرد». به جای اینکه صرفاً فقط کار خود را تبلیغ کنید، به بازخورد دیگران گوش دهید و پاسخگو باشید.
 
-به طور کلی، به کمک کردن به دیگران تمرکز کنید قبل از اینکه چیزهایی را در عوض درخواست کنید؛ چونکه که اگر هر کسی بخواهد پروژه‌های خودش را به صورت آنلاین تبلیغ کند، همهمه و شلوغی زیادی بر پا خواهد شد. برای اینکه در جمعی شناخته شوید، سعی کنید خود را به دیگران معرفی کنید و نه اینکه فقط آنچه که می‌خواهید را بازگو کنید.
+به طور کلی، به کمک کردن به دیگران تمرکز کنید قبل از اینکه چیزهایی را در عوض درخواست کنید؛ چون که اگر هر کسی بخواهد پروژه‌های خودش را به صورت آنلاین تبلیغ کند، همهمه و شلوغی زیادی بر پا خواهد شد. برای اینکه در جمعی شناخته شوید، سعی کنید خود را به دیگران معرفی کنید و نه اینکه فقط آنچه که می‌خواهید را بازگو کنید.
 
-اگر کسی به فعالیت‌های اولیه‌ی شما پاسخی نداد و یا توجه نکرد، ناامید نشوید! اکثر راه‌اندازی‌های پروژه‌ها، فرآیندهایی هستند که باید چندین و چندین بار تکرار شوند که ممکن است ماه‌ها یا سال‌ها به طول انجامد. اگر بار اول پاسخی دریافت نکردید، تاکتیک دیگری را امتحان کنید یا ابتدا به دنبال روش‌هایی برای افزودن ارزش به کار دیگران باشید. راه‌اندازی و توسعه‌ی پروژه، به وقت و تعهد نیاز دارد.
+اگر کسی به فعالیت‌های اولیه‌ی شما پاسخی نداد و یا توجه نکرد، ناامید نشوید! اکثر راه‌اندازی‌های پروژه‌ها، فرآیندهایی هستند که باید چندین و چند بار تکرار شوند که ممکن است ماه‌ها یا سال‌ها به طول انجامد. اگر بار اول پاسخی دریافت نکردید، تاکتیک دیگری را امتحان کنید یا ابتدا به دنبال روش‌هایی برای افزودن ارزش به کار دیگران باشید. راه‌اندازی و توسعه‌ی پروژه، به وقت و تعهد نیاز دارد.
 
 ## هر جا که مخاطبان شما بودند، شما هم به آنجا بروید (آفلاین)
 
@@ -93,7 +93,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
-  من از اینکه بخواهم به «PyCon» بروم، خیلی استرس داشتم. قرار بود که سخنرانی بکنم، قرار بود فقط با چند نفر در آنجا آشنا شوم، قرار بود یک هفته‌ی تمام آنجا می‌بودم. .... هر چند نیازی نبود که استرس داشته باشم. PyCon  فراتر از انتظارهایم فوق‌العاده بود! همگی به طرز خار‌ق‌العاده‌ای رفتاری دوستانه داشتند و خوش‌برخورد بودند، به قدری که من به ندرت وقت می‌کردم که با مردم صحبت نکنم!
+  من از اینکه بخواهم به <span dir="rtl">«PyCon»</span> بروم، خیلی استرس داشتم. قرار بود که سخنرانی بکنم، قرار بود فقط با چند نفر در آنجا آشنا شوم، قرار بود یک هفته‌ی تمام آنجا می‌بودم. .... هر چند نیازی نبود که استرس داشته باشم. <span dir="rtl">PyCon</span>  فراتر از انتظارهایم فوق‌العاده بود! همگی به طرز خار‌ق‌العاده‌ای رفتاری دوستانه داشتند و خوش‌برخورد بودند، به قدری که من به ندرت وقت می‌کردم که با مردم صحبت نکنم!
   <p markdown="1" class="pquote-credit">
 — @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
   </p>
@@ -116,7 +116,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
-  من خیلی محترمانه برای مسئولان کنفرانس JS نامه نوشتم و از آن‌ها خواهش کردم تا نوبتی به من برای سخنرانی در کنفرانس JS اروپا به من بدهند. ...برای این سخنرانی که شش ماه بر روی آن کار کرده بودم، بسیار ترسیده بودم. ...فقط با خودم می‌گفتم، خدایا! من اینجا چیکار می‌کنم؟
+  من خیلی محترمانه برای مسئولان کنفرانس <span dir="rtl">JS</span> نامه نوشتم و از آن‌ها خواهش کردم تا نوبتی به من برای سخنرانی در کنفرانس <span dir="rtl">JS</span> اروپا به من بدهند. ...برای این سخنرانی که شش ماه بر روی آن کار کرده بودم، بسیار ترسیده بودم. ...فقط با خودم می‌گفتم، خدایا! من اینجا چیکار می‌کنم؟
   <p markdown="1" class="pquote-credit">
 — @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
   </p>
@@ -130,7 +130,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
- تنها به خاطر درخواست‌های زیاد از urllib3 است که urllib3 محبوب‌ترین کتابخانه‌ی پایتون شخص ثالث (third-party) امروزی است.
+ تنها به خاطر درخواست‌های زیاد از <span dir="rtl">urllib3</span> است که <span dir="rtl">urllib3</span> محبوب‌ترین کتابخانه‌ی پایتون شخص ثالث <span dir="rtl">(third-party)</span> امروزی است.
   <p markdown="1" class="pquote-credit">
 — @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
   </p>
@@ -142,7 +142,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS برای اولین بار در ابتدای سال 2011 منتشر شد. ...من با روش‌های متداول، خبر را پخش کردم:  من راجع به آن توییت کردم، در مورد کارهایی که می‌توانید با آن انجام دهید در وبلاگ‌ پست‌هایی گذاشتم، در گردهمایی‌ها، در بحث‌های مختلف به آن اشاره کردم. وقتی در سال 2014 بیشتر شناخته شد، شروع به ارائه‌ی سخنرانی‌هایی در مورد آن کردم.
+  <span dir="rtl">PhantomJS</span> برای اولین بار در ابتدای سال 2011 منتشر شد. ...من با روش‌های متداول، خبر را پخش کردم:  من راجع به آن توییت کردم، در مورد کارهایی که می‌توانید با آن انجام دهید در وبلاگ‌ پست‌هایی گذاشتم، در گردهمایی‌ها، در بحث‌های مختلف به آن اشاره کردم. وقتی در سال 2014 بیشتر شناخته شد، شروع به ارائه‌ی سخنرانی‌هایی در مورد آن کردم.
   <p markdown="1" class="pquote-credit">
 — @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
   </p>
@@ -150,4 +150,4 @@ related:
 
 ## تسلیم نشوید!
 
-ممکن است مدت‌ها تا اینکه مردم متوجه پروژه‌ی اوپن سورس شما شوند طول بکشد. هیچ اشکالی نداره! برخی از محبوب‌ترین پروژه‌های امروزی، برای رسیدن به سطح بالایی از فعالیت، سال‌ها به طول انجامید. به جای اینکه امیدوار باشید پروژه‌ی شما به طور خود به خود محبوبیت پیدا کند، بر ایجاد روابط متمرکز شوید. صبور باشید و مدام کار خود را با کسانی که قدر آن را می‌دانند به اشتراک بگذارید.
+ممکن است مدت‌ها طول بکشد تا اینکه مردم متوجه پروژه‌ی اوپن سورس شما شوند. هیچ اشکالی نداره! برخی از محبوب‌ترین پروژه‌های امروزی، برای رسیدن به سطح بالایی از فعالیت، سال‌ها به طول انجامید. به جای اینکه امیدوار باشید پروژه‌ی شما به طور خود به خود محبوبیت پیدا کند، بر ایجاد روابط متمرکز شوید. صبور باشید و مدام کار خود را با کسانی که قدر آن را می‌دانند به اشتراک بگذارید.

From 614b700834d0a6351c087b416536ddd5f7dff2c1 Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Mon, 1 Nov 2021 12:41:02 +0330
Subject: [PATCH 279/749] update for more readability

Hi
changed for more readability
Good time :)
---
 _articles/fa/leadership-and-governance.md | 36 +++++++++++------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/_articles/fa/leadership-and-governance.md b/_articles/fa/leadership-and-governance.md
index 36c285aa8be..a7af7401368 100644
--- a/_articles/fa/leadership-and-governance.md
+++ b/_articles/fa/leadership-and-governance.md
@@ -24,15 +24,15 @@ related:
 * **مشارکت‌کننده (Contributor)**
 * **کامیت کننده (Committer)**
 
-**در برخی از پروژه‌ها، نگهدارندگان** تنها افرادی در پروژه هستند که دسترسی کامیت دارند. در برخی دیگر از پروژه‌ها، فقط افرادی دسترسی دارند که در «README» به عنوان نگهدارنده ذکر شده‌اند.
+**در برخی از پروژه‌ها، نگهدارندگان** تنها افرادی در پروژه هستند که دسترسی کامیت دارند. در برخی دیگر از پروژه‌ها، فقط افرادی دسترسی دارند که در <span dir="rtl">«README»</span> به عنوان نگهدارنده ذکر شده‌اند.
 
 نگهدارنده لزوماً کسی نیست که برای پروژه‌ی شما کد می‌نویسد. بلکه می‌تواند کسی باشد که در تبلیغ پروژه‌ی شما کارهای زیادی انجام داده باشد یا مستنداتی را نوشته باشد که پروژه را برای دیگران قابل دسترسی‌تر کرده است. صرف نظر از کاری که آن‌ها در طی روز انجام می‌دهند، نگهدارنده کسی است که نسبت به مسیر و اجرای پروژه احساس مسئولیت می‌کند و متعهد به بهبود بخشیدن آن است.
 
-**مشارکت‌کننده می‌تواند هر کسی باشد**: کسی که مسئله یا درخواست «Pull»ی را مطرح می‌کند، یا افرادی باشند که به پروژه ارزش می‌بخشند (خواه این که مسائل مربوط به اولویت‌بندی درخواست‌ها، نوشتن کد یا سازماندهی رویدادها باشد) یا هر کسی باشد که درخواست «pull»ی را ادغام (merge) بکند (جزئی‌ترین تعریف از مشارکت‌کننده)
+**مشارکت‌کننده می‌تواند هر کسی باشد**: کسی که مسئله یا درخواست <span dir="rtl">«Pull»</span>ی را مطرح می‌کند، یا افرادی باشند که به پروژه ارزش می‌بخشند (خواه این که مسائل مربوط به اولویت‌بندی درخواست‌ها، نوشتن کد یا سازماندهی رویدادها باشد) یا هر کسی باشد که درخواست <span dir="rtl">«Pull»</span>ی را ادغام <span dir="rtl">(merge)</span> بکند (جزئی‌ترین تعریف از مشارکت‌کننده)
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  \[در پروژه‌ی Node.js\]، هر شخصی که درباره یک موضوع اظهارنظر یا کدی را ارسال کند، عضوی از پروژه است. تنها دیدن نظرات یا ارسال کد به منزله‌ی عبور آن‌ها از فقط کاربر بودن به مشارکت‌کننده بودن است.
+  \[در پروژه‌ی <span dir="rtl">Node.js</span>\]، هر شخصی که درباره یک موضوع اظهارنظر یا کدی را ارسال کند، عضوی از پروژه است. تنها دیدن نظرات یا ارسال کد به منزله‌ی عبور آن‌ها از فقط کاربر بودن به مشارکت‌کننده بودن است.
   <p markdown="1" class="pquote-credit">
 — @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
   </p>
@@ -44,7 +44,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
-  ممکن است من را به عنوان سازنده‌ی «Django» بشناسید... اما در واقع من کسی هستم که یک سال بعد از ساخت «Django»، برای کار در بخشی از آن استخدام شدم. (...)مردم فکر می‌کنند به دلیل مهارت برنامه‌نویسی است که موفق شدم... اما در بهترین حالت می‌توان گفت که من یک برنامه‌نویس متوسط هستم.
+  ممکن است من را به عنوان سازنده‌ی <span dir="rtl">«Django»</span> بشناسید... اما در واقع من کسی هستم که یک سال بعد از ساخت <span dir="rtl">«Django»</span>، برای کار در بخشی از آن استخدام شدم. (...)مردم فکر می‌کنند به دلیل مهارت برنامه‌نویسی است که موفق شدم... اما در بهترین حالت می‌توان گفت که من یک برنامه‌نویس متوسط هستم.
   <p markdown="1" class="pquote-credit">
 — @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
   </p>
@@ -54,7 +54,7 @@ related:
 
 رسمیت بخشیدن به نقش‌های مدیریتی، باعث می‌شود افراد احساس مالکیت کنند و به اعضای سایر اجتماع‌ها بگویند برای کمک به چه کسانی روی آورند.
 
-در پروژه‌های کوچک‌تر، تعیین کردن مدیران می‌تواند به سادگی افزودن نام آن‌ها به فایل‌های «README» یا به یک فایل متنی «CONTRIBUTORS» باشد.
+در پروژه‌های کوچک‌تر، تعیین کردن مدیران می‌تواند به سادگی افزودن نام آن‌ها به فایل‌های <span dir="rtl">«README»</span> یا به یک فایل متنی <span dir="rtl">«CONTRIBUTORS»</span> باشد.
 
 برای پروژه‌های بزرگ‌تر، اگر وب‌سایتی دارید، یک صفحه‌ی تیمی ایجاد کنید یا اسامی مدیران پروژه را در آنجا لیست کنید. به عنوان مثال، [Postgres](https://github.com/postgres/postgres/) یک [صفحه‌ی تیمی جامع](https://www.postgresql.org/community/contributors/) و فراگیر با مشخصاتی کوتاه برای هر مشارکت‌کننده دارد.
 
@@ -67,13 +67,13 @@ related:
   </p>
 </aside>
 
-تیم‌های مدیریت، ممکن است بخواهند کانالی مشخص (مانند IRC) ایجاد کنند یا به طور منظم برای بحث درمورد پروژه با هم ملاقات کنند (مانند Gitter یا Google Hangout). حتی می‌توانید آن جلسات را علنی برگزار کنید تا سایر افراد بتوانند گوش دهند. به عنوان مثال، [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) همچین کاری می‌کند
+تیم‌های مدیریت، ممکن است بخواهند کانالی مشخص (مانند <span dir="rtl">IRC</span>) ایجاد کنند یا به طور منظم برای بحث درمورد پروژه با هم ملاقات کنند (مانند <span dir="rtl">Gitter</span> یا <span dir="rtl">Google Hangout</span>). حتی می‌توانید آن جلسات را علنی برگزار کنید تا سایر افراد بتوانند گوش دهند. به عنوان مثال، [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) همچین کاری می‌کند
 
-پس از اینکه نقش‌های مدیریتی را ایجاد کردید، ثبت چگونگی نحوه‌ی دسترسی افراد به آن‌ها را فراموش نکنید! فرآیند روشن و واضحی را برای چگونگی کسی که می‌خواهد نگهدارنده شود یا به کمیته‌ای فرعی در پروژه شما بپیوندد، ایجاد کنید و آن را در «GOVERNANCE.md» خود بنویسید.
+پس از اینکه نقش‌های مدیریتی را ایجاد کردید، ثبت چگونگی نحوه‌ی دسترسی افراد به آن‌ها را فراموش نکنید! فرآیند روشن و واضحی را برای چگونگی کسی که می‌خواهد نگهدارنده شود یا به کمیته‌ای فرعی در پروژه شما بپیوندد، ایجاد کنید و آن را در <span dir="rtl">«GOVERNANCE.md»</span> خود بنویسید.
 
 ابزارهایی مانند [Vossibility](https://github.com/icecrime/vossibility-stack)، می‌تواند به شما کمک کند تا به طور عمومی افرادی که در پروژه مشارکت می‌کنند (یا نمی‌کنند) را ردیابی کنید. ثبت این اطلاعات، جلوی این ذهنیت اجتماع که نگهدارندگان گروهی هستند که تصمیمات خود را به صورت خصوصی اتخاذ می‌کنند، می‌گیرد
 
-در آخر اینکه اگر پروژه‌ی شما در «GitHub» است، انتقال پروژه‌ی خود را از حساب شخصی خود به یک تشکل و اضافه کردن حداقل یک مدیر پشتیبان را مد نظر خود قرار دهید. [تشکل‌های «GitHub»](https://help.github.com/articles/creating-a-new-organization-account/)، مدیریت دسترسی‌ها و مراکز ذخیره‌سازی متعدد را آسان‌تر می‌کنند و پیشینه‌ی پروژه‌ی شما را از طریق [مالکیت مشترک](../building-community/#share-ownership-of-your-project) محافظت می‌کنند.
+در آخر اینکه اگر پروژه‌ی شما در <span dir="rtl">«GitHub»</span> است، انتقال پروژه‌ی خود را از حساب شخصی خود به یک تشکل و اضافه کردن حداقل یک مدیر پشتیبان را مد نظر خود قرار دهید. [تشکل‌های «GitHub»](https://help.github.com/articles/creating-a-new-organization-account/)، مدیریت دسترسی‌ها و مراکز ذخیره‌سازی متعدد را آسان‌تر می‌کنند و پیشینه‌ی پروژه‌ی شما را از طریق [مالکیت مشترک](../building-community/#share-ownership-of-your-project) محافظت می‌کنند.
 
 ## چه موقع باید به کسی اجازه‌ی دسترسی کامیت بدهیم؟
 
@@ -81,11 +81,11 @@ related:
 
 از طرف دیگر، به خصوص برای پروژه‌های بزرگتر و پیچیده‌تر، ممکن است بخواهید فقط به افرادی که تعهد خود را نشان داده و به اثبات رسانده‌اند، دسترسی کامیت بدهید. هیچ راه درستی برای انجام این کار وجود ندارد - هر جور که راحت‌تر هستید، عمل کنید!
 
-اگر پروژه‌ی شما در «GitHub» است، می توانید از شاخه‌های محافظت شده [protected branches](https://help.github.com/articles/about-protected-branches/) برای مدیریت افرادی که می‌توانند تحت شرایط خاصی در شاخه‌ای خاص عمل کنند، استفاده کنید
+اگر پروژه‌ی شما در <span dir="rtl">«GitHub»</span> است، می توانید از شاخه‌های محافظت شده [protected branches](https://help.github.com/articles/about-protected-branches/) برای مدیریت افرادی که می‌توانند تحت شرایط خاصی در شاخه‌ای خاص عمل کنند، استفاده کنید
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
-  هر زمان کسی درخواست «pull»ی را برای شما ارسال کرد، به او اجازه‌ی دسترسی کایمت به پروژه را بدهید. اگرچه ممکن است در ابتدا بسیار احمقانه به نظر برسد، اما استفاده از این استراتژی به شما این امکان را می‌دهد تا قدرت واقعی «GitHub» را تجربه کنید. (...)به محض دسترسی کامیت افراد، آن‌ها دیگر نگران این نیستند که «patch»هاشان ادغام نشود و باعث زحمت و کار زیادی برای آن‌ها شود.
+  هر زمان کسی درخواست <span dir="rtl">«Pull»</span>ی را برای شما ارسال کرد، به او اجازه‌ی دسترسی کامیت به پروژه را بدهید. اگرچه ممکن است در ابتدا بسیار احمقانه به نظر برسد، اما استفاده از این استراتژی به شما این امکان را می‌دهد تا قدرت واقعی <span dir="rtl">«GitHub»</span> را تجربه کنید. (...)به محض دسترسی کامیت افراد، آن‌ها دیگر نگران این نیستند که <span dir="rtl">«patch»</span>هاشان ادغام نشود و باعث زحمت و کار زیادی برای آن‌ها شود.
   <p markdown="1" class="pquote-credit">
 — @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
   </p>
@@ -95,15 +95,15 @@ related:
 
 سه ساختار نظارتی متداول در ارتباط با پروژه‌های متن باز وجود دارد.
 
-* **BDFL** مخفف "Benevolent Dictator for Life" یا «دیکتاتور خیرخواه جاویدان» است تحت این ساختار،  یک نفر (معمولاً نویسنده‌ی اولیه‌ی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را می‌زند. [Python](https://github.com/python)، نمونه‌ای موثق در این مورد است. پروژه‌های کوچک‌تر احتمالاً به طور پیش‌فرض به صورت «BDFL» هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژه‌هایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقه‌بندی «BDFL» قرار گیرند
+* **BDFL** مخفف <span dir="rtl">“Benevolent Dictator for Life”</span> یا «دیکتاتور خیرخواه جاویدان» است تحت این ساختار،  یک نفر (معمولاً نویسنده‌ی اولیه‌ی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را می‌زند. [Python](https://github.com/python)، نمونه‌ای موثق در این مورد است. پروژه‌های کوچک‌تر احتمالاً به طور پیش‌فرض به صورت <span dir="rtl">BDFL</span> هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژه‌هایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقه‌بندی <span dir="rtl">BDFL</span> قرار گیرند
 
 
-* **Meritocracy:** (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماع‌ها، مفهومی منفی دارد و ساختار آن [دارای پیشینه‌ی پیچیده‌ی اجتماعی و سیاسی](http://geekfeminism.wikia.com/wiki/Meritocracy).)است.) تحت ساختار «شایسته سالاری»، به مشارکت‌کنندگان فعال پروژه (کسانی که از «شایستگی» نشان می‌دهند) نقش تصمیم‌گیرندگی رسمی داده می‌شود. تصمیم‌‌ها، معمولاً براساس اجماع رای گرفته می‌شوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد «Apache»، به وجود آمد. تمامی پروژه‌های «Apache» بر اساس شایسته سالاری هستند. مشارکت‌ها فقط توسط افراد حقیقی صورت می‌گیرد؛ نه توسط یک شرکت.
+* **Meritocracy:** (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماع‌ها، مفهومی منفی دارد و ساختار آن [دارای پیشینه‌ی پیچیده‌ی اجتماعی و سیاسی](http://geekfeminism.wikia.com/wiki/Meritocracy).)است.) تحت ساختار «شایسته سالاری»، به مشارکت‌کنندگان فعال پروژه (کسانی که از خود «شایستگی» نشان می‌دهند) نقش تصمیم‌گیرندگی رسمی داده می‌شود. تصمیم‌‌ها، معمولاً براساس اجماع رای گرفته می‌شوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد <span dir="rtl">«Apache»</span>، به وجود آمد. تمامی پروژه‌های <span dir="rtl">«Apache»</span> بر اساس شایسته سالاری هستند. مشارکت‌ها فقط توسط افراد حقیقی صورت می‌گیرد؛ نه توسط یک شرکت.
 
 
 * **Liberal contribution:** (مشارکت آزادنه) تحت مدل مشارکت آزادانه، افرادی که بیشترین کار را انجام می‌دهند به عنوان تأثیرگذارترین افراد شناخته می‌شوند، اما این مدل براساس کاری که اکنون انجام می‌دهند است و نه مشارکت‌های که در گذشته داشته‌اند. تصمیمات بزرگ‌ پروژه بر اساس فرآیندی در اجتماع به صورت اجماعی (بحث‌ در مورد مسائل اساسی) به جای رأی‌گیری تنها گرفته می‌شود، و تلاش می‌شود تا آنجا که ممکن است دیدگاه‌های بیشتری از اجتماع را شامل شود. از جمله پروژه‌هایی که از مدل مشارکت آزادانه استفاده کردند، می‌توان [Node.js](https://foundation.nodejs.org/) و [Rust](https://www.rust-lang.org/) را نام برد.
 
-از کدام مدل بهتر است استفاده کنید؟ به خودتان بستگی دارد! هر مدل، شامل نکات منفی و مثبتی می‌شود. اگرچه ممکن است این مدل‌ها در ابتدا کاملاً متفاوت به نظر برسند؛ اما هر سه مدل، اشتراکات بیشتری از آنچه که به نظر می رسد دارند:
+از کدام مدل بهتر است استفاده کنید؟ به خودتان بستگی دارد! هر مدل، شامل نکات منفی و مثبتی می‌شود. اگرچه ممکن است این مدل‌ها در ابتدا کاملاً متفاوت به نظر برسند؛ اما هر سه مدل، بیشتری از آنچه که به نظر می رسد اشتراکاتی دارند:
 
 * [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
 * [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
@@ -119,7 +119,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
- ما تیم‌های کوچکی را برای مدیریت پروژه‌ها در «GitHub» اختصاص می‌دهیم که در واقع در فیس‌بوک نیز بر روی آن‌ها کار می‌کنند. برای مثال، پروژه‌ی «React» توسط «React engineer»، اداره می‌شود.
+ ما تیم‌های کوچکی را برای مدیریت پروژه‌ها در <span dir="rtl">«GitHub»</span> اختصاص می‌دهیم که در واقع در فیس‌بوک نیز بر روی آن‌ها کار می‌کنند. برای مثال، پروژه‌ی <span dir="rtl">«React»</span> توسط <span dir="rtl">«React engineer»</span>، اداره می‌شود.
   <p markdown="1" class="pquote-credit">
 — @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
   </p>
@@ -135,21 +135,21 @@ related:
 
 پروژه‌های «تجاری» هیچ فرقی با پروژه‌های «متن باز» ندارند. «تجاری» فقط به این معنی است که پول هم در کار است؛ به این معنی که نرم افزاری که در تجارت مورد استفاده قرار می‌گیرد، نرم‌افزاری در پروژه بوده است که در فعالیت تجاری پذیرفته شده است. (هنگامی که از یک نرم‌افزار «متن باز» به عنوان بخشی سازنده از محصولی «غیر متن باز» استفاده می‌شود، محصول نهایی همچنان نرم‌افزاری «دارای حقوق انحصاری» است، هرچند مانند «متن باز» ممکن است برای اهداف تجاری یا غیر تجاری استفاده شود.)
 
-مانند هر کس دیگری، توسعه‌دهندگانی که انگیزه‌های تجاری دارند از طریق کیفیت و کمیت مشارکت‌های خودشان است که در پروژه اهمیت می‌یابند و تاثیرگذار می‌شوند. بدیهی است که توسعه‌دهنده‌ای که برای کاری که می‌کند حقوق می‌گیرد، احتمالا بیشتر از شخصی که حقوق نمی‌گیرد، توانایی کار کردن دارد ولی اهمیتی ندارد: پرداخت حقوق فقط یکی از بسیار عامل‌های احتمالی است که می‌تواند بر میزان کاری که شخص می‌کند، تأثیر بگذارد. مشارکت‌ها رو معطوف به بحث‌های مربوط به پروژه بکنید، و نه معطوف به موضوعاتی خارج از پروژه.
+مانند هر کس دیگری، توسعه‌دهندگانی که انگیزه‌های تجاری دارند از طریق کیفیت و کمیت مشارکت‌های خودشان است که در پروژه اهمیت می‌یابند و تاثیرگذار می‌شوند. بدیهی است که توسعه‌دهنده‌ای که برای کاری که می‌کند حقوق می‌گیرد، احتمالا بیشتر از شخصی که حقوق نمی‌گیرد، توانایی کار کردن دارد ولی اهمیتی ندارد، پرداخت حقوق فقط یکی از بسیار عامل‌های احتمالی است که می‌تواند بر میزان کاری که شخص می‌کند، تأثیر بگذارد. مشارکت‌ها رو معطوف به بحث‌های مربوط به پروژه بکنید، و نه معطوف به موضوعاتی خارج از پروژه.
 
 ## آیا برای حمایت و پشتیبانی از پروژه‌ی خود به نهاد قانونی نیاز خواهم داشت؟
 
 شما برای پشتیبانی از پروژه‌ی متن باز خود احتیاج به نهاد قانونی نخواهید داشت، مگر اینکه با پول سر و کار داشته باشید.
 
-به عنوان مثال، اگر می‌خواهید کسب و کاری ایجاد کنید، باید از طریق «C Corp» یا «LLC» (اگر در ایالات متحده مستقر هستید) اقدام کنید. اگر فقط کارهای پیمانکاری مربوط به پروژه متن باز خود را انجام می‌دهید، می‌توانید به عنوان یک مالک شخصی پول را بپذیرید یا یک «LLC» (اگر در ایالات متحده مستقر هستید) ایجاد کنید.
+به عنوان مثال، اگر می‌خواهید کسب و کاری ایجاد کنید، باید از طریق <span dir="rtl">«C Corp»</span> یا <span dir="rtl">«LLC»</span> (اگر در ایالات متحده مستقر هستید) اقدام کنید. اگر فقط کارهای پیمانکاری مربوط به پروژه متن باز خود را انجام می‌دهید، می‌توانید به عنوان یک مالک شخصی پول را بپذیرید یا یک <span dir="rtl">«LLC»</span> (اگر در ایالات متحده مستقر هستید) ایجاد کنید.
 
-اگر می‌خواهید کمک‌های مالی برای پروژه‌ی متن باز خود بپذیرید، می‌توانید بستری را برای کمک‌های مالی (مثلاً با استفاده از PayPal یا Stripe) ایجاد کنید، اما این مبلغ مشمول کسر مالیت می‌شود، مگر اینکه به عنوان یک سازمان غیرانتفاعی واجد شرایط باشید (اگر در ایالات متحده مستقر هستید).
+اگر می‌خواهید کمک‌های مالی برای پروژه‌ی متن باز خود بپذیرید، می‌توانید بستری را برای کمک‌های مالی (مثلاً با استفاده از <span dir="rtl">PayPal</span> یا <span dir="rtl">Stripe</span>) ایجاد کنید، اما این مبلغ مشمول کسر مالیات می‌شود، مگر اینکه به عنوان یک سازمان غیرانتفاعی واجد شرایط باشید (اگر در ایالات متحده مستقر هستید).
 
 بسیاری از پروژه‌ها مایل به پذیرفتن مشکلات ناشی از ایجاد سازمانی غیرانتفاعی نیستند، بنابراین در عوض یک حامی مالی غیرانتفاعی پیدا می‌کنند. یک حامی مالی، معمولاً در ازای درصدی از کمک مالی، کمک‌های مالی را از طرف شما قبول می‌کند. [Software Freedom Conservancy](https://sfconservancy.org/)،[Apache Foundation](https://www.apache.org/) ،[Eclipse Foundation](https://eclipse.org/org/foundation/) ، [Linux Foundation](https://www.linuxfoundation.org/projects) و [Open Collective](https://opencollective.com/opensource)، نمونه‌هایی از سازمان‌ها هستند که به عنوان حامی‌های مالی در پروژه‌های متن باز فعالیت می‌کنند
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
-  هدف ما فراهم آوردن زیرساختی است که اجتماع‌هامان (communities) بتوانند از آن برای پایداری خود استفاده کنند، بنابراین محیطی ایجاد می‌کنیم که همه - مشارکت‌کنندگان، پشتیبانان، حامیان مالی - از مزایای آن بهره‌مند شوند
+  هدف ما فراهم آوردن زیرساختی است که اجتماع‌هامان <span dir="rtl">(communities)</span> بتوانند از آن برای پایداری خود استفاده کنند، بنابراین محیطی ایجاد می‌کنیم که همه - مشارکت‌کنندگان، پشتیبانان، حامیان مالی - از مزایای آن بهره‌مند شوند
   <p markdown="1" class="pquote-credit">
 — @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
   </p>

From 7f27acd6d65f4982826ac15f576f67c7979081c7 Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Mon, 1 Nov 2021 17:20:29 +0330
Subject: [PATCH 280/749] Change again :)

Hi
Change again for more readability
Good time :)
---
 _articles/fa/leadership-and-governance.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/leadership-and-governance.md b/_articles/fa/leadership-and-governance.md
index a7af7401368..fed5b70c73a 100644
--- a/_articles/fa/leadership-and-governance.md
+++ b/_articles/fa/leadership-and-governance.md
@@ -95,7 +95,7 @@ related:
 
 سه ساختار نظارتی متداول در ارتباط با پروژه‌های متن باز وجود دارد.
 
-* **BDFL** مخفف <span dir="rtl">“Benevolent Dictator for Life”</span> یا «دیکتاتور خیرخواه جاویدان» است تحت این ساختار،  یک نفر (معمولاً نویسنده‌ی اولیه‌ی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را می‌زند. [Python](https://github.com/python)، نمونه‌ای موثق در این مورد است. پروژه‌های کوچک‌تر احتمالاً به طور پیش‌فرض به صورت <span dir="rtl">BDFL</span> هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژه‌هایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقه‌بندی <span dir="rtl">BDFL</span> قرار گیرند
+* **BDFL** مخفف <span dir="rtl"> "Benevolent Dictator for Life" </span> یا «دیکتاتور خیرخواه جاویدان» است تحت این ساختار،  یک نفر (معمولاً نویسنده‌ی اولیه‌ی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را می‌زند. [Python](https://github.com/python)، نمونه‌ای موثق در این مورد است. پروژه‌های کوچک‌تر احتمالاً به طور پیش‌فرض به صورت <span dir="rtl">BDFL</span> هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژه‌هایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقه‌بندی <span dir="rtl">BDFL</span> قرار گیرند
 
 
 * **Meritocracy:** (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماع‌ها، مفهومی منفی دارد و ساختار آن [دارای پیشینه‌ی پیچیده‌ی اجتماعی و سیاسی](http://geekfeminism.wikia.com/wiki/Meritocracy).)است.) تحت ساختار «شایسته سالاری»، به مشارکت‌کنندگان فعال پروژه (کسانی که از خود «شایستگی» نشان می‌دهند) نقش تصمیم‌گیرندگی رسمی داده می‌شود. تصمیم‌‌ها، معمولاً براساس اجماع رای گرفته می‌شوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد <span dir="rtl">«Apache»</span>، به وجود آمد. تمامی پروژه‌های <span dir="rtl">«Apache»</span> بر اساس شایسته سالاری هستند. مشارکت‌ها فقط توسط افراد حقیقی صورت می‌گیرد؛ نه توسط یک شرکت.

From 55edc176bbc0fbc6c2fb0d532c80be03ceb79ea3 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 3 Nov 2021 09:07:29 +0000
Subject: [PATCH 281/749] Bump actions/checkout from 2.3.5 to 2.4.0

Bumps [actions/checkout](https://github.com/actions/checkout) from 2.3.5 to 2.4.0.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v2.3.5...v2.4.0)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 8916562e180..80d0830419c 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -8,7 +8,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
     - name: Set up Git repository
-      uses: actions/checkout@v2.3.5
+      uses: actions/checkout@v2.4.0
 
     - name: Set up Ruby
       uses: actions/setup-ruby@v1.1.3

From 484dc3b284d2cee5a25ef95c376cf7f8b1c1a558 Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Fri, 5 Nov 2021 08:17:57 +0330
Subject: [PATCH 282/749] direction: rtl for fa translation

hi
direction: rtl for fa translation
---
 assets/css/custom.scss | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/assets/css/custom.scss b/assets/css/custom.scss
index fac4472e7e1..ade4e3f7173 100644
--- a/assets/css/custom.scss
+++ b/assets/css/custom.scss
@@ -250,3 +250,9 @@ blockquote {
 .form-select {
   -webkit-appearance: none;
 }
+
+*:lang(fa) {
+ #content {
+   direction: rtl;
+  }
+}

From 945ef880922cd04587cd275b00ad3e5670fe5d20 Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Fri, 5 Nov 2021 08:47:53 +0330
Subject: [PATCH 283/749] re-edit

re-edit for rtl
---
 assets/css/custom.scss | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/assets/css/custom.scss b/assets/css/custom.scss
index ade4e3f7173..ddda68010b2 100644
--- a/assets/css/custom.scss
+++ b/assets/css/custom.scss
@@ -252,7 +252,9 @@ blockquote {
 }
 
 *:lang(fa) {
- #content {
+ .lead,
+  .lead-mktg ,
+  h2 + p + h3 {
    direction: rtl;
   }
 }

From eea1f2dfa067f7569b7d62cbdb95fc2d4af0930f Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Fri, 5 Nov 2021 09:21:29 +0330
Subject: [PATCH 284/749] re-edit text

re-edit text
---
 _articles/fa/best-practices.md | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md
index 3992c5c131b..4444ed1f1e6 100644
--- a/_articles/fa/best-practices.md
+++ b/_articles/fa/best-practices.md
@@ -12,7 +12,7 @@ related:
 
 ## نگهدارنده بودن به چه معناست؟
 
-اگر شما نگه‌دارنده‌ی پروژه‌ای اوپن سورس باشید که افراد زیادی از آن استفاده می‌کنند، حتما متوجه شده‌اید که کمتر مشغول به کدنویسی هستید و بیشتر نقش پاسخگویی به مشکلات را بر عهده‌ی خود دارید.
+اگر شما نگه‌دارنده‌ی پروژه‌ای اوپن سورس باشید که افراد زیادی از آن استفاده می‌کنند، حتما متوجه شده‌اید که کمتر مشغول به کدنویسی هستید و بیشتر نقش پاسخگویی به مشکلات را بر عهده دارید.
 
 در مراحل اولیه‌ی هر پروژه‌ای، شما ایده‌های جدیدی را امتحان می‌کنید و بر اساس آنچه می‌خواهید تصمیم‌گیری می‌کنید. با افزایش محبوبیت پروژه، متوجه می‌شوید که بیشتر مشغول کار با کاربران و همکاران خود خواهید بود.
 
@@ -105,7 +105,7 @@ related:
 
 مشارکت ناخواسته را صرف اینکه آدم خوبی به نظر برسید، ادامه ندهید زیرا در ادامه‌ی راه احساس گناه خواهید کرد. با گذشت زمان، مسائل و روابط عمومی بی‌پاسخ باعث می‌شود که کارتان روی پروژه بسیار استرس‌زا و ترسناک پیش برود. 
 
-بهتر است فوراً به مشارکت‌هایی که آن‌ها را نمی‌خواهید، پایان دهید. اکر پروژه شما از کمبود بک لاگ رنج می برد, @steveklabnik در مقاله [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) پیشنهاداتی در این خصوص ارائه کرده است.
+بهتر است فوراً به مشارکت‌هایی که آن‌ها را نمی‌خواهید، پایان دهید. اگر پروژه شما از کمبود بک لاگ رنج می برد, @steveklabnik در مقاله [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) پیشنهاداتی در این خصوص ارائه کرده است.
 
 ثانیاً، بی‌توجهی به مشارکت‌هایتان، سیگنال‌های منفی‌ای به درون اجتماع می‌فرستد. مشارکت در هر پروژه‌ای می‌تواند دلهره‌آور باشد، خصوصاً اگر برای اولین بار باشد که در پروژه‌ای شرکت می‌کنید. حتی اگر مشارکت آن‌ها را قبول نکردید، از آن شخص تشکر کرده و از توجه او سپاسگزار باشید. کار پسندیده‌ای است!
 
@@ -151,7 +151,7 @@ related:
 
 بعضی اوقات، وقتی نه می‌گویید، مشارکت‌کننده‌ی بالقوه ممکن است ناراحت شود یا از تصمیم شما انتقاد کند. اگر آن‌ها خصومت‌آمیز رفتار کردند و اگر نخواستند به طور سازنده همکاری کنند، [قدم‌هایی را برای خنثی کردن موقعیت](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) بردارید یا حتی آن‌ها را از اجتماع خودتان اخراج کنید.
 
-### با آعوش باز، پذیرای راهنمایی‌ و مشاوره باشید
+### با آغوش باز، پذیرای راهنمایی‌ و مشاوره باشید
 
 شاید کسانی در اجتماع شما باشند که مرتباً درخواست‌های مشارکتی پیشنهاد می‌کنند که با استانداردهای پروژه‌ی شما مطابقت نداشته باشد. مسلما رد شدن پیاپی برای هر دو طرف، طاقت‌فرساست.
 
@@ -187,7 +187,7 @@ related:
 
 > من یک صفحه‌ در ویکی نوشتم و آنچه را که می‌خواهم و چرایی آن را توصیف کردم. بنا به دلایلی برای من تعجب‌آور بود که نگهدارندگان شروع به انتقال پروژه به سمت و سوی دلخواه خود کردند! آیا آنطور که می‌خواستم، پیش رفت؟ نه همیشه. ولی پروژه را به آنچه که نوشته‌ بودم، نزدیک‌تر کرد.
 
-### به دیگران اجازه دهید تا راه‎‌حل‌های مورد نیاز خودشان را طراحی کنند
+### به دیگران اجازه دهید تا راه حل‌های مورد نیاز خودشان را طراحی کنند
 
 اگر فرد مشارکت‌کننده‌ای نظر دیگری در مورد کاری که پروژه باید انجام دهد داشته باشد، بهتر است که آن‌ها را با مهربانی تشویق به کار بر روی شاخه‌ی خودشان از پروژه بکنید.
 
@@ -211,9 +211,9 @@ related:
 
 ### برای بهبود کیفیت کدهای خود، از تست‌ها و دیگر ابزار استفاده کنید.
 
-یکی از مهم‌ترین راه‌ها برای اتوماتیک کردن پروژه‌ی خود، افزودن تست است.
-
-تست‌ها به مشارکت‌کنندگان کمک می‌کند تا اطمینان داشته باشند که چیزی را خراب نمی‎کنند. تست‌ها، همچنین بررسی و پذیرش سریع مشارکت‌ها را برای شما آسان می‌کند. هر چقدر از خود علاقه‌ی بیشتری نمایش دهید و مشتاق‌تر باشید، اجتماع شما مشارکت بیشتری خواهد داشت.
+یکی از مهم‌ترین راه‌ها برای اتوماتیک کردن پروژه‌ی خود،افزودن تست است.
+تست‌ها به مشارکت‌کنندگان کمک می‌کند تا اطمینان داشته باشند که چیزی را خراب نمی کنند. تست‌ها،همچنین بررسی و پذیرش سریع مشارکت‌ها را برای شما آسان می‌کند.
+هر چقدر از خود علاقه‌ی بیشتری نمایش دهید و مشتاق‌تر باشید،اجتماع شما مشارکت بیشتری خواهد داشت.
 
 تست‌های خودکاری را طراحی کنید که برای همه مشارکت‌های آتی اجرا شود و اطمینان حاصل کنید که تست‌های شما به راحتی توسط مشارکت‌کنندگان قابل اجرا باشند. قبول کردن درخواست‌های مشارکت در کدها را ملزم به قبول شدن در آن تست بکنید. با این کار، حداقل استاندارد کیفیتی را برای همه‌ی درخواست‌ها تعیین می‌کنید. [با بررسی وضعیت](https://help.github.com/articles/about-required-status-checks/) در GitHub می‌توانید اطمینان حاصل کنید که بدون گذراندن تست‌های شما اجازه‌ی هیچ گونه تغییری داده نمی‌شود.
 
@@ -221,7 +221,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <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)
   </p>
@@ -233,7 +233,7 @@ related:
 
 [ابزارهای متنوعی برای کمک](https://github.com/showcases/tools-for-open-source) به اتوماتیک کردن برخی جنبه‌های کار نگهداری وجود دارد. به عنوان مثال:
 
-* ابزار [emantic-release](https://github.com/semantic-release/semantic-release)، عرضه نسخه‌های جدید شما را اتوماتیک می‌کند.
+* ابزار [semantic-release](https://github.com/semantic-release/semantic-release)، عرضه نسخه‌های جدید شما را اتوماتیک می‌کند.
 * ابزار [mention-bot](https://github.com/facebook/mention-bot)، به بازبین‌های بالقوه برای «درخواست pull»ها خبر می دهد.
 * ابزار [Danger](https://github.com/danger/danger)، به بررسی و بازبینی اتوماتیک کد کمک می‌کند.
 * ابزار [no-response](https://github.com/probot/no-response)، مسائلی را که نویسنده به درخواست‌ها برای اطلاعات بیشتر پاسخ نداده است، می‌بندد.

From b7d8790dcd2b9653eb4cdef63971a3e532e402de Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Sun, 7 Nov 2021 11:28:47 +0330
Subject: [PATCH 285/749] edit css for Right to Left

hello
edit css for Right to Left
Good luck :)
---
 assets/css/custom.scss | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/assets/css/custom.scss b/assets/css/custom.scss
index ddda68010b2..2ac41717b44 100644
--- a/assets/css/custom.scss
+++ b/assets/css/custom.scss
@@ -252,9 +252,11 @@ blockquote {
 }
 
 *:lang(fa) {
+.article-body,
  .lead,
-  .lead-mktg ,
-  h2 + p + h3 {
-   direction: rtl;
+  h2,
+  p,
+  h3 {
+   direction: rtl;  /* Right to Left */
   }
 }

From 7047a2d6eaf0708a9f55da2f9c3c64eac147d4e8 Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Mon, 8 Nov 2021 14:36:16 +0000
Subject: [PATCH 286/749] Fix peerj link.

---
 _articles/building-community.md         | 2 +-
 _articles/de/building-community.md      | 2 +-
 _articles/es/building-community.md      | 2 +-
 _articles/fa/building-community.md      | 8 ++++----
 _articles/fr/building-community.md      | 2 +-
 _articles/hu/building-community.md      | 2 +-
 _articles/id/building-community.md      | 2 +-
 _articles/ja/building-community.md      | 2 +-
 _articles/ko/building-community.md      | 2 +-
 _articles/ms/building-community.md      | 2 +-
 _articles/nl/building-community.md      | 2 +-
 _articles/pl/building-community.md      | 2 +-
 _articles/pt/building-community.md      | 2 +-
 _articles/ro/building-community.md      | 2 +-
 _articles/ru/building-community.md      | 2 +-
 _articles/ta/building-community.md      | 2 +-
 _articles/tr/building-community.md      | 2 +-
 _articles/zh-hant/building-community.md | 2 +-
 18 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/_articles/building-community.md b/_articles/building-community.md
index c71d7356dc6..9f113f2c97c 100644
--- a/_articles/building-community.md
+++ b/_articles/building-community.md
@@ -169,7 +169,7 @@ See if you can find ways to share ownership with your community as much as possi
 
 * 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.
 
-The reality is that [most projects only have](https://peerj.com/preprints/1233.pdf) 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.
+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.
 
 While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help.
 
diff --git a/_articles/de/building-community.md b/_articles/de/building-community.md
index aed4d18f5a6..71365413249 100644
--- a/_articles/de/building-community.md
+++ b/_articles/de/building-community.md
@@ -189,7 +189,7 @@ Schauen Sie, ob Sie Wege finden können, Verantwortlichkeiten so weit wie mögli
 
 * 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.
 
-Realistischerweise haben [die meisten Projekte](https://peerj.com/preprints/1233.pdf) nur einen oder zwei Verantwortliche, welche die meiste Arbeit erledigen. Ja größer Ihr Projekt, und je größer seine Nutzer\*innengemeinschaft, desteo einfacher wird es sein, Hilfe zu finden.
+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, desteo einfacher wird es sein, Hilfe zu finden.
 
 Während Sie vielleicht nicht immer Leute finden, die einem Aufruf folgen, erhöht so ein Signals doch die Wahrscheinlichkeit, dass Andere mitmachen. Je früher Sie damit anfangen, desto eher können die Leute helfen.
 
diff --git a/_articles/es/building-community.md b/_articles/es/building-community.md
index a84128a2299..dfde0450769 100644
--- a/_articles/es/building-community.md
+++ b/_articles/es/building-community.md
@@ -170,7 +170,7 @@ Observa si puedes encontrar maneras de compartir la propiedad de tu comunidad ta
 
 * 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.
 
-La realidad es que [la mayor&iacute;a de los proyectos solo tienen](https://peerj.com/preprints/1233.pdf) 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.
+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.
 
 Aunque no siempre encuentres quien responda tu pedido, poner una se&ntilde;al por fuera incrementa las probabilidades de que otras personas se presenten. Y mientras m&aacute;s temprano comiences, m&aacute;s pronto las personas podr&aacute;n ayudar.
 
diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md
index 27aa282782e..852be587b0b 100644
--- a/_articles/fa/building-community.md
+++ b/_articles/fa/building-community.md
@@ -68,7 +68,7 @@ related:
 
 درباره نقشه مسیر پروژه تان ، انواع مشارکت هایی که شما در پی آنها هستید، اینکه چطور مشارکت ها بررسی می شوند یا اینکه چرا تصمیمات خاصی را اتخاذ می کنید ، شفاف سازی کنید.
 
-اگر شما کاربران متعددی را مطلع سازید تا مسئله مشابهی را بررسی کنند، جوابها را در <span dir="rtl">README</span> مستند سازید. 
+اگر شما کاربران متعددی را مطلع سازید تا مسئله مشابهی را بررسی کنند، جوابها را در <span dir="rtl">README</span> مستند سازید.
 
 برای جلسات، منتشر کردن یادداشت ها و نقشه های مسیر خود در یک موضوع مرتبط را مدنظر قرار دهید. بازخوردی که از این سطح از شفافیت کسب می کنید شاید شما را شگفت زده کند.
 
@@ -92,7 +92,7 @@ related:
 
 دو دلیل برای اعطای یک محل برای مشارکت در انجمن‌تان وجود دارد.
 
-اولین دلیل به خاطر مشارکت کنندگان است. به افراد کمک کنید تا همدیگر را بشناسند. افراد دارای منافع مشترک، بطور اجتناب ناپذیری می خواهند که محلی برای گفتگو درباره آن منافع داشته باشند و وقتی ارتباطات علنی و قابل دسترس باشد، هر کسی می تواند آرشیوهای گذشته را بخواند تا به مشارکت خود شتاب بخشد. 
+اولین دلیل به خاطر مشارکت کنندگان است. به افراد کمک کنید تا همدیگر را بشناسند. افراد دارای منافع مشترک، بطور اجتناب ناپذیری می خواهند که محلی برای گفتگو درباره آن منافع داشته باشند و وقتی ارتباطات علنی و قابل دسترس باشد، هر کسی می تواند آرشیوهای گذشته را بخواند تا به مشارکت خود شتاب بخشد.
 
 دلیل دوم به خاطر خود شما است. اگر شما به افراد محل عمومی برای صحبت درباره پروژه تان ندهید، آنها احتمالاً با شما مستقیماً تماس خواهند گرفت. در شروع، ظاهراً ساده است که به پیامهای خصوصی  با موضوع « فقط این بار»پاسخ دهید. اما در طول زمان مخصوصاً اگر پروژه تان معروف شود، شما کلافه خواهید شد. در برابر وسوسه ارتباط برقرار کردن با افراد درباره پروژه تان بطور خصوصی مقاومت کنید. در عوض آنها را به یک کانال عمومی معین هدایت کنید.
 
@@ -110,7 +110,7 @@ related:
 
 ### بازیگران بد را تحمل نکنید
 
-هر پروژه معروفی ناگزیر افرادی که ضرررسان هستند را نیز جذب خواهد کرد. آنها شاید بحثهای غیرضروری را شروع کنند، درباره ویژگی های جزئی خرده گیری کنند یا برای بقیه قلدری کنند. 
+هر پروژه معروفی ناگزیر افرادی که ضرررسان هستند را نیز جذب خواهد کرد. آنها شاید بحثهای غیرضروری را شروع کنند، درباره ویژگی های جزئی خرده گیری کنند یا برای بقیه قلدری کنند.
 
 شما به بهترین نحو تلاش کنید تا یک خطی مشی تحمل-صفر نسبت به این نوع افراد اقتباس کنید. اگر افراد منفی را چک نکنید ، افراد دیگر در جامعه تان را نیز ناراحت خواهند ساخت. آنها حتی شاید پروژه تان را ترک کنند.
 
@@ -170,7 +170,7 @@ related:
 
 * اگر پروژه تان روی گیت هاب است، **آن را از حساب شخصی خود به یک [سازمان](https://help.github.com/articles/creating-a-new-organization-account/) انتقال دهید** و حداقل یک ادمین پشتیبان به آن بیافزایید. سازمان ها کار کردن روی پروژه هایی با همکاران خارجی را آسانتر می سازند.
 
-واقعیت این است که [اکثر پروژه ها](https://peerj.com/preprints/1233.pdf) تنها دارای یک یا دو عضو هستند کسانی که اکثر کار را انجام می دهند. هرچه پروژه تان بزرگتر باشد، و هرچه انجمن تان بزرگتر باشد، دستیابی به کمک ساده تر خواهد بود.
+واقعیت این است که [اکثر پروژه ها](https://peerj.com/preprints/1233/) تنها دارای یک یا دو عضو هستند کسانی که اکثر کار را انجام می دهند. هرچه پروژه تان بزرگتر باشد، و هرچه انجمن تان بزرگتر باشد، دستیابی به کمک ساده تر خواهد بود.
 
 در حالی که شاید همیشه شخصی را برای جواب دادن به تماس ها نیابید، اما فرستادن سیگنالهایی به آنجا شانسی که افراد دیگر در پروژه همکاری بکنند را افزایش خواهد داد. و اینکه هرچه زودتر اقدام کنید، افراد زودتر می توانند به شما کمک کنند.
 
diff --git a/_articles/fr/building-community.md b/_articles/fr/building-community.md
index 546055b23fd..7626e8651a3 100644
--- a/_articles/fr/building-community.md
+++ b/_articles/fr/building-community.md
@@ -168,7 +168,7 @@ Voyez si vous pouvez trouver le moyen de partager la propriété avec votre comm
 
 * 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.
 
-La réalité est que [la plupart des projets ont seulement](https://peerj.com/preprints/1233.pdf) 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.
+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.
 
 Même s'il se peut que vous ne trouviez pas toujours quelqu'un pour répondre à l'appel, envoyer un signal augmente les chances que d'autres personnes interviennent. Plus tôt vous commencerez, plus tôt les gens pourront vous aider.
 
diff --git a/_articles/hu/building-community.md b/_articles/hu/building-community.md
index f2f1b02fbda..eaebc5a5eeb 100644
--- a/_articles/hu/building-community.md
+++ b/_articles/hu/building-community.md
@@ -169,7 +169,7 @@ Nézd meg, hogyan találhatod meg a módját, hogy a lehető legnagyobb mérték
 
 * 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.
 
-A valóságban [a legtöbb projektnek](https://peerj.com/preprints/1233.pdf) 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.
+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.
 
 Bár nem mindig válaszolnak a felhívásodra, de egy jelzés kiküldése növeli az esélyét, hogy valaki reagál majd rá. És minél előbb megteszed ezt, annál hamarabb segíthetnek az emberek.
 
diff --git a/_articles/id/building-community.md b/_articles/id/building-community.md
index 04e30777d32..aa6a0ec5c84 100644
--- a/_articles/id/building-community.md
+++ b/_articles/id/building-community.md
@@ -168,7 +168,7 @@ Cari cara untuk bisa berbagi kepemilikan dengan komunitas Anda sebanyak mungkin.
 
 * 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.
 
-Kenyataannya adalah [sebagian besar proyek hanya memiliki](https://peerj.com/preprints/1233.pdf) satu atau dua pengeloa yang melakukan sebagian besar pekerjaan. Semakin besar proyek Anda, dan semakin besar komunitas Anda, semakin mudah untuk menemukan bantuan.
+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.
 
 Meskipun tidak selalu mudah untuk mendapatkan orang yang memenuhi panggilan Anda, memberikan sinyal akan meningkatkan peluang dimana orang lain akan ikut terlibat. Dan semakin cepat Anda melakukannya, semakin cepat pula orang akan datang membantu.
 
diff --git a/_articles/ja/building-community.md b/_articles/ja/building-community.md
index 57957e7df38..a48da3edb85 100644
--- a/_articles/ja/building-community.md
+++ b/_articles/ja/building-community.md
@@ -168,7 +168,7 @@ CONTRIBUTING ファイルに、新しいコントリビューターに始め方
 
 * もしプロジェクトが GitHub 上にあるのであれば、 **プロジェクトをあなた個人のアカウントから [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** に移し、最低でも一人代わりの管理者を追加しましょう。 Organization によって外部の協力者と一緒にプロジェクト上での作業をしやすくなります。
 
-実際のところ、[ほとんどのプロジェクトはたった](https://peerj.com/preprints/1233.pdf) 一人か二人のメンテナーしかおらず、彼らがほとんどの作業を行っています。プロジェクトやコミュニティが大きくなるほど、協力者を見つけるのがより簡単になります。
+実際のところ、[ほとんどのプロジェクトはたった](https://peerj.com/preprints/1233/) 一人か二人のメンテナーしかおらず、彼らがほとんどの作業を行っています。プロジェクトやコミュニティが大きくなるほど、協力者を見つけるのがより簡単になります。
 
 常に要求に応じてくれる人が見つかるとは限りませんが、そういったシグナルを出しておくことで、協力してくれる人が出てくるチャンスが増えます。そしてより早く始めると、より早く人々が助けてくれるでしょう。
 
diff --git a/_articles/ko/building-community.md b/_articles/ko/building-community.md
index 02fe65a80d1..669254a27e9 100644
--- a/_articles/ko/building-community.md
+++ b/_articles/ko/building-community.md
@@ -169,7 +169,7 @@ CONTRIBUTING 파일에 새 기여자들이 시작할 방법을 자세히 설명
 
 * 여러분의 프로젝트가 GitHub에서 진행되고 있다면 **프로젝트를 개인 계정에서 [조직 계정](https://help.github.com/articles/creating-a-new-organization-account/)으로 옮기고** 예비 관리자를 등록하세요. 조직 계정을 활용하면 외부의 협력자들과 함께 일하기 더 쉽습니다.
 
-현실에서 [대부분의 프로젝트](https://peerj.com/preprints/1233.pdf)는 한두 명의 관리자가 거의 모든 일을 담당합니다. 여러분의 프로젝트와 커뮤니티가 성장할수록 위 방법이 도움을 구하기 좋습니다.
+현실에서 [대부분의 프로젝트](https://peerj.com/preprints/1233/)는 한두 명의 관리자가 거의 모든 일을 담당합니다. 여러분의 프로젝트와 커뮤니티가 성장할수록 위 방법이 도움을 구하기 좋습니다.
 
 항상 도움을 줄 수 있는 사람을 찾을 수 있는 것은 아니지만, 신호를 보내는 것은 그럴 확률을 높입니다. 여러분이 일찍 시작할수록 사람들은 더 빨리 도울 수 있습니다.
 
diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
index eb6dc37e4ef..4abeb4db33e 100644
--- a/_articles/ms/building-community.md
+++ b/_articles/ms/building-community.md
@@ -169,7 +169,7 @@ Lihat apakah anda boleh mencari cara untuk berkongsi pemilikan dengan komuniti a
 
 * 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.
 
-Kenyataannya adalah bahawa[most projects only have](https://peerj.com/preprints/1233.pdf)satu atau dua penyelenggara yang melakukan sebahagian besar kerja. Semakin besar projek anda, dan semakin besar komuniti anda, semakin mudah mendapatkan bantuan.
+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.
 
 Walaupun anda mungkin tidak selalu menjumpai seseorang untuk menjawab panggilan tersebut, memberi isyarat di luar sana akan meningkatkan kemungkinan orang lain akan masuk. Dan lebih awal anda memulakannya, semakin cepat orang dapat membantu.
 
diff --git a/_articles/nl/building-community.md b/_articles/nl/building-community.md
index f4e5363c56d..aec4c76ea6b 100644
--- a/_articles/nl/building-community.md
+++ b/_articles/nl/building-community.md
@@ -181,7 +181,7 @@ Kijk of je manieren kunt vinden om het eigendom zoveel mogelijk met je gemeensch
 * 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.
 
 De realiteit is dat bij [de meeste projecten]
-(https://peerj.com/preprints/1233.pdf) 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.
+(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.
 
 Hoewel je misschien niet altijd iemand vindt om de oproep te beantwoorden, vergroot het geven van een signaal de kans dat andere mensen meedoen. En hoe eerder je begint, hoe eerder mensen kunnen helpen.
 
diff --git a/_articles/pl/building-community.md b/_articles/pl/building-community.md
index 743d5618be9..3f0001c15f0 100644
--- a/_articles/pl/building-community.md
+++ b/_articles/pl/building-community.md
@@ -177,7 +177,7 @@ Sprawdź, czy możesz w jak największym stopniu znaleźć sposób na dzielenie
 
 * 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.
 
-Rzeczywistość jest taka, że [większość projektów ma tylko](https://peerj.com/preprints/1233.pdf) 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.
+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.
 
 Chociaż nie zawsze możesz znaleźć kogoś, kto odbierze połączenie, wysłanie sygnału zwiększa szanse na pojawienie się innych osób. Im wcześniej zaczniesz, tym szybciej ludzie mogą pomóc.
 
diff --git a/_articles/pt/building-community.md b/_articles/pt/building-community.md
index d7c706f7ed6..c2d8bff939d 100644
--- a/_articles/pt/building-community.md
+++ b/_articles/pt/building-community.md
@@ -166,7 +166,7 @@ Procure encontrar maneiras de compartilhar a propriedade com a sua comunidade o
 
 * 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.
 
-A verdade é que [a maioria dos projetos tem somente](https://peerj.com/preprints/1233.pdf) 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.
+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.
 
 Muito embora nem sempre você encontre alguém para responder ao chamado, colocar um aviso em algum lugar aumenta a chance de que outras pessoas contribuam. E quanto antes você começar, mais cedo as pessoas poderão ajudar.
 
diff --git a/_articles/ro/building-community.md b/_articles/ro/building-community.md
index 5be062cf3ab..91bae141fb6 100644
--- a/_articles/ro/building-community.md
+++ b/_articles/ro/building-community.md
@@ -200,7 +200,7 @@ Vezi dacă poți găsi moduri de a împărți proprietatea cu comunitatea ta câ
 
 * 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.
 
-Realitatea este că [cele mai multe proiecte au doar](https://peerj.com/preprints/1233.pdf) 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.
+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.
 
 În timp ce poate tu nu găsești întotdeauna pe cineva să răspundă la apel, punând un semnal acolo crește șansele ca alți oameni să intre pe teren. Și cu cât începi mai devreme, cu atât mai devreme oamenii pot ajuta.
 
diff --git a/_articles/ru/building-community.md b/_articles/ru/building-community.md
index 1fa3b4123d4..ed08148b710 100644
--- a/_articles/ru/building-community.md
+++ b/_articles/ru/building-community.md
@@ -169,7 +169,7 @@ related:
 
 * Если ваш проект размещен на GitHub, **переместите его из своей личной учетной записи в [Организацию](https://help.github.com/articles/creating-a-new-organization-account/)** и добавьте хотя бы одного администратора резервного копирования. Организации упрощают работу над проектами с внешними соавторами.
 
-Реальность такова, что [в большинстве проектов есть](https://peerj.com/preprints/1233.pdf) один или два сопровождающих, которые делают большую часть работы. Чем крупнее ваш проект и чем больше ваше сообщество, тем легче найти помощь.
+Реальность такова, что [в большинстве проектов есть](https://peerj.com/preprints/1233/) один или два сопровождающих, которые делают большую часть работы. Чем крупнее ваш проект и чем больше ваше сообщество, тем легче найти помощь.
 
 Хотя вы не всегда можете найти кого-то, кто ответит на призыв, подача сигнала увеличивает шансы, что другие люди вмешаются. И чем раньше вы начнете, тем скорее люди смогут помочь.
 
diff --git a/_articles/ta/building-community.md b/_articles/ta/building-community.md
index 3cf7b27a710..d402badbf53 100644
--- a/_articles/ta/building-community.md
+++ b/_articles/ta/building-community.md
@@ -168,7 +168,7 @@ related:
 
 * உங்கள் திட்டம் கிட்ஹப் இல் இருந்தால், **உங்கள் திட்டத்தை உங்கள் தனிப்பட்ட கணக்கிலிருந்து ஒரு [அமைப்பாக](https://help.github.com/articles/creating-a-new-organization-account/)** மாற்றவும் மற்றும் குறைந்தது ஒரு காப்பு நிர்வாகியை சேர்க்கவும். வெளிப்புற ஒத்துழைப்பாளர்களுடன் திட்டங்களில் வேலை செய்வதை நிறுவனங்கள் எளிதாக்குகின்றன.
 
-உண்மை என்னவென்றால், [பெரும்பாலான திட்டங்களுக்கு](https://peerj.com/preprints/1233.pdf) பெரும்பாலான வேலைகள் செய்யக்கூடிய ஒன்று அல்லது இரண்டு பராமரிப்பாளர்கள் இருப்பர். பெரிய திட்டம், மற்றும் உங்கள் சமூகம் பெரியதாக இருப்பின், எளிதாக உதவியை கண்டுபிடிக்க முடியும்.
+உண்மை என்னவென்றால், [பெரும்பாலான திட்டங்களுக்கு](https://peerj.com/preprints/1233/) பெரும்பாலான வேலைகள் செய்யக்கூடிய ஒன்று அல்லது இரண்டு பராமரிப்பாளர்கள் இருப்பர். பெரிய திட்டம், மற்றும் உங்கள் சமூகம் பெரியதாக இருப்பின், எளிதாக உதவியை கண்டுபிடிக்க முடியும்.
 
 அழைப்பிற்கு பதில் தெரிவிக்க யாரும் இல்லை என்றாலும், ஒரு சமிக்ஞையைத் தட்டினால், மற்றவர்கள் அதில் கலந்துகொள்ளும் வாய்ப்புகளை அதிகரிக்கிறது. எவ்வளவு முந்தி நீங்கள் ஆரம்பிக்கிறீர்களோ, விரைவில் மக்களால் உதவ முடியும்.
 
diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md
index 1addd0dc400..5b300567650 100644
--- a/_articles/tr/building-community.md
+++ b/_articles/tr/building-community.md
@@ -169,7 +169,7 @@ Mülkiyetinizi topluluğunuzla mümkün olduğunca paylaşmanın yollarını bul
 
 * 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.
 
-Gerçek şu ki çoğu projede işlerin çoğunu yapan [yalnızca](https://peerj.com/preprints/1233.pdf) 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.
+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.
 
 Çağrıya her zaman cevap verecek birini bulamayacak olsanız da, bir mesaj bırakmak, diğer kişilerin girme şansını arttırır.
 
diff --git a/_articles/zh-hant/building-community.md b/_articles/zh-hant/building-community.md
index 5d1e4f504d7..b191800b253 100644
--- a/_articles/zh-hant/building-community.md
+++ b/_articles/zh-hant/building-community.md
@@ -170,7 +170,7 @@ redirect_from: /zh-tw/building-community/
 
 * 如果專案是放在 GitHub 上，那麼 **將專案從你們的個人賬號轉移到一個[組織](https://help.github.com/articles/collaborating-with-groups-in-organizations/)**，加入至少一個備份管理員。組織能讓社群與來自外界的貢獻，彼此協作的工作變得更加容易。
 
-事實上很多專案[只有一個或者兩個維護者](https://peerj.com/preprints/1233.pdf)去做大部分的工作。隨著社群變得越來越大，就會有更多的人參與進來。
+事實上很多專案[只有一個或者兩個維護者](https://peerj.com/preprints/1233/)去做大部分的工作。隨著社群變得越來越大，就會有更多的人參與進來。
 
 雖然並不是一直都有人在回答問題，但是你可以去試著增加一些機會，讓他人有能夠參與的機會，越是儘早開始，越是能夠獲得幫助。
 

From 1652746bf22d6986d976d5e8a5ccd3e0f51be885 Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Fri, 12 Nov 2021 12:02:38 +0330
Subject: [PATCH 287/749] Edited fa/metrics.md

Hi
Edited metrics.md
good luck  :)
---
 _articles/fa/metrics.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/fa/metrics.md b/_articles/fa/metrics.md
index e00f8661e86..ea7c2da1f25 100644
--- a/_articles/fa/metrics.md
+++ b/_articles/fa/metrics.md
@@ -49,7 +49,7 @@ related:
 
 قسمت [GitHub stars](https://help.github.com/articles/about-stars/) هم می‌تواند به صورت معیاری برای محبوبیت عمل کند.اگرچه «GitHub stars» لزوماً با تعداد دانلودها و استفاده از محتوا ارتباط مستقیمی ندارد، اما این قسمت می‌تواند به شما بگوید که چه تعدادی از آدم‌ها متوجه پروژۀ شما شده‌اند..
 
-همچنین شاید بخواهید قابلیت کشف شدن (شناخته‌ شدن) را در [بخش‌های مشخصی ردیابی کنید](https://opensource.com/business/16/6/pirate-metrics): به عنوان مثال، «Google PageRank»، ترافیک رجوعی به وب‌سایت پروژۀ شما، یا مراجعات از سایر پروژه‌های متنباز یا سایر وب‌سایت‌ها.
+همچنین شاید بخواهید قابلیت کشف شدن (شناخته‌ شدن) را در [بخش‌های مشخصی ردیابی کنید](https://opensource.com/business/16/6/pirate-metrics): به عنوان مثال، «Google PageRank»، ترافیک رجوعی به وب‌سایت پروژۀ شما، یا مراجعات از سایر پروژه‌های متن‌باز یا سایر وب‌سایت‌ها.
 
 ## استفاده
 
@@ -78,7 +78,7 @@ related:
 
 مردم پروژۀ شما را پیدا می‌کنند و از آن استفاده می‌کنند. سوالی که باید از خودتان بپرسید این است که: _آیا مردم در آن مشارکت هم می‌کنند یا خیر؟_
 
-هیچ‌وقت برای فکر کردن به مشارکت‌کنندگان دیر نیست. اگر پروژۀ شما محبوب باشد (بسیاری از از آن استفاده کنند) و سایر افراد دست به کار نشوند و از آن _پشتیبانی نکنند_ خود را در موقعیتی ناسالم قرار می‌دهید (به اندازۀ کافی نگهدارنده نداشته باشید).
+هیچ‌وقت برای فکر کردن به مشارکت‌کنندگان دیر نیست. اگر پروژۀ شما محبوب باشد (بسیاری از آن استفاده کنند) و سایر افراد دست به کار نشوند و از آن _پشتیبانی نکنند_ خود را در موقعیتی ناسالم قرار می‌دهید (به اندازۀ کافی نگهدارنده نداشته باشید).
 
 نگهداری، مستلزم [ورود مشارکت‌کنندگان جدید](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2) است، زیرا مشارکت‌کنندگان فعال قبلی در نهایت به سراغ کارهای دیگر می‌روند.
 

From c966e4e97a5a88fab293c8514e0e3f152e78ae77 Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Sat, 13 Nov 2021 10:36:21 +0330
Subject: [PATCH 288/749] Edit for more readability

Hi
Edit for more readability.
Good luck
---
 _articles/fa/legal.md | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index 7cd3a53f2e8..d8953ad1c46 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -18,7 +18,7 @@ related:
 
 به طور کلی، به این معنی است که هیچ کس دیگری نمی‌تواند از اثر شما استفاده کند، کپی کند، پخش کند یا اصلاحاتی روی آن انجام دهد؛ بدون اینکه در معرض ریسک دعوی قضایی و پیگیری قرار بگیرد.
 
-هرچند پروژه‌های متن باز شرایطی غیرمعمول دارند، زیرا خالق اثر انتظار دارد که دیگران از اثر استفاده کنند و آن را اصلاح نمایند و به اشتراک بگذارند. اما از آنجا که پیش‌فرض قانونی همچنان شامل حقق نشر می‌شود، شما به مجوزی نیاز دارید که صریحاً این دسترسی‌ها را میسر سازد.
+هرچند پروژه‌های متن باز شرایطی غیرمعمول دارند، زیرا خالق اثر انتظار دارد که دیگران از اثر استفاده کنند و آن را اصلاح نمایند و به اشتراک بگذارند. اما از آنجا که پیش‌فرض قانونی همچنان شامل حق نشر می‌شود، شما به مجوزی نیاز دارید که صریحاً این دسترسی‌ها را میسر سازد.
 
 اگر مجوز (لایسنس) مربوط به پروژه‌های متن باز را اعمال نکنید، همه کسانی که در پروژۀ شما مشارکت می‌کنند نیز به عنوان دارندۀ حق نشر برای کارهای منحصر به فرد خود شناخته می‌شوند. این بدان معناست که هیچ کس نمی‌تواند از مشارکت‌های خود استفاده یا کپی کند و آن را توزیع یا اصلاح نماید و این «هیچ کس» شامل شما هم می‌شود.
 
@@ -58,7 +58,7 @@ related:
 
 پروژۀ شما به احتمال زیاد **وابستگی‌ها** و مولفه‌های فراوانی داشته باشد (یا خواهد داشت). به عنوان مثال، اگر در پروژۀ متن باز خود از «Node.js» استفاده می‌کنید، احتمالاً از کتابخانه‌های Node Package Manager (npm) (مدیریت پکیج Node) استفاده خواهید کرد. هر کدام از این کتابخانه‌هایی که به آن‌ها وابسته هستید، مجوز (لایسنس، پروانه) متن باز مخصوص به خود را دارند. اگر هر یک از مجوزهای آن‌ها «اختیاری» باشد (بدون هیچ گونه شرطی برای فعالیت‌های آینده، اجازۀ استفاده، اصلاح، تغییر و اشتراک‌گذاری را به عموم مردم می‌دهد)، می‌توانید از هر مجوزی که می‌خواهید استفاده کنید. مجوزهای اختیاری متداول شامل «MIT»، «Apache 2.0»، «ISC» و «BSD» می‌شوند.
 
-از طرف دیگر، اگر هر یک از مجوزهای وابستگی شما، «کپی‌لفت قوی» باشند (مشروط به استفاده از همان مجوز در آینده، مجوزهای عمومی مشابهی را می‌دهد)، در این صورت پروژۀ شما باید از همان مجوز استفاده کند. مجوزهای متداول کپی‌لفت ((Copyleft (تعریف: کپی‌لفت نوعی بازی با کلمهٔ کپی‌رایت است. کپی‌لفت عملی را توصیف می‌کند که در آن تضمین می‌شود که اجازهٔ نسخه‌برداری و ویرایش یک اثر برای همگان محفوظ می‌مانَد و هیچ شخصی اجازه ندارد حق ویرایش و نسخه‌برداری را از دیگر افراد سلب کند.) قوی شامل «GPLv2»، «GPLv3»  و «AGPLv3» می‌شوند.
+از طرف دیگر، اگر هر یک از مجوزهای وابستگی شما، «کپی‌لفت قوی» باشند (مشروط به استفاده از همان مجوز در آینده، مجوزهای عمومی مشابهی را می‌دهد)، در این صورت پروژۀ شما باید از همان مجوز استفاده کند. مجوزهای متداول کپی‌لفت قوی شامل  «GPLv2»، «GPLv3»  و «AGPLv3» می‌شوند. (تعریف Copyleft : کپی‌لفت نوعی بازی با کلمهٔ کپی‌رایت است. کپی‌لفت عملی را توصیف می‌کند که در آن تضمین می‌شود که اجازهٔ نسخه‌برداری و ویرایش یک اثر برای همگان محفوظ می‌مانَد و هیچ شخصی اجازه ندارد حق ویرایش و نسخه‌برداری را از دیگر افراد سلب کند.)
 
 همچنین ممکن است بخواهید **انجمن‌هایی** را در نظر بگیرید که امیدوار هستید از پروژۀ شما استفاده کنند و در آن مشارکت کنند:
 
@@ -80,9 +80,9 @@ related:
 
 **کاری پیچیده است.** تعیین سازگاری و انطباق مجوز و حق نشر می تواند خیلی زود پیچیده و گیج‌کننده شود. تغییر مجوز به مجوزی جدید و سازگار برای نسخه‌های جدید و مشارکت‌ها با تغییر مجوز تمامی مشارکت‌های موجود، تفاوت‌هایی دارد. در اولین قدم، در صورت تمایل به تغییر مجوزها، تیم حقوقی شما درگیر می‌شود. حتی اگر برای تغییر مجوز از دارندگان حق نشر پروژه خود اجازه دارید یا می‌توانید از آن‌ها اجازه بگیرید، تأثیر این تغییر را بر سایر کاربران و مشارکت‌کنندگان پروژۀ خود در نظر داشته باشید. تغییر مجوز را به صورت یک «رویداد مدیریتی» برای پروژۀ خود تصور کنید که به احتمال زیاد با برقراری ارتباط صریح و مشورت با ذی‌نفعان پروژه، هموارتر پیش خواهد رفت. بنابراین بهتر است از بدو تأسیس، مجوزی مناسب را برای پروژۀ خودتان انتخاب کنید!
 
-**مجوز موجود و فعلی پروژه‌تان.** در صورتی که مجوز کنونی پروژۀ شما با مجوزی که می‌خواهید به آن تغییر دهید سازگار باشد، می‌توانید از مجوز جدید استفاده کنید. به این دلیل که اگر مجوز A با مجوز B سازگار باشد، در حالی که با شرایط B مطابقت دارید، با شرایط A نیز منطبق خواهید بود (اما لزوما برعکس آن درست نیست). بنابراین اگر در حال حاضر از مجوزی اختیاری استفاده می‌کنید (به عنوان مثال، «MIT»)، می‌توانید به مجوزی با شرایط بیشتری تغییر مجوز دهید، به شرطی که نسخه‌ای از مجوز «MIT» و هرگونه شرط حق نشر دیگۀ مربوط به آن را حفظ کنید (یعنی همچنان با حداقل شرایط مجوز «MIT» سازگار باشید). اما اگر مجوز فعلی شما اختیاری نباشد (به عنوان مثال کپی‌لفت باشد یا مجوزی نداشته باشید) و تنها دارندۀ حق نشر نیستید، نمی‌توانید مجوز پروژۀ خود را به «MIT» تغییر دهید. اساساً، صاحبان حق نشر پروژه با داشتن مجوز اختیاری از قبل اجازۀ تغییر مجوزها را داده‌اند.
+**مجوز موجود و فعلی پروژه‌تان.** در صورتی که مجوز کنونی پروژۀ شما با مجوزی که می‌خواهید به آن تغییر دهید سازگار باشد، می‌توانید از مجوز جدید استفاده کنید. به این دلیل که اگر مجوز A با مجوز B سازگار باشد، در حالی که با شرایط B مطابقت دارید، با شرایط A نیز منطبق خواهید بود (اما لزوما برعکس آن درست نیست). بنابراین اگر در حال حاضر از مجوزی اختیاری استفاده می‌کنید (به عنوان مثال، «MIT»)، می‌توانید به مجوزی با شرایط بیشتری تغییر مجوز دهید، به شرطی که نسخه‌ای از مجوز «MIT» و هرگونه شرط حق نشر دیگری مربوط به آن را حفظ کنید (یعنی همچنان با حداقل شرایط مجوز «MIT» سازگار باشید). اما اگر مجوز فعلی شما اختیاری نباشد (به عنوان مثال کپی‌لفت باشد یا مجوزی نداشته باشید) و تنها دارندۀ حق نشر نیستید، نمی‌توانید مجوز پروژۀ خود را به «MIT» تغییر دهید. اساساً، صاحبان حق نشر پروژه با داشتن مجوز اختیاری از قبل اجازۀ تغییر مجوزها را داده‌اند.
 
-**صاحبان کنونی حق‌نشر پروژه‌تان.** اگر تنها مشارکت‌کننده در پروژه‌تان هستید، شما یا شرکت شما تنها صاحبان حق‌نشر این پروژه خواهید بود. خودتان یا شرکت می‌توانید، مجوز را تغییر دهید یا مجوز جدیدی اضافه کنید. در غیر این صورت ممکن است باید قبل از تغییر مجوز، با دیگر صاحبان حق‌نشر به توافق برسید. آن‌ها چه کسانی هستند؟ افرادی که در متعهد به پروژه هستند، نفطۀ خوبی برای شروع است. اما در برخی موارد حق‌نشر توسط افراد بالادستی این افراد حفظ می‌شود. در برخی موارد افراد مشارکت کم و حداقلی داشته‌اند، اما هیچ قانون سخت و جدی وجود ندارد که بگوید افرادی که مشارکتی در برخی از خطوط کد داشته‌اند مشمول حق‌نشر نباشد. چه کار باید کرد؟ بستگی دارد. برای پروژه‌ای نسبتاً کوچک و تازه‌شکل گرفته، ممکن است امکان‌پذیر باشد که همۀ مشارکت‌کنندگان موجود با تغییر مجوز در طرح مسئله‌ای یا در درخواست pullی موافقت کنند. برای پروژه‌های بزرگ و قدیمی، ممکن است برای مثلا تغییر مجوز مجبور شوید به جستجوی بسیاری از مشارکت‌کنندگان و حتی ورثه‌های آن‌ها مشغول شوید. موزیلا سال‌ها به طول انجامید (2001 تا 2006) تا مجوز «Firefox»، «Thunderbird» و دیگر نرم‌افزارهای مربوطه را تغییر دهد.
+**صاحبان کنونی حق‌نشر پروژه‌تان.** اگر تنها مشارکت‌کننده در پروژه‌تان هستید، شما یا شرکت شما تنها صاحبان حق‌نشر این پروژه خواهید بود. خودتان یا شرکت می‌توانید، مجوز را تغییر دهید یا مجوز جدیدی اضافه کنید. در غیر این صورت ممکن است باید قبل از تغییر مجوز، با دیگر صاحبان حق‌نشر به توافق برسید. آن‌ها چه کسانی هستند؟ افرادی که متعهد به پروژه هستند، نقطۀ خوبی برای شروع است. اما در برخی موارد حق‌نشر توسط افراد بالادستی این افراد حفظ می‌شود. در برخی موارد افراد مشارکت کم و حداقلی داشته‌اند، اما هیچ قانون سخت و جدی وجود ندارد که بگوید افرادی که مشارکتی در برخی از خطوط کد داشته‌اند مشمول حق‌نشر نباشد. چه کار باید کرد؟ بستگی دارد. برای پروژه‌ای نسبتاً کوچک و تازه‌شکل گرفته، ممکن است امکان‌پذیر باشد که همۀ مشارکت‌کنندگان موجود با تغییر مجوز در طرح مسئله‌ای یا در درخواست pullی موافقت کنند. برای پروژه‌های بزرگ و قدیمی، ممکن است برای مثلا تغییر مجوز مجبور شوید به جستجوی بسیاری از مشارکت‌کنندگان و حتی ورثه‌های آن‌ها مشغول شوید. موزیلا سال‌ها به طول انجامید (2001 تا 2006) تا مجوز «Firefox»، «Thunderbird» و دیگر نرم‌افزارهای مربوطه را تغییر دهد.
 
 همچنین می‌توانید موافقت مشارکت‌کنندگان را از قبل جلب کنید (از طریق توافق‌نامه‌های مشارکتی اضافی - به زیر مراجعه کنید) تا بتوانید کارتان را در مورد برخی از تغییرات مجوز تحت شرایط خاصی را فراتر از شرایط مجاز مجوز متن باز موجود پیش ببرید. این موضوع پیچیدگی تغییر مجوزها را کمی تغییر می‌دهد. برای اینکار به کمک وکلای خود بیشتر احتیاج خواهید داشت و هنوز هم باید در هنگام اجرای تغییر مجوز، به طور واضح با ذی‌نفعان پروژۀ خود صحبت کنید.
 
@@ -104,9 +104,9 @@ related:
 
 برخی از شرایطی که ممکن است بخواهید یک توافق‌نامه‌ی همکاری اضافی را برای پروژۀ خود در نظر بگیرید، شامل این موارد می‌شود:
 
-* شما یا وکیل‌هاتان بخواهید توسعه‌دهندگان نشان دهند که هر تعهدی که روی آن کار می‌کنند مجاز است. الزام [گواهی مبدا توسعه‌دهنده](https://developercertificate.org/) برای این است که چه تعداد پروژه به این صورت هستند. به عنوان مثال، انجمن «Node.js» به جای «توافق‌نامۀ مجوز مشارکت‌کننده» قبلی خود از «گواهی مبدا توسعه‌دهنده» استفاده می کند. راهکار ساده برای اجرای خودکار «گواهی مبدا توسعه‌دهنده» در منبع (repository) شما، «ربات گواهی مبدا توسعه‌دهنده» است.
+* شما یا وکیل‌هایتان از توسعه‌دهندگان بخواهید نشان دهند هر تعهدی که روی آن کار می‌کنند مجاز است. الزام [گواهی مبدا توسعه‌دهنده](https://developercertificate.org/) برای این است که چه تعداد پروژه به این صورت هستند. به عنوان مثال، انجمن «Node.js» به جای «توافق‌نامۀ مجوز مشارکت‌کننده» قبلی خود از «گواهی مبدا توسعه‌دهنده» استفاده می کند. راهکار ساده برای اجرای خودکار «گواهی مبدا توسعه‌دهنده» در منبع (repository) شما، «ربات گواهی مبدا توسعه‌دهنده» است.
 
-* پروژه شما از یک مجوز متن باز استفاده بکند که شامل امتیاز ثبت اختراع (مانند MIT) نباشد و شما به داشتن سریع امتیاز ثبت اختراع  مشارکت‌کنندگان نیاز داشته باشید؛ برخی از آن‌ها ممکن است در شرکت‌هایی با مجموعه‌های بزرگ حق ثبت اختراع کار کنند که می‌تواند شما یا سایر مشارکت‌کنندگان و کاربران پروژه را مورد هدف قرار دهد. [توافق‌نامۀ مجوز مشارکت‌کنندگان حقیقی Apache](https://www.apache.org/licenses/icla.pdf)، یک توافق‌نامۀ همکاری اضافی است که معمولاً مورد استفاده قرار می‌گیرد و شامل امتیاز ثبت اختراع است که همانند آنچه در مجوز «Apache 2.0» یافت می‌شود، است.
+*  اگر پروژه شما از یک مجوز متن باز استفاده بکند که شامل امتیاز ثبت اختراع (مانند MIT) نباشد و شما به داشتن سریع امتیاز ثبت اختراع  مشارکت‌کنندگان نیاز داشته باشید؛ برخی از آن‌ها ممکن است در شرکت‌هایی با مجموعه‌های بزرگ حق ثبت اختراع کار کنند که می‌تواند شما یا سایر مشارکت‌کنندگان و کاربران پروژه را مورد هدف قرار دهد. [توافق‌نامۀ مجوز مشارکت‌کنندگان حقیقی Apache](https://www.apache.org/licenses/icla.pdf)، یک توافق‌نامۀ همکاری اضافی است که معمولاً مورد استفاده قرار می‌گیرد و شامل امتیاز ثبت اختراع است که همانند آنچه در مجوز «Apache 2.0» یافت می‌شود، است.
 
 * پروژۀ شما تحت مجوز کپی‌لفت باشد ، اما شما همچنین باید نسخه‌ای اختصاصی از پروژه را توزیع و پخش کنید. هر مشارکت‌کننده باید به شما حق نشر اختصاص دهد یا به شما (اما نه به عموم) مجوز اختیاری بدهد. [توافق‌نامۀ همکاری MongoDB](https://www.mongodb.com/legal/contributor-agreement) نمونه‌ای از این نوع توافق‌نامه است.
 
@@ -116,13 +116,13 @@ related:
 
 ## تیم حقوقی شرکت من چه چیزهایی را باید بداند؟
 
-اگر به عنوان کارمند شرکت پروژه‌ای متن باز را منتشر می‌کنید، ابتدا تیم حقوقی باید بداند که شما در حال تهیۀ پروژه‌ای متن باز هستید.
+اگر به عنوان کارمند شرکت، پروژه‌ای متن باز را منتشر می‌کنید، ابتدا تیم حقوقی باید بداند که شما در حال تهیۀ پروژه‌ای متن باز هستید.
 
 حتما این موضوع را به آن‌ها بگویید حتی اگر این پروژه‌ای شخصی باشد. شما احتمالاً با شرکت خود «توافق‌نامۀ کارمندی» دارید که به آن‌ها تا حدودی کنترلی بر روی پروژه های شما می‌دهد، به خصوص اگر مربوط به شرکت باشند یا از منابع شرکت برای توسعۀ پروژه استفاده کرده باشید. شرکت شما _باید_ به شما اجازه دهد و ممکن است از قبل از طریق توافق‌نامه‌ی کارمندی یا سایر سیاست‌های شرکت مجوز داشته باشد. در غیر این صورت، می‌توانید مذاکره کنید (به عنوان مثال، توضیح دهید که پروژۀ شما اهداف یادگیری و توسعۀ حرفه‌ای شرکت را دنبال می‌کند)، یا تا زمانی که شرکت بهتری پیدا نکردید از کار بر روی پروژۀ خودتان خودداری کنید..
 
 **اگر در جستجوی پروژه‌ای برای شرکت هستید،** قطعاً آن‌ها را در جریان بگذارید. تیم حقوقی شما احتمالاً قبلاً سیاست‌هایی را برای استفاده از مجوزهای متن باز (و شاید توافق‌نامه‌های همکاری اضافی) برای استفاده بر اساس الزامات تجاری و تخصصی شرکت در مورد اطمینان از مطابقت پروژۀ شما با مجوزهای وابستگی شرکت، در نظر گرفته است. اگر نه، به نفع هم شما و هم شرکت است! تیم حقوقی شما باید مشتاق همکاری با شما برای مشخص کردن این موارد باشد. چند مسئلۀ مهم:
 
-* **نهادهای واسط**  آیا پروژه شما وابستگی‌هایی به کار دیگران دارد یا در غیر این صورت کد دیگران را شامل می شود یا از آن‌ها استفاده می‌کند؟ اگر پروژه متن باز باشد، باید پروژۀ شما با مجوزهای متن باز مطابقت داشته باشد. این کار با انتخاب مجوز شروع می‌شود که مربوط به مجوزهای متن باز واسط می‌شود (نگاه کنید به بالا). اگر پروژۀ شما پروژه‌های متن باز واسط دیگر را اصلاح یا توزیع می‌کند، تیم حقوقی شما همچنین می‌خواهد بداند که شما سایر شرایط‌های مجوزهای متن باز واسط مانند حفظ اخطارهای حق نشر را رعایت می‌کنید یا خیر. اگر پروژۀ شما از کدهای دیگران استفاده می‌کند که فاقد مجوز متن باز هستند، احتمالاً باید از نگهدارندگان واسط بخواهید که [مجوز متن باز را اضافه کنند](https://choosealicense.com/no-license/#for-users) و اگر نمی‌توانید مجوز را دریافت کنید، استفاده از کد دیگران را در پروژۀ خوتان متوقف کنید.
+* **نهادهای واسط**  آیا پروژه شما وابستگی‌هایی به کار دیگران دارد یا در غیر این صورت کد دیگران را شامل می شود یا از آن‌ها استفاده می‌کند؟ اگر پروژه متن باز باشد، باید پروژۀ شما با مجوزهای متن باز مطابقت داشته باشد. این کار با انتخاب مجوز شروع می‌شود که مربوط به مجوزهای متن باز واسط می‌شود (نگاه کنید به بالا). اگر پروژۀ شما پروژه‌های متن باز واسط دیگر را اصلاح یا توزیع می‌کند، تیم حقوقی شما همچنین می‌خواهد بداند که شما سایر شرایط‌های مجوزهای متن باز واسط مانند حفظ اخطارهای حق نشر را رعایت می‌کنید یا خیر. اگر پروژۀ شما از کدهای دیگران استفاده می‌کند که فاقد مجوز متن باز هستند، احتمالاً باید از نگهدارندگان واسط بخواهید که [مجوز متن باز را اضافه کنند](https://choosealicense.com/no-license/#for-users) و اگر نمی‌توانید مجوز را دریافت کنید، استفاده از کد دیگران را در پروژۀ خودتان متوقف کنید.
 
 * **اسرار کاری:** به این توجه داشته باشید که آیا چیزی در پروژه وجود دارد که شرکت نخواهد آن را در دسترس عموم قرار دهد. در این صورت، پس از مشخص کردن مطالبی که می‌خواهید خصوصی نگه دارید، می‌توانید بقیۀ پروژۀ خود را با متن باز کنید.
 
@@ -136,7 +136,7 @@ related:
 
 در بلند مدت، تیم حقوقی می‌تواند کمک بیشتری به شرکت کند تا از مشارکت خود در پروژه‌های متن باز بهره‌ی بیشتری ببرد و در امان بماند:
 
-* سیاست های مربوط به مشارکت کارمندان سیاست‌هایی را تدوین کنید که مشخص سازد کارمندان شما در پروژه‌های متن باز چه نوع مشارکتی داشته باشند. داشتن سیاست‌های مشخص و واضح باعث کاهش سردرگمی در بین کارمندان و کمک به آن‌ها در مشارکت هرچه بهتر در پروژه‌های متن باز شرکت می‌شود؛ چه به عنوان بخشی از شغل آنها و چه به صورت فعالیت در اوقات فراغت‌شان. یک مثال خوب، [مدل‌های استاندارد و سیاست‌های همکاری در پروژه‌های متن باز](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) «Rackspace» است.
+* **سیاست های مربوط به مشارکت کارمندان:** سیاست‌هایی را تدوین کنید که مشخص سازد کارمندان شما در پروژه‌های متن باز چه نوع مشارکتی داشته باشند. داشتن سیاست‌های مشخص و واضح باعث کاهش سردرگمی در بین کارمندان و کمک به آن‌ها در مشارکت هرچه بهتر در پروژه‌های متن باز شرکت می‌شود؛ چه به عنوان بخشی از شغل آنها و چه به صورت فعالیت در اوقات فراغت‌شان. یک مثال خوب، [مدل‌های استاندارد و سیاست‌های همکاری در پروژه‌های متن باز](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) «Rackspace» است.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
@@ -157,6 +157,6 @@ related:
   </p>
 </aside>
 
-* **امتیاز ثبت اختراع:** ممکن است شرکت شما مایل باشد به شبکۀ [Open Invention Network](https://www.openinventionnetwork.com/)، که یک مجموعۀ ثبت اختراع مشترک برای محافظت از اعضا و استفادۀ آن‌ها از از پروژه‌های بزرگ متن باز یا جستجوی سایر [مجوزهای اختراع ثبت جایگزین](https://www.eff.org/document/hacking-patent-system-2016) است، بپیوندد.
+* **امتیاز ثبت اختراع:** ممکن است شرکت شما مایل باشد به شبکۀ [Open Invention Network](https://www.openinventionnetwork.com/)، که یک مجموعۀ ثبت اختراع مشترک برای محافظت از اعضا و استفادۀ آن‌ها از پروژه‌های بزرگ متن باز یا جستجوی سایر [مجوزهای اختراع ثبت جایگزین](https://www.eff.org/document/hacking-patent-system-2016) است، بپیوندد.
 
 * **نظارت:** مخصوصاً زمانی منطقی است که پروژه‌ای را به یک [شخص حقوقی خارج از شرکت](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project) منتقل کنید.

From 20d2e28136fa336283f9112d86959dc69c544ce9 Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Sun, 14 Nov 2021 08:29:06 +0330
Subject: [PATCH 289/749] Update legal.md

Re-edit
---
 _articles/fa/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index d8953ad1c46..ecdcccd72e6 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -151,7 +151,7 @@ related:
 * **سازگاری:** حتی اگر شرکت شما هیچ پروژۀ متن بازی را منتشر نکند، از دیگر نرم‌افزارهای متن باز استفاده می‌کند. [داشتن آگاهی از روند کار](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) می‌تواند از بروز مشکلات بی‌جا، تأخیر در محصول و شکایات جلوگیری کند.
 
 <aside markdown="1" class="pquote">
- شرکت‌ها باید دارای مجوزها و استراتژی‌های انطباقی باشند که متناسب با هر دو دستۀ [«اختیاری» و «کپی‌لفت»] باشد. این کار با ثبت سوابق مجوزهایی که برای نرم‌افزارهای متن باز مورد استفاده شما اعمال می‌شود - از جمله موءلفه‌های فرعی و وابستگی‌ها - آغاز می‌شود.
+ شرکت‌ها باید دارای مجوزها و استراتژی‌های انطباقی باشند که متناسب با هر دو دستۀ [«اختیاری» و «کپی‌لفت»] باشد. این کار با ثبت سوابق مجوزهایی که برای نرم‌افزارهای متن باز مورد استفاده شما اعمال می‌شود - از جمله مؤلفه‌های فرعی و وابستگی‌ها - آغاز می‌شود.
   <p markdown="1" class="pquote-credit">
 — Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
   </p>

From d900d0cc24b59ecbbaba6dd03b40d67f475d550a Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Mon, 15 Nov 2021 09:39:17 +0330
Subject: [PATCH 290/749] Update legal.md

re-edit for readability
---
 _articles/fa/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index ecdcccd72e6..0876a570a8e 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -12,7 +12,7 @@ related:
 
 ## درک پیامدهای حقوقی پروژه‌های منبع آزاد
 
-اشتراک گذاشتن کارهای خلاقانه با جهانیان می‌تواند تجربه‌ای هیجان‌انگیز و ارزشمند باشد. همچنین می‌تواند به معنای درگیر شدن با یک سری موارد حقوقی باشد در رابطه با آن‌ها چیزی نمی‌دانید. خوشبختانه، نیازی نیست از ابتدا شروع کنید. ما نیازهای حقوقی شما را برآورده کرده و پوشش داده‌ایم. (قبل از شروع، حتماً متن [سلب مسئولیت](/notices/) ما را بخوانید.) 
+اشتراک گذاشتن کارهای خلاقانه با جهانیان می‌تواند تجربه‌ای هیجان‌انگیز و ارزشمند باشد. همچنین می‌تواند به معنای درگیر شدن با یک سری موارد حقوقی باشد که در رابطه با آن‌ها چیزی نمی‌دانید. خوشبختانه، نیازی نیست از ابتدا شروع کنید. ما نیازهای حقوقی شما را برآورده کرده و پوشش داده‌ایم. (قبل از شروع، حتماً متن [سلب مسئولیت](/notices/) ما را بخوانید.) 
 
 ## چرا مردم اینقدر به جنبه‌های حقوقی متن آزاد اهمیت می‌دهند؟
 

From aec3ecabbaf27c5d8acf475ccfaf96ac3df026cb Mon Sep 17 00:00:00 2001
From: simin binazadeh <60018281+ciminbinazadeh@users.noreply.github.com>
Date: Wed, 17 Nov 2021 08:47:39 +0330
Subject: [PATCH 291/749] fixed error

Re-edit to fix the error
---
 _articles/fa/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index 0876a570a8e..a15a8fe61b4 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -106,7 +106,7 @@ related:
 
 * شما یا وکیل‌هایتان از توسعه‌دهندگان بخواهید نشان دهند هر تعهدی که روی آن کار می‌کنند مجاز است. الزام [گواهی مبدا توسعه‌دهنده](https://developercertificate.org/) برای این است که چه تعداد پروژه به این صورت هستند. به عنوان مثال، انجمن «Node.js» به جای «توافق‌نامۀ مجوز مشارکت‌کننده» قبلی خود از «گواهی مبدا توسعه‌دهنده» استفاده می کند. راهکار ساده برای اجرای خودکار «گواهی مبدا توسعه‌دهنده» در منبع (repository) شما، «ربات گواهی مبدا توسعه‌دهنده» است.
 
-*  اگر پروژه شما از یک مجوز متن باز استفاده بکند که شامل امتیاز ثبت اختراع (مانند MIT) نباشد و شما به داشتن سریع امتیاز ثبت اختراع  مشارکت‌کنندگان نیاز داشته باشید؛ برخی از آن‌ها ممکن است در شرکت‌هایی با مجموعه‌های بزرگ حق ثبت اختراع کار کنند که می‌تواند شما یا سایر مشارکت‌کنندگان و کاربران پروژه را مورد هدف قرار دهد. [توافق‌نامۀ مجوز مشارکت‌کنندگان حقیقی Apache](https://www.apache.org/licenses/icla.pdf)، یک توافق‌نامۀ همکاری اضافی است که معمولاً مورد استفاده قرار می‌گیرد و شامل امتیاز ثبت اختراع است که همانند آنچه در مجوز «Apache 2.0» یافت می‌شود، است.
+* اگر پروژه شما از یک مجوز متن باز استفاده بکند که شامل امتیاز ثبت اختراع (مانند MIT) نباشد و شما به داشتن سریع امتیاز ثبت اختراع  مشارکت‌کنندگان نیاز داشته باشید؛ برخی از آن‌ها ممکن است در شرکت‌هایی با مجموعه‌های بزرگ حق ثبت اختراع کار کنند که می‌تواند شما یا سایر مشارکت‌کنندگان و کاربران پروژه را مورد هدف قرار دهد. [توافق‌نامۀ مجوز مشارکت‌کنندگان حقیقی Apache](https://www.apache.org/licenses/icla.pdf)، یک توافق‌نامۀ همکاری اضافی است که معمولاً مورد استفاده قرار می‌گیرد و شامل امتیاز ثبت اختراع است که همانند آنچه در مجوز «Apache 2.0» یافت می‌شود، است.
 
 * پروژۀ شما تحت مجوز کپی‌لفت باشد ، اما شما همچنین باید نسخه‌ای اختصاصی از پروژه را توزیع و پخش کنید. هر مشارکت‌کننده باید به شما حق نشر اختصاص دهد یا به شما (اما نه به عموم) مجوز اختیاری بدهد. [توافق‌نامۀ همکاری MongoDB](https://www.mongodb.com/legal/contributor-agreement) نمونه‌ای از این نوع توافق‌نامه است.
 

From e9c616981c9864becb4de24a6f591ec75f6bd9d1 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 17 Nov 2021 09:04:29 +0000
Subject: [PATCH 292/749] Bump github-pages from 221 to 222

Bumps [github-pages](https://github.com/github/pages-gem) from 221 to 222.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v221...v222)

---
updated-dependencies:
- dependency-name: github-pages
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 70c1c375a38..bf890121635 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -19,9 +19,9 @@ GEM
     concurrent-ruby (1.1.9)
     dnsruby (1.61.7)
       simpleidn (~> 0.1)
-    em-websocket (0.5.2)
+    em-websocket (0.5.3)
       eventmachine (>= 0.12.9)
-      http_parser.rb (~> 0.6.0)
+      http_parser.rb (~> 0)
     ethon (0.15.0)
       ffi (>= 1.15.0)
     eventmachine (1.2.7)
@@ -48,7 +48,7 @@ GEM
     ffi (1.15.4)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (221)
+    github-pages (222)
       github-pages-health-check (= 1.17.9)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
@@ -109,7 +109,7 @@ GEM
       rainbow (~> 3.0)
       typhoeus (~> 1.3)
       yell (~> 2.0)
-    http_parser.rb (0.6.0)
+    http_parser.rb (0.8.0)
     i18n (0.9.5)
       concurrent-ruby (~> 1.0)
     jekyll (3.9.0)
@@ -246,7 +246,7 @@ GEM
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
     public_suffix (4.0.6)
-    racc (1.5.2)
+    racc (1.6.0)
     rainbow (3.0.0)
     rake (13.0.6)
     rb-fsevent (0.11.0)
@@ -281,7 +281,7 @@ GEM
     unf_ext (0.0.8)
     unicode-display_width (1.8.0)
     yell (2.2.2)
-    zeitwerk (2.4.2)
+    zeitwerk (2.5.1)
 
 PLATFORMS
   ruby

From 0cd3c7ebceeae0fc43ce873bd0da6f7003706298 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 23 Nov 2021 09:07:17 +0000
Subject: [PATCH 293/749] Bump actions/cache from 2.1.6 to 2.1.7

Bumps [actions/cache](https://github.com/actions/cache) from 2.1.6 to 2.1.7.
- [Release notes](https://github.com/actions/cache/releases)
- [Commits](https://github.com/actions/cache/compare/v2.1.6...v2.1.7)

---
updated-dependencies:
- dependency-name: actions/cache
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 80d0830419c..8e76eca7391 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -17,7 +17,7 @@ jobs:
       uses: actions/setup-node@v2.4.1
 
     - name: Restore bundler cache
-      uses: actions/cache@v2.1.6
+      uses: actions/cache@v2.1.7
       with:
         path: vendor/gems
         key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}

From 2ab6457e4e9e6935b82b80ff3d6615a5618d656e Mon Sep 17 00:00:00 2001
From: plplmax <50287455+plplmax@users.noreply.github.com>
Date: Fri, 26 Nov 2021 21:06:24 +0300
Subject: [PATCH 294/749] Fix spelling mistakes in how-to-contribute.md [ru]

---
 _articles/ru/how-to-contribute.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index 39bac8a96bb..e3723e4be1b 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -60,7 +60,7 @@ related:
 
 ### Необязательно помогать кодом
 
-Распространенное заблуждение, касающиеся участия в опенсорсе, состоит в том, что вам нужно писать код. Зачастую есть другие части проекта, которым [наиболее всего принебрегают или упускают из виду](https://github.com/blog/2195-the-shape-of-open-source). Вы окажете проекту _огромную_ услугу, предложив поработать над ними!
+Распространенное заблуждение, касающееся участия в опенсорсе, состоит в том, что вам нужно писать код. Зачастую есть другие части проекта, которыми [наиболее всего пренебрегают или упускают из виду](https://github.com/blog/2195-the-shape-of-open-source). Вы окажете проекту _огромную_ услугу, предложив поработать над ними!
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
@@ -103,7 +103,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
-  Кроме шуток, \[документация\] крайней важна. Документация до сих пор была отличной и была ключевой особенностью Babel. Есть разделы, которые требуют доработку, и даже добавление параграфа здесь или там чрезвычайно приветствуется.
+  Кроме шуток, \[документация\] крайне важна. Документация до сих пор была отличной и была ключевой особенностью Babel. Есть разделы, которые требуют доработку, и даже добавление параграфа здесь или там чрезвычайно приветствуется.
   <p markdown="1" class="pquote-credit">
 - @kittens, ["Призыв контрибьюторов"](https://github.com/babel/babel/issues/1347)
   </p>

From 2fcd53179cfe087b671f1b234fc40bd99969e948 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 30 Nov 2021 09:08:41 +0000
Subject: [PATCH 295/749] Bump actions/setup-node from 2.4.1 to 2.5.0

Bumps [actions/setup-node](https://github.com/actions/setup-node) from 2.4.1 to 2.5.0.
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/v2.4.1...v2.5.0)

---
updated-dependencies:
- dependency-name: actions/setup-node
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 8e76eca7391..adc5936e24b 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -14,7 +14,7 @@ jobs:
       uses: actions/setup-ruby@v1.1.3
 
     - name: Set up Node
-      uses: actions/setup-node@v2.4.1
+      uses: actions/setup-node@v2.5.0
 
     - name: Restore bundler cache
       uses: actions/cache@v2.1.7

From ec017a75b82778318ed6fb699fa9c8e4043139c2 Mon Sep 17 00:00:00 2001
From: parroty <parroty00@gmail.com>
Date: Tue, 7 Dec 2021 21:41:26 +0900
Subject: [PATCH 296/749] Fix typo

---
 _articles/ja/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/ja/starting-a-project.md b/_articles/ja/starting-a-project.md
index 2161de540af..54821747e37 100644
--- a/_articles/ja/starting-a-project.md
+++ b/_articles/ja/starting-a-project.md
@@ -249,7 +249,7 @@ README に CONTRIBUTING ファイルへのリンクをすることで、より
 
 暖かく、排他的でない言葉遣い（一人の人を指すときであっても「彼ら」を使う、といったような）をすることで、あなたのプロジェクトで新しいコントリビューターが歓迎されていると感じてもらうことに繋がります。シンプルな言葉遣いをすることにこだわりましょう。あなたのプロジェクトを見る人の多くは英語のネイティブスピーカーではないかもしれません。
 
-あなたがどう文書を書くかに加えて、あなたのコーディングスタイルもプロジェクトのブランドの一分になるかもしれません。 [Angular](https://github.com/johnpapa/angular-styleguide) と [jQuery](https://contribute.jquery.org/style-guide/js/) の2つは厳密なコーディングスタイルとガイドラインを持つプロジェクトの例です。
+あなたがどう文書を書くかに加えて、あなたのコーディングスタイルもプロジェクトのブランドの一部になるかもしれません。 [Angular](https://github.com/johnpapa/angular-styleguide) と [jQuery](https://contribute.jquery.org/style-guide/js/) の2つは厳密なコーディングスタイルとガイドラインを持つプロジェクトの例です。
 
 かならずしもプロジェクトを始める際にスタイルガイドを書く必要はありませんし、とにかく異なるコーディングスタイルを盛り込むのが楽しいと思うかもしれません。しかし、あなたの文書やコーディングスタイルが異なるタイプの人々を惹きつけることもあれば落胆させることもあるということを予期しておくべきです。プロジェクトの最初期はあなたが望む先例を作る良い機会です。
 

From f57d6dcf51cfd0aa0cefccfa6fee6c04b39cb1bb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dar=C3=ADo=20Here=C3=B1=C3=BA?= <magallania@gmail.com>
Date: Thu, 9 Dec 2021 15:24:20 -0300
Subject: [PATCH 297/749] Syntax issue (paragraph 74)

- Typos fixed (paragraph 44, 106, 110, 186, 188, 214, 235)
---
 _articles/es/starting-a-project.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/_articles/es/starting-a-project.md b/_articles/es/starting-a-project.md
index fa4cf1b910e..8810fc58b07 100644
--- a/_articles/es/starting-a-project.md
+++ b/_articles/es/starting-a-project.md
@@ -43,7 +43,7 @@ Realicemos una comparaci&oacute;n: un proceso de c&oacute;digo cerrado ser&iacut
 
 * **Colaboraci&oacute;n:** Los proyectos de c&oacute;digo abierto pueden aceptar cambios efectuados por cualquier persona alrededor del mundo. [Exercism](https://github.com/exercism/), por ejemplo, una plataforma para ejercicios de programaci&oacute;n con m&aacute;s de 350 colaboradores.
 
-* **Adopci&oacute;n y remezcla:** Los proyectos de c&oacute;digo abierto puedne ser usados por cualquiera para casi cualquier pr&oacute;p&oacute;sito. Las personas pueden usarlos hasta para construir otras cosas. [WordPress](https://github.com/WordPress), por ejemplo, comenzaron como un "fork" de un proyecto existente llamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **Adopci&oacute;n y remezcla:** Los proyectos de c&oacute;digo abierto pueden ser usados por cualquiera para casi cualquier pr&oacute;p&oacute;sito. Las personas pueden usarlos hasta para construir otras cosas. [WordPress](https://github.com/WordPress), por ejemplo, comenzaron como un "fork" de un proyecto existente llamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
 * **Transparencia:** Cualquiera puede inspeccionar un proyecto de este tipo, ya sea para encontrar errores como inconsistencias. La transparencia es de importancia para gobiernos como el de [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o [United States](https://sourcecode.cio.gov/), para industrias reguladas como la bancaria o la del cuidado de la salud, y para la seguridad del software como [Let's Encrypt](https://github.com/letsencrypt).
 
@@ -71,7 +71,7 @@ Si no estás convencido todav&iacute;a, toma un momento para pensar acerca de cu
 
 Los objetivos pueden ayudarte a detectar puntos en los que continuar trabajando, a qu&eacute; decirle que no, y a d&oacute;nde recurrir por ayuda. Comienza pregunt&aacute;ndote, _&iquest;Por qu&eacute; estoy haciendo "c&oacute;digo abierto" a mi proyecto?_
 
-No hay nunca una respuesta correcta a la &eacute;sta pregunta. Puedes tener m&uacute;ltiples objetivos para un solo proyecto, o diferentes proyectos con diferentes objetivos.
+No hay nunca una respuesta correcta a esta pregunta. Puedes tener m&uacute;ltiples objetivos para un solo proyecto, o diferentes proyectos con diferentes objetivos.
 
 Si tu &uacute;nico objetivo es mostrar al mundo tu trabajo, quiz&aacute;s no necesites ni quieras contribuci&oacute;n, y quiz&aacute;s digas eso en el README. Por otra parte, si quieres ayuda, invertir&aacute;s tiempo en clarificar la documentaci&oacute;n y en hacer sentir a los reci&eacute;n llegados bienvenidos.
 
@@ -103,11 +103,11 @@ Si necesitas un presupuesto dedicado o personal para la promoci&oacute;n, operac
 
 Si tu meta es aprender c&oacute;mo contribuir con otros o entender c&oacute;mo funciona el "c&oacute;digo abierto", considera contribuir en proyectos existentes. Comienza con proyectos que ya has estado usando y que te gustan. Contribuir a un proyecto puede ser tan simple como arreglar "typos" o actualizar documentaci&oacute;n.
 
-Si no sab&eacute;s como comenzar a contribuir, mira esto [Gu&iacute;a sobre c&oacute;mo contribuir](../how-to-contribute/).
+Si no sab&eacute;s como comenzar a contribuir, mira esta [Gu&iacute;a sobre c&oacute;mo contribuir](../how-to-contribute/).
 
 ## Lanzando tu propio proyecto de C&oacute;digo Abierto
 
-No hay momento prefecto para abrir el c&oacute;digo de tu trabajo. Puedes abrir el de una idea, el de un trabajo en progreso, o despu&eacute;s de varios a&ntilde;os de ser un proyecto cerrado.
+No hay momento perfecto para abrir el c&oacute;digo de tu trabajo. Puedes abrir el de una idea, el de un trabajo en progreso, o despu&eacute;s de varios a&ntilde;os de ser un proyecto cerrado.
 
 Generalmente, puedes abrir el c&oacute;digo de tu proyecto cuando te sientas c&oacute;modo de que otras personas vean y te aconsejen sobre tu trabajo.
 
@@ -183,9 +183,9 @@ Por ejemplo, [Active Admin](https://github.com/activeadmin/activeadmin/) comienz
 
 > Primero, muchas gracias por considerar contribuir a Active Admin. Son personas como ustedes las que la hacen una gran herramienta.
 
-En las primeras etapas del proyecto, tu archivo CONTRIBUITNG puede ser simple. Siempre debes explicar c&oacute;mo reportar bugs o issues, y cualquier requerimiento t&eacute;cnico (como tests) para hacer una contribuci&oacute;n.
+En las primeras etapas del proyecto, tu archivo CONTRIBUTING puede ser simple. Siempre debes explicar c&oacute;mo reportar bugs o issues, y cualquier requerimiento t&eacute;cnico (como tests) para hacer una contribuci&oacute;n.
 
-Con el tiempo, quiz&aacute;s debas agregar otras "preguntas frecuentes" a tu archivo. Escribir &eacute;sta informaci&oacute;n significa que menos personas te preguntar&aacute;n nuevamente la misma pregunta.
+Con el tiempo, quiz&aacute;s debas agregar otras "preguntas frecuentes" a tu archivo. Escribir esta informaci&oacute;n significa que menos personas te preguntar&aacute;n nuevamente la misma pregunta.
 
 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/).
 
@@ -211,7 +211,7 @@ Adem&aacute;s de comunicar _c&oacute;mo_ esperas que se comporten los participan
 
 Como muchas licencias de c&oacute;digo abierto, existen est&aacute;ndares emergentes para c&oacute;digos de conducta para que no debas escribir uno propio. El [Contributor Covenant](https://www.contributor-covenant.org/) es un c&oacute;digo de conducta usado por [m&aacute;s de 40000 proyectos de c&oacute;digo abierto](https://www.contributor-covenant.org/adopters), incluyendo Kubernetes, Rails, and Swift. Debes estar preparado para redefinir el tuyo cuando sea necesario.
 
-Copia el texto directamente en el archivo CODE_OF_CONDUCT dentro de tu repositorio, en el directorio ra&iacute;z, y vinculalo desde tu README.
+Copia el texto directamente en el archivo CODE_OF_CONDUCT dentro de tu repositorio, en el directorio ra&iacute;z, y vincúlalo desde tu README.
 
 ## Dando un nombre y una marca a tu proyecto
 
@@ -232,7 +232,7 @@ Considera claridad por sobre todo. Los chismes son divertidos,pero recuerda que
 
 Busca proyectos con el mismo nombre, o similar, especialmente si compartes el mismo ecosistema o idioma. Si tu nombre coincide con alg&uacute;n otro proyecto popular, puede confundir a las personas.
 
-Si quieres una p&aacute;gina web, manejo de Twitter, u otros &iacute;tems que representen tu proyecto, asegurate de que puedas asignar el nombre que quieras. En lo posible, [reserva tu nombre ahora](https://instantdomainsearch.com/) para estar tranquilo, aunque a&uacute;n no lo vayas a usar.
+Si quieres una p&aacute;gina web, manejo de Twitter, u otros &iacute;tems que representen tu proyecto, asegúrate de que puedas asignar el nombre que quieras. En lo posible, [reserva tu nombre ahora](https://instantdomainsearch.com/) para estar tranquilo, aunque a&uacute;n no lo vayas a usar.
 
 Tu nombre no debe infringir ninguna marca (trademark), de ser as&iacute; la compa&ntilde;&iacute;a puede pedirte que des de baja a tu proyecto, o puede tomar acciones legales en tu contra. No vale el riesgo.
 

From 96fb752d816b07af6e7599df8c79fd095b8f2c0c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dar=C3=ADo=20Here=C3=B1=C3=BA?= <magallania@gmail.com>
Date: Thu, 9 Dec 2021 15:29:43 -0300
Subject: [PATCH 298/749] Typo fixed (paragraph 50)

---
 _articles/es/metrics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/es/metrics.md b/_articles/es/metrics.md
index 2d9833ebd34..970b4030785 100644
--- a/_articles/es/metrics.md
+++ b/_articles/es/metrics.md
@@ -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 decargas, si no m&aacute;s bien según la cantidad de notoriedad de tu proyecto.
+[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.
 
 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.
 

From d215a2e4b740be7c32158bfc97c271acd57615b9 Mon Sep 17 00:00:00 2001
From: Marat Talipov <Morion-Self@users.noreply.github.com>
Date: Sat, 11 Dec 2021 18:52:09 +0500
Subject: [PATCH 299/749] Fix spelling mistakes in 'How to contribute'

---
 _articles/ru/how-to-contribute.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index e3723e4be1b..89fbc588238 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -478,14 +478,14 @@ related:
 * Сделать незначительное исправление (например, исправить опечатку, неработающую ссылку или очевидную ошибку)
 * Начать работать над тем, о чём уже было договорено или что обсуждалось в ишью
 
-Пул-реквест не обязательно должен представлять законченную работу. Обычно лучше пул-реквест на раннем этапе, чтобы люди могли наблюдать за вашим прогрессом или оставлять отзывы о нем. Только в названии таком пул-реквесте укажите "WIP" (от англ. Work in Progress — в процессе выполнения). Всегда позже можно отправить дополнительные коммиты.
+Пул-реквест не обязательно должен представлять законченную работу. Обычно лучше открывать пул-реквест на раннем этапе, чтобы люди могли наблюдать за вашим прогрессом или оставлять отзывы о нем. Только в названии таком пул-реквесте укажите "WIP" (от англ. Work in Progress — в процессе выполнения). Всегда позже можно отправить дополнительные коммиты.
 
 Если проект находится на GitHub, выполните следующие шаги, чтобы создать пул-реквест:
 
 * **[Форкните репозиторий](https://guides.github.com/activities/forking/)** и склонируйте его к себе локально. Затем в этом локальном репозитории добавьте оригинальный (upstream) репозиторий. Почаще загружайте изменения из исходного репозиторий, чтобы ваш локальный репозиторий оставался в актуальном состоянии, — это снизит появление конфликтов при создании пул-реквеста. (См. более подробные инструкции [здесь](https://help.github.com/articles/syncing-a-fork/).)
 * **[Создайте ветку](https://guides.github.com/introduction/flow/)** для ваших правок.
 * **Ссылайтесь на любые относящиеся к делу ишью** или подтверждающую документацию в своем PR (например, «Closes #37»).
-* **Добавьте скриншоты до и после**, если ваши изменения включают затрагивает файлы HTML/CSS. Перетащите изображения в текстовую область пул-реквеста.
+* **Добавьте скриншоты до и после**, если ваши изменения затрагивают файлы HTML/CSS. Перетащите изображения в текстовую область пул-реквеста.
 * **Протестируйте свои изменения!** Например, если есть, запустите тесты, и при необходимости напишите новые. Даже если нет тестов, проверьте сами, что после ваших изменений всё работает, как и раньше.
 * **Соблюдайте стиль написания кода проекта** в меру своих возможностей. Это может быть использование отступов, точек с запятой или комментариев иначе, чем вы привыкли, но мейнтейнерам это упросит слияние вашего пул-реквеста, а другим — облегчит понимание и поддержку в будущем.
 
@@ -505,7 +505,7 @@ related:
 
 **Не** обращайтесь напрямую к этому человеку; помните, что публичное общение жизненно важно для опенсорс-проектов.
 
-Если после вежливого напоминания, так и никто не ответил, есть вероятность, что никто и никогда не ответит. Это не самое приятное ощущение, но пусть оно вас не расстраивает. Такое с каждым случалось! Есть множество возможных причин, по которым вам не ответили, в том числе личные обстоятельства, на которые вы можете повлиять. Попробуйте найти другой проект или способ участия. Во всяком случае, нет больше смысла вкладываться в такие проекты, по крайней мере до того момента, когда объявляться другие члены сообщества.
+Если после вежливого напоминания так и никто не ответил, есть вероятность, что никто и никогда не ответит. Это не самое приятное ощущение, но пусть оно вас не расстраивает. Такое с каждым случалось! Есть множество возможных причин, по которым вам не ответили, в том числе личные обстоятельства, на которые вы можете повлиять. Попробуйте найти другой проект или способ участия. Во всяком случае, нет больше смысла вкладываться в такие проекты, по крайней мере до того момента, когда объявятся другие члены сообщества.
 
 ### 🚧 У вас могут запросить внести изменения.
 
@@ -517,7 +517,7 @@ related:
 
 ### 👎 Ваш вклад не принят.
 
-В итоге ваш вклад может быть принят или нет. Надеюсь, вы не потратили слишком много усилий на него. Если для вас не было понятно, почему он не был принят, разумно попросить мейнтейнера дать пояснения. В конечном итоге, однако, вам нужно стоит понять и смирится с их решением. Не спорьте и не злитесь по этому поводу. В случае чего вы всегда можете форкнуть репозиторий, чтобы работать над своей собственной версией продукта!
+В итоге ваш вклад может быть принят или нет. Надеюсь, вы не потратили слишком много усилий на него. Если для вас не было понятно, почему он не был принят, разумно попросить мейнтейнера дать пояснения. В конечном итоге, однако, вам стоит понять и смирится с их решением. Не спорьте и не злитесь по этому поводу. В случае чего вы всегда можете форкнуть репозиторий, чтобы работать над своей собственной версией продукта!
 
 ### 🎉 Ваш вклад принят.
 

From 6ea27cc690e24e5d62d7d61ad72a5b747c31b844 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 20 Dec 2021 09:06:20 +0000
Subject: [PATCH 300/749] Bump html-proofer from 3.19.2 to 3.19.3

Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.19.2 to 3.19.3.
- [Release notes](https://github.com/gjtorikian/html-proofer/releases)
- [Changelog](https://github.com/gjtorikian/html-proofer/blob/main/CHANGELOG.md)
- [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.19.2...v3.19.3)

---
updated-dependencies:
- dependency-name: html-proofer
  dependency-type: direct:development
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index bf890121635..319e8a58cc1 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -101,10 +101,10 @@ GEM
     html-pipeline (2.14.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.19.2)
+    html-proofer (3.19.3)
       addressable (~> 2.3)
       mercenary (~> 0.3)
-      nokogumbo (~> 2.0)
+      nokogiri (~> 1.12)
       parallel (~> 1.3)
       rainbow (~> 3.0)
       typhoeus (~> 1.3)
@@ -237,12 +237,10 @@ GEM
     nokogiri (1.12.5)
       mini_portile2 (~> 2.6.1)
       racc (~> 1.4)
-    nokogumbo (2.0.5)
-      nokogiri (~> 1.8, >= 1.8.4)
     octokit (4.21.0)
       faraday (>= 0.9)
       sawyer (~> 0.8.0, >= 0.5.3)
-    parallel (1.20.1)
+    parallel (1.21.0)
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
     public_suffix (4.0.6)

From 7d78923e397ee7eae8b36b1fe4128ac99959560f Mon Sep 17 00:00:00 2001
From: Deletor <annco88@gmail.com>
Date: Mon, 20 Dec 2021 18:31:01 +0100
Subject: [PATCH 301/749] improving grammar

---
 _articles/pl/best-practices.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/pl/best-practices.md b/_articles/pl/best-practices.md
index 3fed2f2d00f..51c2dba8991 100644
--- a/_articles/pl/best-practices.md
+++ b/_articles/pl/best-practices.md
@@ -52,7 +52,7 @@ Zapisywanie zasad może być denerwujące. Czasami możesz mieć wrażenie, że
 
 Napisane i rzetelnie egzekwowane dobre zasady, jednak upoważniają opiekunów. Zapobiegają wciągnięciu cię w robienie rzeczy, których nie chcesz robić.
 
-Większość ludzi, którzy natkną się na twój projekt, nie wie nic o tobie ani twoich okolicznościach. Mogą założyć, że zarabiasz za pracę nad tym, zwłaszcza jeśli jest to coś, z czego regularnie korzystają i na którym polegają. Może w pewnym momencie poświęcisz dużo czasu na swój projekt, ale teraz jesteś zajęty nową pracą lub członkiem rodziny.
+Większość ludzi, którzy natkną się na twój projekt, nie wie nic o tobie ani twoich okolicznościach. Mogą założyć, że zarabiasz za pracę nad tym, zwłaszcza jeśli jest to coś, z czego regularnie korzystają i na czym polegają. Może w pewnym momencie poświęcałeś dużo czasu na swój projekt, ale teraz jesteś zajęty nową pracą lub członkiem rodziny.
 
 Wszystko to jest w porządku! Upewnij się tylko, że inni wiedzą o tym.
 
@@ -161,7 +161,7 @@ Jeśli widzisz, że ktoś jest entuzjastycznie nastawiony do twojego projektu, a
 
 ## Wykorzystaj swoją społeczność
 
-Nie musisz robić wszystkiego sam. Społeczność twojego projektu istnieje bez powodu! Nawet jeśli nie masz jeszcze aktywnej społeczności współautorów, jeśli masz wielu użytkowników, włącz ich do pracy.
+Nie musisz robić wszystkiego sam. Społeczność twojego projektu nie istnieje bez powodu! Nawet jeśli nie masz jeszcze aktywnej społeczności współautorów, jeśli masz wielu użytkowników, włącz ich do pracy.
 
 ### Udostępnij obciążenie pracą
 

From 89a0925edd322b87ae326a597a0ccd438c9d4d36 Mon Sep 17 00:00:00 2001
From: Nick Holden <nick.r.holden@gmail.com>
Date: Mon, 20 Dec 2021 15:35:25 -0800
Subject: [PATCH 302/749] Remove script for generating ebooks

---
 script/ebooks     | 196 ----------------------------------------------
 test/package.json |   7 --
 2 files changed, 203 deletions(-)
 delete mode 100755 script/ebooks

diff --git a/script/ebooks b/script/ebooks
deleted file mode 100755
index b9372a28de3..00000000000
--- a/script/ebooks
+++ /dev/null
@@ -1,196 +0,0 @@
-#!/usr/bin/env node
-
-// Generate EPUB and MOBI ebooks
-
-const fs = require('fs');
-const path = require('path');
-const exec = require('child_process').exec;
-const fastmatter = require('fastmatter');
-const mkdirp = require('mkdirp');
-const slug = require('slug');
-const unified = require('unified');
-const parse = require('remark-parse');
-const stringify = require('remark-stringify');
-const visit = require('unist-util-visit');
-const download = require('download');
-const ebrew = require('ebrew');
-
-const processor = unified()
-  .use(parse)
-  .use(replaceAsides)
-  .use(replaceCheckboxes)
-  .use(fixImages)
-  .use(downloadImages)
-  .use(stringify);
-
-buildBooks([
-  '_articles/how-to-contribute.md',
-  '_articles/starting-a-project.md',
-  '_articles/finding-users.md',
-  '_articles/building-community.md',
-  '_articles/best-practices.md',
-  '_articles/leadership-and-governance.md',
-  '_articles/getting-paid.md',
-  '_articles/code-of-conduct.md',
-  '_articles/metrics.md',
-  '_articles/legal.md',
-]);
-
-function buildBooks(files) {
-  const out = 'assets/ebooks/open-source-guide';
-  const tempFile = '_ebook.md';
-
-  mkdirp.sync('assets/ebooks');
-  mkdirp.sync('.asset-downloads');
-
-  let source = files.map(readFile).join('\n\n');
-  const { text, promises } = downloadImages(source);
-  fs.writeFileSync(tempFile, text);
-
-  promises
-    .then(() => markdownToEpub(tempFile, `${out}.epub`))
-    .then(() => epubToMobi(`${out}.epub`, `${out}.mobi`))
-    .then(() => fs.unlinkSync(tempFile))
-    .catch(err => console.error(err));
-}
-
-function readFile(file) {
-  const md = fs.readFileSync(file, 'utf8');
-
-  // Replace frontmatter with chapter title
-  const { attributes, body } = fastmatter(md);
-  let text = `# ${attributes.title}\n\n${body}`;
-
-  return processor.process(text).contents;
-}
-
-function markdownToEpub(mdFile, epubFile) {
-  return new Promise((resolve, reject) => {
-    console.log(`Building ${epubFile}...`);
-
-    const manifestFile = '_ebook.json';
-    fs.writeFileSync(manifestFile, JSON.stringify({
-      tocDepth: 1,
-      title: 'Open Source Guides',
-      subtitle: 'Open source software is made by people just like you. Learn how to launch and grow your project.',
-      author: 'GitHub',
-      publisher: 'GitHub',
-      rights: 'CC-BY-4.0',
-      date: (new Date()).toISOString().slice(0, 10),
-      contents: path.resolve(mdFile),
-    }));
-
-    ebrew.generate(manifestFile, epubFile, err => {
-      fs.unlinkSync(manifestFile);
-      if (err) {
-        reject(err.stack || err);
-      } else {
-        resolve();
-      }
-    });
-  });
-}
-
-function epubToMobi(epubFile, mobiFile) {
-  return new Promise((resolve, reject) => {
-    console.log(`Building ${mobiFile}...`);
-
-    const kindlegen = require.resolve('kindlegen/bin/kindlegen');
-    exec(`${kindlegen} ${epubFile} -c2 -verbose -o ${path.basename(mobiFile)}`, (err, stdout) => {
-      if (err && stdout.includes('MOBI file could not be generated because of errors!')) {
-        reject(stdout);
-      } else {
-        resolve();
-      }
-    });
-  });
-}
-
-function downloadImages(text) {
-  function image(processor) {
-    return ast => visit(ast, 'image', node => {
-      if (node.url.startsWith('http')) {
-        const url = node.url;
-        const filename = slug(path.basename(node.url));
-        const filepath = `./.asset-downloads/${filename}.jpg`
-        node.url = filepath;
-        if (fs.existsSync(filepath)) {
-          promises.push(Promise.resolve());
-        } else {
-          const promise = download(url)
-            .then(data => {
-              fs.writeFileSync(filepath, data);
-            });
-          promises.push(promise);
-        }
-      }
-    });
-  }
-
-  let promises = [];
-  const processor = unified()
-    .use(parse)
-    .use(image)
-    .use(stringify);
-
-  text = processor.process(text).contents;
-
-  return {
-    promises: Promise.all(promises),
-    text,
-  };
-}
-
-/*
-Replace asides with Markdown blockquotes:
-<aside markdown="1" class="pquote">
-  <img src="https://avatars2.githubusercontent.com/u/1976330?v=3&s=460" class="pquote-avatar" alt="avatar" alt="@lord avatar">
-  I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of an half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
-  <p markdown="1" class="pquote-credit">
-— @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
-  </p>
-</aside>
-*/
-function replaceAsides(processor) {
-  return ast => visit(ast, 'html', node => {
-    if (node.value.startsWith('<aside')) {
-      node.value = node.value
-        .replace(/  <img src="(.*?)"[^>]*>/, '![]($1)\n')
-        .replace(/\(\/assets\//, '(./assets/')
-        .replace(/<\/?(aside|p).*?>/g, '')
-        .trim()
-        .replace(/(^|\n) */g, '\n> ');
-    }
-  });
-}
-
-/*
-Replace checkboxes with unordered lists:
-<div class="clearfix mb-2">
-  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
-  <label for="cbox1" class="overflow-hidden d-block text-normal">
-  Does it have a license? Usually, this is a file called LICENSE in the root of the repository.
-  </label>
-</div>
-*/
-function replaceCheckboxes(processor) {
-  return ast => visit(ast, 'html', node => {
-    if (node.value.startsWith('<div')) {
-      node.value = node.value
-        .replace(/<\/?.*?>/g, '')
-        .trim()
-        .replace(/^/, '* ');
-    }
-  });
-}
-
-/*
-1. Remove image alts, otherwise they will be visible in a book
-2. Fix asset paths
-*/
-function fixImages(processor) {
-  return ast => visit(ast, 'image', node => {
-    node.alt = null;
-    node.url = node.url.replace(/^\/assets\//, './assets/');
-  });
-}
\ No newline at end of file
diff --git a/test/package.json b/test/package.json
index 030274bc158..f04cd907f11 100644
--- a/test/package.json
+++ b/test/package.json
@@ -3,14 +3,9 @@
   "devDependencies": {
     "async": "^2.0.0",
     "dictionary-en-us": "^2.0.0",
-    "download": "^5.0.3",
-    "ebrew": "^0.2.3",
-    "fastmatter": "^1.1.1",
     "glob": "^7.0.5",
     "ignore": "^3.1.3",
     "js-yaml": "^3.6.1",
-    "kindlegen": "^1.1.0",
-    "mkdirp": "^0.5.1",
     "remark-frontmatter": "^1.1.0",
     "remark-lint": "^6.0.0",
     "remark-lint-blockquote-indentation": "^1.0.0",
@@ -56,10 +51,8 @@
     "retext-syntax-mentions": "^1.1.0",
     "retext-syntax-urls": "^1.0.0",
     "retext-words": "bkeepers/retext-words",
-    "slug": "^0.9.1",
     "to-vfile": "^2.1.0",
     "unified": "^6.1.0",
-    "unist-util-visit": "^1.1.1",
     "vfile-reporter": "^4.0.0",
     "vfile-statistics": "^1.0.0"
   }

From 28187061467020fbb02f51a12f43581c76aadc8a Mon Sep 17 00:00:00 2001
From: Deletor <annco88@gmail.com>
Date: Wed, 22 Dec 2021 20:28:31 +0100
Subject: [PATCH 303/749] Improved translation and grammar

---
 _articles/pl/building-community.md | 50 +++++++++++++++---------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/_articles/pl/building-community.md b/_articles/pl/building-community.md
index 3f0001c15f0..dfe32b40d59 100644
--- a/_articles/pl/building-community.md
+++ b/_articles/pl/building-community.md
@@ -33,7 +33,7 @@ Zacznij od dokumentacji:
 [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.
 
 * **Gdy ktoś nowy wyląduje w twoim projekcie, podziękuj mu za zainteresowanie!** Wystarczy jedno negatywne doświadczenie, aby ktoś już nie chciał wracać.
-* **Reaguj szybko.** Jeśli nie odpowiesz na ich problem przez miesiąc, są szanse, że już zapomnną o twoim projekcie.
+* **Reaguj szybko.** Jeśli nie odpowiesz na ich problem przez miesiąc, są duże szanse, że zapomnną o twoim projekcie.
 * **Miej otwarty umysł na typy wkładów, które akceptujesz.** Wielu autorów zaczyna od zgłoszenia błędu lub drobnej poprawki. Istnieje [wiele sposobów na wniesienie wkładu](../how-to-contribute/#co-to-znaczy-przyczynić-się) do projektu. Pozwól ludziom pomóc, jak chcą pomóc.
 * **Jeśli masz wkład, z którym się nie zgadzasz,** podziękuj im za pomysł i [wyjaśnij dlaczego](../best-practices/#naucz-się-mówić-nie) to nie pasuje do zakresu projektu, zawierając link do odpowiedniej dokumentacji.
 
@@ -47,9 +47,9 @@ Zacznij od dokumentacji:
   </p>
 </aside>
 
-Większość współpracowników open source to „przypadkowi współpracownicy”: ludzie, którzy przyczyniają się do projektu tylko sporadycznie. Przypadkowy współpracownik może nie mieć czasu, aby w pełni przyspieszyć swój projekt, więc Twoim zadaniem jest ułatwienie im wnoszenia wkładu.
+Większość współpracowników open source to „przypadkowi współpracownicy”: ludzie, którzy przyczyniają się do projektu tylko sporadycznie. Przypadkowy współpracownik może nie mieć czasu, aby w pełni przyspieszyć Twój projekt, więc Twoim zadaniem jest ułatwienie im wnoszenia wkładu.
 
-Zachęcanie innych współpracowników to także inwestycja w ciebie. Gdy umożliwisz swoim największym fanom bieganie z pracą, którą są podekscytowani, zmniejszysz presję, aby zrobić wszystko sam.
+Zachęcanie innych współpracowników to także inwestycja w ciebie. Gdy umożliwisz swoim największym fanom bieganie z pracą, którą są podekscytowani, zmniejszysz presję, aby robić wszystko sam.
 
 ### Wszystko dokumentuj
 
@@ -67,21 +67,21 @@ Kiedy zaczynasz nowy projekt, naturalne może być zachowanie prywatności w pra
 
 Kiedy spisujesz rzeczy, więcej osób może brać udział na każdym etapie. Możesz uzyskać pomoc dotyczącą czegoś, o czym nawet nie wiedziałeś, że potrzebujesz.
 
-Zapisywanie rzeczy to coś więcej niż dokumentacja techniczna. Za każdym razem, gdy poczujesz potrzebę napisania czegoś lub prywatnie przedyskutuj swój projekt, zadaj sobie pytanie, czy możesz to upublicznić.
+Zapisywanie rzeczy to coś więcej niż dokumentacja techniczna. Za każdym razem, gdy poczujesz potrzebę coś zapisać lub prywatnie przedyskutować swój projekt, zadaj sobie pytanie, czy możesz to upublicznić.
 
 Zachowaj przejrzystość na temat planu projektu, rodzajów wkładów, których szukasz, sposobu ich sprawdzania lub powodów, dla których podjąłeś określone decyzje.
 
 Jeśli zauważysz, że wielu użytkowników napotyka ten sam problem, udokumentuj odpowiedzi w pliku README.
 
-W przypadku spotkań rozważ opublikowanie notatek lub wynos w odpowiednim numerze. Informacje zwrotne uzyskane z tego poziomu przejrzystości mogą Cię zaskoczyć.
+W przypadku spotkań rozważ opublikowanie swoich notatek lub treści w odpowiednim wydaniu. Uzyskane informacje zwrotne mogą Cię zaskoczyć.
 
 Dokumentowanie wszystkiego dotyczy także wykonywanej pracy. Jeśli pracujesz nad istotną aktualizacją projektu, prześlij ją do pull requesta i oznacz jako trwającą (WIP). W ten sposób inne osoby mogą wcześnie poczuć się zaangażowane w ten proces.
 
 ### Bądź responsywny
 
-Jak [promujesz swój projekt](../finding-users/), ludzie będą mieli dla ciebie opinie. Mogą mieć pytania dotyczące sposobu działania lub potrzebują pomocy na początku.
+Gdy [promujesz swój projekt](../finding-users/), ludzie będą mieli dla ciebie opinie. Mogą mieć pytania dotyczące sposobu działania lub potrzebują pomocy na początku.
 
-Postaraj się reagować, gdy ktoś zgłosi problem, prześle pull request lub zadaje pytanie o Twój projekt. Gdy odpowiesz szybko, ludzie poczują, że są częścią dialogu i będą bardziej entuzjastycznie nastawieni do uczestnictwa.
+Postaraj się reagować, gdy ktoś zgłosi problem, prześle pull request lub zadaje pytanie o Twój projekt. Gdy odpowiesz szybko, ludzie poczują, że są częścią dialogu i będą bardziej entuzjastycznie nastawieni do uczestnictwa w projekcie.
 
 Nawet jeśli nie możesz natychmiast przejrzeć żądania, jego wcześniejsze potwierdzenie pomaga zwiększyć zaangażowanie. Oto jak @tdreyno odpowiedział na pull request na [Middleman](https://github.com/middleman/middleman/pull/1466):
 
@@ -95,11 +95,11 @@ Rozmowy na temat Twojego projektu mogą odbywać się również w innych miejsca
 
 Istnieją dwa powody, aby dać społeczności możliwość gromadzenia się.
 
-Pierwszy powód jest dla nich. Pomóż ludziom się poznać. Ludzie o wspólnych zainteresowaniach nieuchronnie będą chcieli o tym porozmawiać. A gdy komunikacja jest publiczna i dostępna, każdy może czytać poprzednie archiwa, aby przyspieszyć i wziąć udział.
+Pierwszy powód jest dla nich. Pomóż ludziom się poznać. Ludzie o wspólnych zainteresowaniach będą chcieli o tym porozmawiać. A gdy komunikacja jest publiczna i dostępna, każdy może czytać archiwa, aby zapoznać się z projektem i wziąć w nim udział.
 
-Drugi powód jest dla ciebie. Jeśli nie dasz ludziom publicznego miejsca na rozmowę o twoim projekcie, prawdopodobnie skontaktują się z tobą bezpośrednio. Na początku może wydawać się dość łatwe odpowiadanie na prywatne wiadomości „tylko raz”. Ale z czasem, szczególnie jeśli twój projekt stanie się popularny, poczujesz się wyczerpany. Oprzyj się pokusie prywatnego komunikowania się z ludźmi na temat twojego projektu. Zamiast tego skieruj je do wyznaczonego kanału publicznego.
+Drugi powód jest dla ciebie. Jeśli nie dasz ludziom publicznego miejsca na rozmowę o twoim projekcie, prawdopodobnie skontaktują się z tobą bezpośrednio. Na początku może wydawać się dość łatwe odpowiadanie na prywatne wiadomości „tylko raz”. Ale z czasem, szczególnie jeśli twój projekt stanie się popularny, poczujesz się wyczerpany. Oprzyj się pokusie prywatnego komunikowania się z ludźmi na temat twojego projektu. Zamiast tego skieruj ich do wyznaczonego kanału publicznego.
 
-Komunikacja publiczna może być tak prosta, jak nakłanianie ludzi do otwarcia problemu zamiast bezpośredniego wysyłania e-maili lub komentowania na blogu. Możesz także skonfigurować listę mailingową lub utworzyć konto na Twitterze, Slack lub kanał IRC, aby ludzie mogli porozmawiać o twoim projekcie. Lub wypróbuj wszystkie powyższe!
+Komunikacja publiczna może być tak prosta, jak nakłanianie ludzi do otwarcia problemu zamiast bezpośredniego wysyłania e-maili lub komentowania na blogu. Możesz także skonfigurować listę mailingową lub utworzyć konto na Twitterze, Slack lub kanał IRC, aby ludzie mogli rozmawiać o twoim projekcie. Lub wypróbuj wszystkie powyższe!
 
 [Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) co drugi tydzień przeznacza godziny urzędowania, aby pomóc członkom społeczności:
 
@@ -109,13 +109,13 @@ Ważnymi wyjątkami od komunikacji publicznej są: 1) kwestie bezpieczeństwa i
 
 ## Rozwijanie społeczności
 
-Społeczności są niezwykle potężne. Ta moc może być błogosławieństwem lub przekleństwem, w zależności od tego, jak ją władasz. Gdy społeczność twojego projektu rośnie, istnieją sposoby, aby pomóc mu stać się siłą budowy, a nie zniszczenia.
+Społeczności są niezwykle potężne. Ta moc może być błogosławieństwem lub przekleństwem, w zależności od tego, jak ją władasz. Gdy społeczność twojego projektu rośnie, istnieją sposoby, aby pomócjej stać się siłą kontruktywną, a nie destruktywną.
 
 ### Nie toleruj złych aktorów
 
-Każdy popularny projekt nieuchronnie przyciągnie ludzi, którzy krzywdzą, a nie pomagają twojej społeczności. Mogą rozpocząć niepotrzebne debaty, pokłócić się z trywialnymi funkcjami lub zastraszyć innych.
+Każdy popularny projekt nieuchronnie przyciągnie ludzi, którzy bardziej szkodzą niż pomagają twojej społeczności. Mogą rozpocząć niepotrzebne debaty, spierać się o trywialne funkcje lub zastraszać innych.
 
-Staraj się przyjąć politykę zerowej tolerancji dla tego rodzaju ludzi. Jeśli pozostanie niezaznaczone, negatywni ludzie sprawią, że inni ludzie w Twojej społeczności będą się niekomfortowo Mogą nawet odejść.
+Staraj się przyjąć politykę zerowej tolerancji dla tego rodzaju ludzi. Jeśli takie zachowanie pozostanie niezauważone, negatywni ludzie sprawią, że inni ludzie w Twojej społeczności będą czuć się niekomfortowo. Mogą nawet odejść.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
@@ -127,7 +127,7 @@ Staraj się przyjąć politykę zerowej tolerancji dla tego rodzaju ludzi. Jeśl
   </p>
 </aside>
 
-Regularne debaty na temat trywialnych aspektów projektu odwracają uwagę innych, w tym ciebie, od koncentrowania się na ważnych zadaniach. Nowe osoby, które przybędą do Twojego projektu, mogą zobaczyć te rozmowy i nie chcą brać udziału.
+Regularne debaty na temat trywialnych aspektów projektu odwracają uwagę innych, w tym ciebie, od koncentrowania się na ważnych zadaniach. Nowe osoby, które przybędą do Twojego projektu, mogą zobaczyć te rozmowy i nie chcą brać w nich udziału.
 
 Kiedy zobaczysz negatywne zachowanie w twoim projekcie, wywołaj to publicznie. Wyjaśnij, życzliwym, ale zdecydowanym tonem, dlaczego ich zachowanie jest nie do przyjęcia. Jeśli problem będzie się powtarzał, być może będziesz musiał [poprosić ich o odejście](https://github.com/mbiesiad/opensource.guide/blob/pl/_articles/code-of-conduct.md/#enforcing-your-code-of-conduct). Twój [kodeks postępowania](../code-of-conduct/) może być konstruktywnym przewodnikiem dla tych rozmów.
 
@@ -161,7 +161,7 @@ Na przykład oto jak [Rubinius](https://github.com/rubinius/rubinius/) zaczyna [
   </p>
 </aside>
 
-Ludzie są podekscytowani, że mogą uczestniczyć w projektach, kiedy mają poczucie własności. Nie oznacza to, że musisz zmienić wizję swojego projektu lub zaakceptować wkład, którego nie chcesz. Ale im więcej dajesz uznanie innym, tym bardziej będą się trzymać.
+Ludzie są podekscytowani, że mogą uczestniczyć w projektach, kiedy mają poczucie własności. Nie oznacza to, że musisz zmienić wizję swojego projektu lub zaakceptować wkład, którego nie chcesz. Ale im więcej dajesz uznania innym, tym bardziej będą się trzymać.
 
 Sprawdź, czy możesz w jak największym stopniu znaleźć sposób na dzielenie się własnością ze społecznością. Oto kilka pomysłów:
 
@@ -173,7 +173,7 @@ Sprawdź, czy możesz w jak największym stopniu znaleźć sposób na dzielenie
 
 * Jeśli masz sporą społeczność, **wyślij biuletyn lub napisz post na blogu** dziękując autorom. Rusta [This Week in Rust](https://this-week-in-rust.org/) i Hoodie'ego [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) są dwoma dobrymi przykładami
 
-* **Daj dostęp każdemu współautorowi.** @felixge stwierdził, że to sprawiło, że ludzie [bardziej podekscytowani polerowaniem 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ł.
+* **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.
 
@@ -203,7 +203,7 @@ W większości przypadków, jeśli kultywujesz przyjazną, pełną szacunku spo
 
 Gdy Twoja społeczność zmaga się z trudnym problemem, temperament może wzrosnąć. Ludzie mogą się złościć lub sfrustrować i wyładowywać się na sobie nawzajem lub na tobie.
 
-Twoim zadaniem jako opiekuna jest zapobieganie eskalacji tych sytuacji. Nawet jeśli masz silną opinię na ten temat, spróbuj zająć stanowisko moderatora lub facylitatora, zamiast skakać do walki i popychać swoje poglądy. Jeśli ktoś jest nieuprzejmy lub monopolizuje rozmowę, [działaj natychmiast](https://github.com/mbiesiad/opensource.guide/blob/pl/_articles/building-community.md/#dont-tolerate-bad-actors) aby dyskusje były spokojne i owocne.
+Twoim zadaniem jako opiekuna jest zapobieganie eskalacji tych sytuacji. Nawet jeśli masz silną opinię na ten temat, spróbuj zająć stanowisko moderatora lub facylitatora, zamiast wskakiwać do walki i forsować swoje poglądy. Jeśli ktoś jest nieuprzejmy lub monopolizuje rozmowę, [działaj natychmiast](https://github.com/mbiesiad/opensource.guide/blob/pl/_articles/building-community.md/#dont-tolerate-bad-actors) aby dyskusje były spokojne i owocne.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
@@ -225,7 +225,7 @@ Twój plik README to [więcej niż tylko zestaw instrukcji](../starting-a-projec
 
 ### Skoncentruj się na podróży, a nie na celu
 
-Niektóre projekty wykorzystują proces głosowania do podejmowania ważnych decyzji. Na pierwszy rzut oka rozsądne, ale głosowanie kładzie nacisk na dotarcie do „odpowiedzi”, a nie na wzajemne słuchanie i rozwiązywanie problemów.
+Niektóre projekty wykorzystują proces głosowania do podejmowania ważnych decyzji. Na pierwszy rzut oka to jest rozsądne, ale głosowanie kładzie nacisk na dotarcie do „odpowiedzi”, a nie na wzajemnym słuchaniu i rozwiązywaniu problemów.
 
 Głosowanie może mieć charakter polityczny, w którym członkowie społeczności czują się zmuszeni do wzajemnego wyświadczania przysług lub głosowania w określony sposób. Nie wszyscy też głosują, czy też jest to [cicha większość](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) w Twojej społeczności lub obecni użytkownicy, którzy nie wiedzieli, że głosowanie ma miejsce.
 
@@ -243,17 +243,17 @@ W ramach procesu poszukiwania konsensusu członkowie społeczności omawiają g
   </p>
 </aside>
 
-Nawet jeśli tak naprawdę nie przyjmujesz procesu poszukiwania konsensusu, jako opiekun projektu ważne jest, aby ludzie wiedzieli, że słuchasz. Sprawienie, by inni poczuli się wysłuchani i zobowiązanie się do rozwiązania swoich problemów, znacznie przyczynia się do rozproszenia wrażliwych sytuacji. Następnie postępuj zgodnie ze swoimi słowami za pomocą działań.
+Nawet jeśli tak naprawdę nie przyjmujesz procesu poszukiwania konsensusu, jako opiekun projektu ważne jest, aby ludzie wiedzieli, że słuchasz. Sprawienie, by inni poczuli się wysłuchani i zobowiązanie się do rozwiązania ich obaw, znacznie przyczynia się do rozproszenia wrażliwych sytuacji. Następnie postępuj zgodnie ze swoimi słowami za pomocą działań.
 
-Nie spiesz się z decyzją ze względu na rozwiązanie. Upewnij się, że wszyscy czują się słyszani i że wszystkie informacje zostały upublicznione przed przejściem do rozwiązania.
+Nie spiesz się z decyzją. Upewnij się, że wszyscy czują się wysłuchani i że wszystkie informacje zostały upublicznione przed przejściem do rozwiązania.
 
 ### Skoncentruj rozmowę na działaniu
 
 Dyskusja jest ważna, ale istnieje różnica między produktywnymi i nieproduktywnymi rozmowami.
 
-Zachęcaj do dyskusji, o ile aktywnie dąży do rozwiązania. Jeśli jest oczywiste, że rozmowa gubi się lub odchodzi od tematu, dźgnięcia stają się osobiste lub ludzie kłócą się o drobne szczegóły, nadszedł czas, aby je zamknąć.
+Zachęcaj do dyskusji, o ile aktywnie dąży ona do rozwiązania problemu. Jeśli jest oczywiste, że rozmowa gubi się lub odchodzi od tematu, dźgnięcia stają się osobiste lub ludzie kłócą się o drobne szczegóły, nadszedł czas, aby ją zamknąć.
 
-Zezwolenie na kontynuowanie tych rozmów jest nie tylko szkodliwe dla omawianego problemu, ale także niekorzystne dla zdrowia Twojej społeczności. Wysyła wiadomość, że tego rodzaju rozmowy są dozwolone, a nawet zachęcane, i może zniechęcać ludzi do podnoszenia lub rozwiązywania przyszłych problemów.
+Zezwolenie na kontynuowanie tych rozmów jest nie tylko szkodliwe dla omawianego problemu, ale także niekorzystne dla Twojej społeczności. Wysyła wiadomość, że tego rodzaju rozmowy są dozwolone, a nawet zachęcane, i może zniechęcać ludzi do podnoszenia lub rozwiązywania przyszłych problemów.
 
 W każdym punkcie przedstawionym przez ciebie lub przez innych zadawaj sobie pytanie: _"W jaki sposób zbliża nas to do rozwiązania?"_
 
@@ -271,9 +271,9 @@ Jeśli rozmowa najwyraźniej nigdzie się nie kończy, nie ma wyraźnych działa
   </p>
 </aside>
 
-### Wybierz mądrze swoje bitwy
+### Mądrze wybieraj swoje bitwy
 
-Kontekst jest ważny. Zastanów się, kto jest zaangażowany w dyskusję i jak reprezentują resztę społeczności.
+Kontekst jest ważny. Zastanów się, kto jest zaangażowany w dyskusję i jak reprezentuje resztę społeczności.
 
 Czy wszyscy w społeczności są zaniepokojeni, czy nawet zaangażowani w ten problem? A może samotny problemator? Nie zapomnij wziąć pod uwagę swoich cichych członków społeczności, a nie tylko aktywnych głosów.
 
@@ -289,4 +289,4 @@ Twój remis powinien być ostatecznością. Problemy dzielące są szansą dla T
 
 ## Społeczność jest ❤️ open source
 
-Zdrowe, dobrze prosperujące społeczności napędzają tysiące godzin wkładanych w open source każdego tygodnia. Wielu współautorów wskazuje inne osoby jako powód do pracy - lub nie - pracy na otwartym oprogramowaniu. Ucząc się, jak konstruktywnie wykorzystać tę moc, pomożesz komuś, aby doświadczył niezapomnianych wrażeń open source.
+Zdrowe, dobrze prosperujące społeczności napędzają tysiące godzin wkładanych w open source każdego tygodnia. Wielu współautorów wskazuje inne osoby jako powód do pracy - lub nie - nad otwartym oprogramowaniem. Ucząc się, jak konstruktywnie wykorzystać tę moc, pomożesz komuś, aby doświadczył niezapomnianych wrażeń open source.

From 1e7e4999f0045cae0c81c7d894ddbe6fd719ade6 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 28 Dec 2021 09:04:11 +0000
Subject: [PATCH 304/749] Bump github-pages from 222 to 223

Bumps [github-pages](https://github.com/github/pages-gem) from 222 to 223.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v222...v223)

---
updated-dependencies:
- dependency-name: github-pages
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 319e8a58cc1..87c1bd6cb37 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (6.0.4.1)
+    activesupport (6.0.4.4)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
@@ -48,7 +48,7 @@ GEM
     ffi (1.15.4)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (222)
+    github-pages (223)
       github-pages-health-check (= 1.17.9)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
@@ -58,6 +58,7 @@ GEM
       jekyll-feed (= 0.15.1)
       jekyll-gist (= 1.5.0)
       jekyll-github-metadata (= 2.13.0)
+      jekyll-include-cache (= 0.2.1)
       jekyll-mentions (= 1.6.0)
       jekyll-optional-front-matter (= 0.3.2)
       jekyll-paginate (= 1.1.0)
@@ -146,6 +147,8 @@ GEM
     jekyll-github-metadata (2.13.0)
       jekyll (>= 3.4, < 5.0)
       octokit (~> 4.0, != 4.4.0)
+    jekyll-include-cache (0.2.1)
+      jekyll (>= 3.7, < 5.0)
     jekyll-mentions (1.6.0)
       html-pipeline (~> 2.3)
       jekyll (>= 3.7, < 5.0)
@@ -232,7 +235,7 @@ GEM
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
-    minitest (5.14.4)
+    minitest (5.15.0)
     multipart-post (2.1.1)
     nokogiri (1.12.5)
       mini_portile2 (~> 2.6.1)
@@ -279,7 +282,7 @@ GEM
     unf_ext (0.0.8)
     unicode-display_width (1.8.0)
     yell (2.2.2)
-    zeitwerk (2.5.1)
+    zeitwerk (2.5.2)
 
 PLATFORMS
   ruby

From fe11e0767e599b24bad49849b3dca03eba75b852 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 29 Dec 2021 09:08:15 +0000
Subject: [PATCH 305/749] Bump actions/setup-node from 2.5.0 to 2.5.1

Bumps [actions/setup-node](https://github.com/actions/setup-node) from 2.5.0 to 2.5.1.
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/v2.5.0...v2.5.1)

---
updated-dependencies:
- dependency-name: actions/setup-node
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index adc5936e24b..c9e01e903a6 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -14,7 +14,7 @@ jobs:
       uses: actions/setup-ruby@v1.1.3
 
     - name: Set up Node
-      uses: actions/setup-node@v2.5.0
+      uses: actions/setup-node@v2.5.1
 
     - name: Restore bundler cache
       uses: actions/cache@v2.1.7

From 7c264a05e1e056b127d8400e8b72e4a7650a7538 Mon Sep 17 00:00:00 2001
From: gsyx666 <59297143+gsyx666@users.noreply.github.com>
Date: Mon, 3 Jan 2022 11:44:59 +0800
Subject: [PATCH 306/749] Update legal.md

Make translation more native
---
 _articles/zh-hans/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index 28bfca47a9d..a9cb908de12 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -13,7 +13,7 @@ redirect_from: /zh-cn/legal/
 
 ## 理解开源的法律含义
 
-向世界分享你们具有创造性的工作，是一个多么令人激动和有价值的经历。这也意味着你们必须担心一堆你们不清楚的法律问题。幸运的是，你们不必从头开始。我们已经涵盖了你们的法律需求。（在你们行动前，请确定阅读了我们的[免责声明](/notices/)。）
+向世界分享你们具有创造性的工作，是一个多么令人激动和有价值的经历。然而这也意味着你们必须担心一堆你们不清楚的法律问题。幸运的是，你们不必从头开始。我们已经涵盖了你们的法律需求。（在你们行动前，请确定阅读了我们的[免责声明](/notices/)。）
 
 ## 为什么人们这么关心开源的法律方面问题？
 

From 1dfbf85198c178413bc658026fbb958f5308dbed Mon Sep 17 00:00:00 2001
From: mdiazfreire <61229679+mdiazfreire@users.noreply.github.com>
Date: Mon, 3 Jan 2022 16:47:00 +0100
Subject: [PATCH 307/749] =?UTF-8?q?Correcci=C3=B3n=20de=20error=20tipogr?=
 =?UTF-8?q?=C3=A1fico?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

En la sección "Abriendo un pull request" uno de los pasos para abrir un pull request dice "¡Has pruebas de tus cambios!". La palabra "Has" debería ser "Haz" (forma correcta del imperativo del verbo hacer).
---
 _articles/es/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/es/how-to-contribute.md b/_articles/es/how-to-contribute.md
index 4df58790356..36d37673e05 100644
--- a/_articles/es/how-to-contribute.md
+++ b/_articles/es/how-to-contribute.md
@@ -480,7 +480,7 @@ Si el proyecto est&aacute; alojado en GITHUB, ac&aacute; te explicamos los pasos
 * **[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.
-* **¡Has pruebas de tus cambios!** Corre tus cambios contra las pruebas existentes si realmente existen, y crea nuevas pruebas si es necesario. Sin importar que existan o no las pruebas, aseg&uacute;rate que tus cambios no produzcan roturas del proyecto existente.
+* **¡Haz pruebas de tus cambios!** Corre tus cambios contra las pruebas existentes si realmente existen, y crea nuevas pruebas si es necesario. Sin importar que existan o no las pruebas, aseg&uacute;rate que tus cambios no produzcan roturas del proyecto existente.
 * **Contribuye con el estilo del proyecto** con el m&aacute;ximo de tus capacidades. Esto significa utilizar indentaci&oacute;n, punto y comas o comentarios de manera diferente a lo que har&iacute;as en tu repositorio, pero que hacen m&aacute;s sencillo para los responsables combinar y para otros de entender y mantener el proyecto en el futuro.
 
 Si se trata de tu primer pull request, verifica [Haz un Pull Request](http://makeapullrequest.com/), que fue creado por @kentcdodds como un recurso de recorrido gratuito.

From ccc7950f5ac907edff18d011565dedf5a185f6d9 Mon Sep 17 00:00:00 2001
From: Roma Karvacky <64963734+yesnoruly@users.noreply.github.com>
Date: Wed, 5 Jan 2022 12:29:24 +0200
Subject: [PATCH 308/749] fix: correct word duplication

---
 _articles/ru/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index 89fbc588238..163aa6127ea 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -451,7 +451,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
-  Вы многое узнаете <em>многому</em> о проекте, который вы активно используете, если "понаблюдаете" за ним на GitHub и просмотрите все ишью и PR.
+  Вы <em>многое</em> узнаете о проекте, который вы активно используете, если "понаблюдаете" за ним на GitHub и просмотрите все ишью и PR.
 <p markdown="1" class="pquote-credit">
 - @gaearon [о присоединении к проектам](https://twitter.com/dan_abramov/status/819555257055322112)
   </p>

From ec9ef7037b2401aaa886a0b5a59a713a4b41a292 Mon Sep 17 00:00:00 2001
From: Roma Karvacky <64963734+yesnoruly@users.noreply.github.com>
Date: Wed, 5 Jan 2022 18:30:45 +0200
Subject: [PATCH 309/749] fix: case trouble

---
 _articles/ru/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index 163aa6127ea..da62f081322 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -461,7 +461,7 @@ related:
 
 Как правило, следует создать ишью чтобы:
 
-* Сообщить об ошибке, которую вы нельзя исправить самостоятельно
+* Сообщить об ошибке, которую вы не можете исправить самостоятельно
 * Обсудить общую тему или идею (например, связанную с сообществом, развитием или политикой проекта)
 * Предложить реализовать новую функциональность или другую идею проекта
 

From 28757f900d5e76bd36c093feaaff050c4b64552a Mon Sep 17 00:00:00 2001
From: Fabiano Leite <fabianoleittes@gmail.com>
Date: Tue, 11 Jan 2022 17:05:10 -0400
Subject: [PATCH 310/749] chore: :pencil: change branch name from master to
 main

---
 _articles/pt/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md
index f1c4ffd678b..4f2939e754d 100644
--- a/_articles/pt/how-to-contribute.md
+++ b/_articles/pt/how-to-contribute.md
@@ -236,7 +236,7 @@ Aqui está um checklist útil para avaliar se um projeto é bom para novos contr
 
 **O projeto aceita contribuições ativamente**
 
-Veja a atividade de commit no branch master. No GitHub, você pode ver essas informações na página inicial de um repositório.
+Veja a atividade de commit no branch main. No GitHub, você pode ver essas informações na página inicial de um repositório.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">

From ddb975a0124a5da2d2e2776f1fb1432d6abd7d53 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Thu, 27 Jan 2022 21:20:34 +0100
Subject: [PATCH 311/749] Remove unneeded action steps

The bundler-cache option for setting up ruby does the job of running bundle install and caching gems
---
 .github/workflows/tests.yml | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index c9e01e903a6..79acf6e26e7 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,18 +11,13 @@ jobs:
       uses: actions/checkout@v2.4.0
 
     - name: Set up Ruby
-      uses: actions/setup-ruby@v1.1.3
+      uses: ruby/setup-ruby@v1
+      with:
+        bundler-cache: true
 
     - name: Set up Node
       uses: actions/setup-node@v2.5.1
 
-    - name: Restore bundler cache
-      uses: actions/cache@v2.1.7
-      with:
-        path: vendor/gems
-        key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
-        restore-keys: ${{ runner.os }}-gems-
-
     - name: Bootstrap
       run: script/bootstrap
 

From b8da8e7dd246f52e8ca040a91a0f13b8e9e6bf32 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Thu, 27 Jan 2022 21:22:24 +0100
Subject: [PATCH 312/749] Create .ruby-version

---
 .ruby-version | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 .ruby-version

diff --git a/.ruby-version b/.ruby-version
new file mode 100644
index 00000000000..fd2a01863fd
--- /dev/null
+++ b/.ruby-version
@@ -0,0 +1 @@
+3.1.0

From 444be045e39ef0cdb85d8898a4f84e204e479e64 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Thu, 27 Jan 2022 21:25:16 +0100
Subject: [PATCH 313/749] Update .ruby-version

---
 .ruby-version | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.ruby-version b/.ruby-version
index fd2a01863fd..a603bb50a29 100644
--- a/.ruby-version
+++ b/.ruby-version
@@ -1 +1 @@
-3.1.0
+2.7.5

From f2ff696fad54189f0242a26bed7754b916ecca38 Mon Sep 17 00:00:00 2001
From: Igor Zubiaurre <fioddor@gmail.com>
Date: Tue, 8 Feb 2022 12:35:10 +0100
Subject: [PATCH 314/749] Add "More..." chapter

Link to the CHAOSS community, as it is very relevant for open source metrics around open source development.
---
 _articles/metrics.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/_articles/metrics.md b/_articles/metrics.md
index 5b266ccf8cc..f7925bfd6d1 100644
--- a/_articles/metrics.md
+++ b/_articles/metrics.md
@@ -124,3 +124,7 @@ You could also measure the time it takes to move between stages in the contribut
 ## Use 📊 to learn about people
 
 Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+
+## More...
+
+There's a welcoming open source community around open source metrics, called [CHAOSS](https://chaoss.community/), in case you have doubts or want to dive deeper. They develop metrics and provide free software tools.

From 7188d0f2ab8d3bc0788a8199eaaffaf17a9043be Mon Sep 17 00:00:00 2001
From: Igor Zubiaurre <fioddor@gmail.com>
Date: Mon, 14 Feb 2022 19:36:13 +0100
Subject: [PATCH 315/749] Simplify as suggested in code review

Co-authored-by: Mike McQuaid <mike@mikemcquaid.com>
---
 _articles/metrics.md | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/_articles/metrics.md b/_articles/metrics.md
index f7925bfd6d1..78c094f878a 100644
--- a/_articles/metrics.md
+++ b/_articles/metrics.md
@@ -125,6 +125,4 @@ You could also measure the time it takes to move between stages in the contribut
 
 Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
 
-## More...
-
-There's a welcoming open source community around open source metrics, called [CHAOSS](https://chaoss.community/), in case you have doubts or want to dive deeper. They develop metrics and provide free software tools.
+[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health.

From 5abecc1f161ae9081d09c601313bfd231b9b8c1c Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 25 Feb 2022 09:08:23 +0000
Subject: [PATCH 316/749] Bump actions/setup-node from 2.5.1 to 3

Bumps [actions/setup-node](https://github.com/actions/setup-node) from 2.5.1 to 3.
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/v2.5.1...v3)

---
updated-dependencies:
- dependency-name: actions/setup-node
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 79acf6e26e7..a240f1f2f4e 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -16,7 +16,7 @@ jobs:
         bundler-cache: true
 
     - name: Set up Node
-      uses: actions/setup-node@v2.5.1
+      uses: actions/setup-node@v3
 
     - name: Bootstrap
       run: script/bootstrap

From 45308ca979453cadeab19dab9d795f62e3e68565 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Sat, 26 Feb 2022 03:41:14 +0000
Subject: [PATCH 317/749] Bump nokogiri from 1.12.5 to 1.13.3

Bumps [nokogiri](https://github.com/sparklemotion/nokogiri) from 1.12.5 to 1.13.3.
- [Release notes](https://github.com/sparklemotion/nokogiri/releases)
- [Changelog](https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md)
- [Commits](https://github.com/sparklemotion/nokogiri/compare/v1.12.5...v1.13.3)

---
updated-dependencies:
- dependency-name: nokogiri
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 87c1bd6cb37..a335540dcde 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -230,15 +230,15 @@ GEM
       rb-fsevent (~> 0.10, >= 0.10.3)
       rb-inotify (~> 0.9, >= 0.9.10)
     mercenary (0.3.6)
-    mini_portile2 (2.6.1)
+    mini_portile2 (2.8.0)
     minima (2.5.1)
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
     minitest (5.15.0)
     multipart-post (2.1.1)
-    nokogiri (1.12.5)
-      mini_portile2 (~> 2.6.1)
+    nokogiri (1.13.3)
+      mini_portile2 (~> 2.8.0)
       racc (~> 1.4)
     octokit (4.21.0)
       faraday (>= 0.9)

From d90834f8775e61aa950e58ddfab056cd73b13c71 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 2 Mar 2022 09:15:35 +0000
Subject: [PATCH 318/749] Bump actions/checkout from 2.4.0 to 3

Bumps [actions/checkout](https://github.com/actions/checkout) from 2.4.0 to 3.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v2.4.0...v3)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 79acf6e26e7..1a1e08ef3a7 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -8,7 +8,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
     - name: Set up Git repository
-      uses: actions/checkout@v2.4.0
+      uses: actions/checkout@v3
 
     - name: Set up Ruby
       uses: ruby/setup-ruby@v1

From d67f0af0b4ebdde18b64bb56742fdae3db313eac Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Thu, 3 Mar 2022 09:10:11 +0000
Subject: [PATCH 319/749] fa/starting-a-project: fix anchor.

---
 _articles/fa/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md
index af534e3d336..4cd9ebb47f7 100644
--- a/_articles/fa/starting-a-project.md
+++ b/_articles/fa/starting-a-project.md
@@ -20,7 +20,7 @@ related:
 
 پروژه‌های متن باز قدرتمند هستند، چون موانعی که در اختیارات و مشارکت‌ها دیده می‌شود را کاهش و به افراد اجازه می‌دهد پروژه‌های خود را به سرعت گستردش و بهبود دهند. یکی دیگر از دلایل قدرتمند بودن متن بازها این است که پتانسیل کنترل محاسبه را بسته به منابع محدود به کاربران می‌دهد. اگر بخواهیم برای روشن شدن مطلب نمونه‌ای بیاوریم، می‌توانیم به کسب‌وکارهایی اشاره کنیم که به جای تکیه بر منابع محصور و محدود محصولات انحصاری فروشنده‌های نرم‌افزار، از نرم‌افزارهای متن بازی استفاده می‌کنند که به آن‌ها اجازه می‌دهد شخصی را استخدام کنند تا آن نرم‌افزار را برای آن‌ها شخصی‌سازی یا بهینه کند.
 
-_نرم‌افزارهای رایگان_ همچنین به پروژه‌های متن باز منسوب می‌شود. گاهی هم ممکن است برنامه‌هایی ببینید که [ترکیبی](https://en.wikipedia.org/wiki/Free_and_open-source_software) از اصلاحات «نرم‌افزار متن باز و رایگان» (FOSS) یا «نرم‌افزار متن باز، آزاد و رایگان» (FLOSS) استفاده می‌کنند. خب، باید بگوییم که کلمه‌ی _Free_ (رایگان) و _libre_ (آزاد / رایگان) هر دو به معنای آزادی در استفاده و دسترسی اطلاق می‌شود، [نه قیمت آن](#does-open-source-mean-free-of-charge)
+_نرم‌افزارهای رایگان_ همچنین به پروژه‌های متن باز منسوب می‌شود. گاهی هم ممکن است برنامه‌هایی ببینید که [ترکیبی](https://en.wikipedia.org/wiki/Free_and_open-source_software) از اصلاحات «نرم‌افزار متن باز و رایگان» (FOSS) یا «نرم‌افزار متن باز، آزاد و رایگان» (FLOSS) استفاده می‌کنند. خب، باید بگوییم که کلمه‌ی _Free_ (رایگان) و _libre_ (آزاد / رایگان) هر دو به معنای آزادی در استفاده و دسترسی اطلاق می‌شود، [نه قیمت آن](#آیا-پروژهای-متن-باز-مجانی--رایگان-هستند)
 
 ### چرا مردم پروژه‌های‌شان را متن باز می‌کنند؟
 

From 1a68ed067fbc0a4210ccf212d4bcaf7ae116bca8 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 4 Mar 2022 09:07:20 +0000
Subject: [PATCH 320/749] Bump github-pages from 223 to 225

Bumps [github-pages](https://github.com/github/pages-gem) from 223 to 225.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](https://github.com/github/pages-gem/compare/v223...v225)

---
updated-dependencies:
- dependency-name: github-pages
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 51 ++++++++++++++++++++++++++-------------------------
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index a335540dcde..7baf2cd7345 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (6.0.4.4)
+    activesupport (6.0.4.6)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
@@ -14,10 +14,9 @@ GEM
       execjs
     coffee-script-source (1.11.1)
     colorator (1.1.0)
-    commonmarker (0.17.13)
-      ruby-enum (~> 0.5)
+    commonmarker (0.23.4)
     concurrent-ruby (1.1.9)
-    dnsruby (1.61.7)
+    dnsruby (1.61.9)
       simpleidn (~> 0.1)
     em-websocket (0.5.3)
       eventmachine (>= 0.12.9)
@@ -26,34 +25,38 @@ GEM
       ffi (>= 1.15.0)
     eventmachine (1.2.7)
     execjs (2.8.1)
-    faraday (1.8.0)
+    faraday (1.10.0)
       faraday-em_http (~> 1.0)
       faraday-em_synchrony (~> 1.0)
       faraday-excon (~> 1.1)
-      faraday-httpclient (~> 1.0.1)
+      faraday-httpclient (~> 1.0)
+      faraday-multipart (~> 1.0)
       faraday-net_http (~> 1.0)
-      faraday-net_http_persistent (~> 1.1)
+      faraday-net_http_persistent (~> 1.0)
       faraday-patron (~> 1.0)
       faraday-rack (~> 1.0)
-      multipart-post (>= 1.2, < 3)
+      faraday-retry (~> 1.0)
       ruby2_keywords (>= 0.0.4)
     faraday-em_http (1.0.0)
     faraday-em_synchrony (1.0.0)
     faraday-excon (1.1.0)
     faraday-httpclient (1.0.1)
+    faraday-multipart (1.0.3)
+      multipart-post (>= 1.2, < 3)
     faraday-net_http (1.0.1)
     faraday-net_http_persistent (1.2.0)
     faraday-patron (1.0.0)
     faraday-rack (1.0.0)
-    ffi (1.15.4)
+    faraday-retry (1.0.3)
+    ffi (1.15.5)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
-    github-pages (223)
+    github-pages (225)
       github-pages-health-check (= 1.17.9)
       jekyll (= 3.9.0)
       jekyll-avatar (= 0.7.0)
       jekyll-coffeescript (= 1.1.1)
-      jekyll-commonmark-ghpages (= 0.1.6)
+      jekyll-commonmark-ghpages (= 0.2.0)
       jekyll-default-layout (= 0.1.4)
       jekyll-feed (= 0.15.1)
       jekyll-gist (= 1.5.0)
@@ -67,7 +70,7 @@ GEM
       jekyll-relative-links (= 0.6.1)
       jekyll-remote-theme (= 0.4.3)
       jekyll-sass-converter (= 1.5.2)
-      jekyll-seo-tag (= 2.7.1)
+      jekyll-seo-tag (= 2.8.0)
       jekyll-sitemap (= 1.4.0)
       jekyll-swiss (= 1.0.0)
       jekyll-theme-architect (= 0.2.0)
@@ -131,12 +134,12 @@ GEM
     jekyll-coffeescript (1.1.1)
       coffee-script (~> 2.2)
       coffee-script-source (~> 1.11.1)
-    jekyll-commonmark (1.3.1)
-      commonmarker (~> 0.14)
-      jekyll (>= 3.7, < 5.0)
-    jekyll-commonmark-ghpages (0.1.6)
-      commonmarker (~> 0.17.6)
-      jekyll-commonmark (~> 1.2)
+    jekyll-commonmark (1.4.0)
+      commonmarker (~> 0.22)
+    jekyll-commonmark-ghpages (0.2.0)
+      commonmarker (~> 0.23.4)
+      jekyll (~> 3.9.0)
+      jekyll-commonmark (~> 1.4.0)
       rouge (>= 2.0, < 4.0)
     jekyll-default-layout (0.1.4)
       jekyll (~> 3.0)
@@ -168,7 +171,7 @@ GEM
       rubyzip (>= 1.3.0, < 3.0)
     jekyll-sass-converter (1.5.2)
       sass (~> 3.4)
-    jekyll-seo-tag (2.7.1)
+    jekyll-seo-tag (2.8.0)
       jekyll (>= 3.8, < 5.0)
     jekyll-sitemap (1.4.0)
       jekyll (>= 3.7, < 5.0)
@@ -226,7 +229,7 @@ GEM
     kramdown-parser-gfm (1.1.0)
       kramdown (~> 2.0)
     liquid (4.0.3)
-    listen (3.7.0)
+    listen (3.7.1)
       rb-fsevent (~> 0.10, >= 0.10.3)
       rb-inotify (~> 0.9, >= 0.9.10)
     mercenary (0.3.6)
@@ -240,7 +243,7 @@ GEM
     nokogiri (1.13.3)
       mini_portile2 (~> 2.8.0)
       racc (~> 1.4)
-    octokit (4.21.0)
+    octokit (4.22.0)
       faraday (>= 0.9)
       sawyer (~> 0.8.0, >= 0.5.3)
     parallel (1.21.0)
@@ -250,13 +253,11 @@ GEM
     racc (1.6.0)
     rainbow (3.0.0)
     rake (13.0.6)
-    rb-fsevent (0.11.0)
+    rb-fsevent (0.11.1)
     rb-inotify (0.10.1)
       ffi (~> 1.0)
     rexml (3.2.5)
     rouge (3.26.0)
-    ruby-enum (0.9.0)
-      i18n
     ruby2_keywords (0.0.5)
     rubyzip (2.3.2)
     safe_yaml (1.0.5)
@@ -282,7 +283,7 @@ GEM
     unf_ext (0.0.8)
     unicode-display_width (1.8.0)
     yell (2.2.2)
-    zeitwerk (2.5.2)
+    zeitwerk (2.5.4)
 
 PLATFORMS
   ruby

From 8dad8fe71a0a49d5699bda8c76e24dd3d538b191 Mon Sep 17 00:00:00 2001
From: hossein <hossein13mousavi@gmail.com>
Date: Mon, 7 Mar 2022 13:40:21 +0330
Subject: [PATCH 321/749] fix grammatical and punctuation errors on
 CONTRIBUTING.md file

---
 CONTRIBUTING.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 7be27de5935..ffc06480ad7 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -32,8 +32,8 @@ Before we get started, here are a few things we expect from you (and that you sh
 
 * Be kind and thoughtful in your conversations around this project. We all come from different backgrounds and projects, which means we likely have different perspectives on "how open source is done." Try to listen to others rather than convince them that your way is correct.
 * Open Source Guides are released with a [Contributor Code of Conduct](./CODE_OF_CONDUCT.md). By participating in this project, you agree to abide by its terms.
-* If you open a pull request, please ensure that your contribution passes all tests. If there are test failures, you will need to address them before we can merge your contribution.
-* When adding content, please consider if it is widely valuable. Please don't add references or links to things you or your employer have created as others will do so if they appreciate it.
+* Please ensure that your contribution passes all tests if you open a pull request. If there are test failures, you will need to address them before merging your contribution.
+* When adding content, please consider if it is widely valuable. Please don't add references or links to things you or your employer have created, as others will do if they appreciate it.
 
 ## How to contribute
 

From d6efb411ae9ad123cf6a1ccd4cf399359b17eec8 Mon Sep 17 00:00:00 2001
From: Hossein Mousavi <hossein13mousavi@gmail.com>
Date: Mon, 7 Mar 2022 19:49:07 +0330
Subject: [PATCH 322/749] apply changes based on the code review to the
 contributing.md file

---
 CONTRIBUTING.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index ffc06480ad7..ec04018395b 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -32,8 +32,8 @@ Before we get started, here are a few things we expect from you (and that you sh
 
 * Be kind and thoughtful in your conversations around this project. We all come from different backgrounds and projects, which means we likely have different perspectives on "how open source is done." Try to listen to others rather than convince them that your way is correct.
 * Open Source Guides are released with a [Contributor Code of Conduct](./CODE_OF_CONDUCT.md). By participating in this project, you agree to abide by its terms.
-* Please ensure that your contribution passes all tests if you open a pull request. If there are test failures, you will need to address them before merging your contribution.
-* When adding content, please consider if it is widely valuable. Please don't add references or links to things you or your employer have created, as others will do if they appreciate it.
+* Please ensure that your contribution passes all tests if you open a pull request. If there are test failures, you will need to address them before we can merge your contribution.
+* When adding content, please consider if it is widely valuable. Please don't add references or links to things you or your employer have created, as others will do so if they appreciate it.
 
 ## How to contribute
 

From fc313342960aee53751e08d2d64bd1df5796bcec Mon Sep 17 00:00:00 2001
From: Elton Kamuango <eltonkamuango99@gmail.com>
Date: Fri, 18 Mar 2022 08:26:57 +0100
Subject: [PATCH 323/749] Fixing portuguese typo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From this: `**Transparência:** Qualquer um pode inspecionar um projeto open source por erros ou inconsistências. A transparência importa a gorvernos como a [Bulgaria]`
To this: `**Transparência:** Qualquer um pode inspecionar um projeto open source por erros ou inconsistências. A transparência importa a governos como a [Bulgaria]`
---
 _articles/pt/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index 501f358de2b..265860d6692 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -45,7 +45,7 @@ Em comparação, um processo de código fechado seria ir a um restaurante e pedi
 
 * **Adoção e remixing:** Projetos open source podem ser utilizados por qualquer um para praticamente qualquer propósito. As pessoas podem até mesmo utilizá-lo para construir outras coisas. [WordPress](https://github.com/WordPress), por exemplo, começou como um fork de um projeto chamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparência:** Qualquer um pode inspecionar um projeto open source por erros ou inconsistências. A transparência importa a gorvernos como a [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou os [Estados Unidos](https://sourcecode.cio.gov/), industrias regulamentadas como bancos ou industrias de saúde, e softwares de segurança como [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparência:** Qualquer um pode inspecionar um projeto open source por erros ou inconsistências. A transparência importa a governos como a [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou os [Estados Unidos](https://sourcecode.cio.gov/), industrias regulamentadas como bancos ou industrias de saúde, e softwares de segurança como [Let's Encrypt](https://github.com/letsencrypt).
 
 Open source não é só sobre software. Você pode tornar qualquer coisa open source, de conjuntos de dados a livros. Dê uma olhada no [GitHub Explore](https://github.com/explore) por ideias do que você pode tornar open source.
 

From 765b3155a3d9d2cce8a79620b39d86ab4741cc1f Mon Sep 17 00:00:00 2001
From: Elton Kamuango <eltonkamuango99@gmail.com>
Date: Fri, 18 Mar 2022 20:49:54 +0100
Subject: [PATCH 324/749] solving start-a-project.md pt typo

---
 _articles/pt/starting-a-project.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index 265860d6692..fbad818ce44 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -45,7 +45,7 @@ Em comparação, um processo de código fechado seria ir a um restaurante e pedi
 
 * **Adoção e remixing:** Projetos open source podem ser utilizados por qualquer um para praticamente qualquer propósito. As pessoas podem até mesmo utilizá-lo para construir outras coisas. [WordPress](https://github.com/WordPress), por exemplo, começou como um fork de um projeto chamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparência:** Qualquer um pode inspecionar um projeto open source por erros ou inconsistências. A transparência importa a governos como a [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou os [Estados Unidos](https://sourcecode.cio.gov/), industrias regulamentadas como bancos ou industrias de saúde, e softwares de segurança como [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparência:** Qualquer um pode inspecionar um projeto open source por erros ou inconsistências. A transparência importa a governos como a [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou os [Estados Unidos](https://sourcecode.cio.gov/), indústrias regulamentadas como bancos ou indústrias de saúde, e softwares de segurança como [Let's Encrypt](https://github.com/letsencrypt).
 
 Open source não é só sobre software. Você pode tornar qualquer coisa open source, de conjuntos de dados a livros. Dê uma olhada no [GitHub Explore](https://github.com/explore) por ideias do que você pode tornar open source.
 
@@ -69,9 +69,9 @@ Se você ainda não está convencido, reserve um momento para pensar sobre quais
 
 ### Definindo os seus objetivos
 
-Os objetivos podem te ajudar a descrobrir no que trabalhar, para o que dizer não, e onde você precisa da ajuda de outros. Comece perguntando a si mesmo, _por que estou tornando esse projeto open source?_
+Os objetivos podem te ajudar a descobrir no que trabalhar, para o que dizer não, e onde você precisa da ajuda de outros. Comece perguntando a si mesmo, _por que estou tornando esse projeto open source?_
 
-Não há uma resposta definitiva para essa questão. Você pode ter múltiplos objetivos para um dado projeto, ou direfentes projetos com diferentes objetivos.
+Não há uma resposta definitiva para essa questão. Você pode ter múltiplos objetivos para um dado projeto, ou diferentes projetos com diferentes objetivos.
 
 Se seu único objetivo é mostrar seu trabalho, você pode não querer contribuições e até mesmo deixar isso claro em seu README. Por outro lado, se você procura contribuidores, você investirá um certo tempo em produzir uma documentação clara e fazer com que os novatos se sintam bem vindos.
 

From 26b0ade8baf931dd1e090b215fffd6755e84c45e Mon Sep 17 00:00:00 2001
From: Viktor <63919734+ViktorOn@users.noreply.github.com>
Date: Fri, 25 Mar 2022 11:48:37 +0200
Subject: [PATCH 325/749] Update ru.yml

---
 _data/locales/ru.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_data/locales/ru.yml b/_data/locales/ru.yml
index 2c6d12a55c0..13b9d23582f 100644
--- a/_data/locales/ru.yml
+++ b/_data/locales/ru.yml
@@ -17,12 +17,12 @@ ru:
       button: Сотрудничать
     subscribe:
       heading: Оставайтесь на связи
-      description: Будьте первым, кто узнает последние новости открытого кода
+      description: Будьте первым, кто узнает новости из мира открытого кода.
       label: Электронная почта
       button: Подписаться
     byline:
       # [code], [love], and [github] will be replaced by octicons
-      format: '[программируйте] с [любовью] вместе с [github] и [друзьями]'
+      format: '[code] с [love] вместе с [github] и друзьями'
       # Label for code octicon
       code_label: программируйте
       # Label for love octicon

From d0a7454a7723106cf9e01678b5523bae86fe20fa Mon Sep 17 00:00:00 2001
From: Viktor <63919734+ViktorOn@users.noreply.github.com>
Date: Fri, 25 Mar 2022 16:37:56 +0200
Subject: [PATCH 326/749] Update ru.yml

---
 _data/locales/ru.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_data/locales/ru.yml b/_data/locales/ru.yml
index 13b9d23582f..3ccd4444c42 100644
--- a/_data/locales/ru.yml
+++ b/_data/locales/ru.yml
@@ -22,7 +22,7 @@ ru:
       button: Подписаться
     byline:
       # [code], [love], and [github] will be replaced by octicons
-      format: '[code] с [love] вместе с [github] и друзьями'
+      format: '[code] с [love] вместе с [github] и [друзьями]'
       # Label for code octicon
       code_label: программируйте
       # Label for love octicon

From c623d22bc397e72c75243fb0a63d4786617c1105 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Sat, 2 Apr 2022 22:33:38 +0300
Subject: [PATCH 327/749] Add initial files and make some translations

---
 _articles/el/best-practices.md            | 280 ++++++++++++
 _articles/el/building-community.md        | 276 +++++++++++
 _articles/el/code-of-conduct.md           | 114 +++++
 _articles/el/finding-users.md             | 156 +++++++
 _articles/el/getting-paid.md              | 187 ++++++++
 _articles/el/how-to-contribute.md         | 528 ++++++++++++++++++++++
 _articles/el/index.html                   |   6 +
 _articles/el/leadership-and-governance.md | 156 +++++++
 _articles/el/legal.md                     | 158 +++++++
 _articles/el/metrics.md                   | 128 ++++++
 _articles/el/starting-a-project.md        | 356 +++++++++++++++
 _data/locales/el.yml                      |  31 ++
 12 files changed, 2376 insertions(+)
 create mode 100644 _articles/el/best-practices.md
 create mode 100644 _articles/el/building-community.md
 create mode 100644 _articles/el/code-of-conduct.md
 create mode 100644 _articles/el/finding-users.md
 create mode 100644 _articles/el/getting-paid.md
 create mode 100644 _articles/el/how-to-contribute.md
 create mode 100644 _articles/el/index.html
 create mode 100644 _articles/el/leadership-and-governance.md
 create mode 100644 _articles/el/legal.md
 create mode 100644 _articles/el/metrics.md
 create mode 100644 _articles/el/starting-a-project.md
 create mode 100644 _data/locales/el.yml

diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
new file mode 100644
index 00000000000..e3bb39f87d0
--- /dev/null
+++ b/_articles/el/best-practices.md
@@ -0,0 +1,280 @@
+---
+lang: el
+title: Βέλτιστες Πρακτικές για Συντηρητές
+description: Διευκολύνοντας την ζωή σας ως συντηρητής ανοιχτού κώδικα, από την τεκμηρίωση των διαδικασιών μέχρι και την αξιοποίηση της κοινότητάς σας.
+class: best-practices
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+  - metrics
+  - leadership
+---
+
+## What does it mean to be a maintainer?
+
+If you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more.
+
+In the early stages of a project, you're experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you'll find yourself working with your users and contributors more.
+
+Maintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community.
+
+## Documenting your processes
+
+Writing things down is one of the most important things you can do as a maintainer.
+
+Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask.
+
+Writing things down makes it easier to say no when something doesn't fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project.
+
+Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all.
+
+Remember to keep your documentation up-to-date. If you're not able to always do this, delete your outdated documentation or indicate it is outdated so contributors know updates are welcome.
+
+### Write down your project's vision
+
+Start by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well.
+
+Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions.
+
+For example, @lord discovered that having a project vision helped him figure out which requests to spend time on. As a new maintainer, he regretted not sticking to his project's scope when he got his first feature request for [Slate](https://github.com/lord/slate).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
+  I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of a half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
+  <p markdown="1" class="pquote-credit">
+— @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
+  </p>
+</aside>
+
+### Communicate your expectations
+
+Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun.
+
+Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do.
+
+Most people who come across your project don't know anything about you or your circumstances. They may assume you get paid to work on it, especially if it's something they regularly use and depend on. Maybe at one point you put a lot of time into your project, but now you're busy with a new job or family member.
+
+All of this is perfectly okay! Just make sure other people know about it.
+
+If maintaining your project is part-time or purely volunteered, be honest about how much time you have. This is not the same as how much time you think the project requires, or how much time others want you to spend.
+
+Here are a few rules that are worth writing down:
+
+* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_)
+* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_)
+* When it's appropriate to follow up (_for example, "You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread."_)
+* How much time you spend on the project (_for example, "We only spend about 5 hours per week on this project"_)
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors.
+
+### Keep communication public
+
+Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker.
+
+If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes.
+
+That way, anybody who joins your community will have access to the same information as someone who's been there for years.
+
+## Learning to say no
+
+You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists.
+
+Having everything written down, however, helps depersonalize situations when you do need to enforce your rules.
+
+Saying no isn't fun, but  _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_.
+
+Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others.
+
+### Keep the conversation friendly
+
+One of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept.
+
+Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor.
+
+Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards.
+
+If you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
+  The key to handling support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS.
+  <p markdown="1" class="pquote-credit">
+— @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
+  </p>
+</aside>
+
+Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.
+
+It's better to immediately close the contributions you know you don't want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+
+Secondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it's someone's first time. Even if you don't accept their contribution, acknowledge the person behind it and thank them for their interest. It's a big compliment!
+
+If you don't want to accept a contribution:
+
+* **Thank them** for their contribution
+* **Explain why it doesn't fit** into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm.
+* **Link to relevant documentation**, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself.
+* **Close the request**
+
+You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):
+
+![Celery screenshot](/assets/images/best-practices/celery.png)
+
+If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want.
+
+Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it.
+
+Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise.
+
+### Be proactive
+
+To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide.
+
+If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example:
+
+* Fill out a issue or PR template/checklist
+* Open an issue before submitting a PR
+
+If they don't follow your rules, close the issue immediately and point to your documentation.
+
+While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+  Ideally, explain to them and in a CONTRIBUTING.md file how they can get a better indication in the future on what would or would not be accepted before they begin the work.
+  <p markdown="1" class="pquote-credit">
+— @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
+  </p>
+</aside>
+
+Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively.
+
+### Embrace mentorship
+
+Maybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections.
+
+If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first issue,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them.
+
+## Leverage your community
+
+You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work.
+
+### Share the workload
+
+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.
+
+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.
+
+Encouraging others to [share ownership of the project](../building-community/#share-ownership-of-your-project) can greatly reduce your own workload, as @lmccart discovered on her project, [p5.js](https://github.com/processing/p5.js).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
+  I’d been saying, "Yeah, anyone can be involved, you don’t have to have a lot of coding expertise [...]." We had people sign up to come [to an event] and that’s when I was really wondering: is this true, what I’ve been saying? There are gonna be 40 people who show up, and it’s not like I can sit with each of them...But people came together, and it just sort of worked. As soon as one person got it, they could teach their neighbor.
+  <p markdown="1" class="pquote-credit">
+—  @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+  </p>
+</aside>
+
+If you need to step away from your project, either on hiatus or permanently, there's no shame in asking someone else to take over for you.
+
+If other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It's great that so many people want your project to live on!
+
+@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), helped those goals live on even after he stepped away from the project:
+
+> I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down.
+
+### Let others build the solutions they need
+
+If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork.
+
+Forking a project doesn't have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project's vision.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
+  I cater to the 80% use case. If you are one of the unicorns, please fork my work. I won't get offended! My public projects are almost always meant to solve the most common problems; I try to make it easy to go deeper by either forking my work or extending it.
+  <p markdown="1" class="pquote-credit">
+— @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+  </p>
+</aside>
+
+The same applies to a user who really wants a solution that you simply don't have the bandwidth to build. Offering APIs and customization hooks can help others meet their own needs, without having to modify the source directly. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) encouraging plugins for CocoaPods led to "some of the most interesting ideas":
+
+> It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying "no", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform.
+
+## Bring in the robots
+
+Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier.
+
+### Require tests and other checks to improve the quality of your code
+
+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.
+
+If you add tests, make sure to explain how they work in your CONTRIBUTING file.
+
+<aside markdown="1" class="pquote">
+  <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)
+  </p>
+</aside>
+
+### Use tools to automate basic maintenance tasks
+
+The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for them.
+
+There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases
+* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
+* [Danger](https://github.com/danger/danger) helps automate code review
+* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information
+* [dependabot-preview](https://github.com/marketplace/dependabot-preview) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
+
+For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.
+
+To manage your email notifications, you can set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize by priority.
+
+If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept.
+
+However, if your standards are too complicated, they can increase the barriers to contribution. Make sure you're only adding enough rules to make everyone's lives easier.
+
+If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors.
+
+## It's okay to hit pause
+
+Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty.
+
+Perhaps you're feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up.
+
+Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project.
+
+Although it should go without saying, take a break! You shouldn't have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take [a month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) after 14 years of volunteer OSS work.
+
+Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
+  In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
+  <p markdown="1" class="pquote-credit">
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+  </p>
+</aside>
+
+Sometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away.
+
+Do your best to find support for your users and community while you're away from a project. If you can't find the support you need, take a break anyway. Be sure to communicate when you're not available, so people aren't confused by your lack of responsiveness.
+
+Taking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you.
+
+## Take care of yourself first!
+
+Maintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive.
diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
new file mode 100644
index 00000000000..9054102aa78
--- /dev/null
+++ b/_articles/el/building-community.md
@@ -0,0 +1,276 @@
+---
+lang: el
+title: Χτίζοντας Ευπρόσδεκτες Κοινότητες
+description: Χτίζοντας μια κοινωνιά που να ενθαρρύνει τα μέλη της να χρησιμοποιεί, να συνεισφέρει, και να προωθεί το πρότζεκτ σας.
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+  - best-practices
+  - coc
+---
+
+## Setting your project up for success
+
+You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around?
+
+A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back.
+
+### Make people feel welcome
+
+One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+
+As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more.
+
+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.
+
+[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.
+
+* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
+* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
+* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or a small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
+* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+  </p>
+</aside>
+
+The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute.
+
+Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself.
+
+### Document everything
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
+  <p markdown="1" class="pquote-credit">
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public.
+
+When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed.
+
+Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public.
+
+Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions.
+
+If you notice multiple users running into the same problem, document the answers in the README.
+
+For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you.
+
+Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on.
+
+### Be responsive
+
+As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started.
+
+Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating.
+
+Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466):
+
+![Middleman pull request](/assets/images/building-community/middleman_pr.png)
+
+[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution.
+
+Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project.
+
+### Give your community a place to congregate
+
+There are two reasons to give your community a place to congregate.
+
+The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate.
+
+The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel.
+
+Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above!
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members:
+
+> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.
+
+Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address.
+
+## Growing your community
+
+Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction.
+
+### Don't tolerate bad actors
+
+Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others.
+
+Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
+  The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.
+  <p markdown="1" class="pquote-credit">
+— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+  </p>
+</aside>
+
+Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
+
+When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations.
+
+### Meet contributors where they're at
+
+Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need.
+
+In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors.
+
+![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
+
+In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started.
+
+Finally, use your documentation to make people feel welcome at every step of the way.
+
+You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration.
+
+For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
+
+### Share ownership of your project
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
+  Your leaders will have different opinions, as all healthy communities should! However, you need to take steps to ensure the loudest voice doesn't always win by tiring people out, and that less prominent and minority voices are heard.
+  <p markdown="1" class="pquote-credit">
+— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+  </p>
+</aside>
+
+People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around.
+
+See if you can find ways to share ownership with your community as much as possible. Here are some ideas:
+
+* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself.
+
+![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
+
+* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
+
+* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+
+* **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.
+
+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.
+
+While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
+  \[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it.
+  <p markdown="1" class="pquote-credit">
+— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+  </p>
+</aside>
+
+## Resolving conflicts
+
+In the early stages of your project, making major decisions is easy. When you want to do something, you just do it.
+
+As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own.
+
+For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address.
+
+### Set the bar for kindness
+
+When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you.
+
+Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
+  As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
+  <p markdown="1" class="pquote-credit">
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+  </p>
+</aside>
+
+Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly.
+
+Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you.
+
+### Treat your README as a constitution
+
+Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion.
+
+### Focus on the journey, not the destination
+
+Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns.
+
+Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place.
+
+Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus.
+
+Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
+  Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
+  <p markdown="1" class="pquote-credit">
+— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+  </p>
+</aside>
+
+Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions.
+
+Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution.
+
+### Keep the conversation focused on action
+
+Discussion is important, but there is a difference between productive and unproductive conversations.
+
+Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down.
+
+Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues.
+
+With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_
+
+If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation.
+
+If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+  </p>
+</aside>
+
+### Pick your battles wisely
+
+Context is important. Consider who is involved in the discussion and how they represent the rest of the community.
+
+Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices.
+
+If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread.
+
+### Identify a community tiebreaker
+
+With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker.
+
+A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it.
+
+Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible.
+
+## Community is the ❤️ of open source
+
+Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience.
diff --git a/_articles/el/code-of-conduct.md b/_articles/el/code-of-conduct.md
new file mode 100644
index 00000000000..3eaa41575cb
--- /dev/null
+++ b/_articles/el/code-of-conduct.md
@@ -0,0 +1,114 @@
+---
+lang: el
+title: Ο Κώδικας Δεοντολογίας σας
+description: Διευκολύνετε την υγιούς και εποικοδομητική συμπεριφορά της κοινότητας με την υιοθέτηση και επιβολή ενός κώδικα δεοντολογίας.
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+  - building
+  - leadership
+---
+
+## Why do I need a code of conduct?
+
+A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.
+
+Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.
+
+A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with.
+
+## Establishing a code of conduct
+
+Try to establish a code of conduct as early as possible: ideally, when you first create your project.
+
+In addition to communicating your expectations, a code of conduct describes the following:
+
+* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_
+* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_
+* What happens if someone violates the code of conduct
+* How someone can report violations
+
+Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
+
+The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples.
+
+Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
+
+## Deciding how you'll enforce your code of conduct
+
+<aside markdown="1" class="pquote">
+  A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
+  <p markdown="1" class="pquote-credit">
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+  </p>
+</aside>
+
+You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:
+
+* It demonstrates that you are serious about taking action when it's needed.
+
+* Your community will feel more reassured that complaints actually get reviewed.
+
+* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.
+
+You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
+
+Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+
+For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+
+## Enforcing your code of conduct
+
+Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up.
+
+### Gather information about the situation
+
+Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment.
+
+The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context.
+
+Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
+
+<aside markdown="1" class="pquote">
+  Don’t get pulled into an argument. Don’t get sidetracked into dealing with someone else’s behavior before you’ve finished dealing with the matter at hand. Focus on what you need.
+  <p markdown="1" class="pquote-credit">
+— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+  </p>
+</aside>
+
+### Take appropriate action
+
+After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward.
+
+When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise.
+
+There are a few ways you might respond to a code of conduct violation:
+
+* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication.
+
+* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them.
+
+Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example:
+
+* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project
+
+* **Permanently ban** the person from the project
+
+Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached.
+
+## Your responsibilities as a maintainer
+
+A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes.
+
+As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community.
+
+A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable.
+
+In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way.
+
+## Encourage the behavior you want to see in the world 🌎
+
+When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow.
diff --git a/_articles/el/finding-users.md b/_articles/el/finding-users.md
new file mode 100644
index 00000000000..a7a4cb3226f
--- /dev/null
+++ b/_articles/el/finding-users.md
@@ -0,0 +1,156 @@
+---
+lang: el
+title: Βρίσκοντας Χρήστες για το Πρότζεκτ σας
+description: Βοηθήστε το πρότζεκτ ανοιχτού κώδικά σας να μεγαλώσει, δίνοντας το στα χέρια ευχαριστημένων χρηστών.
+class: finding
+order: 3
+image: /assets/images/cards/finding.png
+related:
+  - beginners
+  - building
+---
+
+## Spreading the word
+
+There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work!
+
+## Figure out your message
+
+Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters.
+
+What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance.
+
+Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want.
+
+For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
+
+![Cartography README](/assets/images/finding-users/cartography.jpg)
+
+For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+
+## Help people find and follow your project
+
+<aside markdown="1" class="pquote">
+  You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
+  <p markdown="1" class="pquote-credit">
+— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+  </p>
+</aside>
+
+Help people find and remember your project by pointing them to a single namespace.
+
+**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.
+
+If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. 
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
+  A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project.
+  <p markdown="1" class="pquote-credit">
+— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+  </p>
+</aside>
+
+**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_.
+
+If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+
+![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
+
+Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!
+
+## Go where your project's audience is (online)
+
+Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
+
+Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
+  Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project.
+  <p markdown="1" class="pquote-credit">
+— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+  </p>
+</aside>
+
+See if you can find ways to share your project in relevant ways:
+
+* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.
+* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.
+* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work.
+
+Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want.
+
+If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication.
+
+## Go where your project's audience is (offline)
+
+![Public speaking](/assets/images/finding-users/public_speaking.jpg)
+
+Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.
+
+If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
+  I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
+  <p markdown="1" class="pquote-credit">
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+  </p>
+</aside>
+
+If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.
+
+As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.
+
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
+  When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+  <p markdown="1" class="pquote-credit">
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+  </p>
+</aside>
+
+When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.
+
+Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
+  I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?
+  <p markdown="1" class="pquote-credit">
+— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+  </p>
+</aside>
+
+## Build a reputation
+
+In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.
+
+Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
+  The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+  <p markdown="1" class="pquote-credit">
+— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+  </p>
+</aside>
+
+It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others.
+
+There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
+  PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it.
+  <p markdown="1" class="pquote-credit">
+— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
+  </p>
+</aside>
+
+## Keep at it!
+
+It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.
diff --git a/_articles/el/getting-paid.md b/_articles/el/getting-paid.md
new file mode 100644
index 00000000000..728a6374c6c
--- /dev/null
+++ b/_articles/el/getting-paid.md
@@ -0,0 +1,187 @@
+---
+lang: el
+title: Λαμβάνοντας Αμοιβή για Συνεισφορά Ανοιχτού Κώδικα
+description: Διατηρήστε το έργο σας στον ανοιχτό κώδικα λαμβάνοντας οικονομική υποστήριξη για τον χρόνο σας ή το πρότζεκτ σας.
+class: getting-paid
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+  - best-practices
+  - leadership
+---
+
+## Why some people seek financial support
+
+Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
+I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+  <p markdown="1" class="pquote-credit">
+— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+  </p>
+</aside>
+
+There are many reasons why a person would not want to be paid for their open source work.
+
+* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
+* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
+* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
+  Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+  <p markdown="1" class="pquote-credit">
+— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+  </p>
+</aside>
+
+For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+
+Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
+  Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+  <p markdown="1" class="pquote-credit">
+— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+  </p>
+</aside>
+
+Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
+   OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+  <p markdown="1" class="pquote-credit">
+— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+  </p>
+</aside>
+
+If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+
+## Funding your own time
+
+Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+
+It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
+  Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.
+  <p markdown="1" class="pquote-credit">
+— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
+  </p>
+</aside>
+
+If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+
+Many companies are developing open source programs to build their brand and recruit quality talent.
+
+@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+
+> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+
+If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
+  Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+  <p markdown="1" class="pquote-credit">
+— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+  </p>
+</aside>
+
+If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+
+* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
+* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+
+Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+
+Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
+
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
+* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
+* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+Finally, sometimes open source projects put bounties on issues that you might consider helping with.
+
+* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
+* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+
+## Finding funding for your project
+
+Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+
+Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas.
+
+As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+
+### Raise money for your work through crowdfunding campaigns or sponsorships
+
+Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
+A few examples of sponsored projects include:
+
+* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
+* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803)
+* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+
+### Create a revenue stream
+
+Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
+* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
+* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+
+Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+
+### Apply for grant funding
+
+Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+
+For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+
+## Building a case for financial support
+
+Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+
+Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+
+### Impact
+
+Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+
+### Traction
+
+Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+
+### Value to funder
+
+Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+
+### Use of funds
+
+What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+
+### How you'll receive the funds
+
+Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
+  For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+  <p markdown="1" class="pquote-credit">
+— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+  </p>
+</aside>
+
+## Experiment and don't give up
+
+Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
diff --git a/_articles/el/how-to-contribute.md b/_articles/el/how-to-contribute.md
new file mode 100644
index 00000000000..0c205111896
--- /dev/null
+++ b/_articles/el/how-to-contribute.md
@@ -0,0 +1,528 @@
+---
+lang: el
+title: Πώς να Συνεισφέρετε στον Ανοιχτό Κώδικα
+description: Θέλετε να συνεισφέρετε σε πρότζεκτς ανοιχτού κώδικα; Ένας οδηγός για τη συνεισφορά στον ανοιχτό κώδικα, για αρχάριους και βετεράνους.
+class: contribute
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+  - beginners
+  - building
+---
+
+## Why contribute to open source?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
+  Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+  <p markdown="1" class="pquote-credit">
+— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+  </p>
+</aside>
+
+Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+
+Why do people contribute to open source? Plenty of reasons!
+
+### Improve software you rely on
+
+Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+
+### Improve existing skills
+
+Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+
+### Meet people who are interested in similar things
+
+Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+
+### Find mentors and teach others
+
+Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+
+### Build public artifacts that help you grow a reputation (and a career)
+
+By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+
+### Learn people skills
+
+Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+
+### It's empowering to be able to make changes, even small ones
+
+You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+
+## What it means to contribute
+
+If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+
+Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+
+### You don't have to contribute code
+
+A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
+  I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+  <p markdown="1" class="pquote-credit">
+— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+  </p>
+</aside>
+
+Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
+  I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing.
+  <p markdown="1" class="pquote-credit">
+— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
+  </p>
+</aside>
+
+### Do you like planning events?
+
+* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Organize the project's conference (if they have one)
+* Help community members find the right conferences and submit proposals for speaking
+
+### Do you like to design?
+
+* Restructure layouts to improve the project's usability
+* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Put together a style guide to help the project have a consistent visual design
+* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+
+### Do you like to write?
+
+* Write and improve the project's documentation
+* Curate a folder of examples showing how the project is used
+* Start a newsletter for the project, or curate highlights from the mailing list
+* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Write a translation for the project's documentation
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
+  Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+  <p markdown="1" class="pquote-credit">
+— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+  </p>
+</aside>
+
+### Do you like organizing?
+
+* Link to duplicate issues, and suggest new issue labels, to keep things organized
+* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
+* Ask clarifying questions on recently opened issues to move the discussion forward
+
+### Do you like to code?
+
+* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Ask if you can help write a new feature
+* Automate project setup
+* Improve tooling and testing
+
+### Do you like helping people?
+
+* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
+* Answer questions for people on open issues
+* Help moderate the discussion boards or conversation channels
+
+### Do you like helping others code?
+
+* Review code on other people's submissions
+* Write tutorials for how a project can be used
+* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### You don't just have to work on software projects!
+
+While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+
+For example:
+
+* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
+* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
+* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+
+Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
+
+## Orienting yourself to a new project
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
+  If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+  <p markdown="1" class="pquote-credit">
+— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+  </p>
+</aside>
+
+For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+
+Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
+
+### Anatomy of an open source project
+
+Every open source community is different.
+
+Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+
+That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+
+A typical open source project has the following types of people:
+
+* **Author:** The person/s or organization that created the project
+* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
+* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
+* **Contributors:** Everyone who has contributed something back to the project
+* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+
+Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+
+A project also has documentation. These files are usually listed in the top level of a repository.
+
+* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
+* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
+* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
+* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
+* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.
+
+Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+
+* **Issue tracker:** Where people discuss issues related to the project.
+* **Pull requests:** Where people discuss and review changes that are in progress.
+* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
+* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
+
+## Finding a project to contribute to
+
+Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+
+If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_
+
+Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+
+Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+
+Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+
+Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+
+You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
+
+> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+
+If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+You can also use one of the following resources to help you discover and contribute to new projects:
+
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+
+### A checklist before you contribute
+
+When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+
+Here's a handy checklist to evaluate whether a project is good for new contributors.
+
+**Meets the definition of open source**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+  </label>
+</div>
+
+**Project actively accepts contributions**
+
+Look at the commit activity on the main branch. On GitHub, you can see this information on a repository's homepage.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+  When was the latest commit?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+  How many contributors does the project have?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  </label>
+</div>
+
+Next, look at the project's issues.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    How many open issues are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to issues when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Are the issues recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+  </label>
+</div>
+
+Now do the same for the project's pull requests.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    How many open pull requests are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox20" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to pull requests when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the pull requests?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    Are the pull requests recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox13" class="overflow-hidden d-block text-normal">
+    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+  </label>
+</div>
+
+**Project is welcoming**
+
+A project that is friendly and welcoming signals that they will be receptive to new contributors.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox14" class="overflow-hidden d-block text-normal">
+    Do the maintainers respond helpfully to questions in issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox15" class="overflow-hidden d-block text-normal">
+    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox16" class="overflow-hidden d-block text-normal">
+    Do pull requests get reviewed?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox17" class="overflow-hidden d-block text-normal">
+    Do maintainers thank people for their contributions?
+  </label>
+</div>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+  </p>
+</aside>
+
+## How to submit a contribution
+
+You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+
+### Communicating effectively
+
+Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
+  \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+  <p markdown="1" class="pquote-credit">
+— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+  </p>
+</aside>
+
+Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+
+**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+
+> 😇 _"X doesn't happen when I do Y"_
+>
+> 😢 _"X is broken! Please fix it."_
+
+**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn.
+
+> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+>
+> 😢 _"How do I X?"_
+
+**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+
+> 😇 _"I'd like to write an API tutorial."_
+>
+> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+
+**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+
+> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+>
+> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+
+**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+
+> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+>
+> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+
+**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+
+> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+>
+> 😢 _"Why won't you support my use case? This is unacceptable!"_
+
+**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+
+### Gathering context
+
+Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+
+If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request:
+
+* **Issues** are like starting a conversation or discussion
+* **Pull requests** are for starting work on a solution
+* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
+  You'll learn <em>a lot</em> from taking a single project you actively use, "watching" it on GitHub and reading every issue and PR.
+<p markdown="1" class="pquote-credit">
+— @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
+  </p>
+</aside>
+
+### Opening an issue
+
+You should usually open an issue in the following situations:
+
+* Report an error you can't solve yourself
+* Discuss a high-level topic or idea (for example, community, vision or policies)
+* Propose a new feature or other project idea
+
+Tips for communicating on issues:
+
+* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
+* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
+* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+
+### Opening a pull request
+
+You should usually open a pull request in the following situations:
+
+* Submit trivial fixes (for example, a typo, a broken link or an obvious error)
+* Start work on a contribution that was already asked for, or that you've already discussed, in an issue
+
+A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
+
+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/).)
+* **[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.
+* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
+* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+
+If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+
+## What happens after you submit a contribution
+
+You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
+
+After you submit a contribution, one of the following will happen:
+
+### 😭 You don't get a response.
+
+Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+
+If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+
+**Don't** reach out to that person privately; remember that public communication is vital to open source projects.
+
+If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+
+### 🚧 Someone requests changes to your contribution.
+
+It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+
+When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it.
+
+If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
+
+### 👎 Your contribution doesn't get accepted.
+
+Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+
+### 🎉 Your contribution gets accepted.
+
+Hooray! You've successfully made an open source contribution!
+
+## You did it!
+
+Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
diff --git a/_articles/el/index.html b/_articles/el/index.html
new file mode 100644
index 00000000000..b650ec561e9
--- /dev/null
+++ b/_articles/el/index.html
@@ -0,0 +1,6 @@
+---
+layout: index
+title: Οδηγίες Ανοιχτού Κώδικα
+lang: el
+permalink: /el/
+---
diff --git a/_articles/el/leadership-and-governance.md b/_articles/el/leadership-and-governance.md
new file mode 100644
index 00000000000..c0b8f4504b2
--- /dev/null
+++ b/_articles/el/leadership-and-governance.md
@@ -0,0 +1,156 @@
+---
+lang: el
+title: Ηγεσία και Διοίκηση
+description: Τα αναπτυσσόμενα πρότζεκτς ανοιχτού κώδικα μπορούν να επωφεληθούν από επίσημους κανόνες για τη λήψη αποφάσεων.
+class: leadership
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+  - best-practices
+  - metrics
+---
+
+## Understanding governance for your growing project
+
+Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+
+## What are examples of formal roles used in open source projects?
+
+Many projects follow a similar structure for contributor roles and recognition.
+
+What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+
+* **Maintainer**
+* **Contributor**
+* **Committer**
+
+**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+
+A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+
+**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+  </p>
+</aside>
+
+**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+
+While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
+  You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+  <p markdown="1" class="pquote-credit">
+— @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+  </p>
+</aside>
+
+## How do I formalize these leadership roles?
+
+Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+
+For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+
+For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+
+If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+
+<aside markdown="1" class="pquote">
+  \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+  <p markdown="1" class="pquote-credit">
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+  </p>
+</aside>
+
+Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+
+Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+
+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).
+
+## When should I give someone commit access?
+
+Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
+  Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+  <p markdown="1" class="pquote-credit">
+— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+  </p>
+</aside>
+
+## What are some of the common governance structures for open source projects?
+
+There are three common governance structures associated with open source projects.
+
+* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+
+* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+
+* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
+
+Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Do I need governance docs when I launch my project?
+
+There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+
+Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+
+If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
+  We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+  <p markdown="1" class="pquote-credit">
+— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+  </p>
+</aside>
+
+## What happens if corporate employees start submitting contributions?
+
+Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+
+As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+
+It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+
+"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+
+Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+
+## Do I need a legal entity to support my project?
+
+You don't need a legal entity to support your open source project unless you're handling money.
+
+For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+
+If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+
+Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
+  Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+  <p markdown="1" class="pquote-credit">
+— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+  </p>
+</aside>
+
+If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
diff --git a/_articles/el/legal.md b/_articles/el/legal.md
new file mode 100644
index 00000000000..7c7e700c560
--- /dev/null
+++ b/_articles/el/legal.md
@@ -0,0 +1,158 @@
+---
+lang: el
+title: Η Νομική Πλευρά του Ανοιχτού Κώδικα
+description: Όλα όσα αναρωτηθήκατε ποτέ σχετικά με την νομική πλευρά του ανοιχτού κώδικα, και μερικά πράγματα που δεν γνωρίζατε.
+class: legal
+order: 10
+image: /assets/images/cards/legal.png
+related:
+  - contribute
+  - leadership
+---
+
+## Understanding the legal implications of open source
+
+Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+
+## Why do people care so much about the legal side of open source?
+
+Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+
+In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+
+If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+
+Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
+
+## 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**.
+
+![Create repository](/assets/images/legal/repo-create-name.png)
+
+**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+
+If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+
+## Just give me the TL;DR on what I need to protect my project.
+
+You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+
+[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 the most popular open source 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/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
+  A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+  <p markdown="1" class="pquote-credit">
+— @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+  </p>
+</aside>
+
+## Which open source license is appropriate for my project?
+
+If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+
+Otherwise, picking the right open source license for your project depends on your objectives.
+
+Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+
+On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+
+You may also want to consider the **communities** you hope will use and contribute to your project:
+
+* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
+* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
+* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+
+Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+
+When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+
+## What if I want to change the license of my project?
+
+Most projects never need to change licenses. But occasionally circumstances change.
+
+For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+
+**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+
+**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+
+**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+
+Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+
+## 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).
+
+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.
+
+Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
+    We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+  <p markdown="1" class="pquote-credit">
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+  </p>
+</aside>
+
+Some situations where you may want to consider an additional contributor agreement for your project include:
+
+* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
+* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
+* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
+* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
+* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
+
+If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+
+## What does my company's legal team need to know?
+
+If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+
+For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+
+**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+
+* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+
+* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+
+* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
+
+* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+
+* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+
+If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+
+Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+
+* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
+  Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+  <p markdown="1" class="pquote-credit">
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+  </p>
+</aside>
+
+* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
+* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+
+<aside markdown="1" class="pquote">
+  Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+  <p markdown="1" class="pquote-credit">
+— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+  </p>
+</aside>
+
+* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
+* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
diff --git a/_articles/el/metrics.md b/_articles/el/metrics.md
new file mode 100644
index 00000000000..1c1a22eefe2
--- /dev/null
+++ b/_articles/el/metrics.md
@@ -0,0 +1,128 @@
+---
+lang: el
+title: Στατιστικά Ανοικτού Κώδικα
+description: Λάβετε τεκμηριωμένες αποφάσεις για να βοηθήσετε το πρότζεκτ ανοιχτού κώδικά σας να ευημερήσει, μετρώντας και παρακολουθώντας την επιτυχία του.
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+  - finding
+  - best-practices
+---
+
+## Why measure anything?
+
+Data, when used wisely, can help you make better decisions as an open source maintainer.
+
+With more information, you can:
+
+* Understand how users respond to a new feature
+* Figure out where new users come from
+* Identify, and decide whether to support, an outlier use case or functionality
+* Quantify your project's popularity
+* Understand how your project is used
+* Raise money through sponsorships and grants
+
+For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+
+> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+
+Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+
+If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+
+## Discovery
+
+Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+
+![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:
+
+* **Total page views:** Tells you how many times your project was viewed
+
+* **Total unique visitors:** Tells you how many people viewed your project
+
+* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+
+* **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.
+
+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.
+
+## Usage
+
+People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+
+If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+
+Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+
+If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+
+![Clone graph](/assets/images/metrics/clone_graph.png)
+
+If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+
+* Your project isn't successfully converting your audience, or
+* You're attracting the wrong audience
+
+For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+
+Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+
+Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+
+## Retention
+
+People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+
+It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+
+Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+
+Examples of community metrics that you may want to regularly track include:
+
+* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+
+![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+
+* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+
+* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+
+* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+
+* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
+  Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+  <p markdown="1" class="pquote-credit">
+— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+  </p>
+</aside>
+
+## Maintainer activity
+
+Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+
+Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+
+[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+
+Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+
+You could also measure the time it takes to move between stages in the contribution process, such as:
+
+* Average time an issue remains open
+* Whether issues get closed by PRs
+* Whether stale issues get closed
+* Average time to merge a pull request
+
+## Use 📊 to learn about people
+
+Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+
+[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health.
diff --git a/_articles/el/starting-a-project.md b/_articles/el/starting-a-project.md
new file mode 100644
index 00000000000..1112dec18ed
--- /dev/null
+++ b/_articles/el/starting-a-project.md
@@ -0,0 +1,356 @@
+---
+lang: el
+title: Ξεκινώντας ένα Πρότζεκτ Ανοιχτού Κώδικα
+description: Μάθετε περισσότερα για τον κόσμο του ανοιχτού κώδικα και ετοιμαστείτε να ξεκινήσετε το δικό σας πρότζεκτ. 
+class: beginners
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+  - finding
+  - building
+---
+
+## The "what" and "why" of open source
+
+So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+
+### What does "open source" mean?
+
+When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+
+Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+
+_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+
+### Why do people open source their work?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+  One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+  <p markdown="1" class="pquote-credit">
+— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+  </p>
+</aside>
+
+[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+
+* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+
+* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+
+Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+
+### Does open source mean "free of charge"?
+
+One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+
+Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+
+As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+
+## Should I launch my own open source project?
+
+The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+
+If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+
+Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+
+If you're not yet convinced, take a moment to think about what your goals might be.
+
+### Setting your goals
+
+Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself,  _why am I open sourcing this project?_
+
+There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+
+If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+  At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+  <p markdown="1" class="pquote-credit">
+— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+  </p>
+</aside>
+
+As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+
+While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+
+**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+
+If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+  As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+  <p markdown="1" class="pquote-credit">
+— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+  </p>
+</aside>
+
+### Contributing to other projects
+
+If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+
+If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+
+## Launching your own open source project
+
+There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+
+Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+
+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/)
+* [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.
+
+If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+
+### Choosing a license
+
+An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+
+Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+
+[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 the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+
+When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+
+![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+
+If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+
+### Writing a README
+
+READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+
+In your README, try to answer the following questions:
+
+* What does this project do?
+* Why is this project useful?
+* How do I get started?
+* Where can I get more help, if I need it?
+
+You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+  Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+  <p markdown="1" class="pquote-credit">
+— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+  </p>
+</aside>
+
+Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+
+For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+
+When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+
+### Writing your contributing guidelines
+
+A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+
+* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
+* How to suggest a new feature
+* How to set up your environment and run tests
+
+In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+
+* The types of contributions you're looking for
+* Your roadmap or vision for the project
+* How contributors should (or should not) get in touch with you
+
+Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+
+For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+
+> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+
+In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+
+Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+
+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.
+
+![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+
+### Establishing a code of conduct
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+  We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+  <p markdown="1" class="pquote-credit">
+— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+  </p>
+</aside>
+
+Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+
+For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+
+In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+
+Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+
+Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+
+## Naming and branding your project
+
+Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+
+### Choosing the right name
+
+Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+
+* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
+* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+
+If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+
+Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+
+### Avoiding name conflicts
+
+[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+
+If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+
+Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+
+You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+
+Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+
+### How you write (and code) affects your brand, too!
+
+Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+
+Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+  <p markdown="1" class="pquote-credit">
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+
+Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+
+It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+
+## 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.
+
+**Documentation**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Project has a LICENSE file with an open source license
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    The issue queue is up-to-date, with issues clearly organized and labeled
+  </label>
+</div>
+
+**Code**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Project uses consistent code conventions and clear function/method/variable names
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    The code is clearly commented, documenting intentions and edge cases
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+  </label>
+</div>
+
+**People**
+
+If you're an individual:
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  </label>
+</div>
+
+If you're a company or organization:
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    You've talked to your legal department
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    You have a marketing plan for announcing and promoting the project
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    At least two people have administrative access to the project
+  </label>
+</div>
+
+## You did it!
+
+Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.
diff --git a/_data/locales/el.yml b/_data/locales/el.yml
new file mode 100644
index 00000000000..8c0478ecd53
--- /dev/null
+++ b/_data/locales/el.yml
@@ -0,0 +1,31 @@
+el:
+  locale_name: Ελληνικά
+  nav:
+    about: Σχετικά με
+    contribute: Συνεισφορά
+  index:
+    lead: Το λογισμικό ανοιχτού κώδικα υλοποιείται από ανθρώπους σαν εσάς. Μάθετε πώς να ξεκινήσετε και να αναπτύξετε το δικό σας πρότζεκτ.
+    opensourcefriday: Είναι Παρασκευή! Επενδύστε μερικές ώρες συνεισφέροντας στο λογισμικό που χρησιμοποιείτε και αγαπάτε
+  article:
+    table_of_contents: Πίνακας Περιεχομένων
+    back_to_all_guides: Επιστροφή σε όλους τους οδηγούς
+    related_guides: Σχετικοί Οδηγοί
+  footer:
+    contribute:
+      heading: Συνεισφορά
+      description: Θέλετε να κάνετε μια πρόταση; Αυτό το περιεχόμενο είναι ανοιχτού κώδικα. Βοηθήστε μας να το βελτιώσουμε.
+      button: Συνεισφορά
+    subscribe:
+      heading: Μείνετε σε επαφή
+      description: Ενημερωθείτε πρώτοι για τις πιο πρόσφατες συμβουλές ανοιχτού κώδικα του GitHub.
+      label: Ηλεκτρονική διεύθυνση
+      button: Εγγραφή
+    byline:
+      # [code], [love], and [github] will be replaced by octicons
+      format: "[code] με [love] από το [github] και [friends]"
+      # Label for code octicon
+      code_label: code
+      # Label for love octicon
+      love_label: αγάπη
+      # Label for the contributors link
+      friends_label: φίλους

From 131e20cac45b1def05e64e8e6f27aa1560de1a30 Mon Sep 17 00:00:00 2001
From: Anthony Nikolaidis <anthony.nikolaidis@infopelago.gr>
Date: Sun, 3 Apr 2022 18:47:28 +0200
Subject: [PATCH 328/749] =?UTF-8?q?Translate=20code=20to=20=CE=BA=CF=8E?=
 =?UTF-8?q?=CE=B4=CE=B9=CE=BA=CE=B1=CF=82?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 _data/locales/el.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_data/locales/el.yml b/_data/locales/el.yml
index 8c0478ecd53..cf2dca38566 100644
--- a/_data/locales/el.yml
+++ b/_data/locales/el.yml
@@ -24,7 +24,7 @@ el:
       # [code], [love], and [github] will be replaced by octicons
       format: "[code] με [love] από το [github] και [friends]"
       # Label for code octicon
-      code_label: code
+      code_label: κώδικας
       # Label for love octicon
       love_label: αγάπη
       # Label for the contributors link

From 3dd44ff4da028686fef800cfb5ad495f8c3ea615 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Mon, 4 Apr 2022 18:10:06 +0300
Subject: [PATCH 329/749] Made some progress on best-practices.md

---
 _articles/el/best-practices.md | 90 +++++++++++++++++-----------------
 1 file changed, 45 insertions(+), 45 deletions(-)

diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
index e3bb39f87d0..66d73a43d2c 100644
--- a/_articles/el/best-practices.md
+++ b/_articles/el/best-practices.md
@@ -10,104 +10,104 @@ related:
   - leadership
 ---
 
-## What does it mean to be a maintainer?
+## Τι σημαίνει να είσαι συντηρητής;
 
-If you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more.
+Αν συντηρείτε ένα έργο ανοιχτού κώδικα που χρησιμοποιείται από πολλούς ανθρώπους, μπορεί να έχετε παρατηρήσει ότι προγραμματίζετε λιγότερο και απαντάτε περισσότερο σε ερωτήματα.
 
-In the early stages of a project, you're experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you'll find yourself working with your users and contributors more.
+Στα αρχικά στάδια ενός πρότζεκτ, πειραματίζεστε με νέες ιδέες και παίρνετε αποφάσεις με βάση το τι θέλετε. Καθώς το έργο σας αυξάνει τη φήμη του, θα βρεθείτε να συνεργάζεστε περισσότερο με τους χρήστες και τους συνεισφορείς σας.
 
-Maintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community.
+Η συντήρηση ενός έργου απαιτεί κάτι περισσότερο από κώδικα. Αυτές οι εργασίες είναι συχνά απροσδόκητες, αλλά είναι εξίσου σημαντικές για ένα αναπτυσσόμενο πρότζεκτ. Συγκεντρώσαμε μερικούς τρόπους για να κάνετε τη ζωή σας ευκολότερη, από την τεκμηρίωση των διαδικασιών μέχρι την αξιοποίηση της κοινότητάς σας.
 
-## Documenting your processes
+## Τεκμηριώνοντας τις διαδικασίες σας
 
-Writing things down is one of the most important things you can do as a maintainer.
+Η καταγραφή των πραγμάτων είναι ένα από τα πιο σημαντικά πράγματα που μπορείτε να κάνετε ως συντηρητής.
 
-Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask.
+Η τεκμηρίωση του πρότζεκτ όχι μόνο αποσαφηνίζει τη δική σας σκέψη, αλλά βοηθάει και τους άλλους να καταλάβουν τι χρειάζεστε ή τι περιμένετε, πριν καν ρωτήσουν.
 
-Writing things down makes it easier to say no when something doesn't fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project.
+Η καταγραφή των πραγμάτων καθιστά ευκολότερο να λέτε όχι όταν κάτι δεν ταιριάζει στο πεδίο εφαρμογής σας. Επίσης, διευκολύνει τους άλλους να συνεισφέρουν και να βοηθήσουν. Ποτέ δεν ξέρετε ποιος μπορεί να διαβάσει ή να χρησιμοποιήσει το έργο σας.
 
-Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all.
+Ακόμα και αν δεν χρησιμοποιείτε ολόκληρες παραγράφους, το να σημειώνετε πράγματα με bullet points είναι καλύτερο από το να μην γράφετε τίποτα.
 
-Remember to keep your documentation up-to-date. If you're not able to always do this, delete your outdated documentation or indicate it is outdated so contributors know updates are welcome.
+Να θυμάστε να διατηρείτε την τεκμηρίωσή σας ενημερωμένη. Αν δεν μπορείτε να το κάνετε πάντα αυτό, διαγράψτε την ξεπερασμένη τεκμηρίωσή σας ή αναφέρετε ότι είναι ξεπερασμένη, ώστε οι συνεισφέροντες να γνωρίζουν ότι οι ενημερώσεις είναι ευπρόσδεκτες.
 
-### Write down your project's vision
+### Καταγράψτε το όραμα του πρότζεκτ σας
 
-Start by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well.
+Ξεκινήστε γράφοντας τους στόχους του έργου σας. Προσθέστε τους στο αρχείο README ή δημιουργήστε ένα ξεχωριστό αρχείο με το όνομα VISION. Αν υπάρχουν άλλα αντικείμενα που θα μπορούσαν να βοηθήσουν, όπως ένας χάρτης πορείας του έργου, δημοσιοποιήστε και αυτά.
 
-Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions.
+Η ύπαρξη ενός σαφούς, τεκμηριωμένου οράματος σας κρατάει εστιασμένους και σας βοηθά να αποφύγετε τον "ερπυσμό του πεδίου εφαρμογής" από τις συνεισφορές των άλλων.
 
-For example, @lord discovered that having a project vision helped him figure out which requests to spend time on. As a new maintainer, he regretted not sticking to his project's scope when he got his first feature request for [Slate](https://github.com/lord/slate).
+Για παράδειγμα, ο @lord διαπίστωσε ότι η ύπαρξη ενός οράματος έργου τον βοήθησε να καταλάβει σε ποια αιτήματα να αφιερώσει χρόνο. Ως νέος συντηρητής, μετάνιωσε που δεν τήρησε το πεδίο εφαρμογής του έργου του, όταν έλαβε το πρώτο του αίτημα για μία νέα λειτορυγία για το [Slate](https://github.com/lord/slate).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
-  I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of a half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
+  Τα έκανα μαντάρα. Δεν κατέβαλα προσπάθεια για να βρω μια ολοκληρωμένη λύση. Αντί για μια μισή λύση, θα ήθελα να είχα πει "Δεν έχω χρόνο γι' αυτό τώρα, αλλά θα το προσθέσω στη μακροπρόθεσμη λίστα των καλών-αν-υπήρχαν πραγμάτων".
   <p markdown="1" class="pquote-credit">
 — @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
   </p>
 </aside>
 
-### Communicate your expectations
+### Επικοινωνήστε τις προσδοκίες σας
 
-Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun.
+Οι κανόνες μπορεί να είναι νευραλγικοί για να τους γράψετε. Μερικές φορές μπορεί να αισθάνεστε ότι αστυνομεύετε τη συμπεριφορά των άλλων ή ότι σκοτώνετε όλη τη διασκέδαση.
 
-Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do.
+Γραμμένοι και επιβαλλόμενοι δίκαια, ωστόσο, οι καλοί κανόνες ενδυναμώνουν τους συντηρητές. Σας αποτρέπουν από το να σας παρασύρουν να κάνετε πράγματα που δεν θέλετε.
 
-Most people who come across your project don't know anything about you or your circumstances. They may assume you get paid to work on it, especially if it's something they regularly use and depend on. Maybe at one point you put a lot of time into your project, but now you're busy with a new job or family member.
+Οι περισσότεροι άνθρωποι που έρχονται σε επαφή με το πρότζεκτ σας δεν γνωρίζουν τίποτα για εσάς ή τις συνθήκες που επικρατούν. Μπορεί να υποθέσουν ότι πληρώνεστε για να εργάζεστε σε αυτό, ειδικά αν πρόκειται για κάτι που χρησιμοποιούν τακτικά και από το οποίο εξαρτώνται. Ίσως κάποια στιγμή αφιερώσατε πολύ χρόνο στο πρότζεκτ σας, αλλά τώρα είστε απασχολημένοι με μια νέα δουλειά ή ένα νέο μέλος της οικογένειας.
 
-All of this is perfectly okay! Just make sure other people know about it.
+Όλα αυτά είναι απολύτως εντάξει! Απλώς βεβαιωθείτε ότι οι άλλοι άνθρωποι το γνωρίζουν.
 
-If maintaining your project is part-time or purely volunteered, be honest about how much time you have. This is not the same as how much time you think the project requires, or how much time others want you to spend.
+Αν η συντήρηση του έργου σας γίνεται με μερική απασχόληση ή καθαρά εθελοντικά, να είστε ειλικρινείς σχετικά με το πόσο χρόνο διαθέτετε. Αυτό δεν είναι το ίδιο με το πόσο χρόνο νομίζετε ότι απαιτεί το έργο ή πόσο χρόνο θέλουν οι άλλοι να ξοδέψετε.
 
-Here are a few rules that are worth writing down:
+Ακολουθούν μερικοί κανόνες που αξίζει να καταγράψετε:
 
-* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_)
-* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_)
-* When it's appropriate to follow up (_for example, "You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread."_)
-* How much time you spend on the project (_for example, "We only spend about 5 hours per week on this project"_)
+* Πώς μια συνεισφορά εξετάζεται και γίνεται αποδεκτή (_Χρειάζονται δοκιμές; Ένα πρότυπο θέματος;_)
+* Τα είδη των συνεισφορών που θα δεχτείτε (_Θέλετε βοήθεια μόνο για ένα συγκεκριμένο μέρος του κώδικά σας;_)
+* Πότε είναι σκόπιμο να δώσετε συνέχεια (_για παράδειγμα, "Μπορείτε να περιμένετε απάντηση από έναν συντηρητή εντός 7 ημερών. Αν δεν έχετε ακούσει τίποτα μέχρι τότε, μπορείτε να στείλετε μήνυμα στο νήμα."_)
+* Πόσο χρόνο αφιερώνετε στο έργο (_για παράδειγμα, "Ξοδεύουμε μόνο περίπου 5 ώρες την εβδομάδα σε αυτό το έργο"_)
 
-[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors.
+Το [Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), και το [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) είναι κάποια παραδείγματα από πρότζεκτ με κανόνες για τους συντηρητές και τους συνεισφέροντες.
 
-### Keep communication public
+### Κρατήστε την επικοινωνία δημόσια
 
-Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker.
+Μην ξεχνάτε επίσης να τεκμηριώνετε τις αλληλεπιδράσεις σας. Όπου μπορείτε, κρατήστε την επικοινωνία σχετικά με το πρότζεκτ σας δημόσια. Αν κάποιος προσπαθήσει να επικοινωνήσει μαζί σας ιδιαιτέρως για να συζητήσει ένα αίτημα χαρακτηριστικών ή μια ανάγκη υποστήριξης, κατευθύνετε τον ευγενικά σε ένα δημόσιο κανάλι επικοινωνίας, όπως μια λίστα αλληλογραφίας ή έναν ανιχνευτή προβλημάτων.
 
-If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes.
+Εάν συναντηθείτε με άλλους συντηρητές ή λάβετε μια σημαντική απόφαση ιδιωτικά, τεκμηριώστε αυτές τις συζητήσεις δημόσια, ακόμη και αν πρόκειται απλώς για την ανάρτηση των σημειώσεών σας.
 
-That way, anybody who joins your community will have access to the same information as someone who's been there for years.
+Με αυτόν τον τρόπο, όποιος προσχωρεί στην κοινότητά σας θα έχει πρόσβαση στις ίδιες πληροφορίες με κάποιον που είναι εκεί για χρόνια.
 
-## Learning to say no
+## Μαθαίνοντας να λέτε όχι
 
-You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists.
+Έχετε καταγράψει τα πράγματα. Ιδανικά, όλοι θα διάβαζαν το έγγραφο τεκμηρίωσής σας, αλλά στην πραγματικότητα, θα πρέπει να υπενθυμίζετε στους άλλους ότι υπάρχει αυτή η γνώση.
 
-Having everything written down, however, helps depersonalize situations when you do need to enforce your rules.
+Το να έχετε τα πάντα καταγεγραμμένα, ωστόσο, βοηθά στην αποπροσωποποίηση των καταστάσεων όταν χρειάζεται να επιβάλλετε τους κανόνες σας.
 
-Saying no isn't fun, but  _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_.
+Το να λέτε όχι δεν έχει πλάκα, αλλά _"Η συνεισφορά σας δεν ταιριάζει με τα κριτήρια αυτού του έργου"_ μοιάζει λιγότερο προσωπικό από το _"Δεν μου αρέσει η συνεισφορά σας"_.
 
-Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others.
+Το να λέτε όχι ισχύει σε πολλές περιπτώσεις που θα συναντήσετε ως συντηρητής: αιτήσεις για χαρακτηριστικά που δεν ταιριάζουν στο πεδίο εφαρμογής, κάποιος που εκτροχιάζει μια συζήτηση, που κάνει περιττή δουλειά για άλλους.
 
-### Keep the conversation friendly
+### Κρατήστε τη συζήτηση φιλική
 
-One of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept.
+Ένα από τα πιο σημαντικά μέρη που θα εξασκηθείτε στο να λέτε όχι είναι στην ουρά των ζητημάτων και των αιτημάτων (issues and pull requests). Ως συντηρητής έργου, αναπόφευκτα θα λάβετε προτάσεις που δεν θέλετε να δεχτείτε.
 
-Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor.
+Ίσως η συνεισφορά να αλλάζει το πεδίο εφαρμογής του έργου σας ή να μην ταιριάζει με το όραμά σας. Ίσως η ιδέα είναι καλή, αλλά η υλοποίηση είναι φτωχή.
 
-Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards.
+Ανεξάρτητα από τον λόγο, είναι δυνατόν να χειριστείτε με διακριτικότητα τις συνεισφορές που δεν ανταποκρίνονται στα πρότυπα του έργου σας.
 
-If you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community.
+Αν λάβετε μια συνεισφορά που δεν θέλετε να αποδεχτείτε, η πρώτη σας αντίδραση μπορεί να είναι να την αγνοήσετε ή να προσποιηθείτε ότι δεν την είδατε. Κάτι τέτοιο θα μπορούσε να πληγώσει τα αισθήματα του άλλου ατόμου και να αποθαρρύνει ακόμη και άλλους πιθανούς συνεισφέροντες στην κοινότητά σας.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
-  The key to handling support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS.
+  Το κλειδί για τον χειρισμό της υποστήριξης πρότζεκτ ανοιχτού κώδικα μεγάλης κλίμακας είναι η συνεχής λύση των θεμάτων. Προσπαθήστε να αποφύγετε την καθυστέρηση των θεμάτων. Αν είστε προγραμματιστής iOS ξέρετε πόσο απογοητευτικό μπορεί να είναι να υποβάλλετε radars. Μπορεί να λάβετε απάντηση 2 χρόνια αργότερα και να σας πουν να προσπαθήσετε ξανά με την τελευταία έκδοση του iOS.
   <p markdown="1" class="pquote-credit">
 — @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
   </p>
 </aside>
 
-Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.
+Μην αφήνετε μια ανεπιθύμητη συνεισφορά ανοιχτή επειδή αισθάνεστε ένοχοι ή επειδή θέλετε να είστε ευγενικοί. Με την πάροδο του χρόνου, τα αναπάντητα ζητήματα και αιτήματα θα κάνουν την εργασία στο έργο σας να μοιάζει πολύ πιο αγχωτική και εκφοβιστική.
 
-It's better to immediately close the contributions you know you don't want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Είναι προτιμότερο να κλείνετε αμέσως τις συνεισφορές που ξέρετε ότι δεν θέλετε να δεχτείτε. Αν το έργο σας πάσχει ήδη από ένα μεγάλο ανεκτέλεστο, ο @steveklabnik έχει προτάσεις για το [πώς να ταξινομείτε αποτελεσματικά τα θέματα](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
 
-Secondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it's someone's first time. Even if you don't accept their contribution, acknowledge the person behind it and thank them for their interest. It's a big compliment!
+Δεύτερον, η αγνόηση συνεισφορών στέλνει ένα αρνητικό μήνυμα στην κοινότητά σας. Η συνεισφορά σε ένα έργο μπορεί να είναι εκφοβιστική, ειδικά αν είναι η πρώτη φορά που κάποιος συνεισφέρει. Ακόμα και αν δεν αποδεχτείτε τη συνεισφορά του, αναγνωρίστε το άτομο που βρίσκεται πίσω από αυτή και ευχαριστήστε το για το ενδιαφέρον του. Είναι ένα μεγάλο κομπλιμέντο!
 
 If you don't want to accept a contribution:
 

From 25bf374516fd1c29d480cf08dd14a2ee9716666a Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Mon, 4 Apr 2022 18:22:11 +0300
Subject: [PATCH 330/749] Fix failing CI test

---
 _articles/el/building-community.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index 9054102aa78..a09ff3c7737 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -35,7 +35,7 @@ Start with your documentation:
 * **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
 * **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
 * **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or a small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
-* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#μαθαίνοντας-να-λέτε-όχι) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">

From e1857e3a4812d97bd50d878eb0097ec34f747833 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Mon, 4 Apr 2022 19:23:04 +0300
Subject: [PATCH 331/749] Make some more progress on best-practices.md

---
 _articles/el/best-practices.md | 126 ++++++++++++++++-----------------
 1 file changed, 63 insertions(+), 63 deletions(-)

diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
index 66d73a43d2c..46d42517a0f 100644
--- a/_articles/el/best-practices.md
+++ b/_articles/el/best-practices.md
@@ -109,145 +109,145 @@ related:
 
 Δεύτερον, η αγνόηση συνεισφορών στέλνει ένα αρνητικό μήνυμα στην κοινότητά σας. Η συνεισφορά σε ένα έργο μπορεί να είναι εκφοβιστική, ειδικά αν είναι η πρώτη φορά που κάποιος συνεισφέρει. Ακόμα και αν δεν αποδεχτείτε τη συνεισφορά του, αναγνωρίστε το άτομο που βρίσκεται πίσω από αυτή και ευχαριστήστε το για το ενδιαφέρον του. Είναι ένα μεγάλο κομπλιμέντο!
 
-If you don't want to accept a contribution:
+Εάν δεν θέλετε να δεχτείτε μια συνεισφορά:
 
-* **Thank them** for their contribution
-* **Explain why it doesn't fit** into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm.
-* **Link to relevant documentation**, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself.
-* **Close the request**
+* **Ευχαριστήστε τους** για τη συνεισφορά τους
+* **Εξηγήστε γιατί δεν ταιριάζει** στο πεδίο εφαρμογής του έργου, και προσφέρετε σαφείς προτάσεις βελτίωσης, αν είστε σε θέση. Να είστε ευγενικοί, αλλά σταθεροί.
+* **Να παραπέμψετε σε σχετική τεκμηρίωση**, αν την έχετε. Εάν παρατηρήσετε επαναλαμβανόμενες αιτήσεις για πράγματα που δεν θέλετε να δεχτείτε, προσθέστε τα στην τεκμηρίωσή σας για να αποφύγετε την επανάληψη.
+* **Κλείστε το αίτημα**
 
-You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):
+Δεν θα πρέπει να χρειάζεστε περισσότερες από 1-2 προτάσεις για να απαντήσετε. Για παράδειγμα, όταν ένας χρήστης του [celery](https://github.com/celery/celery/) ανέφερε ένα σφάλμα σχετικό με τα Windows, ο @berkerpeksag [απάντησε με](https://github.com/celery/celery/issues/3383):
 
 ![Celery screenshot](/assets/images/best-practices/celery.png)
 
-If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):
+Αν η σκέψη να πείτε όχι σας τρομάζει, δεν είστε οι μόνοι. Όπως [το έθεσε](https://blog.jessfraz.com/post/the-art-of-closing/) ο @jessfraz:
 
-> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want.
+> Έχω μιλήσει με συντηρητές από διάφορα πρότζεκτς ανοιχτού κώδικα, Mesos, Kubernetes, Chromium, και όλοι συμφωνούν ότι ένα από τα δυσκολότερα μέρη του να είσαι συντηρητής είναι να λέει κανείς "Όχι" σε patches που δεν θέλεις.
 
-Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it.
+Μην αισθάνεστε ένοχοι που δεν θέλετε να αποδεχτείτε την συνεισφορά κάποιου. Ο πρώτος κανόνας του ανοιχτού κώδικα, [σύμφωνα με τον](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Το όχι είναι προσωρινό, το ναι είναι παντοτινό."_ Ενώ η κατανόηση του ενθουσιασμού ενός άλλου ατόμου είναι καλό πράγμα, η απόρριψη μιας συνεισφοράς δεν είναι το ίδιο με την απόρριψη του ατόμου πίσω από αυτήν.
 
-Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise.
+Σε τελική ανάλυση, αν μια συνεισφορά δεν είναι αρκετά καλή, δεν είστε υποχρεωμένοι να την αποδεχτείτε. Να είστε ευγενικοί και να ανταποκρίνεστε όταν οι άνθρωποι συνεισφέρουν στο έργο σας, αλλά να δέχεστε μόνο τις αλλαγές που πραγματικά πιστεύετε ότι θα κάνουν το έργο σας καλύτερο. Όσο πιο συχνά εξασκείστε στο να λέτε όχι, τόσο πιο εύκολο γίνεται. Υπόσχεση.
 
-### Be proactive
+### Να είστε προνοητικοί
 
-To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide.
+Για να μειώσετε εξαρχής τον όγκο των ανεπιθύμητων συνεισφορών, εξηγήστε τη διαδικασία του έργου σας για την υποβολή και την αποδοχή συνεισφορών στον οδηγό συνεισφοράς σας.
 
-If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example:
+Αν λαμβάνετε πάρα πολλές συνεισφορές χαμηλής ποιότητας, απαιτήστε από τους συνεισφέροντες να κάνουν λίγη δουλειά εκ των προτέρων, για παράδειγμα:
 
-* Fill out a issue or PR template/checklist
-* Open an issue before submitting a PR
+* Συμπλήρωση ενός ζητήματος (issue) ή έναν κατάλογο αιτήματος (pull request)
+* Άνοιγμα ζητήματος πριν την υποβολή ενός αιτήματος
 
-If they don't follow your rules, close the issue immediately and point to your documentation.
+Αν δεν τηρούν τους κανόνες σας, κλείστε αμέσως το θέμα και παραπέμψτε στην τεκμηρίωσή σας.
 
-While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage.
+Αν και αυτή η προσέγγιση μπορεί να σας φανεί αγενής στην αρχή, το να είστε προληπτικοί είναι στην πραγματικότητα καλό και για τα δύο μέρη. Μειώνει την πιθανότητα κάποιος να αφιερώσει πολλές χαμένες ώρες εργασίας σε ένα pull request που δεν πρόκειται να αποδεχτείτε. Και καθιστά ευκολότερη τη διαχείριση του φόρτου εργασίας σας.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-  Ideally, explain to them and in a CONTRIBUTING.md file how they can get a better indication in the future on what would or would not be accepted before they begin the work.
+  Ιδανικά, εξηγήστε τους και σε ένα αρχείο CONTRIBUTING.md πώς μπορούν να πάρουν μια καλύτερη ένδειξη στο μέλλον για το τι θα γίνει ή δεν θα γίνει αποδεκτό πριν ξεκινήσουν την εργασία.
   <p markdown="1" class="pquote-credit">
 — @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
   </p>
 </aside>
 
-Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively.
+Μερικές φορές, όταν λέτε όχι, ο πιθανός συνεισφορέας σας μπορεί να εκνευριστεί ή να επικρίνει την απόφασή σας. Αν η συμπεριφορά του γίνει εχθρική, [λάβετε μέτρα για να εκτονώσετε την κατάσταση](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) ή ακόμα και να τον απομακρύνετε από την κοινότητά σας, αν δεν είναι πρόθυμος να συνεργαστεί εποικοδομητικά.
 
-### Embrace mentorship
+### Αποδεχτείτε την καθοδήγηση
 
-Maybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections.
+Ίσως κάποιος στην κοινότητά σας υποβάλλει τακτικά συνεισφορές που δεν ανταποκρίνονται στα πρότυπα του έργου σας. Μπορεί να είναι απογοητευτικό και για τα δύο μέρη να περνούν επανειλημμένα από απορρίψεις.
 
-If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first issue,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them.
+Αν δείτε ότι κάποιος είναι ενθουσιασμένος με το έργο σας, αλλά χρειάζεται λίγη βελτίωση, κάντε υπομονή. Εξηγήστε με σαφήνεια σε κάθε περίπτωση γιατί οι συνεισφορές τους δεν ανταποκρίνονται στις προσδοκίες του έργου. Προσπαθήστε να τους υποδείξετε μια πιο εύκολη ή λιγότερο ασαφή εργασία, όπως ένα ζήτημα με την ένδειξη _"καλό πρώτο ζήτημα",_ για να αρχίσουν να συμμετέχουν. Αν έχετε χρόνο, σκεφτείτε να τους καθοδηγήσετε κατά την πρώτη τους συνεισφορά ή βρείτε κάποιον άλλον στην κοινότητά σας που θα μπορούσε να είναι πρόθυμος να τους καθοδηγήσει.
 
-## Leverage your community
+## Αξιοποιήστε την κοινότητά σας
 
-You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work.
+Δεν χρειάζεται να κάνετε τα πάντα μόνοι σας. Η κοινότητα του έργου σας υπάρχει για κάποιο λόγο! Ακόμα και αν δεν έχετε ακόμα μια ενεργή κοινότητα συνεισφερόντων, αν έχετε πολλούς χρήστες, βάλτε τους να δουλέψουν.
 
-### Share the workload
+### Μοιραστείτε το φόρτο εργασίας
 
-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.
+Ένας τρόπος για να κερδίσετε νέους συνεισφέροντες είναι να επισημάνετε ρητά [θέματα που είναι αρκετά απλά για να τα αντιμετωπίσουν οι αρχάριοι](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Στη συνέχεια, το GitHub θα εμφανίσει αυτά τα ζητήματα σε διάφορα σημεία της πλατφόρμας, αυξάνοντας την προβολή τους.
 
-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.
+Όταν βλέπετε νέους συνεισφέροντες να κάνουν επαναλαμβανόμενες συνεισφορές, αναγνωρίστε το έργο τους προσφέροντας περισσότερες ευθύνες. Τεκμηριώστε τον τρόπο με τον οποίο οι άλλοι μπορούν να εξελιχθούν σε ηγετικούς ρόλους αν το επιθυμούν.
 
-Encouraging others to [share ownership of the project](../building-community/#share-ownership-of-your-project) can greatly reduce your own workload, as @lmccart discovered on her project, [p5.js](https://github.com/processing/p5.js).
+Το να ενθαρρύνετε τους άλλους να [μοιράζονται την ιδιοκτησία του έργου](../building-community/#share-ownership-of-your-project) μπορεί να μειώσει σημαντικά τον δικό σας φόρτο εργασίας, όπως ανακάλυψε η @lmccart στο έργο της, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
-  I’d been saying, "Yeah, anyone can be involved, you don’t have to have a lot of coding expertise [...]." We had people sign up to come [to an event] and that’s when I was really wondering: is this true, what I’ve been saying? There are gonna be 40 people who show up, and it’s not like I can sit with each of them...But people came together, and it just sort of worked. As soon as one person got it, they could teach their neighbor.
+  Έλεγα, "Ναι, ο καθένας μπορεί να συμμετάσχει, δεν χρειάζεται να έχεις μεγάλη εμπειρία στον προγραμματισμό [...]". Είχαμε ανθρώπους που δήλωναν συμμετοχή [σε μια εκδήλωση] και τότε ήταν που πραγματικά αναρωτήθηκα: είναι αλήθεια αυτό που έλεγα; Θα εμφανιστούν 40 άτομα και δεν είναι ότι μπορώ να καθίσω με τον καθένα τους... Αλλά οι άνθρωποι συγκεντρώθηκαν και κατά κάποιο τρόπο λειτούργησε. Μόλις ένα άτομο το καταλάβαινε, μπορούσε να διδάξει τον διπλανό του.
   <p markdown="1" class="pquote-credit">
 —  @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
   </p>
 </aside>
 
-If you need to step away from your project, either on hiatus or permanently, there's no shame in asking someone else to take over for you.
+Αν χρειαστεί να αποχωρήσετε από το έργο σας, είτε για διακοπή είτε μόνιμα, δεν είναι ντροπή να ζητήσετε από κάποιον άλλον να αναλάβει τη θέση σας.
 
-If other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It's great that so many people want your project to live on!
+Αν άλλοι άνθρωποι είναι ενθουσιασμένοι με την κατεύθυνσή του, δώστε τους δεσμευτική πρόσβαση ή παραδώστε επίσημα τον έλεγχο σε κάποιον άλλον. Αν κάποιος έχει διακλαδίσει το έργο σας (fork) και το συντηρεί ενεργά αλλού, σκεφτείτε το ενδεχόμενο να παραπέμψετε στη διακλάδωση από το αρχικό σας έργο. Είναι σπουδαίο που τόσοι πολλοί άνθρωποι θέλουν να συνεχίσει το έργο σας να ζει!
 
-@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), helped those goals live on even after he stepped away from the project:
+Ο @progrium [διαπίστωσε ότι](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) καταγράφοντας το όραμα για το έργο του, [Dokku](https://github.com/dokku/dokku), βοήθησε αυτούς τους στόχους να συνεχίσουν να ζουν ακόμα και μετά την αποχώρησή του από το έργο:
 
-> I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down.
+> Έγραψα μια σελίδα wiki που περιέγραφε τι ήθελα και γιατί το ήθελα. Για κάποιο λόγο με εξέπληξε το γεγονός ότι οι συντηρητές άρχισαν να κινούν το πρότζεκτ προς αυτή την κατεύθυνση! Συνέβη ακριβώς όπως θα το έκανα εγώ; Όχι πάντα. Αλλά και πάλι έφερε το έργο πιο κοντά σε αυτό που έγραψα.
 
-### Let others build the solutions they need
+### Αφήστε τους άλλους να φτιάξουν τις λύσεις που χρειάζονται
 
-If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork.
+Αν ένας πιθανός συνεισφέροντας έχει διαφορετική άποψη για το τι πρέπει να κάνει το έργο σας, ίσως θελήσετε να τον ενθαρρύνετε απαλά να δουλέψει στο δικό του fork.
 
-Forking a project doesn't have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project's vision.
+Η διακλάδωση ενός έργου δεν χρειάζεται να είναι κάτι κακό. Η δυνατότητα αντιγραφής και τροποποίησης έργων είναι ένα από τα καλύτερα πράγματα στον ανοικτό κώδικα. Το να ενθαρρύνετε τα μέλη της κοινότητάς σας να εργαστούν στη δική τους διακλάδωση μπορεί να τους προσφέρει τη δημιουργική διέξοδο που χρειάζονται, χωρίς να έρχεται σε σύγκρουση με το όραμα του έργου σας.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
-  I cater to the 80% use case. If you are one of the unicorns, please fork my work. I won't get offended! My public projects are almost always meant to solve the most common problems; I try to make it easy to go deeper by either forking my work or extending it.
+  Εξυπηρετώ το 80% των περιπτώσεων χρήσης. Αν είστε ένας από τους μονόκερους, παρακαλείσθε να κάνετε fork τη δουλειά μου. Δεν θα προσβληθώ! Τα δημόσια πρότζεκτ μου προορίζονται σχεδόν πάντα για την επίλυση των πιο συνηθισμένων προβλημάτων- προσπαθώ να διευκολύνω την εμβάθυνση, είτε με το να κάνω fork το πρότζεκτ μου είτε με το να το επεκτείνω.
   <p markdown="1" class="pquote-credit">
-— @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+- @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
   </p>
 </aside>
 
-The same applies to a user who really wants a solution that you simply don't have the bandwidth to build. Offering APIs and customization hooks can help others meet their own needs, without having to modify the source directly. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) encouraging plugins for CocoaPods led to "some of the most interesting ideas":
+Το ίδιο ισχύει και για έναν χρήστη που θέλει πραγματικά μια λύση την οποία απλά δεν έχετε το εύρος ζώνης για να κατασκευάσετε. Η προσφορά APIs και customization hooks μπορεί να βοηθήσει τους άλλους να ικανοποιήσουν τις δικές τους ανάγκες, χωρίς να χρειάζεται να τροποποιήσουν άμεσα τον πηγαίο κώδικα. Ο @orta [διαπίστωσε ότι](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) η ενθάρρυνση των plugins για τα CocoaPods οδήγησε σε "μερικές από τις πιο ενδιαφέρουσες ιδέες":
 
-> It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying "no", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform.
+> Είναι σχεδόν αναπόφευκτο ότι μόλις ένα πρότζεκτ γίνει μεγάλο, οι συντηρητές πρέπει να γίνουν πολύ πιο συντηρητικοί σχετικά με το πώς εισάγουν νέο κώδικα. Γίνεστε καλοί στο να λέτε "όχι", αλλά πολλοί άνθρωποι έχουν νόμιμες ανάγκες. Οπότε, αντί γι' αυτό, καταλήγετε να μετατρέψετε το εργαλείο σας σε πλατφόρμα.
 
-## Bring in the robots
+## Φέρτε τα ρομπότ
 
-Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier.
+Όπως ακριβώς υπάρχουν εργασίες στις οποίες μπορούν να σας βοηθήσουν άλλοι άνθρωποι, έτσι υπάρχουν και εργασίες που δεν θα έπρεπε ποτέ να κάνει κανένας άνθρωπος. Τα ρομπότ είναι οι φίλοι σας. Χρησιμοποιήστε τα για να κάνετε τη ζωή σας ως συντηρητής ευκολότερη.
 
-### Require tests and other checks to improve the quality of your code
+### Απαιτήστε δοκιμές και άλλους ελέγχους για να βελτιώσετε την ποιότητα του κώδικά σας
 
-One of the most important ways you can automate your project is by adding tests.
+Ένας από τους σημαντικότερους τρόπους με τους οποίους μπορείτε να αυτοματοποιήσετε το πρότζεκτ σας είναι η προσθήκη δοκιμών (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.
+Ορίστε αυτόματες δοκιμές που θα εκτελούνται σε όλες τις εισερχόμενες συνεισφορές και βεβαιωθείτε ότι οι δοκιμές σας μπορούν εύκολα να εκτελούνται τοπικά από τους συνεισφέροντες. Απαιτήστε ότι όλες οι συνεισφορές κώδικα περνούν τις δοκιμές σας πριν υποβληθούν. Θα βοηθήσετε στον καθορισμό ενός ελάχιστου προτύπου ποιότητας για όλες τις υποβολές. Οι [Απαιτούμενοι έλεγχοι κατάστασης](https://help.github.com/articles/about-required-status-checks/) στο GitHub μπορούν να βοηθήσουν να διασφαλιστεί ότι καμία αλλαγή δεν συγχωνεύεται χωρίς να έχουν περάσει οι δοκιμές σας.
 
-If you add tests, make sure to explain how they work in your CONTRIBUTING file.
+Αν προσθέσετε δοκιμές, φροντίστε να εξηγήσετε πώς λειτουργούν στο αρχείο CONTRIBUTING.
 
 <aside markdown="1" class="pquote">
   <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://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
-### Use tools to automate basic maintenance tasks
+### Χρησιμοποιήστε εργαλεία για την αυτοματοποίηση βασικών εργασιών συντήρησης
 
-The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for them.
+Τα καλά νέα σχετικά με τη συντήρηση ενός δημοφιλούς πρότζεκτ είναι ότι άλλοι συντηρητές έχουν πιθανότατα αντιμετωπίσει παρόμοια ζητήματα και έχουν κατασκευάσει μια λύση για αυτά.
 
-There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples:
+Υπάρχει μια [ποικιλία διαθέσιμων εργαλείων](https://github.com/showcases/tools-for-open-source) που βοηθούν στην αυτοματοποίηση ορισμένων πτυχών των εργασιών συντήρησης. Μερικά παραδείγματα:
 
-* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases
-* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
-* [Danger](https://github.com/danger/danger) helps automate code review
-* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information
-* [dependabot-preview](https://github.com/marketplace/dependabot-preview) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
+* Το [semantic-release](https://github.com/semantic-release/semantic-release) αυτοματοποιεί τις εκδόσεις σας
+* Το [mention-bot](https://github.com/facebook/mention-bot) αναφέρει πιθανούς αναθεωρητές (reviewers) για τα pull requests
+* Το [Danger](https://github.com/danger/danger) βοηθά στην αυτοματοποίηση της αναθεώρησης κώδικα (code review)
+* Το [no-response](https://github.com/probot/no-response) κλείνει θέματα στα οποία ο συγγραφέας δεν έχει απαντήσει σε ένα αίτημα για περισσότερες πληροφορίες
+* Το [dependabot-preview](https://github.com/marketplace/dependabot-preview) ελέγχει τα αρχεία εξαρτήσεων σας κάθε μέρα για ξεπερασμένες απαιτήσεις και ανοίγει μεμονωμένα pull requests για όποια βρει
 
-For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.
+Για αναφορές σφαλμάτων και άλλες κοινές συνεισφορές, το GitHub διαθέτει [Πρότυπα ζητημάτων και πρότυπα αιτημάτων](https://github.com/blog/2111-issue-and-pull-request-templates), τα οποία μπορείτε να δημιουργήσετε για να βελτιώσετε την επικοινωνία που λαμβάνετε. Ο @TalAter δημιούργησε έναν οδηγό [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) για να σας βοηθήσει να γράψετε τα πρότυπα των ζητημάτων και των PR σας.
 
-To manage your email notifications, you can set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize by priority.
+Για να διαχειριστείτε τις ειδοποιήσεις ηλεκτρονικού ταχυδρομείου σας, μπορείτε να δημιουργήσετε [φίλτρα ηλεκτρονικού ταχυδρομείου](https://github.com/blog/2203-email-updates-about-your-own-activity) για να οργανώνετε με βάση την προτεραιότητα.
 
-If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept.
+Αν θέλετε να προχωρήσετε λίγο περισσότερο, οι οδηγοί στυλ και οι λιντέρ μπορούν να τυποποιήσουν τις συνεισφορές στο πρότζεκτ και να τις κάνουν πιο εύκολες στην αναθεώρηση και στην αποδοχή τους.
 
-However, if your standards are too complicated, they can increase the barriers to contribution. Make sure you're only adding enough rules to make everyone's lives easier.
+Ωστόσο, αν τα πρότυπα σας είναι πολύ περίπλοκα, μπορεί να αυξήσουν τα εμπόδια στη συνεισφορά. Βεβαιωθείτε ότι προσθέτετε μόνο αρκετούς κανόνες για να κάνετε τη ζωή όλων πιο εύκολη.
 
-If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors.
+Αν δεν είστε σίγουροι για το ποια εργαλεία να χρησιμοποιήσετε, κοιτάξτε τι κάνουν άλλα δημοφιλή πρότζεκτ, ειδικά αυτά που ανήκουν στο οικοσύστημά σας. Για παράδειγμα, πώς μοιάζει η διαδικασία συνεισφοράς για άλλες ενότητες του Node; Η χρήση παρόμοιων εργαλείων και προσεγγίσεων θα κάνει επίσης τη διαδικασία σας πιο οικεία στους συνεισφέροντες-στόχους σας.
 
 ## It's okay to hit pause
 

From 7126b3533c4b6b0993045864bc69e1225ad45771 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Mon, 4 Apr 2022 21:42:56 +0300
Subject: [PATCH 332/749] Finish translations on best-practices.md

---
 _articles/el/best-practices.md | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
index 46d42517a0f..dc822415245 100644
--- a/_articles/el/best-practices.md
+++ b/_articles/el/best-practices.md
@@ -249,32 +249,32 @@ related:
 
 Αν δεν είστε σίγουροι για το ποια εργαλεία να χρησιμοποιήσετε, κοιτάξτε τι κάνουν άλλα δημοφιλή πρότζεκτ, ειδικά αυτά που ανήκουν στο οικοσύστημά σας. Για παράδειγμα, πώς μοιάζει η διαδικασία συνεισφοράς για άλλες ενότητες του Node; Η χρήση παρόμοιων εργαλείων και προσεγγίσεων θα κάνει επίσης τη διαδικασία σας πιο οικεία στους συνεισφέροντες-στόχους σας.
 
-## It's okay to hit pause
+## Δεν πειράζει να κάνετε διάλειμμα!
 
-Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty.
+Η εργασία σε ανοιχτό κώδικα κάποτε σας έδινε χαρά. Ίσως τώρα αρχίζει να σας κάνει να νιώθετε αποφυγή ή ενοχές.
 
-Perhaps you're feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up.
+Ίσως αισθάνεστε συγκλονισμένοι ή μια αυξανόμενη αίσθηση τρόμου όταν σκέφτεστε τα πρότζεκτ σας. Και εν τω μεταξύ, τα ζητήματα και τα αιτήματα για την έκδοση προτάσεων συσσωρεύονται.
 
-Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project.
+Η επαγγελματική εξουθένωση είναι ένα πραγματικό και διάχυτο ζήτημα στην εργασία ανοιχτού κώδικα, ειδικά μεταξύ των συντηρητών. Ως συντηρητής, η ευτυχία σας είναι αδιαπραγμάτευτη προϋπόθεση για την επιβίωση κάθε έργου ανοιχτού κώδικα.
 
-Although it should go without saying, take a break! You shouldn't have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take [a month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) after 14 years of volunteer OSS work.
+Αν και θα έπρεπε να είναι αυτονόητο, κάντε ένα διάλειμμα! Δεν θα πρέπει να περιμένετε μέχρι να νιώσετε εξαντλημένοι για να κάνετε διακοπές. Ο @brettcannon, ένας κύριος προγραμματιστής της Python, αποφάσισε να κάνει [ένα μήνα διακοπές](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) μετά από 14 χρόνια εθελοντικής εργασίας στο OSS.
 
-Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work.
+Ακριβώς όπως και σε κάθε άλλο είδος εργασίας, το να κάνετε τακτικά διαλείμματα θα σας κρατήσει ανανεωμένους, χαρούμενους και ενθουσιασμένους με τη δουλειά σας.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
-  In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
+  Διατηρώντας το WP-CLI, ανακάλυψα ότι πρέπει πρώτα να κάνω τον εαυτό μου ευτυχισμένο και να θέσω σαφή όρια στη συμμετοχή μου. Η καλύτερη ισορροπία που έχω βρει είναι 2-5 ώρες την εβδομάδα, ως μέρος του κανονικού μου προγράμματος εργασίας. Αυτό κρατάει τη συμμετοχή μου ως πάθος και δεν την αισθάνομαι υπερβολικά σαν δουλειά. Επειδή ιεραρχώ τα θέματα στα οποία εργάζομαι, μπορώ να σημειώνω τακτική πρόοδο σε ό,τι θεωρώ πιο σημαντικό.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+- @danielbachhuber, ["Τα συλλυπητήριά μου, είστε τώρα ο συντηρητής ενός δημοφιλούς πρότζεκτ ανοικτού κώδικα"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
-Sometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away.
+Μερικές φορές, μπορεί να είναι δύσκολο να κάνεις ένα διάλειμμα από την εργασία ανοιχτού κώδικα όταν νιώθεις ότι όλοι σε χρειάζονται. Οι άνθρωποι μπορεί ακόμη και να προσπαθήσουν να σας κάνουν να νιώσετε ένοχοι που απομακρύνεστε.
 
-Do your best to find support for your users and community while you're away from a project. If you can't find the support you need, take a break anyway. Be sure to communicate when you're not available, so people aren't confused by your lack of responsiveness.
+Κάνετε ό,τι μπορείτε για να βρείτε υποστήριξη για τους χρήστες και την κοινότητά σας, ενώ βρίσκεστε μακριά από ένα έργο. Αν δεν μπορείτε να βρείτε την υποστήριξη που χρειάζεστε, κάντε ένα διάλειμμα ούτως ή άλλως. Φροντίστε να επικοινωνείτε όταν δεν είστε διαθέσιμοι, ώστε οι άνθρωποι να μην μπερδεύονται από την έλλειψη ανταπόκρισής σας.
 
-Taking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you.
+Το να κάνετε διαλείμματα ισχύει και για κάτι περισσότερο από τις διακοπές. Αν δεν θέλετε να κάνετε εργασίες ανοιχτού κώδικα τα Σαββατοκύριακα ή κατά τη διάρκεια των ωρών εργασίας, επικοινωνήστε αυτές τις προσδοκίες στους άλλους, ώστε να ξέρουν να μην σας ενοχλούν.
 
-## Take care of yourself first!
+## Φροντίστε πρώτα τον εαυτό σας!
 
-Maintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive.
+Η διατήρηση ενός δημοφιλούς πρότζεκτ απαιτεί διαφορετικές δεξιότητες από τα προηγούμενα στάδια ανάπτυξης, αλλά δεν είναι λιγότερο ικανοποιητική. Ως συντηρητής, θα εξασκήσετε ηγετικές και προσωπικές δεξιότητες σε ένα επίπεδο που λίγοι άνθρωποι έχουν την ευκαιρία να βιώσουν. Αν και δεν είναι πάντα εύκολο να το διαχειριστείτε, ο καθορισμός σαφών ορίων και η ανάληψη μόνο όσων σας βολεύουν θα σας βοηθήσει να παραμείνετε ευτυχισμένοι, ανανεωμένοι και παραγωγικοί.

From 6010e618d6f214a53dccf2439e24edf5eec6dde3 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Mon, 4 Apr 2022 22:13:45 +0300
Subject: [PATCH 333/749] Start work on building-community.md

---
 _articles/el/building-community.md | 86 +++++++++++++++---------------
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index a09ff3c7737..8faab57892b 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -10,98 +10,98 @@ related:
   - coc
 ---
 
-## Setting your project up for success
+## Προετοιμάζοντας το πρότζεκτ σας για την επιτυχία
 
-You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around?
+Ξεκινήσατε το πρότζεκτ σας, το διαδίδετε και ο κόσμος το ελέγχει. Φοβερό! Τώρα, πώς θα τους κάνετε να παραμείνουν;
 
-A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back.
+Μια φιλόξενη κοινότητα είναι μια επένδυση στο μέλλον και τη φήμη του πρότζεκτ σας. Αν το πρότζεκτ σας μόλις αρχίζει να βλέπει τις πρώτες συνεισφορές, ξεκινήστε δίνοντας στους πρώτους συνεισφέροντες μια θετική εμπειρία και διευκολύνετέ τους να συνεχίσουν να επιστρέφουν.
 
-### Make people feel welcome
+### Κάντε τους ανθρώπους να αισθάνονται ευπρόσδεκτοι
 
-One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+Ένας τρόπος για να σκεφτείτε την κοινότητα του έργου σας είναι αυτό που ο @MikeMcQuaid αποκαλεί [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
 
 ![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
 
-As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more.
+Καθώς χτίζετε την κοινότητά σας, σκεφτείτε πώς κάποιος που βρίσκεται στην κορυφή του χωνιού (ένας δυνητικός χρήστης) θα μπορούσε θεωρητικά να φτάσει στο κάτω μέρος (ένας ενεργός συντηρητής). Στόχος σας είναι να μειώσετε τις τριβές σε κάθε στάδιο της εμπειρίας του συνεισφέροντος. Όταν οι άνθρωποι έχουν εύκολες επιτυχίες, θα νιώθουν κίνητρο να κάνουν περισσότερα.
 
-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.
+* **Κάντε εύκολο για κάποιον να χρησιμοποιήσει το πρότζεκτ σας.** [Ένα φιλικό README](../starting-a-project/#writing-a-readme) και σαφή παραδείγματα κώδικα θα διευκολύνουν οποιονδήποτε βρεθεί στο πρότζεκτ σας να ξεκινήσει.
+* **Εξηγήστε με σαφήνεια πώς να συνεισφέρετε**, χρησιμοποιώντας [το αρχείο CONTRIBUTING](../starting-a-project/#writing-your-contributing-guidelines) και διατηρώντας τα θέματά σας ενημερωμένα.
+* **Καλά πρώτα θέματα**: Για να βοηθήσετε τους νέους συνεισφέροντες να ξεκινήσουν, σκεφτείτε ρητά [την επισήμανση θεμάτων που είναι αρκετά απλά για να τα αντιμετωπίσουν οι αρχάριοι](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Στη συνέχεια, το GitHub θα εμφανίσει αυτά τα θέματα σε διάφορα σημεία της πλατφόρμας, αυξάνοντας τις χρήσιμες συνεισφορές και μειώνοντας τις τριβές από τους χρήστες που αντιμετωπίζουν θέματα που είναι πολύ δύσκολα για το επίπεδό τους.
 
-[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.
+[Η έρευνα του GitHub για τον ανοικτό κώδικα του 2017](http://opensourcesurvey.org/2017/) έδειξε ότι η ελλιπής ή συγκεχυμένη τεκμηρίωση είναι το μεγαλύτερο πρόβλημα για τους χρήστες ανοικτού κώδικα. Η καλή τεκμηρίωση προσκαλεί τους ανθρώπους να αλληλεπιδράσουν με το πρότζεκτ σας. Τελικά, κάποιος θα ανοίξει ένα ζήτημα ή ένα αίτημα. Χρησιμοποιήστε αυτές τις αλληλεπιδράσεις ως ευκαιρίες για να τους μετακινήσετε προς τα κάτω στο χωνί.
 
-* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
-* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
-* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or a small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
-* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#μαθαίνοντας-να-λέτε-όχι) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+* **Όταν κάποιος νέος μπαίνει στο έργο σας, ευχαριστήστε τον για το ενδιαφέρον του!** Αρκεί μια αρνητική εμπειρία για να κάνει κάποιον να μην θέλει να επιστρέψει.
+* **Ανταποκριθείτε.** Αν δεν απαντήσετε στο θέμα τους για ένα μήνα, οι πιθανότητες είναι ότι έχουν ήδη ξεχάσει το έργο σας.
+* **Να είστε ανοιχτόμυαλοι όσον αφορά τους τύπους συνεισφορών που θα δεχτείτε.** Πολλοί συνεισφέροντες ξεκινούν με μια αναφορά σφάλματος ή μια μικρή διόρθωση. Υπάρχουν [πολλοί τρόποι συνεισφοράς](../how-to-contribute/#what-it-means-to-contribute) σε ένα πρότζεκτ. Αφήστε τους ανθρώπους να βοηθήσουν με τον τρόπο που θέλουν να βοηθήσουν.
+* **Αν υπάρχει μια συνεισφορά με την οποία διαφωνείτε,** ευχαριστήστε τους για την ιδέα τους και [εξηγήστε γιατί](../best-practices/#μαθαίνοντας-να-λέτε-όχι) δεν ταιριάζει στο πεδίο εφαρμογής του πρότζεκτυ, παραπέμποντας στη σχετική τεκμηρίωση αν την έχετε.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns.
+  Η συνεισφορά στον ανοιχτό κώδικα είναι ευκολότερη για κάποιους από άλλους. Υπάρχει μεγάλος φόβος να τους φωνάξουν ότι δεν κάνουν κάτι σωστά ή ότι απλά δεν ταιριάζουν. (...) Δίνοντας στους συνεισφέροντες ένα μέρος για να συνεισφέρουν με πολύ χαμηλή τεχνική επάρκεια (τεκμηρίωση, markdown περιεχομένου ιστού, κ.λπ.) μπορείτε να μειώσετε σημαντικά αυτές τις ανησυχίες.
   <p markdown="1" class="pquote-credit">
-— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+- @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
   </p>
 </aside>
 
-The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute.
+Η πλειονότητα των συνεισφερόντων ανοιχτού κώδικα είναι "περιστασιακοί συνεισφέροντες": άνθρωποι που συνεισφέρουν σε ένα πρότζεκτ μόνο περιστασιακά. Ένας περιστασιακός συνεισφέρων μπορεί να μην έχει χρόνο να ενημερωθεί πλήρως για το πρότζεκτ σας, οπότε η δουλειά σας είναι να τους διευκολύνετε να συνεισφέρουν.
 
-Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself.
+Η ενθάρρυνση άλλων συνεισφερόντων είναι μια επένδυση και στον εαυτό σας. Όταν εξουσιοδοτείτε τους μεγαλύτερους θαυμαστές σας να ασχοληθούν με το πρότζεκτ για το οποίο είναι ενθουσιασμένοι, υπάρχει λιγότερη πίεση να κάνετε τα πάντα εσείς.
 
-### Document everything
+### Καταγράψτε τα πάντα
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
+  Έχετε πάει ποτέ σε μια (τεχνολογική) εκδήλωση όπου δεν γνωρίζατε κανέναν, αλλά όλοι οι άλλοι έμοιαζαν να στέκονται σε ομάδες και να συζητούν σαν παλιοί φίλοι; (...) Φανταστείτε τώρα ότι θέλετε να συνεισφέρετε σε ένα πρότζεκτ ανοικτού κώδικα, αλλά δεν καταλαβαίνετε γιατί ή πώς συμβαίνει αυτό.
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+- @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
-When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public.
+Όταν ξεκινάτε ένα νέο πρότζεκτ, μπορεί να σας φαίνεται φυσικό να κρατάτε την εργασία σας ιδιωτική. Αλλά τα έργα ανοικτού κώδικα ευδοκιμούν όταν τεκμηριώνετε τη διαδικασία σας δημόσια.
 
-When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed.
+Όταν καταγράφετε τα πράγματα, περισσότεροι άνθρωποι μπορούν να συμμετέχουν σε κάθε βήμα της διαδικασίας. Μπορεί να λάβετε βοήθεια για κάτι που δεν γνωρίζατε καν ότι χρειαζόσασταν.
 
-Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public.
+Η καταγραφή των πραγμάτων σημαίνει κάτι περισσότερο από απλή τεχνική τεκμηρίωση. Κάθε φορά που νιώθετε την ανάγκη να γράψετε κάτι ή να συζητήσετε κατ' ιδίαν το έργο σας, αναρωτηθείτε αν μπορείτε να το δημοσιοποιήσετε.
 
-Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions.
+Να είστε διαφανείς σχετικά με τον οδικό χάρτη του έργου σας, τα είδη των συνεισφορών που αναζητάτε, τον τρόπο εξέτασης των συνεισφορών ή τους λόγους για τους οποίους πήρατε ορισμένες αποφάσεις.
 
-If you notice multiple users running into the same problem, document the answers in the README.
+Αν παρατηρήσετε ότι πολλοί χρήστες αντιμετωπίζουν το ίδιο πρόβλημα, τεκμηριώστε τις απαντήσεις στο README.
 
-For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you.
+Για συναντήσεις, σκεφτείτε να δημοσιεύσετε τις σημειώσεις ή τα συμπεράσματα σας σε ένα σχετικό θέμα. Η ανατροφοδότηση που θα λάβετε από αυτό το επίπεδο διαφάνειας μπορεί να σας εκπλήξει.
 
-Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on.
+Η τεκμηρίωση των πάντων ισχύει και για την εργασία που κάνετε. Αν εργάζεστε σε μια ουσιαστική ενημέρωση του πρότζεκτ σας, βάλτε την σε ένα pull request και σημειώστε την ως εργασία σε εξέλιξη (WIP). Με αυτόν τον τρόπο, άλλοι άνθρωποι μπορούν να νιώσουν ότι συμμετέχουν στη διαδικασία από νωρίς.
 
-### Be responsive
+### Να ανταποκρίνεστε
 
-As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started.
+Καθώς [προωθείτε το έργο σας](../finding-users), οι άνθρωποι θα έχουν ανατροφοδότηση για εσάς. Μπορεί να έχουν ερωτήσεις σχετικά με το πώς λειτουργούν τα πράγματα ή να χρειάζονται βοήθεια για να ξεκινήσουν.
 
-Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating.
+Προσπαθήστε να ανταποκρίνεστε όταν κάποιος καταθέτει ένα ζήτημα, υποβάλλει ένα αίτημα ή κάνει μια ερώτηση σχετικά με το πρότζεκτ σας. Όταν απαντάτε γρήγορα, οι άνθρωποι θα αισθάνονται ότι είναι μέρος ενός διαλόγου και θα είναι πιο ενθουσιώδεις για τη συμμετοχή τους.
 
-Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466):
+Ακόμα και αν δεν μπορείτε να εξετάσετε το αίτημα αμέσως, η έγκαιρη αναγνώρισή του συμβάλλει στην αύξηση της δέσμευσης. Δείτε πώς απάντησε ο @tdreyno σε ένα pull request στο [Middleman](https://github.com/middleman/middleman/pull/1466):
 
 ![Middleman pull request](/assets/images/building-community/middleman_pr.png)
 
-[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution.
+[Μια μελέτη της Mozilla διαπίστωσε ότι](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) οι συνεισφέροντες που λάμβαναν αξιολογήσεις κώδικα (code reviews) εντός 48 ωρών είχαν πολύ υψηλότερο ποσοστό επιστροφής και επαναλαμβανόμενης συνεισφοράς.
 
-Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project.
+Συζητήσεις σχετικά με το πρότζεκτ σας θα μπορούσαν επίσης να συμβαίνουν και σε άλλα μέρη του διαδικτύου, όπως το Stack Overflow, το Twitter ή το Reddit. Μπορείτε να ρυθμίσετε ειδοποιήσεις σε ορισμένα από αυτά τα μέρη, ώστε να ειδοποιείστε όταν κάποιος αναφέρει το πρότζεκτ σας.
 
-### Give your community a place to congregate
+### Δώστε στην κοινότητά σας ένα μέρος για να συγκεντρωθεί
 
-There are two reasons to give your community a place to congregate.
+Υπάρχουν δύο λόγοι για να δώσετε στην κοινότητά σας ένα μέρος για να συγκεντρωθεί.
 
-The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate.
+Ο πρώτος λόγος είναι γι' αυτούς. Βοηθήστε τους ανθρώπους να γνωριστούν μεταξύ τους. Οι άνθρωποι με κοινά ενδιαφέροντα θα θέλουν αναπόφευκτα ένα μέρος για να μιλήσουν γι' αυτά. Και όταν η επικοινωνία είναι δημόσια και προσβάσιμη, ο καθένας μπορεί να διαβάσει τα αρχεία του παρελθόντος για να ενημερωθεί και να συμμετάσχει.
 
-The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel.
+Ο δεύτερος λόγος είναι για εσάς. Αν δεν δώσετε στους ανθρώπους ένα δημόσιο μέρος για να μιλήσουν για το πρότζεκτ σας, πιθανότατα θα επικοινωνήσουν απευθείας μαζί σας. Στην αρχή, μπορεί να φαίνεται αρκετά εύκολο να απαντήσετε σε ιδιωτικά μηνύματα "μόνο αυτή τη φορά". Αλλά με την πάροδο του χρόνου, ειδικά αν το πρότζεκτ σας γίνει δημοφιλές, θα νιώσετε εξαντλημένοι. Αντισταθείτε στον πειρασμό να επικοινωνείτε με τους ανθρώπους για το πρότζεκτ σας ιδιωτικά. Αντ' αυτού, κατευθύνετέ τους σε ένα καθορισμένο δημόσιο κανάλι.
 
-Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above!
+Η δημόσια επικοινωνία μπορεί να είναι τόσο απλή όσο το να κατευθύνετε τους ανθρώπους να ανοίξουν ένα θέμα αντί να σας στείλουν απευθείας email ή να σχολιάσουν στο ιστολόγιό σας. Θα μπορούσατε επίσης να δημιουργήσετε μια λίστα αλληλογραφίας ή έναν λογαριασμό στο Twitter, το Slack ή ένα κανάλι IRC για να συζητούν οι άνθρωποι για το πρότζεκτ σας. Ή δοκιμάστε όλα τα παραπάνω!
 
-[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members:
+Το [Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) ορίζει ώρες γραφείου κάθε δεύτερη εβδομάδα για να βοηθήσει τα μέλη της κοινότητας:
 
-> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.
+> Το Kops διαθέτει επίσης χρόνο που ορίζεται κάθε δεύτερη εβδομάδα για να προσφέρει βοήθεια και καθοδήγηση στην κοινότητα. Οι συντηρητές του Kops έχουν συμφωνήσει να ορίσουν χρόνο ειδικά αφιερωμένο στη συνεργασία με νεοεισερχόμενους, στη βοήθεια με PRs και στη συζήτηση νέων χαρακτηριστικών.
 
-Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address.
+Αξιοσημείωτες εξαιρέσεις στη δημόσια επικοινωνία είναι: 1) θέματα ασφάλειας και 2) ευαίσθητες παραβιάσεις του κώδικα συμπεριφοράς. Θα πρέπει πάντα να έχετε έναν τρόπο για τους ανθρώπους να αναφέρουν αυτά τα ζητήματα ιδιωτικά. Αν δεν θέλετε να χρησιμοποιείτε το προσωπικό σας email, δημιουργήστε μια ειδική διεύθυνση email.
 
 ## Growing your community
 

From 97c9abd8435fed27db4f8888d37955939746a589 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 5 Apr 2022 23:02:42 +0300
Subject: [PATCH 334/749] Make some more progress on building-community.md!

Also fixes some issues with some hyperlinks that would take the user
to pages that do not exist anymore due to them changing title names.
---
 _articles/el/best-practices.md            |  2 +-
 _articles/el/building-community.md        | 80 +++++++++++------------
 _articles/el/leadership-and-governance.md |  2 +-
 3 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
index dc822415245..886581b8fb7 100644
--- a/_articles/el/best-practices.md
+++ b/_articles/el/best-practices.md
@@ -169,7 +169,7 @@ related:
 
 Όταν βλέπετε νέους συνεισφέροντες να κάνουν επαναλαμβανόμενες συνεισφορές, αναγνωρίστε το έργο τους προσφέροντας περισσότερες ευθύνες. Τεκμηριώστε τον τρόπο με τον οποίο οι άλλοι μπορούν να εξελιχθούν σε ηγετικούς ρόλους αν το επιθυμούν.
 
-Το να ενθαρρύνετε τους άλλους να [μοιράζονται την ιδιοκτησία του έργου](../building-community/#share-ownership-of-your-project) μπορεί να μειώσει σημαντικά τον δικό σας φόρτο εργασίας, όπως ανακάλυψε η @lmccart στο έργο της, [p5.js](https://github.com/processing/p5.js).
+Το να ενθαρρύνετε τους άλλους να [μοιράζονται την ιδιοκτησία του έργου](../building-community/#μοιραστείτε-την-ιδιοκτησία-του-πρότζεκτ-σας) μπορεί να μειώσει σημαντικά τον δικό σας φόρτο εργασίας, όπως ανακάλυψε η @lmccart στο έργο της, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index 8faab57892b..f6cf788e274 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -103,103 +103,103 @@ related:
 
 Αξιοσημείωτες εξαιρέσεις στη δημόσια επικοινωνία είναι: 1) θέματα ασφάλειας και 2) ευαίσθητες παραβιάσεις του κώδικα συμπεριφοράς. Θα πρέπει πάντα να έχετε έναν τρόπο για τους ανθρώπους να αναφέρουν αυτά τα ζητήματα ιδιωτικά. Αν δεν θέλετε να χρησιμοποιείτε το προσωπικό σας email, δημιουργήστε μια ειδική διεύθυνση email.
 
-## Growing your community
+## Μεγαλώνοντας την κοινότητά σας
 
-Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction.
+Οι κοινότητες είναι εξαιρετικά ισχυρές. Αυτή η δύναμη μπορεί να είναι ευλογία ή κατάρα, ανάλογα με τον τρόπο που την ασκείτε. Καθώς η κοινότητα του πρότζεκτ σας μεγαλώνει, υπάρχουν τρόποι να τη βοηθήσετε να γίνει μια δύναμη οικοδόμησης και όχι καταστροφής.
 
-### Don't tolerate bad actors
+### Μην ανέχεστε τους κακούς φορείς
 
-Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others.
+Κάθε δημοφιλές πρότζεκτ θα προσελκύσει αναπόφευκτα ανθρώπους που βλάπτουν, αντί να βοηθούν, την κοινότητά σας. Μπορεί να ξεκινήσουν περιττές συζητήσεις, να τσακωθούν για ασήμαντα χαρακτηριστικά ή να εκφοβίσουν άλλους.
 
-Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave.
+Κάντε ό,τι μπορείτε για να υιοθετήσετε μια πολιτική μηδενικής ανοχής απέναντι σε αυτούς τους τύπους ανθρώπων. Αν δεν ελεγχθούν, οι αρνητικοί άνθρωποι θα κάνουν τους άλλους ανθρώπους της κοινότητάς σας να νιώθουν άβολα. Μπορεί ακόμη και να φύγουν.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
-  The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.
+  Η αλήθεια είναι ότι η ύπαρξη μιας υποστηρικτικής κοινότητας είναι το κλειδί. Δεν θα μπορούσα ποτέ να κάνω αυτή τη δουλειά χωρίς τη βοήθεια των συναδέλφων μου, των φιλικών αγνώστων στο διαδίκτυο και των φλύαρων καναλιών IRC. (...) Μην συμβιβάζεστε με λιγότερα. Μην συμβιβάζεστε με μαλάκες.
   <p markdown="1" class="pquote-credit">
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+- @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
   </p>
 </aside>
 
-Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
+Οι τακτικές συζητήσεις για ασήμαντες πτυχές του πρότζεκτ σας αποσπούν την προσοχή των άλλων, συμπεριλαμβανομένου και εσάς, από το να επικεντρωθούν σε σημαντικά καθήκοντα. Τα νέα άτομα που φτάνουν στο πρότζεκτ σας μπορεί να δουν αυτές τις συζητήσεις και να μην θέλουν να συμμετάσχουν.
 
-When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations.
+Όταν βλέπετε αρνητική συμπεριφορά να συμβαίνει στο πρότζεκτ σας, φωνάξτε την δημόσια. Εξηγήστε, με ευγενικό αλλά αυστηρό τόνο, γιατί η συμπεριφορά τους δεν είναι αποδεκτή. Αν το πρόβλημα επιμένει, ίσως χρειαστεί να [τους ζητήσετε να φύγουν](../code-of-conduct/#enforcing-your-code-of-conduct). Ο [κώδικας δεοντολογίας](../code-of-conduct/) μπορεί να αποτελέσει εποικοδομητικό οδηγό για αυτές τις συζητήσεις.
 
-### Meet contributors where they're at
+### Συναντήστε τους συνεισφέροντες εκεί που βρίσκονται
 
-Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need.
+Η καλή τεκμηρίωση γίνεται όλο και πιο σημαντική καθώς η κοινότητά σας μεγαλώνει. Οι περιστασιακοί συνεισφέροντες, οι οποίοι μπορεί διαφορετικά να μην είναι εξοικειωμένοι με το πρότζεκτ σας, διαβάζουν την τεκμηρίωσή σας για να αποκτήσουν γρήγορα το πλαίσιο που χρειάζονται.
 
-In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors.
+Στο αρχείο σας CONTRIBUTING, πείτε ρητά στους νέους συνεισφέροντες πώς να ξεκινήσουν. Ίσως μάλιστα να θέλετε να φτιάξετε μια ειδική ενότητα για το σκοπό αυτό. Το [Django](https://github.com/django/django), για παράδειγμα, έχει μια ειδική σελίδα για να καλωσορίζει τους νέους συνεισφέροντες.
 
 ![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
 
-In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started.
+Στην ουρά θεμάτων σας, επισημάνετε σφάλματα που είναι κατάλληλα για διαφορετικούς τύπους συνεισφερόντων: για παράδειγμα, [_"μόνο για πρωτοεμφανιζόμενους"_](https://kentcdodds.com/blog/first-timers-only), _"καλό πρώτο θέμα"_, ή _"τεκμηρίωση"_. [Αυτές οι ετικέτες](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) διευκολύνουν κάποιον νέο στο πρότζεκτ σας να σαρώσει γρήγορα τα θέματά σας και να ξεκινήσει.
 
-Finally, use your documentation to make people feel welcome at every step of the way.
+Τέλος, χρησιμοποιήστε την τεκμηρίωσή σας για να κάνετε τους ανθρώπους να αισθάνονται ευπρόσδεκτοι σε κάθε βήμα της διαδικασίας.
 
-You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration.
+Δεν θα αλληλεπιδράσετε ποτέ με τους περισσότερους ανθρώπους που θα βρεθούν στο πρότζεκτ σας. Μπορεί να υπάρξουν συνεισφορές που δεν λάβατε επειδή κάποιος ένιωσε εκφοβισμένος ή δεν ήξερε από πού να ξεκινήσει. Ακόμη και μερικά καλά λόγια μπορούν να αποτρέψουν κάποιον από το να εγκαταλείψει το πρότζεκτ σας απογοητευμένος.
 
-For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+Για παράδειγμα, να πώς ξεκινάει ο [Rubinius](https://github.com/rubinius/rubinius/) τον [οδηγό συνεισφοράς του](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
 
-> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
+> Θέλουμε να ξεκινήσουμε λέγοντας σας ευχαριστούμε που χρησιμοποιείτε το Rubinius. Αυτό το πρότζεκτ είναι έργο αγάπης και εκτιμούμε όλους τους χρήστες που εντοπίζουν σφάλματα, κάνουν βελτιώσεις στην απόδοση και βοηθούν με την τεκμηρίωση. Κάθε συνεισφορά έχει νόημα, γι' αυτό σας ευχαριστούμε για τη συμμετοχή σας. Τούτου λεχθέντος, παραθέτουμε μερικές οδηγίες που σας ζητάμε να ακολουθήσετε ώστε να μπορέσουμε να αντιμετωπίσουμε με επιτυχία το πρόβλημά σας.
 
-### Share ownership of your project
+### Μοιραστείτε την ιδιοκτησία του πρότζεκτ σας
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
-  Your leaders will have different opinions, as all healthy communities should! However, you need to take steps to ensure the loudest voice doesn't always win by tiring people out, and that less prominent and minority voices are heard.
+  Οι ηγέτες σας θα έχουν διαφορετικές απόψεις, όπως πρέπει να έχουν όλες οι υγιείς κοινότητες! Ωστόσο, πρέπει να λάβετε μέτρα για να διασφαλίσετε ότι η πιο δυνατή φωνή δεν κερδίζει πάντα, κουράζοντας τους ανθρώπους, και ότι ακούγονται οι λιγότερο εξέχουσες και μειονοτικές φωνές.
   <p markdown="1" class="pquote-credit">
-— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+- @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
   </p>
 </aside>
 
-People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around.
+Οι άνθρωποι είναι ενθουσιασμένοι να συνεισφέρουν σε πρότζεκτς όταν αισθάνονται την αίσθηση της ιδιοκτησίας. Αυτό δεν σημαίνει ότι πρέπει να παραδώσετε το όραμα του πρότζεκτ σας ή να δεχτείτε συνεισφορές που δεν θέλετε. Αλλά όσο περισσότερο δίνετε τα εύσημα στους άλλους, τόσο περισσότερο θα παραμείνουν στο πρότζεκτ.
 
-See if you can find ways to share ownership with your community as much as possible. Here are some ideas:
+Δείτε αν μπορείτε να βρείτε τρόπους να μοιράζεστε την ιδιοκτησία με την κοινότητά σας όσο το δυνατόν περισσότερο. Ακολουθούν μερικές ιδέες:
 
-* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself.
+* **Αποφύγετε την επιδιόρθωση εύκολων (μη κρίσιμων) σφαλμάτων.** Αντ' αυτού, χρησιμοποιήστε τα ως ευκαιρίες για να προσλάβετε νέους συνεισφέροντες ή να καθοδηγήσετε κάποιον που θα ήθελε να συνεισφέρει. Μπορεί να φαίνεται αφύσικο στην αρχή, αλλά η επένδυσή σας θα αποδώσει με την πάροδο του χρόνου. Για παράδειγμα, ο @michaeljoseph ζήτησε από έναν συνεργάτη να υποβάλει ένα pull request για ένα πρόβλημα [Cookiecutter](https://github.com/audreyr/cookiecutter) παρακάτω, αντί να το διορθώσει ο ίδιος.
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
+* **Ξεκινήστε ένα αρχείο CONTRIBUTORS ή AUTHORS στο πρότζκετ σας** το οποίο θα απαριθμεί όλους όσους έχουν συνεισφέρει στο πρότζεκτ σας, όπως κάνει το [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
 
-* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+* Αν έχετε μια σημαντική κοινότητα, **αποστείλετε ένα ενημερωτικό δελτίο ή γράψτε μια δημοσίευση στο ιστολόγιο** ευχαριστώντας τους συνεισφέροντες. Το [This Week in Rust](https://this-week-in-rust.org/) του Rust και το [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) του Hoodie είναι δύο καλά παραδείγματα.
 
-* **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.
+* **Δώστε σε κάθε συνεισφέροντα πρόσβαση για commit.** Ο @felixge διαπίστωσε ότι αυτό έκανε τους ανθρώπους [πιο ενθουσιασμένους να γυαλίζουν τις διορθώσεις τους](https://felixge.de/2013/03/11/the-pull-request-hack.html), και βρήκε ακόμα και νέους συντηρητές για πρότζεκτ στα οποία δεν είχε δουλέψει για λίγο καιρό.
 
-* 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.
+* Αν το πρότζεκτ σας είναι στο GitHub, **μεταφέρετε το πρότζκετ σας από τον προσωπικό σας λογαριασμό σε έναν [Οργανισμό](https://help.github.com/articles/creating-a-new-organization-account/)** και προσθέστε τουλάχιστον έναν εφεδρικό διαχειριστή. Οι οργανισμοί διευκολύνουν την εργασία σε πρότζεκτς με εξωτερικούς συνεργάτες.
 
-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.
+Η πραγματικότητα είναι ότι [τα περισσότερα πρότζεκτς έχουν μόνο](https://peerj.com/preprints/1233/) έναν ή δύο συντηρητές που κάνουν την περισσότερη δουλειά. Όσο μεγαλύτερο είναι το πρότζεκτ σας και όσο μεγαλύτερη είναι η κοινότητά σας, τόσο πιο εύκολο είναι να βρείτε βοήθεια.
 
-While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help.
+Παρόλο που μπορεί να μην βρίσκετε πάντα κάποιον να ανταποκριθεί στο κάλεσμα, το να στέλνετε ένα σήμα εκεί έξω αυξάνει τις πιθανότητες να βοηθήσουν και άλλοι άνθρωποι. Και όσο νωρίτερα ξεκινήσετε, τόσο νωρίτερα μπορούν να βοηθήσουν οι άνθρωποι.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
-  \[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it.
+  \[Είναι προς το συμφέρον σας\] να προσλάβετε συνεργάτες που απολαμβάνουν και είναι ικανοί να κάνουν τα πράγματα που εσείς δεν κάνετε. Σας αρέσει να προγραμματίζετε, αλλά όχι να απαντάτε σε θέματα; Τότε εντοπίστε εκείνα τα άτομα στην κοινότητά σας που το κάνουν και αφήστε τα να το κάνουν.
   <p markdown="1" class="pquote-credit">
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+- @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
   </p>
 </aside>
 
-## Resolving conflicts
+## Επίλυση συγκρούσεων
 
-In the early stages of your project, making major decisions is easy. When you want to do something, you just do it.
+Στα αρχικά στάδια του πρότζεκτ σας, η λήψη σημαντικών αποφάσεων είναι εύκολη. Όταν θέλετε να κάνετε κάτι, απλά το κάνετε.
 
-As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own.
+Καθώς το πρότζεκτ σας γίνεται πιο δημοφιλές, περισσότεροι άνθρωποι θα ενδιαφέρονται για τις αποφάσεις που παίρνετε. Ακόμα και αν δεν έχετε μια μεγάλη κοινότητα συνεισφερόντων, αν το πρότζεκτ σας έχει πολλούς χρήστες, θα βρείτε ανθρώπους να συμμετέχουν στις αποφάσεις ή να θέτουν τα δικά τους ζητήματα.
 
-For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address.
+Ως επί το πλείστον, αν έχετε καλλιεργήσει μια φιλική κοινότητα με σεβασμό και έχετε τεκμηριώσει ανοιχτά τις διαδικασίες σας, η κοινότητά σας θα μπορέσει να βρει λύση. Αλλά μερικές φορές συναντάτε ένα ζήτημα που είναι λίγο πιο δύσκολο να αντιμετωπιστεί.
 
-### Set the bar for kindness
+### Ορίστε τον πήχη της ευγένειας
 
-When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you.
+Όταν η κοινότητά σας παλεύει με ένα δύσκολο ζήτημα, τα πνεύματα μπορεί να ανέβουν. Οι άνθρωποι μπορεί να θυμώσουν ή να απογοητευτούν και να ξεσπάσουν ο ένας στον άλλον ή σε εσάς.
 
-Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive.
+Η δουλειά σας ως συντηρητής είναι να αποτρέψετε την κλιμάκωση αυτών των καταστάσεων. Ακόμα και αν έχετε ισχυρή άποψη για το θέμα, προσπαθήστε να πάρετε τη θέση του συντονιστή ή του διευκολυντή, αντί να μπείτε στη μάχη και να προωθήσετε τις απόψεις σας. Αν κάποιος είναι αγενής ή μονοπωλεί τη συζήτηση, [δράστε αμέσως](../building-community/#μην-ανέχεστε-τους-κακούς-φορείς) για να διατηρήσετε τις συζητήσεις πολιτισμένες και παραγωγικές.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
-  As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
+  Ως συντηρητής ενός πρότζεκτ, είναι εξαιρετικά σημαντικό να σέβεστε τους συνεργάτες σας. Συχνά παίρνουν πολύ προσωπικά αυτά που λέτε.
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+- @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/el/leadership-and-governance.md b/_articles/el/leadership-and-governance.md
index c0b8f4504b2..2171d327915 100644
--- a/_articles/el/leadership-and-governance.md
+++ b/_articles/el/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://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/#μοιραστείτε-την-ιδιοκτησία-του-πρότζεκτ-σας).
 
 ## When should I give someone commit access?
 

From 54893c15c99c537bcfe0923313f124dc77831d49 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 5 Apr 2022 23:40:10 +0300
Subject: [PATCH 335/749] Finish translations on building-community.md

---
 _articles/el/building-community.md | 64 +++++++++++++++---------------
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index f6cf788e274..5fb95dccf2a 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -203,74 +203,74 @@ related:
   </p>
 </aside>
 
-Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly.
+Άλλοι άνθρωποι αναζητούν από εσάς καθοδήγηση. Δώστε το καλό παράδειγμα. Μπορείτε ακόμα να εκφράσετε απογοήτευση, δυσαρέσκεια ή ανησυχία, αλλά να το κάνετε με ηρεμία.
 
-Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you.
+Το να διατηρείτε την ψυχραιμία σας δεν είναι εύκολο, αλλά η επίδειξη ηγετικής ικανότητας βελτιώνει την υγεία της κοινότητάς σας. Το διαδίκτυο σας ευχαριστεί.
 
-### Treat your README as a constitution
+### Αντιμετωπίστε το README σας ως σύνταγμα
 
-Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion.
+Το README σας είναι [κάτι περισσότερο από ένα σύνολο οδηγιών](../starting-a-project/#writing-a-readme). Είναι επίσης ένα μέρος για να μιλήσετε για τους στόχους σας, το όραμα του προϊόντος και τον οδικό χάρτη. Αν οι άνθρωποι επικεντρώνονται υπερβολικά στη συζήτηση για την αξία ενός συγκεκριμένου χαρακτηριστικού, μπορεί να βοηθήσει να επανεξετάσετε το README σας και να μιλήσετε για το ανώτερο όραμα του πρότζεκτ σας. Η εστίαση στο README σας αποπροσωποποιεί επίσης τη συζήτηση, ώστε να μπορείτε να έχετε μια εποικοδομητική συζήτηση.
 
-### Focus on the journey, not the destination
+### Επικεντρωθείτε στο ταξίδι, όχι στον προορισμό
 
-Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns.
+Ορισμένα πρότζεκτ χρησιμοποιούν μια διαδικασία ψηφοφορίας για τη λήψη σημαντικών αποφάσεων. Αν και λογική με την πρώτη ματιά, η ψηφοφορία δίνει έμφαση στο να φτάσουμε σε μια "απάντηση", αντί να ακούτε και να αντιμετωπίζετε τις ανησυχίες του άλλου.
 
-Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place.
+Η ψηφοφορία μπορεί να γίνει πολιτική, όπου τα μέλη της κοινότητας αισθάνονται πιεσμένα να κάνουν χάρες ο ένας στον άλλον ή να ψηφίσουν με συγκεκριμένο τρόπο. Επίσης, δεν ψηφίζουν όλοι, είτε πρόκειται για τη [σιωπηλή πλειοψηφία](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) στην κοινότητά σας, είτε για σημερινούς χρήστες που δεν γνώριζαν ότι γινόταν ψηφοφορία.
 
-Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus.
+Ορισμένες φορές, η ψηφοφορία είναι απαραίτητη για την ισοφάριση. Όσο μπορείτε, ωστόσο, δώστε έμφαση στην ["αναζήτηση συναίνεσης"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) και όχι στη συναίνεση.
 
-Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion.
+Στο πλαίσιο μιας διαδικασίας αναζήτησης συναίνεσης, τα μέλη της κοινότητας συζητούν τις σημαντικότερες ανησυχίες μέχρι να νιώσουν ότι έχουν ακουστεί επαρκώς. Όταν απομένουν μόνο δευτερεύουσες ανησυχίες, η κοινότητα προχωράει μπροστά. Η "αναζήτηση συναίνεσης" αναγνωρίζει ότι μια κοινότητα μπορεί να μην είναι σε θέση να καταλήξει σε μια τέλεια απάντηση. Αντιθέτως, δίνει προτεραιότητα στην ακρόαση και τη συζήτηση.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
-  Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
+  Ένα μέρος του λόγου για τον οποίο δεν υπάρχει ένα σύστημα ψηφοφορίας για τα θέματα Atom είναι επειδή η ομάδα Atom δεν πρόκειται να ακολουθήσει ένα σύστημα ψηφοφορίας σε όλες τις περιπτώσεις. Μερικές φορές πρέπει να επιλέγουμε αυτό που θεωρούμε σωστό ακόμα και αν δεν είναι δημοφιλές. (...) Αυτό που μπορώ να προσφέρω και δεσμεύομαι να κάνω... είναι ότι η δουλειά μου είναι να ακούω την κοινότητα.
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+- @lee-dohm on [Η διαδικασία λήψης αποφάσεων του Atom](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
   </p>
 </aside>
 
-Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions.
+Ακόμα και αν δεν υιοθετείτε στην πραγματικότητα μια διαδικασία αναζήτησης συναίνεσης, ως συντηρητής πρότζεκτ, είναι σημαντικό να γνωρίζουν οι άνθρωποι ότι ακούτε. Το να κάνετε τους άλλους ανθρώπους να αισθάνονται ότι ακούγονται και να δεσμεύεστε να επιλύσετε τις ανησυχίες τους, συμβάλλει σε μεγάλο βαθμό στην εκτόνωση των ευαίσθητων καταστάσεων. Στη συνέχεια, ακολουθήστε τα λόγια σας με πράξεις.
 
-Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution.
+Μην βιάζεστε να πάρετε μια απόφαση για χάρη της επίλυσης. Βεβαιωθείτε ότι όλοι αισθάνονται ότι ακούγονται και ότι όλες οι πληροφορίες έχουν δημοσιοποιηθεί προτού προχωρήσετε προς μια λύση.
 
-### Keep the conversation focused on action
+### Κρατήστε τη συζήτηση εστιασμένη στη δράση
 
-Discussion is important, but there is a difference between productive and unproductive conversations.
+Η συζήτηση είναι σημαντική, αλλά υπάρχει διαφορά μεταξύ παραγωγικών και μη παραγωγικών συζητήσεων.
 
-Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down.
+Ενθαρρύνετε τη συζήτηση εφόσον κινείται ενεργά προς την κατεύθυνση της επίλυσης. Εάν είναι σαφές ότι η συζήτηση μαραζώνει ή ξεφεύγει από το θέμα, οι αιχμές γίνονται προσωπικές ή οι άνθρωποι τσακώνονται για ασήμαντες λεπτομέρειες, είναι καιρός να την κλείσετε.
 
-Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues.
+Το να επιτρέπετε τη συνέχιση αυτών των συζητήσεων δεν είναι μόνο κακό για το συγκεκριμένο θέμα, αλλά και για την υγεία της κοινότητάς σας. Στέλνει το μήνυμα ότι αυτού του είδους οι συζητήσεις επιτρέπονται ή ακόμη και ενθαρρύνονται, και μπορεί να αποθαρρύνει τους ανθρώπους από το να εγείρουν ή να επιλύσουν μελλοντικά ζητήματα.
 
-With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_
+Με κάθε σημείο που διατυπώνεται από εσάς ή από άλλους, αναρωτηθείτε: _"Πώς αυτό μας φέρνει πιο κοντά σε μια λύση;"_
 
-If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation.
+Εάν η συζήτηση αρχίζει να ξεφεύγει, ρωτήστε την ομάδα, _"Ποια βήματα πρέπει να ακολουθήσουμε στη συνέχεια;"_ για να επαναπροσανατολίσετε τη συζήτηση.
 
-If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it.
+Εάν μια συζήτηση είναι σαφές ότι δεν οδηγεί πουθενά, δεν υπάρχουν σαφείς ενέργειες που πρέπει να γίνουν ή η κατάλληλη ενέργεια έχει ήδη γίνει, κλείστε το θέμα και εξηγήστε γιατί το κλείσατε.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-  Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
+  Το να καθοδηγείς ένα thread προς τη χρησιμότητα χωρίς να γίνεσαι πιεστικός είναι τέχνη. Δεν θα πετύχει αν απλά νουθετήσουμε τους ανθρώπους να σταματήσουν να σπαταλούν το χρόνο τους ή αν τους ζητήσουμε να μην γράφουν αν δεν έχουν κάτι εποικοδομητικό να πουν. (...) Αντ' αυτού, πρέπει να προτείνετε τις προϋποθέσεις για περαιτέρω πρόοδο: να δώσετε στους ανθρώπους μια διαδρομή, ένα μονοπάτι να ακολουθήσουν που οδηγεί στα αποτελέσματα που θέλετε, χωρίς όμως να ακούγεται σαν να υπαγορεύετε τη συμπεριφορά.
   <p markdown="1" class="pquote-credit">
-— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+- @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
   </p>
 </aside>
 
-### Pick your battles wisely
+### Διαλέξτε τις μάχες σας με σύνεση
 
-Context is important. Consider who is involved in the discussion and how they represent the rest of the community.
+Το πλαίσιο είναι σημαντικό. Σκεφτείτε ποιος συμμετέχει στη συζήτηση και πώς εκπροσωπεί την υπόλοιπη κοινότητα.
 
-Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices.
+Είναι όλοι στην κοινότητα αναστατωμένοι ή έστω ασχολούνται με αυτό το θέμα; Ή είναι ένας μοναχικός ταραχοποιός; Μην ξεχνάτε να λαμβάνετε υπόψη τα σιωπηλά μέλη της κοινότητάς σας, όχι μόνο τις ενεργές φωνές.
 
-If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread.
+Εάν το ζήτημα δεν αντιπροσωπεύει τις ευρύτερες ανάγκες της κοινότητάς σας, ίσως χρειαστεί απλώς να αναγνωρίσετε τις ανησυχίες μερικών ανθρώπων. Αν πρόκειται για επαναλαμβανόμενο ζήτημα χωρίς σαφή λύση, παραπέμψτε τους σε προηγούμενες συζητήσεις για το θέμα και κλείστε το thread.
 
-### Identify a community tiebreaker
+### Προσδιορίστε ένα κριτήριο ισορροπίας της κοινότητας
 
-With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker.
+Με καλή συμπεριφορά και σαφή επικοινωνία, οι περισσότερες δύσκολες καταστάσεις επιλύονται. Ωστόσο, ακόμη και σε μια παραγωγική συζήτηση, μπορεί απλώς να υπάρχει διάσταση απόψεων σχετικά με το πώς πρέπει να προχωρήσουμε. Σε αυτές τις περιπτώσεις, προσδιορίστε ένα άτομο ή μια ομάδα ατόμων που μπορεί να χρησιμεύσει ως ρυθμιστής ισορροπίας.
 
-A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it.
+Ένας ισοβαθμιστής θα μπορούσε να είναι ο κύριος συντηρητής του πρότζεκτ, ή θα μπορούσε να είναι μια μικρή ομάδα ανθρώπων που λαμβάνει μια απόφαση βάσει ψηφοφορίας. Ιδανικά, έχετε προσδιορίσει έναν ισοβαθμιστή και τη σχετική διαδικασία σε ένα αρχείο GOVERNANCE πριν χρειαστεί ποτέ να το χρησιμοποιήσετε.
 
-Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible.
+Η απόφαση ισοβαθμίας σας θα πρέπει να είναι η τελευταία λύση. Τα διχαστικά ζητήματα είναι μια ευκαιρία για την κοινότητά σας να αναπτυχθεί και να μάθει. Αγκαλιάστε αυτές τις ευκαιρίες και χρησιμοποιήστε μια συνεργατική διαδικασία για να προχωρήσετε σε λύση, όπου είναι δυνατόν.
 
-## Community is the ❤️ of open source
+## Η κοινότητα είναι η ❤️ του ανοιχτού κώδικα
 
-Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience.
+Οι υγιείς, ακμάζουσες κοινότητες τροφοδοτούν τις χιλιάδες ώρες που αφιερώνονται στον ανοικτό κώδικα κάθε εβδομάδα. Πολλοί συνεισφέροντες επισημαίνουν άλλους ανθρώπους ως τον λόγο που εργάζονται - ή δεν εργάζονται - στον ανοικτό κώδικα. Μαθαίνοντας πώς να αξιοποιείτε εποικοδομητικά αυτή τη δύναμη, θα βοηθήσετε κάποιον εκεί έξω να έχει μια αξέχαστη εμπειρία ανοιχτού κώδικα.

From 833b91975129f29fbc33d85600df08e9e3aede30 Mon Sep 17 00:00:00 2001
From: Akira Taguchi <akirahattivatti@gmail.com>
Date: Sun, 17 Apr 2022 19:25:08 +0300
Subject: [PATCH 336/749] Remove Issues mention from CONTRIBUTING.md

---
 CONTRIBUTING.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index ec04018395b..d4c334a2ac6 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -37,7 +37,7 @@ Before we get started, here are a few things we expect from you (and that you sh
 
 ## How to contribute
 
-If you'd like to contribute, start by searching through the [issues](https://github.com/github/opensource.guide/issues) and [pull requests](https://github.com/github/opensource.guide/pulls) to see whether someone else has raised a similar idea or question.
+If you'd like to contribute, start by searching through the [pull requests](https://github.com/github/opensource.guide/pulls) to see whether someone else has raised a similar idea or question.
 
 If you don't see your idea listed, and you think it fits into the goals of this guide, open a pull request.
 

From 6ea3e53c30456b3fba8990af64eba56c5ddbd23b Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Mon, 18 Apr 2022 13:46:59 +0100
Subject: [PATCH 337/749] Remove Gemfile.lock, update Dependabot.

Remove `Gemfile.lock`; it doesn't actually affect what we run in
production and we waste a bunch of time applying Dependabot updates.
---
 .github/dependabot.yml |  40 ++----
 .gitignore             |   1 +
 Gemfile.lock           | 297 -----------------------------------------
 3 files changed, 11 insertions(+), 327 deletions(-)
 delete mode 100644 Gemfile.lock

diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index 9417d2257f5..8e9bbb8d821 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -1,32 +1,12 @@
 version: 2
 updates:
-- package-ecosystem: bundler
-  directory: "/"
-  schedule:
-    interval: daily
-    time: "10:00"
-    timezone: Europe/Vienna
-  pull-request-branch-name:
-    separator: "-"
-  open-pull-requests-limit: 99
-  rebase-strategy: disabled
-- package-ecosystem: github-actions
-  directory: "/"
-  schedule:
-    interval: daily
-    time: "10:00"
-    timezone: Europe/Vienna
-  pull-request-branch-name:
-    separator: "-"
-  open-pull-requests-limit: 99
-  rebase-strategy: disabled
-- package-ecosystem: npm
-  directory: "/"
-  schedule:
-    interval: daily
-    time: "10:00"
-    timezone: Europe/Vienna
-  pull-request-branch-name:
-    separator: "-"
-  open-pull-requests-limit: 99
-  rebase-strategy: disabled
+  - package-ecosystem: npm
+    directory: "/"
+    schedule:
+      interval: daily
+      time: "10:00"
+      timezone: Europe/Vienna
+    pull-request-branch-name:
+      separator: "-"
+    open-pull-requests-limit: 99
+    rebase-strategy: disabled
diff --git a/.gitignore b/.gitignore
index 1e32f1a37a4..177fab1a1b5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@ bin
 css/main.scss
 test/node_modules
 test/package-lock.json
+Gemfile.lock
diff --git a/Gemfile.lock b/Gemfile.lock
deleted file mode 100644
index 7baf2cd7345..00000000000
--- a/Gemfile.lock
+++ /dev/null
@@ -1,297 +0,0 @@
-GEM
-  remote: https://rubygems.org/
-  specs:
-    activesupport (6.0.4.6)
-      concurrent-ruby (~> 1.0, >= 1.0.2)
-      i18n (>= 0.7, < 2)
-      minitest (~> 5.1)
-      tzinfo (~> 1.1)
-      zeitwerk (~> 2.2, >= 2.2.2)
-    addressable (2.8.0)
-      public_suffix (>= 2.0.2, < 5.0)
-    coffee-script (2.4.1)
-      coffee-script-source
-      execjs
-    coffee-script-source (1.11.1)
-    colorator (1.1.0)
-    commonmarker (0.23.4)
-    concurrent-ruby (1.1.9)
-    dnsruby (1.61.9)
-      simpleidn (~> 0.1)
-    em-websocket (0.5.3)
-      eventmachine (>= 0.12.9)
-      http_parser.rb (~> 0)
-    ethon (0.15.0)
-      ffi (>= 1.15.0)
-    eventmachine (1.2.7)
-    execjs (2.8.1)
-    faraday (1.10.0)
-      faraday-em_http (~> 1.0)
-      faraday-em_synchrony (~> 1.0)
-      faraday-excon (~> 1.1)
-      faraday-httpclient (~> 1.0)
-      faraday-multipart (~> 1.0)
-      faraday-net_http (~> 1.0)
-      faraday-net_http_persistent (~> 1.0)
-      faraday-patron (~> 1.0)
-      faraday-rack (~> 1.0)
-      faraday-retry (~> 1.0)
-      ruby2_keywords (>= 0.0.4)
-    faraday-em_http (1.0.0)
-    faraday-em_synchrony (1.0.0)
-    faraday-excon (1.1.0)
-    faraday-httpclient (1.0.1)
-    faraday-multipart (1.0.3)
-      multipart-post (>= 1.2, < 3)
-    faraday-net_http (1.0.1)
-    faraday-net_http_persistent (1.2.0)
-    faraday-patron (1.0.0)
-    faraday-rack (1.0.0)
-    faraday-retry (1.0.3)
-    ffi (1.15.5)
-    forwardable-extended (2.6.0)
-    gemoji (3.0.1)
-    github-pages (225)
-      github-pages-health-check (= 1.17.9)
-      jekyll (= 3.9.0)
-      jekyll-avatar (= 0.7.0)
-      jekyll-coffeescript (= 1.1.1)
-      jekyll-commonmark-ghpages (= 0.2.0)
-      jekyll-default-layout (= 0.1.4)
-      jekyll-feed (= 0.15.1)
-      jekyll-gist (= 1.5.0)
-      jekyll-github-metadata (= 2.13.0)
-      jekyll-include-cache (= 0.2.1)
-      jekyll-mentions (= 1.6.0)
-      jekyll-optional-front-matter (= 0.3.2)
-      jekyll-paginate (= 1.1.0)
-      jekyll-readme-index (= 0.3.0)
-      jekyll-redirect-from (= 0.16.0)
-      jekyll-relative-links (= 0.6.1)
-      jekyll-remote-theme (= 0.4.3)
-      jekyll-sass-converter (= 1.5.2)
-      jekyll-seo-tag (= 2.8.0)
-      jekyll-sitemap (= 1.4.0)
-      jekyll-swiss (= 1.0.0)
-      jekyll-theme-architect (= 0.2.0)
-      jekyll-theme-cayman (= 0.2.0)
-      jekyll-theme-dinky (= 0.2.0)
-      jekyll-theme-hacker (= 0.2.0)
-      jekyll-theme-leap-day (= 0.2.0)
-      jekyll-theme-merlot (= 0.2.0)
-      jekyll-theme-midnight (= 0.2.0)
-      jekyll-theme-minimal (= 0.2.0)
-      jekyll-theme-modernist (= 0.2.0)
-      jekyll-theme-primer (= 0.6.0)
-      jekyll-theme-slate (= 0.2.0)
-      jekyll-theme-tactile (= 0.2.0)
-      jekyll-theme-time-machine (= 0.2.0)
-      jekyll-titles-from-headings (= 0.5.3)
-      jemoji (= 0.12.0)
-      kramdown (= 2.3.1)
-      kramdown-parser-gfm (= 1.1.0)
-      liquid (= 4.0.3)
-      mercenary (~> 0.3)
-      minima (= 2.5.1)
-      nokogiri (>= 1.12.5, < 2.0)
-      rouge (= 3.26.0)
-      terminal-table (~> 1.4)
-    github-pages-health-check (1.17.9)
-      addressable (~> 2.3)
-      dnsruby (~> 1.60)
-      octokit (~> 4.0)
-      public_suffix (>= 3.0, < 5.0)
-      typhoeus (~> 1.3)
-    html-pipeline (2.14.0)
-      activesupport (>= 2)
-      nokogiri (>= 1.4)
-    html-proofer (3.19.3)
-      addressable (~> 2.3)
-      mercenary (~> 0.3)
-      nokogiri (~> 1.12)
-      parallel (~> 1.3)
-      rainbow (~> 3.0)
-      typhoeus (~> 1.3)
-      yell (~> 2.0)
-    http_parser.rb (0.8.0)
-    i18n (0.9.5)
-      concurrent-ruby (~> 1.0)
-    jekyll (3.9.0)
-      addressable (~> 2.4)
-      colorator (~> 1.0)
-      em-websocket (~> 0.5)
-      i18n (~> 0.7)
-      jekyll-sass-converter (~> 1.0)
-      jekyll-watch (~> 2.0)
-      kramdown (>= 1.17, < 3)
-      liquid (~> 4.0)
-      mercenary (~> 0.3.3)
-      pathutil (~> 0.9)
-      rouge (>= 1.7, < 4)
-      safe_yaml (~> 1.0)
-    jekyll-avatar (0.7.0)
-      jekyll (>= 3.0, < 5.0)
-    jekyll-coffeescript (1.1.1)
-      coffee-script (~> 2.2)
-      coffee-script-source (~> 1.11.1)
-    jekyll-commonmark (1.4.0)
-      commonmarker (~> 0.22)
-    jekyll-commonmark-ghpages (0.2.0)
-      commonmarker (~> 0.23.4)
-      jekyll (~> 3.9.0)
-      jekyll-commonmark (~> 1.4.0)
-      rouge (>= 2.0, < 4.0)
-    jekyll-default-layout (0.1.4)
-      jekyll (~> 3.0)
-    jekyll-feed (0.15.1)
-      jekyll (>= 3.7, < 5.0)
-    jekyll-gist (1.5.0)
-      octokit (~> 4.2)
-    jekyll-github-metadata (2.13.0)
-      jekyll (>= 3.4, < 5.0)
-      octokit (~> 4.0, != 4.4.0)
-    jekyll-include-cache (0.2.1)
-      jekyll (>= 3.7, < 5.0)
-    jekyll-mentions (1.6.0)
-      html-pipeline (~> 2.3)
-      jekyll (>= 3.7, < 5.0)
-    jekyll-optional-front-matter (0.3.2)
-      jekyll (>= 3.0, < 5.0)
-    jekyll-paginate (1.1.0)
-    jekyll-readme-index (0.3.0)
-      jekyll (>= 3.0, < 5.0)
-    jekyll-redirect-from (0.16.0)
-      jekyll (>= 3.3, < 5.0)
-    jekyll-relative-links (0.6.1)
-      jekyll (>= 3.3, < 5.0)
-    jekyll-remote-theme (0.4.3)
-      addressable (~> 2.0)
-      jekyll (>= 3.5, < 5.0)
-      jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0)
-      rubyzip (>= 1.3.0, < 3.0)
-    jekyll-sass-converter (1.5.2)
-      sass (~> 3.4)
-    jekyll-seo-tag (2.8.0)
-      jekyll (>= 3.8, < 5.0)
-    jekyll-sitemap (1.4.0)
-      jekyll (>= 3.7, < 5.0)
-    jekyll-swiss (1.0.0)
-    jekyll-theme-architect (0.2.0)
-      jekyll (> 3.5, < 5.0)
-      jekyll-seo-tag (~> 2.0)
-    jekyll-theme-cayman (0.2.0)
-      jekyll (> 3.5, < 5.0)
-      jekyll-seo-tag (~> 2.0)
-    jekyll-theme-dinky (0.2.0)
-      jekyll (> 3.5, < 5.0)
-      jekyll-seo-tag (~> 2.0)
-    jekyll-theme-hacker (0.2.0)
-      jekyll (> 3.5, < 5.0)
-      jekyll-seo-tag (~> 2.0)
-    jekyll-theme-leap-day (0.2.0)
-      jekyll (> 3.5, < 5.0)
-      jekyll-seo-tag (~> 2.0)
-    jekyll-theme-merlot (0.2.0)
-      jekyll (> 3.5, < 5.0)
-      jekyll-seo-tag (~> 2.0)
-    jekyll-theme-midnight (0.2.0)
-      jekyll (> 3.5, < 5.0)
-      jekyll-seo-tag (~> 2.0)
-    jekyll-theme-minimal (0.2.0)
-      jekyll (> 3.5, < 5.0)
-      jekyll-seo-tag (~> 2.0)
-    jekyll-theme-modernist (0.2.0)
-      jekyll (> 3.5, < 5.0)
-      jekyll-seo-tag (~> 2.0)
-    jekyll-theme-primer (0.6.0)
-      jekyll (> 3.5, < 5.0)
-      jekyll-github-metadata (~> 2.9)
-      jekyll-seo-tag (~> 2.0)
-    jekyll-theme-slate (0.2.0)
-      jekyll (> 3.5, < 5.0)
-      jekyll-seo-tag (~> 2.0)
-    jekyll-theme-tactile (0.2.0)
-      jekyll (> 3.5, < 5.0)
-      jekyll-seo-tag (~> 2.0)
-    jekyll-theme-time-machine (0.2.0)
-      jekyll (> 3.5, < 5.0)
-      jekyll-seo-tag (~> 2.0)
-    jekyll-titles-from-headings (0.5.3)
-      jekyll (>= 3.3, < 5.0)
-    jekyll-watch (2.2.1)
-      listen (~> 3.0)
-    jemoji (0.12.0)
-      gemoji (~> 3.0)
-      html-pipeline (~> 2.2)
-      jekyll (>= 3.0, < 5.0)
-    kramdown (2.3.1)
-      rexml
-    kramdown-parser-gfm (1.1.0)
-      kramdown (~> 2.0)
-    liquid (4.0.3)
-    listen (3.7.1)
-      rb-fsevent (~> 0.10, >= 0.10.3)
-      rb-inotify (~> 0.9, >= 0.9.10)
-    mercenary (0.3.6)
-    mini_portile2 (2.8.0)
-    minima (2.5.1)
-      jekyll (>= 3.5, < 5.0)
-      jekyll-feed (~> 0.9)
-      jekyll-seo-tag (~> 2.1)
-    minitest (5.15.0)
-    multipart-post (2.1.1)
-    nokogiri (1.13.3)
-      mini_portile2 (~> 2.8.0)
-      racc (~> 1.4)
-    octokit (4.22.0)
-      faraday (>= 0.9)
-      sawyer (~> 0.8.0, >= 0.5.3)
-    parallel (1.21.0)
-    pathutil (0.16.2)
-      forwardable-extended (~> 2.6)
-    public_suffix (4.0.6)
-    racc (1.6.0)
-    rainbow (3.0.0)
-    rake (13.0.6)
-    rb-fsevent (0.11.1)
-    rb-inotify (0.10.1)
-      ffi (~> 1.0)
-    rexml (3.2.5)
-    rouge (3.26.0)
-    ruby2_keywords (0.0.5)
-    rubyzip (2.3.2)
-    safe_yaml (1.0.5)
-    sass (3.7.4)
-      sass-listen (~> 4.0.0)
-    sass-listen (4.0.0)
-      rb-fsevent (~> 0.9, >= 0.9.4)
-      rb-inotify (~> 0.9, >= 0.9.7)
-    sawyer (0.8.2)
-      addressable (>= 2.3.5)
-      faraday (> 0.8, < 2.0)
-    simpleidn (0.2.1)
-      unf (~> 0.1.4)
-    terminal-table (1.8.0)
-      unicode-display_width (~> 1.1, >= 1.1.1)
-    thread_safe (0.3.6)
-    typhoeus (1.4.0)
-      ethon (>= 0.9.0)
-    tzinfo (1.2.9)
-      thread_safe (~> 0.1)
-    unf (0.1.4)
-      unf_ext
-    unf_ext (0.0.8)
-    unicode-display_width (1.8.0)
-    yell (2.2.2)
-    zeitwerk (2.5.4)
-
-PLATFORMS
-  ruby
-
-DEPENDENCIES
-  github-pages
-  html-proofer
-  rake
-
-BUNDLED WITH
-   2.1.2

From c16750f5b9ba494bdd4d133b25631ca4bc675db1 Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Mon, 18 Apr 2022 14:52:08 +0100
Subject: [PATCH 338/749] Fix `script/bootstrap` and `script/server`.

- need to have `npm` installed
- update deprecated configuration
---
 .node-version | 1 +
 _config.yml   | 7 +++----
 2 files changed, 4 insertions(+), 4 deletions(-)
 create mode 100644 .node-version

diff --git a/.node-version b/.node-version
new file mode 100644
index 00000000000..65d83ce5ae5
--- /dev/null
+++ b/.node-version
@@ -0,0 +1 @@
+12.14.0
diff --git a/_config.yml b/_config.yml
index f4d797a2ebe..7ab1633e699 100644
--- a/_config.yml
+++ b/_config.yml
@@ -17,12 +17,12 @@ exclude:
   - test
   - vendor
 
-permalink: /:path/
+permalink: "/:slug"
 
 collections:
   articles:
     output: true
-    permalink: /:path/
+    permalink: "/:path"
 
 defaults:
   - scope:
@@ -36,14 +36,13 @@ defaults:
       layout: article
 
 plugins:
-  - jekyll-mentions
   - jekyll-redirect-from
   - jekyll-seo-tag
   - jekyll-sitemap
 
 sass:
   sass_dir: assets/css/
-  style: :compressed
+  style: compressed
   load_paths:
     - node_modules
 

From 63b528413a417feaade6af9c60595800997bc8ab Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Tue, 19 Apr 2022 10:18:54 +0100
Subject: [PATCH 339/749] Fix broken links

---
 _articles/best-practices.md               |  2 +-
 _articles/de/best-practices.md            |  2 +-
 _articles/es/best-practices.md            |  2 +-
 _articles/es/legal.md                     |  4 ++--
 _articles/fa/best-practices.md            | 14 +++++------
 _articles/fa/building-community.md        |  4 ++--
 _articles/fa/how-to-contribute.md         | 10 ++++----
 _articles/fa/leadership-and-governance.md |  6 ++---
 _articles/fa/legal.md                     |  8 +++----
 _articles/fr/best-practices.md            |  4 ++--
 _articles/hu/best-practices.md            |  2 +-
 _articles/id/best-practices.md            |  2 +-
 _articles/ja/best-practices.md            |  4 ++--
 _articles/ja/starting-a-project.md        |  2 +-
 _articles/ko/best-practices.md            |  2 +-
 _articles/ms/best-practices.md            | 12 +++++-----
 _articles/nl/best-practices.md            | 29 +++++++++++++----------
 _articles/pl/best-practices.md            |  2 +-
 _articles/pt/best-practices.md            |  2 +-
 _articles/ro/best-practices.md            |  8 +++----
 _articles/ta/best-practices.md            | 10 ++++----
 _articles/ta/how-to-contribute.md         |  2 +-
 _articles/tr/best-practices.md            |  2 +-
 _articles/zh-hans/best-practices.md       |  2 +-
 _articles/zh-hant/best-practices.md       |  2 +-
 _config.yml                               |  4 ++--
 _layouts/index.html                       |  7 +++---
 script/html-proofer                       |  2 ++
 28 files changed, 79 insertions(+), 73 deletions(-)

diff --git a/_articles/best-practices.md b/_articles/best-practices.md
index 7d0821e5b17..6983f16e7a9 100644
--- a/_articles/best-practices.md
+++ b/_articles/best-practices.md
@@ -265,7 +265,7 @@ Just like any other type of work, taking regular breaks will keep you refreshed,
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/de/best-practices.md b/_articles/de/best-practices.md
index ce2a28b7e53..436422b0fe3 100644
--- a/_articles/de/best-practices.md
+++ b/_articles/de/best-practices.md
@@ -297,7 +297,7 @@ Genau wie bei jeder anderen Art von Arbeit, werden Sie durch regelmäßige Pause
   _In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important._
 
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/es/best-practices.md b/_articles/es/best-practices.md
index 2d4125b72ee..f1728729128 100644
--- a/_articles/es/best-practices.md
+++ b/_articles/es/best-practices.md
@@ -259,7 +259,7 @@ Al igual que cualquier otro tipo de trabajo, tomar pausas regulares te mantendr&
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   Durante el mantenimiento de WP-CLI, descubr&iacute; que tengo que preocuparme por mi felicidad primero, y establecer l&iacute;mites claros en mi participaci&oacute;n. El mejor equilibrio que he encontrado es 2-5 horas por semana, como parte de mi horario de trabajo normal. Esto mantiene mi participaci&oacute;n una pasi&oacute;n, y de sentirse demasiado como el trabajo. Como priorizo ​​las issues en las que estoy trabajando, puedo hacer progresos regulares en lo que creo que es lo m&aacute;s importante.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["Mis condolencias, ahora eres el mantenedor de un proyecto de c&oacute;digo abierto popular"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["Mis condolencias, ahora eres el mantenedor de un proyecto de c&oacute;digo abierto popular"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/es/legal.md b/_articles/es/legal.md
index 6d47f7791c3..01815bf90be 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://help.github.com/articles/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://help.github.com/articles/open-source-licensing/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md
index 4444ed1f1e6..10262e5ab15 100644
--- a/_articles/fa/best-practices.md
+++ b/_articles/fa/best-practices.md
@@ -40,7 +40,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
-	دستپاچه شدم. تلاشی نکردم تا به راه‌حلی کامل دست پیدا کنم. ای کاش به جای یک راه‌حل بی‌فکر، می‌گفتم: «الان برای این وقت ندارم، اما آن را به لیست بلند مدت خودم اضافه کردم».
+ دستپاچه شدم. تلاشی نکردم تا به راه‌حلی کامل دست پیدا کنم. ای کاش به جای یک راه‌حل بی‌فکر، می‌گفتم: «الان برای این وقت ندارم، اما آن را به لیست بلند مدت خودم اضافه کردم».
   <p markdown="1" class="pquote-credit">
 — @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
   </p>
@@ -97,13 +97,13 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
-	 نکته‌ی مهم در مدیریت پروژه‌های اوپن سورس در مقیاسی بزرگ، حرکت رو به جلو است. سعی کنید از ماندگاری مسائل و مشکلات، جلوگیری کنید. اگر توسعه‌دهنده‌ی iOS باشید، می‌دانید که این مسائل چقدر طاقت‌فرسا هستند. ممکن است 2 سال بعد دوباره این مسائل به سراغ شما بیاد و به شما گفته شود که با آخرین نسخه iOS دوباره امتحان کنید.
+  نکته‌ی مهم در مدیریت پروژه‌های اوپن سورس در مقیاسی بزرگ، حرکت رو به جلو است. سعی کنید از ماندگاری مسائل و مشکلات، جلوگیری کنید. اگر توسعه‌دهنده‌ی iOS باشید، می‌دانید که این مسائل چقدر طاقت‌فرسا هستند. ممکن است 2 سال بعد دوباره این مسائل به سراغ شما بیاد و به شما گفته شود که با آخرین نسخه iOS دوباره امتحان کنید.
   <p markdown="1" class="pquote-credit">
 — @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
   </p>
 </aside>
 
-مشارکت ناخواسته را صرف اینکه آدم خوبی به نظر برسید، ادامه ندهید زیرا در ادامه‌ی راه احساس گناه خواهید کرد. با گذشت زمان، مسائل و روابط عمومی بی‌پاسخ باعث می‌شود که کارتان روی پروژه بسیار استرس‌زا و ترسناک پیش برود. 
+مشارکت ناخواسته را صرف اینکه آدم خوبی به نظر برسید، ادامه ندهید زیرا در ادامه‌ی راه احساس گناه خواهید کرد. با گذشت زمان، مسائل و روابط عمومی بی‌پاسخ باعث می‌شود که کارتان روی پروژه بسیار استرس‌زا و ترسناک پیش برود.
 
 بهتر است فوراً به مشارکت‌هایی که آن‌ها را نمی‌خواهید، پایان دهید. اگر پروژه شما از کمبود بک لاگ رنج می برد, @steveklabnik در مقاله [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) پیشنهاداتی در این خصوص ارائه کرده است.
 
@@ -113,7 +113,7 @@ related:
 
 * از توجه آن‌ها **تشکر کنید**.
 * **توضیح دهید که چرا نمی‌توانید با آن‌ها همکاری داشته باشید** و اگر می‌توانید، پیشنهادهای واضحی را برای بهبود آن‌ها برای آینده ارائه دهید؛ مهربان باشید، اما مصمم.
-* در صورت داشتن دسترسی، آن‌ها را **به مستندات مربوطه ارجاع دهید**. اگر با درخواست‌های مکرر برای مواردی که نمی‌خواهید آن‌ها را بپذیرید، مواجه شدید؛ آن موارد را برای جلوگیری از مکررات به مستندات خود اضافه کنید. 
+* در صورت داشتن دسترسی، آن‌ها را **به مستندات مربوطه ارجاع دهید**. اگر با درخواست‌های مکرر برای مواردی که نمی‌خواهید آن‌ها را بپذیرید، مواجه شدید؛ آن موارد را برای جلوگیری از مکررات به مستندات خود اضافه کنید.
 * **درخواست مشارکت را ببندید**.
 
 شما به 1 یا 2 جمله بیشتر، برای پاسخگویی نیاز نخواهید داشت. به عنوان مثال، هنگامی که [celery](https://github.com/celery/celery/)، خطایی مربوط به ویندوز را گزارش داد، «berkerpeksag» [اینگونه پاسخ](https://github.com/celery/celery/issues/3383) داد:
@@ -143,7 +143,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-	بهتر است که به افراد متقاضی در یک فایل «CONTRIBUTING.md» توضیح دهید که چه چیزهایی مورد قبول و چه چیزهایی مورد قبول شما برای شروع کردن کارشان نیست.
+ بهتر است که به افراد متقاضی در یک فایل «CONTRIBUTING.md» توضیح دهید که چه چیزهایی مورد قبول و چه چیزهایی مورد قبول شما برای شروع کردن کارشان نیست.
   <p markdown="1" class="pquote-credit">
 — @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
   </p>
@@ -169,7 +169,7 @@ related:
 
 وقتی مشاهده کردید که مشارکت‌کنندگان جدید به صورت مکرر همکاری می‌کنند، با دادن مسئولیت‌های بیشتر، آن‌ها را تصدیق کنید و به رسمیت بشناسید. مشخص کنید که چگونه دیگران می‌توانند در صورت اشتیاق به جایگاه‌های رهبری دست یابند.
 
-همانطور که @lmccart در پروژه‌ی خود متوجه شد، تشویق دیگران [به اشتراک گذاشتن مالکیت پروژه](../building-community/#share-ownership-of-your-project) می‌تواند حجم کاری شما را بسیار کاهش دهد[p5.js](https://github.com/processing/p5.js).
+همانطور که @lmccart در پروژه‌ی خود متوجه شد، تشویق دیگران [به اشتراک گذاشتن مالکیت پروژه](../building-community/#مالکیت-پروژه-تان-را-به-اشتراک-بگذارید) می‌تواند حجم کاری شما را بسیار کاهش دهد[p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
@@ -257,7 +257,7 @@ related:
 
 فرسودگی و خسته شدن از کار، مسئله‌ای واقعی و فراگیر در پروژه‌های اوپن سورس است؛ مخصوصاً در میان نگهدارندگان. به عنوان یک فرد نگهدارنده، خوشحالی و رضایت شما برای بقای هر پروژه‌ی‌ اوپن سورسی، ضروری است.
 
-پس نیازی به گفتن نیست؛ به خودتان استراحت بدهید! نیازی نیست تا سر حد خستگی و فرسودگی پیش بروید تا سپس به تعطیلات بروید. @brettcannon، توسعه‌دهنده‌ی پایتون، [تصمیم گرفت پس از 14 سال کار داوطلبانه در OSS، به تعطیلات یک ماهه برود](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/). 
+پس نیازی به گفتن نیست؛ به خودتان استراحت بدهید! نیازی نیست تا سر حد خستگی و فرسودگی پیش بروید تا سپس به تعطیلات بروید. @brettcannon، توسعه‌دهنده‌ی پایتون، [تصمیم گرفت پس از 14 سال کار داوطلبانه در OSS، به تعطیلات یک ماهه برود](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/).
 
 درست مانند هر کار دیگری، تعطیلات منظم، شما را باطراوت نگه می‌دارد و باعث خوشحالی و هیجان شما نسبت به کارتان می‌شود.
 
diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md
index 852be587b0b..a5f61057489 100644
--- a/_articles/fa/building-community.md
+++ b/_articles/fa/building-community.md
@@ -35,7 +35,7 @@ related:
 
 * **وقتی شخص جدیدی وارد پروژه شما می شود، از وی از روی علاقه تشکر کنید!** این یک تجربه منفی خواهد بود که از فردی بخواهید که به پروژه تان برنگردد.
 * **پاسخگو باشید:** اگر شما به موضوعاتشان در عرض یک ماه پاسخ نمی دهید، شانس اینکه پروژه تان را فراموش کنند بالا می رود.
-* **درباره انواع مشارکت هایی که خواهید پذیرفت ، پذیرای عقاید و افکار جدید باشید.** بسیاری از مشارکت کننده ها با یک گزارش باگ یا ترمیم جزئی آغاز می کنند. راه های زیادی برای مشارکت در یک پروژه وجود دارد. به افراد اجازه دهید تا بازگو کنند [چطور می خواهند مساعدت کنند](../how-to-contribute/#what-it-means-to-contribute).
+* **درباره انواع مشارکت هایی که خواهید پذیرفت ، پذیرای عقاید و افکار جدید باشید.** بسیاری از مشارکت کننده ها با یک گزارش باگ یا ترمیم جزئی آغاز می کنند. راه های زیادی برای مشارکت در یک پروژه وجود دارد. به افراد اجازه دهید تا بازگو کنند [چطور می خواهند مساعدت کنند](../how-to-contribute/#مشارکت-به-چه-معناست).
 * **اگر یک مشارکتی وجود دارد که شما با آن مخالف هستید،** از آنها به خاطر بیان ایده تشکر کرده و [توضیح دهید](../best-practices/#نه-گفتن-را-یاد-بگیرید) چرا آن ایده با محدوده پروژه تان تناسب ندارد، و اگر مستندات خوبی دارید رو کنید.
 
 <aside markdown="1" class="pquote">
@@ -124,7 +124,7 @@ related:
 
 بحثهای دائمی بر روی جنبه های جزئی پروژه تان، افرا دیگر از جمله خود شما را از تمرکز روی کارهای مهم دیگر بازمی دارد. افراد جدیدی که وارد پروژه تان می شوند شاید این مکالمات را ببینند و در نتیجه مشارکت نکنند.
 
-وقتی می بینید رفتار منفی‌ای در پروژه تان رخ می دهد، آن را علنی کنید. با لحن قاطع توضیح  دهید که چرا رفتارشان قابل قبول نیست. اگر این مسئله دائماً وجود داشت شاید نیاز داشته باشید که از [آنها بخواهید تا پروژه تان را ترک کنند](../code-of-conduct/#enforcing-your-code-of-conduct). [کد رفتاری‌تان](../code-of-conduct/) می تواند یک رهنمود سازنده برای این مکالمات باشد.
+وقتی می بینید رفتار منفی‌ای در پروژه تان رخ می دهد، آن را علنی کنید. با لحن قاطع توضیح  دهید که چرا رفتارشان قابل قبول نیست. اگر این مسئله دائماً وجود داشت شاید نیاز داشته باشید که از [آنها بخواهید تا پروژه تان را ترک کنند](../code-of-conduct/#عملیاتی-کردن-منشور-اخلاقی). [کد رفتاری‌تان](../code-of-conduct/) می تواند یک رهنمود سازنده برای این مکالمات باشد.
 
 ### با مشارکت کنندگان تماس بگیرید و در جریان قرار بگیرید که آنها در کجای کار هستند
 
diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 1b1268ae35c..65c7673adcd 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -89,7 +89,7 @@ related:
 ### آیا به طراحی علاقه‌مند هستید؟
 
 * با هدف افزایش قابلیت استفاده به بهبود ساختار برنامه ها کمک کنید.
-* مشابه [دروپال](https://www.drupal.org/community-initiatives/drupal-core/usability) می‌توانید با هدف بهبود رابط کاربری اقدام به کاربرپژوهی و مطالعاتی از این دست کنید. 
+* مشابه [دروپال](https://www.drupal.org/community-initiatives/drupal-core/usability) می‌توانید با هدف بهبود رابط کاربری اقدام به کاربرپژوهی و مطالعاتی از این دست کنید.
 * با جمع آوری و یک کاسه کردن الگوهای طراحی به کار گرفته شده در پروژه یک شیوه‌نامه (استایل گاید) متمرکز ایجاد کنید.
 * اقدام به خلق کارهای هنری مثل طراحی لوگو یا تی شرت مخصوص کنید. مثل کاری که [hapi.js](https://github.com/hapijs/contrib/issues/68) انجام داد.
 
@@ -124,7 +124,7 @@ related:
 
 ### آیا از کمک کردن به مردم لذت می‌برید؟
 
-* به سوالاتی که افراد درباره‌ی پروژه در سایت‌هایی مانند <span dir="rtl">Stack، Postgres، یا Reddit</span> می‌پرسند، جواب بدهید 
+* به سوالاتی که افراد درباره‌ی پروژه در سایت‌هایی مانند <span dir="rtl">Stack، Postgres، یا Reddit</span> می‌پرسند، جواب بدهید
 * سوالات افرادی که مسائل حل نشده‌ای دارند را جواب بدهید
 * در اداره کانال‌های گفتگو و تالارهای گفتمان مشارکت کنید
 
@@ -199,7 +199,7 @@ related:
 
 اگر قبلا در هیچ پروژه‌ی متن بازی مشارکت نداشته‌اید، نصیحت رئیس جمهور آمریکا، جان. اف. کندی را بشنوید که گفت:«نگویید کشورتان برای شما چه کار کرده– بپرسید شما برای کشورتان چه کار کرده‌اید.»
 
-مشارکت‌کننده‌ها در تمام سطح‌های می‌توانند در پروژه‌های متن باز مشارکت کنند. لازم نیست بیش از حد به ذهن خود فشار بیاورید که اولین مشارکت شما در یک پروژه دقیقاً به چه صورت است، یا اولین مشارکت‌تان در آن پروژه چگونه خواهد شد. 
+مشارکت‌کننده‌ها در تمام سطح‌های می‌توانند در پروژه‌های متن باز مشارکت کنند. لازم نیست بیش از حد به ذهن خود فشار بیاورید که اولین مشارکت شما در یک پروژه دقیقاً به چه صورت است، یا اولین مشارکت‌تان در آن پروژه چگونه خواهد شد.
 
 در عوض، به پروژه‌هایی فکر کنید که قبلا استفاده شده، یا می‌خواهید استفاده کنید. پروژه‌هایی که به صورت فعال در آن مشارکت می‌کنید، پروژه‌هایی هستند که برمی‌گردند.
 
@@ -500,13 +500,13 @@ related:
 
 ### 😭 جوابی دریافت نمی‌کنید.
 
-امیدواریم قبل از ارسال درخواست مشارکت، [چک لیست فعالیت‌های پروژه](#a-checklist-before-you-contribute) را برررسی کرده باشید. هرچند، حتی در پروژه‌ی فعال هم این احتمال وجود دارد که به درخواست مشارکت شما پاسخ ندهند.
+امیدواریم قبل از ارسال درخواست مشارکت، [چک لیست فعالیت‌های پروژه](#بررسی-چک-لیست-قبل-از-مشارکت-در-پروژهی-متن-باز) را برررسی کرده باشید. هرچند، حتی در پروژه‌ی فعال هم این احتمال وجود دارد که به درخواست مشارکت شما پاسخ ندهند.
 
 اگر بیش از یک هفته جوابی برایتان ارسال نشد، به طور مودبانه می‌توانید درخواست جواب دهید و از کسی بخواهید درخواست شما را بررسی کند. اگر نام کسی که می‌خواهید درخواست شما را بررسی کند می‌دانید، می توانید به اون اشاره (منشن: با گذاشتن علامت @ در ابتدای نام کاربری) کنید.
 
 به صورت خصوصی با آن شخص **تماس نگیرید**. به یاد داشته باشید ارتباط عمومی برای پروژه‌ها بسیار حیاتی است.
 
-اگر به طور مودبانه درخواست‌هایتان را فرستاده باشید اما هنوز هیچ‌کس پاسخگو نیست، احتمالاً هیچ‌کس هیچوقت پاسخ شما را نخواهد داد. می‌دانیم که حس خوبی ندارد، اما اجازه ندهید این موضوع شما را دلسرد کند چون این اتفاق ممکن است برای همه رخ دهد! 
+اگر به طور مودبانه درخواست‌هایتان را فرستاده باشید اما هنوز هیچ‌کس پاسخگو نیست، احتمالاً هیچ‌کس هیچوقت پاسخ شما را نخواهد داد. می‌دانیم که حس خوبی ندارد، اما اجازه ندهید این موضوع شما را دلسرد کند چون این اتفاق ممکن است برای همه رخ دهد!
 
 برای برطرف کردن این مشکل دلایل زیادی وجود دارد که به شما می‌گوید چرا پاسخ درخواست‌تان داده نمی‌شود؛ دلایلی مانند شرایط شخصی که ممکن است از کنترل خارج شود. شما می‌تواند پروژه‌ی دیگر یا راهی برای مشارکت پیدا کنید. قبل از اینکه اعضای یک انجمن متعهد یا پاسخگو باشند، زمان زیادی را صرف ارسال درخواست مشارکت‌تان نکنید.
 
diff --git a/_articles/fa/leadership-and-governance.md b/_articles/fa/leadership-and-governance.md
index fed5b70c73a..ee06890de91 100644
--- a/_articles/fa/leadership-and-governance.md
+++ b/_articles/fa/leadership-and-governance.md
@@ -40,7 +40,7 @@ related:
 
 **اصطلاح «کامیت کننده»،** ممکن است برای وجه تمایز دسترسی کامیت، که نوع خاصی از مسئولیت در مقابل سایر اشکال مشارکت است، استفاده شود.
 
-در حالی که می‌توانید نقش‌ها را در پروژه‌ی خود به هر روشی که دوست دارید تعریف کنید، استفاده از تعاریف گسترده‌تر را برای تقویت اشکال بیشتری از مشارکت، [مد نظر خود قرار دهید](../how-to-contribute/#what-it-means-to-contribute). شما می‌توانید از نقش‌های مدیریتی برای شناسایی رسمی افرادی که مشارکت برجسته‌ای به پروژه‌ی شما کرده‌اند، صرف نظر از مهارت‌های فنی آن‌ها استفاده کنید
+در حالی که می‌توانید نقش‌ها را در پروژه‌ی خود به هر روشی که دوست دارید تعریف کنید، استفاده از تعاریف گسترده‌تر را برای تقویت اشکال بیشتری از مشارکت، [مد نظر خود قرار دهید](../how-to-contribute/#مشارکت-به-چه-معناست). شما می‌توانید از نقش‌های مدیریتی برای شناسایی رسمی افرادی که مشارکت برجسته‌ای به پروژه‌ی شما کرده‌اند، صرف نظر از مهارت‌های فنی آن‌ها استفاده کنید
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
@@ -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/#share-ownership-of-your-project) محافظت می‌کنند.
+در آخر اینکه اگر پروژه‌ی شما در <span dir="rtl">«GitHub»</span> است، انتقال پروژه‌ی خود را از حساب شخصی خود به یک تشکل و اضافه کردن حداقل یک مدیر پشتیبان را مد نظر خود قرار دهید. [تشکل‌های «GitHub»](https://help.github.com/articles/creating-a-new-organization-account/)، مدیریت دسترسی‌ها و مراکز ذخیره‌سازی متعدد را آسان‌تر می‌کنند و پیشینه‌ی پروژه‌ی شما را از طریق [مالکیت مشترک](../building-community/#مالکیت-پروژه-تان-را-به-اشتراک-بگذارید) محافظت می‌کنند.
 
 ## چه موقع باید به کسی اجازه‌ی دسترسی کامیت بدهیم؟
 
@@ -97,10 +97,8 @@ related:
 
 * **BDFL** مخفف <span dir="rtl"> "Benevolent Dictator for Life" </span> یا «دیکتاتور خیرخواه جاویدان» است تحت این ساختار،  یک نفر (معمولاً نویسنده‌ی اولیه‌ی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را می‌زند. [Python](https://github.com/python)، نمونه‌ای موثق در این مورد است. پروژه‌های کوچک‌تر احتمالاً به طور پیش‌فرض به صورت <span dir="rtl">BDFL</span> هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژه‌هایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقه‌بندی <span dir="rtl">BDFL</span> قرار گیرند
 
-
 * **Meritocracy:** (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماع‌ها، مفهومی منفی دارد و ساختار آن [دارای پیشینه‌ی پیچیده‌ی اجتماعی و سیاسی](http://geekfeminism.wikia.com/wiki/Meritocracy).)است.) تحت ساختار «شایسته سالاری»، به مشارکت‌کنندگان فعال پروژه (کسانی که از خود «شایستگی» نشان می‌دهند) نقش تصمیم‌گیرندگی رسمی داده می‌شود. تصمیم‌‌ها، معمولاً براساس اجماع رای گرفته می‌شوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد <span dir="rtl">«Apache»</span>، به وجود آمد. تمامی پروژه‌های <span dir="rtl">«Apache»</span> بر اساس شایسته سالاری هستند. مشارکت‌ها فقط توسط افراد حقیقی صورت می‌گیرد؛ نه توسط یک شرکت.
 
-
 * **Liberal contribution:** (مشارکت آزادنه) تحت مدل مشارکت آزادانه، افرادی که بیشترین کار را انجام می‌دهند به عنوان تأثیرگذارترین افراد شناخته می‌شوند، اما این مدل براساس کاری که اکنون انجام می‌دهند است و نه مشارکت‌های که در گذشته داشته‌اند. تصمیمات بزرگ‌ پروژه بر اساس فرآیندی در اجتماع به صورت اجماعی (بحث‌ در مورد مسائل اساسی) به جای رأی‌گیری تنها گرفته می‌شود، و تلاش می‌شود تا آنجا که ممکن است دیدگاه‌های بیشتری از اجتماع را شامل شود. از جمله پروژه‌هایی که از مدل مشارکت آزادانه استفاده کردند، می‌توان [Node.js](https://foundation.nodejs.org/) و [Rust](https://www.rust-lang.org/) را نام برد.
 
 از کدام مدل بهتر است استفاده کنید؟ به خودتان بستگی دارد! هر مدل، شامل نکات منفی و مثبتی می‌شود. اگرچه ممکن است این مدل‌ها در ابتدا کاملاً متفاوت به نظر برسند؛ اما هر سه مدل، بیشتری از آنچه که به نظر می رسد اشتراکاتی دارند:
diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index a15a8fe61b4..7bb61289b9e 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -12,7 +12,7 @@ related:
 
 ## درک پیامدهای حقوقی پروژه‌های منبع آزاد
 
-اشتراک گذاشتن کارهای خلاقانه با جهانیان می‌تواند تجربه‌ای هیجان‌انگیز و ارزشمند باشد. همچنین می‌تواند به معنای درگیر شدن با یک سری موارد حقوقی باشد که در رابطه با آن‌ها چیزی نمی‌دانید. خوشبختانه، نیازی نیست از ابتدا شروع کنید. ما نیازهای حقوقی شما را برآورده کرده و پوشش داده‌ایم. (قبل از شروع، حتماً متن [سلب مسئولیت](/notices/) ما را بخوانید.) 
+اشتراک گذاشتن کارهای خلاقانه با جهانیان می‌تواند تجربه‌ای هیجان‌انگیز و ارزشمند باشد. همچنین می‌تواند به معنای درگیر شدن با یک سری موارد حقوقی باشد که در رابطه با آن‌ها چیزی نمی‌دانید. خوشبختانه، نیازی نیست از ابتدا شروع کنید. ما نیازهای حقوقی شما را برآورده کرده و پوشش داده‌ایم. (قبل از شروع، حتماً متن [سلب مسئولیت](/notices/) ما را بخوانید.)
 
 ## چرا مردم اینقدر به جنبه‌های حقوقی متن آزاد اهمیت می‌دهند؟
 
@@ -68,7 +68,7 @@ related:
 
 * **آیا می‌خواهید پروژه شما مورد توجه مشارکت‌کنندگانی قرار بگیرد که نمی‌خواهند مشارکت‌های آن‌ها در نرم‌افزارهای متن بسته مورد استفاده قرار بگیرد؟** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) یا (همچنین اگر آن‌ها تمایلی به مشارکت در خدمات متن بسته ندارند) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) به درد خواهد خورد.
 
-ممکن است **شرکت** شما در پروژه‌های متن باز، شرایط خاصی برای مجوزها داشته باشد. به عنوان مثال، ممکن است به مجوز اختیاری نیاز داشته باشد تا شرکت بتواند از پروژۀ شما در محصول متن بستۀ خود استفاده کند. یا ممکن است شرکت شما به یک مجوز کپی‌لفت قوی و یک توافق‌نامۀ همکاری اضافی نیاز داشته باشد (به زیر مراجعه کنید) تا فقط منحصرا شرکت شما بتواند از پروژه در نرم‌افزارهای متن بسته استفاده کند. یا ممکن است شرکت شما نیازها و شرایط خاصی در رابطه با استانداردها، مسئولیت‌های اجتماعی یا شفافیت داشته باشد، که هر یک از آن‌ها ممکن است به یک استراتژی خاص دیگری در ارتباط با مجوز نیاز داشته باشد. با [بخش حقوقی شرکت](#what-does-my-companys-legal-team-need-to-know) خود در رابطه با این موارد صحبت کنید.
+ممکن است **شرکت** شما در پروژه‌های متن باز، شرایط خاصی برای مجوزها داشته باشد. به عنوان مثال، ممکن است به مجوز اختیاری نیاز داشته باشد تا شرکت بتواند از پروژۀ شما در محصول متن بستۀ خود استفاده کند. یا ممکن است شرکت شما به یک مجوز کپی‌لفت قوی و یک توافق‌نامۀ همکاری اضافی نیاز داشته باشد (به زیر مراجعه کنید) تا فقط منحصرا شرکت شما بتواند از پروژه در نرم‌افزارهای متن بسته استفاده کند. یا ممکن است شرکت شما نیازها و شرایط خاصی در رابطه با استانداردها، مسئولیت‌های اجتماعی یا شفافیت داشته باشد، که هر یک از آن‌ها ممکن است به یک استراتژی خاص دیگری در ارتباط با مجوز نیاز داشته باشد. با [بخش حقوقی شرکت](#تیم-حقوقی-شرکت-من-چه-چیزهایی-را-باید-بداند) خود در رابطه با این موارد صحبت کنید.
 
 هنگام ایجاد پروژه جدید در «GitHub»، به شما امکان انتخاب نوع مجوز داده می‌شود. انتخاب یکی از مجوزهایی که در بالا ذکر شد، پروژۀ «GitHub» شما را متن باز می‌کند. اگر مایل به دیدن گزینه‌های دیگه‌ای هستید، [choosealicense.com](https://choosealicense.com) را بررسی کنید تا مجوز مناسب‌تان را پیدا کنید حتی اگر برای [نرم‌افزار](https://choosealicense.com/non-software/) نباشد.
 
@@ -128,7 +128,7 @@ related:
 
 * **حق ثبت اختراع:** آیا شرکت شما متقاضی ثبت اختراعی است که متن باز آن پروژه در [دسترس عموم](https://en.wikipedia.org/wiki/Public_disclosure) است؟ متأسفانه، ممکن است از شما خواسته شود صبر کنید (یا شاید این شرکت در دیدگاه خود تجدید نظر کند). اگر انتظار دارید که کارمندان شرکت‌های بزرگی که دارای حق ثبت اختراع هستند، به پروژۀ شما کمک کنند و در آن مشارکت داشته باشند، ممکن است تیم حقوقی از شما بخواهد از یک مجوز با امتیاز ثبت اختراع سریع (از جمله Apache 2.0 یا GPLv3) یا توافق‌نامۀ همکاری اضافی استفاده کنید ( به بالا نگاه کنید).
 
-* **نشان تجاری:** بررسی کنید تا نام پروژۀ شما با [هیچ نشان تجاری موجودی مغایرت نداشته باشد](../starting-a-project/#avoiding-name-conflicts). اگر از نشان‌های تجاری شرکت خود در پروژه استفاده می‌کنید، بررسی کنید تا هیچ مشکلی ایجاد نکند. [FOSSmarks](http://fossmarks.org/) یک راهنمای جامع برای شناخت نشان‌های تجاری در زمینه‌ی پروژه‌های متن باز و رایگان است.
+* **نشان تجاری:** بررسی کنید تا نام پروژۀ شما با [هیچ نشان تجاری موجودی مغایرت نداشته باشد](../starting-a-project/#از-نامگذاریهای-دارای-منافات-خودداری-کنید). اگر از نشان‌های تجاری شرکت خود در پروژه استفاده می‌کنید، بررسی کنید تا هیچ مشکلی ایجاد نکند. [FOSSmarks](http://fossmarks.org/) یک راهنمای جامع برای شناخت نشان‌های تجاری در زمینه‌ی پروژه‌های متن باز و رایگان است.
 
 * **حریم خصوصی:** آیا پروژۀ شما اطلاعات مربوط به کاربران را جمع‌آوری می‌کند؟ سرورهای شرکت، مکالمات را ضبط می‌کند؟ تیم حقوقی می‌تواند به شما در زمینه‌ی پیروی از سیاست‌های شرکت و آیین‌نامه‌های خارجی کمک کند.
 
@@ -159,4 +159,4 @@ related:
 
 * **امتیاز ثبت اختراع:** ممکن است شرکت شما مایل باشد به شبکۀ [Open Invention Network](https://www.openinventionnetwork.com/)، که یک مجموعۀ ثبت اختراع مشترک برای محافظت از اعضا و استفادۀ آن‌ها از پروژه‌های بزرگ متن باز یا جستجوی سایر [مجوزهای اختراع ثبت جایگزین](https://www.eff.org/document/hacking-patent-system-2016) است، بپیوندد.
 
-* **نظارت:** مخصوصاً زمانی منطقی است که پروژه‌ای را به یک [شخص حقوقی خارج از شرکت](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project) منتقل کنید.
+* **نظارت:** مخصوصاً زمانی منطقی است که پروژه‌ای را به یک [شخص حقوقی خارج از شرکت](../leadership-and-governance/#آیا-برای-حمایت-و-پشتیبانی-از-پروژهی-خود-به-نهاد-قانونی-نیاز-خواهم-داشت) منتقل کنید.
diff --git a/_articles/fr/best-practices.md b/_articles/fr/best-practices.md
index fc37ddaefa8..a2c213ed820 100644
--- a/_articles/fr/best-practices.md
+++ b/_articles/fr/best-practices.md
@@ -235,7 +235,7 @@ Il y a une [variété d'outils disponibles](https://github.com/showcases/tools-f
 * [mention-bot](https://github.com/facebook/mention-bot) mentionne les reviewers potentiels pour les pull requests
 * [Danger](https://github.com/danger/danger) permet d'automatiser les revues de code
 
-Pour les rapports de bogues et autres contributions communes, GitHub a des [Modèles d'issues et modèles de pull requests](https://github.com/blog/2111-issue-and-pull-request-templates), que vous pouvez créer pour rationaliser la communication que vous recevez. @TalAter a fait un guide [Choisissez Votre Propre Aventure] (https://www.talater.com/open-source-templates/#/) pour vous aider à rédiger vos issues et vos modèles de PR.
+Pour les rapports de bogues et autres contributions communes, GitHub a des [Modèles d'issues et modèles de pull requests](https://github.com/blog/2111-issue-and-pull-request-templates), que vous pouvez créer pour rationaliser la communication que vous recevez. @TalAter a fait un guide [Choisissez Votre Propre Aventure] (<https://www.talater.com/open-source-templates/#/>) pour vous aider à rédiger vos issues et vos modèles de PR.
 
 Pour gérer vos notifications par e-mail, vous pouvez configurer [des filtres e-mail](https://github.com/blog/2203-email-updates-about-your-own-activity) pour organiser par priorité.
 
@@ -261,7 +261,7 @@ Tout comme n'importe quel autre type de travail, prendre des pauses régulières
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   En maintenant le WP-CLI, j'ai découvert que je devais d'abord me rendre heureux et fixer des limites claires sur mon implication. Le meilleur équilibre que j'ai trouvé est de 2 à 5 heures par semaine, dans le cadre de mon horaire de travail normal. Cela maintient ma participation en tant que passion, sans le sentir trop comme du travail. Parce que je priorise les problèmes sur lesquels je travaille, je peux faire des progrès réguliers sur ce que je pense être le plus important.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/hu/best-practices.md b/_articles/hu/best-practices.md
index 4f0098594bd..05ea08b23c7 100644
--- a/_articles/hu/best-practices.md
+++ b/_articles/hu/best-practices.md
@@ -265,7 +265,7 @@ Mint minden más munka esetén a rendszeres pihenők tartása felfrissít, boldo
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   A WP-CLI fenntartása során felfedeztem, hogy előbb boldoggá kell tennem magam, és egyértelmű határokat kell meghúznom. A legjobb egyensúlyt számomra a hetente 2-5 óra biztosította, a normál munkám részeként. Ez megőrzi a szenvedélyemet és nem érzem azt, hogy túl sokat dolgoztam volna. Mivel priorizálom a munkákat amelyeken dolgozom, így normálisan haladok a véleményem szerint legfontosabb dolgokkal.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["Fogadd részvétem, mert Te most egy népszerű, nyílt forráskódú projekt karbantartója lettél"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["Fogadd részvétem, mert Te most egy népszerű, nyílt forráskódú projekt karbantartója lettél"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/id/best-practices.md b/_articles/id/best-practices.md
index 73a4b0e9ea1..4ab11ff70c2 100644
--- a/_articles/id/best-practices.md
+++ b/_articles/id/best-practices.md
@@ -259,7 +259,7 @@ Sama halnya seperti pekerjaan lainnya, mengambil liburan secara berkala akan mem
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   Dalam mengelola WP-CLI, Saya menemukan bahwa saya perlu membuat diri saya bahagia terlebih dahulu, dan menentukan batas keterlibatan saya dengan jelas. Keseimbangan terbaik yang saya temukan adalah 2-5 jam per minggu sebagai bagian dari jadwal pekerjaan normal saya. Hal ini menjaga keterlibatan saya sebagai sebuah gairah. Karena saya memprioritaskan masalah-masalah yang saya kerjakan, saya bisa membuat kemajuan berkala tentang apa yang saya anggap penting.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/ja/best-practices.md b/_articles/ja/best-practices.md
index c62c861826a..d1aa3c43487 100644
--- a/_articles/ja/best-practices.md
+++ b/_articles/ja/best-practices.md
@@ -66,7 +66,7 @@ related:
 * どのくらいの時間をプロジェクトに使えるか（ _例えば、「我々はこのプロジェクトに週5時間しか使いません。」_ ）
 
 [Jekyll](https://github.com/jekyll/jekyll/tree/master/docs) や [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) 、 [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) は、メンテナーとコントリビューターのための基本ルールを定めたプロジェクトの良い例です。
- 
+
 ### コミュニケーションを公開しよう
 
 あなたのやり取りをドキュメント化することも忘れないようにしましょう。可能な限りどこでも、プロジェクトについてのコミュニケーションを公開しましょう。機能要望やサポートリクエストについてプライベートにコンタクトしてくる人がいたら、彼らをメーリングリストやイシュートラッカーのようなパブリックなコミュニケーションチャネルに丁寧に誘導しましょう。
@@ -261,7 +261,7 @@ related:
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   WP-CLI をメンテナンスする中で、まずは自分自身を幸せにし、自分がどこまで関わるかの境界を明確にすることが必要であると気づきました。私が見つけた最も良いバランスは、私の通常の仕事時間の中で週に2 ~ 5時間を充てるというものです。このバランスで、私はプロジェクトに熱心に関わることができ、かつ仕事のようだと感じることもありません。取り掛かるイシューの優先順位付けをしているので、最も重要だと思うことで定期的に進捗を出すことができるのです。
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/ja/starting-a-project.md b/_articles/ja/starting-a-project.md
index 54821747e37..434fd67511e 100644
--- a/_articles/ja/starting-a-project.md
+++ b/_articles/ja/starting-a-project.md
@@ -176,7 +176,7 @@ CONTRIBUTING ファイルはあなたのプロジェクトにどうやって参
 
 > まずはじめに、 Active Admin へのコントリビュートを考えてくれてありがとうございます。あなたのような人々が Active Admin を偉大なツールにしているのです。
 
-あなたのプロジェクトの最初期では、 CONTRIBUTING ファイルはシンプルで大丈夫です。常にバグの報告の仕方かイシューの登録の仕方、コントリビュートをする際の技術的な要求（テストなど）を書くようにしましょう。
+あなたのプロジェクトの最初期では、 CONTRIBUTING ファイルはシンプルで大丈夫です。常にバグの報告の仕方かイシューの登録の仕方、コントリビュートをする際の技術的な要求（テストなど）を書くようにしましょう。
 
 時間が経つにつれて、 CONTRIBUTING ファイルに頻繁に聞かれる質問を加えるでしょう。こういった情報を書くことによって、同じ質問を何度も繰り返ししてくる人が減っていくでしょう。
 
diff --git a/_articles/ko/best-practices.md b/_articles/ko/best-practices.md
index 2295389f32f..26a6bb5407e 100644
--- a/_articles/ko/best-practices.md
+++ b/_articles/ko/best-practices.md
@@ -261,7 +261,7 @@ GitHub에서는 버그 제보나 기타 평범한 기여에 사용할 [이슈 
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you’re now the maintainer of a popular open source project”](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you’re now the maintainer of a popular open source project”](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md
index 345d3a9ed91..bd6758a3426 100644
--- a/_articles/ms/best-practices.md
+++ b/_articles/ms/best-practices.md
@@ -36,7 +36,7 @@ Mulakan dengan menuliskan matlamat projek anda. Tambahkan mereka ke README anda,
 
 Mempunyai visi yang jelas dan didokumentasikan membuat anda tetap fokus dan membantu anda mengelakkan "jangkauan skop" dari sumbangan orang lain.
 
-Sebagai contoh, @lord mendapati bahawa mempunyai visi projek membantunya mengetahui permintaan mana yang perlu diluangkan. Sebagai penyelenggara baru, dia menyesal tidak berpegang pada skop projeknya ketika dia mendapat permintaan fitur pertama untuk [Slate] (https://github.com/lord/slate).
+Sebagai contoh, @lord mendapati bahawa mempunyai visi projek membantunya mengetahui permintaan mana yang perlu diluangkan. Sebagai penyelenggara baru, dia menyesal tidak berpegang pada skop projeknya ketika dia mendapat permintaan fitur pertama untuk [Slate] (<https://github.com/lord/slate>).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
@@ -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://help.github.com/articles/about-required-status-checks/>) 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.
 
@@ -239,9 +239,9 @@ Terdapat [pelbagai alat tersedia](https://github.com/showcases/tools-for-open-so
 * [no-response](https://github.com/probot/no-response) menutup masalah di mana pengarang tidak menjawab permintaan untuk mendapatkan maklumat lebih lanjut
 * [dependabot-preview](https://github.com/marketplace/dependabot-preview) memeriksa fail kebergantungan anda setiap hari untuk keperluan yang ketinggalan zaman dan membuka permintaan tarikan individu untuk apa sahaja yang dijumpainya
 
-Fatau laporan pepijat dan sumbangan umum lain, GitHub mempunyai [Templat Masalah dan Templat Tarik Permintaan] (https://github.com/blog/2111-issue-and-pull-request-templates), yang boleh anda buat untuk melancarkan komunikasi anda terima. @TalAter membuat [Pilih panduan Pengembaraan Anda Sendiri] (https://www.talater.com/open-source-templates/#/) untuk membantu anda menulis isu dan templat PR anda.
+Fatau laporan pepijat dan sumbangan umum lain, GitHub mempunyai [Templat Masalah dan Templat Tarik Permintaan] (<https://github.com/blog/2111-issue-and-pull-request-templates>), yang boleh anda buat untuk melancarkan komunikasi anda terima. @TalAter membuat [Pilih panduan Pengembaraan Anda Sendiri] (<https://www.talater.com/open-source-templates/#/>) untuk membantu anda menulis isu dan templat PR anda.
 
-Untuk menguruskan pemberitahuan e-mel anda, anda boleh menyiapkan [penapis e-mel] (https://github.com/blog/2203-email-updates-about-your-own-activity) untuk disusun mengikut keutamaan.
+Untuk menguruskan pemberitahuan e-mel anda, anda boleh menyiapkan [penapis e-mel] (<https://github.com/blog/2203-email-updates-about-your-own-activity>) untuk disusun mengikut keutamaan.
 
 Sekiranya anda ingin mendapatkan sedikit lebih maju, panduan gaya dan pelapis dapat menyeragamkan sumbangan projek dan menjadikannya lebih mudah untuk disemak dan diterima.
 
@@ -257,7 +257,7 @@ Mungkin anda merasa terharu atau rasa takut yang semakin meningkat ketika anda m
 
 Burnout adalah masalah yang nyata dan meluas dalam kerja sumber terbuka, terutama di kalangan penyelenggara. Sebagai penjaga, kebahagiaan anda adalah syarat yang tidak dapat dirundingkan untuk kelangsungan projek sumber terbuka mana pun.
 
-Walaupun tidak boleh dikatakan, berehat sebentar! Anda tidak perlu menunggu sehingga anda merasa terbakar untuk bercuti. @brettcannon, pemaju teras Python, memutuskan untuk mengambil [percutian selama sebulan] (https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) setelah 14 tahun OSS sukarela bekerja.
+Walaupun tidak boleh dikatakan, berehat sebentar! Anda tidak perlu menunggu sehingga anda merasa terbakar untuk bercuti. @brettcannon, pemaju teras Python, memutuskan untuk mengambil [percutian selama sebulan] (<https://snarky.ca/why-i-took-october-off-from-oss-volunteering/>) setelah 14 tahun OSS sukarela bekerja.
 
 Sama seperti jenis pekerjaan lain, berehat sebentar akan membuat anda segar, gembira, dan gembira dengan pekerjaan anda.
 
@@ -265,7 +265,7 @@ Sama seperti jenis pekerjaan lain, berehat sebentar akan membuat anda segar, gem
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   Dalam mengekalkan WP-CLI, saya mendapati bahawa saya harus membuat diri saya bahagia terlebih dahulu, dan menetapkan batasan yang jelas mengenai penglibatan saya. Imbangan terbaik yang saya dapati adalah 2-5 jam seminggu, sebagai sebahagian daripada jadual kerja biasa saya. Ini menjadikan penglibatan saya menjadi minat, dan daripada merasa terlalu suka bekerja. Kerana saya mengutamakan masalah yang sedang saya jalankan, saya dapat membuat kemajuan secara berkala terhadap perkara yang saya rasa paling penting.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["Takziah, anda sekarang menjadi penyelenggara projek sumber terbuka yang popular"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["Takziah, anda sekarang menjadi penyelenggara projek sumber terbuka yang popular"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index 165e15bff98..cd2546fc8fd 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -41,7 +41,7 @@ Door een duidelijke, gedocumenteerde visie te hebben, blijft u gefocust en kunt
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
 Ik heb het gerommeld. Ik heb niet de moeite genomen om met een complete oplossing te komen. In plaats van een halfslachtige oplossing, zou ik willen dat ik had gezegd: "Ik heb hier momenteel geen tijd voor, maar ik zal het toevoegen aan de lange termijn lijst met leuke dingen."
-  
+
 _I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of an half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."_
 
   <p markdown="1" class="pquote-credit">
@@ -54,7 +54,7 @@ _I fumbled it. I didn't put in the effort to come up with a complete solution. I
 Regels kunnen zenuwslopend zijn om op te schrijven. Soms heb je misschien het gevoel dat je het gedrag van andere mensen controleert of al het plezier wegneemt.
 
 Eerlijk geschreven en gehandhaafd, maar goede regels geven open soruce-onderhouders meer mogelijkheden. Ze voorkomen dat u wordt meegesleurd in dingen die u niet wilt doen.
- 
+
 De meeste mensen die uw project tegenkomen, weten niets over u of uw omstandigheden. Ze gaan er misschien van uit dat je wordt betaald om eraan te werken, vooral als het iets is dat ze regelmatig gebruiken en waarvan ze afhankelijk zijn. Misschien heb je op een gegeven moment veel tijd in je project gestoken, maar ben je nu bezig met een nieuwe baan of familielid.
 
 Dit is allemaal in orde! Zorg ervoor dat andere mensen ervan op de hoogte zijn.
@@ -77,7 +77,7 @@ Vergeet ook niet uw interacties te documenteren. Houd de communicatie over uw pr
 Als u andere beheerders ontmoet, of een belangrijke beslissing neemt in privé, documenteer deze gesprekken dan in het openbaar, zelfs als u alleen maar uw aantekeningen plaatst.
 
 Op die manier heeft iedereen die lid wordt van uw community toegang tot dezelfde informatie als iemand die er al jaren is.
- 
+
 ## Nee leren zeggen
 
 Je hebt dingen opgeschreven. Idealiter zou iedereen uw documentatie lezen, maar in werkelijkheid moet u anderen eraan herinneren dat deze kennis bestaat.
@@ -101,8 +101,9 @@ Als u een bijdrage ontvangt die u niet wilt accepteren, is uw eerste reactie mis
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
   De sleutel tot het afhandelen van ondersteuning voor grootschalige open source-projecten is om problemen in beweging te houden. Probeer te voorkomen dat problemen vastlopen. Als je een iOS-ontwikkelaar bent, weet je hoe frustrerend het kan zijn om radars in te dienen. Mogelijk hoort u 2 jaar later terug en wordt u verteld het opnieuw te proberen met de nieuwste versie van iOS.
-  
+
   _The key to handle support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS._
+
   <p markdown="1" class="pquote-credit">
 — @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
   </p>
@@ -113,7 +114,7 @@ Laat geen ongewenste bijdrage openstaan omdat je een schuldgevoel hebt of aardig
 Het is beter om de bijdragen waarvan u weet dat u ze niet wilt accepteren, onmiddellijk af te sluiten. Als uw project al een grote achterstand heeft, heeft @steveklabnik suggesties voor [hoe u problemen efficiënt kunt sorteren](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
 
 Ten tweede is het negeren van bijdragen een negatief signaal naar uw gemeenschap. Bijdragen aan een project kan intimiderend zijn, vooral als het iemands eerste keer is. Zelfs als u hun bijdrage niet accepteert, erken de persoon erachter en bedank hem voor zijn interesse. Het is een groot compliment!
- 
+
 Als u een bijdrage niet wil accepteren:
 
 * **Bedank ze** voor hun bijdrage
@@ -149,8 +150,9 @@ Hoewel deze aanpak in het begin misschien onaardig aanvoelt, is proactief zijn e
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
   Leg ze idealiter en in een CONTRIBUTING.md-bestand uit hoe ze in de toekomst een betere indicatie kunnen krijgen van wat wel of niet geaccepteerd zou worden voordat ze met het werk beginnen.
-  
+
   _Ideally, explain to them and in a CONTRIBUTING.md file how they can get a better indication in the future on what would or would not be accepted before they begin the work._
+
   <p markdown="1" class="pquote-credit">
 — @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
   </p>
@@ -181,7 +183,7 @@ Anderen aanmoedigen om [aandeelhouderschap van het project](../building-communit
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
   Ik had gezegd: "Ja, iedereen kan erbij betrokken zijn, je hoeft niet veel codeerkennis te hebben [...]." Er waren mensen die zich hadden aangemeld om [naar een evenement] te komen en toen vroeg ik me echt af: is dit waar, wat ik heb gezegd? Er zullen 40 mensen komen opdagen, en het is niet alsof ik bij elk van hen kan zitten... Maar mensen kwamen samen, en het werkte gewoon. Zodra een persoon het kreeg, konden ze het hun buurman leren.
-  
+
   <p markdown="1" class="pquote-credit">
 —  @lmccart, ["Wat betekent "open source"? P5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
   </p>
@@ -204,8 +206,9 @@ Een project forceren hoeft geen slechte zaak te zijn. Projecten kunnen kopiëren
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
   Ik speel in op de use case van 80%. Als je een van de eenhoorns bent, fork mijn werk dan alsjeblieft. Ik zal niet beledigd worden! Mijn openbare projecten zijn bijna altijd bedoeld om de meest voorkomende problemen op te lossen; Ik probeer het gemakkelijk te maken om dieper te gaan door mijn werk te forceren of uit te breiden.
-  
+
   _I cater to the 80% use case. If you are one of the unicorns, please fork my work. I won't get offended! My public projects are almost always meant to solve the most common problems; I try to make it easy to go deeper by either forking my work or extending it._
+
   <p markdown="1" class="pquote-credit">
 — @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
   </p>
@@ -232,8 +235,9 @@ Als u tests toevoegt, leg dan uit hoe ze werken in uw CONTRIBUTING-bestand.
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Ik geloof dat tests nodig zijn voor alle code waar mensen aan werken. Als de code volledig en perfect correct was, zou het geen wijzigingen nodig hebben - we schrijven alleen code als er iets mis is, of dat nu "Het crasht" of "Het mist zo-en-zo-functie". En ongeacht de wijzigingen die u aanbrengt, zijn tests essentieel om eventuele regressies op te sporen die u per ongeluk zou kunnen introduceren.
-  
+
   _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)
   </p>
@@ -243,7 +247,7 @@ Als u tests toevoegt, leg dan uit hoe ze werken in uw CONTRIBUTING-bestand.
 
 Het goede nieuws over het onderhouden van een populair project is dat andere beheerders waarschijnlijk met soortgelijke problemen te maken hebben gehad en er een oplossing voor hebben gebouwd.
 
-Er zijn een hoop [verschillende tools beschikbaar](https://github.com/showcases/tools-for-open-source) om te helpen om sommige aspecten te automatiseren. 
+Er zijn een hoop [verschillende tools beschikbaar](https://github.com/showcases/tools-for-open-source) om te helpen om sommige aspecten te automatiseren.
 
 Een paar voorbeelden:
 
@@ -278,10 +282,11 @@ Net als bij elk ander soort werk, zal het nemen van regelmatige pauzes je verfri
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   Bij het onderhouden van WP-CLI heb ik ontdekt dat ik mezelf eerst gelukkig moet maken en duidelijke grenzen moet stellen aan mijn betrokkenheid. De beste balans die ik heb gevonden, is 2-5 uur per week, als onderdeel van mijn normale werkschema. Dit zorgt ervoor dat mijn betrokkenheid een passie blijft, en dat ik me niet te veel als werk voel. Omdat ik prioriteit geef aan de problemen waaraan ik werk, kan ik regelmatig vooruitgang boeken op wat ik denk dat het belangrijkst is.
-  
+
   _In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important._
+
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["Mijn condoleances, u bent nu de onderhouder (_maintainer_) van een populair open source-project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["Mijn condoleances, u bent nu de onderhouder (_maintainer_) van een populair open source-project"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/pl/best-practices.md b/_articles/pl/best-practices.md
index 51c2dba8991..84f00a234d2 100644
--- a/_articles/pl/best-practices.md
+++ b/_articles/pl/best-practices.md
@@ -271,7 +271,7 @@ Podobnie jak w przypadku każdego innego rodzaju pracy, regularne przerwy sprawi
   <i>
   In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.</i>
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/pt/best-practices.md b/_articles/pt/best-practices.md
index 076c3377cb7..f772ed06c07 100644
--- a/_articles/pt/best-practices.md
+++ b/_articles/pt/best-practices.md
@@ -261,7 +261,7 @@ Assim como qualquer outro tipo de trabalho, fazer pausas regulares manterão voc
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   Na manutenção do WP-CLI, descobri que preciso me tornar feliz primeiro e estabelecer limites claros sobre meu envolvimento. O melhor equilíbrio que encontrei é 2-5 horas por semana, como parte de meu horário normal de trabalho. Isso mantém meu envolvimento uma paixão, e longe de me sentir como se estivesse no trabalho. Devido a priorização dos problemas que estou trabalhando, posso fazer progressos regulares naquilo que penso ser mais importante.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/ro/best-practices.md b/_articles/ro/best-practices.md
index 6673e92d831..a761b6dc5b3 100644
--- a/_articles/ro/best-practices.md
+++ b/_articles/ro/best-practices.md
@@ -137,7 +137,7 @@ Nu ar trebui să ai nevoie de mai mult de 1-2 enunțuri pentru a răspunde. De e
 Dacă gândul de a spune „nu” te îngrozește, nu ești singur. După cum @jessfraz [a spus](https://blog.jessfraz.com/post/the-art-of-closing/):
 
 > Am discutat cu întreținători din câteva proiecte diferite cu sursă deschisă, Mesos, Kubernetes, Chromium, și ei toți cad de acord că una dintre cele mai grele părți de a fi un întreținător este să spui „Nu” la patch-uri pe care nu le vrei.
-> 
+>
 > I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want.
 
 Nu te simți vinovat în legătură cu a nu vrea să accepți contribuția cuiva. Prima regulă a open source, [după](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Nu este temporar, da este pentru totdeauna.”_ În timp ce a empatiza cu entuziasmul altei persoane este un lucru bun, a respinge o contribuție nu este același lucru cu a respinge persoana din spatele ei.
@@ -214,7 +214,7 @@ Dacă alți oameni sunt entuziaști în legătură cu direcția lui, dă-le perm
 @progrium [a găsit că](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documentarea viziunii pentru proiectul său, [Dokku](https://github.com/dokku/dokku), a ajutat aceste scopuri să trăiască mai departe chiar și după ce el a ieșit din proiect:
 
 > Am scris o pagină de wiki descriind ce îmi doream și de ce îmi doream acele lucruri. Din anumite motive a venit ca o surpriză că întreținătorii au început să miște proiectul în acea direcție! S-a întâmplat exact cum aș fi făcut-o eu? Nu întotdeauna. Dar totuși a adus proiectul mai aproape de ceea ce scrisesem.
-> 
+>
 > I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down.
 
 ### Lasă-i pe ceilalți să construiască soluțiile de care au nevoie
@@ -241,7 +241,7 @@ Copierea proiectului nu trebuie să fie un lucru rău. Fiind capabil să copiezi
 Același lucru se aplică unui utilizator care chiar dorește o soluție pentru care pur și simplu nu ai lățimea de bandă să o construiești. A oferi API-uri și cârlige de personalizare poate să-i ajute pe alții să-și satisfacă nevoile lor, fără să trebuiască să modifice sursa direct. @orta [a găsit că](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) încurajarea plugin-urilor pentru CocoaPods a dus la „unele dintre cele mai interesante idei":
 
 > Este aproape inevitabil ca odată ce un proiect devine mare, întreținătorii să trebuiască să devină tot mai conservatori în legătură cu felul în care ei introduc cod nou. Devii bun la a spune „nu”, dar o mulțime de oameni au nevoi legitime. Astfel, în schimb sfârșești prin a-ți transforma unealta într-o platformă.
-> 
+>
 > It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying "no", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform.
 
 ## Cheamă roboții
@@ -316,7 +316,7 @@ Exact la fel ca oricare alt fel de muncă, luarea de pauze dese te va păstra re
     </em>
   </p>
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/ta/best-practices.md b/_articles/ta/best-practices.md
index d658f1f89c9..c41c8e01805 100644
--- a/_articles/ta/best-practices.md
+++ b/_articles/ta/best-practices.md
@@ -103,7 +103,7 @@ related:
   </p>
 </aside>
 
-நீங்கள் தேவையற்ற பங்களிப்பை மூடுவதற்காக வருத்தம் கொள்ள தேவையில்லை. காலப்போக்கில், உங்கள் திட்டத்தில் பதிலளிக்கப்படாத இடுவுகள் மற்றும் இழு கோரிக்கைகள் மனஅழுத்தத்தையும், அச்சுறுத்தலையும் அதிகரிக்கிறது.
+நீங்கள் தேவையற்ற பங்களிப்பை மூடுவதற்காக வருத்தம் கொள்ள தேவையில்லை. காலப்போக்கில், உங்கள் திட்டத்தில் பதிலளிக்கப்படாத இடுவுகள் மற்றும் இழு கோரிக்கைகள் மனஅழுத்தத்தையும், அச்சுறுத்தலையும் அதிகரிக்கிறது.
 
 நீங்கள் ஏற்க விரும்பாத பங்களிப்புகளை உடனடியாக மூடிவிடுதல் நல்லது. உங்கள் திட்டத்தில் ஏற்கனவே வேலைகள் நிறைய இருந்தால்,  [திறம்பட சிக்கல்களை எவ்வாறு தீர்க்க முடியும்](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) @steveklabnik சொல்லும் சில பரிந்துரைகள்.
 
@@ -171,7 +171,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
-  "ஆமாம், யாருக்கும் ஈடுபாடு இருக்க முடியும், நீங்கள் நிறைய குறியீட்டு நிபுணத்துவங்களைக் கொண்டிருக்க வேண்டியதில்லை [...]." என்று சொன்னேன். ஓரு [நிகழ்விற்கு] வருவதற்கு பலர் ஓப்புக் கொண்டனர். இது உண்மையா என்று? அப்பொழுது நான் ஆச்சரியம் கொண்டேன். அங்கு 40 பேர் இருப்பார்கள். அவர்கள் ஒவ்வொருவருடனும் நான் அமர வேண்டுமென்றில்லை... ஆனால் அனைவரும் ஓன்று கூடுவதனால், வேலை சுலபமாகிறது. ஒரு நபர் கற்றவுடன், அதை தன் அருகில் உள்ளவருக்கு கற்பிப்பார்.
+  "ஆமாம், யாருக்கும் ஈடுபாடு இருக்க முடியும், நீங்கள் நிறைய குறியீட்டு நிபுணத்துவங்களைக் கொண்டிருக்க வேண்டியதில்லை [...]." என்று சொன்னேன். ஓரு [நிகழ்விற்கு] வருவதற்கு பலர் ஓப்புக் கொண்டனர். இது உண்மையா என்று? அப்பொழுது நான் ஆச்சரியம் கொண்டேன். அங்கு 40 பேர் இருப்பார்கள். அவர்கள் ஒவ்வொருவருடனும் நான் அமர வேண்டுமென்றில்லை... ஆனால் அனைவரும் ஓன்று கூடுவதனால், வேலை சுலபமாகிறது. ஒரு நபர் கற்றவுடன், அதை தன் அருகில் உள்ளவருக்கு கற்பிப்பார்.
   <p markdown="1" class="pquote-credit">
 — @lmccart, [""திறந்த மூலம்" என்பதன் பொருள் என்ன? p5.js பதிப்பு"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
   </p>
@@ -179,7 +179,7 @@ related:
 
 நீங்கள் உங்கள் திட்டத்திலிருந்து தற்காலிகமாகவோ அல்லது நிரந்தரமாக விலக வேண்டியிருந்தால், வேறு யாரிடமேனும் உங்கள் திட்டத்தை எடுத்துக்கொள்ளுமாறு கேட்டுக்கொள்வதில் எந்த வருத்தமும் கொள்ள தேவையில்லை.
 
-மற்றவர்கள் அதன் திசையைப் பற்றி ஆர்வத்துடன் இருந்தால், அவர்களுக்கு அணுகல் வழங்க அல்லது அதிகாரப்பூர்வமாக மற்றவர்களிடம் கட்டுப்பாட்டை ஒப்படைக்கவும். யாராவது உங்கள் திட்டத்தின் கிளையை, வேறு எங்காவது பராமரித்து வந்தால், உங்கள் அசல் திட்டத்திடமிருந்து பிணைப்பை இணைக்கவும். பல மக்கள் உங்கள் திட்டம் வாழ வேண்டும் என எண்ணுவது பெரிய விஷயம்!
+மற்றவர்கள் அதன் திசையைப் பற்றி ஆர்வத்துடன் இருந்தால், அவர்களுக்கு அணுகல் வழங்க அல்லது அதிகாரப்பூர்வமாக மற்றவர்களிடம் கட்டுப்பாட்டை ஒப்படைக்கவும். யாராவது உங்கள் திட்டத்தின் கிளையை, வேறு எங்காவது பராமரித்து வந்தால், உங்கள் அசல் திட்டத்திடமிருந்து பிணைப்பை இணைக்கவும். பல மக்கள் உங்கள் திட்டம் வாழ வேண்டும் என எண்ணுவது பெரிய விஷயம்!
 
 @progrium திட்டத்தின் நோக்கை ஆவணப்படுத்திருந்ததால், அவர் திட்டத்தில் இருந்து விலகி பின்னர் கூட [Dokku](https://github.com/dokku/dokku) அந்த இலக்குகளை வாழ உதவியது என [கண்டறிந்தார்](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/)
 
@@ -235,7 +235,7 @@ related:
 * [குறிப்பிடு-செயலி](https://github.com/facebook/mention-bot) இழு கோரிக்கைகளுக்கு சாத்தியமான விமர்சகர்களை குறிப்பிடுகின்றது
 * [இடர்](https://github.com/danger/danger) குறியீடு மதிப்பாய்வை தானியங்குபடுத்துவதற்கு உதவுகிறது
 
-பிழை அறிக்கைகள் மற்றும் பிற பொதுவான பங்களிப்புகளுக்கு, கித்ஹப்-இல் உள்ள [சிக்கல் வார்ப்புருக்கள் மற்றும் இழு கோரிக்கை சிக்கல் வார்ப்புருக்கள்](https://github.com/blog/2111-issue-and-pull-request-templates), நீங்கள் பெறும் தகவலை தடையின்றிப் பெருவதற்கு உதவும். @TalAter உங்கள் சிக்கல் மற்றும் PR வார்ப்புருக்கள் எழுதுவதற்கு உதவுவதற்கு [உங்கள் சொந்த சாதனை வழிகாட்டியைத் தேர்வுசெய்யவும்](https://www.talater.com/open-source-templates/#/) உருவாக்கினார்.
+பிழை அறிக்கைகள் மற்றும் பிற பொதுவான பங்களிப்புகளுக்கு, கித்ஹப்-இல் உள்ள [சிக்கல் வார்ப்புருக்கள் மற்றும் இழு கோரிக்கை சிக்கல் வார்ப்புருக்கள்](https://github.com/blog/2111-issue-and-pull-request-templates), நீங்கள் பெறும் தகவலை தடையின்றிப் பெருவதற்கு உதவும். @TalAter உங்கள் சிக்கல் மற்றும் PR வார்ப்புருக்கள் எழுதுவதற்கு உதவுவதற்கு [உங்கள் சொந்த சாதனை வழிகாட்டியைத் தேர்வுசெய்யவும்](https://www.talater.com/open-source-templates/#/) உருவாக்கினார்.
 
 உங்கள் மின்னஞ்சல் அறிவிப்புகளை நிர்வகிக்க, [மின்னஞ்சல் வடிகட்டிகள்](https://github.com/blog/2203-email-updates-about-your-own-activity) மூலம் முன்னுரிமை கொடுத்து ஒழுங்குபடுத்தலாம்.
 
@@ -261,7 +261,7 @@ related:
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   WP-CLI ஐ பராமரிப்பதில், முதலில் நான் மகிழ்ச்சியடைந்தேன், என் ஈடுபாட்டின் மீது தெளிவான எல்லைகளை அமைத்தேன். என் சாதாரண பணி அட்டவணையின் ஒரு பகுதியாக, வாரத்திற்கு 2-5 மணிநேரத்தை நான் கண்டிருக்கிறேன். இது என் ஈடுபாடு ஒரு உணர்வு, மற்றும் மிகவும் வேலை உணர்கிறேன் இருந்து வைத்திருக்கிறது. நான் பணிபுரியும் பிரச்சினைகளுக்கு முன்னுரிமை அளிப்பதால், மிக முக்கியமானது என்னவென்று நான் நினைக்கிறேன். நான் பணிபுரியும் பிரச்சினைகளுக்கு முன்னுரிமை அளிப்பதால், நான் மிகவும் முக்கியம் என நினைப்பதில் நான் தொடர்ந்து முன்னேற்றம் செய்ய முடிகிறது.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["என் இரங்கல்கள், நீங்கள் இப்போது ஒரு பிரபலமான திறந்த மூல திட்டத்தின் பராமரிப்பாளர்"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["என் இரங்கல்கள், நீங்கள் இப்போது ஒரு பிரபலமான திறந்த மூல திட்டத்தின் பராமரிப்பாளர்"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/ta/how-to-contribute.md b/_articles/ta/how-to-contribute.md
index 774154464c5..79b4691e714 100644
--- a/_articles/ta/how-to-contribute.md
+++ b/_articles/ta/how-to-contribute.md
@@ -99,7 +99,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
-  உண்மையாக, \[ஆவணங்கள்\] மிகவும் முக்கியம். இதுவரை ஆவணங்கள் Babel-ன் ஒரு முக்கிய அம்சமாக இருந்தது. திட்டத்தின் சில பகுதிகள் பங்களிப்பை உபயோகப்படுத்திக் கொள்வதோடு, பத்தியில் இங்கும் அங்கும் மாற்றம் செய்வதுகூட பாராட்டத்தக்கதாகும்.
+  உண்மையாக, \[ஆவணங்கள்\] மிகவும் முக்கியம். இதுவரை ஆவணங்கள் Babel-ன் ஒரு முக்கிய அம்சமாக இருந்தது. திட்டத்தின் சில பகுதிகள் பங்களிப்பை உபயோகப்படுத்திக் கொள்வதோடு, பத்தியில் இங்கும் அங்கும் மாற்றம் செய்வதுகூட பாராட்டத்தக்கதாகும்.
   <p markdown="1" class="pquote-credit">
 — @kittens, ["பங்களிப்பாளர்களுக்கு அழைப்பு"](https://github.com/babel/babel/issues/1347)
   </p>
diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md
index 8df08cf5adc..602299eeb96 100644
--- a/_articles/tr/best-practices.md
+++ b/_articles/tr/best-practices.md
@@ -265,7 +265,7 @@ Tıpkı diğer tüm işlerde olduğu gibi, düzenli molalar vermek de işinizi y
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   WP-CLI’yı geliştirirken, önce kendimi mutlu etmem gerektiğini ve katılımım konusunda net sınırlar koymam gerektiğini keşfettim. Bulduğum en iyi denge, normal çalışma programımın bir parçası olarak haftada 2-5 saat. Bu benim katılımımı bir tutku olarak kalmasını sağlıyor ve iş gibi hissetmekten koruyor. Üzerinde çalıştığım konulara öncelik verdiğim için, en önemli olduğunu düşündüğüm konuda düzenli ilerleme sağlayabiliyorum.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["Başınız sağolsun, şimdi popüler bir açık kaynak projesinin sorumlusunuz"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["Başınız sağolsun, şimdi popüler bir açık kaynak projesinin sorumlusunuz"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/zh-hans/best-practices.md b/_articles/zh-hans/best-practices.md
index c19caffa01a..4549cdadebc 100644
--- a/_articles/zh-hans/best-practices.md
+++ b/_articles/zh-hans/best-practices.md
@@ -255,7 +255,7 @@ fork 一个项目不什么坏事情。能复制并且修改别人的代码是开
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   我是 WP-CLI 的维护者，我发现我需要首先让自己开心，在开源项目和其他事情之间设定清楚的界限。我发现最好的平衡点就是每周在日常的工作安排中花 2-5 小时在这上面。这会让我从感觉太累到保持持续的激情。因为我给我需要解决的 issue 标上了优先级，从而我能够在我认为重要的事情上有所进展。
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["我的悼文，你现在是一个非常流行的项目的维护者"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["我的悼文，你现在是一个非常流行的项目的维护者"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/zh-hant/best-practices.md b/_articles/zh-hant/best-practices.md
index 1a3163e7092..91d348b7545 100644
--- a/_articles/zh-hant/best-practices.md
+++ b/_articles/zh-hant/best-practices.md
@@ -255,7 +255,7 @@ fork一個專案不什麼壞事情。能複製並且修改別人的程式是開
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   我是WP-CLI的維護者，我發現我需要首先讓自己開心，在開源專案和其他事情之間設定清楚的界限。我發現最好的平衡點就是每週在日常的工作安排中花2-5小時在這上面。這會讓我從感覺太累到保持持續的激情。因爲我給我需要解決的issue表上了優先級，從而我能夠在我認爲重要的事情上有所進展。
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["我的悼文，你現在是一個非常流行的專案的維護者"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["我的悼文，你現在是一個非常流行的專案的維護者"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_config.yml b/_config.yml
index 7ab1633e699..dfc73a78330 100644
--- a/_config.yml
+++ b/_config.yml
@@ -17,12 +17,12 @@ exclude:
   - test
   - vendor
 
-permalink: "/:slug"
+permalink: "/:path/"
 
 collections:
   articles:
     output: true
-    permalink: "/:path"
+    permalink: "/:path/"
 
 defaults:
   - scope:
diff --git a/_layouts/index.html b/_layouts/index.html
index 2f74e50281f..f3df799eb29 100644
--- a/_layouts/index.html
+++ b/_layouts/index.html
@@ -3,9 +3,9 @@
 ---
 {% assign t = site.data.locales[page.lang][page.lang] %}
 {% if page.title %}
-  {% assign header = page.title %}
+{% assign header = page.title %}
 {% else %}
-  {% assign header = site.title %}
+{% assign header = site.title %}
 {% endif %}
 {% include nav.html %}
 
@@ -33,7 +33,8 @@ <h1 class="h00-mktg">{{ header }}</h1>
         <a href="{{ article.url | relative_url }}" class="guide-cover {{ article.class }} Box height-full d-block">
 
           <div class="lh-none guide-cover-img text-center pt-4">
-            <img src="{{ site.baseurl }}/assets/images/illos/{{ article.class }}.svg" class="" alt="{{ article.title }} illustration">
+            <img src="{{ site.baseurl }}/assets/images/illos/{{ article.class }}.svg" class=""
+              alt="{{ article.title }} illustration">
           </div>
 
           <div class="flex-self-end p-4 text-center p-lg-5">
diff --git a/script/html-proofer b/script/html-proofer
index a1344df4c5e..96eb51b48e0 100755
--- a/script/html-proofer
+++ b/script/html-proofer
@@ -10,6 +10,8 @@ url_ignores = [
   "https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/",
   %r{^https?://twitter\.com/},
   %r{^https?://(www\.)?kickstarter\.com/},
+  %r{^https://guides\.github\.com/},
+  %r{^https://help\.github\.com/},
 ]
 
 HTMLProofer::Runner.new(

From 9b669b6ff8fbfedd91a57e2e0832d4bc4d407904 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 19 Apr 2022 09:25:30 +0000
Subject: [PATCH 340/749] Bump actions/stale from 4 to 5

Bumps [actions/stale](https://github.com/actions/stale) from 4 to 5.
- [Release notes](https://github.com/actions/stale/releases)
- [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/stale/compare/v4...v5)

---
updated-dependencies:
- dependency-name: actions/stale
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/stale.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
index b3a482739c9..08d441de157 100644
--- a/.github/workflows/stale.yml
+++ b/.github/workflows/stale.yml
@@ -8,7 +8,7 @@ jobs:
   stale:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/stale@v4
+    - uses: actions/stale@v5
       with:
         stale-pr-message: >
           This pull request has been automatically marked as stale because it has not

From 7b64d208c9fcfb6c54fe80a82d1e848bf75fa063 Mon Sep 17 00:00:00 2001
From: lunar0926 <lunar0926@gmail.com>
Date: Tue, 26 Apr 2022 01:40:10 +0900
Subject: [PATCH 341/749] update table of contents

---
 _articles/ko/building-community.md |  8 ++++----
 _articles/ko/finding-users.md      | 14 +++++++-------
 _articles/ko/how-to-contribute.md  | 14 +++++++-------
 _articles/ko/starting-a-project.md | 12 ++++++------
 4 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/_articles/ko/building-community.md b/_articles/ko/building-community.md
index 669254a27e9..c7bd45276d9 100644
--- a/_articles/ko/building-community.md
+++ b/_articles/ko/building-community.md
@@ -10,7 +10,7 @@ related:
   - coc
 ---
 
-## Setting your project up for success
+## 프로젝트의 성공을 위해 준비하기
 
 여러분의 프로젝트가 공개되었습니다. 홍보를 하니 찾아오는 사람들도 생겼습니다. 멋지군요! 그들을 곁에 머물게 하려면 이제 어떻게 해야 할까요?
 
@@ -102,7 +102,7 @@ related:
 
 공개적인 의사소통은 중요하지만 예외도 있습니다. 보안 관련 이슈나 민감한 행동 강령 위반 사항이 바로 그것입니다. 이러한 문제는 비공개적으로 보고될 수 있어야 합니다. 개인 이메일을 사용하기 꺼려진다면 프로젝트를 위한 이메일 주소를 준비하세요.
 
-## Growing your community
+## 커뮤니티 성장시키기
 
 커뮤니티는 아주 강력한 힘을 지니고 있습니다. 그 힘은 어떻게 다루느냐에 따라 축복이 될 수도, 저주가 될 수도 있습니다. 성장하는 커뮤니티를 파괴의 힘이 아닌 창조의 힘으로 이끄는 방법을 알아봅시다.
 
@@ -181,7 +181,7 @@ CONTRIBUTING 파일에 새 기여자들이 시작할 방법을 자세히 설명
   </p>
 </aside>
 
-## Resolving conflicts
+## 갈등 해결하기
 
 프로젝트 초기에는 결정을 내리기 쉽습니다. 하고 싶은 일이 있다면, 얼마든 그렇게 하세요.
 
@@ -271,6 +271,6 @@ README 파일은 [단순한 안내서 이상](../starting-a-project/#readme-파
 
 해결사는 마지막 방책으로서 쓰여야 합니다. 의견이 엇갈리는 이슈는 여러분의 커뮤니티가 배우고 성장할 기회입니다. 이러한 기회를 놓치지 말고 협력적인 과정을 통해 가능한 해결책을 향해 나아가세요.
 
-## Community is the ❤️ of open source
+## 커뮤니티는 오픈소스의 ❤️으로
 
 건강하고 번성하는 커뮤니티는 매주 오픈소스에 채워지는 수천 시간의 연료가 됩니다. 많은 기여자들이 오픈소스에 기여하(거나 하지 않)는 이유로서 다른 기여자들을 꼽습니다. 커뮤니티의 힘을 건설적으로 다루는 법을 배움으로써 여러분은 누군가가 잊을 수 없는 오픈소스 경험을 가질 수 있도록 도울 것입니다.
diff --git a/_articles/ko/finding-users.md b/_articles/ko/finding-users.md
index 2b62c4cf857..ce9aa922a69 100644
--- a/_articles/ko/finding-users.md
+++ b/_articles/ko/finding-users.md
@@ -10,11 +10,11 @@ related:
   - building
 ---
 
-## Spreading the word
+## 소문내기
 
 시작할 때부터 오픈소스 프로젝트를 홍보해야 한다는 규칙은 없습니다. 오픈소스에 기여하는 데는 인기와 무관한 많은 이유가 있습니다. 사람들이 여러분의 오픈소스 프로젝트를 찾고 이용해주기를 기대하지만 말고 여러분의 노력에 대한 이야기를 퍼뜨려야 합니다!
 
-## Figure out your message
+## 메시지 생각해 내기
 
 프로젝트를 홍보하기 위한 실질적인 작업을 시작하기 전에 프로젝트가 무엇을 하고 왜 중요한지 설명할 수 있어야 합니다.
 
@@ -28,7 +28,7 @@ related:
 
 메시지 전달에 대해 더 알아보고 싶다면 사용자 페르소나 개발을 위한 Mozilla의 ["Personas and Pathways"](http://mozillascience.github.io/working-open-workshop/personas_pathways/)를 참조하세요.
 
-## Help people find and follow your project
+## 사람들이 당신의 프로젝트를 찾고 팔로우하도록 돕기
 
 <aside markdown="1" class="pquote">
   You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
@@ -61,7 +61,7 @@ Django의 공동 크리에이터인 [@adrianholovaty](https://news.ycombinator.c
 
 이제 여러분은 프로젝트에 대한 메시지와 사람들이 프로젝트를 쉽게 찾아올 수 있는 길을 마련했습니다. 세상으로 나가서 사람들에게 널리 알리세요!
 
-## Go where your project's audience is (online)
+## 프로젝트의 청중이 있는 곳으로 가기 (온라인)
 
 온라인에서의 활동은 이야기를 빠르게 퍼트리는 훌륭한 방법입니다. 온라인 채널을 이용하면 아주 넓은 층의 잠재 사용자 혹은 기여자와 닿을 수 있습니다.
 
@@ -85,7 +85,7 @@ Django의 공동 크리에이터인 [@adrianholovaty](https://news.ycombinator.c
 
 여러분의 노력에도 불구하고 아무도 관심을 가지지 않는다면, 너무 실망하지 마세요! 대부분의 프로젝트는 초기 단계에 수 개월부터 수 년의 시간을 필요로 합니다. 처음 시도에 반응을 얻지 못한다면, 다른 전략을 시도하거나 다른 사람의 프로젝트에 가치를 제공할 방법을 찾아보세요. 프로젝트를 홍보하고 본궤도에 올리는 데에는 충분한 시간과 노력이 필요합니다.
 
-## Go where your project's audience is (offline)
+## 프로젝트의 청중이 있는 곳으로 가기 (오프라인)
 
 ![Public speaking](/assets/images/finding-users/public_speaking.jpg)
 
@@ -125,7 +125,7 @@ Django의 공동 크리에이터인 [@adrianholovaty](https://news.ycombinator.c
   </p>
 </aside>
 
-## Build a reputation
+## 평판 쌓기
 
 지금까지 다루어진 전략에 더해서, 여러분의 프로젝트에 기여할 사람들을 초대하는 가장 좋은 방법은 바로 그들의 프로젝트에 기여하는 것입니다.
 
@@ -151,6 +151,6 @@ Django의 공동 크리에이터인 [@adrianholovaty](https://news.ycombinator.c
   </p>
 </aside>
 
-## Keep at it!
+## 계속해 나가세요!
 
 사람들이 여러분의 프로젝트에 관심을 갖는 데 오랜 시간이 걸릴 수도 있지만 괜찮습니다! 유명한 프로젝트 중 몇몇은 지금의 경지에 다다르기 위해 몇 년이 들었습니다. 프로젝트가 갑자기 유명해지기를 바라는 대신 관계를 쌓는 데 집중하세요. 인내심을 가지고, 여러분의 노력에 고마워하는 사람들과 작업을 계속 공유하세요.
diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md
index 99900325f70..b593d749f7b 100644
--- a/_articles/ko/how-to-contribute.md
+++ b/_articles/ko/how-to-contribute.md
@@ -10,7 +10,7 @@ related:
   - building
 ---
 
-## Why contribute to open source?
+## 왜 오픈소스에 기여할까요?
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
@@ -48,7 +48,7 @@ related:
 
 오픈소스에 참여하는 것을 즐기는 평생 기여자가 될 필요는 없습니다. 웹 사이트에서 오타를 발견하고 누군가가 고쳐주길 바란 적 있나요? 오픈소스 프로젝트에서 여러분은 그렇게 할 수 있습니다. 오픈소스는 사람들이 삶에 대해 어떻게 대처하고 그들이 세상을 경험하는지를 느끼도록 도와줍니다.
 
-## What it means to contribute
+## 기여한다는 것의 의미
 
 새로운 오픈소스 기여자라면, 기여하는 과정이 겁날 수도 있습니다. 알맞은 프로젝트를 어떻게 찾아야 할까요? 코딩을 할 줄 모른다면요? 뭔가 잘못되면 어떡하죠?
 
@@ -142,7 +142,7 @@ related:
 
 비록 당신이 소프트웨어 개발자일지라도, 문서 프로젝트 작업은 오픈소스에서 시작하는 데 도움이 될 수 있습니다. 코드를 포함하지 않는 프로젝트에서 작업하는 것은 보통 어렵지 않으며, 협력하는 과정에서 여러분의 자신감과 경험을 쌓을 수 있을 것입니다.
 
-## Orienting yourself to a new project
+## 새 프로젝트로 향하기
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
@@ -189,7 +189,7 @@ related:
 * **토론 포럼 혹은 메일링 리스트:** 일부 프로젝트는 회화성 주제(버그 제보나 기능 요구 대신 _"...하려면 어떻게 하나요?"_ 또는 _"...에 대해 어떻게 생각하세요?"_ 같은 주제)에 대해 이러한 채널을 사용할 수 있습니다. 나머지 프로젝트는 모든 대화에 이슈 트래커를 사용합니다.
 * **채팅 채널:** 일부 프로젝트에서는 일상 대화, 협업 및 빠른 의사소통을 위해 Slack이나 IRC 같은 채팅 채널을 사용합니다.
 
-## Finding a project to contribute to
+## 기여할 프로젝트 찾기
 
 오픈소스 프로젝트가 어떻게 작동하는지 알았으니, 이제 기여할 프로젝트를 찾아야 합니다!
 
@@ -373,7 +373,7 @@ README를 스캔하여 깨진 링크나 오타를 찾을 수 있습니다. 또
   </p>
 </aside>
 
-## How to submit a contribution
+## 기여하는 방법
 
 기여하고 싶은 프로젝트를 찾았나요? 드디어! 기여하는 올바른 방법은 다음과 같습니다.
 
@@ -485,7 +485,7 @@ PR이 반드시 완료된 작업을 포함할 필요는 없습니다. 보통 다
 
 만약 첫 PR을 열려고 한다면 @kentcdodds가 무료 영상 튜토리얼로 공개한 [Make a Pull Request](http://makeapullrequest.com/)를 참조하세요. @Roshanjossey의 [First Contributions](https://github.com/Roshanjossey/first-contributions) 저장소에서 연습해볼 수도 있습니다.
 
-## What happens after you submit a contribution
+## 기여한 후에 일어나는 일
 
 해내셨군요! 오픈소스 기여자가 되신 것을 축하드립니다. 앞으로도 많이 기여하실 수 있기를 바랍니다.
 
@@ -517,6 +517,6 @@ PR이 반드시 완료된 작업을 포함할 필요는 없습니다. 보통 다
 
 만세! 오픈소스에 기여하는 데 성공했습니다!
 
-## You did it!
+## 해냈어요!
 
 처음으로 오픈소스에 기여한 사람이든, 기여할 새로운 방법을 찾고 있든, 이 문서가 그것을 행동에 옮길 수 있는 계기가 되었길 바랍니다. 비록 기여가 받아들여지지 않더라도, 관리자가 당신을 도우려 할 때 감사의 말을 하는 것을 잊지 마세요. 오픈소스의 이슈, PR, 댓글 하나하나는 여러분에 의해 만들어집니다. 
diff --git a/_articles/ko/starting-a-project.md b/_articles/ko/starting-a-project.md
index ba3087e873e..bad3e06be84 100644
--- a/_articles/ko/starting-a-project.md
+++ b/_articles/ko/starting-a-project.md
@@ -10,7 +10,7 @@ related:
   - building
 ---
 
-## The "what" and "why" of open source
+## 오픈소스는 "무엇"이고 "왜" 하는가?
 
 오픈소스를 시작하려고 하시나요? 축하합니다! 세상이 여러분의 기여를 높이 살 것입니다. 오픈소스란 무엇이며, 왜 사람들이 오픈소스를 사용하는지 알아봅시다.
 
@@ -57,7 +57,7 @@ related:
 
 결론적으로 대부분의 오픈소스 프로젝트는 무료이지만, "무료"는 오픈소스 정의의 일부가 아닙니다. 오픈소스의 공식적인 정의를 계속 준수하면서도 이중 라이선스 또는 제한된 기능을 통해 간접적으로 오픈소스 프로젝트 사용에 비용을 청구할 수 있는 방법이 있습니다.
 
-## Should I launch my own open source project?
+## 내 오픈소스 프로젝트를 시작해야 할까요?
 
 짧게 답하자면 그렇습니다. 결과가 어떻든 여러분 자신의 프로젝트를 시작하는 것이 오픈소스가 돌아가는 방식을 배우기 위한 훌륭한 방법이 되기 때문입니다.
 
@@ -105,7 +105,7 @@ related:
 
 기여를 시작하는 법을 잘 모르겠다면 [오픈소스에 기여하는 방법 가이드](../how-to-contribute/)를 확인해 보세요.
 
-## Launching your own open source project
+## 내 오픈소스 프로젝트 시작하기
 
 프로젝트를 오픈소스화할 정해진 타이밍은 없습니다. 아이디어, 진행중인 작업 혹은 수년이 지난 비공개 소스도 오픈소스화할 수 있습니다.
 
@@ -213,7 +213,7 @@ README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 읽게 할
 
 행동 강령을 저장소의 CODE_OF_CONDUCT 파일에 직접 붙여넣으세요. 파일을 쉽게 찾을 수 있게 프로젝트 최상위 폴더에 저장하고 README에 링크를 첨부하세요.
 
-## Naming and branding your project
+## 프로젝트의 네이밍과 브랜딩
 
 브랜딩은 화려한 로고나 매력적인 프로젝트 이름 그 이상입니다. 브랜딩은 여러분이 프로젝트를 어떻게 생각하는지, 누구에게 여러분의 메시지를 전달하고자 하는지에 대한 것입니다.
 
@@ -260,7 +260,7 @@ README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 읽게 할
 
 프로젝트를 시작할 때 스타일 가이드를 작성할 필요는 없으며, 여러분은 오히려 프로젝트에 여러 코딩 스타일이 혼재하는 것을 좋아할 수도 있습니다. 하지만 글과 코딩 스타일이 서로 다른 유형의 사람들을 끌어모으거나 단념시킬 수도 있다는 점을 예상해야 합니다. 프로젝트의 가장 초기 단계는 여러분이 원하는 선례를 만들 기회입니다.
 
-## Your pre-launch checklist
+## 오픈소스 준비 체크리스트
 
 프로젝트를 오픈소스화할 준비가 되셨습니까? 다음은 도움이 되는 체크리스트입니다. 모든 칸에 체크하셨나요? 이제 출발할 준비가 되었습니다! ["공개"를 클릭](https://help.github.com/articles/making-a-private-repository-public/)하고 등을 토닥이세요.
 
@@ -358,6 +358,6 @@ README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 읽게 할
   </label>
 </div>
 
-## You did it!
+## 해냈어요!
 
 첫번째 프로젝트를 오픈소스화한 것을 축하합니다. 결과가 어떻든 공개적으로 작업하는 것은 커뮤니티에게 좋은 선물입니다. 모든 커밋, 댓글, PR을 통해 여러분은 여러분 스스로와 다른 사람들이 배우고 성장할 기회를 창출하고 있습니다.

From 18ca71e13082cf932c8fc84e66f9b208dada13a4 Mon Sep 17 00:00:00 2001
From: lunar0926 <lunar0926@gmail.com>
Date: Tue, 26 Apr 2022 11:03:54 +0900
Subject: [PATCH 342/749] translate ko table of contents

---
 _articles/ko/code-of-conduct.md | 12 ++++++------
 _articles/ko/getting-paid.md    | 10 +++++-----
 _articles/ko/legal.md           | 16 ++++++++--------
 _articles/ko/metrics.md         | 12 ++++++------
 4 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/_articles/ko/code-of-conduct.md b/_articles/ko/code-of-conduct.md
index 4839651e9fb..93f72e02a60 100644
--- a/_articles/ko/code-of-conduct.md
+++ b/_articles/ko/code-of-conduct.md
@@ -10,7 +10,7 @@ related:
   - leadership
 ---
 
-## Why do I need a code of conduct?
+## 행동강령이 왜 필요할까요?
 
 행동강령은 프로젝트 참가자의 행동에 대한 기대치를 설정하는 문서입니다. 행동강령을 채택하고, 시행하면 커뮤니티에 긍정적인 사회적 분위기를 조성하는데 도움이 될 수 있습니다.
 
@@ -18,7 +18,7 @@ related:
 
 행동강령은 건강하고, 건설적인 커뮤니티 행동을 촉진할 수 있도록 해줍니다. 능동적으로 행동하면 자신이나 다른 사람들이 프로젝트에 피로를 느끼게 될 가능성을 낮추고, 누군가가 동의하지 않을 때 조치를 취할 수 있도록 도와줍니다.
 
-## Establishing a code of conduct
+## 행동강령 수립하기
 
 가능한 빨리 행동강령을 수립하십시오: 이상적으로, 처음 프로젝트를 만들 때입니다.
 
@@ -35,7 +35,7 @@ related:
 
 프로젝트의 최상단 디렉토리에 CODE_OF_CONDUCT 파일을 놓고 CONTRIBUTING 또는 README 파일에서 링크하여 커뮤니티에 표시되게 하십시오.
 
-## Deciding how you'll enforce your code of conduct
+## 행동강령을 어떻게 시행할 것인지 결정하기
 
 <aside markdown="1" class="pquote">
   A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
@@ -60,7 +60,7 @@ related:
 
 영감을 얻으려면, Django의 [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/)를 확인해봅시다(프로젝트의 크기에 따라 이 포괄적인 것을 필요로 하지 않을 수도 있습니다).
 
-## Enforcing your code of conduct
+## 행동강령을 시행하기
 
 때로는, 최선의 노력에도 불구하고, 누군가 이 코드를 위반하는 행동을 취할 때가 있습니다. 부정적인 행동이나 유해한 행동을 해결할 수 있는 몇 가지 방법이 있습니다.
 
@@ -99,7 +99,7 @@ related:
 
 금지 회원은 영구적이고 회피 할 수 없는 관점의 차이를 나타나기 때문에 가볍게 생각해서는 안됩니다. 해결 방법에 도달할 수 없다는 것이 명백 할 때만 이러한 조치를 취해야합니다.
 
-## Your responsibilities as a maintainer
+## 메인테이너로서의 책임
 
 행동강령은 임의적으로 집행되는 법이 아닙니다. 귀하는 행동강령의 집행자이며 행동강령이 정하는 규칙을 준수하는 것은 귀하의 책임입니다.
 
@@ -109,6 +109,6 @@ _기술적인_ 행동강령을 위반하지 않는 행동 보고서는 여전히
 
 결국, 메인테이너로서, 당신은 수용 가능한 행동에 대한 기준을 설정하고 시행합니다. 프로젝트의 커뮤니티 가치를 형성 할 수 있는 능력이 있으며, 참여자는 이러한 가치를 공정하고 균등하게 적용할 것을 기대합니다.
 
-## Encourage the behavior you want to see in the world 🌎
+## 당신이 이 세상에서 보고 싶은 행동을 장려하기 🌎
 
 프로젝트가 적대적이거나 환영받지 못하는 것처럼 보일 때, 다른 사람이 행동을 용인하는 사람이 한 명이라도 더 많은 기여자를 잃을 위험이 있으며, 그 중 일부는 절대 만나지 못할 수도 있습니다. 행동강령을 채택하거나 시행하는 것이 항상 쉬운 것은 아니지만, 친숙한 환경 조성은 커뮤니티 성장을 도울 것입니다.
diff --git a/_articles/ko/getting-paid.md b/_articles/ko/getting-paid.md
index edceba299f7..d80c58592ef 100644
--- a/_articles/ko/getting-paid.md
+++ b/_articles/ko/getting-paid.md
@@ -10,7 +10,7 @@ related:
   - leadership
 ---
 
-## Why some people seek financial support
+## 왜 누군가는 재정적 지원을 찾을까
 
 대부분의 오픈소스 작업은 자원봉사입니다. 예를 들어, 누군가가 사용하는 프로젝트에서 버그를 발견하고 빠른 버그픽스를 제출하거나, 여가 시간에 오픈소스 프로젝트를 사용하여 재미있는 작업을 할 수 있습니다.
 
@@ -60,7 +60,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri
 
 재정 지원을 찾고 있다면, 고려해야 할 두 가지 경로가 있습니다. 기여자로서 자신의 시간을 투자하거나, 프로젝트에 대한 조직 자금을 찾을 수 있습니다.
 
-## Funding your own time
+## 당신이 들인 시간에 대한 펀딩을 받기
 
 오늘날, 많은 사람들이 오픈소스에서 파트 타임 또는 풀 타임으로 일하기 위해 돈을 받습니다. 당신의 시간에 대한 대금을 받는 가장 일반적인 방법은 고용주와 상담하는 것입니다.
 
@@ -105,7 +105,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri
 * @gaearon은 [Patreon crowdfunding campaign](https://redux.js.org/)을 통해 [Redux](https://github.com/reactjs/redux)에 대한 그의 작업에 펀드했습니다.
 * @andrewgodwin은 Django 스키마 마이그레이션 작업을 [Kickstarter 캠페인을 통해](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) 펀드했습니다.
 
-## Finding funding for your project
+## 당신의 프로젝트에 대한 펀딩을 찾기
 
 개인 기여자를 위한 준비 외에도, 때로는 프로젝트가 회사, 개인 또는 다른 사람들로부터 지속적인 자금 마련을 위해 펀드를 모으는 경우가 있습니다.
 
@@ -143,7 +143,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri
 
 보다 자세한 옵션과 사례 연구를 원할 경우, @nayafia [가이드 작성](https://github.com/nayafia/lemonade-stand)을 통해 오픈소스 저작물에 대한 대가를 받을 수 있습니다. 다른 유형의 기금에는 여러 가지 기술이 필요하기 때문에 어떤 옵션이 가장 적합한 지 알아 내려면 장점을 고려하십시오.
 
-## Building a case for financial support
+## 재정적 지원을 받기 위한 근거를 갖추기
 
 프로젝트가 새로운 아이디어이든, 수년간 지속되어 왔든 타겟 기금 제공자를 파악하고 중요한 사건을 만드는데 중요하게 고려되야합니다.
 
@@ -177,6 +177,6 @@ I was looking for a "hobby" programming project that would keep me occupied duri
   </p>
 </aside>
 
-## Experiment and don't give up
+## 시도해 보고 포기하지 마세요!
 
 오픈소스 프로젝트, 비영리 단체, 소프트웨어 스타트업 등 많은 돈을 모으는 것은 쉽지 않습니다. 대부분의 경우 창의력을 발휘해야합니다. 어떻게 돈을 받고, 연구를 하고, 재밌는 사람의 신발에 몸을 두는지를 확인하면 자금 지원에 대한 설득력있는 사례를 구축하는 데 도움이됩니다.
diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index 14f606e5646..09f716f4482 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -10,11 +10,11 @@ related:
   - leadership
 ---
 
-## Understanding the legal implications of open source
+## 오픈소스의 법적 함의를 이해하기
 
 세계와 창의적인 작업을 공유하는 것은 흥미롭고 보람있는 경험이 될 수 있습니다. 그것은 또한 당신이 걱정해야 했지만 잘 몰랐던 여러 법적 문제를 의미할 수도 있습니다. 고맙게도 처음부터 다시 시작할 필요는 없습니다. 귀하의 법적 요구 사항이 있습니다. (이 내용을 파기전에, [면책조항](/notices/)을 읽으십시오.)
 
-## Why do people care so much about the legal side of open source?
+## 왜 사람들은 오픈소스의 법적 측면에 신경을 많이 쓸까요?
 
 물어봤다는건 다행입니다! 창의적인 작업(작성, 그래픽 또는 코드)을 할 때, 그 저작물은 기본적으로 독점적인 저작권 하에 있습니다. 즉, 법은 귀하를 저작물의 작성자로서 다른 사람들이 할 수 있는 것에 대해 귀하가 말하고 있는 것으로 간주합니다.
 
@@ -26,7 +26,7 @@ related:
 
 마지막으로, 프로젝트는 사용자가 알지 못하는 라이선스 요구 사항과의 종속성을 가질 수 있습니다. 프로젝트의 커뮤니티 또는 고용주의 정책에 따라 프로젝트에서 특정 오픈소스 라이선스를 사용해야 할 수도 있습니다. 아래에서 이러한 상황을 다룰 것입니다.
 
-## Are public GitHub projects open source?
+## 깃허브의 공개 프로젝트는 오픈소스인가요?
 
 깃허브에서 [새로운 프로젝트를 만들려고](https://help.github.com/articles/creating-a-new-repository/) 할 때, **비공개** 또는 **공개** 저장소로 만드는 옵션을 선택할 수 있습니다.
 
@@ -36,7 +36,7 @@ related:
 
 다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게 하려면, 오픈소스 라이선스를 포함해야 합니다. 예를 들어, GitHub 프로젝트가 공개되어 있다 하더라도 명시적으로 권한을 부여하지 않는다면, 그 코드의 어느 부분도 사용할 수 없습니다. 
 
-## Just give me the TL;DR on what I need to protect my project.
+## 너무 기니까 그냥 내 프로젝트를 보호하는 데 필요한 점을 요약해 주세요.
 
 운이 좋았습니다. 오늘날 오픈소스 라이선스는 표준화되어 있고 사용하기 쉽기 때문입니다. 기존 라이선스를 프로젝트에 직접 복사하여 붙여넣을 수 있습니다.
 
@@ -52,7 +52,7 @@ GitHub에서 새로운 프로젝트를 만들 때, [라이선스를 추가할 
   </p>
 </aside>
 
-## Which open source license is appropriate for my project?
+## 내 프로젝트에는 어떤 라이선스가 적합할까요?
 
 빈 슬레이트에서 시작한다면, [MIT 라이선스](https://choosealicense.com/licenses/mit/)를 잘못 읽는 것은 어렵습니다. MIT 라이선스는 짧고 이해하기 쉬우며, 저작권 고지를 포함하여 라이선스 사본을 보관하는 한 누구나 모든 것을 할 수 있도록 허락합니다. 필요한 경우 다른 라이선스로 프로젝트를 릴리스 할 수 있습니다.
 
@@ -72,7 +72,7 @@ GitHub에서 새로운 프로젝트를 만들 때, [라이선스를 추가할 
 
 GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는 옵션이 제공됩니다. 위에서 언급한 라이선스 중 하나를 포함하면 GitHub 프로젝트가 오픈소스로 됩니다. 다른 옵션을 보려면 [choosealicense.com](https://choosealicense.com)에서 [소프트웨어가 아닌 프로젝트](https://choosealicense.com/non-software/)에 적합한 라이선스를 찾으십시오.
 
-## What if I want to change the license of my project?
+## 내 프로젝트의 라이선스를 바꾸고 싶다면 어쩌죠?
 
 대부분의 프로젝트는 라이선스를 변경할 필요가 없습니다. 그러나 때때로 상황이 바뀝니다.
 
@@ -86,7 +86,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
 
 또는 기여자가 기존 오픈소스 라이선스에서 허용하는 것 이상으로 특정 조건하에서 특정 라이선스 변경 사항에 대해 사전에 동의할 수 있습니다 (추가 기여자 계약 - 아래 참조). 이렇게하면 라이선스 변경의 복잡성이 조금씩 바뀝니다. 변호사의 도움이 더 필요합니다. 라이선스 변경을 수행할 때는, 프로젝트의 이해 관계자와 명확하게 의견을 나눌 수 있습니다.
 
-## Does my project need an additional contributor agreement?
+## 내 프로젝트에 추가 기여자 계약이 필요한가요?
 
 아마도 그렇지 않습니다. 대다수의 오픈소스 프로젝트에서 공개 소스 라이선스는 인바운드(기여자)와 아웃바운드(다른 참여자 및 사용자) 라이선스로 암묵적으로 사용됩니다. 프로젝트가 GitHub에 있는 경우, GitHub 서비스 약관은 "인바운드 = 아웃 바운드" [명시적 기본값](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license)으로 지정합니다.
 
@@ -111,7 +111,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
 
 프로젝트에 기여자 계약을 추가로 사용해야하는 경우 기여자 산만을 최소화하기 위해 [CLA 어시스턴트](https://github.com/cla-assistant/cla-assistant)와 같은 통합 사용을 고려하십시오.
 
-## What does my company's legal team need to know?
+## 회사의 법무팀은 무엇을 알아야 할까요?
 
 오픈소스 프로젝트를 회사 직원으로 공개하는 경우, 먼저 법률팀이 오픈소스 프로젝트임을 알고 있어야 합니다.
 
diff --git a/_articles/ko/metrics.md b/_articles/ko/metrics.md
index 19d657dbf95..ab5d16f187d 100644
--- a/_articles/ko/metrics.md
+++ b/_articles/ko/metrics.md
@@ -10,7 +10,7 @@ related:
   - best-practices
 ---
 
-## Why measure anything?
+## 왜 측정할까요?
 
 데이터를 현명하게 사용하면, 오픈소스 메인테이너로서 더 나은 의사 결정을 내릴 수 있습니다.
 
@@ -31,7 +31,7 @@ related:
 
 If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
 
-## Discovery
+## 발견
 
 누구든지 프로젝트를 사용하거나 기여할 수 있게 하기전에, 이것이 존재 하는 지를 알아야합니다. 자신에게 물어보십시오: _이 프로젝트를 찾는 사람들입니까?_
 
@@ -51,7 +51,7 @@ If you _are_ interested in understanding your project on a deeper level, read on
 
 [특정 장소에서 검색 가능성을 추적](https://opensource.com/business/16/6/pirate-metrics) 할 수도 있습니다: 예를 들어, Google 페이지랭크, 프로젝트 웹 사이트의 추천 트래픽 또는 다른 오픈소스 프로젝트 또는 웹 사이트의 추천을 포함 할 수 있습니다.
 
-## Usage
+## 사용
 
 사람들은 우리가 인터넷이라고 부르는 이 거칠고 미친 일로 프로젝트를 찾고 있습니다. 이상적으로는, 프로젝트를 보았을 때 뭔가 할 것을 강요 당할 것입니다. 두 번째 질문은 다음과 같습니다: _이 프로젝트를 사용하는 사람들입니까?_
 
@@ -74,7 +74,7 @@ npm 또는 RubyGems.org와 같은 패키지 관리자를 사용하여 프로젝
 
 사람들이 프로젝트를 사용하고 있다는 것을 알게되면, 사람들이 프로젝트를 통해 무엇을 하고 있는지 파악하려고 할 수 있습니다. 그들은 당신의 코드를 포크하고 기능을 추가함으로써 그것을 구축하고 있습니까? 그들은 과학이나 비즈니스를 위해 그것을 사용하고 있습니까?
 
-## Retention
+## 유지
 
 사람들이 프로젝트를 찾고 있으며 프로젝트를 사용하고 있습니다. 다음 질문은 스스로에게 물어볼 것입니다: _이 프로젝트에 다시 기여한 사람들입니까?_
 
@@ -104,7 +104,7 @@ npm 또는 RubyGems.org와 같은 패키지 관리자를 사용하여 프로젝
   </p>
 </aside>
 
-## Maintainer activity
+## 메인테이너의 활동
 
 마지막으로, 프로젝트 메인테이너가 받은 기여 분량을 처리 할 수 있는지 확인하여 루프를 닫으십시오. 자신에게 묻고 싶은 마지막 질문은 다음과 같습니다: _나는 (또는 우리가) 우리 커뮤니티에 반응하고 있습니까?_
 
@@ -121,6 +121,6 @@ npm 또는 RubyGems.org와 같은 패키지 관리자를 사용하여 프로젝
 * 부실 이슈가 종결 되는지 여부
 * pull request을 병합하는 평균 시간
 
-## Use 📊 to learn about people
+## 사람들에 대해 배우려면 📊를 사용하세요
 
 측정 기준을 이해하면 적극적으로 성장하는 오픈소스 프로젝트를 구축하는 데 도움이됩니다. 대시 보드의 모든 측정치를 추적하지 않더라도, 위의 프레임워크를 사용하여 프로젝트가 성공하는 데 도움이 되는 동작 유형에 주의를 기울이십시오.

From 6d0794172ad8ce3ab945a16c2338901300685593 Mon Sep 17 00:00:00 2001
From: lunar0926 <lunar0926@gmail.com>
Date: Tue, 26 Apr 2022 15:35:20 +0900
Subject: [PATCH 343/749] fix broken link

---
 _articles/ko/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index 09f716f4482..6df7a449146 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -68,7 +68,7 @@ GitHub에서 새로운 프로젝트를 만들 때, [라이선스를 추가할 
 * **프로젝트를 대기업에 어필하고 싶습니까?** 대기업은 모든 참여자의 명시적인 특허 라이선스를 원할 것입니다. 이 경우, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)는 귀하(그리고 그들)을 커버해 줄것 입니다.
 * **독점 소스 소프트웨어에 기여를 하고 싶지 않은 기여자에게 프로젝트를 어필하고 싶습니까?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) 혹은 (또한 독점 소스 서비스에 기여하지 않으려는 경우) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/)은 잘될 것입니다.
 
-귀하의 **회사**는 오픈소스 프로젝트에 대한 특정 라이선스 요구 사항을 가지고 있을 수 있습니다. 예를 들어, 회사에서 회사의 독점 소스 제품에서 프로젝트를 사용할 수 있도록 허용 라이선스가 필요할 수 있습니다. 또는 귀사만 독점 소스 소프트웨어에서 프로젝트를 사용할 수 있도록 강력한 카피 레프트 라이선스와 추가 기여자 계약(아래 참조)이 필요할 수 있습니다. 또는 표준, 사회적 책임 또는 투명성과 관련된 특정 요구 사항이 있을 수 있습니다. 이러한 요구 사항에는 특정 라이선스 전략이 필요할 수 있습니다. 귀하의 [회사 법률 부서](#what-does-my-companys-legal-team-need-to-know)에 이야기하십시오.
+귀하의 **회사**는 오픈소스 프로젝트에 대한 특정 라이선스 요구 사항을 가지고 있을 수 있습니다. 예를 들어, 회사에서 회사의 독점 소스 제품에서 프로젝트를 사용할 수 있도록 허용 라이선스가 필요할 수 있습니다. 또는 귀사만 독점 소스 소프트웨어에서 프로젝트를 사용할 수 있도록 강력한 카피 레프트 라이선스와 추가 기여자 계약(아래 참조)이 필요할 수 있습니다. 또는 표준, 사회적 책임 또는 투명성과 관련된 특정 요구 사항이 있을 수 있습니다. 이러한 요구 사항에는 특정 라이선스 전략이 필요할 수 있습니다. 귀하의 [회사 법률 부서](#회사의-법무팀은-무엇을-알아야-할까요)에 이야기하십시오.
 
 GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는 옵션이 제공됩니다. 위에서 언급한 라이선스 중 하나를 포함하면 GitHub 프로젝트가 오픈소스로 됩니다. 다른 옵션을 보려면 [choosealicense.com](https://choosealicense.com)에서 [소프트웨어가 아닌 프로젝트](https://choosealicense.com/non-software/)에 적합한 라이선스를 찾으십시오.
 

From e9fa6c7a8f4034d16dff9c39aebbab9ce2576c27 Mon Sep 17 00:00:00 2001
From: Viktor <63919734+ViktorOn@users.noreply.github.com>
Date: Tue, 3 May 2022 21:34:51 +0300
Subject: [PATCH 344/749] Update best-practices.md

---
 _articles/ru/best-practices.md | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md
index ef7ac98763a..02265cc824d 100644
--- a/_articles/ru/best-practices.md
+++ b/_articles/ru/best-practices.md
@@ -1,7 +1,7 @@
 ---
 lang: ru
 title: Хорошие практики для мейнтейнеров
-description: Облегчите вашу жизнь как мейнтейнера опенсорс-проекта — от документирования процессов до привлечения вашего сообщества.
+description: Облегчение вашей жизни в качестве мейнтейнера опенсорс-проекта — от документирования процессов до привлечения вашего сообщества.
 class: best-practices
 order: 5
 image: /assets/images/cards/best-practices.png
@@ -12,7 +12,7 @@ related:
 
 ## Что значит быть мейнтейнером?
 
-Если вы поддерживаете опенсорс-проект, которым пользуется множество людей, возможно, вы заметили, что меньше пишите код и больше отвечаете в ишью.
+Если вы поддерживаете опенсорс-проект, которым пользуется множество людей, возможно, вы заметили, что стали меньше писать код и больше отвечать на ишью.
 
 На ранних стадиях проекта вы экспериментируете с новыми идеями и принимаете решения, основываясь на собственных предпочтениях. По мере роста популярности вашего проекта вы будете больше работать со своими пользователями и контрибьюторами.
 
@@ -36,11 +36,11 @@ related:
 
 Наличие четкого и задокументированной концепции проекта поможет вам сосредоточиться на главном и избежать «неконтролируемого роста проекта» от участия других людей.
 
-Например, @lord обнаружил, что видение проекта помогло ему понять правильно расставить приоритеты. Как новый мейнтейнер, он сожалел, что проследил за расползанием границ проекта, когда получил свой первый запрос на реализацию новой функциональности в [Slate](https://github.com/lord/slate).
+Например, @lord обнаружил, что видение проекта помогло ему понять правильно расставить приоритеты. Как новый мейнтейнер, он сожалел, что не проследил за расползанием границ проекта, когда получил свой первый запрос на реализацию новой функциональности в [Slate](https://github.com/lord/slate).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
-  Я не справился. Я не приложил достаточно усилий, чтобы найти полное решение. Вместо половинчатого решения мне было бы сказать: «У меня сейчас нет на это времени, но я добавлю его в список пожеланий».
+  Я не справился. Я не приложил достаточно усилий, чтобы найти полное решение. Вместо половинчатого решения мне нужно было бы сказать: «У меня сейчас нет на это времени, но я добавлю его в список пожеланий».
   <p markdown="1" class="pquote-credit">
 - @lord, [«Советы новым опенсорс-мейнтейнерам»](https://lord.io/blog/2014/oss-tips/)
   </p>
@@ -48,7 +48,7 @@ related:
 
 ### Сообщите о своих ожиданиях
 
-Написание правил может утомлять вас. Иногда вам может показаться, что вы следите за поведением других людей или убиваете все самое интересное.
+Написание правил может утомлять вас. Иногда вам может показаться, что вы следите за поведением других людей или убиваете все веселье.
 
 Однако справедливое выполнение хорошо составленных правил расширяют возможности мейнтейнеров. Это избавит вас от вовлечения в малоприятные дела.
 
@@ -120,7 +120,7 @@ related:
 
 ![Скриншот из Celery](/assets/images/best-practices/celery.png)
 
-Если мысль о том, чтобы сказать «нет», пугает вас, вы не одиноки. Как @jessfraz [выразился](https://blog.jessfraz.com/post/the-art-of-closing/):
+Если мысль о том, чтобы сказать «нет», пугает вас, вы не одиноки. Как [выразился](https://blog.jessfraz.com/post/the-art-of-closing/) @jessfraz:
 
 > Я разговаривал с мейнтейнерами из нескольких различных опенсорс-проектов, Mesos, Kubernetes, Chromium, и все они согласны с тем, что одна из самых сложных частей работы мейнтейнера — это отказаться от ненужных патчей.
 
@@ -128,7 +128,7 @@ related:
 
 В конечном итоге, если вклад недостаточно хорош, вы не обязаны его принимать. Будьте добры и отзывчивы, когда люди вносят свой вклад в ваш проект, но принимайте только те изменения, которые, по вашему мнению, сделают ваш проект лучше. Чем чаще вы будете говорить «нет», тем легче будет это получаться. Обещаю.
 
-### Будьте инициативным
+### Будьте инициативным(ой)
 
 Прежде всего, чтобы уменьшить количество нежелательных вкладов, распишите процесс отправки и принятия вкладов в своем руководстве по участию вашего проекта.
 
@@ -139,7 +139,7 @@ related:
 
 Если люди не соблюдают ваши правила, немедленно закройте ишью и укажите им на предварительные требования.
 
-Поначалу такой подход может показаться недобрым, но на самом деле проактивность полезна для обеих сторон. Это снижает вероятность того, что кто-то потратит впустую много часов работы на ненужный для вас пул-реквест. А ещё для вас снизится нагрузка.
+Поначалу такой подход может показаться суровым, но на самом деле проактивность полезна для обеих сторон. Это снижает вероятность того, что кто-то потратит впустую много часов работы на ненужный для вас пул-реквест. А ещё для вас снизится нагрузка.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
@@ -173,7 +173,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
-  Я говорила: «Да, любой может поучаствовать, не обязательно обладать большим опытом программирования [...]». У нас были люди, которые записывались, чтобы прийти [на мероприятие], и тогда я по-настоящему задумалась: справлюсь ли я этим? Придёт 40 человек, и я не могу сидеть с каждым из них... Но люди собрались вместе, и вроде всё прошло хорошо. Как только один человек понимал что-то, он мог научить своего соседа.
+  Я говорила: «Да, любой может поучаствовать, не обязательно обладать большим опытом программирования [...]». У нас были люди, которые записывались, чтобы прийти [на мероприятие], и тогда я по-настоящему задумалась: справлюсь ли с я этим? Собирается прийти 40 человек, и я не могу сидеть с каждым из них... Но люди собрались вместе, и вроде всё прошло хорошо. Как только один человек понимал что-то, он мог научить своего соседа.
   <p markdown="1" class="pquote-credit">
 - @lmccart, [«Что вообще означает «опенсорс»? P5.js Edition»](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
   </p>
@@ -277,4 +277,4 @@ related:
 
 ## Береги себя в первую очередь!
 
-Поддержка популярного проекта требует иных навыков, чем на ранних этапах развития, но это не уменьшает пользу описанных выше советов. Как мейнтейнер, вы будете практиковать лидерские и личные навыки на таком уровне, который мало кому удаётся испытать. Хотя управлять проектом не всегда легко, выстраивание чётких границ и адекватная оценка своих сил, помогут вам оставаться счастливыми, бодрыми и продуктивными.
+Поддержка популярного проекта требует иных навыков, чем на ранних этапах развития, но это не уменьшает пользу описанных выше советов. Как мейнтейнер, вы будете практиковать лидерские и личные навыки на таком уровне, который мало кому удаётся испытать. Хотя управлять проектом не всегда легко, выстраивание чётких границ и адекватная оценка своих сил помогут вам оставаться счастливыми, бодрыми и продуктивными.

From b032bd2a6fb1e9b3be183942adca5af87eb01fa3 Mon Sep 17 00:00:00 2001
From: bistcuite <85484922+bistcuite@users.noreply.github.com>
Date: Wed, 4 May 2022 13:34:36 +0430
Subject: [PATCH 345/749] fix a typo in farsi translation

---
 _articles/fa/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 65c7673adcd..84ceea2dde5 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -20,7 +20,7 @@ related:
   </p>
 </aside>
 
-زمانی که در پروژه‌های متن باز مشارکت می‌کنید، چیزهای زیادی یاد می‌گیرد یا یاد می‌دهید، حتی می‌توانید در هر مهارتی که تصورش را می‌کنید تجربه کسب کنید.
+زمانی که در پروژه‌های متن باز مشارکت می‌کنید، چیزهای زیادی یاد می‌گیرید یا یاد می‌دهید، حتی می‌توانید در هر مهارتی که تصورش را می‌کنید تجربه کسب کنید.
 
 چرا افراد در پروژه‌های متن باز مشارکت می‌کنند؟ خب، دلایل زیادی وجود دارد!
 

From 0e8a774fea1fc99472c78b2d1aff308801d6ca22 Mon Sep 17 00:00:00 2001
From: waltersumbon <907449377@qq.com>
Date: Sat, 14 May 2022 19:05:35 +0800
Subject: [PATCH 346/749] fix typo

---
 _articles/zh-hans/how-to-contribute.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/zh-hans/how-to-contribute.md b/_articles/zh-hans/how-to-contribute.md
index 9e929be9807..3afcb6123ea 100644
--- a/_articles/zh-hans/how-to-contribute.md
+++ b/_articles/zh-hans/how-to-contribute.md
@@ -187,7 +187,7 @@ redirect_from: /zh-cn/how-to-contribute/
 
 * **问题追踪:** 这里是人们讨论项目相关问题的地方。
 * **Pull requests:** 审核代码、以及相关的问题讨论。
-* **论坛或邮件列表:** 一些项目会使用会话式的主题（例如 _"How do I..."_ 或 _"What do you think about..."_ 来替代 Bug 报告或特性请求）。然而有一些项目关于讨论全部实用问题追踪。
+* **论坛或邮件列表:** 一些项目会使用会话式的主题（例如 _"How do I..."_ 或 _"What do you think about..."_ 来替代 Bug 报告或特性请求）。然而有一些项目关于讨论全部使用问题追踪。
 * **即时在线聊天:** 有一些项目会使用聊天频道（诸如 Slack 或 IRC），从而能够随意的谈话、协作和快速交流。
 
 ## 找一个项目开始贡献
@@ -380,7 +380,7 @@ redirect_from: /zh-cn/how-to-contribute/
 
 ### 有效沟通
 
-无论你处于什么样的目的：仅仅是一次性的贡献，亦或是永久性的加入社区，都得和他人进行沟通和交往，这是你要在开源圈发展必须修炼的技能。
+无论你出于什么样的目的：仅仅是一次性的贡献，亦或是永久性的加入社区，都得和他人进行沟通和交往，这是你要在开源圈发展必须修炼的技能。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">

From 9629e9c02915b69189237afd245a5fceb73c9fb3 Mon Sep 17 00:00:00 2001
From: waltersumbon <907449377@qq.com>
Date: Sat, 14 May 2022 19:43:35 +0800
Subject: [PATCH 347/749] fix broken internal hash

---
 _articles/ko/building-community.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/ko/building-community.md b/_articles/ko/building-community.md
index c7bd45276d9..d57c79e5acb 100644
--- a/_articles/ko/building-community.md
+++ b/_articles/ko/building-community.md
@@ -33,7 +33,7 @@ related:
 
 * **새로운 사람이 프로젝트에 찾아오면 그들의 관심에 감사를 표하세요!** 처음 온 사람은 단 한 번의 부정적인 경험으로도 다시 프로젝트에 돌아오지 않게 될 수 있습니다.
 * **적극적으로 반응하세요.** 이슈에 한 달 이상 반응하지 않았다면 이슈를 올린 사람은 이미 여러분의 프로젝트를 잊었을지도 모릅니다.
-* **열린 마음을 가지고 다양한 유형의 기여를 받아들이세요.** 많은 기여자들이 처음에는 버그 제보나 작은 수정에서부터 시작합니다. 프로젝트에 기여하는 데에는 [다양한 방법](../how-to-contribute/#what-it-means-to-contribute)이 있습니다. 그들이 원하는 방식으로 여러분을 도울 수 있게 하세요.
+* **열린 마음을 가지고 다양한 유형의 기여를 받아들이세요.** 많은 기여자들이 처음에는 버그 제보나 작은 수정에서부터 시작합니다. 프로젝트에 기여하는 데에는 [다양한 방법](../how-to-contribute/#기여한다는-것의-의미)이 있습니다. 그들이 원하는 방식으로 여러분을 도울 수 있게 하세요.
 * **받아들일 수 없는 기여가 있다면,** 먼저 그들의 아이디어에 감사하고, 왜 그 기여가 프로젝트의 의도에 맞지 않는지 [이유를 설명](../best-practices/#거절하는-법-배우기)하세요. 관련 문서가 있다면 링크를 첨부하는 것이 좋습니다.
 
 <aside markdown="1" class="pquote">
@@ -122,7 +122,7 @@ related:
 
 프로젝트의 사소한 면에 대한 반복적인 논쟁은 여러분을 포함한 구성원이 보다 중요한 일에 집중하는 것을 방해합니다. 여러분의 프로젝트에 새로 찾아온 사람들이 이런 논쟁을 보면 프로젝트에 참여하고 싶지 않을 것입니다.
 
-여러분의 프로젝트에서 행해지는 옳지 않은 행동을 발견한다면, 친절하지만 완고하게 어째서 그런 행동이 용납될 수 없는지 공적으로 설명하세요. 문제가 지속된다면 [그들을 떠나보내야 할 수도 있습니다](../code-of-conduct/#enforcing-your-code-of-conduct). 프로젝트 [행동 강령](../code-of-conduct/)이 이런 대화의 적절한 지침이 될 것입니다.
+여러분의 프로젝트에서 행해지는 옳지 않은 행동을 발견한다면, 친절하지만 완고하게 어째서 그런 행동이 용납될 수 없는지 공적으로 설명하세요. 문제가 지속된다면 [그들을 떠나보내야 할 수도 있습니다](../code-of-conduct/#행동강령을-시행하기). 프로젝트 [행동 강령](../code-of-conduct/)이 이런 대화의 적절한 지침이 될 것입니다.
 
 ### 기여자에게 먼저 다가가세요
 

From 8cb2d52e232553865f472395190b514aa8845175 Mon Sep 17 00:00:00 2001
From: waltersumbon <907449377@qq.com>
Date: Sat, 14 May 2022 20:00:57 +0800
Subject: [PATCH 348/749] fix broken internal hash tag

---
 _articles/ko/leadership-and-governance.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/ko/leadership-and-governance.md b/_articles/ko/leadership-and-governance.md
index e2c107b53df..87f391f5505 100644
--- a/_articles/ko/leadership-and-governance.md
+++ b/_articles/ko/leadership-and-governance.md
@@ -40,7 +40,7 @@ related:
 
 **"커미터"**라는 용어는 다른 기여 유형에 대비해 커밋이라는 특정 권한과 책임을 가진 사람을 구분하고자 사용합니다.
 
-프로젝트 역할은 여러분이 원하는 대로 정의할 수 있지만, 다양한 유형의 기여를 이끌어내기 위해 되도록 [넓은 정의를 사용하세요](../how-to-contribute/#what-it-means-to-contribute). 전문적인 기술 수준과 별개로 프로젝트에 대단한 기여를 한 사람들에게 리더십 역할을 부여하며 그들에게 답례를 표할 수 있습니다.
+프로젝트 역할은 여러분이 원하는 대로 정의할 수 있지만, 다양한 유형의 기여를 이끌어내기 위해 되도록 [넓은 정의를 사용하세요](../how-to-contribute/#기여한다는-것의-의미). 전문적인 기술 수준과 별개로 프로젝트에 대단한 기여를 한 사람들에게 리더십 역할을 부여하며 그들에게 답례를 표할 수 있습니다.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">

From 9df6872a949b5fd849f485199eb66f2f427da897 Mon Sep 17 00:00:00 2001
From: naveensrinivasan <172697+naveensrinivasan@users.noreply.github.com>
Date: Sat, 14 May 2022 08:44:55 -0500
Subject: [PATCH 349/749] chore: Included githubactions in the dependabot
 config

This should help with keeping the GitHub actions updated on new releases. This will also help with keeping it secure.

Dependabot helps in keeping the supply chain secure https://docs.github.com/en/code-security/dependabot

GitHub actions up to date https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot

https://github.com/ossf/scorecard/blob/main/docs/checks.md#dependency-update-tool
Signed-off-by: naveensrinivasan <172697+naveensrinivasan@users.noreply.github.com>
---
 .github/dependabot.yml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index 8e9bbb8d821..8dc181fec96 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -10,3 +10,10 @@ updates:
       separator: "-"
     open-pull-requests-limit: 99
     rebase-strategy: disabled
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule: 
+     interval: daily
+    open-pull-requests-limit: 99
+    rebase-strategy: disabled
+  

From f7339c440772297c9199d84c14adcd10435daaf8 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Sun, 15 May 2022 11:48:26 +0300
Subject: [PATCH 350/749] Fully translate code-of-conduct.md

---
 _articles/el/code-of-conduct.md | 100 ++++++++++++++++----------------
 1 file changed, 50 insertions(+), 50 deletions(-)

diff --git a/_articles/el/code-of-conduct.md b/_articles/el/code-of-conduct.md
index 3eaa41575cb..f007e8bdb4e 100644
--- a/_articles/el/code-of-conduct.md
+++ b/_articles/el/code-of-conduct.md
@@ -10,105 +10,105 @@ related:
   - leadership
 ---
 
-## Why do I need a code of conduct?
+## Γιατί χρειάζομαι έναν κώδικα δεοντολογίας;
 
-A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.
+Ο κώδικας δεοντολογίας είναι ένα έγγραφο που καθορίζει τις προσδοκίες συμπεριφοράς για τους συμμετέχοντες στο πρότζεκτ σας. Η υιοθέτηση και η επιβολή ενός κώδικα δεοντολογίας μπορεί να συμβάλει στη δημιουργία θετικής κοινωνικής ατμόσφαιρας για την κοινότητά σας.
 
-Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.
+Οι κώδικες δεοντολογίας βοηθούν στην προστασία όχι μόνο των συμμετεχόντων σας, αλλά και εσάς τους ίδιους. Εάν συντηρείτε ένα πρότζεκτ, μπορεί να διαπιστώσετε ότι οι μη παραγωγικές συμπεριφορές των άλλων συμμετεχόντων μπορεί να σας κάνουν να νιώθετε εξαντλημένοι ή δυσαρεστημένοι με την εργασία σας με την πάροδο του χρόνου.
 
-A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with.
+Ένας κώδικας δεοντολογίας σας δίνει τη δυνατότητα να διευκολύνετε την υγιή, εποικοδομητική συμπεριφορά της κοινότητας. Το να είστε προληπτικοί μειώνει την πιθανότητα να κουραστείτε εσείς ή άλλοι από το πρότζεκτ σας και σας βοηθά να αναλάβετε δράση όταν κάποιος κάνει κάτι με το οποίο δεν συμφωνείτε.
 
-## Establishing a code of conduct
+## Καθιέρωση ενός κώδικα συμπεριφοράς
 
-Try to establish a code of conduct as early as possible: ideally, when you first create your project.
+Προσπαθήστε να καθιερώσετε έναν κώδικα συμπεριφοράς όσο το δυνατόν νωρίτερα: ιδανικά, όταν δημιουργείτε για πρώτη φορά το πρότζεκτ σας.
 
-In addition to communicating your expectations, a code of conduct describes the following:
+Εκτός από την κοινοποίηση των προσδοκιών σας, ένας κώδικας δεοντολογίας περιγράφει τα εξής:
 
-* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_
-* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_
-* What happens if someone violates the code of conduct
-* How someone can report violations
+* Πού τίθεται σε ισχύ ο κώδικας συμπεριφοράς _(μόνο σε θέματα και αιτήσεις διανομής ή σε δραστηριότητες της κοινότητας, όπως εκδηλώσεις;)_
+* Σε ποιους ισχύει ο κώδικας συμπεριφοράς _(μέλη της κοινότητας και συντηρητές, αλλά τι γίνεται με τους χορηγούς;)_
+* Τι συμβαίνει αν κάποιος παραβιάσει τον κώδικα συμπεριφοράς
+* Πώς μπορεί κάποιος να αναφέρει παραβιάσεις
 
-Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
+Όπου μπορείτε, χρησιμοποιήστε την προϋπάρχουσα τέχνη. Το [Contributor Covenant] (https://contributor-covenant.org/) είναι ένας drop-in κώδικας συμπεριφοράς που χρησιμοποιείται από πάνω από 40.000 έργα ανοικτού κώδικα, συμπεριλαμβανομένων των Kubernetes, Rails και Swift.
 
-The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples.
+Ο [Django Code of Conduct](https://www.djangoproject.com/conduct/) και ο [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) είναι επίσης δύο καλά παραδείγματα κώδικα συμπεριφοράς.
 
-Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
+Τοποθετήστε ένα αρχείο CODE_OF_CONDUCT στο ριζικό κατάλογο του πρότζεκτ σας και κάντε το ορατό στην κοινότητά σας, συνδέοντάς το από το αρχείο CONTRIBUTING ή README.
 
-## Deciding how you'll enforce your code of conduct
+## Αποφασίζοντας πώς θα επιβάλλετε τον κώδικα συμπεριφοράς σας
 
 <aside markdown="1" class="pquote">
-  A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
+  Ένας κώδικας συμπεριφοράς που δεν επιβάλλεται (ή δεν μπορεί να επιβληθεί) είναι χειρότερος από το να μην υπάρχει καθόλου κώδικας συμπεριφοράς: στέλνει το μήνυμα ότι οι αξίες του κώδικα συμπεριφοράς δεν είναι στην πραγματικότητα σημαντικές ή σεβαστές στην κοινότητά σας.
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+- [Πρωτοβουλία Ada](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
-You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:
+Θα πρέπει να εξηγήσετε πώς θα επιβληθεί ο κώδικας συμπεριφοράς σας **_πριν_** συμβεί μια παραβίαση. Υπάρχουν διάφοροι λόγοι για να το κάνετε αυτό:
 
-* It demonstrates that you are serious about taking action when it's needed.
+* Δείχνει ότι είστε σοβαροί στο να αναλάβετε δράση όταν χρειάζεται.
 
-* Your community will feel more reassured that complaints actually get reviewed.
+* Η κοινότητά σας θα αισθάνεται πιο καθησυχαστική ότι οι καταγγελίες πράγματι εξετάζονται.
 
-* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.
+* Θα καθησυχάσετε την κοινότητά σας ότι η διαδικασία επανεξέτασης είναι δίκαιη και διαφανής, σε περίπτωση που ποτέ βρεθούν υπό διερεύνηση για παραβίαση.
 
-You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
+Θα πρέπει να δώσετε στους ανθρώπους έναν ιδιωτικό τρόπο (όπως μια διεύθυνση ηλεκτρονικού ταχυδρομείου) για να αναφέρουν μια παραβίαση του κώδικα δεοντολογίας και να εξηγήσετε ποιος λαμβάνει αυτή την αναφορά. Θα μπορούσε να είναι ένας συντηρητής, μια ομάδα συντηρητών ή μια ομάδα εργασίας κώδικα δεοντολογίας.
 
-Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+Μην ξεχνάτε ότι κάποιος μπορεί να θέλει να αναφέρει μια παραβίαση για ένα άτομο που λαμβάνει αυτές τις αναφορές. Σε αυτή την περίπτωση, δώστε τους τη δυνατότητα να αναφέρουν τις παραβιάσεις σε κάποιον άλλο. Για παράδειγμα, οι @ctb και @mr-c [εξηγούν για το πρότζεκτ τους](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
-> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+> Περιπτώσεις καταχρηστικής, παρενοχλητικής ή άλλως απαράδεκτης συμπεριφοράς μπορούν να αναφερθούν στέλνοντας email στο **khmer-project@idyll.org**, το οποίο απευθύνεται μόνο στους C. Titus Brown και Michael R. Crusoe. Για να αναφέρετε ένα θέμα που αφορά κάποιον από τους δύο, στείλτε email στον **Judi Brown Clarke, Ph.D.**, τον διευθυντή ποικιλομορφίας στο Κέντρο BEACON για τη μελέτη της εξέλιξης στην πράξη, ένα Κέντρο Επιστήμης και Τεχνολογίας του NSF*.
 
-For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+Για έμπνευση, δείτε το [εγχειρίδιο επιβολής](https://www.djangoproject.com/conduct/enforcement-manual/) του Django (αν και μπορεί να μην χρειάζεστε κάτι τόσο περιεκτικό, ανάλογα με το μέγεθος του πρότζεκτ σας).
 
-## Enforcing your code of conduct
+## Επιβολή του κώδικα συμπεριφοράς σας
 
-Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up.
+Μερικές φορές, παρά τις προσπάθειές σας, κάποιος θα κάνει κάτι που παραβιάζει αυτόν τον κώδικα. Υπάρχουν διάφοροι τρόποι για να αντιμετωπίσετε την αρνητική ή επιβλαβή συμπεριφορά όταν αυτή προκύψει.
 
-### Gather information about the situation
+### Συγκεντρώστε πληροφορίες σχετικά με την κατάσταση
 
-Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment.
+Αντιμετωπίστε τη φωνή κάθε μέλους της κοινότητας εξίσου σημαντική με τη δική σας. Αν λάβετε μια αναφορά ότι κάποιος παραβίασε τον κώδικα συμπεριφοράς, πάρτε την στα σοβαρά και ερευνήστε το θέμα, ακόμη και αν δεν ταιριάζει με τη δική σας εμπειρία με το συγκεκριμένο άτομο. Με τον τρόπο αυτό σηματοδοτείτε στην κοινότητά σας ότι εκτιμάτε την άποψή της και εμπιστεύεστε την κρίση της.
 
-The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context.
+Το εν λόγω μέλος της κοινότητας μπορεί να είναι ένας επαναλαμβανόμενος παραβάτης που κάνει τους άλλους να αισθάνονται συνεχώς άβολα, ή μπορεί να έχει πει ή κάνει κάτι μόνο μία φορά. Και τα δύο μπορούν να αποτελέσουν λόγο για τη λήψη μέτρων, ανάλογα με το πλαίσιο.
 
-Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
+Πριν απαντήσετε, δώστε χρόνο στον εαυτό σας να καταλάβει τι συνέβη. Διαβάστε τα προηγούμενα σχόλια και συζητήσεις του ατόμου για να καταλάβετε καλύτερα ποιος είναι και γιατί μπορεί να ενήργησε με αυτόν τον τρόπο. Προσπαθήστε να συγκεντρώσετε άλλες οπτικές γωνίες εκτός από τις δικές σας σχετικά με αυτό το άτομο και τη συμπεριφορά του.
 
 <aside markdown="1" class="pquote">
-  Don’t get pulled into an argument. Don’t get sidetracked into dealing with someone else’s behavior before you’ve finished dealing with the matter at hand. Focus on what you need.
+  Μην παρασύρεστε σε μια διαφωνία. Μην παρασυρθείτε στο να ασχοληθείτε με τη συμπεριφορά κάποιου άλλου πριν τελειώσετε με το θέμα που σας απασχολεί. Επικεντρωθείτε σε αυτό που χρειάζεστε.
   <p markdown="1" class="pquote-credit">
-— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+- Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
   </p>
 </aside>
 
-### Take appropriate action
+### Αναλάβετε την κατάλληλη δράση
 
-After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward.
+Αφού συγκεντρώσετε και επεξεργαστείτε επαρκείς πληροφορίες, θα πρέπει να αποφασίσετε τι πρέπει να κάνετε. Καθώς εξετάζετε τα επόμενα βήματά σας, να θυμάστε ότι στόχος σας ως συντονιστής είναι να προωθήσετε ένα ασφαλές, με σεβασμό και συνεργασία περιβάλλον. Σκεφτείτε όχι μόνο πώς να αντιμετωπίσετε την εν λόγω κατάσταση, αλλά και πώς η αντίδρασή σας θα επηρεάσει τη συμπεριφορά και τις προσδοκίες της υπόλοιπης κοινότητάς σας στο μέλλον.
 
-When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise.
+Όταν κάποιος αναφέρει μια παραβίαση του κώδικα συμπεριφοράς, είναι δική σας δουλειά, όχι δική τους, να το χειριστείτε. Ορισμένες φορές, ο καταγγέλλων αποκαλύπτει πληροφορίες με μεγάλο κίνδυνο για την καριέρα του, τη φήμη του ή τη σωματική του ακεραιότητα. Ο εξαναγκασμός τους να αντιμετωπίσουν τον παρενοχλητή τους θα μπορούσε να θέσει τον αναφέροντα σε επικίνδυνη θέση. Θα πρέπει να χειρίζεστε την άμεση επικοινωνία με το εν λόγω πρόσωπο, εκτός εάν ο δημοσιογράφος ζητήσει ρητά το αντίθετο.
 
-There are a few ways you might respond to a code of conduct violation:
+Υπάρχουν μερικοί τρόποι με τους οποίους μπορείτε να αντιδράσετε σε μια παραβίαση του κώδικα δεοντολογίας:
 
-* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication.
+* **Δώστε στο εν λόγω άτομο μια δημόσια προειδοποίηση** και εξηγήστε πώς η συμπεριφορά του επηρέασε αρνητικά τους άλλους, κατά προτίμηση στο κανάλι όπου συνέβη. Όπου είναι δυνατόν, η δημόσια επικοινωνία μεταφέρει στην υπόλοιπη κοινότητα ότι παίρνετε σοβαρά τον κώδικα συμπεριφοράς. Να είστε ευγενικοί, αλλά αυστηροί στην επικοινωνία σας.
 
-* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them.
+* **Επικοινωνήστε ιδιωτικά με το εν λόγω άτομο** για να εξηγήσετε πώς η συμπεριφορά του επηρέασε αρνητικά τους άλλους. Μπορεί να θέλετε να χρησιμοποιήσετε ένα ιδιωτικό κανάλι επικοινωνίας, εάν η κατάσταση αφορά ευαίσθητες προσωπικές πληροφορίες. Εάν επικοινωνήσετε με κάποιον ιδιαιτέρως, καλό θα ήταν να ενημερώσετε όσους ανέφεραν πρώτοι την κατάσταση, ώστε να γνωρίζουν ότι αναλάβατε δράση. Ζητήστε τη συγκατάθεση του ατόμου που έκανε την αναφορά πριν τον κάνετε CC.
 
-Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example:
+Μερικές φορές, δεν μπορεί να επιτευχθεί λύση. Το εν λόγω άτομο μπορεί να γίνει επιθετικό ή εχθρικό όταν έρθει αντιμέτωπο ή δεν αλλάζει τη συμπεριφορά του. Σε αυτή την περίπτωση, μπορεί να θέλετε να εξετάσετε το ενδεχόμενο να αναλάβετε ισχυρότερη δράση. Για παράδειγμα:
 
-* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project
+* **Αποβολή του εν λόγω ατόμου** από το πρότζεκτ, με προσωρινή απαγόρευση συμμετοχής σε οποιαδήποτε πτυχή του πρότζεκτ.
 
-* **Permanently ban** the person from the project
+* **Μόνιμος αποκλεισμός** του ατόμου από το πρότζεκτ
 
-Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached.
+Ο αποκλεισμός μελών δεν πρέπει να λαμβάνεται ελαφρά τη καρδία και αντιπροσωπεύει μια μόνιμη και αγεφύρωτη διαφορά απόψεων. Θα πρέπει να λαμβάνετε αυτά τα μέτρα μόνο όταν είναι σαφές ότι δεν μπορεί να επιτευχθεί λύση.
 
-## Your responsibilities as a maintainer
+## Οι ευθύνες σας ως συντηρητής
 
-A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes.
+Ένας κώδικας συμπεριφοράς δεν είναι ένας νόμος που επιβάλλεται αυθαίρετα. Εσείς είστε ο εφαρμοστής του κώδικα δεοντολογίας και είναι δική σας ευθύνη να ακολουθείτε τους κανόνες που θεσπίζει ο κώδικας δεοντολογίας.
 
-As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community.
+Ως συντηρητής θεσπίζετε τις κατευθυντήριες γραμμές για την κοινότητά σας και επιβάλλετε αυτές τις κατευθυντήριες γραμμές σύμφωνα με τους κανόνες που ορίζονται στον κώδικα συμπεριφοράς σας. Αυτό σημαίνει ότι λαμβάνετε σοβαρά υπόψη κάθε αναφορά για παραβίαση του κώδικα συμπεριφοράς. Ο καταγγέλλων οφείλει να εξετάσει διεξοδικά και δίκαια την καταγγελία του. Εάν διαπιστώσετε ότι η συμπεριφορά που ανέφεραν δεν αποτελεί παραβίαση, επικοινωνήστε το με σαφήνεια σε αυτούς και εξηγήστε τους γιατί δεν πρόκειται να λάβετε μέτρα γι' αυτό. Το τι θα κάνουν με αυτό εξαρτάται από αυτούς: να ανεχθούν τη συμπεριφορά με την οποία είχαν πρόβλημα ή να σταματήσουν να συμμετέχουν στην κοινότητα.
 
-A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable.
+Μια αναφορά συμπεριφοράς που _τεχνικά_ δεν παραβιάζει τον κώδικα συμπεριφοράς μπορεί να υποδεικνύει ότι υπάρχει πρόβλημα στην κοινότητά σας, και θα πρέπει να διερευνήσετε αυτό το πιθανό πρόβλημα και να ενεργήσετε αναλόγως. Αυτό μπορεί να περιλαμβάνει την αναθεώρηση του κώδικα συμπεριφοράς σας για να αποσαφηνίσετε την αποδεκτή συμπεριφορά ή/και να μιλήσετε με το άτομο του οποίου η συμπεριφορά αναφέρθηκε και να του πείτε ότι, ενώ δεν παραβίασε τον κώδικα συμπεριφοράς, παρακάμπτει τα όρια του αναμενόμενου και κάνει ορισμένους συμμετέχοντες να αισθάνονται άβολα.
 
-In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way.
+Τελικά, ως συντηρητής, εσείς θέτετε και επιβάλλετε τα πρότυπα αποδεκτής συμπεριφοράς. Έχετε τη δυνατότητα να διαμορφώσετε τις αξίες της κοινότητας του πρότζεκτ και οι συμμετέχοντες περιμένουν από εσάς να επιβάλλετε αυτές τις αξίες με δίκαιο και ισορροπημένο τρόπο.
 
-## Encourage the behavior you want to see in the world 🌎
+## Ενθαρρύνετε τη συμπεριφορά που θέλετε να δείτε στον κόσμο 🌎
 
-When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow.
+Όταν ένα πρότζεκτ φαίνεται εχθρικό ή μη φιλόξενο, ακόμη και αν πρόκειται για ένα μόνο άτομο του οποίου η συμπεριφορά είναι ανεκτή από τους άλλους, κινδυνεύετε να χάσετε πολλούς ακόμη συνεισφέροντες, μερικούς από τους οποίους μπορεί να μην συναντήσετε ποτέ. Δεν είναι πάντα εύκολο να υιοθετήσετε ή να επιβάλλετε έναν κώδικα συμπεριφοράς, αλλά η καλλιέργεια ενός φιλόξενου περιβάλλοντος θα βοηθήσει την κοινότητά σας να αναπτυχθεί.

From 0426411fab87e115c19d200bc51208b153337250 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Sun, 15 May 2022 15:36:54 +0300
Subject: [PATCH 351/749] Translate finding-users.md

---
 _articles/el/finding-users.md | 114 +++++++++++++++++-----------------
 1 file changed, 57 insertions(+), 57 deletions(-)

diff --git a/_articles/el/finding-users.md b/_articles/el/finding-users.md
index a7a4cb3226f..68cf2ef2af0 100644
--- a/_articles/el/finding-users.md
+++ b/_articles/el/finding-users.md
@@ -10,147 +10,147 @@ related:
   - building
 ---
 
-## Spreading the word
+## Διαδίδοντας τη λέξη
 
-There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work!
+Δεν υπάρχει κανένας κανόνας που να λέει ότι πρέπει να προωθήσετε ένα πρότζεκτ ανοιχτού κώδικα όταν το ξεκινάτε. Υπάρχουν πολλοί ικανοποιητικοί λόγοι για να εργαστείτε στον ανοιχτό κώδικα που δεν έχουν καμία σχέση με τη δημοτικότητα. Αντί να ελπίζετε ότι άλλοι θα βρουν και θα χρησιμοποιήσουν το πρότζεκτ σας ανοιχτού κώδικα, πρέπει να διαδώσετε τη σκληρή δουλειά σας!
 
-## Figure out your message
+## Βρείτε το μήνυμά σας
 
-Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters.
+Πριν ξεκινήσετε την πραγματική εργασία προώθησης του πρότζεκτ σας, θα πρέπει να είστε σε θέση να εξηγήσετε τι κάνει και γιατί έχει σημασία.
 
-What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance.
+Τι κάνει το πρότζεκτ σας διαφορετικό ή ενδιαφέρον; Γιατί το δημιουργήσατε; Η απάντηση αυτών των ερωτημάτων για τον εαυτό σας θα σας βοηθήσει να επικοινωνήσετε τη σημασία του πρότζεκτ σας.
 
-Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want.
+Να θυμάστε ότι οι άνθρωποι εμπλέκονται ως χρήστες και τελικά γίνονται συνεισφέροντες, επειδή το πρότζεκτ σας λύνει ένα πρόβλημα γι' αυτούς. Καθώς σκέφτεστε το μήνυμα και την αξία του πρότζεκτ σας, προσπαθήστε να τα δείτε μέσα από το πρίσμα του τι μπορεί να θέλουν οι _χρήστες και οι συνεισφέροντες_.
 
-For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
+Για παράδειγμα, ο @robb χρησιμοποιεί παραδείγματα κώδικα για να επικοινωνήσει με σαφήνεια γιατί το πρότζεκτ του, [Cartography](https://github.com/robb/Cartography), είναι χρήσιμο:
 
 ![Cartography README](/assets/images/finding-users/cartography.jpg)
 
-For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+Για μια βαθύτερη εμβάθυνση στην ανταλλαγή μηνυμάτων, δείτε την άσκηση ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) της Mozilla για την ανάπτυξη προσωπικοτήτων χρηστών.
 
-## Help people find and follow your project
+## Βοηθήστε τους ανθρώπους να βρουν και να ακολουθήσουν το πρότζεκτ σας
 
 <aside markdown="1" class="pquote">
-  You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
+  Ιδανικά χρειάζεστε μια ενιαία "αρχική" διεύθυνση URL που μπορείτε να προωθήσετε και να υποδείξετε στους ανθρώπους σε σχέση με το πρότζεκτ σας. Δεν χρειάζεται να ξοδέψετε πολλά χρήματα σε ένα φανταχτερό πρότυπο ή ακόμη και σε ένα όνομα τομέα, αλλά το πρότζεκτ σας χρειάζεται ένα σημείο εστίασης.
   <p markdown="1" class="pquote-credit">
-— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+- Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
   </p>
 </aside>
 
-Help people find and remember your project by pointing them to a single namespace.
+Βοηθήστε τους ανθρώπους να βρουν και να θυμούνται το πρότζεκτ σας, δείχνοντάς τους ένα ενιαίο χώρο ονομάτων.
 
-**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.
+**Να έχετε ένα ξεκάθαρο χειριστήριο για να προωθήσετε το πρότζεκτ σας.** Ένα χειριστήριο στο Twitter, μια διεύθυνση URL στο GitHub ή ένα κανάλι IRC είναι ένας εύκολος τρόπος για να δείξετε στους ανθρώπους το πρότζεκτ σας. Αυτές οι διέξοδοι δίνουν επίσης στην αναπτυσσόμενη κοινότητα του πρότζεκτ σας ένα μέρος για να συγκεντρώνεται.
 
-If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. 
+Αν δεν επιθυμείτε να δημιουργήσετε ακόμη διεξόδους για το πρότζεκτ σας, προωθήστε τη δική σας λαβή Twitter ή GitHub σε ό,τι κάνετε. Η προώθηση της λαβής σας στο Twitter ή το GitHub θα ενημερώσει τους ανθρώπους για το πώς μπορούν να επικοινωνήσουν μαζί σας ή να παρακολουθήσουν το πρότζεκτ σας. Αν μιλήσετε σε μια συνάντηση ή εκδήλωση, βεβαιωθείτε ότι τα στοιχεία επικοινωνίας σας περιλαμβάνονται στο βιογραφικό σας ή στις διαφάνειές σας. 
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
-  A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project.
+  Ένα λάθος που έκανα εκείνες τις πρώτες μέρες (...) ήταν ότι δεν ξεκίνησα λογαριασμό στο Twitter για το πρότζεκτ. Το Twitter είναι ένας πολύ καλός τρόπος για να κρατάς τους ανθρώπους ενήμερους για ένα πρότζεκτ καθώς και να εκθέτεις συνεχώς τους ανθρώπους στο πρότζεκτ.
   <p markdown="1" class="pquote-credit">
-— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+- @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
   </p>
 </aside>
 
-**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project.
+**Σκεφτείτε να δημιουργήσετε έναν ιστότοπο για το πρότζεκτ σας.** Ένας ιστότοπος κάνει το πρότζεκτ σας πιο φιλικό και πιο εύκολο στην πλοήγηση, ειδικά όταν συνδυάζεται με σαφή τεκμηρίωση και σεμινάρια. Η ύπαρξη ιστότοπου υποδηλώνει επίσης ότι το πρότζεκτ σας είναι ενεργό, γεγονός που θα κάνει το κοινό σας να αισθάνεται πιο άνετα στη χρήση του. Παρέχετε παραδείγματα για να δώσετε στους ανθρώπους ιδέες για το πώς να χρησιμοποιήσουν το πρότζεκτ σας.
 
-[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_.
+Ο [@adrianholovaty](https://news.ycombinator.com/item?id=7531689), συνδημιουργός του Django, δήλωσε ότι ένας ιστότοπος ήταν _"μακράν το καλύτερο πράγμα που κάναμε με το Django τις πρώτες μέρες"_.
 
-If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+Αν το πρότζεκτ σας φιλοξενείται στο GitHub, μπορείτε να χρησιμοποιήσετε το [GitHub Pages](https://pages.github.com/) για να φτιάξετε εύκολα έναν ιστότοπο. Το [Yeoman](http://yeoman.io/), το [Vagrant](https://www.vagrantup.com/) και το [Middleman](https://middlemanapp.com/) είναι [μερικά παραδείγματα](https://github.com/showcases/github-pages-examples) εξαιρετικών, ολοκληρωμένων ιστοσελίδων.
 
-![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
+![Αρχική σελίδα του Vagrant](/assets/images/finding-users/vagrant_homepage.png)
 
-Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!
+Τώρα που έχετε ένα μήνυμα για το πρότζεκτ σας και έναν εύκολο τρόπο για να βρουν οι άνθρωποι το πρότζεκτ σας, ας βγούμε εκεί έξω και ας μιλήσουμε στο κοινό σας!
 
-## Go where your project's audience is (online)
+## Πηγαίνετε εκεί όπου βρίσκεται το κοινό του πρότζεκτ σας (online)
 
-Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
+Η διαδικτυακή προβολή είναι ένας πολύ καλός τρόπος για να μοιραστείτε και να διαδώσετε το μήνυμα γρήγορα. Χρησιμοποιώντας διαδικτυακά κανάλια, έχετε τη δυνατότητα να προσεγγίσετε ένα πολύ ευρύ κοινό.
 
-Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+Εκμεταλλευτείτε τις υπάρχουσες διαδικτυακές κοινότητες και πλατφόρμες για να προσεγγίσετε το κοινό σας. Εάν το πρότζεκτ σας ανοικτού κώδικα είναι ένα πρότζεκτ λογισμικού, μπορείτε πιθανώς να βρείτε το κοινό σας στο [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/) ή [Quora](https://www.quora.com/). Βρείτε τα κανάλια στα οποία πιστεύετε ότι οι άνθρωποι θα επωφεληθούν περισσότερο ή θα ενθουσιαστούν με το πρότζεκτ σας.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
-  Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project.
+  Κάθε πρόγραμμα έχει πολύ συγκεκριμένες λειτουργίες που μόνο ένα κλάσμα των χρηστών θα βρει χρήσιμες. Μην κάνετε spam σε όσο το δυνατόν περισσότερους ανθρώπους. Αντίθετα, στοχεύστε τις προσπάθειές σας σε κοινότητες που θα επωφεληθούν από τη γνώση του προγράμματός σας.
   <p markdown="1" class="pquote-credit">
-— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+- @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
   </p>
 </aside>
 
-See if you can find ways to share your project in relevant ways:
+Δείτε αν μπορείτε να βρείτε τρόπους να μοιραστείτε το πρότζεκτ σας με σχετικούς τρόπους:
 
-* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.
-* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.
-* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work.
+* **Γνωρίστε σχετικά έργα και κοινότητες ανοικτού κώδικα.** Μερικές φορές, δεν χρειάζεται να προωθήσετε άμεσα το πρότζεκτ σας. Αν το πρότζεκτ σας είναι ιδανικό για επιστήμονες δεδομένων που χρησιμοποιούν Python, γνωρίστε την κοινότητα επιστήμης δεδομένων Python. Καθώς οι άνθρωποι θα σας γνωρίζουν, θα προκύψουν φυσικές ευκαιρίες για να μιλήσετε και να μοιραστείτε το πρότζεκτ σας.
+* **Βρείτε ανθρώπους που αντιμετωπίζουν το πρόβλημα που λύνει το πρότζεκτ σας.** Ψάξτε σε σχετικά φόρουμ για ανθρώπους που ανήκουν στο κοινό-στόχο του πρότζεκτ σας. Απαντήστε στην ερώτησή τους και βρείτε έναν διακριτικό τρόπο, όταν χρειάζεται, να προτείνετε το πρότζεκτ σας ως λύση.
+* **Ζητήστε ανατροφοδότηση.** Παρουσιάστε τον εαυτό σας και το πρότζεκτ σας σε ένα κοινό που θα το βρει σχετικό και ενδιαφέρον. Να είστε συγκεκριμένοι σχετικά με το ποιος πιστεύετε ότι θα επωφεληθεί από το πρότζεκτ σας. Προσπαθήστε να ολοκληρώσετε την πρόταση: _"Νομίζω ότι το πρότζεκτ μου θα βοηθούσε πραγματικά τον Χ, ο οποίος προσπαθεί να κάνει Υ_". Ακούστε και απαντήστε στα σχόλια των άλλων, αντί να προωθείτε απλώς το πρότζεκτ σας.
 
-Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want.
+Σε γενικές γραμμές, επικεντρωθείτε στο να βοηθάτε τους άλλους προτού ζητήσετε πράγματα σε αντάλλαγμα. Επειδή ο καθένας μπορεί εύκολα να προωθήσει ένα πρότζεκτ στο διαδίκτυο, θα υπάρχει πολύς θόρυβος. Για να ξεχωρίσετε από το πλήθος, δώστε στους ανθρώπους το πλαίσιο για το ποιοι είστε και όχι απλώς τι θέλετε.
 
-If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication.
+Αν κανείς δεν δώσει σημασία ή δεν ανταποκριθεί στην αρχική σας προβολή, μην αποθαρρύνεστε! Οι περισσότερες εκκινήσεις έργων είναι μια επαναληπτική διαδικασία που μπορεί να διαρκέσει μήνες ή και χρόνια. Αν δεν έχετε ανταπόκριση με την πρώτη φορά, δοκιμάστε μια διαφορετική τακτική ή αναζητήστε πρώτα τρόπους να προσθέσετε αξία στο πρότζεκτ άλλων. Η προώθηση και η έναρξη του πρότζεκτ σας απαιτεί χρόνο και αφοσίωση.
 
-## Go where your project's audience is (offline)
+## Πηγαίνετε εκεί όπου βρίσκεται το κοινό του πρότζεκτ σας (εκτός σύνδεσης)
 
-![Public speaking](/assets/images/finding-users/public_speaking.jpg)
+![Δημόσια ομιλία](/assets/images/finding-users/public_speaking.jpg)
 
-Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.
+Οι offline εκδηλώσεις είναι ένας δημοφιλής τρόπος για την προώθηση νέων έργων στο κοινό. Είναι ένας πολύ καλός τρόπος για να προσεγγίσετε ένα αφοσιωμένο κοινό και να οικοδομήσετε βαθύτερες ανθρώπινες σχέσεις, ειδικά αν ενδιαφέρεστε να προσεγγίσετε προγραμματιστές.
 
-If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.
+Αν είστε [νέος στη δημόσια ομιλία](https://speaking.io/), ξεκινήστε βρίσκοντας μια τοπική συνάντηση που σχετίζεται με τη γλώσσα ή το οικοσύστημα του πρότζεκτ σας.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
-  I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
+  Ήμουν αρκετά αγχωμένος που θα πήγαινα στο PyCon. Θα έδινα μια ομιλία, θα γνώριζα μόνο μερικούς ανθρώπους εκεί, θα πήγαινα για μια ολόκληρη εβδομάδα. (...) Δεν έπρεπε να ανησυχώ, όμως. Το PyCon ήταν εκπληκτικά φοβερό! (...) Όλοι ήταν απίστευτα φιλικοί και εξωστρεφείς, τόσο πολύ που σπάνια έβρισκα χρόνο να μην μιλήσω με τους ανθρώπους!
   <p markdown="1" class="pquote-credit">
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+- @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
   </p>
 </aside>
 
-If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.
+Αν δεν έχετε ξαναμιλήσει ποτέ σε εκδήλωση, είναι απολύτως φυσιολογικό να αισθάνεστε νευρικοί! Να θυμάστε ότι το κοινό σας είναι εκεί επειδή θέλει πραγματικά να ακούσει για τη δουλειά σας.
 
-As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.
+Καθώς γράφετε την ομιλία σας, επικεντρωθείτε σε αυτό που το ακροατήριό σας θα βρει ενδιαφέρον και θα έχει αξία. Κρατήστε τη γλώσσα σας φιλική και προσιτή. Χαμογελάστε, αναπνεύστε και διασκεδάστε.
 
 <aside markdown="1" class="pquote">
   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
-  When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+  Όταν αρχίζετε να γράφετε την ομιλία σας, ανεξάρτητα από το θέμα σας, μπορεί να σας βοηθήσει αν δείτε την ομιλία σας ως μια ιστορία που θα αφηγηθείτε στους ανθρώπους.
   <p markdown="1" class="pquote-credit">
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+- Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
   </p>
 </aside>
 
-When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.
+Όταν νιώσετε έτοιμοι, σκεφτείτε να μιλήσετε σε ένα συνέδριο για να προωθήσετε το πρότζεκτ σας. Τα συνέδρια μπορούν να σας βοηθήσουν να προσεγγίσετε περισσότερους ανθρώπους, μερικές φορές από όλο τον κόσμο.
 
-Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers.
+Αναζητήστε συνέδρια που είναι ειδικά για τη γλώσσα ή το οικοσύστημά σας. Πριν υποβάλετε την ομιλία σας, ερευνήστε το συνέδριο για να προσαρμόσετε την ομιλία σας στους συμμετέχοντες και να αυξήσετε τις πιθανότητες να γίνετε δεκτοί να μιλήσετε στο συνέδριο. Συχνά μπορείτε να πάρετε μια ιδέα για το ακροατήριό σας κοιτάζοντας τους ομιλητές ενός συνεδρίου.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
-  I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?
+  Έγραψα πολύ ωραία στους ανθρώπους της JSConf και τους παρακάλεσα να μου δώσουν μια θέση όπου θα μπορούσα να το παρουσιάσω στην JSConf EU. (...) Ήμουν εξαιρετικά φοβισμένος, παρουσιάζοντας αυτό το πράγμα πάνω στο οποίο δούλευα έξι μήνες. (...) Όλη την ώρα σκεφτόμουν, ω Θεέ μου. Τι κάνω εδώ;
   <p markdown="1" class="pquote-credit">
-— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+- @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
   </p>
 </aside>
 
-## Build a reputation
+## Δημιουργήστε μια φήμη
 
-In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.
+Εκτός από τις στρατηγικές που περιγράφονται παραπάνω, ο καλύτερος τρόπος για να προσκαλέσετε τους ανθρώπους να μοιραστούν και να συνεισφέρουν στο πρότζεκτ σας είναι να μοιραστείτε και να συνεισφέρετε στα έργα τους.
 
-Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships.
+Βοηθώντας τους νεοεισερχόμενους, μοιράζοντας πόρους και κάνοντας προσεγμένες συνεισφορές στα έργα των άλλων θα σας βοηθήσουν να χτίσετε μια θετική φήμη. Το να είστε ενεργό μέλος της κοινότητας ανοικτού κώδικα θα βοηθήσει τους ανθρώπους να έχουν πλαίσιο για το πρότζεκτ σας και θα είναι πιο πιθανό να δώσουν προσοχή και να μοιραστούν το πρότζεκτ σας. Η ανάπτυξη σχέσεων με άλλα έργα ανοικτού κώδικα μπορεί να οδηγήσει ακόμη και σε επίσημες συνεργασίες.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
-  The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+  Ο μόνος λόγος για τον οποίο η urllib3 είναι η πιο δημοφιλής βιβλιοθήκη τρίτου μέρους της Python σήμερα είναι επειδή αποτελεί μέρος των requests.
   <p markdown="1" class="pquote-credit">
-— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+- @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
   </p>
 </aside>
 
-It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others.
+Ποτέ δεν είναι πολύ νωρίς ή πολύ αργά για να αρχίσετε να χτίζετε τη φήμη σας. Ακόμα και αν έχετε ήδη ξεκινήσει το δικό σας πρότζεκτ, συνεχίστε να αναζητάτε τρόπους για να βοηθήσετε τους άλλους.
 
-There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.
+Δεν υπάρχει λύση από τη μια μέρα στην άλλη για να χτίσετε ένα κοινό. Το να κερδίσετε την εμπιστοσύνη και τον σεβασμό των άλλων χρειάζεται χρόνο, και το χτίσιμο της φήμης σας δεν τελειώνει ποτέ.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it.
+  Το PhantomJS κυκλοφόρησε για πρώτη φορά στις αρχές του 2011. (...) Διέδωσα την είδηση με τους συνήθεις τρόπους: Έκανα tweet γι' αυτό, έγραψα αναρτήσεις σε blog για πράγματα που μπορούσατε να κάνετε με αυτό, το ανέφερα κατά τη διάρκεια διαφόρων συζητήσεων σε συναντήσεις. Όταν έγινε πιο γνωστό το 2014, άρχισα να κάνω παρουσιάσεις γι' αυτό.
   <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
+- @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
   </p>
 </aside>
 
-## Keep at it!
+## Συνεχίστε!
 
-It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.
+Μπορεί να χρειαστεί πολύς χρόνος μέχρι οι άνθρωποι να παρατηρήσουν το πρότζεκτ σας ανοιχτού κώδικα. Αυτό δεν πειράζει! Μερικά από τα πιο δημοφιλή έργα σήμερα χρειάστηκαν χρόνια για να φτάσουν σε υψηλά επίπεδα δραστηριότητας. Επικεντρωθείτε στην οικοδόμηση σχέσεων αντί να ελπίζετε ότι το πρότζεκτ σας θα αποκτήσει αυθόρμητα δημοτικότητα. Κάντε υπομονή και συνεχίστε να μοιράζεστε το πρότζεκτ σας με όσους το εκτιμούν.

From f6199f3fd8a57005e714680c13d49aa65dafff4a Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Sun, 15 May 2022 15:50:07 +0300
Subject: [PATCH 352/749] Translate getting-paid.md

---
 _articles/el/getting-paid.md | 164 +++++++++++++++++------------------
 1 file changed, 82 insertions(+), 82 deletions(-)

diff --git a/_articles/el/getting-paid.md b/_articles/el/getting-paid.md
index 728a6374c6c..39ccf014269 100644
--- a/_articles/el/getting-paid.md
+++ b/_articles/el/getting-paid.md
@@ -1,7 +1,7 @@
 ---
 lang: el
 title: Λαμβάνοντας Αμοιβή για Συνεισφορά Ανοιχτού Κώδικα
-description: Διατηρήστε το έργο σας στον ανοιχτό κώδικα λαμβάνοντας οικονομική υποστήριξη για τον χρόνο σας ή το πρότζεκτ σας.
+description: Διατηρήστε το πρότζεκτ σας στον ανοιχτό κώδικα λαμβάνοντας οικονομική υποστήριξη για τον χρόνο σας ή το πρότζεκτ σας.
 class: getting-paid
 order: 7
 image: /assets/images/cards/getting-paid.png
@@ -10,178 +10,178 @@ related:
   - leadership
 ---
 
-## Why some people seek financial support
+## Γιατί κάποιοι άνθρωποι ζητούν οικονομική στήριξη
 
-Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+Μεγάλο μέρος του πρότζεκτ του ανοικτού κώδικα είναι εθελοντικό. Για παράδειγμα, κάποιος μπορεί να συναντήσει ένα σφάλμα σε ένα πρότζεκτ που χρησιμοποιεί και να υποβάλει μια γρήγορη διόρθωση, ή μπορεί να του αρέσει να ασχολείται με ένα πρότζεκτ ανοιχτού κώδικα στον ελεύθερο χρόνο του.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
-I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+Έψαχνα για ένα "χόμπι" προγραμματισμού που θα με απασχολούσε κατά τη διάρκεια της εβδομάδας γύρω από τα Χριστούγεννα. (...) Είχα έναν υπολογιστή στο σπίτι και όχι πολλά άλλα πράγματα στα χέρια μου. Αποφάσισα να γράψω έναν διερμηνέα για τη νέα γλώσσα σεναρίων που σκεφτόμουν τελευταία. (...) Επέλεξα την Python ως τίτλο εργασίας.
   <p markdown="1" class="pquote-credit">
-— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+- @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
   </p>
 </aside>
 
-There are many reasons why a person would not want to be paid for their open source work.
+Υπάρχουν πολλοί λόγοι για τους οποίους ένα άτομο δεν θα ήθελε να πληρωθεί για την εργασία του στον ανοικτό κώδικα.
 
-* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
-* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
-* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+* **Μπορεί να έχουν ήδη μια δουλειά πλήρους απασχόλησης που αγαπούν,** η οποία τους επιτρέπει να συνεισφέρουν στον ανοιχτό κώδικα στον ελεύθερο χρόνο τους.
+* **Απολαμβάνουν να σκέφτονται τον ανοιχτό κώδικα ως χόμπι** ή ως δημιουργική απόδραση και δεν θέλουν να αισθάνονται οικονομικά υποχρεωμένοι να εργάζονται στα έργα τους.
+* **Αποκομίζουν άλλα οφέλη από τη συνεισφορά τους στον ανοικτό κώδικα,** όπως η δημιουργία της φήμης τους ή του χαρτοφυλακίου τους, η εκμάθηση μιας νέας δεξιότητας ή το αίσθημα ότι βρίσκονται πιο κοντά σε μια κοινότητα.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
-  Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+  Οι οικονομικές δωρεές προσθέτουν ένα αίσθημα ευθύνης, για κάποιους. (...) Είναι σημαντικό για εμάς, στον παγκοσμίως συνδεδεμένο, γρήγορο κόσμο που ζούμε, να μπορούμε να πούμε "όχι τώρα, έχω όρεξη να κάνω κάτι εντελώς διαφορετικό".
   <p markdown="1" class="pquote-credit">
-— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+- @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
   </p>
 </aside>
 
-For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+Για άλλους, ειδικά όταν οι συνεισφορές είναι συνεχείς ή απαιτούν σημαντικό χρόνο, το να πληρώνονται για να συνεισφέρουν στον ανοιχτό κώδικα είναι ο μόνος τρόπος που μπορούν να συμμετέχουν, είτε επειδή το απαιτεί το πρότζεκτ, είτε για προσωπικούς λόγους.
 
-Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
+Η συντήρηση δημοφιλών έργων μπορεί να αποτελεί σημαντική ευθύνη, καταλαμβάνοντας 10 ή 20 ώρες την εβδομάδα αντί για λίγες ώρες το μήνα.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
-  Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+  Ρωτήστε οποιονδήποτε συντηρητή πρότζεκτ ανοιχτού κώδικα και θα σας πει για την πραγματικότητα του όγκου εργασίας που απαιτείται για τη διαχείριση ενός πρότζεκτ. Έχετε πελάτες. Διορθώνετε προβλήματα γι' αυτούς. Δημιουργείτε νέα χαρακτηριστικά. Αυτό γίνεται μια πραγματική απαίτηση για το χρόνο σας.
   <p markdown="1" class="pquote-credit">
-— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+- @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
   </p>
 </aside>
 
-Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+Η αμειβόμενη εργασία δίνει επίσης τη δυνατότητα σε ανθρώπους από διαφορετικά κοινωνικά στρώματα να συνεισφέρουν ουσιαστικά. Ορισμένοι άνθρωποι δεν έχουν την οικονομική δυνατότητα να αφιερώσουν απλήρωτο χρόνο σε έργα ανοικτού κώδικα, με βάση την τρέχουσα οικονομική τους κατάσταση, τα χρέη τους ή τις οικογενειακές ή άλλες υποχρεώσεις φροντίδας. Αυτό σημαίνει ότι ο κόσμος δεν βλέπει ποτέ συνεισφορές από ταλαντούχους ανθρώπους που δεν έχουν την οικονομική δυνατότητα να προσφέρουν εθελοντικά τον χρόνο τους. Αυτό έχει ηθικές επιπτώσεις, όπως [έχει περιγράψει](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) ο @ashedryden, καθώς η εργασία που γίνεται μεροληπτεί υπέρ εκείνων που έχουν ήδη πλεονεκτήματα στη ζωή τους, οι οποίοι στη συνέχεια αποκτούν πρόσθετα πλεονεκτήματα με βάση τις εθελοντικές συνεισφορές τους, ενώ άλλοι που δεν είναι σε θέση να προσφέρουν εθελοντικά, τότε δεν παίρνουν αργότερα ευκαιρίες, γεγονός που ενισχύει την τρέχουσα έλλειψη ποικιλομορφίας στην κοινότητα ανοιχτού κώδικα.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
-   OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+   Ο OSS αποφέρει τεράστια οφέλη στην τεχνολογική βιομηχανία, τα οποία με τη σειρά τους σημαίνουν οφέλη για όλες τις βιομηχανίες. (...) Ωστόσο, αν οι μόνοι που μπορούν να εστιάσουν σε αυτό είναι οι τυχεροί και οι εμμονικοί, τότε υπάρχει ένα τεράστιο ανεκμετάλλευτο δυναμικό.
   <p markdown="1" class="pquote-credit">
-— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+- @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
   </p>
 </aside>
 
-If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+Εάν αναζητάτε οικονομική στήριξη, υπάρχουν δύο τρόποι που μπορείτε να εξετάσετε. Μπορείτε να χρηματοδοτήσετε το χρόνο σας ως συνεργάτης, ή μπορείτε να βρείτε οργανωτική χρηματοδότηση για το πρότζεκτ.
 
-## Funding your own time
+## Χρηματοδότηση του χρόνου σας
 
-Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+Σήμερα, πολλοί άνθρωποι αμείβονται για να εργάζονται με μερική ή πλήρη απασχόληση στον ανοικτό κώδικα. Ο πιο συνηθισμένος τρόπος για να πληρωθείτε για το χρόνο σας είναι να μιλήσετε με τον εργοδότη σας.
 
-It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+Είναι πιο εύκολο να υποστηρίξετε την εργασία σε ανοιχτό κώδικα αν ο εργοδότης σας χρησιμοποιεί πραγματικά το πρότζεκτ, αλλά γίνετε δημιουργικοί με την προσφορά σας. Ίσως ο εργοδότης σας δεν χρησιμοποιεί το πρότζεκτ, αλλά χρησιμοποιεί την Python, και η διατήρηση ενός δημοφιλούς πρότζεκτ Python συμβάλλει στην προσέλκυση νέων προγραμματιστών Python. Ίσως αυτό κάνει τον εργοδότη σας να φαίνεται γενικά πιο φιλικός προς τους προγραμματιστές.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.
+  Όπως πολλοί στον τομέα του ανοιχτού κώδικα, πάλευα με το βάρος της συντήρησης ενός πρότζεκτ. Όταν πρωτοξεκίνησα να ασχολούμαι με τον ανοιχτό κώδικα, συνήθιζα να μένω μέχρι αργά για να δουλέψω πάνω σε αυτό ή αμέσως μόλις γύριζα σπίτι. (...) Μπόρεσα να συζητήσω με το αφεντικό μου τα ζητήματα που αντιμετώπιζα και σκεφτήκαμε ιδέες για το πώς θα μπορούσαμε να ενσωματώσουμε εργασίες ανοιχτού κώδικα, δεδομένης της δικής μας χρήσης της Babel.
   <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
+- @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
   </p>
 </aside>
 
-If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+Αν δεν έχετε κάποιο υπάρχον πρότζεκτ ανοικτού κώδικα στο οποίο θα θέλατε να εργαστείτε, αλλά θα προτιμούσατε να είναι ανοικτού κώδικα το τρέχον αποτέλεσμα της δουλειάς σας, κάντε μια πρόταση στον εργοδότη σας να ανοίξει κάποιο από τα εσωτερικά του λογισμικά.
 
-Many companies are developing open source programs to build their brand and recruit quality talent.
+Πολλές εταιρείες αναπτύσσουν προγράμματα ανοικτού κώδικα για να χτίσουν το εμπορικό τους σήμα και να προσλάβουν ποιοτικά ταλέντα.
 
-@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+Η @hueniverse, για παράδειγμα, διαπίστωσε ότι υπάρχουν οικονομικοί λόγοι που δικαιολογούν [την επένδυση της Walmart στον ανοικτό κώδικα](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Και ο @jamesgpearce διαπίστωσε ότι το πρόγραμμα ανοικτού κώδικα του Facebook [έκανε τη διαφορά](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) στην πρόσληψη προσωπικού:
 
-> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+> Είναι στενά ευθυγραμμισμένο με την κουλτούρα μας ως χάκερ και με το πώς αντιλαμβανόταν ο οργανισμός μας. Ρωτήσαμε τους υπαλλήλους μας: "Γνωρίζατε το πρόγραμμα λογισμικού ανοικτού κώδικα στο Facebook;". Τα δύο τρίτα απάντησαν "Ναι". Οι μισοί δήλωσαν ότι το πρόγραμμα συνέβαλε θετικά στην απόφασή τους να εργαστούν σε εμάς. Αυτά δεν είναι οριακά νούμερα, και ελπίζω, μια τάση που συνεχίζεται.
 
-If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+Εάν η εταιρεία σας ακολουθήσει αυτόν τον δρόμο, είναι σημαντικό να διατηρήσετε σαφή τα όρια μεταξύ της κοινοτικής και της εταιρικής δραστηριότητας. Τελικά, ο ανοιχτός κώδικας συντηρείται μέσω των συνεισφορών ανθρώπων από όλο τον κόσμο, και αυτό είναι μεγαλύτερο από οποιαδήποτε εταιρεία ή τοποθεσία.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
-  Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+  Το να πληρώνεσαι για να δουλεύεις πάνω στον ανοιχτό κώδικα είναι μια σπάνια και θαυμάσια ευκαιρία, αλλά δεν θα πρέπει να εγκαταλείψεις το πάθος σου στη διαδικασία. Το πάθος σας θα πρέπει να είναι ο λόγος για τον οποίο οι εταιρείες θέλουν να σας πληρώσουν.
   <p markdown="1" class="pquote-credit">
-— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+- @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
   </p>
 </aside>
 
-If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+Αν δεν μπορείτε να πείσετε τον σημερινό σας εργοδότη να δώσει προτεραιότητα στην εργασία ανοιχτού κώδικα, σκεφτείτε να βρείτε έναν νέο εργοδότη που ενθαρρύνει τις συνεισφορές των εργαζομένων στον ανοιχτό κώδικα. Αναζητήστε εταιρείες που καθιστούν ρητή την αφοσίωσή τους στην εργασία ανοικτού κώδικα. Για παράδειγμα:
 
-* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
-* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+* Ορισμένες εταιρείες, όπως η [Netflix](https://netflix.github.io/) ή η [PayPal](https://paypal.github.io/), διαθέτουν ιστότοπους που αναδεικνύουν τη συμμετοχή τους στον ανοικτό κώδικα.
+* Η [Zalando](https://opensource.zalando.com) δημοσίευσε την [πολιτική συνεισφοράς στον ανοικτό κώδικα](https://opensource.zalando.com/docs/using/contributing/) για τους υπαλλήλους της.
 
-Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+Έργα που ξεκίνησαν από μια μεγάλη εταιρεία, όπως το [Go](https://github.com/golang) ή το [React](https://github.com/facebook/react), είναι επίσης πιθανό να απασχολούν άτομα που εργάζονται στον ανοιχτό κώδικα.
 
-Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
+Ανάλογα με τις προσωπικές σας συνθήκες, μπορείτε να προσπαθήσετε να μαζέψετε χρήματα ανεξάρτητα για να χρηματοδοτήσετε την εργασία σας στον ανοικτό κώδικα. Για παράδειγμα:
 
-* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
-* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
-* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+* Το @Homebrew (και [πολλοί άλλοι συντηρητές και οργανισμοί](https://github.com/sponsors/community)) χρηματοδοτούν το πρότζεκτ τους μέσω του [GitHub Sponsors](https://github.com/sponsors)
+* Ο @gaearon χρηματοδότησε το πρότζεκτ του στο [Redux](https://github.com/reactjs/redux) μέσω μιας [Patreon crowdfunding campaign](https://redux.js.org/)
+* Ο @andrewgodwin χρηματοδότησε το πρότζεκτ του για τις μεταναστεύσεις σχημάτων Django [μέσω μιας καμπάνιας Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
-Finally, sometimes open source projects put bounties on issues that you might consider helping with.
+Τέλος, μερικές φορές τα έργα ανοικτού κώδικα προκηρύσσουν αμοιβές για θέματα που θα μπορούσατε να σκεφτείτε να βοηθήσετε.
 
-* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
-* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+* Ο @ConnorChristie μπόρεσε να πληρωθεί για [βοήθεια](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) Η @MARKETProtocol εργάζεται στη βιβλιοθήκη JavaScript [μέσω μιας επικήρυξης στο gitcoin](https://gitcoin.co/).
+* Η @mamiM έκανε μεταφράσεις στα ιαπωνικά για την @MetaMask μετά την [χρηματοδότηση του θέματος στο Bounties Network](https://explorer.bounties.network/bounty/134).
 
-## Finding funding for your project
+## Εύρεση χρηματοδότησης για το πρότζεκτ σας
 
-Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+Πέρα από τους διακανονισμούς για μεμονωμένους συνεισφέροντες, μερικές φορές τα έργα συγκεντρώνουν χρήματα από εταιρείες, ιδιώτες ή άλλους για τη χρηματοδότηση της τρέχουσας εργασίας.
 
-Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas.
+Η οργανωτική χρηματοδότηση μπορεί να προορίζεται για την πληρωμή των σημερινών συνεισφερόντων, την κάλυψη των εξόδων λειτουργίας του πρότζεκτ (όπως τα τέλη φιλοξενίας) ή την επένδυση σε νέα χαρακτηριστικά ή ιδέες.
 
-As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+Καθώς η δημοτικότητα του ανοικτού κώδικα αυξάνεται, η εξεύρεση χρηματοδότησης για έργα είναι ακόμη πειραματική, αλλά υπάρχουν μερικές κοινές επιλογές.
 
-### Raise money for your work through crowdfunding campaigns or sponsorships
+### Συγκεντρώστε χρήματα για το πρότζεκτ σας μέσω εκστρατειών crowdfunding ή χορηγιών
 
-Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
-A few examples of sponsored projects include:
+Η εξεύρεση χορηγιών λειτουργεί καλά αν έχετε ήδη ένα ισχυρό κοινό ή φήμη ή αν το πρότζεκτ σας είναι πολύ δημοφιλές.
+Μερικά παραδείγματα έργων με χορηγίες περιλαμβάνουν:
 
-* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803)
-* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+* **[webpack](https://github.com/webpack)** συγκεντρώνει χρήματα από εταιρείες και ιδιώτες [μέσω του OpenCollective](https://opencollective.com/webpack)
+* **[Vue](https://github.com/vuejs/vue)** χρηματοδοτείται [μέσω του Patreon](https://github.com/open-source/stories/yyx990803)
+* **[Ruby Together](https://rubytogether.org/),** ένας μη κερδοσκοπικός οργανισμός που πληρώνει για εργασίες στα [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), και άλλα έργα υποδομής Ruby
 
-### Create a revenue stream
+### Δημιουργία μιας ροής εσόδων
 
-Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+Ανάλογα με το πρότζεκτ σας, μπορεί να είστε σε θέση να χρεώνετε για εμπορική υποστήριξη, επιλογές φιλοξενίας ή πρόσθετα χαρακτηριστικά. Μερικά παραδείγματα περιλαμβάνουν:
 
-* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
-* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
-* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+* **[Sidekiq](https://github.com/mperham/sidekiq)** προσφέρει εκδόσεις επί πληρωμή για πρόσθετη υποστήριξη
+* **[Travis CI](https://github.com/travis-ci)** προσφέρει εκδόσεις επί πληρωμή του προϊόντος του
+* **[Ghost](https://github.com/TryGhost/Ghost)** είναι ένα μη κερδοσκοπικό ίδρυμα με επί πληρωμή υπηρεσία διαχείρισης
 
-Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+Ορισμένα δημοφιλή έργα, όπως το [npm](https://github.com/npm/cli) και το [Docker](https://github.com/docker/docker), συγκεντρώνουν ακόμη και επιχειρηματικά κεφάλαια για να υποστηρίξουν την επιχειρηματική τους ανάπτυξη.
 
-### Apply for grant funding
+### Υποβολή αίτησης για επιχορήγηση
 
-Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+Ορισμένα ιδρύματα λογισμικού και εταιρείες προσφέρουν επιχορηγήσεις για εργασίες ανοικτού κώδικα. Ορισμένες φορές, οι επιχορηγήσεις μπορούν να καταβληθούν σε ιδιώτες χωρίς τη δημιουργία νομικής οντότητας για το πρότζεκτ.
 
-* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
-* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
-* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
-* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+* **[Διαβάστε τα έγγραφα](https://github.com/rtfd/readthedocs.org)** έλαβε επιχορήγηση από την [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)** το πρότζεκτ χρηματοδοτήθηκε από το [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** έλαβε επιχορήγηση από το [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* Το **[Python Software Foundation](https://www.python.org/psf/grants/)** προσφέρει επιχορηγήσεις για εργασίες που σχετίζονται με την Python.
 
-For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+Για πιο λεπτομερείς επιλογές και μελέτες περιπτώσεων, ο @nayafia [έγραψε έναν οδηγό](https://github.com/nayafia/lemonade-stand) για να πληρωθείτε για εργασία ανοιχτού κώδικα. Διαφορετικοί τύποι χρηματοδότησης απαιτούν διαφορετικές δεξιότητες, οπότε λάβετε υπόψη τα δυνατά σας σημεία για να βρείτε ποια επιλογή σας ταιριάζει καλύτερα.
 
-## Building a case for financial support
+## Χτίζοντας μια υπόθεση για οικονομική υποστήριξη
 
-Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+Είτε το πρότζεκτ σας είναι μια νέα ιδέα, είτε υπάρχει εδώ και χρόνια, θα πρέπει να περιμένετε να βάλετε σημαντική σκέψη για να εντοπίσετε τον χρηματοδότη-στόχο σας και να παρουσιάσετε μια πειστική υπόθεση.
 
-Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+Είτε επιθυμείτε να πληρώσετε για τον δικό σας χρόνο, είτε να συγκεντρώσετε χρήματα για ένα πρότζεκτ, θα πρέπει να είστε σε θέση να απαντήσετε στις ακόλουθες ερωτήσεις.
 
-### Impact
+### Αντίκτυπος
 
-Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+Γιατί είναι χρήσιμο αυτό το πρότζεκτ; Γιατί αρέσει τόσο πολύ στους χρήστες σας ή στους δυνητικούς χρήστες; Πού θα βρίσκεται σε πέντε χρόνια;
 
-### Traction
+### Έλξη
 
-Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+Προσπαθήστε να συγκεντρώσετε αποδείξεις ότι το πρότζεκτ σας έχει σημασία, είτε πρόκειται για μετρήσεις, είτε για ανέκδοτα, είτε για μαρτυρίες. Υπάρχουν εταιρείες ή αξιόλογοι άνθρωποι που χρησιμοποιούν το πρότζεκτ σας αυτή τη στιγμή; Αν όχι, το έχει υποστηρίξει κάποιο εξέχον πρόσωπο;
 
-### Value to funder
+### Αξία για τον χρηματοδότη
 
-Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+Οι χρηματοδότες, είτε πρόκειται για τον εργοδότη σας είτε για ένα ίδρυμα που χορηγεί επιχορηγήσεις, προσεγγίζονται συχνά με ευκαιρίες. Γιατί θα πρέπει να υποστηρίξουν το πρότζεκτ σας έναντι οποιασδήποτε άλλης ευκαιρίας; Πώς ωφελούνται προσωπικά;
 
-### Use of funds
+### Χρήση των κονδυλίων
 
-What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+Τι ακριβώς θα επιτύχετε με την προτεινόμενη χρηματοδότηση; Επικεντρωθείτε σε ορόσημα ή αποτελέσματα του πρότζεκτ και όχι στην καταβολή μισθού.
 
-### How you'll receive the funds
+### Πώς θα λάβετε τα κεφάλαια
 
-Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+Έχει ο χρηματοδότης οποιεσδήποτε απαιτήσεις σχετικά με την εκταμίευση; Για παράδειγμα, μπορεί να χρειαστεί να είστε μη κερδοσκοπικός οργανισμός ή να έχετε μη κερδοσκοπικό φορολογικό χορηγό. Ή ίσως τα κονδύλια πρέπει να δοθούν σε μεμονωμένο ανάδοχο και όχι σε οργανισμό. Οι απαιτήσεις αυτές διαφέρουν από χρηματοδότη σε χρηματοδότη, οπότε φροντίστε να κάνετε την έρευνά σας εκ των προτέρων.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
-  For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+  Εδώ και χρόνια, είμαστε η κορυφαία πηγή εικονιδίων φιλικών προς τον ιστότοπο, με μια κοινότητα άνω των 20 εκατομμυρίων ανθρώπων και έχουμε εμφανιστεί σε περισσότερους από 70 εκατομμύρια ιστότοπους, συμπεριλαμβανομένου του Whitehouse.gov. (...) Η έκδοση 4 ήταν πριν από τρία χρόνια. Η τεχνολογία του Web έχει αλλάξει πολύ από τότε και ειλικρινά, το Font Awesome έχει γίνει λίγο μπαγιάτικο. (...) Γι' αυτό παρουσιάζουμε τη Font Awesome 5. Εκσυγχρονίζουμε και ξαναγράφουμε το CSS και επανασχεδιάζουμε κάθε εικονίδιο από πάνω μέχρι κάτω. Μιλάμε για καλύτερο σχεδιασμό, καλύτερη συνοχή και καλύτερη αναγνωσιμότητα.
   <p markdown="1" class="pquote-credit">
-— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+- @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
   </p>
 </aside>
 
-## Experiment and don't give up
+## Πειραματιστείτε και μην τα παρατάτε
 
-Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
+Η συγκέντρωση χρημάτων δεν είναι εύκολη υπόθεση, είτε πρόκειται για πρότζεκτ ανοιχτού κώδικα, είτε για μη κερδοσκοπικό οργανισμό, είτε για νεοσύστατη επιχείρηση λογισμικού, και στις περισσότερες περιπτώσεις απαιτεί να γίνετε δημιουργικοί. Το να προσδιορίσετε πώς θέλετε να πληρωθείτε, να κάνετε την έρευνά σας και να μπείτε στη θέση του χρηματοδότη σας θα σας βοηθήσει να δημιουργήσετε μια πειστική υπόθεση για χρηματοδότηση.

From ec0e58c7e6a9e72d181a8d0826ffbb7847000d30 Mon Sep 17 00:00:00 2001
From: eukap <esk.geek@gmail.com>
Date: Tue, 7 Jun 2022 09:35:14 +0300
Subject: [PATCH 353/749] Fix russian translation how-to-contribute.md

---
 _articles/ru/how-to-contribute.md | 74 +++++++++++++++----------------
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index da62f081322..78f454f737a 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -26,7 +26,7 @@ related:
 
 ### Улучшить используемые проекты
 
-Многие опенсорс-контрибьюторы перед тем, как внести свой вклад в продукт, были обычными его пользователями. Если вы обнаружите баг в используемой вами опенсорс-программе вы, возможно, захотите заглянуть в её исходный код, чтобы узнать, сможете ли вы исправить его самостоятельно. Если это так, то отправка патча — лучший способ убедиться, что ваши друзья (и вы сами, когда вы обновитесь до следующего релиза) смогут извлечь из него пользу.
+Многие опенсорс-контрибьюторы перед тем, как внести свой вклад в продукт, были обычными его пользователями. Если вы обнаружите баг в используемой вами опенсорс-программе, вы, возможно, захотите заглянуть в её исходный код, чтобы узнать, сможете ли вы исправить его самостоятельно. Если это так, то отправка патча — лучший способ убедиться, что ваши друзья (и вы сами, когда вы обновитесь до следующего релиза) смогут извлечь из него пользу.
 
 ### Улучшить существующие навыки
 
@@ -50,7 +50,7 @@ related:
 
 ### Возможность внести изменения, пусть даже небольшие
 
-Необязательно становиться контрибьютором на протяжении всей жизни, чтобы получать удовольствие от участия в опенсорс-проектах. Вы когда-нибудь видели опечатку на сайте и хотели бы, чтобы кто-нибудь её исправил? В проекте с открытым исходным кодом вы можете это сделать. Опенсорс помогает людям чувствовать хозяевами своей жизни и того  , как они воспринимают мир, и это само по себе отрадно.
+Необязательно становиться контрибьютором на протяжении всей жизни, чтобы получать удовольствие от участия в опенсорс-проектах. Вы когда-нибудь видели опечатку на сайте и хотели бы, чтобы кто-нибудь её исправил? В проекте с открытым исходным кодом вы можете это сделать. Опенсорс помогает людям чувствовать себя хозяевами своей жизни и того, как они воспринимают мир, и это само по себе отрадно.
 
 ## Что значит внести свой вклад 
 
@@ -64,7 +64,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
-  Я известен своей работой над CocoaPods, но большинство людей не знают, что я на самом деле не работаю над самим инструментом CocoaPods. В основном я занимаюсь документацией и брендингом.
+  Я известен своей работой над CocoaPods, но большинство людей не знают, что я на самом деле не работаю над самим инструментом CocoaPods. В основном, я занимаюсь документацией и брендингом.
   <p markdown="1" class="pquote-credit">
 — @orta, ["Переход на открытый исходный код по умолчанию"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
   </p>
@@ -103,7 +103,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
-  Кроме шуток, \[документация\] крайне важна. Документация до сих пор была отличной и была ключевой особенностью Babel. Есть разделы, которые требуют доработку, и даже добавление параграфа здесь или там чрезвычайно приветствуется.
+  Кроме шуток, \[документация\] крайне важна. Документация до сих пор была отличной и была ключевой особенностью Babel. Есть разделы, которые требуют доработки, и даже добавление параграфа здесь или там чрезвычайно приветствуется.
   <p markdown="1" class="pquote-credit">
 - @kittens, ["Призыв контрибьюторов"](https://github.com/babel/babel/issues/1347)
   </p>
@@ -112,12 +112,12 @@ related:
 ### Нравится организовывать?
 
 * Давайте ссылки на повторяющиеся ишью, предлагайте новые ярлыки для ишью, чтобы они были лучше огранизованы
-* Пройдитесь по открытым ишью и предложите закрыть старые, как [например сделал @nzakas в ESLint](https://github.com/eslint/eslint/issues/6765)
+* Пройдитесь по открытым ишью и предложите закрыть старые, как, [например, сделал @nzakas в ESLint](https://github.com/eslint/eslint/issues/6765)
 * Задавайте уточняющие вопросы по недавно открывшимся ишью, чтобы продвинуть обсуждение вперед
 
 ### Нравится кодить?
 
-* Найдите открытую проблему для решения, что [например @dianjin сделал в Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Найдите открытую проблему для решения, что, [например, @dianjin сделал в Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
 * Спросите, можете ли вы помочь с разработкой новой функциональности
 * Автоматизируйте настройку проекта
 * Улучшите инструменты и тестирование
@@ -166,7 +166,7 @@ related:
 
 Потратить годы на один открытый проект означает, что вы познакомились с одним открытым проектом. Переходите к другому проекту, и вы можете обнаружить, что терминология, нормы и стили общения совершенно другие.
 
-Тем не менее, многие проекты с открытым исходным кодом следуют схожей организационной структуре. Понимание различных ролей сообщества и общего процесса поможет вам быстро сориентироваться в любом новом проекте.
+Тем не менее многие проекты с открытым исходным кодом следуют схожей организационной структуре. Понимание различных ролей сообщества и общего процесса поможет вам быстро сориентироваться в любом новом проекте.
 
 Типичный проект с открытым исходным кодом состоит из следующих типов людей:
 
@@ -176,12 +176,12 @@ related:
 * **Контрибьюторы:** Все, кто внес свой вклад в проект.
 * **Участники сообщества:** Люди, использующие проект. Они могут быть активными в беседах или высказывать свое мнение о направлении проекта.
 
-В более крупных проектах также могут быть подкомитеты или рабочие группы, занимающиеся различными задачами, такими как инструменты, сортировка, модерация сообщества и организация мероприятий. Поищите на сайте проекта или репозитории "командную" или "организационную" страницу, чтобы найти эту информацию.
+В более крупных проектах также могут быть подкомитеты или рабочие группы, занимающиеся различными задачами, такими как инструменты, сортировка, модерация сообщества и организация мероприятий. Поищите на сайте проекта или в репозитории "командную" или "организационную" страницу, чтобы найти эту информацию.
 
 У проекта также есть документация. Эти файлы обычно находятся в корне репозитория.
 
-* **LICENSE:** По определению, каждый опенсорс-проект должен иметь [соответствующую лицензию](https://choosealicense.com). Если у проекта нет лицензии, его нельзя перечислить к опенсорсу.
-* **README:** README — это руководство-инструкция, которая приветствует новых членов сообщества в проекте. В этой файле объясняется назначение и применение проекта.
+* **LICENSE:** По определению, каждый опенсорс-проект должен иметь [соответствующую лицензию](https://choosealicense.com). Если у проекта нет лицензии, его нельзя причислить к опенсорсу.
+* **README:** README — это руководство-инструкция, которая приветствует новых членов сообщества в проекте. В этом файле объясняется назначение и применение проекта.
 * **CONTRIBUTING:** В то время как README помогают людям _использовать_ проект, документация по участию помогает людям _вносить_ вклад в проект. В нем объясняется, какие виды помощи необходимы и как устроен процесс. Хотя не у каждого проекта есть файл CONTRIBUTING, его наличие свидетельствует о дружелюбном отношении к участникам.
 * **CODE_OF_CONDUCT:** Кодекс поведения устанавливает основные правила поведения участников и помогает создать дружелюбную, гостеприимную атмосферу. Хотя не в каждом проекте есть файл CODE_OF_CONDUCT, его наличие свидетельствует о том, что это хороший проект, в который можно внести свой вклад.
 * **Другая документация:** Может быть дополнительная документация, например обучающие материалы, пошаговые руководства или политики управления, особенно для более крупных проектов.
@@ -197,7 +197,7 @@ related:
 
 Теперь, когда вы разобрались, как устроены опенсорс-проекты, пришло время найти проект, в который вы сможете внести свой вклад!
 
-Если вы никогда раньше не имели дело с опенсорсом, прислушайтесь к совету президента США Джона Ф. Кеннеди, который однажды сказал: _«Не спрашивайте, что ваша страна может сделать для вас, спросите, что вы можете сделать для своей страны»_.
+Если вы никогда раньше не имели дела с опенсорсом, прислушайтесь к совету президента США Джона Ф. Кеннеди, который однажды сказал: _«Не спрашивайте, что ваша страна может сделать для вас, спросите, что вы можете сделать для своей страны»_.
 
 Участвовать в опенсорсе могут все, независимо от уровня подготовки. Не ломайте сильно голову над тем, каким будет ваш первый вклад в опенсорс.
 
@@ -207,11 +207,11 @@ related:
 
 Опенсорс — это не закрытый клуб; им занимаются такие же люди, как вы. «Опенсорс» — это всего лишь причудливый термин для обозначения решаемых мировых проблем.
 
-Можно просмотреть файл README, чтобы найти неработающую ссылку или опечатку. Или вы как новый пользователь заметили, что что-то работает неправильно, либо есть неточность в документации. Вместо игнорирования таких проблем или просить кого-нибудь исправить их, посмотрите, удастся ли вам помочь и тем самым поучаствовать в проекте. В этом как раз и смысл опенсорса!
+Можно просмотреть файл README, чтобы найти неработающую ссылку или опечатку. Или вы как новый пользователь заметили, что что-то работает неправильно, либо есть неточность в документации. Вместо игнорирования таких проблем или просьбы к кому-нибудь их исправить, посмотрите, удастся ли вам помочь и тем самым поучаствовать в проекте. В этом как раз и смысл опенсорса!
 
 > [28% случайных вкладов](https://www.igor.pro.br/publica/papers/saner2016.pdf) в опенсорс представляют собой документацию, например, исправление опечатки, переформатирование или перевод.
 
-Если вы ищете существующие ишью, которые можно исправить, то в каждом опенсорс-проекте есть страница `/contribute`, где вы перечислены ишью, специально предназначенные для начинающих. Перейдите на главную страницу репозитория на GitHub и добавьте в конец URL-адреса `/contribute` (например, [https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+Если вы ищете существующие ишью, которые можно исправить, то в каждом опенсорс-проекте есть страница `/contribute`, где перечислены ишью, специально предназначенные для начинающих. Перейдите на главную страницу репозитория на GitHub и добавьте в конец URL-адреса `/contribute` (например, [https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
 
 Вы также можете использовать один из следующих ресурсов, чтобы открыть для себя новые проекты и внести свой вклад в них:
 
@@ -227,7 +227,7 @@ related:
 
 ### Чеклист перед тем, как принять участие
 
-Когда вы нашли проект, в который хотели бы внести свой вклад, бегло осмотритесь проект, чтобы убедиться, что он принимает стороннюю помощь. В противном случае ваш упорный труд может остаться незамеченным.
+Когда вы нашли проект, в который хотели бы внести свой вклад, бегло осмотрите проект, чтобы убедиться, что он принимает стороннюю помощь. В противном случае ваш упорный труд может остаться незамеченным.
 
 Вот удобный чеклист список, чтобы понять, подходит ли проект для новых контрибьюторов.
 
@@ -314,7 +314,7 @@ related:
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox20" class="overflow-hidden d-block text-normal">
-    Быстро ли мейнтейнеры реагируют на пул-реквесты после того, когда они открываются?
+    Быстро ли мейнтейнеры реагируют на пул-реквесты после их открытия?
   </label>
 </div>
 
@@ -341,7 +341,7 @@ related:
 
 **Проект приветливый**
 
-Дружелюбный и доброжелательный проект свидетельствует о том, что в нём будут с пониманием относится к новыми контрибьюторам.
+Дружелюбный и доброжелательный проект свидетельствует о том, что в нём будут с пониманием относиться к новым контрибьюторам.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
@@ -353,7 +353,7 @@ related:
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox15" class="overflow-hidden d-block text-normal">
-    Дружелюбны ли люди в вопросах, дискуссионном форуме и чате (например, IRC или Slack)?
+    Дружелюбны ли люди в вопросах, на дискуссионном форуме и в чате (например, IRC или Slack)?
   </label>
 </div>
 
@@ -381,11 +381,11 @@ related:
 
 ## Как сделать вклад
 
-Вы нашли понравившийся проект, и уже готовы поучаствовать в нём. Наконец-то! И вот как правильно это сделать.
+Вы нашли понравившийся проект и уже готовы поучаствовать в нём. Наконец-то! И вот как правильно это сделать.
 
 ### Эффективное общение
 
-Независимо от того, поучаствуете ли вы только один раз или же попытаетесь присоединиться к сообществу, совместная работа с другими люди  — один из самых важных навыков, который вы приобретете, занимаясь опенсорсом.
+Независимо от того, поучаствуете ли вы только один раз или же попытаетесь присоединиться к сообществу, совместная работа с другими людьми  — один из самых важных навыков, который вы приобретете, занимаясь опенсорсом.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
@@ -395,7 +395,7 @@ related:
   </p>
 </aside>
 
-Прежде чем открывать ишью, пул-реквест, или задать вопрос в чате, запомните эти советы, которые помогут эффективно реализовать ваши идеи в жизнь.
+Прежде чем открыть ишью, пул-реквест или задать вопрос в чате, запомните эти советы, которые помогут эффективно воплотить ваши идеи в жизнь.
 
 **Дайте контекст.** Помогите другим быстро освоиться. Если вы столкнулись с ошибкой, объясните, что вы пытаетесь сделать и как ее воспроизвести. Если вы предлагаете новую идею, объясните, почему вы думаете, что она будет полезна для проекта (не только для вас!).
 
@@ -403,13 +403,13 @@ related:
 >
 > 😢 _"X не работает! Исправьте это."_
 
-**Попробуйте сначала разобраться сами.** Не знать чего-то — это нормально, но покажите, что вы пробовали разобраться. Прежде чем обращаться за помощью, обязательно изучите README-файл проекта, документацию, ишью (открытые или закрытые), список рассылки и поищите ответ в Интернете. Люди оценят, когда вы продемонстрируете, что попытались что-то узнать.
+**Попробуйте сначала разобраться сами.** Не знать чего-то — это нормально, но покажите, что вы пробовали разобраться. Прежде чем обращаться за помощью, обязательно изучите README-файл проекта, документацию, ишью (открытые или закрытые), список рассылки и поищите ответ в Интернете. Люди оценят, если вы продемонстрируете, что попытались что-то узнать.
 
 > 😇 _"Я не знаю, как реализовать X. Я посмотрел документацию и не нашел никаких упоминаний об этом."_
 >
 > 😢 _"Как мне сделать X?"_
 
-**Пишите коротко и по делу.** Как и при отправке электронного письма, каждая сторонняя работа, независимо от того, насколько она была простой или полезной, требует чьей-то проверки. Во многих проектах входящих запросов больше, чем людей, готовых помочь. Будьте лаконичны. Так вы увеличите шанс того, что кто-то сможет вам помочь.
+**Пишите коротко и по делу.** Как и при отправке электронного письма, каждая сторонняя работа, независимо от того, насколько она была простой или полезной, требует чьей-то проверки. Во многих проектах входящих запросов больше, чем людей, готовых помочь. Будьте лаконичны. Так вы увеличите вероятность того, что кто-то сможет вам помочь.
 
 > 😇 _"Я хотел бы написать руководство по API."_
 >
@@ -421,13 +421,13 @@ related:
 >
 > 😢 _(по электронной почте) «Привет, извини, что побеспокоил тебя по электронной почте, но мне было интересно, была ли у тебя возможность просмотреть мой PR»_
 
-**Не стесняйтесь задавать вопросы (но будьте терпеливы!).** В какой-то момент каждый был новичком в проекте, и даже опытным контрибьютором нужно время освоиться, когда они приходят в новый проект. Точно так же уже давние мейнтейнеры не всегда знакомы со всеми частями проекта. Проявите к ним такое же терпение, какое вы бы хотели, чтобы они проявили к вам.
+**Не стесняйтесь задавать вопросы (но будьте терпеливы!).** В какой-то момент каждый был новичком в проекте, и даже опытным контрибьюторам нужно время освоиться, когда они приходят в новый проект. Точно так же мейнтейнеры, давно поддерживающие проект, не всегда знакомы со всеми его частями. Проявите к ним такое же терпение, какое вы бы хотели, чтобы они проявили к вам.
 
 > 😇 _"Спасибо, что разобрались с этой ошибкой. Я последовал вашим предложениям. Вот результат."_
 >
 > 😢 _"Почему вы не можете решить мою проблему? Разве это не ваш проект?"_
 
-**Уважайте решения сообщества.** Ваши идеи могут отличаться от приоритетов или видения сообщества. Они могут высказать свои мнения или отказаться от реализации вашей идеи. Хотя всегда нужно обсуждать и искать компромисс, последнее слово за мейнтейнерами, потому что им в дальнейшем предстоит работать с вашим кодом. Если вы не согласны с их направлением, вы всегда можете работать над собственным ответвлением проекта (форком) или начать собственный проект.
+**Уважайте решения сообщества.** Ваши идеи могут отличаться от приоритетов или видения сообщества. Члены сообщества могут высказать свои мнения или отказаться от реализации вашей идеи. Хотя всегда нужно обсуждать и искать компромисс, последнее слово за мейнтейнерами, потому что им в дальнейшем предстоит работать с вашим кодом. Если вы не согласны с их направлением, вы всегда можете работать над собственным ответвлением проекта (форком) или начать собственный проект.
 
 > 😇 _"Я разочарован, что вы не можете поддержать мой вариант использования, но, как вы объяснили, он затрагивает только небольшую часть пользователей, я понимаю почему. Спасибо за внимание."_
 >
@@ -437,13 +437,13 @@ related:
 
 ### Изучение обстановки
 
-Прежде чем что-либо делать, убедитесь, что это больше нигде не обсуждалась. Пройдитесь по README-файлу проекта, ишью (открытые и закрытые), списку рассылки и Stack Overflow. Не тратьте много времени на это, достаточно поискать по нескольким ключевым словам.
+Прежде чем что-либо делать, убедитесь, что это больше нигде не обсуждалось. Пройдитесь по README-файлу проекта, ишью (открытые и закрытые), списку рассылки и Stack Overflow. Не тратьте много времени на это, достаточно поискать по нескольким ключевым словам.
 
 Если вы не нашли обсуждение вашей идеи, можно начать действовать. Если проект находится на GitHub, вы, скорее всего, будете общаться, открывая ишью или пул-реквест:
 
 * **Ишью** отлично подходят, чтобы завести беседу или обсуждение
 * **Запросы на изменение** предназначены для начала работы над решением.
-* **Для легкого общения**, например, уточняющего или практического вопроса, попробуйте задать вопрос в Stack Overflow, IRC, Slack или других чат-каналах, если он есть в проекте
+* **Для легкого общения**, например, уточняющего или практического вопроса, попробуйте задать вопрос в Stack Overflow, IRC, Slack или других чат-каналах, если они есть в проекте
 
 Прежде чем открывать ишью или пул-реквест, ознакомьтесь с руководством по участию (обычно ему посвящен отдельный файл с именем CONTRIBUTING или соответствующий раздел в файле README), чтобы сделать всё правильно. Например, вас могут попросить представить информацию согласно шаблону или потребовать, чтобы вы написали тесты.
 
@@ -459,7 +459,7 @@ related:
 
 ### Открытие ишью
 
-Как правило, следует создать ишью чтобы:
+Как правило, следует создать ишью, чтобы:
 
 * Сообщить об ошибке, которую вы не можете исправить самостоятельно
 * Обсудить общую тему или идею (например, связанную с сообществом, развитием или политикой проекта)
@@ -467,29 +467,29 @@ related:
 
 Советы по общению в ишью:
 
-* **Если видите открытую ишью, которую хотите решить** прокомментируйте её, чтобы люди знали, что вы занимаетесь ею. Таким образом, снизится вероятность, что кто-то ещё будет работать над ней.
+* **Если видите открытую ишью, которую хотите решить**, прокомментируйте её, чтобы люди знали, что вы занимаетесь ею. Таким образом, снизится вероятность, что кто-то ещё будет работать над ней.
 * **Если ишью была открыта давно,** возможно, что она рассматривается в другом месте, либо уже решена, поэтому прокомментируйте её, чтобы подтвердить её актуальность.
 * **Если вы открыли ишью, но позже самостоятельно нашли ответ,** прокомментируйте её, чтобы сообщить об этом людям, а затем закройте её. Даже фиксирование такого результата является вкладом в проект.
 
 ### Открытие пул-реквеста
 
-Как правило, следует создать пул-реквест чтобы:
+Как правило, следует создать пул-реквест, чтобы:
 
 * Сделать незначительное исправление (например, исправить опечатку, неработающую ссылку или очевидную ошибку)
 * Начать работать над тем, о чём уже было договорено или что обсуждалось в ишью
 
-Пул-реквест не обязательно должен представлять законченную работу. Обычно лучше открывать пул-реквест на раннем этапе, чтобы люди могли наблюдать за вашим прогрессом или оставлять отзывы о нем. Только в названии таком пул-реквесте укажите "WIP" (от англ. Work in Progress — в процессе выполнения). Всегда позже можно отправить дополнительные коммиты.
+Пул-реквест не обязательно должен представлять законченную работу. Обычно лучше открывать пул-реквест на раннем этапе, чтобы люди могли наблюдать за вашим прогрессом или оставлять отзывы о нем. Только в названии такого пул-реквеста укажите "WIP" (от англ. Work in Progress — в процессе выполнения). Всегда позже можно отправить дополнительные коммиты.
 
 Если проект находится на GitHub, выполните следующие шаги, чтобы создать пул-реквест:
 
-* **[Форкните репозиторий](https://guides.github.com/activities/forking/)** и склонируйте его к себе локально. Затем в этом локальном репозитории добавьте оригинальный (upstream) репозиторий. Почаще загружайте изменения из исходного репозиторий, чтобы ваш локальный репозиторий оставался в актуальном состоянии, — это снизит появление конфликтов при создании пул-реквеста. (См. более подробные инструкции [здесь](https://help.github.com/articles/syncing-a-fork/).)
+* **[Форкните репозиторий](https://guides.github.com/activities/forking/)** и склонируйте его к себе локально. Затем в этом локальном репозитории добавьте оригинальный (upstream) репозиторий. Почаще загружайте изменения из исходного репозитория, чтобы ваш локальный репозиторий оставался в актуальном состоянии, — это снизит вероятность возникновения конфликтов при создании пул-реквеста. (См. более подробные инструкции [здесь](https://help.github.com/articles/syncing-a-fork/).)
 * **[Создайте ветку](https://guides.github.com/introduction/flow/)** для ваших правок.
 * **Ссылайтесь на любые относящиеся к делу ишью** или подтверждающую документацию в своем PR (например, «Closes #37»).
 * **Добавьте скриншоты до и после**, если ваши изменения затрагивают файлы HTML/CSS. Перетащите изображения в текстовую область пул-реквеста.
-* **Протестируйте свои изменения!** Например, если есть, запустите тесты, и при необходимости напишите новые. Даже если нет тестов, проверьте сами, что после ваших изменений всё работает, как и раньше.
-* **Соблюдайте стиль написания кода проекта** в меру своих возможностей. Это может быть использование отступов, точек с запятой или комментариев иначе, чем вы привыкли, но мейнтейнерам это упросит слияние вашего пул-реквеста, а другим — облегчит понимание и поддержку в будущем.
+* **Протестируйте свои изменения!** Например, запустите тесты, если они есть, и при необходимости напишите новые. Даже если тестов нет, проверьте сами, что после ваших изменений всё работает, как и раньше.
+* **Соблюдайте стиль написания кода проекта** в меру своих возможностей. Это может быть использование отступов, точек с запятой или комментариев иначе, чем вы привыкли, но мейнтейнерам это упростит слияние вашего пул-реквеста, а другим — облегчит понимание и поддержку в будущем.
 
-Если это ваш первый пул-реквест, ознакомьтесь с сайтом [Make a Pull Request](http://makeapullrequest.com/), которую @kentcdodds сделал в виде пошагового видео-руководства. Вы также можете попрактиковаться в создании пул-реквеста в репозитории [First Contributions](https://github.com/Roshanjossey/first-contributions), созданном @Roshanjossey.
+Если это ваш первый пул-реквест, ознакомьтесь с сайтом [Make a Pull Request](http://makeapullrequest.com/), который @kentcdodds сделал в виде пошагового видео-руководства. Вы также можете попрактиковаться в создании пул-реквеста в репозитории [First Contributions](https://github.com/Roshanjossey/first-contributions), созданном @Roshanjossey.
 
 ## Что будет дальше после принятия участия
 
@@ -505,7 +505,7 @@ related:
 
 **Не** обращайтесь напрямую к этому человеку; помните, что публичное общение жизненно важно для опенсорс-проектов.
 
-Если после вежливого напоминания так и никто не ответил, есть вероятность, что никто и никогда не ответит. Это не самое приятное ощущение, но пусть оно вас не расстраивает. Такое с каждым случалось! Есть множество возможных причин, по которым вам не ответили, в том числе личные обстоятельства, на которые вы можете повлиять. Попробуйте найти другой проект или способ участия. Во всяком случае, нет больше смысла вкладываться в такие проекты, по крайней мере до того момента, когда объявятся другие члены сообщества.
+Если после вежливого напоминания так никто и не ответил, есть вероятность, что никто и никогда не ответит. Это не самое приятное ощущение, но пусть оно вас не расстраивает. Такое с каждым случалось! Есть множество возможных причин, по которым вам могли не ответить, в том числе личные обстоятельства, на которые вы не можете повлиять. Попробуйте найти другой проект или способ участия. В любом случае, нет смысла тратить время на проект, пока члены его сообщества не проявят должного уровня вовлеченности и отзывчивости.
 
 ### 🚧 У вас могут запросить внести изменения.
 
@@ -513,11 +513,11 @@ related:
 
 Когда кто-то запрашивает сделать изменения, относитесь к этому с пониманием и воспринимайте это должным образом. Люди нашли время, чтобы оценить ваш вклад. Открывать PR и бросать его на произвол судьбы — дурной тон. Если вы не знаете, как внести изменения, изучите проблему, а затем обратитесь за помощью, если она вам нужна.
 
-Если у вас больше нет времени работать над проблемой (например, обсуждение длится уже несколько месяцев, а за это время обстоятельства поменялись), сообщите об этом мейнтейнеру, чтобы он не ожидал ответа. Возможно кто-то другой с радостью завершит начатую вами работу.
+Если у вас больше нет времени работать над проблемой (например, обсуждение длится уже несколько месяцев, а за это время обстоятельства поменялись), сообщите об этом мейнтейнеру, чтобы он не ожидал ответа. Возможно, кто-то другой с радостью завершит начатую вами работу.
 
 ### 👎 Ваш вклад не принят.
 
-В итоге ваш вклад может быть принят или нет. Надеюсь, вы не потратили слишком много усилий на него. Если для вас не было понятно, почему он не был принят, разумно попросить мейнтейнера дать пояснения. В конечном итоге, однако, вам стоит понять и смирится с их решением. Не спорьте и не злитесь по этому поводу. В случае чего вы всегда можете форкнуть репозиторий, чтобы работать над своей собственной версией продукта!
+В итоге ваш вклад будет либо принят, либо нет. Надеюсь, вы потратили не слишком много усилий на него. Если вы не поняли, почему он не был принят, разумно попросить мейнтейнера дать пояснения. В конечном итоге, однако, вам стоит понять и смириться с их решением. Не спорьте и не злитесь по этому поводу. В случае чего вы всегда можете форкнуть репозиторий, чтобы работать над своей собственной версией продукта!
 
 ### 🎉 Ваш вклад принят.
 

From ffbc8924b598f72bda49d3d190c7b668f8da08a0 Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Thu, 30 Jun 2022 10:04:59 +0100
Subject: [PATCH 354/749] Autoformat includes/layouts

Let VSCode autoformat these so the indentation is more consistent.
---
 _includes/footer.html     |  74 ++++++---
 _includes/head.html       |  26 ++--
 _includes/jekyll-toc.html | 312 ++++++++++++++++++--------------------
 _includes/nav.html        |  17 ++-
 _layouts/article.html     |  14 +-
 _layouts/default.html     |  25 +--
 6 files changed, 242 insertions(+), 226 deletions(-)

diff --git a/_includes/footer.html b/_includes/footer.html
index 3bf511f15bd..6e1932dfb6e 100644
--- a/_includes/footer.html
+++ b/_includes/footer.html
@@ -5,11 +5,13 @@
     <div class="d-flex flex-wrap flex-items-stretch">
       <div class="col-12 col-sm-6 mb-4 col-border">
         <div class="height-full p-5">
-          <img src="{{ "/assets/images/illos/squirrel.svg" | relative_url }}" class="little-illo mb-3" alt="squirrel illustration">
+          <img src='{{ "/assets/images/illos/squirrel.svg" | relative_url }}' class="little-illo mb-3"
+            alt="squirrel illustration">
           <h3 class="h3-mktg mb-3">{{ t.footer.contribute.heading }}</h3>
           <p class="mb-3 p-large">{{ t.footer.contribute.description }}</p>
           <p>
-            <a data-proofer-ignore href="https://github.com/{{ site.github.repository_nwo }}/edit/main/{{ page.path }}" class="btn btn-outline">
+            <a data-proofer-ignore href="https://github.com/{{ site.github.repository_nwo }}/edit/main/{{ page.path }}"
+              class="btn btn-outline">
               {{ t.footer.contribute.button }}
             </a>
           </p>
@@ -18,52 +20,76 @@ <h3 class="h3-mktg mb-3">{{ t.footer.contribute.heading }}</h3>
       <div class="col-12 col-sm-6 mb-4">
         <div class="height-full p-5">
           <div id="mc_embed_signup">
-          <form action="//github.us11.list-manage.com/subscribe/post?u=9d7ced8c4bbd6c2f238673f0f&amp;id=b514344ba3" method="post" id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" class="validate" target="_blank" novalidate>
+            <form action="//github.us11.list-manage.com/subscribe/post?u=9d7ced8c4bbd6c2f238673f0f&amp;id=b514344ba3"
+              method="post" id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" class="validate"
+              target="_blank" novalidate>
               <div id="mc_embed_signup_scroll">
-              <img src="{{ "/assets/images/illos/bird.svg" | relative_url }}" class="little-illo mb-3" alt="bird illustration">
-              <h3 class="h3-mktg mb-3">{{ t.footer.subscribe.heading }}</h3>
-              <p class="mb-3 p-large">{{ t.footer.subscribe.description }}</p>
+                <img src='{{ "/assets/images/illos/bird.svg" | relative_url }}' class="little-illo mb-3"
+                  alt="bird illustration">
+                <h3 class="h3-mktg mb-3">{{ t.footer.subscribe.heading }}</h3>
+                <p class="mb-3 p-large">{{ t.footer.subscribe.description }}</p>
 
-              <div class="mc-field-group col-12">
+                <div class="mc-field-group col-12">
                   <label for="mce-EMAIL" class="d-none">{{ t.footer.subscribe.label }}</label>
-                  <input type="email" placeholder="{{ t.footer.subscribe.label }}" name="EMAIL" class="form-input required email d-block col-10 mx-auto py-2 px-3 mb-3" id="mce-EMAIL" autocomplete="home email">
-                  <input type="checkbox" value="1" name="group[9617][1]" id="mce-group[9617]-9617-0" checked="checked" style="display:none">
-                  <input type="submit" value="{{ t.footer.subscribe.button }}" name="subscribe" id="mc-embedded-subscribe" class="btn btn-outline">
-              </div>
-              <div id="mce-responses" class="clear">
+                  <input type="email" placeholder="{{ t.footer.subscribe.label }}" name="EMAIL"
+                    class="form-input required email d-block col-10 mx-auto py-2 px-3 mb-3" id="mce-EMAIL"
+                    autocomplete="home email">
+                  <input type="checkbox" value="1" name="group[9617][1]" id="mce-group[9617]-9617-0" checked="checked"
+                    style="display:none">
+                  <input type="submit" value="{{ t.footer.subscribe.button }}" name="subscribe"
+                    id="mc-embedded-subscribe" class="btn btn-outline">
+                </div>
+                <div id="mce-responses" class="clear">
                   <div class="" id="mce-error-response" style="display:none"></div>
                   <div class="" id="mce-success-response" style="display:none"></div>
+                </div>
+                <div style="position: absolute; left: -5000px;" aria-hidden="true"><input type="text"
+                    name="b_9d7ced8c4bbd6c2f238673f0f_b514344ba3" tabindex="-1" value=""></div>
               </div>
-              <div style="position: absolute; left: -5000px;" aria-hidden="true"><input type="text" name="b_9d7ced8c4bbd6c2f238673f0f_b514344ba3" tabindex="-1" value=""></div>
-              </div>
-          </form>
+            </form>
           </div>
         </div>
       </div>
     </div>
 
     <div class="border-top text-gray py-5">
-      <p class="float-md-right"><a class="text-gray-light text-small" href="{{ "/notices/" | relative_url }}">fine print</a></p>
+      <p class="float-md-right"><a class="text-gray-light text-small" href='{{ "/notices/" | relative_url }}'>fine
+          print</a></p>
 
       <div>
         {% capture code %}
-          {% assign code_label = t.footer.byline.code_label %}
-          <svg height="20" class="octicon octicon-code v-align-middle fill-gray mr-1" aria-label="{{ code_label }}" viewBox="0 0 14 16" version="1.1" width="17" role="img"><path d="M9.5 3L8 4.5 11.5 8 8 11.5 9.5 13 14 8 9.5 3zm-5 0L0 8l4.5 5L6 11.5 2.5 8 6 4.5 4.5 3z"></path></svg>
+        {% assign code_label = t.footer.byline.code_label %}
+        <svg height="20" class="octicon octicon-code v-align-middle fill-gray mr-1" aria-label="{{ code_label }}"
+          viewBox="0 0 14 16" version="1.1" width="17" role="img">
+          <path d="M9.5 3L8 4.5 11.5 8 8 11.5 9.5 13 14 8 9.5 3zm-5 0L0 8l4.5 5L6 11.5 2.5 8 6 4.5 4.5 3z"></path>
+        </svg>
         {% endcapture %}
         {% capture love %}
-          {% assign love_label = t.footer.byline.love_label %}
-          <svg height="20" class="octicon octicon-heart v-align-middle fill-gray mx-1" aria-label="{{love_label}}" viewBox="0 0 12 16" version="1.1" width="15" role="img"><path d="M11.2 3c-.52-.63-1.25-.95-2.2-1-.97 0-1.69.42-2.2 1-.51.58-.78.92-.8 1-.02-.08-.28-.42-.8-1-.52-.58-1.17-1-2.2-1-.95.05-1.69.38-2.2 1-.52.61-.78 1.28-.8 2 0 .52.09 1.52.67 2.67C1.25 8.82 3.01 10.61 6 13c2.98-2.39 4.77-4.17 5.34-5.33C11.91 6.51 12 5.5 12 5c-.02-.72-.28-1.39-.8-2.02V3z"></path></svg>
+        {% assign love_label = t.footer.byline.love_label %}
+        <svg height="20" class="octicon octicon-heart v-align-middle fill-gray mx-1" aria-label="{{love_label}}"
+          viewBox="0 0 12 16" version="1.1" width="15" role="img">
+          <path
+            d="M11.2 3c-.52-.63-1.25-.95-2.2-1-.97 0-1.69.42-2.2 1-.51.58-.78.92-.8 1-.02-.08-.28-.42-.8-1-.52-.58-1.17-1-2.2-1-.95.05-1.69.38-2.2 1-.52.61-.78 1.28-.8 2 0 .52.09 1.52.67 2.67C1.25 8.82 3.01 10.61 6 13c2.98-2.39 4.77-4.17 5.34-5.33C11.91 6.51 12 5.5 12 5c-.02-.72-.28-1.39-.8-2.02V3z">
+          </path>
+        </svg>
         {% endcapture %}
         {% capture github %}
-          <svg height="20" class="octicon octicon-mark-github v-align-middle fill-gray mx-1" aria-label="GitHub" viewBox="0 0 16 16" version="1.1" width="20" role="img"><path d="M8 0C3.58 0 0 3.58 0 8c0 3.54 2.29 6.53 5.47 7.59.4.07.55-.17.55-.38 0-.19-.01-.82-.01-1.49-2.01.37-2.53-.49-2.69-.94-.09-.23-.48-.94-.82-1.13-.28-.15-.68-.52-.01-.53.63-.01 1.08.58 1.23.82.72 1.21 1.87.87 2.33.66.07-.52.28-.87.51-1.07-1.78-.2-3.64-.89-3.64-3.95 0-.87.31-1.59.82-2.15-.08-.2-.36-1.02.08-2.12 0 0 .67-.21 2.2.82.64-.18 1.32-.27 2-.27.68 0 1.36.09 2 .27 1.53-1.04 2.2-.82 2.2-.82.44 1.1.16 1.92.08 2.12.51.56.82 1.27.82 2.15 0 3.07-1.87 3.75-3.65 3.95.29.25.54.73.54 1.48 0 1.07-.01 1.93-.01 2.2 0 .21.15.46.55.38A8.013 8.013 0 0 0 16 8c0-4.42-3.58-8-8-8z"></path></svg>
+        <svg height="20" class="octicon octicon-mark-github v-align-middle fill-gray mx-1" aria-label="GitHub"
+          viewBox="0 0 16 16" version="1.1" width="20" role="img">
+          <path
+            d="M8 0C3.58 0 0 3.58 0 8c0 3.54 2.29 6.53 5.47 7.59.4.07.55-.17.55-.38 0-.19-.01-.82-.01-1.49-2.01.37-2.53-.49-2.69-.94-.09-.23-.48-.94-.82-1.13-.28-.15-.68-.52-.01-.53.63-.01 1.08.58 1.23.82.72 1.21 1.87.87 2.33.66.07-.52.28-.87.51-1.07-1.78-.2-3.64-.89-3.64-3.95 0-.87.31-1.59.82-2.15-.08-.2-.36-1.02.08-2.12 0 0 .67-.21 2.2.82.64-.18 1.32-.27 2-.27.68 0 1.36.09 2 .27 1.53-1.04 2.2-.82 2.2-.82.44 1.1.16 1.92.08 2.12.51.56.82 1.27.82 2.15 0 3.07-1.87 3.75-3.65 3.95.29.25.54.73.54 1.48 0 1.07-.01 1.93-.01 2.2 0 .21.15.46.55.38A8.013 8.013 0 0 0 16 8c0-4.42-3.58-8-8-8z">
+          </path>
+        </svg>
         {% endcapture %}
         {% capture friends %}
-          {% assign friends_label = t.footer.byline.friends_label %}
-          <a href="https://github.com/github/opensource.guide/graphs/contributors" class="text-gray">{{ friends_label }}</a>
+        {% assign friends_label = t.footer.byline.friends_label %}
+        <a href="https://github.com/github/opensource.guide/graphs/contributors" class="text-gray">{{ friends_label
+          }}</a>
         {% endcapture %}
 
         {% assign byline = t.footer.byline.format %}
-        {{ byline | replace: "[code]", code | replace: "[love]", love | replace: "[github]", github | replace: "[friends]", friends }}
+        {{ byline | replace: "[code]", code | replace: "[love]", love | replace: "[github]", github | replace:
+        "[friends]", friends }}
       </div>
     </div>
   </div>
diff --git a/_includes/head.html b/_includes/head.html
index 6349cd761bd..df1ea4f4d07 100644
--- a/_includes/head.html
+++ b/_includes/head.html
@@ -4,20 +4,20 @@
   <meta name="google-site-verification" content="c1kuD-K2HIVF635lypcsWPoD4kilo5-jA_wBFyT4uMY" />
   <link rel="icon" type="image/x-icon" href="https://github.githubassets.com/favicon.ico">
   <link href="https://fonts.googleapis.com/css?family=Roboto:300,300i,400,400i,700,700i" rel="stylesheet">
-  <link href="{{ "/assets/css/index.css" | relative_url }}" rel="stylesheet">
+  <link href='{{ "/assets/css/index.css" | relative_url }}' rel="stylesheet">
   {% seo %}
   {% if page.lang and page.untranslated != true and site.data.locales.size > 1 %}
-    {% assign locales = site.data.locales | sort %}
-    {% for locale in locales %}
-      {% assign lang = locale[0] %}
-      {% assign page_lang_slash = page.lang | append: '/' | prepend: '/' %}
-      {% assign default_url = page.url | replace: page_lang_slash, '/' %}
-      {% if lang == "en" %}
-      <link rel="alternate" hreflang="en" href="{{ site.url }}{{ default_url }}" />
-      <link rel="alternate" hreflang="x-default" href="{{ site.url }}{{ default_url }}" />
-      {% else %}
-      <link rel="alternate" hreflang="{{ lang }}" href="{{ site.url }}/{{ lang }}{{ default_url }}" />
-      {% endif %}
-    {% endfor %}
+  {% assign locales = site.data.locales | sort %}
+  {% for locale in locales %}
+  {% assign lang = locale[0] %}
+  {% assign page_lang_slash = page.lang | append: '/' | prepend: '/' %}
+  {% assign default_url = page.url | replace: page_lang_slash, '/' %}
+  {% if lang == "en" %}
+  <link rel="alternate" hreflang="en" href="{{ site.url }}{{ default_url }}" />
+  <link rel="alternate" hreflang="x-default" href="{{ site.url }}{{ default_url }}" />
+  {% else %}
+  <link rel="alternate" hreflang="{{ lang }}" href="{{ site.url }}/{{ lang }}{{ default_url }}" />
+  {% endif %}
+  {% endfor %}
   {% endif %}
 </head>
diff --git a/_includes/jekyll-toc.html b/_includes/jekyll-toc.html
index 662fe88ba7e..fb2547eba0d 100644
--- a/_includes/jekyll-toc.html
+++ b/_includes/jekyll-toc.html
@@ -1,186 +1,166 @@
 {% capture tocWorkspace %}
-    {% comment %}
-        Copyright (c) 2017 Vladimir "allejo" Jimenez
-
-        Permission is hereby granted, free of charge, to any person
-        obtaining a copy of this software and associated documentation
-        files (the "Software"), to deal in the Software without
-        restriction, including without limitation the rights to use,
-        copy, modify, merge, publish, distribute, sublicense, and/or sell
-        copies of the Software, and to permit persons to whom the
-        Software is furnished to do so, subject to the following
-        conditions:
-
-        The above copyright notice and this permission notice shall be
-        included in all copies or substantial portions of the Software.
-
-        THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-        EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
-        OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
-        NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
-        HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
-        WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-        FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
-        OTHER DEALINGS IN THE SOFTWARE.
-    {% endcomment %}
-    {% comment %}
-        Version 1.2.0
-          https://github.com/allejo/jekyll-toc
-
-        "...like all things liquid - where there's a will, and ~36 hours to spare, there's usually a/some way" ~jaybe
-
-        Usage:
-            {% include jekyll-toc.html html=content sanitize=true class="inline_toc" id="my_toc" h_min=2 h_max=3 %}
-
-        Parameters:
-            * html         (string) - the HTML of compiled markdown generated by kramdown in Jekyll
-
-        Optional Parameters:
-            * sanitize      (bool)   : false  - when set to true, the headers will be stripped of any HTML in the TOC
-            * class         (string) :   ''   - a CSS class assigned to the TOC
-            * id            (string) :   ''   - an ID to assigned to the TOC
-            * h_min         (int)    :   1    - the minimum TOC header level to use; any header lower than this value will be ignored
-            * h_max         (int)    :   6    - the maximum TOC header level to use; any header greater than this value will be ignored
-            * ordered       (bool)   : false  - when set to true, an ordered list will be outputted instead of an unordered list
-            * item_class    (string) :   ''   - add custom class(es) for each list item; has support for '%level%' placeholder, which is the current heading level
-            * submenu_class (string) :   ''   - add custom class(es) for each child group of headings; has support for '%level%' placeholder which is the current "submenu" heading level
-            * base_url      (string) :   ''   - add a base url to the TOC links for when your TOC is on another page than the actual content
-            * anchor_class  (string) :   ''   - add custom class(es) for each anchor element
-            * skip_no_ids   (bool)   : false  - skip headers that do not have an `id` attribute
-
-        Output:
-            An ordered or unordered list representing the table of contents of a markdown block. This snippet will only
-            generate the table of contents and will NOT output the markdown given to it
-    {% endcomment %}
-
-    {% capture newline %}
-    {% endcapture %}
-    {% assign newline = newline | rstrip %} <!-- Remove the extra spacing but preserve the newline -->
-
-    {% capture deprecation_warnings %}{% endcapture %}
-
-    {% if include.baseurl %}
-        {% capture deprecation_warnings %}{{ deprecation_warnings }}<!-- jekyll-toc :: "baseurl" has been deprecated, use "base_url" instead -->{{ newline }}{% endcapture %}
+{% comment %}
+Copyright (c) 2017 Vladimir "allejo" Jimenez
+
+Permission is hereby granted, free of charge, to any person
+obtaining a copy of this software and associated documentation
+files (the "Software"), to deal in the Software without
+restriction, including without limitation the rights to use,
+copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following
+conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+OTHER DEALINGS IN THE SOFTWARE.
+{% endcomment %}
+{% comment %}
+Version 1.2.0
+https://github.com/allejo/jekyll-toc
+
+"...like all things liquid - where there's a will, and ~36 hours to spare, there's usually a/some way" ~jaybe
+
+Usage:
+{% include jekyll-toc.html html=content sanitize=true class="inline_toc" id="my_toc" h_min=2 h_max=3 %}
+
+Parameters:
+* html (string) - the HTML of compiled markdown generated by kramdown in Jekyll
+
+Optional Parameters:
+* sanitize (bool) : false - when set to true, the headers will be stripped of any HTML in the TOC
+* class (string) : '' - a CSS class assigned to the TOC
+* id (string) : '' - an ID to assigned to the TOC
+* h_min (int) : 1 - the minimum TOC header level to use; any header lower than this value will be ignored
+* h_max (int) : 6 - the maximum TOC header level to use; any header greater than this value will be ignored
+* ordered (bool) : false - when set to true, an ordered list will be outputted instead of an unordered list
+* item_class (string) : '' - add custom class(es) for each list item; has support for '%level%' placeholder, which is
+the current heading level
+* submenu_class (string) : '' - add custom class(es) for each child group of headings; has support for '%level%'
+placeholder which is the current "submenu" heading level
+* base_url (string) : '' - add a base url to the TOC links for when your TOC is on another page than the actual content
+* anchor_class (string) : '' - add custom class(es) for each anchor element
+* skip_no_ids (bool) : false - skip headers that do not have an `id` attribute
+
+Output:
+An ordered or unordered list representing the table of contents of a markdown block. This snippet will only
+generate the table of contents and will NOT output the markdown given to it
+{% endcomment %}
+
+{% capture newline %}
+{% endcapture %}
+{% assign newline = newline | rstrip %}
+<!-- Remove the extra spacing but preserve the newline -->
+
+{% capture deprecation_warnings %}{% endcapture %}
+
+{% if include.baseurl %}
+{% capture deprecation_warnings %}{{ deprecation_warnings }}
+<!-- jekyll-toc :: "baseurl" has been deprecated, use "base_url" instead -->{{ newline }}{% endcapture %}
+{% endif %}
+
+{% if include.skipNoIDs %}
+{% capture deprecation_warnings %}{{ deprecation_warnings }}
+<!-- jekyll-toc :: "skipNoIDs" has been deprecated, use "skip_no_ids" instead -->{{ newline }}{% endcapture %}
+{% endif %}
+
+{% capture jekyll_toc %}{% endcapture %}
+{% assign orderedList = include.ordered | default: false %}
+{% assign baseURL = include.base_url | default: include.baseurl | default: '' %}
+{% assign skipNoIDs = include.skip_no_ids | default: include.skipNoIDs | default: false %}
+{% assign minHeader = include.h_min | default: 1 %}
+{% assign maxHeader = include.h_max | default: 6 %}
+{% assign nodes = include.html | strip | split: '<h' %} {% assign firstHeader=true %} {% assign currLevel=0 %} {% assign
+    lastLevel=0 %} {% capture listModifier %}{% if orderedList %}ol{% else %}ul{% endif %}{% endcapture %} {% for node
+    in nodes %} {% if node=="" %} {% continue %} {% endif %} {% if forloop.last==true %} {% continue %} {% endif %} {%
+    assign currLevel=node | replace: '"' , '' | slice: 0, 1 | times: 1 %} {% if currLevel < minHeader or currLevel>
+    maxHeader %}
+    {% continue %}
     {% endif %}
 
-    {% if include.skipNoIDs %}
-        {% capture deprecation_warnings %}{{ deprecation_warnings }}<!-- jekyll-toc :: "skipNoIDs" has been deprecated, use "skip_no_ids" instead -->{{ newline }}{% endcapture %}
+    {% assign _workspace = node | split: '</h' %} {% assign _idWorkspace=_workspace[0] | split: 'id="' %} {% assign
+    _idWorkspace=_idWorkspace[1] | split: '"' %} {% assign htmlID=_idWorkspace[0] %} {% assign
+    _classWorkspace=_workspace[0] | split: 'class="' %} {% assign _classWorkspace=_classWorkspace[1] | split: '"' %} {%
+    assign htmlClass=_classWorkspace[0] %} {% if htmlClass contains "no_toc" %} {% continue %} {% endif %} {% if
+    firstHeader %} {% assign minHeader=currLevel %} {% endif %} {% capture _hAttrToStrip %}{{ _workspace[0] | split: '>'
+    | first }}>{% endcapture %}
+{% assign header = _workspace[0] | replace: _hAttrToStrip, '' %}
+
+{% if include.item_class and include.item_class != blank %}
+{% capture listItemClass %} class="{{ include.item_class | replace: '%level%', currLevel | split: '.' | join: ' ' }}"{%
+endcapture %}
+{% endif %}
+
+{% if include.submenu_class and include.submenu_class != blank %}
+{% assign subMenuLevel = currLevel | minus: 1 %}
+{% capture subMenuClass %} class="{{ include.submenu_class | replace: '%level%', subMenuLevel | split: '.' | join: ' '
+}}"{% endcapture %}
+{% endif %}
+
+{% capture anchorBody %}{% if include.sanitize %}{{ header | strip_html }}{% else %}{{ header }}{% endif %}{% endcapture
+%}
+
+{% if htmlID %}
+{% capture anchorAttributes %} href="{% if baseURL %}{{ baseURL }}{% endif %}#{{ htmlID }}"{% endcapture %}
+
+{% if include.anchor_class %}
+{% capture anchorAttributes %}{{ anchorAttributes }} class="{{ include.anchor_class | split: '.' | join: ' ' }}"{%
+endcapture %}
+{% endif %}
+
+{% capture listItem %}<a{{ anchorAttributes }}>{{ anchorBody }}</a>{% endcapture %}
+    {% elsif skipNoIDs == true %}
+    {% continue %}
+    {% else %}
+    {% capture listItem %}{{ anchorBody }}{% endcapture %}
     {% endif %}
 
-    {% capture jekyll_toc %}{% endcapture %}
-    {% assign orderedList = include.ordered | default: false %}
-    {% assign baseURL = include.base_url | default: include.baseurl | default: '' %}
-    {% assign skipNoIDs = include.skip_no_ids | default: include.skipNoIDs | default: false %}
-    {% assign minHeader = include.h_min | default: 1 %}
-    {% assign maxHeader = include.h_max | default: 6 %}
-    {% assign nodes = include.html | strip | split: '<h' %}
-
-    {% assign firstHeader = true %}
-    {% assign currLevel = 0 %}
-    {% assign lastLevel = 0 %}
-
-    {% capture listModifier %}{% if orderedList %}ol{% else %}ul{% endif %}{% endcapture %}
-
-    {% for node in nodes %}
-        {% if node == "" %}
-            {% continue %}
-        {% endif %}
-        
-        {% if forloop.last == true %}
-            {% continue %}
-        {% endif %}
-
-        {% assign currLevel = node | replace: '"', '' | slice: 0, 1 | times: 1 %}
-
-        {% if currLevel < minHeader or currLevel > maxHeader %}
-            {% continue %}
-        {% endif %}
-
-        {% assign _workspace = node | split: '</h' %}
-
-        {% assign _idWorkspace = _workspace[0] | split: 'id="' %}
-        {% assign _idWorkspace = _idWorkspace[1] | split: '"' %}
-        {% assign htmlID = _idWorkspace[0] %}
-
-        {% assign _classWorkspace = _workspace[0] | split: 'class="' %}
-        {% assign _classWorkspace = _classWorkspace[1] | split: '"' %}
-        {% assign htmlClass = _classWorkspace[0] %}
-
-        {% if htmlClass contains "no_toc" %}
-            {% continue %}
-        {% endif %}
-
-        {% if firstHeader %}
-            {% assign minHeader = currLevel %}
-        {% endif %}
-
-        {% capture _hAttrToStrip %}{{ _workspace[0] | split: '>' | first }}>{% endcapture %}
-        {% assign header = _workspace[0] | replace: _hAttrToStrip, '' %}
-
-        {% if include.item_class and include.item_class != blank %}
-            {% capture listItemClass %} class="{{ include.item_class | replace: '%level%', currLevel | split: '.' | join: ' ' }}"{% endcapture %}
-        {% endif %}
-
-        {% if include.submenu_class and include.submenu_class != blank %}
-            {% assign subMenuLevel = currLevel | minus: 1 %}
-            {% capture subMenuClass %} class="{{ include.submenu_class | replace: '%level%', subMenuLevel | split: '.' | join: ' ' }}"{% endcapture %}
-        {% endif %}
-
-        {% capture anchorBody %}{% if include.sanitize %}{{ header | strip_html }}{% else %}{{ header }}{% endif %}{% endcapture %}
-
-        {% if htmlID %}
-            {% capture anchorAttributes %} href="{% if baseURL %}{{ baseURL }}{% endif %}#{{ htmlID }}"{% endcapture %}
-
-            {% if include.anchor_class %}
-                {% capture anchorAttributes %}{{ anchorAttributes }} class="{{ include.anchor_class | split: '.' | join: ' ' }}"{% endcapture %}
-            {% endif %}
-
-            {% capture listItem %}<a{{ anchorAttributes }}>{{ anchorBody }}</a>{% endcapture %}
-        {% elsif skipNoIDs == true %}
-            {% continue %}
-        {% else %}
-            {% capture listItem %}{{ anchorBody }}{% endcapture %}
-        {% endif %}
-
-        {% if currLevel > lastLevel %}
-            {% capture jekyll_toc %}{{ jekyll_toc }}<{{ listModifier }}{{ subMenuClass }}>{% endcapture %}
-        {% elsif currLevel < lastLevel %}
-            {% assign repeatCount = lastLevel | minus: currLevel %}
-
-            {% for i in (1..repeatCount) %}
-                {% capture jekyll_toc %}{{ jekyll_toc }}</li></{{ listModifier }}>{% endcapture %}
-            {% endfor %}
+    {% if currLevel > lastLevel %}
+    {% capture jekyll_toc %}{{ jekyll_toc }}<{{ listModifier }}{{ subMenuClass }}>{% endcapture %}
+        {% elsif currLevel < lastLevel %} {% assign repeatCount=lastLevel | minus: currLevel %} {% for i in
+            (1..repeatCount) %} {% capture jekyll_toc %}{{ jekyll_toc }}</li>
+    </{{ listModifier }}>{% endcapture %}
+    {% endfor %}
 
-            {% capture jekyll_toc %}{{ jekyll_toc }}</li>{% endcapture %}
-        {% else %}
-            {% capture jekyll_toc %}{{ jekyll_toc }}</li>{% endcapture %}
-        {% endif %}
+    {% capture jekyll_toc %}{{ jekyll_toc }}</li>{% endcapture %}
+    {% else %}
+    {% capture jekyll_toc %}{{ jekyll_toc }}</li>{% endcapture %}
+    {% endif %}
 
-        {% capture jekyll_toc %}{{ jekyll_toc }}<li{{ listItemClass }}>{{ listItem }}{% endcapture %}
+    {% capture jekyll_toc %}{{ jekyll_toc }}<li{{ listItemClass }}>{{ listItem }}{% endcapture %}
 
         {% assign lastLevel = currLevel %}
         {% assign firstHeader = false %}
-    {% endfor %}
+        {% endfor %}
 
-    {% assign repeatCount = minHeader | minus: 1 %}
-    {% assign repeatCount = lastLevel | minus: repeatCount %}
-    {% for i in (1..repeatCount) %}
-        {% capture jekyll_toc %}{{ jekyll_toc }}</li></{{ listModifier }}>{% endcapture %}
-    {% endfor %}
+        {% assign repeatCount = minHeader | minus: 1 %}
+        {% assign repeatCount = lastLevel | minus: repeatCount %}
+        {% for i in (1..repeatCount) %}
+        {% capture jekyll_toc %}{{ jekyll_toc }}</li>
+        </{{ listModifier }}>{% endcapture %}
+        {% endfor %}
 
-    {% if jekyll_toc != '' %}
+        {% if jekyll_toc != '' %}
         {% assign rootAttributes = '' %}
         {% if include.class and include.class != blank %}
-            {% capture rootAttributes %} class="{{ include.class | split: '.' | join: ' ' }}"{% endcapture %}
+        {% capture rootAttributes %} class="{{ include.class | split: '.' | join: ' ' }}"{% endcapture %}
         {% endif %}
 
         {% if include.id and include.id != blank %}
-            {% capture rootAttributes %}{{ rootAttributes }} id="{{ include.id }}"{% endcapture %}
+        {% capture rootAttributes %}{{ rootAttributes }} id="{{ include.id }}"{% endcapture %}
         {% endif %}
 
         {% if rootAttributes %}
-            {% assign nodes = jekyll_toc | split: '>' %}
-            {% capture jekyll_toc %}<{{ listModifier }}{{ rootAttributes }}>{{ nodes | shift | join: '>' }}>{% endcapture %}
-        {% endif %}
-    {% endif %}
-{% endcapture %}{% assign tocWorkspace = '' %}{{ deprecation_warnings }}{{ jekyll_toc -}}
+        {% assign nodes = jekyll_toc | split: '>' %}
+        {% capture jekyll_toc %}<{{ listModifier }}{{ rootAttributes }}>{{ nodes | shift | join: '>' }}>{% endcapture %}
+            {% endif %}
+            {% endif %}
+            {% endcapture %}{% assign tocWorkspace = '' %}{{ deprecation_warnings }}{{ jekyll_toc -}}
diff --git a/_includes/nav.html b/_includes/nav.html
index d25cc143864..5a63da061fb 100644
--- a/_includes/nav.html
+++ b/_includes/nav.html
@@ -2,7 +2,8 @@
 <nav class="main-nav">
   <div class="container-lg mx-auto clearfix">
     <div class="float-sm-right">
-      <ul class="main-links d-flex flex-wrap flex-items-stretch flex-justify-center border-left border-bottom border-sm-0 list-style-none">
+      <ul
+        class="main-links d-flex flex-wrap flex-items-stretch flex-justify-center border-left border-bottom border-sm-0 list-style-none">
         <li class="d-inline-block border-right">
           <a class="d-block p-4" href="https://github.com/github/opensource.guide#readme">
             {{ t.nav.about }}
@@ -19,13 +20,13 @@
             <select id="language" class="form-select">
               {% assign locales = site.data.locales | sort %}
               {% for locale in locales %}
-                {% assign lang = locale[0] %}
-                {% assign locale_name = locale[1][lang].locale_name %}
-                {% if page.lang == lang %}
-                <option value="{{ lang }}" selected="selected">{{ locale_name }}</option>
-                {% else %}
-                <option value="{{ lang }}">{{ locale_name }}</option>
-                {% endif %}
+              {% assign lang = locale[0] %}
+              {% assign locale_name = locale[1][lang].locale_name %}
+              {% if page.lang == lang %}
+              <option value="{{ lang }}" selected="selected">{{ locale_name }}</option>
+              {% else %}
+              <option value="{{ lang }}">{{ locale_name }}</option>
+              {% endif %}
               {% endfor %}
             </select>
           </div>
diff --git a/_layouts/article.html b/_layouts/article.html
index 328bbcbb3ec..cd5f8c4c06a 100644
--- a/_layouts/article.html
+++ b/_layouts/article.html
@@ -12,9 +12,14 @@ <h1 class="h0-mktg lh-condensed text-center mb-3">{{ page.title }}</h1>
     <nav class="toc mb-4 mb-md-6">
       <div class="Box col-sm-8 col-md-4 col-lg-3 mx-auto">
         <a class="toc-trigger d-block text-center p-3">
-          <span class="text-black">{{ t.article.table_of_contents }}</span><svg height="18" class="octicon octicon-triangle-down ml-2 fill-blue v-align-middle icon-flip" viewBox="0 0 12 16" version="1.1" width="13" role="img"><path fill-rule="evenodd" d="M0 5l6 6 6-6z"></path></svg>
+          <span class="text-black">{{ t.article.table_of_contents }}</span><svg height="18"
+            class="octicon octicon-triangle-down ml-2 fill-blue v-align-middle icon-flip" viewBox="0 0 12 16"
+            version="1.1" width="13" role="img">
+            <path fill-rule="evenodd" d="M0 5l6 6 6-6z"></path>
+          </svg>
         </a>
-        {% include jekyll-toc.html html=content h_max=2 ordered=true class="toc-list list-style-none" item_class="border-top" anchor_class="d-block py-3 px-3" %}
+        {% include jekyll-toc.html html=content h_max=2 ordered=true class="toc-list list-style-none"
+        item_class="border-top" anchor_class="d-block py-3 px-3" %}
       </div>
     </nav>
     <div class="col-sm-10 mx-auto lh-none cover-img">
@@ -44,7 +49,8 @@ <h2 class="h2-mktg">{{ t.article.related_guides }}</h2>
       <a href="{{ article.url | relative_url }}" class="guide-cover {{ article.class }} Box height-full d-block">
 
         <div class="lh-none guide-cover-img text-center pt-4">
-          <img src="{{ site.baseurl }}/assets/images/illos/{{ article.class }}.svg" class="" alt="{{ article.title }} illustration">
+          <img src="{{ site.baseurl }}/assets/images/illos/{{ article.class }}.svg" class=""
+            alt="{{ article.title }} illustration">
         </div>
 
         <div class="flex-self-end p-4 text-center p-lg-5">
@@ -63,4 +69,4 @@ <h3 class="h3-mktg text-bold lh-condensed mb-2 text-black">
 </div>
 {% endif %}
 
-{% include footer.html %}
\ No newline at end of file
+{% include footer.html %}
diff --git a/_layouts/default.html b/_layouts/default.html
index 0688a6a99aa..7cf57d4efa6 100644
--- a/_layouts/default.html
+++ b/_layouts/default.html
@@ -1,15 +1,18 @@
 <!DOCTYPE html>
 <html lang="{{ page.lang }}">
-  {% include head.html %}
-  <body>
-    <main>
-      <div id="content">
-        {{ content }}
-      </div>
-    </main>
+{% include head.html %}
+
+<body>
+  <main>
+    <div id="content">
+      {{ content }}
+    </div>
+  </main>
+
+  <script src='{{ "/assets/js/index.js" | relative_url }}'></script>
+  <script type="text/javascript" src="https://s3.amazonaws.com/downloads.mailchimp.com/js/mc-validate.js"></script>
+  <script
+    type="text/javascript">(function ($) { window.fnames = new Array(); window.ftypes = new Array(); fnames[0] = 'EMAIL'; ftypes[0] = 'email'; fnames[1] = 'FNAME'; ftypes[1] = 'text'; fnames[2] = 'LNAME'; ftypes[2] = 'text'; }(jQuery)); var $mcj = jQuery.noConflict(true);</script>
+</body>
 
-    <script src="{{ "/assets/js/index.js" | relative_url }}"></script>
-    <script type="text/javascript" src="https://s3.amazonaws.com/downloads.mailchimp.com/js/mc-validate.js"></script>
-    <script type="text/javascript">(function($) {window.fnames = new Array(); window.ftypes = new Array();fnames[0]='EMAIL';ftypes[0]='email';fnames[1]='FNAME';ftypes[1]='text';fnames[2]='LNAME';ftypes[2]='text';}(jQuery));var $mcj = jQuery.noConflict(true);</script>
-  </body>
 </html>

From 7a58200b5ef742a10bcb725b8156fa519440fcae Mon Sep 17 00:00:00 2001
From: Mike McQuaid <mike@mikemcquaid.com>
Date: Thu, 30 Jun 2022 09:38:48 +0100
Subject: [PATCH 355/749] includes/footer: make contribute button link to blob
 not edit.

This reduces the amount of spam we see, based on other sites.
---
 _includes/footer.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_includes/footer.html b/_includes/footer.html
index 6e1932dfb6e..4e7e19b9c67 100644
--- a/_includes/footer.html
+++ b/_includes/footer.html
@@ -10,7 +10,7 @@
           <h3 class="h3-mktg mb-3">{{ t.footer.contribute.heading }}</h3>
           <p class="mb-3 p-large">{{ t.footer.contribute.description }}</p>
           <p>
-            <a data-proofer-ignore href="https://github.com/{{ site.github.repository_nwo }}/edit/main/{{ page.path }}"
+            <a data-proofer-ignore href="https://github.com/{{ site.github.repository_nwo }}/blob/main/{{ page.path }}"
               class="btn btn-outline">
               {{ t.footer.contribute.button }}
             </a>

From 5dd674da8f679805e6f8a33a1e2fc0cd600f571a Mon Sep 17 00:00:00 2001
From: Chicle <chicle@protonmail.com>
Date: Tue, 26 Jul 2022 01:13:57 +0200
Subject: [PATCH 356/749] Typo fixed in description

---
 _articles/es/finding-users.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/es/finding-users.md b/_articles/es/finding-users.md
index 3b204056e2e..bdd0d80f37d 100644
--- a/_articles/es/finding-users.md
+++ b/_articles/es/finding-users.md
@@ -1,7 +1,7 @@
 ---
 lang: es
 title: Encontrando Usuarios Para Tu Proyecto
-description: Ayuda a tu proyecto de c&oacute;digo abierto a crecer poni&oacute;ndolo en manos de usuarios satisfechos.
+description: Ayuda a tu proyecto de c&oacute;digo abierto a crecer poni&eacute;ndolo en manos de usuarios satisfechos.
 class: finding
 order: 3
 image: /assets/images/cards/finding.png

From dcab90affae2929d041cb498b4cbd912322092a0 Mon Sep 17 00:00:00 2001
From: Ash Wilson <smashwilson@github.com>
Date: Tue, 26 Jul 2022 10:50:27 -0400
Subject: [PATCH 357/749] Lock html-proofer version

---
 Gemfile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile b/Gemfile
index ca9b7428d0e..a76c33fb51c 100644
--- a/Gemfile
+++ b/Gemfile
@@ -3,6 +3,6 @@ source "https://rubygems.org"
 gem "github-pages", group: :jekyll_plugins
 
 group :test do
-  gem "html-proofer"
+  gem "html-proofer", "~> 3.19.4"
   gem "rake"
 end

From 94d93d09b965f2c5a33a8c244ccd1cf1641051a0 Mon Sep 17 00:00:00 2001
From: Maximilian Techritz <vemaximilian.t@gmail.com>
Date: Thu, 4 Aug 2022 18:18:36 +0200
Subject: [PATCH 358/749] Fix gender-sensitive phrase

---
 _articles/de/metrics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/de/metrics.md b/_articles/de/metrics.md
index 57c443e2195..0ae3ec4be40 100644
--- a/_articles/de/metrics.md
+++ b/_articles/de/metrics.md
@@ -118,7 +118,7 @@ Unresponsive Betreuer\*innen werden zum Flaschenhals für Open-Source-Projekte.
 
 [Untersuchungen von Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) deuten darauf hin, dass eine schnelle und freundliche Reaktion der Maintainer\*innen Mitwirkende zu weiteren Beiträgen ermutigt.
 
-Überlegen Sie, wie lange es dauert, bis Sie (oder ein anderer Betreuer) auf Beiträge reagieren, egal ob es sich um ein Issue oder ein Pull Request handelt. Die Reaktion muss keine Maßnahme sein; Auch ein einfaches : _"Vielen Dank für diesen Beitrag! Ich werde ihn innerhalb einer Woche überprüfen."_ zählt.
+Überlegen Sie, wie lange es dauert, bis Sie (oder ein\*e andere\*r Betreuer\*in) auf Beiträge reagieren, egal ob es sich um ein Issue oder ein Pull Request handelt. Die Reaktion muss keine Maßnahme sein; Auch ein einfaches : _"Vielen Dank für diesen Beitrag! Ich werde ihn innerhalb einer Woche überprüfen."_ zählt.
 
 Sie können auch die Zeit messen, die benötigt wird, um zwischen den einzelnen Phasen des Beitragsprozesses zu wechseln, wie z.B:
 

From aae1d5b4bce890b71c8a127013f75687d2be959d Mon Sep 17 00:00:00 2001
From: Vik <63919734+ViktorOn@users.noreply.github.com>
Date: Thu, 4 Aug 2022 22:17:29 +0300
Subject: [PATCH 359/749] Update legal.md

---
 _articles/ru/legal.md | 58 +++++++++++++++++++++----------------------
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md
index 2a5272247ee..c19920212fc 100644
--- a/_articles/ru/legal.md
+++ b/_articles/ru/legal.md
@@ -12,19 +12,19 @@ related:
 
 ## Понимание юридических последствий открытого исходного кода
 
-Поделиться своим творчеством со всем миром может быть захватывающим и полезным опытом. Это также может означать множество юридических аспектов, о которых вы даже не подозревали. К счастью, вам не нужно начинать с нуля. Мы позаботимся о ваших юридических потребностях. (Прежде чем углубляться, обязательно прочтите наш [отказ от ответственности](/notices/).)
+Поделиться своим творчеством со всем миром может быть захватывающим и полезным опытом. Это также может означать множество юридических аспектов, о которых вы даже не подозревали. К счастью, вам не нужно начинать с нуля. Мы позаботились о ваших юридических потребностях. (Прежде чем углубляться, обязательно прочтите наш [отказ от ответственности](/notices/).)
 
 ## Почему людей так волнует правовая сторона открытого кода?
 
-Рад, что вы спросили! Когда вы создаете творческую работу (например, текст, графику или код), эта работа по умолчанию находится под исключительным авторским правом. То есть закон предполагает, что как автор вашей работы вы имеете право голоса в отношении того, что другие могут с ней делать.
+Рады, что вы спросили! Когда вы выполняете творческую работу (например, текст, графику или код), эта работа по умолчанию находится под исключительным авторским правом. То есть закон предполагает, что как автор своей работы вы имеете право голоса в отношении того, что другие могут с ней делать.
 
-В общем, это означает, что никто другой не может использовать, копировать, распространять или изменять вашу работу, не подвергаясь риску изъятия, замены или судебного разбирательства.
+В общем, это означает, что никто другой не может использовать, копировать, распространять или изменять вашу работу, не подвергаясь риску разбирательства, изъятия или судебного разбирательства.
 
-Однако открытый исходный код - это необычная ситуация, поскольку автор ожидает, что другие будут использовать, изменять и делиться работой. Но поскольку юридическое значение по умолчанию по-прежнему является исключительным авторским правом, вам нужна лицензия, в которой явно указаны эти разрешения.
+Однако открытый исходный код — это необычная ситуация, поскольку автор ожидает, что другие будут использовать, изменять и делиться работой. Но поскольку юридически законным по умолчанию по-прежнему остется исключительное авторское право, вам нужна лицензия, в которой явно указаны эти разрешения.
 
-Если вы не примените лицензию с открытым исходным кодом, каждый, кто вносит свой вклад в ваш проект, также становится эксклюзивным правообладателем своей работы. Это означает, что никто не может использовать, копировать, распространять или изменять их материалы - и эти «никто» включает и вас.
+Если вы не примените лицензию для открытого исходного кода, каждый, кто вносит свой вклад в ваш проект, также становится эксклюзивным правообладателем своей работы. Это означает, что никто не может использовать, копировать, распространять или изменять их материалы — и этот «никто» включает вас.
 
-Наконец, ваш проект может иметь зависимости от лицензионных требований, о которых вы не знали. Сообщество вашего проекта или политика вашего работодателя также могут требовать от вашего проекта использования определенных лицензий с открытым исходным кодом. Мы рассмотрим эти ситуации ниже.
+Наконец, ваш проект может иметь зависимости от лицензионных требований, о которых вы не знали. Сообщество вашего проекта или политика вашего работодателя также могут требовать от вашего проекта использования определенных лицензий открытого исходного кода. Мы рассмотрим эти ситуации ниже.
 
 ## Открыты ли общедоступные проекты GitHub?
 
@@ -32,15 +32,15 @@ related:
 
 ![Создать репозиторий](/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://help.github.com/en/github/site-policy/github-terms-of-service#3-owner-of-content-right-to-post-and-license-grants), которые позволяют другим просматривать и делать ответвление (fork) вашего проекта. Но в остальном ваша работа не имеет разрешений.
 
-Если вы хотите, чтобы другие могли использовать, распространять, изменять или вносить свой вклад в ваш проект, вам необходимо включить лицензию с открытым исходным кодом. Например, кто-то не может законно использовать какую-либо часть вашего проекта GitHub в своем коде, даже если он общедоступен, если вы явно не дадите ему на это право.
+Если вы хотите, чтобы другие могли использовать, распространять, изменять или вносить свой вклад в ваш проект, вам необходимо включить лицензию открытого исходного кода. Например, кто-то не может законно использовать какую-либо часть вашего проекта GitHub в своем коде, даже если он общедоступен, если вы явно не дадите ему на это право.
 
 ## Просто дайте мне ЧтоБыТоНиБыло, что нужно для защиты моего проекта.
 
-Вам повезло, потому что сегодня лицензии с открытым исходным кодом стандартизированы и просты в использовании. Вы можете скопировать и вставить существующую лицензию прямо в свой проект.
+Вам повезло, потому что сегодня лицензии открытого исходного кода стандартизированы и просты в использовании. Вы можете скопировать и вставить существующую лицензию прямо в свой проект.
 
-[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) и [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) - самые популярные лицензии с открытым исходным кодом, но есть и другие варианты на выбор. Вы можете найти полный текст этих лицензий и инструкции по их использованию на сайте [choosealicense.com](https://choosealicense.com/).
+[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/).
 
@@ -52,29 +52,29 @@ related:
   </p>
 </aside>
 
-## Какая лицензия с открытым исходным кодом подходит для моего проекта?
+## Какая лицензия открытого исходного кода подходит для моего проекта?
 
-Если вы начинаете с чистого листа, трудно ошибиться с [лицензией MIT](https://choosealicense.com/licenses/mit/). Он короткий, очень простой для понимания и позволяет любому делать всё, что угодно, если у него есть копия лицензии и упоминание вашего авторства. Вы сможете выпустить проект под другой лицензией, если понадобится.
+Если вы начинаете с чистого листа, трудно ошибиться с [лицензией MIT](https://choosealicense.com/licenses/mit/). Она короткая, очень простая для понимания и позволяет любому делать всё, что угодно, если у него есть копия лицензии и упоминание вашего авторского права. Вы сможете выпустить проект под другой лицензией, если понадобится.
 
 В противном случае выбор правильной лицензии для открытого исходного кода вашего проекта зависит от ваших целей.
 
-Ваш проект, скорее всего, имеет (или будет иметь) **зависимости**. Например, если вы открываете исходный код проекта Node.js, вы, вероятно, будете использовать библиотеки из диспетчера пакетов узлов (npm). Каждая из этих библиотек, от которых вы зависите, будет иметь собственную лицензию с открытым исходным кодом. Если каждая из их лицензий является «разрешающей» (дает общедоступное разрешение на использование, изменение и совместное использование без каких-либо условий для последующего лицензирования), вы можете использовать любую лицензию, которую хотите. Общие разрешительные лицензии включают MIT, Apache 2.0, ISC и BSD.
+Ваш проект, скорее всего, имеет (или будет иметь) **зависимости**. Например, если вы откроете исходный код проекта Node.js, вы, вероятно, будете использовать библиотеки из Node Package Manager (npm). Каждая из этих библиотек, от которых вы зависите, будет иметь собственную лицензию открытого исходного кода. Если каждая из их лицензий является «разрешающей» (дает общедоступное разрешение на использование, изменение и совместное использование без каких-либо условий для последующего лицензирования), вы можете использовать любую лицензию, которую хотите. Общие разрешительные лицензии включают MIT, Apache 2.0, ISC и BSD.
 
-С другой стороны, если какая-либо из лицензий ваших зависимостей является «строгим авторским левом» (strong copyleft) (также дает такие же общедоступные разрешения при условии использования той же лицензии ниже по течению), тогда ваш проект должен будет использовать ту же лицензию. Общие лицензии с сильным авторским левом включают GPLv2, GPLv3 и AGPLv3.
+С другой стороны, если какая-либо из лицензий ваших зависимостей является «строгим авторским левом» (strong copyleft) (также дает такие же общедоступные разрешения при условии использования той же лицензии в дальнейшем), тогда ваш проект должен будет использовать ту же лицензию. Общие лицензии со строгим авторским левом включают GPLv2, GPLv3 и AGPLv3.
 
 Вы также можете рассмотреть **сообщества**, которые, как вы надеетесь, будут использовать и вносить свой вклад в ваш проект:
 
-* **Вы хотите, чтобы ваш проект использовался в качестве зависимости другими проектами?** Вероятно, лучше всего использовать самую популярную лицензию в вашем соответствующем сообществе. Например, [MIT](https://choosealicense.com/licenses/mit/) - самая популярная лицензия для [библиотек npm](https://libraries.io/search?platforms=NPM).
+* **Вы хотите, чтобы ваш проект использовался в качестве зависимости другими проектами?** Вероятно, лучше всего использовать самую популярную лицензию в вашем соответствующем сообществе. Например, [MIT](https://choosealicense.com/licenses/mit/) — самая популярная лицензия для [библиотек npm](https://libraries.io/search?platforms=NPM).
 * **Вы хотите, чтобы ваш проект понравился крупным предприятиям?** Крупному бизнесу, скорее всего, потребуется явная патентная лицензия от всех участников. В этом случае [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) поможет вам (и им).
 * **Вы хотите, чтобы ваш проект привлек участников, которые не хотят, чтобы их вклад использовался в программном обеспечении с закрытым исходным кодом?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) или (если они также не хотят участвовать в службах с закрытым исходным кодом) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) подойдет.
 
-Ваша **компания** может иметь особые лицензионные требования для своих проектов с открытым исходным кодом. Например, может потребоваться разрешительная лицензия, чтобы компания могла использовать ваш проект в продукте компании с закрытым исходным кодом. Или ваша компания может потребовать сильную лицензию с авторским левом и дополнительное соглашение с участниками (см. Ниже), чтобы только ваша компания и никто другой могли использовать ваш проект в программном обеспечении с закрытым исходным кодом. Или у вашей компании могут быть определенные потребности, связанные со стандартами, социальной ответственностью или прозрачностью, любая из которых может потребовать определенной стратегии лицензирования. Поговорите с юридическим отделом вашей [компании](#что-нужно-знать-юридическому-отделу-моей-компании).
+Ваша **компания** может иметь особые лицензионные требования для проектов с открытым исходным кодом. Например, может потребоваться разрешительная лицензия, чтобы компания могла использовать ваш проект в продукте компании с закрытым исходным кодом. Или ваша компания может потребовать строгую лицензию с авторским левом и дополнительное соглашение с участниками (см. ниже), чтобы только ваша компания и никто другой могли использовать ваш проект в программном обеспечении с закрытым исходным кодом. Или у вашей компании могут быть определенные потребности, связанные со стандартами, социальной ответственностью или прозрачностью, любая из которых может потребовать определенной стратегии лицензирования. Поговорите с [юридическим отделом вашей компании](#что-нужно-знать-юридическому-отделу-моей-компании).
 
-Когда вы создаете новый проект на GitHub, вам предоставляется возможность выбрать лицензию. Включение одной из упомянутых выше лицензий сделает ваш проект GitHub открытым. Если вы хотите увидеть другие варианты, посетите [choosealicense.com](https://choosealicense.com), чтобы найти подходящую лицензию для своего проекта, даже если это [не программное обеспечение](https://choosealicense.com/non-software/).
+Когда вы создаете новый проект на GitHub, вам предоставляется возможность выбрать лицензию. Включение одной из упомянутых выше лицензий сделает ваш проект на GitHub открытым. Если вы хотите увидеть другие варианты, посетите [choosealicense.com](https://choosealicense.com), чтобы найти подходящую лицензию для своего проекта, даже если это [не программное обеспечение](https://choosealicense.com/non-software/).
 
 ## Что, если я хочу изменить лицензию своего проекта?
 
-Для большинства проектов не требуется менять лицензии. Но иногда обстоятельства меняются.
+Большинству проектов не потребуется менять лицензии. Но иногда обстоятельства меняются.
 
 Например, по мере роста вашего проекта он добавляет зависимости или пользователей, или ваша компания меняет стратегии, для любой из которых может потребоваться другая лицензия. Кроме того, если вы пренебрегали лицензированием своего проекта с самого начала, добавление лицензии фактически аналогично изменению лицензий. При добавлении или изменении лицензии на проект необходимо учитывать три основных момента:
 
@@ -82,17 +82,17 @@ related:
 
 **Существующая лицензия вашего проекта.** Если существующая лицензия вашего проекта совместима с лицензией, на которую вы хотите перейти, вы можете просто начать использовать новую лицензию. Это потому, что если лицензия A совместима с лицензией B, вы будете соблюдать условия A, соблюдая условия B (но не обязательно наоборот). Поэтому, если вы в настоящее время используете разрешительную лицензию (например, MIT), вы можете перейти на лицензию с дополнительными условиями, при условии, что вы сохраняете копию лицензии MIT и любые связанные уведомления об авторских правах (т.е. продолжаете соблюдать минимальные условия лицензии MIT). Но если ваша текущая лицензия не разрешающая (например, авторское лево или у вас нет лицензии) и вы не являетесь единственным владельцем авторских прав, вы не можете просто изменить лицензию вашего проекта на MIT. По сути, с разрешающей лицензией правообладатели проекта заранее дали разрешение на изменение лицензий.
 
-**Существующие правообладатели вашего проекта.** Если вы являетесь единственным участником своего проекта, то вы или ваша компания являетесь единственным правообладателем проекта. Вы можете добавить или изменить любую лицензию, которую захотите вы или ваша компания. В противном случае могут быть другие правообладатели, с которыми вам потребуется согласие для изменения лицензий. Кто они? Люди, у которых есть коммиты в вашем проекте, - хорошее место для начала. Но в некоторых случаях авторские права принадлежат работодателям этих людей. В некоторых случаях люди будут вносить только минимальный вклад, но не существует жесткого правила, согласно которому вклады с использованием определенного количества строк кода не подлежат авторскому праву. Что делать? Это зависит. Для относительно небольшого и молодого проекта может оказаться целесообразным убедить всех существующих участников согласиться на изменение лицензии в issue или pull request. Для крупных и долгоживущих проектов вам, возможно, придется искать множество участников и даже их наследников. Mozilla потребовались годы (2001-2006), чтобы перелицензировать Firefox, Thunderbird и сопутствующее программное обеспечение.
+**Существующие правообладатели вашего проекта.** Если вы являетесь единственным участником своего проекта, то вы или ваша компания являетесь единственным правообладателем проекта. Вы можете добавить или изменить любую лицензию, которую захотите вы или ваша компания. В противном случае могут быть другие правообладатели, с которыми вам потребуется согласие для изменения лицензий. Кто они? Люди, у которых есть коммиты в вашем проекте, — хорошее место для начала. Но в некоторых случаях авторские права принадлежат работодателям этих людей. В некоторых случаях люди будут вносить только минимальный вклад, но не существует жесткого правила, согласно которому вклады с использованием определенного количества строк кода не подлежат авторскому праву. Что делать? Это зависит. Для относительно небольшого и молодого проекта может оказаться целесообразным убедить всех существующих участников согласиться на изменение лицензии в ишью или пул-реквесте. Для крупных и долгоживущих проектов вам, возможно, придется искать множество участников и даже их наследников. Mozilla потребовались годы (2001-2006), чтобы перелицензировать Firefox, Thunderbird и сопутствующее программное обеспечение.
 
 В качестве альтернативы вы можете попросить участников заранее согласиться (посредством дополнительного соглашения с участниками - см. Ниже) на определенные изменения лицензии при определенных условиях, помимо тех, которые разрешены вашей существующей лицензией с открытым исходным кодом. Это немного меняет сложность изменения лицензий. Вам заранее понадобится дополнительная помощь юристов, и вы все равно захотите четко общаться с заинтересованными сторонами вашего проекта при изменении лицензии.
 
 ## Требуется ли для моего проекта дополнительное соглашение с участниками?
 
-Возможно нет. Для подавляющего большинства проектов лицензия для открытого исходного кода неявно служит как входящей (от участников), так и исходящей (для других участников и пользователей) лицензией. Если ваш проект размещен на 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://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
 
-Дополнительное соглашение с участником, часто называемое лицензионным соглашением участника (CLA), может создавать административную работу для сопровождающих проект. Сколько работы добавляет соглашение, зависит от проекта и реализации. Простое соглашение может требовать, чтобы участники подтвердили одним щелчком мыши, что у них есть права, необходимые для внесения вклада в соответствии с лицензией проекта с открытым исходным кодом. Более сложное соглашение может потребовать юридической проверки и подписания со стороны работодателей участников.
+Дополнительное соглашение с участником, часто называемое лицензионным соглашением участника (CLA), может создавать административную работу для сопровождающих проект. Сколько работы добавляет соглашение, зависит от проекта и реализации. Простое соглашение может требовать, чтобы участники подтвердили одним щелчком мыши, что у них есть права, необходимые для внесения вклада в соответствии с лицензией проекта с открытым исходным кодом. Более сложное соглашение может потребовать юридической проверки и подписи со стороны работодателей участников.
 
-Кроме того, добавление «бумажной работы», которая, по мнению некоторых, является ненужной, трудной для понимания или несправедливой (когда получатель соглашения получает больше прав, чем участники или общественность через лицензию проекта с открытым исходным кодом), дополнительное соглашение с участниками может быть воспринято как недружественное сообществу проекта.
+Кроме того, добавление «бумажной работы», которая, по мнению некоторых, является ненужной, трудной для понимания или несправедливой (когда получатель соглашения получает больше прав, чем участники или общественность через лицензию проекта с открытым исходным кодом), дополнительное соглашение с участниками может быть воспринято как недружественное к сообществу проекта.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
@@ -105,7 +105,7 @@ related:
 Вот некоторые ситуации, когда вы можете захотеть рассмотреть вопрос о дополнительном соглашении с участниками для вашего проекта:
 
 * Ваши юристы хотят, чтобы все участники явным образом приняли (подписать, онлайн или офлайн) условия вклада, возможно, потому, что они считают, что самой лицензии с открытым исходным кодом недостаточно (даже если это так!). Если это единственная проблема, должно быть достаточно соглашения с участником, подтверждающего лицензию проекта с открытым исходным кодом. [Лицензионное соглашение с индивидуальным участником jQuery](https://contribute.jquery.org/CLA/) является хорошим примером облегченного соглашения с дополнительным участником.
-* Вы или ваши юристы хотите, чтобы разработчики доказали, что каждое совершаемое ими действие санкционировано. Требование [Сертификат разработчика](https://developercertificate.org/) - это количество проектов, которые этого достигают. Например, сообщество Node.js [использует](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо этого](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) их предыдущего CLA. Простым вариантом автоматизации принудительного применения DCO в вашем репозитории является [DCO Probot](https://github.com/probot/dco).
+* Вы или ваши юристы хотите, чтобы разработчики доказали, что каждое совершаемое ими действие санкционировано. Требование [Сертификата разработчика](https://developercertificate.org/) — это количество проектов, которые это обеспечивают. Например, сообщество Node.js [использует](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) их предыдущего CLA. Простым вариантом автоматизации принудительного применения DCO в вашем репозитории является [DCO Probot](https://github.com/probot/dco).
 * В вашем проекте используется лицензия с открытым исходным кодом, которая не включает прямую выдачу патента (например, MIT), и вам нужен патент от всех участников, некоторые из которых могут работать в компаниях с большими портфелями патентов, которые могут быть использованы для вашего таргетинга. или других участников и пользователей проекта. [Лицензионное соглашение с индивидуальным участником Apache](https://www.apache.org/licenses/icla.pdf) является часто используемым соглашением с дополнительным участником, в котором выдача патента является копией той, которая содержится в лицензии Apache License 2.0.
 * Ваш проект находится под лицензией с авторским левом, но вам также необходимо распространять проприетарную версию проекта. Вам потребуется, чтобы каждый участник назначил вам авторские права или предоставил вам (но не общественности) разрешительную лицензию. [Соглашение с участником MongoDB](https://www.mongodb.com/legal/contributor-agreement) является примером такого типа соглашения.
 * Вы думаете, что вашему проекту может потребоваться изменить лицензии в течение его срока службы, и хотите, чтобы участники заранее согласились на такие изменения.
@@ -126,26 +126,26 @@ related:
 
 * **Патенты:** Подает ли ваша компания заявку на патент, открытый исходный код которого ваш проект будет представлять собой [публичное раскрытие](https://en.wikipedia.org/wiki/Public_disclosure)? К сожалению, вас могут попросить подождать (или, возможно, компания пересмотрит мудрость приложения). Если вы ожидаете участия в своем проекте сотрудников компаний с большим портфелем патентов, ваша группа юристов может пожелать, чтобы вы использовали лицензию с явным предоставлением патента от участников (например, Apache 2.0 или GPLv3) или дополнительное соглашение с участником (см. выше).
 
-* **Торговые марки:** Дважды проверьте, что название вашего проекта [не конфликтует с существующими торговыми марками](../starting-a-project/#конфликт-имён). Если вы используете в проекте товарные знаки собственной компании, убедитесь, что это не вызывает конфликтов. [FOSSmarks](http://fossmarks.org/) - это практическое руководство по пониманию товарных знаков в контексте проектов с бесплатным и открытым исходным кодом.
+* **Торговые марки:** Дважды проверьте, что название вашего проекта [не конфликтует с существующими торговыми марками](../starting-a-project/#конфликт-имён). Если вы используете в проекте товарные знаки собственной компании, убедитесь, что это не вызывает конфликтов. [FOSSmarks](http://fossmarks.org/) — это практическое руководство по пониманию товарных знаков в контексте проектов с бесплатным и открытым исходным кодом.
 
-* **Конфиденциальность:** Собирает ли ваш проект данные о пользователях? "Звонит домой" на серверы компании? Ваш юридический отдел может помочь вам в соблюдении политики компании и внешних нормативных требований.
+* **Конфиденциальность:** Собирает ли ваш проект данные о пользователях? «Звонит домой» на серверы компании? Ваш юридическая команда может помочь вам в соблюдении политики компании и внешних нормативных требований.
 
 Если вы выпускаете первый проект своей компании с открытым исходным кодом, вышеуказанного более чем достаточно для выполнения (но не волнуйтесь, большинство проектов не должны вызывать серьезных проблем).
 
 В долгосрочной перспективе ваша команда юристов может сделать больше, чтобы помочь компании получить больше от своего участия в проектах с открытым исходным кодом и оставаться в безопасности:
 
-* **Политики участия сотрудников:** Рассмотрите возможность разработки корпоративной политики, определяющей, как ваши сотрудники вносят вклад в проекты с открытым исходным кодом. Четкая политика уменьшит путаницу среди ваших сотрудников и поможет им внести свой вклад в проекты с открытым исходным кодом в интересах компании, будь то в рамках своей работы или в свободное время. Хорошим примером является политика Rackspace [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Политики участия сотрудников:** Рассмотрите возможность разработки корпоративной политики, определяющей, как ваши сотрудники вносят вклад в проекты с открытым исходным кодом. Четкая политика уменьшит путаницу среди ваших сотрудников и поможет им внести свой вклад в проекты с открытым исходным кодом в интересах компании, будь то в рамках своей работы или в свободное время. Хорошим примером является политика Rackspace [Типовая политика в отношении интеллектуальной собственности и открытого исходного кода](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
 Предоставление IP-адреса, связанного с патчем, создает базу знаний и репутацию сотрудника. Это показывает, что компания инвестирует в развитие этого сотрудника, и создает ощущение полномочий и автономии. Все эти преимущества также приводят к повышению морального духа и лучшему удержанию сотрудников.  
 <p markdown="1" class="pquote-credit">
-— @vanl, ["Типовая IP-политика и политика участия в открытым исходном коде"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["Типовая политика в отношении интеллектуальной собственности и открытого исходного кода"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
-* **Что выпустить:** [(Почти) все?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Если ваша юридическая группа понимает и вкладывается в стратегию открытого исходного кода вашей компании, они смогут лучше помочь, а не препятствовать вашим усилиям.
-* **Соответствие:** Даже если ваша компания не выпускает проекты с открытым исходным кодом, она использует чужое программное обеспечение с открытым исходным кодом. [Осведомленность и процесс](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) могут предотвратить головные боли, задержки продукта, и судебные иски.
+* **Что выпустить:** [(Почти) все](http://tom.preston-werner.com/2011/11/22/open-source-everything.html)? Если ваша юридическая команда понимает и вкладывается в стратегию открытого исходного кода вашей компании, они смогут намного лучше помочь, чем препятствовать вашим усилиям.
+* **Соответствие:** Даже если ваша компания не выпускает проекты с открытым исходным кодом, она использует чужое программное обеспечение с открытым исходным кодом. [Осведомленность и процесс](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) могут предотвратить головные боли, задержки продукта и судебные иски.
 
 <aside markdown="1" class="pquote">
 Организации должны иметь лицензию и стратегию соответствия, которая подходит как для категорий \["разрешающий", так и "авторское лево"\]. Это начинается с записи условий лицензирования, которые применяются к программному обеспечению с открытым исходным кодом, которое вы используете, включая субкомпоненты и зависимости.

From a6bc8e12e1c2419d0a705a9abd20424f1ab5e7a6 Mon Sep 17 00:00:00 2001
From: Vik <63919734+ViktorOn@users.noreply.github.com>
Date: Wed, 10 Aug 2022 20:34:37 +0300
Subject: [PATCH 360/749] Update building-community.md

---
 _articles/ru/building-community.md | 86 +++++++++++++++---------------
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/_articles/ru/building-community.md b/_articles/ru/building-community.md
index ed08148b710..1c0184cc7d8 100644
--- a/_articles/ru/building-community.md
+++ b/_articles/ru/building-community.md
@@ -1,7 +1,7 @@
 ---
 lang: ru
 title: Создание дружного сообщества
-description: Создание сообщества, которое побуждает людей использовать ваш проект, вносить свой вклад и пропагандировать его.
+description: Создание сообщества, которое побуждает людей использовать, вносить свой вклад и распространять ваш проект.
 class: building
 order: 4
 image: /assets/images/cards/building.png
@@ -14,34 +14,34 @@ related:
 
 Вы запустили свой проект, распространяете информацию, и люди пробуют его. Потрясающе! Как убедить их остаться?
 
-Доброжелательное сообщество - это инвестиция в будущее и репутацию вашего проекта. Если ваш проект только начинает получать вклад посторонних разработчиков, начните с того, чтобы дать первым участникам положительный опыт, чтобы им хотелось возвращаться.
+Доброжелательное сообщество — это инвестиция в будущее и репутацию вашего проекта. Если ваш проект только начинает получать сторонний вклад, начните с того, чтобы дать первым участникам положительный опыт, чтобы им хотелось возвращаться.
 
 ### Сделайте так, чтобы люди чувствовали себя желанными гостями
 
-Один из способов подумать о сообществе вашего проекта - это то, что @MikeMcQuaid называет [воронкой участника](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+Один из способов подумать о сообществе вашего проекта — это то, что @MikeMcQuaid называет [воронкой участников](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
 
-![воронка участника](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+![Воронка участников](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
 
-Создавая свое сообщество, подумайте, как кто-то наверху воронки (потенциальный пользователь) теоретически может добраться до конца (активный сопровождающий). Ваша цель - уменьшить трение на каждом этапе взаимодействия с участником. Когда у людей легкие победы, они будут чувствовать стимул делать больше.
+Создавая свое сообщество, подумайте, как кто-то наверху воронки (потенциальный пользователь) теоретически может добраться до конца вниз (активный сопровождающий). Ваша цель — уменьшить трение на каждом этапе взаимодействия с участником. Когда у людей легкие победы, они будут чувствовать стимул делать больше.
 
 Начните с вашей документации:
 
-* **Облегчите использование вашего проекта для любого желающего.** [Дружественное README](../starting-a-project/#написание-readme) а понятные примеры кода помогут любому, кто прикоснется к вашему проекту, начать работу.
+* **Облегчите использование вашего проекта для любого желающего.** [Дружественное README](../starting-a-project/#написание-readme) и понятные примеры кода помогут любому, кто заинтересуется вашим проектом, начать работу.
 * **Объясните, как участвовать**, используя [руководство для участников](../starting-a-project/#написание-руководства-для-участников) и оперативно отвечая на вопросы (issues).
-* **Хорошие первые вопросы (issues)**: чтобы помочь новым участникам начать работу, явно рассмотрите [ярлыки вопросов, которые достаточно просты для начинающих](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Затем Гитхаб выведет эти вопросы в различных местах платформы, увеличивая полезный вклад и уменьшая трение пользователей, решающих проблемы, которые слишком сложны для их уровня.
+* **Хорошие первые вопросы (issues)**: чтобы помочь новым участникам начать работу, явно рассмотрите [ярлыки вопросов, которые достаточно просты для начинающих](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Затем GitHub выведет эти вопросы в различных местах платформы, увеличивая полезный вклад и уменьшая трение пользователей, решающих проблемы, которые слишком сложны для их уровня.
 
-[Обзор открытого исходного кода GitHub за 2017 год](http://opensourcesurvey.org/2017/) показал, что неполная или запутанная документация является самой большой проблемой для пользователей открытого исходного кода. Хорошая документация побуждает людей взаимодействовать с вашим проектом. В конце концов, кто-то откроет вопрос (issue) или запрос на изменение (pull request). Используйте эти взаимодействия как возможности для продвижения их по воронке.
+[Обзор открытого исходного кода GitHub за 2017 год](http://opensourcesurvey.org/2017/) показал, что неполная или запутанная документация является самой большой проблемой для пользователей открытого исходного кода. Хорошая документация побуждает людей взаимодействовать с вашим проектом. В конце концов, кто-то откроет вопрос или пул-реквест. Используйте эти взаимодействия как возможности для продвижения их по воронке.
 
 * **Когда кто-то новый попадает в ваш проект, поблагодарите его за проявленный интерес!** Достаточно одного негативного опыта, чтобы кто-то не захотел возвращаться.
 * **Будьте отзывчивы.** Если вы не отвечаете на их вопрос в течение месяца, скорее всего, они уже забыли о вашем проекте.
 * **Будьте открыты в отношении помощи, которую вы примете.** Многие участники начинают с отчета об ошибке или небольшого исправления. Есть [много способов внести свой вклад](../how-to-contribute/#что-значит-внести-свой-вклад) в проект. Позвольте людям помочь так, как они хотят помочь.
-* **Если есть предложение, с которым вы не согласны,** поблагодарите их за идею и [объясните, почему](../best-practices/#научитесь-говорить-нет), это не вписывается в рамки проекта со ссылкой на соответствующую документацию, если она у вас есть.
+* **Если есть предложение, с которым вы не согласны,** поблагодарите их за идею и [объясните, почему](../best-practices/#научитесь-говорить-нет) она не вписывается в рамки проекта, дав ссылку на соответствующую документацию, если она у вас есть.
 
 <aside markdown = "1" class = "pquote">
   <img src = "https://avatars.githubusercontent.com/mikeal?s=180" class = "pquote-avatar" alt = "avatar">
-  Некоторым легче внести свой вклад в развитие открытого исходного кода, чем другим. Есть много опасений, что на них будут кричать за то, что они что-то не делают правильно или просто не подходят. (...) Предоставляя участникам возможность вносить свой вклад с очень низким уровнем технической подготовки (документация, разметка веб-контента и т.д.), вы можете значительно сократить эти проблемы.
+  Некоторым легче внести свой вклад в развитие открытого исходного кода, чем другим. Есть много опасений, что на них будут кричать за то, что они делают что-то неправильно или просто не подходят. (...) Предоставляя участникам возможность вносить свой вклад с очень низким уровнем технической подготовки (документация, разметка веб-контента и т. д.), вы можете значительно сократить эти проблемы.
   <p markdown = "1" class = "pquote-credit">
-- @mikeal, [«Расширение базы участников в современном открытом исходном коде»](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+— @mikeal, [«Расширение базы участников в современном открытом исходном коде»](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
   </p>
 </aside>
 
@@ -55,15 +55,15 @@ related:
   <img src = "https://avatars.githubusercontent.com/janl?s=180" class = "pquote-avatar" alt = "avatar">
   Вы когда-нибудь были на (техническом) мероприятии, где вы никого не знали, но все остальные, казалось, собирались группами и болтали, как старые друзья? (...) Теперь представьте, что вы хотите внести свой вклад в проект с открытым исходным кодом, но вы не понимаете, почему и как это происходит.
   <p markdown = "1" class = "pquote-credit">
-- @janl, [«Устойчивый открытый исходный код»](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, [«Устойчивый открытый исходный код»](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
 Когда вы начинаете новый проект, может показаться естественным сохранить конфиденциальность своей работы. Но проекты с открытым исходным кодом процветают, когда вы публично документируете свой процесс.
 
-Когда вы что-то записываете, на каждом этапе пути может участвовать больше людей. Вы можете получить помощь в том, о чем даже не подозревали.
+Когда вы что-то записываете, больше людей могут участвовать на каждом этапе пути. Вы можете получить помощь в том, о чем даже не подозревали.
 
-Запись означает больше, чем просто техническая документация. Каждый раз, когда вы чувствуете желание записать что-то или обсудить свой проект в частном порядке, спросите себя, можете ли вы сделать его общедоступным.
+Запись означает больше, чем просто техническая документация. Каждый раз, когда вы чувствуете желание записать что-то или обсудить свой проект в частном порядке, спросите себя, можете ли вы сделать это публично.
 
 Будьте прозрачны в отношении дорожной карты вашего проекта, типов вкладов, которые вы ищете, того, как оцениваются вклады, или почему вы приняли определенные решения.
 
@@ -71,7 +71,7 @@ related:
 
 Для встреч рассмотрите возможность публикации заметок или выводов по актуальному вопросу. Отзывы, которые вы получите от такого уровня прозрачности, могут вас удивить.
 
-Документирование всего относится и к вашей работе. Если вы работаете над существенным обновлением своего проекта, поместите его в запрос на перенос и отметьте его как незавершенное (WIP). Таким образом, другие люди могут почувствовать себя вовлеченными в процесс на ранней стадии.
+Документирование всего относится и к вашей работе. Если вы работаете над существенным обновлением своего проекта, поместите его в пул-реквест и отметьте как незавершенное (WIP). Таким образом, другие люди могут почувствовать себя вовлеченными в процесс на ранней стадии.
 
 ### Будьте отзывчивы
 
@@ -79,11 +79,11 @@ related:
 
 Постарайтесь оперативно реагировать, когда кто-то задаёт вопрос, отправляет запрос на перенос или задает вопрос о вашем проекте. Если вы ответите быстро, люди почувствуют себя участниками диалога и будут с большим энтузиазмом участвовать.
 
-Даже если вы не можете сразу просмотреть запрос, заблаговременное признание его поможет повысить вовлеченность. Вот как @tdreyno ответил на запрос на перенос [Middleman](https://github.com/middleman/middleman/pull/1466):
+Даже если вы не можете сразу просмотреть запрос, заблаговременное признание его поможет повысить вовлеченность. Вот как @tdreyno ответил на пул-реквест в [Middleman](https://github.com/middleman/middleman/pull/1466):
 
-![Запрос на включение посредника](/assets/images/building-community/middleman_pr.png)
+![Пул-ревест Middleman](/assets/images/building-community/middleman_pr.png)
 
-[Исследование Mozilla показало, что](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) участники, получившие гораздо более высокую оценку кода в течение 48 часов, совершили повторный вклад.
+[Исследование Mozilla показало, что](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) участники, чей код проверили в течение 48 часов, чаще возвращались и делали повторный вклад.
 
 Разговоры о вашем проекте также могут происходить в других местах в Интернете, таких как Stack Overflow, Twitter или Reddit. Вы можете настроить уведомления в некоторых из этих мест, чтобы получать их, когда кто-то упоминает ваш проект.
 
@@ -91,9 +91,9 @@ related:
 
 Есть две причины, чтобы дать вашему сообществу место для собраний.
 
-Первая причина - для них. Помогите людям узнать друг друга. Люди с общими интересами неизбежно захотят, об этом поговорить. А когда общение открыто и доступно, любой может читать прошлые архивы, чтобы быть в курсе и участвовать.
+Первая причина для них. Помогите людям узнать друг друга. Люди с общими интересами неизбежно захотят об этом поговорить. А когда общение открыто и доступно, любой может прочитать прошлые архивы, чтобы быть в курсе и начать участвовать.
 
-Вторая причина - для вас. Если вы не предоставите людям публичное место для обсуждения вашего проекта, они, скорее всего, свяжутся с вами напрямую. Вначале может показаться достаточно простым ответить на личные сообщения «только один раз». Но со временем, особенно если ваш проект станет популярным, вы почувствуете себя истощенным. Не поддавайтесь искушению поговорить с людьми о своем проекте наедине. Вместо этого направьте их на назначенный общедоступный канал.
+Вторая причина для вас. Если вы не предоставите людям публичное место для обсуждения вашего проекта, они, скорее всего, свяжутся с вами напрямую. Вначале может показаться достаточно простым ответить на личные сообщения «только один раз». Но со временем, особенно если ваш проект станет популярным, вы почувствуете себя истощенным. Не поддавайтесь искушению поговорить с людьми о своем проекте наедине. Вместо этого направьте их на назначенный общедоступный канал.
 
 Публичное общение может быть таким же простым, как указание людям открыть проблему вместо того, чтобы писать вам напрямую или комментировать ваш блог. Вы также можете настроить список рассылки или создать учетную запись Twitter, Slack или IRC-канал, чтобы люди говорили о вашем проекте. Или попробуйте все вышеперечисленное!
 
@@ -109,21 +109,21 @@ related:
 
 ### Не терпите плохих участников
 
-Любой популярный проект неизбежно привлечет людей, которые скорее вредят, чем помогают вашему сообществу. Они могут начать ненужные споры, спорить о тривиальных особенностях или запугать других.
+Любой популярный проект неизбежно привлечет людей, которые скорее вредят, чем помогают вашему сообществу. Они могут начать ненужные споры, спорить о тривиальных особенностях или запугивать других.
 
-Сделайте все возможное, чтобы принять политику нулевой терпимости по отношению к этим типам людей. Если оставить это без внимания, негативные люди создадут дискомфорт другим людям в вашем сообществе. Они могут даже уйти.
+Сделайте все возможное, чтобы принять политику нулевой терпимости по отношению к этим типам людей. Если оставить это без внимания, негативные люди создадут дискомфорт другим людям в вашем сообществе. Которые могут даже уйти.
 
 <aside markdown = "1" class = "pquote">
   <img src = "https://avatars.githubusercontent.com/okdistribute?s=180" class = "pquote-avatar" alt = "avatar">
   Правда в том, что наличие поддерживающего сообщества является ключевым моментом. Я бы никогда не справилась с этой работой без помощи моих коллег, дружелюбных незнакомцев в Интернете и болтливых каналов IRC. (...) Не соглашайтесь на меньшее. Не соглашайтесь на придурков.
   <p markdown = "1" class = "pquote-credit">
-- @okdistribute, [«Как запустить проект с открытым исходным кодом»](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, [«Как запустить проект с открытым исходным кодом»](https://okdistribute.xyz/post/okf-de)
   </p>
 </aside>
 
 Регулярные дебаты о тривиальных аспектах вашего проекта отвлекают других, в том числе вас, от сосредоточения на важных задачах. Новые люди, которые приходят на ваш проект, могут видеть эти разговоры и не хотят участвовать.
 
-Когда вы видите негативное поведение в своем проекте, объявите об этом публично. Объясните добрым, но твердым тоном, почему их поведение неприемлемо. Если проблема не исчезнет, ​​вам может потребоваться [попросить их уйти](../code-of-conduct/#обеспечение-соблюдения-вашего-кодекса-поведения). Ваш [кодекс поведения](../code-of-conduct/) может быть конструктивным руководством для этих разговоров.
+Когда вы видите негативное поведение в своем проекте, объявите об этом публично. Объясните добрым, но твердым тоном, почему их поведение неприемлемо. Если проблема не исчезнет, вам может потребоваться [попросить их уйти](../code-of-conduct/#обеспечение-соблюдения-вашего-кодекса-поведения). Ваш [кодекс поведения](../code-of-conduct/) может быть конструктивным руководством для таких разговоров.
 
 ### Познакомьтесь с участниками там, где они есть
 
@@ -139,9 +139,9 @@ related:
 
 Вы никогда не будете взаимодействовать с большинством людей, которые попадают в ваш проект. Могут быть вклады, которые вы не получили, потому что кто-то испугался или не знал, с чего начать. Даже несколько добрых слов могут удержать кого-то от разочарования.
 
-Например, вот как [Rubinius](https://github.com/rubinius/rubinius/) запускает [его руководство](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+Например, вот как [Rubinius](https://github.com/rubinius/rubinius/) начинает [свое руководство](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
 
-> Мы хотим начать с того, чтобы поблагодарить вас за использование Rubinius. Этот проект - плод любви, и мы ценим всех пользователей, которые вылавливают ошибки, улучшают производительность и помогают с документацией. Каждый вклад значим, поэтому спасибо за участие. При этом вот несколько рекомендаций, которым мы просим вас следовать, чтобы мы могли успешно решить вашу проблему.
+> Мы хотим начать с того, чтобы поблагодарить вас за использование Rubinius. Этот проект — плод любви, и мы ценим всех пользователей, которые вылавливают ошибки, улучшают производительность и помогают с документацией. Каждый вклад значим, поэтому спасибо за участие. При этом вот несколько рекомендаций, которым мы просим вас следовать, чтобы мы могли успешно решить вашу проблему.
 
 ### Совместное владение вашим проектом
 
@@ -149,7 +149,7 @@ related:
   <img src = "https://avatars.githubusercontent.com/sagesharp?s=180" class = "pquote-avatar" alt = "avatar">
   У ваших лидеров будут разные мнения, как и должно быть у всех здоровых сообществ! Однако вам необходимо предпринять шаги для обеспечения того, чтобы самый громкий голос не всегда побеждал, утомляя людей, и чтобы были слышны менее заметные голоса и голоса меньшинства.
   <p markdown = "1" class = "pquote-credit">
-- @sagesharp, [«Что делает хорошее сообщество?»](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+- @sagesharp, [«Что делает сообщество хорошим?»](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
   </p>
 </aside>
 
@@ -157,13 +157,13 @@ related:
 
 Посмотрите, сможете ли вы найти способы как можно больше поделиться собственностью со своим сообществом. Вот несколько идей:
 
-* **Не поддавайтесь исправлению простых (некритических) ошибок.** Вместо этого используйте их как возможности для привлечения новых участников или наставничества тех, кто хотел бы внести свой вклад. Сначала это может показаться неестественным, но со временем ваши вложения окупятся. Например, @michaeljoseph попросил участника отправить запрос на перенос по проблеме [Cookiecutter](https://github.com/audreyr/cookiecutter), а не исправить ее сам.
+* **Не поддавайтесь исправлению простых (некритических) ошибок.** Вместо этого используйте их как возможности для привлечения новых участников или наставничества тех, кто хотел бы внести свой вклад. Сначала это может показаться неестественным, но со временем ваши вложения окупятся. Например, @michaeljoseph попросил участника отправить пул-реквест по проблеме [Cookiecutter](https://github.com/audreyr/cookiecutter), а не исправлять ее самому.
 
 ![Проблема с Cookiecutter](/assets/images/building-community/cookiecutter_submit_pr.png)
 
 * **Запустите файл УЧАСТНИКИ или АВТОРЫ в своем проекте**, в котором перечислены все, кто внес свой вклад в ваш проект, как, например, [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
 
-* Если у вас большое сообщество, **разошлите информационный бюллетень или напишите сообщение в блоге** с благодарностью участникам. [Эта неделя на Rust](https://this-week-in-rust.org/) от Rust и [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) от Hoodie - два хороших примера.
+* Если у вас большое сообщество, **разошлите информационный бюллетень или напишите сообщение в блоге** с благодарностью участникам. [This Week in Rust](https://this-week-in-rust.org/) от Rust и [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) от Hoodie — два хороших примера.
 
 * **Предоставьте каждому участнику доступ к коммитам.** @felixge обнаружил, что это заставило людей [с большим энтузиазмом оттачивать свои патчи](https://felixge.de/2013/03/11/the-pull-request-hack.html), и он даже нашел новых сопровождающих для проектов, над которыми давно не работал.
 
@@ -177,7 +177,7 @@ related:
   <img src = "https://avatars.githubusercontent.com/gr2m?s=180" class = "pquote-avatar" alt = "avatar">
   \[В ваших\] интересах набирать участников, которым нравится и которые способны делать то, что вам не нравится. Вам нравится писать код, но вы не любите отвечать на вопросы? Определите людей в вашем сообществе, которые это делают, и дайте им это.
   <p markdown = "1" class = "pquote-credit">
-- @gr2m, ["Приветливые сообщества"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, [«Дружелюбные сообщества»](http://hood.ie/blog/welcoming-communities.html)
   </p>
 </aside>
 
@@ -193,13 +193,13 @@ related:
 
 Когда ваше сообщество борется с трудной проблемой, может подняться накал страстей. Люди могут рассердиться или расстроиться и обидеться друг на друга или на вас.
 
-Ваша задача как сопровождающего - не допустить обострения подобных ситуаций. Даже если у вас есть твердое мнение по теме, постарайтесь занять позицию модератора или фасилитатора, вместо того, чтобы вступать в борьбу и продвигать свои взгляды. Если кто-то ведет себя недоброжелательно или монополизирует беседу, [действуйте немедленно](../building-community/#не-терпите-плохих-участников), чтобы обсуждение было вежливым и продуктивным.
+Ваша задача как сопровождающего — не допустить обострения подобных ситуаций. Даже если у вас есть твердое мнение по теме, постарайтесь занять позицию модератора или фасилитатора, вместо того, чтобы вступать в борьбу и продвигать свои взгляды. Если кто-то ведет себя недоброжелательно или монополизирует беседу, [действуйте немедленно](../building-community/#не-терпите-плохих-участников), чтобы обсуждение было вежливым и продуктивным.
 
 <aside markdown = "1" class = "pquote">
   <img src = "https://avatars.githubusercontent.com/kennethreitz?s=180" class = "pquote-avatar" alt = "avatar">
   Сопровождающему проекта, чрезвычайно важно относиться с уважением к своим участникам. Они часто принимают то, что вы говорите, очень близко к сердцу.
   <p markdown = "1" class = "pquote-credit">
-- @kennethreitz, [«Будьте сердечны или идите своим путем»](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, [«Будьте сердечны или идите своим путем»](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
@@ -209,23 +209,23 @@ related:
 
 ### Относитесь к README как к конституции
 
-Ваш README - это [больше, чем просто набор инструкций](../starting-a-project/#написание-readme). Это также место, где можно поговорить о ваших целях, видении продукта и планах развития. Если люди слишком сосредоточены на обсуждении достоинств той или иной функции, возможно, будет полезно вернуться к README и поговорить о более высоком видении вашего проекта. Сосредоточение внимания на README также обезличивает разговор, поэтому вы можете провести конструктивное обсуждение.
+Ваш README — это [больше, чем просто набор инструкций](../starting-a-project/#написание-readme). Это также место, где можно поговорить о ваших целях, видении продукта и планах развития. Если люди слишком сосредоточены на обсуждении достоинств той или иной функции, возможно, будет полезно вернуться к README и поговорить о более высоком видении вашего проекта. Сосредоточение внимания на README также обезличивает разговор, поэтому вы можете вести конструктивное обсуждение.
 
 ### Сосредоточьтесь на путешествии, а не на пункте назначения
 
-В некоторых проектах для принятия важных решений используется процесс голосования. Хотя на первый взгляд разумно, голосование делает упор на поиске «ответа», а не на том, чтобы выслушивать и решать проблемы друг друга.
+В некоторых проектах для принятия важных решений используется процесс голосования. Хотя на первый взгляд это выглядит разумно, голосование делает упор на поиске «ответа», а не на том, чтобы выслушивать и решать проблемы друг друга.
 
-Голосование может стать политическим, когда члены сообщества чувствуют давление, чтобы они оказали друг другу услуги или проголосовали определенным образом. Также не все голосуют, будь то [молчаливое большинство](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) в вашем сообществе или пользователи, которые не знали, что голосование происходит.
+Голосование может стать политическим, когда участники сообщества чувствуют давление, оказывая друг другу услуги или проголосовав определенным образом. Не все голосуют, будь то [молчаливое большинство](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) в вашем сообществе или пользователи, которые не знали, что проходит голосование.
 
-Иногда голосование является необходимым условием разрешения конфликтов. Однако, насколько вы можете, делайте упор на [«поиск консенсуса»](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), а не на консенсусе.
+Иногда голосование является необходимым условием разрешения конфликтов. Однако, насколько вы можете, сделайте упор на [«поиске консенсуса»](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), а не на консенсусе.
 
-В процессе поиска консенсуса члены сообщества обсуждают основные проблемы до тех пор, пока не почувствуют, что их должным образом выслушали. Когда остаются лишь незначительные проблемы, сообщество движется вперед. «Поиск консенсуса» признает, что сообщество не может прийти к идеальному ответу. Вместо этого он отдает приоритет слушанию и обсуждению.
+В процессе поиска консенсуса члены сообщества обсуждают основные проблемы до тех пор, пока не почувствуют, что их должным образом выслушали. Когда остаются лишь незначительные проблемы, сообщество движется вперед. «Поиск консенсуса» признает, что сообщество может не прийти к идеальному ответу. Вместо этого он отдает приоритет слушанию и обсуждению.
 
 <aside markdown = "1" class = "pquote">
   <img src = "https://avatars.githubusercontent.com/lee-dohm?s=180" class = "pquote-avatar" alt = "avatar">
-  Отчасти причина того, что система голосования не существует для проблем Atom, заключается в том, что команда Atom не собирается следовать системе голосования во всех случаях. Иногда нам приходится выбирать то, что мы считаем правильным, даже если это непопулярно. (...) Что я могу предложить и обещаю сделать... это то, что моя работа - слушать сообщество.
+  Отчасти причина того, что система голосования не применяется для проблем Atom, заключается в том, что команда Atom не собирается следовать системе голосования во всех случаях. Иногда нам приходится выбирать то, что мы считаем правильным, даже если это непопулярно. (...) Что я могу предложить и обещаю сделать... так это то, что моя работа — слушать сообщество.
   <p markdown = "1" class = "pquote-credit">
-- @lee-dohm о [процессе принятия решений Atom](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm о [процессе принятия решений в Atom](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
   </p>
 </aside>
 
@@ -251,7 +251,7 @@ related:
   <img src = "https://avatars.githubusercontent.com/kfogel?s=180" class = "pquote-avatar" alt = "avatar">
   Направлять нить к полезности без навязчивости - это искусство. Не сработает просто увещевать людей перестать тратить свое время или просить их не публиковать сообщения, если у них нет чего-то конструктивного. (...) Вместо этого вы должны предложить условия для дальнейшего прогресса: дать людям маршрут, путь, по которому следует следовать, который приведет к желаемым результатам, но чтобы это не звучало, будто вы диктуете поведение.
   <p markdown = "1" class = "pquote-credit">
-- @kfogel, [_Proroduction OSS_](https://produdingoss.com/en/produdingoss.html#common-pitfalls)
+— @kfogel, [_Proroduction OSS_](https://produdingoss.com/en/produdingoss.html#common-pitfalls)
   </p>
 </aside>
 
@@ -259,7 +259,7 @@ related:
 
 Контекст важен. Подумайте, кто участвует в обсуждении и как они представляют остальную часть сообщества.
 
-Все в сообществе расстроены или даже вовлечены в эту проблему? Или одинокий нарушитель спокойствия? Не забывайте принимать во внимание молчаливых членов вашего сообщества, а не только активные голоса.
+Все ли в сообществе расстроены или вовлечены в эту проблему? Или это одинокий нарушитель спокойствия? Не забывайте принимать во внимание молчаливых членов вашего сообщества, а не только активные голоса.
 
 Если проблема не отражает более широкие потребности вашего сообщества, возможно, вам просто нужно признать озабоченность нескольких человек. Если это повторяющаяся проблема без четкого решения, укажите на предыдущие обсуждения по этой теме и закройте ветку.
 
@@ -271,6 +271,6 @@ related:
 
 Тай-брейк должен быть последним средством. Спорные вопросы - это возможность для вашего сообщества расти и учиться. Воспользуйтесь этими возможностями и используйте совместный процесс, чтобы найти решение везде, где это возможно.
 
-## Сообщество - это ❤️ открытого исходного кода
+## Сообщество — это ❤️ открытого исходного кода
 
-Здоровые и процветающие сообщества каждую неделю тратят тысячи часов на разработку программного обеспечения с открытым исходным кодом. Многие участники указывают на других людей как на причину работы - или не работы - над открытым исходным кодом. Узнав, как использовать эту силу конструктивно, вы поможете кому-то получить незабываемый опыт с открытым исходным кодом.
+Здоровые и процветающие сообщества каждую неделю тратят тысячи часов на разработку программного обеспечения с открытым исходным кодом. Многие участники указывают на других людей как на причину работы - или не работы - над открытым исходным кодом. Узнав, как использовать эту силу конструктивно, вы поможете кому-то получить незабываемый опыт работы с открытым исходным кодом.

From 2c7e1b22b707275f373ddc601e95445d2649b82c Mon Sep 17 00:00:00 2001
From: Vik <63919734+ViktorOn@users.noreply.github.com>
Date: Wed, 10 Aug 2022 20:43:57 +0300
Subject: [PATCH 361/749] Update building-community.md

---
 _articles/ru/building-community.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/ru/building-community.md b/_articles/ru/building-community.md
index 1c0184cc7d8..49a9c1d9804 100644
--- a/_articles/ru/building-community.md
+++ b/_articles/ru/building-community.md
@@ -161,13 +161,13 @@ related:
 
 ![Проблема с Cookiecutter](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Запустите файл УЧАСТНИКИ или АВТОРЫ в своем проекте**, в котором перечислены все, кто внес свой вклад в ваш проект, как, например, [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
+* **Запустите файл CONTRIBUTORS или AUTORS в своем проекте**, в котором перечислены все, кто внес свой вклад в ваш проект, как, например, [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
 
 * Если у вас большое сообщество, **разошлите информационный бюллетень или напишите сообщение в блоге** с благодарностью участникам. [This Week in Rust](https://this-week-in-rust.org/) от Rust и [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) от Hoodie — два хороших примера.
 
 * **Предоставьте каждому участнику доступ к коммитам.** @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://help.github.com/articles/creating-a-new-organization-account/)** и добавьте хотя бы одного резервного администратора. Организации упрощают работу над проектами с внешними соавторами.
 
 Реальность такова, что [в большинстве проектов есть](https://peerj.com/preprints/1233/) один или два сопровождающих, которые делают большую часть работы. Чем крупнее ваш проект и чем больше ваше сообщество, тем легче найти помощь.
 

From b05b300570ee97241068ea9e596f484f0a05e960 Mon Sep 17 00:00:00 2001
From: Vik <63919734+ViktorOn@users.noreply.github.com>
Date: Wed, 10 Aug 2022 21:01:43 +0300
Subject: [PATCH 362/749] Update ru.yml

---
 _data/locales/ru.yml | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_data/locales/ru.yml b/_data/locales/ru.yml
index 3ccd4444c42..f47137756dc 100644
--- a/_data/locales/ru.yml
+++ b/_data/locales/ru.yml
@@ -2,7 +2,7 @@ ru:
   locale_name: Русский
   nav:
     about: О проекте
-    contribute: Сотрудничество
+    contribute: Содействие
   index:
     lead: Программы с отрытым кодом создают такие же люди как вы. Узнайте, как запустить и развить свой проект.
     opensourcefriday: Сегодня пятница! Посвятите несколько часов программе, которую вы любите и используете
@@ -12,9 +12,9 @@ ru:
     related_guides: Связанные темы
   footer:
     contribute:
-      heading: Сотрудничество
+      heading: Содействие
       description: Есть что предложить? Эти материалы открыты для редактирования. Помогите улучшить их.
-      button: Сотрудничать
+      button: Содействовать
     subscribe:
       heading: Оставайтесь на связи
       description: Будьте первым, кто узнает новости из мира открытого кода.
@@ -22,7 +22,7 @@ ru:
       button: Подписаться
     byline:
       # [code], [love], and [github] will be replaced by octicons
-      format: '[code] с [love] вместе с [github] и [друзьями]'
+      format: "[code] с [love] вместе с [github] и [друзьями]"
       # Label for code octicon
       code_label: программируйте
       # Label for love octicon

From 029171a82270db021b8cf1bf2918f62341163f0e Mon Sep 17 00:00:00 2001
From: Ernest Rudnicki <e.rudnicki96@gmail.com>
Date: Mon, 15 Aug 2022 10:48:37 +0200
Subject: [PATCH 363/749] update how-to-contribute polish version

---
 _articles/pl/how-to-contribute.md | 114 +++++++++++++++---------------
 1 file changed, 57 insertions(+), 57 deletions(-)

diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index 169f1f50112..b8fa02aa09b 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -1,7 +1,7 @@
 ---
 lang: pl
 title: Jak przyczynić się do Open Source
-description: Chcesz przyczynić się do open source? Przewodnik po wkładach typu open source, dla nowicjuszy i weteranów.
+description: Chciałbyś przyczynić się do open source? Przewodnik po wkładach typu open source, dla nowicjuszy i weteranów.
 class: contribute
 order: 1
 image: /assets/images/cards/contribute.png
@@ -22,47 +22,47 @@ related:
   </p>
 </aside>
 
-Wkład w open source może być satysfakcjonującym sposobem uczenia się, nauczania i budowania doświadczenia w prawie każdej umiejętności, jaką możesz sobie wyobrazić.
+Wkład w open source może być satysfakcjonującym sposobem uczenia się oraz nauczania i budowania doświadczenia w prawie każdej umiejętności, jaką możesz sobie wyobrazić.
 
-Dlaczego ludzie przyczyniają się do open source? Wiele powodów!
+Dlaczego ludzie przyczyniają się do open source? Z wielu powodów!
 
 ### Ulepsz oprogramowanie, na którym możesz polegać
 
-Wielu współpracowników open source zaczyna od bycia użytkownikami oprogramowania, do którego się wnosi. Gdy znajdziesz błąd w używanym oprogramowaniu open source, możesz zajrzeć do źródła, aby sprawdzić, czy możesz go naprawić samodzielnie. Jeśli tak jest, to dodanie poprawki jest najlepszym sposobem, aby zapewnić, że Twoi znajomi (i ty, kiedy zaktualizujesz do następnej wersji) będą mogli z niej skorzystać.
+Wielu współpracowników open source zaczyna od bycia użytkownikami oprogramowania, do którego następnie wnoszą swój wkład. Gdy znajdziesz błąd w używanym przez ciebie oprogramowaniu open source, możesz zajrzeć do źródła, aby sprawdzić, czy możesz go naprawić samodzielnie. Jeśli tak jest, to dodanie poprawki jest najlepszym sposobem, aby zapewnić, że Twoi znajomi (i ty, kiedy zaktualizujesz do następnej wersji) będą mogli z niej skorzystać.
 
-### Popraw istniejące umiejętności
+### Rozwiń swoje umiejętności
 
-Niezależnie od tego, czy chodzi o kodowanie, projektowanie interfejsu użytkownika, projektowanie graficzne, pisanie czy organizowanie, jeśli szukasz praktyki, jest dla ciebie zadanie w projekcie open source.
+Niezależnie od tego, czy chodzi o programowanie, projektowanie interfejsu użytkownika, projektowanie graficzne, pisanie czy organizowanie, jeśli szukasz praktyki, to znajdziesz odpowiednie zadanie w projekcie open source.
 
-### Poznawaj ludzi, którzy są zainteresowani podobnymi rzeczami
+### Poznawaj ludzi, którzy mają podobne zainteresowania
 
 Projekty open source z ciepłymi, przyjaznymi społecznościami sprawiają, że ludzie wracają na lata. Wiele osób nawiązuje przyjaźnie na całe życie poprzez udział w otwartym kodzie źródłowym, bez względu na to, czy spotykają się na konferencjach, czy późno w nocy na czatach internetowych o burritos.
 
 ### Znajdź mentorów i ucz innych
 
-Praca z innymi przy wspólnym projekcie oznacza, że musisz wyjaśnić, jak to robisz, a także poprosić o pomoc innych ludzi. Działania związane z uczeniem się i nauczaniem mogą być satysfakcjonującym zajęciem dla wszystkich zaangażowanych osób.
+Praca z innymi przy wspólnym projekcie oznacza, że musisz wyjaśnić, jak coś robisz, a także poprosić o pomoc innych ludzi. Działania związane z uczeniem się i nauczaniem mogą być satysfakcjonującym zajęciem dla wszystkich zaangażowanych osób.
 
 ### Twórz publiczne artefakty, które pomogą ci zdobyć reputację (i karierę)
 
-Z definicji cała twoja praca z otwartym kodem źródłowym jest publiczna, co oznacza, że masz darmowe przykłady do zabrania w dowolne miejsce jako demonstrację tego, co możesz zrobić.
+Z definicji cała twoja praca z otwartym kodem źródłowym jest publiczna, co oznacza, że masz darmowe przykłady do pokazania w dowolnym miejscu jako demonstrację tego, co potrafisz zrobić.
 
-### Naucz ludzi umiejętności
+### Rozwiń swoje zdolności interpersonalne
 
-Open source oferuje możliwości ćwiczenia umiejętności przywódczych i zarządczych, takich jak rozwiązywanie konfliktów, organizowanie zespołów ludzi i ustalanie priorytetów pracy.
+Open source oferuje możliwośc ćwiczenia umiejętności przywódczych i zarządczych, takich jak rozwiązywanie konfliktów, organizowanie zespołów i ustalanie priorytetów pracy.
 
 ### Daje to możliwość wprowadzania zmian, nawet tych małych
 
-Nie musisz stać się dożywotnim uczestnikiem, aby cieszyć się uczestnictwem w otwartym oprogramowaniu. Czy widziałeś kiedyś literówkę na stronie i żałowałeś, że ktoś to nie naprawi? W projekcie open source możesz to zrobić. Open source pomaga ludziom odczuwać agencję w ich życiu i doświadczaniu świata, a to samo w sobie jest satysfakcjonujące.
+Nie musisz stać się dożywotnim uczestnikiem, aby cieszyć się uczestnictwem w otwartym oprogramowaniu. Czy widziałeś kiedyś literówkę na stronie i żałowałeś, że ktoś to nie naprawił? W projekcie open source możesz to zrobić. Open source pomaga ludziom odczuwać poczucie kontroli w ich życiu i doświadczaniu świata, a to samo w sobie jest satysfakcjonujące.
 
 ## Co to znaczy przyczynić się
 
-Jeśli jesteś nowym współpracownikiem typu open source, proces może być zastraszający. Jak znaleźć odpowiedni projekt? Co jeśli nie wiesz, jak kodować? Co jeśli coś pójdzie nie tak?
+Jeśli jesteś nowym współpracownikiem typu open source, proces może być zastraszający. Jak znaleźć odpowiedni projekt? Co jeśli nie wiesz, jak programować? Co jeśli coś pójdzie nie tak?
 
 Nie martwić się! Istnieje wiele sposobów na zaangażowanie się w projekt open source, a kilka wskazówek pomoże Ci w pełni wykorzystać swoje doświadczenie.
 
 ### Nie musisz przekazywać kodu
 
-Powszechnym błędnym przekonaniem na temat przyczyniania się do open source jest to, że musisz wnieść kod. W rzeczywistości często inne części projektu są [najbardziej zaniedbywane lub pomijane](https://github.com/blog/2195-the-shape-of-open-source). Zrobisz projekt z _wielką_ przysługą, oferując wkład w tego rodzaju wkłady!
+Powszechnym błędnym przekonaniem na temat przyczyniania się do open source jest to, że musisz wnieść kod. W rzeczywistości często inne części projektu są [najbardziej zaniedbywane lub pomijane](https://github.com/blog/2195-the-shape-of-open-source). Zrobisz projektowi _wielką_ przysługę, oferując swój wkład w taką część projektu!
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
@@ -89,12 +89,12 @@ Nawet jeśli lubisz pisać kod, inne rodzaje wkładów to świetny sposób na za
 ### Czy lubisz planować wydarzenia?
 
 * Organizuj warsztaty lub spotkania dotyczące projektu, [jak @fzamperin dla NodeSchool](https://github.com/nodeschool/organizers/issues/406)
-* Zorganizuj konferencję projektu (jeśli ją mają)
+* Zorganizuj konferencję projektu (jeśli taką mają)
 * Pomóż członkom społeczności znaleźć odpowiednie konferencje i przesłać propozycje wystąpień
 
 ### Czy lubisz projektować?
 
-* Przebuduj układy, aby poprawić użyteczność projektu
+* Przebuduj strukturę interfejsu, aby poprawić użyteczność projektu
 * Przeprowadź badania użytkowników w celu reorganizacji i dopracowania nawigacji lub menu projektu, [jak sugeruje Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability)
 * Przygotuj przewodnik po stylu, aby projekt miał spójny wygląd
 * Twórz grafiki na koszulki lub nowe logo, tak jak zrobili to autorzy [hapi.js](https://github.com/hapijs/contrib/issues/68)
@@ -119,16 +119,16 @@ Nawet jeśli lubisz pisać kod, inne rodzaje wkładów to świetny sposób na za
 
 ### Czy lubisz organizować?
 
-* Łącze do duplikatów problemów i sugeruj nowe etykiety problemów, aby utrzymać porządek
-* Przejrzyj otwarte problemy i sugeruj zamknięcie starych, [jak @nzakas zrobił dla ESLint](https://github.com/eslint/eslint/issues/6765)
+* Twórz łącza do duplikatów problemów i sugeruj ich nowe etykiety, aby utrzymać porządek
+* Przejrzyj otwarte problemy i zassugeruj zamknięcie starych, [jak @nzakas zrobił dla ESLint](https://github.com/eslint/eslint/issues/6765)
 * Zadaj pytania wyjaśniające na temat ostatnio otwartych zagadnień, aby popchnąć dyskusję do przodu
 
 ### Czy lubisz kodować?
 
 * Znajdź otwarty problem do rozwiązania [jak @dianjin zrobił dla Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
-* Zapytaj, czy możesz pomóc napisać nową funkcję
+* Zapytaj, czy możesz pomóc napisać nową funkcjonalność
 * Zautomatyzuj konfigurację projektu
-* Ulepsz oprzyrządowanie i testy
+* Ulepsz narzędzia używane w projekcie i testy
 
 ### Czy lubisz pomagać ludziom?
 
@@ -138,7 +138,7 @@ Nawet jeśli lubisz pisać kod, inne rodzaje wkładów to świetny sposób na za
 
 ### Czy lubisz pomagać innym kodować?
 
-* Przejrzyj kod zgłoszeń innych osób
+* Przejrzyj kod zgłoszeń od innych osób
 * Napisz tutoriale dotyczące sposobu wykorzystania projektu
 * Oferta mentorowania innego autora [jak @ereichert zrobił dla @bronzdoc na Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
 
@@ -166,9 +166,9 @@ Nawet jeśli jesteś programistą, praca nad projektem dokumentacji może pomóc
   </p>
 </aside>
 
-W przypadku czegoś więcej niż poprawka literówek, udział w open source jest jak podchodzenie do grupy nieznajomych na imprezie. Jeśli zaczniesz mówić o lamach, gdy byli głęboko w dyskusji na temat złotych rybek, prawdopodobnie spojrzą na ciebie trochę dziwnie.
+W przypadku czegoś więcej niż poprawa literówek, udział w open source jest jak podchodzenie do grupy nieznajomych na imprezie. Jeśli zaczniesz mówić o lamach, gdy byli głęboko w dyskusji na temat złotych rybek, prawdopodobnie spojrzą na ciebie trochę dziwnie.
 
-Zanim wskoczysz na ślepo z własnymi sugestiami, zacznij od nauki czytania pokoju. Takie postępowanie zwiększa szanse, że Twoje pomysły zostaną zauważone i usłyszane.
+Zanim wskoczysz na ślepo z własnymi sugestiami, zacznij od nauki wybadywania terenu. Takie postępowanie zwiększa szanse, że Twoje pomysły zostaną zauważone i usłyszane.
 
 ### Anatomia projektu open source
 
@@ -181,19 +181,19 @@ To powiedziawszy, wiele projektów open source ma podobną strukturę organizacy
 Typowy projekt open source ma następujące typy osób:
 
 * **Autor:** Osoba lub organizacja, która utworzyła projekt
-* **Właściciel:** Osoba / osoby posiadające uprawnienia administracyjne do organizacji lub repozytorium (nie zawsze takie same jak oryginalny autor)
+* **Właściciel:** Osoba / osoby posiadające uprawnienia administracyjne do organizacji lub repozytorium (nie zawsze taki sam jak oryginalny autor)
 * **Opiekunowie:** Współtwórcy odpowiedzialni za kierowanie wizją i zarządzanie aspektami organizacyjnymi projektu (mogą być także autorami lub właścicielami projektu).
-* **Współtwórcy:** Każdy, kto wniósł coś z powrotem do projektu
+* **Współtwórcy:** Każdy, kto wniósł coś do projektu
 * **Członkowie społeczności:** Ludzie, którzy korzystają z projektu. Mogą być aktywni w rozmowach lub wyrażać swoją opinię na temat kierunków projektu
 
-Większe projekty mogą również obejmować podkomitety lub grupy robocze zajmujące się różnymi zadaniami, takimi jak oprzyrządowanie, segregacja, moderacja społeczności i organizacja wydarzeń. Na stronie internetowej projektu można znaleźć stronę „zespołu” lub w repozytorium dokumentacji dotyczącej zarządzania, aby znaleźć te informacje.
+Większe projekty mogą również obejmować podkomitety lub grupy robocze zajmujące się różnymi zadaniami, takimi jak narzędzia projektowe, segregacja, moderacja społeczności i organizacja wydarzeń. Na stronie internetowej projektu można znaleźć stronę „zespołu” lub w repozytorium dokumentacji dotyczącej zarządzania, aby znaleźć te informacje.
 
 Projekt ma również dokumentację. Te pliki są zwykle wymienione na najwyższym poziomie repozytorium.
 
-* **LICENSE:** Z definicji każdy projekt typu open source musi posiadać [licencję typu open source](https://choosealicense.com). Jeśli projekt nie ma licencji, nie jest open source.
+* **LICENSE:** Z definicji każdy projekt typu open source musi posiadać [licencję typu open source](https://choosealicense.com). Jeśli projekt nie ma licencji, to nie jest open source.
 * **README:** Plik README to instrukcja obsługi, która wita nowych członków społeczności w projekcie. Wyjaśnia, dlaczego projekt jest użyteczny i jak zacząć.
-* **CONTRIBUTING:** Podczas gdy pliki README pomagają ludziom _użytkować_ projekt, udostępnianie dokumentów pomaga ludziom _komponować_ w projekcie. Wyjaśnia, jakie rodzaje wkładów są potrzebne i jak działa proces. Chociaż nie każdy projekt ma plik WKŁAD, jego obecność sygnalizuje, że jest to przyjazny projekt, do którego należy się przyczynić.
-* **CODE_OF_CONDUCT:** tworzeniu przyjaznego i przyjaznego środowiska. Chociaż nie każdy projekt ma plik CODE_OF_CONDUCT, jego obecność sygnalizuje, że jest to przyjazny projekt, do którego można się przyczynić.
+* **CONTRIBUTING:** Podczas gdy pliki README pomagają ludziom _użytkować_ projekt, udostępnianie dokumentów pomaga ludziom _komponować_ w projekcie. Wyjaśnia, jakie rodzaje wkładów są potrzebne i jak działa proces. Chociaż nie każdy projekt ma plik CONTRIBUTING, jego obecność sygnalizuje, że jest to przyjazny projekt, do którego można wnieść swój wkład.
+* **CODE_OF_CONDUCT:** tworzeniu przyjaznego i przyjaznego środowiska. Chociaż nie każdy projekt ma plik CODE_OF_CONDUCT, jego obecność sygnalizuje, że jest to przyjazny projekt, do którego można wnieść swój wkład.
 * **Other documentation:** Może istnieć dodatkowa dokumentacja, taka jak samouczki, instrukcje lub zasady zarządzania, szczególnie w przypadku większych projektów.
 
 Wreszcie, projekty open source wykorzystują następujące narzędzia do organizowania dyskusji. Czytanie archiwów daje dobry obraz tego, jak społeczność myśli i działa.
@@ -203,13 +203,13 @@ Wreszcie, projekty open source wykorzystują następujące narzędzia do organiz
 * **Discussion forums or mailing lists:** Niektóre projekty mogą wykorzystywać te kanały do prowadzenia wątków konwersacyjnych (na przykład _„Jak mam ...”_ lub _„Co sądzisz o ...”_ zamiast raportów o błędach lub propozycji funkcji). Inni używają narzędzia do śledzenia problemów do wszystkich rozmów.
 * **Synchronous chat channel:** Niektóre projekty wykorzystują kanały czatu (takie jak Slack lub IRC) do swobodnej rozmowy, współpracy i szybkiej wymiany.
 
-## Znalezienie projektu, do którego można się przyczynić
+## Znalezienie projektu, do którego można wnieść swój wkład
 
-Teraz, gdy już zorientowałeś się, jak działają projekty typu open source, nadszedł czas, aby znaleźć projekt, do którego możesz się przyczynić!
+Teraz, gdy już zorientowałeś się, jak działają projekty typu open source, nadszedł czas, aby znaleźć projekt, do którego możesz wnieść swój wkład!
 
 Jeśli nigdy wcześniej nie uczestniczyłeś w tworzeniu oprogramowania typu open source, skorzystaj z porady Prezydenta Stanów Zjednoczonych Johna F. Kennedy'ego, który powiedział kiedyś, _"Ask not what your country can do for you - ask what you can do for your country."_
 
-Wkład w open source ma miejsce na wszystkich poziomach, w różnych projektach. Nie musisz zastanawiać się, jaki dokładnie będzie twój pierwszy wkład ani jak będzie wyglądał.
+Wkład w open source ma miejsce na wszystkich poziomach, w różnych projektach. Nie musisz się zastanawiać, jaki dokładnie będzie twój pierwszy wkład ani jak będzie wyglądał.
 
 Zamiast tego zacznij od przemyślenia projektów, z których już korzystasz lub z których chcesz skorzystać. Projekty, w których aktywnie uczestniczysz, to te, do których wracasz.
 
@@ -349,7 +349,7 @@ Teraz wykonaj te same kroki dla PR (pull requests) projektu.
   </label>
 </div>
 
-**Projekt jest mile widziany**
+**Projekt jest otwarty na nwoych autorów**
 
 Projekt przyjazny i gościnny sygnalizuje, że będą otwarci na nowych autorów.
 
@@ -405,15 +405,15 @@ Niezależnie od tego, czy jesteś jednorazowym współpracownikiem, czy próbuje
   </p>
 </aside>
 
-Zanim otworzysz issue, pull request lub zadasz pytanie na czacie, pamiętaj o tych punktach, aby pomóc skutecznie znaleźć swoje pomysły.
+Zanim otworzysz issue, pull request lub zadasz pytanie na czacie, pamiętaj o tych punktach, aby pomóc skutecznie zrozumieć twoje pomysły.
 
-**Podaj kontekst.** Pomóż innym szybko przyśpieszyć. Jeśli napotkasz błąd, wyjaśnij, co próbujesz zrobić i jak go odtworzyć. Jeśli sugerujesz nowy pomysł, wyjaśnij, dlaczego uważasz, że byłby przydatny dla projektu (nie tylko dla ciebie!).
+**Podaj kontekst.** Pomóż innym szybko wgryźć się w temat. Jeśli napotkasz błąd, wyjaśnij, co próbujesz zrobić i jak go odtworzyć. Jeśli sugerujesz nowy pomysł, wyjaśnij, dlaczego uważasz, że byłby przydatny dla projektu (nie tylko dla ciebie!).
 
 > 😇 _"X doesn't happen when I do Y"_
 >
 > 😢 _"X is broken! Please fix it."_
 
-**Zrób swoją pracę domową wcześniej.** Nie można nic wiedzieć, ale pokazać, że próbowałeś. Zanim poprosisz o pomoc, koniecznie sprawdź README projektu, dokumentację, problemy (otwarte lub zamknięte), listę mailingową i wyszukaj w Internecie odpowiedź. Ludzie docenią, gdy pokażesz, że próbujesz się uczyć.
+**Odrób swoją pracę domową wcześniej.** To w porządku, jeśli wszystkiego nie wiesz, ale pokazałeś, że próbowałeś. Zanim poprosisz o pomoc, koniecznie sprawdź README projektu, dokumentację, problemy (otwarte lub zamknięte), listę mailingową i wyszukaj w Internecie odpowiedź. Ludzie docenią, gdy pokażesz, że próbujesz się uczyć.
 
 > 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
 >
@@ -425,7 +425,7 @@ Zanim otworzysz issue, pull request lub zadasz pytanie na czacie, pamiętaj o ty
 >
 > 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
 
-**Trzymaj całą komunikację publiczną.** Chociaż jest to kuszące, nie kontaktuj się prywatnie z opiekunami, chyba że musisz udostępniać poufne informacje (takie jak problem z bezpieczeństwem lub poważne naruszenie zasad postępowania). Gdy udostępnisz rozmowę publicznie, więcej osób może się uczyć i korzystać z wymiany. Dyskusje mogą być same w sobie wkładem.
+**Trzymaj całą komunikację publiczną.** Chociaż jest to kuszące, nie kontaktuj się prywatnie z opiekunami, chyba że musisz udostępniać poufne informacje (takie jak problem z bezpieczeństwem lub poważne naruszenie zasad postępowania). Gdy udostępnisz rozmowę publicznie, więcej osób może się uczyć i korzystać z wymiany zdań. Dyskusje mogą być same w sobie wkładem.
 
 > 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
 >
@@ -437,13 +437,13 @@ Zanim otworzysz issue, pull request lub zadasz pytanie na czacie, pamiętaj o ty
 >
 > 😢 _"Why can't you fix my problem? Isn't this your project?"_
 
-**Szanuj decyzje społeczności.** Twoje pomysły mogą różnić się od priorytetów lub wizji społeczności. Mogą oferować informacje zwrotne lub zdecydować o nie realizowaniu Twojego pomysłu. Podczas gdy powinieneś dyskutować i szukać kompromisu, opiekunowie muszą żyć z twoją decyzją dłużej niż ty. Jeśli nie zgadzasz się z ich kierunkiem, zawsze możesz pracować nad własnym widelcem lub rozpocząć własny projekt.
+**Szanuj decyzje społeczności.** Twoje pomysły mogą różnić się od priorytetów lub wizji społeczności. Mogą oni oferować informacje zwrotne lub zdecydować o nie realizowaniu Twojego pomysłu. Podczas gdy powinieneś dyskutować i szukać kompromisu, opiekunowie muszą żyć z twoją decyzją dłużej niż ty. Jeśli nie zgadzasz się z ich kierunkiem, zawsze możesz pracować nad własnym forkiem lub rozpocząć własny projekt.
 
 > 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
 >
 > 😢 _"Why won't you support my use case? This is unacceptable!"_
 
-**Przede wszystkim zachowaj klasę.** Open source składa się ze współpracowników z całego świata. Kontekst gubi się w różnych językach, kulturach, regionach geograficznych i strefach czasowych. Ponadto pisemna komunikacja utrudnia przekazanie tonu lub nastroju. Przyjmij dobre intencje w tych rozmowach. Dobrze jest grzecznie odepchnąć pomysł, poprosić o więcej kontekstu lub wyjaśnić swoje stanowisko. Po prostu spróbuj zostawić Internet w lepszym miejscu niż wtedy, gdy go znajdziesz.
+**Przede wszystkim zachowaj klasę.** Open source składa się ze współpracowników z całego świata. Kontekst gubi się w różnych językach, kulturach, regionach geograficznych i strefach czasowych. Ponadto pisemna komunikacja utrudnia przekazanie tonu lub nastroju. Przyjmij dobre intencje w tych rozmowach. Dobrze jest grzecznie odepchnąć pomysł, poprosić o więcej kontekstu lub wyjaśnić swoje stanowisko. Po prostu spróbuj zostawić Internet w lepszym miejscu niż wtedy, gdy go znalazłeś.
 
 ### Zbieranie kontekstu
 
@@ -452,12 +452,12 @@ Zanim cokolwiek zrobisz, szybko sprawdź, czy Twój pomysł nie został omówion
 Jeśli nie możesz znaleźć swojego pomysłu w innym miejscu, możesz zrobić krok. Jeśli projekt jest w serwisie GitHub, prawdopodobnie komunikujesz się, otwierając problem lub wysyłając żądanie:
 
 * **Issues** są jak rozpoczęcie rozmowy lub dyskusji
-* **Pull requests** są za rozpoczęcie pracy nad rozwiązaniem
-* **Aby uzyskać lekką komunikację,** takie jak pytanie wyjaśniające lub poradnik, spróbuj zadać pytanie na temat przepełnienia stosu, IRC, Slacka lub innych kanałów czatu, jeśli projekt ma taki
+* **Pull requests** są rozpoczęciem pracy nad rozwiązaniem
+* **Aby uzyskać lekką komunikację,** takie jak pytanie wyjaśniające lub poradnik, spróbuj zadać pytanie Stack Overflow, IRC, Slacka lub innych kanałów komunikacyjnych, jeśli projekt ma taki
 
-Zanim otworzysz problem lub wyciągniesz prośbę, sprawdź dokumenty wspierające projekt (zwykle plik o nazwie CONTRIBUTING lub w README), aby sprawdzić, czy musisz dołączyć coś konkretnego. Na przykład mogą poprosić o przestrzeganie szablonu lub wymagać użycia testów.
+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 zadać, zanim zaczniesz nad nim pracować. Przydatne jest obejrzenie projektu przez chwilę (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://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.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -477,33 +477,33 @@ Zazwyczaj powinieneś otworzyć problem w następujących sytuacjach:
 
 Wskazówki dotyczące komunikowania się w issue:
 
-* **Jeśli widzisz otwarty problem, który chcesz rozwiązać,** skomentuj ten problem, aby inni wiedzieli, że na nim jesteś. W ten sposób ludzie są mniej skłonni do powielania twojej pracy.
-* **Jeśli jakiś problem został otwarty jakiś czas temu,** możliwe, że problem został rozwiązany gdzieś indziej lub został już rozwiązany, więc skomentuj, aby poprosić o potwierdzenie przed rozpoczęciem pracy.
+* **Jeśli widzisz otwarty problem, który chcesz rozwiązać,** skomentuj ten problem, aby inni wiedzieli, że nad nim pracujesz. W ten sposób ludzie są mniej skłonni do powielania twojej pracy.
+* **Jeśli jakiś problem został otwarty jakiś czas temu,** możliwe, że problem został przedyskutowany gdzieś indziej lub został już rozwiązany, więc skomentuj, aby poprosić o potwierdzenie przed rozpoczęciem pracy.
 * **Jeśli otworzyłeś problem, ale sam później zorientowałeś się,** skomentuj problem, aby dać innym znać, a następnie zamknij problem. Nawet udokumentowanie tego wyniku stanowi wkład w projekt.
 
 ### Otwieranie pull request
 
-Zwykle należy otworzyć żądanie ściągnięcia w następujących sytuacjach:
+Zwykle należy otworzyć pull request w następujących sytuacjach:
 
 * Prześlij trywialne poprawki (na przykład literówka, zepsuty link lub oczywisty błąd)
 * Rozpocznij pracę nad wkładem, o który zostałeś już poproszony lub który już omawiałeś w numerze
 
-Żądanie ściągnięcia nie musi reprezentować ukończonej pracy. Zwykle lepiej jest wcześniej otworzyć prośbę ściągnięcia, aby inni mogli obserwować twoje postępy lub udzielać informacji zwrotnych. Po prostu zaznacz go jako „WIP” (Work in Progress) w temacie. Zawsze możesz później dodać więcej zatwierdzeń.
+Pull request nie musi reprezentować ukończonej pracy. Zwykle lepiej jest wcześniej otworzyć pull request, aby inni mogli obserwować twoje postępy lub udzielać informacji zwrotnych. Po prostu zaznacz go jako „WIP” (Work in Progress) w temacie. Zawsze możesz później dodać więcej commitów.
 
-Jeśli projekt znajduje się na GitHub, oto jak przesłać żądanie ściągnięcia:
+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 do oryginalnego repozytorium „upstream”, dodając je jako zdalne. Wyciągaj zmiany z „upstream” często, abyś był na bieżąco, aby po przesłaniu żądania ściągania konflikty scalania 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://help.github.com/articles/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 żądania ściągnięcia.
-* **Sprawdzenie swoich zmian!** Uruchom zmiany w stosunku do istniejących testów, jeśli istnieją, i w razie potrzeby utwórz nowe. Niezależnie od tego, czy testy istnieją, czy nie, upewnij się, że zmiany nie psują istniejącego projektu.
-* **Wkład w styl projektu** najlepiej jak potrafisz. Może to oznaczać stosowanie wcięć, średników lub komentarzy inaczej niż w swoim własnym repozytorium, ale ułatwia opiekunowi scalenie, innym zrozumienie i utrzymanie w przyszłości.
+* **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.
+* **Sprawdzenie swoich zmian!** Uruchom istniejące testy w stosunku to twoich zmian, i w razie potrzeby utwórz nowe. Niezależnie od tego, czy testy istnieją, czy nie, upewnij się, że zmiany nie psują istniejącego projektu.
+* **Wkład w styl projektu** najlepiej jak potrafisz. Może to oznaczać stosowanie wcięć, średników lub komentarzy inaczej niż w swoim własnym repozytorium, co ułatwia opiekunowi scalenie, innym zrozumienie i utrzymanie w przyszłości.
 
 Jeśli to twój pierwszy pull request, sprawdź [Make a Pull Request](http://makeapullrequest.com/), które @kentcdodds utworzone jako instruktażowy samouczek wideo. Możesz także przećwiczyć składanie pull request w repozytorium [First Contributions](https://github.com/Roshanjossey/first-contributions), stworzonym przez @Roshanjossey.
 
 ## Co dzieje się po przesłaniu wkładu
 
-Zrobiłeś to! Gratulujemy zostania współpracownikiem typu open source. Mamy nadzieję, że to pierwszy z wielu.
+Zrobiłeś to! Gratulujemy zostania współpracownikiem typu open source. Mamy nadzieję, że to pierwszy z wielu twoich wkładów.
 
 Po przesłaniu wkładu nastąpi jedna z następujących sytuacji:
 
@@ -511,11 +511,11 @@ Po przesłaniu wkładu nastąpi jedna z następujących sytuacji:
 
 Mam nadzieję, że [sprawdziłeś projekt pod kątem oznak aktywności](../how-to-contribute/#lista-kontrolna-przed-wniesieniem-wkładu) przed wniesieniem wkładu. Jednak nawet w przypadku aktywnego projektu możliwe jest, że Twój wkład nie uzyska odpowiedzi.
 
-Jeśli nie otrzymałeś odpowiedzi od ponad tygodnia, możesz grzecznie odpowiedzieć w tym samym wątku, prosząc kogoś o recenzję. Jeśli znasz nazwisko właściwej osoby do sprawdzenia swojego wkładu, możesz @-mentionować ją w tym wątku.
+Jeśli nie otrzymałeś odpowiedzi od ponad tygodnia, możesz grzecznie odpowiedzieć w tym samym wątku, prosząc kogoś o recenzję. Jeśli znasz właściwą osobę do sprawdzenia swojego wkładu, możesz @-mentionować ją w tym wątku.
 
 **Nie** docieraj do tej osoby prywatnie; pamiętaj, że komunikacja publiczna jest niezbędna w projektach typu open source.
 
-Jeśli zrobisz uprzejme uderzenie i nadal nikt nie zareaguje, możliwe, że nikt nigdy nie odpowie. To nie jest wspaniałe uczucie, ale nie zniechęcaj się. Zdarzyło się wszystkim! Istnieje wiele możliwych powodów, dla których nie otrzymałeś odpowiedzi, w tym okoliczności osobiste, które mogą być poza twoją kontrolą. Spróbuj znaleźć inny projekt lub sposób na wniesienie wkładu. Jeśli tak, to dobry powód, aby nie poświęcać zbyt wiele czasu na wkład, zanim inni członkowie społeczności będą zaangażowani i reagują.
+Jeśli uprzejmie kogoś zapytasz i nadal nikt nie zareaguje, możliwe, że nikt nigdy nie odpowie. To nie jest zbyt miłe uczucie, ale nie zniechęcaj się. Zdarzyło się wszystkim! Istnieje wiele możliwych powodów, dla których nie otrzymałeś odpowiedzi, w tym okoliczności osobiste, które mogą być poza twoją kontrolą. Spróbuj znaleźć inny projekt lub sposób na wniesienie wkładu. Jeśli tak, to dobry powód, aby nie poświęcać zbyt wiele czasu na wkład, zanim inni członkowie społeczności nie będą zaangażowani i nie będą reagować.
 
 ### 🚧 Ktoś prosi o zmianę Twojego wkładu.
 
@@ -523,11 +523,11 @@ Często zdarza się, że będziesz proszony o wprowadzenie zmian do Twojego wkł
 
 Gdy ktoś prosi o zmiany, bądź responsywny. Sprawdzili Twój wkład. Otwarcie PR i odejście to zła forma. Jeśli nie wiesz, jak wprowadzić zmiany, zbadaj problem, a następnie poproś o pomoc, jeśli jej potrzebujesz.
 
-Jeśli nie masz czasu na pracę nad problemem (na przykład, jeśli rozmowa trwa od miesięcy, a Twoja sytuacja uległa zmianie), powiadom opiekuna, aby nie oczekiwał odpowiedzi. Ktoś inny może być szczęśliwy, aby przejąć.
+Jeśli nie masz czasu na pracę nad problemem (na przykład, jeśli rozmowa trwa od miesięcy, a Twoja sytuacja uległa zmianie), powiadom opiekuna, aby nie oczekiwał odpowiedzi. Ktoś inny może być szczęśliwy, aby przejąć ten problem.
 
 ### 👎 Twój wkład nie zostanie zaakceptowany.
 
-Twój wkład może, ale nie musi, zostać ostatecznie zaakceptowany. Mam nadzieję, że nie włożyłeś już w to zbyt wiele pracy. Jeśli nie masz pewności, dlaczego nie zostało to zaakceptowane, całkowicie uzasadnione jest poproszenie opiekuna o opinie i wyjaśnienia. Ostatecznie jednak musisz uszanować, że to jest ich decyzja. Nie kłóć się ani nie bądź wrogi. Jeśli się nie zgadzasz, możesz zawsze rozwidlać i pracować nad własną wersją!
+Twój wkład może, ale nie musi, zostać ostatecznie zaakceptowany. Mam nadzieję, że nie włożyłeś już w to zbyt wiele pracy. Jeśli nie masz pewności, dlaczego nie zostało to zaakceptowane, całkowicie uzasadnione jest poproszenie opiekuna o opinie i wyjaśnienia. Ostatecznie jednak musisz uszanować, że to jest ich decyzja. Nie kłóć się ani nie bądź wrogi. Jeśli się nie zgadzasz, możesz zawsze zrobić forka i pracować nad własną wersją!
 
 ### 🎉 Twój wkład zostanie zaakceptowany.
 

From 3ea36cc58795c8b4c119808b5f7e09da980d7949 Mon Sep 17 00:00:00 2001
From: Ernest Rudnicki <e.rudnicki96@gmail.com>
Date: Mon, 15 Aug 2022 10:56:45 +0200
Subject: [PATCH 364/749] fix typos

---
 _articles/pl/how-to-contribute.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index b8fa02aa09b..f20cd6c7671 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -120,7 +120,7 @@ Nawet jeśli lubisz pisać kod, inne rodzaje wkładów to świetny sposób na za
 ### Czy lubisz organizować?
 
 * Twórz łącza do duplikatów problemów i sugeruj ich nowe etykiety, aby utrzymać porządek
-* Przejrzyj otwarte problemy i zassugeruj zamknięcie starych, [jak @nzakas zrobił dla ESLint](https://github.com/eslint/eslint/issues/6765)
+* Przejrzyj otwarte problemy i zasugeruj zamknięcie starych, [jak @nzakas zrobił dla ESLint](https://github.com/eslint/eslint/issues/6765)
 * Zadaj pytania wyjaśniające na temat ostatnio otwartych zagadnień, aby popchnąć dyskusję do przodu
 
 ### Czy lubisz kodować?
@@ -349,7 +349,7 @@ Teraz wykonaj te same kroki dla PR (pull requests) projektu.
   </label>
 </div>
 
-**Projekt jest otwarty na nwoych autorów**
+**Projekt jest otwarty na nowych autorów**
 
 Projekt przyjazny i gościnny sygnalizuje, że będą otwarci na nowych autorów.
 
@@ -453,7 +453,7 @@ Jeśli nie możesz znaleźć swojego pomysłu w innym miejscu, możesz zrobić k
 
 * **Issues** są jak rozpoczęcie rozmowy lub dyskusji
 * **Pull requests** są rozpoczęciem pracy nad rozwiązaniem
-* **Aby uzyskać lekką komunikację,** takie jak pytanie wyjaśniające lub poradnik, spróbuj zadać pytanie Stack Overflow, IRC, Slacka lub innych kanałów komunikacyjnych, jeśli projekt ma taki
+* **Aby uzyskać lekką komunikację,** takie jak pytanie wyjaśniające lub poradnik, spróbuj zadać pytanie Stack Overflow, IRC, Slacka lub innych kanałów komunikacyjnych, jeśli projekt takie ma
 
 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.
 
@@ -496,7 +496,7 @@ Jeśli projekt znajduje się na GitHub, oto jak przesłać pull request:
 * **[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.
-* **Sprawdzenie swoich zmian!** Uruchom istniejące testy w stosunku to twoich zmian, i w razie potrzeby utwórz nowe. Niezależnie od tego, czy testy istnieją, czy nie, upewnij się, że zmiany nie psują istniejącego projektu.
+* **Sprawdzenie swoich zmian!** Uruchom istniejące testy w stosunku do twoich zmian, i w razie potrzeby utwórz nowe. Niezależnie od tego, czy testy istnieją, czy nie, upewnij się, że zmiany nie psują istniejącego projektu.
 * **Wkład w styl projektu** najlepiej jak potrafisz. Może to oznaczać stosowanie wcięć, średników lub komentarzy inaczej niż w swoim własnym repozytorium, co ułatwia opiekunowi scalenie, innym zrozumienie i utrzymanie w przyszłości.
 
 Jeśli to twój pierwszy pull request, sprawdź [Make a Pull Request](http://makeapullrequest.com/), które @kentcdodds utworzone jako instruktażowy samouczek wideo. Możesz także przećwiczyć składanie pull request w repozytorium [First Contributions](https://github.com/Roshanjossey/first-contributions), stworzonym przez @Roshanjossey.
@@ -515,7 +515,7 @@ Jeśli nie otrzymałeś odpowiedzi od ponad tygodnia, możesz grzecznie odpowied
 
 **Nie** docieraj do tej osoby prywatnie; pamiętaj, że komunikacja publiczna jest niezbędna w projektach typu open source.
 
-Jeśli uprzejmie kogoś zapytasz i nadal nikt nie zareaguje, możliwe, że nikt nigdy nie odpowie. To nie jest zbyt miłe uczucie, ale nie zniechęcaj się. Zdarzyło się wszystkim! Istnieje wiele możliwych powodów, dla których nie otrzymałeś odpowiedzi, w tym okoliczności osobiste, które mogą być poza twoją kontrolą. Spróbuj znaleźć inny projekt lub sposób na wniesienie wkładu. Jeśli tak, to dobry powód, aby nie poświęcać zbyt wiele czasu na wkład, zanim inni członkowie społeczności nie będą zaangażowani i nie będą reagować.
+Jeśli uprzejmie kogoś zapytasz i nadal nikt nie zareaguje, możliwe, że nikt nigdy nie odpowie. To nie jest to zbyt miłe uczucie, ale nie zniechęcaj się. Zdarzyło się wszystkim! Istnieje wiele możliwych powodów, dla których nie otrzymałeś odpowiedzi, w tym okoliczności osobiste, które mogą być poza twoją kontrolą. Spróbuj znaleźć inny projekt lub sposób na wniesienie wkładu. Jeśli tak, to dobry powód, aby nie poświęcać zbyt wiele czasu na wkład, zanim inni członkowie społeczności nie będą zaangażowani i nie będą reagować.
 
 ### 🚧 Ktoś prosi o zmianę Twojego wkładu.
 

From 530f1d05d1e3c3186c63b75a4f796ac860d60904 Mon Sep 17 00:00:00 2001
From: Ernest Rudnicki <e.rudnicki96@gmail.com>
Date: Mon, 15 Aug 2022 11:04:15 +0200
Subject: [PATCH 365/749] fix typo in a word

---
 _articles/pl/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index f20cd6c7671..d2229607ec4 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -48,7 +48,7 @@ Z definicji cała twoja praca z otwartym kodem źródłowym jest publiczna, co o
 
 ### Rozwiń swoje zdolności interpersonalne
 
-Open source oferuje możliwośc ćwiczenia umiejętności przywódczych i zarządczych, takich jak rozwiązywanie konfliktów, organizowanie zespołów i ustalanie priorytetów pracy.
+Open source oferuje możliwość ćwiczenia umiejętności przywódczych i zarządczych, takich jak rozwiązywanie konfliktów, organizowanie zespołów i ustalanie priorytetów pracy.
 
 ### Daje to możliwość wprowadzania zmian, nawet tych małych
 

From 183b5e756239587c0debe0090fa6d021afd40225 Mon Sep 17 00:00:00 2001
From: Ernest Rudnicki <e.rudnicki96@gmail.com>
Date: Tue, 16 Aug 2022 16:12:12 +0200
Subject: [PATCH 366/749] update getting-paid polish version

---
 _articles/pl/getting-paid.md | 70 ++++++++++++++++++------------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/_articles/pl/getting-paid.md b/_articles/pl/getting-paid.md
index 32a1ea63766..6c063787907 100644
--- a/_articles/pl/getting-paid.md
+++ b/_articles/pl/getting-paid.md
@@ -1,7 +1,7 @@
 ---
 lang: pl
-title: Zarabianie za pracę Open Source
-description: Utrzymaj swoją pracę w otwartym kodzie źródłowym, uzyskując wsparcie finansowe na Twój czas lub projekt.
+title: Zarabianie poprzez pracę Open Source
+description: Pracuj w otwartym kodzie źródłowym, uzyskując wsparcie finansowe za swój czas lub projekt.
 class: getting-paid
 order: 7
 image: /assets/images/cards/getting-paid.png
@@ -28,7 +28,7 @@ Istnieje wiele powodów, dla których dana osoba nie chce otrzymywać wynagrodze
 
 * **Mogą już mieć pracę na pełny etat, którą kochają,** co pozwala im wnieść wkład w open source w wolnym czasie.
 * **Lubią myśleć o otwartym źródle jako hobby** lub kreatywnej ucieczce i nie chcą czuć się zobowiązani finansowo do pracy nad swoimi projektami.
-* **Dostają inne korzyści z wkładu w open source,** takie jak budowanie reputacji lub portfolio, uczenie się nowych umiejętności lub zbliżenie się do społeczności.
+* **Dostają inne korzyści z wkładu w open source,** takie jak budowanie reputacji lub portfolio, uczenie się nowych umiejętności lub poczucie przynależności do społeczności.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
@@ -40,9 +40,9 @@ Istnieje wiele powodów, dla których dana osoba nie chce otrzymywać wynagrodze
   </p>
 </aside>
 
-Dla innych, szczególnie gdy składki są w toku lub wymagają znacznego czasu, zarabianie na wkładach w open source jest jedynym sposobem, w jaki mogą wziąć udział, ponieważ wymaga tego projekt lub z powodów osobistych.
+Dla innych, z powodu ich sytuacji osobistych lub gdy projekt potrzebuje ciągłego wkładu oraz poświęcenia znacznej ilości czasu, zarabianie na wkładach open source jest jedynym sposobem, w jaki mogą oni wziąć udział w takim projekcie.
 
-Utrzymanie popularnych projektów może być znaczącą odpowiedzialnością, ponieważ zajmuje 10 lub 20 godzin tygodniowo zamiast kilku godzin miesięcznie.
+Utrzymanie popularnych projektów wymaga dużej odpowiedzialności, ponieważ taka praca może zajmować od 10 do 20 godzin tygodniowo zamiast kilku godzin miesięcznie.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
@@ -54,7 +54,7 @@ Utrzymanie popularnych projektów może być znaczącą odpowiedzialnością, po
   </p>
 </aside>
 
-Płatna praca umożliwia także osobom z różnych środowisk życiowych wniesienie znaczącego wkładu. Niektóre osoby nie mogą sobie pozwolić na niepłatne spędzanie czasu na projektach typu open source, w oparciu o ich obecną sytuację finansową, zadłużenie, rodzinę lub inne obowiązki opiekuńcze. Oznacza to, że świat nigdy nie dostrzega wkładu utalentowanych ludzi, których nie stać na poświęcenie swojego czasu. Ma to implikacje etyczne, jak to [opisał](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) @ashedryden, ponieważ praca, która jest wykonana, jest uprzedzony na korzyść tych, którzy już mają zalety w życiu, którzy następnie zyskują dodatkowe korzyści na podstawie swojego wkładu wolontariuszy, podczas gdy inni, którzy nie są w stanie zgłosić się na ochotnika, nie dostają później możliwości, co wzmacnia obecny brak różnorodności w otwartym oprogramowaniu społeczność.
+Płatna praca umożliwia także osobom z różnych sytuacji życiowych wniesienie znaczącego wkładu. Niektóre osoby nie mogą sobie pozwolić na nieodpłatne spędzanie czasu na projektach typu open source, w oparciu o ich obecną sytuację finansową, zadłużenie, rodzinę lub inne obowiązki opiekuńcze. Oznacza to, że świat nigdy nie dostrzeże wkładu utalentowanych ludzi, których nie stać na poświęcenie swojego czasu. Ma to implikacje etyczne, jak to [opisał](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) @ashedryden, ponieważ wykonana praca sprzyja tym, którzy już mają pewną przewagę w życiu, a następnie zyskują dodatkowe korzyści na podstawie swojego wolontaryjnego wkładu, podczas gdy inni, którzy nie są w stanie pracować jako wolontariusze, nie dostają później kolejnych możliwości, co wzmacnia obecny brak różnorodności w społeczności open source.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
@@ -72,7 +72,7 @@ Jeśli szukasz wsparcia finansowego, musisz rozważyć dwie ścieżki. Możesz s
 
 Obecnie wiele osób otrzymuje wynagrodzenie za pracę w niepełnym lub pełnym wymiarze godzin na otwartym oprogramowaniu. Najczęstszym sposobem zarabiania za czas jest rozmowa z pracodawcą.
 
-Łatwiej jest uzasadnić pracę z otwartym kodem źródłowym, jeśli Twój pracodawca faktycznie korzysta z projektu, ale wykaż się kreatywnością. Być może twój pracodawca nie korzysta z projektu, ale używa Pythona, a utrzymanie popularnego projektu w Pythonie pomaga przyciągnąć nowych deweloperów języka Python. Być może sprawia to, że Twój pracodawca wydaje się bardziej przyjazny dla programistów.
+Łatwiej jest uzasadnić pracę z otwartym kodem źródłowym, jeśli twój pracodawca faktycznie korzysta z projektu, ale dobrym pomysłem byłoby kreatywne uzasadnienie swojej prośby. Być może twój pracodawca nie korzysta z projektu, ale używa Pythona, a utrzymanie popularnego projektu w Pythonie pomaga przyciągnąć nowych deweloperów języka Python. Może to sprawić, że twój pracodawca będzie wydawał się bardziej atrakcyjny dla innych programistów.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
@@ -84,15 +84,15 @@ Obecnie wiele osób otrzymuje wynagrodzenie za pracę w niepełnym lub pełnym w
   </p>
 </aside>
 
-Jeśli nie masz istniejącego projektu typu open source, nad którym chciałbyś pracować, ale wolisz, aby twoje bieżące wyniki pracy były typu open source, poproś pracodawcę o otwarcie częściowego oprogramowania wewnętrznego.
+Jeśli nie masz istniejącego projektu typu open source, nad którym chciałbyś pracować, możesz poprosić swojego pracodawcę aby wydał część wewnętrznego oprogramowania jako open source.
 
-Wiele firm opracowuje programy typu open source, aby budować swoją markę i rekrutować talenty wysokiej jakości.
+Wiele firm opracowywuje programy typu open source, aby budować swoją markę i rekrutować utalentowanych pracowników.
 
-@hueniverse, na przykład stwierdzono, że istnieją finansowe powody, aby uzasadnić [inwestycję Walmarta w open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). I @jamesgpearce stwierdził, że program open source Facebooka [zrobił różnicę](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) w rekrutacji:
+@hueniverse, na przykład stwierdził, że istnieją finansowe powody, aby uzasadnić [inwestycję Walmarta w open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). I @jamesgpearce także stwierdził, że program open source Facebooka [pomógł](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) w rekrutacji:
 
 > It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
 
-Jeśli Twoja firma pójdzie tą drogą, ważne jest, aby zachować wyraźne granice między działalnością społeczności a działalnością firmy. Ostatecznie, open source utrzymuje się dzięki wkładom ludzi z całego świata, a to jest większe niż jakakolwiek jedna firma lub lokalizacja.
+Jeśli Twoja firma pójdzie tą drogą, ważne jest, aby zachować wyraźne granice między działalnością społeczności a działalnością firmy. Ostatecznie, open source utrzymuje się dzięki wkładom ludzi z całego świata, a to jest większe niż jakakolwiek firma lub organizacja.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
@@ -104,35 +104,35 @@ Jeśli Twoja firma pójdzie tą drogą, ważne jest, aby zachować wyraźne gran
   </p>
 </aside>
 
-Jeśli nie możesz przekonać swojego obecnego pracodawcy do priorytetowego traktowania pracy typu open source, zastanów się nad znalezieniem nowego pracodawcy, który zachęca pracowników do korzystania z oprogramowania typu open source. Poszukaj firm, które wyrażają swoje zaangażowanie w pracę z otwartym oprogramowaniem. Na przykład:
+Jeśli nie możesz przekonać swojego obecnego pracodawcy do priorytetowego traktowania pracy typu open source, zastanów się nad znalezieniem nowego, który zachęca pracowników do korzystania z oprogramowania typu open source. Poszukaj firm, które wyrażają swoje zaangażowanie w pracę z otwartym oprogramowaniem. Na przykład:
 
 * Niektóre firmy, jak [Netflix](https://netflix.github.io/) lub [PayPal](https://paypal.github.io/), mają strony internetowe, które podkreślają ich zaangażowanie w open source
 * [Zalando](https://opensource.zalando.com) opublikował [politykę dotyczącą wkładu typu open source](https://opensource.zalando.com/docs/using/contributing/) dla pracowników
 
-Projekty, które powstały w dużej firmie, takie jak [Go](https://github.com/golang) lub [React](https://github.com/facebook/react), prawdopodobnie również zatrudnią ludzi do pracy na otwartym oprogramowaniu.
+Projekty, które powstały w dużej firmie, takie jak [Go](https://github.com/golang) lub [React](https://github.com/facebook/react), prawdopodobnie również zatrudniają ludzi do pracy na otwartym oprogramowaniu.
 
 W zależności od osobistych okoliczności możesz spróbować samodzielnie zebrać pieniądze, aby sfinansować swoją pracę typu open source. Na przykład:
 
-* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) sfinansował swoją pracę poprzez [GitHub Sponsors](https://github.com/sponsors)
 * @gaearon sfinansował swoją pracę [Redux](https://github.com/reactjs/redux) poprzez [kampanię crowdfundingową Patreon](https://redux.js.org/)
-* @andrewgodwin sfinansował prace nad migracjami schematu Django [poprzez kampanię Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+* @andrewgodwin sfinansował prace nad Django schema migrations [poprzez kampanię Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
-Wreszcie, czasami projekty open source dają nagrody za problemy, z którymi możesz pomyśleć o pomocy.
+Wreszcie, czasami niektóre projekty open source nagradzają za rozwiązywanie danych problemów.
 
-* @ConnorChristie był w stanie otrzymać wynagrodzenie za [pomoc](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol pracować nad biblioteką JavaScript [poprzez nagrodę za gitcoin](https://gitcoin.co/).
-* @mamiM zrobiłem japońskie tłumaczenia dla @MetaMask po tym, jak [problem został sfinansowany przez Bounties Network](https://explorer.bounties.network/bounty/134).
+* @ConnorChristie był w stanie otrzymać wynagrodzenie za [pomoc](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol pracował nad biblioteką JavaScript [poprzez nagrodę za gitcoin](https://gitcoin.co/).
+* @mamiM zrobił japońskie tłumaczenia dla @MetaMask po tym, jak [problem został sfinansowany przez Bounties Network](https://explorer.bounties.network/bounty/134).
 
 ## Znajdowanie funduszy na swój projekt
 
 Oprócz ustaleń dotyczących indywidualnych uczestników, czasami projekty zbierają pieniądze od firm, osób fizycznych lub innych osób na finansowanie bieżącej pracy.
 
-Finansowanie organizacyjne może zostać przeznaczone na opłacenie obecnych uczestników, pokrycie kosztów prowadzenia projektu (takich jak opłaty za hosting) lub inwestowanie w nowe funkcje lub pomysły.
+Finansowanie organizacyjne może zostać przeznaczone na opłacenie obecnych uczestników, pokrycie kosztów prowadzenia projektu (takich jak opłaty za hosting) lub inwestowanie w nowe funkcjonalności lub pomysły.
 
-Wraz ze wzrostem popularności oprogramowania typu open source znalezienie funduszy na projekty jest nadal eksperymentalne, ale dostępnych jest kilka typowych opcji.
+Wraz ze wzrostem popularności oprogramowania typu open source znalezienie funduszy na projekty jest nadal niepewne, ale dostępnych jest kilka możliwych opcji.
 
 ### Zbieraj pieniądze na swoją pracę poprzez kampanie crowdfundingowe lub sponsoring
 
-Znalezienie sponsorów działa dobrze, jeśli masz już silną publiczność lub reputację lub twój projekt jest bardzo popularny.
+Znalezienie sponsorów działa dobrze, jeśli masz już odpowiednią publiczność, reputację lub twój projekt jest bardzo popularny.
 Kilka przykładów sponsorowanych projektów to:
 
 * **[webpack](https://github.com/webpack)** zbiera pieniądze od firm i osób prywatnych [poprzez OpenCollective](https://opencollective.com/webpack)
@@ -141,50 +141,50 @@ Kilka przykładów sponsorowanych projektów to:
 
 ### Utwórz strumień przychodów
 
-W zależności od projektu możesz być w stanie pobierać opłaty za wsparcie komercyjne, opcje hostowane lub dodatkowe funkcje. Kilka przykładów obejmuje:
+W zależności od projektu możesz być w stanie pobierać opłaty za wsparcie komercyjne, opcje hostowane lub dodatkowe funkcjonalności. Kilka przykładów obejmuje:
 
 * **[Sidekiq](https://github.com/mperham/sidekiq)** oferuje płatne wersje dodatkowego wsparcia
 * **[Travis CI](https://github.com/travis-ci)** oferuje płatne wersje swojego produktu
 * **[Ghost](https://github.com/TryGhost/Ghost)** jest organizacją non-profit z płatną usługą zarządzaną
 
-Niektóre popularne projekty, takie jak [npm](https://github.com/npm/cli) oraz [Docker](https://github.com/docker/docker), nawet pozyskały kapitał wysokiego ryzyka w celu wsparcia rozwoju ich działalności.
+Niektóre popularne projekty, takie jak [npm](https://github.com/npm/cli) oraz [Docker](https://github.com/docker/docker), pozyskały nawet kapitał wysokiego ryzyka w celu wsparcia rozwoju ich działalności.
 
 ### Złóż wniosek o dofinansowanie
 
-Niektóre fundacje i firmy oferują granty na prace typu open source. Czasami dotacje można wypłacać osobom fizycznym bez zakładania osobowości prawnej dla projektu.
+Niektóre fundacje i firmy oferują granty na prace typu open source. Czasami dotacje można wypłacać osobom fizycznym bez zakładania działalności prawnej dla projektu.
 
 * **[Read the Docs](https://github.com/rtfd/readthedocs.org)** otrzymał dotację od [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
 * **[OpenMRS](https://github.com/openmrs)** praca została sfinansowana przez [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
 * **[Libraries.io](https://github.com/librariesio)** otrzymał dotację z [Sloan Foundation](https://sloan.org/programs/digital-technology)
 * **[Python Software Foundation](https://www.python.org/psf/grants/)** oferuje granty na prace związane z Pythonem
 
-Aby uzyskać bardziej szczegółowe opcje i studia przypadków, @nayafia [napisał przewodnik](https://github.com/nayafia/lemonade-stand) jak zarabiać za pracę typu open source. Różne rodzaje finansowania wymagają różnych umiejętności, więc rozważ swoje mocne strony, aby dowiedzieć się, która opcja będzie dla Ciebie najlepsza.
+Aby uzyskać bardziej szczegółowe opcje i studia przypadków, @nayafia [napisał przewodnik](https://github.com/nayafia/lemonade-stand) jak zarabiać za pracę typu open source. Różne rodzaje finansowania wymagają różnych umiejętności, więc rozważ swoje mocne strony, aby dowiedzieć się, która opcja będzie dla ciebie najlepsza.
 
-## Budowanie uzasadnienia wsparcia finansowego
+## Budowanie uzasadnienia dla wsparcia finansowego
 
-Niezależnie od tego, czy Twój projekt jest nowym pomysłem, czy istnieje już od lat, powinieneś się zastanowić, czy nie zidentyfikować docelowego fundatora i przedstawić przekonujący argument.
+Niezależnie od tego, czy twój projekt jest nowym pomysłem, czy istnieje już od lat, powinieneś się zastanowić, czy nie warto zidentyfikować docelowego fundatora i przedstawić przekonujące argumenty.
 
-Niezależnie od tego, czy chcesz zapłacić za swój czas, czy zbierać fundusze na projekt, powinieneś być w stanie odpowiedzieć na następujące pytania.
+Niezależnie od tego, czy chcesz zarobić za swój czas, czy zbierać fundusze na projekt, powinieneś być w stanie odpowiedzieć na następujące pytania.
 
 ### Wpływ
 
-Dlaczego ten projekt jest przydatny? Dlaczego tak lubią Twoi użytkownicy lub potencjalni użytkownicy? Gdzie będzie za pięć lat?
+Dlaczego ten projekt jest przydatny? Dlaczego tak lubią twoi użytkownicy lub potencjalni użytkownicy? Gdzie będzie za pięć lat?
 
-### Trakcja
+### Popularność projektu
 
-Postaraj się zebrać dowody na to, że projekt ma znaczenie, czy to metryki, anegdoty czy referencje. Czy są teraz jakieś firmy lub godne uwagi osoby korzystające z Twojego projektu? Jeśli nie, czy wybitna osoba to poparła?
+Postaraj się zebrać dowody na to, że projekt ma znaczenie, czy to metryki, anegdoty czy referencje. Czy istnieją jakieś firmy lub godne uwagi osoby korzystające z twojego projektu? Jeśli nie, czy jakaś wybitna osoba go poparła?
 
 ### Wartość do finansowania
 
-Do fundatorów, czy to pracodawcy, czy fundacji przyznającej granty, często zwraca się szansa. Dlaczego powinni wesprzeć Twój projekt w jakikolwiek inny sposób? Jakie korzyści odnoszą osobiście?
+Do fundatorów, czy to pracodawcy, czy fundacji przyznającej granty, często zwracają się inne projekty. Dlaczego powinni wesprzeć akurat twój projekt w jakikolwiek sposób? Jakie korzyści odnosią z tego osobiście?
 
 ### Wykorzystanie funduszy
 
-Co dokładnie osiągniesz dzięki proponowanemu finansowaniu? Skoncentruj się na kamieniach milowych projektu lub jego wynikach, zamiast płacić pensję.
+Co dokładnie osiągniesz dzięki proponowanemu finansowaniu? Skoncentruj się na kamieniach milowych projektu lub jego wynikach, zamiast na opłacaniu pensji.
 
 ### Jak otrzymasz fundusze
 
-Czy podmiot finansujący ma jakieś wymagania dotyczące wypłaty? Na przykład być może trzeba być organizacją non-profit lub mieć sponsora podatkowego typu non-profit. A może fundusze należy przekazać indywidualnemu kontrahentowi, a nie organizacji. Wymagania te różnią się w zależności od fundatora, dlatego należy wcześniej przeprowadzić badania.
+Czy podmiot finansujący ma jakieś wymagania dotyczące wypłaty? Na przykład być może trzeba być organizacją non-profit lub mieć sponsora podatkowego typu non-profit. A może fundusze należy przekazać indywidualnemu kontrahentowi, a nie organizacji. Wymagania te różnią się w zależności od fundatora, dlatego należy wcześniej przeprowadzić odpowiedni research.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
@@ -198,4 +198,4 @@ Czy podmiot finansujący ma jakieś wymagania dotyczące wypłaty? Na przykład
 
 ## Eksperymentuj i nie poddawaj się
 
-Zbieranie pieniędzy nie jest łatwe, bez względu na to, czy jesteś projektem typu open source, organizacją non-profit, czy też uruchomieniem oprogramowania, aw większości przypadków wymaga kreatywności. Określenie, w jaki sposób chcesz otrzymać zapłatę, przeprowadzenie badań i postawienie się w sytuacji gracza finansującego, pomoże ci zbudować przekonującą argumentację za finansowaniem.
+Zbieranie pieniędzy nie jest łatwe, bez względu na to, czy kierujesz projektem typu open source, organizacją non-profit, czy też startupem, a w większości przypadków wymaga kreatywności. Określenie, w jaki sposób chcesz otrzymać zapłatę, zrobienie odpowiedniego researchu i postawienie się w sytuacji fundatora, pomoże ci zbudować przekonującą argumentację za finansowaniem.

From 85e45092b51e0faa543949b0338cf50c2f7bc29b Mon Sep 17 00:00:00 2001
From: Ernest Rudnicki <e.rudnicki96@gmail.com>
Date: Tue, 16 Aug 2022 16:20:04 +0200
Subject: [PATCH 367/749] fix typo in getting-paid pl version

---
 _articles/pl/getting-paid.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/getting-paid.md b/_articles/pl/getting-paid.md
index 6c063787907..90c71a59f88 100644
--- a/_articles/pl/getting-paid.md
+++ b/_articles/pl/getting-paid.md
@@ -176,7 +176,7 @@ Postaraj się zebrać dowody na to, że projekt ma znaczenie, czy to metryki, an
 
 ### Wartość do finansowania
 
-Do fundatorów, czy to pracodawcy, czy fundacji przyznającej granty, często zwracają się inne projekty. Dlaczego powinni wesprzeć akurat twój projekt w jakikolwiek sposób? Jakie korzyści odnosią z tego osobiście?
+Do fundatorów, czy to pracodawcy, czy fundacji przyznającej granty, często zwracają się inne projekty. Dlaczego powinni wesprzeć akurat twój projekt w jakikolwiek sposób? Jakie korzyści odniosą z tego osobiście?
 
 ### Wykorzystanie funduszy
 

From 27b5f82a52358de674a1e21f574829f332d6584e Mon Sep 17 00:00:00 2001
From: Ernest Rudnicki <e.rudnicki96@gmail.com>
Date: Tue, 16 Aug 2022 16:31:21 +0200
Subject: [PATCH 368/749] change uppercase possesive pronouns

---
 _articles/pl/how-to-contribute.md | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index d2229607ec4..6f139ccb303 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -28,7 +28,7 @@ Dlaczego ludzie przyczyniają się do open source? Z wielu powodów!
 
 ### Ulepsz oprogramowanie, na którym możesz polegać
 
-Wielu współpracowników open source zaczyna od bycia użytkownikami oprogramowania, do którego następnie wnoszą swój wkład. Gdy znajdziesz błąd w używanym przez ciebie oprogramowaniu open source, możesz zajrzeć do źródła, aby sprawdzić, czy możesz go naprawić samodzielnie. Jeśli tak jest, to dodanie poprawki jest najlepszym sposobem, aby zapewnić, że Twoi znajomi (i ty, kiedy zaktualizujesz do następnej wersji) będą mogli z niej skorzystać.
+Wielu współpracowników open source zaczyna od bycia użytkownikami oprogramowania, do którego następnie wnoszą swój wkład. Gdy znajdziesz błąd w używanym przez ciebie oprogramowaniu open source, możesz zajrzeć do źródła, aby sprawdzić, czy możesz go naprawić samodzielnie. Jeśli tak jest, to dodanie poprawki jest najlepszym sposobem, aby zapewnić, że twoi znajomi (i ty, kiedy zaktualizujesz do następnej wersji) będą mogli z niej skorzystać.
 
 ### Rozwiń swoje umiejętności
 
@@ -58,7 +58,7 @@ Nie musisz stać się dożywotnim uczestnikiem, aby cieszyć się uczestnictwem
 
 Jeśli jesteś nowym współpracownikiem typu open source, proces może być zastraszający. Jak znaleźć odpowiedni projekt? Co jeśli nie wiesz, jak programować? Co jeśli coś pójdzie nie tak?
 
-Nie martwić się! Istnieje wiele sposobów na zaangażowanie się w projekt open source, a kilka wskazówek pomoże Ci w pełni wykorzystać swoje doświadczenie.
+Nie martwić się! Istnieje wiele sposobów na zaangażowanie się w projekt open source, a kilka wskazówek pomoże ci w pełni wykorzystać swoje doświadczenie.
 
 ### Nie musisz przekazywać kodu
 
@@ -152,7 +152,7 @@ Na przykład:
 * @h5bp utrzymuje [listę potencjalnych pytań do rozmowy kwalifikacyjnej](https://github.com/h5bp/Front-end-Developer-Interview-Questions) dla kandydatów na programistów front-end
 * @stuartlynn a @nicole-a-tesla stworzyła [zbiór zabawnych faktów na temat maskonurów](https://github.com/stuartlynn/puffin_facts)
 
-Nawet jeśli jesteś programistą, praca nad projektem dokumentacji może pomóc w rozpoczęciu pracy w środowisku open source. Praca z projektami niewymagającymi kodu jest często mniej zastraszająca, a proces współpracy zwiększy Twoje zaufanie i doświadczenie.
+Nawet jeśli jesteś programistą, praca nad projektem dokumentacji może pomóc w rozpoczęciu pracy w środowisku open source. Praca z projektami niewymagającymi kodu jest często mniej zastraszająca, a proces współpracy zwiększy twoje zaufanie i doświadczenie.
 
 ## Orientacja na nowy projekt
 
@@ -168,7 +168,7 @@ Nawet jeśli jesteś programistą, praca nad projektem dokumentacji może pomóc
 
 W przypadku czegoś więcej niż poprawa literówek, udział w open source jest jak podchodzenie do grupy nieznajomych na imprezie. Jeśli zaczniesz mówić o lamach, gdy byli głęboko w dyskusji na temat złotych rybek, prawdopodobnie spojrzą na ciebie trochę dziwnie.
 
-Zanim wskoczysz na ślepo z własnymi sugestiami, zacznij od nauki wybadywania terenu. Takie postępowanie zwiększa szanse, że Twoje pomysły zostaną zauważone i usłyszane.
+Zanim wskoczysz na ślepo z własnymi sugestiami, zacznij od nauki wybadywania terenu. Takie postępowanie zwiększa szanse, że twoje pomysły zostaną zauważone i usłyszane.
 
 ### Anatomia projektu open source
 
@@ -223,7 +223,7 @@ Możesz zeskanować plik README i znaleźć uszkodzony link lub literówkę. Lub
 
 Jeśli szukasz istniejących problemów, które możesz naprawić, każdy projekt open source ma stronę `/contribute`, która podkreśla problemy przyjazne dla początkujących, z którymi możesz zacząć. Przejdź do strony głównej repozytorium w serwisie GitHub i dodaj `/contribute` na końcu adresu URL (na przykład [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
 
-Możesz także skorzystać z jednego z następujących zasobów, aby pomóc Ci odkryć nowe projekty i wnieść swój wkład:
+Możesz także skorzystać z jednego z następujących zasobów, aby pomóc ci odkryć nowe projekty i wnieść swój wkład:
 
 * [GitHub Explore](https://github.com/explore/)
 * [Open Source Friday](https://opensourcefriday.com)
@@ -391,7 +391,7 @@ Projekt przyjazny i gościnny sygnalizuje, że będą otwarci na nowych autorów
 
 ## Jak przesłać kontrybucję
 
-Znalazłeś projekt, który Ci się podoba i jesteś gotowy, aby wnieść swój wkład. Wreszcie! Oto, w jaki sposób uzyskać odpowiedni wkład we właściwy sposób.
+Znalazłeś projekt, który ci się podoba i jesteś gotowy, aby wnieść swój wkład. Wreszcie! Oto, w jaki sposób uzyskać odpowiedni wkład we właściwy sposób.
 
 ### Skuteczna komunikacja
 
@@ -447,7 +447,7 @@ Zanim otworzysz issue, pull request lub zadasz pytanie na czacie, pamiętaj o ty
 
 ### Zbieranie kontekstu
 
-Zanim cokolwiek zrobisz, szybko sprawdź, czy Twój pomysł nie został omówiony w innym miejscu. Przejrzyj README projektu, problemy (otwarte i zamknięte), listę mailingową i przepełnienie stosu. Nie musisz spędzać godzin na przeglądaniu wszystkiego, ale szybkie poszukiwanie kilku kluczowych haseł to długa droga.
+Zanim cokolwiek zrobisz, szybko sprawdź, czy twój pomysł nie został omówiony w innym miejscu. Przejrzyj README projektu, problemy (otwarte i zamknięte), listę mailingową i przepełnienie stosu. Nie musisz spędzać godzin na przeglądaniu wszystkiego, ale szybkie poszukiwanie kilku kluczowych haseł to długa droga.
 
 Jeśli nie możesz znaleźć swojego pomysłu w innym miejscu, możesz zrobić krok. Jeśli projekt jest w serwisie GitHub, prawdopodobnie komunikujesz się, otwierając problem lub wysyłając żądanie:
 
@@ -509,7 +509,7 @@ Po przesłaniu wkładu nastąpi jedna z następujących sytuacji:
 
 ### 😭 Nie dostaniesz odpowiedzi.
 
-Mam nadzieję, że [sprawdziłeś projekt pod kątem oznak aktywności](../how-to-contribute/#lista-kontrolna-przed-wniesieniem-wkładu) przed wniesieniem wkładu. Jednak nawet w przypadku aktywnego projektu możliwe jest, że Twój wkład nie uzyska odpowiedzi.
+Mam nadzieję, że [sprawdziłeś projekt pod kątem oznak aktywności](../how-to-contribute/#lista-kontrolna-przed-wniesieniem-wkładu) przed wniesieniem wkładu. Jednak nawet w przypadku aktywnego projektu możliwe jest, że twój wkład nie uzyska odpowiedzi.
 
 Jeśli nie otrzymałeś odpowiedzi od ponad tygodnia, możesz grzecznie odpowiedzieć w tym samym wątku, prosząc kogoś o recenzję. Jeśli znasz właściwą osobę do sprawdzenia swojego wkładu, możesz @-mentionować ją w tym wątku.
 
@@ -519,11 +519,11 @@ Jeśli uprzejmie kogoś zapytasz i nadal nikt nie zareaguje, możliwe, że nikt
 
 ### 🚧 Ktoś prosi o zmianę Twojego wkładu.
 
-Często zdarza się, że będziesz proszony o wprowadzenie zmian do Twojego wkładu, niezależnie od tego, czy jest to opinia na temat zakresu Twojego pomysłu, czy zmiany w kodzie.
+Często zdarza się, że będziesz proszony o wprowadzenie zmian do twojego wkładu, niezależnie od tego, czy jest to opinia na temat zakresu twojego pomysłu, czy zmiany w kodzie.
 
-Gdy ktoś prosi o zmiany, bądź responsywny. Sprawdzili Twój wkład. Otwarcie PR i odejście to zła forma. Jeśli nie wiesz, jak wprowadzić zmiany, zbadaj problem, a następnie poproś o pomoc, jeśli jej potrzebujesz.
+Gdy ktoś prosi o zmiany, bądź responsywny. Sprawdzili twój wkład. Otwarcie PR i odejście to zła forma. Jeśli nie wiesz, jak wprowadzić zmiany, zbadaj problem, a następnie poproś o pomoc, jeśli jej potrzebujesz.
 
-Jeśli nie masz czasu na pracę nad problemem (na przykład, jeśli rozmowa trwa od miesięcy, a Twoja sytuacja uległa zmianie), powiadom opiekuna, aby nie oczekiwał odpowiedzi. Ktoś inny może być szczęśliwy, aby przejąć ten problem.
+Jeśli nie masz czasu na pracę nad problemem (na przykład, jeśli rozmowa trwa od miesięcy, a twoja sytuacja uległa zmianie), powiadom opiekuna, aby nie oczekiwał odpowiedzi. Ktoś inny może być szczęśliwy, aby przejąć ten problem.
 
 ### 👎 Twój wkład nie zostanie zaakceptowany.
 
@@ -535,4 +535,4 @@ Hooray! Udało ci się wnieść wkład typu open source!
 
 ## Zrobiłeś to!
 
-Niezależnie od tego, czy właśnie wniósłeś swój pierwszy wkład typu open source, czy szukasz nowych sposobów, mamy nadzieję, że zainspirujesz się do działania. Nawet jeśli Twój wkład nie został zaakceptowany, nie zapomnij podziękować, gdy opiekun wkłada wysiłek, aby ci pomóc. Oprogramowanie typu open source jest tworzone przez osoby takie jak Ty: jeden problem, żądanie ściągnięcia, komentarz lub piątka na raz.
+Niezależnie od tego, czy właśnie wniósłeś swój pierwszy wkład typu open source, czy szukasz nowych sposobów, mamy nadzieję, że zainspirujesz się do działania. Nawet jeśli twój wkład nie został zaakceptowany, nie zapomnij podziękować, gdy opiekun wkłada wysiłek, aby ci pomóc. Oprogramowanie typu open source jest tworzone przez osoby takie jak ty: jeden problem, żądanie ściągnięcia, komentarz lub piątka na raz.

From c5e3a7b44e0ba98cd9526b2210364680d28c3b69 Mon Sep 17 00:00:00 2001
From: Vik <63919734+ViktorOn@users.noreply.github.com>
Date: Thu, 18 Aug 2022 16:17:48 +0300
Subject: [PATCH 369/749] Update metrics.md

---
 _articles/ru/metrics.md | 46 +++++++++++++++++++++--------------------
 1 file changed, 24 insertions(+), 22 deletions(-)

diff --git a/_articles/ru/metrics.md b/_articles/ru/metrics.md
index 00e632615ec..63f5b9d5743 100644
--- a/_articles/ru/metrics.md
+++ b/_articles/ru/metrics.md
@@ -1,6 +1,6 @@
 ---
 lang: ru
-title: Метрики для Open Source
+title: Метрики проектов с открытым исходным кодом
 description: Принимайте обоснованные решения, чтобы помочь вашему проекту с открытым исходным кодом процветать, измеряя и отслеживая его успех.
 class: metrics
 order: 9
@@ -27,9 +27,9 @@ related:
 
 > Homebrew предоставляется бесплатно и управляется исключительно добровольцами в свободное время. В результате у нас нет ресурсов для проведения детальных исследований пользователей Homebrew, чтобы решить, как лучше разработать будущие функции и определить приоритеты текущей работы. Анонимная совокупная аналитика пользователей позволяет нам определять приоритетность фиксов и фич на основе того, как, где и когда люди используют Homebrew.
 
-Популярность - это еще не все. Все приходят в open source по разным причинам. Если ваша цель как сопровождающего open source - показать свою работу, свой код или просто развлечься, то метрики могут быть для вас не важны.
+Популярность — это еще не всё. Все приходят в окрытые проекты по разным причинам. Если ваша цель как сопровождающего открытый исходный код — продемонтсрировать свою работу, быть прозрачным в работе с кодом или просто развлечься, то метрики могут быть для вас не важны.
 
-Если вы _заинтересованы_ в более глубоком понимании своего проекта, читайте далее о способах анализа активности вашего проекта.
+Если вы _заинтересованы_ в более глубоком понимании своего проекта, читайте дальше, чтобы узнать, как проанализировать деятельность вашего проекта.
 
 ## Обнаруживаемость
 
@@ -37,15 +37,15 @@ related:
 
 ![График трафика](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Если ваш проект размещен на GitHub, [вы можете посмотреть](https://help.github.com/articles/about-repository-graphs/#traffic), сколько людей заходит на ваш проект и откуда они приходят. На странице вашего проекта нажмите **Insights**, затем **Traffic**. На этой странице вы можете увидеть:
+Если ваш проект размещён на GitHub, [вы можете посмотреть](https://help.github.com/articles/about-repository-graphs/#traffic), сколько людей попадают в ваш проект и откуда они приходят. На странице вашего проекта нажмите **Insights**, затем **Traffic**. На этой странице вы можете увидеть:
 
 * **Общее количество просмотров страниц:** показывает, сколько раз был просмотрен ваш проект.
 
 * **Общее количество уникальных посетителей:** показывает, сколько человек просмотрело ваш проект.
 
-* **Сайты-источники:** Рассказывает о том, откуда пришли посетители. Эта метрика может помочь вам определить, где можно привлечь аудиторию и работают ли ваши усилия по продвижению.
+* **Сайты-источники:** рассказывает о том, откуда пришли посетители. Эта метрика может помочь вам определить, где можно привлечь аудиторию и работают ли ваши усилия по продвижению.
 
-* **Популярный контент:** Рассказывает о том, куда заходят посетители на вашем проекте, в разбивке по просмотрам страниц и уникальным посетителям.
+* **Популярный контент:** рассказывает о том, куда заходят посетители вашего проекта, в разбивке по просмотрам страниц и уникальным посетителям.
 
 [GitHub stars](https://help.github.com/articles/about-stars/) также может помочь определить базовый показатель популярности. Хотя звезды GitHub не обязательно коррелируют с загрузками и использованием, они могут сказать вам, сколько людей обращают внимание на вашу работу.
 
@@ -57,18 +57,18 @@ related:
 
 Если вы используете менеджер пакетов, такой как npm или RubyGems.org, для распространения вашего проекта, вы можете отслеживать скачивания пакета.
 
-Каждый пакетный менеджер может использовать несколько иное определение "скачивания", и скачивания не обязательно коррелируют с установками или использованием, но это дает некоторую базу для сравнения. Попробуйте использовать [Libraries.io](https://libraries.io/) для отслеживания статистики использования многих популярных менеджеров пакетов.
+Каждый пакетный менеджер может использовать несколько иное определение "скачивания", и скачивания не обязательно коррелируют с установками или использованием, но это даёт некоторую базу для сравнения. Попробуйте использовать [Libraries.io](https://libraries.io/) для отслеживания статистики использования многих популярных менеджеров пакетов.
 
-Если ваш проект находится на GitHub, снова перейдите на страницу **Traffic**. Вы можете использовать [График git clone](https://github.com/blog/1873-clone-graphs), чтобы увидеть, сколько раз ваш проект был клонирован в определенный день, с разбивкой по общему количеству клонирований и уникальным клонирователям.
+Если ваш проект находится на GitHub, снова перейдите на страницу **Traffic**. Вы можете использовать [clone graph](https://github.com/blog/1873-clone-graphs), чтобы увидеть, сколько раз ваш проект был клонирован в определенный день, с разбивкой по общему количеству клонирований и уникальным клонирователям.
 
 ![График git clone](/assets/images/metrics/clone_graph.png)
 
 Если использование низкое по сравнению с количеством людей, которые находят ваш проект, есть два аспекта, которые следует рассмотреть. Либо:
 
-* Ваш проект плохо конвертирует вашу аудиторию, или
+* Ваш проект плохо конвертирует вашу аудиторию, либо
 * Вы привлекаете не ту аудиторию
 
-Например, если ваш проект попадет на первую страницу Hacker News, вы, вероятно, увидите всплеск посещений (трафика), но более низкий коэффициент конверсии, поскольку вы охватите всех пользователей Hacker News. Однако если ваш Ruby-проект будет представлен на Ruby-конференции, вы, скорее всего, получите высокий коэффициент конверсии от целевой аудитории.
+Например, если ваш проект попадет на первую страницу Hacker News, вы, вероятно, увидите всплеск посещений (трафика), но более низкий коэффициент конверсии, поскольку вы охватите всех пользователей Hacker News. Однако если ваш Ruby-проект будет представлен на конференции Ruby, вы, скорее всего, получите высокий коэффициент конверсии от целевой аудитории.
 
 Попытайтесь понять, откуда приходит ваша аудитория, и попросите других людей оставить отзыв на странице вашего проекта, чтобы выяснить, с какой из этих двух проблем вы столкнулись.
 
@@ -76,37 +76,37 @@ related:
 
 ## Удержание
 
-Люди находят ваш проект и используют его. Следующий вопрос, который вы захотите задать себе: _участвуют (to contribute) ли люди в этом проекте?_
+Люди находят ваш проект и используют его. Следующий вопрос, который вы захотите задать себе: _участвуют (contribute) ли люди в этом проекте?_
 
-Никогда не рано начинать думать об участниках. Без участия других людей вы рискуете оказаться в нездоровой ситуации, когда ваш проект _популярен_ (многие используют его), но не _поддерживается_ (не хватает времени сопровождающих (maintainers) для удовлетворения спроса).
+Никогда не рано начинать думать об участниках (contributors). Без участия других людей вы рискуете оказаться в нездоровой ситуации, когда ваш проект _популярен_ (многие используют его), но не _поддерживается_ (не хватает времени сопровождающих (maintainers) для удовлетворения спроса).
 
 Для удержания также необходим [приток новых участников](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), так как ранее активные участники со временем переходят на другие виды деятельности.
 
 Вот ещё показатели для отслеживания:
 
-* **Общее количество участников (contributor) и количество правок (commit) на одного участника:** Позволяет узнать, сколько у вас участников и кто из них более или менее активен. На GitHub это можно посмотреть в разделе **Insights** -> **Contributors**. В настоящее время этот график учитывает только тех участников, которые сделали правку (commit) в ветку репозитория по умолчанию.
+* **Общее количество участников и количество правок (commit) на одного участника:** позволяет узнать, сколько у вас участников и кто из них более или менее активен. На GitHub это можно посмотреть в разделе **Insights** -> **Contributors**. В настоящее время этот график учитывает только тех участников, которые сделали правку (commit) в ветку репозитория по умолчанию.
 
-![График вкладчиков](/assets/images/metrics/repo_contributors_specific_graph.png)
+![График участников](/assets/images/metrics/repo_contributors_specific_graph.png)
 
-* **Первоначальные, случайные и повторные участники:** Помогает вам отслеживать, привлекаете ли вы новых участников и возвращаются ли они. (Случайные участники - те, у кого мало правок (commit). Будет ли это одна правка, менее пяти или что-то другое - решать вам). Без новых участников сообщество вашего проекта может стать застойным.
+* **Первоначальные, случайные и повторные участники:** помогает вам отслеживать, привлекаете ли вы новых участников и возвращаются ли они. (Случайные участники - те, у кого мало правок (commit). Будет ли это одна правка, менее пяти или что-то другое - решать вам). Без новых участников сообщество вашего проекта может стать застойным.
 
-* **Количество текущих открытых проблем (issue) и запросов на перенос (pull request)** Если эти показатели слишком высоки, вам может понадобиться помощь в устранении проблем и проверке кода.
+* **Количество текущих открытых проблем (issue) и запросов на перенос (pull request):** если эти показатели слишком высоки, вам может понадобиться помощь в устранении проблем и проверке кода.
 
-* **Общее количество проблем (issues) и запросов на перенос (pull request) (включая закрытые)** Открытые когда-то проблемы (issues) означают, что ваш проект кому-то достаточно интересен, чтобы открыть проблему (issue). Если это число увеличивается со временем, это говорит о том, что люди заинтересованы в вашем проекте.
+* **Общее количество проблем (issues) и запросов на перенос (pull request) (включая закрытые):** открытые когда-то проблемы (issues) означают, что ваш проект кому-то достаточно интересен, чтобы он открыл проблему (issue). Если это число увеличивается со временем, это говорит о том, что люди заинтересованы в вашем проекте.
 
-* **Типы вклада (contribution):** Например, правки (commit), исправление опечаток или ошибок, или комментирование проблемы (issue).
+* **Типы вклада (contribution):** например, правки (commit), исправление опечаток или ошибок, или комментирование проблемы (issue).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
-  Открытый исходный код - это больше, чем просто код. Успешные проекты с открытым исходным кодом включают написание кода и документации вместе с обсуждением этих изменений.
+  Открытый исходный код — это больше, чем просто код. Успешные проекты с открытым исходным кодом включают написание кода и документации вместе с обсуждением этих изменений.
   <p markdown="1" class="pquote-credit">— @arfon, ["Как выглядит Open Source"](https://github.com/blog/2195-the-shape-of-open-source)</p>
 </aside>
 
 ## Активность сопровождающих
 
-Наконец, вы захотите замкнуть цикл, убедившись, что участники (contributors) вашего проекта в состоянии справиться с объемом получаемых вкладов (contributions). Последний вопрос, который вы хотите задать себе, это: _отвечаю ли я (или мы) на запросы нашего сообщества?_
+Наконец, вы захотите замкнуть цикл, убедившись, что участники вашего проекта в состоянии справиться с объёмом получаемых вкладов (contributions). Последний вопрос, который вы хотите задать себе, это: _отвечаю ли я (или мы) на запросы нашего сообщества?_
 
-Неотзывчивые сопровождающие (maintainer) становятся узким местом для open source проектов. Если кто-то вносит свой вклад, но так и не получает ответа от сопрождающего, он может почувствовать себя демотивированным и уйти.
+Неотзывчивые сопровождающие становятся узким местом для проектов с открытм кодом. Если кто-то вносит свой вклад, но так и не получает ответа от сопровождающего, он может разочароваться и уйти.
 
 [Исследование компании Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) предполагает, что отзывчивость сопровождающих является критическим фактором поощрения повторного участия.
 
@@ -114,7 +114,7 @@ related:
 
 Можно также измерять время, необходимое для перехода от одного этапа процесса внесения вклада к другому, например:
 
-* Среднее время, в течение которого проблема (issue) остается открытой
+* Среднее время, в течение которого проблема (issue) остаётся открытой
 * Закрываются ли проблемы (issue) в запросе на перенос (pull request)
 * Закрываются ли неактуальные проблемы (issue)
 * Среднее время для слияния запроса на перенос (pull request)
@@ -122,3 +122,5 @@ related:
 ## Используйте 📊, чтобы узнать о людях
 
 Понимание метрик поможет вам построить активный, растущий проект с открытым исходным кодом. Даже если вы не отслеживаете каждую метрику на панели инструментов, используйте описанный выше алгоритм действий, чтобы сосредоточить свое внимание на том типе поведения, который поможет вашему проекту процветать.
+
+[CHAOSS](https://chaoss.community/) — это гостеприимное сообщество с открытым исходным кодом, ориентированное на аналитику, показатели и программное обеспечение для здоровья сообщества.

From c742636008ebf655f929bc0508e14f92f91be394 Mon Sep 17 00:00:00 2001
From: Maximilian Techritz <vemaximilian.t@gmail.com>
Date: Thu, 18 Aug 2022 22:05:01 +0200
Subject: [PATCH 370/749] Fix gender-sensitive phrases

---
 _articles/de/building-community.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/_articles/de/building-community.md b/_articles/de/building-community.md
index 71365413249..434aab8c084 100644
--- a/_articles/de/building-community.md
+++ b/_articles/de/building-community.md
@@ -18,17 +18,17 @@ Eine einladende, offenherzige Gemeinschaft ist eine Investition in die Zukunft u
 
 ### Geben Sie Leuten das Gefühl, willkommen zu sein
 
-Die Community Ihres Projekts kann nach @MikeMcQuaid als "Kontributorentrichter" ([contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel)) aufgefasst werden:
+Die Community Ihres Projekts kann nach @MikeMcQuaid als "Kontributor*innentrichter" ([contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel)) aufgefasst werden:
 
 ![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
 
-Während Sie Ihre Community aufbauen, überlegen Sie sich, wie jemand am Eingang des Trichters (potenzielle\*r Benutzer\*in) theoretisch den Weg nach unten finden könnte (aktiver\* Mitstreiter\*in). Ihr Ziel ist es, jede Phase des Mithelfens möglichst reibungslos zu gestalten. Denn wenn die Leute "leichte Beute" machen können, ermutigt sie dies zu weiteren Beiträgen.
+Während Sie Ihre Community aufbauen, überlegen Sie sich, wie jemand am Eingang des Trichters (potenzielle\*r Benutzer\*in) theoretisch den Weg nach unten finden könnte (aktive\*r Mitstreiter\*in). Ihr Ziel ist es, jede Phase des Mithelfens möglichst reibungslos zu gestalten. Denn wenn die Leute "leichte Beute" machen können, ermutigt sie dies zu weiteren Beiträgen.
 
 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://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.
 
 [GitHubs 2017er Open-Source-Umfrage](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.
 
@@ -105,7 +105,7 @@ Der zweite Grund nützt Ihnen selbst: Wenn Sie den Leuten _keinen_ öffentlichen
 
 Öffentliche Kommunikation kann ganz einfach sein: Bitten Sie Leute, ein Issue zu öffnen, anstatt Ihnen direkt eine E-Mail zu schreiben oder in Ihr Blog zu kommentieren. Sie können für Leute, die über Ihr Projekt sprechen möchten, auch eine Mailingliste einrichten oder einen Twitter-Account, einen Slack- oder IRC-Kanal. Oder all dies gleichzeitig ausprobieren!
 
-[Kubernetes' Kops](https://github.com/kubernetes/kops#getting-involved) legt alle zwei Wochen Bürozeiten fest, um den Mitgliedern der Gemeinschaft zu helfen:
+[Kubernetes' Kops](https://github.com/kubernetes/kops#getting-involved) legt alle zwei Wochen Bürozeiten fest, um den Mitglieder*innen der Gemeinschaft zu helfen:
 
 > Die Kops-Betreuer\*innen haben sich bereit erklärt, Zeit einzuplanen für die Arbeit mit Neuankömmlingen, die Unterstützung von Pull Requests, sowie für die Diskussion über neue Funktionen.
 >
@@ -293,9 +293,9 @@ Wenn eine Diskussion offensichtlich nirgendwo hinführt, es keine klaren Maßnah
 
 ### Wählen Sie Auseinandersetzungen mit Bedacht
 
-Der Kontext ist wichtig: Überlegen Sie, wer an der Diskussion beteiligt ist und wie die Diskutanten den Rest der Gemeinschaft repräsentieren.
+Der Kontext ist wichtig: Überlegen Sie, wer an der Diskussion beteiligt ist und wie die Diskutant\*innen den Rest der Gemeinschaft repräsentieren.
 
-Ist jeder in der Community verärgert oder gar mit diesem Thema beschäftigt? Oder ist er ein\*e einzelner Unruhestifter\*in? Berücksichtigen Sie nicht nur die Aktiven, sondern vergessen Sie Ihre stillen Community-Mitglieder nicht.
+Ist jede\*r in der Community verärgert oder gar mit diesem Thema beschäftigt? Ist er oder sie ein\*e einzelne\*r Unruhestifter\*in? Berücksichtigen Sie nicht nur die Aktiven, sondern vergessen Sie Ihre stillen Community-Mitglieder\*innen nicht.
 
 Wenn das Thema nicht die breiteren Bedürfnisse Ihrer Gemeinschaft widerspiegelt, müssen Sie vielleicht nur die Sorgen einiger Weniger anerkennen. Wenn es sich um ein wiederkehrendes Problem ohne klare Lösung handelt, weisen Sie sie auf frühere Diskussionen hin und schließen Sie das Issue.
 

From 88d2fcf9cd4a7dff97423291c2a834f38c85112e Mon Sep 17 00:00:00 2001
From: Ernest Rudnicki <e.rudnicki96@gmail.com>
Date: Sat, 20 Aug 2022 12:29:58 +0200
Subject: [PATCH 371/749] update finding-users polish article

---
 _articles/pl/finding-users.md | 68 +++++++++++++++++------------------
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/_articles/pl/finding-users.md b/_articles/pl/finding-users.md
index 35ec46f700d..c9649fedf01 100644
--- a/_articles/pl/finding-users.md
+++ b/_articles/pl/finding-users.md
@@ -1,7 +1,7 @@
 ---
 lang: pl
-title: Znajdowanie użytkowników dla twojego projektu
-description: Pomóż rozwijać projekt open source, przekazując go w ręce szczęśliwych użytkowników.
+title: Jak znaleźć użytkowników dla twojego projektu
+description: Rozwijaj projekt open source, przekazując go w ręce odpowiednich użytkowników.
 class: finding
 order: 3
 image: /assets/images/cards/finding.png
@@ -10,25 +10,25 @@ related:
   - building
 ---
 
-## Szerzyć wieści
+## Rozpowszechnianie informacji
 
-Nie ma reguły, która mówi, że musisz promować projekt open source podczas uruchamiania. Istnieje wiele satysfakcjonujących powodów do pracy w open source, które nie mają nic wspólnego z popularnością. Zamiast mieć nadzieję, że inni znajdą i wykorzystają Twój projekt open source, musisz rozpowszechnić informacje o swojej ciężkiej pracy!
+Nie ma reguły, która mówi, że musisz promować swój projekt open source podczas jego wypuszczania. Istnieje wiele satysfakcjonujących powodów do pracy w open source, które nie mają nic wspólnego z popularnością. Zamiast liczyć na to, że inni znajdą i wykorzystają twój projekt open source, lepiej jest rozpowszechnić informacje o swojej ciężkiej pracy!
 
-## Sprawdź swoją wiadomość
+## Zastanów się nad komunikatem
 
-Przed rozpoczęciem faktycznej pracy nad promocją projektu powinieneś być w stanie wyjaśnić, co robi i dlaczego ma to znaczenie.
+Przed rozpoczęciem faktycznej pracy nad promocją projektu powinieneś być w stanie wyjaśnić, co robi i dlaczego ma on znaczenie.
 
-Co sprawia, że Twój projekt jest inny lub interesujący? Dlaczego to stworzyłeś? Odpowiedzi na te pytania pomogą ci przekazać znaczenie twojego projektu.
+Co sprawia, że twój projekt jest inny lub interesujący? Dlaczego go stworzyłeś? Odpowiedzi na te pytania pomogą ci przekazać informację dlaczego twój projekt może być przydatny dla innych.
 
-Pamiętaj, że ludzie angażują się jako użytkownicy i ostatecznie stają się współpracownikami, ponieważ Twój projekt rozwiązuje dla nich problem. Gdy myślisz o przesłaniu i wartości projektu, spróbuj spojrzeć na nie z perspektywy potencjalnych użytkowników i współpracowników.
+Pamiętaj, że ludzie angażują się jako użytkownicy i ostatecznie stają się współpracownikami, ponieważ twój projekt rozwiązuje dla nich dany problem. Gdy myślisz o przesłaniu i wartości projektu, spróbuj spojrzeć na niego z perspektywy potencjalnych użytkowników i współpracowników.
 
 Na przykład @robb używa przykładów kodu, aby jasno przekazać, dlaczego jego projekt [Cartography](https://github.com/robb/Cartography) jest przydatny:
 
 ![Cartography README](/assets/images/finding-users/cartography.jpg)
 
-Aby głębiej zagłębić się w wiadomości, sprawdź Mozilli ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/), ćwiczenie rozwijające osobowości użytkowników.
+Aby zagłębić się w tworzenie odpowiednich komunikatów, sprawdź artykuł Mozilli ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/), o personach użytkowników.
 
-## Pomóż ludziom znaleźć i śledzić Twój projekt
+## Pomóż ludziom znaleźć i śledzić twój projekt
 
 <aside markdown="1" class="pquote">
   You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
@@ -37,11 +37,11 @@ Aby głębiej zagłębić się w wiadomości, sprawdź Mozilli ["Personas and Pa
   </p>
 </aside>
 
-Pomóż innym znaleźć i zapamiętać Twój projekt, wskazując je w jednej przestrzeni nazw.
+Pomóż innym znaleźć i zapamiętać twój projekt, poprzez utworzenie odpowiedniej nazwy firmowej która będzie reprezentować cały projekt.
 
-**Miej wyraźny uchwyt, aby promować swoją pracę.** Twitter handle, adres URL GitHub lub kanał IRC to łatwy sposób wskazywania ludziom Twojego projektu. Te sklepy zapewniają także rosnącej społeczności projektu możliwość zwołania spotkania.
+**Znajdz odpowiednie miejsce do promowania swojej pracy.** Twitter, GitHub URL lub kanał IRC to łatwy sposób promowania twojego projektu. Te miejsca pozwolą także na zbieranie się rosnącej społeczności twojego projektu.
 
-Jeśli nie chcesz jeszcze zakładać punktów sprzedaży dla swojego projektu, promuj swój własny uchwyt Twittera lub GitHub we wszystkim, co robisz. Promowanie swojego uchwytu na Twitterze lub GitHub pozwoli ludziom wiedzieć, jak się z tobą skontaktować lub śledzić twoją pracę. Jeśli przemawiasz na spotkaniu lub wydarzeniu, upewnij się, że Twoje dane kontaktowe znajdują się w biografii lub slajdach.
+Jeśli nie chcesz jeszcze zakładać takich punktów dla swojego projektu, promuj go na swoim własnym koncie Twitter lub GitHub. Promowanie swojego projektu na Twitterze lub GitHub pozwoli ludziom wiedzieć, jak się z tobą skontaktować lub śledzić twoją pracę. Jeśli przemawiasz na spotkaniu lub wydarzeniu, upewnij się, że twoje dane kontaktowe znajdują się w prezentacji.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
@@ -53,21 +53,21 @@ Jeśli nie chcesz jeszcze zakładać punktów sprzedaży dla swojego projektu, p
   </p>
 </aside>
 
-**Rozważ utworzenie strony internetowej dla swojego projektu.** Strona internetowa sprawia, że projekt jest łatwiejszy w obsłudze i łatwiejszy w nawigacji, szczególnie gdy jest połączony z przejrzystą dokumentacją i samouczkami. Posiadanie strony internetowej sugeruje również, że Twój projekt jest aktywny, co sprawi, że Twoi odbiorcy poczują się bardziej komfortowo z niego korzystający. Podaj przykłady, aby dać ludziom pomysły, jak korzystać z twojego projektu.
+**Rozważ utworzenie strony internetowej dla swojego projektu.** Strona internetowa sprawia, że projekt jest łatwiejszy w obsłudze i łatwiejszy w nawigacji, szczególnie gdy jest połączony z przejrzystą dokumentacją i samouczkami. Posiadanie strony internetowej sugeruje również, że twój projekt jest aktywny, co sprawi, że twoi odbiorcy poczują się bardziej komfortowo z niego korzystając. Podawaj przykłady użycia, aby ludzie wiedzieli, jak korzystać z twojego projektu.
 
-[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), współtwórca Django powiedział, że strona internetowa była _"zdecydowanie najlepszą rzeczą, jaką zrobiliśmy z Django we wczesnych dniach"_.
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), współtwórca Django powiedział, że strona internetowa była _"zdecydowanie najlepszą rzeczą, jaką zrobiliśmy dla Django we wczesnych dniach projektu"_.
 
 Jeśli Twój projekt jest hostowany na GitHub, możesz użyć [GitHub Pages](https://pages.github.com/) aby łatwo stworzyć stronę internetową. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), oraz [Middleman](https://middlemanapp.com/) to [kilka przykładów](https://github.com/showcases/github-pages-examples) doskonałych, kompleksowych stron internetowych.
 
 ![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
 
-Teraz, gdy masz wiadomość dla swojego projektu i łatwy sposób, aby ludzie mogli znaleźć Twój projekt, chodźmy i porozmawiaj z publicznością!
+Teraz, gdy już masz odpowiedni komunikat dla swojego projektu oraz miejsce w którym możesz go promować, chodźmy porozmawiać z publicznością!
 
-## Idź tam, gdzie są odbiorcy Twojego projektu (online)
+## Idź tam, gdzie znajdziesz odbiorców twojego projektu (online)
 
-Internetowy zasięg to świetny sposób na szybkie udostępnianie i rozpowszechnianie wiadomości. Korzystając z kanałów online, możesz dotrzeć do bardzo szerokiego grona odbiorców.
+Internetowy zasięg to świetny sposób na szybkie udostępnianie i rozpowszechnianie treści. Korzystając z kanałów online, możesz dotrzeć do bardzo szerokiego grona odbiorców.
 
-Skorzystaj z istniejących społeczności i platform internetowych, aby dotrzeć do odbiorców. Jeśli twój projekt open source jest projektem oprogramowania, prawdopodobnie znajdziesz odbiorców [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), lub [Quora](https://www.quora.com/). Znajdź kanały, w których Twoim zdaniem ludzie najbardziej skorzystają lub będą podekscytowani Twoją pracą.
+Skorzystaj z istniejących społeczności i platform internetowych, aby dotrzeć do odbiorców. Jeśli twój projekt open source jest projektem oprogramowania, prawdopodobnie znajdziesz odbiorców [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), lub [Quora](https://www.quora.com/). Znajdź kanały, w których twoim zdaniem ludzie najbardziej skorzystają lub będą podekscytowani twoją pracą.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
@@ -79,23 +79,23 @@ Skorzystaj z istniejących społeczności i platform internetowych, aby dotrzeć
   </p>
 </aside>
 
-Sprawdź, czy możesz znaleźć sposoby na udostępnienie swojego projektu w odpowiedni sposób:
+Określ odpowiednie sposoby na udostępnienie swojego projektu:
 
-* **Poznaj odpowiednie projekty i społeczności o otwartym kodzie źródłowym.** Czasami nie musisz bezpośrednio promować swojego projektu. Jeśli Twój projekt jest idealny dla naukowców zajmujących się danymi, którzy używają Pythona, poznaj społeczność nauki danych w Pythonie. Gdy ludzie Cię poznają, pojawią się naturalne okazje do rozmowy i dzielenia się twoją pracą.
-* **Znajdź osoby, które mają problem z rozwiązaniem twojego projektu.** Przeszukuj powiązane fora osób, które należą do grupy docelowej Twojego projektu. Odpowiedz na ich pytanie i znajdź taktowny sposób, w stosownych przypadkach, aby zaproponować swój projekt jako rozwiązanie.
-* **Poproś o opinię.** Przedstaw siebie i swoją pracę publiczności, która uznałaby ją za przydatną i interesującą. Sprecyzuj, kto według Ciebie skorzystałby na twoim projekcie. Spróbuj dokończyć zdanie: _"Myślę, że mój projekt naprawdę pomógłby X, który próbuje zrobić Y"_. Słuchaj opinii innych i odpowiadaj na nie, zamiast po prostu promować swoją pracę.
+* **Poznaj odpowiednie projekty i społeczności opensource.** Czasami nie musisz bezpośrednio promować swojego projektu. Jeśli twój projekt jest idealny dla programistów zajmujących się danymi, którzy używają Pythona, poznaj społeczności data science w Pythonie. Gdy ludzie cię poznają, pojawią się naturalne okazje do rozmowy i dzielenia się twoją pracą.
+* **Znajdź osoby, które mają jakiś problem którego rozwiązaniem może być twój projekt** Przeszukuj powiązane fora osób, które należą do grupy docelowej twojego projektu. Odpowiedz na ich pytania i znajdź taktowny sposób, w stosownych przypadkach, aby zaproponować swój projekt jako rozwiązanie.
+* **Poproś o opinię.** Przedstaw siebie i swoją pracę publiczności, która uznałaby ją za przydatną i interesującą. Sprecyzuj, kto według ciebie skorzystałby na twoim projekcie. Spróbuj dokończyć zdanie: _"Myślę, że mój projekt naprawdę pomógłby X, który próbuje zrobić Y"_. Słuchaj opinii innych i odpowiadaj na nie, zamiast po prostu promować swoją pracę.
 
-Ogólnie rzecz biorąc, skup się na pomaganiu innym, zanim poprosisz o coś w zamian. Ponieważ każdy może z łatwością promować projekt online, będzie dużo hałasu. Aby wyróżnić się z tłumu, daj ludziom kontekst, kim jesteś, a nie tylko to, czego chcesz.
+Ogólnie rzecz biorąc, skup się na pomaganiu innym, zanim poprosisz o coś w zamian. Ponieważ każdy może z łatwością promować projekt online, ale by wyróżnić się z tłumu, daj ludziom kontekst, kim jesteś, a nie tylko to, czego chcesz.
 
-Jeśli nikt nie zwraca uwagi lub nie reaguje na twoje pierwsze działanie, nie zniechęcaj się! Większość uruchomień projektów jest procesem iteracyjnym, który może potrwać miesiące lub lata. Jeśli nie otrzymasz odpowiedzi za pierwszym razem, wypróbuj inną taktykę lub poszukaj sposobów, aby w pierwszej kolejności zwiększyć wartość pracy innych. Promowanie i uruchomienie projektu wymaga czasu i poświęcenia.
+Jeśli nikt nie zwraca uwagi lub nie reaguje na twoje pierwsze działania, nie zniechęcaj się! Większość wprowadzeń projektów jest procesem iteracyjnym, który może potrwać miesiące lub lata. Jeśli nie otrzymasz odpowiedzi za pierwszym razem, wypróbuj inną taktykę lub poszukaj sposobów, aby w pierwszej kolejności zwiększyć wartość pracy innych. Promowanie i uruchomienie projektu wymaga czasu i poświęcenia.
 
-## Idź tam, gdzie są odbiorcy Twojego projektu (offline)
+## Idź tam, gdzie są odbiorcy dla twojego projektu (offline)
 
 ![Public speaking](/assets/images/finding-users/public_speaking.jpg)
 
 Wydarzenia offline są popularnym sposobem promowania nowych projektów wśród odbiorców. To świetny sposób na dotarcie do zaangażowanej publiczności i budowanie głębszych kontaktów międzyludzkich, szczególnie jeśli chcesz dotrzeć do programistów.
 
-Jeśli jesteś [nowy w wystąpieniach publicznych](https://speaking.io/), zacznij od znalezienia lokalnego spotkania związanego z językiem lub ekosystemem twojego projektu.
+Jeśli jesteś [nowy w wystąpieniach publicznych](https://speaking.io/), zacznij od znalezienia lokalnego spotkania związanego z językiem lub ekosystemem powiązanym z twoim projektem.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
@@ -109,7 +109,7 @@ Jeśli jesteś [nowy w wystąpieniach publicznych](https://speaking.io/), zaczni
 
 Jeśli nigdy wcześniej nie rozmawiałeś na żadnym wydarzeniu, to zupełnie normalne, że się denerwujesz! Pamiętaj, że twoi odbiorcy są tam, ponieważ naprawdę chcą usłyszeć o twojej pracy.
 
-Pisząc swoje przemówienie, skup się na tym, co zainteresuje twoją publiczność i czerp z niej wartość. Zachowaj swój język przyjazny i przystępny. Uśmiechnij się, oddychaj i baw się dobrze.
+Pisząc swoje przemówienie, skup się na tym, co zainteresuje twoją publiczność i czerp z niej wartość. Twój język powinien być przyjazny i przystępny. Uśmiechnij się, oddychaj i baw się dobrze.
 
 <aside markdown="1" class="pquote">
   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
@@ -121,9 +121,9 @@ Pisząc swoje przemówienie, skup się na tym, co zainteresuje twoją publiczno
   </p>
 </aside>
 
-Kiedy będziesz gotowy, przemów na konferencji, aby promować swój projekt. Konferencje mogą pomóc Ci dotrzeć do większej liczby osób, czasem z całego świata.
+Kiedy będziesz gotowy, przemów na konferencji, aby przedstawić swój projekt. Konferencje mogą pomóc ci dotrzeć do większej liczby odbiorców, czasem z całego świata.
 
-Szukaj konferencji specyficznych dla Twojego języka lub ekosystemu. Przed przesłaniem swojego przemówienia zapoznaj się z konferencją, aby dostosować ją do uczestników i zwiększyć swoje szanse na przyjęcie na mowę. Często możesz poznać odbiorców, patrząc na prelegentów konferencji.
+Szukaj konferencji specyficznych dla twojego języka lub ekosystemu. Przed przesłaniem swojego przemówienia zapoznaj się z konferencją, aby dostosować ją do uczestników i zwiększyć swoje szanse na przyjęcie na przemówienie. Często możesz poznać odbiorców, patrząc na prelegentów konferencji.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
@@ -137,9 +137,9 @@ Szukaj konferencji specyficznych dla Twojego języka lub ekosystemu. Przed przes
 
 ## Zbuduj reputację
 
-Oprócz strategii przedstawionych powyżej, najlepszym sposobem zapraszania ludzi do dzielenia się i udziału w projekcie jest dzielenie się i udział w swoich projektach.
+Oprócz strategii przedstawionych powyżej, najlepszym sposobem zapraszania ludzi do udziału w twoim projekcie jest branie udziału w ich projektach.
 
-Pomaganie nowicjuszom, dzielenie się zasobami i merytoryczny wkład w projekty innych osób pomoże Ci zbudować pozytywną reputację. Bycie aktywnym członkiem społeczności open source pomoże ludziom mieć kontekst dla twojej pracy i będzie bardziej prawdopodobne, że zwrócą uwagę i podzielą się twoim projektem. Rozwijanie relacji z innymi projektami typu open source może nawet prowadzić do oficjalnych partnerstw.
+Pomaganie nowicjuszom, dzielenie się zasobami i merytoryczny wkład w projekty innych osób pomoże ci zbudować pozytywną reputację. Bycie aktywnym członkiem społeczności open source pomoże ludziom mieć kontekst dla twojej pracy i będzie bardziej prawdopodobne, że zwrócą uwagę i podzielą się twoim projektem. Rozwijanie relacji z innymi projektami typu open source może nawet prowadzić do oficjalnych partnerstw.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
@@ -165,6 +165,6 @@ Nie ma jednodniowego rozwiązania dla budowania widowni. Zdobycie zaufania i sza
   </p>
 </aside>
 
-## Tak trzymać!
+## Tak trzymaj!
 
-Może minąć dużo czasu, zanim ludzie zauważą Twój projekt open source. W porządku! Niektóre z najbardziej popularnych projektów zajęły dziś lata, aby osiągnąć wysoki poziom aktywności. Skoncentruj się na budowaniu relacji, zamiast mieć nadzieję, że Twój projekt spontanicznie zyska popularność. Bądź cierpliwy i dziel się swoją pracą z tymi, którzy ją doceniają.
+Może minąć dużo czasu, zanim ludzie zauważą twój projekt open source. W porządku! Niektóre z najbardziej popularnych projektów zajęły lata, aby osiągnąć wysoki poziom aktywności. Skoncentruj się na budowaniu relacji, zamiast mieć nadzieję, że twój projekt spontanicznie zyska popularność. Bądź cierpliwy i dziel się swoją pracą z tymi, którzy ją doceniają.

From 287590e4d97c527676016624412390d259cd6fdb Mon Sep 17 00:00:00 2001
From: Ernest Rudnicki <e.rudnicki96@gmail.com>
Date: Sat, 20 Aug 2022 12:33:10 +0200
Subject: [PATCH 372/749] typo fix

---
 _articles/pl/finding-users.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/finding-users.md b/_articles/pl/finding-users.md
index c9649fedf01..c45561cf24e 100644
--- a/_articles/pl/finding-users.md
+++ b/_articles/pl/finding-users.md
@@ -39,7 +39,7 @@ Aby zagłębić się w tworzenie odpowiednich komunikatów, sprawdź artykuł Mo
 
 Pomóż innym znaleźć i zapamiętać twój projekt, poprzez utworzenie odpowiedniej nazwy firmowej która będzie reprezentować cały projekt.
 
-**Znajdz odpowiednie miejsce do promowania swojej pracy.** Twitter, GitHub URL lub kanał IRC to łatwy sposób promowania twojego projektu. Te miejsca pozwolą także na zbieranie się rosnącej społeczności twojego projektu.
+**Znajdź odpowiednie miejsce do promowania swojej pracy.** Twitter, GitHub URL lub kanał IRC to łatwy sposób promowania twojego projektu. Te miejsca pozwolą także na zbieranie się rosnącej społeczności twojego projektu.
 
 Jeśli nie chcesz jeszcze zakładać takich punktów dla swojego projektu, promuj go na swoim własnym koncie Twitter lub GitHub. Promowanie swojego projektu na Twitterze lub GitHub pozwoli ludziom wiedzieć, jak się z tobą skontaktować lub śledzić twoją pracę. Jeśli przemawiasz na spotkaniu lub wydarzeniu, upewnij się, że twoje dane kontaktowe znajdują się w prezentacji.
 

From 0e72c7cc0886b037b242f2198aa01a8fdc89c92c Mon Sep 17 00:00:00 2001
From: Ernest Rudnicki <e.rudnicki96@gmail.com>
Date: Sun, 18 Sep 2022 20:29:38 +0200
Subject: [PATCH 373/749] update code of conduct polish version

---
 _articles/pl/code-of-conduct.md | 52 ++++++++++++++++-----------------
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/_articles/pl/code-of-conduct.md b/_articles/pl/code-of-conduct.md
index 6a8c980e889..781994c4a09 100644
--- a/_articles/pl/code-of-conduct.md
+++ b/_articles/pl/code-of-conduct.md
@@ -1,7 +1,7 @@
 ---
 lang: pl
 title: Twój kodeks postępowania
-description: Ułatwienie zdrowego i konstruktywnego zachowania społeczności poprzez przyjęcie i egzekwowanie kodeksu postępowania.
+description: Promowanie przyjaznych i konstruktywnych zachowań poprzez przyjęcie i egzekwowanie kodeksu postępowania.
 class: coc
 order: 8
 image: /assets/images/cards/coc.png
@@ -12,30 +12,30 @@ related:
 
 ## Dlaczego potrzebuję kodeksu postępowania?
 
-Kodeks postępowania to dokument, który określa oczekiwania dotyczące zachowania uczestników projektu. Przyjęcie i egzekwowanie kodeksu postępowania może pomóc stworzyć pozytywną atmosferę społeczną dla społeczności.
+Kodeks postępowania to dokument, który określa oczekiwania dotyczące zachowania uczestników projektu. Przyjęcie i egzekwowanie kodeksu postępowania może pomóc stworzyć pozytywną atmosferę wśród społeczności.
 
-Kodeksy postępowania chronią nie tylko uczestników, ale i ciebie. Jeśli utrzymasz projekt, może się okazać, że nieproduktywne postawy innych uczestników mogą z czasem powodować wyczerpanie lub niezadowolenie z pracy.
+Kodeksy postępowania chronią nie tylko uczestników, ale i ciebie. Jeśli utrzymujesz projekt, może się okazać, że nieproduktywne postawy innych uczestników mogą z czasem powodować wyczerpanie lub niezadowolenie z pracy.
 
-Kodeks postępowania umożliwia ci zdrowe, konstruktywne zachowanie społeczności. Aktywne podejście zmniejsza prawdopodobieństwo zmęczenia twojego projektu i pomaga podejmować działania, gdy ktoś robi coś, z czym się nie zgadzasz.
+Kodeks postępowania umożliwia ci przyjazne i konstruktywne zachowania wśród społeczności projektu. Aktywne podejście zmniejsza prawdopodobieństwo zmęczenia się swoim projektem i pomaga podejmować działania, gdy ktoś robi coś, z czym się nie zgadzasz.
 
 ## Ustanowienie kodeksu postępowania
 
-Postaraj się ustalić kodeks postępowania tak wcześnie, jak to możliwe: najlepiej przy pierwszym tworzeniu projektu.
+Postaraj się ustalić kodeks postępowania tak wcześnie, jak to możliwe: najlepiej na samym początku projektu.
 
 Oprócz przekazywania swoich oczekiwań kodeks postępowania opisuje następujące kwestie:
 
-* Gdzie obowiązuje kodeks postępowania _(tylko w przypadku problemów i wniosków lub działań społeczności, takich jak wydarzenia?)_
-* Do kogo odnosi się kodeks postępowania _(członkowie społeczności i opiekunowie, ale co ze sponsorami?)_
+* Gdzie obowiązuje kodeks postępowania _(tylko w przypadku problemów i pull requestów lub przy różnych wydarzeniach społeczności)_
+* Do kogo odnosi się kodeks postępowania _(członków społeczności i opiekunów, ale także na przykład sponsorów)_
 * Co się stanie, jeśli ktoś naruszy kodeks postępowania
 * Jak ktoś może zgłaszać naruszenia
 
-Gdziekolwiek możesz, skorzystaj ze stanu techniki. [Przymierze współautorów](https://contributor-covenant.org/) to rozwijany kodeks postępowania używany przez ponad 40 000 projektów open source, w tym Kubernetes, Rails i Swift.
+Gdziekolwiek możesz, skorzystaj z istniejących szablonów. [Przymierze współautorów](https://contributor-covenant.org/) to rozwijany kodeks postępowania używany przez ponad 40 000 projektów open source, w tym Kubernetes, Rails i Swift.
 
-[Kodeks postępowania Django](https://www.djangoproject.com/conduct/) oraz [Kodeks postępowania obywatelskiego](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) to także dwa przykłady dobrego kodeksu postępowania.
+[Kodeks postępowania Django](https://www.djangoproject.com/conduct/) oraz [Kodeks postępowania obywatelskiego](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) to także dwa przykłady dobrych kodeksów postępowania.
 
 Umieść plik CODE_OF_CONDUCT w katalogu głównym projektu i uczyń go widocznym dla społeczności, łącząc go z plikiem CONTRIBUTING  lub README.
 
-## Decydowanie o tym, jak będziesz egzekwować swój kodeks postępowania
+## Zdecyduj, jak będziesz egzekwować swój kodeks postępowania
 
 <aside markdown="1" class="pquote">
   A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
@@ -44,31 +44,31 @@ Umieść plik CODE_OF_CONDUCT w katalogu głównym projektu i uczyń go widoczny
   </p>
 </aside>
 
-Musisz wyjaśnić, w jaki sposób Twój kodeks postępowania będzie egzekwowany **_zanim_** nastąpi naruszenie. Istnieje kilka powodów:
+Musisz wyjaśnić, w jaki sposób Twój kodeks postępowania będzie egzekwowany **_zanim_** nastąpi naruszenie. Istnieje kilka powodów, dla których warto to zrobić:
 
 * To pokazuje, że poważnie podchodzisz do działania, gdy jest to potrzebne.
 
 * Twoja społeczność poczuje się bardziej pewnie, że skargi faktycznie zostaną rozpatrzone.
 
-* Zapewnisz swoją społeczność, że proces sprawdzania jest uczciwy i przejrzysty, jeśli kiedykolwiek zostaną zbadani pod kątem naruszenia.
+* Zapewnisz swoją społeczność, że proces sprawdzania jest uczciwy i przejrzysty, jeśli kiedykolwiek zostaną sprawdzeni pod kątem naruszenia.
 
-Powinieneś dać ludziom prywatny sposób (np. Adres e-mail), aby zgłosić naruszenie zasad postępowania i wyjaśnić, kto otrzyma to zgłoszenie. Może to być opiekun, grupa opiekunów lub grupa robocza ds. Kodeksu postępowania.
+Powinieneś dać ludziom poufny sposób (np. Adres e-mail), do zgłoszenia naruszenia zasad postępowania i wyjaśnić, kto otrzyma to zgłoszenie. Może to być opiekun, grupa opiekunów lub grupa robocza ds. Kodeksu postępowania.
 
-Nie zapominaj, że ktoś może chcieć zgłosić naruszenie dotyczące osoby, która je otrzyma. W takim przypadku daj im możliwość zgłaszania naruszeń komuś innemu. Na przykład, @ctb oraz @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+Nie zapominaj, że ktoś może chcieć zgłosić naruszenie dotyczące osoby, która je otrzyma. W takim przypadku daj im możliwość zgłaszania naruszeń komuś innemu. Na przykład tak jak, @ctb oraz @mr-c [tłumaczą w swoim projekcie](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
 > Przypadki obraźliwych, nękających lub w inny sposób niedopuszczalnych zachowań można zgłaszać, wysyłając wiadomość e-mail na adres **khmer-project@idyll.org**, który jest wysyłany tylko do C. Titusa Browna i Michaela R. Crusoe. Aby zgłosić problem dotyczący któregokolwiek z nich, wyślij wiadomość e-mail **dr Judi Brown Clarke** dyrektor ds. Różnorodności w Centrum Badań nad Ewolucją w Działaniu BEACON, Centrum Nauki i Technologii NSF.*
 
-Aby uzyskać inspirację, zapoznaj się z [instrukcją egzekwowania Django](https://www.djangoproject.com/conduct/enforcement-manual/) (chociaż możesz nie potrzebować czegoś tak kompleksowego, w zależności od wielkości twojego projektu).
+Możesz zainspirować się także [instrukcją egzekwowania Django](https://www.djangoproject.com/conduct/enforcement-manual/) (chociaż możesz nie potrzebować czegoś tak kompleksowego, w zależności od wielkości twojego projektu).
 
-## Egzekwowanie Twojego kodeksu postępowania
+## Egzekwowanie twojego kodeksu postępowania
 
-Czasami, pomimo twoich starań, ktoś zrobi coś, co narusza ten kod. Istnieje kilka sposobów przeciwdziałania negatywnym lub szkodliwym zachowaniom.
+Czasami, pomimo twoich starań, ktoś zrobi coś, co narusza ten kodeks. Istnieje kilka sposobów przeciwdziałania negatywnym lub szkodliwym zachowaniom.
 
 ### Zbierz informacje o sytuacji
 
-Traktuj głos każdego członka społeczności tak samo ważny jak własny. Jeśli otrzymasz zgłoszenie, że ktoś naruszył kodeks postępowania, podejmij go poważnie i zbadaj sprawę, nawet jeśli nie pasuje on do twoich doświadczeń z tą osobą. Takie postępowanie sygnalizuje społeczności, że cenisz ich perspektywę i ufasz ich osądowi.
+Traktuj głos każdego członka społeczności tak samo ważny jak własny. Jeśli otrzymasz zgłoszenie, że ktoś naruszył kodeks postępowania, podejmij się go na poważnie i zbadaj sprawę, nawet jeśli naruszenie nie pasuje do twoich doświadczeń z tą osobą. Takie postępowanie sygnalizuje społeczności, że cenisz ich perspektywę i ufasz ich osądowi.
 
-Członek społeczności, o którym mowa, może być wielokrotnym przestępcą, który konsekwentnie sprawia, że inni czują się niekomfortowo, lub mogą powiedzieć coś lub zrobić tylko raz. Oba mogą być podstawą do podjęcia działania, w zależności od kontekstu.
+Członek społeczności, o którym mowa, może wieloktrotnie sprawiać, że inni członkowie czują się niekomfortowo lub zrobić to tylko jeden raz. Oba mogą być podstawą do podjęcia działania, w zależności od kontekstu.
 
 Zanim odpowiesz, daj sobie czas na zrozumienie, co się stało. Przeczytaj wcześniejsze komentarze i rozmowy tej osoby, aby lepiej zrozumieć, kim ona jest i dlaczego mogła postąpić w taki sposób. Spróbuj zebrać inne niż własne opinie na temat tej osoby i jej zachowania.
 
@@ -81,17 +81,17 @@ Zanim odpowiesz, daj sobie czas na zrozumienie, co się stało. Przeczytaj wcze
 
 ### Podejmij odpowiednie działania
 
-Po zebraniu i przetworzeniu wystarczających informacji musisz zdecydować, co robić. Rozważając kolejne kroki, pamiętaj, że Twoim celem jako moderatora jest promowanie bezpiecznego, pełnego szacunku i współpracy środowiska. Zastanów się nie tylko, jak poradzić sobie z daną sytuacją, ale także, w jaki sposób twoja reakcja wpłynie na dalsze zachowania i oczekiwania twojej społeczności.
+Po zebraniu i przetworzeniu wystarczających informacji musisz zdecydować, co robić. Rozważając kolejne kroki, pamiętaj, że twoim celem jako moderatora jest promowanie bezpiecznego, pełnego szacunku i współpracy środowiska. Zastanów się nie tylko, jak poradzić sobie z daną sytuacją, ale także, w jaki sposób twoja reakcja wpłynie na dalsze zachowania i oczekiwania twojej społeczności.
 
-Gdy ktoś zgłosi naruszenie kodeksu postępowania, jego zadaniem jest zająć się nim, a nie jego obowiązkiem. Czasami reporter ujawnia informacje z dużym ryzykiem dla ich kariery, reputacji lub bezpieczeństwa fizycznego. Zmuszenie ich do konfrontacji z napastnikiem może postawić reportera w kompromitującej sytuacji. Należy obsługiwać bezpośrednią komunikację z daną osobą, chyba że reporter wyraźnie zażąda inaczej.
+Gdy ktoś zgłosi naruszenie kodeksu postępowania, to twoim obowiązkiem jest wyjaśnić sprawę. Czasami osoba zgłaszająca ujawnia informacje z dużym ryzykiem dla ich kariery, reputacji lub bezpieczeństwa fizycznego. Zmuszenie ich do konfrontacji z napastnikiem może postawić osobę zgłaszającą w kompromitującej sytuacji. Należy komunikować się bezpośrednio z daną osobą, chyba że osoba zgłaszająca wyraźnie zażąda inaczej.
 
 Istnieje kilka sposobów reagowania na naruszenie kodeksu postępowania:
 
 * **Daj osobie, o której mowa, publiczne ostrzeżenie** i wyjaśnij, w jaki sposób ich zachowanie wpłynęło negatywnie na innych, najlepiej w kanale, w którym miało miejsce. Tam, gdzie to możliwe, komunikacja publiczna przekazuje reszcie społeczności, że poważnie podchodzisz do kodeksu postępowania. Bądź miły, ale stanowczy w swojej komunikacji.
 
-* **Prywatnie skontaktuj się z osobą** w celu wyjaśnienia, w jaki sposób ich zachowanie wpłynęło negatywnie na innych. Możesz skorzystać z prywatnego kanału komunikacji, jeśli sytuacja dotyczy poufnych danych osobowych. Jeśli komunikujesz się z kimś prywatnie, dobrym pomysłem jest skontaktowanie się z osobami, które jako pierwsze zgłosiły sytuację, aby wiedziały, że podjąłeś działania. Poproś osobę zgłaszającą o zgodę przed jej wysłaniem.
+* **Prywatnie skontaktuj się z osobą** w celu wyjaśnienia, w jaki sposób ich zachowanie wpłynęło negatywnie na innych. Możesz skorzystać z prywatnego kanału komunikacji, jeśli sytuacja dotyczy poufnych danych osobowych. Jeśli komunikujesz się z kimś prywatnie, dobrym pomysłem jest skontaktowanie się z osobami, które jako pierwsze zgłosiły sytuację, aby wiedziały, że podjąłeś działania. Poproś osobę zgłaszającą o zgodę o ujawnienie jej przed wysłaniem wiadomości.
 
-Czasami nie można osiągnąć rozdzielczości. Dana osoba może stać się agresywna lub wroga, gdy zostanie skonfrontowana lub nie zmieni swojego zachowania. W tej sytuacji możesz rozważyć podjęcie silniejszych działań. Na przykład:
+Czasami nie można osiągnąć rozwiązania. Dana osoba może stać się agresywna lub wroga, gdy zostanie skonfrontowana lub nie zmieni swojego zachowania. W tej sytuacji możesz rozważyć podjęcie silniejszych działań. Na przykład:
 
 * **Zawieś osobę** w kwestii projektu, egzekwowane przez tymczasowy zakaz uczestnictwa w jakimkolwiek aspekcie projektu
 
@@ -101,14 +101,14 @@ Zbanowanych członków nie należy lekceważyć, stanowią trwałą i niemożliw
 
 ## Twoje obowiązki jako opiekuna
 
-Kodeks postępowania nie jest prawem egzekwowanym arbitralnie. Jesteś podmiotem egzekwującym kodeks postępowania i Twoim obowiązkiem jest przestrzegać zasad ustanowionych w tym kodeksie postępowania.
+Kodeks postępowania nie jest prawem egzekwowanym arbitralnie. Jesteś podmiotem egzekwującym kodeks postępowania i twoim obowiązkiem jest przestrzegać zasad ustanowionych w tym kodeksie postępowania.
 
 Jako opiekun ustalasz wytyczne dla swojej społeczności i egzekwujesz je zgodnie z zasadami określonymi w kodeksie postępowania. Oznacza to poważne potraktowanie każdego zgłoszenia naruszenia kodeksu postępowania. Zgłaszającemu należy się dokładna i rzetelna ocena jego skargi. Jeśli stwierdzisz, że zgłoszone przez nich zachowanie nie stanowi naruszenia, przekaż im to jasno i wyjaśnij, dlaczego nie zamierzasz podjąć działań w związku z tym. To, co zrobią z tym, zależy od nich: tolerować zachowanie, z którym mieli problem, lub przestać uczestniczyć w społeczności.
 
-Raport o zachowaniu, który nie narusza kodeksu postępowania technicznego, może nadal wskazywać na problem w Twojej społeczności i powinieneś zbadać ten potencjalny problem i podjąć odpowiednie działania. Może to obejmować rewizję twojego kodeksu postępowania w celu wyjaśnienia dopuszczalnego zachowania i / lub rozmowę z osobą, której zachowanie zostało zgłoszone i poinformowanie ich, że chociaż nie naruszyli kodeksu postępowania, omijają granicę oczekiwań i upewniają się uczestnicy czują się niekomfortowo.
+Zgłoszenie zachowania, które nie narusza kodeksu postępowania, może nadal wskazywać na problem w twojej społeczności i powinieneś zbadać ten potencjalny problem i podjąć odpowiednie działania. Może to obejmować rewizję twojego kodeksu postępowania w celu wyjaśnienia dopuszczalnego zachowania i / lub rozmowę z osobą, której zachowanie zostało zgłoszone i poinformowanie ich, że chociaż nie naruszyli kodeksu postępowania, omijają granicę oczekiwań i sprawiają, że uczestnicy czują się niekomfortowo.
 
 W końcu, jako opiekun, ustalasz i egzekwujesz standardy dotyczące akceptowalnego zachowania. Masz możliwość kształtowania wartości społeczności w ramach projektu, a uczestnicy oczekują, że egzekwujesz te wartości w uczciwy i zrównoważony sposób.
 
 ## Zachęcaj do zachowań, które chcesz zobaczyć na świecie 🌎
 
-Kiedy projekt wydaje się wrogi lub niechciany, nawet jeśli jest to tylko jedna osoba, której zachowanie jest tolerowane przez innych, ryzykujesz utratą znacznie większej liczby współpracowników, z którymi niektórzy mogą nawet nie spotkać. Przyjęcie lub egzekwowanie kodeksu postępowania nie zawsze jest łatwe, ale promowanie przyjaznego środowiska pomoże Twojej społeczności w rozwoju.
+Kiedy projekt wydaje się wrogi lub niechciany, nawet jeśli jest to tylko jedna osoba, której zachowanie jest tolerowane przez innych, ryzykujesz utratą znacznie większej liczby współpracowników, a niektórzy nigdy nie dołączą do społeczności twojego projektu. Przyjęcie lub egzekwowanie kodeksu postępowania nie zawsze jest łatwe, ale promowanie przyjaznego środowiska pomoże twojej społeczności w rozwoju.

From 07c496dfd1be93cf350cc6cb15a20162fb769ef3 Mon Sep 17 00:00:00 2001
From: collin-klippel <112669514+collin-klippel@users.noreply.github.com>
Date: Sun, 18 Sep 2022 15:51:22 -0500
Subject: [PATCH 374/749] =?UTF-8?q?Add=20mention=20of=20=E2=80=9Cdraft?=
 =?UTF-8?q?=E2=80=9D=20PRs?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 _articles/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 663f84ca1a7..c2ec46bc89e 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -478,7 +478,7 @@ You should usually open a pull request in the following situations:
 * Submit trivial fixes (for example, a typo, a broken link or an obvious error)
 * Start work on a contribution that was already asked for, or that you've already discussed, in an issue
 
-A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
+A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
 
 If the project is on GitHub, here's how to submit a pull request:
 

From a124cd09d548d1413a2722ee9a1ac651cae1184f Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 20 Sep 2022 10:24:44 +0300
Subject: [PATCH 375/749] translate how-to-contribute.md

---
 _articles/el/how-to-contribute.md | 424 +++++++++++++++---------------
 1 file changed, 212 insertions(+), 212 deletions(-)

diff --git a/_articles/el/how-to-contribute.md b/_articles/el/how-to-contribute.md
index 0c205111896..b9362f910ac 100644
--- a/_articles/el/how-to-contribute.md
+++ b/_articles/el/how-to-contribute.md
@@ -10,210 +10,210 @@ related:
   - building
 ---
 
-## Why contribute to open source?
+## Γιατί να συνεισφέρετε στον ανοιχτό κώδικα;
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
-  Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+  Η εργασία στο \[freenode\] με βοήθησε να αποκτήσω πολλές από τις δεξιότητες που χρησιμοποίησα αργότερα για τις σπουδές μου στο πανεπιστήμιο και την πραγματική μου δουλειά. Νομίζω ότι η εργασία σε έργα ανοιχτού κώδικα βοηθάει εμένα όσο βοηθάει και το έργο!
   <p markdown="1" class="pquote-credit">
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+- @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
   </p>
 </aside>
 
-Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+Η συνεισφορά σε λογισμικό ανοικτού κώδικα μπορεί να είναι ένας ικανοποιητικός τρόπος για να μάθετε, να διδάξετε και να αποκτήσετε εμπειρία σε σχεδόν οποιαδήποτε δεξιότητα μπορείτε να φανταστείτε.
 
-Why do people contribute to open source? Plenty of reasons!
+Γιατί οι άνθρωποι συνεισφέρουν στον ανοικτό κώδικα; Πολλοί λόγοι!
 
-### Improve software you rely on
+### Βελτιώνουν το λογισμικό στο οποίο βασίζονται
 
-Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+Πολλοί συνεισφέροντες σε λογισμικό ανοικτού κώδικα ξεκινούν ως χρήστες του λογισμικού στο οποίο συνεισφέρουν. Όταν βρίσκετε ένα σφάλμα σε ένα λογισμικό ανοικτού κώδικα που χρησιμοποιείτε, ίσως θελήσετε να κοιτάξετε τον πηγαίο κώδικα για να δείτε αν μπορείτε να το διορθώσετε μόνοι σας. Αν είναι έτσι, τότε η συνεισφορά του διορθωτικού είναι ο καλύτερος τρόπος για να διασφαλίσετε ότι οι φίλοι σας (και εσείς οι ίδιοι όταν κάνετε ενημέρωση στην επόμενη έκδοση) θα μπορέσουν να επωφεληθούν από αυτό.
 
-### Improve existing skills
+### Βελτιώστε τις υπάρχουσες δεξιότητες
 
-Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+Είτε πρόκειται για προγραμματισμό, είτε για σχεδιασμό διεπαφής χρήστη, είτε για γραφιστική, είτε για συγγραφή, είτε για οργάνωση, αν ψάχνετε για εξάσκηση, υπάρχει μια εργασία για εσάς σε ένα έργο ανοιχτού κώδικα.
 
-### Meet people who are interested in similar things
+### Γνωρίστε ανθρώπους που ενδιαφέρονται για παρόμοια πράγματα
 
-Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+Τα έργα ανοιχτού κώδικα με θερμές, φιλόξενες κοινότητες κρατούν τους ανθρώπους να επιστρέφουν για χρόνια. Πολλοί άνθρωποι δημιουργούν φιλίες ζωής μέσα από τη συμμετοχή τους στον ανοιχτό κώδικα, είτε πρόκειται για συναντήσεις σε συνέδρια είτε για διαδικτυακές συζητήσεις αργά το βράδυ για μπουρίτος.
 
-### Find mentors and teach others
+### Βρείτε μέντορες και διδάξτε άλλους
 
-Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+Η συνεργασία με άλλους σε ένα κοινό έργο σημαίνει ότι θα πρέπει να εξηγείτε πώς κάνετε τα πράγματα, καθώς και να ζητάτε βοήθεια από άλλους ανθρώπους. Οι πράξεις μάθησης και διδασκαλίας μπορεί να είναι μια ικανοποιητική δραστηριότητα για όλους τους εμπλεκόμενους.
 
-### Build public artifacts that help you grow a reputation (and a career)
+### Δημιουργήστε δημόσια αντικείμενα που σας βοηθούν να αναπτύξετε τη φήμη σας (και την καριέρα σας)
 
-By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+Εξ ορισμού, όλη η εργασία σας με ανοιχτό κώδικα είναι δημόσια, πράγμα που σημαίνει ότι έχετε δωρεάν παραδείγματα για να τα πάρετε οπουδήποτε ως επίδειξη του τι μπορείτε να κάνετε.
 
-### Learn people skills
+### Μάθετε δεξιότητες ανθρώπινου δυναμικού
 
-Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+Ο ανοικτός κώδικας προσφέρει ευκαιρίες για να εξασκήσετε ηγετικές και διοικητικές δεξιότητες, όπως η επίλυση συγκρούσεων, η οργάνωση ομάδων ανθρώπων και η ιεράρχηση προτεραιοτήτων εργασίας.
 
-### It's empowering to be able to make changes, even small ones
+### Είναι ενδυναμωτικό να μπορείς να κάνεις αλλαγές, ακόμη και μικρές
 
-You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+Δεν χρειάζεται να γίνετε ισόβιος συνεργάτης για να απολαύσετε τη συμμετοχή σας στον ανοικτό κώδικα. Έχετε δει ποτέ ένα τυπογραφικό λάθος σε έναν ιστότοπο και ευχηθήκατε κάποιος να το διορθώσει; Σε ένα έργο ανοιχτού κώδικα, μπορείτε να κάνετε ακριβώς αυτό. Ο ανοικτός κώδικας βοηθά τους ανθρώπους να αισθάνονται ότι έχουν εξουσία στη ζωή τους και στο πώς βιώνουν τον κόσμο, και αυτό από μόνο του είναι ευχάριστο.
 
-## What it means to contribute
+## Τι σημαίνει να συνεισφέρεις
 
-If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+Αν είστε νέος συνεισφέρων σε έργα ανοικτού κώδικα, η διαδικασία μπορεί να είναι εκφοβιστική. Πώς μπορείτε να βρείτε το κατάλληλο έργο; Τι γίνεται αν δεν ξέρετε να προγραμματίζετε; Τι γίνεται αν κάτι πάει στραβά;
 
-Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+Μην ανησυχείτε! Υπάρχουν διάφοροι τρόποι για να συμμετάσχετε σε ένα έργο ανοικτού κώδικα και μερικές συμβουλές θα σας βοηθήσουν να αξιοποιήσετε στο έπακρο την εμπειρία σας.
 
-### You don't have to contribute code
+### Δεν χρειάζεται να συνεισφέρετε κώδικα
 
-A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+Μια κοινή παρανόηση σχετικά με τη συνεισφορά σε έργα ανοικτού κώδικα είναι ότι πρέπει να συνεισφέρετε κώδικα. Στην πραγματικότητα, είναι συχνά τα άλλα μέρη ενός έργου που [παραμελούνται ή παραβλέπονται περισσότερο](https://github.com/blog/2195-the-shape-of-open-source). Θα κάνετε στο έργο μια _τεράστια_ χάρη προσφέροντας να συνεισφέρετε με τέτοιου είδους συνεισφορές!
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
-  I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+  Έχω γίνει γνωστός για τη δουλειά μου στο CocoaPods, αλλά οι περισσότεροι άνθρωποι δεν γνωρίζουν ότι στην πραγματικότητα δεν κάνω καμία πραγματική δουλειά στο ίδιο το εργαλείο CocoaPods. Ο χρόνος μου για το έργο αναλώνεται κυρίως σε πράγματα όπως η τεκμηρίωση και η εργασία πάνω στο branding.
   <p markdown="1" class="pquote-credit">
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+- @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
   </p>
 </aside>
 
-Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+## Γιατί να συνεισφέρετε στον ανοιχτό κώδικα; <aside markdown="1" class="pquote">
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing.
+<img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
+  Η εργασία στο \[freenode\] με βοήθησε να αποκτήσω πολλές από τις δεξιότητες που χρησιμοποίησα αργότερα για τις σπουδές μου στο πανεπιστήμιο και την πραγματική μου δουλειά.
+  Νομίζω ότι η εργασία σε έργα ανοιχτού κώδικα βοηθάει εμένα όσο βοηθάει και το έργο! <p markdown="1" class="pquote-credit"> Μου έδιναν μια πολύ καλή αφορμή για να ζητήσω διευκρινίσεις σχετικά με ένα θέμα, αλλά το πιο κρίσιμο ήταν ότι μπορούσα να παρατηρήσω πότε κάποιος επισήμανε κάτι που έπρεπε να διορθωθεί.
   <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
+- @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
   </p>
 </aside>
 
-### Do you like planning events?
+### Σας αρέσει να προγραμματίζετε εκδηλώσεις;
 
-* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
-* Organize the project's conference (if they have one)
-* Help community members find the right conferences and submit proposals for speaking
+* Οργανώστε εργαστήρια ή συναντήσεις για το έργο, [όπως έκανε ο @fzamperin για το NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Διοργανώνετε το συνέδριο του έργου (αν έχουν)
+* Βοηθήστε τα μέλη της κοινότητας να βρουν τα κατάλληλα συνέδρια και να υποβάλουν προτάσεις για ομιλία
 
-### Do you like to design?
+### Σας αρέσει να σχεδιάζετε;
 
-* Restructure layouts to improve the project's usability
-* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
-* Put together a style guide to help the project have a consistent visual design
-* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+* Να αναδιαρθρώνετε τις διατάξεις για να βελτιώσετε τη χρηστικότητα του έργου
+* Διεξαγωγή έρευνας χρηστών για την αναδιοργάνωση και βελτίωση της πλοήγησης ή των μενού του έργου, [όπως προτείνει το Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Να συντάσσετε έναν οδηγό στυλ για να βοηθήσετε το έργο να έχει έναν συνεπή οπτικό σχεδιασμό
+* Δημιουργήστε τέχνη για μπλουζάκια ή ένα νέο λογότυπο, [όπως έκαναν οι συντελεστές του hapi.js](https://github.com/hapijs/contrib/issues/68)
 
-### Do you like to write?
+### Σας αρέσει να γράφετε;
 
-* Write and improve the project's documentation
-* Curate a folder of examples showing how the project is used
-* Start a newsletter for the project, or curate highlights from the mailing list
-* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
-* Write a translation for the project's documentation
+* Γράφετε και βελτιώνετε την τεκμηρίωση του έργου
+* Επιμεληθείτε έναν φάκελο με παραδείγματα που δείχνουν πώς χρησιμοποιείται το έργο
+* Ξεκινήστε ένα ενημερωτικό δελτίο για το έργο, ή επιμεληθείτε τα σημαντικότερα σημεία από τη λίστα αλληλογραφίας
+* Γράφετε εκπαιδευτικά προγράμματα για το έργο, [όπως έκαναν οι συντελεστές του PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Γράψτε μια μετάφραση για την τεκμηρίωση του έργου
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
-  Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+  Σοβαρά, το \[documentation\] είναι μέγα-σημαντικό. Η τεκμηρίωση μέχρι στιγμής είναι εξαιρετική και είναι ένα φονικό χαρακτηριστικό της Babel. Υπάρχουν τμήματα που σίγουρα χρειάζονται λίγη δουλειά και ακόμα και η προσθήκη μιας παραγράφου εδώ ή εκεί είναι εξαιρετικά ευπρόσδεκτη.
   <p markdown="1" class="pquote-credit">
-— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+- @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
   </p>
 </aside>
 
-### Do you like organizing?
+### Σας αρέσει η οργάνωση;
 
-* Link to duplicate issues, and suggest new issue labels, to keep things organized
-* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
-* Ask clarifying questions on recently opened issues to move the discussion forward
+* Συνδέστε τα διπλά θέματα και προτείνετε νέες ετικέτες θεμάτων, για να διατηρήσετε τα πράγματα οργανωμένα
+* Ψάξτε τα ανοιχτά θέματα και προτείνετε το κλείσιμο των παλιών, [όπως έκανε ο @nzakas για το ESLint](https://github.com/eslint/eslint/issues/6765)
+* Να κάνετε διευκρινιστικές ερωτήσεις σε πρόσφατα ανοιχτά θέματα για να προχωρήσει η συζήτηση.
 
-### Do you like to code?
+### Σας αρέσει να γράφετε κώδικα;
 
-* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
-* Ask if you can help write a new feature
-* Automate project setup
-* Improve tooling and testing
+* Βρείτε ένα ανοιχτό θέμα για να ασχοληθείτε, [όπως έκανε ο @dianjin για το Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Ρωτήστε αν μπορείτε να βοηθήσετε στη συγγραφή ενός νέου χαρακτηριστικού.
+* Αυτοματοποιήστε την εγκατάσταση του έργου
+* Βελτιώστε τα εργαλεία και τις δοκιμές
 
-### Do you like helping people?
+### Σας αρέσει να βοηθάτε τους ανθρώπους;
 
-* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
-* Answer questions for people on open issues
-* Help moderate the discussion boards or conversation channels
+* Απαντήστε σε ερωτήσεις σχετικά με το έργο π.χ. στο Stack Overflow ([όπως αυτό το παράδειγμα Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) ή στο Reddit.
+* Απαντάτε σε ερωτήσεις για ανθρώπους σε ανοιχτά θέματα
+* Βοηθήστε να συντονίσετε τους πίνακες συζητήσεων ή τα κανάλια συζήτησης
 
-### Do you like helping others code?
+### Σας αρέσει να βοηθάτε άλλους να προγραμματίζουν;
 
-* Review code on other people's submissions
-* Write tutorials for how a project can be used
-* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+* Αναθεωρείτε τον κώδικα σε υποβολές άλλων ανθρώπων
+* Γράφετε σεμινάρια για το πώς μπορεί να χρησιμοποιηθεί ένα έργο
+* Προσφερθείτε να γίνετε μέντορας ενός άλλου συνεισφέροντα, [όπως έκανε ο @ereichert για τον @bronzdoc στο Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
 
-### You don't just have to work on software projects!
+### Δεν χρειάζεται να εργάζεστε μόνο σε έργα λογισμικού!
 
-While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+Αν και ο όρος "ανοικτός κώδικας" αναφέρεται συχνά στο λογισμικό, μπορείτε να συνεργαστείτε σχεδόν σε οτιδήποτε. * Απαντήστε σε ερωτήσεις σχετικά με το έργο π.χ. στο Stack Overflow ([όπως αυτό το παράδειγμα Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) ή στο Reddit.
 
-For example:
+Για παράδειγμα:
 
-* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
-* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
-* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+* @sindresorhus επιμελείται μια [λίστα με "φοβερές" λίστες](https://github.com/sindresorhus/awesome)
+* Ο @h5bp διατηρεί μια [λίστα με πιθανές ερωτήσεις συνέντευξης](https://github.com/h5bp/Front-end-Developer-Interview-Questions) για υποψήφιους front-end προγραμματιστές
+* Ο @stuartlynn και η @nicole-a-tesla δημιούργησαν μια [συλλογή με διασκεδαστικά στοιχεία για τους πιθήκους](https://github.com/stuartlynn/puffin_facts)
 
-Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
+Ακόμα και αν είστε προγραμματιστής λογισμικού, η εργασία σε ένα έργο τεκμηρίωσης μπορεί να σας βοηθήσει να ξεκινήσετε στον ανοιχτό κώδικα. Είναι συχνά λιγότερο τρομακτικό να εργάζεστε σε έργα που δεν περιλαμβάνουν κώδικα, και η διαδικασία της συνεργασίας θα ενισχύσει την αυτοπεποίθηση και την εμπειρία σας.
 
-## Orienting yourself to a new project
+## Προσανατολισμός σε ένα νέο έργο
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
-  If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+  Αν πηγαίνετε σε έναν ανιχνευτή ζητημάτων και τα πράγματα φαίνονται συγκεχυμένα, δεν φταίτε μόνο εσείς. Αυτά τα εργαλεία απαιτούν πολλές σιωπηρές γνώσεις, αλλά οι άνθρωποι μπορούν να σας βοηθήσουν να περιηγηθείτε σε αυτά και μπορείτε να τους κάνετε ερωτήσεις.
   <p markdown="1" class="pquote-credit">
-— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+- @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
   </p>
 </aside>
 
-For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+Για οτιδήποτε περισσότερο από μια διόρθωση τυπογραφικού λάθους, η συνεισφορά στον ανοιχτό κώδικα είναι σαν να πηγαίνεις σε μια ομάδα αγνώστων σε ένα πάρτι. Αν αρχίσετε να μιλάτε για λάμα, ενώ αυτοί ήταν βαθιά χωμένοι σε μια συζήτηση για χρυσόψαρα, μάλλον θα σας κοιτάξουν λίγο περίεργα.
 
-Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
+Πριν πέσετε στα τυφλά με τις δικές σας προτάσεις, ξεκινήστε μαθαίνοντας πώς να διαβάζετε το δωμάτιο. Με αυτόν τον τρόπο αυξάνονται οι πιθανότητες να προσέξουν και να ακούσουν τις ιδέες σας.
 
-### Anatomy of an open source project
+### Ανατομία ενός έργου ανοικτού κώδικα
 
-Every open source community is different.
+Κάθε κοινότητα ανοικτού κώδικα είναι διαφορετική.
 
-Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+Το να περάσετε χρόνια σε ένα έργο ανοιχτού κώδικα σημαίνει ότι έχετε γνωρίσει ένα έργο ανοιχτού κώδικα. Αν μετακινηθείτε σε ένα άλλο έργο, μπορεί να διαπιστώσετε ότι το λεξιλόγιο, οι κανόνες και οι τρόποι επικοινωνίας είναι εντελώς διαφορετικοί.
 
-That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+Τούτου λεχθέντος, πολλά έργα ανοικτού κώδικα ακολουθούν μια παρόμοια οργανωτική δομή. Η κατανόηση των διαφορετικών ρόλων της κοινότητας και της συνολικής διαδικασίας θα σας βοηθήσει να προσανατολιστείτε γρήγορα σε οποιοδήποτε νέο έργο.
 
-A typical open source project has the following types of people:
+Ένα τυπικό έργο ανοικτού κώδικα έχει τους ακόλουθους τύπους ανθρώπων:
 
-* **Author:** The person/s or organization that created the project
-* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
-* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
-* **Contributors:** Everyone who has contributed something back to the project
-* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+* **Συγγραφέας:** Το άτομο/τα άτομα ή ο οργανισμός που δημιούργησε το έργο
+* **Δικαιούχος:** Το άτομο/α που έχει/ουν τη διοικητική κυριότητα του οργανισμού ή του αποθετηρίου (δεν είναι πάντα το ίδιο με τον αρχικό συγγραφέα)
+* **Διαχειριστές:** Συντελεστές που είναι υπεύθυνοι για την προώθηση του οράματος και τη διαχείριση των οργανωτικών πτυχών του έργου (μπορεί επίσης να είναι συγγραφείς ή ιδιοκτήτες του έργου).
+* **Συντελεστές:** Όλοι όσοι έχουν συνεισφέρει κάτι στο έργο
+* **Μέλη της κοινότητας:** Άνθρωποι που χρησιμοποιούν το έργο. Μπορεί να συμμετέχουν ενεργά σε συζητήσεις ή να εκφράζουν τη γνώμη τους για την κατεύθυνση του έργου
 
-Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+Τα μεγαλύτερα έργα μπορεί επίσης να έχουν υποεπιτροπές ή ομάδες εργασίας που επικεντρώνονται σε διαφορετικά καθήκοντα, όπως η δημιουργία εργαλείων, η ταξινόμηση, ο συντονισμός της κοινότητας και η διοργάνωση εκδηλώσεων. Αναζητήστε στον ιστότοπο ενός έργου μια σελίδα "ομάδας" ή στο αποθετήριο για την τεκμηρίωση διακυβέρνησης, για να βρείτε αυτές τις πληροφορίες.
 
-A project also has documentation. These files are usually listed in the top level of a repository.
+Ένα έργο διαθέτει επίσης τεκμηρίωση. Αυτά τα αρχεία συνήθως παρατίθενται στο κορυφαίο επίπεδο ενός αποθετηρίου.
 
-* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
-* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
-* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
-* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
-* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.
+* **ΑΔΕΙΑ ΑΝΟΙΚΤΟΥ ΚΩΔΙΚΟΥ:** Εξ ορισμού, κάθε έργο ανοικτού κώδικα πρέπει να έχει μια [άδεια ανοικτού κώδικα](https://choosealicense.com). Εάν το έργο δεν έχει άδεια χρήσης, δεν είναι ανοικτού κώδικα.
+* **README:** Το README είναι το εγχειρίδιο οδηγιών που καλωσορίζει τα νέα μέλη της κοινότητας στο έργο. Εξηγεί γιατί το έργο είναι χρήσιμο και πώς να ξεκινήσετε.
+* **ΣΥΜΒΟΛΗ:** Ενώ τα README βοηθούν τους ανθρώπους να _χρησιμοποιήσουν_ το έργο, τα έγγραφα συνεισφοράς βοηθούν τους ανθρώπους να _εισφέρουν_ στο έργο. Εξηγεί τι είδους συνεισφορές χρειάζονται και πώς λειτουργεί η διαδικασία. Αν και δεν έχει κάθε έργο ένα αρχείο CONTRIBUTING, η παρουσία του σηματοδοτεί ότι το έργο είναι φιλόξενο για συνεισφορά.
+* **ΚΩΔΙΚΑΣ_ΔΕΟΝΤΟΛΟΓΙΑΣ:** Ο κώδικας δεοντολογίας θέτει βασικούς κανόνες για τη συμπεριφορά των συμμετεχόντων που σχετίζονται και βοηθά στη διευκόλυνση ενός φιλικού, φιλόξενου περιβάλλοντος. Αν και δεν έχει κάθε έργο ένα αρχείο CODE_OF_CONDUCT, η παρουσία του σηματοδοτεί ότι πρόκειται για ένα φιλόξενο έργο στο οποίο μπορείτε να συνεισφέρετε.
+* **Άλλη τεκμηρίωση:** Ενδέχεται να υπάρχει πρόσθετη τεκμηρίωση, όπως σεμινάρια, οδηγίες χρήσης ή πολιτικές διακυβέρνησης, ειδικά σε μεγαλύτερα έργα.
 
-Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+Τέλος, τα έργα ανοικτού κώδικα χρησιμοποιούν τα ακόλουθα εργαλεία για την οργάνωση της συζήτησης. Η ανάγνωση των αρχείων θα σας δώσει μια καλή εικόνα για το πώς σκέφτεται και λειτουργεί η κοινότητα.
 
-* **Issue tracker:** Where people discuss issues related to the project.
-* **Pull requests:** Where people discuss and review changes that are in progress.
-* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
-* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
+* **Issue tracker:** Όπου οι άνθρωποι συζητούν θέματα που σχετίζονται με το έργο.
+* **Pull requests:** Όπου οι άνθρωποι συζητούν και αναθεωρούν τις αλλαγές που βρίσκονται σε εξέλιξη.
+* **Φόρουμ συζητήσεων ή λίστες αλληλογραφίας:** Ορισμένα έργα μπορεί να χρησιμοποιούν αυτά τα κανάλια για θέματα συζήτησης (για παράδειγμα, _"Πώς μπορώ να..."_ ή _"Τι πιστεύετε για..."_ αντί για αναφορές σφαλμάτων ή αιτήσεις για χαρακτηριστικά). Άλλα χρησιμοποιούν τον ανιχνευτή ζητημάτων για όλες τις συζητήσεις.
+* **Σύγχρονο κανάλι συνομιλίας:** Ορισμένα έργα χρησιμοποιούν κανάλια συνομιλίας (όπως το Slack ή το IRC) για περιστασιακή συζήτηση, συνεργασία και γρήγορες ανταλλαγές.
 
-## Finding a project to contribute to
+## Βρίσκοντας ένα έργο για να συνεισφέρετε
 
-Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+Τώρα που έχετε καταλάβει πώς λειτουργούν τα έργα ανοικτού κώδικα, ήρθε η ώρα να βρείτε ένα έργο για να συνεισφέρετε!
 
-If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_
+Αν δεν έχετε συνεισφέρει ποτέ στο παρελθόν σε έργα ανοικτού κώδικα, ακολουθήστε τη συμβουλή του προέδρου των ΗΠΑ Τζον Φ. Κένεντι, ο οποίος είπε κάποτε: _"Μη ρωτάτε τι μπορεί να κάνει η χώρα σας για εσάς - ρωτήστε τι μπορείτε να κάνετε εσείς για τη χώρα σας".
 
-Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+Η συνεισφορά στον ανοικτό κώδικα γίνεται σε όλα τα επίπεδα, σε όλα τα έργα. Δεν χρειάζεται να σκεφτείτε υπερβολικά ποια ακριβώς θα είναι η πρώτη σας συνεισφορά ή πώς θα φαίνεται.
 
-Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+Αντ' αυτού, ξεκινήστε σκεπτόμενοι τα έργα που ήδη χρησιμοποιείτε ή θέλετε να χρησιμοποιήσετε. Τα έργα στα οποία θα συνεισφέρετε ενεργά είναι αυτά στα οποία θα βρίσκεστε να επιστρέφετε.
 
-Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+Μέσα σε αυτά τα έργα, όποτε πιάνετε τον εαυτό σας να σκέφτεται ότι κάτι θα μπορούσε να είναι καλύτερο ή διαφορετικό, ακολουθήστε το ένστικτό σας.
 
-Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+Ο ανοιχτός κώδικας δεν είναι μια αποκλειστική λέσχη- φτιάχνεται από ανθρώπους σαν εσάς. Ο "ανοικτός κώδικας" είναι απλώς ένας φανταχτερός όρος για να αντιμετωπίζεις τα προβλήματα του κόσμου ως επιλύσιμα.
 
-You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
+Μπορεί να σκανάρετε ένα README και να βρείτε έναν σπασμένο σύνδεσμο ή ένα τυπογραφικό λάθος. Ή είστε νέος χρήστης και παρατηρήσατε ότι κάτι είναι σπασμένο ή ένα θέμα που πιστεύετε ότι θα έπρεπε πραγματικά να υπάρχει στην τεκμηρίωση. Αντί να το αγνοήσετε και να προχωρήσετε ή να ζητήσετε από κάποιον άλλο να το διορθώσει, δείτε αν μπορείτε να βοηθήσετε με τη συμμετοχή σας. Αυτό είναι το νόημα του ανοιχτού κώδικα!
 
-> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+> Το [28% των περιστασιακών συνεισφορών](https://www.igor.pro.br/publica/papers/saner2016.pdf) στον ανοικτό κώδικα είναι τεκμηρίωση, όπως διόρθωση τυπογραφικών λαθών, αναδιαμόρφωση ή συγγραφή μετάφρασης.
 
-If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+Αν ψάχνετε για υπάρχοντα θέματα που μπορείτε να διορθώσετε, κάθε έργο ανοιχτού κώδικα έχει μια σελίδα `/contribute` που επισημαίνει θέματα φιλικά προς τους αρχάριους με τα οποία μπορείτε να ξεκινήσετε. Πλοηγηθείτε στην κεντρική σελίδα του αποθετηρίου στο GitHub και προσθέστε `/contribute` στο τέλος της διεύθυνσης URL (για παράδειγμα [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
 
-You can also use one of the following resources to help you discover and contribute to new projects:
+Μπορείτε επίσης να χρησιμοποιήσετε έναν από τους παρακάτω πόρους για να σας βοηθήσει να ανακαλύψετε και να συνεισφέρετε σε νέα έργα:
 
 * [GitHub Explore](https://github.com/explore/)
 * [Open Source Friday](https://opensourcefriday.com)
@@ -225,229 +225,229 @@ You can also use one of the following resources to help you discover and contrib
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
-### A checklist before you contribute
+### Μια λίστα ελέγχου πριν συνεισφέρετε
 
-When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+Όταν έχετε βρει ένα έργο στο οποίο θα θέλατε να συνεισφέρετε, κάντε ένα γρήγορο έλεγχο για να βεβαιωθείτε ότι το έργο είναι κατάλληλο για να δέχεται συνεισφορές. Διαφορετικά, η σκληρή δουλειά σας μπορεί να μην βρει ποτέ ανταπόκριση.
 
-Here's a handy checklist to evaluate whether a project is good for new contributors.
+Ακολουθεί ένας εύχρηστος κατάλογος ελέγχου για να αξιολογήσετε αν ένα έργο είναι κατάλληλο για νέους συνεισφέροντες.
 
 **Meets the definition of open source**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+    Έχει άδεια; Συνήθως, υπάρχει ένα αρχείο που ονομάζεται LICENSE στη ρίζα του αποθετηρίου.
   </label>
 </div>
 
-**Project actively accepts contributions**
+**Το έργο δέχεται ενεργά συνεισφορές**
 
-Look at the commit activity on the main branch. On GitHub, you can see this information on a repository's homepage.
+Κοιτάξτε τη δραστηριότητα των δεσμεύσεων στον κύριο κλάδο. Στο GitHub, μπορείτε να δείτε αυτές τις πληροφορίες στην αρχική σελίδα ενός αποθετηρίου.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-  When was the latest commit?
+  Πότε έγινε το τελευταίο commit;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-  How many contributors does the project have?
+  Πόσους συνεισφέροντες έχει το πρότζεκτ;
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  Πόσο συχνά κάνει commit ο κόσμος; (Στο GitHub, μπορείτε να βρείτε αυτή την πληροφορία κάνοντας κλίκ στο "Commits" στην επάνω μπάρα.)
   </label>
 </div>
 
-Next, look at the project's issues.
+Στη συνέχεια, εξετάστε τα ζητήματα του πρότζεκτ.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    How many open issues are there?
+    Πόσα ζητήματα υπάρχουν;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to issues when they are opened?
+    Ανταποκρίνονται οι συντηρητές γρήγορα στα θέματα που ανοίγουν;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the issues?
+     Υπάρχει ενεργή συζήτηση επί των θεμάτων;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-    Are the issues recent?
+    Είναι τα θέματα πρόσφατα;
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+     Κλείνουν τα θέματα; (Στο GitHub, κάντε κλικ στην καρτέλα "closed" στη σελίδα Issues για να δείτε τα κλειστά ζητήματα.
   </label>
 </div>
 
-Now do the same for the project's pull requests.
+Τώρα κάντε το ίδιο για τις αιτήσεις έλξης του έργου.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    How many open pull requests are there?
+     Πόσες ανοιχτές αιτήσεις έλξης υπάρχουν;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox20" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to pull requests when they are opened?
+     Οι συντηρητές ανταποκρίνονται γρήγορα στις αιτήσεις έλξης όταν ανοίγουν;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the pull requests?
+      Υπάρχει ενεργή συζήτηση σχετικά με τα pull requests;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    Are the pull requests recent?
+     Είναι πρόσφατες οι αιτήσεις έλξης;
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox13" class="overflow-hidden d-block text-normal">
-    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+     Πόσο πρόσφατα συγχωνεύτηκαν κάποια pull requests; (Στο GitHub, κάντε κλικ στην καρτέλα "closed" στη σελίδα Pull Requests για να δείτε τα κλειστά PRs.)
   </label>
 </div>
 
-**Project is welcoming**
+**Το έργο είναι φιλόξενο**
 
-A project that is friendly and welcoming signals that they will be receptive to new contributors.
+Ένα έργο που είναι φιλικό και φιλόξενο σηματοδοτεί ότι θα είναι δεκτικό σε νέους συνεισφέροντες.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox14" class="overflow-hidden d-block text-normal">
-    Do the maintainers respond helpfully to questions in issues?
+     Ανταποκρίνονται οι συντηρητές βοηθητικά στις ερωτήσεις στα θέματα;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox15" class="overflow-hidden d-block text-normal">
-    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+     Είναι οι άνθρωποι φιλικοί στα θέματα, στο φόρουμ συζητήσεων και στη συνομιλία (για παράδειγμα, στο IRC ή στο Slack);
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox16" class="overflow-hidden d-block text-normal">
-    Do pull requests get reviewed?
+     Επανεξετάζονται τα pull requests;
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox17" class="overflow-hidden d-block text-normal">
-    Do maintainers thank people for their contributions?
+     Οι συντηρητές ευχαριστούν τους ανθρώπους για τις συνεισφορές τους;
   </label>
 </div>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-  Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+   Κάθε φορά που βλέπετε ένα μακρύ νήμα, ελέγξτε επιτόπου τις απαντήσεις από τους προγραμματιστές του πυρήνα που έρχονται αργά στο νήμα. Συνοψίζουν εποικοδομητικά και λαμβάνουν μέτρα για να οδηγήσουν το νήμα σε μια απόφαση παραμένοντας ευγενικοί; Αν βλέπετε να γίνονται πολλοί πόλεμοι φλογών, αυτό είναι συχνά σημάδι ότι η ενέργεια πηγαίνει σε επιχειρήματα αντί για την ανάπτυξη.
   <p markdown="1" class="pquote-credit">
 — @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
   </p>
 </aside>
 
-## How to submit a contribution
+## Πώς να υποβάλετε μια συνεισφορά
 
-You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+Βρήκατε ένα έργο που σας αρέσει και είστε έτοιμοι να συνεισφέρετε. Επιτέλους! Εδώ θα δείτε πώς θα στείλετε τη συνεισφορά σας με τον σωστό τρόπο.
 
-### Communicating effectively
+### Αποτελεσματική επικοινωνία
 
-Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+Είτε συνεισφέρετε μια φορά είτε προσπαθείτε να ενταχθείτε σε μια κοινότητα, η συνεργασία με άλλους είναι μια από τις σημαντικότερες δεξιότητες που θα αναπτύξετε στον ανοιχτό κώδικα.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
-  \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+  \[Ως νέος συνεισφέρων,\] γρήγορα συνειδητοποίησα ότι έπρεπε να κάνω ερωτήσεις αν ήθελα να μπορέσω να κλείσω το θέμα. Ξεφύλλισα τη βάση κώδικα. Μόλις κατάλαβα τι συνέβαινε, ζήτησα περισσότερες οδηγίες. Και ιδού! Μπόρεσα να λύσω το ζήτημα αφού πήρα όλες τις σχετικές λεπτομέρειες που χρειαζόμουν.
   <p markdown="1" class="pquote-credit">
-— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+- @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
   </p>
 </aside>
 
-Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+Προτού ανοίξετε ένα θέμα ή ένα pull request ή κάνετε μια ερώτηση στη συνομιλία, έχετε υπόψη σας αυτά τα σημεία για να βοηθήσετε τις ιδέες σας να περάσουν αποτελεσματικά.
 
-**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+**Δώστε πλαίσιο.** Βοηθήστε τους άλλους να ενημερωθούν γρήγορα. Αν αντιμετωπίζετε ένα σφάλμα, εξηγήστε τι προσπαθείτε να κάνετε και πώς να το αναπαράγετε. Αν προτείνετε μια νέα ιδέα, εξηγήστε γιατί πιστεύετε ότι θα ήταν χρήσιμη για το έργο (όχι μόνο για εσάς!).
 
-> 😇 _"X doesn't happen when I do Y"_
+> 😇 _"Το Χ δεν συμβαίνει όταν κάνω το Υ"_
 >
-> 😢 _"X is broken! Please fix it."_
+> 😢 _"Το X είναι χαλασμένο! Σε παρακαλώ, διόρθωσέ το."_
 
-**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn.
+**Κάντε την έρευνα σας εκ των προτέρων.** Δεν πειράζει να μην ξέρετε πράγματα, αλλά δείξτε ότι προσπαθήσατε. Πριν ζητήσετε βοήθεια, φροντίστε να ελέγξετε το README ενός έργου, την τεκμηρίωση, τα θέματα (ανοικτά ή κλειστά), τη λίστα αλληλογραφίας και να ψάξετε στο διαδίκτυο για μια απάντηση. Οι άνθρωποι θα το εκτιμήσουν όταν δείχνετε ότι προσπαθείτε να μάθετε.
 
-> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+> 😇 _"Δεν είμαι σίγουρος πώς να υλοποιήσω το X. Έλεγξα τα έγγραφα βοήθειας και δεν βρήκα καμία αναφορά."_
 >
-> 😢 _"How do I X?"_
+> 😢 _"Πώς μπορώ να κάνω το X;"_
 
-**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+**Κρατήστε τα αιτήματα σύντομα και άμεσα.** Όπως και με την αποστολή ενός email, κάθε συνεισφορά, όσο απλή ή χρήσιμη κι αν είναι, απαιτεί την εξέταση κάποιου άλλου. Πολλά έργα έχουν περισσότερα εισερχόμενα αιτήματα από άτομα που είναι διαθέσιμα να βοηθήσουν. Να είστε συνοπτικοί. Θα αυξήσετε την πιθανότητα να μπορέσει κάποιος να σας βοηθήσει.
 
-> 😇 _"I'd like to write an API tutorial."_
+> 😇 _"Θα ήθελα να γράψω ένα tutorial για API."_
 >
-> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+> 😢 _"Οδηγούσα στον αυτοκινητόδρομο τις προάλλες και σταμάτησα για βενζίνη, και τότε μου ήρθε αυτή η καταπληκτική ιδέα για κάτι που πρέπει να κάνουμε, αλλά πριν σας το εξηγήσω, επιτρέψτε μου να σας δείξω..."_
 
-**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+**Κρατήστε όλη την επικοινωνία δημόσια.** Αν και είναι δελεαστικό, μην επικοινωνείτε με τους συντηρητές ιδιωτικά, εκτός αν πρέπει να μοιραστείτε ευαίσθητες πληροφορίες (όπως ένα ζήτημα ασφάλειας ή μια σοβαρή παραβίαση συμπεριφοράς). Όταν κρατάτε τη συζήτηση δημόσια, περισσότεροι άνθρωποι μπορούν να μάθουν και να επωφεληθούν από την ανταλλαγή σας. Οι συζητήσεις μπορούν να είναι, από μόνες τους, συνεισφορές.
 
-> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+> 😇 _(ως σχόλιο) "@-maintainer Γεια σας! Πώς θα πρέπει να προχωρήσουμε σε αυτή τη δημοσιότητα;"_
 >
-> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+> 😢 _(ως email) "Γεια σου, συγγνώμη που σε ενοχλώ μέσω email, αλλά αναρωτιόμουν αν είχες την ευκαιρία να αναθεωρήσεις το PR μου"_
 
-**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+**Δεν πειράζει να κάνετε ερωτήσεις (αλλά να είστε υπομονετικοί!).** Όλοι ήταν νέοι στο έργο κάποια στιγμή, και ακόμη και οι έμπειροι συνεισφέροντες πρέπει να ενημερωθούν όταν βλέπουν ένα νέο έργο. Με την ίδια λογική, ακόμη και οι μακροχρόνιοι συντηρητές δεν είναι πάντα εξοικειωμένοι με κάθε μέρος του έργου. Δείξτε τους την ίδια υπομονή που θα θέλατε να δείξουν και αυτοί σε εσάς.
 
-> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+> 😇 _"Ευχαριστώ που εξετάσατε αυτό το σφάλμα. Ακολούθησα τις προτάσεις σας. Εδώ είναι η έξοδος."_
 >
-> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+> 😢 _"Γιατί δεν μπορείτε να διορθώσετε το πρόβλημά μου; Αυτό δεν είναι το έργο σας;"_
 
-**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+**Σεβαστείτε τις αποφάσεις της κοινότητας.** Οι ιδέες σας μπορεί να διαφέρουν από τις προτεραιότητες ή το όραμα της κοινότητας. Μπορεί να προσφέρουν ανατροφοδότηση ή να αποφασίσουν να μην ακολουθήσουν την ιδέα σας. Ενώ θα πρέπει να συζητάτε και να αναζητάτε συμβιβασμούς, οι συντηρητές πρέπει να ζουν με την απόφασή σας περισσότερο από ό,τι εσείς. Αν διαφωνείτε με την κατεύθυνσή τους, μπορείτε πάντα να δουλέψετε πάνω στο δικό σας fork ή να ξεκινήσετε το δικό σας έργο.
 
-> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+> 😇 _"Απογοητεύομαι που δεν μπορείτε να υποστηρίξετε την περίπτωση χρήσης μου, αλλά όπως εξηγήσατε επηρεάζει μόνο ένα μικρό μέρος των χρηστών, καταλαβαίνω γιατί. Ευχαριστώ που με ακούσατε."_
 >
-> 😢 _"Why won't you support my use case? This is unacceptable!"_
+> 😢 _"Γιατί δεν υποστηρίζετε την περίπτωση χρήσης μου; Αυτό είναι απαράδεκτο!"_
 
-**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+**Πάνω απ' όλα, κρατήστε το κομψό.** Ο ανοικτός κώδικας αποτελείται από συνεργάτες από όλο τον κόσμο. Τα συμφραζόμενα χάνονται μεταξύ γλωσσών, πολιτισμών, γεωγραφικών περιοχών και ζωνών ώρας. Επιπλέον, η γραπτή επικοινωνία δυσκολεύει τη μετάδοση του τόνου ή της διάθεσης. Υποθέστε καλές προθέσεις σε αυτές τις συζητήσεις. Δεν πειράζει να απορρίψετε ευγενικά μια ιδέα, να ζητήσετε περισσότερα συμφραζόμενα ή να διευκρινίσετε περαιτέρω τη θέση σας. Απλά προσπαθήστε να αφήσετε το διαδίκτυο σε ένα καλύτερο μέρος από αυτό που βρήκατε.
 
-### Gathering context
+### Συγκέντρωση περιεχομένου
 
-Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+Πριν κάνετε οτιδήποτε, κάντε έναν γρήγορο έλεγχο για να βεβαιωθείτε ότι η ιδέα σας δεν έχει συζητηθεί αλλού. Ξεφυλλίστε το README του έργου, τα θέματα (ανοικτά και κλειστά), τη λίστα αλληλογραφίας και το Stack Overflow. Δεν χρειάζεται να ξοδέψετε ώρες για να ψάξετε τα πάντα, αλλά μια γρήγορη αναζήτηση για μερικούς όρους-κλειδιά θα σας βοηθήσει πολύ.
 
-If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request:
+Αν δεν μπορείτε να βρείτε την ιδέα σας αλλού, είστε έτοιμοι να κάνετε μια κίνηση. Αν το έργο βρίσκεται στο GitHub, πιθανότατα θα επικοινωνήσετε ανοίγοντας ένα ζήτημα ή ένα pull request:
 
-* **Issues** are like starting a conversation or discussion
-* **Pull requests** are for starting work on a solution
-* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one
+* **Τα θέματα** είναι σαν να ξεκινάτε μια συζήτηση ή μια συζήτηση
+* **Αιτήματα μετακίνησης** είναι για την έναρξη της εργασίας πάνω σε μια λύση
+* **Για ελαφριά επικοινωνία**, όπως μια διευκρινιστική ερώτηση ή μια ερώτηση για το πώς να κάνετε, δοκιμάστε να ρωτήσετε στο Stack Overflow, στο IRC, στο Slack ή σε άλλα κανάλια συνομιλίας, αν το έργο διαθέτει τέτοιο κανάλι.
 
-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.
+Πριν ανοίξετε ένα θέμα ή ένα αίτημα έλξης, ελέγξτε τα έγγραφα συνεισφοράς του έργου (συνήθως ένα αρχείο που ονομάζεται ΣΥΝΔΡΟΜΗ ή στο README), για να δείτε αν πρέπει να συμπεριλάβετε κάτι συγκεκριμένο. Για παράδειγμα, μπορεί να σας ζητούν να ακολουθήσετε ένα πρότυπο ή να απαιτείται η χρήση δοκιμών.
 
-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.
+Αν θέλετε να κάνετε μια ουσιαστική συνεισφορά, ανοίξτε ένα θέμα για να ρωτήσετε πριν εργαστείτε πάνω σε αυτό. Είναι χρήσιμο να παρακολουθείτε το έργο για λίγο (στο GitHub, [μπορείτε να κάνετε κλικ στο "Watch"](https://help.github.com/articles/watching-repositories/) για να ενημερώνεστε για όλες τις συζητήσεις), και να γνωρίσετε τα μέλη της κοινότητας, πριν κάνετε εργασία που μπορεί να μην γίνει αποδεκτή.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -457,72 +457,72 @@ If you want to make a substantial contribution, open an issue to ask before work
   </p>
 </aside>
 
-### Opening an issue
+### Άνοιγμα ενός θέματος
 
-You should usually open an issue in the following situations:
+Συνήθως πρέπει να ανοίγετε ένα θέμα στις ακόλουθες περιπτώσεις:
 
-* Report an error you can't solve yourself
-* Discuss a high-level topic or idea (for example, community, vision or policies)
-* Propose a new feature or other project idea
+* Αναφέρετε ένα σφάλμα που δεν μπορείτε να λύσετε μόνοι σας
+* Συζητήστε ένα θέμα ή μια ιδέα υψηλού επιπέδου (για παράδειγμα, κοινότητα, όραμα ή πολιτικές)
+* Προτείνετε ένα νέο χαρακτηριστικό ή μια άλλη ιδέα έργου
 
-Tips for communicating on issues:
+Συμβουλές για την επικοινωνία σχετικά με θέματα:
 
-* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
-* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
-* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+* **Αν δείτε ένα ανοιχτό ζήτημα που θέλετε να αντιμετωπίσετε,** σχολιάστε το ζήτημα για να ενημερώσετε τους άλλους ότι ασχολείστε με αυτό. Με αυτόν τον τρόπο, οι άνθρωποι είναι λιγότερο πιθανό να αντιγράψουν τη δουλειά σας.
+* **Αν ένα θέμα έχει ανοίξει πριν από καιρό,** είναι πιθανό να αντιμετωπίζεται κάπου αλλού ή να έχει ήδη επιλυθεί, οπότε σχολιάστε για να ζητήσετε επιβεβαίωση πριν ξεκινήσετε την εργασία.
+* **Αν ανοίξατε ένα θέμα, αλλά βρήκατε την απάντηση αργότερα μόνοι σας,** σχολιάστε το θέμα για να ενημερώσετε τους άλλους και, στη συνέχεια, κλείστε το θέμα. Ακόμα και η τεκμηρίωση αυτού του αποτελέσματος αποτελεί συμβολή στο έργο.
 
-### Opening a pull request
+### Άνοιγμα ενός αιτήματος αλλαγής κειμένου
 
-You should usually open a pull request in the following situations:
+Συνήθως θα πρέπει να ανοίγετε ένα pull request στις ακόλουθες περιπτώσεις:
 
-* Submit trivial fixes (for example, a typo, a broken link or an obvious error)
-* Start work on a contribution that was already asked for, or that you've already discussed, in an issue
+* Υποβολή ασήμαντων διορθώσεων (για παράδειγμα, ένα τυπογραφικό λάθος, ένας σπασμένος σύνδεσμος ή ένα προφανές σφάλμα)
+* Ξεκινήστε να εργάζεστε σε μια συνεισφορά που σας έχει ήδη ζητηθεί, ή που έχετε ήδη συζητήσει, σε ένα θέμα
 
-A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
+Ένα pull request δεν χρειάζεται να αντιπροσωπεύει ολοκληρωμένη εργασία. Συνήθως είναι καλύτερο να ανοίξετε ένα pull request νωρίς, ώστε οι άλλοι να μπορούν να παρακολουθήσουν ή να δώσουν ανατροφοδότηση σχετικά με την πρόοδό σας. Απλά σημειώστε το ως "WIP" (Work in Progress) στη γραμμή θέματος. Μπορείτε πάντα να προσθέσετε περισσότερα commits αργότερα.
 
-If the project is on GitHub, here's how to submit a pull request:
+Αν το έργο βρίσκεται στο GitHub, δείτε πώς μπορείτε να υποβάλετε ένα 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/).)
-* **[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.
-* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
-* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+* **[Κάντε fork το πρότζεκτ](https://guides.github.com/activities/forking/)** και κλωνοποιήστε το τοπικά. Συνδέστε το τοπικό σας με το αρχικό "upstream" αποθετήριο προσθέτοντάς το ως απομακρυσμένο. Τραβήξτε συχνά αλλαγές από το "upstream" ώστε να παραμένετε ενημερωμένοι, ώστε όταν υποβάλετε το pull request σας, οι συγκρούσεις συγχώνευσης να είναι λιγότερο πιθανές. (Δείτε πιο λεπτομερείς οδηγίες [εδώ](https://help.github.com/articles/syncing-a-fork/).)
+* **[Δημιουργήστε έναν κλάδο](https://guides.github.com/introduction/flow/)** για τις επεξεργασίες σας.
+* **Αναφέρετε οποιαδήποτε σχετικά θέματα** ή υποστηρικτική τεκμηρίωση στο PR σας (για παράδειγμα, "Κλείνει το #37.")
+* **Περιλάβετε στιγμιότυπα οθόνης του πριν και του μετά** αν οι αλλαγές σας περιλαμβάνουν διαφορές στην HTML/CSS. Σύρετε και αφήστε τις εικόνες στο σώμα του αιτήματος έλξης σας.
+* **Δοκιμάστε τις αλλαγές σας!** Ελέγξτε τις αλλαγές σας με τυχόν υπάρχουσες δοκιμές, αν υπάρχουν, και δημιουργήστε νέες, όταν χρειάζεται. Είτε υπάρχουν δοκιμές είτε όχι, βεβαιωθείτε ότι οι αλλαγές σας δεν καταστρέφουν το υπάρχον έργο.
+* **Συνεισφέρετε στο ύφος του έργου** στο μέτρο των δυνατοτήτων σας. Αυτό μπορεί να σημαίνει ότι χρησιμοποιείτε εσοχές, άνω και κάτω τελεία ή σχόλια διαφορετικά από ό,τι θα κάνατε στο δικό σας αποθετήριο, αλλά διευκολύνει τον συντηρητή να συγχωνεύσει, άλλους να καταλάβουν και να συντηρήσουν στο μέλλον.
 
-If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+Αν αυτό είναι το πρώτο σας pull request, ελέγξτε το [Make a Pull Request](http://makeapullrequest.com/), το οποίο δημιούργησε ο @kentcdodds ως ένα βίντεο με οδηγίες. Μπορείτε επίσης να εξασκηθείτε στο να κάνετε ένα pull request στο αποθετήριο [First Contributions](https://github.com/Roshanjossey/first-contributions), που δημιουργήθηκε από τον @Roshanjossey.
 
-## What happens after you submit a contribution
+## Τι συμβαίνει μετά την υποβολή μιας συνεισφοράς
 
-You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
+Τα καταφέρατε! Συγχαρητήρια που γίνατε συνεργάτης ανοιχτού κώδικα. Ελπίζουμε να είναι η πρώτη από τις πολλές.
 
-After you submit a contribution, one of the following will happen:
+Αφού υποβάλετε μια συνεισφορά, θα συμβεί ένα από τα ακόλουθα:
 
-### 😭 You don't get a response.
+### 😭 Δεν λαμβάνετε απάντηση.
 
-Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+Ελπίζουμε ότι [ελέγξατε το έργο για σημάδια δραστηριότητας](#a-checklist-before-you-contribute) πριν κάνετε μια συνεισφορά. Ακόμα και σε ένα ενεργό έργο, ωστόσο, είναι πιθανό η συνεισφορά σας να μην λάβει απάντηση.
 
-If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+Αν δεν έχετε λάβει απάντηση για πάνω από μια εβδομάδα, είναι δίκαιο να απαντήσετε ευγενικά στο ίδιο θέμα, ζητώντας από κάποιον να το αξιολογήσει. Αν γνωρίζετε το όνομα του κατάλληλου ατόμου που θα αξιολογήσει τη συνεισφορά σας, μπορείτε να τον @-αναφέρετε στο ίδιο θέμα.
 
-**Don't** reach out to that person privately; remember that public communication is vital to open source projects.
+**Μην** απευθυνθείτε σε αυτό το άτομο ιδιωτικά- να θυμάστε ότι η δημόσια επικοινωνία είναι ζωτικής σημασίας για τα έργα ανοικτού κώδικα.
 
-If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+Αν κάνετε ένα ευγενικό χτύπημα και παρόλα αυτά κανείς δεν απαντήσει, είναι πιθανό ότι κανείς δεν θα απαντήσει, ποτέ. Δεν είναι ωραίο συναίσθημα, αλλά μην το αφήσετε να σας αποθαρρύνει. Έχει συμβεί σε όλους! Υπάρχουν πολλοί πιθανοί λόγοι για τους οποίους δεν πήρατε απάντηση, συμπεριλαμβανομένων προσωπικών περιστάσεων που μπορεί να είναι εκτός του ελέγχου σας. Προσπαθήστε να βρείτε ένα άλλο έργο ή έναν άλλο τρόπο να συνεισφέρετε. Αν μη τι άλλο, αυτός είναι ένας καλός λόγος για να μην επενδύσετε πολύ χρόνο στην πραγματοποίηση μιας συνεισφοράς πριν τα άλλα μέλη της κοινότητας ασχοληθούν και ανταποκριθούν.
 
-### 🚧 Someone requests changes to your contribution.
+### 🚧 Κάποιος ζητά αλλαγές στη συνεισφορά σας.
 
-It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+Είναι σύνηθες να σας ζητηθεί να κάνετε αλλαγές στη συνεισφορά σας, είτε πρόκειται για ανατροφοδότηση σχετικά με το εύρος της ιδέας σας, είτε για αλλαγές στον κώδικά σας.
 
-When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it.
+Όταν κάποιος ζητάει αλλαγές, ανταποκριθείτε. Έχουν αφιερώσει χρόνο για να εξετάσουν τη συνεισφορά σας. Το να ανοίγετε ένα PR και να φεύγετε είναι κακή συμπεριφορά. Αν δεν ξέρετε πώς να κάνετε αλλαγές, ερευνήστε το πρόβλημα και, στη συνέχεια, ζητήστε βοήθεια αν τη χρειάζεστε.
 
-If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
+Αν δεν έχετε πια χρόνο να ασχοληθείτε με το θέμα (για παράδειγμα, αν η συζήτηση διαρκεί μήνες και οι συνθήκες έχουν αλλάξει), ενημερώστε τον συντηρητή ώστε να μην περιμένει απάντηση. Κάποιος άλλος μπορεί να είναι στην ευχάριστη θέση να αναλάβει.
 
-### 👎 Your contribution doesn't get accepted.
+### 👎 Η συνεισφορά σας δεν γίνεται αποδεκτή.
 
-Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+Η συνεισφορά σας μπορεί να γίνει αποδεκτή ή να μην γίνει αποδεκτή τελικά. Ελπίζω να μην έχετε ήδη αφιερώσει πολλή δουλειά σε αυτήν. Αν δεν είστε σίγουροι γιατί δεν έγινε αποδεκτή, είναι απολύτως λογικό να ζητήσετε από τον συντηρητή ανατροφοδότηση και διευκρινίσεις. Τελικά, όμως, θα πρέπει να σεβαστείτε ότι αυτή είναι η απόφασή τους. Μην διαφωνήσετε ή γίνετε εχθρικοί. Είστε πάντα ευπρόσδεκτοι να διακλαδώσετε και να δουλέψετε στη δική σας έκδοση αν διαφωνείτε!
 
-### 🎉 Your contribution gets accepted.
+### 🎉 Η συνεισφορά σας γίνεται αποδεκτή.
 
-Hooray! You've successfully made an open source contribution!
+Ζήτω! Κάνατε με επιτυχία μια συνεισφορά σε ανοιχτό κώδικα!
 
-## You did it!
+## Τα καταφέρατε!
 
-Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
+Είτε μόλις κάνατε την πρώτη σας συνεισφορά σε ανοιχτό κώδικα, είτε ψάχνετε για νέους τρόπους συνεισφοράς, ελπίζουμε να εμπνευστείτε για να αναλάβετε δράση. Ακόμα και αν η συνεισφορά σας δεν έγινε αποδεκτή, μην ξεχνάτε να λέτε ευχαριστώ όταν ένας συντηρητής κατέβαλε προσπάθεια για να σας βοηθήσει. Ο ανοιχτός κώδικας δημιουργείται από ανθρώπους σαν εσάς: ένα θέμα, ένα αίτημα διανομής, ένα σχόλιο ή ένα "high-five" κάθε φορά.

From 3ec14e20fd2836b232f24027ae5f70efc9ed95c8 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 20 Sep 2022 11:00:09 +0300
Subject: [PATCH 376/749] translate leadership-and-governance.md

---
 _articles/el/leadership-and-governance.md | 122 +++++++++++-----------
 1 file changed, 61 insertions(+), 61 deletions(-)

diff --git a/_articles/el/leadership-and-governance.md b/_articles/el/leadership-and-governance.md
index 2171d327915..1bd1bde86f5 100644
--- a/_articles/el/leadership-and-governance.md
+++ b/_articles/el/leadership-and-governance.md
@@ -10,147 +10,147 @@ related:
   - metrics
 ---
 
-## Understanding governance for your growing project
+## Κατανόηση της διακυβέρνησης για το αναπτυσσόμενο πρότζεκτ σας
 
-Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+Το πρότζεκτ σας αναπτύσσεται, οι άνθρωποι είναι αφοσιωμένοι και είστε αποφασισμένοι να το συνεχίσετε. Σε αυτό το στάδιο, μπορεί να αναρωτιέστε πώς να ενσωματώσετε τους τακτικούς συνεργάτες του πρότζεκτ στη ροή εργασίας σας, είτε πρόκειται για την παροχή σε κάποιον πρόσβασης στη δέσμευση είτε για την επίλυση των συζητήσεων της κοινότητας. Αν έχετε απορίες, έχουμε απαντήσεις.
 
-## What are examples of formal roles used in open source projects?
+## Ποια είναι παραδείγματα επίσημων ρόλων που χρησιμοποιούνται σε πρότζεκτ ανοικτού κώδικα;
 
-Many projects follow a similar structure for contributor roles and recognition.
+Πολλά πρότζεκτ ακολουθούν μια παρόμοια δομή για τους ρόλους και την αναγνώριση των συνεισφερόντων.
 
-What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+Το τι σημαίνουν στην πραγματικότητα αυτοί οι ρόλοι, όμως, εξαρτάται αποκλειστικά από εσάς. Ακολουθούν μερικοί τύποι ρόλων που μπορεί να αναγνωρίσετε:
 
-* **Maintainer**
+* **Συντηρητής**
 * **Contributor**
 * **Committer**
 
-**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+**Για ορισμένα πρότζεκτ, οι "συντηρητές"** είναι τα μόνα άτομα σε ένα πρότζεκτ με πρόσβαση στa commits. Σε άλλα πρότζεκτ, είναι απλά τα άτομα που αναφέρονται στο README ως συντηρητές.
 
-A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+Ένας συντηρητής δεν χρειάζεται απαραίτητα να είναι κάποιος που γράφει κώδικα για το πρότζεκτ σας. Θα μπορούσε να είναι κάποιος που έχει κάνει πολλή δουλειά για να ευαγγελιστεί το πρότζεκτ σας, ή έχει γράψει τεκμηρίωση που έκανε το πρότζεκτ πιο προσιτό σε άλλους. Ανεξάρτητα από το τι κάνει καθημερινά, ένας συντηρητής είναι πιθανότατα κάποιος που αισθάνεται την ευθύνη για την κατεύθυνση του πρότζεκτ και δεσμεύεται να το βελτιώσει.
 
-**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+**Ένας "contributor" θα μπορούσε να είναι οποιοσδήποτε** που σχολιάζει ένα θέμα ή ένα pull request, άνθρωποι που προσθέτουν αξία στο πρότζεκτ (είτε πρόκειται για τη διαχείριση θεμάτων, τη συγγραφή κώδικα ή τη διοργάνωση εκδηλώσεων), ή οποιοσδήποτε με ένα συγχωνευμένο pull request (ίσως ο στενότερος ορισμός ενός contributor).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+  \[Για το Node.js,\] κάθε άτομο που εμφανίζεται για να σχολιάσει ένα θέμα ή να υποβάλει κώδικα είναι μέλος της κοινότητας ενός πρότζεκτ. Και μόνο το γεγονός ότι είναι σε θέση να τους βλέπεις σημαίνει ότι είναι πια συνεισφέροντες και όχι απλώς χρήστες.
   <p markdown="1" class="pquote-credit">
-— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+- @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
   </p>
 </aside>
 
-**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+**Ο όρος "committer"** θα μπορούσε να χρησιμοποιηθεί για να διακρίνει την πρόσβαση στα commits, η οποία είναι ένας συγκεκριμένος τύπος ευθύνης, από άλλες μορφές συνεισφοράς.
 
-While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+Ενώ μπορείτε να ορίσετε τους ρόλους του πρότζεκτ σας με όποιον τρόπο θέλετε, [εξετάστε το ενδεχόμενο να χρησιμοποιήσετε ευρύτερους ορισμούς](../how-to-contribute/#what-it-means-to-contribute) για να ενθαρρύνετε περισσότερες μορφές συνεισφοράς. Μπορείτε να χρησιμοποιήσετε τους ρόλους ηγεσίας για να αναγνωρίσετε επίσημα τους ανθρώπους που έχουν συνεισφέρει εξαιρετικά στο πρότζεκτ σας, ανεξάρτητα από τις τεχνικές τους δεξιότητες.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
-  You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+  Μπορεί να με ξέρετε ως τον "εφευρέτη" του Django... αλλά στην πραγματικότητα είμαι ο τύπος που προσλήφθηκε για να δουλέψει πάνω σε ένα πράγμα ένα χρόνο αφότου είχε ήδη φτιαχτεί. (...) Οι άνθρωποι υποψιάζονται ότι είμαι επιτυχημένος λόγω των προγραμματιστικών μου ικανοτήτων... αλλά είμαι στην καλύτερη περίπτωση ένας μέτριος προγραμματιστής.
   <p markdown="1" class="pquote-credit">
-— @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+- @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
   </p>
 </aside>
 
-## How do I formalize these leadership roles?
+## Πώς μπορώ να επισημοποιήσω αυτούς τους ηγετικούς ρόλους;
 
-Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+Η επισημοποίηση των ηγετικών σας ρόλων βοηθάει τους ανθρώπους να αισθάνονται ιδιοκτησία και λέει στα άλλα μέλη της κοινότητας σε ποιον να απευθυνθούν για βοήθεια.
 
-For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+Για ένα μικρότερο πρότζεκτ, ο ορισμός των ηγετών μπορεί να είναι τόσο απλός όσο η προσθήκη των ονομάτων τους στο README ή σε ένα αρχείο κειμένου CONTRIBUTORS.
 
-For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+Για ένα μεγαλύτερο πρότζεκτ, αν έχετε έναν ιστότοπο, δημιουργήστε μια σελίδα ομάδας ή αναφέρετε εκεί τους επικεφαλής του πρότζεκτ σας. Για παράδειγμα, το [Postgres](https://github.com/postgres/postgres/) έχει μια [ολοκληρωμένη σελίδα ομάδας](https://www.postgresql.org/community/contributors/) με σύντομα προφίλ για κάθε συνεισφέροντα.
 
-If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+Εάν το πρότζεκτ σας έχει μια πολύ ενεργή κοινότητα συνεισφερόντων, μπορείτε να δημιουργήσετε μια "βασική ομάδα" συντηρητών ή ακόμη και υποεπιτροπές ατόμων που αναλαμβάνουν την ευθύνη για διαφορετικούς τομείς θεμάτων (για παράδειγμα, ασφάλεια, διαχείριση θεμάτων ή συμπεριφορά της κοινότητας). Αφήστε τους ανθρώπους να αυτοοργανωθούν και να αναλάβουν εθελοντικά τους ρόλους που τους ενθουσιάζουν περισσότερο, αντί να τους αναθέσετε.
 
 <aside markdown="1" class="pquote">
-  \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+  \[Εμείς\] συμπληρώνουμε τη βασική ομάδα με διάφορες "υποομάδες". Κάθε υποομάδα επικεντρώνεται σε έναν συγκεκριμένο τομέα, π.χ. στο σχεδιασμό γλωσσών ή στις βιβλιοθήκες. (...) Για να εξασφαλιστεί ο συνολικός συντονισμός και ένα ισχυρό, συνεκτικό όραμα για το πρότζεκτ ως σύνολο, κάθε υποομάδα καθοδηγείται από ένα μέλος της βασικής ομάδας.
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+- ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+Οι ηγετικές ομάδες μπορεί να θέλουν να δημιουργήσουν ένα καθορισμένο κανάλι (όπως στο IRC) ή να συναντώνται τακτικά για να συζητούν το πρότζεκτ (όπως στο Gitter ή στο Google Hangout). Μπορείτε ακόμη και να κάνετε αυτές τις συναντήσεις δημόσιες ώστε να μπορούν να τις ακούνε και άλλοι. Το [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), για παράδειγμα, [φιλοξενεί ώρες γραφείου κάθε εβδομάδα](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
-Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+Αφού καθιερώσετε ηγετικούς ρόλους, μην ξεχάσετε να τεκμηριώσετε πώς οι άνθρωποι μπορούν να τους αποκτήσουν! Καθορίστε μια σαφή διαδικασία για το πώς κάποιος μπορεί να γίνει συντηρητής ή να ενταχθεί σε μια υποεπιτροπή του πρότζεκτ σας και γράψτε την στο GOVERNANCE.md.
 
-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.
+Εργαλεία όπως το [Vossibility](https://github.com/icecrime/vossibility-stack) μπορούν να σας βοηθήσουν να παρακολουθείτε δημόσια ποιος συνεισφέρει (ή δεν συνεισφέρει) στο πρότζεκτ. Η τεκμηρίωση αυτών των πληροφοριών αποφεύγει την αντίληψη της κοινότητας ότι οι συντηρητές είναι μια κλίκα που παίρνει τις αποφάσεις της ιδιωτικά.
 
-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/#μοιραστείτε-την-ιδιοκτησία-του-πρότζεκτ-σας).
+Τέλος, αν το πρότζεκτ σας βρίσκεται στο GitHub, εξετάστε το ενδεχόμενο να μεταφέρετε το πρότζεκτ σας από τον προσωπικό σας λογαριασμό σε έναν Οργανισμό και να προσθέσετε τουλάχιστον έναν εφεδρικό διαχειριστή. Οι [Οργανισμοί του GitHub](https://help.github.com/articles/creating-a-new-organization-account/) διευκολύνουν τη διαχείριση των δικαιωμάτων και των πολλαπλών αποθετηρίων και προστατεύουν την κληρονομιά του πρότζεκτ σας μέσω της [κοινής ιδιοκτησίας](../building-community/#μοιραστείτε-την-ιδιοκτησία-του-πρότζεκτ-σας).
 
-## When should I give someone commit access?
+## Πότε θα πρέπει να δώσω σε κάποιον πρόσβαση στα commits;
 
-Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+Κάποιοι πιστεύουν ότι πρέπει να δίνετε πρόσβαση στα commits σε όλους όσους συνεισφέρουν. Κάτι τέτοιο θα μπορούσε να ενθαρρύνει περισσότερους ανθρώπους να νιώσουν ιδιοκτησία του πρότζεκτ σας.
 
-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.
+Αν το πρότζεκτ σας βρίσκεται στο GitHub, μπορείτε να χρησιμοποιήσετε το [protected branches](https://help.github.com/articles/about-protected-branches/) για να διαχειριστείτε ποιος μπορεί να προωθήσει σε ένα συγκεκριμένο κλάδο και υπό ποιες συνθήκες.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
-  Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+  Κάθε φορά που κάποιος σας στέλνει ένα pull request, δώστε του πρόσβαση στα commits στο πρότζεκτ σας. Αν και μπορεί να ακούγεται απίστευτα ανόητο στην αρχή, η χρήση αυτής της στρατηγικής θα σας επιτρέψει να απελευθερώσετε την πραγματική δύναμη του GitHub. (...) Μόλις οι άνθρωποι έχουν πρόσβαση στα commits, δεν ανησυχούν πλέον ότι η διόρθωσή τους μπορεί να μην ενσωματωθεί... με αποτέλεσμα να βάλουν πολύ περισσότερη δουλειά σε αυτήν.
   <p markdown="1" class="pquote-credit">
-— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+- @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
   </p>
 </aside>
 
-## What are some of the common governance structures for open source projects?
+## Ποιες είναι μερικές από τις συνήθεις δομές διακυβέρνησης για πρότζεκτ ανοικτού κώδικα;
 
-There are three common governance structures associated with open source projects.
+Υπάρχουν τρεις κοινές δομές διακυβέρνησης που σχετίζονται με πρότζεκτ ανοικτού κώδικα.
 
-* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+* **BDFL:** Το BDFL σημαίνει "καλοπροαίρετος δικτάτορας για όλη τη ζωή" (Benevolent Dictator For Life). Σύμφωνα με αυτή τη δομή, ένα άτομο (συνήθως ο αρχικός ιδιοκτήτης του πρότζεκτ) έχει τον τελικό λόγο σε όλες τις σημαντικές αποφάσεις του πρότζεκτ. Η [Python](https://github.com/python) είναι ένα κλασικό παράδειγμα. Τα μικρότερα πρότζεκτ είναι πιθανώς εξ ορισμού BDFL, επειδή υπάρχουν μόνο ένας ή δύο συντηρητές. Ένα πρότζεκτ που προέρχεται από μια εταιρεία μπορεί επίσης να εμπίπτει στην κατηγορία BDFL.
 
-* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+* **Μεριτοκρατία:** **(Σημείωση: ο όρος "αξιοκρατία" έχει αρνητική χροιά για ορισμένες κοινότητες και έχει μια [πολύπλοκη κοινωνική και πολιτική ιστορία](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Στο πλαίσιο μιας αξιοκρατίας, στους ενεργούς συνεισφέροντες στο πρότζεκτ (αυτούς που επιδεικνύουν "αξία") δίνεται επίσημος ρόλος στη λήψη αποφάσεων. Οι αποφάσεις λαμβάνονται συνήθως με βάση την καθαρή συναίνεση της ψηφοφορίας. Η έννοια της αξιοκρατίας πρωτοπορήθηκε από το [Apache Foundation](https://www.apache.org/)- [όλα τα πρότζεκτ του Apache](https://www.apache.org/index.html#projects-list) είναι αξιοκρατίες. Οι συνεισφορές μπορούν να γίνουν μόνο από άτομα που εκπροσωπούν τον εαυτό τους, όχι από μια εταιρεία.
 
-* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
+* **Φιλελεύθερη συνεισφορά:** Σύμφωνα με το μοντέλο της φιλελεύθερης συνεισφοράς, τα άτομα που κάνουν τη μεγαλύτερη δουλειά αναγνωρίζονται ως τα άτομα με τη μεγαλύτερη επιρροή, αλλά αυτό βασίζεται στην τρέχουσα δουλειά και όχι στις ιστορικές συνεισφορές. Οι σημαντικές αποφάσεις για το πρότζεκτ λαμβάνονται με βάση μια διαδικασία αναζήτησης συναίνεσης (συζήτηση των σημαντικότερων παραπόνων) και όχι με καθαρή ψηφοφορία, και επιδιώκεται να συμπεριληφθούν όσο το δυνατόν περισσότερες προοπτικές της κοινότητας. Δημοφιλή παραδείγματα πρότζεκτ που χρησιμοποιούν ένα φιλελεύθερο μοντέλο συνεισφοράς περιλαμβάνουν το [Node.js](https://foundation.nodejs.org/) και το [Rust](https://www.rust-lang.org/).
 
-Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+Ποιο από τα δύο πρέπει να χρησιμοποιήσετε; Εξαρτάται από εσάς! Κάθε μοντέλο έχει πλεονεκτήματα και συμβιβασμούς. Και παρόλο που μπορεί να φαίνονται αρκετά διαφορετικά στην αρχή, και τα τρία μοντέλα έχουν περισσότερα κοινά απ' όσα φαίνονται. Αν ενδιαφέρεστε να υιοθετήσετε ένα από αυτά τα μοντέλα, δείτε αυτά τα πρότυπα:
 
-* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
-* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
-* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+* [Πρότυπο μοντέλου BDFL](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Πρότυπο μοντέλου αξιοκρατίας](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Η φιλελεύθερη πολιτική συνεισφοράς του Node.js](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
 
-## Do I need governance docs when I launch my project?
+## Χρειάζομαι έγγραφα διακυβέρνησης όταν ξεκινάω το πρότζεκτ μου;
 
-There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+Δεν υπάρχει σωστή στιγμή για να καταγράψετε τη διακυβέρνηση του πρότζεκτ σας, αλλά είναι πολύ πιο εύκολο να την ορίσετε μόλις δείτε τη δυναμική της κοινότητάς σας να εξελίσσεται. Το καλύτερο (και δυσκολότερο) μέρος της διακυβέρνησης του ανοιχτού κώδικα είναι ότι διαμορφώνεται από την κοινότητα!
 
-Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+Ωστόσο, κάποια πρώιμη τεκμηρίωση θα συμβάλει αναπόφευκτα στη διακυβέρνηση του πρότζεκτ σας, οπότε αρχίστε να γράφετε ό,τι μπορείτε. Για παράδειγμα, μπορείτε να ορίσετε σαφείς προσδοκίες για τη συμπεριφορά ή τον τρόπο λειτουργίας της διαδικασίας συνεισφοράς σας, ακόμη και κατά την έναρξη του πρότζεκτ σας.
 
-If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
+Αν ανήκετε σε μια εταιρεία που εγκαινιάζει ένα πρότζεκτ ανοιχτού κώδικα, αξίζει να κάνετε μια εσωτερική συζήτηση πριν από την έναρξη σχετικά με το πώς η εταιρεία σας αναμένει να συντηρεί και να λαμβάνει αποφάσεις σχετικά με το πρότζεκτ που προχωράει. Μπορεί επίσης να θέλετε να εξηγήσετε δημόσια οτιδήποτε ιδιαίτερο σχετικά με τον τρόπο με τον οποίο η εταιρεία σας θα συμμετέχει (ή δεν θα συμμετέχει!) στο πρότζεκτ.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
-  We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+  Αναθέτουμε τη διαχείριση πρότζεκτ στο GitHub σε μικρές ομάδες που εργάζονται πραγματικά σε αυτά στο Facebook. Για παράδειγμα, το React διευθύνεται από έναν μηχανικό του React.
   <p markdown="1" class="pquote-credit">
-— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+- @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
   </p>
 </aside>
 
-## What happens if corporate employees start submitting contributions?
+## Τι θα συμβεί αν οι εταιρικοί υπάλληλοι αρχίσουν να υποβάλλουν συνεισφορές;
 
-Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+Τα επιτυχημένα πρότζεκτ ανοικτού κώδικα χρησιμοποιούνται από πολλούς ανθρώπους και εταιρείες, και ορισμένες εταιρείες μπορεί τελικά να έχουν ροές εσόδων που συνδέονται τελικά με το πρότζεκτ. Για παράδειγμα, μια εταιρεία μπορεί να χρησιμοποιήσει τον κώδικα του πρότζεκτ ως ένα συστατικό στοιχείο σε μια εμπορική προσφορά υπηρεσιών.
 
-As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+Καθώς το πρότζεκτ χρησιμοποιείται ευρύτερα, οι άνθρωποι που έχουν εμπειρία σε αυτό γίνονται πιο περιζήτητοι - ίσως είστε ένας από αυτούς! - και μερικές φορές θα πληρώνονται για τη δουλειά που κάνουν στο πρότζεκτ.
 
-It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+Είναι σημαντικό να αντιμετωπίζετε την εμπορική δραστηριότητα ως φυσιολογική και ως μια ακόμη πηγή ενέργειας ανάπτυξης. Φυσικά, οι αμειβόμενοι προγραμματιστές δεν πρέπει να τυγχάνουν ιδιαίτερης μεταχείρισης σε σχέση με τους μη αμειβόμενους- κάθε συνεισφορά πρέπει να αξιολογείται με βάση την τεχνική της αξία. Ωστόσο, οι άνθρωποι θα πρέπει να αισθάνονται άνετα να συμμετέχουν σε εμπορική δραστηριότητα και να αισθάνονται άνετα να αναφέρουν τις περιπτώσεις χρήσης τους όταν επιχειρηματολογούν υπέρ μιας συγκεκριμένης βελτίωσης ή λειτουργίας.
 
-"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+Το "εμπορικό" είναι απολύτως συμβατό με το "ανοιχτό κώδικα". "Εμπορικό" σημαίνει απλώς ότι κάπου εμπλέκονται χρήματα - ότι το λογισμικό χρησιμοποιείται στο εμπόριο, κάτι που είναι όλο και πιο πιθανό καθώς ένα πρότζεκτ κερδίζει την αποδοχή του. (Όταν το λογισμικό ανοικτού κώδικα χρησιμοποιείται ως μέρος ενός προϊόντος μη ανοικτού κώδικα, το συνολικό προϊόν εξακολουθεί να είναι "ιδιόκτητο" λογισμικό, αν και, όπως και ο ανοικτός κώδικας, μπορεί να χρησιμοποιηθεί για εμπορικούς ή μη εμπορικούς σκοπούς).
 
-Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+Όπως όλοι οι άλλοι, οι προγραμματιστές με εμπορικά κίνητρα αποκτούν επιρροή στο πρότζεκτ μέσω της ποιότητας και της ποσότητας των συνεισφορών τους. Προφανώς, ένας προγραμματιστής που πληρώνεται για το χρόνο του μπορεί να είναι σε θέση να κάνει περισσότερα από κάποιον που δεν πληρώνεται, αλλά αυτό δεν πειράζει: η πληρωμή είναι απλώς ένας από τους πολλούς πιθανούς παράγοντες που θα μπορούσαν να επηρεάσουν το πόσο κάνει κάποιος. Κρατήστε τις συζητήσεις σας για το πρότζεκτ επικεντρωμένες στις συνεισφορές και όχι στους εξωτερικούς παράγοντες που επιτρέπουν στους ανθρώπους να κάνουν αυτές τις συνεισφορές.
 
-## Do I need a legal entity to support my project?
+## Χρειάζομαι μια νομική οντότητα για να υποστηρίξω το πρότζεκτ μου;
 
-You don't need a legal entity to support your open source project unless you're handling money.
+Δεν χρειάζεστε μια νομική οντότητα για την υποστήριξη του πρότζεκτ σας ανοικτού κώδικα, εκτός αν διαχειρίζεστε χρήματα.
 
-For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+Για παράδειγμα, αν θέλετε να δημιουργήσετε μια εμπορική επιχείρηση, θα πρέπει να δημιουργήσετε μια C Corp ή LLC (αν έχετε την έδρα σας στις ΗΠΑ). Αν απλά κάνετε εργασίες συμβολαίου που σχετίζονται με το πρότζεκτ σας ανοικτού κώδικα, μπορείτε να δεχτείτε χρήματα ως ατομική επιχείρηση ή να δημιουργήσετε μια LLC (αν έχετε την έδρα σας στις ΗΠΑ).
 
-If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+Αν θέλετε να δέχεστε δωρεές για το ανοικτού κώδικα πρότζεκτ σας, μπορείτε να δημιουργήσετε ένα κουμπί δωρεάς (χρησιμοποιώντας το PayPal ή το Stripe, για παράδειγμα), αλλά τα χρήματα δεν θα εκπίπτουν από τη φορολογία, εκτός αν είστε αναγνωρισμένος μη κερδοσκοπικός οργανισμός (501c3, αν είστε στις ΗΠΑ).
 
-Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+Πολλά πρότζεκτ δεν επιθυμούν να μπουν στον κόπο να δημιουργήσουν έναν μη κερδοσκοπικό οργανισμό, οπότε βρίσκουν έναν μη κερδοσκοπικό φορολογικό χορηγό. Ένας φορολογικός χορηγός δέχεται δωρεές εκ μέρους σας, συνήθως με αντάλλαγμα ένα ποσοστό της δωρεάς. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) και [Open Collective](https://opencollective.com/opensource) είναι παραδείγματα οργανισμών που λειτουργούν ως φορολογικοί χορηγοί για πρότζεκτ ανοικτού κώδικα.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
-  Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+  Στόχος μας είναι να παρέχουμε μια υποδομή που οι κοινότητες μπορούν να χρησιμοποιήσουν για να είναι αυτοσυντηρούμενες, δημιουργώντας έτσι ένα περιβάλλον όπου όλοι - συνεισφέροντες, υποστηρικτές, χορηγοί - θα έχουν συγκεκριμένα οφέλη.
   <p markdown="1" class="pquote-credit">
-— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+- @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
   </p>
 </aside>
 
-If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
+Εάν το πρότζεκτ σας συνδέεται στενά με μια συγκεκριμένη γλώσσα ή οικοσύστημα, μπορεί επίσης να υπάρχει ένα σχετικό ίδρυμα λογισμικού με το οποίο μπορείτε να συνεργαστείτε. Για παράδειγμα, το [Python Software Foundation](https://www.python.org/psf/) βοηθά στην υποστήριξη του [PyPI](https://pypi.org/), του διαχειριστή πακέτων Python, και το [Node.js Foundation](https://foundation.nodejs.org/) βοηθά στην υποστήριξη του [Express.js](https://expressjs.com/), ενός πλαισίου βασισμένου στο Node.

From 536e9fb56498405a69d09ab3df8e489522e5735f Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 20 Sep 2022 11:37:49 +0300
Subject: [PATCH 377/749] Translate legal.md

---
 _articles/el/legal.md | 140 +++++++++++++++++++++---------------------
 1 file changed, 70 insertions(+), 70 deletions(-)

diff --git a/_articles/el/legal.md b/_articles/el/legal.md
index 7c7e700c560..01042fbdf58 100644
--- a/_articles/el/legal.md
+++ b/_articles/el/legal.md
@@ -10,149 +10,149 @@ related:
   - leadership
 ---
 
-## Understanding the legal implications of open source
+## Κατανόηση των νομικών επιπτώσεων του ανοικτού κώδικα
 
-Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+Το να μοιραστείτε το δημιουργικό σας πρότζεκτ με τον κόσμο μπορεί να είναι μια συναρπαστική και ικανοποιητική εμπειρία. Μπορεί επίσης να σημαίνει ένα σωρό νομικά πράγματα για τα οποία δεν γνωρίζατε ότι έπρεπε να ανησυχείτε. Ευτυχώς, δεν χρειάζεται να ξεκινήσετε από το μηδέν. Έχουμε καλύψει τις νομικές σας ανάγκες. (Πριν ξεκινήσετε, φροντίστε να διαβάσετε την [αποποίηση ευθυνών](/notices/) μας).
 
-## Why do people care so much about the legal side of open source?
+## Γιατί οι άνθρωποι ενδιαφέρονται τόσο πολύ για τη νομική πλευρά του ανοιχτού κώδικα;
 
-Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+Χαίρομαι που ρωτάτε! Όταν δημιουργείτε ένα δημιουργικό πρότζεκτ (όπως συγγραφή, γραφικά ή κώδικα), το πρότζεκτ αυτό υπόκειται εξ ορισμού σε αποκλειστικά πνευματικά δικαιώματα. Δηλαδή, ο νόμος υποθέτει ότι ως δημιουργός του πρότζεκτ σας, έχετε λόγο στο τι μπορούν να κάνουν οι άλλοι με αυτό.
 
-In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+Σε γενικές γραμμές, αυτό σημαίνει ότι κανένας άλλος δεν μπορεί να χρησιμοποιήσει, να αντιγράψει, να διανείμει ή να τροποποιήσει το πρότζεκτ σας χωρίς να κινδυνεύει από αποκοπές, εκβιασμούς ή δικαστικές διενέξεις.
 
-Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+Ωστόσο, ο ανοικτός κώδικας αποτελεί μια ασυνήθιστη περίπτωση, επειδή ο συγγραφέας αναμένει ότι άλλοι θα χρησιμοποιήσουν, θα τροποποιήσουν και θα μοιραστούν το πρότζεκτ. Αλλά επειδή η νομική προεπιλογή εξακολουθεί να είναι η αποκλειστική πνευματική ιδιοκτησία, χρειάζεστε μια άδεια που να δηλώνει ρητά αυτές τις άδειες.
 
-If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+Εάν δεν εφαρμόσετε μια άδεια χρήσης ανοικτού κώδικα, όλοι όσοι συνεισφέρουν στο πρότζεκτ σας γίνονται επίσης αποκλειστικοί κάτοχοι πνευματικών δικαιωμάτων της εργασίας τους. Αυτό σημαίνει ότι κανείς δεν μπορεί να χρησιμοποιήσει, να αντιγράψει, να διανείμει ή να τροποποιήσει τις συνεισφορές του - και σε αυτό το "κανείς" συμπεριλαμβάνεστε και εσείς.
 
-Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
+Τέλος, το πρότζεκτ σας μπορεί να έχει εξαρτήσεις με απαιτήσεις άδειας χρήσης που δεν γνωρίζατε. Η κοινότητα του πρότζεκτ σας ή οι πολιτικές του εργοδότη σας μπορεί επίσης να απαιτούν από το πρότζεκτ σας να χρησιμοποιεί συγκεκριμένες άδειες ανοικτού κώδικα. Θα καλύψουμε αυτές τις καταστάσεις παρακάτω.
 
-## Are public GitHub projects open source?
+## Είναι τα δημόσια πρότζεκτ GitHub ανοιχτού κώδικα;
 
-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**.
+Όταν [δημιουργείτε ένα νέο πρότζεκτ](https://help.github.com/articles/creating-a-new-repository/) στο GitHub, έχετε την επιλογή να κάνετε το αποθετήριο **ιδιωτικό** ή **δημόσιο**.
 
-![Create repository](/assets/images/legal/repo-create-name.png)
+![Δημιουργία αποθετηρίου](/assets/images/legal/repo-create-name.png)
 
-**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+**Η δημοσιοποίηση του έργου σας στο GitHub δεν είναι το ίδιο με την αδειοδότηση του έργου σας.** Τα δημόσια πρότζεκτ καλύπτονται από τους [Όρους χρήσης του GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), οι οποίοι επιτρέπουν σε άλλους να βλέπουν και να διαιρούν το πρότζεκτ σας, αλλά η εργασία σας δεν συνοδεύεται από άλλα δικαιώματα.
 
-If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+Αν θέλετε να χρησιμοποιούν, να διανέμουν, να τροποποιούν ή να συνεισφέρουν άλλοι στο πρότζεκτ σας, πρέπει να συμπεριλάβετε μια άδεια χρήσης ανοικτού κώδικα. Για παράδειγμα, κάποιος δεν μπορεί νομικά να χρησιμοποιήσει οποιοδήποτε μέρος του έργου σας στο GitHub στον κώδικά του, ακόμη και αν είναι δημόσιο, εκτός αν του δώσετε ρητά το δικαίωμα να το κάνει.
 
-## Just give me the TL;DR on what I need to protect my project.
+## Απλά δώστε μου ένα TL;DR σχετικά με το τι χρειάζομαι για να προστατεύσω το πρότζεκτ μου.
 
-You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+Είστε τυχεροί, διότι σήμερα οι άδειες χρήσης ανοικτού κώδικα είναι τυποποιημένες και εύκολες στη χρήση. Μπορείτε να αντιγράψετε-επικολλήσετε μια υπάρχουσα άδεια απευθείας στο πρότζεκτ σας.
 
-[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 the most popular open source 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/).
+Οι [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/).
 
-When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/).
+Όταν δημιουργείτε ένα νέο πρότζεκτ στο GitHub, θα σας ζητηθεί [να προσθέσετε μια άδεια](https://help.github.com/articles/open-source-licensing/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
-  A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+  Μια τυποποιημένη άδεια χρησιμεύει ως πληρεξούσιο για όσους δεν έχουν νομική κατάρτιση, ώστε να γνωρίζουν ακριβώς τι μπορούν και τι δεν μπορούν να κάνουν με το λογισμικό. Εκτός αν είναι απολύτως απαραίτητο, αποφύγετε τους προσαρμοσμένους, τροποποιημένους ή μη τυποποιημένους όρους, οι οποίοι θα αποτελέσουν εμπόδιο για τη μεταγενέστερη χρήση του κώδικα του οργανισμού.
   <p markdown="1" class="pquote-credit">
-— @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+- @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
   </p>
 </aside>
 
-## Which open source license is appropriate for my project?
+## Ποια άδεια ανοιχτού κώδικα είναι κατάλληλη για το πρότζεκτ μου;
 
-If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+Αν ξεκινάτε από μια κενή πλάκα, είναι δύσκολο να κάνετε λάθος με την [MIT License](https://choosealicense.com/licenses/mit/). Είναι σύντομη, πολύ εύκολη στην κατανόηση και επιτρέπει σε οποιονδήποτε να κάνει οτιδήποτε, αρκεί να κρατήσει ένα αντίγραφο της άδειας, συμπεριλαμβανομένης της ειδοποίησης για τα πνευματικά σας δικαιώματα. Θα είστε σε θέση να κυκλοφορήσετε το πρότζεκτ με μια διαφορετική άδεια αν ποτέ χρειαστεί.
 
-Otherwise, picking the right open source license for your project depends on your objectives.
+Διαφορετικά, η επιλογή της σωστής άδειας ανοικτού κώδικα για το πρότζεκτ σας εξαρτάται από τους στόχους σας.
 
-Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+Το πρότζεκτ σας είναι πολύ πιθανό να έχει (ή θα έχει) **εξαρτήσεις**. Για παράδειγμα, αν έχετε ένα πρότζεκτ που βασίζεται στο Node.js, πιθανότατα θα χρησιμοποιείτε βιβλιοθήκες από τον Node Package Manager (npm). Κάθε μία από αυτές τις βιβλιοθήκες από τις οποίες εξαρτάστε θα έχει τη δική της άδεια χρήσης ανοικτού κώδικα. Αν κάθε μία από τις άδειες τους είναι "επιτρεπτή" (δίνει στο κοινό την άδεια χρήσης, τροποποίησης και διαμοιρασμού, χωρίς καμία προϋπόθεση για την αδειοδότηση σε μεταγενέστερο στάδιο), μπορείτε να χρησιμοποιήσετε οποιαδήποτε άδεια θέλετε. Οι συνήθεις άδειες με επιτρεπτικό χαρακτήρα περιλαμβάνουν τις MIT, Apache 2.0, ISC και BSD.
 
-On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+Από την άλλη πλευρά, εάν οι άδειες οποιασδήποτε από τις εξαρτήσεις σας είναι "strong copyleft" (δίνει επίσης στο κοινό τα ίδια δικαιώματα, υπό την προϋπόθεση ότι θα χρησιμοποιείτε την ίδια άδεια στα επόμενα στάδια), τότε το πρότζεκτ σας θα πρέπει να χρησιμοποιεί την ίδια άδεια. Οι συνήθεις άδειες με ισχυρό copyleft περιλαμβάνουν τις GPLv2, GPLv3 και AGPLv3.
 
-You may also want to consider the **communities** you hope will use and contribute to your project:
+Μπορεί επίσης να θέλετε να εξετάσετε τις **κοινότητες** που ελπίζετε ότι θα χρησιμοποιήσουν και θα συνεισφέρουν στο πρότζεκτ σας:
 
-* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
-* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
-* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+* **Θέλετε το πρότζεκτ σας να χρησιμοποιηθεί ως εξάρτηση από άλλα πρότζεκτ;** Πιθανώς είναι καλύτερο να χρησιμοποιήσετε την πιο δημοφιλή άδεια χρήσης στη σχετική κοινότητα. Για παράδειγμα, η [MIT](https://choosealicense.com/licenses/mit/) είναι η πιο δημοφιλής άδεια για τις [npm libraries](https://libraries.io/search?platforms=NPM).
+* **Θέλετε το πρότζεκτ σας να απευθύνεται σε μεγάλες επιχειρήσεις;** Μια μεγάλη επιχείρηση θα θέλει πιθανότατα ρητή άδεια χρήσης διπλωμάτων ευρεσιτεχνίας από όλους τους συνεισφέροντες. Σε αυτή την περίπτωση, το [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) σας καλύπτει (και αυτούς).
+* **Θέλετε το πρότζεκτ σας να απευθύνεται σε συνεισφέροντες που δεν επιθυμούν οι συνεισφορές τους να χρησιμοποιηθούν σε λογισμικό κλειστού κώδικα;** Η [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) ή (αν επίσης δεν επιθυμούν να συνεισφέρουν σε υπηρεσίες κλειστού κώδικα) η [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) θα είναι καλή επιλογή.
 
-Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+Η **επιχείρησή σας** μπορεί να έχει συγκεκριμένες απαιτήσεις αδειοδότησης για τα πρότζεκτ ανοικτού κώδικα. Για παράδειγμα, μπορεί να απαιτεί μια επιτρεπτική άδεια ώστε η εταιρεία να μπορεί να χρησιμοποιήσει το πρότζεκτ σας στο προϊόν κλειστού κώδικα της εταιρείας. Ή η εταιρεία σας μπορεί να απαιτεί μια ισχυρή άδεια copyleft και μια πρόσθετη συμφωνία συνεισφοράς (βλ. παρακάτω), έτσι ώστε μόνο η εταιρεία σας, και κανένας άλλος, να μπορεί να χρησιμοποιήσει το πρότζεκτ σας σε λογισμικό κλειστού κώδικα. Ή η εταιρεία σας μπορεί να έχει ορισμένες ανάγκες που σχετίζονται με πρότυπα, κοινωνική ευθύνη ή διαφάνεια, οι οποίες μπορεί να απαιτούν μια συγκεκριμένη στρατηγική αδειοδότησης. Μιλήστε με το νομικό τμήμα της [εταιρείας σας](#what-does-my-companys-legal-team-need-to-know).
 
-When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+Όταν δημιουργείτε ένα νέο πρότζεκτ στο GitHub, σας δίνεται η δυνατότητα να επιλέξετε μια άδεια χρήσης. Η συμπερίληψη μιας από τις άδειες που αναφέρονται παραπάνω θα καταστήσει το πρότζεκτ σας στο GitHub ανοικτού κώδικα. Αν θέλετε να δείτε και άλλες επιλογές, επισκεφθείτε την ιστοσελίδα [choosealicense.com](https://choosealicense.com) για να βρείτε την κατάλληλη άδεια για το πρότζεκτ σας, ακόμη και αν αυτό [δεν είναι λογισμικό](https://choosealicense.com/non-software/).
 
-## What if I want to change the license of my project?
+## Τι γίνεται αν θέλω να αλλάξω την άδεια χρήσης του έργου μου;
 
-Most projects never need to change licenses. But occasionally circumstances change.
+Τα περισσότερα πρότζεκτ δεν χρειάζεται ποτέ να αλλάξουν άδειες χρήσης. Αλλά περιστασιακά οι συνθήκες αλλάζουν.
 
-For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+Για παράδειγμα, καθώς το πρότζεκτ σας μεγαλώνει, προσθέτει εξαρτήσεις ή χρήστες, ή η εταιρεία σας αλλάζει στρατηγικές, κάτι που μπορεί να απαιτεί ή να επιθυμεί διαφορετική άδεια χρήσης. Επίσης, αν αμελήσατε να αδειοδοτήσετε το πρότζεκτ σας από την αρχή, η προσθήκη άδειας είναι ουσιαστικά το ίδιο με την αλλαγή αδειών. Υπάρχουν τρία θεμελιώδη πράγματα που πρέπει να λάβετε υπόψη όταν προσθέτετε ή αλλάζετε την άδεια του έργου σας:
 
-**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+**Είναι περίπλοκο.** Ο προσδιορισμός της συμβατότητας και της συμμόρφωσης με τις άδειες χρήσης και το ποιος κατέχει τα πνευματικά δικαιώματα μπορεί να γίνει πολύπλοκος και συγκεχυμένος πολύ γρήγορα. Η μετάβαση σε μια νέα, αλλά συμβατή άδεια για νέες εκδόσεις και συνεισφορές είναι διαφορετική από την εκ νέου αδειοδότηση όλων των υφιστάμενων συνεισφορών. Εμπλέξτε τη νομική σας ομάδα με την πρώτη ένδειξη οποιασδήποτε επιθυμίας αλλαγής αδειών χρήσης. Ακόμη και αν έχετε ή μπορείτε να λάβετε άδεια από τους κατόχους των πνευματικών δικαιωμάτων του έργου σας για μια αλλαγή άδειας χρήσης, λάβετε υπόψη σας τον αντίκτυπο της αλλαγής στους άλλους χρήστες και συνεισφέροντες του έργου σας. Σκεφτείτε μια αλλαγή άδειας χρήσης ως ένα "γεγονός διακυβέρνησης" για το πρότζεκτ σας, το οποίο είναι πιθανότερο να εξελιχθεί ομαλά με σαφή επικοινωνία και διαβούλευση με τους ενδιαφερόμενους φορείς του έργου σας. Ένας λόγος παραπάνω για να επιλέξετε και να χρησιμοποιήσετε την κατάλληλη άδεια για το πρότζεκτ σας από την αρχή του!
 
-**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+**Η υπάρχουσα άδεια του έργου σας.** Αν η υπάρχουσα άδεια του έργου σας είναι συμβατή με την άδεια στην οποία θέλετε να αλλάξετε, μπορείτε απλά να αρχίσετε να χρησιμοποιείτε τη νέα άδεια. Αυτό συμβαίνει επειδή, αν η άδεια Α είναι συμβατή με την άδεια Β, θα συμμορφώνεστε με τους όρους της Α, ενώ παράλληλα θα συμμορφώνεστε με τους όρους της Β (αλλά όχι απαραίτητα το αντίστροφο). Έτσι, αν χρησιμοποιείτε επί του παρόντος μια επιτρεπτική άδεια (π.χ. MIT), θα μπορούσατε να αλλάξετε σε μια άδεια με περισσότερους όρους, αρκεί να διατηρήσετε ένα αντίγραφο της άδειας MIT και οποιεσδήποτε σχετικές ειδοποιήσεις πνευματικών δικαιωμάτων (δηλαδή, να συνεχίσετε να συμμορφώνεστε με τους ελάχιστους όρους της άδειας MIT). Αλλά αν η τρέχουσα άδειά σας δεν είναι επιτρεπτή (π.χ. copyleft, ή δεν έχετε άδεια) και δεν είστε ο μοναδικός κάτοχος των πνευματικών δικαιωμάτων, δεν θα μπορούσατε απλά να αλλάξετε την άδεια του έργου σας σε MIT. Ουσιαστικά, με μια επιτρεπτική άδεια οι κάτοχοι των πνευματικών δικαιωμάτων του έργου έχουν δώσει εκ των προτέρων την άδεια να αλλάξουν τις άδειες.
 
-**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+**Οι υπάρχοντες κάτοχοι πνευματικών δικαιωμάτων του έργου σας.** Εάν είστε ο μοναδικός συντελεστής του έργου σας, τότε είτε εσείς είτε η εταιρεία σας είστε ο μοναδικός κάτοχος πνευματικών δικαιωμάτων του έργου. Μπορείτε να προσθέσετε ή να αλλάξετε σε όποια άδεια χρήσης θέλετε εσείς ή η εταιρεία σας. Διαφορετικά, μπορεί να υπάρχουν άλλοι κάτοχοι πνευματικών δικαιωμάτων από τους οποίους θα πρέπει να έχετε τη σύμφωνη γνώμη για να αλλάξετε τις άδειες χρήσης. Ποιοι είναι αυτοί; Οι άνθρωποι που έχουν commits στο πρότζεκτ σας είναι ένα καλό μέρος για να ξεκινήσετε. Αλλά σε ορισμένες περιπτώσεις τα πνευματικά δικαιώματα θα κατέχονται από τους εργοδότες αυτών των ανθρώπων. Σε ορισμένες περιπτώσεις οι άνθρωποι θα έχουν κάνει μόνο ελάχιστες συνεισφορές, αλλά δεν υπάρχει κανένας αυστηρός και σταθερός κανόνας ότι συνεισφορές κάτω από κάποιο αριθμό γραμμών κώδικα δεν υπόκεινται σε πνευματικά δικαιώματα. Τι πρέπει να γίνει; Εξαρτάται. Για ένα σχετικά μικρό και νεαρό πρότζεκτ, μπορεί να είναι εφικτό να πείσετε όλους τους υπάρχοντες συνεισφέροντες να συμφωνήσουν σε μια αλλαγή άδειας χρήσης σε ένα θέμα ή σε ένα pull request. Για μεγάλα και μακροχρόνια πρότζεκτ, μπορεί να χρειαστεί να αναζητήσετε πολλούς συνεισφέροντες, ακόμη και τους κληρονόμους τους. Η Mozilla χρειάστηκε πολλά χρόνια (2001-2006) για να ανανεώσει την άδεια χρήσης του Firefox, του Thunderbird και του σχετικού λογισμικού.
 
-Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+Εναλλακτικά, μπορείτε να ζητήσετε από τους συνεισφέροντες να συμφωνήσουν εκ των προτέρων (μέσω μιας πρόσθετης συμφωνίας συνεισφέροντος -- δείτε παρακάτω) σε ορισμένες αλλαγές στην άδεια χρήσης υπό ορισμένες προϋποθέσεις, πέραν αυτών που επιτρέπονται από την υπάρχουσα άδεια χρήσης ανοικτού κώδικα. Αυτό μετατοπίζει λίγο την πολυπλοκότητα της αλλαγής των αδειών χρήσης. Θα χρειαστείτε περισσότερη βοήθεια από τους δικηγόρους σας εκ των προτέρων, και θα εξακολουθείτε να θέλετε να επικοινωνείτε με σαφήνεια με τα ενδιαφερόμενα μέρη του έργου σας όταν εκτελείτε μια αλλαγή άδειας χρήσης.
 
-## 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).
+Μάλλον όχι. Για τη συντριπτική πλειονότητα των πρότζεκτ ανοικτού κώδικα, μια άδεια ανοικτού κώδικα χρησιμεύει σιωπηρά τόσο ως η εισερχόμενη (από τους συνεισφέροντες) όσο και ως η εξερχόμενη (προς άλλους συνεισφέροντες και χρήστες) άδεια. Εάν το πρότζεκτ σας βρίσκεται στο GitHub, οι όροι χρήσης του GitHub καθιστούν το "inbound=outbound" τη [ρητή προεπιλογή](https://help.github.com/en/github/site-policy/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.
+Μια πρόσθετη συμφωνία συνεισφέροντος -- συχνά αποκαλούμενη Συμφωνία άδειας χρήσης συνεισφέροντος (CLA) -- μπορεί να δημιουργήσει διοικητική εργασία για τους συντηρητές του έργου. Το πόση εργασία προσθέτει μια συμφωνία εξαρτάται από το πρότζεκτ και την εφαρμογή. Μια απλή συμφωνία μπορεί να απαιτεί από τους συνεισφέροντες να επιβεβαιώνουν, με ένα κλικ, ότι έχουν τα απαραίτητα δικαιώματα για να συνεισφέρουν σύμφωνα με την άδεια χρήσης ανοικτού κώδικα του έργου. Μια πιο περίπλοκη συμφωνία μπορεί να απαιτεί νομικό έλεγχο και υπογραφή από τους εργοδότες των συνεισφερόντων.
 
-Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
+Επίσης, προσθέτοντας "γραφειοκρατία" που κάποιοι θεωρούν περιττή, δυσνόητη ή άδικη (όταν ο παραλήπτης της συμφωνίας αποκτά περισσότερα δικαιώματα από ό,τι οι συνεισφέροντες ή το κοινό μέσω της άδειας χρήσης ανοικτού κώδικα του έργου), μια πρόσθετη συμφωνία συνεισφοράς μπορεί να θεωρηθεί μη φιλική προς την κοινότητα του έργου.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
-    We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+    Εξαλείψαμε το CLA για το Node.js. Με αυτόν τον τρόπο μειώνουμε το εμπόδιο εισόδου για τους συνεισφέροντες του Node.js, διευρύνοντας έτσι τη βάση των συνεισφερόντων.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+- @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
-Some situations where you may want to consider an additional contributor agreement for your project include:
+Ορισμένες περιπτώσεις στις οποίες μπορεί να θέλετε να εξετάσετε το ενδεχόμενο σύναψης πρόσθετης συμφωνίας συνεισφοράς για το πρότζεκτ σας περιλαμβάνουν:
 
-* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
-* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
-* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
-* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
-* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
+* Οι δικηγόροι σας θέλουν όλοι οι συνεισφέροντες να αποδέχονται ρητά (_υπογράφουν_, online ή offline) τους όρους συνεισφοράς, ίσως επειδή θεωρούν ότι η ίδια η άδεια ανοιχτού κώδικα δεν είναι αρκετή (παρόλο που είναι!). Εάν αυτό είναι το μόνο πρόβλημα, μια συμφωνία συνεισφοράς που επιβεβαιώνει την άδεια χρήσης ανοικτού κώδικα του έργου θα πρέπει να είναι αρκετή. Η [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) είναι ένα καλό παράδειγμα μιας ελαφριάς πρόσθετης συμφωνίας συνεισφοράς.
+* Εσείς ή οι δικηγόροι σας θέλετε οι προγραμματιστές να δηλώνουν ότι κάθε δέσμευση που κάνουν είναι εξουσιοδοτημένη. Η απαίτηση [Πιστοποιητικό προέλευσης προγραμματιστή] (https://developercertificate.org/) είναι ο τρόπος με τον οποίο πολλά πρότζεκτ το επιτυγχάνουν αυτό. Για παράδειγμα, η κοινότητα Node.js [χρησιμοποιεί](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) το DCO [αντί](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) του προηγούμενου CLA. Μια απλή επιλογή για να αυτοματοποιήσετε την επιβολή του DCO στο αποθετήριο σας είναι το [DCO Probot](https://github.com/probot/dco).
+* Το πρότζεκτ σας χρησιμοποιεί μια άδεια χρήσης ανοικτού κώδικα που δεν περιλαμβάνει ρητή παραχώρηση διπλωμάτων ευρεσιτεχνίας (όπως η MIT) και χρειάζεστε παραχώρηση διπλώματος ευρεσιτεχνίας από όλους τους συνεισφέροντες, ορισμένοι από τους οποίους μπορεί να εργάζονται σε εταιρείες με μεγάλα χαρτοφυλάκια διπλωμάτων ευρεσιτεχνίας που θα μπορούσαν να χρησιμοποιηθούν για να στοχεύσουν εσάς ή άλλους συνεισφέροντες και χρήστες του έργου. Η [Apache Individual Contributor License Agreement] (https://www.apache.org/licenses/icla.pdf) είναι μια ευρέως χρησιμοποιούμενη πρόσθετη συμφωνία συνεισφοράς που έχει μια παραχώρηση διπλώματος ευρεσιτεχνίας που αντικατοπτρίζει αυτή που υπάρχει στην Άδεια Apache 2.0.
+* Το πρότζεκτ σας τελεί υπό άδεια copyleft, αλλά πρέπει επίσης να διανείμετε μια ιδιόκτητη έκδοση του έργου. Θα χρειαστείτε κάθε συνεισφέροντα να σας εκχωρήσει τα πνευματικά δικαιώματα ή να σας παραχωρήσει (αλλά όχι στο κοινό) μια επιτρεπτική άδεια. Το [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) είναι ένα παράδειγμα αυτού του τύπου συμφωνίας.
+* Πιστεύετε ότι το πρότζεκτ σας μπορεί να χρειαστεί να αλλάξει άδειες χρήσης κατά τη διάρκεια της ζωής του και θέλετε οι συνεισφέροντες να συμφωνήσουν εκ των προτέρων σε τέτοιες αλλαγές.
 
-If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+Εάν χρειάζεται να χρησιμοποιήσετε μια πρόσθετη συμφωνία συνεισφοράς με το πρότζεκτ σας, εξετάστε το ενδεχόμενο να χρησιμοποιήσετε μια ενσωμάτωση όπως η [CLA assistant](https://github.com/cla-assistant/cla-assistant) για να ελαχιστοποιήσετε την απόσπαση της προσοχής των συνεισφερόντων.
 
-## What does my company's legal team need to know?
+## Τι πρέπει να γνωρίζει η νομική ομάδα της εταιρείας μου;
 
-If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+Εάν κυκλοφορείτε ένα πρότζεκτ ανοικτού κώδικα ως υπάλληλος της εταιρείας, πρώτα απ' όλα, η νομική σας ομάδα θα πρέπει να γνωρίζει ότι χρησιμοποιείτε ένα πρότζεκτ ανοικτού κώδικα.
 
-For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+Καλώς ή κακώς, σκεφτείτε να τους ενημερώσετε, ακόμη και αν πρόκειται για ένα προσωπικό πρότζεκτ. Πιθανόν να έχετε μια "συμφωνία διανοητικής ιδιοκτησίας εργαζομένων" με την εταιρεία σας που τους δίνει κάποιο έλεγχο των πρότζεκτ σας, ειδικά αν αυτά σχετίζονται καθόλου με την επιχειρηματική δραστηριότητα της εταιρείας ή αν χρησιμοποιείτε πόρους της εταιρείας για την ανάπτυξη του έργου. Η εταιρεία σας _θα πρέπει_ να σας δώσει εύκολα την άδεια, και ίσως το έχει ήδη κάνει μέσω μιας φιλικής προς τους εργαζόμενους συμφωνίας πνευματικής ιδιοκτησίας ή μιας εταιρικής πολιτικής. Αν όχι, μπορείτε να διαπραγματευτείτε (για παράδειγμα, να εξηγήσετε ότι το πρότζεκτ σας εξυπηρετεί τους στόχους επαγγελματικής μάθησης και ανάπτυξης της εταιρείας για εσάς) ή να αποφύγετε να εργαστείτε στο πρότζεκτ σας μέχρι να βρείτε μια καλύτερη εταιρεία.
 
-**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+**Αν κάνετε ένα πρότζεκτ ανοιχτού κώδικα για την εταιρεία σας,** τότε σίγουρα ενημερώστε τους. Η νομική σας ομάδα πιθανότατα έχει ήδη πολιτικές για το ποια άδεια ανοικτού κώδικα (και ίσως πρόσθετη συμφωνία συνεισφοράς) θα πρέπει να χρησιμοποιηθεί με βάση τις επιχειρηματικές απαιτήσεις της εταιρείας και την τεχνογνωσία γύρω από τη διασφάλιση της συμμόρφωσης του έργου σας με τις άδειες των εξαρτήσεών του. Εάν όχι, εσείς και αυτοί είστε τυχεροί! Η νομική σας ομάδα θα πρέπει να είναι πρόθυμη να συνεργαστεί μαζί σας για να τα βρείτε αυτά τα πράγματα. Μερικά πράγματα που πρέπει να σκεφτείτε:
 
-* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+* **Υλικό τρίτων:** Έχει το πρότζεκτ σας εξαρτήσεις που δημιουργήθηκαν από άλλους ή περιλαμβάνει ή χρησιμοποιεί κώδικα άλλων; Εάν αυτά είναι ανοιχτού κώδικα, θα πρέπει να συμμορφωθείτε με τις άδειες χρήσης του υλικού ανοιχτού κώδικα. Αυτό ξεκινάει με την επιλογή μιας άδειας που συνεργάζεται με τις άδειες ανοικτού κώδικα τρίτων (βλ. παραπάνω). Εάν το πρότζεκτ σας τροποποιεί ή διανέμει υλικό ανοικτού κώδικα τρίτων, τότε η νομική σας ομάδα θα θέλει επίσης να γνωρίζει ότι πληροίτε άλλους όρους των αδειών ανοικτού κώδικα τρίτων, όπως η διατήρηση των σημειώσεων περί πνευματικών δικαιωμάτων. Εάν το πρότζεκτ σας χρησιμοποιεί κώδικα άλλων που δεν έχει άδεια χρήσης ανοικτού κώδικα, θα πρέπει πιθανώς να ζητήσετε από τους συντηρητές του τρίτου μέρους να [προσθέσουν μια άδεια χρήσης ανοικτού κώδικα](https://choosealicense.com/no-license/#for-users), και εάν δεν μπορείτε να πάρετε μια τέτοια άδεια, να σταματήσετε να χρησιμοποιείτε τον κώδικά τους στο πρότζεκτ σας.
 
-* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+* **Εμπορικά μυστικά:** Εξετάστε αν υπάρχει κάτι στο πρότζεκτ που η εταιρεία δεν θέλει να διαθέσει στο ευρύ κοινό. Αν ναι, θα μπορούσατε να ανοίξετε τον κώδικα του υπόλοιπου έργου σας, αφού εξάγετε το υλικό που θέλετε να κρατήσετε ιδιωτικό.
 
-* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
+* **Διπλώματα ευρεσιτεχνίας:** Υποβάλλει η εταιρεία σας αίτηση για δίπλωμα ευρεσιτεχνίας του οποίου η ανοικτή διάθεση του έργου σας θα αποτελούσε [δημόσια αποκάλυψη](https://en.wikipedia.org/wiki/Public_disclosure); Δυστυχώς, μπορεί να σας ζητηθεί να περιμένετε (ή ίσως η εταιρεία να επανεξετάσει τη σοφία της αίτησης). Αν περιμένετε συνεισφορές στο πρότζεκτ σας από υπαλλήλους εταιρειών με μεγάλα χαρτοφυλάκια διπλωμάτων ευρεσιτεχνίας, η νομική σας ομάδα μπορεί να θέλει να χρησιμοποιήσετε μια άδεια με ρητή παραχώρηση διπλωμάτων ευρεσιτεχνίας από τους συνεισφέροντες (όπως η Apache 2.0 ή η GPLv3), ή μια πρόσθετη συμφωνία συνεισφοράς (βλ. παραπάνω).
 
-* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+* **Εμπορικά σήματα:** Ελέγξτε δύο φορές ότι το όνομα του έργου σας [δεν συγκρούεται με τυχόν υπάρχοντα εμπορικά σήματα](../starting-a-project/#avoiding-name-conflicts). Εάν χρησιμοποιείτε τα εμπορικά σήματα της εταιρείας σας στο πρότζεκτ, ελέγξτε ότι δεν προκαλούνται συγκρούσεις. Το [FOSSmarks](http://fossmarks.org/) είναι ένας πρακτικός οδηγός για την κατανόηση των εμπορικών σημάτων στο πλαίσιο των πρότζεκτ ελεύθερου και ανοικτού κώδικα.
 
-* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+* **Απόρρητο:** Το πρότζεκτ σας συλλέγει δεδομένα για τους χρήστες; "Τηλεφωνεί στο σπίτι" σε διακομιστές της εταιρείας; Η νομική σας ομάδα μπορεί να σας βοηθήσει να συμμορφωθείτε με τις εταιρικές πολιτικές και τους εξωτερικούς κανονισμούς.
 
-If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+Αν πρόκειται να κυκλοφορήσετε το πρώτο πρότζεκτ ανοικτού κώδικα της εταιρείας σας, τα παραπάνω είναι υπεραρκετά για να τα ξεπεράσετε (αλλά μην ανησυχείτε, τα περισσότερα πρότζεκτ δεν θα πρέπει να εγείρουν σημαντικές ανησυχίες).
 
-Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+Μακροπρόθεσμα, η νομική σας ομάδα μπορεί να κάνει περισσότερα για να βοηθήσει την εταιρεία να αποκομίσει περισσότερα από τη συμμετοχή της στον ανοικτό κώδικα και να παραμείνει ασφαλής:
 
-* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Πολιτικές συνεισφοράς των υπαλλήλων:** Εξετάστε το ενδεχόμενο να αναπτύξετε μια εταιρική πολιτική που να καθορίζει τον τρόπο με τον οποίο οι υπάλληλοί σας συνεισφέρουν σε πρότζεκτ ανοικτού κώδικα. Μια σαφής πολιτική θα μειώσει τη σύγχυση μεταξύ των υπαλλήλων σας και θα τους βοηθήσει να συνεισφέρουν σε πρότζεκτ ανοικτού κώδικα προς το συμφέρον της εταιρείας, είτε ως μέρος της εργασίας τους είτε στον ελεύθερο χρόνο τους. Ένα καλό παράδειγμα είναι η [Πρότυπη πολιτική IP και συνεισφοράς σε ανοικτό κώδικα](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) της Rackspace.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
-  Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+  Η εκμίσθωση της IP που σχετίζεται με μια επιδιόρθωση δημιουργεί τη βάση γνώσεων και τη φήμη του υπαλλήλου. Δείχνει ότι η εταιρεία επενδύει στην ανάπτυξη του συγκεκριμένου εργαζομένου και δημιουργεί μια αίσθηση ενδυνάμωσης και αυτονομίας. Όλα αυτά τα οφέλη οδηγούν επίσης σε υψηλότερο ηθικό και καλύτερη διατήρηση των εργαζομένων.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+- @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
-* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
-* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+* **Τι να δημοσιεύσετε:** [(Σχεδόν) τα πάντα;](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Εάν η νομική σας ομάδα κατανοεί και έχει επενδύσει στη στρατηγική ανοικτού κώδικα της εταιρείας σας, θα είναι σε θέση να βοηθήσει καλύτερα παρά να εμποδίσει τις προσπάθειές σας.
+* **Συμμόρφωση:** Ακόμα και αν η εταιρεία σας δεν εκδίδει πρότζεκτ ανοικτού κώδικα, χρησιμοποιεί λογισμικό ανοικτού κώδικα άλλων. Η [Ενημέρωση και διαδικασία](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) μπορεί να αποτρέψει πονοκεφάλους, καθυστερήσεις προϊόντων και αγωγές.
 
 <aside markdown="1" class="pquote">
-  Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+  Οι οργανισμοί πρέπει να διαθέτουν μια στρατηγική αδειοδότησης και συμμόρφωσης που να ταιριάζει και στις δύο κατηγορίες \["επιτρεπτή" και "copyleft"\]. Αυτό ξεκινά με την τήρηση αρχείου των όρων αδειοδότησης που ισχύουν για το λογισμικό ανοικτού κώδικα που χρησιμοποιείτε - συμπεριλαμβανομένων των υποσυνιστωσών και των εξαρτήσεων.
   <p markdown="1" class="pquote-credit">
-— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+- Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
   </p>
 </aside>
 
-* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
-* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
+* **Διπλώματα ευρεσιτεχνίας:** Η εταιρεία σας μπορεί να επιθυμεί να ενταχθεί στο [Open Invention Network](https://www.openinventionnetwork.com/), μια κοινή αμυντική δεξαμενή διπλωμάτων ευρεσιτεχνίας για την προστασία της χρήσης μεγάλων πρότζεκτ ανοικτού κώδικα από τα μέλη, ή να διερευνήσει άλλες [εναλλακτικές αδειοδοτήσεις διπλωμάτων ευρεσιτεχνίας](https://www.eff.org/document/hacking-patent-system-2016).
+* **Διακυβέρνηση:** Ειδικά εάν και εφόσον έχει νόημα να μεταφερθεί ένα πρότζεκτ σε μια [νομική οντότητα εκτός της εταιρείας](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).

From b48df6915aa1b95ff9a8241e64eba8686eb31619 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 20 Sep 2022 11:51:46 +0300
Subject: [PATCH 378/749] Translate starting-a-project.md

---
 _articles/el/starting-a-project.md | 270 ++++++++++++++---------------
 1 file changed, 135 insertions(+), 135 deletions(-)

diff --git a/_articles/el/starting-a-project.md b/_articles/el/starting-a-project.md
index 1112dec18ed..8af7812bf76 100644
--- a/_articles/el/starting-a-project.md
+++ b/_articles/el/starting-a-project.md
@@ -10,347 +10,347 @@ related:
   - building
 ---
 
-## The "what" and "why" of open source
+## Το "τι" και το "γιατί" του ανοικτού κώδικα
 
-So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+Σκέφτεστε λοιπόν να ξεκινήσετε με τον ανοιχτό κώδικα; Συγχαρητήρια! Ο κόσμος εκτιμά τη συνεισφορά σας. Ας μιλήσουμε για το τι είναι ο ανοιχτός κώδικας και γιατί οι άνθρωποι το κάνουν.
 
-### What does "open source" mean?
+### Τι σημαίνει "ανοιχτός κώδικας";
 
-When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+Όταν ένα πρότζεκτ είναι ανοικτού κώδικα, αυτό σημαίνει ότι **ο καθένας είναι ελεύθερος να χρησιμοποιήσει, να μελετήσει, να τροποποιήσει και να διανείμει το πρότζεκτ σας για οποιονδήποτε σκοπό.** Αυτά τα δικαιώματα επιβάλλονται μέσω [μιας άδειας ανοικτού κώδικα](https://opensource.org/licenses).
 
-Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+Ο ανοικτός κώδικας είναι ισχυρός επειδή μειώνει τα εμπόδια στην υιοθέτηση και τη συνεργασία, επιτρέποντας στους ανθρώπους να διαδίδουν και να βελτιώνουν πρότζεκτ γρήγορα. Επίσης, επειδή δίνει στους χρήστες τη δυνατότητα να ελέγχουν τους υπολογιστές τους, σε σχέση με τον κλειστό κώδικα. Για παράδειγμα, μια επιχείρηση που χρησιμοποιεί λογισμικό ανοικτού κώδικα έχει τη δυνατότητα να προσλάβει κάποιον για να κάνει προσαρμοσμένες βελτιώσεις στο λογισμικό, αντί να βασίζεται αποκλειστικά στις αποφάσεις ενός προμηθευτή κλειστού κώδικα για το προϊόν.
 
-_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+Το _ελεύθερο λογισμικό_ αναφέρεται στο ίδιο σύνολο πρότζεκτ με το _ανοικτού κώδικα_. Μερικές φορές θα δείτε επίσης [αυτούς τους όρους](https://en.wikipedia.org/wiki/Free_and_open-source_software) συνδυασμένους ως "ελεύθερο λογισμικό και λογισμικό ανοικτού κώδικα" (FOSS) ή "ελεύθερο, ελεύθερο και λογισμικό ανοικτού κώδικα" (FLOSS). Τα _Free_ και _libre_ αναφέρονται στην ελευθερία, [όχι στην τιμή](#does-open-source-mean-free-of-charge).
 
-### Why do people open source their work?
+### Γιατί οι άνθρωποι ανοίγουν το λογισμικό τους;
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
-  One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+  Μια από τις πιο ικανοποιητικές εμπειρίες που αποκομίζω από τη χρήση και τη συνεργασία σε θέματα ανοικτού κώδικα προέρχεται από τις σχέσεις που χτίζω με άλλους προγραμματιστές που αντιμετωπίζουν πολλά από τα ίδια προβλήματα με εμένα.
   <p markdown="1" class="pquote-credit">
-— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+- @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
   </p>
 </aside>
 
-[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+[Υπάρχουν πολλοί λόγοι](https://ben.balter.com/2015/11/23/why-open-source/) για τους οποίους ένα άτομο ή ένας οργανισμός θα ήθελε να ανοίξει τον κώδικα ενός έργου. Μερικά παραδείγματα περιλαμβάνουν:
 
-* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+* **Συνεργασία:** Τα πρότζεκτ ανοικτού κώδικα μπορούν να δέχονται αλλαγές από οποιονδήποτε στον κόσμο. Το [Exercism](https://github.com/exercism/), για παράδειγμα, είναι μια πλατφόρμα ασκήσεων προγραμματισμού με πάνω από 350 συνεισφέροντες.
 
-* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **Υιοθέτηση και επανασύνθεση:** Τα πρότζεκτ ανοικτού κώδικα μπορούν να χρησιμοποιηθούν από οποιονδήποτε για σχεδόν οποιονδήποτε σκοπό. Οι άνθρωποι μπορούν ακόμη και να τα χρησιμοποιήσουν για να κατασκευάσουν άλλα πράγματα. Το [WordPress](https://github.com/WordPress), για παράδειγμα, ξεκίνησε ως διακλάδωση ενός υπάρχοντος έργου που ονομαζόταν [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+* **Διαφάνεια:** Οποιοσδήποτε μπορεί να επιθεωρήσει ένα πρότζεκτ ανοικτού κώδικα για λάθη ή ασυνέπειες. Η διαφάνεια έχει σημασία για κυβερνήσεις όπως η [Βουλγαρία](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ή οι [Ηνωμένες Πολιτείες](https://sourcecode.cio.gov/), ρυθμιζόμενες βιομηχανίες όπως οι τράπεζες ή η υγειονομική περίθαλψη και λογισμικό ασφαλείας όπως το [Let's Encrypt](https://github.com/letsencrypt).
 
-Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+Ο ανοικτός κώδικας δεν είναι μόνο για το λογισμικό. Μπορείτε να ανοίξετε τα πάντα, από σύνολα δεδομένων μέχρι βιβλία. Ελέγξτε το [GitHub Explore](https://github.com/explore) για ιδέες σχετικά με το τι άλλο μπορείτε να ανοίξετε με ανοικτό κώδικα.
 
-### Does open source mean "free of charge"?
+### Ανοιχτός κώδικας σημαίνει "δωρεάν";
 
-One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+Ένα από τα μεγαλύτερα πλεονεκτήματα του ανοικτού κώδικα είναι ότι δεν κοστίζει χρήματα. Το "δωρεάν", ωστόσο, είναι ένα υποπροϊόν της συνολικής αξίας του ανοικτού κώδικα.
 
-Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+Επειδή [μια άδεια χρήσης ανοικτού κώδικα απαιτεί](https://opensource.org/osd-annotated) ότι ο καθένας μπορεί να χρησιμοποιήσει, να τροποποιήσει και να μοιραστεί το πρότζεκτ σας για σχεδόν οποιονδήποτε σκοπό, τα ίδια τα πρότζεκτ τείνουν να είναι δωρεάν. Αν το πρότζεκτ κόστιζε χρήματα για τη χρήση του, ο καθένας θα μπορούσε νόμιμα να δημιουργήσει ένα αντίγραφο και να χρησιμοποιήσει τη δωρεάν έκδοση αντί αυτού.
 
-As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+Ως αποτέλεσμα, τα περισσότερα πρότζεκτ ανοικτού κώδικα είναι δωρεάν, αλλά το "δωρεάν" δεν αποτελεί μέρος του ορισμού του ανοικτού κώδικα. Υπάρχουν τρόποι να χρεώνετε τα πρότζεκτ ανοικτού κώδικα έμμεσα μέσω διπλής αδειοδότησης ή περιορισμένων χαρακτηριστικών, ενώ παράλληλα εξακολουθούν να συμμορφώνονται με τον επίσημο ορισμό του ανοικτού κώδικα.
 
-## Should I launch my own open source project?
+## Πρέπει να ξεκινήσω το δικό μου πρότζεκτ ανοιχτού κώδικα;
 
-The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+Η σύντομη απάντηση είναι ναι, διότι, ανεξάρτητα από το αποτέλεσμα, το να ξεκινήσετε το δικό σας πρότζεκτ είναι ένας πολύ καλός τρόπος για να μάθετε πώς λειτουργεί ο ανοιχτός κώδικας.
 
-If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+Αν δεν έχετε ποτέ στο παρελθόν ανοίξει ένα πρότζεκτ, μπορεί να έχετε άγχος για το τι θα πει ο κόσμος ή αν θα το προσέξει κανείς. Αν αυτό σας μοιάζει, δεν είστε οι μόνοι!
 
-Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+Η εργασία ανοιχτού κώδικα είναι όπως κάθε άλλη δημιουργική δραστηριότητα, είτε πρόκειται για συγγραφή είτε για ζωγραφική. Μπορεί να αισθάνεστε τρομακτικό να μοιράζεστε τη δουλειά σας με τον κόσμο, αλλά ο μόνος τρόπος για να βελτιωθείτε είναι να εξασκηθείτε - ακόμη και αν δεν έχετε κοινό.
 
-If you're not yet convinced, take a moment to think about what your goals might be.
+Αν δεν έχετε πειστεί ακόμα, σκεφτείτε για λίγο ποιοι μπορεί να είναι οι στόχοι σας.
 
-### Setting your goals
+### Θέτοντας τους στόχους σας
 
-Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself,  _why am I open sourcing this project?_
+Οι στόχοι μπορούν να σας βοηθήσουν να καταλάβετε τι πρέπει να δουλέψετε, σε τι να πείτε όχι και πού χρειάζεστε βοήθεια από άλλους. Ξεκινήστε ρωτώντας τον εαυτό σας, _γιατί κάνω open sourcing αυτό το πρότζεκτ;_
 
-There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+Δεν υπάρχει μια σωστή απάντηση σε αυτό το ερώτημα. Μπορεί να έχετε πολλαπλούς στόχους για ένα πρότζεκτ ή διαφορετικά πρότζεκτ με διαφορετικούς στόχους.
 
-If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+Αν ο μόνος σας στόχος είναι να επιδείξετε τη δουλειά σας, μπορεί να μην θέλετε καν συνεισφορές, και μάλιστα να το πείτε αυτό στο README σας. Από την άλλη πλευρά, αν θέλετε συνεισφέροντες, θα επενδύσετε χρόνο σε σαφή τεκμηρίωση και θα κάνετε τους νεοεισερχόμενους να αισθάνονται ευπρόσδεκτοι.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
-  At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+  Κάποια στιγμή δημιούργησα ένα προσαρμοσμένο UIAlertView που χρησιμοποιούσα... και αποφάσισα να το κάνω open source. Έτσι το τροποποίησα για να είναι πιο δυναμικό και το ανέβασα στο GitHub. Έγραψα επίσης την πρώτη μου τεκμηρίωση εξηγώντας σε άλλους προγραμματιστές πώς να το χρησιμοποιήσουν στα πρότζεκτ τους. Πιθανότατα κανείς δεν το χρησιμοποίησε ποτέ επειδή ήταν ένα απλό πρότζεκτ, αλλά ένιωθα καλά για τη συνεισφορά μου.
   <p markdown="1" class="pquote-credit">
-— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+- @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
   </p>
 </aside>
 
-As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+Καθώς το πρότζεκτ σας αναπτύσσεται, η κοινότητά σας μπορεί να χρειάζεται κάτι περισσότερο από τον κώδικα που θα σας παρέχει. Η ανταπόκριση σε ζητήματα, η αναθεώρηση κώδικα και η προώθηση του έργου σας είναι όλα σημαντικά καθήκοντα σε ένα πρότζεκτ ανοικτού κώδικα.
 
-While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+Αν και ο χρόνος που αφιερώνετε σε εργασίες που δεν σχετίζονται με τον προγραμματισμό εξαρτάται από το μέγεθος και το πεδίο εφαρμογής του έργου σας, θα πρέπει να είστε προετοιμασμένοι ως συντηρητής να τις αντιμετωπίσετε μόνοι σας ή να βρείτε κάποιον να σας βοηθήσει.
 
-**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+**Αν ανήκετε σε μια εταιρεία με ανοικτό sourcing ενός έργου,** βεβαιωθείτε ότι το πρότζεκτ σας διαθέτει τους εσωτερικούς πόρους που χρειάζεται για να ευδοκιμήσει. Θα πρέπει να προσδιορίσετε ποιος είναι υπεύθυνος για τη συντήρηση του έργου μετά την έναρξη και πώς θα μοιραστείτε αυτά τα καθήκοντα με την κοινότητά σας.
 
-If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+Αν χρειάζεστε ειδικό προϋπολογισμό ή προσωπικό για την προώθηση, τις λειτουργίες και τη συντήρηση του έργου, ξεκινήστε τις συζητήσεις αυτές από νωρίς.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-  As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+  Καθώς αρχίζετε να ανοίγετε το πρότζεκτ, είναι σημαντικό να βεβαιωθείτε ότι οι διαδικασίες διαχείρισης λαμβάνουν υπόψη τις συνεισφορές και τις ικανότητες της κοινότητας γύρω από το πρότζεκτ σας. Μη φοβάστε να εμπλέξετε συνεισφέροντες που δεν απασχολούνται στην επιχείρησή σας σε βασικές πτυχές του έργου - ειδικά αν είναι συχνοί συνεισφέροντες.
   <p markdown="1" class="pquote-credit">
-— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+- @captainsafia, ["Ώστε θέλεις να ανοίξεις ένα πρότζεκτ με ανοιχτό κώδικα, ε;"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
   </p>
 </aside>
 
-### Contributing to other projects
+### Συμβολή σε άλλα πρότζεκτ
 
-If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+Αν ο στόχος σας είναι να μάθετε πώς να συνεργάζεστε με άλλους ή να κατανοήσετε πώς λειτουργεί ο ανοιχτός κώδικας, σκεφτείτε να συνεισφέρετε σε ένα υπάρχον πρότζεκτ. Ξεκινήστε με ένα πρότζεκτ που ήδη χρησιμοποιείτε και αγαπάτε. Η συνεισφορά σε ένα πρότζεκτ μπορεί να είναι τόσο απλή όσο η διόρθωση τυπογραφικών λαθών ή η ενημέρωση της τεκμηρίωσης.
 
-If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+Αν δεν είστε σίγουροι για το πώς να ξεκινήσετε να συνεισφέρετε, ανατρέξτε στον οδηγό μας [Πώς να συνεισφέρετε στον Ανοιχτό Κώδικα](../how-to-contribute/).
 
-## Launching your own open source project
+## Ξεκινώντας το δικό σας πρότζεκτ ανοιχτού κώδικα
 
-There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+Δεν υπάρχει ιδανική στιγμή για να ανοίξετε το πρότζεκτ σας. Μπορείτε να ανοίξετε τον κώδικα μιας ιδέας, μιας εργασίας σε εξέλιξη ή μετά από χρόνια κλειστού κώδικα.
 
-Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+Σε γενικές γραμμές, θα πρέπει να ανοίγετε το πρότζεκτ σας όταν αισθάνεστε άνετα να αφήσετε άλλους να δουν και να δώσουν ανατροφοδότηση σχετικά με το πρότζεκτ σας.
 
-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)
+* [Άδεια χρήσης ανοικτού κώδικα](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)
 * [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change)
-* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
-* [Code of conduct](../code-of-conduct/)
+* [Κατευθυντήριες γραμμές για τη συμβολή](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Κώδικας δεοντολογίας](../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.
+Ως συντηρητής, αυτά τα στοιχεία θα σας βοηθήσουν να επικοινωνήσετε τις προσδοκίες, να διαχειριστείτε τις συνεισφορές και να προστατεύσετε τα νομικά δικαιώματα όλων (συμπεριλαμβανομένων των δικών σας). Αυξάνουν σημαντικά τις πιθανότητές σας να έχετε μια θετική εμπειρία.
 
-If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+Εάν το πρότζεκτ σας βρίσκεται στο GitHub, η τοποθέτηση αυτών των αρχείων στον ριζικό σας κατάλογο με τα συνιστώμενα ονόματα αρχείων θα βοηθήσει το GitHub να τα αναγνωρίσει και να τα εμφανίσει αυτόματα στους αναγνώστες σας.
 
-### Choosing a license
+### Επιλέγοντας μια άδεια
 
-An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+Μια άδεια ανοικτού κώδικα εγγυάται ότι άλλοι μπορούν να χρησιμοποιούν, να αντιγράφουν, να τροποποιούν και να συνεισφέρουν στο πρότζεκτ σας χωρίς επιπτώσεις. Σας προστατεύει επίσης από δύσκολες νομικές καταστάσεις. **Πρέπει να συμπεριλάβετε μια άδεια χρήσης όταν ξεκινάτε ένα πρότζεκτ ανοικτού κώδικα**.
 
-Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+Η νομική εργασία δεν είναι διασκεδαστική. Τα καλά νέα είναι ότι μπορείτε να αντιγράψετε και να επικολλήσετε μια υπάρχουσα άδεια χρήσης στο αποθετήριό σας. Θα χρειαστεί μόνο ένα λεπτό για να προστατέψετε τη σκληρή δουλειά σας.
 
-[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 the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+Οι [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) και [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) είναι οι πιο δημοφιλείς άδειες ανοικτού κώδικα, αλλά [υπάρχουν και άλλες επιλογές](https://choosealicense.com) για να επιλέξετε.
 
-When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+Όταν δημιουργείτε ένα νέο πρότζεκτ στο GitHub, σας δίνεται η δυνατότητα να επιλέξετε μια άδεια χρήσης. Η συμπερίληψη μιας άδειας ανοικτού κώδικα θα καταστήσει το πρότζεκτ σας στο GitHub ανοικτού κώδικα.
 
-![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+![Διαλέξτε μια άδεια](/assets/images/starting-a-project/repository-license-picker.png)
 
-If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+Αν έχετε άλλες ερωτήσεις ή ανησυχίες σχετικά με τις νομικές πτυχές της διαχείρισης ενός έργου ανοικτού κώδικα, [σας καλύπτουμε](../legal/).
 
-### Writing a README
+### Γράφοντας ένα README
 
-READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+Τα READMEs κάνουν περισσότερα από το να εξηγούν πώς να χρησιμοποιήσετε το πρότζεκτ σας. Εξηγούν επίσης γιατί το πρότζεκτ σας έχει σημασία και τι μπορούν να κάνουν οι χρήστες σας με αυτό.
 
-In your README, try to answer the following questions:
+Στο README σας, προσπαθήστε να απαντήσετε στις ακόλουθες ερωτήσεις:
 
-* What does this project do?
-* Why is this project useful?
-* How do I get started?
-* Where can I get more help, if I need it?
+* Τι κάνει αυτό το πρότζεκτ;
+* Γιατί είναι χρήσιμο αυτό το πρότζεκτ;
+* Πώς μπορώ να ξεκινήσω;
+* Πού μπορώ να βρω περισσότερη βοήθεια, αν τη χρειαστώ;
 
-You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+Μπορείτε να χρησιμοποιήσετε το README για να απαντήσετε σε άλλες ερωτήσεις, όπως πώς χειρίζεστε τις συνεισφορές, ποιοι είναι οι στόχοι του έργου και πληροφορίες σχετικά με τις άδειες χρήσης και την απόδοση. Αν δεν θέλετε να δέχεστε συνεισφορές ή αν το πρότζεκτ σας δεν είναι ακόμα έτοιμο για παραγωγή, γράψτε αυτές τις πληροφορίες.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
-  Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+  Καλύτερη τεκμηρίωση σημαίνει περισσότερους χρήστες, λιγότερα αιτήματα υποστήριξης και περισσότερους συνεργάτες. (...) Να θυμάστε ότι οι αναγνώστες σας δεν είναι εσείς. Υπάρχουν άνθρωποι που μπορεί να έρθουν σε ένα πρότζεκτ που έχουν εντελώς διαφορετικές εμπειρίες.
   <p markdown="1" class="pquote-credit">
-— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+- @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
   </p>
 </aside>
 
-Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+Μερικές φορές, οι άνθρωποι αποφεύγουν να γράψουν ένα README επειδή αισθάνονται ότι το πρότζεκτ είναι ημιτελές ή δεν θέλουν συνεισφορές. Όλοι αυτοί είναι πολύ καλοί λόγοι για να γράψετε ένα τέτοιο κείμενο.
 
-For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+Για περισσότερη έμπνευση, δοκιμάστε να χρησιμοποιήσετε τον ["Make a README" guide](https://www.makeareadme.com/) του @dguo ή το [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) του @PurpleBooth για να γράψετε ένα πλήρες README.
 
-When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+Όταν συμπεριλαμβάνετε ένα αρχείο README στον ριζικό κατάλογο, το GitHub θα το εμφανίσει αυτόματα στην αρχική σελίδα του αποθετηρίου.
 
-### Writing your contributing guidelines
+### Γράφοντας τις κατευθυντήριες γραμμές συνεισφοράς σας
 
-A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+Ένα αρχείο CONTRIBUTING λέει στο κοινό σας πώς να συμμετάσχει στο πρότζεκτ σας. Για παράδειγμα, θα μπορούσατε να συμπεριλάβετε πληροφορίες σχετικά με:
 
-* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
-* How to suggest a new feature
-* How to set up your environment and run tests
+* Πώς να καταθέσετε μια αναφορά σφάλματος (δοκιμάστε να χρησιμοποιήσετε τα [πρότυπα issue και pull request](https://github.com/blog/2111-issue-and-pull-request-templates))
+* Πώς να προτείνετε ένα νέο χαρακτηριστικό
+* Πώς να ρυθμίσετε το περιβάλλον σας και να εκτελέσετε δοκιμές
 
-In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+Εκτός από τις τεχνικές λεπτομέρειες, ένα αρχείο ΣΥΜΒΟΛΗΣ είναι μια ευκαιρία να επικοινωνήσετε τις προσδοκίες σας για τις συνεισφορές, όπως:
 
-* The types of contributions you're looking for
-* Your roadmap or vision for the project
-* How contributors should (or should not) get in touch with you
+* Τα είδη των συνεισφορών που αναζητάτε
+* Ο οδικός χάρτης ή το όραμά σας για το πρότζεκτ
+* Πώς οι συνεργάτες θα πρέπει (ή δεν θα πρέπει) να έρθουν σε επαφή μαζί σας
 
-Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+Χρησιμοποιώντας ένα ζεστό, φιλικό τόνο και προσφέροντας συγκεκριμένες προτάσεις για συνεισφορές (όπως η συγγραφή τεκμηρίωσης ή η δημιουργία ενός ιστότοπου) μπορείτε να κάνετε τους νεοεισερχόμενους να αισθάνονται ευπρόσδεκτοι και ενθουσιασμένοι να συμμετάσχουν.
 
-For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+Για παράδειγμα, το [Active Admin](https://github.com/activeadmin/activeadmin/) ξεκινά [τον οδηγό συνεισφοράς του](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) με:
 
-> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+> Πρώτα απ' όλα, σας ευχαριστώ που σκέφτεστε να συνεισφέρετε στο Active Admin. Είναι άνθρωποι σαν εσάς που κάνουν το Active Admin ένα τόσο σπουδαίο εργαλείο.
 
-In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+Στα πρώτα στάδια του έργου σας, το αρχείο CONTRIBUTING μπορεί να είναι απλό. Θα πρέπει πάντα να εξηγείτε πώς να αναφέρετε σφάλματα ή θέματα αρχείων, καθώς και τυχόν τεχνικές απαιτήσεις (όπως δοκιμές) για να κάνετε μια συνεισφορά.
 
-Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+Με την πάροδο του χρόνου, μπορεί να προσθέσετε και άλλες συχνές ερωτήσεις στο αρχείο ΣΥΝΔΡΟΜΗ. Η καταγραφή αυτών των πληροφοριών σημαίνει ότι λιγότεροι άνθρωποι θα σας κάνουν τις ίδιες ερωτήσεις ξανά και ξανά.
 
-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/).
+Για περισσότερη βοήθεια σχετικά με τη σύνταξη του αρχείου 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.
 
-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.
+Συνδέστε το αρχείο CONTRIBUTING από το README, ώστε να το βλέπουν περισσότεροι άνθρωποι. Εάν [τοποθετήσετε το αρχείο CONTRIBUTING στο αποθετήριο του έργου σας](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), το GitHub θα συνδέει αυτόματα το αρχείο σας όταν ένας συνεργάτης δημιουργεί ένα ζήτημα ή ανοίγει ένα αίτημα έλξης.
 
-![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+![Οδηγίες συνεισφοράς](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
-### Establishing a code of conduct
+### Καθιέρωση κώδικα δεοντολογίας
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
-  We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+  Όλοι έχουμε βιώσει εμπειρίες όπου αντιμετωπίσαμε κάτι που πιθανώς ήταν κατάχρηση, είτε ως συντηρητής που προσπαθούσε να εξηγήσει γιατί κάτι έπρεπε να γίνει με έναν συγκεκριμένο τρόπο, είτε ως χρήστης... που έκανε μια απλή ερώτηση. (...) Ένας κώδικας δεοντολογίας γίνεται ένα έγγραφο στο οποίο γίνεται εύκολα αναφορά και το οποίο μπορεί να συνδεθεί και το οποίο δείχνει ότι η ομάδα σας παίρνει τον εποικοδομητικό διάλογο πολύ σοβαρά.
   <p markdown="1" class="pquote-credit">
-— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+- @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
   </p>
 </aside>
 
-Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+Τέλος, ένας κώδικας δεοντολογίας βοηθά στον καθορισμό βασικών κανόνων συμπεριφοράς για τους συμμετέχοντες στο πρότζεκτ σας. Αυτό είναι ιδιαίτερα πολύτιμο αν ξεκινάτε ένα πρότζεκτ ανοικτού κώδικα για μια κοινότητα ή μια εταιρεία. Ένας κώδικας δεοντολογίας σας δίνει τη δυνατότητα να διευκολύνετε την υγιή, εποικοδομητική συμπεριφορά της κοινότητας, γεγονός που θα μειώσει το άγχος σας ως συντηρητής.
 
-For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+Για περισσότερες πληροφορίες, ανατρέξτε στον οδηγό [Κώδικας δεοντολογίας](../code-of-conduct/).
 
-In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+Εκτός από το να γνωστοποιεί _πώς_ περιμένετε από τους συμμετέχοντες να συμπεριφέρονται, ένας κώδικας συμπεριφοράς τείνει επίσης να περιγράφει ποιους αφορούν αυτές οι προσδοκίες, πότε ισχύουν και τι πρέπει να γίνει σε περίπτωση παραβίασης.
 
-Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+Όπως οι άδειες ανοικτού κώδικα, έτσι και για τους κώδικες δεοντολογίας υπάρχουν αναδυόμενα πρότυπα, ώστε να μην χρειάζεται να γράψετε τους δικούς σας. Το [Contributor Covenant](https://contributor-covenant.org/) είναι ένας drop-in κώδικας συμπεριφοράς που χρησιμοποιείται από [πάνω από 40.000 πρότζεκτ ανοικτού κώδικα](https://www.contributor-covenant.org/adopters), συμπεριλαμβανομένων των Kubernetes, Rails και Swift. Ανεξάρτητα από το κείμενο που χρησιμοποιείτε, θα πρέπει να είστε προετοιμασμένοι να επιβάλλετε τον κώδικα συμπεριφοράς σας όταν είναι απαραίτητο.
 
-Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+Επικολλήστε το κείμενο απευθείας σε ένα αρχείο CODE_OF_CONDUCT στο αποθετήριό σας. Κρατήστε το αρχείο στο ριζικό κατάλογο του έργου σας, ώστε να είναι εύκολο να το βρείτε, και παραπέμψτε σε αυτό από το README σας.
 
-## Naming and branding your project
+## Ονομασία και branding του έργου σας
 
-Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+Το branding είναι κάτι περισσότερο από ένα φανταχτερό λογότυπο ή ένα πιασάρικο όνομα έργου. Έχει να κάνει με το πώς μιλάτε για το πρότζεκτ σας και σε ποιον απευθύνεστε με το μήνυμά σας.
 
-### Choosing the right name
+### Επιλέγοντας το σωστό όνομα
 
-Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+Διαλέξτε ένα όνομα που να είναι εύκολο να το θυμάστε και, ιδανικά, να δίνει μια ιδέα για το τι κάνει το πρότζεκτ. Για παράδειγμα:
 
-* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
-* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+* [Sentry](https://github.com/getsentry/sentry) παρακολουθεί τις εφαρμογές για αναφορά ατυχημάτων
+* [Thin](https://github.com/macournoyer/thin) είναι ένας γρήγορος και απλός διακομιστής ιστοσελίδων Ruby
 
-If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+Αν βασίζεστε σε ένα υπάρχον πρότζεκτ, η χρήση του ονόματός του ως πρόθεμα μπορεί να βοηθήσει να αποσαφηνιστεί τι κάνει το πρότζεκτ σας (για παράδειγμα, το [node-fetch](https://github.com/bitinn/node-fetch) φέρνει το `window.fetch` στο Node.js).
 
-Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+Σκεφτείτε πάνω απ' όλα τη σαφήνεια. Τα λογοπαίγνια είναι διασκεδαστικά, αλλά να θυμάστε ότι ορισμένα αστεία μπορεί να μη μεταφράζονται σε άλλους πολιτισμούς ή σε ανθρώπους με διαφορετικές εμπειρίες από εσάς. Ορισμένοι από τους δυνητικούς χρήστες σας μπορεί να είναι υπάλληλοι της εταιρείας: δεν θέλετε να τους κάνετε να νιώσουν άβολα όταν θα πρέπει να εξηγήσουν το πρότζεκτ σας στη δουλειά!
 
-### Avoiding name conflicts
+### Αποφυγή συγκρούσεων ονομάτων
 
-[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+[Ελέγξτε για πρότζεκτ ανοικτού κώδικα με παρόμοιο όνομα](http://ivantomic.com/projects/ospnc/), ειδικά αν μοιράζεστε την ίδια γλώσσα ή το ίδιο οικοσύστημα. Εάν το όνομά σας συμπίπτει με ένα δημοφιλές υπάρχον πρότζεκτ, μπορεί να προκαλέσετε σύγχυση στο κοινό σας.
 
-If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+Αν θέλετε έναν ιστότοπο, μια λαβή στο Twitter ή άλλες ιδιότητες που θα αντιπροσωπεύουν το πρότζεκτ σας, βεβαιωθείτε ότι μπορείτε να πάρετε τα ονόματα που θέλετε. Ιδανικά, [κρατήστε αυτά τα ονόματα τώρα](https://instantdomainsearch.com/) για να είστε ήσυχοι, ακόμη και αν δεν σκοπεύετε να τα χρησιμοποιήσετε ακόμη.
 
-Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+Βεβαιωθείτε ότι το όνομα του έργου σας δεν παραβιάζει κανένα εμπορικό σήμα. Μια εταιρεία μπορεί να σας ζητήσει αργότερα να καταργήσετε το πρότζεκτ σας ή ακόμη και να κινηθεί νομικά εναντίον σας. Δεν αξίζει τον κόπο να το ρισκάρετε.
 
-You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+Μπορείτε να ελέγξετε τη [WIPO Global Brand Database] (http://www.wipo.int/branddb/en/) για συγκρούσεις εμπορικών σημάτων. Αν είστε σε μια εταιρεία, αυτό είναι ένα από τα πράγματα με τα οποία μπορεί να σας βοηθήσει η [νομική ομάδα](../legal/).
 
-Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+Τέλος, κάντε μια γρήγορη αναζήτηση στο Google για το όνομα του έργου σας. Θα μπορούν οι άνθρωποι να βρουν εύκολα το πρότζεκτ σας; Εμφανίζεται κάτι άλλο στα αποτελέσματα της αναζήτησης που δεν θα θέλατε να δουν;
 
-### How you write (and code) affects your brand, too!
+### Ο τρόπος που γράφετε (και κωδικοποιείτε) επηρεάζει και το brand σας!
 
-Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+Καθ' όλη τη διάρκεια του έργου σας, θα γράφετε πολύ: READMEs, tutorials, έγγραφα της κοινότητας, απαντήσεις σε θέματα, ίσως ακόμη και ενημερωτικά δελτία και λίστες αλληλογραφίας.
 
-Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+Είτε πρόκειται για επίσημη τεκμηρίωση είτε για ένα απλό μήνυμα ηλεκτρονικού ταχυδρομείου, το στυλ γραφής σας αποτελεί μέρος της επωνυμίας του έργου σας. Σκεφτείτε πώς θα μπορούσατε να φανείτε στο κοινό σας και αν αυτός είναι ο τόνος που θέλετε να μεταδώσετε.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+  Προσπάθησα να συμμετέχω σε κάθε νήμα της λίστας αλληλογραφίας και να δείχνω υποδειγματική συμπεριφορά, να είμαι καλός με τους ανθρώπους, να παίρνω σοβαρά τα θέματά τους και να προσπαθώ να είμαι χρήσιμος συνολικά. Μετά από λίγο, οι άνθρωποι έμειναν κοντά μου όχι μόνο για να κάνουν ερωτήσεις, αλλά και για να βοηθήσουν με τις απαντήσεις, και προς μεγάλη μου χαρά, μιμούνταν το στυλ μου.
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+- @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
-Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+Η χρήση θερμής, περιεκτικής γλώσσας (όπως "τους", ακόμη και όταν αναφέρεται σε ένα άτομο) μπορεί να συμβάλει σημαντικά στο να γίνει το πρότζεκτ σας φιλόξενο για τους νέους συνεισφέροντες. Μείνετε σε απλή γλώσσα, καθώς πολλοί από τους αναγνώστες σας μπορεί να μην έχουν ως μητρική γλώσσα τα αγγλικά.
 
-Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+Πέρα από τον τρόπο που γράφετε λέξεις, το στυλ κωδικοποίησης μπορεί επίσης να γίνει μέρος της επωνυμίας του έργου σας. Το [Angular](https://angular.io/guide/styleguide) και το [jQuery](https://contribute.jquery.org/style-guide/js/) είναι δύο παραδείγματα πρότζεκτ με αυστηρό στυλ κωδικοποίησης και κατευθυντήριες γραμμές.
 
-It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+Δεν είναι απαραίτητο να γράψετε έναν οδηγό στυλ για το πρότζεκτ σας όταν ξεκινάτε, και μπορεί να διαπιστώσετε ότι σας αρέσει να ενσωματώνετε διαφορετικά στυλ κωδικοποίησης στο πρότζεκτ σας ούτως ή άλλως. Θα πρέπει όμως να προβλέψετε πώς το στυλ γραφής και κωδικοποίησης που χρησιμοποιείτε μπορεί να προσελκύσει ή να αποθαρρύνει διαφορετικούς τύπους ανθρώπων. Τα πρώτα στάδια του έργου σας είναι η ευκαιρία σας να δημιουργήσετε το προηγούμενο που επιθυμείτε.
 
-## 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.
+Είστε έτοιμοι να ανοίξετε το πρότζεκτ σας; Ακολουθεί ένας κατάλογος ελέγχου για να σας βοηθήσει. Έχετε τσεκάρει όλα τα κουτάκια; Είστε έτοιμοι να ξεκινήσετε! [Κάντε κλικ στο "publish"](https://help.github.com/articles/making-a-private-repository-public/) και χτυπήστε τον εαυτό σας στην πλάτη.
 
-**Documentation**
+**Έγγραφα**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-    Project has a LICENSE file with an open source license
+    Το πρότζεκτ έχει ένα αρχείο LICENSE με άδεια χρήσης ανοικτού κώδικα
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+    Το πρότζεκτ έχει βασική τεκμηρίωση (README, CONTRIBUTING, CODE_OF_CONDUCT)
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+    Το όνομα είναι εύκολο να το θυμάται κανείς, δίνει μια ιδέα για το τι κάνει το πρότζεκτ και δεν έρχεται σε σύγκρουση με ένα υπάρχον πρότζεκτ ή παραβιάζει εμπορικά σήματα.
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-    The issue queue is up-to-date, with issues clearly organized and labeled
+    Η ουρά θεμάτων είναι ενημερωμένη, με τα θέματα σαφώς οργανωμένα και επισημασμένα.
   </label>
 </div>
 
-**Code**
+**Κώδικας**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    Project uses consistent code conventions and clear function/method/variable names
+    Το πρότζεκτ χρησιμοποιεί συνεπείς συμβάσεις κώδικα και σαφή ονόματα συναρτήσεων/μεθόδων/μεταβλητών
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    The code is clearly commented, documenting intentions and edge cases
+    Ο κώδικας είναι σαφώς σχολιασμένος, τεκμηριώνοντας τις προθέσεις και τις ακραίες περιπτώσεις
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+    Δεν υπάρχει ευαίσθητο υλικό στο ιστορικό αναθεωρήσεων, στα ζητήματα ή στα αιτήματα έλξης (για παράδειγμα, κωδικοί πρόσβασης ή άλλες μη δημόσιες πληροφορίες).
   </label>
 </div>
 
-**People**
+**Άνθρωποι**
 
-If you're an individual:
+Αν είστε άτομο:
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  Έχετε μιλήσει με το νομικό τμήμα ή/και έχετε κατανοήσει τις πολιτικές IP και ανοιχτού κώδικα της εταιρείας σας (αν είστε υπάλληλος κάπου)
   </label>
 </div>
 
-If you're a company or organization:
+Εάν είστε εταιρεία ή οργανισμός:
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    You've talked to your legal department
+    Μιλήσατε με το νομικό σας τμήμα
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    You have a marketing plan for announcing and promoting the project
+    Έχετε σχέδιο μάρκετινγκ για την ανακοίνωση και την προώθηση του έργου
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+    Κάποιος που έχει δεσμευτεί να διαχειρίζεται τις αλληλεπιδράσεις της κοινότητας (απάντηση σε θέματα, εξέταση και συγχώνευση αιτημάτων έλξης)
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    At least two people have administrative access to the project
+    Τουλάχιστον δύο άτομα έχουν διοικητική πρόσβαση στο πρότζεκτ
   </label>
 </div>
 
-## You did it!
+## Τα καταφέρατε!
 
-Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.
+Συγχαρητήρια για την ανοιχτή διάθεση του πρώτου σας έργου. Ανεξάρτητα από το αποτέλεσμα, η δημόσια εργασία είναι ένα δώρο στην κοινότητα. Με κάθε δέσμευση, σχόλιο και αίτηση έλξης, δημιουργείτε ευκαιρίες για τον εαυτό σας και για τους άλλους να μάθουν και να αναπτυχθούν.

From 2d54500e9952499bfbda425f320d0d368400fa29 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 20 Sep 2022 12:04:19 +0300
Subject: [PATCH 379/749] Translate metrics.md

---
 _articles/el/metrics.md | 120 ++++++++++++++++++++--------------------
 1 file changed, 60 insertions(+), 60 deletions(-)

diff --git a/_articles/el/metrics.md b/_articles/el/metrics.md
index 1c1a22eefe2..ab1ff2adf6a 100644
--- a/_articles/el/metrics.md
+++ b/_articles/el/metrics.md
@@ -10,119 +10,119 @@ related:
   - best-practices
 ---
 
-## Why measure anything?
+## Γιατί να μετρήσουμε οτιδήποτε;
 
-Data, when used wisely, can help you make better decisions as an open source maintainer.
+Τα δεδομένα, όταν χρησιμοποιούνται με σύνεση, μπορούν να σας βοηθήσουν να λάβετε καλύτερες αποφάσεις ως συντηρητής ανοικτού κώδικα.
 
-With more information, you can:
+Με περισσότερες πληροφορίες, μπορείτε:
 
-* Understand how users respond to a new feature
-* Figure out where new users come from
-* Identify, and decide whether to support, an outlier use case or functionality
-* Quantify your project's popularity
-* Understand how your project is used
-* Raise money through sponsorships and grants
+* Κατανόηση του τρόπου με τον οποίο οι χρήστες ανταποκρίνονται σε ένα νέο χαρακτηριστικό
+* Ανακαλύψτε από πού προέρχονται οι νέοι χρήστες
+* Εντοπισμός και απόφαση σχετικά με την υποστήριξη μιας περίπτωσης χρήσης ή μιας λειτουργικότητας που ξεφεύγει από τα συνηθισμένα
+* Ποσοτικοποιήστε τη δημοτικότητα του πρότζεκτ σας
+* Κατανοήστε πώς χρησιμοποιείται το πρότζεκτ σας
+* Συγκέντρωση χρημάτων μέσω χορηγιών και επιχορηγήσεων
 
-For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+Για παράδειγμα, το [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) διαπιστώνει ότι το Google Analytics τους βοηθάει να θέτουν προτεραιότητες στην εργασία τους:
 
-> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+> Το Homebrew παρέχεται δωρεάν και διευθύνεται εξ ολοκλήρου από εθελοντές στον ελεύθερο χρόνο τους. Ως αποτέλεσμα, δεν έχουμε τους πόρους για να κάνουμε λεπτομερείς μελέτες χρηστών του Homebrew για να αποφασίσουμε πώς θα σχεδιάσουμε καλύτερα τα μελλοντικά χαρακτηριστικά και να δώσουμε προτεραιότητα στις τρέχουσες εργασίες. Οι ανώνυμες συγκεντρωτικές αναλύσεις χρηστών μας επιτρέπουν να δώσουμε προτεραιότητα στις διορθώσεις και τα χαρακτηριστικά με βάση το πώς, πού και πότε οι χρήστες χρησιμοποιούν το Homebrew.
 
-Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+Η δημοτικότητα δεν είναι το παν. Όλοι ασχολούνται με τον ανοιχτό κώδικα για διαφορετικούς λόγους. Αν ο στόχος σας ως συντηρητής ανοιχτού κώδικα είναι να επιδείξετε τη δουλειά σας, να είστε διαφανείς σχετικά με τον κώδικά σας ή απλά να διασκεδάσετε, οι μετρήσεις μπορεί να μην είναι σημαντικές για εσάς.
 
-If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+Αν _ενδιαφέρεστε_ να κατανοήσετε το πρότζεκτ σας σε βαθύτερο επίπεδο, διαβάστε παρακάτω για τρόπους ανάλυσης της δραστηριότητας του έργου σας.
 
-## Discovery
+## Ανακάλυψη
 
-Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+Πριν κάποιος μπορεί να χρησιμοποιήσει ή να συνεισφέρει στο πρότζεκτ σας, πρέπει να γνωρίζει ότι υπάρχει. Ρωτήστε τον εαυτό σας: _βρίσκουν οι άνθρωποι αυτό το πρότζεκτ;_
 
-![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
+![Διάγραμμα κυκλοφορίας](/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:
+Εάν το πρότζεκτ σας φιλοξενείται στο GitHub, [μπορείτε να δείτε](https://help.github.com/articles/about-repository-graphs/#traffic) πόσοι άνθρωποι μπαίνουν στο πρότζεκτ σας και από πού προέρχονται. Από τη σελίδα του έργου σας, κάντε κλικ στην επιλογή "Insights" και στη συνέχεια στην επιλογή "Traffic". Σε αυτή τη σελίδα, μπορείτε να δείτε: "Το πρότζεκτ σας":
 
-* **Total page views:** Tells you how many times your project was viewed
+* **Συνολικές προβολές σελίδων:** Σας λέει πόσες φορές προβλήθηκε το πρότζεκτ σας
 
-* **Total unique visitors:** Tells you how many people viewed your project
+* **Συνολικοί μοναδικοί επισκέπτες:** Σας λέει πόσοι άνθρωποι είδαν το πρότζεκτ σας
 
-* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+* **Συμβαλλόμενοι ιστότοποι:** Σας λέει από πού προήλθαν οι επισκέπτες. Αυτή η μέτρηση μπορεί να σας βοηθήσει να καταλάβετε πού να προσεγγίσετε το κοινό σας και αν οι προσπάθειες προώθησής σας αποδίδουν.
 
-* **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://help.github.com/articles/about-stars/) μπορεί επίσης να βοηθήσει στην παροχή ενός βασικού μέτρου δημοτικότητας. Αν και τα αστέρια του GitHub δεν συσχετίζονται απαραίτητα με τις λήψεις και τη χρήση, μπορούν να σας δείξουν πόσοι άνθρωποι λαμβάνουν γνώση της εργασίας σας.
 
-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.
+Μπορεί επίσης να θέλετε να [παρακολουθείτε την ανιχνευσιμότητα σε συγκεκριμένα μέρη](https://opensource.com/business/16/6/pirate-metrics): για παράδειγμα, το Google PageRank, την επισκεψιμότητα παραπομπών από τον ιστότοπο του έργου σας ή παραπομπές από άλλα πρότζεκτ ή ιστότοπους ανοικτού κώδικα.
 
-## Usage
+## Χρήση
 
-People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+Οι άνθρωποι βρίσκουν το πρότζεκτ σας σε αυτό το άγριο και τρελό πράγμα που αποκαλούμε διαδίκτυο. Ιδανικά, όταν δουν το πρότζεκτ σας, θα νιώσουν την ανάγκη να κάνουν κάτι. Η δεύτερη ερώτηση που θα πρέπει να κάνετε είναι: _χρησιμοποιούν οι άνθρωποι αυτό το πρότζεκτ;_
 
-If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+Αν χρησιμοποιείτε έναν διαχειριστή πακέτων, όπως το npm ή το RubyGems.org, για να διανείμετε το πρότζεκτ σας, μπορεί να μπορείτε να παρακολουθείτε τις λήψεις του έργου σας.
 
-Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+Κάθε διαχειριστής πακέτων μπορεί να χρησιμοποιεί έναν ελαφρώς διαφορετικό ορισμό της "λήψης" και οι λήψεις δεν συσχετίζονται απαραίτητα με τις εγκαταστάσεις ή τη χρήση, αλλά παρέχει κάποια βάση σύγκρισης. Δοκιμάστε να χρησιμοποιήσετε το [Libraries.io](https://libraries.io/) για να παρακολουθήσετε στατιστικά στοιχεία χρήσης σε πολλούς δημοφιλείς διαχειριστές πακέτων.
 
-If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+Αν το πρότζεκτ σας βρίσκεται στο GitHub, μεταβείτε ξανά στη σελίδα "Traffic". Μπορείτε να χρησιμοποιήσετε το [clone graph](https://github.com/blog/1873-clone-graphs) για να δείτε πόσες φορές έχει κλωνοποιηθεί το πρότζεκτ σας σε μια δεδομένη ημέρα, αναλυτικά με βάση το σύνολο των κλώνων και τους μοναδικούς κλώνους.
 
 ![Clone graph](/assets/images/metrics/clone_graph.png)
 
-If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+Εάν η χρήση είναι χαμηλή σε σύγκριση με τον αριθμό των ατόμων που ανακαλύπτουν το πρότζεκτ σας, υπάρχουν δύο ζητήματα που πρέπει να εξετάσετε. Είτε:
 
-* Your project isn't successfully converting your audience, or
-* You're attracting the wrong audience
+* Το πρότζεκτ σας δεν μετατρέπει με επιτυχία το κοινό σας, ή
+* Προσελκύετε το λάθος κοινό
 
-For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+Για παράδειγμα, αν το πρότζεκτ σας βρεθεί στην πρώτη σελίδα του Hacker News, θα δείτε πιθανότατα μια αύξηση στην ανακάλυψη (επισκεψιμότητα), αλλά ένα χαμηλότερο ποσοστό μετατροπής, επειδή θα φτάσετε σε όλους τους χρήστες του Hacker News. Αν το Ruby πρότζεκτ σας παρουσιάζεται σε ένα συνέδριο Ruby, ωστόσο, είναι πιο πιθανό να δείτε υψηλό ποσοστό μετατροπής από ένα στοχευμένο κοινό.
 
-Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+Προσπαθήστε να καταλάβετε από πού προέρχεται το κοινό σας και ζητήστε από τους άλλους σχόλια για τη σελίδα του πρότζεκτ σας για να καταλάβετε ποιο από αυτά τα δύο ζητήματα αντιμετωπίζετε.
 
-Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+Μόλις μάθετε ότι οι άνθρωποι χρησιμοποιούν το πρότζεκτ σας, ίσως θελήσετε να προσπαθήσετε να καταλάβετε τι κάνουν με αυτό. Χτίζουν πάνω σε αυτό με το να διακλαδώνουν τον κώδικά σας και να προσθέτουν χαρακτηριστικά; Το χρησιμοποιούν για επιστημονικούς ή επιχειρηματικούς σκοπούς;
 
-## Retention
+## Διατήρηση
 
-People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+Οι άνθρωποι βρίσκουν το πρότζεκτ σας και το χρησιμοποιούν. Το επόμενο ερώτημα που θα πρέπει να θέσετε στον εαυτό σας είναι: _Συμβάλλουν οι άνθρωποι σε αυτό το πρότζεκτ;_
 
-It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+Ποτέ δεν είναι πολύ νωρίς για να αρχίσετε να σκέφτεστε τους συνεισφέροντες. Χωρίς τη συμμετοχή άλλων ανθρώπων, κινδυνεύετε να βρεθείτε σε μια ανθυγιεινή κατάσταση όπου το πρότζεκτ σας είναι _δημοφιλές_ (πολλοί το χρησιμοποιούν) αλλά δεν _υποστηρίζεται_ (δεν υπάρχει αρκετός χρόνος συντηρητών για να καλύψει τη ζήτηση).
 
-Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+Η διατήρηση απαιτεί επίσης [εισροή νέων συνεισφερόντων](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), καθώς οι προηγουμένως ενεργοί συνεισφέροντες θα προχωρήσουν τελικά σε άλλα πράγματα.
 
-Examples of community metrics that you may want to regularly track include:
+Παραδείγματα μετρήσεων της κοινότητας που μπορεί να θέλετε να παρακολουθείτε τακτικά περιλαμβάνουν:
 
-* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+* **Συνολικός αριθμός συνεργατών και αριθμός κοινοποιήσεων ανά συνεργάτη:** Σας λέει πόσους συνεργάτες έχετε και ποιοι είναι περισσότερο ή λιγότερο ενεργοί. Στο GitHub, μπορείτε να το δείτε αυτό στην ενότητα "Insights" -> "Contributors". Αυτή τη στιγμή, αυτό το γράφημα μετράει μόνο τους συνεισφέροντες που έχουν δεσμευτεί στον προεπιλεγμένο κλάδο του αποθετηρίου.
 
-![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+![Διάγραμμα συνεισφερόντων](/assets/images/metrics/repo_contributors_specific_graph.png)
 
-* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+* **Πρώτη φορά, περιστασιακοί και επαναλαμβανόμενοι συνεισφέροντες:** Σας βοηθά να παρακολουθείτε αν έχετε νέους συνεισφέροντες και αν επιστρέφουν. (Οι περιστασιακοί συνεισφέροντες είναι συνεισφέροντες με χαμηλό αριθμό κοινοποιήσεων. Το αν αυτό είναι μία δέσμευση, λιγότερες από πέντε δεσμεύσεις ή κάτι άλλο εξαρτάται από εσάς). Χωρίς νέους συνεισφέροντες, η κοινότητα του έργου σας μπορεί να μείνει στάσιμη.
 
-* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+* **Αριθμός ανοιχτών ζητημάτων και ανοιχτών pull request:** Αν αυτοί οι αριθμοί είναι πολύ υψηλοί, ίσως χρειαστείτε βοήθεια με την ταξινόμηση ζητημάτων και τις ανασκοπήσεις κώδικα.
 
-* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+* **Αριθμός _ανοικτών_ θεμάτων και _ανοικτών_ pull request:** Τα ανοικτά θέματα σημαίνουν ότι κάποιος ενδιαφέρεται αρκετά για το πρότζεκτ σας ώστε να ανοίξει ένα θέμα. Αν ο αριθμός αυτός αυξάνεται με την πάροδο του χρόνου, αυτό υποδηλώνει ότι οι άνθρωποι ενδιαφέρονται για το πρότζεκτ σας.
 
-* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+* **Τύποι συνεισφορών:** Για παράδειγμα, μεταβιβάσεις, διόρθωση τυπογραφικών λαθών ή σφαλμάτων ή σχολιασμός ενός θέματος.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
-  Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+  Ο ανοικτός κώδικας είναι κάτι περισσότερο από απλός κώδικας. Τα επιτυχημένα πρότζεκτ ανοικτού κώδικα περιλαμβάνουν συνεισφορές σε κώδικα και τεκμηρίωση μαζί με συζητήσεις σχετικά με αυτές τις αλλαγές.
   <p markdown="1" class="pquote-credit">
-— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+- @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
   </p>
 </aside>
 
-## Maintainer activity
+## Δραστηριότητα συντηρητή
 
-Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+Τέλος, θα πρέπει να κλείσετε το βρόχο διασφαλίζοντας ότι οι συντηρητές του έργου σας είναι σε θέση να διαχειριστούν τον όγκο των συνεισφορών που λαμβάνουν. Το τελευταίο ερώτημα που θα πρέπει να θέσετε στον εαυτό σας είναι: Ανταποκρίνομαι (ή ανταποκρινόμαστε) στην κοινότητά μας;
 
-Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+Οι μη ανταποκρινόμενοι συντηρητές γίνονται τροχοπέδη για τα πρότζεκτ ανοικτού κώδικα. Αν κάποιος υποβάλλει μια συνεισφορά αλλά δεν λαμβάνει ποτέ απάντηση από έναν συντηρητή, μπορεί να αποθαρρυνθεί και να φύγει.
 
-[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+[Έρευνα από τη Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) δείχνει ότι η ανταπόκριση του συντηρητή είναι ένας κρίσιμος παράγοντας για την ενθάρρυνση της επανάληψης των συνεισφορών.
 
-Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+Εξετάστε το ενδεχόμενο να παρακολουθείτε πόσος χρόνος χρειάζεται για να απαντήσετε εσείς (ή κάποιος άλλος συντηρητής) σε συνεισφορές, είτε πρόκειται για ένα θέμα είτε για ένα pull request. Η ανταπόκριση δεν απαιτεί την ανάληψη δράσης. Μπορεί να είναι τόσο απλό όσο το να πείτε: _"Ευχαριστώ για την υποβολή σας! Θα το επανεξετάσω μέσα στην επόμενη εβδομάδα."_
 
-You could also measure the time it takes to move between stages in the contribution process, such as:
+Θα μπορούσατε επίσης να μετρήσετε το χρόνο που απαιτείται για να μετακινηθείτε μεταξύ των σταδίων της διαδικασίας συνεισφοράς, όπως:
 
-* Average time an issue remains open
-* Whether issues get closed by PRs
-* Whether stale issues get closed
-* Average time to merge a pull request
+* Μέσος χρόνος που ένα ζήτημα παραμένει ανοικτό
+* Αν τα θέματα κλείνουν από τις δημόσιες σχέσεις
+* Αν τα θέματα που έχουν μείνει στάσιμα κλείνουν
+* Μέσος χρόνος για τη συγχώνευση ενός pull request
 
-## Use 📊 to learn about people
+## Χρησιμοποιήστε το 📊 για να μάθετε για τους ανθρώπους
 
-Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+Η κατανόηση των μετρήσεων θα σας βοηθήσει να δημιουργήσετε ένα ενεργό, αναπτυσσόμενο πρότζεκτ ανοικτού κώδικα. Ακόμα και αν δεν παρακολουθείτε κάθε μετρική σε ένα ταμπλό, χρησιμοποιήστε το παραπάνω πλαίσιο για να εστιάσετε την προσοχή σας στο είδος της συμπεριφοράς που θα βοηθήσει το πρότζεκτ σας να ευδοκιμήσει.
 
-[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health.
+[CHAOSS](https://chaoss.community/) είναι μια φιλόξενη κοινότητα ανοικτού κώδικα που επικεντρώνεται στην ανάλυση, τις μετρήσεις και το λογισμικό για την κοινοτική υγεία.

From d6dfe5a2e604d2f3d85934074a260ce9cabce243 Mon Sep 17 00:00:00 2001
From: Ash Wilson <smashwilson@github.com>
Date: Tue, 20 Sep 2022 09:23:38 -0400
Subject: [PATCH 380/749] Update Linux Foundation blog link

---
 _articles/de/legal.md      | 2 +-
 _articles/es/legal.md      | 2 +-
 _articles/fa/legal.md      | 2 +-
 _articles/fr/legal.md      | 2 +-
 _articles/hu/legal.md      | 2 +-
 _articles/id/legal.md      | 2 +-
 _articles/ja/legal.md      | 2 +-
 _articles/ko/legal.md      | 2 +-
 _articles/legal.md         | 2 +-
 _articles/ms/legal.md      | 2 +-
 _articles/nl/legal.md      | 2 +-
 _articles/pl/legal.md      | 2 +-
 _articles/pt/legal.md      | 2 +-
 _articles/ro/legal.md      | 2 +-
 _articles/ru/legal.md      | 2 +-
 _articles/ta/legal.md      | 2 +-
 _articles/tr/legal.md      | 2 +-
 _articles/zh-hans/legal.md | 2 +-
 _articles/zh-hant/legal.md | 2 +-
 19 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/_articles/de/legal.md b/_articles/de/legal.md
index e74a64e6176..2c3c850c8d7 100644
--- a/_articles/de/legal.md
+++ b/_articles/de/legal.md
@@ -157,7 +157,7 @@ Längerfristig kann Ihre Rechtsabteilung mehr tun, um dem Unternehmen zu helfen,
 </aside>
 
 * **Was veröffentlichen?** [(Fast) alles?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html). Wenn Ihre Rechtsabteilung die Open-Source-Strategie Ihres Unternehmens versteht und in sie investiert, kann sie Ihnen am besten helfen, anstatt Ihre Bemühungen zu behindern.
-* **Compliance:** Auch wenn Ihr Unternehmen keine Open-Source-Projekte veröffentlicht, verwendet es die Open-Source-Software von anderen. [Bewusstsein darüber und Prozesse dafür](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) helfen, Kopfschmerzen, Produktverzögerungen und Klagen zu vermeiden.
+* **Compliance:** Auch wenn Ihr Unternehmen keine Open-Source-Projekte veröffentlicht, verwendet es die Open-Source-Software von anderen. [Bewusstsein darüber und Prozesse dafür](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) helfen, Kopfschmerzen, Produktverzögerungen und Klagen zu vermeiden.
 
 <aside markdown="1" class="pquote">
 
diff --git a/_articles/es/legal.md b/_articles/es/legal.md
index 01815bf90be..8543e20fd36 100644
--- a/_articles/es/legal.md
+++ b/_articles/es/legal.md
@@ -151,7 +151,7 @@ A largo plazo, tu equipo legal puede hacer m&aacute;s para ayudar a la empresa a
 
 * **Qu&eacute; liberar:** [¿(casi) todo?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Si tu equipo legal entiende e invierte en la estrategia de c&oacute;digo abierto de su empresa, ser&aacute;n m&aacute;s capaces de ayudar en lugar de dificultar tus esfuerzos.
 
-* **Conformidad:** Incluso si tu empresa no libera ning&uacute;n proyecto de c&oacute;digo abierto, utiliza otro software de c&oacute;digo abierto. La [conciencia y el proceso](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) puede prevenir dolores de cabeza, retrasos del producto, y demandas.
+* **Conformidad:** Incluso si tu empresa no libera ning&uacute;n proyecto de c&oacute;digo abierto, utiliza otro software de c&oacute;digo abierto. La [conciencia y el proceso](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) puede prevenir dolores de cabeza, retrasos del producto, y demandas.
 
 <aside markdown="1" class="pquote">
   Las organizaciones deben tener una estrategia de licencia y cumplimiento que se ajuste tanto a categor&iacute;as \["permisiva" y "copyleft"\]. Esto comienza con el mantenimiento de un registro de los t&eacute;rminos de licencia que se aplican al software de c&oacute;digo abierto que est&aacute; utilizando - incluidos subcomponentes y dependencias.
diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index 7bb61289b9e..a160b790bde 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -148,7 +148,7 @@ related:
 
 * **چه چیزهایی را منتشر کنیم:** [(تقریبا) همه چیز؟](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) اگر تیم حقوقی شما استراتژی متن باز شرکت شما را درک کرده و در آن سرمایه‌گذاری کرده باشد، به جای جلوگیری از تلاش‌هایتان، به بهترین وجه به شما کمک می‌کند.
 
-* **سازگاری:** حتی اگر شرکت شما هیچ پروژۀ متن بازی را منتشر نکند، از دیگر نرم‌افزارهای متن باز استفاده می‌کند. [داشتن آگاهی از روند کار](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) می‌تواند از بروز مشکلات بی‌جا، تأخیر در محصول و شکایات جلوگیری کند.
+* **سازگاری:** حتی اگر شرکت شما هیچ پروژۀ متن بازی را منتشر نکند، از دیگر نرم‌افزارهای متن باز استفاده می‌کند. [داشتن آگاهی از روند کار](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) می‌تواند از بروز مشکلات بی‌جا، تأخیر در محصول و شکایات جلوگیری کند.
 
 <aside markdown="1" class="pquote">
  شرکت‌ها باید دارای مجوزها و استراتژی‌های انطباقی باشند که متناسب با هر دو دستۀ [«اختیاری» و «کپی‌لفت»] باشد. این کار با ثبت سوابق مجوزهایی که برای نرم‌افزارهای متن باز مورد استفاده شما اعمال می‌شود - از جمله مؤلفه‌های فرعی و وابستگی‌ها - آغاز می‌شود.
diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index f1ca789143c..29d2a217d11 100644
--- a/_articles/fr/legal.md
+++ b/_articles/fr/legal.md
@@ -144,7 +144,7 @@ Si vous publiez le premier projet open source de votre entreprise, ce qui préc
 </aside>
 
 * **Que publier :** [(Presque) tout ?](Http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Si votre équipe juridique comprend et est investis dans la stratégie open source de votre entreprise, ils seront les mieux placés pour vous aider plutôt que d'entraver vos efforts.
-* **Conformité :** Même si votre entreprise ne diffuse aucun projet open source, elle utilise le logiciel open source des autres. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) peut prévenir les maux de tête, les retards de produit et les poursuites judiciaires.
+* **Conformité :** Même si votre entreprise ne diffuse aucun projet open source, elle utilise le logiciel open source des autres. [Awareness and process](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) peut prévenir les maux de tête, les retards de produit et les poursuites judiciaires.
 
 <aside markdown="1" class="pquote">
   Les organisations doivent disposer d'une stratégie de licence et de conformité qui corresponde à la fois aux catégories \["permissive" et "copyleft"\]. Cela commence par garder une trace des conditions de licence qui s'appliquent aux logiciels open source que vous utilisez, y compris les sous-composants et les dépendances.
diff --git a/_articles/hu/legal.md b/_articles/hu/legal.md
index cca7b35181d..3c4d20b2576 100644
--- a/_articles/hu/legal.md
+++ b/_articles/hu/legal.md
@@ -145,7 +145,7 @@ Hosszabb távon a jogi csapat többet tehet azért, hogy segítsen a vállalatna
 </aside>
 
 * **Mit kell kiadni:** [(Majdnem) mindent?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Ha a jogi csapat megérti és hajlandó munkát befektetni a vállalat nyílt forráskódú stratégiájába, akkor az inkább segíteni fog, mint akadályozni.
-* **Megfelelés:** Még ha a céged nem is fejleszt nyílt forráskódot, biztosan használja azt. A [tudatosság és folytonosság](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) megakadályozhatja a fejfájást, a késedelmeket és a pereket.
+* **Megfelelés:** Még ha a céged nem is fejleszt nyílt forráskódot, biztosan használja azt. A [tudatosság és folytonosság](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) megakadályozhatja a fejfájást, a késedelmeket és a pereket.
 
 <aside markdown="1" class="pquote">
   A szervezeteknek rendelkezniük kell olyan licenc- és megfelelőségi stratégiával, amely megfelel mind a „megengedő”, mind a „copyleft” kategóriáknak. Ez azzal kezdődik, hogy nyilvántartást vezetnek az általad használt nyílt forráskódú szoftverekre vonatkozó licencfeltételekről, beleértve az alkomponenseket és a függőségeket.
diff --git a/_articles/id/legal.md b/_articles/id/legal.md
index a6110582127..8bf7069ada9 100644
--- a/_articles/id/legal.md
+++ b/_articles/id/legal.md
@@ -144,7 +144,7 @@ Dalam jangka panjang, tim hukum Anda bisa melakukan lebih banyak lagi dengan mem
 </aside>
 
 * **Apa yang dirilis:** [(Hampir) semuanya?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) jika tim hukum Anda memahami dan berinvestasi pada strategi open source perusahaan Anda, mereka akan banyak membantu dibandingkan merugikan Anda.
-* **Kesesuaian:** Meskipun perusahaan Anda tidak merilis proyek open source, perusahaan Anda menggunakan perangkat lunak open source milik orang lain. [Kewaspadaandan proses](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) bisa mencegah masalah, keterlambatan produk, dan tuntutan hukum.
+* **Kesesuaian:** Meskipun perusahaan Anda tidak merilis proyek open source, perusahaan Anda menggunakan perangkat lunak open source milik orang lain. [Kewaspadaandan proses](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) bisa mencegah masalah, keterlambatan produk, dan tuntutan hukum.
 
 <aside markdown="1" class="pquote">
   Organisasi harus memiliki lisensi dan strategi penyesuaian yang sesuai untuk kategori \["permissive" dan "copyleft"\]. Hal ini dimulai dengan menyimpan catatan dari istilah lisensi yang digunakan pada perangkat lunak open source yang Anda gunakan — termasuk sub komponen dan ketergantungannya.
diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md
index 9fa40fcc7af..a21666763ac 100644
--- a/_articles/ja/legal.md
+++ b/_articles/ja/legal.md
@@ -145,7 +145,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
 </aside>
 
 * **何をリリースすべきですか？：** [(ほぼ)すべて？](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) もし法務部門が企業のオープンソース戦略を理解し、それに投資している場合は、あなたの努力を妨害するよりもむしろ助けとなってくれるでしょう。
-* **コンプライアンス：** たとえあなたの企業が 1 つもオープンソースプロジェクトをリリースしていないとしても、他の人のオープンソースソフトウェアを使っているはずです。 [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+* **コンプライアンス：** たとえあなたの企業が 1 つもオープンソースプロジェクトをリリースしていないとしても、他の人のオープンソースソフトウェアを使っているはずです。 [Awareness and process](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
 
 <aside markdown="1" class="pquote">
 組織は、\[「寛容」と「コピーレフト」\]の両方のカテゴリにフィットするライセンス戦略、コンプライアンス戦略を確立しなければなりません。まずは使っているオープンソースソフトウェアとそのサブコンポーネント、依存関係に適用されているライセンス条項の記録を保持する所から始めましょう。
diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index 6df7a449146..115e7d6eab8 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -144,7 +144,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
 </aside>
 
 * **공개 할 내용:** [(거의) 다?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) 귀하의 법무팀이 귀하의 회사 오픈소스 전략을 이해하고 투자한다면, 귀하의 노력을 방해하는 것보다 최선을 다 할 수 있습니다.
-* **준수:** 회사가 오픈소스 프로젝트를 공개하지 않더라도, 다른 회사의 오픈 소스 소프트웨어를 사용합니다. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/)는 두통, 제품 지연 및 법적 소송을 예방할 수 있습니다.
+* **준수:** 회사가 오픈소스 프로젝트를 공개하지 않더라도, 다른 회사의 오픈 소스 소프트웨어를 사용합니다. [Awareness and process](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/)는 두통, 제품 지연 및 법적 소송을 예방할 수 있습니다.
 
 <aside markdown="1" class="pquote">
   Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
diff --git a/_articles/legal.md b/_articles/legal.md
index 2a5d5ccb982..7ae7033b668 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -145,7 +145,7 @@ Longer term, your legal team can do more to help the company get more from its i
 </aside>
 
 * **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
-* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
 
 <aside markdown="1" class="pquote">
   Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
diff --git a/_articles/ms/legal.md b/_articles/ms/legal.md
index cf9fba9e94a..46e666f9ec3 100644
--- a/_articles/ms/legal.md
+++ b/_articles/ms/legal.md
@@ -145,7 +145,7 @@ Jangka panjang, pasukan undang-undang anda boleh melakukan lebih banyak perkara
 </aside>
 
 * **Apa yang hendak dilepaskan:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Sekiranya pasukan undang-undang anda memahami dan dilaburkan dalam strategi sumber terbuka syarikat anda, mereka akan dapat membantu dan bukannya menghalang usaha anda.
-* **Pematuhan:** Walaupun syarikat anda tidak mengeluarkan projek sumber terbuka, ia menggunakan perisian sumber terbuka orang lain. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) dapat mencegah sakit kepala, kelewatan produk, dan tuntutan mahkamah.
+* **Pematuhan:** Walaupun syarikat anda tidak mengeluarkan projek sumber terbuka, ia menggunakan perisian sumber terbuka orang lain. [Awareness and process](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) dapat mencegah sakit kepala, kelewatan produk, dan tuntutan mahkamah.
 
 <aside markdown="1" class="pquote">
   Organisasi mesti mempunyai strategi lesen dan pematuhan yang sesuai dengan kedua kategori [["permisive" dan "copyleft" \]. Ini bermula dengan mencatat syarat-syarat pelesenan yang berlaku untuk perisian sumber terbuka yang Anda gunakan - termasuk subkomponen dan dependensi.
diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
index 66881b615df..55a535a933e 100644
--- a/_articles/nl/legal.md
+++ b/_articles/nl/legal.md
@@ -153,7 +153,7 @@ Op de langere termijn kan uw juridische team meer doen om het bedrijf te helpen
 </aside>
 
 * **Wat vrij te geven:** [(Bijna) alles?] (Http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Als uw juridische team het begrijpt en geïnvesteerd in de open source-strategie van uw bedrijf, zullen ze u het beste kunnen helpen in plaats van hinderen.
-* **Naleving:** Zelfs als uw bedrijf geen open source-projecten vrijgeeft, gebruikt het open source-software van anderen. [Bewustwording en proces](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) kan hoofdpijn, productvertragingen, en rechtszaken voorkomen.
+* **Naleving:** Zelfs als uw bedrijf geen open source-projecten vrijgeeft, gebruikt het open source-software van anderen. [Bewustwording en proces](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) kan hoofdpijn, productvertragingen, en rechtszaken voorkomen.
 
 <aside markdown="1" class="pquote">
   Organisaties moeten een licentie- en nalevingsstrategie hebben die past in de categorieën \["tolerant" en "copyleft"\]. Dit begint met het bijhouden van de licentievoorwaarden die van toepassing zijn op de open source-software die u gebruikt, inclusief subcomponenten en afhankelijkheden.
diff --git a/_articles/pl/legal.md b/_articles/pl/legal.md
index 796d4014a97..5cf9cbe07d2 100644
--- a/_articles/pl/legal.md
+++ b/_articles/pl/legal.md
@@ -151,7 +151,7 @@ W dłuższej perspektywie Twój zespół prawny może zrobić więcej, aby pomó
 </aside>
 
 * **Co wydać:** [(Prawie) wszystko?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Jeśli Twój zespół prawny rozumie i jest zaangażowany w strategię otwartego oprogramowania firmy, najlepiej będzie Ci w stanie pomóc, a nie utrudnić wysiłki.
-* **Zgodność:** Nawet jeśli Twoja firma nie wydaje żadnych projektów typu open source, korzysta z oprogramowania innego typu. [Świadomość i proces](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) może zapobiegać bólom głowy, opóźnieniom produktowym, i procesom sądowym.
+* **Zgodność:** Nawet jeśli Twoja firma nie wydaje żadnych projektów typu open source, korzysta z oprogramowania innego typu. [Świadomość i proces](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) może zapobiegać bólom głowy, opóźnieniom produktowym, i procesom sądowym.
 
 <aside markdown="1" class="pquote">
   Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
diff --git a/_articles/pt/legal.md b/_articles/pt/legal.md
index 6c5cbeb0e6d..968e5ce9b31 100644
--- a/_articles/pt/legal.md
+++ b/_articles/pt/legal.md
@@ -145,7 +145,7 @@ A longo prazo, sua equipe jurídica pode fazer mais para ajudar a empresa a obte
 </aside>
 
 * **O que liberar:** [(Quase) tudo?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Se a sua equipe jurídica entender e investir na estratégia open source da sua empresa, ela será mais capaz de ajudar do que atrapalhar seus esforços.
-* **Conformidade:** Mesmo que sua empresa não libere nenhum projeto open source, ela usa o software open source dos outros. [Conscientização e processo](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) pode evitar dores de cabeça, atrasos de produtos e ações judiciais.
+* **Conformidade:** Mesmo que sua empresa não libere nenhum projeto open source, ela usa o software open source dos outros. [Conscientização e processo](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) pode evitar dores de cabeça, atrasos de produtos e ações judiciais.
 
 <aside markdown="1" class="pquote">
   Organizações devem ter uma estratégia de licença e conformidade funcionando que encaixe ambas as categorias \["permissive" e "copyleft"\]. Isso começa com a manutenção de um registro dos termos de licença que se aplicam ao software open source que você está utilizando — incluindo subcomponentes e dependências.
diff --git a/_articles/ro/legal.md b/_articles/ro/legal.md
index ecf5a8c2b47..163daa229de 100644
--- a/_articles/ro/legal.md
+++ b/_articles/ro/legal.md
@@ -165,7 +165,7 @@ Pe termen lung, echipa voastră juridică poate face mai mult pentru a ajuta com
 </aside>
 
 * **Ce să lansezi:** [(Aproape) totul?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Dacă echipa voastră juridică înțelege și este investită în strategia open source a companiei voastre, ei vor fi cel mai bine capabili să te ajute în loc să împiedice eforturile tale.
-* **Conformare:** Chiar dacă compania ta nu lansează niciun proiect cu sursă deschisă, ea folosește software open source al altora. [Conștientizarea și procesul](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) pot preveni dureri de cap, întârzieri de produs, și procese.
+* **Conformare:** Chiar dacă compania ta nu lansează niciun proiect cu sursă deschisă, ea folosește software open source al altora. [Conștientizarea și procesul](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) pot preveni dureri de cap, întârzieri de produs, și procese.
 
 <aside markdown="1" class="pquote">
   <p>
diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md
index c19920212fc..ed3d2ee91dc 100644
--- a/_articles/ru/legal.md
+++ b/_articles/ru/legal.md
@@ -145,7 +145,7 @@ related:
 </aside>
 
 * **Что выпустить:** [(Почти) все](http://tom.preston-werner.com/2011/11/22/open-source-everything.html)? Если ваша юридическая команда понимает и вкладывается в стратегию открытого исходного кода вашей компании, они смогут намного лучше помочь, чем препятствовать вашим усилиям.
-* **Соответствие:** Даже если ваша компания не выпускает проекты с открытым исходным кодом, она использует чужое программное обеспечение с открытым исходным кодом. [Осведомленность и процесс](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) могут предотвратить головные боли, задержки продукта и судебные иски.
+* **Соответствие:** Даже если ваша компания не выпускает проекты с открытым исходным кодом, она использует чужое программное обеспечение с открытым исходным кодом. [Осведомленность и процесс](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) могут предотвратить головные боли, задержки продукта и судебные иски.
 
 <aside markdown="1" class="pquote">
 Организации должны иметь лицензию и стратегию соответствия, которая подходит как для категорий \["разрешающий", так и "авторское лево"\]. Это начинается с записи условий лицензирования, которые применяются к программному обеспечению с открытым исходным кодом, которое вы используете, включая субкомпоненты и зависимости.
diff --git a/_articles/ta/legal.md b/_articles/ta/legal.md
index 21c81b9d6d4..bddb062152b 100644
--- a/_articles/ta/legal.md
+++ b/_articles/ta/legal.md
@@ -144,7 +144,7 @@ Yஉங்கள் திட்டம் **சார்புகள்** கொ
 </aside>
 
 * **எதை வெளியிடுவது:** [(கிட்டத்தட்ட) எல்லாவற்றையும்?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) உங்கள் சட்ட குழு புரிந்துகொண்டு உங்கள் நிறுவனத்தின் திறந்த மூலோபாயத்தில் முதலீடு செய்திருந்தால், உங்கள் முயற்சிகளை தடுப்பதை காட்டிலும் உதவி செய்ய முடியும்.
-* **இணக்கம்:** உங்கள் நிறுவனம் திறந்த மூல திட்டங்களை வெளியிடாவிட்டாலும், அது மற்றவரின் திறந்த மூல மென்பொருள் பயன்படுத்துகிறது. [விழிப்புணர்வு மற்றும் செயல்முறை](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) தலைவலி, தயாரிப்பு தாமதங்கள் மற்றும் வழக்குகள் ஆகியவற்றை தடுக்கலாம்.
+* **இணக்கம்:** உங்கள் நிறுவனம் திறந்த மூல திட்டங்களை வெளியிடாவிட்டாலும், அது மற்றவரின் திறந்த மூல மென்பொருள் பயன்படுத்துகிறது. [விழிப்புணர்வு மற்றும் செயல்முறை](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) தலைவலி, தயாரிப்பு தாமதங்கள் மற்றும் வழக்குகள் ஆகியவற்றை தடுக்கலாம்.
 
 <aside markdown="1" class="pquote">
   நிறுவனங்கள் ["இசைவு தருகிற" and "அளிப்புரிமை"] வகைகளை பொருந்தும் வகையில் உரிமம் மற்றும் இணக்கம் மூலோபாயம் இருக்க வேண்டும். நீங்கள் பயன்படுத்தும் திறந்த மூல மென்பொருளுக்கு பொருந்தும் உரிம விதிகளின் பதிவுகளை வைத்து இது தொடங்குகிறது - துணைக்குழுக்கள் மற்றும் சார்புகள் உட்பட.
diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index 1fc8a7718e4..b32df57eb17 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -145,7 +145,7 @@ Daha uzun vadede hukuk ekibiniz, şirketin açık kaynaklara katılımından dah
 </aside>
 
 * **Neyi yayınlama:** [(Neredeyse) her şey?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Eğer yasal ekibiniz şirketinizin açık kaynaklı stratejisini anlıyor ve yatırım yapıyorsa, çabalarınızı engellemekten ziyade en iyi şekilde yardım edebileceklerdir.
-* **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir.
+* **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir.
 
 <aside markdown="1" class="pquote">
   Kuruluşların hem \["izin verilen" hem de "copyleft"\] kategorilerine uyan bir lisans ve uyum stratejisi olmalıdır. Bu, alt bileşenler ve bağımlılıklar dahil, kullanmakta olduğunuz açık kaynaklı yazılım için geçerli olan lisans terimlerinin kaydını tutmakla başlar.
diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index a9cb908de12..8f8fd202722 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -144,7 +144,7 @@ redirect_from: /zh-cn/legal/
 </aside>
 
 * **发布什么：**[（几乎） 所有？](http://tom.preston-werner.com/2011/11/22/open-source-everything.html)如果你们的法律团队了解并投资于你们公司的开源策略，他们将是你们最好的帮助，而不是阻碍你们的努力。
-* **合规性：**即使你们公司没有发布任何开源项目，他们也会使用别人的开源软件。[意识和过程](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻烦，产品延迟发布和诉讼。
+* **合规性：**即使你们公司没有发布任何开源项目，他们也会使用别人的开源软件。[意识和过程](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻烦，产品延迟发布和诉讼。
 
 <aside markdown="1" class="pquote">
   组织必须具有适合["允许"和"copyleft"]类别的许可协议和合规性策略。首先，记录适用于你们所使用的开源软件的许可条款（包括子组件和依赖项）。
diff --git a/_articles/zh-hant/legal.md b/_articles/zh-hant/legal.md
index 87b7dd670f3..33796840c18 100644
--- a/_articles/zh-hant/legal.md
+++ b/_articles/zh-hant/legal.md
@@ -143,7 +143,7 @@ redirect_from: /zh-tw/legal/
 </aside>
 
 * **發佈什麼：**[（幾乎） 所有？](http://tom.preston-werner.com/2011/11/22/open-source-everything.html)如果你們的法律團隊瞭解並投資於你們公司的開源策略，他們將是你們最好的幫助，而不是阻礙你們的努力。
-* **合規性：**即使你們公司沒有發佈任何開源專案，他們也會使用別人的開源軟件。[意識和過程](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻煩，產品延遲發佈和訴訟。
+* **合規性：**即使你們公司沒有發佈任何開源專案，他們也會使用別人的開源軟件。[意識和過程](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻煩，產品延遲發佈和訴訟。
 
 <aside markdown="1" class="pquote">
   組織必須具有適合["允許"和"copyleft"]類別的許可協議和合規性策略。首先，記錄適用於你們所使用的開源軟件的許可條款（包括子組件和依賴項）。

From 98701df1cedd9c63c0c2609de5089b1489c12b05 Mon Sep 17 00:00:00 2001
From: christolis <work@chris-sdogkos.com>
Date: Wed, 21 Sep 2022 16:15:42 +0100
Subject: [PATCH 381/749] Fix some HTML-Proofer failures

---
 _articles/el/building-community.md | 6 +++---
 _articles/el/how-to-contribute.md  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index 5fb95dccf2a..3174dc5b12d 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -26,8 +26,8 @@ related:
 
 Ξεκινήστε με την τεκμηρίωσή σας:
 
-* **Κάντε εύκολο για κάποιον να χρησιμοποιήσει το πρότζεκτ σας.** [Ένα φιλικό README](../starting-a-project/#writing-a-readme) και σαφή παραδείγματα κώδικα θα διευκολύνουν οποιονδήποτε βρεθεί στο πρότζεκτ σας να ξεκινήσει.
-* **Εξηγήστε με σαφήνεια πώς να συνεισφέρετε**, χρησιμοποιώντας [το αρχείο CONTRIBUTING](../starting-a-project/#writing-your-contributing-guidelines) και διατηρώντας τα θέματά σας ενημερωμένα.
+* **Κάντε εύκολο για κάποιον να χρησιμοποιήσει το πρότζεκτ σας.** [Ένα φιλικό README](../starting-a-project/#γράφοντας-ένα-readme) και σαφή παραδείγματα κώδικα θα διευκολύνουν οποιονδήποτε βρεθεί στο πρότζεκτ σας να ξεκινήσει.
+* **Εξηγήστε με σαφήνεια πώς να συνεισφέρετε**, χρησιμοποιώντας [το αρχείο CONTRIBUTING](../starting-a-project/#γράφοντας-τις-κατευθυντήριες-γραμμές-συνεισφοράς-σας) και διατηρώντας τα θέματά σας ενημερωμένα.
 * **Καλά πρώτα θέματα**: Για να βοηθήσετε τους νέους συνεισφέροντες να ξεκινήσουν, σκεφτείτε ρητά [την επισήμανση θεμάτων που είναι αρκετά απλά για να τα αντιμετωπίσουν οι αρχάριοι](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Στη συνέχεια, το GitHub θα εμφανίσει αυτά τα θέματα σε διάφορα σημεία της πλατφόρμας, αυξάνοντας τις χρήσιμες συνεισφορές και μειώνοντας τις τριβές από τους χρήστες που αντιμετωπίζουν θέματα που είναι πολύ δύσκολα για το επίπεδό τους.
 
 [Η έρευνα του GitHub για τον ανοικτό κώδικα του 2017](http://opensourcesurvey.org/2017/) έδειξε ότι η ελλιπής ή συγκεχυμένη τεκμηρίωση είναι το μεγαλύτερο πρόβλημα για τους χρήστες ανοικτού κώδικα. Η καλή τεκμηρίωση προσκαλεί τους ανθρώπους να αλληλεπιδράσουν με το πρότζεκτ σας. Τελικά, κάποιος θα ανοίξει ένα ζήτημα ή ένα αίτημα. Χρησιμοποιήστε αυτές τις αλληλεπιδράσεις ως ευκαιρίες για να τους μετακινήσετε προς τα κάτω στο χωνί.
@@ -209,7 +209,7 @@ related:
 
 ### Αντιμετωπίστε το README σας ως σύνταγμα
 
-Το README σας είναι [κάτι περισσότερο από ένα σύνολο οδηγιών](../starting-a-project/#writing-a-readme). Είναι επίσης ένα μέρος για να μιλήσετε για τους στόχους σας, το όραμα του προϊόντος και τον οδικό χάρτη. Αν οι άνθρωποι επικεντρώνονται υπερβολικά στη συζήτηση για την αξία ενός συγκεκριμένου χαρακτηριστικού, μπορεί να βοηθήσει να επανεξετάσετε το README σας και να μιλήσετε για το ανώτερο όραμα του πρότζεκτ σας. Η εστίαση στο README σας αποπροσωποποιεί επίσης τη συζήτηση, ώστε να μπορείτε να έχετε μια εποικοδομητική συζήτηση.
+Το README σας είναι [κάτι περισσότερο από ένα σύνολο οδηγιών](../starting-a-project/#γράφοντας-ένα-readme). Είναι επίσης ένα μέρος για να μιλήσετε για τους στόχους σας, το όραμα του προϊόντος και τον οδικό χάρτη. Αν οι άνθρωποι επικεντρώνονται υπερβολικά στη συζήτηση για την αξία ενός συγκεκριμένου χαρακτηριστικού, μπορεί να βοηθήσει να επανεξετάσετε το README σας και να μιλήσετε για το ανώτερο όραμα του πρότζεκτ σας. Η εστίαση στο README σας αποπροσωποποιεί επίσης τη συζήτηση, ώστε να μπορείτε να έχετε μια εποικοδομητική συζήτηση.
 
 ### Επικεντρωθείτε στο ταξίδι, όχι στον προορισμό
 
diff --git a/_articles/el/how-to-contribute.md b/_articles/el/how-to-contribute.md
index b9362f910ac..c524cc06d96 100644
--- a/_articles/el/how-to-contribute.md
+++ b/_articles/el/how-to-contribute.md
@@ -499,7 +499,7 @@ related:
 
 ### 😭 Δεν λαμβάνετε απάντηση.
 
-Ελπίζουμε ότι [ελέγξατε το έργο για σημάδια δραστηριότητας](#a-checklist-before-you-contribute) πριν κάνετε μια συνεισφορά. Ακόμα και σε ένα ενεργό έργο, ωστόσο, είναι πιθανό η συνεισφορά σας να μην λάβει απάντηση.
+Ελπίζουμε ότι [ελέγξατε το έργο για σημάδια δραστηριότητας](#μια-λίστα-ελέγχου-πριν-συνεισφέρετε) πριν κάνετε μια συνεισφορά. Ακόμα και σε ένα ενεργό έργο, ωστόσο, είναι πιθανό η συνεισφορά σας να μην λάβει απάντηση.
 
 Αν δεν έχετε λάβει απάντηση για πάνω από μια εβδομάδα, είναι δίκαιο να απαντήσετε ευγενικά στο ίδιο θέμα, ζητώντας από κάποιον να το αξιολογήσει. Αν γνωρίζετε το όνομα του κατάλληλου ατόμου που θα αξιολογήσει τη συνεισφορά σας, μπορείτε να τον @-αναφέρετε στο ίδιο θέμα.
 

From 10b3051dea5a58139a64f2f734dcc92b00baac53 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Sat, 2 Apr 2022 22:33:38 +0300
Subject: [PATCH 382/749] Add initial files and make some translations

---
 _articles/el/best-practices.md            | 280 ++++++++++++
 _articles/el/building-community.md        | 276 +++++++++++
 _articles/el/code-of-conduct.md           | 114 +++++
 _articles/el/finding-users.md             | 156 +++++++
 _articles/el/getting-paid.md              | 187 ++++++++
 _articles/el/how-to-contribute.md         | 528 ++++++++++++++++++++++
 _articles/el/index.html                   |   6 +
 _articles/el/leadership-and-governance.md | 156 +++++++
 _articles/el/legal.md                     | 158 +++++++
 _articles/el/metrics.md                   | 128 ++++++
 _articles/el/starting-a-project.md        | 356 +++++++++++++++
 _data/locales/el.yml                      |  31 ++
 12 files changed, 2376 insertions(+)
 create mode 100644 _articles/el/best-practices.md
 create mode 100644 _articles/el/building-community.md
 create mode 100644 _articles/el/code-of-conduct.md
 create mode 100644 _articles/el/finding-users.md
 create mode 100644 _articles/el/getting-paid.md
 create mode 100644 _articles/el/how-to-contribute.md
 create mode 100644 _articles/el/index.html
 create mode 100644 _articles/el/leadership-and-governance.md
 create mode 100644 _articles/el/legal.md
 create mode 100644 _articles/el/metrics.md
 create mode 100644 _articles/el/starting-a-project.md
 create mode 100644 _data/locales/el.yml

diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
new file mode 100644
index 00000000000..e3bb39f87d0
--- /dev/null
+++ b/_articles/el/best-practices.md
@@ -0,0 +1,280 @@
+---
+lang: el
+title: Βέλτιστες Πρακτικές για Συντηρητές
+description: Διευκολύνοντας την ζωή σας ως συντηρητής ανοιχτού κώδικα, από την τεκμηρίωση των διαδικασιών μέχρι και την αξιοποίηση της κοινότητάς σας.
+class: best-practices
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+  - metrics
+  - leadership
+---
+
+## What does it mean to be a maintainer?
+
+If you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more.
+
+In the early stages of a project, you're experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you'll find yourself working with your users and contributors more.
+
+Maintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community.
+
+## Documenting your processes
+
+Writing things down is one of the most important things you can do as a maintainer.
+
+Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask.
+
+Writing things down makes it easier to say no when something doesn't fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project.
+
+Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all.
+
+Remember to keep your documentation up-to-date. If you're not able to always do this, delete your outdated documentation or indicate it is outdated so contributors know updates are welcome.
+
+### Write down your project's vision
+
+Start by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well.
+
+Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions.
+
+For example, @lord discovered that having a project vision helped him figure out which requests to spend time on. As a new maintainer, he regretted not sticking to his project's scope when he got his first feature request for [Slate](https://github.com/lord/slate).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
+  I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of a half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
+  <p markdown="1" class="pquote-credit">
+— @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
+  </p>
+</aside>
+
+### Communicate your expectations
+
+Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun.
+
+Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do.
+
+Most people who come across your project don't know anything about you or your circumstances. They may assume you get paid to work on it, especially if it's something they regularly use and depend on. Maybe at one point you put a lot of time into your project, but now you're busy with a new job or family member.
+
+All of this is perfectly okay! Just make sure other people know about it.
+
+If maintaining your project is part-time or purely volunteered, be honest about how much time you have. This is not the same as how much time you think the project requires, or how much time others want you to spend.
+
+Here are a few rules that are worth writing down:
+
+* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_)
+* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_)
+* When it's appropriate to follow up (_for example, "You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread."_)
+* How much time you spend on the project (_for example, "We only spend about 5 hours per week on this project"_)
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors.
+
+### Keep communication public
+
+Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker.
+
+If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes.
+
+That way, anybody who joins your community will have access to the same information as someone who's been there for years.
+
+## Learning to say no
+
+You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists.
+
+Having everything written down, however, helps depersonalize situations when you do need to enforce your rules.
+
+Saying no isn't fun, but  _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_.
+
+Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others.
+
+### Keep the conversation friendly
+
+One of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept.
+
+Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor.
+
+Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards.
+
+If you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
+  The key to handling support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS.
+  <p markdown="1" class="pquote-credit">
+— @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
+  </p>
+</aside>
+
+Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.
+
+It's better to immediately close the contributions you know you don't want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+
+Secondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it's someone's first time. Even if you don't accept their contribution, acknowledge the person behind it and thank them for their interest. It's a big compliment!
+
+If you don't want to accept a contribution:
+
+* **Thank them** for their contribution
+* **Explain why it doesn't fit** into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm.
+* **Link to relevant documentation**, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself.
+* **Close the request**
+
+You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):
+
+![Celery screenshot](/assets/images/best-practices/celery.png)
+
+If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want.
+
+Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it.
+
+Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise.
+
+### Be proactive
+
+To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide.
+
+If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example:
+
+* Fill out a issue or PR template/checklist
+* Open an issue before submitting a PR
+
+If they don't follow your rules, close the issue immediately and point to your documentation.
+
+While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+  Ideally, explain to them and in a CONTRIBUTING.md file how they can get a better indication in the future on what would or would not be accepted before they begin the work.
+  <p markdown="1" class="pquote-credit">
+— @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
+  </p>
+</aside>
+
+Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively.
+
+### Embrace mentorship
+
+Maybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections.
+
+If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first issue,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them.
+
+## Leverage your community
+
+You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work.
+
+### Share the workload
+
+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.
+
+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.
+
+Encouraging others to [share ownership of the project](../building-community/#share-ownership-of-your-project) can greatly reduce your own workload, as @lmccart discovered on her project, [p5.js](https://github.com/processing/p5.js).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
+  I’d been saying, "Yeah, anyone can be involved, you don’t have to have a lot of coding expertise [...]." We had people sign up to come [to an event] and that’s when I was really wondering: is this true, what I’ve been saying? There are gonna be 40 people who show up, and it’s not like I can sit with each of them...But people came together, and it just sort of worked. As soon as one person got it, they could teach their neighbor.
+  <p markdown="1" class="pquote-credit">
+—  @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+  </p>
+</aside>
+
+If you need to step away from your project, either on hiatus or permanently, there's no shame in asking someone else to take over for you.
+
+If other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It's great that so many people want your project to live on!
+
+@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), helped those goals live on even after he stepped away from the project:
+
+> I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down.
+
+### Let others build the solutions they need
+
+If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork.
+
+Forking a project doesn't have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project's vision.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
+  I cater to the 80% use case. If you are one of the unicorns, please fork my work. I won't get offended! My public projects are almost always meant to solve the most common problems; I try to make it easy to go deeper by either forking my work or extending it.
+  <p markdown="1" class="pquote-credit">
+— @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+  </p>
+</aside>
+
+The same applies to a user who really wants a solution that you simply don't have the bandwidth to build. Offering APIs and customization hooks can help others meet their own needs, without having to modify the source directly. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) encouraging plugins for CocoaPods led to "some of the most interesting ideas":
+
+> It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying "no", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform.
+
+## Bring in the robots
+
+Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier.
+
+### Require tests and other checks to improve the quality of your code
+
+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.
+
+If you add tests, make sure to explain how they work in your CONTRIBUTING file.
+
+<aside markdown="1" class="pquote">
+  <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)
+  </p>
+</aside>
+
+### Use tools to automate basic maintenance tasks
+
+The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for them.
+
+There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases
+* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
+* [Danger](https://github.com/danger/danger) helps automate code review
+* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information
+* [dependabot-preview](https://github.com/marketplace/dependabot-preview) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
+
+For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.
+
+To manage your email notifications, you can set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize by priority.
+
+If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept.
+
+However, if your standards are too complicated, they can increase the barriers to contribution. Make sure you're only adding enough rules to make everyone's lives easier.
+
+If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors.
+
+## It's okay to hit pause
+
+Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty.
+
+Perhaps you're feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up.
+
+Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project.
+
+Although it should go without saying, take a break! You shouldn't have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take [a month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) after 14 years of volunteer OSS work.
+
+Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
+  In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
+  <p markdown="1" class="pquote-credit">
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+  </p>
+</aside>
+
+Sometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away.
+
+Do your best to find support for your users and community while you're away from a project. If you can't find the support you need, take a break anyway. Be sure to communicate when you're not available, so people aren't confused by your lack of responsiveness.
+
+Taking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you.
+
+## Take care of yourself first!
+
+Maintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive.
diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
new file mode 100644
index 00000000000..9054102aa78
--- /dev/null
+++ b/_articles/el/building-community.md
@@ -0,0 +1,276 @@
+---
+lang: el
+title: Χτίζοντας Ευπρόσδεκτες Κοινότητες
+description: Χτίζοντας μια κοινωνιά που να ενθαρρύνει τα μέλη της να χρησιμοποιεί, να συνεισφέρει, και να προωθεί το πρότζεκτ σας.
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+  - best-practices
+  - coc
+---
+
+## Setting your project up for success
+
+You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around?
+
+A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back.
+
+### Make people feel welcome
+
+One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+
+As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more.
+
+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.
+
+[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.
+
+* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
+* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
+* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or a small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
+* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+  </p>
+</aside>
+
+The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute.
+
+Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself.
+
+### Document everything
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
+  <p markdown="1" class="pquote-credit">
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public.
+
+When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed.
+
+Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public.
+
+Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions.
+
+If you notice multiple users running into the same problem, document the answers in the README.
+
+For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you.
+
+Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on.
+
+### Be responsive
+
+As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started.
+
+Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating.
+
+Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466):
+
+![Middleman pull request](/assets/images/building-community/middleman_pr.png)
+
+[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution.
+
+Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project.
+
+### Give your community a place to congregate
+
+There are two reasons to give your community a place to congregate.
+
+The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate.
+
+The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel.
+
+Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above!
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members:
+
+> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.
+
+Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address.
+
+## Growing your community
+
+Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction.
+
+### Don't tolerate bad actors
+
+Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others.
+
+Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
+  The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.
+  <p markdown="1" class="pquote-credit">
+— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+  </p>
+</aside>
+
+Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
+
+When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations.
+
+### Meet contributors where they're at
+
+Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need.
+
+In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors.
+
+![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
+
+In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started.
+
+Finally, use your documentation to make people feel welcome at every step of the way.
+
+You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration.
+
+For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
+
+### Share ownership of your project
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
+  Your leaders will have different opinions, as all healthy communities should! However, you need to take steps to ensure the loudest voice doesn't always win by tiring people out, and that less prominent and minority voices are heard.
+  <p markdown="1" class="pquote-credit">
+— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+  </p>
+</aside>
+
+People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around.
+
+See if you can find ways to share ownership with your community as much as possible. Here are some ideas:
+
+* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself.
+
+![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
+
+* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
+
+* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+
+* **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.
+
+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.
+
+While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
+  \[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it.
+  <p markdown="1" class="pquote-credit">
+— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+  </p>
+</aside>
+
+## Resolving conflicts
+
+In the early stages of your project, making major decisions is easy. When you want to do something, you just do it.
+
+As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own.
+
+For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address.
+
+### Set the bar for kindness
+
+When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you.
+
+Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
+  As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
+  <p markdown="1" class="pquote-credit">
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+  </p>
+</aside>
+
+Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly.
+
+Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you.
+
+### Treat your README as a constitution
+
+Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion.
+
+### Focus on the journey, not the destination
+
+Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns.
+
+Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place.
+
+Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus.
+
+Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
+  Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
+  <p markdown="1" class="pquote-credit">
+— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+  </p>
+</aside>
+
+Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions.
+
+Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution.
+
+### Keep the conversation focused on action
+
+Discussion is important, but there is a difference between productive and unproductive conversations.
+
+Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down.
+
+Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues.
+
+With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_
+
+If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation.
+
+If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+  </p>
+</aside>
+
+### Pick your battles wisely
+
+Context is important. Consider who is involved in the discussion and how they represent the rest of the community.
+
+Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices.
+
+If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread.
+
+### Identify a community tiebreaker
+
+With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker.
+
+A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it.
+
+Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible.
+
+## Community is the ❤️ of open source
+
+Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience.
diff --git a/_articles/el/code-of-conduct.md b/_articles/el/code-of-conduct.md
new file mode 100644
index 00000000000..3eaa41575cb
--- /dev/null
+++ b/_articles/el/code-of-conduct.md
@@ -0,0 +1,114 @@
+---
+lang: el
+title: Ο Κώδικας Δεοντολογίας σας
+description: Διευκολύνετε την υγιούς και εποικοδομητική συμπεριφορά της κοινότητας με την υιοθέτηση και επιβολή ενός κώδικα δεοντολογίας.
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+  - building
+  - leadership
+---
+
+## Why do I need a code of conduct?
+
+A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.
+
+Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.
+
+A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with.
+
+## Establishing a code of conduct
+
+Try to establish a code of conduct as early as possible: ideally, when you first create your project.
+
+In addition to communicating your expectations, a code of conduct describes the following:
+
+* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_
+* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_
+* What happens if someone violates the code of conduct
+* How someone can report violations
+
+Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
+
+The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples.
+
+Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
+
+## Deciding how you'll enforce your code of conduct
+
+<aside markdown="1" class="pquote">
+  A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
+  <p markdown="1" class="pquote-credit">
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+  </p>
+</aside>
+
+You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:
+
+* It demonstrates that you are serious about taking action when it's needed.
+
+* Your community will feel more reassured that complaints actually get reviewed.
+
+* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.
+
+You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
+
+Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+
+For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+
+## Enforcing your code of conduct
+
+Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up.
+
+### Gather information about the situation
+
+Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment.
+
+The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context.
+
+Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
+
+<aside markdown="1" class="pquote">
+  Don’t get pulled into an argument. Don’t get sidetracked into dealing with someone else’s behavior before you’ve finished dealing with the matter at hand. Focus on what you need.
+  <p markdown="1" class="pquote-credit">
+— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+  </p>
+</aside>
+
+### Take appropriate action
+
+After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward.
+
+When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise.
+
+There are a few ways you might respond to a code of conduct violation:
+
+* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication.
+
+* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them.
+
+Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example:
+
+* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project
+
+* **Permanently ban** the person from the project
+
+Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached.
+
+## Your responsibilities as a maintainer
+
+A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes.
+
+As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community.
+
+A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable.
+
+In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way.
+
+## Encourage the behavior you want to see in the world 🌎
+
+When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow.
diff --git a/_articles/el/finding-users.md b/_articles/el/finding-users.md
new file mode 100644
index 00000000000..a7a4cb3226f
--- /dev/null
+++ b/_articles/el/finding-users.md
@@ -0,0 +1,156 @@
+---
+lang: el
+title: Βρίσκοντας Χρήστες για το Πρότζεκτ σας
+description: Βοηθήστε το πρότζεκτ ανοιχτού κώδικά σας να μεγαλώσει, δίνοντας το στα χέρια ευχαριστημένων χρηστών.
+class: finding
+order: 3
+image: /assets/images/cards/finding.png
+related:
+  - beginners
+  - building
+---
+
+## Spreading the word
+
+There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work!
+
+## Figure out your message
+
+Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters.
+
+What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance.
+
+Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want.
+
+For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
+
+![Cartography README](/assets/images/finding-users/cartography.jpg)
+
+For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+
+## Help people find and follow your project
+
+<aside markdown="1" class="pquote">
+  You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
+  <p markdown="1" class="pquote-credit">
+— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+  </p>
+</aside>
+
+Help people find and remember your project by pointing them to a single namespace.
+
+**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.
+
+If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. 
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
+  A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project.
+  <p markdown="1" class="pquote-credit">
+— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+  </p>
+</aside>
+
+**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_.
+
+If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+
+![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
+
+Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!
+
+## Go where your project's audience is (online)
+
+Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
+
+Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
+  Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project.
+  <p markdown="1" class="pquote-credit">
+— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+  </p>
+</aside>
+
+See if you can find ways to share your project in relevant ways:
+
+* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.
+* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.
+* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work.
+
+Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want.
+
+If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication.
+
+## Go where your project's audience is (offline)
+
+![Public speaking](/assets/images/finding-users/public_speaking.jpg)
+
+Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.
+
+If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
+  I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
+  <p markdown="1" class="pquote-credit">
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+  </p>
+</aside>
+
+If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.
+
+As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.
+
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
+  When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+  <p markdown="1" class="pquote-credit">
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+  </p>
+</aside>
+
+When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.
+
+Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
+  I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?
+  <p markdown="1" class="pquote-credit">
+— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+  </p>
+</aside>
+
+## Build a reputation
+
+In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.
+
+Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
+  The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+  <p markdown="1" class="pquote-credit">
+— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+  </p>
+</aside>
+
+It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others.
+
+There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
+  PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it.
+  <p markdown="1" class="pquote-credit">
+— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
+  </p>
+</aside>
+
+## Keep at it!
+
+It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.
diff --git a/_articles/el/getting-paid.md b/_articles/el/getting-paid.md
new file mode 100644
index 00000000000..728a6374c6c
--- /dev/null
+++ b/_articles/el/getting-paid.md
@@ -0,0 +1,187 @@
+---
+lang: el
+title: Λαμβάνοντας Αμοιβή για Συνεισφορά Ανοιχτού Κώδικα
+description: Διατηρήστε το έργο σας στον ανοιχτό κώδικα λαμβάνοντας οικονομική υποστήριξη για τον χρόνο σας ή το πρότζεκτ σας.
+class: getting-paid
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+  - best-practices
+  - leadership
+---
+
+## Why some people seek financial support
+
+Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
+I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+  <p markdown="1" class="pquote-credit">
+— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+  </p>
+</aside>
+
+There are many reasons why a person would not want to be paid for their open source work.
+
+* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
+* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
+* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
+  Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+  <p markdown="1" class="pquote-credit">
+— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+  </p>
+</aside>
+
+For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+
+Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
+  Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+  <p markdown="1" class="pquote-credit">
+— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+  </p>
+</aside>
+
+Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
+   OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+  <p markdown="1" class="pquote-credit">
+— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+  </p>
+</aside>
+
+If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+
+## Funding your own time
+
+Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+
+It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
+  Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.
+  <p markdown="1" class="pquote-credit">
+— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
+  </p>
+</aside>
+
+If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+
+Many companies are developing open source programs to build their brand and recruit quality talent.
+
+@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+
+> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+
+If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
+  Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+  <p markdown="1" class="pquote-credit">
+— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+  </p>
+</aside>
+
+If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+
+* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
+* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+
+Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+
+Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
+
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
+* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
+* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+Finally, sometimes open source projects put bounties on issues that you might consider helping with.
+
+* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
+* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+
+## Finding funding for your project
+
+Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+
+Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas.
+
+As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+
+### Raise money for your work through crowdfunding campaigns or sponsorships
+
+Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
+A few examples of sponsored projects include:
+
+* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
+* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803)
+* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+
+### Create a revenue stream
+
+Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
+* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
+* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+
+Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+
+### Apply for grant funding
+
+Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+
+For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+
+## Building a case for financial support
+
+Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+
+Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+
+### Impact
+
+Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+
+### Traction
+
+Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+
+### Value to funder
+
+Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+
+### Use of funds
+
+What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+
+### How you'll receive the funds
+
+Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
+  For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+  <p markdown="1" class="pquote-credit">
+— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+  </p>
+</aside>
+
+## Experiment and don't give up
+
+Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
diff --git a/_articles/el/how-to-contribute.md b/_articles/el/how-to-contribute.md
new file mode 100644
index 00000000000..0c205111896
--- /dev/null
+++ b/_articles/el/how-to-contribute.md
@@ -0,0 +1,528 @@
+---
+lang: el
+title: Πώς να Συνεισφέρετε στον Ανοιχτό Κώδικα
+description: Θέλετε να συνεισφέρετε σε πρότζεκτς ανοιχτού κώδικα; Ένας οδηγός για τη συνεισφορά στον ανοιχτό κώδικα, για αρχάριους και βετεράνους.
+class: contribute
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+  - beginners
+  - building
+---
+
+## Why contribute to open source?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
+  Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+  <p markdown="1" class="pquote-credit">
+— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+  </p>
+</aside>
+
+Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+
+Why do people contribute to open source? Plenty of reasons!
+
+### Improve software you rely on
+
+Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+
+### Improve existing skills
+
+Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+
+### Meet people who are interested in similar things
+
+Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+
+### Find mentors and teach others
+
+Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+
+### Build public artifacts that help you grow a reputation (and a career)
+
+By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+
+### Learn people skills
+
+Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+
+### It's empowering to be able to make changes, even small ones
+
+You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+
+## What it means to contribute
+
+If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+
+Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+
+### You don't have to contribute code
+
+A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
+  I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+  <p markdown="1" class="pquote-credit">
+— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+  </p>
+</aside>
+
+Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
+  I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing.
+  <p markdown="1" class="pquote-credit">
+— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
+  </p>
+</aside>
+
+### Do you like planning events?
+
+* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Organize the project's conference (if they have one)
+* Help community members find the right conferences and submit proposals for speaking
+
+### Do you like to design?
+
+* Restructure layouts to improve the project's usability
+* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Put together a style guide to help the project have a consistent visual design
+* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+
+### Do you like to write?
+
+* Write and improve the project's documentation
+* Curate a folder of examples showing how the project is used
+* Start a newsletter for the project, or curate highlights from the mailing list
+* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Write a translation for the project's documentation
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
+  Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+  <p markdown="1" class="pquote-credit">
+— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+  </p>
+</aside>
+
+### Do you like organizing?
+
+* Link to duplicate issues, and suggest new issue labels, to keep things organized
+* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
+* Ask clarifying questions on recently opened issues to move the discussion forward
+
+### Do you like to code?
+
+* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Ask if you can help write a new feature
+* Automate project setup
+* Improve tooling and testing
+
+### Do you like helping people?
+
+* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
+* Answer questions for people on open issues
+* Help moderate the discussion boards or conversation channels
+
+### Do you like helping others code?
+
+* Review code on other people's submissions
+* Write tutorials for how a project can be used
+* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### You don't just have to work on software projects!
+
+While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+
+For example:
+
+* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
+* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
+* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+
+Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
+
+## Orienting yourself to a new project
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
+  If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+  <p markdown="1" class="pquote-credit">
+— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+  </p>
+</aside>
+
+For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+
+Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
+
+### Anatomy of an open source project
+
+Every open source community is different.
+
+Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+
+That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+
+A typical open source project has the following types of people:
+
+* **Author:** The person/s or organization that created the project
+* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
+* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
+* **Contributors:** Everyone who has contributed something back to the project
+* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+
+Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+
+A project also has documentation. These files are usually listed in the top level of a repository.
+
+* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
+* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
+* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
+* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
+* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.
+
+Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+
+* **Issue tracker:** Where people discuss issues related to the project.
+* **Pull requests:** Where people discuss and review changes that are in progress.
+* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
+* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
+
+## Finding a project to contribute to
+
+Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+
+If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_
+
+Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+
+Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+
+Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+
+Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+
+You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
+
+> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+
+If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+You can also use one of the following resources to help you discover and contribute to new projects:
+
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+
+### A checklist before you contribute
+
+When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+
+Here's a handy checklist to evaluate whether a project is good for new contributors.
+
+**Meets the definition of open source**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+  </label>
+</div>
+
+**Project actively accepts contributions**
+
+Look at the commit activity on the main branch. On GitHub, you can see this information on a repository's homepage.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+  When was the latest commit?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+  How many contributors does the project have?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  </label>
+</div>
+
+Next, look at the project's issues.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    How many open issues are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to issues when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Are the issues recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+  </label>
+</div>
+
+Now do the same for the project's pull requests.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    How many open pull requests are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox20" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to pull requests when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the pull requests?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    Are the pull requests recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox13" class="overflow-hidden d-block text-normal">
+    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+  </label>
+</div>
+
+**Project is welcoming**
+
+A project that is friendly and welcoming signals that they will be receptive to new contributors.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox14" class="overflow-hidden d-block text-normal">
+    Do the maintainers respond helpfully to questions in issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox15" class="overflow-hidden d-block text-normal">
+    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox16" class="overflow-hidden d-block text-normal">
+    Do pull requests get reviewed?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox17" class="overflow-hidden d-block text-normal">
+    Do maintainers thank people for their contributions?
+  </label>
+</div>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+  </p>
+</aside>
+
+## How to submit a contribution
+
+You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+
+### Communicating effectively
+
+Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
+  \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+  <p markdown="1" class="pquote-credit">
+— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+  </p>
+</aside>
+
+Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+
+**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+
+> 😇 _"X doesn't happen when I do Y"_
+>
+> 😢 _"X is broken! Please fix it."_
+
+**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn.
+
+> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+>
+> 😢 _"How do I X?"_
+
+**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+
+> 😇 _"I'd like to write an API tutorial."_
+>
+> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+
+**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+
+> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+>
+> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+
+**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+
+> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+>
+> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+
+**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+
+> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+>
+> 😢 _"Why won't you support my use case? This is unacceptable!"_
+
+**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+
+### Gathering context
+
+Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+
+If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request:
+
+* **Issues** are like starting a conversation or discussion
+* **Pull requests** are for starting work on a solution
+* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
+  You'll learn <em>a lot</em> from taking a single project you actively use, "watching" it on GitHub and reading every issue and PR.
+<p markdown="1" class="pquote-credit">
+— @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
+  </p>
+</aside>
+
+### Opening an issue
+
+You should usually open an issue in the following situations:
+
+* Report an error you can't solve yourself
+* Discuss a high-level topic or idea (for example, community, vision or policies)
+* Propose a new feature or other project idea
+
+Tips for communicating on issues:
+
+* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
+* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
+* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+
+### Opening a pull request
+
+You should usually open a pull request in the following situations:
+
+* Submit trivial fixes (for example, a typo, a broken link or an obvious error)
+* Start work on a contribution that was already asked for, or that you've already discussed, in an issue
+
+A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
+
+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/).)
+* **[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.
+* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
+* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+
+If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+
+## What happens after you submit a contribution
+
+You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
+
+After you submit a contribution, one of the following will happen:
+
+### 😭 You don't get a response.
+
+Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+
+If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+
+**Don't** reach out to that person privately; remember that public communication is vital to open source projects.
+
+If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+
+### 🚧 Someone requests changes to your contribution.
+
+It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+
+When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it.
+
+If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
+
+### 👎 Your contribution doesn't get accepted.
+
+Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+
+### 🎉 Your contribution gets accepted.
+
+Hooray! You've successfully made an open source contribution!
+
+## You did it!
+
+Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
diff --git a/_articles/el/index.html b/_articles/el/index.html
new file mode 100644
index 00000000000..b650ec561e9
--- /dev/null
+++ b/_articles/el/index.html
@@ -0,0 +1,6 @@
+---
+layout: index
+title: Οδηγίες Ανοιχτού Κώδικα
+lang: el
+permalink: /el/
+---
diff --git a/_articles/el/leadership-and-governance.md b/_articles/el/leadership-and-governance.md
new file mode 100644
index 00000000000..c0b8f4504b2
--- /dev/null
+++ b/_articles/el/leadership-and-governance.md
@@ -0,0 +1,156 @@
+---
+lang: el
+title: Ηγεσία και Διοίκηση
+description: Τα αναπτυσσόμενα πρότζεκτς ανοιχτού κώδικα μπορούν να επωφεληθούν από επίσημους κανόνες για τη λήψη αποφάσεων.
+class: leadership
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+  - best-practices
+  - metrics
+---
+
+## Understanding governance for your growing project
+
+Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+
+## What are examples of formal roles used in open source projects?
+
+Many projects follow a similar structure for contributor roles and recognition.
+
+What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+
+* **Maintainer**
+* **Contributor**
+* **Committer**
+
+**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+
+A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+
+**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+  </p>
+</aside>
+
+**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+
+While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
+  You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+  <p markdown="1" class="pquote-credit">
+— @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+  </p>
+</aside>
+
+## How do I formalize these leadership roles?
+
+Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+
+For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+
+For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+
+If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+
+<aside markdown="1" class="pquote">
+  \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+  <p markdown="1" class="pquote-credit">
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+  </p>
+</aside>
+
+Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+
+Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+
+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).
+
+## When should I give someone commit access?
+
+Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
+  Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+  <p markdown="1" class="pquote-credit">
+— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+  </p>
+</aside>
+
+## What are some of the common governance structures for open source projects?
+
+There are three common governance structures associated with open source projects.
+
+* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+
+* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+
+* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
+
+Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Do I need governance docs when I launch my project?
+
+There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+
+Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+
+If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
+  We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+  <p markdown="1" class="pquote-credit">
+— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+  </p>
+</aside>
+
+## What happens if corporate employees start submitting contributions?
+
+Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+
+As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+
+It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+
+"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+
+Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+
+## Do I need a legal entity to support my project?
+
+You don't need a legal entity to support your open source project unless you're handling money.
+
+For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+
+If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+
+Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
+  Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+  <p markdown="1" class="pquote-credit">
+— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+  </p>
+</aside>
+
+If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
diff --git a/_articles/el/legal.md b/_articles/el/legal.md
new file mode 100644
index 00000000000..7c7e700c560
--- /dev/null
+++ b/_articles/el/legal.md
@@ -0,0 +1,158 @@
+---
+lang: el
+title: Η Νομική Πλευρά του Ανοιχτού Κώδικα
+description: Όλα όσα αναρωτηθήκατε ποτέ σχετικά με την νομική πλευρά του ανοιχτού κώδικα, και μερικά πράγματα που δεν γνωρίζατε.
+class: legal
+order: 10
+image: /assets/images/cards/legal.png
+related:
+  - contribute
+  - leadership
+---
+
+## Understanding the legal implications of open source
+
+Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+
+## Why do people care so much about the legal side of open source?
+
+Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+
+In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+
+If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+
+Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
+
+## 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**.
+
+![Create repository](/assets/images/legal/repo-create-name.png)
+
+**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+
+If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+
+## Just give me the TL;DR on what I need to protect my project.
+
+You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+
+[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 the most popular open source 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/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
+  A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+  <p markdown="1" class="pquote-credit">
+— @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+  </p>
+</aside>
+
+## Which open source license is appropriate for my project?
+
+If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+
+Otherwise, picking the right open source license for your project depends on your objectives.
+
+Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+
+On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+
+You may also want to consider the **communities** you hope will use and contribute to your project:
+
+* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
+* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
+* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+
+Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+
+When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+
+## What if I want to change the license of my project?
+
+Most projects never need to change licenses. But occasionally circumstances change.
+
+For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+
+**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+
+**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+
+**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+
+Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+
+## 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).
+
+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.
+
+Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
+    We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+  <p markdown="1" class="pquote-credit">
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+  </p>
+</aside>
+
+Some situations where you may want to consider an additional contributor agreement for your project include:
+
+* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
+* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
+* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
+* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
+* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
+
+If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+
+## What does my company's legal team need to know?
+
+If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+
+For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+
+**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+
+* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+
+* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+
+* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
+
+* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+
+* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+
+If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+
+Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+
+* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
+  Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+  <p markdown="1" class="pquote-credit">
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+  </p>
+</aside>
+
+* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
+* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+
+<aside markdown="1" class="pquote">
+  Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+  <p markdown="1" class="pquote-credit">
+— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+  </p>
+</aside>
+
+* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
+* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
diff --git a/_articles/el/metrics.md b/_articles/el/metrics.md
new file mode 100644
index 00000000000..1c1a22eefe2
--- /dev/null
+++ b/_articles/el/metrics.md
@@ -0,0 +1,128 @@
+---
+lang: el
+title: Στατιστικά Ανοικτού Κώδικα
+description: Λάβετε τεκμηριωμένες αποφάσεις για να βοηθήσετε το πρότζεκτ ανοιχτού κώδικά σας να ευημερήσει, μετρώντας και παρακολουθώντας την επιτυχία του.
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+  - finding
+  - best-practices
+---
+
+## Why measure anything?
+
+Data, when used wisely, can help you make better decisions as an open source maintainer.
+
+With more information, you can:
+
+* Understand how users respond to a new feature
+* Figure out where new users come from
+* Identify, and decide whether to support, an outlier use case or functionality
+* Quantify your project's popularity
+* Understand how your project is used
+* Raise money through sponsorships and grants
+
+For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+
+> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+
+Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+
+If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+
+## Discovery
+
+Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+
+![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:
+
+* **Total page views:** Tells you how many times your project was viewed
+
+* **Total unique visitors:** Tells you how many people viewed your project
+
+* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+
+* **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.
+
+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.
+
+## Usage
+
+People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+
+If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+
+Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+
+If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+
+![Clone graph](/assets/images/metrics/clone_graph.png)
+
+If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+
+* Your project isn't successfully converting your audience, or
+* You're attracting the wrong audience
+
+For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+
+Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+
+Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+
+## Retention
+
+People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+
+It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+
+Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+
+Examples of community metrics that you may want to regularly track include:
+
+* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+
+![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+
+* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+
+* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+
+* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+
+* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
+  Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+  <p markdown="1" class="pquote-credit">
+— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+  </p>
+</aside>
+
+## Maintainer activity
+
+Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+
+Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+
+[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+
+Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+
+You could also measure the time it takes to move between stages in the contribution process, such as:
+
+* Average time an issue remains open
+* Whether issues get closed by PRs
+* Whether stale issues get closed
+* Average time to merge a pull request
+
+## Use 📊 to learn about people
+
+Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+
+[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health.
diff --git a/_articles/el/starting-a-project.md b/_articles/el/starting-a-project.md
new file mode 100644
index 00000000000..1112dec18ed
--- /dev/null
+++ b/_articles/el/starting-a-project.md
@@ -0,0 +1,356 @@
+---
+lang: el
+title: Ξεκινώντας ένα Πρότζεκτ Ανοιχτού Κώδικα
+description: Μάθετε περισσότερα για τον κόσμο του ανοιχτού κώδικα και ετοιμαστείτε να ξεκινήσετε το δικό σας πρότζεκτ. 
+class: beginners
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+  - finding
+  - building
+---
+
+## The "what" and "why" of open source
+
+So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+
+### What does "open source" mean?
+
+When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+
+Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+
+_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+
+### Why do people open source their work?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+  One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+  <p markdown="1" class="pquote-credit">
+— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+  </p>
+</aside>
+
+[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+
+* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+
+* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+
+Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+
+### Does open source mean "free of charge"?
+
+One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+
+Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+
+As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+
+## Should I launch my own open source project?
+
+The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+
+If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+
+Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+
+If you're not yet convinced, take a moment to think about what your goals might be.
+
+### Setting your goals
+
+Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself,  _why am I open sourcing this project?_
+
+There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+
+If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+  At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+  <p markdown="1" class="pquote-credit">
+— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+  </p>
+</aside>
+
+As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+
+While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+
+**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+
+If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+  As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+  <p markdown="1" class="pquote-credit">
+— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+  </p>
+</aside>
+
+### Contributing to other projects
+
+If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+
+If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+
+## Launching your own open source project
+
+There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+
+Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+
+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/)
+* [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.
+
+If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+
+### Choosing a license
+
+An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+
+Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+
+[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 the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+
+When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+
+![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+
+If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+
+### Writing a README
+
+READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+
+In your README, try to answer the following questions:
+
+* What does this project do?
+* Why is this project useful?
+* How do I get started?
+* Where can I get more help, if I need it?
+
+You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+  Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+  <p markdown="1" class="pquote-credit">
+— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+  </p>
+</aside>
+
+Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+
+For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+
+When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+
+### Writing your contributing guidelines
+
+A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+
+* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
+* How to suggest a new feature
+* How to set up your environment and run tests
+
+In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+
+* The types of contributions you're looking for
+* Your roadmap or vision for the project
+* How contributors should (or should not) get in touch with you
+
+Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+
+For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+
+> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+
+In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+
+Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+
+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.
+
+![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+
+### Establishing a code of conduct
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+  We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+  <p markdown="1" class="pquote-credit">
+— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+  </p>
+</aside>
+
+Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+
+For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+
+In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+
+Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+
+Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+
+## Naming and branding your project
+
+Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+
+### Choosing the right name
+
+Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+
+* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
+* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+
+If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+
+Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+
+### Avoiding name conflicts
+
+[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+
+If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+
+Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+
+You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+
+Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+
+### How you write (and code) affects your brand, too!
+
+Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+
+Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+  <p markdown="1" class="pquote-credit">
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+
+Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+
+It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+
+## 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.
+
+**Documentation**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Project has a LICENSE file with an open source license
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    The issue queue is up-to-date, with issues clearly organized and labeled
+  </label>
+</div>
+
+**Code**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Project uses consistent code conventions and clear function/method/variable names
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    The code is clearly commented, documenting intentions and edge cases
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+  </label>
+</div>
+
+**People**
+
+If you're an individual:
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  </label>
+</div>
+
+If you're a company or organization:
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    You've talked to your legal department
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    You have a marketing plan for announcing and promoting the project
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    At least two people have administrative access to the project
+  </label>
+</div>
+
+## You did it!
+
+Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.
diff --git a/_data/locales/el.yml b/_data/locales/el.yml
new file mode 100644
index 00000000000..8c0478ecd53
--- /dev/null
+++ b/_data/locales/el.yml
@@ -0,0 +1,31 @@
+el:
+  locale_name: Ελληνικά
+  nav:
+    about: Σχετικά με
+    contribute: Συνεισφορά
+  index:
+    lead: Το λογισμικό ανοιχτού κώδικα υλοποιείται από ανθρώπους σαν εσάς. Μάθετε πώς να ξεκινήσετε και να αναπτύξετε το δικό σας πρότζεκτ.
+    opensourcefriday: Είναι Παρασκευή! Επενδύστε μερικές ώρες συνεισφέροντας στο λογισμικό που χρησιμοποιείτε και αγαπάτε
+  article:
+    table_of_contents: Πίνακας Περιεχομένων
+    back_to_all_guides: Επιστροφή σε όλους τους οδηγούς
+    related_guides: Σχετικοί Οδηγοί
+  footer:
+    contribute:
+      heading: Συνεισφορά
+      description: Θέλετε να κάνετε μια πρόταση; Αυτό το περιεχόμενο είναι ανοιχτού κώδικα. Βοηθήστε μας να το βελτιώσουμε.
+      button: Συνεισφορά
+    subscribe:
+      heading: Μείνετε σε επαφή
+      description: Ενημερωθείτε πρώτοι για τις πιο πρόσφατες συμβουλές ανοιχτού κώδικα του GitHub.
+      label: Ηλεκτρονική διεύθυνση
+      button: Εγγραφή
+    byline:
+      # [code], [love], and [github] will be replaced by octicons
+      format: "[code] με [love] από το [github] και [friends]"
+      # Label for code octicon
+      code_label: code
+      # Label for love octicon
+      love_label: αγάπη
+      # Label for the contributors link
+      friends_label: φίλους

From 5b336ba11363210ec3e3d16b9bec2cb9e3d9b9bb Mon Sep 17 00:00:00 2001
From: Anthony Nikolaidis <anthony.nikolaidis@infopelago.gr>
Date: Sun, 3 Apr 2022 18:47:28 +0200
Subject: [PATCH 383/749] =?UTF-8?q?Translate=20code=20to=20=CE=BA=CF=8E?=
 =?UTF-8?q?=CE=B4=CE=B9=CE=BA=CE=B1=CF=82?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 _data/locales/el.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_data/locales/el.yml b/_data/locales/el.yml
index 8c0478ecd53..cf2dca38566 100644
--- a/_data/locales/el.yml
+++ b/_data/locales/el.yml
@@ -24,7 +24,7 @@ el:
       # [code], [love], and [github] will be replaced by octicons
       format: "[code] με [love] από το [github] και [friends]"
       # Label for code octicon
-      code_label: code
+      code_label: κώδικας
       # Label for love octicon
       love_label: αγάπη
       # Label for the contributors link

From 6e0933add823fbf3d46af021111ecb627ae40a0d Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Mon, 4 Apr 2022 18:10:06 +0300
Subject: [PATCH 384/749] Made some progress on best-practices.md

---
 _articles/el/best-practices.md | 90 +++++++++++++++++-----------------
 1 file changed, 45 insertions(+), 45 deletions(-)

diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
index e3bb39f87d0..66d73a43d2c 100644
--- a/_articles/el/best-practices.md
+++ b/_articles/el/best-practices.md
@@ -10,104 +10,104 @@ related:
   - leadership
 ---
 
-## What does it mean to be a maintainer?
+## Τι σημαίνει να είσαι συντηρητής;
 
-If you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more.
+Αν συντηρείτε ένα έργο ανοιχτού κώδικα που χρησιμοποιείται από πολλούς ανθρώπους, μπορεί να έχετε παρατηρήσει ότι προγραμματίζετε λιγότερο και απαντάτε περισσότερο σε ερωτήματα.
 
-In the early stages of a project, you're experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you'll find yourself working with your users and contributors more.
+Στα αρχικά στάδια ενός πρότζεκτ, πειραματίζεστε με νέες ιδέες και παίρνετε αποφάσεις με βάση το τι θέλετε. Καθώς το έργο σας αυξάνει τη φήμη του, θα βρεθείτε να συνεργάζεστε περισσότερο με τους χρήστες και τους συνεισφορείς σας.
 
-Maintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community.
+Η συντήρηση ενός έργου απαιτεί κάτι περισσότερο από κώδικα. Αυτές οι εργασίες είναι συχνά απροσδόκητες, αλλά είναι εξίσου σημαντικές για ένα αναπτυσσόμενο πρότζεκτ. Συγκεντρώσαμε μερικούς τρόπους για να κάνετε τη ζωή σας ευκολότερη, από την τεκμηρίωση των διαδικασιών μέχρι την αξιοποίηση της κοινότητάς σας.
 
-## Documenting your processes
+## Τεκμηριώνοντας τις διαδικασίες σας
 
-Writing things down is one of the most important things you can do as a maintainer.
+Η καταγραφή των πραγμάτων είναι ένα από τα πιο σημαντικά πράγματα που μπορείτε να κάνετε ως συντηρητής.
 
-Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask.
+Η τεκμηρίωση του πρότζεκτ όχι μόνο αποσαφηνίζει τη δική σας σκέψη, αλλά βοηθάει και τους άλλους να καταλάβουν τι χρειάζεστε ή τι περιμένετε, πριν καν ρωτήσουν.
 
-Writing things down makes it easier to say no when something doesn't fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project.
+Η καταγραφή των πραγμάτων καθιστά ευκολότερο να λέτε όχι όταν κάτι δεν ταιριάζει στο πεδίο εφαρμογής σας. Επίσης, διευκολύνει τους άλλους να συνεισφέρουν και να βοηθήσουν. Ποτέ δεν ξέρετε ποιος μπορεί να διαβάσει ή να χρησιμοποιήσει το έργο σας.
 
-Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all.
+Ακόμα και αν δεν χρησιμοποιείτε ολόκληρες παραγράφους, το να σημειώνετε πράγματα με bullet points είναι καλύτερο από το να μην γράφετε τίποτα.
 
-Remember to keep your documentation up-to-date. If you're not able to always do this, delete your outdated documentation or indicate it is outdated so contributors know updates are welcome.
+Να θυμάστε να διατηρείτε την τεκμηρίωσή σας ενημερωμένη. Αν δεν μπορείτε να το κάνετε πάντα αυτό, διαγράψτε την ξεπερασμένη τεκμηρίωσή σας ή αναφέρετε ότι είναι ξεπερασμένη, ώστε οι συνεισφέροντες να γνωρίζουν ότι οι ενημερώσεις είναι ευπρόσδεκτες.
 
-### Write down your project's vision
+### Καταγράψτε το όραμα του πρότζεκτ σας
 
-Start by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well.
+Ξεκινήστε γράφοντας τους στόχους του έργου σας. Προσθέστε τους στο αρχείο README ή δημιουργήστε ένα ξεχωριστό αρχείο με το όνομα VISION. Αν υπάρχουν άλλα αντικείμενα που θα μπορούσαν να βοηθήσουν, όπως ένας χάρτης πορείας του έργου, δημοσιοποιήστε και αυτά.
 
-Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions.
+Η ύπαρξη ενός σαφούς, τεκμηριωμένου οράματος σας κρατάει εστιασμένους και σας βοηθά να αποφύγετε τον "ερπυσμό του πεδίου εφαρμογής" από τις συνεισφορές των άλλων.
 
-For example, @lord discovered that having a project vision helped him figure out which requests to spend time on. As a new maintainer, he regretted not sticking to his project's scope when he got his first feature request for [Slate](https://github.com/lord/slate).
+Για παράδειγμα, ο @lord διαπίστωσε ότι η ύπαρξη ενός οράματος έργου τον βοήθησε να καταλάβει σε ποια αιτήματα να αφιερώσει χρόνο. Ως νέος συντηρητής, μετάνιωσε που δεν τήρησε το πεδίο εφαρμογής του έργου του, όταν έλαβε το πρώτο του αίτημα για μία νέα λειτορυγία για το [Slate](https://github.com/lord/slate).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
-  I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of a half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
+  Τα έκανα μαντάρα. Δεν κατέβαλα προσπάθεια για να βρω μια ολοκληρωμένη λύση. Αντί για μια μισή λύση, θα ήθελα να είχα πει "Δεν έχω χρόνο γι' αυτό τώρα, αλλά θα το προσθέσω στη μακροπρόθεσμη λίστα των καλών-αν-υπήρχαν πραγμάτων".
   <p markdown="1" class="pquote-credit">
 — @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
   </p>
 </aside>
 
-### Communicate your expectations
+### Επικοινωνήστε τις προσδοκίες σας
 
-Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun.
+Οι κανόνες μπορεί να είναι νευραλγικοί για να τους γράψετε. Μερικές φορές μπορεί να αισθάνεστε ότι αστυνομεύετε τη συμπεριφορά των άλλων ή ότι σκοτώνετε όλη τη διασκέδαση.
 
-Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do.
+Γραμμένοι και επιβαλλόμενοι δίκαια, ωστόσο, οι καλοί κανόνες ενδυναμώνουν τους συντηρητές. Σας αποτρέπουν από το να σας παρασύρουν να κάνετε πράγματα που δεν θέλετε.
 
-Most people who come across your project don't know anything about you or your circumstances. They may assume you get paid to work on it, especially if it's something they regularly use and depend on. Maybe at one point you put a lot of time into your project, but now you're busy with a new job or family member.
+Οι περισσότεροι άνθρωποι που έρχονται σε επαφή με το πρότζεκτ σας δεν γνωρίζουν τίποτα για εσάς ή τις συνθήκες που επικρατούν. Μπορεί να υποθέσουν ότι πληρώνεστε για να εργάζεστε σε αυτό, ειδικά αν πρόκειται για κάτι που χρησιμοποιούν τακτικά και από το οποίο εξαρτώνται. Ίσως κάποια στιγμή αφιερώσατε πολύ χρόνο στο πρότζεκτ σας, αλλά τώρα είστε απασχολημένοι με μια νέα δουλειά ή ένα νέο μέλος της οικογένειας.
 
-All of this is perfectly okay! Just make sure other people know about it.
+Όλα αυτά είναι απολύτως εντάξει! Απλώς βεβαιωθείτε ότι οι άλλοι άνθρωποι το γνωρίζουν.
 
-If maintaining your project is part-time or purely volunteered, be honest about how much time you have. This is not the same as how much time you think the project requires, or how much time others want you to spend.
+Αν η συντήρηση του έργου σας γίνεται με μερική απασχόληση ή καθαρά εθελοντικά, να είστε ειλικρινείς σχετικά με το πόσο χρόνο διαθέτετε. Αυτό δεν είναι το ίδιο με το πόσο χρόνο νομίζετε ότι απαιτεί το έργο ή πόσο χρόνο θέλουν οι άλλοι να ξοδέψετε.
 
-Here are a few rules that are worth writing down:
+Ακολουθούν μερικοί κανόνες που αξίζει να καταγράψετε:
 
-* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_)
-* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_)
-* When it's appropriate to follow up (_for example, "You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread."_)
-* How much time you spend on the project (_for example, "We only spend about 5 hours per week on this project"_)
+* Πώς μια συνεισφορά εξετάζεται και γίνεται αποδεκτή (_Χρειάζονται δοκιμές; Ένα πρότυπο θέματος;_)
+* Τα είδη των συνεισφορών που θα δεχτείτε (_Θέλετε βοήθεια μόνο για ένα συγκεκριμένο μέρος του κώδικά σας;_)
+* Πότε είναι σκόπιμο να δώσετε συνέχεια (_για παράδειγμα, "Μπορείτε να περιμένετε απάντηση από έναν συντηρητή εντός 7 ημερών. Αν δεν έχετε ακούσει τίποτα μέχρι τότε, μπορείτε να στείλετε μήνυμα στο νήμα."_)
+* Πόσο χρόνο αφιερώνετε στο έργο (_για παράδειγμα, "Ξοδεύουμε μόνο περίπου 5 ώρες την εβδομάδα σε αυτό το έργο"_)
 
-[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors.
+Το [Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), και το [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) είναι κάποια παραδείγματα από πρότζεκτ με κανόνες για τους συντηρητές και τους συνεισφέροντες.
 
-### Keep communication public
+### Κρατήστε την επικοινωνία δημόσια
 
-Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker.
+Μην ξεχνάτε επίσης να τεκμηριώνετε τις αλληλεπιδράσεις σας. Όπου μπορείτε, κρατήστε την επικοινωνία σχετικά με το πρότζεκτ σας δημόσια. Αν κάποιος προσπαθήσει να επικοινωνήσει μαζί σας ιδιαιτέρως για να συζητήσει ένα αίτημα χαρακτηριστικών ή μια ανάγκη υποστήριξης, κατευθύνετε τον ευγενικά σε ένα δημόσιο κανάλι επικοινωνίας, όπως μια λίστα αλληλογραφίας ή έναν ανιχνευτή προβλημάτων.
 
-If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes.
+Εάν συναντηθείτε με άλλους συντηρητές ή λάβετε μια σημαντική απόφαση ιδιωτικά, τεκμηριώστε αυτές τις συζητήσεις δημόσια, ακόμη και αν πρόκειται απλώς για την ανάρτηση των σημειώσεών σας.
 
-That way, anybody who joins your community will have access to the same information as someone who's been there for years.
+Με αυτόν τον τρόπο, όποιος προσχωρεί στην κοινότητά σας θα έχει πρόσβαση στις ίδιες πληροφορίες με κάποιον που είναι εκεί για χρόνια.
 
-## Learning to say no
+## Μαθαίνοντας να λέτε όχι
 
-You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists.
+Έχετε καταγράψει τα πράγματα. Ιδανικά, όλοι θα διάβαζαν το έγγραφο τεκμηρίωσής σας, αλλά στην πραγματικότητα, θα πρέπει να υπενθυμίζετε στους άλλους ότι υπάρχει αυτή η γνώση.
 
-Having everything written down, however, helps depersonalize situations when you do need to enforce your rules.
+Το να έχετε τα πάντα καταγεγραμμένα, ωστόσο, βοηθά στην αποπροσωποποίηση των καταστάσεων όταν χρειάζεται να επιβάλλετε τους κανόνες σας.
 
-Saying no isn't fun, but  _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_.
+Το να λέτε όχι δεν έχει πλάκα, αλλά _"Η συνεισφορά σας δεν ταιριάζει με τα κριτήρια αυτού του έργου"_ μοιάζει λιγότερο προσωπικό από το _"Δεν μου αρέσει η συνεισφορά σας"_.
 
-Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others.
+Το να λέτε όχι ισχύει σε πολλές περιπτώσεις που θα συναντήσετε ως συντηρητής: αιτήσεις για χαρακτηριστικά που δεν ταιριάζουν στο πεδίο εφαρμογής, κάποιος που εκτροχιάζει μια συζήτηση, που κάνει περιττή δουλειά για άλλους.
 
-### Keep the conversation friendly
+### Κρατήστε τη συζήτηση φιλική
 
-One of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept.
+Ένα από τα πιο σημαντικά μέρη που θα εξασκηθείτε στο να λέτε όχι είναι στην ουρά των ζητημάτων και των αιτημάτων (issues and pull requests). Ως συντηρητής έργου, αναπόφευκτα θα λάβετε προτάσεις που δεν θέλετε να δεχτείτε.
 
-Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor.
+Ίσως η συνεισφορά να αλλάζει το πεδίο εφαρμογής του έργου σας ή να μην ταιριάζει με το όραμά σας. Ίσως η ιδέα είναι καλή, αλλά η υλοποίηση είναι φτωχή.
 
-Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards.
+Ανεξάρτητα από τον λόγο, είναι δυνατόν να χειριστείτε με διακριτικότητα τις συνεισφορές που δεν ανταποκρίνονται στα πρότυπα του έργου σας.
 
-If you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community.
+Αν λάβετε μια συνεισφορά που δεν θέλετε να αποδεχτείτε, η πρώτη σας αντίδραση μπορεί να είναι να την αγνοήσετε ή να προσποιηθείτε ότι δεν την είδατε. Κάτι τέτοιο θα μπορούσε να πληγώσει τα αισθήματα του άλλου ατόμου και να αποθαρρύνει ακόμη και άλλους πιθανούς συνεισφέροντες στην κοινότητά σας.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
-  The key to handling support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS.
+  Το κλειδί για τον χειρισμό της υποστήριξης πρότζεκτ ανοιχτού κώδικα μεγάλης κλίμακας είναι η συνεχής λύση των θεμάτων. Προσπαθήστε να αποφύγετε την καθυστέρηση των θεμάτων. Αν είστε προγραμματιστής iOS ξέρετε πόσο απογοητευτικό μπορεί να είναι να υποβάλλετε radars. Μπορεί να λάβετε απάντηση 2 χρόνια αργότερα και να σας πουν να προσπαθήσετε ξανά με την τελευταία έκδοση του iOS.
   <p markdown="1" class="pquote-credit">
 — @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
   </p>
 </aside>
 
-Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.
+Μην αφήνετε μια ανεπιθύμητη συνεισφορά ανοιχτή επειδή αισθάνεστε ένοχοι ή επειδή θέλετε να είστε ευγενικοί. Με την πάροδο του χρόνου, τα αναπάντητα ζητήματα και αιτήματα θα κάνουν την εργασία στο έργο σας να μοιάζει πολύ πιο αγχωτική και εκφοβιστική.
 
-It's better to immediately close the contributions you know you don't want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Είναι προτιμότερο να κλείνετε αμέσως τις συνεισφορές που ξέρετε ότι δεν θέλετε να δεχτείτε. Αν το έργο σας πάσχει ήδη από ένα μεγάλο ανεκτέλεστο, ο @steveklabnik έχει προτάσεις για το [πώς να ταξινομείτε αποτελεσματικά τα θέματα](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
 
-Secondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it's someone's first time. Even if you don't accept their contribution, acknowledge the person behind it and thank them for their interest. It's a big compliment!
+Δεύτερον, η αγνόηση συνεισφορών στέλνει ένα αρνητικό μήνυμα στην κοινότητά σας. Η συνεισφορά σε ένα έργο μπορεί να είναι εκφοβιστική, ειδικά αν είναι η πρώτη φορά που κάποιος συνεισφέρει. Ακόμα και αν δεν αποδεχτείτε τη συνεισφορά του, αναγνωρίστε το άτομο που βρίσκεται πίσω από αυτή και ευχαριστήστε το για το ενδιαφέρον του. Είναι ένα μεγάλο κομπλιμέντο!
 
 If you don't want to accept a contribution:
 

From ad858cd6a6297ae016f4cfbe6906b740bca4180b Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Mon, 4 Apr 2022 18:22:11 +0300
Subject: [PATCH 385/749] Fix failing CI test

---
 _articles/el/building-community.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index 9054102aa78..a09ff3c7737 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -35,7 +35,7 @@ Start with your documentation:
 * **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
 * **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
 * **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or a small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
-* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#μαθαίνοντας-να-λέτε-όχι) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">

From 824a91f50ddd4ed4efc3838e15a78b3788f1a189 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Mon, 4 Apr 2022 19:23:04 +0300
Subject: [PATCH 386/749] Make some more progress on best-practices.md

---
 _articles/el/best-practices.md | 126 ++++++++++++++++-----------------
 1 file changed, 63 insertions(+), 63 deletions(-)

diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
index 66d73a43d2c..46d42517a0f 100644
--- a/_articles/el/best-practices.md
+++ b/_articles/el/best-practices.md
@@ -109,145 +109,145 @@ related:
 
 Δεύτερον, η αγνόηση συνεισφορών στέλνει ένα αρνητικό μήνυμα στην κοινότητά σας. Η συνεισφορά σε ένα έργο μπορεί να είναι εκφοβιστική, ειδικά αν είναι η πρώτη φορά που κάποιος συνεισφέρει. Ακόμα και αν δεν αποδεχτείτε τη συνεισφορά του, αναγνωρίστε το άτομο που βρίσκεται πίσω από αυτή και ευχαριστήστε το για το ενδιαφέρον του. Είναι ένα μεγάλο κομπλιμέντο!
 
-If you don't want to accept a contribution:
+Εάν δεν θέλετε να δεχτείτε μια συνεισφορά:
 
-* **Thank them** for their contribution
-* **Explain why it doesn't fit** into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm.
-* **Link to relevant documentation**, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself.
-* **Close the request**
+* **Ευχαριστήστε τους** για τη συνεισφορά τους
+* **Εξηγήστε γιατί δεν ταιριάζει** στο πεδίο εφαρμογής του έργου, και προσφέρετε σαφείς προτάσεις βελτίωσης, αν είστε σε θέση. Να είστε ευγενικοί, αλλά σταθεροί.
+* **Να παραπέμψετε σε σχετική τεκμηρίωση**, αν την έχετε. Εάν παρατηρήσετε επαναλαμβανόμενες αιτήσεις για πράγματα που δεν θέλετε να δεχτείτε, προσθέστε τα στην τεκμηρίωσή σας για να αποφύγετε την επανάληψη.
+* **Κλείστε το αίτημα**
 
-You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):
+Δεν θα πρέπει να χρειάζεστε περισσότερες από 1-2 προτάσεις για να απαντήσετε. Για παράδειγμα, όταν ένας χρήστης του [celery](https://github.com/celery/celery/) ανέφερε ένα σφάλμα σχετικό με τα Windows, ο @berkerpeksag [απάντησε με](https://github.com/celery/celery/issues/3383):
 
 ![Celery screenshot](/assets/images/best-practices/celery.png)
 
-If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):
+Αν η σκέψη να πείτε όχι σας τρομάζει, δεν είστε οι μόνοι. Όπως [το έθεσε](https://blog.jessfraz.com/post/the-art-of-closing/) ο @jessfraz:
 
-> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want.
+> Έχω μιλήσει με συντηρητές από διάφορα πρότζεκτς ανοιχτού κώδικα, Mesos, Kubernetes, Chromium, και όλοι συμφωνούν ότι ένα από τα δυσκολότερα μέρη του να είσαι συντηρητής είναι να λέει κανείς "Όχι" σε patches που δεν θέλεις.
 
-Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it.
+Μην αισθάνεστε ένοχοι που δεν θέλετε να αποδεχτείτε την συνεισφορά κάποιου. Ο πρώτος κανόνας του ανοιχτού κώδικα, [σύμφωνα με τον](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Το όχι είναι προσωρινό, το ναι είναι παντοτινό."_ Ενώ η κατανόηση του ενθουσιασμού ενός άλλου ατόμου είναι καλό πράγμα, η απόρριψη μιας συνεισφοράς δεν είναι το ίδιο με την απόρριψη του ατόμου πίσω από αυτήν.
 
-Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise.
+Σε τελική ανάλυση, αν μια συνεισφορά δεν είναι αρκετά καλή, δεν είστε υποχρεωμένοι να την αποδεχτείτε. Να είστε ευγενικοί και να ανταποκρίνεστε όταν οι άνθρωποι συνεισφέρουν στο έργο σας, αλλά να δέχεστε μόνο τις αλλαγές που πραγματικά πιστεύετε ότι θα κάνουν το έργο σας καλύτερο. Όσο πιο συχνά εξασκείστε στο να λέτε όχι, τόσο πιο εύκολο γίνεται. Υπόσχεση.
 
-### Be proactive
+### Να είστε προνοητικοί
 
-To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide.
+Για να μειώσετε εξαρχής τον όγκο των ανεπιθύμητων συνεισφορών, εξηγήστε τη διαδικασία του έργου σας για την υποβολή και την αποδοχή συνεισφορών στον οδηγό συνεισφοράς σας.
 
-If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example:
+Αν λαμβάνετε πάρα πολλές συνεισφορές χαμηλής ποιότητας, απαιτήστε από τους συνεισφέροντες να κάνουν λίγη δουλειά εκ των προτέρων, για παράδειγμα:
 
-* Fill out a issue or PR template/checklist
-* Open an issue before submitting a PR
+* Συμπλήρωση ενός ζητήματος (issue) ή έναν κατάλογο αιτήματος (pull request)
+* Άνοιγμα ζητήματος πριν την υποβολή ενός αιτήματος
 
-If they don't follow your rules, close the issue immediately and point to your documentation.
+Αν δεν τηρούν τους κανόνες σας, κλείστε αμέσως το θέμα και παραπέμψτε στην τεκμηρίωσή σας.
 
-While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage.
+Αν και αυτή η προσέγγιση μπορεί να σας φανεί αγενής στην αρχή, το να είστε προληπτικοί είναι στην πραγματικότητα καλό και για τα δύο μέρη. Μειώνει την πιθανότητα κάποιος να αφιερώσει πολλές χαμένες ώρες εργασίας σε ένα pull request που δεν πρόκειται να αποδεχτείτε. Και καθιστά ευκολότερη τη διαχείριση του φόρτου εργασίας σας.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-  Ideally, explain to them and in a CONTRIBUTING.md file how they can get a better indication in the future on what would or would not be accepted before they begin the work.
+  Ιδανικά, εξηγήστε τους και σε ένα αρχείο CONTRIBUTING.md πώς μπορούν να πάρουν μια καλύτερη ένδειξη στο μέλλον για το τι θα γίνει ή δεν θα γίνει αποδεκτό πριν ξεκινήσουν την εργασία.
   <p markdown="1" class="pquote-credit">
 — @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
   </p>
 </aside>
 
-Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively.
+Μερικές φορές, όταν λέτε όχι, ο πιθανός συνεισφορέας σας μπορεί να εκνευριστεί ή να επικρίνει την απόφασή σας. Αν η συμπεριφορά του γίνει εχθρική, [λάβετε μέτρα για να εκτονώσετε την κατάσταση](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) ή ακόμα και να τον απομακρύνετε από την κοινότητά σας, αν δεν είναι πρόθυμος να συνεργαστεί εποικοδομητικά.
 
-### Embrace mentorship
+### Αποδεχτείτε την καθοδήγηση
 
-Maybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections.
+Ίσως κάποιος στην κοινότητά σας υποβάλλει τακτικά συνεισφορές που δεν ανταποκρίνονται στα πρότυπα του έργου σας. Μπορεί να είναι απογοητευτικό και για τα δύο μέρη να περνούν επανειλημμένα από απορρίψεις.
 
-If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first issue,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them.
+Αν δείτε ότι κάποιος είναι ενθουσιασμένος με το έργο σας, αλλά χρειάζεται λίγη βελτίωση, κάντε υπομονή. Εξηγήστε με σαφήνεια σε κάθε περίπτωση γιατί οι συνεισφορές τους δεν ανταποκρίνονται στις προσδοκίες του έργου. Προσπαθήστε να τους υποδείξετε μια πιο εύκολη ή λιγότερο ασαφή εργασία, όπως ένα ζήτημα με την ένδειξη _"καλό πρώτο ζήτημα",_ για να αρχίσουν να συμμετέχουν. Αν έχετε χρόνο, σκεφτείτε να τους καθοδηγήσετε κατά την πρώτη τους συνεισφορά ή βρείτε κάποιον άλλον στην κοινότητά σας που θα μπορούσε να είναι πρόθυμος να τους καθοδηγήσει.
 
-## Leverage your community
+## Αξιοποιήστε την κοινότητά σας
 
-You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work.
+Δεν χρειάζεται να κάνετε τα πάντα μόνοι σας. Η κοινότητα του έργου σας υπάρχει για κάποιο λόγο! Ακόμα και αν δεν έχετε ακόμα μια ενεργή κοινότητα συνεισφερόντων, αν έχετε πολλούς χρήστες, βάλτε τους να δουλέψουν.
 
-### Share the workload
+### Μοιραστείτε το φόρτο εργασίας
 
-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.
+Ένας τρόπος για να κερδίσετε νέους συνεισφέροντες είναι να επισημάνετε ρητά [θέματα που είναι αρκετά απλά για να τα αντιμετωπίσουν οι αρχάριοι](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Στη συνέχεια, το GitHub θα εμφανίσει αυτά τα ζητήματα σε διάφορα σημεία της πλατφόρμας, αυξάνοντας την προβολή τους.
 
-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.
+Όταν βλέπετε νέους συνεισφέροντες να κάνουν επαναλαμβανόμενες συνεισφορές, αναγνωρίστε το έργο τους προσφέροντας περισσότερες ευθύνες. Τεκμηριώστε τον τρόπο με τον οποίο οι άλλοι μπορούν να εξελιχθούν σε ηγετικούς ρόλους αν το επιθυμούν.
 
-Encouraging others to [share ownership of the project](../building-community/#share-ownership-of-your-project) can greatly reduce your own workload, as @lmccart discovered on her project, [p5.js](https://github.com/processing/p5.js).
+Το να ενθαρρύνετε τους άλλους να [μοιράζονται την ιδιοκτησία του έργου](../building-community/#share-ownership-of-your-project) μπορεί να μειώσει σημαντικά τον δικό σας φόρτο εργασίας, όπως ανακάλυψε η @lmccart στο έργο της, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
-  I’d been saying, "Yeah, anyone can be involved, you don’t have to have a lot of coding expertise [...]." We had people sign up to come [to an event] and that’s when I was really wondering: is this true, what I’ve been saying? There are gonna be 40 people who show up, and it’s not like I can sit with each of them...But people came together, and it just sort of worked. As soon as one person got it, they could teach their neighbor.
+  Έλεγα, "Ναι, ο καθένας μπορεί να συμμετάσχει, δεν χρειάζεται να έχεις μεγάλη εμπειρία στον προγραμματισμό [...]". Είχαμε ανθρώπους που δήλωναν συμμετοχή [σε μια εκδήλωση] και τότε ήταν που πραγματικά αναρωτήθηκα: είναι αλήθεια αυτό που έλεγα; Θα εμφανιστούν 40 άτομα και δεν είναι ότι μπορώ να καθίσω με τον καθένα τους... Αλλά οι άνθρωποι συγκεντρώθηκαν και κατά κάποιο τρόπο λειτούργησε. Μόλις ένα άτομο το καταλάβαινε, μπορούσε να διδάξει τον διπλανό του.
   <p markdown="1" class="pquote-credit">
 —  @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
   </p>
 </aside>
 
-If you need to step away from your project, either on hiatus or permanently, there's no shame in asking someone else to take over for you.
+Αν χρειαστεί να αποχωρήσετε από το έργο σας, είτε για διακοπή είτε μόνιμα, δεν είναι ντροπή να ζητήσετε από κάποιον άλλον να αναλάβει τη θέση σας.
 
-If other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It's great that so many people want your project to live on!
+Αν άλλοι άνθρωποι είναι ενθουσιασμένοι με την κατεύθυνσή του, δώστε τους δεσμευτική πρόσβαση ή παραδώστε επίσημα τον έλεγχο σε κάποιον άλλον. Αν κάποιος έχει διακλαδίσει το έργο σας (fork) και το συντηρεί ενεργά αλλού, σκεφτείτε το ενδεχόμενο να παραπέμψετε στη διακλάδωση από το αρχικό σας έργο. Είναι σπουδαίο που τόσοι πολλοί άνθρωποι θέλουν να συνεχίσει το έργο σας να ζει!
 
-@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), helped those goals live on even after he stepped away from the project:
+Ο @progrium [διαπίστωσε ότι](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) καταγράφοντας το όραμα για το έργο του, [Dokku](https://github.com/dokku/dokku), βοήθησε αυτούς τους στόχους να συνεχίσουν να ζουν ακόμα και μετά την αποχώρησή του από το έργο:
 
-> I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down.
+> Έγραψα μια σελίδα wiki που περιέγραφε τι ήθελα και γιατί το ήθελα. Για κάποιο λόγο με εξέπληξε το γεγονός ότι οι συντηρητές άρχισαν να κινούν το πρότζεκτ προς αυτή την κατεύθυνση! Συνέβη ακριβώς όπως θα το έκανα εγώ; Όχι πάντα. Αλλά και πάλι έφερε το έργο πιο κοντά σε αυτό που έγραψα.
 
-### Let others build the solutions they need
+### Αφήστε τους άλλους να φτιάξουν τις λύσεις που χρειάζονται
 
-If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork.
+Αν ένας πιθανός συνεισφέροντας έχει διαφορετική άποψη για το τι πρέπει να κάνει το έργο σας, ίσως θελήσετε να τον ενθαρρύνετε απαλά να δουλέψει στο δικό του fork.
 
-Forking a project doesn't have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project's vision.
+Η διακλάδωση ενός έργου δεν χρειάζεται να είναι κάτι κακό. Η δυνατότητα αντιγραφής και τροποποίησης έργων είναι ένα από τα καλύτερα πράγματα στον ανοικτό κώδικα. Το να ενθαρρύνετε τα μέλη της κοινότητάς σας να εργαστούν στη δική τους διακλάδωση μπορεί να τους προσφέρει τη δημιουργική διέξοδο που χρειάζονται, χωρίς να έρχεται σε σύγκρουση με το όραμα του έργου σας.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
-  I cater to the 80% use case. If you are one of the unicorns, please fork my work. I won't get offended! My public projects are almost always meant to solve the most common problems; I try to make it easy to go deeper by either forking my work or extending it.
+  Εξυπηρετώ το 80% των περιπτώσεων χρήσης. Αν είστε ένας από τους μονόκερους, παρακαλείσθε να κάνετε fork τη δουλειά μου. Δεν θα προσβληθώ! Τα δημόσια πρότζεκτ μου προορίζονται σχεδόν πάντα για την επίλυση των πιο συνηθισμένων προβλημάτων- προσπαθώ να διευκολύνω την εμβάθυνση, είτε με το να κάνω fork το πρότζεκτ μου είτε με το να το επεκτείνω.
   <p markdown="1" class="pquote-credit">
-— @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+- @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
   </p>
 </aside>
 
-The same applies to a user who really wants a solution that you simply don't have the bandwidth to build. Offering APIs and customization hooks can help others meet their own needs, without having to modify the source directly. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) encouraging plugins for CocoaPods led to "some of the most interesting ideas":
+Το ίδιο ισχύει και για έναν χρήστη που θέλει πραγματικά μια λύση την οποία απλά δεν έχετε το εύρος ζώνης για να κατασκευάσετε. Η προσφορά APIs και customization hooks μπορεί να βοηθήσει τους άλλους να ικανοποιήσουν τις δικές τους ανάγκες, χωρίς να χρειάζεται να τροποποιήσουν άμεσα τον πηγαίο κώδικα. Ο @orta [διαπίστωσε ότι](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) η ενθάρρυνση των plugins για τα CocoaPods οδήγησε σε "μερικές από τις πιο ενδιαφέρουσες ιδέες":
 
-> It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying "no", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform.
+> Είναι σχεδόν αναπόφευκτο ότι μόλις ένα πρότζεκτ γίνει μεγάλο, οι συντηρητές πρέπει να γίνουν πολύ πιο συντηρητικοί σχετικά με το πώς εισάγουν νέο κώδικα. Γίνεστε καλοί στο να λέτε "όχι", αλλά πολλοί άνθρωποι έχουν νόμιμες ανάγκες. Οπότε, αντί γι' αυτό, καταλήγετε να μετατρέψετε το εργαλείο σας σε πλατφόρμα.
 
-## Bring in the robots
+## Φέρτε τα ρομπότ
 
-Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier.
+Όπως ακριβώς υπάρχουν εργασίες στις οποίες μπορούν να σας βοηθήσουν άλλοι άνθρωποι, έτσι υπάρχουν και εργασίες που δεν θα έπρεπε ποτέ να κάνει κανένας άνθρωπος. Τα ρομπότ είναι οι φίλοι σας. Χρησιμοποιήστε τα για να κάνετε τη ζωή σας ως συντηρητής ευκολότερη.
 
-### Require tests and other checks to improve the quality of your code
+### Απαιτήστε δοκιμές και άλλους ελέγχους για να βελτιώσετε την ποιότητα του κώδικά σας
 
-One of the most important ways you can automate your project is by adding tests.
+Ένας από τους σημαντικότερους τρόπους με τους οποίους μπορείτε να αυτοματοποιήσετε το πρότζεκτ σας είναι η προσθήκη δοκιμών (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.
+Ορίστε αυτόματες δοκιμές που θα εκτελούνται σε όλες τις εισερχόμενες συνεισφορές και βεβαιωθείτε ότι οι δοκιμές σας μπορούν εύκολα να εκτελούνται τοπικά από τους συνεισφέροντες. Απαιτήστε ότι όλες οι συνεισφορές κώδικα περνούν τις δοκιμές σας πριν υποβληθούν. Θα βοηθήσετε στον καθορισμό ενός ελάχιστου προτύπου ποιότητας για όλες τις υποβολές. Οι [Απαιτούμενοι έλεγχοι κατάστασης](https://help.github.com/articles/about-required-status-checks/) στο GitHub μπορούν να βοηθήσουν να διασφαλιστεί ότι καμία αλλαγή δεν συγχωνεύεται χωρίς να έχουν περάσει οι δοκιμές σας.
 
-If you add tests, make sure to explain how they work in your CONTRIBUTING file.
+Αν προσθέσετε δοκιμές, φροντίστε να εξηγήσετε πώς λειτουργούν στο αρχείο CONTRIBUTING.
 
 <aside markdown="1" class="pquote">
   <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://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
-### Use tools to automate basic maintenance tasks
+### Χρησιμοποιήστε εργαλεία για την αυτοματοποίηση βασικών εργασιών συντήρησης
 
-The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for them.
+Τα καλά νέα σχετικά με τη συντήρηση ενός δημοφιλούς πρότζεκτ είναι ότι άλλοι συντηρητές έχουν πιθανότατα αντιμετωπίσει παρόμοια ζητήματα και έχουν κατασκευάσει μια λύση για αυτά.
 
-There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples:
+Υπάρχει μια [ποικιλία διαθέσιμων εργαλείων](https://github.com/showcases/tools-for-open-source) που βοηθούν στην αυτοματοποίηση ορισμένων πτυχών των εργασιών συντήρησης. Μερικά παραδείγματα:
 
-* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases
-* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
-* [Danger](https://github.com/danger/danger) helps automate code review
-* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information
-* [dependabot-preview](https://github.com/marketplace/dependabot-preview) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
+* Το [semantic-release](https://github.com/semantic-release/semantic-release) αυτοματοποιεί τις εκδόσεις σας
+* Το [mention-bot](https://github.com/facebook/mention-bot) αναφέρει πιθανούς αναθεωρητές (reviewers) για τα pull requests
+* Το [Danger](https://github.com/danger/danger) βοηθά στην αυτοματοποίηση της αναθεώρησης κώδικα (code review)
+* Το [no-response](https://github.com/probot/no-response) κλείνει θέματα στα οποία ο συγγραφέας δεν έχει απαντήσει σε ένα αίτημα για περισσότερες πληροφορίες
+* Το [dependabot-preview](https://github.com/marketplace/dependabot-preview) ελέγχει τα αρχεία εξαρτήσεων σας κάθε μέρα για ξεπερασμένες απαιτήσεις και ανοίγει μεμονωμένα pull requests για όποια βρει
 
-For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.
+Για αναφορές σφαλμάτων και άλλες κοινές συνεισφορές, το GitHub διαθέτει [Πρότυπα ζητημάτων και πρότυπα αιτημάτων](https://github.com/blog/2111-issue-and-pull-request-templates), τα οποία μπορείτε να δημιουργήσετε για να βελτιώσετε την επικοινωνία που λαμβάνετε. Ο @TalAter δημιούργησε έναν οδηγό [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) για να σας βοηθήσει να γράψετε τα πρότυπα των ζητημάτων και των PR σας.
 
-To manage your email notifications, you can set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize by priority.
+Για να διαχειριστείτε τις ειδοποιήσεις ηλεκτρονικού ταχυδρομείου σας, μπορείτε να δημιουργήσετε [φίλτρα ηλεκτρονικού ταχυδρομείου](https://github.com/blog/2203-email-updates-about-your-own-activity) για να οργανώνετε με βάση την προτεραιότητα.
 
-If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept.
+Αν θέλετε να προχωρήσετε λίγο περισσότερο, οι οδηγοί στυλ και οι λιντέρ μπορούν να τυποποιήσουν τις συνεισφορές στο πρότζεκτ και να τις κάνουν πιο εύκολες στην αναθεώρηση και στην αποδοχή τους.
 
-However, if your standards are too complicated, they can increase the barriers to contribution. Make sure you're only adding enough rules to make everyone's lives easier.
+Ωστόσο, αν τα πρότυπα σας είναι πολύ περίπλοκα, μπορεί να αυξήσουν τα εμπόδια στη συνεισφορά. Βεβαιωθείτε ότι προσθέτετε μόνο αρκετούς κανόνες για να κάνετε τη ζωή όλων πιο εύκολη.
 
-If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors.
+Αν δεν είστε σίγουροι για το ποια εργαλεία να χρησιμοποιήσετε, κοιτάξτε τι κάνουν άλλα δημοφιλή πρότζεκτ, ειδικά αυτά που ανήκουν στο οικοσύστημά σας. Για παράδειγμα, πώς μοιάζει η διαδικασία συνεισφοράς για άλλες ενότητες του Node; Η χρήση παρόμοιων εργαλείων και προσεγγίσεων θα κάνει επίσης τη διαδικασία σας πιο οικεία στους συνεισφέροντες-στόχους σας.
 
 ## It's okay to hit pause
 

From 41ed5d8749140f5fe8bcf4d2ad9f6ac6cfc91a87 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Mon, 4 Apr 2022 21:42:56 +0300
Subject: [PATCH 387/749] Finish translations on best-practices.md

---
 _articles/el/best-practices.md | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
index 46d42517a0f..dc822415245 100644
--- a/_articles/el/best-practices.md
+++ b/_articles/el/best-practices.md
@@ -249,32 +249,32 @@ related:
 
 Αν δεν είστε σίγουροι για το ποια εργαλεία να χρησιμοποιήσετε, κοιτάξτε τι κάνουν άλλα δημοφιλή πρότζεκτ, ειδικά αυτά που ανήκουν στο οικοσύστημά σας. Για παράδειγμα, πώς μοιάζει η διαδικασία συνεισφοράς για άλλες ενότητες του Node; Η χρήση παρόμοιων εργαλείων και προσεγγίσεων θα κάνει επίσης τη διαδικασία σας πιο οικεία στους συνεισφέροντες-στόχους σας.
 
-## It's okay to hit pause
+## Δεν πειράζει να κάνετε διάλειμμα!
 
-Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty.
+Η εργασία σε ανοιχτό κώδικα κάποτε σας έδινε χαρά. Ίσως τώρα αρχίζει να σας κάνει να νιώθετε αποφυγή ή ενοχές.
 
-Perhaps you're feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up.
+Ίσως αισθάνεστε συγκλονισμένοι ή μια αυξανόμενη αίσθηση τρόμου όταν σκέφτεστε τα πρότζεκτ σας. Και εν τω μεταξύ, τα ζητήματα και τα αιτήματα για την έκδοση προτάσεων συσσωρεύονται.
 
-Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project.
+Η επαγγελματική εξουθένωση είναι ένα πραγματικό και διάχυτο ζήτημα στην εργασία ανοιχτού κώδικα, ειδικά μεταξύ των συντηρητών. Ως συντηρητής, η ευτυχία σας είναι αδιαπραγμάτευτη προϋπόθεση για την επιβίωση κάθε έργου ανοιχτού κώδικα.
 
-Although it should go without saying, take a break! You shouldn't have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take [a month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) after 14 years of volunteer OSS work.
+Αν και θα έπρεπε να είναι αυτονόητο, κάντε ένα διάλειμμα! Δεν θα πρέπει να περιμένετε μέχρι να νιώσετε εξαντλημένοι για να κάνετε διακοπές. Ο @brettcannon, ένας κύριος προγραμματιστής της Python, αποφάσισε να κάνει [ένα μήνα διακοπές](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) μετά από 14 χρόνια εθελοντικής εργασίας στο OSS.
 
-Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work.
+Ακριβώς όπως και σε κάθε άλλο είδος εργασίας, το να κάνετε τακτικά διαλείμματα θα σας κρατήσει ανανεωμένους, χαρούμενους και ενθουσιασμένους με τη δουλειά σας.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
-  In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
+  Διατηρώντας το WP-CLI, ανακάλυψα ότι πρέπει πρώτα να κάνω τον εαυτό μου ευτυχισμένο και να θέσω σαφή όρια στη συμμετοχή μου. Η καλύτερη ισορροπία που έχω βρει είναι 2-5 ώρες την εβδομάδα, ως μέρος του κανονικού μου προγράμματος εργασίας. Αυτό κρατάει τη συμμετοχή μου ως πάθος και δεν την αισθάνομαι υπερβολικά σαν δουλειά. Επειδή ιεραρχώ τα θέματα στα οποία εργάζομαι, μπορώ να σημειώνω τακτική πρόοδο σε ό,τι θεωρώ πιο σημαντικό.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+- @danielbachhuber, ["Τα συλλυπητήριά μου, είστε τώρα ο συντηρητής ενός δημοφιλούς πρότζεκτ ανοικτού κώδικα"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
-Sometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away.
+Μερικές φορές, μπορεί να είναι δύσκολο να κάνεις ένα διάλειμμα από την εργασία ανοιχτού κώδικα όταν νιώθεις ότι όλοι σε χρειάζονται. Οι άνθρωποι μπορεί ακόμη και να προσπαθήσουν να σας κάνουν να νιώσετε ένοχοι που απομακρύνεστε.
 
-Do your best to find support for your users and community while you're away from a project. If you can't find the support you need, take a break anyway. Be sure to communicate when you're not available, so people aren't confused by your lack of responsiveness.
+Κάνετε ό,τι μπορείτε για να βρείτε υποστήριξη για τους χρήστες και την κοινότητά σας, ενώ βρίσκεστε μακριά από ένα έργο. Αν δεν μπορείτε να βρείτε την υποστήριξη που χρειάζεστε, κάντε ένα διάλειμμα ούτως ή άλλως. Φροντίστε να επικοινωνείτε όταν δεν είστε διαθέσιμοι, ώστε οι άνθρωποι να μην μπερδεύονται από την έλλειψη ανταπόκρισής σας.
 
-Taking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you.
+Το να κάνετε διαλείμματα ισχύει και για κάτι περισσότερο από τις διακοπές. Αν δεν θέλετε να κάνετε εργασίες ανοιχτού κώδικα τα Σαββατοκύριακα ή κατά τη διάρκεια των ωρών εργασίας, επικοινωνήστε αυτές τις προσδοκίες στους άλλους, ώστε να ξέρουν να μην σας ενοχλούν.
 
-## Take care of yourself first!
+## Φροντίστε πρώτα τον εαυτό σας!
 
-Maintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive.
+Η διατήρηση ενός δημοφιλούς πρότζεκτ απαιτεί διαφορετικές δεξιότητες από τα προηγούμενα στάδια ανάπτυξης, αλλά δεν είναι λιγότερο ικανοποιητική. Ως συντηρητής, θα εξασκήσετε ηγετικές και προσωπικές δεξιότητες σε ένα επίπεδο που λίγοι άνθρωποι έχουν την ευκαιρία να βιώσουν. Αν και δεν είναι πάντα εύκολο να το διαχειριστείτε, ο καθορισμός σαφών ορίων και η ανάληψη μόνο όσων σας βολεύουν θα σας βοηθήσει να παραμείνετε ευτυχισμένοι, ανανεωμένοι και παραγωγικοί.

From 625f1b573d3b6de94612bf4144fe5fa0ea8b50c5 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Mon, 4 Apr 2022 22:13:45 +0300
Subject: [PATCH 388/749] Start work on building-community.md

---
 _articles/el/building-community.md | 86 +++++++++++++++---------------
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index a09ff3c7737..8faab57892b 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -10,98 +10,98 @@ related:
   - coc
 ---
 
-## Setting your project up for success
+## Προετοιμάζοντας το πρότζεκτ σας για την επιτυχία
 
-You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around?
+Ξεκινήσατε το πρότζεκτ σας, το διαδίδετε και ο κόσμος το ελέγχει. Φοβερό! Τώρα, πώς θα τους κάνετε να παραμείνουν;
 
-A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back.
+Μια φιλόξενη κοινότητα είναι μια επένδυση στο μέλλον και τη φήμη του πρότζεκτ σας. Αν το πρότζεκτ σας μόλις αρχίζει να βλέπει τις πρώτες συνεισφορές, ξεκινήστε δίνοντας στους πρώτους συνεισφέροντες μια θετική εμπειρία και διευκολύνετέ τους να συνεχίσουν να επιστρέφουν.
 
-### Make people feel welcome
+### Κάντε τους ανθρώπους να αισθάνονται ευπρόσδεκτοι
 
-One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+Ένας τρόπος για να σκεφτείτε την κοινότητα του έργου σας είναι αυτό που ο @MikeMcQuaid αποκαλεί [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
 
 ![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
 
-As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more.
+Καθώς χτίζετε την κοινότητά σας, σκεφτείτε πώς κάποιος που βρίσκεται στην κορυφή του χωνιού (ένας δυνητικός χρήστης) θα μπορούσε θεωρητικά να φτάσει στο κάτω μέρος (ένας ενεργός συντηρητής). Στόχος σας είναι να μειώσετε τις τριβές σε κάθε στάδιο της εμπειρίας του συνεισφέροντος. Όταν οι άνθρωποι έχουν εύκολες επιτυχίες, θα νιώθουν κίνητρο να κάνουν περισσότερα.
 
-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.
+* **Κάντε εύκολο για κάποιον να χρησιμοποιήσει το πρότζεκτ σας.** [Ένα φιλικό README](../starting-a-project/#writing-a-readme) και σαφή παραδείγματα κώδικα θα διευκολύνουν οποιονδήποτε βρεθεί στο πρότζεκτ σας να ξεκινήσει.
+* **Εξηγήστε με σαφήνεια πώς να συνεισφέρετε**, χρησιμοποιώντας [το αρχείο CONTRIBUTING](../starting-a-project/#writing-your-contributing-guidelines) και διατηρώντας τα θέματά σας ενημερωμένα.
+* **Καλά πρώτα θέματα**: Για να βοηθήσετε τους νέους συνεισφέροντες να ξεκινήσουν, σκεφτείτε ρητά [την επισήμανση θεμάτων που είναι αρκετά απλά για να τα αντιμετωπίσουν οι αρχάριοι](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Στη συνέχεια, το GitHub θα εμφανίσει αυτά τα θέματα σε διάφορα σημεία της πλατφόρμας, αυξάνοντας τις χρήσιμες συνεισφορές και μειώνοντας τις τριβές από τους χρήστες που αντιμετωπίζουν θέματα που είναι πολύ δύσκολα για το επίπεδό τους.
 
-[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.
+[Η έρευνα του GitHub για τον ανοικτό κώδικα του 2017](http://opensourcesurvey.org/2017/) έδειξε ότι η ελλιπής ή συγκεχυμένη τεκμηρίωση είναι το μεγαλύτερο πρόβλημα για τους χρήστες ανοικτού κώδικα. Η καλή τεκμηρίωση προσκαλεί τους ανθρώπους να αλληλεπιδράσουν με το πρότζεκτ σας. Τελικά, κάποιος θα ανοίξει ένα ζήτημα ή ένα αίτημα. Χρησιμοποιήστε αυτές τις αλληλεπιδράσεις ως ευκαιρίες για να τους μετακινήσετε προς τα κάτω στο χωνί.
 
-* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
-* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
-* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or a small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
-* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#μαθαίνοντας-να-λέτε-όχι) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+* **Όταν κάποιος νέος μπαίνει στο έργο σας, ευχαριστήστε τον για το ενδιαφέρον του!** Αρκεί μια αρνητική εμπειρία για να κάνει κάποιον να μην θέλει να επιστρέψει.
+* **Ανταποκριθείτε.** Αν δεν απαντήσετε στο θέμα τους για ένα μήνα, οι πιθανότητες είναι ότι έχουν ήδη ξεχάσει το έργο σας.
+* **Να είστε ανοιχτόμυαλοι όσον αφορά τους τύπους συνεισφορών που θα δεχτείτε.** Πολλοί συνεισφέροντες ξεκινούν με μια αναφορά σφάλματος ή μια μικρή διόρθωση. Υπάρχουν [πολλοί τρόποι συνεισφοράς](../how-to-contribute/#what-it-means-to-contribute) σε ένα πρότζεκτ. Αφήστε τους ανθρώπους να βοηθήσουν με τον τρόπο που θέλουν να βοηθήσουν.
+* **Αν υπάρχει μια συνεισφορά με την οποία διαφωνείτε,** ευχαριστήστε τους για την ιδέα τους και [εξηγήστε γιατί](../best-practices/#μαθαίνοντας-να-λέτε-όχι) δεν ταιριάζει στο πεδίο εφαρμογής του πρότζεκτυ, παραπέμποντας στη σχετική τεκμηρίωση αν την έχετε.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns.
+  Η συνεισφορά στον ανοιχτό κώδικα είναι ευκολότερη για κάποιους από άλλους. Υπάρχει μεγάλος φόβος να τους φωνάξουν ότι δεν κάνουν κάτι σωστά ή ότι απλά δεν ταιριάζουν. (...) Δίνοντας στους συνεισφέροντες ένα μέρος για να συνεισφέρουν με πολύ χαμηλή τεχνική επάρκεια (τεκμηρίωση, markdown περιεχομένου ιστού, κ.λπ.) μπορείτε να μειώσετε σημαντικά αυτές τις ανησυχίες.
   <p markdown="1" class="pquote-credit">
-— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+- @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
   </p>
 </aside>
 
-The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute.
+Η πλειονότητα των συνεισφερόντων ανοιχτού κώδικα είναι "περιστασιακοί συνεισφέροντες": άνθρωποι που συνεισφέρουν σε ένα πρότζεκτ μόνο περιστασιακά. Ένας περιστασιακός συνεισφέρων μπορεί να μην έχει χρόνο να ενημερωθεί πλήρως για το πρότζεκτ σας, οπότε η δουλειά σας είναι να τους διευκολύνετε να συνεισφέρουν.
 
-Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself.
+Η ενθάρρυνση άλλων συνεισφερόντων είναι μια επένδυση και στον εαυτό σας. Όταν εξουσιοδοτείτε τους μεγαλύτερους θαυμαστές σας να ασχοληθούν με το πρότζεκτ για το οποίο είναι ενθουσιασμένοι, υπάρχει λιγότερη πίεση να κάνετε τα πάντα εσείς.
 
-### Document everything
+### Καταγράψτε τα πάντα
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
+  Έχετε πάει ποτέ σε μια (τεχνολογική) εκδήλωση όπου δεν γνωρίζατε κανέναν, αλλά όλοι οι άλλοι έμοιαζαν να στέκονται σε ομάδες και να συζητούν σαν παλιοί φίλοι; (...) Φανταστείτε τώρα ότι θέλετε να συνεισφέρετε σε ένα πρότζεκτ ανοικτού κώδικα, αλλά δεν καταλαβαίνετε γιατί ή πώς συμβαίνει αυτό.
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+- @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
-When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public.
+Όταν ξεκινάτε ένα νέο πρότζεκτ, μπορεί να σας φαίνεται φυσικό να κρατάτε την εργασία σας ιδιωτική. Αλλά τα έργα ανοικτού κώδικα ευδοκιμούν όταν τεκμηριώνετε τη διαδικασία σας δημόσια.
 
-When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed.
+Όταν καταγράφετε τα πράγματα, περισσότεροι άνθρωποι μπορούν να συμμετέχουν σε κάθε βήμα της διαδικασίας. Μπορεί να λάβετε βοήθεια για κάτι που δεν γνωρίζατε καν ότι χρειαζόσασταν.
 
-Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public.
+Η καταγραφή των πραγμάτων σημαίνει κάτι περισσότερο από απλή τεχνική τεκμηρίωση. Κάθε φορά που νιώθετε την ανάγκη να γράψετε κάτι ή να συζητήσετε κατ' ιδίαν το έργο σας, αναρωτηθείτε αν μπορείτε να το δημοσιοποιήσετε.
 
-Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions.
+Να είστε διαφανείς σχετικά με τον οδικό χάρτη του έργου σας, τα είδη των συνεισφορών που αναζητάτε, τον τρόπο εξέτασης των συνεισφορών ή τους λόγους για τους οποίους πήρατε ορισμένες αποφάσεις.
 
-If you notice multiple users running into the same problem, document the answers in the README.
+Αν παρατηρήσετε ότι πολλοί χρήστες αντιμετωπίζουν το ίδιο πρόβλημα, τεκμηριώστε τις απαντήσεις στο README.
 
-For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you.
+Για συναντήσεις, σκεφτείτε να δημοσιεύσετε τις σημειώσεις ή τα συμπεράσματα σας σε ένα σχετικό θέμα. Η ανατροφοδότηση που θα λάβετε από αυτό το επίπεδο διαφάνειας μπορεί να σας εκπλήξει.
 
-Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on.
+Η τεκμηρίωση των πάντων ισχύει και για την εργασία που κάνετε. Αν εργάζεστε σε μια ουσιαστική ενημέρωση του πρότζεκτ σας, βάλτε την σε ένα pull request και σημειώστε την ως εργασία σε εξέλιξη (WIP). Με αυτόν τον τρόπο, άλλοι άνθρωποι μπορούν να νιώσουν ότι συμμετέχουν στη διαδικασία από νωρίς.
 
-### Be responsive
+### Να ανταποκρίνεστε
 
-As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started.
+Καθώς [προωθείτε το έργο σας](../finding-users), οι άνθρωποι θα έχουν ανατροφοδότηση για εσάς. Μπορεί να έχουν ερωτήσεις σχετικά με το πώς λειτουργούν τα πράγματα ή να χρειάζονται βοήθεια για να ξεκινήσουν.
 
-Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating.
+Προσπαθήστε να ανταποκρίνεστε όταν κάποιος καταθέτει ένα ζήτημα, υποβάλλει ένα αίτημα ή κάνει μια ερώτηση σχετικά με το πρότζεκτ σας. Όταν απαντάτε γρήγορα, οι άνθρωποι θα αισθάνονται ότι είναι μέρος ενός διαλόγου και θα είναι πιο ενθουσιώδεις για τη συμμετοχή τους.
 
-Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466):
+Ακόμα και αν δεν μπορείτε να εξετάσετε το αίτημα αμέσως, η έγκαιρη αναγνώρισή του συμβάλλει στην αύξηση της δέσμευσης. Δείτε πώς απάντησε ο @tdreyno σε ένα pull request στο [Middleman](https://github.com/middleman/middleman/pull/1466):
 
 ![Middleman pull request](/assets/images/building-community/middleman_pr.png)
 
-[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution.
+[Μια μελέτη της Mozilla διαπίστωσε ότι](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) οι συνεισφέροντες που λάμβαναν αξιολογήσεις κώδικα (code reviews) εντός 48 ωρών είχαν πολύ υψηλότερο ποσοστό επιστροφής και επαναλαμβανόμενης συνεισφοράς.
 
-Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project.
+Συζητήσεις σχετικά με το πρότζεκτ σας θα μπορούσαν επίσης να συμβαίνουν και σε άλλα μέρη του διαδικτύου, όπως το Stack Overflow, το Twitter ή το Reddit. Μπορείτε να ρυθμίσετε ειδοποιήσεις σε ορισμένα από αυτά τα μέρη, ώστε να ειδοποιείστε όταν κάποιος αναφέρει το πρότζεκτ σας.
 
-### Give your community a place to congregate
+### Δώστε στην κοινότητά σας ένα μέρος για να συγκεντρωθεί
 
-There are two reasons to give your community a place to congregate.
+Υπάρχουν δύο λόγοι για να δώσετε στην κοινότητά σας ένα μέρος για να συγκεντρωθεί.
 
-The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate.
+Ο πρώτος λόγος είναι γι' αυτούς. Βοηθήστε τους ανθρώπους να γνωριστούν μεταξύ τους. Οι άνθρωποι με κοινά ενδιαφέροντα θα θέλουν αναπόφευκτα ένα μέρος για να μιλήσουν γι' αυτά. Και όταν η επικοινωνία είναι δημόσια και προσβάσιμη, ο καθένας μπορεί να διαβάσει τα αρχεία του παρελθόντος για να ενημερωθεί και να συμμετάσχει.
 
-The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel.
+Ο δεύτερος λόγος είναι για εσάς. Αν δεν δώσετε στους ανθρώπους ένα δημόσιο μέρος για να μιλήσουν για το πρότζεκτ σας, πιθανότατα θα επικοινωνήσουν απευθείας μαζί σας. Στην αρχή, μπορεί να φαίνεται αρκετά εύκολο να απαντήσετε σε ιδιωτικά μηνύματα "μόνο αυτή τη φορά". Αλλά με την πάροδο του χρόνου, ειδικά αν το πρότζεκτ σας γίνει δημοφιλές, θα νιώσετε εξαντλημένοι. Αντισταθείτε στον πειρασμό να επικοινωνείτε με τους ανθρώπους για το πρότζεκτ σας ιδιωτικά. Αντ' αυτού, κατευθύνετέ τους σε ένα καθορισμένο δημόσιο κανάλι.
 
-Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above!
+Η δημόσια επικοινωνία μπορεί να είναι τόσο απλή όσο το να κατευθύνετε τους ανθρώπους να ανοίξουν ένα θέμα αντί να σας στείλουν απευθείας email ή να σχολιάσουν στο ιστολόγιό σας. Θα μπορούσατε επίσης να δημιουργήσετε μια λίστα αλληλογραφίας ή έναν λογαριασμό στο Twitter, το Slack ή ένα κανάλι IRC για να συζητούν οι άνθρωποι για το πρότζεκτ σας. Ή δοκιμάστε όλα τα παραπάνω!
 
-[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members:
+Το [Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) ορίζει ώρες γραφείου κάθε δεύτερη εβδομάδα για να βοηθήσει τα μέλη της κοινότητας:
 
-> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.
+> Το Kops διαθέτει επίσης χρόνο που ορίζεται κάθε δεύτερη εβδομάδα για να προσφέρει βοήθεια και καθοδήγηση στην κοινότητα. Οι συντηρητές του Kops έχουν συμφωνήσει να ορίσουν χρόνο ειδικά αφιερωμένο στη συνεργασία με νεοεισερχόμενους, στη βοήθεια με PRs και στη συζήτηση νέων χαρακτηριστικών.
 
-Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address.
+Αξιοσημείωτες εξαιρέσεις στη δημόσια επικοινωνία είναι: 1) θέματα ασφάλειας και 2) ευαίσθητες παραβιάσεις του κώδικα συμπεριφοράς. Θα πρέπει πάντα να έχετε έναν τρόπο για τους ανθρώπους να αναφέρουν αυτά τα ζητήματα ιδιωτικά. Αν δεν θέλετε να χρησιμοποιείτε το προσωπικό σας email, δημιουργήστε μια ειδική διεύθυνση email.
 
 ## Growing your community
 

From 4b2733fc61c94a59726990e5914b57132891ce69 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 5 Apr 2022 23:02:42 +0300
Subject: [PATCH 389/749] Make some more progress on building-community.md!

Also fixes some issues with some hyperlinks that would take the user
to pages that do not exist anymore due to them changing title names.
---
 _articles/el/best-practices.md            |  2 +-
 _articles/el/building-community.md        | 80 +++++++++++------------
 _articles/el/leadership-and-governance.md |  2 +-
 3 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
index dc822415245..886581b8fb7 100644
--- a/_articles/el/best-practices.md
+++ b/_articles/el/best-practices.md
@@ -169,7 +169,7 @@ related:
 
 Όταν βλέπετε νέους συνεισφέροντες να κάνουν επαναλαμβανόμενες συνεισφορές, αναγνωρίστε το έργο τους προσφέροντας περισσότερες ευθύνες. Τεκμηριώστε τον τρόπο με τον οποίο οι άλλοι μπορούν να εξελιχθούν σε ηγετικούς ρόλους αν το επιθυμούν.
 
-Το να ενθαρρύνετε τους άλλους να [μοιράζονται την ιδιοκτησία του έργου](../building-community/#share-ownership-of-your-project) μπορεί να μειώσει σημαντικά τον δικό σας φόρτο εργασίας, όπως ανακάλυψε η @lmccart στο έργο της, [p5.js](https://github.com/processing/p5.js).
+Το να ενθαρρύνετε τους άλλους να [μοιράζονται την ιδιοκτησία του έργου](../building-community/#μοιραστείτε-την-ιδιοκτησία-του-πρότζεκτ-σας) μπορεί να μειώσει σημαντικά τον δικό σας φόρτο εργασίας, όπως ανακάλυψε η @lmccart στο έργο της, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index 8faab57892b..f6cf788e274 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -103,103 +103,103 @@ related:
 
 Αξιοσημείωτες εξαιρέσεις στη δημόσια επικοινωνία είναι: 1) θέματα ασφάλειας και 2) ευαίσθητες παραβιάσεις του κώδικα συμπεριφοράς. Θα πρέπει πάντα να έχετε έναν τρόπο για τους ανθρώπους να αναφέρουν αυτά τα ζητήματα ιδιωτικά. Αν δεν θέλετε να χρησιμοποιείτε το προσωπικό σας email, δημιουργήστε μια ειδική διεύθυνση email.
 
-## Growing your community
+## Μεγαλώνοντας την κοινότητά σας
 
-Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction.
+Οι κοινότητες είναι εξαιρετικά ισχυρές. Αυτή η δύναμη μπορεί να είναι ευλογία ή κατάρα, ανάλογα με τον τρόπο που την ασκείτε. Καθώς η κοινότητα του πρότζεκτ σας μεγαλώνει, υπάρχουν τρόποι να τη βοηθήσετε να γίνει μια δύναμη οικοδόμησης και όχι καταστροφής.
 
-### Don't tolerate bad actors
+### Μην ανέχεστε τους κακούς φορείς
 
-Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others.
+Κάθε δημοφιλές πρότζεκτ θα προσελκύσει αναπόφευκτα ανθρώπους που βλάπτουν, αντί να βοηθούν, την κοινότητά σας. Μπορεί να ξεκινήσουν περιττές συζητήσεις, να τσακωθούν για ασήμαντα χαρακτηριστικά ή να εκφοβίσουν άλλους.
 
-Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave.
+Κάντε ό,τι μπορείτε για να υιοθετήσετε μια πολιτική μηδενικής ανοχής απέναντι σε αυτούς τους τύπους ανθρώπων. Αν δεν ελεγχθούν, οι αρνητικοί άνθρωποι θα κάνουν τους άλλους ανθρώπους της κοινότητάς σας να νιώθουν άβολα. Μπορεί ακόμη και να φύγουν.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
-  The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.
+  Η αλήθεια είναι ότι η ύπαρξη μιας υποστηρικτικής κοινότητας είναι το κλειδί. Δεν θα μπορούσα ποτέ να κάνω αυτή τη δουλειά χωρίς τη βοήθεια των συναδέλφων μου, των φιλικών αγνώστων στο διαδίκτυο και των φλύαρων καναλιών IRC. (...) Μην συμβιβάζεστε με λιγότερα. Μην συμβιβάζεστε με μαλάκες.
   <p markdown="1" class="pquote-credit">
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+- @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
   </p>
 </aside>
 
-Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
+Οι τακτικές συζητήσεις για ασήμαντες πτυχές του πρότζεκτ σας αποσπούν την προσοχή των άλλων, συμπεριλαμβανομένου και εσάς, από το να επικεντρωθούν σε σημαντικά καθήκοντα. Τα νέα άτομα που φτάνουν στο πρότζεκτ σας μπορεί να δουν αυτές τις συζητήσεις και να μην θέλουν να συμμετάσχουν.
 
-When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations.
+Όταν βλέπετε αρνητική συμπεριφορά να συμβαίνει στο πρότζεκτ σας, φωνάξτε την δημόσια. Εξηγήστε, με ευγενικό αλλά αυστηρό τόνο, γιατί η συμπεριφορά τους δεν είναι αποδεκτή. Αν το πρόβλημα επιμένει, ίσως χρειαστεί να [τους ζητήσετε να φύγουν](../code-of-conduct/#enforcing-your-code-of-conduct). Ο [κώδικας δεοντολογίας](../code-of-conduct/) μπορεί να αποτελέσει εποικοδομητικό οδηγό για αυτές τις συζητήσεις.
 
-### Meet contributors where they're at
+### Συναντήστε τους συνεισφέροντες εκεί που βρίσκονται
 
-Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need.
+Η καλή τεκμηρίωση γίνεται όλο και πιο σημαντική καθώς η κοινότητά σας μεγαλώνει. Οι περιστασιακοί συνεισφέροντες, οι οποίοι μπορεί διαφορετικά να μην είναι εξοικειωμένοι με το πρότζεκτ σας, διαβάζουν την τεκμηρίωσή σας για να αποκτήσουν γρήγορα το πλαίσιο που χρειάζονται.
 
-In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors.
+Στο αρχείο σας CONTRIBUTING, πείτε ρητά στους νέους συνεισφέροντες πώς να ξεκινήσουν. Ίσως μάλιστα να θέλετε να φτιάξετε μια ειδική ενότητα για το σκοπό αυτό. Το [Django](https://github.com/django/django), για παράδειγμα, έχει μια ειδική σελίδα για να καλωσορίζει τους νέους συνεισφέροντες.
 
 ![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
 
-In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started.
+Στην ουρά θεμάτων σας, επισημάνετε σφάλματα που είναι κατάλληλα για διαφορετικούς τύπους συνεισφερόντων: για παράδειγμα, [_"μόνο για πρωτοεμφανιζόμενους"_](https://kentcdodds.com/blog/first-timers-only), _"καλό πρώτο θέμα"_, ή _"τεκμηρίωση"_. [Αυτές οι ετικέτες](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) διευκολύνουν κάποιον νέο στο πρότζεκτ σας να σαρώσει γρήγορα τα θέματά σας και να ξεκινήσει.
 
-Finally, use your documentation to make people feel welcome at every step of the way.
+Τέλος, χρησιμοποιήστε την τεκμηρίωσή σας για να κάνετε τους ανθρώπους να αισθάνονται ευπρόσδεκτοι σε κάθε βήμα της διαδικασίας.
 
-You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration.
+Δεν θα αλληλεπιδράσετε ποτέ με τους περισσότερους ανθρώπους που θα βρεθούν στο πρότζεκτ σας. Μπορεί να υπάρξουν συνεισφορές που δεν λάβατε επειδή κάποιος ένιωσε εκφοβισμένος ή δεν ήξερε από πού να ξεκινήσει. Ακόμη και μερικά καλά λόγια μπορούν να αποτρέψουν κάποιον από το να εγκαταλείψει το πρότζεκτ σας απογοητευμένος.
 
-For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+Για παράδειγμα, να πώς ξεκινάει ο [Rubinius](https://github.com/rubinius/rubinius/) τον [οδηγό συνεισφοράς του](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
 
-> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
+> Θέλουμε να ξεκινήσουμε λέγοντας σας ευχαριστούμε που χρησιμοποιείτε το Rubinius. Αυτό το πρότζεκτ είναι έργο αγάπης και εκτιμούμε όλους τους χρήστες που εντοπίζουν σφάλματα, κάνουν βελτιώσεις στην απόδοση και βοηθούν με την τεκμηρίωση. Κάθε συνεισφορά έχει νόημα, γι' αυτό σας ευχαριστούμε για τη συμμετοχή σας. Τούτου λεχθέντος, παραθέτουμε μερικές οδηγίες που σας ζητάμε να ακολουθήσετε ώστε να μπορέσουμε να αντιμετωπίσουμε με επιτυχία το πρόβλημά σας.
 
-### Share ownership of your project
+### Μοιραστείτε την ιδιοκτησία του πρότζεκτ σας
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
-  Your leaders will have different opinions, as all healthy communities should! However, you need to take steps to ensure the loudest voice doesn't always win by tiring people out, and that less prominent and minority voices are heard.
+  Οι ηγέτες σας θα έχουν διαφορετικές απόψεις, όπως πρέπει να έχουν όλες οι υγιείς κοινότητες! Ωστόσο, πρέπει να λάβετε μέτρα για να διασφαλίσετε ότι η πιο δυνατή φωνή δεν κερδίζει πάντα, κουράζοντας τους ανθρώπους, και ότι ακούγονται οι λιγότερο εξέχουσες και μειονοτικές φωνές.
   <p markdown="1" class="pquote-credit">
-— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+- @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
   </p>
 </aside>
 
-People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around.
+Οι άνθρωποι είναι ενθουσιασμένοι να συνεισφέρουν σε πρότζεκτς όταν αισθάνονται την αίσθηση της ιδιοκτησίας. Αυτό δεν σημαίνει ότι πρέπει να παραδώσετε το όραμα του πρότζεκτ σας ή να δεχτείτε συνεισφορές που δεν θέλετε. Αλλά όσο περισσότερο δίνετε τα εύσημα στους άλλους, τόσο περισσότερο θα παραμείνουν στο πρότζεκτ.
 
-See if you can find ways to share ownership with your community as much as possible. Here are some ideas:
+Δείτε αν μπορείτε να βρείτε τρόπους να μοιράζεστε την ιδιοκτησία με την κοινότητά σας όσο το δυνατόν περισσότερο. Ακολουθούν μερικές ιδέες:
 
-* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself.
+* **Αποφύγετε την επιδιόρθωση εύκολων (μη κρίσιμων) σφαλμάτων.** Αντ' αυτού, χρησιμοποιήστε τα ως ευκαιρίες για να προσλάβετε νέους συνεισφέροντες ή να καθοδηγήσετε κάποιον που θα ήθελε να συνεισφέρει. Μπορεί να φαίνεται αφύσικο στην αρχή, αλλά η επένδυσή σας θα αποδώσει με την πάροδο του χρόνου. Για παράδειγμα, ο @michaeljoseph ζήτησε από έναν συνεργάτη να υποβάλει ένα pull request για ένα πρόβλημα [Cookiecutter](https://github.com/audreyr/cookiecutter) παρακάτω, αντί να το διορθώσει ο ίδιος.
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
+* **Ξεκινήστε ένα αρχείο CONTRIBUTORS ή AUTHORS στο πρότζκετ σας** το οποίο θα απαριθμεί όλους όσους έχουν συνεισφέρει στο πρότζεκτ σας, όπως κάνει το [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
 
-* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+* Αν έχετε μια σημαντική κοινότητα, **αποστείλετε ένα ενημερωτικό δελτίο ή γράψτε μια δημοσίευση στο ιστολόγιο** ευχαριστώντας τους συνεισφέροντες. Το [This Week in Rust](https://this-week-in-rust.org/) του Rust και το [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) του Hoodie είναι δύο καλά παραδείγματα.
 
-* **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.
+* **Δώστε σε κάθε συνεισφέροντα πρόσβαση για commit.** Ο @felixge διαπίστωσε ότι αυτό έκανε τους ανθρώπους [πιο ενθουσιασμένους να γυαλίζουν τις διορθώσεις τους](https://felixge.de/2013/03/11/the-pull-request-hack.html), και βρήκε ακόμα και νέους συντηρητές για πρότζεκτ στα οποία δεν είχε δουλέψει για λίγο καιρό.
 
-* 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.
+* Αν το πρότζεκτ σας είναι στο GitHub, **μεταφέρετε το πρότζκετ σας από τον προσωπικό σας λογαριασμό σε έναν [Οργανισμό](https://help.github.com/articles/creating-a-new-organization-account/)** και προσθέστε τουλάχιστον έναν εφεδρικό διαχειριστή. Οι οργανισμοί διευκολύνουν την εργασία σε πρότζεκτς με εξωτερικούς συνεργάτες.
 
-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.
+Η πραγματικότητα είναι ότι [τα περισσότερα πρότζεκτς έχουν μόνο](https://peerj.com/preprints/1233/) έναν ή δύο συντηρητές που κάνουν την περισσότερη δουλειά. Όσο μεγαλύτερο είναι το πρότζεκτ σας και όσο μεγαλύτερη είναι η κοινότητά σας, τόσο πιο εύκολο είναι να βρείτε βοήθεια.
 
-While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help.
+Παρόλο που μπορεί να μην βρίσκετε πάντα κάποιον να ανταποκριθεί στο κάλεσμα, το να στέλνετε ένα σήμα εκεί έξω αυξάνει τις πιθανότητες να βοηθήσουν και άλλοι άνθρωποι. Και όσο νωρίτερα ξεκινήσετε, τόσο νωρίτερα μπορούν να βοηθήσουν οι άνθρωποι.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
-  \[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it.
+  \[Είναι προς το συμφέρον σας\] να προσλάβετε συνεργάτες που απολαμβάνουν και είναι ικανοί να κάνουν τα πράγματα που εσείς δεν κάνετε. Σας αρέσει να προγραμματίζετε, αλλά όχι να απαντάτε σε θέματα; Τότε εντοπίστε εκείνα τα άτομα στην κοινότητά σας που το κάνουν και αφήστε τα να το κάνουν.
   <p markdown="1" class="pquote-credit">
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+- @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
   </p>
 </aside>
 
-## Resolving conflicts
+## Επίλυση συγκρούσεων
 
-In the early stages of your project, making major decisions is easy. When you want to do something, you just do it.
+Στα αρχικά στάδια του πρότζεκτ σας, η λήψη σημαντικών αποφάσεων είναι εύκολη. Όταν θέλετε να κάνετε κάτι, απλά το κάνετε.
 
-As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own.
+Καθώς το πρότζεκτ σας γίνεται πιο δημοφιλές, περισσότεροι άνθρωποι θα ενδιαφέρονται για τις αποφάσεις που παίρνετε. Ακόμα και αν δεν έχετε μια μεγάλη κοινότητα συνεισφερόντων, αν το πρότζεκτ σας έχει πολλούς χρήστες, θα βρείτε ανθρώπους να συμμετέχουν στις αποφάσεις ή να θέτουν τα δικά τους ζητήματα.
 
-For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address.
+Ως επί το πλείστον, αν έχετε καλλιεργήσει μια φιλική κοινότητα με σεβασμό και έχετε τεκμηριώσει ανοιχτά τις διαδικασίες σας, η κοινότητά σας θα μπορέσει να βρει λύση. Αλλά μερικές φορές συναντάτε ένα ζήτημα που είναι λίγο πιο δύσκολο να αντιμετωπιστεί.
 
-### Set the bar for kindness
+### Ορίστε τον πήχη της ευγένειας
 
-When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you.
+Όταν η κοινότητά σας παλεύει με ένα δύσκολο ζήτημα, τα πνεύματα μπορεί να ανέβουν. Οι άνθρωποι μπορεί να θυμώσουν ή να απογοητευτούν και να ξεσπάσουν ο ένας στον άλλον ή σε εσάς.
 
-Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive.
+Η δουλειά σας ως συντηρητής είναι να αποτρέψετε την κλιμάκωση αυτών των καταστάσεων. Ακόμα και αν έχετε ισχυρή άποψη για το θέμα, προσπαθήστε να πάρετε τη θέση του συντονιστή ή του διευκολυντή, αντί να μπείτε στη μάχη και να προωθήσετε τις απόψεις σας. Αν κάποιος είναι αγενής ή μονοπωλεί τη συζήτηση, [δράστε αμέσως](../building-community/#μην-ανέχεστε-τους-κακούς-φορείς) για να διατηρήσετε τις συζητήσεις πολιτισμένες και παραγωγικές.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
-  As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
+  Ως συντηρητής ενός πρότζεκτ, είναι εξαιρετικά σημαντικό να σέβεστε τους συνεργάτες σας. Συχνά παίρνουν πολύ προσωπικά αυτά που λέτε.
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+- @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
diff --git a/_articles/el/leadership-and-governance.md b/_articles/el/leadership-and-governance.md
index c0b8f4504b2..2171d327915 100644
--- a/_articles/el/leadership-and-governance.md
+++ b/_articles/el/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://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/#μοιραστείτε-την-ιδιοκτησία-του-πρότζεκτ-σας).
 
 ## When should I give someone commit access?
 

From 0abf12c3ca200b347da44a372dcf4e9ea675446d Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 5 Apr 2022 23:40:10 +0300
Subject: [PATCH 390/749] Finish translations on building-community.md

---
 _articles/el/building-community.md | 64 +++++++++++++++---------------
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index f6cf788e274..5fb95dccf2a 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -203,74 +203,74 @@ related:
   </p>
 </aside>
 
-Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly.
+Άλλοι άνθρωποι αναζητούν από εσάς καθοδήγηση. Δώστε το καλό παράδειγμα. Μπορείτε ακόμα να εκφράσετε απογοήτευση, δυσαρέσκεια ή ανησυχία, αλλά να το κάνετε με ηρεμία.
 
-Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you.
+Το να διατηρείτε την ψυχραιμία σας δεν είναι εύκολο, αλλά η επίδειξη ηγετικής ικανότητας βελτιώνει την υγεία της κοινότητάς σας. Το διαδίκτυο σας ευχαριστεί.
 
-### Treat your README as a constitution
+### Αντιμετωπίστε το README σας ως σύνταγμα
 
-Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion.
+Το README σας είναι [κάτι περισσότερο από ένα σύνολο οδηγιών](../starting-a-project/#writing-a-readme). Είναι επίσης ένα μέρος για να μιλήσετε για τους στόχους σας, το όραμα του προϊόντος και τον οδικό χάρτη. Αν οι άνθρωποι επικεντρώνονται υπερβολικά στη συζήτηση για την αξία ενός συγκεκριμένου χαρακτηριστικού, μπορεί να βοηθήσει να επανεξετάσετε το README σας και να μιλήσετε για το ανώτερο όραμα του πρότζεκτ σας. Η εστίαση στο README σας αποπροσωποποιεί επίσης τη συζήτηση, ώστε να μπορείτε να έχετε μια εποικοδομητική συζήτηση.
 
-### Focus on the journey, not the destination
+### Επικεντρωθείτε στο ταξίδι, όχι στον προορισμό
 
-Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns.
+Ορισμένα πρότζεκτ χρησιμοποιούν μια διαδικασία ψηφοφορίας για τη λήψη σημαντικών αποφάσεων. Αν και λογική με την πρώτη ματιά, η ψηφοφορία δίνει έμφαση στο να φτάσουμε σε μια "απάντηση", αντί να ακούτε και να αντιμετωπίζετε τις ανησυχίες του άλλου.
 
-Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place.
+Η ψηφοφορία μπορεί να γίνει πολιτική, όπου τα μέλη της κοινότητας αισθάνονται πιεσμένα να κάνουν χάρες ο ένας στον άλλον ή να ψηφίσουν με συγκεκριμένο τρόπο. Επίσης, δεν ψηφίζουν όλοι, είτε πρόκειται για τη [σιωπηλή πλειοψηφία](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) στην κοινότητά σας, είτε για σημερινούς χρήστες που δεν γνώριζαν ότι γινόταν ψηφοφορία.
 
-Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus.
+Ορισμένες φορές, η ψηφοφορία είναι απαραίτητη για την ισοφάριση. Όσο μπορείτε, ωστόσο, δώστε έμφαση στην ["αναζήτηση συναίνεσης"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) και όχι στη συναίνεση.
 
-Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion.
+Στο πλαίσιο μιας διαδικασίας αναζήτησης συναίνεσης, τα μέλη της κοινότητας συζητούν τις σημαντικότερες ανησυχίες μέχρι να νιώσουν ότι έχουν ακουστεί επαρκώς. Όταν απομένουν μόνο δευτερεύουσες ανησυχίες, η κοινότητα προχωράει μπροστά. Η "αναζήτηση συναίνεσης" αναγνωρίζει ότι μια κοινότητα μπορεί να μην είναι σε θέση να καταλήξει σε μια τέλεια απάντηση. Αντιθέτως, δίνει προτεραιότητα στην ακρόαση και τη συζήτηση.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
-  Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
+  Ένα μέρος του λόγου για τον οποίο δεν υπάρχει ένα σύστημα ψηφοφορίας για τα θέματα Atom είναι επειδή η ομάδα Atom δεν πρόκειται να ακολουθήσει ένα σύστημα ψηφοφορίας σε όλες τις περιπτώσεις. Μερικές φορές πρέπει να επιλέγουμε αυτό που θεωρούμε σωστό ακόμα και αν δεν είναι δημοφιλές. (...) Αυτό που μπορώ να προσφέρω και δεσμεύομαι να κάνω... είναι ότι η δουλειά μου είναι να ακούω την κοινότητα.
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+- @lee-dohm on [Η διαδικασία λήψης αποφάσεων του Atom](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
   </p>
 </aside>
 
-Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions.
+Ακόμα και αν δεν υιοθετείτε στην πραγματικότητα μια διαδικασία αναζήτησης συναίνεσης, ως συντηρητής πρότζεκτ, είναι σημαντικό να γνωρίζουν οι άνθρωποι ότι ακούτε. Το να κάνετε τους άλλους ανθρώπους να αισθάνονται ότι ακούγονται και να δεσμεύεστε να επιλύσετε τις ανησυχίες τους, συμβάλλει σε μεγάλο βαθμό στην εκτόνωση των ευαίσθητων καταστάσεων. Στη συνέχεια, ακολουθήστε τα λόγια σας με πράξεις.
 
-Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution.
+Μην βιάζεστε να πάρετε μια απόφαση για χάρη της επίλυσης. Βεβαιωθείτε ότι όλοι αισθάνονται ότι ακούγονται και ότι όλες οι πληροφορίες έχουν δημοσιοποιηθεί προτού προχωρήσετε προς μια λύση.
 
-### Keep the conversation focused on action
+### Κρατήστε τη συζήτηση εστιασμένη στη δράση
 
-Discussion is important, but there is a difference between productive and unproductive conversations.
+Η συζήτηση είναι σημαντική, αλλά υπάρχει διαφορά μεταξύ παραγωγικών και μη παραγωγικών συζητήσεων.
 
-Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down.
+Ενθαρρύνετε τη συζήτηση εφόσον κινείται ενεργά προς την κατεύθυνση της επίλυσης. Εάν είναι σαφές ότι η συζήτηση μαραζώνει ή ξεφεύγει από το θέμα, οι αιχμές γίνονται προσωπικές ή οι άνθρωποι τσακώνονται για ασήμαντες λεπτομέρειες, είναι καιρός να την κλείσετε.
 
-Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues.
+Το να επιτρέπετε τη συνέχιση αυτών των συζητήσεων δεν είναι μόνο κακό για το συγκεκριμένο θέμα, αλλά και για την υγεία της κοινότητάς σας. Στέλνει το μήνυμα ότι αυτού του είδους οι συζητήσεις επιτρέπονται ή ακόμη και ενθαρρύνονται, και μπορεί να αποθαρρύνει τους ανθρώπους από το να εγείρουν ή να επιλύσουν μελλοντικά ζητήματα.
 
-With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_
+Με κάθε σημείο που διατυπώνεται από εσάς ή από άλλους, αναρωτηθείτε: _"Πώς αυτό μας φέρνει πιο κοντά σε μια λύση;"_
 
-If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation.
+Εάν η συζήτηση αρχίζει να ξεφεύγει, ρωτήστε την ομάδα, _"Ποια βήματα πρέπει να ακολουθήσουμε στη συνέχεια;"_ για να επαναπροσανατολίσετε τη συζήτηση.
 
-If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it.
+Εάν μια συζήτηση είναι σαφές ότι δεν οδηγεί πουθενά, δεν υπάρχουν σαφείς ενέργειες που πρέπει να γίνουν ή η κατάλληλη ενέργεια έχει ήδη γίνει, κλείστε το θέμα και εξηγήστε γιατί το κλείσατε.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-  Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
+  Το να καθοδηγείς ένα thread προς τη χρησιμότητα χωρίς να γίνεσαι πιεστικός είναι τέχνη. Δεν θα πετύχει αν απλά νουθετήσουμε τους ανθρώπους να σταματήσουν να σπαταλούν το χρόνο τους ή αν τους ζητήσουμε να μην γράφουν αν δεν έχουν κάτι εποικοδομητικό να πουν. (...) Αντ' αυτού, πρέπει να προτείνετε τις προϋποθέσεις για περαιτέρω πρόοδο: να δώσετε στους ανθρώπους μια διαδρομή, ένα μονοπάτι να ακολουθήσουν που οδηγεί στα αποτελέσματα που θέλετε, χωρίς όμως να ακούγεται σαν να υπαγορεύετε τη συμπεριφορά.
   <p markdown="1" class="pquote-credit">
-— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+- @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
   </p>
 </aside>
 
-### Pick your battles wisely
+### Διαλέξτε τις μάχες σας με σύνεση
 
-Context is important. Consider who is involved in the discussion and how they represent the rest of the community.
+Το πλαίσιο είναι σημαντικό. Σκεφτείτε ποιος συμμετέχει στη συζήτηση και πώς εκπροσωπεί την υπόλοιπη κοινότητα.
 
-Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices.
+Είναι όλοι στην κοινότητα αναστατωμένοι ή έστω ασχολούνται με αυτό το θέμα; Ή είναι ένας μοναχικός ταραχοποιός; Μην ξεχνάτε να λαμβάνετε υπόψη τα σιωπηλά μέλη της κοινότητάς σας, όχι μόνο τις ενεργές φωνές.
 
-If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread.
+Εάν το ζήτημα δεν αντιπροσωπεύει τις ευρύτερες ανάγκες της κοινότητάς σας, ίσως χρειαστεί απλώς να αναγνωρίσετε τις ανησυχίες μερικών ανθρώπων. Αν πρόκειται για επαναλαμβανόμενο ζήτημα χωρίς σαφή λύση, παραπέμψτε τους σε προηγούμενες συζητήσεις για το θέμα και κλείστε το thread.
 
-### Identify a community tiebreaker
+### Προσδιορίστε ένα κριτήριο ισορροπίας της κοινότητας
 
-With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker.
+Με καλή συμπεριφορά και σαφή επικοινωνία, οι περισσότερες δύσκολες καταστάσεις επιλύονται. Ωστόσο, ακόμη και σε μια παραγωγική συζήτηση, μπορεί απλώς να υπάρχει διάσταση απόψεων σχετικά με το πώς πρέπει να προχωρήσουμε. Σε αυτές τις περιπτώσεις, προσδιορίστε ένα άτομο ή μια ομάδα ατόμων που μπορεί να χρησιμεύσει ως ρυθμιστής ισορροπίας.
 
-A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it.
+Ένας ισοβαθμιστής θα μπορούσε να είναι ο κύριος συντηρητής του πρότζεκτ, ή θα μπορούσε να είναι μια μικρή ομάδα ανθρώπων που λαμβάνει μια απόφαση βάσει ψηφοφορίας. Ιδανικά, έχετε προσδιορίσει έναν ισοβαθμιστή και τη σχετική διαδικασία σε ένα αρχείο GOVERNANCE πριν χρειαστεί ποτέ να το χρησιμοποιήσετε.
 
-Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible.
+Η απόφαση ισοβαθμίας σας θα πρέπει να είναι η τελευταία λύση. Τα διχαστικά ζητήματα είναι μια ευκαιρία για την κοινότητά σας να αναπτυχθεί και να μάθει. Αγκαλιάστε αυτές τις ευκαιρίες και χρησιμοποιήστε μια συνεργατική διαδικασία για να προχωρήσετε σε λύση, όπου είναι δυνατόν.
 
-## Community is the ❤️ of open source
+## Η κοινότητα είναι η ❤️ του ανοιχτού κώδικα
 
-Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience.
+Οι υγιείς, ακμάζουσες κοινότητες τροφοδοτούν τις χιλιάδες ώρες που αφιερώνονται στον ανοικτό κώδικα κάθε εβδομάδα. Πολλοί συνεισφέροντες επισημαίνουν άλλους ανθρώπους ως τον λόγο που εργάζονται - ή δεν εργάζονται - στον ανοικτό κώδικα. Μαθαίνοντας πώς να αξιοποιείτε εποικοδομητικά αυτή τη δύναμη, θα βοηθήσετε κάποιον εκεί έξω να έχει μια αξέχαστη εμπειρία ανοιχτού κώδικα.

From 91a78448b278598571aa7c062232d22f724a48ec Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Sun, 15 May 2022 11:48:26 +0300
Subject: [PATCH 391/749] Fully translate code-of-conduct.md

---
 _articles/el/code-of-conduct.md | 100 ++++++++++++++++----------------
 1 file changed, 50 insertions(+), 50 deletions(-)

diff --git a/_articles/el/code-of-conduct.md b/_articles/el/code-of-conduct.md
index 3eaa41575cb..f007e8bdb4e 100644
--- a/_articles/el/code-of-conduct.md
+++ b/_articles/el/code-of-conduct.md
@@ -10,105 +10,105 @@ related:
   - leadership
 ---
 
-## Why do I need a code of conduct?
+## Γιατί χρειάζομαι έναν κώδικα δεοντολογίας;
 
-A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.
+Ο κώδικας δεοντολογίας είναι ένα έγγραφο που καθορίζει τις προσδοκίες συμπεριφοράς για τους συμμετέχοντες στο πρότζεκτ σας. Η υιοθέτηση και η επιβολή ενός κώδικα δεοντολογίας μπορεί να συμβάλει στη δημιουργία θετικής κοινωνικής ατμόσφαιρας για την κοινότητά σας.
 
-Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.
+Οι κώδικες δεοντολογίας βοηθούν στην προστασία όχι μόνο των συμμετεχόντων σας, αλλά και εσάς τους ίδιους. Εάν συντηρείτε ένα πρότζεκτ, μπορεί να διαπιστώσετε ότι οι μη παραγωγικές συμπεριφορές των άλλων συμμετεχόντων μπορεί να σας κάνουν να νιώθετε εξαντλημένοι ή δυσαρεστημένοι με την εργασία σας με την πάροδο του χρόνου.
 
-A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with.
+Ένας κώδικας δεοντολογίας σας δίνει τη δυνατότητα να διευκολύνετε την υγιή, εποικοδομητική συμπεριφορά της κοινότητας. Το να είστε προληπτικοί μειώνει την πιθανότητα να κουραστείτε εσείς ή άλλοι από το πρότζεκτ σας και σας βοηθά να αναλάβετε δράση όταν κάποιος κάνει κάτι με το οποίο δεν συμφωνείτε.
 
-## Establishing a code of conduct
+## Καθιέρωση ενός κώδικα συμπεριφοράς
 
-Try to establish a code of conduct as early as possible: ideally, when you first create your project.
+Προσπαθήστε να καθιερώσετε έναν κώδικα συμπεριφοράς όσο το δυνατόν νωρίτερα: ιδανικά, όταν δημιουργείτε για πρώτη φορά το πρότζεκτ σας.
 
-In addition to communicating your expectations, a code of conduct describes the following:
+Εκτός από την κοινοποίηση των προσδοκιών σας, ένας κώδικας δεοντολογίας περιγράφει τα εξής:
 
-* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_
-* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_
-* What happens if someone violates the code of conduct
-* How someone can report violations
+* Πού τίθεται σε ισχύ ο κώδικας συμπεριφοράς _(μόνο σε θέματα και αιτήσεις διανομής ή σε δραστηριότητες της κοινότητας, όπως εκδηλώσεις;)_
+* Σε ποιους ισχύει ο κώδικας συμπεριφοράς _(μέλη της κοινότητας και συντηρητές, αλλά τι γίνεται με τους χορηγούς;)_
+* Τι συμβαίνει αν κάποιος παραβιάσει τον κώδικα συμπεριφοράς
+* Πώς μπορεί κάποιος να αναφέρει παραβιάσεις
 
-Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
+Όπου μπορείτε, χρησιμοποιήστε την προϋπάρχουσα τέχνη. Το [Contributor Covenant] (https://contributor-covenant.org/) είναι ένας drop-in κώδικας συμπεριφοράς που χρησιμοποιείται από πάνω από 40.000 έργα ανοικτού κώδικα, συμπεριλαμβανομένων των Kubernetes, Rails και Swift.
 
-The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples.
+Ο [Django Code of Conduct](https://www.djangoproject.com/conduct/) και ο [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) είναι επίσης δύο καλά παραδείγματα κώδικα συμπεριφοράς.
 
-Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
+Τοποθετήστε ένα αρχείο CODE_OF_CONDUCT στο ριζικό κατάλογο του πρότζεκτ σας και κάντε το ορατό στην κοινότητά σας, συνδέοντάς το από το αρχείο CONTRIBUTING ή README.
 
-## Deciding how you'll enforce your code of conduct
+## Αποφασίζοντας πώς θα επιβάλλετε τον κώδικα συμπεριφοράς σας
 
 <aside markdown="1" class="pquote">
-  A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
+  Ένας κώδικας συμπεριφοράς που δεν επιβάλλεται (ή δεν μπορεί να επιβληθεί) είναι χειρότερος από το να μην υπάρχει καθόλου κώδικας συμπεριφοράς: στέλνει το μήνυμα ότι οι αξίες του κώδικα συμπεριφοράς δεν είναι στην πραγματικότητα σημαντικές ή σεβαστές στην κοινότητά σας.
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+- [Πρωτοβουλία Ada](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
-You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:
+Θα πρέπει να εξηγήσετε πώς θα επιβληθεί ο κώδικας συμπεριφοράς σας **_πριν_** συμβεί μια παραβίαση. Υπάρχουν διάφοροι λόγοι για να το κάνετε αυτό:
 
-* It demonstrates that you are serious about taking action when it's needed.
+* Δείχνει ότι είστε σοβαροί στο να αναλάβετε δράση όταν χρειάζεται.
 
-* Your community will feel more reassured that complaints actually get reviewed.
+* Η κοινότητά σας θα αισθάνεται πιο καθησυχαστική ότι οι καταγγελίες πράγματι εξετάζονται.
 
-* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.
+* Θα καθησυχάσετε την κοινότητά σας ότι η διαδικασία επανεξέτασης είναι δίκαιη και διαφανής, σε περίπτωση που ποτέ βρεθούν υπό διερεύνηση για παραβίαση.
 
-You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
+Θα πρέπει να δώσετε στους ανθρώπους έναν ιδιωτικό τρόπο (όπως μια διεύθυνση ηλεκτρονικού ταχυδρομείου) για να αναφέρουν μια παραβίαση του κώδικα δεοντολογίας και να εξηγήσετε ποιος λαμβάνει αυτή την αναφορά. Θα μπορούσε να είναι ένας συντηρητής, μια ομάδα συντηρητών ή μια ομάδα εργασίας κώδικα δεοντολογίας.
 
-Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+Μην ξεχνάτε ότι κάποιος μπορεί να θέλει να αναφέρει μια παραβίαση για ένα άτομο που λαμβάνει αυτές τις αναφορές. Σε αυτή την περίπτωση, δώστε τους τη δυνατότητα να αναφέρουν τις παραβιάσεις σε κάποιον άλλο. Για παράδειγμα, οι @ctb και @mr-c [εξηγούν για το πρότζεκτ τους](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
-> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+> Περιπτώσεις καταχρηστικής, παρενοχλητικής ή άλλως απαράδεκτης συμπεριφοράς μπορούν να αναφερθούν στέλνοντας email στο **khmer-project@idyll.org**, το οποίο απευθύνεται μόνο στους C. Titus Brown και Michael R. Crusoe. Για να αναφέρετε ένα θέμα που αφορά κάποιον από τους δύο, στείλτε email στον **Judi Brown Clarke, Ph.D.**, τον διευθυντή ποικιλομορφίας στο Κέντρο BEACON για τη μελέτη της εξέλιξης στην πράξη, ένα Κέντρο Επιστήμης και Τεχνολογίας του NSF*.
 
-For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+Για έμπνευση, δείτε το [εγχειρίδιο επιβολής](https://www.djangoproject.com/conduct/enforcement-manual/) του Django (αν και μπορεί να μην χρειάζεστε κάτι τόσο περιεκτικό, ανάλογα με το μέγεθος του πρότζεκτ σας).
 
-## Enforcing your code of conduct
+## Επιβολή του κώδικα συμπεριφοράς σας
 
-Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up.
+Μερικές φορές, παρά τις προσπάθειές σας, κάποιος θα κάνει κάτι που παραβιάζει αυτόν τον κώδικα. Υπάρχουν διάφοροι τρόποι για να αντιμετωπίσετε την αρνητική ή επιβλαβή συμπεριφορά όταν αυτή προκύψει.
 
-### Gather information about the situation
+### Συγκεντρώστε πληροφορίες σχετικά με την κατάσταση
 
-Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment.
+Αντιμετωπίστε τη φωνή κάθε μέλους της κοινότητας εξίσου σημαντική με τη δική σας. Αν λάβετε μια αναφορά ότι κάποιος παραβίασε τον κώδικα συμπεριφοράς, πάρτε την στα σοβαρά και ερευνήστε το θέμα, ακόμη και αν δεν ταιριάζει με τη δική σας εμπειρία με το συγκεκριμένο άτομο. Με τον τρόπο αυτό σηματοδοτείτε στην κοινότητά σας ότι εκτιμάτε την άποψή της και εμπιστεύεστε την κρίση της.
 
-The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context.
+Το εν λόγω μέλος της κοινότητας μπορεί να είναι ένας επαναλαμβανόμενος παραβάτης που κάνει τους άλλους να αισθάνονται συνεχώς άβολα, ή μπορεί να έχει πει ή κάνει κάτι μόνο μία φορά. Και τα δύο μπορούν να αποτελέσουν λόγο για τη λήψη μέτρων, ανάλογα με το πλαίσιο.
 
-Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
+Πριν απαντήσετε, δώστε χρόνο στον εαυτό σας να καταλάβει τι συνέβη. Διαβάστε τα προηγούμενα σχόλια και συζητήσεις του ατόμου για να καταλάβετε καλύτερα ποιος είναι και γιατί μπορεί να ενήργησε με αυτόν τον τρόπο. Προσπαθήστε να συγκεντρώσετε άλλες οπτικές γωνίες εκτός από τις δικές σας σχετικά με αυτό το άτομο και τη συμπεριφορά του.
 
 <aside markdown="1" class="pquote">
-  Don’t get pulled into an argument. Don’t get sidetracked into dealing with someone else’s behavior before you’ve finished dealing with the matter at hand. Focus on what you need.
+  Μην παρασύρεστε σε μια διαφωνία. Μην παρασυρθείτε στο να ασχοληθείτε με τη συμπεριφορά κάποιου άλλου πριν τελειώσετε με το θέμα που σας απασχολεί. Επικεντρωθείτε σε αυτό που χρειάζεστε.
   <p markdown="1" class="pquote-credit">
-— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+- Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
   </p>
 </aside>
 
-### Take appropriate action
+### Αναλάβετε την κατάλληλη δράση
 
-After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward.
+Αφού συγκεντρώσετε και επεξεργαστείτε επαρκείς πληροφορίες, θα πρέπει να αποφασίσετε τι πρέπει να κάνετε. Καθώς εξετάζετε τα επόμενα βήματά σας, να θυμάστε ότι στόχος σας ως συντονιστής είναι να προωθήσετε ένα ασφαλές, με σεβασμό και συνεργασία περιβάλλον. Σκεφτείτε όχι μόνο πώς να αντιμετωπίσετε την εν λόγω κατάσταση, αλλά και πώς η αντίδρασή σας θα επηρεάσει τη συμπεριφορά και τις προσδοκίες της υπόλοιπης κοινότητάς σας στο μέλλον.
 
-When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise.
+Όταν κάποιος αναφέρει μια παραβίαση του κώδικα συμπεριφοράς, είναι δική σας δουλειά, όχι δική τους, να το χειριστείτε. Ορισμένες φορές, ο καταγγέλλων αποκαλύπτει πληροφορίες με μεγάλο κίνδυνο για την καριέρα του, τη φήμη του ή τη σωματική του ακεραιότητα. Ο εξαναγκασμός τους να αντιμετωπίσουν τον παρενοχλητή τους θα μπορούσε να θέσει τον αναφέροντα σε επικίνδυνη θέση. Θα πρέπει να χειρίζεστε την άμεση επικοινωνία με το εν λόγω πρόσωπο, εκτός εάν ο δημοσιογράφος ζητήσει ρητά το αντίθετο.
 
-There are a few ways you might respond to a code of conduct violation:
+Υπάρχουν μερικοί τρόποι με τους οποίους μπορείτε να αντιδράσετε σε μια παραβίαση του κώδικα δεοντολογίας:
 
-* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication.
+* **Δώστε στο εν λόγω άτομο μια δημόσια προειδοποίηση** και εξηγήστε πώς η συμπεριφορά του επηρέασε αρνητικά τους άλλους, κατά προτίμηση στο κανάλι όπου συνέβη. Όπου είναι δυνατόν, η δημόσια επικοινωνία μεταφέρει στην υπόλοιπη κοινότητα ότι παίρνετε σοβαρά τον κώδικα συμπεριφοράς. Να είστε ευγενικοί, αλλά αυστηροί στην επικοινωνία σας.
 
-* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them.
+* **Επικοινωνήστε ιδιωτικά με το εν λόγω άτομο** για να εξηγήσετε πώς η συμπεριφορά του επηρέασε αρνητικά τους άλλους. Μπορεί να θέλετε να χρησιμοποιήσετε ένα ιδιωτικό κανάλι επικοινωνίας, εάν η κατάσταση αφορά ευαίσθητες προσωπικές πληροφορίες. Εάν επικοινωνήσετε με κάποιον ιδιαιτέρως, καλό θα ήταν να ενημερώσετε όσους ανέφεραν πρώτοι την κατάσταση, ώστε να γνωρίζουν ότι αναλάβατε δράση. Ζητήστε τη συγκατάθεση του ατόμου που έκανε την αναφορά πριν τον κάνετε CC.
 
-Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example:
+Μερικές φορές, δεν μπορεί να επιτευχθεί λύση. Το εν λόγω άτομο μπορεί να γίνει επιθετικό ή εχθρικό όταν έρθει αντιμέτωπο ή δεν αλλάζει τη συμπεριφορά του. Σε αυτή την περίπτωση, μπορεί να θέλετε να εξετάσετε το ενδεχόμενο να αναλάβετε ισχυρότερη δράση. Για παράδειγμα:
 
-* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project
+* **Αποβολή του εν λόγω ατόμου** από το πρότζεκτ, με προσωρινή απαγόρευση συμμετοχής σε οποιαδήποτε πτυχή του πρότζεκτ.
 
-* **Permanently ban** the person from the project
+* **Μόνιμος αποκλεισμός** του ατόμου από το πρότζεκτ
 
-Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached.
+Ο αποκλεισμός μελών δεν πρέπει να λαμβάνεται ελαφρά τη καρδία και αντιπροσωπεύει μια μόνιμη και αγεφύρωτη διαφορά απόψεων. Θα πρέπει να λαμβάνετε αυτά τα μέτρα μόνο όταν είναι σαφές ότι δεν μπορεί να επιτευχθεί λύση.
 
-## Your responsibilities as a maintainer
+## Οι ευθύνες σας ως συντηρητής
 
-A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes.
+Ένας κώδικας συμπεριφοράς δεν είναι ένας νόμος που επιβάλλεται αυθαίρετα. Εσείς είστε ο εφαρμοστής του κώδικα δεοντολογίας και είναι δική σας ευθύνη να ακολουθείτε τους κανόνες που θεσπίζει ο κώδικας δεοντολογίας.
 
-As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community.
+Ως συντηρητής θεσπίζετε τις κατευθυντήριες γραμμές για την κοινότητά σας και επιβάλλετε αυτές τις κατευθυντήριες γραμμές σύμφωνα με τους κανόνες που ορίζονται στον κώδικα συμπεριφοράς σας. Αυτό σημαίνει ότι λαμβάνετε σοβαρά υπόψη κάθε αναφορά για παραβίαση του κώδικα συμπεριφοράς. Ο καταγγέλλων οφείλει να εξετάσει διεξοδικά και δίκαια την καταγγελία του. Εάν διαπιστώσετε ότι η συμπεριφορά που ανέφεραν δεν αποτελεί παραβίαση, επικοινωνήστε το με σαφήνεια σε αυτούς και εξηγήστε τους γιατί δεν πρόκειται να λάβετε μέτρα γι' αυτό. Το τι θα κάνουν με αυτό εξαρτάται από αυτούς: να ανεχθούν τη συμπεριφορά με την οποία είχαν πρόβλημα ή να σταματήσουν να συμμετέχουν στην κοινότητα.
 
-A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable.
+Μια αναφορά συμπεριφοράς που _τεχνικά_ δεν παραβιάζει τον κώδικα συμπεριφοράς μπορεί να υποδεικνύει ότι υπάρχει πρόβλημα στην κοινότητά σας, και θα πρέπει να διερευνήσετε αυτό το πιθανό πρόβλημα και να ενεργήσετε αναλόγως. Αυτό μπορεί να περιλαμβάνει την αναθεώρηση του κώδικα συμπεριφοράς σας για να αποσαφηνίσετε την αποδεκτή συμπεριφορά ή/και να μιλήσετε με το άτομο του οποίου η συμπεριφορά αναφέρθηκε και να του πείτε ότι, ενώ δεν παραβίασε τον κώδικα συμπεριφοράς, παρακάμπτει τα όρια του αναμενόμενου και κάνει ορισμένους συμμετέχοντες να αισθάνονται άβολα.
 
-In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way.
+Τελικά, ως συντηρητής, εσείς θέτετε και επιβάλλετε τα πρότυπα αποδεκτής συμπεριφοράς. Έχετε τη δυνατότητα να διαμορφώσετε τις αξίες της κοινότητας του πρότζεκτ και οι συμμετέχοντες περιμένουν από εσάς να επιβάλλετε αυτές τις αξίες με δίκαιο και ισορροπημένο τρόπο.
 
-## Encourage the behavior you want to see in the world 🌎
+## Ενθαρρύνετε τη συμπεριφορά που θέλετε να δείτε στον κόσμο 🌎
 
-When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow.
+Όταν ένα πρότζεκτ φαίνεται εχθρικό ή μη φιλόξενο, ακόμη και αν πρόκειται για ένα μόνο άτομο του οποίου η συμπεριφορά είναι ανεκτή από τους άλλους, κινδυνεύετε να χάσετε πολλούς ακόμη συνεισφέροντες, μερικούς από τους οποίους μπορεί να μην συναντήσετε ποτέ. Δεν είναι πάντα εύκολο να υιοθετήσετε ή να επιβάλλετε έναν κώδικα συμπεριφοράς, αλλά η καλλιέργεια ενός φιλόξενου περιβάλλοντος θα βοηθήσει την κοινότητά σας να αναπτυχθεί.

From e75fbcd3b9cfc24ed4b86d46c6ab8364bd528aef Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Sun, 15 May 2022 15:36:54 +0300
Subject: [PATCH 392/749] Translate finding-users.md

---
 _articles/el/finding-users.md | 114 +++++++++++++++++-----------------
 1 file changed, 57 insertions(+), 57 deletions(-)

diff --git a/_articles/el/finding-users.md b/_articles/el/finding-users.md
index a7a4cb3226f..68cf2ef2af0 100644
--- a/_articles/el/finding-users.md
+++ b/_articles/el/finding-users.md
@@ -10,147 +10,147 @@ related:
   - building
 ---
 
-## Spreading the word
+## Διαδίδοντας τη λέξη
 
-There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work!
+Δεν υπάρχει κανένας κανόνας που να λέει ότι πρέπει να προωθήσετε ένα πρότζεκτ ανοιχτού κώδικα όταν το ξεκινάτε. Υπάρχουν πολλοί ικανοποιητικοί λόγοι για να εργαστείτε στον ανοιχτό κώδικα που δεν έχουν καμία σχέση με τη δημοτικότητα. Αντί να ελπίζετε ότι άλλοι θα βρουν και θα χρησιμοποιήσουν το πρότζεκτ σας ανοιχτού κώδικα, πρέπει να διαδώσετε τη σκληρή δουλειά σας!
 
-## Figure out your message
+## Βρείτε το μήνυμά σας
 
-Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters.
+Πριν ξεκινήσετε την πραγματική εργασία προώθησης του πρότζεκτ σας, θα πρέπει να είστε σε θέση να εξηγήσετε τι κάνει και γιατί έχει σημασία.
 
-What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance.
+Τι κάνει το πρότζεκτ σας διαφορετικό ή ενδιαφέρον; Γιατί το δημιουργήσατε; Η απάντηση αυτών των ερωτημάτων για τον εαυτό σας θα σας βοηθήσει να επικοινωνήσετε τη σημασία του πρότζεκτ σας.
 
-Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want.
+Να θυμάστε ότι οι άνθρωποι εμπλέκονται ως χρήστες και τελικά γίνονται συνεισφέροντες, επειδή το πρότζεκτ σας λύνει ένα πρόβλημα γι' αυτούς. Καθώς σκέφτεστε το μήνυμα και την αξία του πρότζεκτ σας, προσπαθήστε να τα δείτε μέσα από το πρίσμα του τι μπορεί να θέλουν οι _χρήστες και οι συνεισφέροντες_.
 
-For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
+Για παράδειγμα, ο @robb χρησιμοποιεί παραδείγματα κώδικα για να επικοινωνήσει με σαφήνεια γιατί το πρότζεκτ του, [Cartography](https://github.com/robb/Cartography), είναι χρήσιμο:
 
 ![Cartography README](/assets/images/finding-users/cartography.jpg)
 
-For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+Για μια βαθύτερη εμβάθυνση στην ανταλλαγή μηνυμάτων, δείτε την άσκηση ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) της Mozilla για την ανάπτυξη προσωπικοτήτων χρηστών.
 
-## Help people find and follow your project
+## Βοηθήστε τους ανθρώπους να βρουν και να ακολουθήσουν το πρότζεκτ σας
 
 <aside markdown="1" class="pquote">
-  You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
+  Ιδανικά χρειάζεστε μια ενιαία "αρχική" διεύθυνση URL που μπορείτε να προωθήσετε και να υποδείξετε στους ανθρώπους σε σχέση με το πρότζεκτ σας. Δεν χρειάζεται να ξοδέψετε πολλά χρήματα σε ένα φανταχτερό πρότυπο ή ακόμη και σε ένα όνομα τομέα, αλλά το πρότζεκτ σας χρειάζεται ένα σημείο εστίασης.
   <p markdown="1" class="pquote-credit">
-— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+- Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
   </p>
 </aside>
 
-Help people find and remember your project by pointing them to a single namespace.
+Βοηθήστε τους ανθρώπους να βρουν και να θυμούνται το πρότζεκτ σας, δείχνοντάς τους ένα ενιαίο χώρο ονομάτων.
 
-**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.
+**Να έχετε ένα ξεκάθαρο χειριστήριο για να προωθήσετε το πρότζεκτ σας.** Ένα χειριστήριο στο Twitter, μια διεύθυνση URL στο GitHub ή ένα κανάλι IRC είναι ένας εύκολος τρόπος για να δείξετε στους ανθρώπους το πρότζεκτ σας. Αυτές οι διέξοδοι δίνουν επίσης στην αναπτυσσόμενη κοινότητα του πρότζεκτ σας ένα μέρος για να συγκεντρώνεται.
 
-If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. 
+Αν δεν επιθυμείτε να δημιουργήσετε ακόμη διεξόδους για το πρότζεκτ σας, προωθήστε τη δική σας λαβή Twitter ή GitHub σε ό,τι κάνετε. Η προώθηση της λαβής σας στο Twitter ή το GitHub θα ενημερώσει τους ανθρώπους για το πώς μπορούν να επικοινωνήσουν μαζί σας ή να παρακολουθήσουν το πρότζεκτ σας. Αν μιλήσετε σε μια συνάντηση ή εκδήλωση, βεβαιωθείτε ότι τα στοιχεία επικοινωνίας σας περιλαμβάνονται στο βιογραφικό σας ή στις διαφάνειές σας. 
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
-  A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project.
+  Ένα λάθος που έκανα εκείνες τις πρώτες μέρες (...) ήταν ότι δεν ξεκίνησα λογαριασμό στο Twitter για το πρότζεκτ. Το Twitter είναι ένας πολύ καλός τρόπος για να κρατάς τους ανθρώπους ενήμερους για ένα πρότζεκτ καθώς και να εκθέτεις συνεχώς τους ανθρώπους στο πρότζεκτ.
   <p markdown="1" class="pquote-credit">
-— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+- @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
   </p>
 </aside>
 
-**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project.
+**Σκεφτείτε να δημιουργήσετε έναν ιστότοπο για το πρότζεκτ σας.** Ένας ιστότοπος κάνει το πρότζεκτ σας πιο φιλικό και πιο εύκολο στην πλοήγηση, ειδικά όταν συνδυάζεται με σαφή τεκμηρίωση και σεμινάρια. Η ύπαρξη ιστότοπου υποδηλώνει επίσης ότι το πρότζεκτ σας είναι ενεργό, γεγονός που θα κάνει το κοινό σας να αισθάνεται πιο άνετα στη χρήση του. Παρέχετε παραδείγματα για να δώσετε στους ανθρώπους ιδέες για το πώς να χρησιμοποιήσουν το πρότζεκτ σας.
 
-[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_.
+Ο [@adrianholovaty](https://news.ycombinator.com/item?id=7531689), συνδημιουργός του Django, δήλωσε ότι ένας ιστότοπος ήταν _"μακράν το καλύτερο πράγμα που κάναμε με το Django τις πρώτες μέρες"_.
 
-If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+Αν το πρότζεκτ σας φιλοξενείται στο GitHub, μπορείτε να χρησιμοποιήσετε το [GitHub Pages](https://pages.github.com/) για να φτιάξετε εύκολα έναν ιστότοπο. Το [Yeoman](http://yeoman.io/), το [Vagrant](https://www.vagrantup.com/) και το [Middleman](https://middlemanapp.com/) είναι [μερικά παραδείγματα](https://github.com/showcases/github-pages-examples) εξαιρετικών, ολοκληρωμένων ιστοσελίδων.
 
-![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
+![Αρχική σελίδα του Vagrant](/assets/images/finding-users/vagrant_homepage.png)
 
-Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!
+Τώρα που έχετε ένα μήνυμα για το πρότζεκτ σας και έναν εύκολο τρόπο για να βρουν οι άνθρωποι το πρότζεκτ σας, ας βγούμε εκεί έξω και ας μιλήσουμε στο κοινό σας!
 
-## Go where your project's audience is (online)
+## Πηγαίνετε εκεί όπου βρίσκεται το κοινό του πρότζεκτ σας (online)
 
-Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
+Η διαδικτυακή προβολή είναι ένας πολύ καλός τρόπος για να μοιραστείτε και να διαδώσετε το μήνυμα γρήγορα. Χρησιμοποιώντας διαδικτυακά κανάλια, έχετε τη δυνατότητα να προσεγγίσετε ένα πολύ ευρύ κοινό.
 
-Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+Εκμεταλλευτείτε τις υπάρχουσες διαδικτυακές κοινότητες και πλατφόρμες για να προσεγγίσετε το κοινό σας. Εάν το πρότζεκτ σας ανοικτού κώδικα είναι ένα πρότζεκτ λογισμικού, μπορείτε πιθανώς να βρείτε το κοινό σας στο [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/) ή [Quora](https://www.quora.com/). Βρείτε τα κανάλια στα οποία πιστεύετε ότι οι άνθρωποι θα επωφεληθούν περισσότερο ή θα ενθουσιαστούν με το πρότζεκτ σας.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
-  Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project.
+  Κάθε πρόγραμμα έχει πολύ συγκεκριμένες λειτουργίες που μόνο ένα κλάσμα των χρηστών θα βρει χρήσιμες. Μην κάνετε spam σε όσο το δυνατόν περισσότερους ανθρώπους. Αντίθετα, στοχεύστε τις προσπάθειές σας σε κοινότητες που θα επωφεληθούν από τη γνώση του προγράμματός σας.
   <p markdown="1" class="pquote-credit">
-— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+- @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
   </p>
 </aside>
 
-See if you can find ways to share your project in relevant ways:
+Δείτε αν μπορείτε να βρείτε τρόπους να μοιραστείτε το πρότζεκτ σας με σχετικούς τρόπους:
 
-* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.
-* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.
-* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work.
+* **Γνωρίστε σχετικά έργα και κοινότητες ανοικτού κώδικα.** Μερικές φορές, δεν χρειάζεται να προωθήσετε άμεσα το πρότζεκτ σας. Αν το πρότζεκτ σας είναι ιδανικό για επιστήμονες δεδομένων που χρησιμοποιούν Python, γνωρίστε την κοινότητα επιστήμης δεδομένων Python. Καθώς οι άνθρωποι θα σας γνωρίζουν, θα προκύψουν φυσικές ευκαιρίες για να μιλήσετε και να μοιραστείτε το πρότζεκτ σας.
+* **Βρείτε ανθρώπους που αντιμετωπίζουν το πρόβλημα που λύνει το πρότζεκτ σας.** Ψάξτε σε σχετικά φόρουμ για ανθρώπους που ανήκουν στο κοινό-στόχο του πρότζεκτ σας. Απαντήστε στην ερώτησή τους και βρείτε έναν διακριτικό τρόπο, όταν χρειάζεται, να προτείνετε το πρότζεκτ σας ως λύση.
+* **Ζητήστε ανατροφοδότηση.** Παρουσιάστε τον εαυτό σας και το πρότζεκτ σας σε ένα κοινό που θα το βρει σχετικό και ενδιαφέρον. Να είστε συγκεκριμένοι σχετικά με το ποιος πιστεύετε ότι θα επωφεληθεί από το πρότζεκτ σας. Προσπαθήστε να ολοκληρώσετε την πρόταση: _"Νομίζω ότι το πρότζεκτ μου θα βοηθούσε πραγματικά τον Χ, ο οποίος προσπαθεί να κάνει Υ_". Ακούστε και απαντήστε στα σχόλια των άλλων, αντί να προωθείτε απλώς το πρότζεκτ σας.
 
-Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want.
+Σε γενικές γραμμές, επικεντρωθείτε στο να βοηθάτε τους άλλους προτού ζητήσετε πράγματα σε αντάλλαγμα. Επειδή ο καθένας μπορεί εύκολα να προωθήσει ένα πρότζεκτ στο διαδίκτυο, θα υπάρχει πολύς θόρυβος. Για να ξεχωρίσετε από το πλήθος, δώστε στους ανθρώπους το πλαίσιο για το ποιοι είστε και όχι απλώς τι θέλετε.
 
-If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication.
+Αν κανείς δεν δώσει σημασία ή δεν ανταποκριθεί στην αρχική σας προβολή, μην αποθαρρύνεστε! Οι περισσότερες εκκινήσεις έργων είναι μια επαναληπτική διαδικασία που μπορεί να διαρκέσει μήνες ή και χρόνια. Αν δεν έχετε ανταπόκριση με την πρώτη φορά, δοκιμάστε μια διαφορετική τακτική ή αναζητήστε πρώτα τρόπους να προσθέσετε αξία στο πρότζεκτ άλλων. Η προώθηση και η έναρξη του πρότζεκτ σας απαιτεί χρόνο και αφοσίωση.
 
-## Go where your project's audience is (offline)
+## Πηγαίνετε εκεί όπου βρίσκεται το κοινό του πρότζεκτ σας (εκτός σύνδεσης)
 
-![Public speaking](/assets/images/finding-users/public_speaking.jpg)
+![Δημόσια ομιλία](/assets/images/finding-users/public_speaking.jpg)
 
-Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.
+Οι offline εκδηλώσεις είναι ένας δημοφιλής τρόπος για την προώθηση νέων έργων στο κοινό. Είναι ένας πολύ καλός τρόπος για να προσεγγίσετε ένα αφοσιωμένο κοινό και να οικοδομήσετε βαθύτερες ανθρώπινες σχέσεις, ειδικά αν ενδιαφέρεστε να προσεγγίσετε προγραμματιστές.
 
-If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.
+Αν είστε [νέος στη δημόσια ομιλία](https://speaking.io/), ξεκινήστε βρίσκοντας μια τοπική συνάντηση που σχετίζεται με τη γλώσσα ή το οικοσύστημα του πρότζεκτ σας.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
-  I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
+  Ήμουν αρκετά αγχωμένος που θα πήγαινα στο PyCon. Θα έδινα μια ομιλία, θα γνώριζα μόνο μερικούς ανθρώπους εκεί, θα πήγαινα για μια ολόκληρη εβδομάδα. (...) Δεν έπρεπε να ανησυχώ, όμως. Το PyCon ήταν εκπληκτικά φοβερό! (...) Όλοι ήταν απίστευτα φιλικοί και εξωστρεφείς, τόσο πολύ που σπάνια έβρισκα χρόνο να μην μιλήσω με τους ανθρώπους!
   <p markdown="1" class="pquote-credit">
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+- @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
   </p>
 </aside>
 
-If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.
+Αν δεν έχετε ξαναμιλήσει ποτέ σε εκδήλωση, είναι απολύτως φυσιολογικό να αισθάνεστε νευρικοί! Να θυμάστε ότι το κοινό σας είναι εκεί επειδή θέλει πραγματικά να ακούσει για τη δουλειά σας.
 
-As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.
+Καθώς γράφετε την ομιλία σας, επικεντρωθείτε σε αυτό που το ακροατήριό σας θα βρει ενδιαφέρον και θα έχει αξία. Κρατήστε τη γλώσσα σας φιλική και προσιτή. Χαμογελάστε, αναπνεύστε και διασκεδάστε.
 
 <aside markdown="1" class="pquote">
   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
-  When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+  Όταν αρχίζετε να γράφετε την ομιλία σας, ανεξάρτητα από το θέμα σας, μπορεί να σας βοηθήσει αν δείτε την ομιλία σας ως μια ιστορία που θα αφηγηθείτε στους ανθρώπους.
   <p markdown="1" class="pquote-credit">
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+- Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
   </p>
 </aside>
 
-When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.
+Όταν νιώσετε έτοιμοι, σκεφτείτε να μιλήσετε σε ένα συνέδριο για να προωθήσετε το πρότζεκτ σας. Τα συνέδρια μπορούν να σας βοηθήσουν να προσεγγίσετε περισσότερους ανθρώπους, μερικές φορές από όλο τον κόσμο.
 
-Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers.
+Αναζητήστε συνέδρια που είναι ειδικά για τη γλώσσα ή το οικοσύστημά σας. Πριν υποβάλετε την ομιλία σας, ερευνήστε το συνέδριο για να προσαρμόσετε την ομιλία σας στους συμμετέχοντες και να αυξήσετε τις πιθανότητες να γίνετε δεκτοί να μιλήσετε στο συνέδριο. Συχνά μπορείτε να πάρετε μια ιδέα για το ακροατήριό σας κοιτάζοντας τους ομιλητές ενός συνεδρίου.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
-  I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?
+  Έγραψα πολύ ωραία στους ανθρώπους της JSConf και τους παρακάλεσα να μου δώσουν μια θέση όπου θα μπορούσα να το παρουσιάσω στην JSConf EU. (...) Ήμουν εξαιρετικά φοβισμένος, παρουσιάζοντας αυτό το πράγμα πάνω στο οποίο δούλευα έξι μήνες. (...) Όλη την ώρα σκεφτόμουν, ω Θεέ μου. Τι κάνω εδώ;
   <p markdown="1" class="pquote-credit">
-— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+- @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
   </p>
 </aside>
 
-## Build a reputation
+## Δημιουργήστε μια φήμη
 
-In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.
+Εκτός από τις στρατηγικές που περιγράφονται παραπάνω, ο καλύτερος τρόπος για να προσκαλέσετε τους ανθρώπους να μοιραστούν και να συνεισφέρουν στο πρότζεκτ σας είναι να μοιραστείτε και να συνεισφέρετε στα έργα τους.
 
-Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships.
+Βοηθώντας τους νεοεισερχόμενους, μοιράζοντας πόρους και κάνοντας προσεγμένες συνεισφορές στα έργα των άλλων θα σας βοηθήσουν να χτίσετε μια θετική φήμη. Το να είστε ενεργό μέλος της κοινότητας ανοικτού κώδικα θα βοηθήσει τους ανθρώπους να έχουν πλαίσιο για το πρότζεκτ σας και θα είναι πιο πιθανό να δώσουν προσοχή και να μοιραστούν το πρότζεκτ σας. Η ανάπτυξη σχέσεων με άλλα έργα ανοικτού κώδικα μπορεί να οδηγήσει ακόμη και σε επίσημες συνεργασίες.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
-  The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+  Ο μόνος λόγος για τον οποίο η urllib3 είναι η πιο δημοφιλής βιβλιοθήκη τρίτου μέρους της Python σήμερα είναι επειδή αποτελεί μέρος των requests.
   <p markdown="1" class="pquote-credit">
-— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+- @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
   </p>
 </aside>
 
-It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others.
+Ποτέ δεν είναι πολύ νωρίς ή πολύ αργά για να αρχίσετε να χτίζετε τη φήμη σας. Ακόμα και αν έχετε ήδη ξεκινήσει το δικό σας πρότζεκτ, συνεχίστε να αναζητάτε τρόπους για να βοηθήσετε τους άλλους.
 
-There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.
+Δεν υπάρχει λύση από τη μια μέρα στην άλλη για να χτίσετε ένα κοινό. Το να κερδίσετε την εμπιστοσύνη και τον σεβασμό των άλλων χρειάζεται χρόνο, και το χτίσιμο της φήμης σας δεν τελειώνει ποτέ.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it.
+  Το PhantomJS κυκλοφόρησε για πρώτη φορά στις αρχές του 2011. (...) Διέδωσα την είδηση με τους συνήθεις τρόπους: Έκανα tweet γι' αυτό, έγραψα αναρτήσεις σε blog για πράγματα που μπορούσατε να κάνετε με αυτό, το ανέφερα κατά τη διάρκεια διαφόρων συζητήσεων σε συναντήσεις. Όταν έγινε πιο γνωστό το 2014, άρχισα να κάνω παρουσιάσεις γι' αυτό.
   <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
+- @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
   </p>
 </aside>
 
-## Keep at it!
+## Συνεχίστε!
 
-It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.
+Μπορεί να χρειαστεί πολύς χρόνος μέχρι οι άνθρωποι να παρατηρήσουν το πρότζεκτ σας ανοιχτού κώδικα. Αυτό δεν πειράζει! Μερικά από τα πιο δημοφιλή έργα σήμερα χρειάστηκαν χρόνια για να φτάσουν σε υψηλά επίπεδα δραστηριότητας. Επικεντρωθείτε στην οικοδόμηση σχέσεων αντί να ελπίζετε ότι το πρότζεκτ σας θα αποκτήσει αυθόρμητα δημοτικότητα. Κάντε υπομονή και συνεχίστε να μοιράζεστε το πρότζεκτ σας με όσους το εκτιμούν.

From 126ef5df34dab245dcd828d49e6e2e3bdda5676f Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Sun, 15 May 2022 15:50:07 +0300
Subject: [PATCH 393/749] Translate getting-paid.md

---
 _articles/el/getting-paid.md | 164 +++++++++++++++++------------------
 1 file changed, 82 insertions(+), 82 deletions(-)

diff --git a/_articles/el/getting-paid.md b/_articles/el/getting-paid.md
index 728a6374c6c..39ccf014269 100644
--- a/_articles/el/getting-paid.md
+++ b/_articles/el/getting-paid.md
@@ -1,7 +1,7 @@
 ---
 lang: el
 title: Λαμβάνοντας Αμοιβή για Συνεισφορά Ανοιχτού Κώδικα
-description: Διατηρήστε το έργο σας στον ανοιχτό κώδικα λαμβάνοντας οικονομική υποστήριξη για τον χρόνο σας ή το πρότζεκτ σας.
+description: Διατηρήστε το πρότζεκτ σας στον ανοιχτό κώδικα λαμβάνοντας οικονομική υποστήριξη για τον χρόνο σας ή το πρότζεκτ σας.
 class: getting-paid
 order: 7
 image: /assets/images/cards/getting-paid.png
@@ -10,178 +10,178 @@ related:
   - leadership
 ---
 
-## Why some people seek financial support
+## Γιατί κάποιοι άνθρωποι ζητούν οικονομική στήριξη
 
-Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+Μεγάλο μέρος του πρότζεκτ του ανοικτού κώδικα είναι εθελοντικό. Για παράδειγμα, κάποιος μπορεί να συναντήσει ένα σφάλμα σε ένα πρότζεκτ που χρησιμοποιεί και να υποβάλει μια γρήγορη διόρθωση, ή μπορεί να του αρέσει να ασχολείται με ένα πρότζεκτ ανοιχτού κώδικα στον ελεύθερο χρόνο του.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
-I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+Έψαχνα για ένα "χόμπι" προγραμματισμού που θα με απασχολούσε κατά τη διάρκεια της εβδομάδας γύρω από τα Χριστούγεννα. (...) Είχα έναν υπολογιστή στο σπίτι και όχι πολλά άλλα πράγματα στα χέρια μου. Αποφάσισα να γράψω έναν διερμηνέα για τη νέα γλώσσα σεναρίων που σκεφτόμουν τελευταία. (...) Επέλεξα την Python ως τίτλο εργασίας.
   <p markdown="1" class="pquote-credit">
-— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+- @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
   </p>
 </aside>
 
-There are many reasons why a person would not want to be paid for their open source work.
+Υπάρχουν πολλοί λόγοι για τους οποίους ένα άτομο δεν θα ήθελε να πληρωθεί για την εργασία του στον ανοικτό κώδικα.
 
-* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
-* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
-* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+* **Μπορεί να έχουν ήδη μια δουλειά πλήρους απασχόλησης που αγαπούν,** η οποία τους επιτρέπει να συνεισφέρουν στον ανοιχτό κώδικα στον ελεύθερο χρόνο τους.
+* **Απολαμβάνουν να σκέφτονται τον ανοιχτό κώδικα ως χόμπι** ή ως δημιουργική απόδραση και δεν θέλουν να αισθάνονται οικονομικά υποχρεωμένοι να εργάζονται στα έργα τους.
+* **Αποκομίζουν άλλα οφέλη από τη συνεισφορά τους στον ανοικτό κώδικα,** όπως η δημιουργία της φήμης τους ή του χαρτοφυλακίου τους, η εκμάθηση μιας νέας δεξιότητας ή το αίσθημα ότι βρίσκονται πιο κοντά σε μια κοινότητα.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
-  Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+  Οι οικονομικές δωρεές προσθέτουν ένα αίσθημα ευθύνης, για κάποιους. (...) Είναι σημαντικό για εμάς, στον παγκοσμίως συνδεδεμένο, γρήγορο κόσμο που ζούμε, να μπορούμε να πούμε "όχι τώρα, έχω όρεξη να κάνω κάτι εντελώς διαφορετικό".
   <p markdown="1" class="pquote-credit">
-— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+- @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
   </p>
 </aside>
 
-For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+Για άλλους, ειδικά όταν οι συνεισφορές είναι συνεχείς ή απαιτούν σημαντικό χρόνο, το να πληρώνονται για να συνεισφέρουν στον ανοιχτό κώδικα είναι ο μόνος τρόπος που μπορούν να συμμετέχουν, είτε επειδή το απαιτεί το πρότζεκτ, είτε για προσωπικούς λόγους.
 
-Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
+Η συντήρηση δημοφιλών έργων μπορεί να αποτελεί σημαντική ευθύνη, καταλαμβάνοντας 10 ή 20 ώρες την εβδομάδα αντί για λίγες ώρες το μήνα.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
-  Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+  Ρωτήστε οποιονδήποτε συντηρητή πρότζεκτ ανοιχτού κώδικα και θα σας πει για την πραγματικότητα του όγκου εργασίας που απαιτείται για τη διαχείριση ενός πρότζεκτ. Έχετε πελάτες. Διορθώνετε προβλήματα γι' αυτούς. Δημιουργείτε νέα χαρακτηριστικά. Αυτό γίνεται μια πραγματική απαίτηση για το χρόνο σας.
   <p markdown="1" class="pquote-credit">
-— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+- @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
   </p>
 </aside>
 
-Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+Η αμειβόμενη εργασία δίνει επίσης τη δυνατότητα σε ανθρώπους από διαφορετικά κοινωνικά στρώματα να συνεισφέρουν ουσιαστικά. Ορισμένοι άνθρωποι δεν έχουν την οικονομική δυνατότητα να αφιερώσουν απλήρωτο χρόνο σε έργα ανοικτού κώδικα, με βάση την τρέχουσα οικονομική τους κατάσταση, τα χρέη τους ή τις οικογενειακές ή άλλες υποχρεώσεις φροντίδας. Αυτό σημαίνει ότι ο κόσμος δεν βλέπει ποτέ συνεισφορές από ταλαντούχους ανθρώπους που δεν έχουν την οικονομική δυνατότητα να προσφέρουν εθελοντικά τον χρόνο τους. Αυτό έχει ηθικές επιπτώσεις, όπως [έχει περιγράψει](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) ο @ashedryden, καθώς η εργασία που γίνεται μεροληπτεί υπέρ εκείνων που έχουν ήδη πλεονεκτήματα στη ζωή τους, οι οποίοι στη συνέχεια αποκτούν πρόσθετα πλεονεκτήματα με βάση τις εθελοντικές συνεισφορές τους, ενώ άλλοι που δεν είναι σε θέση να προσφέρουν εθελοντικά, τότε δεν παίρνουν αργότερα ευκαιρίες, γεγονός που ενισχύει την τρέχουσα έλλειψη ποικιλομορφίας στην κοινότητα ανοιχτού κώδικα.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
-   OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+   Ο OSS αποφέρει τεράστια οφέλη στην τεχνολογική βιομηχανία, τα οποία με τη σειρά τους σημαίνουν οφέλη για όλες τις βιομηχανίες. (...) Ωστόσο, αν οι μόνοι που μπορούν να εστιάσουν σε αυτό είναι οι τυχεροί και οι εμμονικοί, τότε υπάρχει ένα τεράστιο ανεκμετάλλευτο δυναμικό.
   <p markdown="1" class="pquote-credit">
-— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+- @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
   </p>
 </aside>
 
-If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+Εάν αναζητάτε οικονομική στήριξη, υπάρχουν δύο τρόποι που μπορείτε να εξετάσετε. Μπορείτε να χρηματοδοτήσετε το χρόνο σας ως συνεργάτης, ή μπορείτε να βρείτε οργανωτική χρηματοδότηση για το πρότζεκτ.
 
-## Funding your own time
+## Χρηματοδότηση του χρόνου σας
 
-Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+Σήμερα, πολλοί άνθρωποι αμείβονται για να εργάζονται με μερική ή πλήρη απασχόληση στον ανοικτό κώδικα. Ο πιο συνηθισμένος τρόπος για να πληρωθείτε για το χρόνο σας είναι να μιλήσετε με τον εργοδότη σας.
 
-It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+Είναι πιο εύκολο να υποστηρίξετε την εργασία σε ανοιχτό κώδικα αν ο εργοδότης σας χρησιμοποιεί πραγματικά το πρότζεκτ, αλλά γίνετε δημιουργικοί με την προσφορά σας. Ίσως ο εργοδότης σας δεν χρησιμοποιεί το πρότζεκτ, αλλά χρησιμοποιεί την Python, και η διατήρηση ενός δημοφιλούς πρότζεκτ Python συμβάλλει στην προσέλκυση νέων προγραμματιστών Python. Ίσως αυτό κάνει τον εργοδότη σας να φαίνεται γενικά πιο φιλικός προς τους προγραμματιστές.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.
+  Όπως πολλοί στον τομέα του ανοιχτού κώδικα, πάλευα με το βάρος της συντήρησης ενός πρότζεκτ. Όταν πρωτοξεκίνησα να ασχολούμαι με τον ανοιχτό κώδικα, συνήθιζα να μένω μέχρι αργά για να δουλέψω πάνω σε αυτό ή αμέσως μόλις γύριζα σπίτι. (...) Μπόρεσα να συζητήσω με το αφεντικό μου τα ζητήματα που αντιμετώπιζα και σκεφτήκαμε ιδέες για το πώς θα μπορούσαμε να ενσωματώσουμε εργασίες ανοιχτού κώδικα, δεδομένης της δικής μας χρήσης της Babel.
   <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
+- @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
   </p>
 </aside>
 
-If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+Αν δεν έχετε κάποιο υπάρχον πρότζεκτ ανοικτού κώδικα στο οποίο θα θέλατε να εργαστείτε, αλλά θα προτιμούσατε να είναι ανοικτού κώδικα το τρέχον αποτέλεσμα της δουλειάς σας, κάντε μια πρόταση στον εργοδότη σας να ανοίξει κάποιο από τα εσωτερικά του λογισμικά.
 
-Many companies are developing open source programs to build their brand and recruit quality talent.
+Πολλές εταιρείες αναπτύσσουν προγράμματα ανοικτού κώδικα για να χτίσουν το εμπορικό τους σήμα και να προσλάβουν ποιοτικά ταλέντα.
 
-@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+Η @hueniverse, για παράδειγμα, διαπίστωσε ότι υπάρχουν οικονομικοί λόγοι που δικαιολογούν [την επένδυση της Walmart στον ανοικτό κώδικα](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Και ο @jamesgpearce διαπίστωσε ότι το πρόγραμμα ανοικτού κώδικα του Facebook [έκανε τη διαφορά](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) στην πρόσληψη προσωπικού:
 
-> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+> Είναι στενά ευθυγραμμισμένο με την κουλτούρα μας ως χάκερ και με το πώς αντιλαμβανόταν ο οργανισμός μας. Ρωτήσαμε τους υπαλλήλους μας: "Γνωρίζατε το πρόγραμμα λογισμικού ανοικτού κώδικα στο Facebook;". Τα δύο τρίτα απάντησαν "Ναι". Οι μισοί δήλωσαν ότι το πρόγραμμα συνέβαλε θετικά στην απόφασή τους να εργαστούν σε εμάς. Αυτά δεν είναι οριακά νούμερα, και ελπίζω, μια τάση που συνεχίζεται.
 
-If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+Εάν η εταιρεία σας ακολουθήσει αυτόν τον δρόμο, είναι σημαντικό να διατηρήσετε σαφή τα όρια μεταξύ της κοινοτικής και της εταιρικής δραστηριότητας. Τελικά, ο ανοιχτός κώδικας συντηρείται μέσω των συνεισφορών ανθρώπων από όλο τον κόσμο, και αυτό είναι μεγαλύτερο από οποιαδήποτε εταιρεία ή τοποθεσία.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
-  Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+  Το να πληρώνεσαι για να δουλεύεις πάνω στον ανοιχτό κώδικα είναι μια σπάνια και θαυμάσια ευκαιρία, αλλά δεν θα πρέπει να εγκαταλείψεις το πάθος σου στη διαδικασία. Το πάθος σας θα πρέπει να είναι ο λόγος για τον οποίο οι εταιρείες θέλουν να σας πληρώσουν.
   <p markdown="1" class="pquote-credit">
-— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+- @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
   </p>
 </aside>
 
-If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+Αν δεν μπορείτε να πείσετε τον σημερινό σας εργοδότη να δώσει προτεραιότητα στην εργασία ανοιχτού κώδικα, σκεφτείτε να βρείτε έναν νέο εργοδότη που ενθαρρύνει τις συνεισφορές των εργαζομένων στον ανοιχτό κώδικα. Αναζητήστε εταιρείες που καθιστούν ρητή την αφοσίωσή τους στην εργασία ανοικτού κώδικα. Για παράδειγμα:
 
-* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
-* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+* Ορισμένες εταιρείες, όπως η [Netflix](https://netflix.github.io/) ή η [PayPal](https://paypal.github.io/), διαθέτουν ιστότοπους που αναδεικνύουν τη συμμετοχή τους στον ανοικτό κώδικα.
+* Η [Zalando](https://opensource.zalando.com) δημοσίευσε την [πολιτική συνεισφοράς στον ανοικτό κώδικα](https://opensource.zalando.com/docs/using/contributing/) για τους υπαλλήλους της.
 
-Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+Έργα που ξεκίνησαν από μια μεγάλη εταιρεία, όπως το [Go](https://github.com/golang) ή το [React](https://github.com/facebook/react), είναι επίσης πιθανό να απασχολούν άτομα που εργάζονται στον ανοιχτό κώδικα.
 
-Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
+Ανάλογα με τις προσωπικές σας συνθήκες, μπορείτε να προσπαθήσετε να μαζέψετε χρήματα ανεξάρτητα για να χρηματοδοτήσετε την εργασία σας στον ανοικτό κώδικα. Για παράδειγμα:
 
-* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
-* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
-* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+* Το @Homebrew (και [πολλοί άλλοι συντηρητές και οργανισμοί](https://github.com/sponsors/community)) χρηματοδοτούν το πρότζεκτ τους μέσω του [GitHub Sponsors](https://github.com/sponsors)
+* Ο @gaearon χρηματοδότησε το πρότζεκτ του στο [Redux](https://github.com/reactjs/redux) μέσω μιας [Patreon crowdfunding campaign](https://redux.js.org/)
+* Ο @andrewgodwin χρηματοδότησε το πρότζεκτ του για τις μεταναστεύσεις σχημάτων Django [μέσω μιας καμπάνιας Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
-Finally, sometimes open source projects put bounties on issues that you might consider helping with.
+Τέλος, μερικές φορές τα έργα ανοικτού κώδικα προκηρύσσουν αμοιβές για θέματα που θα μπορούσατε να σκεφτείτε να βοηθήσετε.
 
-* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
-* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+* Ο @ConnorChristie μπόρεσε να πληρωθεί για [βοήθεια](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) Η @MARKETProtocol εργάζεται στη βιβλιοθήκη JavaScript [μέσω μιας επικήρυξης στο gitcoin](https://gitcoin.co/).
+* Η @mamiM έκανε μεταφράσεις στα ιαπωνικά για την @MetaMask μετά την [χρηματοδότηση του θέματος στο Bounties Network](https://explorer.bounties.network/bounty/134).
 
-## Finding funding for your project
+## Εύρεση χρηματοδότησης για το πρότζεκτ σας
 
-Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+Πέρα από τους διακανονισμούς για μεμονωμένους συνεισφέροντες, μερικές φορές τα έργα συγκεντρώνουν χρήματα από εταιρείες, ιδιώτες ή άλλους για τη χρηματοδότηση της τρέχουσας εργασίας.
 
-Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas.
+Η οργανωτική χρηματοδότηση μπορεί να προορίζεται για την πληρωμή των σημερινών συνεισφερόντων, την κάλυψη των εξόδων λειτουργίας του πρότζεκτ (όπως τα τέλη φιλοξενίας) ή την επένδυση σε νέα χαρακτηριστικά ή ιδέες.
 
-As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+Καθώς η δημοτικότητα του ανοικτού κώδικα αυξάνεται, η εξεύρεση χρηματοδότησης για έργα είναι ακόμη πειραματική, αλλά υπάρχουν μερικές κοινές επιλογές.
 
-### Raise money for your work through crowdfunding campaigns or sponsorships
+### Συγκεντρώστε χρήματα για το πρότζεκτ σας μέσω εκστρατειών crowdfunding ή χορηγιών
 
-Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
-A few examples of sponsored projects include:
+Η εξεύρεση χορηγιών λειτουργεί καλά αν έχετε ήδη ένα ισχυρό κοινό ή φήμη ή αν το πρότζεκτ σας είναι πολύ δημοφιλές.
+Μερικά παραδείγματα έργων με χορηγίες περιλαμβάνουν:
 
-* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803)
-* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+* **[webpack](https://github.com/webpack)** συγκεντρώνει χρήματα από εταιρείες και ιδιώτες [μέσω του OpenCollective](https://opencollective.com/webpack)
+* **[Vue](https://github.com/vuejs/vue)** χρηματοδοτείται [μέσω του Patreon](https://github.com/open-source/stories/yyx990803)
+* **[Ruby Together](https://rubytogether.org/),** ένας μη κερδοσκοπικός οργανισμός που πληρώνει για εργασίες στα [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), και άλλα έργα υποδομής Ruby
 
-### Create a revenue stream
+### Δημιουργία μιας ροής εσόδων
 
-Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+Ανάλογα με το πρότζεκτ σας, μπορεί να είστε σε θέση να χρεώνετε για εμπορική υποστήριξη, επιλογές φιλοξενίας ή πρόσθετα χαρακτηριστικά. Μερικά παραδείγματα περιλαμβάνουν:
 
-* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
-* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
-* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+* **[Sidekiq](https://github.com/mperham/sidekiq)** προσφέρει εκδόσεις επί πληρωμή για πρόσθετη υποστήριξη
+* **[Travis CI](https://github.com/travis-ci)** προσφέρει εκδόσεις επί πληρωμή του προϊόντος του
+* **[Ghost](https://github.com/TryGhost/Ghost)** είναι ένα μη κερδοσκοπικό ίδρυμα με επί πληρωμή υπηρεσία διαχείρισης
 
-Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+Ορισμένα δημοφιλή έργα, όπως το [npm](https://github.com/npm/cli) και το [Docker](https://github.com/docker/docker), συγκεντρώνουν ακόμη και επιχειρηματικά κεφάλαια για να υποστηρίξουν την επιχειρηματική τους ανάπτυξη.
 
-### Apply for grant funding
+### Υποβολή αίτησης για επιχορήγηση
 
-Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+Ορισμένα ιδρύματα λογισμικού και εταιρείες προσφέρουν επιχορηγήσεις για εργασίες ανοικτού κώδικα. Ορισμένες φορές, οι επιχορηγήσεις μπορούν να καταβληθούν σε ιδιώτες χωρίς τη δημιουργία νομικής οντότητας για το πρότζεκτ.
 
-* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
-* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
-* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
-* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+* **[Διαβάστε τα έγγραφα](https://github.com/rtfd/readthedocs.org)** έλαβε επιχορήγηση από την [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)** το πρότζεκτ χρηματοδοτήθηκε από το [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** έλαβε επιχορήγηση από το [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* Το **[Python Software Foundation](https://www.python.org/psf/grants/)** προσφέρει επιχορηγήσεις για εργασίες που σχετίζονται με την Python.
 
-For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+Για πιο λεπτομερείς επιλογές και μελέτες περιπτώσεων, ο @nayafia [έγραψε έναν οδηγό](https://github.com/nayafia/lemonade-stand) για να πληρωθείτε για εργασία ανοιχτού κώδικα. Διαφορετικοί τύποι χρηματοδότησης απαιτούν διαφορετικές δεξιότητες, οπότε λάβετε υπόψη τα δυνατά σας σημεία για να βρείτε ποια επιλογή σας ταιριάζει καλύτερα.
 
-## Building a case for financial support
+## Χτίζοντας μια υπόθεση για οικονομική υποστήριξη
 
-Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+Είτε το πρότζεκτ σας είναι μια νέα ιδέα, είτε υπάρχει εδώ και χρόνια, θα πρέπει να περιμένετε να βάλετε σημαντική σκέψη για να εντοπίσετε τον χρηματοδότη-στόχο σας και να παρουσιάσετε μια πειστική υπόθεση.
 
-Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+Είτε επιθυμείτε να πληρώσετε για τον δικό σας χρόνο, είτε να συγκεντρώσετε χρήματα για ένα πρότζεκτ, θα πρέπει να είστε σε θέση να απαντήσετε στις ακόλουθες ερωτήσεις.
 
-### Impact
+### Αντίκτυπος
 
-Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+Γιατί είναι χρήσιμο αυτό το πρότζεκτ; Γιατί αρέσει τόσο πολύ στους χρήστες σας ή στους δυνητικούς χρήστες; Πού θα βρίσκεται σε πέντε χρόνια;
 
-### Traction
+### Έλξη
 
-Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+Προσπαθήστε να συγκεντρώσετε αποδείξεις ότι το πρότζεκτ σας έχει σημασία, είτε πρόκειται για μετρήσεις, είτε για ανέκδοτα, είτε για μαρτυρίες. Υπάρχουν εταιρείες ή αξιόλογοι άνθρωποι που χρησιμοποιούν το πρότζεκτ σας αυτή τη στιγμή; Αν όχι, το έχει υποστηρίξει κάποιο εξέχον πρόσωπο;
 
-### Value to funder
+### Αξία για τον χρηματοδότη
 
-Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+Οι χρηματοδότες, είτε πρόκειται για τον εργοδότη σας είτε για ένα ίδρυμα που χορηγεί επιχορηγήσεις, προσεγγίζονται συχνά με ευκαιρίες. Γιατί θα πρέπει να υποστηρίξουν το πρότζεκτ σας έναντι οποιασδήποτε άλλης ευκαιρίας; Πώς ωφελούνται προσωπικά;
 
-### Use of funds
+### Χρήση των κονδυλίων
 
-What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+Τι ακριβώς θα επιτύχετε με την προτεινόμενη χρηματοδότηση; Επικεντρωθείτε σε ορόσημα ή αποτελέσματα του πρότζεκτ και όχι στην καταβολή μισθού.
 
-### How you'll receive the funds
+### Πώς θα λάβετε τα κεφάλαια
 
-Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+Έχει ο χρηματοδότης οποιεσδήποτε απαιτήσεις σχετικά με την εκταμίευση; Για παράδειγμα, μπορεί να χρειαστεί να είστε μη κερδοσκοπικός οργανισμός ή να έχετε μη κερδοσκοπικό φορολογικό χορηγό. Ή ίσως τα κονδύλια πρέπει να δοθούν σε μεμονωμένο ανάδοχο και όχι σε οργανισμό. Οι απαιτήσεις αυτές διαφέρουν από χρηματοδότη σε χρηματοδότη, οπότε φροντίστε να κάνετε την έρευνά σας εκ των προτέρων.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
-  For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+  Εδώ και χρόνια, είμαστε η κορυφαία πηγή εικονιδίων φιλικών προς τον ιστότοπο, με μια κοινότητα άνω των 20 εκατομμυρίων ανθρώπων και έχουμε εμφανιστεί σε περισσότερους από 70 εκατομμύρια ιστότοπους, συμπεριλαμβανομένου του Whitehouse.gov. (...) Η έκδοση 4 ήταν πριν από τρία χρόνια. Η τεχνολογία του Web έχει αλλάξει πολύ από τότε και ειλικρινά, το Font Awesome έχει γίνει λίγο μπαγιάτικο. (...) Γι' αυτό παρουσιάζουμε τη Font Awesome 5. Εκσυγχρονίζουμε και ξαναγράφουμε το CSS και επανασχεδιάζουμε κάθε εικονίδιο από πάνω μέχρι κάτω. Μιλάμε για καλύτερο σχεδιασμό, καλύτερη συνοχή και καλύτερη αναγνωσιμότητα.
   <p markdown="1" class="pquote-credit">
-— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+- @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
   </p>
 </aside>
 
-## Experiment and don't give up
+## Πειραματιστείτε και μην τα παρατάτε
 
-Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
+Η συγκέντρωση χρημάτων δεν είναι εύκολη υπόθεση, είτε πρόκειται για πρότζεκτ ανοιχτού κώδικα, είτε για μη κερδοσκοπικό οργανισμό, είτε για νεοσύστατη επιχείρηση λογισμικού, και στις περισσότερες περιπτώσεις απαιτεί να γίνετε δημιουργικοί. Το να προσδιορίσετε πώς θέλετε να πληρωθείτε, να κάνετε την έρευνά σας και να μπείτε στη θέση του χρηματοδότη σας θα σας βοηθήσει να δημιουργήσετε μια πειστική υπόθεση για χρηματοδότηση.

From 6edf71b04fd14da88ff384a58a5b56ad898568b1 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 20 Sep 2022 10:24:44 +0300
Subject: [PATCH 394/749] translate how-to-contribute.md

---
 _articles/el/how-to-contribute.md | 424 +++++++++++++++---------------
 1 file changed, 212 insertions(+), 212 deletions(-)

diff --git a/_articles/el/how-to-contribute.md b/_articles/el/how-to-contribute.md
index 0c205111896..b9362f910ac 100644
--- a/_articles/el/how-to-contribute.md
+++ b/_articles/el/how-to-contribute.md
@@ -10,210 +10,210 @@ related:
   - building
 ---
 
-## Why contribute to open source?
+## Γιατί να συνεισφέρετε στον ανοιχτό κώδικα;
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
-  Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+  Η εργασία στο \[freenode\] με βοήθησε να αποκτήσω πολλές από τις δεξιότητες που χρησιμοποίησα αργότερα για τις σπουδές μου στο πανεπιστήμιο και την πραγματική μου δουλειά. Νομίζω ότι η εργασία σε έργα ανοιχτού κώδικα βοηθάει εμένα όσο βοηθάει και το έργο!
   <p markdown="1" class="pquote-credit">
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+- @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
   </p>
 </aside>
 
-Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+Η συνεισφορά σε λογισμικό ανοικτού κώδικα μπορεί να είναι ένας ικανοποιητικός τρόπος για να μάθετε, να διδάξετε και να αποκτήσετε εμπειρία σε σχεδόν οποιαδήποτε δεξιότητα μπορείτε να φανταστείτε.
 
-Why do people contribute to open source? Plenty of reasons!
+Γιατί οι άνθρωποι συνεισφέρουν στον ανοικτό κώδικα; Πολλοί λόγοι!
 
-### Improve software you rely on
+### Βελτιώνουν το λογισμικό στο οποίο βασίζονται
 
-Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+Πολλοί συνεισφέροντες σε λογισμικό ανοικτού κώδικα ξεκινούν ως χρήστες του λογισμικού στο οποίο συνεισφέρουν. Όταν βρίσκετε ένα σφάλμα σε ένα λογισμικό ανοικτού κώδικα που χρησιμοποιείτε, ίσως θελήσετε να κοιτάξετε τον πηγαίο κώδικα για να δείτε αν μπορείτε να το διορθώσετε μόνοι σας. Αν είναι έτσι, τότε η συνεισφορά του διορθωτικού είναι ο καλύτερος τρόπος για να διασφαλίσετε ότι οι φίλοι σας (και εσείς οι ίδιοι όταν κάνετε ενημέρωση στην επόμενη έκδοση) θα μπορέσουν να επωφεληθούν από αυτό.
 
-### Improve existing skills
+### Βελτιώστε τις υπάρχουσες δεξιότητες
 
-Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+Είτε πρόκειται για προγραμματισμό, είτε για σχεδιασμό διεπαφής χρήστη, είτε για γραφιστική, είτε για συγγραφή, είτε για οργάνωση, αν ψάχνετε για εξάσκηση, υπάρχει μια εργασία για εσάς σε ένα έργο ανοιχτού κώδικα.
 
-### Meet people who are interested in similar things
+### Γνωρίστε ανθρώπους που ενδιαφέρονται για παρόμοια πράγματα
 
-Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+Τα έργα ανοιχτού κώδικα με θερμές, φιλόξενες κοινότητες κρατούν τους ανθρώπους να επιστρέφουν για χρόνια. Πολλοί άνθρωποι δημιουργούν φιλίες ζωής μέσα από τη συμμετοχή τους στον ανοιχτό κώδικα, είτε πρόκειται για συναντήσεις σε συνέδρια είτε για διαδικτυακές συζητήσεις αργά το βράδυ για μπουρίτος.
 
-### Find mentors and teach others
+### Βρείτε μέντορες και διδάξτε άλλους
 
-Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+Η συνεργασία με άλλους σε ένα κοινό έργο σημαίνει ότι θα πρέπει να εξηγείτε πώς κάνετε τα πράγματα, καθώς και να ζητάτε βοήθεια από άλλους ανθρώπους. Οι πράξεις μάθησης και διδασκαλίας μπορεί να είναι μια ικανοποιητική δραστηριότητα για όλους τους εμπλεκόμενους.
 
-### Build public artifacts that help you grow a reputation (and a career)
+### Δημιουργήστε δημόσια αντικείμενα που σας βοηθούν να αναπτύξετε τη φήμη σας (και την καριέρα σας)
 
-By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+Εξ ορισμού, όλη η εργασία σας με ανοιχτό κώδικα είναι δημόσια, πράγμα που σημαίνει ότι έχετε δωρεάν παραδείγματα για να τα πάρετε οπουδήποτε ως επίδειξη του τι μπορείτε να κάνετε.
 
-### Learn people skills
+### Μάθετε δεξιότητες ανθρώπινου δυναμικού
 
-Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+Ο ανοικτός κώδικας προσφέρει ευκαιρίες για να εξασκήσετε ηγετικές και διοικητικές δεξιότητες, όπως η επίλυση συγκρούσεων, η οργάνωση ομάδων ανθρώπων και η ιεράρχηση προτεραιοτήτων εργασίας.
 
-### It's empowering to be able to make changes, even small ones
+### Είναι ενδυναμωτικό να μπορείς να κάνεις αλλαγές, ακόμη και μικρές
 
-You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+Δεν χρειάζεται να γίνετε ισόβιος συνεργάτης για να απολαύσετε τη συμμετοχή σας στον ανοικτό κώδικα. Έχετε δει ποτέ ένα τυπογραφικό λάθος σε έναν ιστότοπο και ευχηθήκατε κάποιος να το διορθώσει; Σε ένα έργο ανοιχτού κώδικα, μπορείτε να κάνετε ακριβώς αυτό. Ο ανοικτός κώδικας βοηθά τους ανθρώπους να αισθάνονται ότι έχουν εξουσία στη ζωή τους και στο πώς βιώνουν τον κόσμο, και αυτό από μόνο του είναι ευχάριστο.
 
-## What it means to contribute
+## Τι σημαίνει να συνεισφέρεις
 
-If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+Αν είστε νέος συνεισφέρων σε έργα ανοικτού κώδικα, η διαδικασία μπορεί να είναι εκφοβιστική. Πώς μπορείτε να βρείτε το κατάλληλο έργο; Τι γίνεται αν δεν ξέρετε να προγραμματίζετε; Τι γίνεται αν κάτι πάει στραβά;
 
-Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+Μην ανησυχείτε! Υπάρχουν διάφοροι τρόποι για να συμμετάσχετε σε ένα έργο ανοικτού κώδικα και μερικές συμβουλές θα σας βοηθήσουν να αξιοποιήσετε στο έπακρο την εμπειρία σας.
 
-### You don't have to contribute code
+### Δεν χρειάζεται να συνεισφέρετε κώδικα
 
-A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+Μια κοινή παρανόηση σχετικά με τη συνεισφορά σε έργα ανοικτού κώδικα είναι ότι πρέπει να συνεισφέρετε κώδικα. Στην πραγματικότητα, είναι συχνά τα άλλα μέρη ενός έργου που [παραμελούνται ή παραβλέπονται περισσότερο](https://github.com/blog/2195-the-shape-of-open-source). Θα κάνετε στο έργο μια _τεράστια_ χάρη προσφέροντας να συνεισφέρετε με τέτοιου είδους συνεισφορές!
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
-  I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+  Έχω γίνει γνωστός για τη δουλειά μου στο CocoaPods, αλλά οι περισσότεροι άνθρωποι δεν γνωρίζουν ότι στην πραγματικότητα δεν κάνω καμία πραγματική δουλειά στο ίδιο το εργαλείο CocoaPods. Ο χρόνος μου για το έργο αναλώνεται κυρίως σε πράγματα όπως η τεκμηρίωση και η εργασία πάνω στο branding.
   <p markdown="1" class="pquote-credit">
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+- @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
   </p>
 </aside>
 
-Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+## Γιατί να συνεισφέρετε στον ανοιχτό κώδικα; <aside markdown="1" class="pquote">
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing.
+<img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
+  Η εργασία στο \[freenode\] με βοήθησε να αποκτήσω πολλές από τις δεξιότητες που χρησιμοποίησα αργότερα για τις σπουδές μου στο πανεπιστήμιο και την πραγματική μου δουλειά.
+  Νομίζω ότι η εργασία σε έργα ανοιχτού κώδικα βοηθάει εμένα όσο βοηθάει και το έργο! <p markdown="1" class="pquote-credit"> Μου έδιναν μια πολύ καλή αφορμή για να ζητήσω διευκρινίσεις σχετικά με ένα θέμα, αλλά το πιο κρίσιμο ήταν ότι μπορούσα να παρατηρήσω πότε κάποιος επισήμανε κάτι που έπρεπε να διορθωθεί.
   <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
+- @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
   </p>
 </aside>
 
-### Do you like planning events?
+### Σας αρέσει να προγραμματίζετε εκδηλώσεις;
 
-* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
-* Organize the project's conference (if they have one)
-* Help community members find the right conferences and submit proposals for speaking
+* Οργανώστε εργαστήρια ή συναντήσεις για το έργο, [όπως έκανε ο @fzamperin για το NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Διοργανώνετε το συνέδριο του έργου (αν έχουν)
+* Βοηθήστε τα μέλη της κοινότητας να βρουν τα κατάλληλα συνέδρια και να υποβάλουν προτάσεις για ομιλία
 
-### Do you like to design?
+### Σας αρέσει να σχεδιάζετε;
 
-* Restructure layouts to improve the project's usability
-* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
-* Put together a style guide to help the project have a consistent visual design
-* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+* Να αναδιαρθρώνετε τις διατάξεις για να βελτιώσετε τη χρηστικότητα του έργου
+* Διεξαγωγή έρευνας χρηστών για την αναδιοργάνωση και βελτίωση της πλοήγησης ή των μενού του έργου, [όπως προτείνει το Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Να συντάσσετε έναν οδηγό στυλ για να βοηθήσετε το έργο να έχει έναν συνεπή οπτικό σχεδιασμό
+* Δημιουργήστε τέχνη για μπλουζάκια ή ένα νέο λογότυπο, [όπως έκαναν οι συντελεστές του hapi.js](https://github.com/hapijs/contrib/issues/68)
 
-### Do you like to write?
+### Σας αρέσει να γράφετε;
 
-* Write and improve the project's documentation
-* Curate a folder of examples showing how the project is used
-* Start a newsletter for the project, or curate highlights from the mailing list
-* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
-* Write a translation for the project's documentation
+* Γράφετε και βελτιώνετε την τεκμηρίωση του έργου
+* Επιμεληθείτε έναν φάκελο με παραδείγματα που δείχνουν πώς χρησιμοποιείται το έργο
+* Ξεκινήστε ένα ενημερωτικό δελτίο για το έργο, ή επιμεληθείτε τα σημαντικότερα σημεία από τη λίστα αλληλογραφίας
+* Γράφετε εκπαιδευτικά προγράμματα για το έργο, [όπως έκαναν οι συντελεστές του PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Γράψτε μια μετάφραση για την τεκμηρίωση του έργου
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
-  Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+  Σοβαρά, το \[documentation\] είναι μέγα-σημαντικό. Η τεκμηρίωση μέχρι στιγμής είναι εξαιρετική και είναι ένα φονικό χαρακτηριστικό της Babel. Υπάρχουν τμήματα που σίγουρα χρειάζονται λίγη δουλειά και ακόμα και η προσθήκη μιας παραγράφου εδώ ή εκεί είναι εξαιρετικά ευπρόσδεκτη.
   <p markdown="1" class="pquote-credit">
-— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+- @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
   </p>
 </aside>
 
-### Do you like organizing?
+### Σας αρέσει η οργάνωση;
 
-* Link to duplicate issues, and suggest new issue labels, to keep things organized
-* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
-* Ask clarifying questions on recently opened issues to move the discussion forward
+* Συνδέστε τα διπλά θέματα και προτείνετε νέες ετικέτες θεμάτων, για να διατηρήσετε τα πράγματα οργανωμένα
+* Ψάξτε τα ανοιχτά θέματα και προτείνετε το κλείσιμο των παλιών, [όπως έκανε ο @nzakas για το ESLint](https://github.com/eslint/eslint/issues/6765)
+* Να κάνετε διευκρινιστικές ερωτήσεις σε πρόσφατα ανοιχτά θέματα για να προχωρήσει η συζήτηση.
 
-### Do you like to code?
+### Σας αρέσει να γράφετε κώδικα;
 
-* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
-* Ask if you can help write a new feature
-* Automate project setup
-* Improve tooling and testing
+* Βρείτε ένα ανοιχτό θέμα για να ασχοληθείτε, [όπως έκανε ο @dianjin για το Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Ρωτήστε αν μπορείτε να βοηθήσετε στη συγγραφή ενός νέου χαρακτηριστικού.
+* Αυτοματοποιήστε την εγκατάσταση του έργου
+* Βελτιώστε τα εργαλεία και τις δοκιμές
 
-### Do you like helping people?
+### Σας αρέσει να βοηθάτε τους ανθρώπους;
 
-* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
-* Answer questions for people on open issues
-* Help moderate the discussion boards or conversation channels
+* Απαντήστε σε ερωτήσεις σχετικά με το έργο π.χ. στο Stack Overflow ([όπως αυτό το παράδειγμα Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) ή στο Reddit.
+* Απαντάτε σε ερωτήσεις για ανθρώπους σε ανοιχτά θέματα
+* Βοηθήστε να συντονίσετε τους πίνακες συζητήσεων ή τα κανάλια συζήτησης
 
-### Do you like helping others code?
+### Σας αρέσει να βοηθάτε άλλους να προγραμματίζουν;
 
-* Review code on other people's submissions
-* Write tutorials for how a project can be used
-* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+* Αναθεωρείτε τον κώδικα σε υποβολές άλλων ανθρώπων
+* Γράφετε σεμινάρια για το πώς μπορεί να χρησιμοποιηθεί ένα έργο
+* Προσφερθείτε να γίνετε μέντορας ενός άλλου συνεισφέροντα, [όπως έκανε ο @ereichert για τον @bronzdoc στο Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
 
-### You don't just have to work on software projects!
+### Δεν χρειάζεται να εργάζεστε μόνο σε έργα λογισμικού!
 
-While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+Αν και ο όρος "ανοικτός κώδικας" αναφέρεται συχνά στο λογισμικό, μπορείτε να συνεργαστείτε σχεδόν σε οτιδήποτε. * Απαντήστε σε ερωτήσεις σχετικά με το έργο π.χ. στο Stack Overflow ([όπως αυτό το παράδειγμα Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) ή στο Reddit.
 
-For example:
+Για παράδειγμα:
 
-* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
-* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
-* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+* @sindresorhus επιμελείται μια [λίστα με "φοβερές" λίστες](https://github.com/sindresorhus/awesome)
+* Ο @h5bp διατηρεί μια [λίστα με πιθανές ερωτήσεις συνέντευξης](https://github.com/h5bp/Front-end-Developer-Interview-Questions) για υποψήφιους front-end προγραμματιστές
+* Ο @stuartlynn και η @nicole-a-tesla δημιούργησαν μια [συλλογή με διασκεδαστικά στοιχεία για τους πιθήκους](https://github.com/stuartlynn/puffin_facts)
 
-Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
+Ακόμα και αν είστε προγραμματιστής λογισμικού, η εργασία σε ένα έργο τεκμηρίωσης μπορεί να σας βοηθήσει να ξεκινήσετε στον ανοιχτό κώδικα. Είναι συχνά λιγότερο τρομακτικό να εργάζεστε σε έργα που δεν περιλαμβάνουν κώδικα, και η διαδικασία της συνεργασίας θα ενισχύσει την αυτοπεποίθηση και την εμπειρία σας.
 
-## Orienting yourself to a new project
+## Προσανατολισμός σε ένα νέο έργο
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
-  If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+  Αν πηγαίνετε σε έναν ανιχνευτή ζητημάτων και τα πράγματα φαίνονται συγκεχυμένα, δεν φταίτε μόνο εσείς. Αυτά τα εργαλεία απαιτούν πολλές σιωπηρές γνώσεις, αλλά οι άνθρωποι μπορούν να σας βοηθήσουν να περιηγηθείτε σε αυτά και μπορείτε να τους κάνετε ερωτήσεις.
   <p markdown="1" class="pquote-credit">
-— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+- @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
   </p>
 </aside>
 
-For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+Για οτιδήποτε περισσότερο από μια διόρθωση τυπογραφικού λάθους, η συνεισφορά στον ανοιχτό κώδικα είναι σαν να πηγαίνεις σε μια ομάδα αγνώστων σε ένα πάρτι. Αν αρχίσετε να μιλάτε για λάμα, ενώ αυτοί ήταν βαθιά χωμένοι σε μια συζήτηση για χρυσόψαρα, μάλλον θα σας κοιτάξουν λίγο περίεργα.
 
-Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
+Πριν πέσετε στα τυφλά με τις δικές σας προτάσεις, ξεκινήστε μαθαίνοντας πώς να διαβάζετε το δωμάτιο. Με αυτόν τον τρόπο αυξάνονται οι πιθανότητες να προσέξουν και να ακούσουν τις ιδέες σας.
 
-### Anatomy of an open source project
+### Ανατομία ενός έργου ανοικτού κώδικα
 
-Every open source community is different.
+Κάθε κοινότητα ανοικτού κώδικα είναι διαφορετική.
 
-Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+Το να περάσετε χρόνια σε ένα έργο ανοιχτού κώδικα σημαίνει ότι έχετε γνωρίσει ένα έργο ανοιχτού κώδικα. Αν μετακινηθείτε σε ένα άλλο έργο, μπορεί να διαπιστώσετε ότι το λεξιλόγιο, οι κανόνες και οι τρόποι επικοινωνίας είναι εντελώς διαφορετικοί.
 
-That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+Τούτου λεχθέντος, πολλά έργα ανοικτού κώδικα ακολουθούν μια παρόμοια οργανωτική δομή. Η κατανόηση των διαφορετικών ρόλων της κοινότητας και της συνολικής διαδικασίας θα σας βοηθήσει να προσανατολιστείτε γρήγορα σε οποιοδήποτε νέο έργο.
 
-A typical open source project has the following types of people:
+Ένα τυπικό έργο ανοικτού κώδικα έχει τους ακόλουθους τύπους ανθρώπων:
 
-* **Author:** The person/s or organization that created the project
-* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
-* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
-* **Contributors:** Everyone who has contributed something back to the project
-* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+* **Συγγραφέας:** Το άτομο/τα άτομα ή ο οργανισμός που δημιούργησε το έργο
+* **Δικαιούχος:** Το άτομο/α που έχει/ουν τη διοικητική κυριότητα του οργανισμού ή του αποθετηρίου (δεν είναι πάντα το ίδιο με τον αρχικό συγγραφέα)
+* **Διαχειριστές:** Συντελεστές που είναι υπεύθυνοι για την προώθηση του οράματος και τη διαχείριση των οργανωτικών πτυχών του έργου (μπορεί επίσης να είναι συγγραφείς ή ιδιοκτήτες του έργου).
+* **Συντελεστές:** Όλοι όσοι έχουν συνεισφέρει κάτι στο έργο
+* **Μέλη της κοινότητας:** Άνθρωποι που χρησιμοποιούν το έργο. Μπορεί να συμμετέχουν ενεργά σε συζητήσεις ή να εκφράζουν τη γνώμη τους για την κατεύθυνση του έργου
 
-Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+Τα μεγαλύτερα έργα μπορεί επίσης να έχουν υποεπιτροπές ή ομάδες εργασίας που επικεντρώνονται σε διαφορετικά καθήκοντα, όπως η δημιουργία εργαλείων, η ταξινόμηση, ο συντονισμός της κοινότητας και η διοργάνωση εκδηλώσεων. Αναζητήστε στον ιστότοπο ενός έργου μια σελίδα "ομάδας" ή στο αποθετήριο για την τεκμηρίωση διακυβέρνησης, για να βρείτε αυτές τις πληροφορίες.
 
-A project also has documentation. These files are usually listed in the top level of a repository.
+Ένα έργο διαθέτει επίσης τεκμηρίωση. Αυτά τα αρχεία συνήθως παρατίθενται στο κορυφαίο επίπεδο ενός αποθετηρίου.
 
-* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
-* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
-* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
-* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
-* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.
+* **ΑΔΕΙΑ ΑΝΟΙΚΤΟΥ ΚΩΔΙΚΟΥ:** Εξ ορισμού, κάθε έργο ανοικτού κώδικα πρέπει να έχει μια [άδεια ανοικτού κώδικα](https://choosealicense.com). Εάν το έργο δεν έχει άδεια χρήσης, δεν είναι ανοικτού κώδικα.
+* **README:** Το README είναι το εγχειρίδιο οδηγιών που καλωσορίζει τα νέα μέλη της κοινότητας στο έργο. Εξηγεί γιατί το έργο είναι χρήσιμο και πώς να ξεκινήσετε.
+* **ΣΥΜΒΟΛΗ:** Ενώ τα README βοηθούν τους ανθρώπους να _χρησιμοποιήσουν_ το έργο, τα έγγραφα συνεισφοράς βοηθούν τους ανθρώπους να _εισφέρουν_ στο έργο. Εξηγεί τι είδους συνεισφορές χρειάζονται και πώς λειτουργεί η διαδικασία. Αν και δεν έχει κάθε έργο ένα αρχείο CONTRIBUTING, η παρουσία του σηματοδοτεί ότι το έργο είναι φιλόξενο για συνεισφορά.
+* **ΚΩΔΙΚΑΣ_ΔΕΟΝΤΟΛΟΓΙΑΣ:** Ο κώδικας δεοντολογίας θέτει βασικούς κανόνες για τη συμπεριφορά των συμμετεχόντων που σχετίζονται και βοηθά στη διευκόλυνση ενός φιλικού, φιλόξενου περιβάλλοντος. Αν και δεν έχει κάθε έργο ένα αρχείο CODE_OF_CONDUCT, η παρουσία του σηματοδοτεί ότι πρόκειται για ένα φιλόξενο έργο στο οποίο μπορείτε να συνεισφέρετε.
+* **Άλλη τεκμηρίωση:** Ενδέχεται να υπάρχει πρόσθετη τεκμηρίωση, όπως σεμινάρια, οδηγίες χρήσης ή πολιτικές διακυβέρνησης, ειδικά σε μεγαλύτερα έργα.
 
-Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+Τέλος, τα έργα ανοικτού κώδικα χρησιμοποιούν τα ακόλουθα εργαλεία για την οργάνωση της συζήτησης. Η ανάγνωση των αρχείων θα σας δώσει μια καλή εικόνα για το πώς σκέφτεται και λειτουργεί η κοινότητα.
 
-* **Issue tracker:** Where people discuss issues related to the project.
-* **Pull requests:** Where people discuss and review changes that are in progress.
-* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
-* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
+* **Issue tracker:** Όπου οι άνθρωποι συζητούν θέματα που σχετίζονται με το έργο.
+* **Pull requests:** Όπου οι άνθρωποι συζητούν και αναθεωρούν τις αλλαγές που βρίσκονται σε εξέλιξη.
+* **Φόρουμ συζητήσεων ή λίστες αλληλογραφίας:** Ορισμένα έργα μπορεί να χρησιμοποιούν αυτά τα κανάλια για θέματα συζήτησης (για παράδειγμα, _"Πώς μπορώ να..."_ ή _"Τι πιστεύετε για..."_ αντί για αναφορές σφαλμάτων ή αιτήσεις για χαρακτηριστικά). Άλλα χρησιμοποιούν τον ανιχνευτή ζητημάτων για όλες τις συζητήσεις.
+* **Σύγχρονο κανάλι συνομιλίας:** Ορισμένα έργα χρησιμοποιούν κανάλια συνομιλίας (όπως το Slack ή το IRC) για περιστασιακή συζήτηση, συνεργασία και γρήγορες ανταλλαγές.
 
-## Finding a project to contribute to
+## Βρίσκοντας ένα έργο για να συνεισφέρετε
 
-Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+Τώρα που έχετε καταλάβει πώς λειτουργούν τα έργα ανοικτού κώδικα, ήρθε η ώρα να βρείτε ένα έργο για να συνεισφέρετε!
 
-If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_
+Αν δεν έχετε συνεισφέρει ποτέ στο παρελθόν σε έργα ανοικτού κώδικα, ακολουθήστε τη συμβουλή του προέδρου των ΗΠΑ Τζον Φ. Κένεντι, ο οποίος είπε κάποτε: _"Μη ρωτάτε τι μπορεί να κάνει η χώρα σας για εσάς - ρωτήστε τι μπορείτε να κάνετε εσείς για τη χώρα σας".
 
-Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+Η συνεισφορά στον ανοικτό κώδικα γίνεται σε όλα τα επίπεδα, σε όλα τα έργα. Δεν χρειάζεται να σκεφτείτε υπερβολικά ποια ακριβώς θα είναι η πρώτη σας συνεισφορά ή πώς θα φαίνεται.
 
-Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+Αντ' αυτού, ξεκινήστε σκεπτόμενοι τα έργα που ήδη χρησιμοποιείτε ή θέλετε να χρησιμοποιήσετε. Τα έργα στα οποία θα συνεισφέρετε ενεργά είναι αυτά στα οποία θα βρίσκεστε να επιστρέφετε.
 
-Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+Μέσα σε αυτά τα έργα, όποτε πιάνετε τον εαυτό σας να σκέφτεται ότι κάτι θα μπορούσε να είναι καλύτερο ή διαφορετικό, ακολουθήστε το ένστικτό σας.
 
-Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+Ο ανοιχτός κώδικας δεν είναι μια αποκλειστική λέσχη- φτιάχνεται από ανθρώπους σαν εσάς. Ο "ανοικτός κώδικας" είναι απλώς ένας φανταχτερός όρος για να αντιμετωπίζεις τα προβλήματα του κόσμου ως επιλύσιμα.
 
-You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
+Μπορεί να σκανάρετε ένα README και να βρείτε έναν σπασμένο σύνδεσμο ή ένα τυπογραφικό λάθος. Ή είστε νέος χρήστης και παρατηρήσατε ότι κάτι είναι σπασμένο ή ένα θέμα που πιστεύετε ότι θα έπρεπε πραγματικά να υπάρχει στην τεκμηρίωση. Αντί να το αγνοήσετε και να προχωρήσετε ή να ζητήσετε από κάποιον άλλο να το διορθώσει, δείτε αν μπορείτε να βοηθήσετε με τη συμμετοχή σας. Αυτό είναι το νόημα του ανοιχτού κώδικα!
 
-> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+> Το [28% των περιστασιακών συνεισφορών](https://www.igor.pro.br/publica/papers/saner2016.pdf) στον ανοικτό κώδικα είναι τεκμηρίωση, όπως διόρθωση τυπογραφικών λαθών, αναδιαμόρφωση ή συγγραφή μετάφρασης.
 
-If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+Αν ψάχνετε για υπάρχοντα θέματα που μπορείτε να διορθώσετε, κάθε έργο ανοιχτού κώδικα έχει μια σελίδα `/contribute` που επισημαίνει θέματα φιλικά προς τους αρχάριους με τα οποία μπορείτε να ξεκινήσετε. Πλοηγηθείτε στην κεντρική σελίδα του αποθετηρίου στο GitHub και προσθέστε `/contribute` στο τέλος της διεύθυνσης URL (για παράδειγμα [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
 
-You can also use one of the following resources to help you discover and contribute to new projects:
+Μπορείτε επίσης να χρησιμοποιήσετε έναν από τους παρακάτω πόρους για να σας βοηθήσει να ανακαλύψετε και να συνεισφέρετε σε νέα έργα:
 
 * [GitHub Explore](https://github.com/explore/)
 * [Open Source Friday](https://opensourcefriday.com)
@@ -225,229 +225,229 @@ You can also use one of the following resources to help you discover and contrib
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
-### A checklist before you contribute
+### Μια λίστα ελέγχου πριν συνεισφέρετε
 
-When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+Όταν έχετε βρει ένα έργο στο οποίο θα θέλατε να συνεισφέρετε, κάντε ένα γρήγορο έλεγχο για να βεβαιωθείτε ότι το έργο είναι κατάλληλο για να δέχεται συνεισφορές. Διαφορετικά, η σκληρή δουλειά σας μπορεί να μην βρει ποτέ ανταπόκριση.
 
-Here's a handy checklist to evaluate whether a project is good for new contributors.
+Ακολουθεί ένας εύχρηστος κατάλογος ελέγχου για να αξιολογήσετε αν ένα έργο είναι κατάλληλο για νέους συνεισφέροντες.
 
 **Meets the definition of open source**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+    Έχει άδεια; Συνήθως, υπάρχει ένα αρχείο που ονομάζεται LICENSE στη ρίζα του αποθετηρίου.
   </label>
 </div>
 
-**Project actively accepts contributions**
+**Το έργο δέχεται ενεργά συνεισφορές**
 
-Look at the commit activity on the main branch. On GitHub, you can see this information on a repository's homepage.
+Κοιτάξτε τη δραστηριότητα των δεσμεύσεων στον κύριο κλάδο. Στο GitHub, μπορείτε να δείτε αυτές τις πληροφορίες στην αρχική σελίδα ενός αποθετηρίου.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-  When was the latest commit?
+  Πότε έγινε το τελευταίο commit;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-  How many contributors does the project have?
+  Πόσους συνεισφέροντες έχει το πρότζεκτ;
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  Πόσο συχνά κάνει commit ο κόσμος; (Στο GitHub, μπορείτε να βρείτε αυτή την πληροφορία κάνοντας κλίκ στο "Commits" στην επάνω μπάρα.)
   </label>
 </div>
 
-Next, look at the project's issues.
+Στη συνέχεια, εξετάστε τα ζητήματα του πρότζεκτ.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    How many open issues are there?
+    Πόσα ζητήματα υπάρχουν;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to issues when they are opened?
+    Ανταποκρίνονται οι συντηρητές γρήγορα στα θέματα που ανοίγουν;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the issues?
+     Υπάρχει ενεργή συζήτηση επί των θεμάτων;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-    Are the issues recent?
+    Είναι τα θέματα πρόσφατα;
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+     Κλείνουν τα θέματα; (Στο GitHub, κάντε κλικ στην καρτέλα "closed" στη σελίδα Issues για να δείτε τα κλειστά ζητήματα.
   </label>
 </div>
 
-Now do the same for the project's pull requests.
+Τώρα κάντε το ίδιο για τις αιτήσεις έλξης του έργου.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    How many open pull requests are there?
+     Πόσες ανοιχτές αιτήσεις έλξης υπάρχουν;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox20" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to pull requests when they are opened?
+     Οι συντηρητές ανταποκρίνονται γρήγορα στις αιτήσεις έλξης όταν ανοίγουν;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the pull requests?
+      Υπάρχει ενεργή συζήτηση σχετικά με τα pull requests;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    Are the pull requests recent?
+     Είναι πρόσφατες οι αιτήσεις έλξης;
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox13" class="overflow-hidden d-block text-normal">
-    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+     Πόσο πρόσφατα συγχωνεύτηκαν κάποια pull requests; (Στο GitHub, κάντε κλικ στην καρτέλα "closed" στη σελίδα Pull Requests για να δείτε τα κλειστά PRs.)
   </label>
 </div>
 
-**Project is welcoming**
+**Το έργο είναι φιλόξενο**
 
-A project that is friendly and welcoming signals that they will be receptive to new contributors.
+Ένα έργο που είναι φιλικό και φιλόξενο σηματοδοτεί ότι θα είναι δεκτικό σε νέους συνεισφέροντες.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox14" class="overflow-hidden d-block text-normal">
-    Do the maintainers respond helpfully to questions in issues?
+     Ανταποκρίνονται οι συντηρητές βοηθητικά στις ερωτήσεις στα θέματα;
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox15" class="overflow-hidden d-block text-normal">
-    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+     Είναι οι άνθρωποι φιλικοί στα θέματα, στο φόρουμ συζητήσεων και στη συνομιλία (για παράδειγμα, στο IRC ή στο Slack);
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox16" class="overflow-hidden d-block text-normal">
-    Do pull requests get reviewed?
+     Επανεξετάζονται τα pull requests;
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox17" class="overflow-hidden d-block text-normal">
-    Do maintainers thank people for their contributions?
+     Οι συντηρητές ευχαριστούν τους ανθρώπους για τις συνεισφορές τους;
   </label>
 </div>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-  Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+   Κάθε φορά που βλέπετε ένα μακρύ νήμα, ελέγξτε επιτόπου τις απαντήσεις από τους προγραμματιστές του πυρήνα που έρχονται αργά στο νήμα. Συνοψίζουν εποικοδομητικά και λαμβάνουν μέτρα για να οδηγήσουν το νήμα σε μια απόφαση παραμένοντας ευγενικοί; Αν βλέπετε να γίνονται πολλοί πόλεμοι φλογών, αυτό είναι συχνά σημάδι ότι η ενέργεια πηγαίνει σε επιχειρήματα αντί για την ανάπτυξη.
   <p markdown="1" class="pquote-credit">
 — @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
   </p>
 </aside>
 
-## How to submit a contribution
+## Πώς να υποβάλετε μια συνεισφορά
 
-You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+Βρήκατε ένα έργο που σας αρέσει και είστε έτοιμοι να συνεισφέρετε. Επιτέλους! Εδώ θα δείτε πώς θα στείλετε τη συνεισφορά σας με τον σωστό τρόπο.
 
-### Communicating effectively
+### Αποτελεσματική επικοινωνία
 
-Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+Είτε συνεισφέρετε μια φορά είτε προσπαθείτε να ενταχθείτε σε μια κοινότητα, η συνεργασία με άλλους είναι μια από τις σημαντικότερες δεξιότητες που θα αναπτύξετε στον ανοιχτό κώδικα.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
-  \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+  \[Ως νέος συνεισφέρων,\] γρήγορα συνειδητοποίησα ότι έπρεπε να κάνω ερωτήσεις αν ήθελα να μπορέσω να κλείσω το θέμα. Ξεφύλλισα τη βάση κώδικα. Μόλις κατάλαβα τι συνέβαινε, ζήτησα περισσότερες οδηγίες. Και ιδού! Μπόρεσα να λύσω το ζήτημα αφού πήρα όλες τις σχετικές λεπτομέρειες που χρειαζόμουν.
   <p markdown="1" class="pquote-credit">
-— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+- @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
   </p>
 </aside>
 
-Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+Προτού ανοίξετε ένα θέμα ή ένα pull request ή κάνετε μια ερώτηση στη συνομιλία, έχετε υπόψη σας αυτά τα σημεία για να βοηθήσετε τις ιδέες σας να περάσουν αποτελεσματικά.
 
-**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+**Δώστε πλαίσιο.** Βοηθήστε τους άλλους να ενημερωθούν γρήγορα. Αν αντιμετωπίζετε ένα σφάλμα, εξηγήστε τι προσπαθείτε να κάνετε και πώς να το αναπαράγετε. Αν προτείνετε μια νέα ιδέα, εξηγήστε γιατί πιστεύετε ότι θα ήταν χρήσιμη για το έργο (όχι μόνο για εσάς!).
 
-> 😇 _"X doesn't happen when I do Y"_
+> 😇 _"Το Χ δεν συμβαίνει όταν κάνω το Υ"_
 >
-> 😢 _"X is broken! Please fix it."_
+> 😢 _"Το X είναι χαλασμένο! Σε παρακαλώ, διόρθωσέ το."_
 
-**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn.
+**Κάντε την έρευνα σας εκ των προτέρων.** Δεν πειράζει να μην ξέρετε πράγματα, αλλά δείξτε ότι προσπαθήσατε. Πριν ζητήσετε βοήθεια, φροντίστε να ελέγξετε το README ενός έργου, την τεκμηρίωση, τα θέματα (ανοικτά ή κλειστά), τη λίστα αλληλογραφίας και να ψάξετε στο διαδίκτυο για μια απάντηση. Οι άνθρωποι θα το εκτιμήσουν όταν δείχνετε ότι προσπαθείτε να μάθετε.
 
-> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+> 😇 _"Δεν είμαι σίγουρος πώς να υλοποιήσω το X. Έλεγξα τα έγγραφα βοήθειας και δεν βρήκα καμία αναφορά."_
 >
-> 😢 _"How do I X?"_
+> 😢 _"Πώς μπορώ να κάνω το X;"_
 
-**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+**Κρατήστε τα αιτήματα σύντομα και άμεσα.** Όπως και με την αποστολή ενός email, κάθε συνεισφορά, όσο απλή ή χρήσιμη κι αν είναι, απαιτεί την εξέταση κάποιου άλλου. Πολλά έργα έχουν περισσότερα εισερχόμενα αιτήματα από άτομα που είναι διαθέσιμα να βοηθήσουν. Να είστε συνοπτικοί. Θα αυξήσετε την πιθανότητα να μπορέσει κάποιος να σας βοηθήσει.
 
-> 😇 _"I'd like to write an API tutorial."_
+> 😇 _"Θα ήθελα να γράψω ένα tutorial για API."_
 >
-> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+> 😢 _"Οδηγούσα στον αυτοκινητόδρομο τις προάλλες και σταμάτησα για βενζίνη, και τότε μου ήρθε αυτή η καταπληκτική ιδέα για κάτι που πρέπει να κάνουμε, αλλά πριν σας το εξηγήσω, επιτρέψτε μου να σας δείξω..."_
 
-**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+**Κρατήστε όλη την επικοινωνία δημόσια.** Αν και είναι δελεαστικό, μην επικοινωνείτε με τους συντηρητές ιδιωτικά, εκτός αν πρέπει να μοιραστείτε ευαίσθητες πληροφορίες (όπως ένα ζήτημα ασφάλειας ή μια σοβαρή παραβίαση συμπεριφοράς). Όταν κρατάτε τη συζήτηση δημόσια, περισσότεροι άνθρωποι μπορούν να μάθουν και να επωφεληθούν από την ανταλλαγή σας. Οι συζητήσεις μπορούν να είναι, από μόνες τους, συνεισφορές.
 
-> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+> 😇 _(ως σχόλιο) "@-maintainer Γεια σας! Πώς θα πρέπει να προχωρήσουμε σε αυτή τη δημοσιότητα;"_
 >
-> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+> 😢 _(ως email) "Γεια σου, συγγνώμη που σε ενοχλώ μέσω email, αλλά αναρωτιόμουν αν είχες την ευκαιρία να αναθεωρήσεις το PR μου"_
 
-**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+**Δεν πειράζει να κάνετε ερωτήσεις (αλλά να είστε υπομονετικοί!).** Όλοι ήταν νέοι στο έργο κάποια στιγμή, και ακόμη και οι έμπειροι συνεισφέροντες πρέπει να ενημερωθούν όταν βλέπουν ένα νέο έργο. Με την ίδια λογική, ακόμη και οι μακροχρόνιοι συντηρητές δεν είναι πάντα εξοικειωμένοι με κάθε μέρος του έργου. Δείξτε τους την ίδια υπομονή που θα θέλατε να δείξουν και αυτοί σε εσάς.
 
-> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+> 😇 _"Ευχαριστώ που εξετάσατε αυτό το σφάλμα. Ακολούθησα τις προτάσεις σας. Εδώ είναι η έξοδος."_
 >
-> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+> 😢 _"Γιατί δεν μπορείτε να διορθώσετε το πρόβλημά μου; Αυτό δεν είναι το έργο σας;"_
 
-**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+**Σεβαστείτε τις αποφάσεις της κοινότητας.** Οι ιδέες σας μπορεί να διαφέρουν από τις προτεραιότητες ή το όραμα της κοινότητας. Μπορεί να προσφέρουν ανατροφοδότηση ή να αποφασίσουν να μην ακολουθήσουν την ιδέα σας. Ενώ θα πρέπει να συζητάτε και να αναζητάτε συμβιβασμούς, οι συντηρητές πρέπει να ζουν με την απόφασή σας περισσότερο από ό,τι εσείς. Αν διαφωνείτε με την κατεύθυνσή τους, μπορείτε πάντα να δουλέψετε πάνω στο δικό σας fork ή να ξεκινήσετε το δικό σας έργο.
 
-> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+> 😇 _"Απογοητεύομαι που δεν μπορείτε να υποστηρίξετε την περίπτωση χρήσης μου, αλλά όπως εξηγήσατε επηρεάζει μόνο ένα μικρό μέρος των χρηστών, καταλαβαίνω γιατί. Ευχαριστώ που με ακούσατε."_
 >
-> 😢 _"Why won't you support my use case? This is unacceptable!"_
+> 😢 _"Γιατί δεν υποστηρίζετε την περίπτωση χρήσης μου; Αυτό είναι απαράδεκτο!"_
 
-**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+**Πάνω απ' όλα, κρατήστε το κομψό.** Ο ανοικτός κώδικας αποτελείται από συνεργάτες από όλο τον κόσμο. Τα συμφραζόμενα χάνονται μεταξύ γλωσσών, πολιτισμών, γεωγραφικών περιοχών και ζωνών ώρας. Επιπλέον, η γραπτή επικοινωνία δυσκολεύει τη μετάδοση του τόνου ή της διάθεσης. Υποθέστε καλές προθέσεις σε αυτές τις συζητήσεις. Δεν πειράζει να απορρίψετε ευγενικά μια ιδέα, να ζητήσετε περισσότερα συμφραζόμενα ή να διευκρινίσετε περαιτέρω τη θέση σας. Απλά προσπαθήστε να αφήσετε το διαδίκτυο σε ένα καλύτερο μέρος από αυτό που βρήκατε.
 
-### Gathering context
+### Συγκέντρωση περιεχομένου
 
-Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+Πριν κάνετε οτιδήποτε, κάντε έναν γρήγορο έλεγχο για να βεβαιωθείτε ότι η ιδέα σας δεν έχει συζητηθεί αλλού. Ξεφυλλίστε το README του έργου, τα θέματα (ανοικτά και κλειστά), τη λίστα αλληλογραφίας και το Stack Overflow. Δεν χρειάζεται να ξοδέψετε ώρες για να ψάξετε τα πάντα, αλλά μια γρήγορη αναζήτηση για μερικούς όρους-κλειδιά θα σας βοηθήσει πολύ.
 
-If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request:
+Αν δεν μπορείτε να βρείτε την ιδέα σας αλλού, είστε έτοιμοι να κάνετε μια κίνηση. Αν το έργο βρίσκεται στο GitHub, πιθανότατα θα επικοινωνήσετε ανοίγοντας ένα ζήτημα ή ένα pull request:
 
-* **Issues** are like starting a conversation or discussion
-* **Pull requests** are for starting work on a solution
-* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one
+* **Τα θέματα** είναι σαν να ξεκινάτε μια συζήτηση ή μια συζήτηση
+* **Αιτήματα μετακίνησης** είναι για την έναρξη της εργασίας πάνω σε μια λύση
+* **Για ελαφριά επικοινωνία**, όπως μια διευκρινιστική ερώτηση ή μια ερώτηση για το πώς να κάνετε, δοκιμάστε να ρωτήσετε στο Stack Overflow, στο IRC, στο Slack ή σε άλλα κανάλια συνομιλίας, αν το έργο διαθέτει τέτοιο κανάλι.
 
-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.
+Πριν ανοίξετε ένα θέμα ή ένα αίτημα έλξης, ελέγξτε τα έγγραφα συνεισφοράς του έργου (συνήθως ένα αρχείο που ονομάζεται ΣΥΝΔΡΟΜΗ ή στο README), για να δείτε αν πρέπει να συμπεριλάβετε κάτι συγκεκριμένο. Για παράδειγμα, μπορεί να σας ζητούν να ακολουθήσετε ένα πρότυπο ή να απαιτείται η χρήση δοκιμών.
 
-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.
+Αν θέλετε να κάνετε μια ουσιαστική συνεισφορά, ανοίξτε ένα θέμα για να ρωτήσετε πριν εργαστείτε πάνω σε αυτό. Είναι χρήσιμο να παρακολουθείτε το έργο για λίγο (στο GitHub, [μπορείτε να κάνετε κλικ στο "Watch"](https://help.github.com/articles/watching-repositories/) για να ενημερώνεστε για όλες τις συζητήσεις), και να γνωρίσετε τα μέλη της κοινότητας, πριν κάνετε εργασία που μπορεί να μην γίνει αποδεκτή.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -457,72 +457,72 @@ If you want to make a substantial contribution, open an issue to ask before work
   </p>
 </aside>
 
-### Opening an issue
+### Άνοιγμα ενός θέματος
 
-You should usually open an issue in the following situations:
+Συνήθως πρέπει να ανοίγετε ένα θέμα στις ακόλουθες περιπτώσεις:
 
-* Report an error you can't solve yourself
-* Discuss a high-level topic or idea (for example, community, vision or policies)
-* Propose a new feature or other project idea
+* Αναφέρετε ένα σφάλμα που δεν μπορείτε να λύσετε μόνοι σας
+* Συζητήστε ένα θέμα ή μια ιδέα υψηλού επιπέδου (για παράδειγμα, κοινότητα, όραμα ή πολιτικές)
+* Προτείνετε ένα νέο χαρακτηριστικό ή μια άλλη ιδέα έργου
 
-Tips for communicating on issues:
+Συμβουλές για την επικοινωνία σχετικά με θέματα:
 
-* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
-* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
-* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+* **Αν δείτε ένα ανοιχτό ζήτημα που θέλετε να αντιμετωπίσετε,** σχολιάστε το ζήτημα για να ενημερώσετε τους άλλους ότι ασχολείστε με αυτό. Με αυτόν τον τρόπο, οι άνθρωποι είναι λιγότερο πιθανό να αντιγράψουν τη δουλειά σας.
+* **Αν ένα θέμα έχει ανοίξει πριν από καιρό,** είναι πιθανό να αντιμετωπίζεται κάπου αλλού ή να έχει ήδη επιλυθεί, οπότε σχολιάστε για να ζητήσετε επιβεβαίωση πριν ξεκινήσετε την εργασία.
+* **Αν ανοίξατε ένα θέμα, αλλά βρήκατε την απάντηση αργότερα μόνοι σας,** σχολιάστε το θέμα για να ενημερώσετε τους άλλους και, στη συνέχεια, κλείστε το θέμα. Ακόμα και η τεκμηρίωση αυτού του αποτελέσματος αποτελεί συμβολή στο έργο.
 
-### Opening a pull request
+### Άνοιγμα ενός αιτήματος αλλαγής κειμένου
 
-You should usually open a pull request in the following situations:
+Συνήθως θα πρέπει να ανοίγετε ένα pull request στις ακόλουθες περιπτώσεις:
 
-* Submit trivial fixes (for example, a typo, a broken link or an obvious error)
-* Start work on a contribution that was already asked for, or that you've already discussed, in an issue
+* Υποβολή ασήμαντων διορθώσεων (για παράδειγμα, ένα τυπογραφικό λάθος, ένας σπασμένος σύνδεσμος ή ένα προφανές σφάλμα)
+* Ξεκινήστε να εργάζεστε σε μια συνεισφορά που σας έχει ήδη ζητηθεί, ή που έχετε ήδη συζητήσει, σε ένα θέμα
 
-A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
+Ένα pull request δεν χρειάζεται να αντιπροσωπεύει ολοκληρωμένη εργασία. Συνήθως είναι καλύτερο να ανοίξετε ένα pull request νωρίς, ώστε οι άλλοι να μπορούν να παρακολουθήσουν ή να δώσουν ανατροφοδότηση σχετικά με την πρόοδό σας. Απλά σημειώστε το ως "WIP" (Work in Progress) στη γραμμή θέματος. Μπορείτε πάντα να προσθέσετε περισσότερα commits αργότερα.
 
-If the project is on GitHub, here's how to submit a pull request:
+Αν το έργο βρίσκεται στο GitHub, δείτε πώς μπορείτε να υποβάλετε ένα 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/).)
-* **[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.
-* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
-* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+* **[Κάντε fork το πρότζεκτ](https://guides.github.com/activities/forking/)** και κλωνοποιήστε το τοπικά. Συνδέστε το τοπικό σας με το αρχικό "upstream" αποθετήριο προσθέτοντάς το ως απομακρυσμένο. Τραβήξτε συχνά αλλαγές από το "upstream" ώστε να παραμένετε ενημερωμένοι, ώστε όταν υποβάλετε το pull request σας, οι συγκρούσεις συγχώνευσης να είναι λιγότερο πιθανές. (Δείτε πιο λεπτομερείς οδηγίες [εδώ](https://help.github.com/articles/syncing-a-fork/).)
+* **[Δημιουργήστε έναν κλάδο](https://guides.github.com/introduction/flow/)** για τις επεξεργασίες σας.
+* **Αναφέρετε οποιαδήποτε σχετικά θέματα** ή υποστηρικτική τεκμηρίωση στο PR σας (για παράδειγμα, "Κλείνει το #37.")
+* **Περιλάβετε στιγμιότυπα οθόνης του πριν και του μετά** αν οι αλλαγές σας περιλαμβάνουν διαφορές στην HTML/CSS. Σύρετε και αφήστε τις εικόνες στο σώμα του αιτήματος έλξης σας.
+* **Δοκιμάστε τις αλλαγές σας!** Ελέγξτε τις αλλαγές σας με τυχόν υπάρχουσες δοκιμές, αν υπάρχουν, και δημιουργήστε νέες, όταν χρειάζεται. Είτε υπάρχουν δοκιμές είτε όχι, βεβαιωθείτε ότι οι αλλαγές σας δεν καταστρέφουν το υπάρχον έργο.
+* **Συνεισφέρετε στο ύφος του έργου** στο μέτρο των δυνατοτήτων σας. Αυτό μπορεί να σημαίνει ότι χρησιμοποιείτε εσοχές, άνω και κάτω τελεία ή σχόλια διαφορετικά από ό,τι θα κάνατε στο δικό σας αποθετήριο, αλλά διευκολύνει τον συντηρητή να συγχωνεύσει, άλλους να καταλάβουν και να συντηρήσουν στο μέλλον.
 
-If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+Αν αυτό είναι το πρώτο σας pull request, ελέγξτε το [Make a Pull Request](http://makeapullrequest.com/), το οποίο δημιούργησε ο @kentcdodds ως ένα βίντεο με οδηγίες. Μπορείτε επίσης να εξασκηθείτε στο να κάνετε ένα pull request στο αποθετήριο [First Contributions](https://github.com/Roshanjossey/first-contributions), που δημιουργήθηκε από τον @Roshanjossey.
 
-## What happens after you submit a contribution
+## Τι συμβαίνει μετά την υποβολή μιας συνεισφοράς
 
-You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
+Τα καταφέρατε! Συγχαρητήρια που γίνατε συνεργάτης ανοιχτού κώδικα. Ελπίζουμε να είναι η πρώτη από τις πολλές.
 
-After you submit a contribution, one of the following will happen:
+Αφού υποβάλετε μια συνεισφορά, θα συμβεί ένα από τα ακόλουθα:
 
-### 😭 You don't get a response.
+### 😭 Δεν λαμβάνετε απάντηση.
 
-Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+Ελπίζουμε ότι [ελέγξατε το έργο για σημάδια δραστηριότητας](#a-checklist-before-you-contribute) πριν κάνετε μια συνεισφορά. Ακόμα και σε ένα ενεργό έργο, ωστόσο, είναι πιθανό η συνεισφορά σας να μην λάβει απάντηση.
 
-If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+Αν δεν έχετε λάβει απάντηση για πάνω από μια εβδομάδα, είναι δίκαιο να απαντήσετε ευγενικά στο ίδιο θέμα, ζητώντας από κάποιον να το αξιολογήσει. Αν γνωρίζετε το όνομα του κατάλληλου ατόμου που θα αξιολογήσει τη συνεισφορά σας, μπορείτε να τον @-αναφέρετε στο ίδιο θέμα.
 
-**Don't** reach out to that person privately; remember that public communication is vital to open source projects.
+**Μην** απευθυνθείτε σε αυτό το άτομο ιδιωτικά- να θυμάστε ότι η δημόσια επικοινωνία είναι ζωτικής σημασίας για τα έργα ανοικτού κώδικα.
 
-If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+Αν κάνετε ένα ευγενικό χτύπημα και παρόλα αυτά κανείς δεν απαντήσει, είναι πιθανό ότι κανείς δεν θα απαντήσει, ποτέ. Δεν είναι ωραίο συναίσθημα, αλλά μην το αφήσετε να σας αποθαρρύνει. Έχει συμβεί σε όλους! Υπάρχουν πολλοί πιθανοί λόγοι για τους οποίους δεν πήρατε απάντηση, συμπεριλαμβανομένων προσωπικών περιστάσεων που μπορεί να είναι εκτός του ελέγχου σας. Προσπαθήστε να βρείτε ένα άλλο έργο ή έναν άλλο τρόπο να συνεισφέρετε. Αν μη τι άλλο, αυτός είναι ένας καλός λόγος για να μην επενδύσετε πολύ χρόνο στην πραγματοποίηση μιας συνεισφοράς πριν τα άλλα μέλη της κοινότητας ασχοληθούν και ανταποκριθούν.
 
-### 🚧 Someone requests changes to your contribution.
+### 🚧 Κάποιος ζητά αλλαγές στη συνεισφορά σας.
 
-It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+Είναι σύνηθες να σας ζητηθεί να κάνετε αλλαγές στη συνεισφορά σας, είτε πρόκειται για ανατροφοδότηση σχετικά με το εύρος της ιδέας σας, είτε για αλλαγές στον κώδικά σας.
 
-When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it.
+Όταν κάποιος ζητάει αλλαγές, ανταποκριθείτε. Έχουν αφιερώσει χρόνο για να εξετάσουν τη συνεισφορά σας. Το να ανοίγετε ένα PR και να φεύγετε είναι κακή συμπεριφορά. Αν δεν ξέρετε πώς να κάνετε αλλαγές, ερευνήστε το πρόβλημα και, στη συνέχεια, ζητήστε βοήθεια αν τη χρειάζεστε.
 
-If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
+Αν δεν έχετε πια χρόνο να ασχοληθείτε με το θέμα (για παράδειγμα, αν η συζήτηση διαρκεί μήνες και οι συνθήκες έχουν αλλάξει), ενημερώστε τον συντηρητή ώστε να μην περιμένει απάντηση. Κάποιος άλλος μπορεί να είναι στην ευχάριστη θέση να αναλάβει.
 
-### 👎 Your contribution doesn't get accepted.
+### 👎 Η συνεισφορά σας δεν γίνεται αποδεκτή.
 
-Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+Η συνεισφορά σας μπορεί να γίνει αποδεκτή ή να μην γίνει αποδεκτή τελικά. Ελπίζω να μην έχετε ήδη αφιερώσει πολλή δουλειά σε αυτήν. Αν δεν είστε σίγουροι γιατί δεν έγινε αποδεκτή, είναι απολύτως λογικό να ζητήσετε από τον συντηρητή ανατροφοδότηση και διευκρινίσεις. Τελικά, όμως, θα πρέπει να σεβαστείτε ότι αυτή είναι η απόφασή τους. Μην διαφωνήσετε ή γίνετε εχθρικοί. Είστε πάντα ευπρόσδεκτοι να διακλαδώσετε και να δουλέψετε στη δική σας έκδοση αν διαφωνείτε!
 
-### 🎉 Your contribution gets accepted.
+### 🎉 Η συνεισφορά σας γίνεται αποδεκτή.
 
-Hooray! You've successfully made an open source contribution!
+Ζήτω! Κάνατε με επιτυχία μια συνεισφορά σε ανοιχτό κώδικα!
 
-## You did it!
+## Τα καταφέρατε!
 
-Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
+Είτε μόλις κάνατε την πρώτη σας συνεισφορά σε ανοιχτό κώδικα, είτε ψάχνετε για νέους τρόπους συνεισφοράς, ελπίζουμε να εμπνευστείτε για να αναλάβετε δράση. Ακόμα και αν η συνεισφορά σας δεν έγινε αποδεκτή, μην ξεχνάτε να λέτε ευχαριστώ όταν ένας συντηρητής κατέβαλε προσπάθεια για να σας βοηθήσει. Ο ανοιχτός κώδικας δημιουργείται από ανθρώπους σαν εσάς: ένα θέμα, ένα αίτημα διανομής, ένα σχόλιο ή ένα "high-five" κάθε φορά.

From 72dd18549533013a478a333e4d760a3626fdca97 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 20 Sep 2022 11:00:09 +0300
Subject: [PATCH 395/749] translate leadership-and-governance.md

---
 _articles/el/leadership-and-governance.md | 122 +++++++++++-----------
 1 file changed, 61 insertions(+), 61 deletions(-)

diff --git a/_articles/el/leadership-and-governance.md b/_articles/el/leadership-and-governance.md
index 2171d327915..1bd1bde86f5 100644
--- a/_articles/el/leadership-and-governance.md
+++ b/_articles/el/leadership-and-governance.md
@@ -10,147 +10,147 @@ related:
   - metrics
 ---
 
-## Understanding governance for your growing project
+## Κατανόηση της διακυβέρνησης για το αναπτυσσόμενο πρότζεκτ σας
 
-Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+Το πρότζεκτ σας αναπτύσσεται, οι άνθρωποι είναι αφοσιωμένοι και είστε αποφασισμένοι να το συνεχίσετε. Σε αυτό το στάδιο, μπορεί να αναρωτιέστε πώς να ενσωματώσετε τους τακτικούς συνεργάτες του πρότζεκτ στη ροή εργασίας σας, είτε πρόκειται για την παροχή σε κάποιον πρόσβασης στη δέσμευση είτε για την επίλυση των συζητήσεων της κοινότητας. Αν έχετε απορίες, έχουμε απαντήσεις.
 
-## What are examples of formal roles used in open source projects?
+## Ποια είναι παραδείγματα επίσημων ρόλων που χρησιμοποιούνται σε πρότζεκτ ανοικτού κώδικα;
 
-Many projects follow a similar structure for contributor roles and recognition.
+Πολλά πρότζεκτ ακολουθούν μια παρόμοια δομή για τους ρόλους και την αναγνώριση των συνεισφερόντων.
 
-What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+Το τι σημαίνουν στην πραγματικότητα αυτοί οι ρόλοι, όμως, εξαρτάται αποκλειστικά από εσάς. Ακολουθούν μερικοί τύποι ρόλων που μπορεί να αναγνωρίσετε:
 
-* **Maintainer**
+* **Συντηρητής**
 * **Contributor**
 * **Committer**
 
-**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+**Για ορισμένα πρότζεκτ, οι "συντηρητές"** είναι τα μόνα άτομα σε ένα πρότζεκτ με πρόσβαση στa commits. Σε άλλα πρότζεκτ, είναι απλά τα άτομα που αναφέρονται στο README ως συντηρητές.
 
-A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+Ένας συντηρητής δεν χρειάζεται απαραίτητα να είναι κάποιος που γράφει κώδικα για το πρότζεκτ σας. Θα μπορούσε να είναι κάποιος που έχει κάνει πολλή δουλειά για να ευαγγελιστεί το πρότζεκτ σας, ή έχει γράψει τεκμηρίωση που έκανε το πρότζεκτ πιο προσιτό σε άλλους. Ανεξάρτητα από το τι κάνει καθημερινά, ένας συντηρητής είναι πιθανότατα κάποιος που αισθάνεται την ευθύνη για την κατεύθυνση του πρότζεκτ και δεσμεύεται να το βελτιώσει.
 
-**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+**Ένας "contributor" θα μπορούσε να είναι οποιοσδήποτε** που σχολιάζει ένα θέμα ή ένα pull request, άνθρωποι που προσθέτουν αξία στο πρότζεκτ (είτε πρόκειται για τη διαχείριση θεμάτων, τη συγγραφή κώδικα ή τη διοργάνωση εκδηλώσεων), ή οποιοσδήποτε με ένα συγχωνευμένο pull request (ίσως ο στενότερος ορισμός ενός contributor).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+  \[Για το Node.js,\] κάθε άτομο που εμφανίζεται για να σχολιάσει ένα θέμα ή να υποβάλει κώδικα είναι μέλος της κοινότητας ενός πρότζεκτ. Και μόνο το γεγονός ότι είναι σε θέση να τους βλέπεις σημαίνει ότι είναι πια συνεισφέροντες και όχι απλώς χρήστες.
   <p markdown="1" class="pquote-credit">
-— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+- @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
   </p>
 </aside>
 
-**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+**Ο όρος "committer"** θα μπορούσε να χρησιμοποιηθεί για να διακρίνει την πρόσβαση στα commits, η οποία είναι ένας συγκεκριμένος τύπος ευθύνης, από άλλες μορφές συνεισφοράς.
 
-While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+Ενώ μπορείτε να ορίσετε τους ρόλους του πρότζεκτ σας με όποιον τρόπο θέλετε, [εξετάστε το ενδεχόμενο να χρησιμοποιήσετε ευρύτερους ορισμούς](../how-to-contribute/#what-it-means-to-contribute) για να ενθαρρύνετε περισσότερες μορφές συνεισφοράς. Μπορείτε να χρησιμοποιήσετε τους ρόλους ηγεσίας για να αναγνωρίσετε επίσημα τους ανθρώπους που έχουν συνεισφέρει εξαιρετικά στο πρότζεκτ σας, ανεξάρτητα από τις τεχνικές τους δεξιότητες.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
-  You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+  Μπορεί να με ξέρετε ως τον "εφευρέτη" του Django... αλλά στην πραγματικότητα είμαι ο τύπος που προσλήφθηκε για να δουλέψει πάνω σε ένα πράγμα ένα χρόνο αφότου είχε ήδη φτιαχτεί. (...) Οι άνθρωποι υποψιάζονται ότι είμαι επιτυχημένος λόγω των προγραμματιστικών μου ικανοτήτων... αλλά είμαι στην καλύτερη περίπτωση ένας μέτριος προγραμματιστής.
   <p markdown="1" class="pquote-credit">
-— @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+- @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
   </p>
 </aside>
 
-## How do I formalize these leadership roles?
+## Πώς μπορώ να επισημοποιήσω αυτούς τους ηγετικούς ρόλους;
 
-Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+Η επισημοποίηση των ηγετικών σας ρόλων βοηθάει τους ανθρώπους να αισθάνονται ιδιοκτησία και λέει στα άλλα μέλη της κοινότητας σε ποιον να απευθυνθούν για βοήθεια.
 
-For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+Για ένα μικρότερο πρότζεκτ, ο ορισμός των ηγετών μπορεί να είναι τόσο απλός όσο η προσθήκη των ονομάτων τους στο README ή σε ένα αρχείο κειμένου CONTRIBUTORS.
 
-For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+Για ένα μεγαλύτερο πρότζεκτ, αν έχετε έναν ιστότοπο, δημιουργήστε μια σελίδα ομάδας ή αναφέρετε εκεί τους επικεφαλής του πρότζεκτ σας. Για παράδειγμα, το [Postgres](https://github.com/postgres/postgres/) έχει μια [ολοκληρωμένη σελίδα ομάδας](https://www.postgresql.org/community/contributors/) με σύντομα προφίλ για κάθε συνεισφέροντα.
 
-If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+Εάν το πρότζεκτ σας έχει μια πολύ ενεργή κοινότητα συνεισφερόντων, μπορείτε να δημιουργήσετε μια "βασική ομάδα" συντηρητών ή ακόμη και υποεπιτροπές ατόμων που αναλαμβάνουν την ευθύνη για διαφορετικούς τομείς θεμάτων (για παράδειγμα, ασφάλεια, διαχείριση θεμάτων ή συμπεριφορά της κοινότητας). Αφήστε τους ανθρώπους να αυτοοργανωθούν και να αναλάβουν εθελοντικά τους ρόλους που τους ενθουσιάζουν περισσότερο, αντί να τους αναθέσετε.
 
 <aside markdown="1" class="pquote">
-  \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+  \[Εμείς\] συμπληρώνουμε τη βασική ομάδα με διάφορες "υποομάδες". Κάθε υποομάδα επικεντρώνεται σε έναν συγκεκριμένο τομέα, π.χ. στο σχεδιασμό γλωσσών ή στις βιβλιοθήκες. (...) Για να εξασφαλιστεί ο συνολικός συντονισμός και ένα ισχυρό, συνεκτικό όραμα για το πρότζεκτ ως σύνολο, κάθε υποομάδα καθοδηγείται από ένα μέλος της βασικής ομάδας.
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+- ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+Οι ηγετικές ομάδες μπορεί να θέλουν να δημιουργήσουν ένα καθορισμένο κανάλι (όπως στο IRC) ή να συναντώνται τακτικά για να συζητούν το πρότζεκτ (όπως στο Gitter ή στο Google Hangout). Μπορείτε ακόμη και να κάνετε αυτές τις συναντήσεις δημόσιες ώστε να μπορούν να τις ακούνε και άλλοι. Το [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), για παράδειγμα, [φιλοξενεί ώρες γραφείου κάθε εβδομάδα](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
-Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+Αφού καθιερώσετε ηγετικούς ρόλους, μην ξεχάσετε να τεκμηριώσετε πώς οι άνθρωποι μπορούν να τους αποκτήσουν! Καθορίστε μια σαφή διαδικασία για το πώς κάποιος μπορεί να γίνει συντηρητής ή να ενταχθεί σε μια υποεπιτροπή του πρότζεκτ σας και γράψτε την στο GOVERNANCE.md.
 
-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.
+Εργαλεία όπως το [Vossibility](https://github.com/icecrime/vossibility-stack) μπορούν να σας βοηθήσουν να παρακολουθείτε δημόσια ποιος συνεισφέρει (ή δεν συνεισφέρει) στο πρότζεκτ. Η τεκμηρίωση αυτών των πληροφοριών αποφεύγει την αντίληψη της κοινότητας ότι οι συντηρητές είναι μια κλίκα που παίρνει τις αποφάσεις της ιδιωτικά.
 
-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/#μοιραστείτε-την-ιδιοκτησία-του-πρότζεκτ-σας).
+Τέλος, αν το πρότζεκτ σας βρίσκεται στο GitHub, εξετάστε το ενδεχόμενο να μεταφέρετε το πρότζεκτ σας από τον προσωπικό σας λογαριασμό σε έναν Οργανισμό και να προσθέσετε τουλάχιστον έναν εφεδρικό διαχειριστή. Οι [Οργανισμοί του GitHub](https://help.github.com/articles/creating-a-new-organization-account/) διευκολύνουν τη διαχείριση των δικαιωμάτων και των πολλαπλών αποθετηρίων και προστατεύουν την κληρονομιά του πρότζεκτ σας μέσω της [κοινής ιδιοκτησίας](../building-community/#μοιραστείτε-την-ιδιοκτησία-του-πρότζεκτ-σας).
 
-## When should I give someone commit access?
+## Πότε θα πρέπει να δώσω σε κάποιον πρόσβαση στα commits;
 
-Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+Κάποιοι πιστεύουν ότι πρέπει να δίνετε πρόσβαση στα commits σε όλους όσους συνεισφέρουν. Κάτι τέτοιο θα μπορούσε να ενθαρρύνει περισσότερους ανθρώπους να νιώσουν ιδιοκτησία του πρότζεκτ σας.
 
-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.
+Αν το πρότζεκτ σας βρίσκεται στο GitHub, μπορείτε να χρησιμοποιήσετε το [protected branches](https://help.github.com/articles/about-protected-branches/) για να διαχειριστείτε ποιος μπορεί να προωθήσει σε ένα συγκεκριμένο κλάδο και υπό ποιες συνθήκες.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
-  Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+  Κάθε φορά που κάποιος σας στέλνει ένα pull request, δώστε του πρόσβαση στα commits στο πρότζεκτ σας. Αν και μπορεί να ακούγεται απίστευτα ανόητο στην αρχή, η χρήση αυτής της στρατηγικής θα σας επιτρέψει να απελευθερώσετε την πραγματική δύναμη του GitHub. (...) Μόλις οι άνθρωποι έχουν πρόσβαση στα commits, δεν ανησυχούν πλέον ότι η διόρθωσή τους μπορεί να μην ενσωματωθεί... με αποτέλεσμα να βάλουν πολύ περισσότερη δουλειά σε αυτήν.
   <p markdown="1" class="pquote-credit">
-— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+- @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
   </p>
 </aside>
 
-## What are some of the common governance structures for open source projects?
+## Ποιες είναι μερικές από τις συνήθεις δομές διακυβέρνησης για πρότζεκτ ανοικτού κώδικα;
 
-There are three common governance structures associated with open source projects.
+Υπάρχουν τρεις κοινές δομές διακυβέρνησης που σχετίζονται με πρότζεκτ ανοικτού κώδικα.
 
-* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+* **BDFL:** Το BDFL σημαίνει "καλοπροαίρετος δικτάτορας για όλη τη ζωή" (Benevolent Dictator For Life). Σύμφωνα με αυτή τη δομή, ένα άτομο (συνήθως ο αρχικός ιδιοκτήτης του πρότζεκτ) έχει τον τελικό λόγο σε όλες τις σημαντικές αποφάσεις του πρότζεκτ. Η [Python](https://github.com/python) είναι ένα κλασικό παράδειγμα. Τα μικρότερα πρότζεκτ είναι πιθανώς εξ ορισμού BDFL, επειδή υπάρχουν μόνο ένας ή δύο συντηρητές. Ένα πρότζεκτ που προέρχεται από μια εταιρεία μπορεί επίσης να εμπίπτει στην κατηγορία BDFL.
 
-* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+* **Μεριτοκρατία:** **(Σημείωση: ο όρος "αξιοκρατία" έχει αρνητική χροιά για ορισμένες κοινότητες και έχει μια [πολύπλοκη κοινωνική και πολιτική ιστορία](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Στο πλαίσιο μιας αξιοκρατίας, στους ενεργούς συνεισφέροντες στο πρότζεκτ (αυτούς που επιδεικνύουν "αξία") δίνεται επίσημος ρόλος στη λήψη αποφάσεων. Οι αποφάσεις λαμβάνονται συνήθως με βάση την καθαρή συναίνεση της ψηφοφορίας. Η έννοια της αξιοκρατίας πρωτοπορήθηκε από το [Apache Foundation](https://www.apache.org/)- [όλα τα πρότζεκτ του Apache](https://www.apache.org/index.html#projects-list) είναι αξιοκρατίες. Οι συνεισφορές μπορούν να γίνουν μόνο από άτομα που εκπροσωπούν τον εαυτό τους, όχι από μια εταιρεία.
 
-* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
+* **Φιλελεύθερη συνεισφορά:** Σύμφωνα με το μοντέλο της φιλελεύθερης συνεισφοράς, τα άτομα που κάνουν τη μεγαλύτερη δουλειά αναγνωρίζονται ως τα άτομα με τη μεγαλύτερη επιρροή, αλλά αυτό βασίζεται στην τρέχουσα δουλειά και όχι στις ιστορικές συνεισφορές. Οι σημαντικές αποφάσεις για το πρότζεκτ λαμβάνονται με βάση μια διαδικασία αναζήτησης συναίνεσης (συζήτηση των σημαντικότερων παραπόνων) και όχι με καθαρή ψηφοφορία, και επιδιώκεται να συμπεριληφθούν όσο το δυνατόν περισσότερες προοπτικές της κοινότητας. Δημοφιλή παραδείγματα πρότζεκτ που χρησιμοποιούν ένα φιλελεύθερο μοντέλο συνεισφοράς περιλαμβάνουν το [Node.js](https://foundation.nodejs.org/) και το [Rust](https://www.rust-lang.org/).
 
-Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+Ποιο από τα δύο πρέπει να χρησιμοποιήσετε; Εξαρτάται από εσάς! Κάθε μοντέλο έχει πλεονεκτήματα και συμβιβασμούς. Και παρόλο που μπορεί να φαίνονται αρκετά διαφορετικά στην αρχή, και τα τρία μοντέλα έχουν περισσότερα κοινά απ' όσα φαίνονται. Αν ενδιαφέρεστε να υιοθετήσετε ένα από αυτά τα μοντέλα, δείτε αυτά τα πρότυπα:
 
-* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
-* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
-* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+* [Πρότυπο μοντέλου BDFL](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Πρότυπο μοντέλου αξιοκρατίας](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Η φιλελεύθερη πολιτική συνεισφοράς του Node.js](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
 
-## Do I need governance docs when I launch my project?
+## Χρειάζομαι έγγραφα διακυβέρνησης όταν ξεκινάω το πρότζεκτ μου;
 
-There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+Δεν υπάρχει σωστή στιγμή για να καταγράψετε τη διακυβέρνηση του πρότζεκτ σας, αλλά είναι πολύ πιο εύκολο να την ορίσετε μόλις δείτε τη δυναμική της κοινότητάς σας να εξελίσσεται. Το καλύτερο (και δυσκολότερο) μέρος της διακυβέρνησης του ανοιχτού κώδικα είναι ότι διαμορφώνεται από την κοινότητα!
 
-Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+Ωστόσο, κάποια πρώιμη τεκμηρίωση θα συμβάλει αναπόφευκτα στη διακυβέρνηση του πρότζεκτ σας, οπότε αρχίστε να γράφετε ό,τι μπορείτε. Για παράδειγμα, μπορείτε να ορίσετε σαφείς προσδοκίες για τη συμπεριφορά ή τον τρόπο λειτουργίας της διαδικασίας συνεισφοράς σας, ακόμη και κατά την έναρξη του πρότζεκτ σας.
 
-If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
+Αν ανήκετε σε μια εταιρεία που εγκαινιάζει ένα πρότζεκτ ανοιχτού κώδικα, αξίζει να κάνετε μια εσωτερική συζήτηση πριν από την έναρξη σχετικά με το πώς η εταιρεία σας αναμένει να συντηρεί και να λαμβάνει αποφάσεις σχετικά με το πρότζεκτ που προχωράει. Μπορεί επίσης να θέλετε να εξηγήσετε δημόσια οτιδήποτε ιδιαίτερο σχετικά με τον τρόπο με τον οποίο η εταιρεία σας θα συμμετέχει (ή δεν θα συμμετέχει!) στο πρότζεκτ.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
-  We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+  Αναθέτουμε τη διαχείριση πρότζεκτ στο GitHub σε μικρές ομάδες που εργάζονται πραγματικά σε αυτά στο Facebook. Για παράδειγμα, το React διευθύνεται από έναν μηχανικό του React.
   <p markdown="1" class="pquote-credit">
-— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+- @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
   </p>
 </aside>
 
-## What happens if corporate employees start submitting contributions?
+## Τι θα συμβεί αν οι εταιρικοί υπάλληλοι αρχίσουν να υποβάλλουν συνεισφορές;
 
-Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+Τα επιτυχημένα πρότζεκτ ανοικτού κώδικα χρησιμοποιούνται από πολλούς ανθρώπους και εταιρείες, και ορισμένες εταιρείες μπορεί τελικά να έχουν ροές εσόδων που συνδέονται τελικά με το πρότζεκτ. Για παράδειγμα, μια εταιρεία μπορεί να χρησιμοποιήσει τον κώδικα του πρότζεκτ ως ένα συστατικό στοιχείο σε μια εμπορική προσφορά υπηρεσιών.
 
-As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+Καθώς το πρότζεκτ χρησιμοποιείται ευρύτερα, οι άνθρωποι που έχουν εμπειρία σε αυτό γίνονται πιο περιζήτητοι - ίσως είστε ένας από αυτούς! - και μερικές φορές θα πληρώνονται για τη δουλειά που κάνουν στο πρότζεκτ.
 
-It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+Είναι σημαντικό να αντιμετωπίζετε την εμπορική δραστηριότητα ως φυσιολογική και ως μια ακόμη πηγή ενέργειας ανάπτυξης. Φυσικά, οι αμειβόμενοι προγραμματιστές δεν πρέπει να τυγχάνουν ιδιαίτερης μεταχείρισης σε σχέση με τους μη αμειβόμενους- κάθε συνεισφορά πρέπει να αξιολογείται με βάση την τεχνική της αξία. Ωστόσο, οι άνθρωποι θα πρέπει να αισθάνονται άνετα να συμμετέχουν σε εμπορική δραστηριότητα και να αισθάνονται άνετα να αναφέρουν τις περιπτώσεις χρήσης τους όταν επιχειρηματολογούν υπέρ μιας συγκεκριμένης βελτίωσης ή λειτουργίας.
 
-"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+Το "εμπορικό" είναι απολύτως συμβατό με το "ανοιχτό κώδικα". "Εμπορικό" σημαίνει απλώς ότι κάπου εμπλέκονται χρήματα - ότι το λογισμικό χρησιμοποιείται στο εμπόριο, κάτι που είναι όλο και πιο πιθανό καθώς ένα πρότζεκτ κερδίζει την αποδοχή του. (Όταν το λογισμικό ανοικτού κώδικα χρησιμοποιείται ως μέρος ενός προϊόντος μη ανοικτού κώδικα, το συνολικό προϊόν εξακολουθεί να είναι "ιδιόκτητο" λογισμικό, αν και, όπως και ο ανοικτός κώδικας, μπορεί να χρησιμοποιηθεί για εμπορικούς ή μη εμπορικούς σκοπούς).
 
-Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+Όπως όλοι οι άλλοι, οι προγραμματιστές με εμπορικά κίνητρα αποκτούν επιρροή στο πρότζεκτ μέσω της ποιότητας και της ποσότητας των συνεισφορών τους. Προφανώς, ένας προγραμματιστής που πληρώνεται για το χρόνο του μπορεί να είναι σε θέση να κάνει περισσότερα από κάποιον που δεν πληρώνεται, αλλά αυτό δεν πειράζει: η πληρωμή είναι απλώς ένας από τους πολλούς πιθανούς παράγοντες που θα μπορούσαν να επηρεάσουν το πόσο κάνει κάποιος. Κρατήστε τις συζητήσεις σας για το πρότζεκτ επικεντρωμένες στις συνεισφορές και όχι στους εξωτερικούς παράγοντες που επιτρέπουν στους ανθρώπους να κάνουν αυτές τις συνεισφορές.
 
-## Do I need a legal entity to support my project?
+## Χρειάζομαι μια νομική οντότητα για να υποστηρίξω το πρότζεκτ μου;
 
-You don't need a legal entity to support your open source project unless you're handling money.
+Δεν χρειάζεστε μια νομική οντότητα για την υποστήριξη του πρότζεκτ σας ανοικτού κώδικα, εκτός αν διαχειρίζεστε χρήματα.
 
-For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+Για παράδειγμα, αν θέλετε να δημιουργήσετε μια εμπορική επιχείρηση, θα πρέπει να δημιουργήσετε μια C Corp ή LLC (αν έχετε την έδρα σας στις ΗΠΑ). Αν απλά κάνετε εργασίες συμβολαίου που σχετίζονται με το πρότζεκτ σας ανοικτού κώδικα, μπορείτε να δεχτείτε χρήματα ως ατομική επιχείρηση ή να δημιουργήσετε μια LLC (αν έχετε την έδρα σας στις ΗΠΑ).
 
-If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+Αν θέλετε να δέχεστε δωρεές για το ανοικτού κώδικα πρότζεκτ σας, μπορείτε να δημιουργήσετε ένα κουμπί δωρεάς (χρησιμοποιώντας το PayPal ή το Stripe, για παράδειγμα), αλλά τα χρήματα δεν θα εκπίπτουν από τη φορολογία, εκτός αν είστε αναγνωρισμένος μη κερδοσκοπικός οργανισμός (501c3, αν είστε στις ΗΠΑ).
 
-Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+Πολλά πρότζεκτ δεν επιθυμούν να μπουν στον κόπο να δημιουργήσουν έναν μη κερδοσκοπικό οργανισμό, οπότε βρίσκουν έναν μη κερδοσκοπικό φορολογικό χορηγό. Ένας φορολογικός χορηγός δέχεται δωρεές εκ μέρους σας, συνήθως με αντάλλαγμα ένα ποσοστό της δωρεάς. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) και [Open Collective](https://opencollective.com/opensource) είναι παραδείγματα οργανισμών που λειτουργούν ως φορολογικοί χορηγοί για πρότζεκτ ανοικτού κώδικα.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
-  Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+  Στόχος μας είναι να παρέχουμε μια υποδομή που οι κοινότητες μπορούν να χρησιμοποιήσουν για να είναι αυτοσυντηρούμενες, δημιουργώντας έτσι ένα περιβάλλον όπου όλοι - συνεισφέροντες, υποστηρικτές, χορηγοί - θα έχουν συγκεκριμένα οφέλη.
   <p markdown="1" class="pquote-credit">
-— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+- @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
   </p>
 </aside>
 
-If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
+Εάν το πρότζεκτ σας συνδέεται στενά με μια συγκεκριμένη γλώσσα ή οικοσύστημα, μπορεί επίσης να υπάρχει ένα σχετικό ίδρυμα λογισμικού με το οποίο μπορείτε να συνεργαστείτε. Για παράδειγμα, το [Python Software Foundation](https://www.python.org/psf/) βοηθά στην υποστήριξη του [PyPI](https://pypi.org/), του διαχειριστή πακέτων Python, και το [Node.js Foundation](https://foundation.nodejs.org/) βοηθά στην υποστήριξη του [Express.js](https://expressjs.com/), ενός πλαισίου βασισμένου στο Node.

From ea1bc0b7cdd2250d4a50456ffaf1e6ffa4dca662 Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 20 Sep 2022 11:37:49 +0300
Subject: [PATCH 396/749] Translate legal.md

---
 _articles/el/legal.md | 140 +++++++++++++++++++++---------------------
 1 file changed, 70 insertions(+), 70 deletions(-)

diff --git a/_articles/el/legal.md b/_articles/el/legal.md
index 7c7e700c560..01042fbdf58 100644
--- a/_articles/el/legal.md
+++ b/_articles/el/legal.md
@@ -10,149 +10,149 @@ related:
   - leadership
 ---
 
-## Understanding the legal implications of open source
+## Κατανόηση των νομικών επιπτώσεων του ανοικτού κώδικα
 
-Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+Το να μοιραστείτε το δημιουργικό σας πρότζεκτ με τον κόσμο μπορεί να είναι μια συναρπαστική και ικανοποιητική εμπειρία. Μπορεί επίσης να σημαίνει ένα σωρό νομικά πράγματα για τα οποία δεν γνωρίζατε ότι έπρεπε να ανησυχείτε. Ευτυχώς, δεν χρειάζεται να ξεκινήσετε από το μηδέν. Έχουμε καλύψει τις νομικές σας ανάγκες. (Πριν ξεκινήσετε, φροντίστε να διαβάσετε την [αποποίηση ευθυνών](/notices/) μας).
 
-## Why do people care so much about the legal side of open source?
+## Γιατί οι άνθρωποι ενδιαφέρονται τόσο πολύ για τη νομική πλευρά του ανοιχτού κώδικα;
 
-Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+Χαίρομαι που ρωτάτε! Όταν δημιουργείτε ένα δημιουργικό πρότζεκτ (όπως συγγραφή, γραφικά ή κώδικα), το πρότζεκτ αυτό υπόκειται εξ ορισμού σε αποκλειστικά πνευματικά δικαιώματα. Δηλαδή, ο νόμος υποθέτει ότι ως δημιουργός του πρότζεκτ σας, έχετε λόγο στο τι μπορούν να κάνουν οι άλλοι με αυτό.
 
-In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+Σε γενικές γραμμές, αυτό σημαίνει ότι κανένας άλλος δεν μπορεί να χρησιμοποιήσει, να αντιγράψει, να διανείμει ή να τροποποιήσει το πρότζεκτ σας χωρίς να κινδυνεύει από αποκοπές, εκβιασμούς ή δικαστικές διενέξεις.
 
-Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+Ωστόσο, ο ανοικτός κώδικας αποτελεί μια ασυνήθιστη περίπτωση, επειδή ο συγγραφέας αναμένει ότι άλλοι θα χρησιμοποιήσουν, θα τροποποιήσουν και θα μοιραστούν το πρότζεκτ. Αλλά επειδή η νομική προεπιλογή εξακολουθεί να είναι η αποκλειστική πνευματική ιδιοκτησία, χρειάζεστε μια άδεια που να δηλώνει ρητά αυτές τις άδειες.
 
-If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+Εάν δεν εφαρμόσετε μια άδεια χρήσης ανοικτού κώδικα, όλοι όσοι συνεισφέρουν στο πρότζεκτ σας γίνονται επίσης αποκλειστικοί κάτοχοι πνευματικών δικαιωμάτων της εργασίας τους. Αυτό σημαίνει ότι κανείς δεν μπορεί να χρησιμοποιήσει, να αντιγράψει, να διανείμει ή να τροποποιήσει τις συνεισφορές του - και σε αυτό το "κανείς" συμπεριλαμβάνεστε και εσείς.
 
-Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
+Τέλος, το πρότζεκτ σας μπορεί να έχει εξαρτήσεις με απαιτήσεις άδειας χρήσης που δεν γνωρίζατε. Η κοινότητα του πρότζεκτ σας ή οι πολιτικές του εργοδότη σας μπορεί επίσης να απαιτούν από το πρότζεκτ σας να χρησιμοποιεί συγκεκριμένες άδειες ανοικτού κώδικα. Θα καλύψουμε αυτές τις καταστάσεις παρακάτω.
 
-## Are public GitHub projects open source?
+## Είναι τα δημόσια πρότζεκτ GitHub ανοιχτού κώδικα;
 
-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**.
+Όταν [δημιουργείτε ένα νέο πρότζεκτ](https://help.github.com/articles/creating-a-new-repository/) στο GitHub, έχετε την επιλογή να κάνετε το αποθετήριο **ιδιωτικό** ή **δημόσιο**.
 
-![Create repository](/assets/images/legal/repo-create-name.png)
+![Δημιουργία αποθετηρίου](/assets/images/legal/repo-create-name.png)
 
-**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+**Η δημοσιοποίηση του έργου σας στο GitHub δεν είναι το ίδιο με την αδειοδότηση του έργου σας.** Τα δημόσια πρότζεκτ καλύπτονται από τους [Όρους χρήσης του GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), οι οποίοι επιτρέπουν σε άλλους να βλέπουν και να διαιρούν το πρότζεκτ σας, αλλά η εργασία σας δεν συνοδεύεται από άλλα δικαιώματα.
 
-If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+Αν θέλετε να χρησιμοποιούν, να διανέμουν, να τροποποιούν ή να συνεισφέρουν άλλοι στο πρότζεκτ σας, πρέπει να συμπεριλάβετε μια άδεια χρήσης ανοικτού κώδικα. Για παράδειγμα, κάποιος δεν μπορεί νομικά να χρησιμοποιήσει οποιοδήποτε μέρος του έργου σας στο GitHub στον κώδικά του, ακόμη και αν είναι δημόσιο, εκτός αν του δώσετε ρητά το δικαίωμα να το κάνει.
 
-## Just give me the TL;DR on what I need to protect my project.
+## Απλά δώστε μου ένα TL;DR σχετικά με το τι χρειάζομαι για να προστατεύσω το πρότζεκτ μου.
 
-You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+Είστε τυχεροί, διότι σήμερα οι άδειες χρήσης ανοικτού κώδικα είναι τυποποιημένες και εύκολες στη χρήση. Μπορείτε να αντιγράψετε-επικολλήσετε μια υπάρχουσα άδεια απευθείας στο πρότζεκτ σας.
 
-[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 the most popular open source 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/).
+Οι [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/).
 
-When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/).
+Όταν δημιουργείτε ένα νέο πρότζεκτ στο GitHub, θα σας ζητηθεί [να προσθέσετε μια άδεια](https://help.github.com/articles/open-source-licensing/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
-  A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+  Μια τυποποιημένη άδεια χρησιμεύει ως πληρεξούσιο για όσους δεν έχουν νομική κατάρτιση, ώστε να γνωρίζουν ακριβώς τι μπορούν και τι δεν μπορούν να κάνουν με το λογισμικό. Εκτός αν είναι απολύτως απαραίτητο, αποφύγετε τους προσαρμοσμένους, τροποποιημένους ή μη τυποποιημένους όρους, οι οποίοι θα αποτελέσουν εμπόδιο για τη μεταγενέστερη χρήση του κώδικα του οργανισμού.
   <p markdown="1" class="pquote-credit">
-— @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+- @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
   </p>
 </aside>
 
-## Which open source license is appropriate for my project?
+## Ποια άδεια ανοιχτού κώδικα είναι κατάλληλη για το πρότζεκτ μου;
 
-If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+Αν ξεκινάτε από μια κενή πλάκα, είναι δύσκολο να κάνετε λάθος με την [MIT License](https://choosealicense.com/licenses/mit/). Είναι σύντομη, πολύ εύκολη στην κατανόηση και επιτρέπει σε οποιονδήποτε να κάνει οτιδήποτε, αρκεί να κρατήσει ένα αντίγραφο της άδειας, συμπεριλαμβανομένης της ειδοποίησης για τα πνευματικά σας δικαιώματα. Θα είστε σε θέση να κυκλοφορήσετε το πρότζεκτ με μια διαφορετική άδεια αν ποτέ χρειαστεί.
 
-Otherwise, picking the right open source license for your project depends on your objectives.
+Διαφορετικά, η επιλογή της σωστής άδειας ανοικτού κώδικα για το πρότζεκτ σας εξαρτάται από τους στόχους σας.
 
-Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+Το πρότζεκτ σας είναι πολύ πιθανό να έχει (ή θα έχει) **εξαρτήσεις**. Για παράδειγμα, αν έχετε ένα πρότζεκτ που βασίζεται στο Node.js, πιθανότατα θα χρησιμοποιείτε βιβλιοθήκες από τον Node Package Manager (npm). Κάθε μία από αυτές τις βιβλιοθήκες από τις οποίες εξαρτάστε θα έχει τη δική της άδεια χρήσης ανοικτού κώδικα. Αν κάθε μία από τις άδειες τους είναι "επιτρεπτή" (δίνει στο κοινό την άδεια χρήσης, τροποποίησης και διαμοιρασμού, χωρίς καμία προϋπόθεση για την αδειοδότηση σε μεταγενέστερο στάδιο), μπορείτε να χρησιμοποιήσετε οποιαδήποτε άδεια θέλετε. Οι συνήθεις άδειες με επιτρεπτικό χαρακτήρα περιλαμβάνουν τις MIT, Apache 2.0, ISC και BSD.
 
-On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+Από την άλλη πλευρά, εάν οι άδειες οποιασδήποτε από τις εξαρτήσεις σας είναι "strong copyleft" (δίνει επίσης στο κοινό τα ίδια δικαιώματα, υπό την προϋπόθεση ότι θα χρησιμοποιείτε την ίδια άδεια στα επόμενα στάδια), τότε το πρότζεκτ σας θα πρέπει να χρησιμοποιεί την ίδια άδεια. Οι συνήθεις άδειες με ισχυρό copyleft περιλαμβάνουν τις GPLv2, GPLv3 και AGPLv3.
 
-You may also want to consider the **communities** you hope will use and contribute to your project:
+Μπορεί επίσης να θέλετε να εξετάσετε τις **κοινότητες** που ελπίζετε ότι θα χρησιμοποιήσουν και θα συνεισφέρουν στο πρότζεκτ σας:
 
-* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
-* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
-* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+* **Θέλετε το πρότζεκτ σας να χρησιμοποιηθεί ως εξάρτηση από άλλα πρότζεκτ;** Πιθανώς είναι καλύτερο να χρησιμοποιήσετε την πιο δημοφιλή άδεια χρήσης στη σχετική κοινότητα. Για παράδειγμα, η [MIT](https://choosealicense.com/licenses/mit/) είναι η πιο δημοφιλής άδεια για τις [npm libraries](https://libraries.io/search?platforms=NPM).
+* **Θέλετε το πρότζεκτ σας να απευθύνεται σε μεγάλες επιχειρήσεις;** Μια μεγάλη επιχείρηση θα θέλει πιθανότατα ρητή άδεια χρήσης διπλωμάτων ευρεσιτεχνίας από όλους τους συνεισφέροντες. Σε αυτή την περίπτωση, το [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) σας καλύπτει (και αυτούς).
+* **Θέλετε το πρότζεκτ σας να απευθύνεται σε συνεισφέροντες που δεν επιθυμούν οι συνεισφορές τους να χρησιμοποιηθούν σε λογισμικό κλειστού κώδικα;** Η [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) ή (αν επίσης δεν επιθυμούν να συνεισφέρουν σε υπηρεσίες κλειστού κώδικα) η [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) θα είναι καλή επιλογή.
 
-Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+Η **επιχείρησή σας** μπορεί να έχει συγκεκριμένες απαιτήσεις αδειοδότησης για τα πρότζεκτ ανοικτού κώδικα. Για παράδειγμα, μπορεί να απαιτεί μια επιτρεπτική άδεια ώστε η εταιρεία να μπορεί να χρησιμοποιήσει το πρότζεκτ σας στο προϊόν κλειστού κώδικα της εταιρείας. Ή η εταιρεία σας μπορεί να απαιτεί μια ισχυρή άδεια copyleft και μια πρόσθετη συμφωνία συνεισφοράς (βλ. παρακάτω), έτσι ώστε μόνο η εταιρεία σας, και κανένας άλλος, να μπορεί να χρησιμοποιήσει το πρότζεκτ σας σε λογισμικό κλειστού κώδικα. Ή η εταιρεία σας μπορεί να έχει ορισμένες ανάγκες που σχετίζονται με πρότυπα, κοινωνική ευθύνη ή διαφάνεια, οι οποίες μπορεί να απαιτούν μια συγκεκριμένη στρατηγική αδειοδότησης. Μιλήστε με το νομικό τμήμα της [εταιρείας σας](#what-does-my-companys-legal-team-need-to-know).
 
-When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+Όταν δημιουργείτε ένα νέο πρότζεκτ στο GitHub, σας δίνεται η δυνατότητα να επιλέξετε μια άδεια χρήσης. Η συμπερίληψη μιας από τις άδειες που αναφέρονται παραπάνω θα καταστήσει το πρότζεκτ σας στο GitHub ανοικτού κώδικα. Αν θέλετε να δείτε και άλλες επιλογές, επισκεφθείτε την ιστοσελίδα [choosealicense.com](https://choosealicense.com) για να βρείτε την κατάλληλη άδεια για το πρότζεκτ σας, ακόμη και αν αυτό [δεν είναι λογισμικό](https://choosealicense.com/non-software/).
 
-## What if I want to change the license of my project?
+## Τι γίνεται αν θέλω να αλλάξω την άδεια χρήσης του έργου μου;
 
-Most projects never need to change licenses. But occasionally circumstances change.
+Τα περισσότερα πρότζεκτ δεν χρειάζεται ποτέ να αλλάξουν άδειες χρήσης. Αλλά περιστασιακά οι συνθήκες αλλάζουν.
 
-For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+Για παράδειγμα, καθώς το πρότζεκτ σας μεγαλώνει, προσθέτει εξαρτήσεις ή χρήστες, ή η εταιρεία σας αλλάζει στρατηγικές, κάτι που μπορεί να απαιτεί ή να επιθυμεί διαφορετική άδεια χρήσης. Επίσης, αν αμελήσατε να αδειοδοτήσετε το πρότζεκτ σας από την αρχή, η προσθήκη άδειας είναι ουσιαστικά το ίδιο με την αλλαγή αδειών. Υπάρχουν τρία θεμελιώδη πράγματα που πρέπει να λάβετε υπόψη όταν προσθέτετε ή αλλάζετε την άδεια του έργου σας:
 
-**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+**Είναι περίπλοκο.** Ο προσδιορισμός της συμβατότητας και της συμμόρφωσης με τις άδειες χρήσης και το ποιος κατέχει τα πνευματικά δικαιώματα μπορεί να γίνει πολύπλοκος και συγκεχυμένος πολύ γρήγορα. Η μετάβαση σε μια νέα, αλλά συμβατή άδεια για νέες εκδόσεις και συνεισφορές είναι διαφορετική από την εκ νέου αδειοδότηση όλων των υφιστάμενων συνεισφορών. Εμπλέξτε τη νομική σας ομάδα με την πρώτη ένδειξη οποιασδήποτε επιθυμίας αλλαγής αδειών χρήσης. Ακόμη και αν έχετε ή μπορείτε να λάβετε άδεια από τους κατόχους των πνευματικών δικαιωμάτων του έργου σας για μια αλλαγή άδειας χρήσης, λάβετε υπόψη σας τον αντίκτυπο της αλλαγής στους άλλους χρήστες και συνεισφέροντες του έργου σας. Σκεφτείτε μια αλλαγή άδειας χρήσης ως ένα "γεγονός διακυβέρνησης" για το πρότζεκτ σας, το οποίο είναι πιθανότερο να εξελιχθεί ομαλά με σαφή επικοινωνία και διαβούλευση με τους ενδιαφερόμενους φορείς του έργου σας. Ένας λόγος παραπάνω για να επιλέξετε και να χρησιμοποιήσετε την κατάλληλη άδεια για το πρότζεκτ σας από την αρχή του!
 
-**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+**Η υπάρχουσα άδεια του έργου σας.** Αν η υπάρχουσα άδεια του έργου σας είναι συμβατή με την άδεια στην οποία θέλετε να αλλάξετε, μπορείτε απλά να αρχίσετε να χρησιμοποιείτε τη νέα άδεια. Αυτό συμβαίνει επειδή, αν η άδεια Α είναι συμβατή με την άδεια Β, θα συμμορφώνεστε με τους όρους της Α, ενώ παράλληλα θα συμμορφώνεστε με τους όρους της Β (αλλά όχι απαραίτητα το αντίστροφο). Έτσι, αν χρησιμοποιείτε επί του παρόντος μια επιτρεπτική άδεια (π.χ. MIT), θα μπορούσατε να αλλάξετε σε μια άδεια με περισσότερους όρους, αρκεί να διατηρήσετε ένα αντίγραφο της άδειας MIT και οποιεσδήποτε σχετικές ειδοποιήσεις πνευματικών δικαιωμάτων (δηλαδή, να συνεχίσετε να συμμορφώνεστε με τους ελάχιστους όρους της άδειας MIT). Αλλά αν η τρέχουσα άδειά σας δεν είναι επιτρεπτή (π.χ. copyleft, ή δεν έχετε άδεια) και δεν είστε ο μοναδικός κάτοχος των πνευματικών δικαιωμάτων, δεν θα μπορούσατε απλά να αλλάξετε την άδεια του έργου σας σε MIT. Ουσιαστικά, με μια επιτρεπτική άδεια οι κάτοχοι των πνευματικών δικαιωμάτων του έργου έχουν δώσει εκ των προτέρων την άδεια να αλλάξουν τις άδειες.
 
-**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+**Οι υπάρχοντες κάτοχοι πνευματικών δικαιωμάτων του έργου σας.** Εάν είστε ο μοναδικός συντελεστής του έργου σας, τότε είτε εσείς είτε η εταιρεία σας είστε ο μοναδικός κάτοχος πνευματικών δικαιωμάτων του έργου. Μπορείτε να προσθέσετε ή να αλλάξετε σε όποια άδεια χρήσης θέλετε εσείς ή η εταιρεία σας. Διαφορετικά, μπορεί να υπάρχουν άλλοι κάτοχοι πνευματικών δικαιωμάτων από τους οποίους θα πρέπει να έχετε τη σύμφωνη γνώμη για να αλλάξετε τις άδειες χρήσης. Ποιοι είναι αυτοί; Οι άνθρωποι που έχουν commits στο πρότζεκτ σας είναι ένα καλό μέρος για να ξεκινήσετε. Αλλά σε ορισμένες περιπτώσεις τα πνευματικά δικαιώματα θα κατέχονται από τους εργοδότες αυτών των ανθρώπων. Σε ορισμένες περιπτώσεις οι άνθρωποι θα έχουν κάνει μόνο ελάχιστες συνεισφορές, αλλά δεν υπάρχει κανένας αυστηρός και σταθερός κανόνας ότι συνεισφορές κάτω από κάποιο αριθμό γραμμών κώδικα δεν υπόκεινται σε πνευματικά δικαιώματα. Τι πρέπει να γίνει; Εξαρτάται. Για ένα σχετικά μικρό και νεαρό πρότζεκτ, μπορεί να είναι εφικτό να πείσετε όλους τους υπάρχοντες συνεισφέροντες να συμφωνήσουν σε μια αλλαγή άδειας χρήσης σε ένα θέμα ή σε ένα pull request. Για μεγάλα και μακροχρόνια πρότζεκτ, μπορεί να χρειαστεί να αναζητήσετε πολλούς συνεισφέροντες, ακόμη και τους κληρονόμους τους. Η Mozilla χρειάστηκε πολλά χρόνια (2001-2006) για να ανανεώσει την άδεια χρήσης του Firefox, του Thunderbird και του σχετικού λογισμικού.
 
-Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+Εναλλακτικά, μπορείτε να ζητήσετε από τους συνεισφέροντες να συμφωνήσουν εκ των προτέρων (μέσω μιας πρόσθετης συμφωνίας συνεισφέροντος -- δείτε παρακάτω) σε ορισμένες αλλαγές στην άδεια χρήσης υπό ορισμένες προϋποθέσεις, πέραν αυτών που επιτρέπονται από την υπάρχουσα άδεια χρήσης ανοικτού κώδικα. Αυτό μετατοπίζει λίγο την πολυπλοκότητα της αλλαγής των αδειών χρήσης. Θα χρειαστείτε περισσότερη βοήθεια από τους δικηγόρους σας εκ των προτέρων, και θα εξακολουθείτε να θέλετε να επικοινωνείτε με σαφήνεια με τα ενδιαφερόμενα μέρη του έργου σας όταν εκτελείτε μια αλλαγή άδειας χρήσης.
 
-## 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).
+Μάλλον όχι. Για τη συντριπτική πλειονότητα των πρότζεκτ ανοικτού κώδικα, μια άδεια ανοικτού κώδικα χρησιμεύει σιωπηρά τόσο ως η εισερχόμενη (από τους συνεισφέροντες) όσο και ως η εξερχόμενη (προς άλλους συνεισφέροντες και χρήστες) άδεια. Εάν το πρότζεκτ σας βρίσκεται στο GitHub, οι όροι χρήσης του GitHub καθιστούν το "inbound=outbound" τη [ρητή προεπιλογή](https://help.github.com/en/github/site-policy/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.
+Μια πρόσθετη συμφωνία συνεισφέροντος -- συχνά αποκαλούμενη Συμφωνία άδειας χρήσης συνεισφέροντος (CLA) -- μπορεί να δημιουργήσει διοικητική εργασία για τους συντηρητές του έργου. Το πόση εργασία προσθέτει μια συμφωνία εξαρτάται από το πρότζεκτ και την εφαρμογή. Μια απλή συμφωνία μπορεί να απαιτεί από τους συνεισφέροντες να επιβεβαιώνουν, με ένα κλικ, ότι έχουν τα απαραίτητα δικαιώματα για να συνεισφέρουν σύμφωνα με την άδεια χρήσης ανοικτού κώδικα του έργου. Μια πιο περίπλοκη συμφωνία μπορεί να απαιτεί νομικό έλεγχο και υπογραφή από τους εργοδότες των συνεισφερόντων.
 
-Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
+Επίσης, προσθέτοντας "γραφειοκρατία" που κάποιοι θεωρούν περιττή, δυσνόητη ή άδικη (όταν ο παραλήπτης της συμφωνίας αποκτά περισσότερα δικαιώματα από ό,τι οι συνεισφέροντες ή το κοινό μέσω της άδειας χρήσης ανοικτού κώδικα του έργου), μια πρόσθετη συμφωνία συνεισφοράς μπορεί να θεωρηθεί μη φιλική προς την κοινότητα του έργου.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
-    We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+    Εξαλείψαμε το CLA για το Node.js. Με αυτόν τον τρόπο μειώνουμε το εμπόδιο εισόδου για τους συνεισφέροντες του Node.js, διευρύνοντας έτσι τη βάση των συνεισφερόντων.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+- @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
-Some situations where you may want to consider an additional contributor agreement for your project include:
+Ορισμένες περιπτώσεις στις οποίες μπορεί να θέλετε να εξετάσετε το ενδεχόμενο σύναψης πρόσθετης συμφωνίας συνεισφοράς για το πρότζεκτ σας περιλαμβάνουν:
 
-* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
-* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
-* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
-* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
-* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
+* Οι δικηγόροι σας θέλουν όλοι οι συνεισφέροντες να αποδέχονται ρητά (_υπογράφουν_, online ή offline) τους όρους συνεισφοράς, ίσως επειδή θεωρούν ότι η ίδια η άδεια ανοιχτού κώδικα δεν είναι αρκετή (παρόλο που είναι!). Εάν αυτό είναι το μόνο πρόβλημα, μια συμφωνία συνεισφοράς που επιβεβαιώνει την άδεια χρήσης ανοικτού κώδικα του έργου θα πρέπει να είναι αρκετή. Η [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) είναι ένα καλό παράδειγμα μιας ελαφριάς πρόσθετης συμφωνίας συνεισφοράς.
+* Εσείς ή οι δικηγόροι σας θέλετε οι προγραμματιστές να δηλώνουν ότι κάθε δέσμευση που κάνουν είναι εξουσιοδοτημένη. Η απαίτηση [Πιστοποιητικό προέλευσης προγραμματιστή] (https://developercertificate.org/) είναι ο τρόπος με τον οποίο πολλά πρότζεκτ το επιτυγχάνουν αυτό. Για παράδειγμα, η κοινότητα Node.js [χρησιμοποιεί](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) το DCO [αντί](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) του προηγούμενου CLA. Μια απλή επιλογή για να αυτοματοποιήσετε την επιβολή του DCO στο αποθετήριο σας είναι το [DCO Probot](https://github.com/probot/dco).
+* Το πρότζεκτ σας χρησιμοποιεί μια άδεια χρήσης ανοικτού κώδικα που δεν περιλαμβάνει ρητή παραχώρηση διπλωμάτων ευρεσιτεχνίας (όπως η MIT) και χρειάζεστε παραχώρηση διπλώματος ευρεσιτεχνίας από όλους τους συνεισφέροντες, ορισμένοι από τους οποίους μπορεί να εργάζονται σε εταιρείες με μεγάλα χαρτοφυλάκια διπλωμάτων ευρεσιτεχνίας που θα μπορούσαν να χρησιμοποιηθούν για να στοχεύσουν εσάς ή άλλους συνεισφέροντες και χρήστες του έργου. Η [Apache Individual Contributor License Agreement] (https://www.apache.org/licenses/icla.pdf) είναι μια ευρέως χρησιμοποιούμενη πρόσθετη συμφωνία συνεισφοράς που έχει μια παραχώρηση διπλώματος ευρεσιτεχνίας που αντικατοπτρίζει αυτή που υπάρχει στην Άδεια Apache 2.0.
+* Το πρότζεκτ σας τελεί υπό άδεια copyleft, αλλά πρέπει επίσης να διανείμετε μια ιδιόκτητη έκδοση του έργου. Θα χρειαστείτε κάθε συνεισφέροντα να σας εκχωρήσει τα πνευματικά δικαιώματα ή να σας παραχωρήσει (αλλά όχι στο κοινό) μια επιτρεπτική άδεια. Το [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) είναι ένα παράδειγμα αυτού του τύπου συμφωνίας.
+* Πιστεύετε ότι το πρότζεκτ σας μπορεί να χρειαστεί να αλλάξει άδειες χρήσης κατά τη διάρκεια της ζωής του και θέλετε οι συνεισφέροντες να συμφωνήσουν εκ των προτέρων σε τέτοιες αλλαγές.
 
-If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+Εάν χρειάζεται να χρησιμοποιήσετε μια πρόσθετη συμφωνία συνεισφοράς με το πρότζεκτ σας, εξετάστε το ενδεχόμενο να χρησιμοποιήσετε μια ενσωμάτωση όπως η [CLA assistant](https://github.com/cla-assistant/cla-assistant) για να ελαχιστοποιήσετε την απόσπαση της προσοχής των συνεισφερόντων.
 
-## What does my company's legal team need to know?
+## Τι πρέπει να γνωρίζει η νομική ομάδα της εταιρείας μου;
 
-If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+Εάν κυκλοφορείτε ένα πρότζεκτ ανοικτού κώδικα ως υπάλληλος της εταιρείας, πρώτα απ' όλα, η νομική σας ομάδα θα πρέπει να γνωρίζει ότι χρησιμοποιείτε ένα πρότζεκτ ανοικτού κώδικα.
 
-For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+Καλώς ή κακώς, σκεφτείτε να τους ενημερώσετε, ακόμη και αν πρόκειται για ένα προσωπικό πρότζεκτ. Πιθανόν να έχετε μια "συμφωνία διανοητικής ιδιοκτησίας εργαζομένων" με την εταιρεία σας που τους δίνει κάποιο έλεγχο των πρότζεκτ σας, ειδικά αν αυτά σχετίζονται καθόλου με την επιχειρηματική δραστηριότητα της εταιρείας ή αν χρησιμοποιείτε πόρους της εταιρείας για την ανάπτυξη του έργου. Η εταιρεία σας _θα πρέπει_ να σας δώσει εύκολα την άδεια, και ίσως το έχει ήδη κάνει μέσω μιας φιλικής προς τους εργαζόμενους συμφωνίας πνευματικής ιδιοκτησίας ή μιας εταιρικής πολιτικής. Αν όχι, μπορείτε να διαπραγματευτείτε (για παράδειγμα, να εξηγήσετε ότι το πρότζεκτ σας εξυπηρετεί τους στόχους επαγγελματικής μάθησης και ανάπτυξης της εταιρείας για εσάς) ή να αποφύγετε να εργαστείτε στο πρότζεκτ σας μέχρι να βρείτε μια καλύτερη εταιρεία.
 
-**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+**Αν κάνετε ένα πρότζεκτ ανοιχτού κώδικα για την εταιρεία σας,** τότε σίγουρα ενημερώστε τους. Η νομική σας ομάδα πιθανότατα έχει ήδη πολιτικές για το ποια άδεια ανοικτού κώδικα (και ίσως πρόσθετη συμφωνία συνεισφοράς) θα πρέπει να χρησιμοποιηθεί με βάση τις επιχειρηματικές απαιτήσεις της εταιρείας και την τεχνογνωσία γύρω από τη διασφάλιση της συμμόρφωσης του έργου σας με τις άδειες των εξαρτήσεών του. Εάν όχι, εσείς και αυτοί είστε τυχεροί! Η νομική σας ομάδα θα πρέπει να είναι πρόθυμη να συνεργαστεί μαζί σας για να τα βρείτε αυτά τα πράγματα. Μερικά πράγματα που πρέπει να σκεφτείτε:
 
-* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+* **Υλικό τρίτων:** Έχει το πρότζεκτ σας εξαρτήσεις που δημιουργήθηκαν από άλλους ή περιλαμβάνει ή χρησιμοποιεί κώδικα άλλων; Εάν αυτά είναι ανοιχτού κώδικα, θα πρέπει να συμμορφωθείτε με τις άδειες χρήσης του υλικού ανοιχτού κώδικα. Αυτό ξεκινάει με την επιλογή μιας άδειας που συνεργάζεται με τις άδειες ανοικτού κώδικα τρίτων (βλ. παραπάνω). Εάν το πρότζεκτ σας τροποποιεί ή διανέμει υλικό ανοικτού κώδικα τρίτων, τότε η νομική σας ομάδα θα θέλει επίσης να γνωρίζει ότι πληροίτε άλλους όρους των αδειών ανοικτού κώδικα τρίτων, όπως η διατήρηση των σημειώσεων περί πνευματικών δικαιωμάτων. Εάν το πρότζεκτ σας χρησιμοποιεί κώδικα άλλων που δεν έχει άδεια χρήσης ανοικτού κώδικα, θα πρέπει πιθανώς να ζητήσετε από τους συντηρητές του τρίτου μέρους να [προσθέσουν μια άδεια χρήσης ανοικτού κώδικα](https://choosealicense.com/no-license/#for-users), και εάν δεν μπορείτε να πάρετε μια τέτοια άδεια, να σταματήσετε να χρησιμοποιείτε τον κώδικά τους στο πρότζεκτ σας.
 
-* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+* **Εμπορικά μυστικά:** Εξετάστε αν υπάρχει κάτι στο πρότζεκτ που η εταιρεία δεν θέλει να διαθέσει στο ευρύ κοινό. Αν ναι, θα μπορούσατε να ανοίξετε τον κώδικα του υπόλοιπου έργου σας, αφού εξάγετε το υλικό που θέλετε να κρατήσετε ιδιωτικό.
 
-* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
+* **Διπλώματα ευρεσιτεχνίας:** Υποβάλλει η εταιρεία σας αίτηση για δίπλωμα ευρεσιτεχνίας του οποίου η ανοικτή διάθεση του έργου σας θα αποτελούσε [δημόσια αποκάλυψη](https://en.wikipedia.org/wiki/Public_disclosure); Δυστυχώς, μπορεί να σας ζητηθεί να περιμένετε (ή ίσως η εταιρεία να επανεξετάσει τη σοφία της αίτησης). Αν περιμένετε συνεισφορές στο πρότζεκτ σας από υπαλλήλους εταιρειών με μεγάλα χαρτοφυλάκια διπλωμάτων ευρεσιτεχνίας, η νομική σας ομάδα μπορεί να θέλει να χρησιμοποιήσετε μια άδεια με ρητή παραχώρηση διπλωμάτων ευρεσιτεχνίας από τους συνεισφέροντες (όπως η Apache 2.0 ή η GPLv3), ή μια πρόσθετη συμφωνία συνεισφοράς (βλ. παραπάνω).
 
-* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+* **Εμπορικά σήματα:** Ελέγξτε δύο φορές ότι το όνομα του έργου σας [δεν συγκρούεται με τυχόν υπάρχοντα εμπορικά σήματα](../starting-a-project/#avoiding-name-conflicts). Εάν χρησιμοποιείτε τα εμπορικά σήματα της εταιρείας σας στο πρότζεκτ, ελέγξτε ότι δεν προκαλούνται συγκρούσεις. Το [FOSSmarks](http://fossmarks.org/) είναι ένας πρακτικός οδηγός για την κατανόηση των εμπορικών σημάτων στο πλαίσιο των πρότζεκτ ελεύθερου και ανοικτού κώδικα.
 
-* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+* **Απόρρητο:** Το πρότζεκτ σας συλλέγει δεδομένα για τους χρήστες; "Τηλεφωνεί στο σπίτι" σε διακομιστές της εταιρείας; Η νομική σας ομάδα μπορεί να σας βοηθήσει να συμμορφωθείτε με τις εταιρικές πολιτικές και τους εξωτερικούς κανονισμούς.
 
-If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+Αν πρόκειται να κυκλοφορήσετε το πρώτο πρότζεκτ ανοικτού κώδικα της εταιρείας σας, τα παραπάνω είναι υπεραρκετά για να τα ξεπεράσετε (αλλά μην ανησυχείτε, τα περισσότερα πρότζεκτ δεν θα πρέπει να εγείρουν σημαντικές ανησυχίες).
 
-Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+Μακροπρόθεσμα, η νομική σας ομάδα μπορεί να κάνει περισσότερα για να βοηθήσει την εταιρεία να αποκομίσει περισσότερα από τη συμμετοχή της στον ανοικτό κώδικα και να παραμείνει ασφαλής:
 
-* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Πολιτικές συνεισφοράς των υπαλλήλων:** Εξετάστε το ενδεχόμενο να αναπτύξετε μια εταιρική πολιτική που να καθορίζει τον τρόπο με τον οποίο οι υπάλληλοί σας συνεισφέρουν σε πρότζεκτ ανοικτού κώδικα. Μια σαφής πολιτική θα μειώσει τη σύγχυση μεταξύ των υπαλλήλων σας και θα τους βοηθήσει να συνεισφέρουν σε πρότζεκτ ανοικτού κώδικα προς το συμφέρον της εταιρείας, είτε ως μέρος της εργασίας τους είτε στον ελεύθερο χρόνο τους. Ένα καλό παράδειγμα είναι η [Πρότυπη πολιτική IP και συνεισφοράς σε ανοικτό κώδικα](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) της Rackspace.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
-  Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+  Η εκμίσθωση της IP που σχετίζεται με μια επιδιόρθωση δημιουργεί τη βάση γνώσεων και τη φήμη του υπαλλήλου. Δείχνει ότι η εταιρεία επενδύει στην ανάπτυξη του συγκεκριμένου εργαζομένου και δημιουργεί μια αίσθηση ενδυνάμωσης και αυτονομίας. Όλα αυτά τα οφέλη οδηγούν επίσης σε υψηλότερο ηθικό και καλύτερη διατήρηση των εργαζομένων.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+- @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
-* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
-* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+* **Τι να δημοσιεύσετε:** [(Σχεδόν) τα πάντα;](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Εάν η νομική σας ομάδα κατανοεί και έχει επενδύσει στη στρατηγική ανοικτού κώδικα της εταιρείας σας, θα είναι σε θέση να βοηθήσει καλύτερα παρά να εμποδίσει τις προσπάθειές σας.
+* **Συμμόρφωση:** Ακόμα και αν η εταιρεία σας δεν εκδίδει πρότζεκτ ανοικτού κώδικα, χρησιμοποιεί λογισμικό ανοικτού κώδικα άλλων. Η [Ενημέρωση και διαδικασία](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) μπορεί να αποτρέψει πονοκεφάλους, καθυστερήσεις προϊόντων και αγωγές.
 
 <aside markdown="1" class="pquote">
-  Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+  Οι οργανισμοί πρέπει να διαθέτουν μια στρατηγική αδειοδότησης και συμμόρφωσης που να ταιριάζει και στις δύο κατηγορίες \["επιτρεπτή" και "copyleft"\]. Αυτό ξεκινά με την τήρηση αρχείου των όρων αδειοδότησης που ισχύουν για το λογισμικό ανοικτού κώδικα που χρησιμοποιείτε - συμπεριλαμβανομένων των υποσυνιστωσών και των εξαρτήσεων.
   <p markdown="1" class="pquote-credit">
-— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+- Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
   </p>
 </aside>
 
-* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
-* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
+* **Διπλώματα ευρεσιτεχνίας:** Η εταιρεία σας μπορεί να επιθυμεί να ενταχθεί στο [Open Invention Network](https://www.openinventionnetwork.com/), μια κοινή αμυντική δεξαμενή διπλωμάτων ευρεσιτεχνίας για την προστασία της χρήσης μεγάλων πρότζεκτ ανοικτού κώδικα από τα μέλη, ή να διερευνήσει άλλες [εναλλακτικές αδειοδοτήσεις διπλωμάτων ευρεσιτεχνίας](https://www.eff.org/document/hacking-patent-system-2016).
+* **Διακυβέρνηση:** Ειδικά εάν και εφόσον έχει νόημα να μεταφερθεί ένα πρότζεκτ σε μια [νομική οντότητα εκτός της εταιρείας](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).

From 9f7617ef9c9cce856a445c5760099eb1ed1c4ebe Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 20 Sep 2022 11:51:46 +0300
Subject: [PATCH 397/749] Translate starting-a-project.md

---
 _articles/el/starting-a-project.md | 270 ++++++++++++++---------------
 1 file changed, 135 insertions(+), 135 deletions(-)

diff --git a/_articles/el/starting-a-project.md b/_articles/el/starting-a-project.md
index 1112dec18ed..8af7812bf76 100644
--- a/_articles/el/starting-a-project.md
+++ b/_articles/el/starting-a-project.md
@@ -10,347 +10,347 @@ related:
   - building
 ---
 
-## The "what" and "why" of open source
+## Το "τι" και το "γιατί" του ανοικτού κώδικα
 
-So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+Σκέφτεστε λοιπόν να ξεκινήσετε με τον ανοιχτό κώδικα; Συγχαρητήρια! Ο κόσμος εκτιμά τη συνεισφορά σας. Ας μιλήσουμε για το τι είναι ο ανοιχτός κώδικας και γιατί οι άνθρωποι το κάνουν.
 
-### What does "open source" mean?
+### Τι σημαίνει "ανοιχτός κώδικας";
 
-When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+Όταν ένα πρότζεκτ είναι ανοικτού κώδικα, αυτό σημαίνει ότι **ο καθένας είναι ελεύθερος να χρησιμοποιήσει, να μελετήσει, να τροποποιήσει και να διανείμει το πρότζεκτ σας για οποιονδήποτε σκοπό.** Αυτά τα δικαιώματα επιβάλλονται μέσω [μιας άδειας ανοικτού κώδικα](https://opensource.org/licenses).
 
-Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+Ο ανοικτός κώδικας είναι ισχυρός επειδή μειώνει τα εμπόδια στην υιοθέτηση και τη συνεργασία, επιτρέποντας στους ανθρώπους να διαδίδουν και να βελτιώνουν πρότζεκτ γρήγορα. Επίσης, επειδή δίνει στους χρήστες τη δυνατότητα να ελέγχουν τους υπολογιστές τους, σε σχέση με τον κλειστό κώδικα. Για παράδειγμα, μια επιχείρηση που χρησιμοποιεί λογισμικό ανοικτού κώδικα έχει τη δυνατότητα να προσλάβει κάποιον για να κάνει προσαρμοσμένες βελτιώσεις στο λογισμικό, αντί να βασίζεται αποκλειστικά στις αποφάσεις ενός προμηθευτή κλειστού κώδικα για το προϊόν.
 
-_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+Το _ελεύθερο λογισμικό_ αναφέρεται στο ίδιο σύνολο πρότζεκτ με το _ανοικτού κώδικα_. Μερικές φορές θα δείτε επίσης [αυτούς τους όρους](https://en.wikipedia.org/wiki/Free_and_open-source_software) συνδυασμένους ως "ελεύθερο λογισμικό και λογισμικό ανοικτού κώδικα" (FOSS) ή "ελεύθερο, ελεύθερο και λογισμικό ανοικτού κώδικα" (FLOSS). Τα _Free_ και _libre_ αναφέρονται στην ελευθερία, [όχι στην τιμή](#does-open-source-mean-free-of-charge).
 
-### Why do people open source their work?
+### Γιατί οι άνθρωποι ανοίγουν το λογισμικό τους;
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
-  One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+  Μια από τις πιο ικανοποιητικές εμπειρίες που αποκομίζω από τη χρήση και τη συνεργασία σε θέματα ανοικτού κώδικα προέρχεται από τις σχέσεις που χτίζω με άλλους προγραμματιστές που αντιμετωπίζουν πολλά από τα ίδια προβλήματα με εμένα.
   <p markdown="1" class="pquote-credit">
-— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+- @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
   </p>
 </aside>
 
-[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+[Υπάρχουν πολλοί λόγοι](https://ben.balter.com/2015/11/23/why-open-source/) για τους οποίους ένα άτομο ή ένας οργανισμός θα ήθελε να ανοίξει τον κώδικα ενός έργου. Μερικά παραδείγματα περιλαμβάνουν:
 
-* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+* **Συνεργασία:** Τα πρότζεκτ ανοικτού κώδικα μπορούν να δέχονται αλλαγές από οποιονδήποτε στον κόσμο. Το [Exercism](https://github.com/exercism/), για παράδειγμα, είναι μια πλατφόρμα ασκήσεων προγραμματισμού με πάνω από 350 συνεισφέροντες.
 
-* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **Υιοθέτηση και επανασύνθεση:** Τα πρότζεκτ ανοικτού κώδικα μπορούν να χρησιμοποιηθούν από οποιονδήποτε για σχεδόν οποιονδήποτε σκοπό. Οι άνθρωποι μπορούν ακόμη και να τα χρησιμοποιήσουν για να κατασκευάσουν άλλα πράγματα. Το [WordPress](https://github.com/WordPress), για παράδειγμα, ξεκίνησε ως διακλάδωση ενός υπάρχοντος έργου που ονομαζόταν [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+* **Διαφάνεια:** Οποιοσδήποτε μπορεί να επιθεωρήσει ένα πρότζεκτ ανοικτού κώδικα για λάθη ή ασυνέπειες. Η διαφάνεια έχει σημασία για κυβερνήσεις όπως η [Βουλγαρία](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ή οι [Ηνωμένες Πολιτείες](https://sourcecode.cio.gov/), ρυθμιζόμενες βιομηχανίες όπως οι τράπεζες ή η υγειονομική περίθαλψη και λογισμικό ασφαλείας όπως το [Let's Encrypt](https://github.com/letsencrypt).
 
-Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+Ο ανοικτός κώδικας δεν είναι μόνο για το λογισμικό. Μπορείτε να ανοίξετε τα πάντα, από σύνολα δεδομένων μέχρι βιβλία. Ελέγξτε το [GitHub Explore](https://github.com/explore) για ιδέες σχετικά με το τι άλλο μπορείτε να ανοίξετε με ανοικτό κώδικα.
 
-### Does open source mean "free of charge"?
+### Ανοιχτός κώδικας σημαίνει "δωρεάν";
 
-One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+Ένα από τα μεγαλύτερα πλεονεκτήματα του ανοικτού κώδικα είναι ότι δεν κοστίζει χρήματα. Το "δωρεάν", ωστόσο, είναι ένα υποπροϊόν της συνολικής αξίας του ανοικτού κώδικα.
 
-Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+Επειδή [μια άδεια χρήσης ανοικτού κώδικα απαιτεί](https://opensource.org/osd-annotated) ότι ο καθένας μπορεί να χρησιμοποιήσει, να τροποποιήσει και να μοιραστεί το πρότζεκτ σας για σχεδόν οποιονδήποτε σκοπό, τα ίδια τα πρότζεκτ τείνουν να είναι δωρεάν. Αν το πρότζεκτ κόστιζε χρήματα για τη χρήση του, ο καθένας θα μπορούσε νόμιμα να δημιουργήσει ένα αντίγραφο και να χρησιμοποιήσει τη δωρεάν έκδοση αντί αυτού.
 
-As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+Ως αποτέλεσμα, τα περισσότερα πρότζεκτ ανοικτού κώδικα είναι δωρεάν, αλλά το "δωρεάν" δεν αποτελεί μέρος του ορισμού του ανοικτού κώδικα. Υπάρχουν τρόποι να χρεώνετε τα πρότζεκτ ανοικτού κώδικα έμμεσα μέσω διπλής αδειοδότησης ή περιορισμένων χαρακτηριστικών, ενώ παράλληλα εξακολουθούν να συμμορφώνονται με τον επίσημο ορισμό του ανοικτού κώδικα.
 
-## Should I launch my own open source project?
+## Πρέπει να ξεκινήσω το δικό μου πρότζεκτ ανοιχτού κώδικα;
 
-The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+Η σύντομη απάντηση είναι ναι, διότι, ανεξάρτητα από το αποτέλεσμα, το να ξεκινήσετε το δικό σας πρότζεκτ είναι ένας πολύ καλός τρόπος για να μάθετε πώς λειτουργεί ο ανοιχτός κώδικας.
 
-If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+Αν δεν έχετε ποτέ στο παρελθόν ανοίξει ένα πρότζεκτ, μπορεί να έχετε άγχος για το τι θα πει ο κόσμος ή αν θα το προσέξει κανείς. Αν αυτό σας μοιάζει, δεν είστε οι μόνοι!
 
-Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+Η εργασία ανοιχτού κώδικα είναι όπως κάθε άλλη δημιουργική δραστηριότητα, είτε πρόκειται για συγγραφή είτε για ζωγραφική. Μπορεί να αισθάνεστε τρομακτικό να μοιράζεστε τη δουλειά σας με τον κόσμο, αλλά ο μόνος τρόπος για να βελτιωθείτε είναι να εξασκηθείτε - ακόμη και αν δεν έχετε κοινό.
 
-If you're not yet convinced, take a moment to think about what your goals might be.
+Αν δεν έχετε πειστεί ακόμα, σκεφτείτε για λίγο ποιοι μπορεί να είναι οι στόχοι σας.
 
-### Setting your goals
+### Θέτοντας τους στόχους σας
 
-Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself,  _why am I open sourcing this project?_
+Οι στόχοι μπορούν να σας βοηθήσουν να καταλάβετε τι πρέπει να δουλέψετε, σε τι να πείτε όχι και πού χρειάζεστε βοήθεια από άλλους. Ξεκινήστε ρωτώντας τον εαυτό σας, _γιατί κάνω open sourcing αυτό το πρότζεκτ;_
 
-There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+Δεν υπάρχει μια σωστή απάντηση σε αυτό το ερώτημα. Μπορεί να έχετε πολλαπλούς στόχους για ένα πρότζεκτ ή διαφορετικά πρότζεκτ με διαφορετικούς στόχους.
 
-If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+Αν ο μόνος σας στόχος είναι να επιδείξετε τη δουλειά σας, μπορεί να μην θέλετε καν συνεισφορές, και μάλιστα να το πείτε αυτό στο README σας. Από την άλλη πλευρά, αν θέλετε συνεισφέροντες, θα επενδύσετε χρόνο σε σαφή τεκμηρίωση και θα κάνετε τους νεοεισερχόμενους να αισθάνονται ευπρόσδεκτοι.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
-  At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+  Κάποια στιγμή δημιούργησα ένα προσαρμοσμένο UIAlertView που χρησιμοποιούσα... και αποφάσισα να το κάνω open source. Έτσι το τροποποίησα για να είναι πιο δυναμικό και το ανέβασα στο GitHub. Έγραψα επίσης την πρώτη μου τεκμηρίωση εξηγώντας σε άλλους προγραμματιστές πώς να το χρησιμοποιήσουν στα πρότζεκτ τους. Πιθανότατα κανείς δεν το χρησιμοποίησε ποτέ επειδή ήταν ένα απλό πρότζεκτ, αλλά ένιωθα καλά για τη συνεισφορά μου.
   <p markdown="1" class="pquote-credit">
-— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+- @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
   </p>
 </aside>
 
-As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+Καθώς το πρότζεκτ σας αναπτύσσεται, η κοινότητά σας μπορεί να χρειάζεται κάτι περισσότερο από τον κώδικα που θα σας παρέχει. Η ανταπόκριση σε ζητήματα, η αναθεώρηση κώδικα και η προώθηση του έργου σας είναι όλα σημαντικά καθήκοντα σε ένα πρότζεκτ ανοικτού κώδικα.
 
-While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+Αν και ο χρόνος που αφιερώνετε σε εργασίες που δεν σχετίζονται με τον προγραμματισμό εξαρτάται από το μέγεθος και το πεδίο εφαρμογής του έργου σας, θα πρέπει να είστε προετοιμασμένοι ως συντηρητής να τις αντιμετωπίσετε μόνοι σας ή να βρείτε κάποιον να σας βοηθήσει.
 
-**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+**Αν ανήκετε σε μια εταιρεία με ανοικτό sourcing ενός έργου,** βεβαιωθείτε ότι το πρότζεκτ σας διαθέτει τους εσωτερικούς πόρους που χρειάζεται για να ευδοκιμήσει. Θα πρέπει να προσδιορίσετε ποιος είναι υπεύθυνος για τη συντήρηση του έργου μετά την έναρξη και πώς θα μοιραστείτε αυτά τα καθήκοντα με την κοινότητά σας.
 
-If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+Αν χρειάζεστε ειδικό προϋπολογισμό ή προσωπικό για την προώθηση, τις λειτουργίες και τη συντήρηση του έργου, ξεκινήστε τις συζητήσεις αυτές από νωρίς.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-  As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+  Καθώς αρχίζετε να ανοίγετε το πρότζεκτ, είναι σημαντικό να βεβαιωθείτε ότι οι διαδικασίες διαχείρισης λαμβάνουν υπόψη τις συνεισφορές και τις ικανότητες της κοινότητας γύρω από το πρότζεκτ σας. Μη φοβάστε να εμπλέξετε συνεισφέροντες που δεν απασχολούνται στην επιχείρησή σας σε βασικές πτυχές του έργου - ειδικά αν είναι συχνοί συνεισφέροντες.
   <p markdown="1" class="pquote-credit">
-— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+- @captainsafia, ["Ώστε θέλεις να ανοίξεις ένα πρότζεκτ με ανοιχτό κώδικα, ε;"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
   </p>
 </aside>
 
-### Contributing to other projects
+### Συμβολή σε άλλα πρότζεκτ
 
-If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+Αν ο στόχος σας είναι να μάθετε πώς να συνεργάζεστε με άλλους ή να κατανοήσετε πώς λειτουργεί ο ανοιχτός κώδικας, σκεφτείτε να συνεισφέρετε σε ένα υπάρχον πρότζεκτ. Ξεκινήστε με ένα πρότζεκτ που ήδη χρησιμοποιείτε και αγαπάτε. Η συνεισφορά σε ένα πρότζεκτ μπορεί να είναι τόσο απλή όσο η διόρθωση τυπογραφικών λαθών ή η ενημέρωση της τεκμηρίωσης.
 
-If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+Αν δεν είστε σίγουροι για το πώς να ξεκινήσετε να συνεισφέρετε, ανατρέξτε στον οδηγό μας [Πώς να συνεισφέρετε στον Ανοιχτό Κώδικα](../how-to-contribute/).
 
-## Launching your own open source project
+## Ξεκινώντας το δικό σας πρότζεκτ ανοιχτού κώδικα
 
-There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+Δεν υπάρχει ιδανική στιγμή για να ανοίξετε το πρότζεκτ σας. Μπορείτε να ανοίξετε τον κώδικα μιας ιδέας, μιας εργασίας σε εξέλιξη ή μετά από χρόνια κλειστού κώδικα.
 
-Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+Σε γενικές γραμμές, θα πρέπει να ανοίγετε το πρότζεκτ σας όταν αισθάνεστε άνετα να αφήσετε άλλους να δουν και να δώσουν ανατροφοδότηση σχετικά με το πρότζεκτ σας.
 
-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)
+* [Άδεια χρήσης ανοικτού κώδικα](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)
 * [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change)
-* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
-* [Code of conduct](../code-of-conduct/)
+* [Κατευθυντήριες γραμμές για τη συμβολή](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Κώδικας δεοντολογίας](../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.
+Ως συντηρητής, αυτά τα στοιχεία θα σας βοηθήσουν να επικοινωνήσετε τις προσδοκίες, να διαχειριστείτε τις συνεισφορές και να προστατεύσετε τα νομικά δικαιώματα όλων (συμπεριλαμβανομένων των δικών σας). Αυξάνουν σημαντικά τις πιθανότητές σας να έχετε μια θετική εμπειρία.
 
-If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+Εάν το πρότζεκτ σας βρίσκεται στο GitHub, η τοποθέτηση αυτών των αρχείων στον ριζικό σας κατάλογο με τα συνιστώμενα ονόματα αρχείων θα βοηθήσει το GitHub να τα αναγνωρίσει και να τα εμφανίσει αυτόματα στους αναγνώστες σας.
 
-### Choosing a license
+### Επιλέγοντας μια άδεια
 
-An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+Μια άδεια ανοικτού κώδικα εγγυάται ότι άλλοι μπορούν να χρησιμοποιούν, να αντιγράφουν, να τροποποιούν και να συνεισφέρουν στο πρότζεκτ σας χωρίς επιπτώσεις. Σας προστατεύει επίσης από δύσκολες νομικές καταστάσεις. **Πρέπει να συμπεριλάβετε μια άδεια χρήσης όταν ξεκινάτε ένα πρότζεκτ ανοικτού κώδικα**.
 
-Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+Η νομική εργασία δεν είναι διασκεδαστική. Τα καλά νέα είναι ότι μπορείτε να αντιγράψετε και να επικολλήσετε μια υπάρχουσα άδεια χρήσης στο αποθετήριό σας. Θα χρειαστεί μόνο ένα λεπτό για να προστατέψετε τη σκληρή δουλειά σας.
 
-[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 the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+Οι [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) και [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) είναι οι πιο δημοφιλείς άδειες ανοικτού κώδικα, αλλά [υπάρχουν και άλλες επιλογές](https://choosealicense.com) για να επιλέξετε.
 
-When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+Όταν δημιουργείτε ένα νέο πρότζεκτ στο GitHub, σας δίνεται η δυνατότητα να επιλέξετε μια άδεια χρήσης. Η συμπερίληψη μιας άδειας ανοικτού κώδικα θα καταστήσει το πρότζεκτ σας στο GitHub ανοικτού κώδικα.
 
-![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+![Διαλέξτε μια άδεια](/assets/images/starting-a-project/repository-license-picker.png)
 
-If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+Αν έχετε άλλες ερωτήσεις ή ανησυχίες σχετικά με τις νομικές πτυχές της διαχείρισης ενός έργου ανοικτού κώδικα, [σας καλύπτουμε](../legal/).
 
-### Writing a README
+### Γράφοντας ένα README
 
-READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+Τα READMEs κάνουν περισσότερα από το να εξηγούν πώς να χρησιμοποιήσετε το πρότζεκτ σας. Εξηγούν επίσης γιατί το πρότζεκτ σας έχει σημασία και τι μπορούν να κάνουν οι χρήστες σας με αυτό.
 
-In your README, try to answer the following questions:
+Στο README σας, προσπαθήστε να απαντήσετε στις ακόλουθες ερωτήσεις:
 
-* What does this project do?
-* Why is this project useful?
-* How do I get started?
-* Where can I get more help, if I need it?
+* Τι κάνει αυτό το πρότζεκτ;
+* Γιατί είναι χρήσιμο αυτό το πρότζεκτ;
+* Πώς μπορώ να ξεκινήσω;
+* Πού μπορώ να βρω περισσότερη βοήθεια, αν τη χρειαστώ;
 
-You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+Μπορείτε να χρησιμοποιήσετε το README για να απαντήσετε σε άλλες ερωτήσεις, όπως πώς χειρίζεστε τις συνεισφορές, ποιοι είναι οι στόχοι του έργου και πληροφορίες σχετικά με τις άδειες χρήσης και την απόδοση. Αν δεν θέλετε να δέχεστε συνεισφορές ή αν το πρότζεκτ σας δεν είναι ακόμα έτοιμο για παραγωγή, γράψτε αυτές τις πληροφορίες.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
-  Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+  Καλύτερη τεκμηρίωση σημαίνει περισσότερους χρήστες, λιγότερα αιτήματα υποστήριξης και περισσότερους συνεργάτες. (...) Να θυμάστε ότι οι αναγνώστες σας δεν είναι εσείς. Υπάρχουν άνθρωποι που μπορεί να έρθουν σε ένα πρότζεκτ που έχουν εντελώς διαφορετικές εμπειρίες.
   <p markdown="1" class="pquote-credit">
-— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+- @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
   </p>
 </aside>
 
-Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+Μερικές φορές, οι άνθρωποι αποφεύγουν να γράψουν ένα README επειδή αισθάνονται ότι το πρότζεκτ είναι ημιτελές ή δεν θέλουν συνεισφορές. Όλοι αυτοί είναι πολύ καλοί λόγοι για να γράψετε ένα τέτοιο κείμενο.
 
-For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+Για περισσότερη έμπνευση, δοκιμάστε να χρησιμοποιήσετε τον ["Make a README" guide](https://www.makeareadme.com/) του @dguo ή το [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) του @PurpleBooth για να γράψετε ένα πλήρες README.
 
-When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+Όταν συμπεριλαμβάνετε ένα αρχείο README στον ριζικό κατάλογο, το GitHub θα το εμφανίσει αυτόματα στην αρχική σελίδα του αποθετηρίου.
 
-### Writing your contributing guidelines
+### Γράφοντας τις κατευθυντήριες γραμμές συνεισφοράς σας
 
-A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+Ένα αρχείο CONTRIBUTING λέει στο κοινό σας πώς να συμμετάσχει στο πρότζεκτ σας. Για παράδειγμα, θα μπορούσατε να συμπεριλάβετε πληροφορίες σχετικά με:
 
-* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
-* How to suggest a new feature
-* How to set up your environment and run tests
+* Πώς να καταθέσετε μια αναφορά σφάλματος (δοκιμάστε να χρησιμοποιήσετε τα [πρότυπα issue και pull request](https://github.com/blog/2111-issue-and-pull-request-templates))
+* Πώς να προτείνετε ένα νέο χαρακτηριστικό
+* Πώς να ρυθμίσετε το περιβάλλον σας και να εκτελέσετε δοκιμές
 
-In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+Εκτός από τις τεχνικές λεπτομέρειες, ένα αρχείο ΣΥΜΒΟΛΗΣ είναι μια ευκαιρία να επικοινωνήσετε τις προσδοκίες σας για τις συνεισφορές, όπως:
 
-* The types of contributions you're looking for
-* Your roadmap or vision for the project
-* How contributors should (or should not) get in touch with you
+* Τα είδη των συνεισφορών που αναζητάτε
+* Ο οδικός χάρτης ή το όραμά σας για το πρότζεκτ
+* Πώς οι συνεργάτες θα πρέπει (ή δεν θα πρέπει) να έρθουν σε επαφή μαζί σας
 
-Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+Χρησιμοποιώντας ένα ζεστό, φιλικό τόνο και προσφέροντας συγκεκριμένες προτάσεις για συνεισφορές (όπως η συγγραφή τεκμηρίωσης ή η δημιουργία ενός ιστότοπου) μπορείτε να κάνετε τους νεοεισερχόμενους να αισθάνονται ευπρόσδεκτοι και ενθουσιασμένοι να συμμετάσχουν.
 
-For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+Για παράδειγμα, το [Active Admin](https://github.com/activeadmin/activeadmin/) ξεκινά [τον οδηγό συνεισφοράς του](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) με:
 
-> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+> Πρώτα απ' όλα, σας ευχαριστώ που σκέφτεστε να συνεισφέρετε στο Active Admin. Είναι άνθρωποι σαν εσάς που κάνουν το Active Admin ένα τόσο σπουδαίο εργαλείο.
 
-In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+Στα πρώτα στάδια του έργου σας, το αρχείο CONTRIBUTING μπορεί να είναι απλό. Θα πρέπει πάντα να εξηγείτε πώς να αναφέρετε σφάλματα ή θέματα αρχείων, καθώς και τυχόν τεχνικές απαιτήσεις (όπως δοκιμές) για να κάνετε μια συνεισφορά.
 
-Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+Με την πάροδο του χρόνου, μπορεί να προσθέσετε και άλλες συχνές ερωτήσεις στο αρχείο ΣΥΝΔΡΟΜΗ. Η καταγραφή αυτών των πληροφοριών σημαίνει ότι λιγότεροι άνθρωποι θα σας κάνουν τις ίδιες ερωτήσεις ξανά και ξανά.
 
-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/).
+Για περισσότερη βοήθεια σχετικά με τη σύνταξη του αρχείου 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.
 
-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.
+Συνδέστε το αρχείο CONTRIBUTING από το README, ώστε να το βλέπουν περισσότεροι άνθρωποι. Εάν [τοποθετήσετε το αρχείο CONTRIBUTING στο αποθετήριο του έργου σας](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), το GitHub θα συνδέει αυτόματα το αρχείο σας όταν ένας συνεργάτης δημιουργεί ένα ζήτημα ή ανοίγει ένα αίτημα έλξης.
 
-![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+![Οδηγίες συνεισφοράς](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
-### Establishing a code of conduct
+### Καθιέρωση κώδικα δεοντολογίας
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
-  We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+  Όλοι έχουμε βιώσει εμπειρίες όπου αντιμετωπίσαμε κάτι που πιθανώς ήταν κατάχρηση, είτε ως συντηρητής που προσπαθούσε να εξηγήσει γιατί κάτι έπρεπε να γίνει με έναν συγκεκριμένο τρόπο, είτε ως χρήστης... που έκανε μια απλή ερώτηση. (...) Ένας κώδικας δεοντολογίας γίνεται ένα έγγραφο στο οποίο γίνεται εύκολα αναφορά και το οποίο μπορεί να συνδεθεί και το οποίο δείχνει ότι η ομάδα σας παίρνει τον εποικοδομητικό διάλογο πολύ σοβαρά.
   <p markdown="1" class="pquote-credit">
-— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+- @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
   </p>
 </aside>
 
-Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+Τέλος, ένας κώδικας δεοντολογίας βοηθά στον καθορισμό βασικών κανόνων συμπεριφοράς για τους συμμετέχοντες στο πρότζεκτ σας. Αυτό είναι ιδιαίτερα πολύτιμο αν ξεκινάτε ένα πρότζεκτ ανοικτού κώδικα για μια κοινότητα ή μια εταιρεία. Ένας κώδικας δεοντολογίας σας δίνει τη δυνατότητα να διευκολύνετε την υγιή, εποικοδομητική συμπεριφορά της κοινότητας, γεγονός που θα μειώσει το άγχος σας ως συντηρητής.
 
-For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+Για περισσότερες πληροφορίες, ανατρέξτε στον οδηγό [Κώδικας δεοντολογίας](../code-of-conduct/).
 
-In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+Εκτός από το να γνωστοποιεί _πώς_ περιμένετε από τους συμμετέχοντες να συμπεριφέρονται, ένας κώδικας συμπεριφοράς τείνει επίσης να περιγράφει ποιους αφορούν αυτές οι προσδοκίες, πότε ισχύουν και τι πρέπει να γίνει σε περίπτωση παραβίασης.
 
-Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+Όπως οι άδειες ανοικτού κώδικα, έτσι και για τους κώδικες δεοντολογίας υπάρχουν αναδυόμενα πρότυπα, ώστε να μην χρειάζεται να γράψετε τους δικούς σας. Το [Contributor Covenant](https://contributor-covenant.org/) είναι ένας drop-in κώδικας συμπεριφοράς που χρησιμοποιείται από [πάνω από 40.000 πρότζεκτ ανοικτού κώδικα](https://www.contributor-covenant.org/adopters), συμπεριλαμβανομένων των Kubernetes, Rails και Swift. Ανεξάρτητα από το κείμενο που χρησιμοποιείτε, θα πρέπει να είστε προετοιμασμένοι να επιβάλλετε τον κώδικα συμπεριφοράς σας όταν είναι απαραίτητο.
 
-Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+Επικολλήστε το κείμενο απευθείας σε ένα αρχείο CODE_OF_CONDUCT στο αποθετήριό σας. Κρατήστε το αρχείο στο ριζικό κατάλογο του έργου σας, ώστε να είναι εύκολο να το βρείτε, και παραπέμψτε σε αυτό από το README σας.
 
-## Naming and branding your project
+## Ονομασία και branding του έργου σας
 
-Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+Το branding είναι κάτι περισσότερο από ένα φανταχτερό λογότυπο ή ένα πιασάρικο όνομα έργου. Έχει να κάνει με το πώς μιλάτε για το πρότζεκτ σας και σε ποιον απευθύνεστε με το μήνυμά σας.
 
-### Choosing the right name
+### Επιλέγοντας το σωστό όνομα
 
-Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+Διαλέξτε ένα όνομα που να είναι εύκολο να το θυμάστε και, ιδανικά, να δίνει μια ιδέα για το τι κάνει το πρότζεκτ. Για παράδειγμα:
 
-* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
-* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+* [Sentry](https://github.com/getsentry/sentry) παρακολουθεί τις εφαρμογές για αναφορά ατυχημάτων
+* [Thin](https://github.com/macournoyer/thin) είναι ένας γρήγορος και απλός διακομιστής ιστοσελίδων Ruby
 
-If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+Αν βασίζεστε σε ένα υπάρχον πρότζεκτ, η χρήση του ονόματός του ως πρόθεμα μπορεί να βοηθήσει να αποσαφηνιστεί τι κάνει το πρότζεκτ σας (για παράδειγμα, το [node-fetch](https://github.com/bitinn/node-fetch) φέρνει το `window.fetch` στο Node.js).
 
-Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+Σκεφτείτε πάνω απ' όλα τη σαφήνεια. Τα λογοπαίγνια είναι διασκεδαστικά, αλλά να θυμάστε ότι ορισμένα αστεία μπορεί να μη μεταφράζονται σε άλλους πολιτισμούς ή σε ανθρώπους με διαφορετικές εμπειρίες από εσάς. Ορισμένοι από τους δυνητικούς χρήστες σας μπορεί να είναι υπάλληλοι της εταιρείας: δεν θέλετε να τους κάνετε να νιώσουν άβολα όταν θα πρέπει να εξηγήσουν το πρότζεκτ σας στη δουλειά!
 
-### Avoiding name conflicts
+### Αποφυγή συγκρούσεων ονομάτων
 
-[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+[Ελέγξτε για πρότζεκτ ανοικτού κώδικα με παρόμοιο όνομα](http://ivantomic.com/projects/ospnc/), ειδικά αν μοιράζεστε την ίδια γλώσσα ή το ίδιο οικοσύστημα. Εάν το όνομά σας συμπίπτει με ένα δημοφιλές υπάρχον πρότζεκτ, μπορεί να προκαλέσετε σύγχυση στο κοινό σας.
 
-If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+Αν θέλετε έναν ιστότοπο, μια λαβή στο Twitter ή άλλες ιδιότητες που θα αντιπροσωπεύουν το πρότζεκτ σας, βεβαιωθείτε ότι μπορείτε να πάρετε τα ονόματα που θέλετε. Ιδανικά, [κρατήστε αυτά τα ονόματα τώρα](https://instantdomainsearch.com/) για να είστε ήσυχοι, ακόμη και αν δεν σκοπεύετε να τα χρησιμοποιήσετε ακόμη.
 
-Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+Βεβαιωθείτε ότι το όνομα του έργου σας δεν παραβιάζει κανένα εμπορικό σήμα. Μια εταιρεία μπορεί να σας ζητήσει αργότερα να καταργήσετε το πρότζεκτ σας ή ακόμη και να κινηθεί νομικά εναντίον σας. Δεν αξίζει τον κόπο να το ρισκάρετε.
 
-You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+Μπορείτε να ελέγξετε τη [WIPO Global Brand Database] (http://www.wipo.int/branddb/en/) για συγκρούσεις εμπορικών σημάτων. Αν είστε σε μια εταιρεία, αυτό είναι ένα από τα πράγματα με τα οποία μπορεί να σας βοηθήσει η [νομική ομάδα](../legal/).
 
-Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+Τέλος, κάντε μια γρήγορη αναζήτηση στο Google για το όνομα του έργου σας. Θα μπορούν οι άνθρωποι να βρουν εύκολα το πρότζεκτ σας; Εμφανίζεται κάτι άλλο στα αποτελέσματα της αναζήτησης που δεν θα θέλατε να δουν;
 
-### How you write (and code) affects your brand, too!
+### Ο τρόπος που γράφετε (και κωδικοποιείτε) επηρεάζει και το brand σας!
 
-Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+Καθ' όλη τη διάρκεια του έργου σας, θα γράφετε πολύ: READMEs, tutorials, έγγραφα της κοινότητας, απαντήσεις σε θέματα, ίσως ακόμη και ενημερωτικά δελτία και λίστες αλληλογραφίας.
 
-Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+Είτε πρόκειται για επίσημη τεκμηρίωση είτε για ένα απλό μήνυμα ηλεκτρονικού ταχυδρομείου, το στυλ γραφής σας αποτελεί μέρος της επωνυμίας του έργου σας. Σκεφτείτε πώς θα μπορούσατε να φανείτε στο κοινό σας και αν αυτός είναι ο τόνος που θέλετε να μεταδώσετε.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+  Προσπάθησα να συμμετέχω σε κάθε νήμα της λίστας αλληλογραφίας και να δείχνω υποδειγματική συμπεριφορά, να είμαι καλός με τους ανθρώπους, να παίρνω σοβαρά τα θέματά τους και να προσπαθώ να είμαι χρήσιμος συνολικά. Μετά από λίγο, οι άνθρωποι έμειναν κοντά μου όχι μόνο για να κάνουν ερωτήσεις, αλλά και για να βοηθήσουν με τις απαντήσεις, και προς μεγάλη μου χαρά, μιμούνταν το στυλ μου.
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+- @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
-Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+Η χρήση θερμής, περιεκτικής γλώσσας (όπως "τους", ακόμη και όταν αναφέρεται σε ένα άτομο) μπορεί να συμβάλει σημαντικά στο να γίνει το πρότζεκτ σας φιλόξενο για τους νέους συνεισφέροντες. Μείνετε σε απλή γλώσσα, καθώς πολλοί από τους αναγνώστες σας μπορεί να μην έχουν ως μητρική γλώσσα τα αγγλικά.
 
-Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+Πέρα από τον τρόπο που γράφετε λέξεις, το στυλ κωδικοποίησης μπορεί επίσης να γίνει μέρος της επωνυμίας του έργου σας. Το [Angular](https://angular.io/guide/styleguide) και το [jQuery](https://contribute.jquery.org/style-guide/js/) είναι δύο παραδείγματα πρότζεκτ με αυστηρό στυλ κωδικοποίησης και κατευθυντήριες γραμμές.
 
-It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+Δεν είναι απαραίτητο να γράψετε έναν οδηγό στυλ για το πρότζεκτ σας όταν ξεκινάτε, και μπορεί να διαπιστώσετε ότι σας αρέσει να ενσωματώνετε διαφορετικά στυλ κωδικοποίησης στο πρότζεκτ σας ούτως ή άλλως. Θα πρέπει όμως να προβλέψετε πώς το στυλ γραφής και κωδικοποίησης που χρησιμοποιείτε μπορεί να προσελκύσει ή να αποθαρρύνει διαφορετικούς τύπους ανθρώπων. Τα πρώτα στάδια του έργου σας είναι η ευκαιρία σας να δημιουργήσετε το προηγούμενο που επιθυμείτε.
 
-## 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.
+Είστε έτοιμοι να ανοίξετε το πρότζεκτ σας; Ακολουθεί ένας κατάλογος ελέγχου για να σας βοηθήσει. Έχετε τσεκάρει όλα τα κουτάκια; Είστε έτοιμοι να ξεκινήσετε! [Κάντε κλικ στο "publish"](https://help.github.com/articles/making-a-private-repository-public/) και χτυπήστε τον εαυτό σας στην πλάτη.
 
-**Documentation**
+**Έγγραφα**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-    Project has a LICENSE file with an open source license
+    Το πρότζεκτ έχει ένα αρχείο LICENSE με άδεια χρήσης ανοικτού κώδικα
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+    Το πρότζεκτ έχει βασική τεκμηρίωση (README, CONTRIBUTING, CODE_OF_CONDUCT)
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+    Το όνομα είναι εύκολο να το θυμάται κανείς, δίνει μια ιδέα για το τι κάνει το πρότζεκτ και δεν έρχεται σε σύγκρουση με ένα υπάρχον πρότζεκτ ή παραβιάζει εμπορικά σήματα.
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-    The issue queue is up-to-date, with issues clearly organized and labeled
+    Η ουρά θεμάτων είναι ενημερωμένη, με τα θέματα σαφώς οργανωμένα και επισημασμένα.
   </label>
 </div>
 
-**Code**
+**Κώδικας**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    Project uses consistent code conventions and clear function/method/variable names
+    Το πρότζεκτ χρησιμοποιεί συνεπείς συμβάσεις κώδικα και σαφή ονόματα συναρτήσεων/μεθόδων/μεταβλητών
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    The code is clearly commented, documenting intentions and edge cases
+    Ο κώδικας είναι σαφώς σχολιασμένος, τεκμηριώνοντας τις προθέσεις και τις ακραίες περιπτώσεις
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+    Δεν υπάρχει ευαίσθητο υλικό στο ιστορικό αναθεωρήσεων, στα ζητήματα ή στα αιτήματα έλξης (για παράδειγμα, κωδικοί πρόσβασης ή άλλες μη δημόσιες πληροφορίες).
   </label>
 </div>
 
-**People**
+**Άνθρωποι**
 
-If you're an individual:
+Αν είστε άτομο:
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  Έχετε μιλήσει με το νομικό τμήμα ή/και έχετε κατανοήσει τις πολιτικές IP και ανοιχτού κώδικα της εταιρείας σας (αν είστε υπάλληλος κάπου)
   </label>
 </div>
 
-If you're a company or organization:
+Εάν είστε εταιρεία ή οργανισμός:
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    You've talked to your legal department
+    Μιλήσατε με το νομικό σας τμήμα
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    You have a marketing plan for announcing and promoting the project
+    Έχετε σχέδιο μάρκετινγκ για την ανακοίνωση και την προώθηση του έργου
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+    Κάποιος που έχει δεσμευτεί να διαχειρίζεται τις αλληλεπιδράσεις της κοινότητας (απάντηση σε θέματα, εξέταση και συγχώνευση αιτημάτων έλξης)
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    At least two people have administrative access to the project
+    Τουλάχιστον δύο άτομα έχουν διοικητική πρόσβαση στο πρότζεκτ
   </label>
 </div>
 
-## You did it!
+## Τα καταφέρατε!
 
-Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.
+Συγχαρητήρια για την ανοιχτή διάθεση του πρώτου σας έργου. Ανεξάρτητα από το αποτέλεσμα, η δημόσια εργασία είναι ένα δώρο στην κοινότητα. Με κάθε δέσμευση, σχόλιο και αίτηση έλξης, δημιουργείτε ευκαιρίες για τον εαυτό σας και για τους άλλους να μάθουν και να αναπτυχθούν.

From 98fc659689ee27bf5480d1a99951d0baa1cd56bc Mon Sep 17 00:00:00 2001
From: Christolisofficial <work@chris-sdogkos.com>
Date: Tue, 20 Sep 2022 12:04:19 +0300
Subject: [PATCH 398/749] Translate metrics.md

---
 _articles/el/metrics.md | 120 ++++++++++++++++++++--------------------
 1 file changed, 60 insertions(+), 60 deletions(-)

diff --git a/_articles/el/metrics.md b/_articles/el/metrics.md
index 1c1a22eefe2..ab1ff2adf6a 100644
--- a/_articles/el/metrics.md
+++ b/_articles/el/metrics.md
@@ -10,119 +10,119 @@ related:
   - best-practices
 ---
 
-## Why measure anything?
+## Γιατί να μετρήσουμε οτιδήποτε;
 
-Data, when used wisely, can help you make better decisions as an open source maintainer.
+Τα δεδομένα, όταν χρησιμοποιούνται με σύνεση, μπορούν να σας βοηθήσουν να λάβετε καλύτερες αποφάσεις ως συντηρητής ανοικτού κώδικα.
 
-With more information, you can:
+Με περισσότερες πληροφορίες, μπορείτε:
 
-* Understand how users respond to a new feature
-* Figure out where new users come from
-* Identify, and decide whether to support, an outlier use case or functionality
-* Quantify your project's popularity
-* Understand how your project is used
-* Raise money through sponsorships and grants
+* Κατανόηση του τρόπου με τον οποίο οι χρήστες ανταποκρίνονται σε ένα νέο χαρακτηριστικό
+* Ανακαλύψτε από πού προέρχονται οι νέοι χρήστες
+* Εντοπισμός και απόφαση σχετικά με την υποστήριξη μιας περίπτωσης χρήσης ή μιας λειτουργικότητας που ξεφεύγει από τα συνηθισμένα
+* Ποσοτικοποιήστε τη δημοτικότητα του πρότζεκτ σας
+* Κατανοήστε πώς χρησιμοποιείται το πρότζεκτ σας
+* Συγκέντρωση χρημάτων μέσω χορηγιών και επιχορηγήσεων
 
-For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+Για παράδειγμα, το [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) διαπιστώνει ότι το Google Analytics τους βοηθάει να θέτουν προτεραιότητες στην εργασία τους:
 
-> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+> Το Homebrew παρέχεται δωρεάν και διευθύνεται εξ ολοκλήρου από εθελοντές στον ελεύθερο χρόνο τους. Ως αποτέλεσμα, δεν έχουμε τους πόρους για να κάνουμε λεπτομερείς μελέτες χρηστών του Homebrew για να αποφασίσουμε πώς θα σχεδιάσουμε καλύτερα τα μελλοντικά χαρακτηριστικά και να δώσουμε προτεραιότητα στις τρέχουσες εργασίες. Οι ανώνυμες συγκεντρωτικές αναλύσεις χρηστών μας επιτρέπουν να δώσουμε προτεραιότητα στις διορθώσεις και τα χαρακτηριστικά με βάση το πώς, πού και πότε οι χρήστες χρησιμοποιούν το Homebrew.
 
-Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+Η δημοτικότητα δεν είναι το παν. Όλοι ασχολούνται με τον ανοιχτό κώδικα για διαφορετικούς λόγους. Αν ο στόχος σας ως συντηρητής ανοιχτού κώδικα είναι να επιδείξετε τη δουλειά σας, να είστε διαφανείς σχετικά με τον κώδικά σας ή απλά να διασκεδάσετε, οι μετρήσεις μπορεί να μην είναι σημαντικές για εσάς.
 
-If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+Αν _ενδιαφέρεστε_ να κατανοήσετε το πρότζεκτ σας σε βαθύτερο επίπεδο, διαβάστε παρακάτω για τρόπους ανάλυσης της δραστηριότητας του έργου σας.
 
-## Discovery
+## Ανακάλυψη
 
-Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+Πριν κάποιος μπορεί να χρησιμοποιήσει ή να συνεισφέρει στο πρότζεκτ σας, πρέπει να γνωρίζει ότι υπάρχει. Ρωτήστε τον εαυτό σας: _βρίσκουν οι άνθρωποι αυτό το πρότζεκτ;_
 
-![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
+![Διάγραμμα κυκλοφορίας](/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:
+Εάν το πρότζεκτ σας φιλοξενείται στο GitHub, [μπορείτε να δείτε](https://help.github.com/articles/about-repository-graphs/#traffic) πόσοι άνθρωποι μπαίνουν στο πρότζεκτ σας και από πού προέρχονται. Από τη σελίδα του έργου σας, κάντε κλικ στην επιλογή "Insights" και στη συνέχεια στην επιλογή "Traffic". Σε αυτή τη σελίδα, μπορείτε να δείτε: "Το πρότζεκτ σας":
 
-* **Total page views:** Tells you how many times your project was viewed
+* **Συνολικές προβολές σελίδων:** Σας λέει πόσες φορές προβλήθηκε το πρότζεκτ σας
 
-* **Total unique visitors:** Tells you how many people viewed your project
+* **Συνολικοί μοναδικοί επισκέπτες:** Σας λέει πόσοι άνθρωποι είδαν το πρότζεκτ σας
 
-* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+* **Συμβαλλόμενοι ιστότοποι:** Σας λέει από πού προήλθαν οι επισκέπτες. Αυτή η μέτρηση μπορεί να σας βοηθήσει να καταλάβετε πού να προσεγγίσετε το κοινό σας και αν οι προσπάθειες προώθησής σας αποδίδουν.
 
-* **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://help.github.com/articles/about-stars/) μπορεί επίσης να βοηθήσει στην παροχή ενός βασικού μέτρου δημοτικότητας. Αν και τα αστέρια του GitHub δεν συσχετίζονται απαραίτητα με τις λήψεις και τη χρήση, μπορούν να σας δείξουν πόσοι άνθρωποι λαμβάνουν γνώση της εργασίας σας.
 
-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.
+Μπορεί επίσης να θέλετε να [παρακολουθείτε την ανιχνευσιμότητα σε συγκεκριμένα μέρη](https://opensource.com/business/16/6/pirate-metrics): για παράδειγμα, το Google PageRank, την επισκεψιμότητα παραπομπών από τον ιστότοπο του έργου σας ή παραπομπές από άλλα πρότζεκτ ή ιστότοπους ανοικτού κώδικα.
 
-## Usage
+## Χρήση
 
-People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+Οι άνθρωποι βρίσκουν το πρότζεκτ σας σε αυτό το άγριο και τρελό πράγμα που αποκαλούμε διαδίκτυο. Ιδανικά, όταν δουν το πρότζεκτ σας, θα νιώσουν την ανάγκη να κάνουν κάτι. Η δεύτερη ερώτηση που θα πρέπει να κάνετε είναι: _χρησιμοποιούν οι άνθρωποι αυτό το πρότζεκτ;_
 
-If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+Αν χρησιμοποιείτε έναν διαχειριστή πακέτων, όπως το npm ή το RubyGems.org, για να διανείμετε το πρότζεκτ σας, μπορεί να μπορείτε να παρακολουθείτε τις λήψεις του έργου σας.
 
-Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+Κάθε διαχειριστής πακέτων μπορεί να χρησιμοποιεί έναν ελαφρώς διαφορετικό ορισμό της "λήψης" και οι λήψεις δεν συσχετίζονται απαραίτητα με τις εγκαταστάσεις ή τη χρήση, αλλά παρέχει κάποια βάση σύγκρισης. Δοκιμάστε να χρησιμοποιήσετε το [Libraries.io](https://libraries.io/) για να παρακολουθήσετε στατιστικά στοιχεία χρήσης σε πολλούς δημοφιλείς διαχειριστές πακέτων.
 
-If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+Αν το πρότζεκτ σας βρίσκεται στο GitHub, μεταβείτε ξανά στη σελίδα "Traffic". Μπορείτε να χρησιμοποιήσετε το [clone graph](https://github.com/blog/1873-clone-graphs) για να δείτε πόσες φορές έχει κλωνοποιηθεί το πρότζεκτ σας σε μια δεδομένη ημέρα, αναλυτικά με βάση το σύνολο των κλώνων και τους μοναδικούς κλώνους.
 
 ![Clone graph](/assets/images/metrics/clone_graph.png)
 
-If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+Εάν η χρήση είναι χαμηλή σε σύγκριση με τον αριθμό των ατόμων που ανακαλύπτουν το πρότζεκτ σας, υπάρχουν δύο ζητήματα που πρέπει να εξετάσετε. Είτε:
 
-* Your project isn't successfully converting your audience, or
-* You're attracting the wrong audience
+* Το πρότζεκτ σας δεν μετατρέπει με επιτυχία το κοινό σας, ή
+* Προσελκύετε το λάθος κοινό
 
-For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+Για παράδειγμα, αν το πρότζεκτ σας βρεθεί στην πρώτη σελίδα του Hacker News, θα δείτε πιθανότατα μια αύξηση στην ανακάλυψη (επισκεψιμότητα), αλλά ένα χαμηλότερο ποσοστό μετατροπής, επειδή θα φτάσετε σε όλους τους χρήστες του Hacker News. Αν το Ruby πρότζεκτ σας παρουσιάζεται σε ένα συνέδριο Ruby, ωστόσο, είναι πιο πιθανό να δείτε υψηλό ποσοστό μετατροπής από ένα στοχευμένο κοινό.
 
-Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+Προσπαθήστε να καταλάβετε από πού προέρχεται το κοινό σας και ζητήστε από τους άλλους σχόλια για τη σελίδα του πρότζεκτ σας για να καταλάβετε ποιο από αυτά τα δύο ζητήματα αντιμετωπίζετε.
 
-Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+Μόλις μάθετε ότι οι άνθρωποι χρησιμοποιούν το πρότζεκτ σας, ίσως θελήσετε να προσπαθήσετε να καταλάβετε τι κάνουν με αυτό. Χτίζουν πάνω σε αυτό με το να διακλαδώνουν τον κώδικά σας και να προσθέτουν χαρακτηριστικά; Το χρησιμοποιούν για επιστημονικούς ή επιχειρηματικούς σκοπούς;
 
-## Retention
+## Διατήρηση
 
-People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+Οι άνθρωποι βρίσκουν το πρότζεκτ σας και το χρησιμοποιούν. Το επόμενο ερώτημα που θα πρέπει να θέσετε στον εαυτό σας είναι: _Συμβάλλουν οι άνθρωποι σε αυτό το πρότζεκτ;_
 
-It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+Ποτέ δεν είναι πολύ νωρίς για να αρχίσετε να σκέφτεστε τους συνεισφέροντες. Χωρίς τη συμμετοχή άλλων ανθρώπων, κινδυνεύετε να βρεθείτε σε μια ανθυγιεινή κατάσταση όπου το πρότζεκτ σας είναι _δημοφιλές_ (πολλοί το χρησιμοποιούν) αλλά δεν _υποστηρίζεται_ (δεν υπάρχει αρκετός χρόνος συντηρητών για να καλύψει τη ζήτηση).
 
-Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+Η διατήρηση απαιτεί επίσης [εισροή νέων συνεισφερόντων](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), καθώς οι προηγουμένως ενεργοί συνεισφέροντες θα προχωρήσουν τελικά σε άλλα πράγματα.
 
-Examples of community metrics that you may want to regularly track include:
+Παραδείγματα μετρήσεων της κοινότητας που μπορεί να θέλετε να παρακολουθείτε τακτικά περιλαμβάνουν:
 
-* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+* **Συνολικός αριθμός συνεργατών και αριθμός κοινοποιήσεων ανά συνεργάτη:** Σας λέει πόσους συνεργάτες έχετε και ποιοι είναι περισσότερο ή λιγότερο ενεργοί. Στο GitHub, μπορείτε να το δείτε αυτό στην ενότητα "Insights" -> "Contributors". Αυτή τη στιγμή, αυτό το γράφημα μετράει μόνο τους συνεισφέροντες που έχουν δεσμευτεί στον προεπιλεγμένο κλάδο του αποθετηρίου.
 
-![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+![Διάγραμμα συνεισφερόντων](/assets/images/metrics/repo_contributors_specific_graph.png)
 
-* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+* **Πρώτη φορά, περιστασιακοί και επαναλαμβανόμενοι συνεισφέροντες:** Σας βοηθά να παρακολουθείτε αν έχετε νέους συνεισφέροντες και αν επιστρέφουν. (Οι περιστασιακοί συνεισφέροντες είναι συνεισφέροντες με χαμηλό αριθμό κοινοποιήσεων. Το αν αυτό είναι μία δέσμευση, λιγότερες από πέντε δεσμεύσεις ή κάτι άλλο εξαρτάται από εσάς). Χωρίς νέους συνεισφέροντες, η κοινότητα του έργου σας μπορεί να μείνει στάσιμη.
 
-* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+* **Αριθμός ανοιχτών ζητημάτων και ανοιχτών pull request:** Αν αυτοί οι αριθμοί είναι πολύ υψηλοί, ίσως χρειαστείτε βοήθεια με την ταξινόμηση ζητημάτων και τις ανασκοπήσεις κώδικα.
 
-* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+* **Αριθμός _ανοικτών_ θεμάτων και _ανοικτών_ pull request:** Τα ανοικτά θέματα σημαίνουν ότι κάποιος ενδιαφέρεται αρκετά για το πρότζεκτ σας ώστε να ανοίξει ένα θέμα. Αν ο αριθμός αυτός αυξάνεται με την πάροδο του χρόνου, αυτό υποδηλώνει ότι οι άνθρωποι ενδιαφέρονται για το πρότζεκτ σας.
 
-* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+* **Τύποι συνεισφορών:** Για παράδειγμα, μεταβιβάσεις, διόρθωση τυπογραφικών λαθών ή σφαλμάτων ή σχολιασμός ενός θέματος.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
-  Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+  Ο ανοικτός κώδικας είναι κάτι περισσότερο από απλός κώδικας. Τα επιτυχημένα πρότζεκτ ανοικτού κώδικα περιλαμβάνουν συνεισφορές σε κώδικα και τεκμηρίωση μαζί με συζητήσεις σχετικά με αυτές τις αλλαγές.
   <p markdown="1" class="pquote-credit">
-— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+- @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
   </p>
 </aside>
 
-## Maintainer activity
+## Δραστηριότητα συντηρητή
 
-Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+Τέλος, θα πρέπει να κλείσετε το βρόχο διασφαλίζοντας ότι οι συντηρητές του έργου σας είναι σε θέση να διαχειριστούν τον όγκο των συνεισφορών που λαμβάνουν. Το τελευταίο ερώτημα που θα πρέπει να θέσετε στον εαυτό σας είναι: Ανταποκρίνομαι (ή ανταποκρινόμαστε) στην κοινότητά μας;
 
-Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+Οι μη ανταποκρινόμενοι συντηρητές γίνονται τροχοπέδη για τα πρότζεκτ ανοικτού κώδικα. Αν κάποιος υποβάλλει μια συνεισφορά αλλά δεν λαμβάνει ποτέ απάντηση από έναν συντηρητή, μπορεί να αποθαρρυνθεί και να φύγει.
 
-[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+[Έρευνα από τη Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) δείχνει ότι η ανταπόκριση του συντηρητή είναι ένας κρίσιμος παράγοντας για την ενθάρρυνση της επανάληψης των συνεισφορών.
 
-Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+Εξετάστε το ενδεχόμενο να παρακολουθείτε πόσος χρόνος χρειάζεται για να απαντήσετε εσείς (ή κάποιος άλλος συντηρητής) σε συνεισφορές, είτε πρόκειται για ένα θέμα είτε για ένα pull request. Η ανταπόκριση δεν απαιτεί την ανάληψη δράσης. Μπορεί να είναι τόσο απλό όσο το να πείτε: _"Ευχαριστώ για την υποβολή σας! Θα το επανεξετάσω μέσα στην επόμενη εβδομάδα."_
 
-You could also measure the time it takes to move between stages in the contribution process, such as:
+Θα μπορούσατε επίσης να μετρήσετε το χρόνο που απαιτείται για να μετακινηθείτε μεταξύ των σταδίων της διαδικασίας συνεισφοράς, όπως:
 
-* Average time an issue remains open
-* Whether issues get closed by PRs
-* Whether stale issues get closed
-* Average time to merge a pull request
+* Μέσος χρόνος που ένα ζήτημα παραμένει ανοικτό
+* Αν τα θέματα κλείνουν από τις δημόσιες σχέσεις
+* Αν τα θέματα που έχουν μείνει στάσιμα κλείνουν
+* Μέσος χρόνος για τη συγχώνευση ενός pull request
 
-## Use 📊 to learn about people
+## Χρησιμοποιήστε το 📊 για να μάθετε για τους ανθρώπους
 
-Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+Η κατανόηση των μετρήσεων θα σας βοηθήσει να δημιουργήσετε ένα ενεργό, αναπτυσσόμενο πρότζεκτ ανοικτού κώδικα. Ακόμα και αν δεν παρακολουθείτε κάθε μετρική σε ένα ταμπλό, χρησιμοποιήστε το παραπάνω πλαίσιο για να εστιάσετε την προσοχή σας στο είδος της συμπεριφοράς που θα βοηθήσει το πρότζεκτ σας να ευδοκιμήσει.
 
-[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health.
+[CHAOSS](https://chaoss.community/) είναι μια φιλόξενη κοινότητα ανοικτού κώδικα που επικεντρώνεται στην ανάλυση, τις μετρήσεις και το λογισμικό για την κοινοτική υγεία.

From 6d2b61d13460854b36a7c31b183fe36edacc97d4 Mon Sep 17 00:00:00 2001
From: christolis <work@chris-sdogkos.com>
Date: Wed, 21 Sep 2022 16:15:42 +0100
Subject: [PATCH 399/749] Fix some HTML-Proofer failures

---
 _articles/el/building-community.md | 6 +++---
 _articles/el/how-to-contribute.md  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index 5fb95dccf2a..3174dc5b12d 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -26,8 +26,8 @@ related:
 
 Ξεκινήστε με την τεκμηρίωσή σας:
 
-* **Κάντε εύκολο για κάποιον να χρησιμοποιήσει το πρότζεκτ σας.** [Ένα φιλικό README](../starting-a-project/#writing-a-readme) και σαφή παραδείγματα κώδικα θα διευκολύνουν οποιονδήποτε βρεθεί στο πρότζεκτ σας να ξεκινήσει.
-* **Εξηγήστε με σαφήνεια πώς να συνεισφέρετε**, χρησιμοποιώντας [το αρχείο CONTRIBUTING](../starting-a-project/#writing-your-contributing-guidelines) και διατηρώντας τα θέματά σας ενημερωμένα.
+* **Κάντε εύκολο για κάποιον να χρησιμοποιήσει το πρότζεκτ σας.** [Ένα φιλικό README](../starting-a-project/#γράφοντας-ένα-readme) και σαφή παραδείγματα κώδικα θα διευκολύνουν οποιονδήποτε βρεθεί στο πρότζεκτ σας να ξεκινήσει.
+* **Εξηγήστε με σαφήνεια πώς να συνεισφέρετε**, χρησιμοποιώντας [το αρχείο CONTRIBUTING](../starting-a-project/#γράφοντας-τις-κατευθυντήριες-γραμμές-συνεισφοράς-σας) και διατηρώντας τα θέματά σας ενημερωμένα.
 * **Καλά πρώτα θέματα**: Για να βοηθήσετε τους νέους συνεισφέροντες να ξεκινήσουν, σκεφτείτε ρητά [την επισήμανση θεμάτων που είναι αρκετά απλά για να τα αντιμετωπίσουν οι αρχάριοι](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Στη συνέχεια, το GitHub θα εμφανίσει αυτά τα θέματα σε διάφορα σημεία της πλατφόρμας, αυξάνοντας τις χρήσιμες συνεισφορές και μειώνοντας τις τριβές από τους χρήστες που αντιμετωπίζουν θέματα που είναι πολύ δύσκολα για το επίπεδό τους.
 
 [Η έρευνα του GitHub για τον ανοικτό κώδικα του 2017](http://opensourcesurvey.org/2017/) έδειξε ότι η ελλιπής ή συγκεχυμένη τεκμηρίωση είναι το μεγαλύτερο πρόβλημα για τους χρήστες ανοικτού κώδικα. Η καλή τεκμηρίωση προσκαλεί τους ανθρώπους να αλληλεπιδράσουν με το πρότζεκτ σας. Τελικά, κάποιος θα ανοίξει ένα ζήτημα ή ένα αίτημα. Χρησιμοποιήστε αυτές τις αλληλεπιδράσεις ως ευκαιρίες για να τους μετακινήσετε προς τα κάτω στο χωνί.
@@ -209,7 +209,7 @@ related:
 
 ### Αντιμετωπίστε το README σας ως σύνταγμα
 
-Το README σας είναι [κάτι περισσότερο από ένα σύνολο οδηγιών](../starting-a-project/#writing-a-readme). Είναι επίσης ένα μέρος για να μιλήσετε για τους στόχους σας, το όραμα του προϊόντος και τον οδικό χάρτη. Αν οι άνθρωποι επικεντρώνονται υπερβολικά στη συζήτηση για την αξία ενός συγκεκριμένου χαρακτηριστικού, μπορεί να βοηθήσει να επανεξετάσετε το README σας και να μιλήσετε για το ανώτερο όραμα του πρότζεκτ σας. Η εστίαση στο README σας αποπροσωποποιεί επίσης τη συζήτηση, ώστε να μπορείτε να έχετε μια εποικοδομητική συζήτηση.
+Το README σας είναι [κάτι περισσότερο από ένα σύνολο οδηγιών](../starting-a-project/#γράφοντας-ένα-readme). Είναι επίσης ένα μέρος για να μιλήσετε για τους στόχους σας, το όραμα του προϊόντος και τον οδικό χάρτη. Αν οι άνθρωποι επικεντρώνονται υπερβολικά στη συζήτηση για την αξία ενός συγκεκριμένου χαρακτηριστικού, μπορεί να βοηθήσει να επανεξετάσετε το README σας και να μιλήσετε για το ανώτερο όραμα του πρότζεκτ σας. Η εστίαση στο README σας αποπροσωποποιεί επίσης τη συζήτηση, ώστε να μπορείτε να έχετε μια εποικοδομητική συζήτηση.
 
 ### Επικεντρωθείτε στο ταξίδι, όχι στον προορισμό
 
diff --git a/_articles/el/how-to-contribute.md b/_articles/el/how-to-contribute.md
index b9362f910ac..c524cc06d96 100644
--- a/_articles/el/how-to-contribute.md
+++ b/_articles/el/how-to-contribute.md
@@ -499,7 +499,7 @@ related:
 
 ### 😭 Δεν λαμβάνετε απάντηση.
 
-Ελπίζουμε ότι [ελέγξατε το έργο για σημάδια δραστηριότητας](#a-checklist-before-you-contribute) πριν κάνετε μια συνεισφορά. Ακόμα και σε ένα ενεργό έργο, ωστόσο, είναι πιθανό η συνεισφορά σας να μην λάβει απάντηση.
+Ελπίζουμε ότι [ελέγξατε το έργο για σημάδια δραστηριότητας](#μια-λίστα-ελέγχου-πριν-συνεισφέρετε) πριν κάνετε μια συνεισφορά. Ακόμα και σε ένα ενεργό έργο, ωστόσο, είναι πιθανό η συνεισφορά σας να μην λάβει απάντηση.
 
 Αν δεν έχετε λάβει απάντηση για πάνω από μια εβδομάδα, είναι δίκαιο να απαντήσετε ευγενικά στο ίδιο θέμα, ζητώντας από κάποιον να το αξιολογήσει. Αν γνωρίζετε το όνομα του κατάλληλου ατόμου που θα αξιολογήσει τη συνεισφορά σας, μπορείτε να τον @-αναφέρετε στο ίδιο θέμα.
 

From 66646071c1f9e15da185bcbafaafa8fa1cfd51be Mon Sep 17 00:00:00 2001
From: christolis <work@chris-sdogkos.com>
Date: Wed, 21 Sep 2022 16:38:17 +0100
Subject: [PATCH 400/749] Fix some more HTML-Proofer failures

---
 _articles/el/building-community.md        | 2 +-
 _articles/el/how-to-contribute.md         | 2 +-
 _articles/el/leadership-and-governance.md | 2 +-
 _articles/el/legal.md                     | 6 +++---
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index 3174dc5b12d..9a194818300 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -123,7 +123,7 @@ related:
 
 Οι τακτικές συζητήσεις για ασήμαντες πτυχές του πρότζεκτ σας αποσπούν την προσοχή των άλλων, συμπεριλαμβανομένου και εσάς, από το να επικεντρωθούν σε σημαντικά καθήκοντα. Τα νέα άτομα που φτάνουν στο πρότζεκτ σας μπορεί να δουν αυτές τις συζητήσεις και να μην θέλουν να συμμετάσχουν.
 
-Όταν βλέπετε αρνητική συμπεριφορά να συμβαίνει στο πρότζεκτ σας, φωνάξτε την δημόσια. Εξηγήστε, με ευγενικό αλλά αυστηρό τόνο, γιατί η συμπεριφορά τους δεν είναι αποδεκτή. Αν το πρόβλημα επιμένει, ίσως χρειαστεί να [τους ζητήσετε να φύγουν](../code-of-conduct/#enforcing-your-code-of-conduct). Ο [κώδικας δεοντολογίας](../code-of-conduct/) μπορεί να αποτελέσει εποικοδομητικό οδηγό για αυτές τις συζητήσεις.
+Όταν βλέπετε αρνητική συμπεριφορά να συμβαίνει στο πρότζεκτ σας, φωνάξτε την δημόσια. Εξηγήστε, με ευγενικό αλλά αυστηρό τόνο, γιατί η συμπεριφορά τους δεν είναι αποδεκτή. Αν το πρόβλημα επιμένει, ίσως χρειαστεί να [τους ζητήσετε να φύγουν](../code-of-conduct/#επιβολή-του-κώδικα-συμπεριφοράς-σας). Ο [κώδικας δεοντολογίας](../code-of-conduct/) μπορεί να αποτελέσει εποικοδομητικό οδηγό για αυτές τις συζητήσεις.
 
 ### Συναντήστε τους συνεισφέροντες εκεί που βρίσκονται
 
diff --git a/_articles/el/how-to-contribute.md b/_articles/el/how-to-contribute.md
index c524cc06d96..9c5db70be9e 100644
--- a/_articles/el/how-to-contribute.md
+++ b/_articles/el/how-to-contribute.md
@@ -52,7 +52,7 @@ related:
 
 Δεν χρειάζεται να γίνετε ισόβιος συνεργάτης για να απολαύσετε τη συμμετοχή σας στον ανοικτό κώδικα. Έχετε δει ποτέ ένα τυπογραφικό λάθος σε έναν ιστότοπο και ευχηθήκατε κάποιος να το διορθώσει; Σε ένα έργο ανοιχτού κώδικα, μπορείτε να κάνετε ακριβώς αυτό. Ο ανοικτός κώδικας βοηθά τους ανθρώπους να αισθάνονται ότι έχουν εξουσία στη ζωή τους και στο πώς βιώνουν τον κόσμο, και αυτό από μόνο του είναι ευχάριστο.
 
-## Τι σημαίνει να συνεισφέρεις
+## Τι σημαίνει να συνεισφέρετε
 
 Αν είστε νέος συνεισφέρων σε έργα ανοικτού κώδικα, η διαδικασία μπορεί να είναι εκφοβιστική. Πώς μπορείτε να βρείτε το κατάλληλο έργο; Τι γίνεται αν δεν ξέρετε να προγραμματίζετε; Τι γίνεται αν κάτι πάει στραβά;
 
diff --git a/_articles/el/leadership-and-governance.md b/_articles/el/leadership-and-governance.md
index 1bd1bde86f5..a80c0d928a9 100644
--- a/_articles/el/leadership-and-governance.md
+++ b/_articles/el/leadership-and-governance.md
@@ -40,7 +40,7 @@ related:
 
 **Ο όρος "committer"** θα μπορούσε να χρησιμοποιηθεί για να διακρίνει την πρόσβαση στα commits, η οποία είναι ένας συγκεκριμένος τύπος ευθύνης, από άλλες μορφές συνεισφοράς.
 
-Ενώ μπορείτε να ορίσετε τους ρόλους του πρότζεκτ σας με όποιον τρόπο θέλετε, [εξετάστε το ενδεχόμενο να χρησιμοποιήσετε ευρύτερους ορισμούς](../how-to-contribute/#what-it-means-to-contribute) για να ενθαρρύνετε περισσότερες μορφές συνεισφοράς. Μπορείτε να χρησιμοποιήσετε τους ρόλους ηγεσίας για να αναγνωρίσετε επίσημα τους ανθρώπους που έχουν συνεισφέρει εξαιρετικά στο πρότζεκτ σας, ανεξάρτητα από τις τεχνικές τους δεξιότητες.
+Ενώ μπορείτε να ορίσετε τους ρόλους του πρότζεκτ σας με όποιον τρόπο θέλετε, [εξετάστε το ενδεχόμενο να χρησιμοποιήσετε ευρύτερους ορισμούς](../how-to-contribute/#τι-σημαίνει-να-συνεισφέρετε) για να ενθαρρύνετε περισσότερες μορφές συνεισφοράς. Μπορείτε να χρησιμοποιήσετε τους ρόλους ηγεσίας για να αναγνωρίσετε επίσημα τους ανθρώπους που έχουν συνεισφέρει εξαιρετικά στο πρότζεκτ σας, ανεξάρτητα από τις τεχνικές τους δεξιότητες.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/el/legal.md b/_articles/el/legal.md
index 01042fbdf58..9c4e8dd6b7a 100644
--- a/_articles/el/legal.md
+++ b/_articles/el/legal.md
@@ -68,7 +68,7 @@ related:
 * **Θέλετε το πρότζεκτ σας να απευθύνεται σε μεγάλες επιχειρήσεις;** Μια μεγάλη επιχείρηση θα θέλει πιθανότατα ρητή άδεια χρήσης διπλωμάτων ευρεσιτεχνίας από όλους τους συνεισφέροντες. Σε αυτή την περίπτωση, το [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) σας καλύπτει (και αυτούς).
 * **Θέλετε το πρότζεκτ σας να απευθύνεται σε συνεισφέροντες που δεν επιθυμούν οι συνεισφορές τους να χρησιμοποιηθούν σε λογισμικό κλειστού κώδικα;** Η [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) ή (αν επίσης δεν επιθυμούν να συνεισφέρουν σε υπηρεσίες κλειστού κώδικα) η [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) θα είναι καλή επιλογή.
 
-Η **επιχείρησή σας** μπορεί να έχει συγκεκριμένες απαιτήσεις αδειοδότησης για τα πρότζεκτ ανοικτού κώδικα. Για παράδειγμα, μπορεί να απαιτεί μια επιτρεπτική άδεια ώστε η εταιρεία να μπορεί να χρησιμοποιήσει το πρότζεκτ σας στο προϊόν κλειστού κώδικα της εταιρείας. Ή η εταιρεία σας μπορεί να απαιτεί μια ισχυρή άδεια copyleft και μια πρόσθετη συμφωνία συνεισφοράς (βλ. παρακάτω), έτσι ώστε μόνο η εταιρεία σας, και κανένας άλλος, να μπορεί να χρησιμοποιήσει το πρότζεκτ σας σε λογισμικό κλειστού κώδικα. Ή η εταιρεία σας μπορεί να έχει ορισμένες ανάγκες που σχετίζονται με πρότυπα, κοινωνική ευθύνη ή διαφάνεια, οι οποίες μπορεί να απαιτούν μια συγκεκριμένη στρατηγική αδειοδότησης. Μιλήστε με το νομικό τμήμα της [εταιρείας σας](#what-does-my-companys-legal-team-need-to-know).
+Η **επιχείρησή σας** μπορεί να έχει συγκεκριμένες απαιτήσεις αδειοδότησης για τα πρότζεκτ ανοικτού κώδικα. Για παράδειγμα, μπορεί να απαιτεί μια επιτρεπτική άδεια ώστε η εταιρεία να μπορεί να χρησιμοποιήσει το πρότζεκτ σας στο προϊόν κλειστού κώδικα της εταιρείας. Ή η εταιρεία σας μπορεί να απαιτεί μια ισχυρή άδεια copyleft και μια πρόσθετη συμφωνία συνεισφοράς (βλ. παρακάτω), έτσι ώστε μόνο η εταιρεία σας, και κανένας άλλος, να μπορεί να χρησιμοποιήσει το πρότζεκτ σας σε λογισμικό κλειστού κώδικα. Ή η εταιρεία σας μπορεί να έχει ορισμένες ανάγκες που σχετίζονται με πρότυπα, κοινωνική ευθύνη ή διαφάνεια, οι οποίες μπορεί να απαιτούν μια συγκεκριμένη στρατηγική αδειοδότησης. Μιλήστε με το νομικό τμήμα της [εταιρείας σας](#τι-πρέπει-να-γνωρίζει-η-νομική-ομάδα-της-εταιρείας-μου).
 
 Όταν δημιουργείτε ένα νέο πρότζεκτ στο GitHub, σας δίνεται η δυνατότητα να επιλέξετε μια άδεια χρήσης. Η συμπερίληψη μιας από τις άδειες που αναφέρονται παραπάνω θα καταστήσει το πρότζεκτ σας στο GitHub ανοικτού κώδικα. Αν θέλετε να δείτε και άλλες επιλογές, επισκεφθείτε την ιστοσελίδα [choosealicense.com](https://choosealicense.com) για να βρείτε την κατάλληλη άδεια για το πρότζεκτ σας, ακόμη και αν αυτό [δεν είναι λογισμικό](https://choosealicense.com/non-software/).
 
@@ -126,7 +126,7 @@ related:
 
 * **Διπλώματα ευρεσιτεχνίας:** Υποβάλλει η εταιρεία σας αίτηση για δίπλωμα ευρεσιτεχνίας του οποίου η ανοικτή διάθεση του έργου σας θα αποτελούσε [δημόσια αποκάλυψη](https://en.wikipedia.org/wiki/Public_disclosure); Δυστυχώς, μπορεί να σας ζητηθεί να περιμένετε (ή ίσως η εταιρεία να επανεξετάσει τη σοφία της αίτησης). Αν περιμένετε συνεισφορές στο πρότζεκτ σας από υπαλλήλους εταιρειών με μεγάλα χαρτοφυλάκια διπλωμάτων ευρεσιτεχνίας, η νομική σας ομάδα μπορεί να θέλει να χρησιμοποιήσετε μια άδεια με ρητή παραχώρηση διπλωμάτων ευρεσιτεχνίας από τους συνεισφέροντες (όπως η Apache 2.0 ή η GPLv3), ή μια πρόσθετη συμφωνία συνεισφοράς (βλ. παραπάνω).
 
-* **Εμπορικά σήματα:** Ελέγξτε δύο φορές ότι το όνομα του έργου σας [δεν συγκρούεται με τυχόν υπάρχοντα εμπορικά σήματα](../starting-a-project/#avoiding-name-conflicts). Εάν χρησιμοποιείτε τα εμπορικά σήματα της εταιρείας σας στο πρότζεκτ, ελέγξτε ότι δεν προκαλούνται συγκρούσεις. Το [FOSSmarks](http://fossmarks.org/) είναι ένας πρακτικός οδηγός για την κατανόηση των εμπορικών σημάτων στο πλαίσιο των πρότζεκτ ελεύθερου και ανοικτού κώδικα.
+* **Εμπορικά σήματα:** Ελέγξτε δύο φορές ότι το όνομα του έργου σας [δεν συγκρούεται με τυχόν υπάρχοντα εμπορικά σήματα](../starting-a-project/#αποφυγή-συγκρούσεων-ονομάτων). Εάν χρησιμοποιείτε τα εμπορικά σήματα της εταιρείας σας στο πρότζεκτ, ελέγξτε ότι δεν προκαλούνται συγκρούσεις. Το [FOSSmarks](http://fossmarks.org/) είναι ένας πρακτικός οδηγός για την κατανόηση των εμπορικών σημάτων στο πλαίσιο των πρότζεκτ ελεύθερου και ανοικτού κώδικα.
 
 * **Απόρρητο:** Το πρότζεκτ σας συλλέγει δεδομένα για τους χρήστες; "Τηλεφωνεί στο σπίτι" σε διακομιστές της εταιρείας; Η νομική σας ομάδα μπορεί να σας βοηθήσει να συμμορφωθείτε με τις εταιρικές πολιτικές και τους εξωτερικούς κανονισμούς.
 
@@ -155,4 +155,4 @@ related:
 </aside>
 
 * **Διπλώματα ευρεσιτεχνίας:** Η εταιρεία σας μπορεί να επιθυμεί να ενταχθεί στο [Open Invention Network](https://www.openinventionnetwork.com/), μια κοινή αμυντική δεξαμενή διπλωμάτων ευρεσιτεχνίας για την προστασία της χρήσης μεγάλων πρότζεκτ ανοικτού κώδικα από τα μέλη, ή να διερευνήσει άλλες [εναλλακτικές αδειοδοτήσεις διπλωμάτων ευρεσιτεχνίας](https://www.eff.org/document/hacking-patent-system-2016).
-* **Διακυβέρνηση:** Ειδικά εάν και εφόσον έχει νόημα να μεταφερθεί ένα πρότζεκτ σε μια [νομική οντότητα εκτός της εταιρείας](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
+* **Διακυβέρνηση:** Ειδικά εάν και εφόσον έχει νόημα να μεταφερθεί ένα πρότζεκτ σε μια [νομική οντότητα εκτός της εταιρείας](../leadership-and-governance/#χρειάζομαι-μια-νομική-οντότητα-για-να υποστηρίξω-το-πρότζεκτ-μου).

From 6d8823800d90202bdaa5f6b772efddbe62d8b8d0 Mon Sep 17 00:00:00 2001
From: christolis <work@chris-sdogkos.com>
Date: Wed, 21 Sep 2022 17:03:13 +0100
Subject: [PATCH 401/749] Fix 3 more HTML-Proofer failures

---
 _articles/el/building-community.md | 2 +-
 _articles/el/legal.md              | 2 +-
 _articles/el/starting-a-project.md | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index 9a194818300..48f086364c7 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -34,7 +34,7 @@ related:
 
 * **Όταν κάποιος νέος μπαίνει στο έργο σας, ευχαριστήστε τον για το ενδιαφέρον του!** Αρκεί μια αρνητική εμπειρία για να κάνει κάποιον να μην θέλει να επιστρέψει.
 * **Ανταποκριθείτε.** Αν δεν απαντήσετε στο θέμα τους για ένα μήνα, οι πιθανότητες είναι ότι έχουν ήδη ξεχάσει το έργο σας.
-* **Να είστε ανοιχτόμυαλοι όσον αφορά τους τύπους συνεισφορών που θα δεχτείτε.** Πολλοί συνεισφέροντες ξεκινούν με μια αναφορά σφάλματος ή μια μικρή διόρθωση. Υπάρχουν [πολλοί τρόποι συνεισφοράς](../how-to-contribute/#what-it-means-to-contribute) σε ένα πρότζεκτ. Αφήστε τους ανθρώπους να βοηθήσουν με τον τρόπο που θέλουν να βοηθήσουν.
+* **Να είστε ανοιχτόμυαλοι όσον αφορά τους τύπους συνεισφορών που θα δεχτείτε.** Πολλοί συνεισφέροντες ξεκινούν με μια αναφορά σφάλματος ή μια μικρή διόρθωση. Υπάρχουν [πολλοί τρόποι συνεισφοράς](../how-to-contribute/#τι-σημαίνει-να-συνεισφέρετε) σε ένα πρότζεκτ. Αφήστε τους ανθρώπους να βοηθήσουν με τον τρόπο που θέλουν να βοηθήσουν.
 * **Αν υπάρχει μια συνεισφορά με την οποία διαφωνείτε,** ευχαριστήστε τους για την ιδέα τους και [εξηγήστε γιατί](../best-practices/#μαθαίνοντας-να-λέτε-όχι) δεν ταιριάζει στο πεδίο εφαρμογής του πρότζεκτυ, παραπέμποντας στη σχετική τεκμηρίωση αν την έχετε.
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/el/legal.md b/_articles/el/legal.md
index 9c4e8dd6b7a..d0d754f2fcc 100644
--- a/_articles/el/legal.md
+++ b/_articles/el/legal.md
@@ -155,4 +155,4 @@ related:
 </aside>
 
 * **Διπλώματα ευρεσιτεχνίας:** Η εταιρεία σας μπορεί να επιθυμεί να ενταχθεί στο [Open Invention Network](https://www.openinventionnetwork.com/), μια κοινή αμυντική δεξαμενή διπλωμάτων ευρεσιτεχνίας για την προστασία της χρήσης μεγάλων πρότζεκτ ανοικτού κώδικα από τα μέλη, ή να διερευνήσει άλλες [εναλλακτικές αδειοδοτήσεις διπλωμάτων ευρεσιτεχνίας](https://www.eff.org/document/hacking-patent-system-2016).
-* **Διακυβέρνηση:** Ειδικά εάν και εφόσον έχει νόημα να μεταφερθεί ένα πρότζεκτ σε μια [νομική οντότητα εκτός της εταιρείας](../leadership-and-governance/#χρειάζομαι-μια-νομική-οντότητα-για-να υποστηρίξω-το-πρότζεκτ-μου).
+* **Διακυβέρνηση:** Ειδικά εάν και εφόσον έχει νόημα να μεταφερθεί ένα πρότζεκτ σε μια [νομική οντότητα εκτός της εταιρείας](../leadership-and-governance/#χρειάζομαι-μια-νομική-οντότητα-για-να-υποστηρίξω-το-πρότζεκτ-μου).
diff --git a/_articles/el/starting-a-project.md b/_articles/el/starting-a-project.md
index 8af7812bf76..c714ae3fd54 100644
--- a/_articles/el/starting-a-project.md
+++ b/_articles/el/starting-a-project.md
@@ -20,7 +20,7 @@ related:
 
 Ο ανοικτός κώδικας είναι ισχυρός επειδή μειώνει τα εμπόδια στην υιοθέτηση και τη συνεργασία, επιτρέποντας στους ανθρώπους να διαδίδουν και να βελτιώνουν πρότζεκτ γρήγορα. Επίσης, επειδή δίνει στους χρήστες τη δυνατότητα να ελέγχουν τους υπολογιστές τους, σε σχέση με τον κλειστό κώδικα. Για παράδειγμα, μια επιχείρηση που χρησιμοποιεί λογισμικό ανοικτού κώδικα έχει τη δυνατότητα να προσλάβει κάποιον για να κάνει προσαρμοσμένες βελτιώσεις στο λογισμικό, αντί να βασίζεται αποκλειστικά στις αποφάσεις ενός προμηθευτή κλειστού κώδικα για το προϊόν.
 
-Το _ελεύθερο λογισμικό_ αναφέρεται στο ίδιο σύνολο πρότζεκτ με το _ανοικτού κώδικα_. Μερικές φορές θα δείτε επίσης [αυτούς τους όρους](https://en.wikipedia.org/wiki/Free_and_open-source_software) συνδυασμένους ως "ελεύθερο λογισμικό και λογισμικό ανοικτού κώδικα" (FOSS) ή "ελεύθερο, ελεύθερο και λογισμικό ανοικτού κώδικα" (FLOSS). Τα _Free_ και _libre_ αναφέρονται στην ελευθερία, [όχι στην τιμή](#does-open-source-mean-free-of-charge).
+Το _ελεύθερο λογισμικό_ αναφέρεται στο ίδιο σύνολο πρότζεκτ με το _ανοικτού κώδικα_. Μερικές φορές θα δείτε επίσης [αυτούς τους όρους](https://en.wikipedia.org/wiki/Free_and_open-source_software) συνδυασμένους ως "ελεύθερο λογισμικό και λογισμικό ανοικτού κώδικα" (FOSS) ή "ελεύθερο, ελεύθερο και λογισμικό ανοικτού κώδικα" (FLOSS). Τα _Free_ και _libre_ αναφέρονται στην ελευθερία, [όχι στην τιμή](#ανοιχτός-κώδικας-σημαίνει-δωρεάν).
 
 ### Γιατί οι άνθρωποι ανοίγουν το λογισμικό τους;
 

From 86836a578c40356252ecca30d0585323468629e0 Mon Sep 17 00:00:00 2001
From: christolis <work@chris-sdogkos.com>
Date: Wed, 21 Sep 2022 17:13:33 +0100
Subject: [PATCH 402/749] Fix broken blog links

---
 _articles/el/best-practices.md | 2 +-
 _articles/el/legal.md          | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
index 886581b8fb7..2e1c5d4922c 100644
--- a/_articles/el/best-practices.md
+++ b/_articles/el/best-practices.md
@@ -265,7 +265,7 @@ related:
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   Διατηρώντας το WP-CLI, ανακάλυψα ότι πρέπει πρώτα να κάνω τον εαυτό μου ευτυχισμένο και να θέσω σαφή όρια στη συμμετοχή μου. Η καλύτερη ισορροπία που έχω βρει είναι 2-5 ώρες την εβδομάδα, ως μέρος του κανονικού μου προγράμματος εργασίας. Αυτό κρατάει τη συμμετοχή μου ως πάθος και δεν την αισθάνομαι υπερβολικά σαν δουλειά. Επειδή ιεραρχώ τα θέματα στα οποία εργάζομαι, μπορώ να σημειώνω τακτική πρόοδο σε ό,τι θεωρώ πιο σημαντικό.
   <p markdown="1" class="pquote-credit">
-- @danielbachhuber, ["Τα συλλυπητήριά μου, είστε τώρα ο συντηρητής ενός δημοφιλούς πρότζεκτ ανοικτού κώδικα"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+- @danielbachhuber, ["Τα συλλυπητήριά μου, είστε τώρα ο συντηρητής ενός δημοφιλούς πρότζεκτ ανοικτού κώδικα"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
diff --git a/_articles/el/legal.md b/_articles/el/legal.md
index d0d754f2fcc..5ab29f60d36 100644
--- a/_articles/el/legal.md
+++ b/_articles/el/legal.md
@@ -145,7 +145,7 @@ related:
 </aside>
 
 * **Τι να δημοσιεύσετε:** [(Σχεδόν) τα πάντα;](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Εάν η νομική σας ομάδα κατανοεί και έχει επενδύσει στη στρατηγική ανοικτού κώδικα της εταιρείας σας, θα είναι σε θέση να βοηθήσει καλύτερα παρά να εμποδίσει τις προσπάθειές σας.
-* **Συμμόρφωση:** Ακόμα και αν η εταιρεία σας δεν εκδίδει πρότζεκτ ανοικτού κώδικα, χρησιμοποιεί λογισμικό ανοικτού κώδικα άλλων. Η [Ενημέρωση και διαδικασία](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) μπορεί να αποτρέψει πονοκεφάλους, καθυστερήσεις προϊόντων και αγωγές.
+* **Συμμόρφωση:** Ακόμα και αν η εταιρεία σας δεν εκδίδει πρότζεκτ ανοικτού κώδικα, χρησιμοποιεί λογισμικό ανοικτού κώδικα άλλων. Η [Ενημέρωση και διαδικασία](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) μπορεί να αποτρέψει πονοκεφάλους, καθυστερήσεις προϊόντων και αγωγές.
 
 <aside markdown="1" class="pquote">
   Οι οργανισμοί πρέπει να διαθέτουν μια στρατηγική αδειοδότησης και συμμόρφωσης που να ταιριάζει και στις δύο κατηγορίες \["επιτρεπτή" και "copyleft"\]. Αυτό ξεκινά με την τήρηση αρχείου των όρων αδειοδότησης που ισχύουν για το λογισμικό ανοικτού κώδικα που χρησιμοποιείτε - συμπεριλαμβανομένων των υποσυνιστωσών και των εξαρτήσεων.

From e4b93e71b0b8abda61e08e585c07fde7c23bc05c Mon Sep 17 00:00:00 2001
From: christolis <work@chris-sdogkos.com>
Date: Wed, 21 Sep 2022 17:32:20 +0100
Subject: [PATCH 403/749] Correct certain parts in how-to-contribute.md

---
 _articles/el/how-to-contribute.md | 18 ++++--------------
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/_articles/el/how-to-contribute.md b/_articles/el/how-to-contribute.md
index 9c5db70be9e..e63ec27bd4c 100644
--- a/_articles/el/how-to-contribute.md
+++ b/_articles/el/how-to-contribute.md
@@ -70,16 +70,6 @@ related:
   </p>
 </aside>
 
-## Γιατί να συνεισφέρετε στον ανοιχτό κώδικα; <aside markdown="1" class="pquote">
-
-<img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
-  Η εργασία στο \[freenode\] με βοήθησε να αποκτήσω πολλές από τις δεξιότητες που χρησιμοποίησα αργότερα για τις σπουδές μου στο πανεπιστήμιο και την πραγματική μου δουλειά.
-  Νομίζω ότι η εργασία σε έργα ανοιχτού κώδικα βοηθάει εμένα όσο βοηθάει και το έργο! <p markdown="1" class="pquote-credit"> Μου έδιναν μια πολύ καλή αφορμή για να ζητήσω διευκρινίσεις σχετικά με ένα θέμα, αλλά το πιο κρίσιμο ήταν ότι μπορούσα να παρατηρήσω πότε κάποιος επισήμανε κάτι που έπρεπε να διορθωθεί.
-  <p markdown="1" class="pquote-credit">
-- @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### Σας αρέσει να προγραμματίζετε εκδηλώσεις;
 
 * Οργανώστε εργαστήρια ή συναντήσεις για το έργο, [όπως έκανε ο @fzamperin για το NodeSchool](https://github.com/nodeschool/organizers/issues/406)
@@ -180,10 +170,10 @@ related:
 
 Ένα έργο διαθέτει επίσης τεκμηρίωση. Αυτά τα αρχεία συνήθως παρατίθενται στο κορυφαίο επίπεδο ενός αποθετηρίου.
 
-* **ΑΔΕΙΑ ΑΝΟΙΚΤΟΥ ΚΩΔΙΚΟΥ:** Εξ ορισμού, κάθε έργο ανοικτού κώδικα πρέπει να έχει μια [άδεια ανοικτού κώδικα](https://choosealicense.com). Εάν το έργο δεν έχει άδεια χρήσης, δεν είναι ανοικτού κώδικα.
+* **LICENSE:** Εξ ορισμού, κάθε έργο ανοικτού κώδικα πρέπει να έχει μια [άδεια ανοικτού κώδικα](https://choosealicense.com). Εάν το έργο δεν έχει άδεια χρήσης, δεν είναι ανοικτού κώδικα.
 * **README:** Το README είναι το εγχειρίδιο οδηγιών που καλωσορίζει τα νέα μέλη της κοινότητας στο έργο. Εξηγεί γιατί το έργο είναι χρήσιμο και πώς να ξεκινήσετε.
-* **ΣΥΜΒΟΛΗ:** Ενώ τα README βοηθούν τους ανθρώπους να _χρησιμοποιήσουν_ το έργο, τα έγγραφα συνεισφοράς βοηθούν τους ανθρώπους να _εισφέρουν_ στο έργο. Εξηγεί τι είδους συνεισφορές χρειάζονται και πώς λειτουργεί η διαδικασία. Αν και δεν έχει κάθε έργο ένα αρχείο CONTRIBUTING, η παρουσία του σηματοδοτεί ότι το έργο είναι φιλόξενο για συνεισφορά.
-* **ΚΩΔΙΚΑΣ_ΔΕΟΝΤΟΛΟΓΙΑΣ:** Ο κώδικας δεοντολογίας θέτει βασικούς κανόνες για τη συμπεριφορά των συμμετεχόντων που σχετίζονται και βοηθά στη διευκόλυνση ενός φιλικού, φιλόξενου περιβάλλοντος. Αν και δεν έχει κάθε έργο ένα αρχείο CODE_OF_CONDUCT, η παρουσία του σηματοδοτεί ότι πρόκειται για ένα φιλόξενο έργο στο οποίο μπορείτε να συνεισφέρετε.
+* **CONTRIBUTING:** Ενώ τα README βοηθούν τους ανθρώπους να _χρησιμοποιήσουν_ το έργο, τα έγγραφα συνεισφοράς βοηθούν τους ανθρώπους να _εισφέρουν_ στο έργο. Εξηγεί τι είδους συνεισφορές χρειάζονται και πώς λειτουργεί η διαδικασία. Αν και δεν έχει κάθε έργο ένα αρχείο CONTRIBUTING, η παρουσία του σηματοδοτεί ότι το έργο είναι φιλόξενο για συνεισφορά.
+* **CODE_OF_CONDUCT:** Ο κώδικας δεοντολογίας θέτει βασικούς κανόνες για τη συμπεριφορά των συμμετεχόντων που σχετίζονται και βοηθά στη διευκόλυνση ενός φιλικού, φιλόξενου περιβάλλοντος. Αν και δεν έχει κάθε έργο ένα αρχείο CODE_OF_CONDUCT, η παρουσία του σηματοδοτεί ότι πρόκειται για ένα φιλόξενο έργο στο οποίο μπορείτε να συνεισφέρετε.
 * **Άλλη τεκμηρίωση:** Ενδέχεται να υπάρχει πρόσθετη τεκμηρίωση, όπως σεμινάρια, οδηγίες χρήσης ή πολιτικές διακυβέρνησης, ειδικά σε μεγαλύτερα έργα.
 
 Τέλος, τα έργα ανοικτού κώδικα χρησιμοποιούν τα ακόλουθα εργαλεία για την οργάνωση της συζήτησης. Η ανάγνωση των αρχείων θα σας δώσει μια καλή εικόνα για το πώς σκέφτεται και λειτουργεί η κοινότητα.
@@ -525,4 +515,4 @@ related:
 
 ## Τα καταφέρατε!
 
-Είτε μόλις κάνατε την πρώτη σας συνεισφορά σε ανοιχτό κώδικα, είτε ψάχνετε για νέους τρόπους συνεισφοράς, ελπίζουμε να εμπνευστείτε για να αναλάβετε δράση. Ακόμα και αν η συνεισφορά σας δεν έγινε αποδεκτή, μην ξεχνάτε να λέτε ευχαριστώ όταν ένας συντηρητής κατέβαλε προσπάθεια για να σας βοηθήσει. Ο ανοιχτός κώδικας δημιουργείται από ανθρώπους σαν εσάς: ένα θέμα, ένα αίτημα διανομής, ένα σχόλιο ή ένα "high-five" κάθε φορά.
+Είτε μόλις κάνατε την πρώτη σας συνεισφορά σε ανοιχτό κώδικα, είτε ψάχνετε για νέους τρόπους συνεισφοράς, ελπίζουμε να εμπνευστείτε για να αναλάβετε δράση. Ακόμα και αν η συνεισφορά σας δεν έγινε αποδεκτή, μην ξεχνάτε να λέτε ευχαριστώ όταν ένας συντηρητής κατέβαλε προσπάθεια για να σας βοηθήσει. Ο ανοιχτός κώδικας δημιουργείται από ανθρώπους σαν εσάς: ένα θέμα, ένα αίτημα διανομής, ένα σχόλιο ή ένα "κόλλα-πέντε" κάθε φορά.

From 94feb4c5c0860207c61723a83a24ce4a6d748b01 Mon Sep 17 00:00:00 2001
From: christolis <work@chris-sdogkos.com>
Date: Wed, 21 Sep 2022 17:51:08 +0100
Subject: [PATCH 404/749] Fix some formatting issues and replace some words

---
 _articles/el/code-of-conduct.md    | 2 +-
 _articles/el/legal.md              | 4 ++--
 _articles/el/starting-a-project.md | 8 ++++----
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/_articles/el/code-of-conduct.md b/_articles/el/code-of-conduct.md
index f007e8bdb4e..224c4130567 100644
--- a/_articles/el/code-of-conduct.md
+++ b/_articles/el/code-of-conduct.md
@@ -29,7 +29,7 @@ related:
 * Τι συμβαίνει αν κάποιος παραβιάσει τον κώδικα συμπεριφοράς
 * Πώς μπορεί κάποιος να αναφέρει παραβιάσεις
 
-Όπου μπορείτε, χρησιμοποιήστε την προϋπάρχουσα τέχνη. Το [Contributor Covenant] (https://contributor-covenant.org/) είναι ένας drop-in κώδικας συμπεριφοράς που χρησιμοποιείται από πάνω από 40.000 έργα ανοικτού κώδικα, συμπεριλαμβανομένων των Kubernetes, Rails και Swift.
+Όπου μπορείτε, χρησιμοποιήστε την προϋπάρχουσα τέχνη. Το [Contributor Covenant](https://contributor-covenant.org/) είναι ένας drop-in κώδικας συμπεριφοράς που χρησιμοποιείται από πάνω από 40.000 έργα ανοικτού κώδικα, συμπεριλαμβανομένων των Kubernetes, Rails και Swift.
 
 Ο [Django Code of Conduct](https://www.djangoproject.com/conduct/) και ο [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) είναι επίσης δύο καλά παραδείγματα κώδικα συμπεριφοράς.
 
diff --git a/_articles/el/legal.md b/_articles/el/legal.md
index 5ab29f60d36..c7681ed7658 100644
--- a/_articles/el/legal.md
+++ b/_articles/el/legal.md
@@ -105,8 +105,8 @@ related:
 Ορισμένες περιπτώσεις στις οποίες μπορεί να θέλετε να εξετάσετε το ενδεχόμενο σύναψης πρόσθετης συμφωνίας συνεισφοράς για το πρότζεκτ σας περιλαμβάνουν:
 
 * Οι δικηγόροι σας θέλουν όλοι οι συνεισφέροντες να αποδέχονται ρητά (_υπογράφουν_, online ή offline) τους όρους συνεισφοράς, ίσως επειδή θεωρούν ότι η ίδια η άδεια ανοιχτού κώδικα δεν είναι αρκετή (παρόλο που είναι!). Εάν αυτό είναι το μόνο πρόβλημα, μια συμφωνία συνεισφοράς που επιβεβαιώνει την άδεια χρήσης ανοικτού κώδικα του έργου θα πρέπει να είναι αρκετή. Η [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) είναι ένα καλό παράδειγμα μιας ελαφριάς πρόσθετης συμφωνίας συνεισφοράς.
-* Εσείς ή οι δικηγόροι σας θέλετε οι προγραμματιστές να δηλώνουν ότι κάθε δέσμευση που κάνουν είναι εξουσιοδοτημένη. Η απαίτηση [Πιστοποιητικό προέλευσης προγραμματιστή] (https://developercertificate.org/) είναι ο τρόπος με τον οποίο πολλά πρότζεκτ το επιτυγχάνουν αυτό. Για παράδειγμα, η κοινότητα Node.js [χρησιμοποιεί](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) το DCO [αντί](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) του προηγούμενου CLA. Μια απλή επιλογή για να αυτοματοποιήσετε την επιβολή του DCO στο αποθετήριο σας είναι το [DCO Probot](https://github.com/probot/dco).
-* Το πρότζεκτ σας χρησιμοποιεί μια άδεια χρήσης ανοικτού κώδικα που δεν περιλαμβάνει ρητή παραχώρηση διπλωμάτων ευρεσιτεχνίας (όπως η MIT) και χρειάζεστε παραχώρηση διπλώματος ευρεσιτεχνίας από όλους τους συνεισφέροντες, ορισμένοι από τους οποίους μπορεί να εργάζονται σε εταιρείες με μεγάλα χαρτοφυλάκια διπλωμάτων ευρεσιτεχνίας που θα μπορούσαν να χρησιμοποιηθούν για να στοχεύσουν εσάς ή άλλους συνεισφέροντες και χρήστες του έργου. Η [Apache Individual Contributor License Agreement] (https://www.apache.org/licenses/icla.pdf) είναι μια ευρέως χρησιμοποιούμενη πρόσθετη συμφωνία συνεισφοράς που έχει μια παραχώρηση διπλώματος ευρεσιτεχνίας που αντικατοπτρίζει αυτή που υπάρχει στην Άδεια Apache 2.0.
+* Εσείς ή οι δικηγόροι σας θέλετε οι προγραμματιστές να δηλώνουν ότι κάθε δέσμευση που κάνουν είναι εξουσιοδοτημένη. Η απαίτηση [Πιστοποιητικό προέλευσης προγραμματιστή](https://developercertificate.org/) είναι ο τρόπος με τον οποίο πολλά πρότζεκτ το επιτυγχάνουν αυτό. Για παράδειγμα, η κοινότητα Node.js [χρησιμοποιεί](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) το DCO [αντί](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) του προηγούμενου CLA. Μια απλή επιλογή για να αυτοματοποιήσετε την επιβολή του DCO στο αποθετήριο σας είναι το [DCO Probot](https://github.com/probot/dco).
+* Το πρότζεκτ σας χρησιμοποιεί μια άδεια χρήσης ανοικτού κώδικα που δεν περιλαμβάνει ρητή παραχώρηση διπλωμάτων ευρεσιτεχνίας (όπως η MIT) και χρειάζεστε παραχώρηση διπλώματος ευρεσιτεχνίας από όλους τους συνεισφέροντες, ορισμένοι από τους οποίους μπορεί να εργάζονται σε εταιρείες με μεγάλα χαρτοφυλάκια διπλωμάτων ευρεσιτεχνίας που θα μπορούσαν να χρησιμοποιηθούν για να στοχεύσουν εσάς ή άλλους συνεισφέροντες και χρήστες του έργου. Η [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) είναι μια ευρέως χρησιμοποιούμενη πρόσθετη συμφωνία συνεισφοράς που έχει μια παραχώρηση διπλώματος ευρεσιτεχνίας που αντικατοπτρίζει αυτή που υπάρχει στην Άδεια Apache 2.0.
 * Το πρότζεκτ σας τελεί υπό άδεια copyleft, αλλά πρέπει επίσης να διανείμετε μια ιδιόκτητη έκδοση του έργου. Θα χρειαστείτε κάθε συνεισφέροντα να σας εκχωρήσει τα πνευματικά δικαιώματα ή να σας παραχωρήσει (αλλά όχι στο κοινό) μια επιτρεπτική άδεια. Το [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) είναι ένα παράδειγμα αυτού του τύπου συμφωνίας.
 * Πιστεύετε ότι το πρότζεκτ σας μπορεί να χρειαστεί να αλλάξει άδειες χρήσης κατά τη διάρκεια της ζωής του και θέλετε οι συνεισφέροντες να συμφωνήσουν εκ των προτέρων σε τέτοιες αλλαγές.
 
diff --git a/_articles/el/starting-a-project.md b/_articles/el/starting-a-project.md
index c714ae3fd54..2b1d19ee7df 100644
--- a/_articles/el/starting-a-project.md
+++ b/_articles/el/starting-a-project.md
@@ -108,7 +108,7 @@ 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://help.github.com/articles/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 θα συνδέει αυτόματα το αρχείο σας όταν ένας συνεργάτης δημιουργεί ένα ζήτημα ή ανοίγει ένα αίτημα έλξης.
+Συνδέστε το αρχείο CONTRIBUTING από το README, ώστε να το βλέπουν περισσότεροι άνθρωποι. Εάν [τοποθετήσετε το αρχείο CONTRIBUTING στο αποθετήριο του έργου σας](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), το GitHub θα συνδέει αυτόματα το αρχείο σας όταν ένας συνεργάτης δημιουργεί ένα ζήτημα ή ανοίγει ένα pull request.
 
 ![Οδηγίες συνεισφοράς](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -229,7 +229,7 @@ related:
 
 Βεβαιωθείτε ότι το όνομα του έργου σας δεν παραβιάζει κανένα εμπορικό σήμα. Μια εταιρεία μπορεί να σας ζητήσει αργότερα να καταργήσετε το πρότζεκτ σας ή ακόμη και να κινηθεί νομικά εναντίον σας. Δεν αξίζει τον κόπο να το ρισκάρετε.
 
-Μπορείτε να ελέγξετε τη [WIPO Global Brand Database] (http://www.wipo.int/branddb/en/) για συγκρούσεις εμπορικών σημάτων. Αν είστε σε μια εταιρεία, αυτό είναι ένα από τα πράγματα με τα οποία μπορεί να σας βοηθήσει η [νομική ομάδα](../legal/).
+Μπορείτε να ελέγξετε τη [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) για συγκρούσεις εμπορικών σημάτων. Αν είστε σε μια εταιρεία, αυτό είναι ένα από τα πράγματα με τα οποία μπορεί να σας βοηθήσει η [νομική ομάδα](../legal/).
 
 Τέλος, κάντε μια γρήγορη αναζήτηση στο Google για το όνομα του έργου σας. Θα μπορούν οι άνθρωποι να βρουν εύκολα το πρότζεκτ σας; Εμφανίζεται κάτι άλλο στα αποτελέσματα της αναζήτησης που δεν θα θέλατε να δουν;
 
@@ -353,4 +353,4 @@ related:
 
 ## Τα καταφέρατε!
 
-Συγχαρητήρια για την ανοιχτή διάθεση του πρώτου σας έργου. Ανεξάρτητα από το αποτέλεσμα, η δημόσια εργασία είναι ένα δώρο στην κοινότητα. Με κάθε δέσμευση, σχόλιο και αίτηση έλξης, δημιουργείτε ευκαιρίες για τον εαυτό σας και για τους άλλους να μάθουν και να αναπτυχθούν.
+Συγχαρητήρια για την ανοιχτή διάθεση του πρώτου σας έργου. Ανεξάρτητα από το αποτέλεσμα, η δημόσια εργασία είναι ένα δώρο στην κοινότητα. Με κάθε δέσμευση, σχόλιο και pull request, δημιουργείτε ευκαιρίες για τον εαυτό σας και για τους άλλους να μάθουν και να αναπτυχθούν.

From 0a8f6804c3b331c8d6c59c29386e1ddc3f2e691c Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 22 Sep 2022 04:52:14 +0000
Subject: [PATCH 405/749] Bump actions/stale from 5 to 6

Bumps [actions/stale](https://github.com/actions/stale) from 5 to 6.
- [Release notes](https://github.com/actions/stale/releases)
- [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/stale/compare/v5...v6)

---
updated-dependencies:
- dependency-name: actions/stale
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/stale.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
index 08d441de157..0da66f40f54 100644
--- a/.github/workflows/stale.yml
+++ b/.github/workflows/stale.yml
@@ -8,7 +8,7 @@ jobs:
   stale:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/stale@v5
+    - uses: actions/stale@v6
       with:
         stale-pr-message: >
           This pull request has been automatically marked as stale because it has not

From 4a17f26a452771ce42d2630ad4a98a56b2a98572 Mon Sep 17 00:00:00 2001
From: Wey Gu <weyl.gu@gmail.com>
Date: Mon, 10 Oct 2022 15:27:23 +0800
Subject: [PATCH 406/749] chore: fixed wrong comma in Chinese

An English comma was used here, which should be a Chinese one.
---
 _articles/zh-hans/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md
index e1dd6ae8a63..6ce2f91161e 100644
--- a/_articles/zh-hans/starting-a-project.md
+++ b/_articles/zh-hans/starting-a-project.md
@@ -361,4 +361,4 @@ redirect_from: /zh-cn/starting-a-project/
 
 ## 你做到了!
 
-恭喜你开源了你的首个项目。不论结果如何，对开源社区都是一份礼物。随着每次commit,comment和pull request，你正在为自己或者他人创造学习和成长的机会。
+恭喜你开源了你的首个项目。不论结果如何，对开源社区都是一份礼物。随着每次commit，comment和pull request，你正在为自己或者他人创造学习和成长的机会。

From eb2241e18e39d64e30a5a87d8419422091a7a3fd Mon Sep 17 00:00:00 2001
From: Sergio Campbell Dev <51247757+SergioCampbell@users.noreply.github.com>
Date: Sun, 16 Oct 2022 22:53:47 -0500
Subject: [PATCH 407/749] Fixing commas and spanish expresions.

---
 _articles/es/best-practices.md | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/_articles/es/best-practices.md b/_articles/es/best-practices.md
index f1728729128..c8aee16a1d5 100644
--- a/_articles/es/best-practices.md
+++ b/_articles/es/best-practices.md
@@ -14,7 +14,7 @@ related:
 
 Si tu trabajo es mantener un proyecto de c&oacute;digo abierto que mucha gente usa, probablemente te hayas percatado que pasas m&aacute;s tiempo respondiendo issues que programando.
 
-En etapas tempranas de un proyecto, pasas tiempo experimentando con ideas nuevas y tomando decisiones en base a lo que te gusta. A medida que tu proyecto crece en popularidad, te encontrar&aacute;s en una situaci&oacute;n en la que trabajar&aacute;s con tus usuarios y colaboradores cada vez m&aacute;s.
+En etapas tempranas de un proyecto, pasas tiempo experimentando con ideas nuevas y tomando decisiones con base a lo que te gusta. A medida que tu proyecto crece en popularidad, te encontrar&aacute;s en una situaci&oacute;n en la que trabajar&aacute;s con tus usuarios y colaboradores cada vez m&aacute;s.
 
 Mantener un proyecto requiere m&aacute;s que solamente c&oacute;digo. Estas tareas no suelen ser tenidas en cuenta, pero son igual de importantes para un proyecto en crecimiento. Hemos reunido algunas ideas que har&aacute;n tu vida m&aacute;s f&aacute;cil, desde el proceso de documentaci&oacute;n hasta sacar el m&aacute;ximo provecho de la comunidad.
 
@@ -30,11 +30,12 @@ Aunque no seas del tipo de persona que escribe p&aacute;rrafos completos, tener
 
 ### Dejando en claro la visi&oacute;n de tu proyecto
 
-Comienza escribiendo los objetivos de tu proyecto. Agr&eacute;galos a tu archivo README, o crea un archivo separado llamado VISION. Si existen otros artefactos que puedan ayudar, como un mapa del proyecto, h&aacute;zlos p&uacute;blicos tambi&eacute;n
+Comienza escribiendo los objetivos de tu proyecto. Agr&eacute;galos a tu archivo README, o crea un archivo separado llamado VISION. Si existen otros artefactos que puedan ayudar, como un mapa del proyecto, h&aacute;zlos p&uacute;blicos tambi&eacute;n.
 
-Llevando una clara, documentada visi&oacute;n te mantiene en foco y ayuda a evitar el mal entendimiento del alcance por parte de otros colaboradores.
+Llevando una clara visi&oacute;n documentada, te mantiene en foco y ayuda a evitar el mal entendimiento del alcance por parte de otros colaboradores.
 
-Por ejemplo, @lord descubri&oacute; que tener la visi&oacute;n de un proyecto lo ayud&oacute; a darse cuenta que peticiones priorizar. Como un mantenedor de c&oacute;digo novato, se lament&oacute; de no ser fiel al alcance del proyecto cuando recibi&oacute; su primer pedido de funcionalidad por [Slate](https://github.com/lord/slate).
+Por ejemplo:
+@lord descubri&oacute; que tener la visi&oacute;n de un proyecto lo ayud&oacute; a darse cuenta que peticiones priorizar. Como un mantenedor de c&oacute;digo novato, se lament&oacute; de no ser fiel al alcance del proyecto cuando recibi&oacute; su primer pedido de funcionalidad por [Slate](https://github.com/lord/slate).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">

From 2a697670d105d7fd88933dbc78dc13ca1ee00ebc Mon Sep 17 00:00:00 2001
From: izzqz <v@izzqz.me>
Date: Mon, 28 Nov 2022 00:31:27 +0100
Subject: [PATCH 408/749] Add adaptive favicon

---
 _includes/head.html | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/_includes/head.html b/_includes/head.html
index df1ea4f4d07..74084a42cd3 100644
--- a/_includes/head.html
+++ b/_includes/head.html
@@ -2,7 +2,9 @@
   <meta charset="utf-8">
   <meta name="viewport" content="width=device-width, initial-scale=1">
   <meta name="google-site-verification" content="c1kuD-K2HIVF635lypcsWPoD4kilo5-jA_wBFyT4uMY" />
-  <link rel="icon" type="image/x-icon" href="https://github.githubassets.com/favicon.ico">
+  <link rel="icon" type="image/x-icon" href="https://github.githubassets.com/favicon.ico" media="(prefers-color-scheme:no-preference)">
+  <link rel="icon" type="image/png" href="https://github.githubassets.com/favicons/favicon.png" media="(prefers-color-scheme:light)">
+  <link rel="icon" type="image/png" href="https://github.githubassets.com/favicons/favicon-dark.png" media="(prefers-color-scheme:dark)">
   <link href="https://fonts.googleapis.com/css?family=Roboto:300,300i,400,400i,700,700i" rel="stylesheet">
   <link href='{{ "/assets/css/index.css" | relative_url }}' rel="stylesheet">
   {% seo %}

From ca1c27889066da19ef0b44240481ac0cf688443c Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Mon, 28 Nov 2022 23:09:27 +0100
Subject: [PATCH 409/749] Update Blog Link

The existing link 404s now, this updates it to the valid link.
---
 _articles/ko/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md
index b593d749f7b..71a86b36272 100644
--- a/_articles/ko/how-to-contribute.md
+++ b/_articles/ko/how-to-contribute.md
@@ -385,7 +385,7 @@ README를 스캔하여 깨진 링크나 오타를 찾을 수 있습니다. 또
   <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
   \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
   <p markdown="1" class="pquote-credit">
-— @shubheksha, [A Beginner’s Very Bumpy Journey Through The World of Open Source](https://medium.freecodecamp.com/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39#.pcswr2e78)
+— @shubheksha, [A Beginner’s Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
   </p>
 </aside>
 

From 080c98bc43effb93bd3717232c050faa51b1078d Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Mon, 28 Nov 2022 23:20:02 +0100
Subject: [PATCH 410/749] Make tests faster

---
 .github/workflows/tests.yml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 62802a9f7ef..850928f147e 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -20,6 +20,8 @@ jobs:
 
     - name: Bootstrap
       run: script/bootstrap
+      env:
+        SKIP_BUNDLER: true
 
     - name: Tests
       run: script/test

From 62545d341ed94812e91a05e7f09d962e5ef2b444 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Mon, 28 Nov 2022 23:21:30 +0100
Subject: [PATCH 411/749] Update bootstrap

---
 script/bootstrap | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/script/bootstrap b/script/bootstrap
index cf9af7cce45..8b850b7d73b 100755
--- a/script/bootstrap
+++ b/script/bootstrap
@@ -4,10 +4,12 @@ set -e
 
 cd "$(dirname "$0")/.."
 
-echo "==> Installing gem dependencies…"
-bundle check --path vendor/gems &>/dev/null || {
-  time bundle install --binstubs bin --path vendor/gems
-}
+if [[ -z "${SKIP_BUNDLE}" ]]; then
+  echo "==> Installing gem dependencies…"
+  bundle check --path vendor/gems &>/dev/null || {
+    time bundle install --binstubs bin --path vendor/gems
+  }
+fi
 
 echo "==> Installing node dependencies…"
 npm install

From ae8bc2c444b8a9a80fa4f6cd1cc8d2be0d204759 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Mon, 28 Nov 2022 23:22:42 +0100
Subject: [PATCH 412/749] Update bootstrap

---
 script/bootstrap | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/script/bootstrap b/script/bootstrap
index 8b850b7d73b..64d5b971319 100755
--- a/script/bootstrap
+++ b/script/bootstrap
@@ -4,7 +4,7 @@ set -e
 
 cd "$(dirname "$0")/.."
 
-if [[ -z "${SKIP_BUNDLE}" ]]; then
+if [[ -z "${SKIP_BUNDLER}" ]]; then
   echo "==> Installing gem dependencies…"
   bundle check --path vendor/gems &>/dev/null || {
     time bundle install --binstubs bin --path vendor/gems

From 93138932accec72ff0e5563f2eea0db71f135f99 Mon Sep 17 00:00:00 2001
From: WebSnke <websnke@tutanota.com>
Date: Sat, 10 Dec 2022 12:27:54 +0100
Subject: [PATCH 413/749] Remove redundant period

Fixes the sentence which would otherwise end with ".:".
---
 _data/locales/de.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_data/locales/de.yml b/_data/locales/de.yml
index 18399935054..d2891744842 100644
--- a/_data/locales/de.yml
+++ b/_data/locales/de.yml
@@ -5,7 +5,7 @@ de:
     contribute: Mitarbeiten
   index:
     lead: Open-Source-Software wird von Menschen wie Ihnen gemacht. Lernen Sie, wie Sie Ihr Projekt anfangen und ausbauen können.
-    opensourcefriday: Es ist Freitag! Investieren Sie ein paar Stunden in die Software, die Sie verwenden und lieben.
+    opensourcefriday: Es ist Freitag! Investieren Sie ein paar Stunden in die Software, die Sie verwenden und lieben
   article:
     table_of_contents: Inhaltsverzeichnis
     back_to_all_guides: Zurück zur Übersicht

From d1a1a25e076a2b790d671b896b6b3d4dc1c51a0f Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 21 Dec 2022 04:13:15 +0000
Subject: [PATCH 414/749] Bump actions/stale from 6 to 7

Bumps [actions/stale](https://github.com/actions/stale) from 6 to 7.
- [Release notes](https://github.com/actions/stale/releases)
- [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/stale/compare/v6...v7)

---
updated-dependencies:
- dependency-name: actions/stale
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/stale.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
index 0da66f40f54..f77f3c3e108 100644
--- a/.github/workflows/stale.yml
+++ b/.github/workflows/stale.yml
@@ -8,7 +8,7 @@ jobs:
   stale:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/stale@v6
+    - uses: actions/stale@v7
       with:
         stale-pr-message: >
           This pull request has been automatically marked as stale because it has not

From aa2de5acca0aa5dd3f33c4f7a339729fbba1e55e Mon Sep 17 00:00:00 2001
From: yionr <yionr99@gmail.com>
Date: Fri, 23 Dec 2022 09:08:56 +0800
Subject: [PATCH 415/749] Update legal.md

---
 _articles/zh-hans/legal.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index 8f8fd202722..59c633d5583 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -115,7 +115,8 @@ redirect_from: /zh-cn/legal/
 ## 公司的法律团队需要知道什么？
 
 作为一名公司的雇员，如果你们在发布一个开源项目，你们首先需要让法律团队知道。
-即使是个人项目，请考虑让他们知道。你们可能和公司有一个"员工知识产权协议"，这给了公司一些对你们项目的控制权，特别是当项目和公司的业务有着很多的联系或者你们使用公司的资源发展项目。你的公司 _应该_ 很容易地给你许可，也许已经通过一个员工友好的知识产权协议或公司政策。如果不是这样，你么可以谈判（例如，解释你们的项目为公司的专业学习和发展目标服务），或者你们在找到一个更好的公司前停止你们项目的工作。
+
+即使是个人项目，请考虑让他们知道。你们可能和公司有一个"员工知识产权协议"，这给了公司一些对你们项目的控制权，特别是当项目和公司的业务有着很多的联系或者你们使用公司的资源发展项目。你的公司 _应该_ 很容易地给你许可，也许已经通过一个员工友好的知识产权协议或公司政策。如果不是这样，你们可以谈判（例如，解释你们的项目为公司的专业学习和发展目标服务），或者在你们找到一个更好的公司前停止该项目的工作。
 
 **如果你们的开源项目是为了你们的公司，**那么绝对要让他们知道。根据公司的业务需求和专业知识，你们的法律团队可能已经制定了有关开放源代码许可协议（以及可能还有其他贡献者协议）的政策，以确保您的项目符合其依赖关系的许可协议。如果不是这样，你们和他们很幸运！你们的法律团队应该渴望与你们合作，把这个东西搞清楚。你们需要思考这些事：
 
@@ -130,7 +131,7 @@ redirect_from: /zh-cn/legal/
 
 * **隐私：**你们的项目是否收集了用户数据并存储到公司的服务器？你们的法律团队可以帮助你们遵守公司政策和外部法规。
 
-如果你们发布了公司的第一开源项目，为了能通过，以上这些绰绰有余（不要担心，大多数项目不会引起重大关注）。
+如果你们发布了公司的第一个开源项目，为了能通过，以上这些绰绰有余（不要担心，大多数项目不会引起重大关注）。
 长期来说，你们的法律团队可以做更多的事情，以帮助公司从开源中获得更多，并保持安全：
 
 * **员工贡献策略：**考虑制定一个公司策略，指明你们的员工如何为开源项目贡献。明确的政策将减少你们员工的迷惑，并帮助他们为公司的最佳利益向开源项目做贡献，无论是作为他们工作的一部分还是在自由时间。Rackspace的[Model IP和开源贡献策略](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)就是很好的示例。

From 8674de843b11391a5c2bc68ab343d79a1975f9a5 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Mon, 26 Dec 2022 09:53:36 -0500
Subject: [PATCH 416/749] Update links

---
 _articles/nl/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md
index 3d06316591b..738d8db6807 100644
--- a/_articles/nl/how-to-contribute.md
+++ b/_articles/nl/how-to-contribute.md
@@ -222,7 +222,7 @@ U kunt een README lezen en een incorrecte link of typefout vinden. Of je bent ee
 
 > [28% van de losse bijdragen](https://www.igor.pro.br/publica/papers/saner2016.pdf) aan open source zijn documentatie, zoals een typefout, herformattering of het schrijven van een vertaling.
 
-Als u op zoek bent naar bestaande problemen die u kunt oplossen, heeft elk open source-project een '/ contribute'-pagina die beginnersvriendelijke problemen belicht waarmee u kunt beginnen. Navigeer naar de hoofdpagina van de repository op GitHub en voeg '/ contribute' toe aan het einde van de URL (bijvoorbeeld [`https://github.com/facebook/react/contribute`](https://github.com/facebook/contribute/contribute)).
+Als u op zoek bent naar bestaande problemen die u kunt oplossen, heeft elk open source-project een '/ contribute'-pagina die beginnersvriendelijke problemen belicht waarmee u kunt beginnen. Navigeer naar de hoofdpagina van de repository op GitHub en voeg '/ contribute' toe aan het einde van de URL (bijvoorbeeld [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
 
 U kunt ook een van de volgende bronnen gebruiken om u te helpen bij het ontdekken van en bijdragen aan nieuwe projecten:
 

From b8380d23795d3c7fdc6f2e6cf5e35e3f25228a35 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Mon, 26 Dec 2022 10:00:15 -0500
Subject: [PATCH 417/749] Update best-practices.md

---
 _articles/el/best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
index 2e1c5d4922c..e4389724d1a 100644
--- a/_articles/el/best-practices.md
+++ b/_articles/el/best-practices.md
@@ -237,7 +237,7 @@ related:
 * Το [mention-bot](https://github.com/facebook/mention-bot) αναφέρει πιθανούς αναθεωρητές (reviewers) για τα pull requests
 * Το [Danger](https://github.com/danger/danger) βοηθά στην αυτοματοποίηση της αναθεώρησης κώδικα (code review)
 * Το [no-response](https://github.com/probot/no-response) κλείνει θέματα στα οποία ο συγγραφέας δεν έχει απαντήσει σε ένα αίτημα για περισσότερες πληροφορίες
-* Το [dependabot-preview](https://github.com/marketplace/dependabot-preview) ελέγχει τα αρχεία εξαρτήσεων σας κάθε μέρα για ξεπερασμένες απαιτήσεις και ανοίγει μεμονωμένα pull requests για όποια βρει
+* Το [dependabot](https://github.com/dependabot) ελέγχει τα αρχεία εξαρτήσεων σας κάθε μέρα για ξεπερασμένες απαιτήσεις και ανοίγει μεμονωμένα pull requests για όποια βρει
 
 Για αναφορές σφαλμάτων και άλλες κοινές συνεισφορές, το GitHub διαθέτει [Πρότυπα ζητημάτων και πρότυπα αιτημάτων](https://github.com/blog/2111-issue-and-pull-request-templates), τα οποία μπορείτε να δημιουργήσετε για να βελτιώσετε την επικοινωνία που λαμβάνετε. Ο @TalAter δημιούργησε έναν οδηγό [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) για να σας βοηθήσει να γράψετε τα πρότυπα των ζητημάτων και των PR σας.
 

From 98c97553d4d22cfee2374cb536129ef85df3d5eb Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Mon, 26 Dec 2022 10:05:37 -0500
Subject: [PATCH 418/749] Update building-community.md

---
 _articles/el/building-community.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index 48f086364c7..12d11d82e45 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -225,7 +225,7 @@ related:
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
   Ένα μέρος του λόγου για τον οποίο δεν υπάρχει ένα σύστημα ψηφοφορίας για τα θέματα Atom είναι επειδή η ομάδα Atom δεν πρόκειται να ακολουθήσει ένα σύστημα ψηφοφορίας σε όλες τις περιπτώσεις. Μερικές φορές πρέπει να επιλέγουμε αυτό που θεωρούμε σωστό ακόμα και αν δεν είναι δημοφιλές. (...) Αυτό που μπορώ να προσφέρω και δεσμεύομαι να κάνω... είναι ότι η δουλειά μου είναι να ακούω την κοινότητα.
   <p markdown="1" class="pquote-credit">
-- @lee-dohm on [Η διαδικασία λήψης αποφάσεων του Atom](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+- @lee-dohm on Η διαδικασία λήψης αποφάσεων του Atom
   </p>
 </aside>
 

From 9154070f0bbc004a694c50507de424a8a3ac9051 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@gmail.com>
Date: Tue, 3 Jan 2023 12:08:53 -0500
Subject: [PATCH 419/749] replace marketplace dependabot links

---
 _articles/best-practices.md    | 2 +-
 _articles/de/best-practices.md | 2 +-
 _articles/fa/best-practices.md | 2 +-
 _articles/hu/best-practices.md | 2 +-
 _articles/ms/best-practices.md | 2 +-
 _articles/nl/best-practices.md | 2 +-
 _articles/pl/best-practices.md | 2 +-
 _articles/ru/best-practices.md | 2 +-
 _articles/tr/best-practices.md | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/_articles/best-practices.md b/_articles/best-practices.md
index 6983f16e7a9..1ff41a65ed4 100644
--- a/_articles/best-practices.md
+++ b/_articles/best-practices.md
@@ -237,7 +237,7 @@ There are a [variety of tools available](https://github.com/showcases/tools-for-
 * [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
 * [Danger](https://github.com/danger/danger) helps automate code review
 * [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information
-* [dependabot-preview](https://github.com/marketplace/dependabot-preview) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
+* [dependabot](https://github.com/marketplace/dependabot) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
 
 For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.
 
diff --git a/_articles/de/best-practices.md b/_articles/de/best-practices.md
index 436422b0fe3..4a6f2d0b868 100644
--- a/_articles/de/best-practices.md
+++ b/_articles/de/best-practices.md
@@ -265,7 +265,7 @@ Viele Maintainer\*innen populärer Projekte sind mit ähnlichen Problemen konfro
 * [mention-bot](https://github.com/facebook/mention-bot) erwähnt potentielle Reviewer für Pull Requests
 * [Danger](https://github.com/danger/danger) hilft bei der Automatisierung des Code Review
 * [no-response](https://github.com/probot/no-response) schließt Issues deren Autor\*in nicht auf Nachfragen antwortet
-* [dependabot-preview](https://github.com/marketplace/dependabot-preview) prüft bekannte Abhängigkeitsdateien täglich und eröffnet Pull Requests, sobald Aktualisierungen verfügbar werden
+* [dependabot](https://github.com/marketplace/dependabot) prüft bekannte Abhängigkeitsdateien täglich und eröffnet Pull Requests, sobald Aktualisierungen verfügbar werden
 
 Für Fehlerberichte und andere allgemeine Beiträge hat GitHub [Issue- und Pull-Request-Templates](https://github.com/blog/2111-issue-and-pull-request-templates), die Sie erstellen können, um die Kommunikation zu optimieren. @TalAter hat einen [Choose Your Own Adventure Guide](https://www.talater.com/open-source-templates/#/) erstellt, der Ihnen beim Schreiben dieser Vorlagen hilft.
 
diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md
index 10262e5ab15..e6a46142e6e 100644
--- a/_articles/fa/best-practices.md
+++ b/_articles/fa/best-practices.md
@@ -237,7 +237,7 @@ related:
 * ابزار [mention-bot](https://github.com/facebook/mention-bot)، به بازبین‌های بالقوه برای «درخواست pull»ها خبر می دهد.
 * ابزار [Danger](https://github.com/danger/danger)، به بررسی و بازبینی اتوماتیک کد کمک می‌کند.
 * ابزار [no-response](https://github.com/probot/no-response)، مسائلی را که نویسنده به درخواست‌ها برای اطلاعات بیشتر پاسخ نداده است، می‌بندد.
-* ابزار [dependabot-preview](https://github.com/marketplace/dependabot-preview)، هر روز «فایل‌های وابسته» (مثل کتابخانه‌ها یا کلاس‌های جانبی یا ماژول‌ها) شما را از نظر الزامات منسوخ شده بررسی می‌کند و «درخواست‌های pull» را برای هر موردی که پیدا می‌کند، باز می‌کند.
+* ابزار [dependabot](https://github.com/marketplace/dependabot)، هر روز «فایل‌های وابسته» (مثل کتابخانه‌ها یا کلاس‌های جانبی یا ماژول‌ها) شما را از نظر الزامات منسوخ شده بررسی می‌کند و «درخواست‌های pull» را برای هر موردی که پیدا می‌کند، باز می‌کند.
 
 برای گزارش اشکالات (bug) و سایر مشارکت‌های متداول، GitHub دارای [قالب‌های طرح مشکل و قالب‌های درخواست‌های pull](https://github.com/blog/2111-issue-and-pull-request-templates) است، که می‌توانید برای کارآمد ساختن ارتباطاتی که دریافت می‌کنید، استفاده کنید. «TalAter»، برای کمک کردن به شما برای طرح مشکلات و مسائل روابط عمومی (PR templates)، ابزار [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) را ساخت.
 
diff --git a/_articles/hu/best-practices.md b/_articles/hu/best-practices.md
index 05ea08b23c7..931b5a8341d 100644
--- a/_articles/hu/best-practices.md
+++ b/_articles/hu/best-practices.md
@@ -237,7 +237,7 @@ A jó hír egy népszerű projekt fenntartásához az, hogy más karbantartók v
 * [mention-bot](https://github.com/facebook/mention-bot) a beolvasztási kérelemben megemlíti automatikusan a lehetséges embereket, akik a kódot majd átnézik (kód review)
 * [Danger](https://github.com/danger/danger) segít automatizálni a kód review-t
 * [no-response](https://github.com/probot/no-response) lezárja azokat az issue-kat, amelyekben az issue szerzője nem válaszolt a további információkérésre
-* [dependabot-preview](https://github.com/marketplace/dependabot-preview) minden nap ellenőrzi a függőségeket, ha talál frissebb verziót, akkor automatikusan beolvasztási kérelmet készít az új verzió számmal
+* [dependabot](https://github.com/marketplace/dependabot) minden nap ellenőrzi a függőségeket, ha talál frissebb verziót, akkor automatikusan beolvasztási kérelmet készít az új verzió számmal
 
 A hiba jelzésekhez és más általános hozzájárulásokhoz a GitHub biztosít egy [hiba jelzés és beolvasztási kérelem formanyomtatványt](https://github.com/blog/2111-issue-and-pull-request-templates), amellyel egyszerűsíteni és egységesíteni tudod ezek beadását. @TalAter készített egy [Választásos Kalandjátékot](https://www.talater.com/open-source-templates/#/) hogy segítse ezen formanyomtatványok elkészítését.
 
diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md
index bd6758a3426..e27b8a34757 100644
--- a/_articles/ms/best-practices.md
+++ b/_articles/ms/best-practices.md
@@ -237,7 +237,7 @@ Terdapat [pelbagai alat tersedia](https://github.com/showcases/tools-for-open-so
 * [mention-bot](https://github.com/facebook/mention-bot) menyebut pengulas berpotensi untuk permintaan tarik
 * [Danger](https://github.com/danger/danger) membantu mengautomasikan semakan kod
 * [no-response](https://github.com/probot/no-response) menutup masalah di mana pengarang tidak menjawab permintaan untuk mendapatkan maklumat lebih lanjut
-* [dependabot-preview](https://github.com/marketplace/dependabot-preview) memeriksa fail kebergantungan anda setiap hari untuk keperluan yang ketinggalan zaman dan membuka permintaan tarikan individu untuk apa sahaja yang dijumpainya
+* [dependabot](https://github.com/marketplace/dependabot) memeriksa fail kebergantungan anda setiap hari untuk keperluan yang ketinggalan zaman dan membuka permintaan tarikan individu untuk apa sahaja yang dijumpainya
 
 Fatau laporan pepijat dan sumbangan umum lain, GitHub mempunyai [Templat Masalah dan Templat Tarik Permintaan] (<https://github.com/blog/2111-issue-and-pull-request-templates>), yang boleh anda buat untuk melancarkan komunikasi anda terima. @TalAter membuat [Pilih panduan Pengembaraan Anda Sendiri] (<https://www.talater.com/open-source-templates/#/>) untuk membantu anda menulis isu dan templat PR anda.
 
diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index cd2546fc8fd..22901951592 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -255,7 +255,7 @@ Een paar voorbeelden:
 * [mention-bot](https://github.com/facebook/mention-bot) vermeldt potentiële reviewers voor pull-aanvragen
 * [Danger](https://github.com/danger/danger) helpt bij het automatiseren van codebeoordeling
 * [no-response](https://github.com/probot/no-response) sluit issues af waarbij de auteur niet heeft gereageerd op een verzoek om meer informatie
-* [dependabot-preview](https://github.com/marketplace/dependabot-preview) controleert uw afhankelijkheidsbestanden elke dag op verouderde vereisten en opent individuele pull-verzoeken voor alle gevonden items
+* [dependabot](https://github.com/marketplace/dependabot) controleert uw afhankelijkheidsbestanden elke dag op verouderde vereisten en opent individuele pull-verzoeken voor alle gevonden items
 
 Voor bugrapporten en andere veelvoorkomende bijdragen heeft GitHub [Issue-sjablonen en Pull Request-sjablonen](https://github.com/blog/2111-issue-and-pull-request-templates), die u kunt maken om de communicatie die u ontvangt te stroomlijnen. @TalAter heeft een [Kies je eigen avonturengids](https://www.talater.com/open-source-templates/#/) gemaakt om u te helpen bij het schrijven van uw issue en PR-sjablonen.
 
diff --git a/_articles/pl/best-practices.md b/_articles/pl/best-practices.md
index 84f00a234d2..7078923fa58 100644
--- a/_articles/pl/best-practices.md
+++ b/_articles/pl/best-practices.md
@@ -242,7 +242,7 @@ Dostępnych jest [wiele dostępnych narzędzi](https://github.com/showcases/tool
 * [mention-bot](https://github.com/facebook/mention-bot) wymienia potencjalnych recenzentów dla pull requestów
 * [Danger](https://github.com/danger/danger) pomaga zautomatyzować code review
 * [no-response](https://github.com/probot/no-response) zamyka issues gdzie autor nie odpowiedział na request lub więcej informacji
-* [dependabot-preview](https://github.com/marketplace/dependabot-preview) sprawdza pliki zależności każdego dnia pod kątem nieaktualnych wymagań i otwiera indywidualne pull requesty dla każdego, kogo znajdzie
+* [dependabot](https://github.com/marketplace/dependabot) sprawdza pliki zależności każdego dnia pod kątem nieaktualnych wymagań i otwiera indywidualne pull requesty dla każdego, kogo znajdzie
 
 W przypadku raportów o błędach i innych typowych treści GitHub ma [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), które możesz utworzyć, aby usprawnić otrzymywaną komunikację. @TalAter stworzył [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) aby pomóc Ci napisać swój issue i szablony PR.
 
diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md
index 02265cc824d..e9fffc71d8f 100644
--- a/_articles/ru/best-practices.md
+++ b/_articles/ru/best-practices.md
@@ -237,7 +237,7 @@ related:
 * [mention-bot](https://github.com/facebook/mention-bot) упоминает потенциальных ревьюеров для пул-реквеста
 * [Danger](https://github.com/danger/danger) помогает автоматизировать проверку кода
 * [no-response](https://github.com/probot/no-response) закрывает ишью, если автор не предоставил дополнительную информацию
-* [dependabot-preview](https://github.com/marketplace/dependabot-preview) ежедневно следует за актуальностью зависимостей, и если находит что-то новое, то открывает отдельные пул-реквесты
+* [dependabot](https://github.com/marketplace/dependabot) ежедневно следует за актуальностью зависимостей, и если находит что-то новое, то открывает отдельные пул-реквесты
 
 Для сообщений об ошибках и других общих проблем на GitHub есть [шаблоны для ишью и пул-реквеста](https://github.com/blog/2111-issue-and-pull-request-templates), которые можно создать для упрощения взаимодействия с сообществом. @TalAter создал [руководство Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/), чтобы помочь вам написать собственные шаблоны ишью и пул-реквеста.
 
diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md
index 602299eeb96..95cd3a8ed5b 100644
--- a/_articles/tr/best-practices.md
+++ b/_articles/tr/best-practices.md
@@ -237,7 +237,7 @@ Bakım çalışmalarının bazı yönlerini otomatikleştirmeye yardımcı olaca
 * [mention-bot](https://github.com/facebook/mention-bot) PR talepleri için potansiyel denetçilerden bahseder
 * [Danger](https://github.com/danger/danger) kod incelemesini otomatikleştirmeye yardımcı olur
 * [no-response](https://github.com/probot/no-response) geliştiricilerin uzun süre yanıt vermediği sorunları kapatır
-* [dependabot-preview](https://github.com/marketplace/dependabot-preview) bağımlılık dosyalarınızı her gün eski gereksinimler için kontrol eder ve bulduğu her biri için PR istekleri açar
+* [dependabot](https://github.com/marketplace/dependabot) bağımlılık dosyalarınızı her gün eski gereksinimler için kontrol eder ve bulduğu her biri için PR istekleri açar
 
 Hata raporları ve diğer genel katkılar için GitHub, aldığınız iletişimi kolaylaştırmak için oluşturabileceğiniz [Sorun Şablonlarına ve PR İsteği Şablonlarına](https://github.com/blog/2111-issue-and-pull-request-templates) sahiptir. @TalAter sorununuzu ve PR şablonlarınızı yazmanıza yardımcı olmak için [Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/) rehberini geliştirdi.
 

From 0a104a857b0f93b1a7a2c9050e4f005fc1d1d27b Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@gmail.com>
Date: Tue, 3 Jan 2023 12:25:56 -0500
Subject: [PATCH 420/749] remove ariya blockquotes

---
 _articles/de/finding-users.md | 12 ------------
 _articles/el/finding-users.md | 10 +---------
 _articles/es/finding-users.md |  8 --------
 _articles/ru/finding-users.md |  8 --------
 _articles/tr/finding-users.md | 10 +---------
 5 files changed, 2 insertions(+), 46 deletions(-)

diff --git a/_articles/de/finding-users.md b/_articles/de/finding-users.md
index f0279bdc380..697076881b2 100644
--- a/_articles/de/finding-users.md
+++ b/_articles/de/finding-users.md
@@ -171,18 +171,6 @@ Es ist nie zu früh oder zu spät, um mit dem Aufbau eines guten Rufs zu beginne
 
 Ein Publikum aufzubauen, schafft man nicht über Nacht. Das Vertrauens und den Respekt anderer zu gewinnen, nimmt Zeit in Anspruch, und der Aufbau Ihres Rufes endet nie.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-
-  PhantomJS wurde Anfang 2011 zum ersten Mal veröffentlicht. (...) Ich verkündete dies auf die übliche Art und Weise: Ich twitterte darüber, ich schrieb Blog-Posts über Dinge, die man damit machen könnte, ich erwähnte es in verschiedenen Diskussionen in Meetups. Als es 2014 bekannter wurde, fing ich an, Vorträge darüber zu halten.
-
-  _PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it._
-
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## Weitermachen!
 
 Es kann lange dauern, bis Leute Ihr Open-Source-Projekt bemerken. Das ist in Ordnung! Einige der populärsten Projekte erreichten erst nach Jahren ein hohes Aktivitätsniveau. Konzentrieren Sie sich darauf, Kontakte aufzubauen, anstatt zu hoffen, dass Ihr Projekt spontan an Popularität gewinnt. Seien Sie geduldig und teilen Sie Ihre Arbeit mit denen, die sie zu schätzen wissen.
diff --git a/_articles/el/finding-users.md b/_articles/el/finding-users.md
index 68cf2ef2af0..4f1a2cf630c 100644
--- a/_articles/el/finding-users.md
+++ b/_articles/el/finding-users.md
@@ -41,7 +41,7 @@ related:
 
 **Να έχετε ένα ξεκάθαρο χειριστήριο για να προωθήσετε το πρότζεκτ σας.** Ένα χειριστήριο στο Twitter, μια διεύθυνση URL στο GitHub ή ένα κανάλι IRC είναι ένας εύκολος τρόπος για να δείξετε στους ανθρώπους το πρότζεκτ σας. Αυτές οι διέξοδοι δίνουν επίσης στην αναπτυσσόμενη κοινότητα του πρότζεκτ σας ένα μέρος για να συγκεντρώνεται.
 
-Αν δεν επιθυμείτε να δημιουργήσετε ακόμη διεξόδους για το πρότζεκτ σας, προωθήστε τη δική σας λαβή Twitter ή GitHub σε ό,τι κάνετε. Η προώθηση της λαβής σας στο Twitter ή το GitHub θα ενημερώσει τους ανθρώπους για το πώς μπορούν να επικοινωνήσουν μαζί σας ή να παρακολουθήσουν το πρότζεκτ σας. Αν μιλήσετε σε μια συνάντηση ή εκδήλωση, βεβαιωθείτε ότι τα στοιχεία επικοινωνίας σας περιλαμβάνονται στο βιογραφικό σας ή στις διαφάνειές σας. 
+Αν δεν επιθυμείτε να δημιουργήσετε ακόμη διεξόδους για το πρότζεκτ σας, προωθήστε τη δική σας λαβή Twitter ή GitHub σε ό,τι κάνετε. Η προώθηση της λαβής σας στο Twitter ή το GitHub θα ενημερώσει τους ανθρώπους για το πώς μπορούν να επικοινωνήσουν μαζί σας ή να παρακολουθήσουν το πρότζεκτ σας. Αν μιλήσετε σε μια συνάντηση ή εκδήλωση, βεβαιωθείτε ότι τα στοιχεία επικοινωνίας σας περιλαμβάνονται στο βιογραφικό σας ή στις διαφάνειές σας.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
@@ -143,14 +143,6 @@ related:
 
 Δεν υπάρχει λύση από τη μια μέρα στην άλλη για να χτίσετε ένα κοινό. Το να κερδίσετε την εμπιστοσύνη και τον σεβασμό των άλλων χρειάζεται χρόνο, και το χτίσιμο της φήμης σας δεν τελειώνει ποτέ.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  Το PhantomJS κυκλοφόρησε για πρώτη φορά στις αρχές του 2011. (...) Διέδωσα την είδηση με τους συνήθεις τρόπους: Έκανα tweet γι' αυτό, έγραψα αναρτήσεις σε blog για πράγματα που μπορούσατε να κάνετε με αυτό, το ανέφερα κατά τη διάρκεια διαφόρων συζητήσεων σε συναντήσεις. Όταν έγινε πιο γνωστό το 2014, άρχισα να κάνω παρουσιάσεις γι' αυτό.
-  <p markdown="1" class="pquote-credit">
-- @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## Συνεχίστε!
 
 Μπορεί να χρειαστεί πολύς χρόνος μέχρι οι άνθρωποι να παρατηρήσουν το πρότζεκτ σας ανοιχτού κώδικα. Αυτό δεν πειράζει! Μερικά από τα πιο δημοφιλή έργα σήμερα χρειάστηκαν χρόνια για να φτάσουν σε υψηλά επίπεδα δραστηριότητας. Επικεντρωθείτε στην οικοδόμηση σχέσεων αντί να ελπίζετε ότι το πρότζεκτ σας θα αποκτήσει αυθόρμητα δημοτικότητα. Κάντε υπομονή και συνεχίστε να μοιράζεστε το πρότζεκτ σας με όσους το εκτιμούν.
diff --git a/_articles/es/finding-users.md b/_articles/es/finding-users.md
index bdd0d80f37d..d6c58b540e1 100644
--- a/_articles/es/finding-users.md
+++ b/_articles/es/finding-users.md
@@ -144,14 +144,6 @@ Nunca es demasiado temprano, o muy tarde, para comenzar a construir tu reputaci&
 
 No hay una soluci&oacute;n para construir una audiencia en una noche. Ganarse la confianza y el respeto de los dem&aacute;s lleva tiempo, y el trabajo de construir la reputaci&oacute;n no termina nunca.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS fue lanzado por primera vez a comienzos del 2011. (...)  Yo pas&eacute; la voz utilizando maneras convencionales: envi&eacute; posts en Tweeter sobre el mismo, escrib&iacute; posts en blogs sobre cosas que pod&iacute;an hacerse con &eacute;l, lo nombr&eacute; durante varias discusiones en encuentros. Cuando se hizo más conocido en el 2014, comenc&eacute; a hacer presentaciones sobre &eacute;l.
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## S&iacute;guelo!
 
 Algunas veces, lleva mucho tiempo antes de que la gente note tu proyecto de c&oacute;digo abierto. ¡Está bien! Algunos de los proyectos más populares de hoy en día, tardaron años en alcanzar altos niveles de actividad. Enfócate en construir relaciones en lugar de una bala mágica. S&eacute; paciente, y contin&uacute;a compartiendo tu trabajo con aquellos que lo aprecian.
diff --git a/_articles/ru/finding-users.md b/_articles/ru/finding-users.md
index d87a1009367..f28f88e542c 100644
--- a/_articles/ru/finding-users.md
+++ b/_articles/ru/finding-users.md
@@ -143,14 +143,6 @@ related:
 
 Невозможно в одночасье нарастить аудиторию. Чтобы заслужить доверие и уважение окружающих нужно время, а созданию репутации нет конца и края.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  Впервые PhantomJS был выпущен в начале 2011 года. (...) Я рекламировал его обычными способами: писал в Twitter, публиковал посты в блоге о том, что с ним можно сделать, упоминал во время различных обсуждений на митапах. Когда о нём стало больше известно в 2014 году, я начал выступать с докладами.
-  <p markdown="1" class="pquote-credit">
-- @ariya, ["Истории мейнтейнеров"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## Не останавливайтесь на достигнутом!
 
 Может пройти много времени, прежде чем люди заметят ваш опенсорс-проект. Это нормально! Некоторым из самых популярных сегодня проектов потребовались годы, чтобы достичь высокого уровня активности. Сосредоточьтесь на выстраивании отношений, а не на надежде, что ваш проект внезапно станет популярным. Будьте терпеливы и продолжайте делиться своей работой с теми, кто её ценит.
diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md
index 01486a9d4a9..d9946ba556a 100644
--- a/_articles/tr/finding-users.md
+++ b/_articles/tr/finding-users.md
@@ -97,7 +97,7 @@ Genel olarak konuşursak, karşılığında bir şey istemeden önce başkaları
   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
   PyCon'a giderken oldukça gergindim. Bir konuşma yapıyordum, sadece birkaç kişiyi tanıyacaktım, bir hafta boyunca gidecektim. (...) Yine de bu kadar endişelenmemeliydim. PyCon olağanüstü bir harikaydı! (...) Herkes inanılmaz derecede cana yakın ve paylaşımcıydı, o kadar ki nadiren ben de konuşmak için fırsat bulabildim!
   <p markdown="1" class="pquote-credit">
-- @jhamrick, ["Endişelenmeyi Durdurmayı ve PyCon'u Sevmeyi Nasıl Öğreniyorum"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)   
+- @jhamrick, ["Endişelenmeyi Durdurmayı ve PyCon'u Sevmeyi Nasıl Öğreniyorum"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
   </p>
 </aside>
 
@@ -143,14 +143,6 @@ Yeni gelenlere yardım etmek, kaynakları paylaşmak ve başkalarının projeler
 
 Kitle oluşturmak için bir gecede çözüm yoktur. Başkalarının güvenini ve saygısını kazanmak zaman alır ve itibarınızı geliştirmek hiç tamamlanmayan bir iştir.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS ilk kez 2011 yılının başında piyasaya sürüldü. (...) Mesajını her zamanki gibi yaydım: Tweetledim, yapabileceğin şeyler hakkında blog yazıları yazdım, buluşmalarda çeşitli tartışmalar sırasında bahsettim. 2014 yılında daha iyi tanındığında, onunla ilgili sunumlar yapmaya başladım.
-  <p markdown="1" class="pquote-credit">
-- @ariya, ["Geliştirici Hikayeleri"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## Devam et!
 
 İnsanların açık kaynaklı projenizi fark etmesi uzun zaman alabilir. Sorun yok! Bugün en popüler projelerden bazılarının yüksek düzeyde faaliyet göstermesi yıllar aldı. Projenizin kendiliğinden popülerlik kazanacağını ummak yerine ilişkiler kurmaya odaklanın. Sabırlı olun ve çalışmanızı takdir edenlerle paylaşmaya devam edin.

From 1425e4fd06bba536f518131daffcf43ea526b916 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@gmail.com>
Date: Tue, 3 Jan 2023 15:59:29 -0500
Subject: [PATCH 421/749] remove more links

---
 _articles/de/getting-paid.md       | 13 -------------
 _articles/el/getting-paid.md       |  9 ---------
 _articles/es/getting-paid.md       |  9 ---------
 _articles/fa/finding-users.md      | 14 +++-----------
 _articles/fa/getting-paid.md       |  8 --------
 _articles/finding-users.md         | 10 +---------
 _articles/fr/finding-users.md      |  8 --------
 _articles/fr/getting-paid.md       |  8 --------
 _articles/getting-paid.md          |  9 ---------
 _articles/hu/finding-users.md      | 10 +---------
 _articles/hu/getting-paid.md       |  8 --------
 _articles/id/finding-users.md      |  8 --------
 _articles/id/getting-paid.md       |  8 --------
 _articles/ja/finding-users.md      |  8 --------
 _articles/ja/getting-paid.md       |  8 --------
 _articles/ko/finding-users.md      |  8 --------
 _articles/ko/getting-paid.md       |  8 --------
 _articles/ms/finding-users.md      |  8 --------
 _articles/ms/getting-paid.md       |  8 --------
 _articles/nl/finding-users.md      | 24 +++++++-----------------
 _articles/nl/getting-paid.md       | 11 -----------
 _articles/pl/finding-users.md      | 10 ----------
 _articles/pl/getting-paid.md       | 10 ----------
 _articles/pt/finding-users.md      |  8 --------
 _articles/pt/getting-paid.md       |  8 --------
 _articles/ro/finding-users.md      | 15 ---------------
 _articles/ro/getting-paid.md       | 15 ---------------
 _articles/ru/getting-paid.md       | 10 +---------
 _articles/ta/finding-users.md      |  8 --------
 _articles/ta/getting-paid.md       |  8 --------
 _articles/tr/getting-paid.md       |  8 --------
 _articles/zh-hans/finding-users.md |  8 --------
 _articles/zh-hans/getting-paid.md  |  8 --------
 _articles/zh-hant/finding-users.md |  8 --------
 _articles/zh-hant/getting-paid.md  |  8 --------
 35 files changed, 13 insertions(+), 324 deletions(-)

diff --git a/_articles/de/getting-paid.md b/_articles/de/getting-paid.md
index 13ac987f875..ac5aa3b5d1a 100644
--- a/_articles/de/getting-paid.md
+++ b/_articles/de/getting-paid.md
@@ -82,18 +82,6 @@ Heutzutage werden viele Leute für Open-Source in Teil- oder Vollzeit bezahlt. D
 
 Es ist einfacher, sich für Open-Source-Arbeiten zu entscheiden, wenn Ihr Arbeitgeber das Projekt tatsächlich nutzt. Wenn nicht, werden Sie kreativ: Vielleicht nutzt Ihr Arbeitgeber nicht das Projekt, aber Python, und die Pflege eines beliebten Python-Projekts hilft dabei, neue Python-Entwickler\*innen anzuziehen. Vielleicht sieht Ihr Arbeitgeber dadurch generell entwicklerfreundlicher aus.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-
-  Wie viele Andere auch, kämpfte ich mit der Last, ein Open-Source-Projekt aufrechtzuerhalten. Als ich mit Open Source anfing, blieb ich lange auf Arbeit, um daran zu arbeiten, oder fing nach dem Feierabend direkt wieder an. (...) Mit meinem Chef besprach ich diese mir im Weg stehenden Probleme, aber weil wir Babel selbst nutzten, entwickelten wir Ideen, um die Open-Source-Aufgaben zu integrieren.
-
-  _Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel._
-
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 Wenn Sie kein existierendes Open-Source-Projekt haben, an dem Sie gerne arbeiten würden, sondern lieber Ihre aktuellen Arbeitsergebnisse quell-offen hätten, sollten Sie Ihren Arbeitgeber bitten, einen Teil seiner internen Software zu öffnen.
 
 Viele Unternehmen entwickeln Open-Source-Programme, um ihre Marke aufzubauen und Talente zu rekrutieren.
@@ -146,7 +134,6 @@ Sponsoren lassen sich einfacher finden, wenn Sie bereits ein starkes Publikum od
 Hier einige Beispiele für gesponsorte Projekte:
 
 * **[webpack](https://github.com/webpack)** sammelt Geld von Firmen und Einzelpersonen [mittels OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** wird [mittels Patreon finanziert](https://github.com/open-source/stories/yyx990803)
 * **[Ruby Together](https://rubytogether.org/),** eine nicht-Gewinn-orientierte Organisation zahlt für die Arbeit an [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), und anderen Ruby-Infrastrukturprojekten
 
 ### Eine Einnahmequelle schaffen
diff --git a/_articles/el/getting-paid.md b/_articles/el/getting-paid.md
index 39ccf014269..f53254585a2 100644
--- a/_articles/el/getting-paid.md
+++ b/_articles/el/getting-paid.md
@@ -66,14 +66,6 @@ related:
 
 Είναι πιο εύκολο να υποστηρίξετε την εργασία σε ανοιχτό κώδικα αν ο εργοδότης σας χρησιμοποιεί πραγματικά το πρότζεκτ, αλλά γίνετε δημιουργικοί με την προσφορά σας. Ίσως ο εργοδότης σας δεν χρησιμοποιεί το πρότζεκτ, αλλά χρησιμοποιεί την Python, και η διατήρηση ενός δημοφιλούς πρότζεκτ Python συμβάλλει στην προσέλκυση νέων προγραμματιστών Python. Ίσως αυτό κάνει τον εργοδότη σας να φαίνεται γενικά πιο φιλικός προς τους προγραμματιστές.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Όπως πολλοί στον τομέα του ανοιχτού κώδικα, πάλευα με το βάρος της συντήρησης ενός πρότζεκτ. Όταν πρωτοξεκίνησα να ασχολούμαι με τον ανοιχτό κώδικα, συνήθιζα να μένω μέχρι αργά για να δουλέψω πάνω σε αυτό ή αμέσως μόλις γύριζα σπίτι. (...) Μπόρεσα να συζητήσω με το αφεντικό μου τα ζητήματα που αντιμετώπιζα και σκεφτήκαμε ιδέες για το πώς θα μπορούσαμε να ενσωματώσουμε εργασίες ανοιχτού κώδικα, δεδομένης της δικής μας χρήσης της Babel.
-  <p markdown="1" class="pquote-credit">
-- @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 Αν δεν έχετε κάποιο υπάρχον πρότζεκτ ανοικτού κώδικα στο οποίο θα θέλατε να εργαστείτε, αλλά θα προτιμούσατε να είναι ανοικτού κώδικα το τρέχον αποτέλεσμα της δουλειάς σας, κάντε μια πρόταση στον εργοδότη σας να ανοίξει κάποιο από τα εσωτερικά του λογισμικά.
 
 Πολλές εταιρείες αναπτύσσουν προγράμματα ανοικτού κώδικα για να χτίσουν το εμπορικό τους σήμα και να προσλάβουν ποιοτικά ταλέντα.
@@ -124,7 +116,6 @@ related:
 Μερικά παραδείγματα έργων με χορηγίες περιλαμβάνουν:
 
 * **[webpack](https://github.com/webpack)** συγκεντρώνει χρήματα από εταιρείες και ιδιώτες [μέσω του OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** χρηματοδοτείται [μέσω του Patreon](https://github.com/open-source/stories/yyx990803)
 * **[Ruby Together](https://rubytogether.org/),** ένας μη κερδοσκοπικός οργανισμός που πληρώνει για εργασίες στα [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), και άλλα έργα υποδομής Ruby
 
 ### Δημιουργία μιας ροής εσόδων
diff --git a/_articles/es/getting-paid.md b/_articles/es/getting-paid.md
index deb595bded9..728adcc0eac 100644
--- a/_articles/es/getting-paid.md
+++ b/_articles/es/getting-paid.md
@@ -66,14 +66,6 @@ Hoy en d&iacute;a, muchas personas reciben pagos por trabajos a tiempo parcial o
 
 Es m&aacute;s f&aacute;cil establecer un trabajo en c&oacute;digo abierto si tu empleador usa el proyecto, pero ponte creativo. Puede que tu empleador no use el proyecto, pero usa Python, y mantener un proyecto popular de Python puede atraer nuevos desarrolladores de Python. Tambi&eacute;n puede que haga que tu empleador se vea m&aacute;s desarrollador-amigable en general.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Como muchos desarrolladores en proyectos de c&oacute;digo abierto, yo estaba esforz&aacute;ndome por seguir manteniendo uno. Cuando por primera vez comenc&eacute; a aportar a un proyecto, sol&iacute;a quedarme despierto hasta tarde o me pon&iacute;a a trabajar ni bien llegaba a mi hogar. (...) Fui capaz de discutir con mi jefe los problemas que estaba enfrentando y nos surgieron ideas sobre c&oacute;mo podr&iacute;amos incorporar las tareas de c&oacute;digo abierto dado nuestro propio uso de Babel.
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 Si tu no tienes un excitante proyecto de c&oacute;digo abierto en el que quisieras trabajar, pero te gustar&iacute;a que tu actual trabajo genere aportes al c&oacute;digo abierto, establece un acuerdo con tu empleador para aportar algo del software interno de la organizaci&oacute;n a la comunidad de c&oacute;digo abierto.
 
 Muchas empresas est&aacute;n desarrollando programas de c&oacute;digo abierto para construir su marca y reclutar talentos de calidad.
@@ -119,7 +111,6 @@ Encontrar sponsors funciona si tienes una fuerte audiencia o reputaci&oacute;n y
 Algunos ejemplos comunes de proyectos sponsoreados incluyen:
 
 * **[webpack](https://github.com/webpack)** genera dinero de empresas e individuos [a trav&eacute;s de OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** es [financiado a trav&eacute;s de Patreon](https://github.com/open-source/stories/yyx990803)
 * **[Ruby Together](https://rubytogether.org/),** una organizaci&oacute;n sin fines de lucro que paga por el trabajo en [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), y otros proyectos de la infraestructura de Ruby.
 
 ### Crea un flujo de ingresos.
diff --git a/_articles/fa/finding-users.md b/_articles/fa/finding-users.md
index d5ff6ed0547..a66bf22b0f2 100644
--- a/_articles/fa/finding-users.md
+++ b/_articles/fa/finding-users.md
@@ -42,7 +42,7 @@ related:
 **برای توسعه‌ی پروژه‌ی خود، کاملا بر کار خویش آگاه و از آن اطمینان داشته باشید.** یک آدرس توییتری، آدرس <span dir="rtl">GitHub</span> یا کانال <span dir="rtl">IRC</span> راهی آسان برای مشایعت و هدایت افراد به سمت پروژه‌ی خودتان است. این رسانه‌ها همچنین به اجتماع در حال رشد پروژه‌ی شما، محلی برای تجمع و تبادل نظر می‌دهند.
 
 اگر هنوز مایل به راه‌اندازی رسانه‌هایی برای پروژه‌ی خودتان نیستید، در همه‌ی کارهایی که انجام می‌دهید <span dir="rtl">Twitter</span> یا <span dir="rtl">GitHub</span> خود را ترویج دهید. توسعه و تبلیغ <span dir="rtl">Twitter</span> یا <span dir="rtl">GitHub</span> به مردم این امکان را می‌دهد تا با شما در ارتباط باشند یا کارهای شما را دنبال کنند. اگر در جلسه یا رویدادی صحبت می‌کنید، اطمینان حاصل کنید تا اطلاعات تماس شما در مشخصات شما یا اسلایدها آمده باشد.
- 
+
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
   اشتباهی که در همان روزهای اولیه مرتکب به آن شدم، افتتاح نکردن یک حساب توییتر برای پروژه بود. توییتر راهی عالی برای به روز نگه داشتن مردم در مورد پروژه و همچنین نشان دادن پروژه به آدم‌های جدید است.
@@ -53,7 +53,7 @@ related:
 
 **ساخت وب‌سایتی را برای پروژه‌ی خود مد نظر قرار دهید.** داشتن وب‌سایت، پروژه‌ی شما را دوستانه‌تر و برای وب‌گردی و گشت‌زنی ساده‌تر می‌کند؛ به ویژه هنگامی که با مستندات و آموزش‌های واضح همراه باشد. داشتن یک وب سایت همچنین بیانگر این است که پروژه‌ی شما فعال است که همین باعث می‌شود مخاطبان شما احساس راحتی بیشتری در استفاده از آن داشته باشند. مثال‌هایی را ارائه دهید تا به افراد در مورد چگونگی استفاده از پروژه‌تان ایده بدهد.
 
-[@Adrianholovaty](https://news.ycombinator.com/item?id=7531689)، یکی از سازند‌گان شرکت <span dir="rtl">Django</span> گفت که وب‌سایت «بهترین کاری بود که می‌توانستیم برای <span dir="rtl">Django</span> در آن روزهای اولیه انجام دهیم». اگر پروژه‌ی شما در <span dir="rtl">GitHub</span> باشد، می‌توانید با استفاده از [GitHub Pages](https://pages.github.com/)، به راحتی وب‌سایت ایجاد کنید. [Yeoman](http://yeoman.io/)، [Vagrant](https://www.vagrantup.com/)  و [Middleman](https://middlemanapp.com/) چند نمونه از وب‌سایت‌های عالی و جامع هستند.                                      
+[@Adrianholovaty](https://news.ycombinator.com/item?id=7531689)، یکی از سازند‌گان شرکت <span dir="rtl">Django</span> گفت که وب‌سایت «بهترین کاری بود که می‌توانستیم برای <span dir="rtl">Django</span> در آن روزهای اولیه انجام دهیم». اگر پروژه‌ی شما در <span dir="rtl">GitHub</span> باشد، می‌توانید با استفاده از [GitHub Pages](https://pages.github.com/)، به راحتی وب‌سایت ایجاد کنید. [Yeoman](http://yeoman.io/)، [Vagrant](https://www.vagrantup.com/)  و [Middleman](https://middlemanapp.com/) چند نمونه از وب‌سایت‌های عالی و جامع هستند.
 
 ![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
 
@@ -136,18 +136,10 @@ related:
   </p>
 </aside>
 
-برای ایجاد و کسب اعتبار، هیچوقت خیلی زود و یا خیلی دیر نیست. حتی اگر پروژه‌ی خود را از قبل راه‌اندازی کرده‌اید، به جستجوی راه‌هایی برای کمک به دیگران ادامه دهید. برای ایجاد و جذب مخاطب، هیچ راه‌حل یک شبه‌ای وجود ندارد. 
+برای ایجاد و کسب اعتبار، هیچوقت خیلی زود و یا خیلی دیر نیست. حتی اگر پروژه‌ی خود را از قبل راه‌اندازی کرده‌اید، به جستجوی راه‌هایی برای کمک به دیگران ادامه دهید. برای ایجاد و جذب مخاطب، هیچ راه‌حل یک شبه‌ای وجود ندارد.
 
 جلب اعتماد و احترامِ دیگران نیازمند زمان است و هیچ پایانی برای ایجاد و کسب اعتبار  وجود ندارد
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  <span dir="rtl">PhantomJS</span> برای اولین بار در ابتدای سال 2011 منتشر شد. ...من با روش‌های متداول، خبر را پخش کردم:  من راجع به آن توییت کردم، در مورد کارهایی که می‌توانید با آن انجام دهید در وبلاگ‌ پست‌هایی گذاشتم، در گردهمایی‌ها، در بحث‌های مختلف به آن اشاره کردم. وقتی در سال 2014 بیشتر شناخته شد، شروع به ارائه‌ی سخنرانی‌هایی در مورد آن کردم.
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## تسلیم نشوید!
 
 ممکن است مدت‌ها طول بکشد تا اینکه مردم متوجه پروژه‌ی اوپن سورس شما شوند. هیچ اشکالی نداره! برخی از محبوب‌ترین پروژه‌های امروزی، برای رسیدن به سطح بالایی از فعالیت، سال‌ها به طول انجامید. به جای اینکه امیدوار باشید پروژه‌ی شما به طور خود به خود محبوبیت پیدا کند، بر ایجاد روابط متمرکز شوید. صبور باشید و مدام کار خود را با کسانی که قدر آن را می‌دانند به اشتراک بگذارید.
diff --git a/_articles/fa/getting-paid.md b/_articles/fa/getting-paid.md
index ca2cc68fb61..fd6887bdfae 100644
--- a/_articles/fa/getting-paid.md
+++ b/_articles/fa/getting-paid.md
@@ -66,14 +66,6 @@ related:
 
 متقاعد کردن کارفرما در پروژه‌ای که واقعا از آن استفاده ‌می‌کند آسان‌تر است، اما در مورد صحبتی که با او خواهید کرد، رویه‌ای خلاقانه در نظر بگیرید. شاید کارفرمای شما از این پروژه استفاده نکند، اما آن‌ها از پایتون استفاده می‌کنند و نگهداری از  پروژه‌ی پایتون محبوب به جذب توسعه‌دهندگان جدید پایتون کمک می‌کند. شاید این امر باعث شود که کارفرمای شما به طور کلی در در ارتباط با توسعه‌دهندگان سازنده‌تر و دوستانه‌تر به نظر برسد.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  مانند بسیاری پروژه‌های متن باز، با سنگینی مسئولیت نگهداری پروژه دست و پنجه نرم می‌کردم. هنگامی که من برای اولین بار شروع به انجام پروژه‌های متن باز کردم، تا در وقت سر کار می‌ماندم تا روی آن کار کنم یا درست وقتی که به خانه می‌رسیدم، کار روی آن را ادامه می‌دادم. (...) من این امکان را داشتم مسائلی را که با آن روبرو می‌شدم را با رئیس خودم در میان بگذارم و به ایده‌هایی درباره‌ی چگونگی ادغام کردن وظایف پروژه‌های متن باز با شلوغی کار خودمان دست یابیم.
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 اگر در حال حاضر پروژه‌ای متن باز ندارید که بخواهید روی آن کار کنید، اما ترجیح می‌دهید که خروجی کار فعلی شما متن باز باشد، از کارفرمای خود درخواست کنید که برخی از نرم‌افزارهای داخلی خود را متن باز کند.
 
 بسیاری از شرکت‌ها برنامه‌هایی متن باز توسعه می‌دهند تا اعتباری برای نام برند خود ایجاد کنند و افرادی با استعداد استخدام کنند.
diff --git a/_articles/finding-users.md b/_articles/finding-users.md
index 969d092df03..61e7b3e98ff 100644
--- a/_articles/finding-users.md
+++ b/_articles/finding-users.md
@@ -41,7 +41,7 @@ Help people find and remember your project by pointing them to a single namespac
 
 **Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.
 
-If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. 
+If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
@@ -143,14 +143,6 @@ It's never too early, or too late, to start building your reputation. Even if yo
 
 There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it.
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## Keep at it!
 
 It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.
diff --git a/_articles/fr/finding-users.md b/_articles/fr/finding-users.md
index 8dcd4fdd539..86838dbab02 100644
--- a/_articles/fr/finding-users.md
+++ b/_articles/fr/finding-users.md
@@ -143,14 +143,6 @@ Il n'est jamais trop tôt ou trop tard pour commencer à bâtir votre réputatio
 
 Il n'y a pas de solution du jour au lendemain pour créer un public. Gagner la confiance et le respect des autres prend du temps, et bâtir votre réputation ne s'arrête jamais.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS a été publié pour la première fois début 2011. (...) J'ai répandu le mot de la manière habituelle: j'ai tweeté à ce sujet, j'ai écrit des articles sur ce que vous pouviez faire avec, je l'ai mentionné lors de diverses discussions dans les meetups. Quand il est devenu plus connu en 2014, j'ai commencé à faire des présentations à ce sujet.
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## Persévèrez !
 
 Cela peut prendre beaucoup de temps avant que les gens remarquent votre projet open source. C'est bon ! Certains des projets les plus populaires aujourd'hui ont pris des années pour atteindre des niveaux d'activité élevés. Concentrez-vous sur l'établissement de relations au lieu d'espérer que votre projet gagnera spontanément en popularité. Soyez patient et continuez à partager votre travail avec ceux qui l'apprécient.
diff --git a/_articles/fr/getting-paid.md b/_articles/fr/getting-paid.md
index a9aa8516c3c..3e64e034e3e 100644
--- a/_articles/fr/getting-paid.md
+++ b/_articles/fr/getting-paid.md
@@ -66,14 +66,6 @@ Aujourd'hui, beaucoup de gens sont payés pour travailler à temps plein ou à t
 
 Il est plus facile de plaider en faveur du travail open source si votre employeur utilise réellement le projet, mais soyez créatif avec votre argumentaire. Peut-être que votre employeur n'utilise pas le projet, mais ils utilisent Python, et le maintien d'un projet populaire Python aide à attirer de nouveaux développeurs Python. Peut-être que cela rend votre employeur plus convivial en général.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Comme beaucoup en open source, je me débattais avec le fardeau de maintenir un projet. Quand j'ai commencé à faire de l'open source, je restais juste en retard pour travailler dessus ou juste quand je rentrais à la maison. (...) J'ai pu discuter avec mon patron des problèmes auxquels je faisais face et nous avons eu des idées sur la façon dont nous pourrions intégrer des tâches open source étant donné notre propre utilisation de Babel.
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 Si vous n'avez pas de projet Open Source sur lequel vous souhaitez travailler, mais préférez que votre travail actuel soit ouvert, demandez à votre employeur d'ouvrir certains de ses logiciels internes.
 
 De nombreuses entreprises développent des programmes open source pour construire leur marque et recruter des talents de qualité.
diff --git a/_articles/getting-paid.md b/_articles/getting-paid.md
index cd865dc9a45..7fd4a32af4c 100644
--- a/_articles/getting-paid.md
+++ b/_articles/getting-paid.md
@@ -66,14 +66,6 @@ Today, many people get paid to work part- or full-time on open source. The most
 
 It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
 
 Many companies are developing open source programs to build their brand and recruit quality talent.
@@ -124,7 +116,6 @@ Finding sponsorships works well if you have a strong audience or reputation alre
 A few examples of sponsored projects include:
 
 * **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803)
 * **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
 
 ### Create a revenue stream
diff --git a/_articles/hu/finding-users.md b/_articles/hu/finding-users.md
index d88b44333c8..7074945de98 100644
--- a/_articles/hu/finding-users.md
+++ b/_articles/hu/finding-users.md
@@ -41,7 +41,7 @@ Segíts az embereknek megjegyezni a projektedet azáltal, hogy egyetlen pontra,
 
 **Legyen egyértelmű, hogy hol népszerűsíted a munkád.** Ez lehet Twitter vagy IRC csatorna, vagy GitHub URL, amely könnyen elérhető mindenkinek. Ezek a helyek a projekt növekvő közösségének is helyet biztosítanak.
 
-Ha még nem szeretnél projekthez köthető kommunikációs csatornákat kiépíteni, akkor a saját Twitter vagy GitHub helyeiden is meg tudod azt tenni. A Twitter vagy GitHub azonosító alapján a felhasználók tudni fogják hogyan érjenek el téged és a projektet. Ha eseményen vagy szakmai találkozókon adsz elő, akkor bizonyosodj meg róla, hogy ezeket a elérhetőségeket feltüntetted az előadásodban. 
+Ha még nem szeretnél projekthez köthető kommunikációs csatornákat kiépíteni, akkor a saját Twitter vagy GitHub helyeiden is meg tudod azt tenni. A Twitter vagy GitHub azonosító alapján a felhasználók tudni fogják hogyan érjenek el téged és a projektet. Ha eseményen vagy szakmai találkozókon adsz elő, akkor bizonyosodj meg róla, hogy ezeket a elérhetőségeket feltüntetted az előadásodban.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
@@ -143,14 +143,6 @@ Soha sincs túl késő vagy túl korán a hírnév építéséhez. Még ha el is
 
 Nem létezik olyan módszer, amivel hirtelen közönséget és hírnevet tudsz szerezni. A bizalom és tisztelet megszerzéséhez idő kell, és a hírnév építése sohasem érhet véget.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  A PhantomJS 2011 elején jelent meg először. (...) A hírét a szokásos módon terjesztettem: Twitter-en írtam róla, írtam Blog-ot arról hogyan és mire jó, és számos szakmai összejövetelen beszélgettem róla. 2014-re, mikorra ismertté vált, elkezdtem önálló előadásokat is tartani.
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## Tarts ki!
 
 Lehet, hogy sokáig fog tartani, mire az emberek felfigyelnek a projektedre, de ezzel nincs semmi probléma! Számos olyan projektnek, amely ma a leghíresebbek között van, évekig tartott, mire elérte a jelenlegi ismertségét és aktivitását. A lényeg a kapcsolatépítésen legyen, ne abban reménykedj, hogy egyszer magától fog növekedni a hírneve. Légy türelmes, és működj együtt azokkal, akik értékelik a munkádat.
diff --git a/_articles/hu/getting-paid.md b/_articles/hu/getting-paid.md
index ea0ac67f4d0..2a023d94bbe 100644
--- a/_articles/hu/getting-paid.md
+++ b/_articles/hu/getting-paid.md
@@ -66,14 +66,6 @@ Ma sok embernek fizetnek részmunkaidőben vagy teljes munkaidőben nyílt forr
 
 Egyszerűbb elérni ezt, ha az adott nyílt forráskódú projektet a munkaadód is használja. Lehet, hogy a munkaadód nem használja a projektet, de használja a Python-t, és egy népszerű Python projekt fenntartása segíti, hogy új Python fejlesztőket találjon a munkaadód. Ezzel a munkaadód még fejlesztő-barátabbnak tűnik.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Mint sokan mások a nyílt forráskódú közösségben, én is küzdöttem egy projekt fenntartásának terheivel. Amikor először kezdtem el a nyílt forráskódú munkát, későig maradtam a munkahelyemen, hogy dolgozhassak, vagy rögtön nekikezdtem, ahogy hazaértem. (...) Meg tudtam beszélni a vezetőmmel a problémákat, amikkel szembesültem és kitaláltuk, hogy mivel használjuk a Babel-t, be tudjuk beépíteni a nyílt forráskódú feladatokat a saját munkánkba.
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 Ha még nincs nyílt forráskódú projekted, amin dolgoznál, de szeretnéd, ha munkád eredménye nyílt forrású lenne, győzd meg a munkaadódat, hogy valamelyik belső projekt forráskódját tegye nyílttá.
 
 Számos cég fejleszt nyílt forráskódú programokat azért, hogy az imázsukat javítsák és a tehetséges fejlesztőket megszerezzék.
diff --git a/_articles/id/finding-users.md b/_articles/id/finding-users.md
index 05dbf7cd56b..c47bd96cffa 100644
--- a/_articles/id/finding-users.md
+++ b/_articles/id/finding-users.md
@@ -145,14 +145,6 @@ Tidak pernah terlalu cepat, atau terlambat untuk membangun reputasi Anda. Meskip
 
 Tidak ada solusi cepat untuk membangun pengguna. Mendapatkan kepercayaan dan penghargaan membutuhkan waktu, dan proses membangun reputasi tidak pernah selesai.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS dirilis pertama kalinya di awal 2011. (...) Saya menyebarkan dengan cara yang sederhana: Saya menuliskan tweet, saya menuliskan di blog tentang apa yang bisa Anda lakukan, saya menjelaskannya pada berbagai acara pertemuan. Ketika proyek ini mulai dikenal pada 2014, Saya mulai memberikan presentasi tentang proyek ini.
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## Teruslah Berjuang!
 
 Seringkali membutuhkan waktu yang sangat lama sebelum orang lain mulai memperhatikan proyek open source Anda. Tidak masalah! Sebagian dari proyek open source yang terkenal saat ini membutuhkan waktu bertahun-tahun untuk mencapai aktivitas yang tinggi seperti saat ini. Fokus pada membangun relasi dibandingkan mencari jalan pintas.Bersabarlah dan terus berbagi pekerjaan Anda dengan mereka yang menghargainya.
diff --git a/_articles/id/getting-paid.md b/_articles/id/getting-paid.md
index d2b86acc681..90446ad9515 100644
--- a/_articles/id/getting-paid.md
+++ b/_articles/id/getting-paid.md
@@ -66,14 +66,6 @@ Saat ini, banyak orang dibayar untuk bekerja secara paruh waktu atau penuh pada
 
 Akan lebih mudah untuk mendiskusikan proyek open source jika yang mempekerjakan Anda menggunakan proyek tersebut, tetapi tetap kreatiflah dalam usaha negosiasi Anda. Mungkin mereka tidak menggunakan proyek tersebut, tetapi mereka menggunakan Python, dan mengelola proyek Python yang populer akan membantu mengundang pengembang Python yang baru. Mungkin hal ini membuat perusahaan Anda lebih ramah terhadap pengembang secara umum.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Seperti halnya yang lain pada open source, saya mendapatkan masalah dengan beban mengelola sebuah proyek. Ketika saya pertama kalinya melakukan open source, saya biasa lembur untuk mengerjakannya atau ketika saya pulang ke rumah. (...) Saya mampu mendiskusikannya dengan pimpinan saya tentang isu yang saya alami dan kami mendapatkan ide tentang bagaimana kami dapat menyertakan tugas open source pada penggunaan Babel kami sendiri.
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 Jika Anda tidak memiliki proyek open source yang ingin Anda kerjakan, tetapi Anda berharap pekerjaan Anda saat ini dibuat dalam bentuk open source, ajukan ke perusahaan Anda untuk membuka perangkat lunak internal mereka pada open source.
 
 Banyak perusahaan mengembangkan program open source untuk membangun citra mereka dan merekrut talenta berkualitas.
diff --git a/_articles/ja/finding-users.md b/_articles/ja/finding-users.md
index 94cffd443d7..2e2ff7fb836 100644
--- a/_articles/ja/finding-users.md
+++ b/_articles/ja/finding-users.md
@@ -143,14 +143,6 @@ Django の共同作者の [@adrianholovaty](https://news.ycombinator.com/item?id
 
 一夜で人々を引きつけるようなやり方はありません。信頼や尊敬を得るには時間がかかりますし、評判を築く事は永遠に終わることはありません。
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS は2011年初頭に初めてリリースされました。（中略）私は普通のやり方でメッセージを広めていきました：プロジェクトについてツイートし、人々がこのプロジェクトを使うことでできることについてブログポストを書き、ミートアップの様々な議論で言及しました。2014年にもっと知られるようになった時、プロジェクトについてプレゼンテーションをし始めました。
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## やり続けよう！
 
 人々があなたのオープンソースプロジェクトに気づくまでには時間がかかるかもしれません。それで良いのです！今日最も有名なプロジェクトの中には活発になるまでに何年もかかったものもあります。あなたのプロジェクトが自然と人気を獲得するのを願うのではなく、関係を構築することに集中しましょう。あなたのプロジェクトを喜んでくれる人に対して、辛抱強く、やっていることを伝え続けましょう。
diff --git a/_articles/ja/getting-paid.md b/_articles/ja/getting-paid.md
index 78873974081..e242c1378d8 100644
--- a/_articles/ja/getting-paid.md
+++ b/_articles/ja/getting-paid.md
@@ -66,14 +66,6 @@ related:
 
 もし雇用主がそのプロジェクトを使っているのであれば、オープンソース活動をするのはより簡単になるでしょう。しかし、説明の仕方はよく練る必要があります。そのプロジェクトを使っていないかもしれませんが、 Python を使っているとすれば、 Python の有名なプロジェクトに関わることで新しい Python 開発者を惹き付ける役に立つでしょう。こう説明することで、雇用主はより友好的になるでしょう。
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  オープンソースを行っている多くの人のように、プロジェクト運営の重荷に苦しんでいました。はじめてオープンソース活動を始めた時、私は遅い時間か、家に帰ってすぐにオープンソース活動を行っていました。 (...) 私が直面していた問題について上司と話すことができたため、自分たちが使っていたBabelに関するタスクを普段の仕事に取り込む良い方法を思いつきました。
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 もし取り組みたい既存のオープンソース活動がないけれども、現在の仕事の成果をオープンソースにしたいと望んでいる場合は、社内のソフトウェアをオープンソース化する事例を作りましょう。
 
 多くの企業が、ブランド構築と有能な開発者の採用のためにオープンソースプログラムを作っています。
diff --git a/_articles/ko/finding-users.md b/_articles/ko/finding-users.md
index ce9aa922a69..ffa4bce7272 100644
--- a/_articles/ko/finding-users.md
+++ b/_articles/ko/finding-users.md
@@ -143,14 +143,6 @@ Django의 공동 크리에이터인 [@adrianholovaty](https://news.ycombinator.c
 
 하룻밤 사이에 청중을 확보하는 비법 같은 것은 없습니다. 사람들의 신뢰와 존경심을 얻는 데에는 시간이 필요하고, 평판은 아무리 오래 관리해도 그 끝이 없습니다.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it.
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories”](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## 계속해 나가세요!
 
 사람들이 여러분의 프로젝트에 관심을 갖는 데 오랜 시간이 걸릴 수도 있지만 괜찮습니다! 유명한 프로젝트 중 몇몇은 지금의 경지에 다다르기 위해 몇 년이 들었습니다. 프로젝트가 갑자기 유명해지기를 바라는 대신 관계를 쌓는 데 집중하세요. 인내심을 가지고, 여러분의 노력에 고마워하는 사람들과 작업을 계속 공유하세요.
diff --git a/_articles/ko/getting-paid.md b/_articles/ko/getting-paid.md
index d80c58592ef..933a9cd3ad2 100644
--- a/_articles/ko/getting-paid.md
+++ b/_articles/ko/getting-paid.md
@@ -66,14 +66,6 @@ I was looking for a "hobby" programming project that would keep me occupied duri
 
 고용주가 프로젝트를 실제로 사용하고 오픈소스 작업에 대한 사례를 만드는 것이 더 쉽지만, 자신의 계획대로 창의력을 발휘하십시오. 어쩌면 고용주가 프로젝트를 사용하지 않고 파이썬을 이용한 인기있는 파이썬 프로젝트를 유지한다면, 새로운 파이썬 개발자를 유치할 수 있습니다. 어쩌면 고용주가 일반적으로 더 개발자 친화적인 것처럼 보일 수도 있습니다.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["메인테이너 이야기"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 기존의 오픈소스 프로젝트가 없지만 현재 작업 결과물이 오픈소스인 경우, 고용주가 내부 소프트웨어의 일부를 스스로 오픈할 수 있는 사례를 작성하십시오.
 
 많은 기업들이 브랜드를 구축하고 우수한 인재를 영입하기 위해 오픈소스 프로그램을 개발하고 있습니다.
diff --git a/_articles/ms/finding-users.md b/_articles/ms/finding-users.md
index ebfc6ec9040..b77061a7348 100644
--- a/_articles/ms/finding-users.md
+++ b/_articles/ms/finding-users.md
@@ -143,14 +143,6 @@ Tidak terlalu awal, atau terlambat, untuk mula membina reputasi anda Walaupun an
 
 Tidak ada penyelesaian semalam untuk membina penonton. Memperoleh kepercayaan dan penghormatan orang lain memerlukan masa, dan membina reputasi anda tidak akan pernah berakhir.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS dilancarkan untuk pertama kalinya pada awal tahun 2011. (...) Saya menyebarkan berita dengan cara biasa: Saya tweet mengenainya, saya menulis catatan blog mengenai perkara-perkara yang boleh anda lakukan dengannya, saya menyebutnya semasa pelbagai perbincangan dalam perjumpaan. Ketika menjadi lebih terkenal pada tahun 2014, saya mula memberikan persembahan mengenainya.
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## Terus!
 
 Mungkin memerlukan masa yang lama sebelum orang melihat projek sumber terbuka anda. Tak mengapa! Beberapa projek yang paling popular hari ini mengambil masa bertahun-tahun untuk mencapai tahap aktiviti yang tinggi. Fokus pada membina hubungan dan bukannya berharap projek anda mendapat populariti secara spontan. Bersabarlah, dan teruskan berkongsi karya anda dengan mereka yang menghargainya.
diff --git a/_articles/ms/getting-paid.md b/_articles/ms/getting-paid.md
index aa74e27d818..bebc3185a4f 100644
--- a/_articles/ms/getting-paid.md
+++ b/_articles/ms/getting-paid.md
@@ -66,14 +66,6 @@ Hari ini, banyak orang dibayar untuk bekerja secara sambilan atau sepenuh masa d
 
 Lebih mudah untuk membuat kes untuk kerja sumber terbuka jika majikan anda benar-benar menggunakan projek ini, tetapi kreatif dengan usaha anda. Mungkin majikan anda tidak menggunakan projek itu, tetapi mereka menggunakan Python, dan mengekalkan projek Python yang popular membantu menarik pemaju Python baru. Mungkin itu menjadikan majikan anda kelihatan lebih mesra pemaju secara amnya.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Seperti banyak sumber terbuka, saya bergelut dengan beban penyelenggaraan projek. Ketika mula-mula mula melakukan open source, saya selalu terlambat untuk mengerjakannya atau tepat ketika saya pulang ke rumah. (...) Saya dapat membincangkan masalah yang saya hadapi dengan bos saya dan kami mendapat idea tentang bagaimana kami dapat memasukkan tugas sumber terbuka memandangkan penggunaan Babel oleh kami sendiri.
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 Sekiranya anda tidak mempunyai projek sumber terbuka yang sedia ada, anda ingin mengusahakannya, tetapi lebih suka bahawa hasil kerja anda sekarang bersumber terbuka, buatlah majikan anda membuka sumber perisian dalaman mereka.
 
 Banyak syarikat sedang mengembangkan program sumber terbuka untuk membina jenama mereka dan merekrut bakat berkualiti.
diff --git a/_articles/nl/finding-users.md b/_articles/nl/finding-users.md
index c8a2c87201a..311af8c0c56 100644
--- a/_articles/nl/finding-users.md
+++ b/_articles/nl/finding-users.md
@@ -32,7 +32,7 @@ Voor een diepere duik in berichten, bekijk Mozilla's ["Persona's en paden"](http
 
 <aside markdown="1" class="pquote">
   U hebt idealiter een enkele "home"-URL nodig die u kunt promoten en waarnaar u mensen kunt verwijzen met betrekking tot uw project. U hoeft niet te spetteren op een mooie sjabloon of zelfs een domeinnaam, maar uw project heeft een centraal punt nodig.
-  
+
   _You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point._
   <p markdown="1" class="pquote-credit">
 — Peter Cooper & Robert Nyman, ["Hoe u het woord over uw code kunt verspreiden"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
@@ -48,7 +48,7 @@ Als u nog geen verkooppunten voor uw project wilt opzetten, promoot dan uw eigen
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
   Een fout die ik in die vroege dagen maakte (...) was dat ik geen Twitter-account voor het project startte. Twitter is een geweldige manier om mensen op de hoogte te houden van een project en om mensen constant aan het project bloot te stellen.
-  
+
   _A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project._
   <p markdown="1" class="pquote-credit">
 — @nathanmarz, ["Geschiedenis van Apache Storm en geleerde lessen"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
@@ -74,7 +74,7 @@ Profiteer van bestaande online communities en platforms om uw publiek te bereike
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
   Elk programma heeft zeer specifieke functies die slechts een fractie van de gebruikers nuttig zullen vinden. Spam niet zoveel mogelijk mensen. Richt uw inspanningen in plaats daarvan op gemeenschappen die baat hebben bij kennis van uw project.
-  
+
   _Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project._
   <p markdown="1" class="pquote-credit">
 — @pazdera, ["Marketing voor open source-projecten"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
@@ -102,7 +102,7 @@ Als je [nieuw bent bij spreken in het openbaar](https://speaking.io/), begin dan
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
   Ik was behoorlijk zenuwachtig om naar PyCon te gaan. Ik hield een lezing, ik zou daar maar een paar mensen leren kennen, ik ging een hele week. (...) Ik had me echter geen zorgen moeten maken. PyCon was fenomenaal geweldig! (...) Iedereen was ongelooflijk vriendelijk en extravert, zo erg dat ik zelden tijd vond om niet met mensen te praten!
-  
+
   _I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!_
   <p markdown="1" class="pquote-credit">
 — @jhamrick, ["Hoe ik heb geleerd om te stoppen met piekeren en van PyCon te houden"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -116,7 +116,7 @@ Concentreer u tijdens het schrijven van uw lezing op wat uw publiek interessant
 <aside markdown="1" class="pquote">
   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
   Wanneer u begint met het schrijven van uw lezing, ongeacht wat uw onderwerp is, kan het helpen als u uw lezing ziet als een verhaal dat u aan mensen vertelt.
-  
+
   _When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people._
   <p markdown="1" class="pquote-credit">
 — Lena Reinhard, ["Hoe u een Tech Conferentie Lezing voorbereidt en schrijft"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
@@ -130,7 +130,7 @@ Zoek naar conferenties die specifiek zijn voor uw taal of ecosysteem. Voordat u
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
   Ik schreef heel vriendelijk naar de JSConf-mensen en smeekte hen om me een slot te geven waar ik het op JSConf EU kon presenteren. (...) Ik was enorm bang toen ik dit ding presenteerde waar ik al een half jaar aan werkte. (...) De hele tijd dacht ik alleen maar: oh mijn God. Wat doe ik hier?
-  
+
   _I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?_
   <p markdown="1" class="pquote-credit">
 — @ry, ["Historie van Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
@@ -146,7 +146,7 @@ Door nieuwkomers te helpen, middelen te delen en doordachte bijdragen te leveren
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
   De enige reden waarom urllib3 tegenwoordig de populairste Python-bibliotheek van derden is, is omdat het deel uitmaakt van verzoeken.
-  
+
   _The only reason urllib3 is the most popular third-party Python library today is because it's part of requests._
   <p markdown="1" class="pquote-credit">
 — @shazow, ["Hoe u uw open source-project kunt laten floreren"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
@@ -157,16 +157,6 @@ Het is nooit te vroeg of te laat om uw reputatie op te bouwen. Zelfs als u uw ei
 
 Er is geen oplossing van de ene op de andere dag om een publiek op te bouwen. Het vertrouwen en respect van anderen winnen kost tijd, en het opbouwen van uw reputatie houdt nooit op.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS werd begin 2011 voor het eerst uitgebracht. (...) Ik verspreidde het woord op de gebruikelijke manieren: ik twitterde erover, ik schreef blogposts over dingen die je ermee kon doen, ik noemde het tijdens verschillende discussies in meetups. Toen het in 2014 bekender werd, ben ik er presentaties over gaan geven.
-  
-  _PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it._
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Open source-beheerder verhalen"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## Keep at it!
 
 Het kan lang duren voordat mensen uw open source-project opmerken. Dat is goed! Enkele van de meest populaire projecten van vandaag hebben jaren geduurd om een hoog activiteitsniveau te bereiken. Concentreer u op het opbouwen van relaties in plaats van te hopen dat uw project spontaan populair zal worden. Wees geduldig en blijf uw werk delen met degenen die het op prijs stellen.
diff --git a/_articles/nl/getting-paid.md b/_articles/nl/getting-paid.md
index 404eac9f95a..c6528dba1cb 100644
--- a/_articles/nl/getting-paid.md
+++ b/_articles/nl/getting-paid.md
@@ -78,17 +78,6 @@ Tegenwoordig worden veel mensen betaald om part- of fulltime aan open source te
 
 Het is gemakkelijker om een pleidooi te houden voor open source-werk als je werkgever het project ook daadwerkelijk gebruikt, maar wees creatief met je pitch. Misschien gebruikt je werkgever het project niet, maar ze gebruiken Python, en het onderhouden van een populair Python-project helpt nieuwe Python-ontwikkelaars aan te trekken. Misschien zorgt het ervoor dat uw werkgever er in het algemeen ontwikkelaarvriendelijker uitziet.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Zoals velen in open source, worstelde ik met de last om een project te onderhouden. Toen ik voor het eerst met open source begon, bleef ik gewoon te laat om eraan te werken of toen ik thuiskwam. (...) Ik was in staat om met mijn baas de problemen te bespreken waarmee ik werd geconfronteerd en we kwamen met ideeën over hoe we open source-taken konden integreren met ons eigen gebruik van Babel.
-
-  _Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel._
-
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["Open source-onderhouder verhalen"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 Als je geen bestaand open source-project hebt waaraan je zou willen werken, maar liever hebt dat je huidige werkoutput open source is, pleit er dan voor dat je werkgever een deel van hun interne software open source maakt.
 
 Veel bedrijven ontwikkelen open source-programma's om hun merk op te bouwen en talent van hoge kwaliteit te werven.
diff --git a/_articles/pl/finding-users.md b/_articles/pl/finding-users.md
index c45561cf24e..0049f58f8f5 100644
--- a/_articles/pl/finding-users.md
+++ b/_articles/pl/finding-users.md
@@ -155,16 +155,6 @@ Nigdy nie jest za wcześnie ani za późno, aby zacząć budować swoją reputac
 
 Nie ma jednodniowego rozwiązania dla budowania widowni. Zdobycie zaufania i szacunku innych wymaga czasu, a budowanie reputacji nigdy się nie kończy.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  <i>
-  PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it.
-  </i>
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## Tak trzymaj!
 
 Może minąć dużo czasu, zanim ludzie zauważą twój projekt open source. W porządku! Niektóre z najbardziej popularnych projektów zajęły lata, aby osiągnąć wysoki poziom aktywności. Skoncentruj się na budowaniu relacji, zamiast mieć nadzieję, że twój projekt spontanicznie zyska popularność. Bądź cierpliwy i dziel się swoją pracą z tymi, którzy ją doceniają.
diff --git a/_articles/pl/getting-paid.md b/_articles/pl/getting-paid.md
index 90c71a59f88..2bd71809a34 100644
--- a/_articles/pl/getting-paid.md
+++ b/_articles/pl/getting-paid.md
@@ -74,16 +74,6 @@ Obecnie wiele osób otrzymuje wynagrodzenie za pracę w niepełnym lub pełnym w
 
 Łatwiej jest uzasadnić pracę z otwartym kodem źródłowym, jeśli twój pracodawca faktycznie korzysta z projektu, ale dobrym pomysłem byłoby kreatywne uzasadnienie swojej prośby. Być może twój pracodawca nie korzysta z projektu, ale używa Pythona, a utrzymanie popularnego projektu w Pythonie pomaga przyciągnąć nowych deweloperów języka Python. Może to sprawić, że twój pracodawca będzie wydawał się bardziej atrakcyjny dla innych programistów.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  <i>
-  Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.
-  </i>
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 Jeśli nie masz istniejącego projektu typu open source, nad którym chciałbyś pracować, możesz poprosić swojego pracodawcę aby wydał część wewnętrznego oprogramowania jako open source.
 
 Wiele firm opracowywuje programy typu open source, aby budować swoją markę i rekrutować utalentowanych pracowników.
diff --git a/_articles/pt/finding-users.md b/_articles/pt/finding-users.md
index 3ea6cf6fb88..2db6d191baa 100644
--- a/_articles/pt/finding-users.md
+++ b/_articles/pt/finding-users.md
@@ -143,14 +143,6 @@ Nunca é cedo demais ou tarde demais para iniciar a construir sua reputação. M
 
 Não há uma solução instantânea para a construção de uma audiência. Ganhar a confiança e o respeito dos outros leva tempo, e a construção de sua reputação nunca acaba.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS foi lançado pela primeira vez no início de 2011. (...) Eu espalhei a palavra da maneira usual: Eu "twittava" sobre isso, escrevia posts de blog sobre o que você pode fazer com isso, o mencionei durante várias discussões em meetups. Quando ficou mais conhecido em 2014, comecei a fazer apresentações sobre o assunto.
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## Continue assim!
 
 Pode levar um longo tempo antes das pessoas notarem seu projeto open source. Está tudo bem! Alguns dos projetos mais populares hoje levaram anos para atingir os níveis mais altos de atividade. Concentre-se em construir relacionamentos em vez de esperar que seu projeto espontâneamente ganhe popularidade. Seja paciente, e mantenha-se compartilhando seu trabalho com aqueles que o apreciam.
diff --git a/_articles/pt/getting-paid.md b/_articles/pt/getting-paid.md
index 057948160d4..c87e517cbde 100644
--- a/_articles/pt/getting-paid.md
+++ b/_articles/pt/getting-paid.md
@@ -66,14 +66,6 @@ Hoje, muitas pessoas são pagas para trabalhar parcial ou integralmente com open
 
 É mais fácil convencer o seu empregador se sua empresa, de fato, utilizar o seu projeto, mas seja criativo com a sua proposta. Talvez seu projeto não seja utilizado, mas Python sim, e manter um projeto Python popular ajude a atrair novos desenvolvedores Python. Pode fazer com que sua empresa pareça mais developer-friendly, de um modo geral.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Como muitos no open source, eu estava sustentando o fardo de manter um projeto. Quando eu comecei com o open source, eu costumava ficar acordado até tarde para trabalhar nisso ou assim que chegava em casa. (...) Eu tive a oportunidade de discutir com meu chefe sobre os problemas que estava enfrentando e tivemos várias ideias sobre como poderíamos incorporar tarefas open source baseadas no nosso próprio uso do Babel.
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 Se você não tem um projeto open source no qual gostaria de contribuir, mas contribuiria se o que fosse produzido no seu trabalho fosse de open source, convença o seu empregador a abrir o código de alguns dos softwares internos da empresa.
 
 Muitas empresas estão desenvolvendo programas open source para construir suar marca e recrutar talentos de qualidade.
diff --git a/_articles/ro/finding-users.md b/_articles/ro/finding-users.md
index 45f0aa42697..991646f871f 100644
--- a/_articles/ro/finding-users.md
+++ b/_articles/ro/finding-users.md
@@ -192,21 +192,6 @@ Nu este niciodată prea devreme, sau prea tâziu, să începi să-ți construie
 
 Nu există o soluție peste noapte de a construi un public. Obținerea încrederii și respectului celorlalți ia timp, și construirea reputației tale nu se sfârșește niciodată.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  <p>
-    PhantomJS a fost lansat prima dată la începutul lui 2011. (...) Am răspândit cuvântul prin căile obișnuite: am tweet-uit despre el, am scris postări de blog despre lucruri pe care le poți face cu el, l-am menționat în timpul variatelor discuții din întâlniri. Când a devenit mai cunoscut în 2014, am început să țin prezentări despre el.
-  </p>
-  <p>
-    <em>
-      PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it.
-    </em>
-  </p>
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## Continuă!
 
 Este posibil să dureze mult înainte ca utilizatorii să observe proiectul tău cu sursă deschisă. Este în regulă! Unele dintre cele mai populare proiecte de astăzi au avut nevoie de ani pentru a atinge nivele înalte de activitate. Concentrează-te pe a construi relații în loc de a spera că proiectul tău va câștiga popularitate în mod spontan. Fii răbdător, și continuă să împărtășești munca ta cu cei care o apreciază.
diff --git a/_articles/ro/getting-paid.md b/_articles/ro/getting-paid.md
index 0077dae8563..e104b801d14 100644
--- a/_articles/ro/getting-paid.md
+++ b/_articles/ro/getting-paid.md
@@ -94,21 +94,6 @@ Astăzi, mulți oameni sunt plătiți să lucreze cu normă parțială sau într
 
 Este mai ușor să faci un caz pentru muncă open source dacă angajatorul tău folosește de fapt proiectul, dar devino creativ cu pasul tău. Poate angajatorul tău nu folosește proiectul, dar el folosește Python, și întreținerea unui proiect popular Python ajută la atragerea de noi dezvoltatori Python. Poate îl face pe angajatorul tău să arate mai prietenos cu dezvoltatorii în general.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  <p>
-    La fel ca mulți în open source, mă luptam cu povara de a întreține un proiect. Când am început prima dată să fac open source, obișnuiam doar să stau până târziu la muncă pe asta sau chiar când ajungeam acasă. (...) Puteam să discut cu șeful meu despre problemele cu care mă confruntam și noi am venit cu idei despre cum am putea să încorporăm sarcini open source dată fiind propria noastră utilizare Babel.
-  </p>
-  <p>
-    <em>
-      Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.
-    </em>
-  </p>
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 Dacă nu ai un proiect cu sursă deschisă existent pe care ți-ar plăcea să lucrezi, dar preferi ca să se deschidă sursa rezultatelor muncii tale curente, fă un caz pentru angajatorul tău să deschidă sursa unei părți din software-urile sale interne.
 
 Multe companii dezvoltă programe open source pentru a-și construi marca și a recruta talent de calitate.
diff --git a/_articles/ru/getting-paid.md b/_articles/ru/getting-paid.md
index 602964b3d40..a5ec47189d9 100644
--- a/_articles/ru/getting-paid.md
+++ b/_articles/ru/getting-paid.md
@@ -42,7 +42,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
-Спросите любого сопровождающего проект с открытым кодом, и он расскажет вам, какой объем работы уходит на управление проектом. У вас есть клиенты. Вы решаете для них проблемы. Вы создаете новые функции. Возникает большая потребность в вашем времени.  
+Спросите любого сопровождающего проект с открытым кодом, и он расскажет вам, какой объем работы уходит на управление проектом. У вас есть клиенты. Вы решаете для них проблемы. Вы создаете новые функции. Возникает большая потребность в вашем времени.
 <p markdown="1" class="pquote-credit">
 — @ashedryden, ["Этика неоплачиваемого труда в сообществах открытого кода"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
   </p>
@@ -66,14 +66,6 @@ related:
 
 Если ваш работодатель действительно использует проект, будет проще обосновать необходимость работы над открытым кодом, но подойдите к делу творчески. Возможно, ваш работодатель не использует этот проект, но он использует питон, а поддержка популярного проекта питон помогает привлечь новых разработчиков питон. Может быть, это в целом делает вашего работодателя более дружелюбным к разработчикам.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-Как и многие другие разработчики ПО с открытым кодом, я боролся с бременем поддержки проекта. Когда я только начинал заниматься открытым кодом, я просто задерживался допоздна, чтобы поработать над ним, или прямо по возвращении домой. (...) Я смог обсудить со своим начальником проблемы, с которыми я столкнулся, и мы пришли к идее о том, что мы могли бы включить в работу задачи с открытым кодом, учитывая наше собственное использование Babel.  
-<p markdown="1" class="pquote-credit">
-— @hzoo, ["Истории сопровождающих"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 Если у вас нет существующего проекта с открытым кодом, над которым вы хотели бы работать, но вы предпочитаете, чтобы ваши текущие результаты работы были с открытым кодом, попросите вашего работодателя открыть код некоторых внутренних программ.
 
 Многие компании разрабатывают программы с открытым кодом, чтобы создать свой бренд и нанять квалифицированных специалистов.
diff --git a/_articles/ta/finding-users.md b/_articles/ta/finding-users.md
index 45fa862ffe9..f1cbf3561d4 100644
--- a/_articles/ta/finding-users.md
+++ b/_articles/ta/finding-users.md
@@ -143,14 +143,6 @@ related:
 
 பார்வையாளர்களை உருவாக்குவதற்கு ஒரே இரவில் தீர்வு இல்லை. நம்பிக்கையையும் மற்றவர்களுடைய மரியாதையையும் பெற்றுக்கொள்வது நேரம் எடுக்கும், உங்கள் நற்பெயரைக் கட்டி முடிக்காது.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  2011ன் தொடக்கத்தில் முதல்முறையாக PhantomJS வெளியிடப்பட்டது. (...) நான் வழக்கமான வழிகளில் வார்த்தையை பரப்பினேன்: நான் அதை பற்றி கீச்சினேன், நான் அதை வைத்து செய்ய முடியும் விஷயங்களை இடுகைகள் எழுதினார், நான் சந்திப்புகள் பல்வேறு விவாதங்களின் போது அதை குறிப்பிட்டுள்ளேன். அது 2014 ல் நன்கு அறியப்பட்டபோது, அதைப் பற்றி விளக்கங்களைத் தரத் தொடங்கினேன்.
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["பராமரிப்பாளர் கதைகள்"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## பொறுமை காக்கவும்
 
 உங்கள் திறந்த மூல திட்டத்தை மக்கள் கவனிக்க முன் நீண்ட நேரம் எடுக்கலாம். பரவாயில்லை! மிக பிரபலமான சில திட்டங்கள் இன்று அதிக அளவில் நடவடிக்கைகளை எட்டுவதற்கு பல ஆண்டுகள் எடுத்தன. உங்கள் திட்டம் தன்னிச்சையாக புகழ் பெறும் என்று நம்புவதற்குப் பதிலாக உறவுகளை மேம்படுத்தவதில் கவனம் செலுத்துங்கள். பொறுமையாக இருங்கள், உங்கள் வேலையைப் பாராட்டுபவர்களுடன் பகிர்ந்து கொள்ளுங்கள்.
diff --git a/_articles/ta/getting-paid.md b/_articles/ta/getting-paid.md
index 29a2861e9eb..a4064ff4896 100644
--- a/_articles/ta/getting-paid.md
+++ b/_articles/ta/getting-paid.md
@@ -66,14 +66,6 @@ related:
 
 உங்கள் முதலாளி உண்மையிலேயே திட்டத்தை பயன்படுத்துகிறார்களானால், திறந்த மூல வேலைக்கு ஒரு விஷயத்தை எளிதாக்கலாம், ஆனால் உங்கள் சுருதிடன் ஆக்கப்பூர்வமாகப் பெறலாம். ஒருவேளை உங்கள் முதலாளி இந்த திட்டத்தை பயன்படுத்தவில்லை, ஆனால் பைதான் பயன்படுத்தப்படுகிறது, மேலும் பிரபலமான பைத்தான் திட்டத்தை பராமரிக்க புதிய பைத்தான் நிரல் உருவாக்குபவர்களை ஈர்க்கிறது. ஒருவேளை அது உங்கள் முதலாளி பொதுவாக நிரலர் நட்புக்கு மிகவும் பொருத்தமானதாக இருக்கும்.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  திறந்த மூலத்தில் பலரைப் போலவே, ஒரு திட்டத்தை பராமரிப்பதற்கான சுமையோடு நான் போராடினேன். நான் முதலில் திறந்த மூலத்தை ஆரம்பித்தபோது, நான் வேலைக்குச் செல்வதில் தாமதம் அல்லது நான் வீட்டிற்கு வந்தவுடன் வேலை செய்வதாயிருந்தது. (...) என் முதலாளியுடன் நான் எதிர்கொள்ளும் பிரச்சினைகள் பற்றி விவாதிக்க முடிந்தது மற்றும் நாம் பாபேலில் சொந்த பயன்பாடு கொடுக்கப்பட்ட திறந்த மூல பணிகளை எப்படி இணைத்துக்கொள்ள முடியும் என்ற கருத்துக்கள் வந்தது.
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["பராமரிப்பாளர் கதைகள்"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 நீங்கள் வேலை செய்ய உங்களிடம் திறந்த மூல திட்டப்பணி இல்லை என்றால், தற்போதைய பணி வெளியீடு திறந்த மூலமாக்க, உங்கள் சொந்த மென்பொருளில் சிலவற்றை திறக்க உங்கள் முதலாளிக்கு ஒரு வழக்கு உருவாக்கவும்.
 
 பல நிறுவனங்கள் திறந்த மூல திட்டங்களை தங்கள் வியாபாரக் குறி உருவாக்க மற்றும் செயல் திறனை மிக்கவர்களை பணியமர்த்துவதற்கு உருவாக்குகின்றன.
diff --git a/_articles/tr/getting-paid.md b/_articles/tr/getting-paid.md
index c35fe6d7b34..6e51deec62b 100644
--- a/_articles/tr/getting-paid.md
+++ b/_articles/tr/getting-paid.md
@@ -66,14 +66,6 @@ Bugün, birçok insana yarı zamanlı veya tam zamanlı olarak açık kaynak üz
 
 Eğer işvereniniz projeyi gerçekten kullanıyorsa, işiniz daha kolay, ancak adımınızda yaratıcı olun. Belki işvereniniz projeyi kullanmaz, ancak Python'u kullanır ve popüler bir Python projesini sürdürmek yeni Python geliştiricilerini çekmeye yardımcı olur. Belki işvereninizin genel olarak geliştirici dostu görünmesini sağlar.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  Açık kaynak kodlu birçok kişi gibi ben de bir projeyi sürdürme yüküyle mücadele ediyordum. Açık kaynak yapmaya ilk başladığımda, üzerinde çalışmak için geç saatlere kadar ofiste kaldım ya da eve geldiğimde uğraştım. (...) Patronumla karşılaştığım sorunları tartışabildim ve Babel'i kendi kullanımımıza göre açık kaynak kodlu görevleri nasıl dahil edebileceğimize dair fikirler bulduk.
-  <p markdown="1" class="pquote-credit">
-- @hzoo, ["Geliştirici Hikayeleri"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 Üzerinde çalışmak istediğiniz bir açık kaynak projeniz yoksa, ancak mevcut iş çıktınızın açık kaynaklı olmasını tercih ederseniz, işvereninizin kendi iç yazılımlarının bir kısmının kaynağını açması için bir öneride bulunun.
 
 Birçok şirket markalarını geliştirmek ve kaliteli yetenekler kazanmak için açık kaynaklı programlar geliştiriyor.
diff --git a/_articles/zh-hans/finding-users.md b/_articles/zh-hans/finding-users.md
index 9c2f10443dd..37d969e64cb 100644
--- a/_articles/zh-hans/finding-users.md
+++ b/_articles/zh-hans/finding-users.md
@@ -144,14 +144,6 @@ redirect_from: /zh-cn/finding-users/
 
 建立用户群没有一蹴而就的方法。获取别人的信任和尊重需要时间，同样，建立声望的过程也永远不会停止。
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/ariya?s=180" class="pquote-avatar" alt="avatar">
-  PhantomJS公开第一个版本的时候是在2011年初。我也就是用了一些常规的方法来推广：发Twitter，写博客告诉别人可以用它来做什么，在各种各样的聚会上我都提到过它。到2014年它已经广为人知的时候，我才开始做关于它的演讲。
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## 保持下去!
 
 有时候，让人们注意你的开源项目会花费很多时间。但是没关系！一些今天很流行的项目都是花了很多年才有如今的高活跃度。把重点放在建立声望上而不是企图一夜成名。耐心一点，一如既往的和那些可能会从中受益的人分享你的项目。
diff --git a/_articles/zh-hans/getting-paid.md b/_articles/zh-hans/getting-paid.md
index 8ffbf583b9c..1747187e37b 100644
--- a/_articles/zh-hans/getting-paid.md
+++ b/_articles/zh-hans/getting-paid.md
@@ -67,14 +67,6 @@ redirect_from: /zh-cn/getting-paid/
 
 如果你的老板使用到了相应的项目，那么人们找到对应的开源工作就顺理成章，当然这需要你有足够的能力来担当。也有的情况是老板没有使用到相应的开源项目，但是用到了诸如 Python 之类的开源编程语言，那么能够维护流行的开源编程语言项目可以帮助老板吸引到相应的开发者。又或者都不是，那老板也可以获得对开发者友好的口碑。
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/hzoo?s=180" class="pquote-avatar" alt="avatar">
-  就像很多开源项目的故事一样，我花了大量的时间来维护项目。当我第一次开始为开源做事情的时候，我在公司待到很晚才回家。（...)然后我就和老板谈，就开源的任务当作本来的工作来做。
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["一名维护者的故事"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 如果你现在还没有为开源项目做工作，但是你希望你现在所做得成绩开源出来，那么你可以和你的老板讲，奉劝他将内部的软件开源。
 
 很多公司都在开发开源项目，从而能够打造自己的品牌，以及希望雇佣到高质量的人才。
diff --git a/_articles/zh-hant/finding-users.md b/_articles/zh-hant/finding-users.md
index 94cbc2150dd..dd78e00343b 100644
--- a/_articles/zh-hant/finding-users.md
+++ b/_articles/zh-hant/finding-users.md
@@ -144,14 +144,6 @@ redirect_from: /zh-tw/finding-users/
 
 建立用戶群沒有一蹴而就的方法。獲取別人的新人和尊重需要時間，同樣，建立聲望的過程也永遠不會停止。
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars1.githubusercontent.com/u/7288?v=3&s=460" class="pquote-avatar" alt="avatar">
-  PhantomJS公開第一個版本的時候實在2011年初。我也就是用一些常規的方法來推廣：發Twitter，寫博客告訴別人可以用它來做什麼，在各種各樣的聚會上我都提到過它。當2014年他已經廣爲人知的時候。我才開始做關於它的演講。
-  <p markdown="1" class="pquote-credit">
-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya)
-  </p>
-</aside>
-
 ## 保持精進
 
 有時候，讓人麼注意你的開源專案會花費很多時間。但是沒關係！現在很多流行的專案也都是花了很多年才有今天的活躍度。把重點放在建立聲望上而不是企圖一夜成名。耐心一點，一如既往的和那些可能會從中受益的人們分享你的專案。
diff --git a/_articles/zh-hant/getting-paid.md b/_articles/zh-hant/getting-paid.md
index 2d083b27ff5..876f39c44ff 100644
--- a/_articles/zh-hant/getting-paid.md
+++ b/_articles/zh-hant/getting-paid.md
@@ -67,14 +67,6 @@ redirect_from: /zh-tw/getting-paid/
 
 如果你的老闆使用了該開源專案，贊助的事情自然就比較好談，盡量發揮創意地去向雇主提案。也可能雇主沒有使用到開源專案，但他們有使用 Python ，用來經營一個熱門的專案，吸引有興趣的 Python 開發者，又或者都不是，那老闆也至少營造了一個對開發者友善的環境。
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars3.githubusercontent.com/u/588473?v=3&s=460" class="pquote-avatar" alt="avatar">
-  就像很多開源專案的故事一樣，我花了大量的時間來維護專案。當我第一次開始爲開源做事情的時候，我在公司待到很晚才回家。（...)然後我就和老闆談，就開源的任務當作本來的工作來做。
-  <p markdown="1" class="pquote-credit">
-— @hzoo, ["一位維護者的故事"](https://github.com/open-source/stories/hzoo)
-  </p>
-</aside>
-
 如果你現在還沒有爲開源專案做工作，但是你希望你現在所做得成績開源出來，那麼你可以和你的老闆講，奉勸他將內部的軟體開源。
 
 很多公司都在開發開源專案，從而能夠打造自己的品牌，以及希望僱傭到高質量的人才。

From 0391c1601deb4c7754b65c3165d2813bc963fc41 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@gmail.com>
Date: Tue, 3 Jan 2023 16:07:17 -0500
Subject: [PATCH 422/749] remove link to another open-source stories link

---
 _articles/fa/getting-paid.md      | 1 -
 _articles/fr/getting-paid.md      | 1 -
 _articles/hu/getting-paid.md      | 1 -
 _articles/id/getting-paid.md      | 1 -
 _articles/ja/getting-paid.md      | 1 -
 _articles/ko/getting-paid.md      | 1 -
 _articles/ms/getting-paid.md      | 1 -
 _articles/nl/getting-paid.md      | 1 -
 _articles/pl/getting-paid.md      | 1 -
 _articles/pt/getting-paid.md      | 1 -
 _articles/ro/getting-paid.md      | 1 -
 _articles/ru/getting-paid.md      | 1 -
 _articles/ta/getting-paid.md      | 1 -
 _articles/tr/getting-paid.md      | 1 -
 _articles/zh-hans/getting-paid.md | 1 -
 _articles/zh-hant/getting-paid.md | 1 -
 16 files changed, 16 deletions(-)

diff --git a/_articles/fa/getting-paid.md b/_articles/fa/getting-paid.md
index fd6887bdfae..0293a100568 100644
--- a/_articles/fa/getting-paid.md
+++ b/_articles/fa/getting-paid.md
@@ -115,7 +115,6 @@ related:
 اگر از قبل مخاطب یا اعتبار بالایی داشته باشید یا پروژه‌ی شما از محبوبیت بالایی برخوردار باشد، یافتن حمایت‌های مالی امکان‌پذیر است. چند نمونه از پروژه‌های حمایت شده:
 
 * پروژه‌ی **[webpack](https://github.com/webpack)** از طریق [OpenCollective](https://opencollective.com/webpack) از شرکت‌ها و اشخاص پول جمع‌آوری می‌کند
-* بودجه‌ی **[Vue](https://github.com/vuejs/vue)** از طریق [Patreon](https://github.com/open-source/stories/yyx990803) تأمین می‌شود
 * **[Ruby Together](https://rubytogether.org/)،** یک سازمان غیر‌انتفاعی است که هزینه‌های کار در [bundler](https://github.com/bundler/bundler)،  [RubyGems](https://github.com/rubygems/rubygems) و سایر پروژه‌های بر پایه‌ی زیرساختی «Ruby» را پرداخت می‌کند
 
 ### ایجاد یک منبع درآمدی
diff --git a/_articles/fr/getting-paid.md b/_articles/fr/getting-paid.md
index 3e64e034e3e..1f70efd7f01 100644
--- a/_articles/fr/getting-paid.md
+++ b/_articles/fr/getting-paid.md
@@ -111,7 +111,6 @@ Trouver des commandites fonctionne bien si vous avez déjà un public ou une ré
 Quelques exemples de projets sponsorisés incluent:
 
 * **[webpack](https://github.com/webpack)** collecte des fonds auprès des entreprises et des particuliers [via OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** est [financé par Patreon](https://github.com/open-source/stories/yyx990803)
 * **[Ruby Together](https://rubytogether.org/),** une organisation à but non lucratif qui paie pour travailler sur [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), et d'autres projets d'infrastructure Ruby
 
 ### Créer un flux de revenus
diff --git a/_articles/hu/getting-paid.md b/_articles/hu/getting-paid.md
index 2a023d94bbe..114e4e67583 100644
--- a/_articles/hu/getting-paid.md
+++ b/_articles/hu/getting-paid.md
@@ -117,7 +117,6 @@ Könnyű szponzorokat találni, ha már erős közönséged vagy jó hírneved v
 Néhány példa:
 
 * **[webpack](https://github.com/webpack)** magánszemélyektől és cégektől is támogatáshoz jut [az OpenCollective-en keresztül](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** [a Patreon-on keresztül jut támogatáshoz](https://github.com/open-source/stories/yyx990803)
 * **[Ruby Together](https://rubytogether.org/),** egy non-profit szervezet, amely támogatja a [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), és egyéb Ruby infrastruktúra projekteket
 
 ### Hozz létre bevételi forrást
diff --git a/_articles/id/getting-paid.md b/_articles/id/getting-paid.md
index 90446ad9515..e41f5fce280 100644
--- a/_articles/id/getting-paid.md
+++ b/_articles/id/getting-paid.md
@@ -110,7 +110,6 @@ Seiring dengan popularitas open source, menemukan pendanaan untuk proyek masih b
 Mencari sponsor bisa dilakukan jika Anda memiliki pengguna atau reputasi yang kuat, atau proyek Anda sangat populer. Beberapa proyek yang disponsori meliputi:
 
 * **[webpack](https://github.com/webpack)** mendapatkan pendanaan dari perusahaan dan perseorangan [melalui OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** [didanai melalui Patreon](https://github.com/open-source/stories/yyx990803)
 * **[Ruby Together](https://rubytogether.org/),** organisasi nirlaba yang membayar untuk bekerja pada [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), dan proyek infrastruktur Ruby lainnya.
 
 ### Menciptakan pendapatan
diff --git a/_articles/ja/getting-paid.md b/_articles/ja/getting-paid.md
index e242c1378d8..26f2eaf24bc 100644
--- a/_articles/ja/getting-paid.md
+++ b/_articles/ja/getting-paid.md
@@ -115,7 +115,6 @@ related:
 あなたが既に協力者や強力な名声を築いていたり、プロジェクトが非常に有名なのであれば、スポンサーを探すのはうまくいくでしょう。スポンサーを得たプロジェクトの例を幾つか挙げます：
 
 * **[webpack](https://github.com/webpack)** は [OpenCollective を通じて](https://opencollective.com/webpack)企業や個人から資金を得ています。
-* **[Vue](https://github.com/vuejs/vue)** は [Patreon を通じて資金を得ています](https://github.com/open-source/stories/yyx990803)。
 * **[Ruby Together](https://rubytogether.org/)** という非営利団体は [bundler](https://github.com/bundler/bundler) や [RubyGems](https://github.com/rubygems/rubygems) といった Ruby の基盤プロジェクトに資金を提供しています。
 
 ### 収益源を作る
diff --git a/_articles/ko/getting-paid.md b/_articles/ko/getting-paid.md
index 933a9cd3ad2..d7dd7199a10 100644
--- a/_articles/ko/getting-paid.md
+++ b/_articles/ko/getting-paid.md
@@ -111,7 +111,6 @@ I was looking for a "hobby" programming project that would keep me occupied duri
 스폰서 프로젝트의 몇 가지 예는 다음과 같습니다.
 
 * **[webpack](https://github.com/webpack)** 는 [OpenCollective를 통해](https://opencollective.com/webpack) 회사와 개인에게 돈을 모읍니다
-* **[Vue](https://github.com/vuejs/vue)** 는 [Patreon를 통해 펀드됩니다](https://github.com/open-source/stories/yyx990803)
 * **[Ruby Together](https://rubytogether.org/)는,** [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems) 및 기타 Ruby 인프라 프로젝트에 대한 비용을 지불하는 비영리 단체입니다.
 
 ### 수입원 만들기
diff --git a/_articles/ms/getting-paid.md b/_articles/ms/getting-paid.md
index bebc3185a4f..c2f75a3b525 100644
--- a/_articles/ms/getting-paid.md
+++ b/_articles/ms/getting-paid.md
@@ -116,7 +116,6 @@ Mencari tajaan berfungsi dengan baik jika anda sudah mempunyai khalayak atau rep
 Beberapa contoh projek yang ditaja termasuk:
 
 * **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803)
 * **[Ruby Together](https://rubytogether.org/),** organisasi bukan untung yang membayar untuk bekerja [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), dan projek infrastruktur Ruby yang lain
 
 ### Buat aliran pendapatan
diff --git a/_articles/nl/getting-paid.md b/_articles/nl/getting-paid.md
index c6528dba1cb..0101227d3c7 100644
--- a/_articles/nl/getting-paid.md
+++ b/_articles/nl/getting-paid.md
@@ -131,7 +131,6 @@ Het vinden van sponsoring werkt goed als je al een sterk publiek of een sterke r
 Enkele voorbeelden van gesponsorde projecten zijn:
 
 * **[webpack](https://github.com/webpack)** zamelt geld in bij bedrijven en particulieren [via OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** wordt [gefinancierd via Patreon](https://github.com/open-source/stories/yyx990803)
 * **[Ruby Together](https://rubytogether.org/),** een non-profitorganisatie die betaalt voor werk aan [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), en andere Ruby-infrastructuurprojecten
 
 ### Creëer een inkomstenstroom
diff --git a/_articles/pl/getting-paid.md b/_articles/pl/getting-paid.md
index 2bd71809a34..5fa29669221 100644
--- a/_articles/pl/getting-paid.md
+++ b/_articles/pl/getting-paid.md
@@ -126,7 +126,6 @@ Znalezienie sponsorów działa dobrze, jeśli masz już odpowiednią publicznoś
 Kilka przykładów sponsorowanych projektów to:
 
 * **[webpack](https://github.com/webpack)** zbiera pieniądze od firm i osób prywatnych [poprzez OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** jest [finansowany przez Patreon](https://github.com/open-source/stories/yyx990803)
 * **[Ruby Together](https://rubytogether.org/),** organizacja non-profit, która płaci za pracę [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), i inne projekty infrastruktury Ruby
 
 ### Utwórz strumień przychodów
diff --git a/_articles/pt/getting-paid.md b/_articles/pt/getting-paid.md
index c87e517cbde..23c350710da 100644
--- a/_articles/pt/getting-paid.md
+++ b/_articles/pt/getting-paid.md
@@ -116,7 +116,6 @@ Encontrar patrocínio funciona bem se você já tem uma forte audiência ou repu
 Alguns exemplos de patrocínio incluem:
 
 * O **[webpack](https://github.com/webpack)** arrecada dinheiro de empresas e indivíduos [através do OpenCollective](https://opencollective.com/webpack)
-* O **[Vue](https://github.com/vuejs/vue)** é [financiado através do Patreon](https://github.com/open-source/stories/yyx990803)
 * A **[Ruby Together](https://rubytogether.org/),** é uma organização sem fins lucrativos que paga pelo trabalho no [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), e outros projetos de infraestrutura do Ruby.
 
 ### Crie um fluxo de receita
diff --git a/_articles/ro/getting-paid.md b/_articles/ro/getting-paid.md
index e104b801d14..9e8f3fda107 100644
--- a/_articles/ro/getting-paid.md
+++ b/_articles/ro/getting-paid.md
@@ -153,7 +153,6 @@ Găsirea sponsorizărilor funcționează bine dacă ai deja un public puternic s
 Câteva exemple de proiecte sponsorizate includ:
 
 * **[webpack](https://github.com/webpack)** strânge bani de la companii și indivizi [prin OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** este [finanțat prin Patreon](https://github.com/open-source/stories/yyx990803)
 * **[Ruby Together](https://rubytogether.org/),** o organizație nonprofit care plătește pentru munca pe [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), și alte proiecte de infrastructură Ruby
 
 ### Creează un flux de venit
diff --git a/_articles/ru/getting-paid.md b/_articles/ru/getting-paid.md
index a5ec47189d9..24d12aedf6b 100644
--- a/_articles/ru/getting-paid.md
+++ b/_articles/ru/getting-paid.md
@@ -115,7 +115,6 @@ related:
 Вот несколько примеров спонсируемых проектов:
 
 * **[webpack](https://github.com/webpack)** привлекает деньги от компаний и частных лиц [through OpenCollective](https://opencollective.com/webpack)
-* **[Vue](https://github.com/vuejs/vue)** [спонсируется через Patreon](https://github.com/open-source/stories/yyx990803)
 * **[вместе с Ruby](https://rubytogether.org/),** - некоммерческая организация, которая платит за работу над [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), и над другими проектами инфраструктуры Ruby
 
 ### Создайте поток доходов
diff --git a/_articles/ta/getting-paid.md b/_articles/ta/getting-paid.md
index a4064ff4896..246d0195899 100644
--- a/_articles/ta/getting-paid.md
+++ b/_articles/ta/getting-paid.md
@@ -111,7 +111,6 @@ related:
 நிதியளிக்கும் திட்டங்களின் சில உதாரணங்கள் பின்வருமாறு:
 
 * **[வெப்பேக்](https://github.com/webpack)** நிறுவனங்கள் மற்றும் தனிநபர்களிடமிருந்து [OpenCollective மூலம்](https://opencollective.com/webpack) நிதி திரட்டுகிறது
-* **[Vue](https://github.com/vuejs/vue)**  [பேட்ரன் மூலம் நிதியளிக்கப்பட்டது](https://github.com/open-source/stories/yyx990803)
 * **[ரூபி டுகேதர்](https://rubytogether.org/),**  [பண்ட்லர்](https://github.com/bundler/bundler), [ரூபிஜெம்ஸ்](https://github.com/rubygems/rubygems), மற்றும் பிற ரூபி உள்கட்டமைப்பு திட்டங்களுக்கு பணிக்கு பணம் செலுத்துகின்ற ஒரு இலாப நோக்கமற்ற அமைப்பு
 
 ### வருவாய் நீரோடை உருவாக்கவும்
diff --git a/_articles/tr/getting-paid.md b/_articles/tr/getting-paid.md
index 6e51deec62b..f46ae1ed6b8 100644
--- a/_articles/tr/getting-paid.md
+++ b/_articles/tr/getting-paid.md
@@ -115,7 +115,6 @@ Açık kaynağın popülaritesi arttıkça, projelere fon bulmak için hala dene
 Sponsorluk bulmak, zaten güçlü bir kitleye veya şöhrete sahipseniz veya projeniz çok popülerse işe yarar. Sponsorlu projelere birkaç örnek:
 
 * **[webpack](https://github.com/webpack)** [OpenCollective](https://opencollective.com/webpack) üzerinden şirketler ve bireylerden para topladı
-* **[Vue](https://github.com/vuejs/vue)** [Patreon](https://github.com/open-source/stories/yyx990803) üzerinden finanse ediliyor
 * **[Ruby Together](https://rubytogether.org/) ,** [paketleyici](https://github.com/bundler/bundler) , [RubyGems](https://github.com/rubygems/rubygems) ve diğer Ruby altyapı projelerinde işe yarayan kar amacı gütmeyen bir organizasyon
 
 ### Bir gelir akışı oluşturun
diff --git a/_articles/zh-hans/getting-paid.md b/_articles/zh-hans/getting-paid.md
index 1747187e37b..a6c650c7102 100644
--- a/_articles/zh-hans/getting-paid.md
+++ b/_articles/zh-hans/getting-paid.md
@@ -107,7 +107,6 @@ redirect_from: /zh-cn/getting-paid/
 一些获得组织资助的项目案例：
 
 * **[webpack](https://github.com/webpack),**  [通过 OpenCollective](https://opencollective.com/webpack) 从公司和个人来筹集资金
-* **[Vue](https://github.com/vuejs/vue),** 由 @yyx990803 创建，[通过 Patreon](https://github.com/open-source/stories/yyx990803) 获得资助
 * **[Ruby Together](https://rubytogether.org/),** 由 @indirect 创建的非盈利组织 ，为诸如 [bundler](https://github.com/bundler/bundler)、[RubyGems](https://github.com/rubygems/rubygems)、以及其它的一些 Ruby 的基础设施项目提供资金支持
 
 尽管开源日渐的流行，但是为项目寻找资金仍处于试验阶段。目前所收集到的包括：
diff --git a/_articles/zh-hant/getting-paid.md b/_articles/zh-hant/getting-paid.md
index 876f39c44ff..05325e33beb 100644
--- a/_articles/zh-hant/getting-paid.md
+++ b/_articles/zh-hant/getting-paid.md
@@ -107,7 +107,6 @@ redirect_from: /zh-tw/getting-paid/
 一些獲得組織資助的專案案例：
 
 * **[webpack](https://github.com/webpack),**  [通過 OpenCollective](https://opencollective.com/webpack) 從公司和個人來籌集資金
-* **[Vue](https://github.com/vuejs/vue),** 由 @yyx990803 創建，[通過 Patreon](https://github.com/open-source/stories/yyx990803)獲得資助
 * **[Ruby Together](https://rubytogether.org/),** 由 @indirect 創建的非盈利組織 ，爲諸如 [bundler](https://github.com/bundler/bundler)、[RubyGems](https://github.com/rubygems/rubygems)、以及其它的一些 Ruby 的基礎設施專案提供資金支持
 
 儘管開源日漸的流行，但是爲專案尋找資金仍然是處於試驗中。目前所收集到的包括：

From 83964e05fc49bba39352d215c0c2285d32db5140 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@gmail.com>
Date: Tue, 3 Jan 2023 16:13:22 -0500
Subject: [PATCH 423/749] remove block quote

---
 _articles/de/how-to-contribute.md      | 12 ------------
 _articles/es/how-to-contribute.md      |  8 --------
 _articles/fa/how-to-contribute.md      |  8 --------
 _articles/fr/how-to-contribute.md      |  8 --------
 _articles/how-to-contribute.md         |  8 --------
 _articles/hu/how-to-contribute.md      |  9 ---------
 _articles/id/how-to-contribute.md      |  8 --------
 _articles/ja/how-to-contribute.md      |  8 --------
 _articles/ko/how-to-contribute.md      |  8 --------
 _articles/ms/how-to-contribute.md      |  8 --------
 _articles/nl/how-to-contribute.md      | 11 -----------
 _articles/pl/how-to-contribute.md      | 10 ----------
 _articles/pt/how-to-contribute.md      |  8 --------
 _articles/ro/how-to-contribute.md      | 15 ---------------
 _articles/ru/how-to-contribute.md      |  8 --------
 _articles/ta/how-to-contribute.md      |  8 --------
 _articles/tr/how-to-contribute.md      |  8 --------
 _articles/zh-hans/how-to-contribute.md |  8 --------
 18 files changed, 161 deletions(-)

diff --git a/_articles/de/how-to-contribute.md b/_articles/de/how-to-contribute.md
index 4b42858fafa..4d8f47dc28c 100644
--- a/_articles/de/how-to-contribute.md
+++ b/_articles/de/how-to-contribute.md
@@ -80,18 +80,6 @@ Ein weit verbreiteter Irrtum! Aber in Wirklichkeit sind es oft andere Projektasp
 
 Auch wenn Sie gerne Code schreiben, sind andere Beitragsarten eine gute Möglichkeit, sich an einem Projekt zu beteiligen und andere Leute aus der Community zu treffen. Solche Beziehungen aufzubauen, ebnet Ihnen den Weg zur Mitarbeit an anderen Projektaspekten.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-
-  Ich habe mich zum ersten Mal an das Python-Entwicklungsteam ("python-dev") gewandt, als ich am 17. Juni 2002 eine E-Mail bezüglich eines Patches von mir an die Mailingliste schickte. Das Open-Source-Fieber packte mich sofort und ich beschloss, E-Mail-Zusammenfassungen für die Gruppe zu kuratieren. So hatte ich immer eine gute Ausrede, um mir Dinge erklären zu lassen. Aber noch wichtiger war die Möglichkeit, schnell mitzubekommen wenn jemand auf einen Reparaturbedarf hinwies.
-
-  _I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing._
-
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### Planen Sie gerne Veranstaltungen?
 
 * Veranstalten Sie Workshops oder Meetups über das Projekt, wie @fzamperin [für NodeSchool](https://github.com/nodeschool/organizers/issues/406)
diff --git a/_articles/es/how-to-contribute.md b/_articles/es/how-to-contribute.md
index 36d37673e05..d6ba5d58d41 100644
--- a/_articles/es/how-to-contribute.md
+++ b/_articles/es/how-to-contribute.md
@@ -68,14 +68,6 @@ Un error conceptual com&uacute;n acerca de contribuir con el c&oacute;digo abier
 
 Incluso si te gusta codificar, otro tipo de contribuciones son una gran manera de involucrarse con un proyecto y conocer a otros miembros de la comunidad. Construir esas relaciones te dar&aacute; oportunidades de trabajar en otras partes del proyecto.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  Llegu&eacute; por primera vez al equipo de desarrollo de Python (alias python-dev) cuando envi&eacute; un correo electr&oacute;nico a su lista de correos el 17 de junio de 2002, aceptando mi parche. R&aacute;pidamente me encontr&eacute; con un error de c&oacute;digo abierto, y decid&iacute; comenzar a limpiar el resumen de correos electr&oacute;nicos para el grupo. Me dieron una gran excusa para pedir aclaraciones sobre un tema, pero principalmente pude notar cu&aacute;ndo alguien señalaba algo que necesitaba ser reparado.
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Hostorias de un encargado"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### ¿Te gusta planificar eventos?
 
 * Organiza workshops o reuniones acerca del proyecto, [como hizo @fzamperin para NodeSchool](https://github.com/nodeschool/organizers/issues/406)
diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 84ceea2dde5..6bfdf1ffb77 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -72,14 +72,6 @@ related:
 
 حتی اگر هم به کدنویسی در پروژه علاقه‌مند باشید، روش‌های دیگر مشارکت بهترین راه‌برای درگیر شدن در یک پروژه و ملاقات با اعضای انجمن‌های دیگر وجود دارد. ساختن این روابط به شما فرصت‌هایی می‌دهد تا در بخش‌های دیگر پروژه مشارکت کنید.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  زمانی که درخواست مشارکتم را در 17 ژوئن سال 2002 به تیم توسعه‌ی پایتون با نام مستعار <span dir="rtl">(python-dev)</span> ارسال کردم، توانستم اولین مشارکتم را با آن‌ها شروع کنم. به سرعت باگ‌ها و خطاهای پروژه‌ی متن باز را پیدا می‌کردم و تصمیم می‌گرفتم خلاصه‌های آن را برای گروه تنظیم کنم. آن‌ها بهانه‌های زیادی می‌آوردند که یک موضوع را روشن کنم، اما با تمام انتقادات، زمانی که هر کسی برای برطرف کردن یک مشکل به کمک نیاز داشت، من آن را متوجه می‌شدم.
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### آیا به برگزاری رویدادها علاقه‌مند هستید؟
 
 * ورکشاپ‌ها (کارگاه‌ها) را سازماندهی یا جلسات پروژه را برگزار کنید، مانند کاری که @fzamperin برای  [NodeSchool](https://github.com/nodeschool/organizers/issues/406) انجام داد
diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md
index bd74af09175..79d9c25edf3 100644
--- a/_articles/fr/how-to-contribute.md
+++ b/_articles/fr/how-to-contribute.md
@@ -68,14 +68,6 @@ Une idée commune fausse sur la contribution à l'open source est que vous devez
 
 Même si vous aimez écrire du code, d'autres types de contributions sont un excellent moyen de s'impliquer dans un projet et de rencontrer d'autres membres de la communauté. Construire ces relations vous donnera l'opportunité de travailler sur d'autres parties du projet.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  J'ai d'abord contacté l'équipe de développement de Python (alias python-dev) quand j'ai envoyé un mail à la liste de diffusion le 17 juin 2002 pour accepter mon patch. J'ai rapidement attrapé le bogue open source, et j'ai décidé de commencer à organiser des résumés d'emails pour le groupe. Ils m'ont donné une bonne excuse pour demander des éclaircissements sur un sujet, mais d'un point de vue plus critique je pouvais remarquer quand quelqu'un a signalait quelque chose qui avait besoin d'être réparé.
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### Aimez-vous la planification d'événements ?
 
 * Organiser des ateliers ou des meetups sur le projet, [comme @fzamperin a fait pour NodeSchool](https://github.com/nodeschool/organizers/issues/406)
diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index c2ec46bc89e..17a04ad9821 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -72,14 +72,6 @@ A common misconception about contributing to open source is that you need to con
 
 Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing.
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### Do you like planning events?
 
 * Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
diff --git a/_articles/hu/how-to-contribute.md b/_articles/hu/how-to-contribute.md
index 899a77272d0..e7be38930e1 100644
--- a/_articles/hu/how-to-contribute.md
+++ b/_articles/hu/how-to-contribute.md
@@ -68,15 +68,6 @@ Gyakori tévhit a nyílt forráskódhoz való hozzájárulásról, hogy programo
 
 Még ha szeretsz is programozni, akkor is nagyszerű módja a projektben való részvételnek vagy hogy találkozz közösségi tagokkal az, hogy más jellegű hozzájárulásod van a projekthez. Ezeknek a kapcsolatoknak a kiépítése lehetőséget teremt arra, hogy a projekt egyéb részein dolgozz.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  Az első kapcsolatom a Python fejlesztői csapattal (python-dev) az volt, amikor a 2002 június 17-én kértem őket a levelező listán, hogy fogadják el a javításomat.
-  Gyorsan rákattantam a nyílt forráskódra, így elhatároztam, hogy kezelni fogom a csoport levelezési listáját. Nagyszerű lehetőséget biztosítottak, hogy az adott témában a kérdéseket tisztázzuk, de még fontosabb, hogy észrevettem, ha valaki rámutatott valamire, ami javításra szorult.
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Fenntartói Történetek"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### Szeretsz rendezvényt szervezni?
 
 * Szervezz gyakorlati előadásokat vagy találkozókat a projektről, [ahogy @fzamperin csinálja a NodeSchool-nál](https://github.com/nodeschool/organizers/issues/406)
diff --git a/_articles/id/how-to-contribute.md b/_articles/id/how-to-contribute.md
index f47582740dc..b3d2cb2c763 100644
--- a/_articles/id/how-to-contribute.md
+++ b/_articles/id/how-to-contribute.md
@@ -68,14 +68,6 @@ Kesalahpahaman yang sering terjadi tentang berkontribusi pada open source adalah
 
 Meskipun Anda suka untuk menulis kode program, kontribusi jenis lain merupakan cara yang baik untuk bisa berpartisipasi pada proyek dan bertemu dengan anggota komunitas lainnya. Membangun hubungan tersebut akan memberikan Anda kesempatan untuk bekerja pada bagian lain dari proyek.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  Saya pertama kali menghubungi tim pengembang Python (python-dev) ketika saya mengirimkan pesan email kepada mailing list pada 17 Juni 2002 tentang perbaikan dari saya. Saya dengan cepat menemukan kesalahan, dan memutuskan untuk mulai memilih email dari grup. Mereka memberikan saya alasan yang baik untuk bertanya tentang klarifikasi sebuah topik, tetapi yang lebih penting lagi saya mampu mendeteksi apabila seseorang menunjukkan sesuatu yang perlu diperbaiki.
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### Apakah Anda suka merencanakan kegiatan?
 
 * Mengelola workshop atau acara pertemuan tentang proyek, [seperti yang dilakukan @fzamperin untuk NodeSchool](https://github.com/nodeschool/organizers/issues/406)
diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md
index 1cfd6d87701..dfecc9a1157 100644
--- a/_articles/ja/how-to-contribute.md
+++ b/_articles/ja/how-to-contribute.md
@@ -68,14 +68,6 @@ related:
 
 たとえコードを書くことが好きであったとしても、他の種類のコントリビュートはプロジェクトに関わり、他のコミュニティメンバーに会う良いやり方です。このような関係を作ることはそのプロジェクトの他の部分に関わる人と仕事をする機会を与えてくれます。
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  私が初めて Python 開発チーム(別名 python-dev )と接触したのは、2002年6月17日に私のパッチを受け入れてもらうためにメーリングリストにメールをした時でした。私はすぐにオープンソースバグに遭遇し、グループのためにメールの要約を整理し始めることにしました。彼らは、私の各トピックについての質問に寛大に接してくれましたが、更に非常に重要だったのが、誰かが修正が必要であるなにかを指摘した時にすぐに気づくことができるようになったということでした。
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### イベントを計画するのが好きですか？
 
 * [@fzamperin が NodeSchool でやったように](https://github.com/nodeschool/organizers/issues/406)ワークショップやミートアップを開催する
diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md
index 71a86b36272..44a441e8e9b 100644
--- a/_articles/ko/how-to-contribute.md
+++ b/_articles/ko/how-to-contribute.md
@@ -68,14 +68,6 @@ related:
 
 코드를 작성하는 것을 좋아해도, 다른 유형의 기여는 프로젝트에 참여하고 다른 커뮤니티 구성원을 만날 수 있는 좋은 방법입니다. 이러한 관계를 구축하면 프로젝트의 다른 부분에서 작업할 기회를 얻을 수 있습니다.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing.
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories”](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### 행사 계획 짜는 걸 좋아하세요?
 
 * [NodeSchool을 위해 @fzamperin이 했던 것처럼](https://github.com/nodeschool/organizers/issues/406), 프로젝트에 관한 워크샵이나 미팅 조직하기
diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
index 6e1e863869b..ea1bc6af630 100644
--- a/_articles/ms/how-to-contribute.md
+++ b/_articles/ms/how-to-contribute.md
@@ -72,14 +72,6 @@ Kesalahpahaman umum mengenai menyumbang kepada sumber terbuka ialah anda perlu m
 
 Walaupun anda suka menulis kod, jenis sumbangan lain adalah kaedah terbaik untuk terlibat dengan projek dan bertemu dengan ahli komuniti lain. Membina hubungan tersebut akan memberi anda peluang untuk bekerja di bahagian lain projek.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  Saya pertama kali menghubungi pasukan pengembangan Python (aka python-dev) ketika saya menghantar e-mel kepada senarai mel pada 17 Jun 2002 mengenai penerimaan tampalan saya. Saya dengan cepat menangkap bug sumber terbuka, dan memutuskan untuk mula menguruskan pencernaan e-mel untuk kumpulan itu. Mereka memberi saya alasan yang baik untuk meminta penjelasan mengenai sesuatu topik, tetapi lebih kritikal saya dapat melihat ketika seseorang menunjukkan sesuatu yang perlu diperbaiki.
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### Adakah anda suka merancang acara?
 
 * Mengadakan bengkel atau pertemuan mengenai projek tersebut,[like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md
index 738d8db6807..4d561689084 100644
--- a/_articles/nl/how-to-contribute.md
+++ b/_articles/nl/how-to-contribute.md
@@ -77,17 +77,6 @@ Een veel voorkomende misvatting over bijdragen aan open source is dat je code mo
 
 Zelfs als je graag code schrijft, zijn andere soorten bijdragen een geweldige manier om bij een project betrokken te raken en andere leden van de gemeenschap te ontmoeten. Door die relaties op te bouwen, krijg je de kans om aan andere delen van het project te werken.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  Ik nam voor het eerst contact op met het Python-ontwikkelingsteam (ook bekend als python-dev) toen ik de mailinglijst op 17 juni 2002 e-mailde over het accepteren van mijn patch. Ik ontdekte snel de open source-bug en besloot om e-mailsamenvattingen voor de groep te gaan beheren. Ze gaven me een geweldig excuus om opheldering over een onderwerp te vragen, maar kritischer merkte ik dat iemand op iets wees dat moest worden opgelost.
-  
-  _I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing._
-  
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### Houd je van het plannen van evenementen?
 
 * Organiseer workshops of meetups over het project, [zoals @fzamperin deed voor NodeSchool](https://github.com/nodeschool/organizers/issues/406)
diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index 6f139ccb303..399cd50af2f 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -76,16 +76,6 @@ Powszechnym błędnym przekonaniem na temat przyczyniania się do open source je
 
 Nawet jeśli lubisz pisać kod, inne rodzaje wkładów to świetny sposób na zaangażowanie się w projekt i poznanie innych członków społeczności. Budowanie tych relacji da ci możliwość pracy nad innymi częściami projektu.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  <i>
-  I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing.
-  </i>
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### Czy lubisz planować wydarzenia?
 
 * Organizuj warsztaty lub spotkania dotyczące projektu, [jak @fzamperin dla NodeSchool](https://github.com/nodeschool/organizers/issues/406)
diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md
index 4f2939e754d..e6ee8a1c380 100644
--- a/_articles/pt/how-to-contribute.md
+++ b/_articles/pt/how-to-contribute.md
@@ -68,14 +68,6 @@ Um equívoco comum sobre contribuir para o open source é que você precisa cont
 
 Mesmo se você gosta de escrever código, outros tipos de contribuições são uma ótima maneira de se envolver com um projeto e conhecer outros membros da comunidade. Construir esses relacionamentos lhe dará oportunidades de trabalhar em outras partes do projeto.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  Eu entrei em contato com a equipe de desenvolvimento do Python (também conhecida como python-dev) quando enviei um email para a lista de discussão em 17 de junho de 2002 sobre a aceitação do meu patch. Eu rapidamente peguei o bug do open source e decidi começar a curar os resumos de e-mail para o grupo. Eles me deram uma ótima desculpa para pedir esclarecimentos sobre um tópico, mas, mais criticamente, pude perceber quando alguém apontou algo que precisava ser consertado.
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### Você gosta de planejar eventos?
 
 * Organize workshops ou encontros sobre o projeto, [como @fzamperin fez para NodeSchool](https://github.com/nodeschool/organizers/issues/406)
diff --git a/_articles/ro/how-to-contribute.md b/_articles/ro/how-to-contribute.md
index 33c67e44a2b..ed1a435c010 100644
--- a/_articles/ro/how-to-contribute.md
+++ b/_articles/ro/how-to-contribute.md
@@ -82,21 +82,6 @@ O neînțelegere comună despre contribuirea la open source este că trebuie să
 
 Chiar dacă îți place să scrii cod, alte tipuri de contribuții sunt o cale grozavă de a te implica într-un proiect și de a întâlni alți membri ai comunității. Construind aceste relații îți va da oportunități de a lucra pe alte părți ale proiectului.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  <p>
-    Întâi am luat legătura cu echipa de dezvoltare Python (numită și python-dev) când am trimis email la lista de email-uri în 17 iunie 2002 pentru a-mi accepta patch-ul. Am prins repede bug-ul din sursa deschisă, și am decis să încep să organizez rezumatele email-urilor pentru grup. Ei mi-au dat o scuză grozavă pentru a cere clarificări despre un subiect, dar mai critic am putut observa când cineva indica ceva ce necesita rezolvare.
-  </p>
-  <p>
-    <em>
-      I first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing.
-    </em>
-  </p>
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["Maintainer Stories"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### Îți place să planifici evenimente?
 
 * Organizează ateliere sau întâlniri despre proiect, [precum @fzamperin a făcut pentru NodeSchool](https://github.com/nodeschool/organizers/issues/406)
diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index 78f454f737a..ddef7a39287 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -72,14 +72,6 @@ related:
 
 Даже если вам нравится писать код, другие виды помощи — отличный способ поучаствовать в проекте и познакомиться с другими членами сообщества. Налаживание таких отношений даст вам возможность работать над другими частями проекта.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  Я впервые обратился к команде разработчиков Python (также известной как python-dev), когда 17 июня 2002 года в список рассылки отправил электронное письмо с просьбой принять мой патч. Я быстро заметил баг в коде и решил начать готовить почтовые дайджесты для группы. Это послужило отличным предлогом попросить разъяснений по теме, но, что более важно, я мог заметить, когда кто-то указывал на то, что требовало исправления.
-  <p markdown="1" class="pquote-credit">
-  — @brettcannon, ["Истории мейнтейнера"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### Нравится планировать мероприятия?
 
 * Организуйте семинары или митапы по проекту, [что и сделал @fzamperin в NodeSchool](https://github.com/nodeschool/organizers/issues/406)
diff --git a/_articles/ta/how-to-contribute.md b/_articles/ta/how-to-contribute.md
index 79b4691e714..38afc0e72ea 100644
--- a/_articles/ta/how-to-contribute.md
+++ b/_articles/ta/how-to-contribute.md
@@ -68,14 +68,6 @@ related:
 
 நீங்கள் குறியீட்டை எழுத விரும்பினால் கூட, பிற வகையான பங்களிப்புகள் ஒரு திட்டத்துடன் தொடர்பு கொள்ளவும் மற்ற சமூக உறுப்பினர்களை சந்திக்கவும் சிறந்த வழியாகும். அந்த உறவுகளை கட்டியெழுப்புதல் திட்டத்தின் மற்ற பகுதிகளிலும் வேலை செய்ய உங்களுக்கு வாய்ப்பளிக்கும்.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
- ஜூன் 17, 2002 அன்று என் சீரமைப்புகளை ஏற்றுக்கொள்வதைப் பற்றி நான் அஞ்சல் பட்டியலில் பைத்தான் மேம்பாட்டுக் குழுவிடம் (அதாவது பைத்தான்-டெவ்) மின்னஞ்சல் அனுப்பினேன். நான் விரைவாக திறந்த மூல பிழையைப் கண்டறிந்தேன், குழுவிற்கு மின்னஞ்சல் சுருக்கத் தொகுப்புக்களைத் தொகுத்து அனுப்ப முடிவு செய்தேன். ஒரு தலைப்பைப் பற்றிய விளக்கங்களைக் கேட்கும் பொழுது அவர்கள் பொறுத்துக்கொள்ள சொன்ன பொழுது, ஆனால் யாரோ ஒருவர் நெருக்கடி உள்ள ஒன்றை செய்ய வேண்டி சுட்டிக்காட்டியதை நான் கவனிக்க முடிந்தது.
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["பராமரிப்பாளர் கதைகள்"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### நிகழ்வு திட்டமிடல்களை விரும்புகிறீர்களா?
 
 * திட்டம் பற்றி பட்டறைகள் அல்லது சந்திப்புகளை ஏற்பாடு செய்யுங்கள், [@fzamperin NodeSchoolக்கு செய்ததை போல](https://github.com/nodeschool/organizers/issues/406)
diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md
index 53044406517..e97b7d07903 100644
--- a/_articles/tr/how-to-contribute.md
+++ b/_articles/tr/how-to-contribute.md
@@ -72,14 +72,6 @@ Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak ka
 
 Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve diğer topluluk üyeleriyle tanışmak için harika bir yoldur. Bu ilişkileri kurmak size projenin diğer bölümlerinde de çalışma fırsatı verecektir.
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  İlk önce 17 Haziran 2002 tarihinde düzeltme yamamı e-postayla gönderdiğimde Python geliştirme ekibine (aka python-dev) ulaştım. Hızlı bir şekilde hatayı yakaladım ve grubun e-posta özetlerini iyileştirmeye başladım. Bir konu hakkında net bilgi almak için bana büyük bir bahane verdiler, ama daha kritik olarak, birinin düzeltilmesi gereken bir şeyi işaret ettiğini fark ettim.
-  <p markdown="1" class="pquote-credit">
-- @brettcannon, ["Geliştirme Hikayeleri"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### Etkinlik planlamayı sever misiniz?
 
 * [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin
diff --git a/_articles/zh-hans/how-to-contribute.md b/_articles/zh-hans/how-to-contribute.md
index 3afcb6123ea..cfb7eb262e3 100644
--- a/_articles/zh-hans/how-to-contribute.md
+++ b/_articles/zh-hans/how-to-contribute.md
@@ -69,14 +69,6 @@ redirect_from: /zh-cn/how-to-contribute/
 
 即使你是一位开发者，非代码的贡献对于项目来说也是举足轻重的，尤其是对于社区的其他成员来说。用心维系这些关系能够让你有工作到项目其它部分的机会。
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  我第一次接触 Python 开发团队（简称 python-dev）是在 2002年6月17日，当时我是向其邮件列表发送了一份邮件，是关于请求通过我的补丁的。我很快就又发现了开源的 bug，于是决定开始为小组收集邮件摘要，然后他们给了我一个澄清问题的理由，但是更加重要的是，我能够捕获到某人指出需要修复的问题。
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["维护者的故事"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### 是否热衷于规划事件？
 
 * 为项目组织研讨会或线下分享，[一如 @fzamperin 为 NodeSchool 所做的那样](https://github.com/nodeschool/organizers/issues/406)

From 4e23dc6a4814cf581bd7118a20e946cae23e41bc Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@gmail.com>
Date: Tue, 3 Jan 2023 16:33:18 -0500
Subject: [PATCH 424/749] remove more links

---
 _articles/building-community.md         | 2 +-
 _articles/de/building-community.md      | 2 +-
 _articles/es/building-community.md      | 2 +-
 _articles/fa/building-community.md      | 2 +-
 _articles/fr/building-community.md      | 2 +-
 _articles/hu/building-community.md      | 2 +-
 _articles/id/building-community.md      | 2 +-
 _articles/ja/building-community.md      | 2 +-
 _articles/ko/building-community.md      | 2 +-
 _articles/ms/building-community.md      | 2 +-
 _articles/nl/building-community.md      | 2 +-
 _articles/pl/building-community.md      | 2 +-
 _articles/pt/building-community.md      | 2 +-
 _articles/ro/building-community.md      | 2 +-
 _articles/ru/building-community.md      | 2 +-
 _articles/ta/building-community.md      | 2 +-
 _articles/tr/building-community.md      | 2 +-
 _articles/zh-hans/building-community.md | 2 +-
 _articles/zh-hant/building-community.md | 2 +-
 docs/personas.md                        | 2 +-
 20 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/_articles/building-community.md b/_articles/building-community.md
index 9f113f2c97c..90d73dd6eda 100644
--- a/_articles/building-community.md
+++ b/_articles/building-community.md
@@ -225,7 +225,7 @@ Under a consensus seeking process, community members discuss major concerns unti
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
   Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom's decision making process
   </p>
 </aside>
 
diff --git a/_articles/de/building-community.md b/_articles/de/building-community.md
index 434aab8c084..46792f9abe9 100644
--- a/_articles/de/building-community.md
+++ b/_articles/de/building-community.md
@@ -257,7 +257,7 @@ Im Rahmen der Konsensfindungsprozesses diskutieren die Mitglieder der Gemeinscha
   _Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do (...) is that it is my job to listen to the community._
 
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom's decision making process
   </p>
 </aside>
 
diff --git a/_articles/es/building-community.md b/_articles/es/building-community.md
index dfde0450769..fe289f559de 100644
--- a/_articles/es/building-community.md
+++ b/_articles/es/building-community.md
@@ -227,7 +227,7 @@ Bajo un proceso de b&uacute;squeda de concenso, los miembros de la comunidad dis
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
   Parte de la raz&oacute;n por la que la votaci&oacute;n no existe para Cuestiones At&oacute;micas es porque un Grupo At&oacute;mico no llevar&aacute; adelante un sistema de votaci&oacute;n en todos los casos. Algunas veces tenemos que elegir lo que nos parece correcto incluso aunque no sea popular. (...) Lo que puedo ofrecer y prometo hacer... es escuchar a la comunidad.
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom's decision making process
   </p>
 </aside>
 
diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md
index a5f61057489..15cc1d0c63d 100644
--- a/_articles/fa/building-community.md
+++ b/_articles/fa/building-community.md
@@ -226,7 +226,7 @@ related:
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
   بخشی از دلیل اینکه چرا یک سامانه رای گیری برای موضوعات اتمی وجود ندارد بدین خاطر است که تیم اتمی قصد ندارد که از یک سیستم رای گیری در همه موارد بهره گیرد. گاهی اوقات ما باید آنچیزی را انتخاب کنیم که درست است حتی اگر آن معروف نباشد. (...) آنچه من می توانم پیشنهاد کنم و برای انجام آن تقاضا کنم این است که کار من این است که به انجمن گوش فرا دهم.
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom's decision making process
   </p>
 </aside>
 
diff --git a/_articles/fr/building-community.md b/_articles/fr/building-community.md
index 7626e8651a3..557ae48e8db 100644
--- a/_articles/fr/building-community.md
+++ b/_articles/fr/building-community.md
@@ -224,7 +224,7 @@ Dans le cadre d'un processus de recherche de consensus, les membres de la commun
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
   Une partie de la raison pour laquelle un système de vote n'existe pas pour les issues Atom est parce que l'équipe Atom ne va pas suivre un système de vote dans tous les cas. Parfois, nous devons choisir ce que nous ressentons, même si c'est impopulaire. (...) Ce que je peux offrir et m'engager à faire... c'est que c'est mon travail d'écouter la communauté.
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom's decision making process
   </p>
 </aside>
 
diff --git a/_articles/hu/building-community.md b/_articles/hu/building-community.md
index eaebc5a5eeb..e771c1f5641 100644
--- a/_articles/hu/building-community.md
+++ b/_articles/hu/building-community.md
@@ -225,7 +225,7 @@ Konszenzuskeresési folyamat keretében a közösség tagjai megbeszélik a legf
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
   Az egyik ok, amiért nem létezik szavazási rendszer az Atom Issues számára az, hogy az Atom csapata nem minden esetben követi a szavazás módszerét. Időnként azt kell választanunk, hogy mit érzünk helyesnek, még akkor is, ha az nem éppen népszerű. (...) Amit felajánlhatok és vállalhatok az, hogy a közösség meghallgatása az én dolgom.
   <p markdown="1" class="pquote-credit">
-— @lee-dohm az [Atom döntési folyamata](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm az Atom döntési folyamata
   </p>
 </aside>
 
diff --git a/_articles/id/building-community.md b/_articles/id/building-community.md
index aa6a0ec5c84..01235e4efda 100644
--- a/_articles/id/building-community.md
+++ b/_articles/id/building-community.md
@@ -224,7 +224,7 @@ Pada proses _consensus seeking_, anggota komunitas mendiskusikan masalah utama s
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
   Salah satu alasan kenapa sistem voting tidak berlaku untuk masalah Atom adalah karena tim Atom tidak akan mengikuti sistem voting pada setiap kasusnya. Seringkali kami harus memilih apa yang kami rasa benar meskipun tidak populer. (...) Apa yang bisa saya tawarkan dan janjikan...adalah karena itu merupakan pekerjaan saya untuk mendengarkan komunitas.
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom's decision making process
   </p>
 </aside>
 
diff --git a/_articles/ja/building-community.md b/_articles/ja/building-community.md
index a48da3edb85..90e84ac2a83 100644
--- a/_articles/ja/building-community.md
+++ b/_articles/ja/building-community.md
@@ -224,7 +224,7 @@ README は[単なる手順書以上の存在です](../starting-a-project/#readm
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
   Atom の Issue に投票システムが存在しない理由の一部は、 Atom チームはあらゆるケースにおいて投票システムを使うわけではないからです。時には、あまり支持されていなくても、正しいと感じることを選ぶ必要があります。（中略）私が提供し、実施すると固く約束するのは…、コミュニティの意見に耳を傾けることが私の仕事であるということです。
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom's decision making process
   </p>
 </aside>
 
diff --git a/_articles/ko/building-community.md b/_articles/ko/building-community.md
index d57c79e5acb..307442652bb 100644
--- a/_articles/ko/building-community.md
+++ b/_articles/ko/building-community.md
@@ -225,7 +225,7 @@ README 파일은 [단순한 안내서 이상](../starting-a-project/#readme-파
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
   Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom’s decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom’s decision making process
   </p>
 </aside>
 
diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
index 4abeb4db33e..4226e9d79a7 100644
--- a/_articles/ms/building-community.md
+++ b/_articles/ms/building-community.md
@@ -225,7 +225,7 @@ Di bawah proses pencarian konsensus, anggota masyarakat membincangkan masalah ut
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
   Sebahagian daripada sebab mengapa sistem pemungutan suara tidak ada untuk Masalah Atom adalah kerana pasukan Atom tidak akan mengikuti sistem pengundian dalam semua hal. Kadang-kadang kita harus memilih apa yang kita rasa betul walaupun tidak popular. (...) Apa yang dapat saya tawarkan dan berjanji untuk dilakukan ... adalah tugas saya untuk mendengarkan masyarakat.
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom's decision making process
   </p>
 </aside>
 
diff --git a/_articles/nl/building-community.md b/_articles/nl/building-community.md
index aec4c76ea6b..15b99b75b94 100644
--- a/_articles/nl/building-community.md
+++ b/_articles/nl/building-community.md
@@ -246,7 +246,7 @@ In het kader van een proces voor het zoeken naar consensus, bespreken leden van
   _Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community._
 
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's besluitvormingsproces](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom's besluitvormingsproces
   </p>
 </aside>
 
diff --git a/_articles/pl/building-community.md b/_articles/pl/building-community.md
index dfe32b40d59..ea217246994 100644
--- a/_articles/pl/building-community.md
+++ b/_articles/pl/building-community.md
@@ -239,7 +239,7 @@ W ramach procesu poszukiwania konsensusu członkowie społeczności omawiają g
   Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
   </i>
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom's decision making process
   </p>
 </aside>
 
diff --git a/_articles/pt/building-community.md b/_articles/pt/building-community.md
index c2d8bff939d..89c93b66a5e 100644
--- a/_articles/pt/building-community.md
+++ b/_articles/pt/building-community.md
@@ -222,7 +222,7 @@ Sob o processo de busca por um consenso, membros da comunidade discutem questõe
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
   Parte da razão do porquê um sistema de votos não existe para as issues do Atom é porque o time do Atom não irá seguir um sistema de votação em todos os casos. Algumas vezes temos de escolher o que acreditamos que é certo, mesmo que isso seja impopular. (...) O que posso oferecer e prometer fazer ... é que é meu trabalho ouvir a comunidade.
   <p markdown="1" class="pquote-credit">
-  — @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+  — @lee-dohm on Atom's decision making process
   </p>
 </aside>
 
diff --git a/_articles/ro/building-community.md b/_articles/ro/building-community.md
index 91bae141fb6..68b61861dd8 100644
--- a/_articles/ro/building-community.md
+++ b/_articles/ro/building-community.md
@@ -277,7 +277,7 @@ Uneori, votarea este o departajare necesară. Totuși, cât de mult poți, accen
     </em>
   </p>
   <p markdown="1" class="pquote-credit">
-— @lee-dohm privind [procesul de luare a deciziilor al Atom](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm privind procesul de luare a deciziilor al Atom
   </p>
 </aside>
 
diff --git a/_articles/ru/building-community.md b/_articles/ru/building-community.md
index 49a9c1d9804..d36599b4600 100644
--- a/_articles/ru/building-community.md
+++ b/_articles/ru/building-community.md
@@ -225,7 +225,7 @@ related:
   <img src = "https://avatars.githubusercontent.com/lee-dohm?s=180" class = "pquote-avatar" alt = "avatar">
   Отчасти причина того, что система голосования не применяется для проблем Atom, заключается в том, что команда Atom не собирается следовать системе голосования во всех случаях. Иногда нам приходится выбирать то, что мы считаем правильным, даже если это непопулярно. (...) Что я могу предложить и обещаю сделать... так это то, что моя работа — слушать сообщество.
   <p markdown = "1" class = "pquote-credit">
-— @lee-dohm о [процессе принятия решений в Atom](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm о процессе принятия решений в Atom
   </p>
 </aside>
 
diff --git a/_articles/ta/building-community.md b/_articles/ta/building-community.md
index d402badbf53..f7e17cdb471 100644
--- a/_articles/ta/building-community.md
+++ b/_articles/ta/building-community.md
@@ -224,7 +224,7 @@ related:
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
   ஆட்டம்(Atom) குழு அனைத்து சந்தர்ப்பங்களிலும் வாக்களிப்பு முறையை பின்பற்றுவதற்குப் போவதில்லை என்பதால் Atom சிக்கல்களுக்கு ஒரு வாக்கெடுப்பு முறை இல்லை. சில நேரங்களில் நாம் எது சரியானது என்று நினைக்கிறோமோ அதை தேர்வு செய்வது சரியே அது செல்வாக்கற்றதாக இருந்தாலும். (...) நான் என்ன செய்ய முடியும் மற்றும் செய்ய உறுதிமொழி கொடுக்கமுடியும் ... சமூகத்தை கவனிப்பது என் வேலை என்று ஆகிறது.
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom's decision making process
   </p>
 </aside>
 
diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md
index 5b300567650..db9461e5b0e 100644
--- a/_articles/tr/building-community.md
+++ b/_articles/tr/building-community.md
@@ -225,7 +225,7 @@ Bir uzlaşma arayışı sürecinde, topluluk üyeleri yeterince duyulduğunu his
   <img class="pquote-avatar" alt="avatar" src="https://avatars.githubusercontent.com/lee-dohm?s=180">
   Atom sorunları için bir oylama sisteminin bulunmamasının bir nedeni de Atom ekibinin her durumda bir oylama sistemini takip etmemesi. Bazen popüler olmasa bile neyin doğru olduğunu düşündüğümüzü seçmek zorundayız. (...) Yapabileceğim ve yapmayı taahhüt edebileceğim şey, toplumu dinlemek benim işim.
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom's decision making process
   </p>
 </aside>
 
diff --git a/_articles/zh-hans/building-community.md b/_articles/zh-hans/building-community.md
index ac65ba58346..2c77538531b 100644
--- a/_articles/zh-hans/building-community.md
+++ b/_articles/zh-hans/building-community.md
@@ -231,7 +231,7 @@ README [不仅仅是一组指令](../starting-a-project/#撰写自述文件)。
 Atom Issues不存在投票系统的部分原因是因为Atom团队在所有情况下都不会遵循投票系统。有时我们必须选择我们认为是对的事，即使它不流行。（。。。）我能通过社区的反馈知道我能够提供什么以及做什么样的工作。
 
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom 决策流程](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom 决策流程
   </p>
 </aside>
 
diff --git a/_articles/zh-hant/building-community.md b/_articles/zh-hant/building-community.md
index b191800b253..90c5937a31a 100644
--- a/_articles/zh-hant/building-community.md
+++ b/_articles/zh-hant/building-community.md
@@ -229,7 +229,7 @@ README [不僅僅是指導手冊](../starting-a-project/#編寫自述文件)。
 Atom 專案的 Issues 沒有投票機制，因為 Atom 團隊並不會遵循投票的結果。有時我們必須選擇我們認為是對的事，即使它不是主流看法。（...）我能做的是傾聽社群的意見，這也是我能保證提供的服務。
 
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on [Atom 決策流程](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
+— @lee-dohm on Atom 決策流程
   </p>
 </aside>
 
diff --git a/docs/personas.md b/docs/personas.md
index 625269e06a9..aa38aee500a 100644
--- a/docs/personas.md
+++ b/docs/personas.md
@@ -84,7 +84,7 @@
 
 * Likely feels some sense of ownership over the project ("We are open sourcing this project to the community")
 
-* Company plays a clear role in decisionmaking
+* Company plays a clear role in decision making
 
 * May not have open sourced a project before
 

From eabf850ed1f397ec46aba66e78d82d61553c016d Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@gmail.com>
Date: Tue, 3 Jan 2023 16:40:08 -0500
Subject: [PATCH 425/749] remove marketplace from link

---
 _articles/best-practices.md    | 2 +-
 _articles/de/best-practices.md | 2 +-
 _articles/fa/best-practices.md | 2 +-
 _articles/hu/best-practices.md | 2 +-
 _articles/ms/best-practices.md | 2 +-
 _articles/nl/best-practices.md | 2 +-
 _articles/pl/best-practices.md | 2 +-
 _articles/ru/best-practices.md | 2 +-
 _articles/tr/best-practices.md | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/_articles/best-practices.md b/_articles/best-practices.md
index 1ff41a65ed4..01895803615 100644
--- a/_articles/best-practices.md
+++ b/_articles/best-practices.md
@@ -237,7 +237,7 @@ There are a [variety of tools available](https://github.com/showcases/tools-for-
 * [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
 * [Danger](https://github.com/danger/danger) helps automate code review
 * [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information
-* [dependabot](https://github.com/marketplace/dependabot) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
+* [dependabot](https://github.com/dependabot) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
 
 For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.
 
diff --git a/_articles/de/best-practices.md b/_articles/de/best-practices.md
index 4a6f2d0b868..e4402da32af 100644
--- a/_articles/de/best-practices.md
+++ b/_articles/de/best-practices.md
@@ -265,7 +265,7 @@ Viele Maintainer\*innen populärer Projekte sind mit ähnlichen Problemen konfro
 * [mention-bot](https://github.com/facebook/mention-bot) erwähnt potentielle Reviewer für Pull Requests
 * [Danger](https://github.com/danger/danger) hilft bei der Automatisierung des Code Review
 * [no-response](https://github.com/probot/no-response) schließt Issues deren Autor\*in nicht auf Nachfragen antwortet
-* [dependabot](https://github.com/marketplace/dependabot) prüft bekannte Abhängigkeitsdateien täglich und eröffnet Pull Requests, sobald Aktualisierungen verfügbar werden
+* [dependabot](https://github.com/dependabot) prüft bekannte Abhängigkeitsdateien täglich und eröffnet Pull Requests, sobald Aktualisierungen verfügbar werden
 
 Für Fehlerberichte und andere allgemeine Beiträge hat GitHub [Issue- und Pull-Request-Templates](https://github.com/blog/2111-issue-and-pull-request-templates), die Sie erstellen können, um die Kommunikation zu optimieren. @TalAter hat einen [Choose Your Own Adventure Guide](https://www.talater.com/open-source-templates/#/) erstellt, der Ihnen beim Schreiben dieser Vorlagen hilft.
 
diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md
index e6a46142e6e..8a22e65aa06 100644
--- a/_articles/fa/best-practices.md
+++ b/_articles/fa/best-practices.md
@@ -237,7 +237,7 @@ related:
 * ابزار [mention-bot](https://github.com/facebook/mention-bot)، به بازبین‌های بالقوه برای «درخواست pull»ها خبر می دهد.
 * ابزار [Danger](https://github.com/danger/danger)، به بررسی و بازبینی اتوماتیک کد کمک می‌کند.
 * ابزار [no-response](https://github.com/probot/no-response)، مسائلی را که نویسنده به درخواست‌ها برای اطلاعات بیشتر پاسخ نداده است، می‌بندد.
-* ابزار [dependabot](https://github.com/marketplace/dependabot)، هر روز «فایل‌های وابسته» (مثل کتابخانه‌ها یا کلاس‌های جانبی یا ماژول‌ها) شما را از نظر الزامات منسوخ شده بررسی می‌کند و «درخواست‌های pull» را برای هر موردی که پیدا می‌کند، باز می‌کند.
+* ابزار [dependabot](https://github.com/dependabot)، هر روز «فایل‌های وابسته» (مثل کتابخانه‌ها یا کلاس‌های جانبی یا ماژول‌ها) شما را از نظر الزامات منسوخ شده بررسی می‌کند و «درخواست‌های pull» را برای هر موردی که پیدا می‌کند، باز می‌کند.
 
 برای گزارش اشکالات (bug) و سایر مشارکت‌های متداول، GitHub دارای [قالب‌های طرح مشکل و قالب‌های درخواست‌های pull](https://github.com/blog/2111-issue-and-pull-request-templates) است، که می‌توانید برای کارآمد ساختن ارتباطاتی که دریافت می‌کنید، استفاده کنید. «TalAter»، برای کمک کردن به شما برای طرح مشکلات و مسائل روابط عمومی (PR templates)، ابزار [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) را ساخت.
 
diff --git a/_articles/hu/best-practices.md b/_articles/hu/best-practices.md
index 931b5a8341d..c4c9ecd2d31 100644
--- a/_articles/hu/best-practices.md
+++ b/_articles/hu/best-practices.md
@@ -237,7 +237,7 @@ A jó hír egy népszerű projekt fenntartásához az, hogy más karbantartók v
 * [mention-bot](https://github.com/facebook/mention-bot) a beolvasztási kérelemben megemlíti automatikusan a lehetséges embereket, akik a kódot majd átnézik (kód review)
 * [Danger](https://github.com/danger/danger) segít automatizálni a kód review-t
 * [no-response](https://github.com/probot/no-response) lezárja azokat az issue-kat, amelyekben az issue szerzője nem válaszolt a további információkérésre
-* [dependabot](https://github.com/marketplace/dependabot) minden nap ellenőrzi a függőségeket, ha talál frissebb verziót, akkor automatikusan beolvasztási kérelmet készít az új verzió számmal
+* [dependabot](https://github.com/dependabot) minden nap ellenőrzi a függőségeket, ha talál frissebb verziót, akkor automatikusan beolvasztási kérelmet készít az új verzió számmal
 
 A hiba jelzésekhez és más általános hozzájárulásokhoz a GitHub biztosít egy [hiba jelzés és beolvasztási kérelem formanyomtatványt](https://github.com/blog/2111-issue-and-pull-request-templates), amellyel egyszerűsíteni és egységesíteni tudod ezek beadását. @TalAter készített egy [Választásos Kalandjátékot](https://www.talater.com/open-source-templates/#/) hogy segítse ezen formanyomtatványok elkészítését.
 
diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md
index e27b8a34757..fc11cd94e4d 100644
--- a/_articles/ms/best-practices.md
+++ b/_articles/ms/best-practices.md
@@ -237,7 +237,7 @@ Terdapat [pelbagai alat tersedia](https://github.com/showcases/tools-for-open-so
 * [mention-bot](https://github.com/facebook/mention-bot) menyebut pengulas berpotensi untuk permintaan tarik
 * [Danger](https://github.com/danger/danger) membantu mengautomasikan semakan kod
 * [no-response](https://github.com/probot/no-response) menutup masalah di mana pengarang tidak menjawab permintaan untuk mendapatkan maklumat lebih lanjut
-* [dependabot](https://github.com/marketplace/dependabot) memeriksa fail kebergantungan anda setiap hari untuk keperluan yang ketinggalan zaman dan membuka permintaan tarikan individu untuk apa sahaja yang dijumpainya
+* [dependabot](https://github.com/dependabot) memeriksa fail kebergantungan anda setiap hari untuk keperluan yang ketinggalan zaman dan membuka permintaan tarikan individu untuk apa sahaja yang dijumpainya
 
 Fatau laporan pepijat dan sumbangan umum lain, GitHub mempunyai [Templat Masalah dan Templat Tarik Permintaan] (<https://github.com/blog/2111-issue-and-pull-request-templates>), yang boleh anda buat untuk melancarkan komunikasi anda terima. @TalAter membuat [Pilih panduan Pengembaraan Anda Sendiri] (<https://www.talater.com/open-source-templates/#/>) untuk membantu anda menulis isu dan templat PR anda.
 
diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index 22901951592..0fedcb43424 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -255,7 +255,7 @@ Een paar voorbeelden:
 * [mention-bot](https://github.com/facebook/mention-bot) vermeldt potentiële reviewers voor pull-aanvragen
 * [Danger](https://github.com/danger/danger) helpt bij het automatiseren van codebeoordeling
 * [no-response](https://github.com/probot/no-response) sluit issues af waarbij de auteur niet heeft gereageerd op een verzoek om meer informatie
-* [dependabot](https://github.com/marketplace/dependabot) controleert uw afhankelijkheidsbestanden elke dag op verouderde vereisten en opent individuele pull-verzoeken voor alle gevonden items
+* [dependabot](https://github.com/dependabot) controleert uw afhankelijkheidsbestanden elke dag op verouderde vereisten en opent individuele pull-verzoeken voor alle gevonden items
 
 Voor bugrapporten en andere veelvoorkomende bijdragen heeft GitHub [Issue-sjablonen en Pull Request-sjablonen](https://github.com/blog/2111-issue-and-pull-request-templates), die u kunt maken om de communicatie die u ontvangt te stroomlijnen. @TalAter heeft een [Kies je eigen avonturengids](https://www.talater.com/open-source-templates/#/) gemaakt om u te helpen bij het schrijven van uw issue en PR-sjablonen.
 
diff --git a/_articles/pl/best-practices.md b/_articles/pl/best-practices.md
index 7078923fa58..e15b7cd62c4 100644
--- a/_articles/pl/best-practices.md
+++ b/_articles/pl/best-practices.md
@@ -242,7 +242,7 @@ Dostępnych jest [wiele dostępnych narzędzi](https://github.com/showcases/tool
 * [mention-bot](https://github.com/facebook/mention-bot) wymienia potencjalnych recenzentów dla pull requestów
 * [Danger](https://github.com/danger/danger) pomaga zautomatyzować code review
 * [no-response](https://github.com/probot/no-response) zamyka issues gdzie autor nie odpowiedział na request lub więcej informacji
-* [dependabot](https://github.com/marketplace/dependabot) sprawdza pliki zależności każdego dnia pod kątem nieaktualnych wymagań i otwiera indywidualne pull requesty dla każdego, kogo znajdzie
+* [dependabot](https://github.com/dependabot) sprawdza pliki zależności każdego dnia pod kątem nieaktualnych wymagań i otwiera indywidualne pull requesty dla każdego, kogo znajdzie
 
 W przypadku raportów o błędach i innych typowych treści GitHub ma [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), które możesz utworzyć, aby usprawnić otrzymywaną komunikację. @TalAter stworzył [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) aby pomóc Ci napisać swój issue i szablony PR.
 
diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md
index e9fffc71d8f..111bf483312 100644
--- a/_articles/ru/best-practices.md
+++ b/_articles/ru/best-practices.md
@@ -237,7 +237,7 @@ related:
 * [mention-bot](https://github.com/facebook/mention-bot) упоминает потенциальных ревьюеров для пул-реквеста
 * [Danger](https://github.com/danger/danger) помогает автоматизировать проверку кода
 * [no-response](https://github.com/probot/no-response) закрывает ишью, если автор не предоставил дополнительную информацию
-* [dependabot](https://github.com/marketplace/dependabot) ежедневно следует за актуальностью зависимостей, и если находит что-то новое, то открывает отдельные пул-реквесты
+* [dependabot](https://github.com/dependabot) ежедневно следует за актуальностью зависимостей, и если находит что-то новое, то открывает отдельные пул-реквесты
 
 Для сообщений об ошибках и других общих проблем на GitHub есть [шаблоны для ишью и пул-реквеста](https://github.com/blog/2111-issue-and-pull-request-templates), которые можно создать для упрощения взаимодействия с сообществом. @TalAter создал [руководство Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/), чтобы помочь вам написать собственные шаблоны ишью и пул-реквеста.
 
diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md
index 95cd3a8ed5b..5f698d8036a 100644
--- a/_articles/tr/best-practices.md
+++ b/_articles/tr/best-practices.md
@@ -237,7 +237,7 @@ Bakım çalışmalarının bazı yönlerini otomatikleştirmeye yardımcı olaca
 * [mention-bot](https://github.com/facebook/mention-bot) PR talepleri için potansiyel denetçilerden bahseder
 * [Danger](https://github.com/danger/danger) kod incelemesini otomatikleştirmeye yardımcı olur
 * [no-response](https://github.com/probot/no-response) geliştiricilerin uzun süre yanıt vermediği sorunları kapatır
-* [dependabot](https://github.com/marketplace/dependabot) bağımlılık dosyalarınızı her gün eski gereksinimler için kontrol eder ve bulduğu her biri için PR istekleri açar
+* [dependabot](https://github.com/dependabot) bağımlılık dosyalarınızı her gün eski gereksinimler için kontrol eder ve bulduğu her biri için PR istekleri açar
 
 Hata raporları ve diğer genel katkılar için GitHub, aldığınız iletişimi kolaylaştırmak için oluşturabileceğiniz [Sorun Şablonlarına ve PR İsteği Şablonlarına](https://github.com/blog/2111-issue-and-pull-request-templates) sahiptir. @TalAter sorununuzu ve PR şablonlarınızı yazmanıza yardımcı olmak için [Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/) rehberini geliştirdi.
 

From 9bdab9550483439a4802146477841239063bf96a Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@gmail.com>
Date: Tue, 3 Jan 2023 16:41:48 -0500
Subject: [PATCH 426/749] remove one more block quote

---
 _articles/zh-hant/how-to-contribute.md | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md
index 26629548e1e..eb09d712faf 100644
--- a/_articles/zh-hant/how-to-contribute.md
+++ b/_articles/zh-hant/how-to-contribute.md
@@ -69,14 +69,6 @@ redirect_from: /zh-tw/how-to-contribute/
 
 即便你樂於寫程式，撰寫程式以外的貢獻對於專案來說也是舉足輕重的，維繫這樣的關係也能讓你獲得與專案的其他成員共事的機會。
 
-<aside markdown="1" class="pquote">
-  <img src="https://avatars3.githubusercontent.com/u/54418?v=3&s=460" class="pquote-avatar" alt="avatar">
-  我第一次接觸 Python 開發團隊（簡稱 python-dev）是在 2002年6月17日，當時我向郵件列表寄了一份請求接受補丁的信，接著我決定為工作小組蒐集整理郵件摘要，後來他們甚至給了我一個機會去諮詢某個主題，這當中的關鍵是，我能注意到有人指出哪些東西必須要處裡。
-  <p markdown="1" class="pquote-credit">
-— @brettcannon, ["系統維護者的故事"](https://github.com/open-source/stories/brettcannon)
-  </p>
-</aside>
-
 ### **你是否熱衷於規劃活動？**
 
 * 為專案舉辦一個工作坊或線下聚會，[例如 @fzamperin 為 NodeSchool 所做的](https://github.com/nodeschool/organizers/issues/406)

From 8dd02d0aeeb7495f26ae6813e1b46e79f23c9ff8 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@gmail.com>
Date: Tue, 3 Jan 2023 16:45:09 -0500
Subject: [PATCH 427/749] add blank lines around blocks

---
 _articles/nl/finding-users.md | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/_articles/nl/finding-users.md b/_articles/nl/finding-users.md
index 311af8c0c56..a4ee2407114 100644
--- a/_articles/nl/finding-users.md
+++ b/_articles/nl/finding-users.md
@@ -34,6 +34,7 @@ Voor een diepere duik in berichten, bekijk Mozilla's ["Persona's en paden"](http
   U hebt idealiter een enkele "home"-URL nodig die u kunt promoten en waarnaar u mensen kunt verwijzen met betrekking tot uw project. U hoeft niet te spetteren op een mooie sjabloon of zelfs een domeinnaam, maar uw project heeft een centraal punt nodig.
 
   _You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point._
+
   <p markdown="1" class="pquote-credit">
 — Peter Cooper & Robert Nyman, ["Hoe u het woord over uw code kunt verspreiden"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
   </p>
@@ -50,6 +51,7 @@ Als u nog geen verkooppunten voor uw project wilt opzetten, promoot dan uw eigen
   Een fout die ik in die vroege dagen maakte (...) was dat ik geen Twitter-account voor het project startte. Twitter is een geweldige manier om mensen op de hoogte te houden van een project en om mensen constant aan het project bloot te stellen.
 
   _A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project._
+
   <p markdown="1" class="pquote-credit">
 — @nathanmarz, ["Geschiedenis van Apache Storm en geleerde lessen"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
   </p>
@@ -76,6 +78,7 @@ Profiteer van bestaande online communities en platforms om uw publiek te bereike
   Elk programma heeft zeer specifieke functies die slechts een fractie van de gebruikers nuttig zullen vinden. Spam niet zoveel mogelijk mensen. Richt uw inspanningen in plaats daarvan op gemeenschappen die baat hebben bij kennis van uw project.
 
   _Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project._
+
   <p markdown="1" class="pquote-credit">
 — @pazdera, ["Marketing voor open source-projecten"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
   </p>
@@ -104,6 +107,7 @@ Als je [nieuw bent bij spreken in het openbaar](https://speaking.io/), begin dan
   Ik was behoorlijk zenuwachtig om naar PyCon te gaan. Ik hield een lezing, ik zou daar maar een paar mensen leren kennen, ik ging een hele week. (...) Ik had me echter geen zorgen moeten maken. PyCon was fenomenaal geweldig! (...) Iedereen was ongelooflijk vriendelijk en extravert, zo erg dat ik zelden tijd vond om niet met mensen te praten!
 
   _I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!_
+
   <p markdown="1" class="pquote-credit">
 — @jhamrick, ["Hoe ik heb geleerd om te stoppen met piekeren en van PyCon te houden"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
   </p>
@@ -118,6 +122,7 @@ Concentreer u tijdens het schrijven van uw lezing op wat uw publiek interessant
   Wanneer u begint met het schrijven van uw lezing, ongeacht wat uw onderwerp is, kan het helpen als u uw lezing ziet als een verhaal dat u aan mensen vertelt.
 
   _When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people._
+
   <p markdown="1" class="pquote-credit">
 — Lena Reinhard, ["Hoe u een Tech Conferentie Lezing voorbereidt en schrijft"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
   </p>
@@ -132,6 +137,7 @@ Zoek naar conferenties die specifiek zijn voor uw taal of ecosysteem. Voordat u
   Ik schreef heel vriendelijk naar de JSConf-mensen en smeekte hen om me een slot te geven waar ik het op JSConf EU kon presenteren. (...) Ik was enorm bang toen ik dit ding presenteerde waar ik al een half jaar aan werkte. (...) De hele tijd dacht ik alleen maar: oh mijn God. Wat doe ik hier?
 
   _I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?_
+
   <p markdown="1" class="pquote-credit">
 — @ry, ["Historie van Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
   </p>
@@ -148,6 +154,7 @@ Door nieuwkomers te helpen, middelen te delen en doordachte bijdragen te leveren
   De enige reden waarom urllib3 tegenwoordig de populairste Python-bibliotheek van derden is, is omdat het deel uitmaakt van verzoeken.
 
   _The only reason urllib3 is the most popular third-party Python library today is because it's part of requests._
+
   <p markdown="1" class="pquote-credit">
 — @shazow, ["Hoe u uw open source-project kunt laten floreren"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
   </p>

From 4b5702fe4753de9715666adb82d00d9a084c8187 Mon Sep 17 00:00:00 2001
From: XYZ <xyzscer@outlook.com>
Date: Mon, 9 Jan 2023 09:31:45 +0800
Subject: [PATCH 428/749] fix a typo

github -> GitHub
---
 _articles/zh-hans/metrics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/metrics.md b/_articles/zh-hans/metrics.md
index 5f5b00baf5c..f3189fc0790 100644
--- a/_articles/zh-hans/metrics.md
+++ b/_articles/zh-hans/metrics.md
@@ -85,7 +85,7 @@ redirect_from: /zh-cn/metrics/
 
 可能会经常用的衡量社区的指标包括：
 
-* **贡献者的总数和每个贡献者的提交次数：** 有多少贡献者，哪些是活跃的，哪些是不活跃。github上，你可以在"Graphs" -> "Contributors"面板查看这些信息。目前，这个图标只计算了那些往仓库默认分支推送的贡献者。
+* **贡献者的总数和每个贡献者的提交次数：** 有多少贡献者，哪些是活跃的，哪些是不活跃。GitHub上，你可以在"Graphs" -> "Contributors"面板查看这些信息。目前，这个图标只计算了那些往仓库默认分支推送的贡献者。
 
 ![contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
 

From f89d017337acb3935688bb5735e0724d41ebaf54 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20S=C3=BCnder?= <asuender@student.tgm.ac.at>
Date: Wed, 8 Feb 2023 20:43:29 +0100
Subject: [PATCH 429/749] Remove 'Beitragsarten' and fix some minor typos

---
 _articles/de/how-to-contribute.md | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/_articles/de/how-to-contribute.md b/_articles/de/how-to-contribute.md
index 4d8f47dc28c..af73a79748e 100644
--- a/_articles/de/how-to-contribute.md
+++ b/_articles/de/how-to-contribute.md
@@ -28,7 +28,7 @@ Zu Open Source beizutragen, kann ein lohnender Weg sein, um nahezu alle erdenkli
 
 Warum tragen Menschen zu Open Source bei? Es gibt viele Gründe!
 
-### Software verbessern, auf die Sie sich verlassen.
+### Software verbessern, auf die Sie sich verlassen
 
 Viele Open-Source-Beitragende waren vorher Nutzer\*innen der Software, zu der sie beitragen. Wenn Sie einen Fehler in einer von Ihnen verwendeten Open-Source-Software finden, sollten Sie sich im Quellcode umsehen, ob Sie den Fehler evtl. selbst patchen können. Wenn ja, ist einen Patch einzureichen der beste Weg sicherzustellen, dass Ihre Kolleg\*innen (und Sie selbst, wenn Sie auf die nächste Version aktualisieren) davon profitieren können.
 
@@ -52,7 +52,7 @@ Per Definition ist Ihre gesamte Open-Source-Arbeit öffentlich. Sie erstellen au
 
 Softwareentwicklung ist eine soziale Tätigkeit, und Open-Source-Projekte bieten Führungserfahrungen, denn es müssen z.B. Konflikte gelöst, Teams organisiert und Aufgaben priorisiert werden.
 
-### Es ist ermutigend, auch kleine Änderungen vornehmen zu können.
+### Es ist ermutigend, auch kleine Änderungen vornehmen zu können
 
 Sie müssen nicht lebenslang an Open Source mithelfen. Haben Sie schon einmal einen Tippfehler auf einer Website gesehen und sich gewünscht, dass ihn jemand beheben würde? Bei einem Open-Source-Projekt können Sie genau das tun. Open Source hilft Leuten, selbst in die Hand zu nehmen, wie sie die Welt erleben, und das ist an sich schon befriedigend.
 
@@ -78,7 +78,7 @@ Ein weit verbreiteter Irrtum! Aber in Wirklichkeit sind es oft andere Projektasp
   </p>
 </aside>
 
-Auch wenn Sie gerne Code schreiben, sind andere Beitragsarten eine gute Möglichkeit, sich an einem Projekt zu beteiligen und andere Leute aus der Community zu treffen. Solche Beziehungen aufzubauen, ebnet Ihnen den Weg zur Mitarbeit an anderen Projektaspekten.
+Auch wenn Sie gerne Code schreiben, gibt es vielleicht bessere Möglichkeiten, sich an einem Projekt zu beteiligen und andere Leute aus der Community zu treffen. Solche Beziehungen aufzubauen, ebnet Ihnen den Weg zur Mitarbeit an anderen Projektaspekten.
 
 ### Planen Sie gerne Veranstaltungen?
 
@@ -485,7 +485,7 @@ Unabhängig davon, ob Sie ein\*e einmalige\*r Beitragende\*r sind oder versuchen
   </p>
 </aside>
 
-Bevor Sie ein Issue oder Pull Request aufmachen oder eine Frage im Chat stellen, sollten Sie diese Punkte im Hinterkopf behalten, damit Ihre Ideen effektiv rüberkommen.
+Bevor Sie ein Issue oder einen Pull Request aufmachen oder eine Frage im Chat stellen, sollten Sie diese Punkte im Hinterkopf behalten, damit Ihre Ideen effektiv rüberkommen.
 
 **Erklären Sie den Kontext.** Bringen Sie andere schnell auf den neuesten Stand. Wenn Sie auf einen Fehler stoßen, erklären Sie, was Sie zu tun versuchen und wie Sie ihn reproduzieren können. Wenn Sie eine neue Idee vorschlagen, erklären Sie deren Nutzen für das Projekt (nicht nur für Sie!).
 
@@ -529,13 +529,13 @@ Bevor Sie ein Issue oder Pull Request aufmachen oder eine Frage im Chat stellen,
 
 Bevor Sie etwas tun, sollten Sie kurz sicherstellen, dass Ihre Idee nicht schon an anderer Stelle besprochen wurde. Überfliegen Sie die README des Projekts, Issues (offen und geschlossen), die Mailingliste und Stack Overflow. Sie müssen nicht stundenlang alles durchgehen, aber eine schnelle Suche nach ein paar Schlüsselbegriffen bringt Sie weiter.
 
-Wenn Sie Ihre Idee woanders nicht finden können, sind Sie bereit für den ersten Schritt. Wenn sich das Projekt auf GitHub befindet, werden Sie Ihre Idee vermutlich als Issue kommunizieren, oder ein Pull Request stellen:
+Wenn Sie Ihre Idee woanders nicht finden können, sind Sie bereit für den ersten Schritt. Wenn sich das Projekt auf GitHub befindet, werden Sie Ihre Idee vermutlich als Issue kommunizieren oder einen Pull Request erstellen:
 
 * **Issues** sind wie ein Gespräch oder eine Diskussion.
 * **Pull Requests** sind der Beginn der Arbeit an einer Lösung.
 * **Eine unkomplizierte Kommunikation,** wie z.B. die Klärung einer Vorgehensweise oder Frage, versuchen Sie es in Stack Overflow, IRC, Slack oder anderen Chat-Kanälen, falls das Projekt über solche verfügt.
 
-Bevor Sie ein Issue oder 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.
+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.
 
@@ -565,16 +565,16 @@ Tipps für die Kommunikation zu Issues:
 * **Wenn ein Issue vor einer Weile geöffnet wurde,** ist es möglich, dass es woanders bearbeitet wird, oder bereits gelöst wurde. Daher bitten Sie um Bestätigung, bevor Sie mit der Arbeit beginnen.
 * **Wenn Sie ein Issue geöffnet haben, aber die Antwort später selbst herausgefunden haben,** kommentieren Sie das Issue, um anderen Leuten die Antwort mitzuteilen. Schließen Sie danach das Issue. Auch die Dokumentation dieses Ergebnisses ist ein Beitrag zum Projekt.
 
-### ein Pull Request erstellen
+### Einen Pull Request erstellen
 
-In den folgenden Situationen sollten Sie in der Regel ein Pull Request öffnen:
+In den folgenden Situationen sollten Sie in der Regel einen Pull Request öffnen:
 
 * Triviale Korrekturen einreichen (z.B. eines Tippfehlers, eines defekten Links oder eines offensichtlichen Fehlers)
 * Beginn der Arbeit an einem Beitrag, um den Sie bereits gebeten wurden oder den Sie bereits in einem Issue diskutiert haben.
 
-Ein Pull Request muss keine fertige Arbeit darstellen. Es ist in der Regel besser, es frühzeitig zu starten, damit andere zuschauen oder Feedback zu Ihrem Fortschritt geben können. Markieren Sie es einfach als "WIP" (Work in Progress) in der Betreffzeile. Sie können später jederzeit weitere Commits hinzufügen.
+Einen Pull Request muss keine fertige Arbeit darstellen. Es ist in der Regel besser, es frühzeitig zu starten, damit andere zuschauen oder Feedback zu Ihrem Fortschritt geben können. Markieren Sie es einfach als "WIP" (Work in Progress) in der Betreffzeile. Sie können später jederzeit weitere Commits hinzufügen.
 
-Wenn das Projekt auf GitHub läuft, können Sie hier ein Pull Request stellen:
+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/).)
 * **[Erstellen Sie einen Branch](https://guides.github.com/introduction/flow/)** für Ihre Änderungen.
@@ -583,7 +583,7 @@ Wenn das Projekt auf GitHub läuft, können Sie hier ein Pull Request stellen:
 * **Testen Sie Ihre Änderungen!** Führen Sie vorhandene Tests aus und erstellen bei Bedarf neue. Egal ob es Tests gibt oder nicht, stellen Sie sicher, dass Ihre Änderungen das bestehende Projekt nicht brechen.
 * **Tragen Sie im Stil des Projekts bei,** nach bestem Wissen und Gewissen. Dies kann bedeuten, dass Sie Einrückungen, Semikolons oder Kommentare anders verwenden als in Ihrem eigenen Repository, aber es erleichtert dem oder der Betreuer\*in das Zusammenführen, und anderen das Verständnis und die Pflege in der Zukunft.
 
-Wenn dies Ihr erstes Pull Request ist, sehen Sie sich [Make a Pull Request](http://makeapullrequest.com/) an, die @kentcdodds als Video-Tutorial erstellt hat. Sie können auch üben, ein Pull Request in @Roshanjossey\s "[First Contributions](https://github.com/Roshanjossey/first-contributions)"-Repository zu erstellen.
+Wenn dies Ihr erster Pull Request ist, sehen Sie sich [Make a Pull Request](http://makeapullrequest.com/) an, die @kentcdodds als Video-Tutorial erstellt hat. Sie können auch üben, ein Pull Request in @Roshanjossey\s "[First Contributions](https://github.com/Roshanjossey/first-contributions)"-Repository zu erstellen.
 
 ## Was passiert, nachdem Sie einen Beitrag eingereicht haben?
 
@@ -605,7 +605,7 @@ Wenn Sie höflich nachhaken und trotzdem niemand antwortet, könnte dies für im
 
 Es ist üblich, dass Sie aufgefordert werden, Änderungen an Ihrem Beitrag vorzunehmen, z.B. bezüglich des Umfangs Ihrer Idee oder bezüglich Ihres Code.
 
-Wenn jemand Änderungen vorschlägt, reagieren Sie darauf. Der- oder diejenige hat sich die Zeit genommen, Ihren Beitrag zu überprüfen. Ein Pull Request zu eröffnen aber nicht weiterzuverfolgen, ist schlechter Stil. Wenn Sie nicht wissen, wie Sie Änderungen vornehmen sollen, recherchieren Sie dies und bitten um Hilfe, wenn Sie sie brauchen.
+Wenn jemand Änderungen vorschlägt, reagieren Sie darauf. Der- oder diejenige hat sich die Zeit genommen, Ihren Beitrag zu überprüfen. Einen Pull Request zu eröffnen, aber nicht weiterzuverfolgen, ist schlechter Stil. Wenn Sie nicht wissen, wie Sie Änderungen vornehmen sollen, recherchieren Sie dies und bitten um Hilfe, wenn Sie sie brauchen.
 
 Wenn Sie keine Zeit mehr haben, an dem Problem zu arbeiten (zum Beispiel, wenn das Thema seit Monaten vor sich hin brodelt aber sich Ihre Umstände geändert haben), lassen Sie es den Maintainer\*in wissen, damit sie oder er keine Antwort erwartet. Vielleicht übernimmt jemand anderes Ihren Pull Request.
 

From e0c0b12b5f7512dd55d45214c89429121ed074f3 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Mon, 13 Feb 2023 16:13:45 +0100
Subject: [PATCH 430/749] Update tests.yml

---
 .github/workflows/tests.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 850928f147e..d1e7bd1955e 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -3,6 +3,7 @@ on:
   push:
     branches: master
   pull_request: []
+  merge_group:
 jobs:
   tests:
     runs-on: ubuntu-latest

From feeb8f63a49fe69ef0f4894ca71351f894c440bc Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@gmail.com>
Date: Mon, 13 Feb 2023 10:16:47 -0500
Subject: [PATCH 431/749] Fix link

---
 _articles/de/legal.md      | 2 +-
 _articles/el/legal.md      | 2 +-
 _articles/es/legal.md      | 2 +-
 _articles/fa/legal.md      | 2 +-
 _articles/fr/legal.md      | 2 +-
 _articles/hu/legal.md      | 2 +-
 _articles/id/legal.md      | 2 +-
 _articles/ja/legal.md      | 2 +-
 _articles/ko/legal.md      | 2 +-
 _articles/legal.md         | 2 +-
 _articles/ms/legal.md      | 2 +-
 _articles/nl/legal.md      | 2 +-
 _articles/pl/legal.md      | 2 +-
 _articles/pt/legal.md      | 2 +-
 _articles/ro/legal.md      | 2 +-
 _articles/ru/legal.md      | 2 +-
 _articles/ta/legal.md      | 2 +-
 _articles/tr/legal.md      | 2 +-
 _articles/zh-hans/legal.md | 2 +-
 _articles/zh-hant/legal.md | 2 +-
 20 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/_articles/de/legal.md b/_articles/de/legal.md
index 2c3c850c8d7..92fcdea794f 100644
--- a/_articles/de/legal.md
+++ b/_articles/de/legal.md
@@ -157,7 +157,7 @@ Längerfristig kann Ihre Rechtsabteilung mehr tun, um dem Unternehmen zu helfen,
 </aside>
 
 * **Was veröffentlichen?** [(Fast) alles?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html). Wenn Ihre Rechtsabteilung die Open-Source-Strategie Ihres Unternehmens versteht und in sie investiert, kann sie Ihnen am besten helfen, anstatt Ihre Bemühungen zu behindern.
-* **Compliance:** Auch wenn Ihr Unternehmen keine Open-Source-Projekte veröffentlicht, verwendet es die Open-Source-Software von anderen. [Bewusstsein darüber und Prozesse dafür](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) helfen, Kopfschmerzen, Produktverzögerungen und Klagen zu vermeiden.
+* **Compliance:** Auch wenn Ihr Unternehmen keine Open-Source-Projekte veröffentlicht, verwendet es die Open-Source-Software von anderen. [Bewusstsein darüber und Prozesse dafür](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) helfen, Kopfschmerzen, Produktverzögerungen und Klagen zu vermeiden.
 
 <aside markdown="1" class="pquote">
 
diff --git a/_articles/el/legal.md b/_articles/el/legal.md
index c7681ed7658..343f6320b98 100644
--- a/_articles/el/legal.md
+++ b/_articles/el/legal.md
@@ -145,7 +145,7 @@ related:
 </aside>
 
 * **Τι να δημοσιεύσετε:** [(Σχεδόν) τα πάντα;](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Εάν η νομική σας ομάδα κατανοεί και έχει επενδύσει στη στρατηγική ανοικτού κώδικα της εταιρείας σας, θα είναι σε θέση να βοηθήσει καλύτερα παρά να εμποδίσει τις προσπάθειές σας.
-* **Συμμόρφωση:** Ακόμα και αν η εταιρεία σας δεν εκδίδει πρότζεκτ ανοικτού κώδικα, χρησιμοποιεί λογισμικό ανοικτού κώδικα άλλων. Η [Ενημέρωση και διαδικασία](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) μπορεί να αποτρέψει πονοκεφάλους, καθυστερήσεις προϊόντων και αγωγές.
+* **Συμμόρφωση:** Ακόμα και αν η εταιρεία σας δεν εκδίδει πρότζεκτ ανοικτού κώδικα, χρησιμοποιεί λογισμικό ανοικτού κώδικα άλλων. Η [Ενημέρωση και διαδικασία](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) μπορεί να αποτρέψει πονοκεφάλους, καθυστερήσεις προϊόντων και αγωγές.
 
 <aside markdown="1" class="pquote">
   Οι οργανισμοί πρέπει να διαθέτουν μια στρατηγική αδειοδότησης και συμμόρφωσης που να ταιριάζει και στις δύο κατηγορίες \["επιτρεπτή" και "copyleft"\]. Αυτό ξεκινά με την τήρηση αρχείου των όρων αδειοδότησης που ισχύουν για το λογισμικό ανοικτού κώδικα που χρησιμοποιείτε - συμπεριλαμβανομένων των υποσυνιστωσών και των εξαρτήσεων.
diff --git a/_articles/es/legal.md b/_articles/es/legal.md
index 8543e20fd36..b7dfbe84e46 100644
--- a/_articles/es/legal.md
+++ b/_articles/es/legal.md
@@ -151,7 +151,7 @@ A largo plazo, tu equipo legal puede hacer m&aacute;s para ayudar a la empresa a
 
 * **Qu&eacute; liberar:** [¿(casi) todo?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Si tu equipo legal entiende e invierte en la estrategia de c&oacute;digo abierto de su empresa, ser&aacute;n m&aacute;s capaces de ayudar en lugar de dificultar tus esfuerzos.
 
-* **Conformidad:** Incluso si tu empresa no libera ning&uacute;n proyecto de c&oacute;digo abierto, utiliza otro software de c&oacute;digo abierto. La [conciencia y el proceso](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) puede prevenir dolores de cabeza, retrasos del producto, y demandas.
+* **Conformidad:** Incluso si tu empresa no libera ning&uacute;n proyecto de c&oacute;digo abierto, utiliza otro software de c&oacute;digo abierto. La [conciencia y el proceso](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) puede prevenir dolores de cabeza, retrasos del producto, y demandas.
 
 <aside markdown="1" class="pquote">
   Las organizaciones deben tener una estrategia de licencia y cumplimiento que se ajuste tanto a categor&iacute;as \["permisiva" y "copyleft"\]. Esto comienza con el mantenimiento de un registro de los t&eacute;rminos de licencia que se aplican al software de c&oacute;digo abierto que est&aacute; utilizando - incluidos subcomponentes y dependencias.
diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index a160b790bde..a5b666c58d8 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -148,7 +148,7 @@ related:
 
 * **چه چیزهایی را منتشر کنیم:** [(تقریبا) همه چیز؟](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) اگر تیم حقوقی شما استراتژی متن باز شرکت شما را درک کرده و در آن سرمایه‌گذاری کرده باشد، به جای جلوگیری از تلاش‌هایتان، به بهترین وجه به شما کمک می‌کند.
 
-* **سازگاری:** حتی اگر شرکت شما هیچ پروژۀ متن بازی را منتشر نکند، از دیگر نرم‌افزارهای متن باز استفاده می‌کند. [داشتن آگاهی از روند کار](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) می‌تواند از بروز مشکلات بی‌جا، تأخیر در محصول و شکایات جلوگیری کند.
+* **سازگاری:** حتی اگر شرکت شما هیچ پروژۀ متن بازی را منتشر نکند، از دیگر نرم‌افزارهای متن باز استفاده می‌کند. [داشتن آگاهی از روند کار](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) می‌تواند از بروز مشکلات بی‌جا، تأخیر در محصول و شکایات جلوگیری کند.
 
 <aside markdown="1" class="pquote">
  شرکت‌ها باید دارای مجوزها و استراتژی‌های انطباقی باشند که متناسب با هر دو دستۀ [«اختیاری» و «کپی‌لفت»] باشد. این کار با ثبت سوابق مجوزهایی که برای نرم‌افزارهای متن باز مورد استفاده شما اعمال می‌شود - از جمله مؤلفه‌های فرعی و وابستگی‌ها - آغاز می‌شود.
diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index 29d2a217d11..b68a74078bf 100644
--- a/_articles/fr/legal.md
+++ b/_articles/fr/legal.md
@@ -144,7 +144,7 @@ Si vous publiez le premier projet open source de votre entreprise, ce qui préc
 </aside>
 
 * **Que publier :** [(Presque) tout ?](Http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Si votre équipe juridique comprend et est investis dans la stratégie open source de votre entreprise, ils seront les mieux placés pour vous aider plutôt que d'entraver vos efforts.
-* **Conformité :** Même si votre entreprise ne diffuse aucun projet open source, elle utilise le logiciel open source des autres. [Awareness and process](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) peut prévenir les maux de tête, les retards de produit et les poursuites judiciaires.
+* **Conformité :** Même si votre entreprise ne diffuse aucun projet open source, elle utilise le logiciel open source des autres. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) peut prévenir les maux de tête, les retards de produit et les poursuites judiciaires.
 
 <aside markdown="1" class="pquote">
   Les organisations doivent disposer d'une stratégie de licence et de conformité qui corresponde à la fois aux catégories \["permissive" et "copyleft"\]. Cela commence par garder une trace des conditions de licence qui s'appliquent aux logiciels open source que vous utilisez, y compris les sous-composants et les dépendances.
diff --git a/_articles/hu/legal.md b/_articles/hu/legal.md
index 3c4d20b2576..8edd7d79069 100644
--- a/_articles/hu/legal.md
+++ b/_articles/hu/legal.md
@@ -145,7 +145,7 @@ Hosszabb távon a jogi csapat többet tehet azért, hogy segítsen a vállalatna
 </aside>
 
 * **Mit kell kiadni:** [(Majdnem) mindent?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Ha a jogi csapat megérti és hajlandó munkát befektetni a vállalat nyílt forráskódú stratégiájába, akkor az inkább segíteni fog, mint akadályozni.
-* **Megfelelés:** Még ha a céged nem is fejleszt nyílt forráskódot, biztosan használja azt. A [tudatosság és folytonosság](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) megakadályozhatja a fejfájást, a késedelmeket és a pereket.
+* **Megfelelés:** Még ha a céged nem is fejleszt nyílt forráskódot, biztosan használja azt. A [tudatosság és folytonosság](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) megakadályozhatja a fejfájást, a késedelmeket és a pereket.
 
 <aside markdown="1" class="pquote">
   A szervezeteknek rendelkezniük kell olyan licenc- és megfelelőségi stratégiával, amely megfelel mind a „megengedő”, mind a „copyleft” kategóriáknak. Ez azzal kezdődik, hogy nyilvántartást vezetnek az általad használt nyílt forráskódú szoftverekre vonatkozó licencfeltételekről, beleértve az alkomponenseket és a függőségeket.
diff --git a/_articles/id/legal.md b/_articles/id/legal.md
index 8bf7069ada9..a65220e36f4 100644
--- a/_articles/id/legal.md
+++ b/_articles/id/legal.md
@@ -144,7 +144,7 @@ Dalam jangka panjang, tim hukum Anda bisa melakukan lebih banyak lagi dengan mem
 </aside>
 
 * **Apa yang dirilis:** [(Hampir) semuanya?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) jika tim hukum Anda memahami dan berinvestasi pada strategi open source perusahaan Anda, mereka akan banyak membantu dibandingkan merugikan Anda.
-* **Kesesuaian:** Meskipun perusahaan Anda tidak merilis proyek open source, perusahaan Anda menggunakan perangkat lunak open source milik orang lain. [Kewaspadaandan proses](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) bisa mencegah masalah, keterlambatan produk, dan tuntutan hukum.
+* **Kesesuaian:** Meskipun perusahaan Anda tidak merilis proyek open source, perusahaan Anda menggunakan perangkat lunak open source milik orang lain. [Kewaspadaandan proses](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) bisa mencegah masalah, keterlambatan produk, dan tuntutan hukum.
 
 <aside markdown="1" class="pquote">
   Organisasi harus memiliki lisensi dan strategi penyesuaian yang sesuai untuk kategori \["permissive" dan "copyleft"\]. Hal ini dimulai dengan menyimpan catatan dari istilah lisensi yang digunakan pada perangkat lunak open source yang Anda gunakan — termasuk sub komponen dan ketergantungannya.
diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md
index a21666763ac..9e150ad769a 100644
--- a/_articles/ja/legal.md
+++ b/_articles/ja/legal.md
@@ -145,7 +145,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
 </aside>
 
 * **何をリリースすべきですか？：** [(ほぼ)すべて？](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) もし法務部門が企業のオープンソース戦略を理解し、それに投資している場合は、あなたの努力を妨害するよりもむしろ助けとなってくれるでしょう。
-* **コンプライアンス：** たとえあなたの企業が 1 つもオープンソースプロジェクトをリリースしていないとしても、他の人のオープンソースソフトウェアを使っているはずです。 [Awareness and process](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+* **コンプライアンス：** たとえあなたの企業が 1 つもオープンソースプロジェクトをリリースしていないとしても、他の人のオープンソースソフトウェアを使っているはずです。 [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
 
 <aside markdown="1" class="pquote">
 組織は、\[「寛容」と「コピーレフト」\]の両方のカテゴリにフィットするライセンス戦略、コンプライアンス戦略を確立しなければなりません。まずは使っているオープンソースソフトウェアとそのサブコンポーネント、依存関係に適用されているライセンス条項の記録を保持する所から始めましょう。
diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index 115e7d6eab8..e23bab5555a 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -144,7 +144,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
 </aside>
 
 * **공개 할 내용:** [(거의) 다?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) 귀하의 법무팀이 귀하의 회사 오픈소스 전략을 이해하고 투자한다면, 귀하의 노력을 방해하는 것보다 최선을 다 할 수 있습니다.
-* **준수:** 회사가 오픈소스 프로젝트를 공개하지 않더라도, 다른 회사의 오픈 소스 소프트웨어를 사용합니다. [Awareness and process](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/)는 두통, 제품 지연 및 법적 소송을 예방할 수 있습니다.
+* **준수:** 회사가 오픈소스 프로젝트를 공개하지 않더라도, 다른 회사의 오픈 소스 소프트웨어를 사용합니다. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/)는 두통, 제품 지연 및 법적 소송을 예방할 수 있습니다.
 
 <aside markdown="1" class="pquote">
   Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
diff --git a/_articles/legal.md b/_articles/legal.md
index 7ae7033b668..312c51dfa1a 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -145,7 +145,7 @@ Longer term, your legal team can do more to help the company get more from its i
 </aside>
 
 * **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
-* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
 
 <aside markdown="1" class="pquote">
   Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
diff --git a/_articles/ms/legal.md b/_articles/ms/legal.md
index 46e666f9ec3..6bccef8e1d6 100644
--- a/_articles/ms/legal.md
+++ b/_articles/ms/legal.md
@@ -145,7 +145,7 @@ Jangka panjang, pasukan undang-undang anda boleh melakukan lebih banyak perkara
 </aside>
 
 * **Apa yang hendak dilepaskan:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Sekiranya pasukan undang-undang anda memahami dan dilaburkan dalam strategi sumber terbuka syarikat anda, mereka akan dapat membantu dan bukannya menghalang usaha anda.
-* **Pematuhan:** Walaupun syarikat anda tidak mengeluarkan projek sumber terbuka, ia menggunakan perisian sumber terbuka orang lain. [Awareness and process](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) dapat mencegah sakit kepala, kelewatan produk, dan tuntutan mahkamah.
+* **Pematuhan:** Walaupun syarikat anda tidak mengeluarkan projek sumber terbuka, ia menggunakan perisian sumber terbuka orang lain. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) dapat mencegah sakit kepala, kelewatan produk, dan tuntutan mahkamah.
 
 <aside markdown="1" class="pquote">
   Organisasi mesti mempunyai strategi lesen dan pematuhan yang sesuai dengan kedua kategori [["permisive" dan "copyleft" \]. Ini bermula dengan mencatat syarat-syarat pelesenan yang berlaku untuk perisian sumber terbuka yang Anda gunakan - termasuk subkomponen dan dependensi.
diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
index 55a535a933e..1b06118b779 100644
--- a/_articles/nl/legal.md
+++ b/_articles/nl/legal.md
@@ -153,7 +153,7 @@ Op de langere termijn kan uw juridische team meer doen om het bedrijf te helpen
 </aside>
 
 * **Wat vrij te geven:** [(Bijna) alles?] (Http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Als uw juridische team het begrijpt en geïnvesteerd in de open source-strategie van uw bedrijf, zullen ze u het beste kunnen helpen in plaats van hinderen.
-* **Naleving:** Zelfs als uw bedrijf geen open source-projecten vrijgeeft, gebruikt het open source-software van anderen. [Bewustwording en proces](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) kan hoofdpijn, productvertragingen, en rechtszaken voorkomen.
+* **Naleving:** Zelfs als uw bedrijf geen open source-projecten vrijgeeft, gebruikt het open source-software van anderen. [Bewustwording en proces](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) kan hoofdpijn, productvertragingen, en rechtszaken voorkomen.
 
 <aside markdown="1" class="pquote">
   Organisaties moeten een licentie- en nalevingsstrategie hebben die past in de categorieën \["tolerant" en "copyleft"\]. Dit begint met het bijhouden van de licentievoorwaarden die van toepassing zijn op de open source-software die u gebruikt, inclusief subcomponenten en afhankelijkheden.
diff --git a/_articles/pl/legal.md b/_articles/pl/legal.md
index 5cf9cbe07d2..8de980aee30 100644
--- a/_articles/pl/legal.md
+++ b/_articles/pl/legal.md
@@ -151,7 +151,7 @@ W dłuższej perspektywie Twój zespół prawny może zrobić więcej, aby pomó
 </aside>
 
 * **Co wydać:** [(Prawie) wszystko?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Jeśli Twój zespół prawny rozumie i jest zaangażowany w strategię otwartego oprogramowania firmy, najlepiej będzie Ci w stanie pomóc, a nie utrudnić wysiłki.
-* **Zgodność:** Nawet jeśli Twoja firma nie wydaje żadnych projektów typu open source, korzysta z oprogramowania innego typu. [Świadomość i proces](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) może zapobiegać bólom głowy, opóźnieniom produktowym, i procesom sądowym.
+* **Zgodność:** Nawet jeśli Twoja firma nie wydaje żadnych projektów typu open source, korzysta z oprogramowania innego typu. [Świadomość i proces](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) może zapobiegać bólom głowy, opóźnieniom produktowym, i procesom sądowym.
 
 <aside markdown="1" class="pquote">
   Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
diff --git a/_articles/pt/legal.md b/_articles/pt/legal.md
index 968e5ce9b31..3aa0babf75e 100644
--- a/_articles/pt/legal.md
+++ b/_articles/pt/legal.md
@@ -145,7 +145,7 @@ A longo prazo, sua equipe jurídica pode fazer mais para ajudar a empresa a obte
 </aside>
 
 * **O que liberar:** [(Quase) tudo?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Se a sua equipe jurídica entender e investir na estratégia open source da sua empresa, ela será mais capaz de ajudar do que atrapalhar seus esforços.
-* **Conformidade:** Mesmo que sua empresa não libere nenhum projeto open source, ela usa o software open source dos outros. [Conscientização e processo](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) pode evitar dores de cabeça, atrasos de produtos e ações judiciais.
+* **Conformidade:** Mesmo que sua empresa não libere nenhum projeto open source, ela usa o software open source dos outros. [Conscientização e processo](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) pode evitar dores de cabeça, atrasos de produtos e ações judiciais.
 
 <aside markdown="1" class="pquote">
   Organizações devem ter uma estratégia de licença e conformidade funcionando que encaixe ambas as categorias \["permissive" e "copyleft"\]. Isso começa com a manutenção de um registro dos termos de licença que se aplicam ao software open source que você está utilizando — incluindo subcomponentes e dependências.
diff --git a/_articles/ro/legal.md b/_articles/ro/legal.md
index 163daa229de..0dcf7c8dcec 100644
--- a/_articles/ro/legal.md
+++ b/_articles/ro/legal.md
@@ -165,7 +165,7 @@ Pe termen lung, echipa voastră juridică poate face mai mult pentru a ajuta com
 </aside>
 
 * **Ce să lansezi:** [(Aproape) totul?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Dacă echipa voastră juridică înțelege și este investită în strategia open source a companiei voastre, ei vor fi cel mai bine capabili să te ajute în loc să împiedice eforturile tale.
-* **Conformare:** Chiar dacă compania ta nu lansează niciun proiect cu sursă deschisă, ea folosește software open source al altora. [Conștientizarea și procesul](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) pot preveni dureri de cap, întârzieri de produs, și procese.
+* **Conformare:** Chiar dacă compania ta nu lansează niciun proiect cu sursă deschisă, ea folosește software open source al altora. [Conștientizarea și procesul](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) pot preveni dureri de cap, întârzieri de produs, și procese.
 
 <aside markdown="1" class="pquote">
   <p>
diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md
index ed3d2ee91dc..00cd216088c 100644
--- a/_articles/ru/legal.md
+++ b/_articles/ru/legal.md
@@ -145,7 +145,7 @@ related:
 </aside>
 
 * **Что выпустить:** [(Почти) все](http://tom.preston-werner.com/2011/11/22/open-source-everything.html)? Если ваша юридическая команда понимает и вкладывается в стратегию открытого исходного кода вашей компании, они смогут намного лучше помочь, чем препятствовать вашим усилиям.
-* **Соответствие:** Даже если ваша компания не выпускает проекты с открытым исходным кодом, она использует чужое программное обеспечение с открытым исходным кодом. [Осведомленность и процесс](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) могут предотвратить головные боли, задержки продукта и судебные иски.
+* **Соответствие:** Даже если ваша компания не выпускает проекты с открытым исходным кодом, она использует чужое программное обеспечение с открытым исходным кодом. [Осведомленность и процесс](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) могут предотвратить головные боли, задержки продукта и судебные иски.
 
 <aside markdown="1" class="pquote">
 Организации должны иметь лицензию и стратегию соответствия, которая подходит как для категорий \["разрешающий", так и "авторское лево"\]. Это начинается с записи условий лицензирования, которые применяются к программному обеспечению с открытым исходным кодом, которое вы используете, включая субкомпоненты и зависимости.
diff --git a/_articles/ta/legal.md b/_articles/ta/legal.md
index bddb062152b..5807627bea6 100644
--- a/_articles/ta/legal.md
+++ b/_articles/ta/legal.md
@@ -144,7 +144,7 @@ Yஉங்கள் திட்டம் **சார்புகள்** கொ
 </aside>
 
 * **எதை வெளியிடுவது:** [(கிட்டத்தட்ட) எல்லாவற்றையும்?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) உங்கள் சட்ட குழு புரிந்துகொண்டு உங்கள் நிறுவனத்தின் திறந்த மூலோபாயத்தில் முதலீடு செய்திருந்தால், உங்கள் முயற்சிகளை தடுப்பதை காட்டிலும் உதவி செய்ய முடியும்.
-* **இணக்கம்:** உங்கள் நிறுவனம் திறந்த மூல திட்டங்களை வெளியிடாவிட்டாலும், அது மற்றவரின் திறந்த மூல மென்பொருள் பயன்படுத்துகிறது. [விழிப்புணர்வு மற்றும் செயல்முறை](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) தலைவலி, தயாரிப்பு தாமதங்கள் மற்றும் வழக்குகள் ஆகியவற்றை தடுக்கலாம்.
+* **இணக்கம்:** உங்கள் நிறுவனம் திறந்த மூல திட்டங்களை வெளியிடாவிட்டாலும், அது மற்றவரின் திறந்த மூல மென்பொருள் பயன்படுத்துகிறது. [விழிப்புணர்வு மற்றும் செயல்முறை](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) தலைவலி, தயாரிப்பு தாமதங்கள் மற்றும் வழக்குகள் ஆகியவற்றை தடுக்கலாம்.
 
 <aside markdown="1" class="pquote">
   நிறுவனங்கள் ["இசைவு தருகிற" and "அளிப்புரிமை"] வகைகளை பொருந்தும் வகையில் உரிமம் மற்றும் இணக்கம் மூலோபாயம் இருக்க வேண்டும். நீங்கள் பயன்படுத்தும் திறந்த மூல மென்பொருளுக்கு பொருந்தும் உரிம விதிகளின் பதிவுகளை வைத்து இது தொடங்குகிறது - துணைக்குழுக்கள் மற்றும் சார்புகள் உட்பட.
diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index b32df57eb17..9fd2f1a1c94 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -145,7 +145,7 @@ Daha uzun vadede hukuk ekibiniz, şirketin açık kaynaklara katılımından dah
 </aside>
 
 * **Neyi yayınlama:** [(Neredeyse) her şey?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Eğer yasal ekibiniz şirketinizin açık kaynaklı stratejisini anlıyor ve yatırım yapıyorsa, çabalarınızı engellemekten ziyade en iyi şekilde yardım edebileceklerdir.
-* **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir.
+* **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir.
 
 <aside markdown="1" class="pquote">
   Kuruluşların hem \["izin verilen" hem de "copyleft"\] kategorilerine uyan bir lisans ve uyum stratejisi olmalıdır. Bu, alt bileşenler ve bağımlılıklar dahil, kullanmakta olduğunuz açık kaynaklı yazılım için geçerli olan lisans terimlerinin kaydını tutmakla başlar.
diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index 8f8fd202722..03b342bd15b 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -144,7 +144,7 @@ redirect_from: /zh-cn/legal/
 </aside>
 
 * **发布什么：**[（几乎） 所有？](http://tom.preston-werner.com/2011/11/22/open-source-everything.html)如果你们的法律团队了解并投资于你们公司的开源策略，他们将是你们最好的帮助，而不是阻碍你们的努力。
-* **合规性：**即使你们公司没有发布任何开源项目，他们也会使用别人的开源软件。[意识和过程](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻烦，产品延迟发布和诉讼。
+* **合规性：**即使你们公司没有发布任何开源项目，他们也会使用别人的开源软件。[意识和过程](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻烦，产品延迟发布和诉讼。
 
 <aside markdown="1" class="pquote">
   组织必须具有适合["允许"和"copyleft"]类别的许可协议和合规性策略。首先，记录适用于你们所使用的开源软件的许可条款（包括子组件和依赖项）。
diff --git a/_articles/zh-hant/legal.md b/_articles/zh-hant/legal.md
index 33796840c18..fcabcdc6ab0 100644
--- a/_articles/zh-hant/legal.md
+++ b/_articles/zh-hant/legal.md
@@ -143,7 +143,7 @@ redirect_from: /zh-tw/legal/
 </aside>
 
 * **發佈什麼：**[（幾乎） 所有？](http://tom.preston-werner.com/2011/11/22/open-source-everything.html)如果你們的法律團隊瞭解並投資於你們公司的開源策略，他們將是你們最好的幫助，而不是阻礙你們的努力。
-* **合規性：**即使你們公司沒有發佈任何開源專案，他們也會使用別人的開源軟件。[意識和過程](https://www.linuxfoundation.org/blog/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻煩，產品延遲發佈和訴訟。
+* **合規性：**即使你們公司沒有發佈任何開源專案，他們也會使用別人的開源軟件。[意識和過程](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻煩，產品延遲發佈和訴訟。
 
 <aside markdown="1" class="pquote">
   組織必須具有適合["允許"和"copyleft"]類別的許可協議和合規性策略。首先，記錄適用於你們所使用的開源軟件的許可條款（包括子組件和依賴項）。

From dcf2e1aa0dece4d1c802129f1887eb046117100a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20S=C3=BCnder?= <asuender@student.tgm.ac.at>
Date: Sun, 26 Feb 2023 16:54:24 +0100
Subject: [PATCH 432/749] Update German translation

Some sentences sounded weird, so I corrected them, along with some other typos & smaller improvements.
---
 _articles/de/building-community.md        | 68 +++++++++---------
 _articles/de/code-of-conduct.md           |  4 +-
 _articles/de/finding-users.md             |  8 +--
 _articles/de/getting-paid.md              | 36 +++++-----
 _articles/de/leadership-and-governance.md | 32 ++++-----
 _articles/de/legal.md                     | 32 ++++-----
 _articles/de/metrics.md                   | 10 +--
 _articles/de/starting-a-project.md        | 84 +++++++++++------------
 8 files changed, 137 insertions(+), 137 deletions(-)

diff --git a/_articles/de/building-community.md b/_articles/de/building-community.md
index 46792f9abe9..8415d5ff371 100644
--- a/_articles/de/building-community.md
+++ b/_articles/de/building-community.md
@@ -14,11 +14,11 @@ related:
 
 Ihr gerade gestartetes Projekt wird schon verbreitet und Leute schauen vorbei? Fantastisch! Wie überzeugen Sie sie, da zu bleiben?
 
-Eine einladende, offenherzige Gemeinschaft ist eine Investition in die Zukunft und in den Ruf Ihres Projekts. Wenn Ihr Projekt gerade erst die initialen Kontributionen erfährt, fangen Sie damit an, den frühen Kontributor\*innen eine positive Erfahrung zu bereiten, und machen Sie es ihnen leicht, wiederzukommen.
+Eine einladende, offenherzige Gemeinschaft ist eine Investition in die Zukunft und in den Ruf Ihres Projekts. Wenn Ihr Projekt gerade erst die initialen Beiträge erfährt, fangen Sie damit an, den frühen Mitwirkenden eine positive Erfahrung zu bereiten, und machen Sie es ihnen leicht, wiederzukommen.
 
 ### Geben Sie Leuten das Gefühl, willkommen zu sein
 
-Die Community Ihres Projekts kann nach @MikeMcQuaid als "Kontributor*innentrichter" ([contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel)) aufgefasst werden:
+Die Community Ihres Projekts kann nach @MikeMcQuaid als "Mitwirkendenrichter" ([contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel)) aufgefasst werden:
 
 ![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
 
@@ -30,17 +30,17 @@ Beginnen Sie mit der Dokumentation:
 * **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.
 
-[GitHubs 2017er Open-Source-Umfrage](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.
+[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.
 
 * **Wenn Leute neu zu Ihrem Projekt hinzustoßen, danken Sie ihnen für ihr Interesse!** Ansonsten braucht es nur eine negative Erfahrung, um jemanden nachhaltig abzuschrecken.
 * **Antworten Sie schnell.** Wenn Sie einen Monat lang nicht auf jemandes Issue reagieren, ist es wahrscheinlich, dass diese Person Ihr Projekt bereits vergessen hat.
-* **Nehmen Sie verschiedener Beitragsarten an.** Viele Mitwirkende beginnen mit einem Fehlerbericht oder einer kleinen Korrektur: Es gibt [viele Möglichkeiten, einen Beitrag zu leisten](../how-to-contribute/#was-einen-beitrag-leisten-bedeutet) zu einem Projekt. Lassen Sie Leute so helfen, wie diese es möchten.
+* **Nehmen Sie unterschiedliche Arten von Beiträgen an.** Viele Mitwirkende beginnen mit einem Fehlerbericht oder einer kleinen Korrektur: Es gibt [viele Möglichkeiten, einen Beitrag zu leisten](../how-to-contribute/#was-einen-beitrag-leisten-bedeutet) zu einem Projekt. Lassen Sie Leute so helfen, wie diese es möchten.
 * **Wenn es einen Beitrag gibt, mit dem Sie nicht einverstanden sind,** bedanken Sie sich trotzdem, aber [erklären warum](../best-practices/#lernen-nein-zu-sagen) die Idee nicht in den Projektrahmen passt. Verlinken Sie auf relevante Dokumentation, wenn vorhanden.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
 
-  Zu Open Source beizutragen ist für Manche einfacher als für andere. Manche haben Angst, angeschrien zu werden, weil sie etwas nicht richtig machen könnten oder einfach nicht hineinpassen. (...) Indem man den Mitwirkenden die Möglichkeiten gibt, auch mit sehr geringen technischen Kenntnissen (Dokumentation, Abschriften von Webinhalten, etc.) beitragen zu können, kann man diese Bedenken stark reduzieren.
+  Zu Open-Source beitragen ist für manche einfacher als für andere. Manche haben Angst, angeschrien zu werden, weil sie etwas nicht richtig machen könnten oder einfach nicht hineinpassen. (...) Indem man den Mitwirkenden die Möglichkeiten gibt, auch mit sehr geringen technischen Kenntnissen (Dokumentation, Abschriften von Webinhalten, etc.) beitragen zu können, kann man diese Bedenken stark reduzieren.
 
   Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns.
 
@@ -73,7 +73,7 @@ Wenn Sie Dinge aufschreiben, können mehr Leute an jedem Schritt des Weges teiln
 
 Dinge aufzuschreiben, ist mehr als nur technische Dokumentation. Wenn Sie den Drang verspüren, etwas aufzuschreiben oder Ihr Projekt privat zu diskutieren, fragen Sie sich, ob Sie es nicht doch öffentlich machen können.
 
-Seien Sie transparent was die Roadmap Ihres Projekts angeht, die Arten von Beiträgen, nach denen Sie suchen, wie Beiträge überprüft werden, oder warum Sie bisherige Entscheidungen so getroffen haben.
+Seien Sie transparent, was die Roadmap Ihres Projekts angeht, die Arten von Beiträgen, nach denen Sie suchen, wie Beiträge überprüft werden, oder warum Sie bisherige Entscheidungen so getroffen haben.
 
 Wenn Sie feststellen, dass mehrere Benutzer\*innen auf das gleiche Problem stoßen, dokumentieren Sie die Antworten in der README.
 
@@ -83,15 +83,15 @@ Alles zu dokumentieren, gilt auch für Ihre Arbeit. Wenn Sie an einem umfangreic
 
 ### Antworten Sie schnell
 
-Wenn Sie [für Ihr Projekt werben](../finding-users), werden Leute Ihnen Rückmeldungen geben. Vielleicht in Form von Fragen, wie etwas in Ihrem Projekt funktioniert, oder sie brauchen Starthilfe bei der Benutzung.
+Wenn Sie [für Ihr Projekt werben](../finding-users), werden Sie sicherlich Rückmeldungen geben - vielleicht in Form von Fragen, wie etwas in Ihrem Projekt funktioniert, oder wo sie Hilfe für die Benutzung finden können.
 
-Versuchen Sie, schnell zu reagieren, wenn jemand ein Issue oder Pull Request einreicht, oder eine Frage zu Ihrem Projekt stellt. Eine schnell Antwort gibt den Leuten das Gefühl, an einem Dialog teilzunehmen, und das kann ermutigend wirken, weiter mitzuhelfen.
+Versuchen Sie, schnell zu reagieren, wenn jemand ein Issue oder Pull Request einreicht, oder eine Frage zu Ihrem Projekt stellt. Eine schnelle Antwort gibt den Leuten das Gefühl, an einem Dialog teilzunehmen, und das kann ermutigend wirken, weiter mitzuhelfen.
 
-Auch wenn Sie die Anfrage nicht sofort inhaltlich prüfen können, hilft die frühzeitige Bestätigung, das Engagement zu erhöhen. Ein Beispiel: @tdreyno reagiert auf einen Pull Request an [Middleman](https://github.com/middleman/middleman/pull/1466):
+Auch wenn Sie die Anfrage nicht sofort inhaltlich prüfen können, hilft eine frühzeitige Bestätigung, das Engagement zu erhöhen. Ein Beispiel: @tdreyno reagiert auf einen Pull Request an [Middleman](https://github.com/middleman/middleman/pull/1466):
 
 ![Pull Request an Middleman](/assets/images/building-community/middleman_pr.png)
 
-[Eine Mozilla-Studie fand heraus, dass](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) Kontributor\*innen, deren Codebeitrag innerhalb von 48 Stunden überprüft wurde, deutlich häufiger nochmal mithalfen.
+[Eine Mozilla-Studie fand heraus, dass](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) Mitwirkende, deren Codebeitrag innerhalb von 48 Stunden überprüft wurde, deutlich häufiger nochmal mithalfen.
 
 Ihr Projekt kann an allen möglichen Stellen des Internets besprochen werden, wie z.B. auf Stack Overflow, Twitter oder Reddit. Dort können Sie Benachrichtigungen einrichten, um über Erwähnungen Ihres Projektes informiert zu werden.
 
@@ -99,11 +99,11 @@ Ihr Projekt kann an allen möglichen Stellen des Internets besprochen werden, wi
 
 Es gibt zwei Gründe, Ihrer Gemeinschaft einen Ort der Begegnung zu geben.
 
-Der erste Grund ist, Menschen mit gemeinsamen Interessen zu helfen, sich kennenzulernen. Menschen mit gemeinsamen Interessen wollen sich zwangsläufig treffen können, um über diese zu reden. Wenn die Kommunikation öffentlich und zugänglich ist, kann jede\*r die Archive lesen, um sich auf den neuesten Stand zu bringen und sich daran zu beteiligen.
+Der erste Grund ist, Menschen mit gemeinsamen Interessen zu helfen, sich kennenzulernen. Menschen mit gemeinsamen Interessen wollen sich zwangsläufig treffen können, um über diese zu reden. Wenn die Kommunikation öffentlich und zugänglich ist, kann jeder die Archive lesen, um sich auf den neuesten Stand zu bringen und sich daran zu beteiligen.
 
 Der zweite Grund nützt Ihnen selbst: Wenn Sie den Leuten _keinen_ öffentlichen Ort geben, um über Ihr Projekt zu sprechen, werden sie wahrscheinlich direkt mit Ihnen in Verbindung treten. Am Anfang mag es einfach erscheinen, hin und wieder mal auf private Nachrichten zu antworten, aber mit der Zeit, besonders wenn Ihr Projekt populär wird, werden Sie sich erschöpft fühlen und der Versuchung widerstehen, mit Leuten über Ihr Projekt privat zu kommunizieren, anstatt sie an einen bestimmten öffentlichen Kanal zu verweisen.
 
-Öffentliche Kommunikation kann ganz einfach sein: Bitten Sie Leute, ein Issue zu öffnen, anstatt Ihnen direkt eine E-Mail zu schreiben oder in Ihr Blog zu kommentieren. Sie können für Leute, die über Ihr Projekt sprechen möchten, auch eine Mailingliste einrichten oder einen Twitter-Account, einen Slack- oder IRC-Kanal. Oder all dies gleichzeitig ausprobieren!
+Öffentliche Kommunikation kann ganz einfach sein: Bitten Sie Leute, ein Issue zu öffnen, anstatt Ihnen direkt eine E-Mail zu schreiben oder in Ihr Blog zu kommentieren. Sie können für Leute, die über Ihr Projekt sprechen möchten, auch eine Mailingliste einrichten oder einen Twitter-Account, einen Slack- oder IRC-Kanal. Oder gleich alles auf einmal!
 
 [Kubernetes' Kops](https://github.com/kubernetes/kops#getting-involved) legt alle zwei Wochen Bürozeiten fest, um den Mitglieder*innen der Gemeinschaft zu helfen:
 
@@ -141,7 +141,7 @@ Wenn Sie ein destruktives Verhalten in Ihrem Projekt beobachten, sprechen Sie es
 
 ### Holen Sie Mitwirkende dort ab, wo sie sich stehen
 
-Eine gute Dokumentation wird nur immer wichtiger, je mehr Ihre Community wächst. Gelegenheitskontributor\*innen, die mit Ihrem Projekt nicht vertraut sind, lesen Ihre Dokumentation, um schnell den nötigen Überblick zu bekommen.
+Eine gute Dokumentation wird immer wichtiger, je mehr Ihre Community wächst. Mitwirkende, die nur gelegentlich Beiträge leisten und damit mit Ihrem Projekt nicht zwingend vertraut sind, lesen Ihre Dokumentation, um schnell den nötigen Überblick zu bekommen.
 
 Geben Sie in Ihrer CONTRIBUTING-Datei explizit an, wie sie anfangen sollen. Vielleicht möchten Sie sogar eine eigene Sektion für diesen Zweck einrichten: [Django](https://github.com/django/django) zum Beispiel, hat eine spezielle Startseite, die neue Mitwirkende willkommen heißt.
 
@@ -151,7 +151,7 @@ Die Liste der Issues sollte durchsortiert sein, Bugs z.B. als solche markiert, s
 
 Nicht zuletzt sollten Sie die Dokumentation nutzen, um Leute mit offenen Armen zu empfangen und ihnen Schritt-für-Schritt zu helfen.
 
-Sie werden mit den meisten Leuten, die auf Ihr Projekt stoßen nie interagieren. Ihnen könnten Beiträge entgehen, weil jemand sich eingeschüchtert fühlte, oder nicht herausfand, was es denn zu tun gab. Schon ein paar freundliche Worte können verhindern, dass jemand einfach weiter zieht.
+Sie werden mit den meisten Leuten, die auf Ihr Projekt stoßen, nie interagieren. Ihnen könnten Beiträge entgehen, weil jemand sich eingeschüchtert fühlte, oder nicht herausfand, was es denn zu tun gab. Schon ein paar freundliche Worte können verhindern, dass jemand einfach weiter zieht.
 
 Zum Beispiel: [Rubinius](https://github.com/rubinius/rubinius/) beginnt [den Kontributionsratgeber](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) mit:
 
@@ -173,9 +173,9 @@ Zum Beispiel: [Rubinius](https://github.com/rubinius/rubinius/) beginnt [den Kon
   </p>
 </aside>
 
-Leute sind begeistert davon, an Projekten mitzuwirken, wenn sie ein Gefühl für Verantwortung bekommen. Das bedeutet nicht, dass Sie Ihre Projektvision umdrehen müssen, oder Beiträge annehmen, die Sie nicht wollen. Je mehr Anerkennung Sie anderen Menschen jedoch zollen, desto eher werden diese bei Ihrem Projekt bleiben.
+Leute sind begeistert davon, an Projekten mitzuwirken, wenn sie ein Gefühl für Verantwortung bekommen. Das bedeutet nicht, dass Sie Ihre Projektvision umdrehen müssen, oder Beiträge annehmen, die Sie nicht wollen. Je mehr Anerkennung Sie anderen Menschen jedoch schenken, desto eher werden diese bei Ihrem Projekt bleiben.
 
-Schauen Sie, ob Sie Wege finden können, Verantwortlichkeiten so weit wie möglich mit Ihren Projektteilnehmer\*innen zu teilen:
+Schauen Sie, ob Sie Wege finden können, Verantwortlichkeiten so weit wie möglich mit Ihren Projektteilnehmern\*innen zu teilen:
 
 * **Lassen Sie einfache (unkritische) Bugs unangetastet.** Nutzen Sie diese stattdessen als Gelegenheit, neue Mitwirkende zu rekrutieren, oder helfen Sie einem hilfsbereiten Neuling, den Prozess eines Bug-Fixes zu durchlaufen. Es mag zunächst unnatürlich erscheinen, aber Ihre Investition wird sich im Laufe der Zeit auszahlen. @michaeljoseph hat zum Beispiel einen Mitwirkenden gebeten, einen Pull Request zu einem der folgenden Probleme in [Cookiecutter](https://github.com/audreyr/cookiecutter) zu stellen, anstatt es selbst zu beheben.
 
@@ -185,11 +185,11 @@ Schauen Sie, ob Sie Wege finden können, Verantwortlichkeiten so weit wie mögli
 
 * Wenn Sie schon eine etwas größere Gemeinschaft versammelt haben, **senden Sie eine Rundmail oder schreiben ins Blog**, dass Sie Kontributor\*innen danken. Rusts [This Week in Rust](https://this-week-in-rust.org/) und Hoodies [Shoutout-Grüße](http://hood.ie/blog/shoutouts-week-24.html) sind zwei gute Beispiele dafür.
 
-* **Geben Sie allen Kontributor\*innen 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.
+* **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.
 
-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, desteo einfacher wird es sein, Hilfe zu finden.
+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.
 
 Während Sie vielleicht nicht immer Leute finden, die einem Aufruf folgen, erhöht so ein Signals doch die Wahrscheinlichkeit, dass Andere mitmachen. Je früher Sie damit anfangen, desto eher können die Leute helfen.
 
@@ -211,13 +211,13 @@ In der Anfangsphase Ihres Projekts ist es einfach, wichtige Entscheidungen zu tr
 
 Je beliebter Ihr Projekt wird, desto mehr Menschen werden sich für von Ihnen getroffene Entscheidungen interessieren. Selbst wenn Sie keine große Gemeinschaft von Mitwirkenden haben: Wenn Ihr Projekt viele Benutzer\*innen hat, werden darunter Leute sein, die sich über Entscheidungen auslassen oder ihre eigenen Themen ansprechen.
 
-Wenn Sie eine freundliche, respektvolle Gemeinschaft gepflegt und Ihre Prozesse offen dokumentiert haben, sollten Alle zur Lösungsfindung in der Lage sein. Aber manchmal stoßen Sie auf ein Problem, das etwas schwieriger zu lösen ist.
+Wenn Sie eine freundliche, respektvolle Gemeinschaft gepflegt und Ihre Prozesse offen dokumentiert haben, sollten alle zur Lösungsfindung in der Lage sein. Aber manchmal stoßen Sie auf ein Problem, das etwas schwieriger zu lösen ist.
 
 ### Setzen Sie die Messlatte für Freundlichkeit
 
-Wenn sich Ihre Gemeinschaft mit einem schwierigen Thema auseinandersetzt, können sich Gemüter schnell mal erhitzen. Menschen können wütend oder frustriert werden und es an Anderen oder an Ihnen auslassen.
+Wenn sich Ihre Gemeinschaft mit einem schwierigen Thema auseinandersetzt, können sich Gemüter schnell mal erhitzen. Menschen können wütend oder frustriert werden und es an anderen oder an Ihnen auslassen.
 
-Ihre Aufgabe als Maintainer\*in ist es, solche Situationen vor einer Eskalation zu bewahren. Selbst wenn Sie eine klare eigene Meinung zu diesem Thema haben, versuchen Sie, die moderierende Position einzunehmen, anstatt sich in den Kampf zu stürzen und Ihre Ansichten durchzusetzen. Wenn jemand unfreundlich wird oder das Gespräch an sich reißt, [handeln Sie sofort](../building-community/#dulden-sie-keine-destruktiven-akteure), um die Diskussionen zivil und produktiv zu halten.
+Ihre Aufgabe als Maintainer\*in ist es, solche Situationen vor einer Eskalation zu schützen. Selbst wenn Sie eine klare eigene Meinung zu diesem Thema haben, versuchen Sie, die moderierende Position einzunehmen, anstatt sich in den Kampf zu stürzen und Ihre Ansichten durchzusetzen. Wenn jemand unfreundlich wird oder das Gespräch an sich reißt, [handeln Sie sofort](../building-community/#dulden-sie-keine-destruktiven-akteure), um die Diskussionen zivil und produktiv zu halten.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
@@ -233,7 +233,7 @@ Ihre Aufgabe als Maintainer\*in ist es, solche Situationen vor einer Eskalation
 
 Andere Leute erwarten von Ihnen, ein gutes Beispiel abzugeben. Sie können immer noch Enttäuschung, Unzufriedenheit oder Besorgnis ausdrücken, aber tun Sie dies auf eine ruhige Art und Weise.
 
-Es ist nicht einfach, einen kühlen Kopf zu bewahren, aber Führung zu zeigen, verbessert die Gesundheit der Gemeinschaft. Das Internet wird es Ihnen danken!
+Es ist nicht einfach, einen kühlen Kopf zu bewahren, aber Führung zu zeigen, verbessert die Gesundheit der Gemeinschaft. Das Internet wird Ihnen dafür danken!
 
 ### Nutzen Sie die README als Verfassung
 
@@ -241,18 +241,18 @@ Ihre README-Datei ist [mehr als nur eine Anleitung](../starting-a-project/#eine-
 
 ### Der Weg ist das Ziel
 
-Einige Projekte nutzen einen Abstimmungsprozess, um wichtige Entscheidungen zu treffen. Auf den ersten Blick ist es sinnvoll, so eine Antwort zu finden, anstatt sich gegenseitig zuzuhören und auf die Sichtweisen Anderer einzugehen.
+Einige Projekte eigene "Abstimmungsprozesse", um wichtige Entscheidungen zu treffen. Auf den ersten Blick ist es sinnvoll, so eine Antwort zu finden, anstatt sich gegenseitig zuzuhören und auf die Sichtweisen anderer einzugehen.
 
-Abstimmungen können aber politisch werden, wenn sich die Community-Mitglieder unter Druck gesetzt fühlen, sich gegenseitig einen Gefallen zu tun oder auf eine bestimmte Wahl zu treffen. Außerdem stimmt nicht jede\*r mit ab, z.B. weil es ein [stille Mehrheit](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in Ihrer Gemeinschaft geben könnte, oder neue Benutzer\*innen einfach nicht wussten, dass eine Abstimmung stattfindet.
+Abstimmungen können aber politisch werden, wenn sich die Community-Mitglieder unter Druck gesetzt fühlen, sich gegenseitig einen Gefallen zu tun oder eine bestimmte Wahl zu treffen. Außerdem stimmt nicht jeder mit ab, z.B. weil es ein [stille Mehrheit](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in Ihrer Gemeinschaft geben könnte, oder neue Benutzer\*innen einfach nicht wussten, dass eine Abstimmung stattfindet.
 
-Manchmal ist eine Abstimmung notwendig, um ein Patt aufzulösen. Aber soviel Sie können, betonen Sie die [Konsensfindung](https://de.wikipedia.org/wiki/Konsensprinzip) statt des Konsenses an sich.
+Manchmal ist eine Abstimmung notwendig, um ein Patt aufzulösen. Versuchen Sie daher - so gut es geht - die [Konsensfindung](https://de.wikipedia.org/wiki/Konsensprinzip) statt den Konsens selbst zu betonen.
 
-Im Rahmen der Konsensfindungsprozesses diskutieren die Mitglieder der Gemeinschaft wichtige Anliegen, bis sie das Gefühl haben, angemessen gehört worden zu sein, und wenn nur noch geringe Bedenken bestehen, kommt die Gemeinschaft voran. Die Konsensfindung erkennt an, dass eine Gemeinschaft möglicherweise keine perfekte Antwort finden kann. Stattdessen priorisiert sie das Zuhören und die Diskussion.
+Im Rahmen der Konsensfindungsprozesses diskutieren die Mitglieder der Gemeinschaft wichtige Anliegen, bis sie das Gefühl haben, angemessen gehört worden zu sein. Wenn dann nur noch geringe Bedenken bestehen, kommt die Gemeinschaft voran. Die Konsensfindung erlaubt auch, dass eine Gemeinschaft möglicherweise keine perfekte Antwort finden kann. Stattdessen priorisiert sie das Zuhören und die Diskussion.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
 
-  Für Atom-Issues gibt es kein Abstimmungssystem, weil z.B. das Atom-Team nicht in allen Fällen einem Abstimmungssystem folgen würde. Manchmal müssen wir uns für etwas entscheiden, das wir für richtig halten, auch wenn es unbeliebt ist. (...) Was ich anbieten und versprechen kann: Es ist meine Aufgabe, der Community zuzuhören.
+  Für Issues bei Atom gibt es kein Abstimmungssystem, weil z.B. das Atom-Team nicht in allen Fällen einem Abstimmungssystem folgen würde. Manchmal müssen wir uns für etwas entscheiden, das wir für richtig halten, auch wenn es unbeliebt ist. (...) Was ich anbieten und versprechen kann: Es ist meine Aufgabe, der Community zuzuhören.
 
   _Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do (...) is that it is my job to listen to the community._
 
@@ -263,19 +263,19 @@ Im Rahmen der Konsensfindungsprozesses diskutieren die Mitglieder der Gemeinscha
 
 Auch wenn Sie als Projektbetreuer\*in keine Konsensfindung betreiben möchten, ist es wichtig, dass die Leute ein offenes Ohr bei Ihnen finden. Anderen zuzuhören, und sich für die Lösung ihrer Probleme einzusetzen, hilft beim Entschärfen sensibler Situationen sehr. Lassen Sie Ihren Worten aber auch Taten folgen.
 
-Überstürzen Sie Entscheidungen nicht, nur um eine Lösung herbeizuführen. Stellen Sie sicher, dass jede\*r sich gehört fühlt und dass alle Informationen öffentlich gemacht wurden, bevor Sie sich auf eine Entscheidung zubewegen.
+Überstürzen Sie Entscheidungen nicht, nur um eine Lösung herbeizuführen. Stellen Sie sicher, dass jeder sich gehört fühlt und dass alle Informationen öffentlich gemacht wurden, bevor Sie sich auf eine Entscheidung zubewegen.
 
 ### Halten Sie Diskussionen fokussiert auf Aktionen
 
 Diskussionen sind wichtig, aber es gibt einen Unterschied zwischen produktiven und unproduktiven Gesprächen.
 
-Fördern Sie Diskussionen, die sich aktiv auf eine Lösung zubewegen: Wenn klar ist, dass Dinge zerredet werden, oder die Konversation vom Thema abweicht, persönliche Anfeindungen passieren, oder die Leute sich über kleine Details streiten, ist es Zeit für eine Beendigung der Diskussion.
+Fördern Sie Diskussionen, die sich aktiv auf eine Lösung zubewegen: Wenn klar wird, dass Dinge zerredet werden, oder die Konversation vom Thema abweicht, persönliche Anfeindungen passieren, oder die Leute sich über kleine Details streiten, ist es Zeit für eine Beendigung der Diskussion.
 
 Die Fortsetzung solcher Diskussionen ist nicht nur schlecht für das jeweilige Thema, sondern auch für die Gesundheit Ihrer Gemeinschaft. Die Botschaft zu vermitteln, dass unproduktive Diskussionen erlaubt oder sogar gefördert werden, könnte Leute zukünftig davon abgehalten werden, Probleme anzusprechen oder zu lösen.
 
-Bei jedem Diskussionsbeitrag ihrerseits, oder von Anderen, sollten Sie sich fragen _"Wie bringt uns dies einer Lösung näher?"_
+Bei jedem Diskussionsbeitrag ihrerseits, oder von anderen, sollten Sie sich fragen _"Wie bringt uns dies einer Lösung näher?"_
 
-Falls die Diskussion abdriftet, fragen Sie die Teilnehmer\*innen: _"Welche Schritte sollten wir als nächstes gehen?"_ um sie wieder zu fokussieren.
+Falls die Diskussion abdriftet, fragen Sie die Teilnehmer\*innen: _"Welche Schritte sollten wir als nächstes gehen?"_, um sie wieder zu fokussieren.
 
 Wenn eine Diskussion offensichtlich nirgendwo hinführt, es keine klaren Maßnahmen zu ergreifen gibt, oder schon welche ergriffen wurden, schließen Sie das Issue und erklären Sie, warum Sie es geschlossen haben.
 
@@ -293,15 +293,15 @@ Wenn eine Diskussion offensichtlich nirgendwo hinführt, es keine klaren Maßnah
 
 ### Wählen Sie Auseinandersetzungen mit Bedacht
 
-Der Kontext ist wichtig: Überlegen Sie, wer an der Diskussion beteiligt ist und wie die Diskutant\*innen den Rest der Gemeinschaft repräsentieren.
+Der Kontext ist wichtig: Überlegen Sie, wer an der Diskussion beteiligt ist und wie die Teilnehmer\*innen den Rest der Gemeinschaft repräsentieren.
 
-Ist jede\*r in der Community verärgert oder gar mit diesem Thema beschäftigt? Ist er oder sie ein\*e einzelne\*r Unruhestifter\*in? Berücksichtigen Sie nicht nur die Aktiven, sondern vergessen Sie Ihre stillen Community-Mitglieder\*innen nicht.
+Ist jeder in der Community verärgert oder gar mit diesem Thema beschäftigt? Ist er oder sie ein\*e einzelne\*r Unruhestifter\*in? Berücksichtigen Sie nicht nur die Aktiven, sondern vergessen Sie Ihre stillen Community-Mitglieder\*innen nicht.
 
 Wenn das Thema nicht die breiteren Bedürfnisse Ihrer Gemeinschaft widerspiegelt, müssen Sie vielleicht nur die Sorgen einiger Weniger anerkennen. Wenn es sich um ein wiederkehrendes Problem ohne klare Lösung handelt, weisen Sie sie auf frühere Diskussionen hin und schließen Sie das Issue.
 
 ### Identifizieren Sie einen Community-Tiebreaker
 
-Mit einer positiven Herangehensweise und klarer Kommunikation sind die schwierigsten Situationen lösbar. Aber auch in einem produktiven Gespräch kann es einfach zu Meinungsverschiedenheiten kommen. Identifizieren Sie dann eine Person oder Gruppe, die quasi als Schiedsrichter\*in fungieren kann.
+Mit einer positiven Herangehensweise und klarer Kommunikation sind selbst die schwierigsten Situationen lösbar. Aber auch in einem produktiven Gespräch kann es einfach zu Meinungsverschiedenheiten kommen. Identifizieren Sie dann eine Person oder Gruppe, die als Schiedsrichter\*in fungieren kann.
 
 Ein\*e solche\*r Schiedsrichter\*in kann die oder der Hauptverantwortliche für das Projekt sein, oder eine kleine Gruppe von Leuten, die über eine Entscheidung abstimmen. Idealerweise haben Sie einen Tiebreaker und den damit verbundenen Prozess in einer GOVERNANCE-Datei identifiziert, bevor Sie diese verwenden müssen.
 
diff --git a/_articles/de/code-of-conduct.md b/_articles/de/code-of-conduct.md
index 5014da00061..4b2c083c298 100644
--- a/_articles/de/code-of-conduct.md
+++ b/_articles/de/code-of-conduct.md
@@ -14,7 +14,7 @@ related:
 
 Ein Verhaltenskodex ist ein Dokument, das die Erwartungen an das Verhalten der Projektteilnehmer\*innen festlegt. Einen Verhaltenskodex festzulegen und durchzusetzen, kann dazu beitragen, eine positive soziale Atmosphäre für Ihre Community zu schaffen.
 
-Verhaltenskodizes schützen nicht nur Ihre Teilnehmer\*innen, sondern auch Sie selbst. Wenn Sie ein Projekt pflegen, werden Sie vielleicht feststellen, dass unproduktive Einstellungen von anderen dazu führen können, dass Sie sich im Laufe der Zeit ausgelaugt oder unglücklich über Ihre Arbeit fühlen.
+Verhaltenskodizes schützen nicht nur Ihre Mitwirkenden, sondern auch Sie selbst. Wenn Sie ein Projekt pflegen, werden Sie vielleicht feststellen, dass unproduktive Einstellungen von anderen dazu führen können, dass Sie sich im Laufe der Zeit ausgelaugt oder unglücklich über Ihre Arbeit fühlen.
 
 Ein Verhaltenskodex bevollmächtigt Sie, ein gesundes, konstruktives Miteinander zu fördern. Proaktiv zu sein, verringert die Wahrscheinlichkeit, dass Sie oder andere projektmüde werden, und hilft Ihnen, Maßnahmen gegen unerwünschtes Verhalten zu ergreifen.
 
@@ -103,7 +103,7 @@ Es gibt einige Möglichkeiten, wie Sie auf einen Verstoß gegen den Verhaltensko
 
 Manchmal kann keine Lösung erreicht werden. Die gemeldete Person kann aggressiv oder feindselig werden, wenn er oder sie damit konfrontiert wird oder das Verhalten nicht ändert. In dieser Situation sollten Sie vielleicht stärkere Maßnahmen in Betracht ziehen. Zum Beispiel:
 
-* **zeitweise Suspendierung** in Form eines vorübergehenden Verbots, sich an den Aspekten des Projekts zu beteiligen.
+* **zeitweise Suspendierung** in Form eines vorübergehenden Verbots, sich in irgendeiner Art am Projekt zu beteiligen.
 
 * Die Person **dauerhaft aus dem Projekt verbannen**.
 
diff --git a/_articles/de/finding-users.md b/_articles/de/finding-users.md
index 697076881b2..6a801f55ef3 100644
--- a/_articles/de/finding-users.md
+++ b/_articles/de/finding-users.md
@@ -26,7 +26,7 @@ Code-Beispiele wie @robb sie verwendet, können klar kommunizieren, warum sein P
 
 ![Cartography README](/assets/images/finding-users/cartography.jpg)
 
-Tiefere Einblicke in das Thema "Botschaften", finden Sie in Mozillas ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/)-Übung zur Entwicklung von Personas.
+Tiefere Einblicke in das Thema "Botschaften" finden Sie in Mozillas ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/)-Übung zur Entwicklung von Personas.
 
 ## Helfen Sie Menschen dabei, Ihr Projekt zu finden und zu beobachten
 
@@ -73,7 +73,7 @@ Nun, da Sie die Botschaft Ihres Projekt klargestellt haben, und seine einfache A
 
 Internetkommunikation ist ein großartiger Weg, um die Botschaft Ihres Projektes schnell zu verbreiten und verteilen zu lassen: Online-Kanälen bieten das Potenzial, ein sehr breites Publikum zu erreichen.
 
-Nutzen Sie die Vorteile bestehender Online-Communities und -Plattformen, um Ihr Publikum zu erreichen. Wenn es sich bei Ihrem Open Source Projekt um ein Softwareprojekt handelt, erreichen Sie Ihr Publikum wahrscheinlich auf [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), oder [Quora](https://www.quora.com/). Finden Sie die Kanäle, von denen Sie denken, dass die Menschen am meisten von Ihrer Arbeit profitieren werden, oder sich begeistern lassen.
+Nutzen Sie die Vorteile bestehender Online-Communities und -Plattformen, um Ihr Publikum zu erreichen. Wenn es sich bei Ihrem Open-Source-Projekt um ein Softwareprojekt handelt, erreichen Sie Ihr Publikum wahrscheinlich auf [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), oder [Quora](https://www.quora.com/). Finden Sie die Kanäle, von denen Sie denken, dass die Menschen am meisten von Ihrer Arbeit profitieren werden, oder sich begeistern lassen.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
@@ -89,7 +89,7 @@ Nutzen Sie die Vorteile bestehender Online-Communities und -Plattformen, um Ihr
 
 Finden Sie Wege, um Ihr Projekt auf relevante Art und Weise mit anderen zu teilen:
 
-* **Lernen Sie relevante Open Source Projekte und Communities kennen.** Manchmal müssen Sie nicht direkt für Ihr Projekt werben. Wenn Ihr Projekt perfekt für Datenwissenschaftler geeignet ist, die Python nutzen, lernen Sie die Python Data Science Community kennen. Wenn die Leute Sie kennenlernen, ergeben sich natürliche Gelegenheiten, über Ihre Arbeit zu sprechen und sie mit anderen zu teilen.
+* **Lernen Sie relevante Open-Source-Projekte und Communities kennen.** Manchmal müssen Sie nicht direkt für Ihr Projekt werben. Wenn Ihr Projekt perfekt für Datenwissenschaftler geeignet ist, die Python nutzen, lernen Sie die Python Data Science Community kennen. Wenn die Leute Sie kennenlernen, ergeben sich natürliche Gelegenheiten, über Ihre Arbeit zu sprechen und sie mit anderen zu teilen.
 * **Finden Sie Personen, die mit dem Problem konfrontiert sind, das Ihr Projekt löst.** Suchen Sie in verwandten Foren nach Personen, die in die Zielgruppe Ihres Projekts fallen, beantworten Sie deren Fragen und finden Sie einen taktvollen Weg, um Ihr Projekt als Lösung vorzuschlagen.
 * **Bitten Sie um Feedback.** Stellen Sie sich und Ihre Arbeit einem Publikum vor, das Sie für relevant und interessant hält, und geben Sie an, wer Ihrer Meinung nach von Ihrem Projekt profitieren könnte. Versuchen Sie, diesen Satz zu vervollständigen: _"Ich denke, dass mein Projekt wirklich den X helfen würde, die versuchen, Y zu tun."_. Hören Sie zu und reagieren Sie auf das Feedback anderer, anstatt einfach nur Ihre Arbeit anzupreisen.
 
@@ -169,7 +169,7 @@ Wenn Sie Neuankömmlingen helfen, Ressourcen gemeinsam nutzen und durchdachte Be
 
 Es ist nie zu früh oder zu spät, um mit dem Aufbau eines guten Rufs zu beginnen. Auch wenn Sie bereits ein eigenes Projekt gestartet haben, suchen Sie weiterhin nach Möglichkeiten, anderen zu helfen.
 
-Ein Publikum aufzubauen, schafft man nicht über Nacht. Das Vertrauens und den Respekt anderer zu gewinnen, nimmt Zeit in Anspruch, und der Aufbau Ihres Rufes endet nie.
+Ein Publikum aufzubauen schafft man nicht über Nacht. Das Vertrauens und den Respekt anderer zu gewinnen, nimmt Zeit in Anspruch, und der Aufbau Ihres Rufes endet nie.
 
 ## Weitermachen!
 
diff --git a/_articles/de/getting-paid.md b/_articles/de/getting-paid.md
index ac5aa3b5d1a..d2f154f7a6b 100644
--- a/_articles/de/getting-paid.md
+++ b/_articles/de/getting-paid.md
@@ -12,12 +12,12 @@ related:
 
 ## Warum manche Menschen finanzielle Unterstützung suchen
 
-Ein Großteil der Open-Source-Arbeit wird ehrenamtlich geleistet, z.B. wenn jemand in einem Projekt, das er benutzt, auf einen Fehler stößt und eine schnelle Lösung vorschlägt. Außerdem basteln viele Leute einfach in ihrer Freizeit an einem Open-Source-Projekt.
+Ein Großteil der Open-Source-Arbeit wird ehrenamtlich geleistet, z.B. wenn jemand in einem Projekt, das er/sie benutzt, auf einen Fehler stößt und eine schnelle Lösung vorschlägt. Außerdem basteln viele Leute einfach in ihrer Freizeit an einem Open-Source-Projekt.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
 
-  Ich war auf der Suche nach einem Hobby-Programmierprojekt, mit dem ich mich während der Weihnachtswoche beschäftigen konnte. (...) Ich hatte einen Heimcomputer und nicht viel anderes an der Hand und entschied mich, einen Interpreter für die neue Skriptsprache zu schreiben, über die ich in letzter Zeit nachgedacht hatte. (...) Ich wählte Python als Arbeitstitel.
+  Ich war auf der Suche nach einem Hobby-Programmierprojekt, mit dem ich mich während der Weihnachtswoche beschäftigen konnte. (...) Ich hatte einen Heimcomputer und nicht viel anderes an der Hand und entschied mich, einen Interpreter für die neue Skriptsprache zu schreiben, über die ich in letzter Zeit nachgedacht hatte. (...) Ich nannte sie Python.
 
   _I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title._
 
@@ -29,7 +29,7 @@ Ein Großteil der Open-Source-Arbeit wird ehrenamtlich geleistet, z.B. wenn jema
 Es gibt viele Gründe, warum eine Person _nicht_ für ihre Open-Source-Arbeit bezahlt werden möchte.
 
 * **Sie haben vielleicht schon einen Vollzeitjob, den sie lieben,** und der ihnen ermöglicht, in ihrer Freizeit einen Beitrag zu Open-Source-Software zu leisten.
-* **Sie mögen Open Source als Hobby,** oder als kreative Flucht und wollen sich finanziell nicht verpflichtet fühlen, an ihren Projekten arbeiten zu müssen.
+* **Sie mögen Open-Source als Hobby,** oder als kreative Flucht und wollen sich finanziell nicht verpflichtet fühlen, an ihren Projekten arbeiten zu müssen.
 * **Sie ziehen andere Vorteile aus ihren Open-Source-Beiträgen,** wie z.B. den Aufbau ihres Rufs oder Portfolios, das Erlernen neuer Fertigkeiten oder das Gefühl, in einer Gemeinschaft eingebettet zu sein.
 
 <aside markdown="1" class="pquote">
@@ -44,14 +44,14 @@ Es gibt viele Gründe, warum eine Person _nicht_ für ihre Open-Source-Arbeit be
   </p>
 </aside>
 
-Für andere kann eine Bezahlung die einzige Möglichkeit sein, sich an Open Source zu beteiligen. Sei es, weil das Projekt ständige oder zeitintensive Mitarbeit erfordert, oder seien es persönliche Gründe.
+Für andere kann eine Bezahlung die einzige Möglichkeit sein, sich an Open-Source zu beteiligen. Sei es, weil das Projekt ständige oder zeitintensive Mitarbeit erfordert, oder seien es persönliche Gründe.
 
 Populäre Projekte aufrecht zu erhalten, kann eine große Verantwortung sein, die 10 oder 20 Stunden pro Woche in Anspruch nimmt, statt nur ein paar Stunden pro Monat.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
 
-  Fragen Sie irgendeine\*n Open-Source-Projektbetreuer\*in, und sie oder er wird Ihnen sagen, wie viel Arbeit im Management eines Projekts steckt. Sie haben Kunden. Sie beheben Probleme für sie. Sie erschaffen neue Funktionen. Das alles wird zu einem echten Zeitaufwand.
+  Fragen Sie irgendeine\*n Open-Source-Projektbetreuer\*in, und er oder sie wird Ihnen sagen, wie viel Arbeit im Management eines Projekts steckt. Sie haben Kunden. Sie beheben Probleme für sie. Sie erschaffen neue Funktionen. Das alles wird zu einem echten Zeitaufwand.
 
   _Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time._
 
@@ -65,7 +65,7 @@ Bezahlte Arbeit ermöglicht Leuten aus verschiedenen Lebenssituationen heraus, s
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
 
-  OSS bringt massive Vorteile für die Technologieindustrie, was wiederum Vorteile für alle Branchen bedeutet. (...) Solange jedoch die einzigen Leute, die sich darauf konzentrieren können, die Glücklichen und die Besessenen sind, dann gibt es ein riesiges ungenutztes Potenzial.
+  OSS bringt massive Vorteile für die Technologieindustrie, was wiederum Vorteile für alle Branchen bedeutet. (...) Solange jedoch die einzigen Leute, die sich darauf konzentrieren können, die Glücklichen und die Besessenen sind, gibt es ein riesiges ungenutztes Potenzial.
 
   _OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential._
 
@@ -86,18 +86,18 @@ Wenn Sie kein existierendes Open-Source-Projekt haben, an dem Sie gerne arbeiten
 
 Viele Unternehmen entwickeln Open-Source-Programme, um ihre Marke aufzubauen und Talente zu rekrutieren.
 
-@hueniverse z.B., fand heraus, dass es finanzielle Gründe gab, die [Investition von Walmart in Open Source zu rechtfertigten.](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Und @jamesgpearce fand heraus, dass Facebooks Open-Source-Program [den Unterschied in der Personalakquise](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) machte:
+@hueniverse z.B., fand heraus, dass es finanzielle Gründe gab, die [Investition von Walmart in Open-Source zu rechtfertigten.](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Und @jamesgpearce fand heraus, dass Facebooks Open-Source-Program [den Unterschied in der Personalakquise](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) machte:
 
 > Es ist eng mit unserer Hackerkultur und der Wahrnehmung unseres Unternehmens verbunden. Wir fragten unsere Angestellten: "Kanntet ihr das Open-Source-Programm von Facebook?". Zwei Drittel sagten "Ja". Die Hälfte sagte, dass das Programm positiv zu ihrer Entscheidung beigetragen hat, für uns zu arbeiten. Das sind keine marginalen Zahlen, und ein sich hoffentlich fortsetzender Trend.
 >
 > It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
 
-Wenn Ihr Unternehmen diesen Weg einschlägt, ist es wichtig, die Grenzen zwischen Gemeinschafts- und Unternehmenstätigkeit klar zu halten, denn Open Source erhält sich letztlich durch Beiträge von Menschen auf der ganzen Welt. Und das ist größer als jedes einzelne Unternehmen oder jeder einzelne Standort.
+Wenn Ihr Unternehmen diesen Weg einschlägt, ist es wichtig, die Grenzen zwischen Gemeinschafts- und Unternehmenstätigkeit klar zu halten, denn Open-Source erhält sich letztlich durch Beiträge von Menschen auf der ganzen Welt. Und das ist größer als jedes einzelne Unternehmen oder jeder einzelne Standort.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
 
-  Die Arbeit an Open Source ist eine seltene und wunderbare Gelegenheit, aber Sie sollten dabei nicht auf Ihre Leidenschaft verzichten müssen. Denn die sollte der Grund für Ihre Bezahlung durch ein Unternehmen sein.
+  Die Arbeit an Open-Source ist eine seltene und wunderbare Gelegenheit, aber Sie sollten dabei nicht auf Ihre Leidenschaft verzichten müssen. Denn die sollte der Grund für Ihre Bezahlung durch ein Unternehmen sein.
 
   _Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you._
 
@@ -106,12 +106,12 @@ Wenn Ihr Unternehmen diesen Weg einschlägt, ist es wichtig, die Grenzen zwische
   </p>
 </aside>
 
-Wenn Sie Ihren derzeitigen Arbeitgeber nicht davon überzeugen können, Open-Source-Arbeit zu priorisieren, sollten Sie sich überlegen, einen neuen Arbeitgeber zu finden, der Mitarbeit an Open Source fördert. Zum Beispiel:
+Wenn Sie Ihren derzeitigen Arbeitgeber nicht davon überzeugen können, Open-Source-Arbeit zu priorisieren, sollten Sie sich überlegen, einen neuen Arbeitgeber zu finden, der Mitarbeit an Open-Source fördert. Zum Beispiel:
 
 * Manche Firmen, wie [Netflix](https://netflix.github.io/) oder [PayPal](https://paypal.github.io/), zeigen ihr Open-Source-Engagement auf ihren Webseiten
 * [Zalando](https://opensource.zalando.com) veröffentlicht seine [Open-Source-Beitragsrichtlinie](https://opensource.zalando.com/docs/using/contributing/) für Angestellte
 
-Aus einer großen Firma stammende Projekte, wie z.B. [Go](https://github.com/golang) oder [React](https://github.com/facebook/react), stellen vermutlich auch weiterhin Leute für Open-Source-Arbeit an.
+Aus einer großen Firma stammende Projekte, wie z.B. [Go](https://github.com/golang) oder [React](https://github.com/facebook/react), stellen u. U. auch weiterhin Leute für Open-Source-Arbeit an.
 
 Außerdem können Sie versuchen, abhängig von Ihren persönlichen Umständen, selbstständig Geld zu sammeln, um Ihre Open-Source-Arbeit zu finanzieren, zum Beispiel:
 
@@ -125,7 +125,7 @@ Abgesehen von Vereinbarungen für einzelne Projektteilnehmer\*innen, sammeln Pro
 
 Geld von einer Organisation kann verwendet werden, aktuelle Projektteilnehmer\*innen zu bezahlen, die Kosten für den Betrieb des Projekts zu decken (z.B. Hosting-Gebühren) oder in neue Funktionen oder Ideen zu investieren.
 
-Da Open Source populärer wird, ist die Finanzierung von Projekten immer noch experimentell, aber es gibt einige allgemeine Optionen.
+Da Open-Source populärer wird, ist die Finanzierung von Projekten immer noch experimentell, aber es gibt einige allgemeine Optionen.
 
 ### Geld mittels Crowdfunding-Kampagnen oder Sponsoren einsammeln
 
@@ -150,7 +150,7 @@ Einige populäre Projekte, wie z.B. [npm](https://github.com/npm/cli) und [Docke
 
 Einige Softwarestiftungen und Unternehmen bieten Zuschüsse für Open-Source-Arbeiten an. Manchmal können Zuschüsse an Einzelpersonen ausgezahlt werden, ohne eine juristische Person für das Projekt zu gründen.
 
-* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** erhielt eine Förderung des [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** erhielt eine Förderung des [Mozilla Open-Source Support](https://www.mozilla.org/en-US/grants/)
 * Arbeiten an **[OpenMRS](https://github.com/openmrs)** wurden von [Stripes Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) gefördert
 * **[Libraries.io](https://github.com/librariesio)** erhielt Fördermittel der [Sloan Foundation](https://sloan.org/programs/digital-technology)
 * Die **[Python Software Foundation](https://www.python.org/psf/grants/)** fördert Python-relvante Arbeiten
@@ -161,19 +161,19 @@ Weitere, detaillierter erklärte Möglichkeiten, um für Open-Source-Arbeit beza
 
 Egal ob Ihr Projekt eine neue Idee umsetzt, oder schon seit Jahren besteht: Sie sollten sich Gedanken über passende Finanzierung machen, Geldquellen identifizieren, und diesen ein überzeugendes Argument liefern können.
 
-Egal, ob Sie für Ihre eigene Zeit oder für ein Projekt Geld sammeln möchten, Sie sollten in der Lage sein, die folgenden Fragen zu beantworten.
+Egal, ob Sie für Ihre eigene Zeit bezahlen oder für ein Projekt Geld sammeln möchten, sollten Sie in der Lage sein, die folgenden Fragen zu beantworten.
 
 ### Einfluss
 
-Warum ist dieses Projekt nützlich? Warum gefällt es Ihren (potenziellen) Nutzer\*innen so gut? Wo wird es in fünf Jahren sein?
+Wie kann dieses Projekt von Nutzen sein? Warum gefällt es Ihren (potenziellen) Nutzer\*innen so gut? Wo wird es in fünf Jahren sein?
 
 ### Wichtigkeit
 
-Versuchen Sie Beweise für die Wichtigkeit Ihres Projektes zu sammeln: Metriken, Anekdoten oder Referenzen. Gibt es Unternehmen oder bemerkenswerte Personen, die Ihr Projekt gerade nutzen? Falls nicht, hat es jemand Bekanntes empfohlen?
+Versuchen Sie Beweise für die Wichtigkeit Ihres Projektes zu sammeln: Metriken, Anekdoten oder Referenzen. Gibt es Unternehmen oder wichtige Personen, die Ihr Projekt gerade nutzen? Falls nicht, hat eine bekannte Person es befürwortet?
 
 ### Nutzen für die Geldgeber
 
-Geldgeber (sei es Ihr\*e Arbeitgeber\*in oder eine Förderstiftung) werden von vielen Anderen angesprochen: Warum sollte gerade Ihr Projekt unterstützt werden? Wie profitiert der Geldgeber selbst davon?
+Geldgeber (seien es Ihr\*e Arbeitgeber\*in oder eine Förderstiftung) werden von vielen anderen angesprochen: Warum sollte gerade Ihr Projekt unterstützt werden? Wie profitiert der Geldgeber selbst davon?
 
 ### Nutzung der Gelder
 
@@ -197,4 +197,4 @@ Hat der Geldgeber irgendwelche Anforderungen an die Auszahlung? Müssen Sie beis
 
 ## Experimentieren und nicht aufgeben
 
-Es ist nicht einfach, Geld zu sammeln. Egal ob Sie ein Open-Source-Projekt, einen gemeinnützigen Verein oder ein Software-Startup betreiben. In den meisten Fällen müssen Sie kreativ werden. Identifizieren Sie den Modus der Bezahlung, stellen Sie Recherchen an und versetzen Sie sich selbst in die Rolle der Geldgeber\*innen. Dies wird Ihnen beim Finden eines überzeugenden Argumentes für die Finanzierung helfen.
+Es ist nicht einfach, Geld zu sammeln. Egal ob Sie ein Open-Source-Projekt, einen gemeinnützigen Verein oder ein Software-Startup betreiben. In den meisten Fällen müssen Sie kreativ werden. Identifizieren Sie die Art der Bezahlung, stellen Sie Recherchen an und versetzen Sie sich selbst in die Rolle der Geldgeber\*innen. Dies wird Ihnen beim Finden eines überzeugenden Argumentes für die Finanzierung helfen.
diff --git a/_articles/de/leadership-and-governance.md b/_articles/de/leadership-and-governance.md
index 1eff016164e..fa8cef055b3 100644
--- a/_articles/de/leadership-and-governance.md
+++ b/_articles/de/leadership-and-governance.md
@@ -12,7 +12,7 @@ related:
 
 ## Die Lenkungen eines wachsenden Projektes verstehen
 
-Ihr Projekt wächst, Leute sind engagiert und Sie setzen sich dafür ein, dass alles _läuft_. In diesem Stadium fragen Sie sich vielleicht, wie Sie regelmäßig Mitwirkende in Ihren Arbeitsprozess einbinden können? Sei es durch die Gewährung von direktem Commit-Zugang oder durch die Führung von Debatten in der Gemeinschaft. Wir liefern Antworten auf Ihre Fragen.
+Ihr Projekt wächst, Leute sind engagiert und Sie setzen sich dafür ein, dass alles läuft. In diesem Stadium fragen Sie sich vielleicht, wie Sie regelmäßig Mitwirkende in Ihren Arbeitsprozess einbinden können - sei es durch die Gewährung von direktem Commit-Zugang oder durch die Führung von Debatten in der Gemeinschaft. Wir liefern Antworten auf Ihre Fragen.
 
 ## Welche formalen Rollen kann es in Open-Source-Projekten geben?
 
@@ -21,14 +21,14 @@ Viele Projekte folgen einer ähnlichen Struktur hinsichtlich Mitwirkung und Aner
 Was diese Rollen aber tatsächlich bedeuten, liegt ganz bei Ihnen. Nachfolgend sind einige Arten von Rollen aufgeführt, die Sie vielleicht schon kennen:
 
 * **Maintainer\*in**
-* **Kontributor\*in**
+* **Mitwirkende\*r**
 * **Committer\*in**
 
 **Bei einigen Projekten sind "Maintainer\*innen"** die einzigen Personen mit Commit-Rechten. In anderen Projekten sind es einfach die Leute, die in der README als Maintainer\*innen aufgelistet sind.
 
 Ein\*e Maintainer\*in muss in Ihrem Projekt nicht zwangsläufig Code schreiben. Es kann auch eine Person sein, die viel Öffentlichkeitsarbeit für Ihr Projekt geleistet hat, viel Dokumentation geschrieben hat, oder das Projekt für andere zugänglicher gemacht hat. Unabhängig davon, was sie tagtäglich tun, fühlen sich Maintainer\*innen wahrscheinlich für die Richtung des Projekts verantwortlich und setzen sich für dessen Verbesserung ein.
 
-"Kontributor\*innen" könnten alle Menschen sein, die ein Issue oder Pull Request kommentiert, die dem Projekt einen Mehrwert verleihen (sei es durch Problembehebungen, das Schreiben von Code oder die Veranstaltungsorganisation) oder alle, deren Pull Requests akzeptiert wurden (vielleicht die engste Definition für Kontribution).
+"Mitwirkende" könnten alle Menschen sein, die ein Issue oder Pull Request kommentiert, die dem Projekt einen Mehrwert verleihen (sei es durch Problembehebungen, das Schreiben von Code oder die Organisation von Veranstaltungen) oder alle, deren Pull Requests akzeptiert wurden (vielleicht die engste Definition für einen Beitrag).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -42,7 +42,7 @@ Ein\*e Maintainer\*in muss in Ihrem Projekt nicht zwangsläufig Code schreiben.
   </p>
 </aside>
 
-**Der Begriff "Committer\*in"** könnte verwendet werden, um die höhere Verantwortung des Commit-Rechtes zu unterscheiden von anderen Formen der Mitarbeit.
+**Der Begriff "Committer\*in"** könnte verwendet werden, um die höhere Verantwortung des Commit-Rechtes von anderen Formen der Mitarbeit zu unterscheiden.
 
 Sie können Ihre Projektrollen zwar nach Belieben definieren, aber Sie sollten die Verwendung von [breiteren Definitionen in Betracht ziehen](../how-to-contribute/#was-einen-beitrag-leisten-bedeutet), um mehr Beitragsformen zu fördern. Mit Hilfe von Führungsrollen können Sie Personen, die unabhängig von ihren fachlichen Fähigkeiten herausragende Leistungen für Ihr Projekt erbracht haben, formell auszeichnen.
 
@@ -79,7 +79,7 @@ Wenn Ihr Projekt eine sehr aktive Gemeinschaft von Mitwirkenden hat, können Sie
   </p>
 </aside>
 
-Führungsteams können einen Kommunikationskanal einrichten (z.B. im IRC) oder sich regelmäßig treffen, um das Projekt zu besprechen (z.B. in Gitter oder Google Hangout). Sie können diese Meetings sogar öffentlich machen, damit andere Leute zuhören können. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) zum Beispiel, [lädt zu wöchentlichen Sprechstunden ein](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+Führungsteams können einen Kommunikationskanal einrichten (z.B. mit IRC) oder sich regelmäßig treffen, um das Projekt zu besprechen (z.B. in Gitter oder Google Hangout). Sie können diese Meetings sogar öffentlich machen, damit andere Leute zuhören können. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) zum Beispiel, [lädt zu wöchentlichen Sprechstunden ein](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 Vergessen Sie nicht, nach der Festlegung von Führungsrollen zu dokumentieren, wie Menschen diese erreichen können! Richten Sie einen klaren Prozess ein, wie Leute Maintainer\*in werden oder einem Gremium in Ihrem Projekt beitreten können, und beschreiben Sie diesen Prozess in einer GOVERNANCE.md.
 
@@ -91,7 +91,7 @@ Wenn sich Ihr Projekt auf GitHub befindet, können Sie Ihr Projekt von Ihrem per
 
 Einige Leute denken, dass Sie allen Commit-Zugang geben sollten, die einen Beitrag geleistet haben. Dies könnte dazu führen, dass sich mehr Menschen für Ihr Projekt interessieren.
 
-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!
+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.
 
@@ -107,17 +107,17 @@ Wenn sich Ihr Projekt auf GitHub befindet, können Sie unter [protected branches
   </p>
 </aside>
 
-## Welche Lenkungsstrukturen nutzen Open-Source-Projekte häufiger?
+## Welche Verwaltungsstrukturen nutzen Open-Source-Projekte häufiger?
 
-Es gibt drei Lenkungsstrukturen, die häufig bei Open-Source-Projekten vorkommen.
+Es gibt drei Verwaltungsstrukturen, die häufig bei Open-Source-Projekten vorkommen.
 
 * * **BDFL:** BDFL steht für "Benevolent Dictator for Life" (gutmütige\*r Diktator\*in auf Lebenszeit). Bei dieser Struktur hat eine Person (in der Regel die oder der Erstautor\*in des Projekts) das letzte Wort bei allen wichtigen Projektentscheidungen. [Python](https://github.com/python) ist ein klassisches Beispiel. Kleinere Projekte haben wahrscheinlich standardmäßig ein\*e BDFL, da es nur einen oder zwei Maintainer\*innen gibt. Aus Unternehmen stammende Projekte können ebenfalls in die Kategorie BDFL fallen.
 
-* **Meritokratie:** **(Hinweis: Der Begriff "Meritokratie" ist bei einigen Communities negativ konnotiert und hat eine [komplexe soziale und politische Geschichte](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Unter einer Meritokratie erhalten aktive Projektmitarbeiter\*innen (diejenigen, die "sich die Meriten angelesen" haben) eine formelle Entscheidungsrolle. Entscheidungen werden in der Regel auf der Grundlage eines reinen Abstimmungskonsenses getroffen. Das Konzept der Meritokratie wurde von der [Apache Foundation](http://www.apache.org/) entwickelt; [alle Apache-Projekte](http://www.apache.org/index.html#projects-list) sind Meritokratien. Beiträge können nur von Personen geleistet werden, die sich selbst vertreten, nicht von einem Unternehmen.
+* **Meritokratie:** **(Hinweis: Der Begriff "Meritokratie" ist bei einigen Communitys negativ konnotiert und hat eine [komplexe soziale und politische Geschichte](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Unter einer Meritokratie erhalten aktive Projektmitarbeiter\*innen (diejenigen, die "sich die Meriten angelesen" haben) eine formelle Entscheidungsrolle. Entscheidungen werden in der Regel auf der Grundlage eines reinen Abstimmungskonsenses getroffen. Das Konzept der Meritokratie wurde von der [Apache Foundation](http://www.apache.org/) entwickelt; [alle Apache-Projekte](http://www.apache.org/index.html#projects-list) sind Meritokratien. Beiträge können nur von Personen geleistet werden, die sich selbst vertreten, nicht von einem Unternehmen.
 
 * **Liberales Beitragsmodell:** Nach einem liberalen Beitragsmodell werden die Menschen, die aktuell die meiste Arbeit leisten, als die einflussreichsten anerkannt. Dabei wird aber ihre frühere Beitragshistorie außer Acht gelassen. Wichtige Projektentscheidungen werden auf der Grundlage eines Konsensfindungsprozesses (Besprechen der wichtigsten Missstände) und nicht auf Grundlage reiner Abstimmung getroffen. Dabei streben solche Projekte nach Einbeziehung möglichst vieler Perspektiven der Gemeinschaft. Beliebte Beispiele für Projekte, die ein liberales Beitragsmodell verwenden, sind [Node.js](https://foundation.nodejs.org/) und [Rust](https://www.rust-lang.org/).
 
-Welches Modell sollten Sie verwenden? Das obliegt Ihnen! Jedes Modell hat Vor- und Nachteile. Und obwohl sie zunächst sehr unterschiedlich erscheinen mögen, haben alle drei Modelle mehr gemeinsam als zu vermuten wäre. Wenn Sie daran interessiert sind, eines dieser Modelle zu übernehmen, schauen Sie sich diese Vorlagen an (alle Englisch):
+Welches Modell sollten Sie verwenden? Das obliegt Ihnen! Jedes Modell hat Vor- und Nachteile. Und obwohl sie zunächst sehr unterschiedlich erscheinen mögen, haben alle drei Modelle mehr gemeinsam als zu vermuten wäre. Wenn Sie daran interessiert sind, eines dieser Modelle zu übernehmen, schauen Sie sich diese Vorlagen an (alle auf Englisch):
 
 * [BDFL-Modellvorlage](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
 * [Meritokratische Modellvorlage](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
@@ -129,7 +129,7 @@ Es gibt nicht den einen richtigen Zeitpunkt, um die Leitungs- und Steuerungsrich
 
 Frühzeitige Dokumentationen wird selbst auch dazu beitragen, wie sich Ihr Projekt entwickelt, also schreiben Sie ruhig früh auf, was Sie früh wissen. So können Sie beispielsweise schon zum Projektstart klare Erwartungen an die Funktionsweise Ihres Mitwirkungsprozesses definieren.
 
-Wenn Sie Teil eines Unternehmens sind, das ein Open-Source-Projekt startet, lohnt sich eine interne Diskussion vor dem Start. Wie erwartet Ihr Unternehmen, dass es das Projekt aufrechterhält und Entscheidungen trifft? Möglicherweise möchten Sie auch öffentlich erklären, wie oder ob Ihr Unternehmen in das Projekt eingebunden wird.
+Wenn Sie Teil eines Unternehmens sind, das ein Open-Source-Projekt startet, lohnt sich eine interne Diskussion vor dem Start. Wie erwartet Ihr Unternehmen, dass es das Projekt aufrechterhält und Entscheidungen trifft? Möglicherweise möchten Sie auch öffentlich erklären, ob oder wie Ihr Unternehmen in das Projekt eingebunden wird.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
@@ -149,11 +149,11 @@ Erfolgreiche Open-Source-Projekte werden von vielen Menschen und Unternehmen gen
 
 Mit zunehmender Verbreitung des Projekts werden Menschen, die über Fachwissen verfügen, immer gefragter (Sie könnten eine\*r davon sein!) und wird manchmal für die Arbeit bezahlt, die sie im Projekt leisten.
 
-Es ist wichtig, kommerzielle Aktivitäten als normal und als eine weitere Motivation für die Entwicklungsarbeit zu betrachten. Bezahlte Entwickler\*innen sollten natürlich keine Sonderbehandlung gegenüber Unbezahlten erhalten. Jeder Beitrag muss nach seinen technischen Eigenschaften bewertet werden. Allerdings sollten die Leute zu kommerziellen Aktivitäten bereit sein, und sich damit wohl fühlen, wenn sie ihre Anwendungsfälle angeben oder sich für eine bestimmte Verbesserung oder Funktion aussprechen.
+Es ist wichtig, kommerzielle Aktivitäten als normal und als eine weitere Motivation für die Entwicklungsarbeit zu betrachten. Bezahlte Entwickler\*innen sollten natürlich keine Sonderbehandlung gegenüber unbezahlten erhalten. Jeder Beitrag muss nach seinen technischen Eigenschaften bewertet werden. Allerdings sollten die Leute zu kommerziellen Aktivitäten bereit sein, und sich damit wohl fühlen, wenn sie ihre Anwendungsfälle angeben oder sich für eine bestimmte Verbesserung oder Funktion aussprechen.
 
-"Kommerziell" ist vollständig kompatibel mit "Open Source". "Kommerziell" bedeutet nur, dass irgendwo Geld im Spiel ist, z.B. dass die Software unternehmerisch eingesetzt wird. Dies wird umso wahrscheinlicher, je weiter sich ein Projekt verbreitet. Wenn Open-Source-Software als Teil eines Nicht-Open-Source-Produkts verwendet wird, ist das Gesamtprodukt immer noch "proprietäre" Software, obwohl sie (wie Open Source!) für kommerzielle oder nicht-kommerzielle Zwecke verwendet werden kann.
+"Kommerziell" ist vollständig kompatibel mit "Open-Source". "Kommerziell" bedeutet nur, dass irgendwo Geld im Spiel ist, z.B. dass die Software unternehmerisch eingesetzt wird. Dies wird umso wahrscheinlicher, je weiter sich ein Projekt verbreitet. Wenn Open-Source-Software als Teil eines Nicht-Open-Source-Produkts verwendet wird, ist das Gesamtprodukt immer noch "proprietäre" Software, obwohl sie (wie Open-Source!) für kommerzielle oder nicht-kommerzielle Zwecke verwendet werden kann.
 
-Wie jede\*r Andere auch, gewinnen kommerziell motivierte Entwickler\*innen durch die Qualität und Quantität ihrer Beiträge Einfluss auf das Projekt. Natürlich kann ein\*e Entwickler\*in, die oder der für die Arbeitszeit bezahlt wird, mehr tun als unbezahlte Beitragende, aber das ist in Ordnung: Bezahlung beeinflusst nur als einer von vielen möglichen Faktoren, was jemand tut. Halten Sie Ihre Projektdiskussionen auf den Inhalt der Beiträge fokussiert, nicht auf die externen Faktoren, die es den Menschen ermöglichen, diese Beiträge zu leisten.
+Wie jeder andere auch, gewinnen kommerziell motivierte Entwickler\*innen durch die Qualität und Quantität ihrer Beiträge Einfluss auf das Projekt. Natürlich kann ein\*e Entwickler\*in, die oder der für die Arbeitszeit bezahlt wird, mehr tun als unbezahlte Beitragende, aber das ist in Ordnung: Bezahlung beeinflusst nur als einer von vielen möglichen Faktoren, was jemand tut. Halten Sie Ihre Projektdiskussionen auf den Inhalt der Beiträge fokussiert, nicht auf die externen Faktoren, die es den Menschen ermöglichen, diese Beiträge zu leisten.
 
 ## Brauche ich für mein Projekt eine juristische Person?
 
@@ -161,14 +161,14 @@ Sie benötigen keine juristische Person, um Ihr Open-Source-Projekt zu verwalten
 
 Wenn Sie beispielsweise ein kommerzielles Unternehmen gründen möchten, sollten Sie eine GmbH oder UG gründen (wenn Sie in Deutschland ansässig sind). Wenn Sie nur Auftragsarbeiten im Zusammenhang mit Ihrem Open-Source-Projekt durchführen, können Sie Geld als (Einzel)Unternehmergesellschaft akzeptieren oder eine GmbH gründen.
 
-Wenn Sie Spenden für Ihr Open-Source-Projekt annehmen möchten, können Sie einen Spendenkanal einrichten (z.B. über PayPal oder Stripe), aber das Geld ist nicht steuerlich absetzbar. Es sei denn, über einen anerkannt gemeinnütziger Verein.
+Wenn Sie Spenden für Ihr Open-Source-Projekt annehmen möchten, können Sie einen Spendenkanal einrichten (z.B. über PayPal oder Stripe), aber das Geld ist nicht steuerlich absetzbar. Es sei denn, dieser Prozess läuft über einen anerkannten gemeinnützigen Verein.
 
 Viele Projekte wollen sich nicht die Mühe machen, einen gemeinnützigen Verein zu gründen, also finden sie stattdessen einen gemeinnützigen, steuerrechtlichen Sponsor. Ein solcher Sponsor nimmt Spenden in Ihrem Namen entgegen (teilweise im Austausch gegen einen prozentualen Anteil der Spende). [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects), [Open Collective](https://opencollective.com/opensource), und das deutsche [Center for the Cultivation of Technology](https://techcultivation.org/) sind Beispiele für Organisationen, die als steuerrechtliche Sponsoren für Open-Source-Projekte fungieren.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
 
-  Unser Ziel ist es, eine Infrastruktur bereitzustellen, die Communities nutzen können, um selbsttragend zu sein, und so ein Umfeld zu schaffen, in dem alle (Beitragende, Geldgeber\*innen und Sponsor\*innen) konkrete Vorteile daraus ziehen können.
+  Unser Ziel ist es, eine Infrastruktur bereitzustellen, die Communitys nutzen können, um selbsttragend zu sein, und so ein Umfeld zu schaffen, in dem alle (Beitragende, Geldgeber\*innen und Sponsor\*innen) konkrete Vorteile daraus ziehen können.
 
   _Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it._
 
diff --git a/_articles/de/legal.md b/_articles/de/legal.md
index 92fcdea794f..1539fd1f417 100644
--- a/_articles/de/legal.md
+++ b/_articles/de/legal.md
@@ -18,15 +18,15 @@ Ihr kreatives Werk mit der Welt zu teilen, ist eine anregende und erfüllende Er
 
 Danke, dass Sie fragen! Wenn Sie ein kreatives Werk erarbeiten (bspw. einen Text, ein Bild, oder eben Code) fällt es standardmäßig und automatisch unter das Urheberrecht. Das bedeutet, das von Rechts wegen Sie, der/die Autor\*in des Werkes bestimmen dürfen, was andere damit tun dürfen.
 
-Generell gilt, dass Niemand sonst Ihr Werk nutzen, kopieren, verbreiten, oder modifizieren darf, ohne Abmahnungen oder Klagen zu riskieren.
+Generell gilt, dass niemand sonst Ihr Werk nutzen, kopieren, verbreiten, oder modifizieren darf, ohne Abmahnungen oder Klagen zu riskieren.
 
-Open Source ist diesbezüglich natürlich anders, denn die/der Autor\*in erwartet ja, dass andere das Werk nutzen, modifizieren und teilen. Aber weil der Rechtsgrundsatz zunächst "exklusives Urheberrecht" lautet, benötigen Sie eine Lizenz, die klare Erlaubnisse verteilt.
+Open-Source ist diesbezüglich natürlich anders, denn die/der Autor\*in erwartet ja, dass andere das Werk nutzen, modifizieren und teilen. Aber weil der Rechtsgrundsatz zunächst "exklusives Urheberrecht" lautet, benötigen Sie eine Lizenz, die klare Erlaubnisse verteilt.
 
-Wenn Sie keine Open-Source-Lizenz einsetzen, erhält zudem jede\*r ebenfalls das ausschließliche Urheberrechts, der/die zu Ihrem Projekt beiträgt. Das würde bedeuten, dass wirklich Niemand die Beiträge nutzen, kopieren, verbreiten, oder modifizieren dürfte. Selbst Sie nicht.
+Wenn Sie keine Open-Source-Lizenz einsetzen, erhält zudem jede\*r ebenfalls das ausschließliche Urheberrechts, der/die zu Ihrem Projekt beiträgt. Das würde bedeuten, dass wirklich niemand die Beiträge nutzen, kopieren, verbreiten, oder modifizieren dürfte. Selbst Sie nicht.
 
 Schlussendlich könnte Ihr Projekt auch von anderen abhängen, die wiederum Lizenzbedingungen haben, derer Sie sich nicht bewusst waren. Die Gemeinschaft um Ihr Projekt und/oder Regelungen Ihrer Arbeitsstelle können auch bestimmte Open-Source-Lizenzen bedingen. Diese Fälle behandeln wir weiter unten.
 
-## Sind publizierte GitHub-Projekte Open Source?
+## 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.
 
@@ -34,7 +34,7 @@ Wenn Sie [ein neues Projekt auf GitHub erstellen](https://help.github.com/articl
 
 **Ihr GitHub-Projekt öffentlich zu machen, ist nicht dasselbe, wie eine Lizenz zu vergeben.** Öffentliche Projekte unterliegen [GitHubs Servicebedingungen](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), die Anderen das Ansehen und Forken Ihres Projektes erlauben. Dies bringt allerdings keine weiteren Erlaubnisse für Ihr Werk mit sich.
 
-Wenn Sie anderen die Nutzung, Verbreitung, Modifikation Ihres Projektes erlauben möchten, sowie zu ihm beizutragen, müssen Sie eine Open-Source-Lizenz vergeben. Beispielsweise darf legalerweise kein Mensch irgendeinen Teil Ihres GitHub-Projektes in seinen/ihren eigenen Code nutzen (selbst wenn es öffentlich ist) solange Sie nicht das Recht dazu explizit eingeräumt haben.
+Wenn Sie anderen die Nutzung, Verbreitung, Modifikation Ihres Projektes sowie das Beitragen erlauben möchten, müssen Sie eine Open-Source-Lizenz vergeben. Beispielsweise darf legalerweise kein Mensch irgendeinen Teil Ihres GitHub-Projektes in seinen/ihren eigenen Code nutzen (selbst wenn er öffentlich ist), solange Sie nicht das Recht dazu explizit eingeräumt haben.
 
 ## Sag mir nur kurz, wie ich mein Projekt schützen kann.
 
@@ -47,7 +47,7 @@ Wenn Sie ein neues Projekt auf GitHub anlegen, wird Ihnen [die Nutzung einer Liz
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
 
-  Eine Standardlizenz fasst für juristisch nicht vorgebildete Leute zusammen, was diese mit der Software tun können, und was nicht. Solange es nicht absolut nötig ist, sollten Sie eigene, modifizierte oder nicht-Standard-Klauseln vermeiden, denn diese behindern die Nachnutzung des Codes.
+  Eine Standardlizenz fasst für juristisch nicht vorgebildete Leute zusammen, was diese mit der Software tun können, und was nicht. Solange es nicht absolut nötig ist, sollten Sie eigene, modifizierte oder nicht standardisierte Klauseln vermeiden, denn diese behindern die Nachnutzung des Codes.
 
   _A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code._
 
@@ -69,10 +69,10 @@ Wenn allerdings irgendeine der Bibliotheken, von denen Ihr Projekt abhängt, ein
 Sie sollten auch die **Gemeinschaften** beachten, von denen Sie sich Nutzung und Beiträge Ihres Projektes erhoffen.
 
 * **Möchten Sie Ihr Projekt in anderen nachgenutzt wissen?** Am Besten nutzen Sie dann die populärste Lizenz im Umfeld ihres Projektes. Beispielsweise ist die [MIT-Lizenz](https://choosealicense.com/licenses/mit/) für [npm-Bibliotheken](https://libraries.io/npm) am populärsten.
-* **Soll Ihr Projekt auch große Firmen anziehen?** Große Firmen möchten sich vermutlich Patentrechte sichern, auch von allen Kontributor\*innen. Diesen Fall deckt [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) ab.
-* **Soll Ihr Projekt Kontributor\*innen anziehen, die ihre Beiträge aus Closed-Source-Software raushalten möchten?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) oder (wenn sie auch nicht zu Closed-Source-Diensten beitragen möchten) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) würden dazu passen.
+* **Soll Ihr Projekt auch große Firmen anziehen?** Große Firmen möchten sich vermutlich Patentrechte sichern, auch von allen Mitwirkenden. Diesen Fall deckt [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) ab.
+* **Soll Ihr Projekt Mitwirkende anziehen, die ihre Beiträge aus Closed-Source-Software raushalten möchten?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) oder (wenn sie auch nicht zu Closed-Source-Diensten beitragen möchten) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) würden dazu passen.
 
-Ihre **Firma** hat evtl. spezifische Lizenzanforderungen für ihre Open-Source-Projekte. Beispielsweise fordert sie eine permissive Lizenz, sodass sie Ihr Projekt in firmeneigener Closed-Source-Software nutzen kann. Oder, Ihre Firma könnte eine starke Copyleft-Lizenz und eine zusätzliche Kontributionsvereinbarung nutzen (siehe unten). Sodann kann nur sie und keine andere Firma, Ihr Projekt in einer Closed-Source-Software nutzen. Oder, Ihre Firma könnte spezielle Standards technischer Art haben, oder bezogen auf soziale Verantwortung, oder an Transparenz. All dies könnte eine spezifische Lizenzstrategie bedingen. Sprechen Sie mit der [Rechtsabteilung Ihrer Firma](#was-muss-die-rechtsabteilung-meines-unternehmens-wissen).
+Ihre **Firma** hat evtl. spezifische Lizenzanforderungen für ihre Open-Source-Projekte. Beispielsweise fordert sie eine permissive Lizenz, sodass sie Ihr Projekt in firmeneigener Closed-Source-Software nutzen kann. Oder Ihre Firma könnte eine starke Copyleft-Lizenz und eine zusätzliche Vereinbarung nutzen (siehe unten). Sodann kann nur sie und keine andere Firma, Ihr Projekt in einer Closed-Source-Software nutzen. Oder, Ihre Firma könnte spezielle Standards technischer Art haben, oder bezogen auf soziale Verantwortung, oder an Transparenz. All dies könnte eine spezifische Lizenzstrategie bedingen. Sprechen Sie mit der [Rechtsabteilung Ihrer Firma](#was-muss-die-rechtsabteilung-meines-unternehmens-wissen).
 
 Wenn Sie ein GitHub-Projekt erstellen, wird Ihnen die Lizenzwahl vorgeschlagen. Dabei eine der oben genannten Lizenzen auszuwählen, "open-sourced" ihr Projekt. Wenn Sie aus weiteren Möglichkeiten die richtige Lizenz finden möchten, bitte schauen Sie sich [choosealicense.com](https://choosealicense.com) an, auch wenn Ihr Projekt [keine Software](https://choosealicense.com/non-software/) an sich ist.
 
@@ -86,7 +86,7 @@ Zum Beispiel: Während des Wachstums Ihres Projektes bindet es weitere externe B
 
 **Die vorhandene Lizenz Ihres Projektes.** Wenn diese kompatibel mit der gewünschten neuen Lizenz ist, können Sie die neue einfach anfangen zu verwenden. Dies funktioniert, da eine Kompatibilität von Lizenz A mit Lizenz B bedeutet, dass Sie die Bedingungen von Lizenz A auch erfüllen, wenn Sie sich an Lizenz B halten (Umgekehrt gilt dies allerdings nicht notwendigerweise ebenso). Wenn Sie z.B. eine permissive Lizenz nutzen (wie MIT), können Sie auf eine Lizenz mit mehr Bedingungen wechseln, solange Sie die Kopie des MIT-Lizenztextes und die assoziierten Urheberrechtshinweise beibehalten (also die MIT-Minimalbedingungen erfüllen). Wenn allerdings Ihre aktuelle Lizenz nicht-permissiv ist (sondern z.B. copyleft, oder wenn Sie keine Lizenz nutzen), und Sie nicht der oder die einzige Urheberrechtsinhaber\*in sind, können Sie Ihr Projekt nicht einfach auf MIT umstellen. Im Kern bedeutet eine permissive Lizenz auch, dass ein\*e Urheberrechtsinhaber\*in schon im Vorhinein die Erlaubnis zur Lizenzänderung gegeben hat.
 
-**Die bestehenden Urheber\*innen Ihres Projekts.** Wenn Sie die oder der einzige Mitwirkende an Ihrem Projekt sind, dann sind entweder Sie oder Ihr Unternehmen der/die einzige Rechteinhaber\*in des Projekts. Sie können die Lizenz hinzufügen oder ändern, die Sie oder Ihr Unternehmen haben möchten. Andernfalls kann es andere Urheberrechtsinhaber\*innen geben, von denen Sie die Zustimmung benötigen, um die Lizenzen zu ändern. Wer sind sie? Menschen, die sich in Ihrem Projekt engagieren, kommen infrage. Aber in manchen Fällen werden die Verwertungsrechte von den Arbeitgeber\*innen dieser Leute gehalten, in anderen Fällen haben die Leute nur minimale Beiträge geleistet, aber es gibt keine exakte Regel, dass Beiträge unter einer bestimmten Anzahl von Code-Zeilen nicht dem Urheberrecht unterliegen. Was tun? Das kommt darauf an. Für ein relativ kleines und junges Projekt kann es möglich sein, alle existierenden Mitwirkenden dazu zu bringen, einer Lizenzänderung in einem Issue oder einem Pull-Antrag zuzustimmen. Für große und langlebige Projekte müssen Sie möglicherweise viele Mitwirkende und sogar deren Erben suchen. Mozilla brauchte Jahre (2001-2006), um Firefox, Thunderbird und verwandte Software neu zu lizenzieren.
+**Die bestehenden Urheber\*innen Ihres Projekts.** Wenn Sie die oder der einzige Mitwirkende an Ihrem Projekt sind, dann sind entweder Sie oder Ihr Unternehmen der/die einzige Rechteinhaber\*in des Projekts. Sie können die Lizenz hinzufügen oder ändern, die Sie oder Ihr Unternehmen haben möchten. Andernfalls kann es andere Urheberrechtsinhaber\*innen geben, von denen Sie die Zustimmung benötigen, um die Lizenzen zu ändern. Wer sind sie? Menschen, die sich in Ihrem Projekt engagieren, kommen hierfür infrage. Aber in manchen Fällen werden die Verwertungsrechte von den Arbeitgeber\*innen dieser Leute gehalten, in anderen Fällen haben die Leute nur minimale Beiträge geleistet, aber es gibt keine exakte Regel, dass Beiträge unter einer bestimmten Anzahl von Code-Zeilen nicht dem Urheberrecht unterliegen. Was tun? Das kommt darauf an. Für ein relativ kleines und junges Projekt kann es möglich sein, alle existierenden Mitwirkenden dazu zu bringen, einer Lizenzänderung in einem Issue oder einem Pull-Antrag zuzustimmen. Für große und langlebige Projekte müssen Sie möglicherweise viele Mitwirkende und sogar deren Erben suchen. Mozilla brauchte Jahre (2001-2006), um Firefox, Thunderbird und verwandte Software neu zu lizenzieren.
 
 Alternativ können Sie auch im Voraus bestimmte Lizenzänderungen unter bestimmten Bedingungen vereinbaren, die über die von Ihrer bestehenden Open-Source-Lizenz hinausgehen. Solche zusätzlichen Vereinbarungen, auch "contributor (license) agreements" genannt, werden unten weiter erklärt. Sie verschieben die Komplexität des Lizenzwechsels etwas: Sie brauchen mehr Hilfe von Ihren Anwälten im Vorfeld, und Sie werden trotzdem mit den Beteiligten Ihres Projekts kommunizieren wollen, wenn Sie eine Lizenzänderung durchführen.
 
@@ -94,14 +94,14 @@ Alternativ können Sie auch im Voraus bestimmte Lizenzänderungen unter bestimmt
 
 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).
 
-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 Kontributor\*innen mit einem Klick bestätigen, dass sie die erforderlichen Rechte innehaben, um zum Projekts im Rahmen dessen Open-Source-Lizenz beizutragen.
+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.
 
-Durch das Hinzufügen von "Papierkram", den einige für unnötig, schwer verständlich oder ungerecht halten (wenn der/die Empfänger\*in der Vereinbarung mehr Rechte erhält als die Mitwirkenden oder die Öffentlichkeit über die Open-Source-Lizenz des Projekts erhält), kann eine zusätzliche Kontributionsvereinbarung als unfreundlich für die Gemeinschaft des Projekts empfunden werden.
+Durch das Hinzufügen von "Papierkram", den einige für unnötig, schwer verständlich oder ungerecht halten (wenn der/die Empfänger\*in der Vereinbarung mehr Rechte als die Mitwirkenden oder die Öffentlichkeit über die Open-Source-Lizenz des Projekts erhält), kann eine zusätzliche Kontributionsvereinbarung als unfreundlich für die Gemeinschaft des Projekts empfunden werden.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
 
-    Wir haben den CLA für Node.js eliminiert, was die Eintrittsbarriere für Node.js-Mitwirkende senkt und damit die Basis der Kontributor\*innen verbreitert.
+    Wir haben die Kontributionsvereinbarung für Node.js entfernt, was die Eintrittsbarriere für Node.js-Mitwirkende senkt und damit die Basis der Mitwirkenden verbreitert.
 
     _We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base._
 
@@ -132,7 +132,7 @@ Ungeachtet der möglichen Vor- oder Nachteile sollten Sie es mitteilen, auch wen
 
 * **Geschäftsgeheimnisse:** Überlegen Sie, ob Teile des Projektes Ihres Unternehmen nicht der Öffentlichkeit zugänglich gemacht werden sollten. Solches Material können Sie aus Ihrem Projekt extrahieren, privat halten, und den Rest veröffentlichen.
 
-* **Patente:** Wenn Ihr Unternehmen ein Patent anmeldet, für das die Veröffentlichung Ihres Projekt eine [Offenlegung](https://en.wikipedia.org/wiki/Public_disclosure) darstellen würde, werden Sie evtl. gebeten zu warten (oder vielleicht wird das Unternehmen überdenken, ob die Patentanmeldung sinnvoll ist). Wenn Sie Beiträge von Mitarbeiter\*innen von Unternehmen mit großen Patentportfolios erwarten, könnte Ihre Rechtsabteilung sich eine Lizenz mit einer ausdrücklichen Patenterteilung von Kontributor\*innen wünschen (z.B. die Apache 2.0 oder GPLv3), oder eine zusätzliche Kontributionsvereinbarung (siehe oben).
+* **Patente:** Wenn Ihr Unternehmen ein Patent anmeldet, für das die Veröffentlichung Ihres Projektes eine [Offenlegung](https://en.wikipedia.org/wiki/Public_disclosure) darstellen würde, werden Sie evtl. gebeten zu warten (oder vielleicht wird das Unternehmen überdenken, ob die Patentanmeldung sinnvoll ist). Wenn Sie Beiträge von Mitarbeiter\*innen von Unternehmen mit großen Patentportfolios erwarten, könnte Ihre Rechtsabteilung sich eine Lizenz mit einer ausdrücklichen Patenterteilung von Mitwirkenden wünschen (z.B. die Apache 2.0 oder GPLv3), oder eine zusätzliche Kontributionsvereinbarung (siehe oben).
 
 * **Marken- und Warenzeichen:** Vergewissern Sie sich, dass Ihr Projektname [nicht im Widerspruch zu bestehenden Marken steht](../starting-a-project/#namenskonflikte-vermeiden). Wenn Sie Ihre eigenen Firmenmarken im Projekt verwenden, stellen Sie sicher, dass diese keine Konflikte verursachen. [FOSSmarks](http://fossmarks.org/) ist ein praktischer Leitfaden, um Marken im Rahmen von freien und Open-Source-Projekten zu verstehen.
 
@@ -140,9 +140,9 @@ Ungeachtet der möglichen Vor- oder Nachteile sollten Sie es mitteilen, auch wen
 
 Wenn Sie das erste Open-Source-Projekt Ihres Unternehmens veröffentlichen, ist das mehr als genug, um durchzukommen (aber keine Sorge, die meisten Projekte sollten keine größeren Bedenken aufwerfen).
 
-Längerfristig kann Ihre Rechtsabteilung mehr tun, um dem Unternehmen zu helfen, von seinem Engagement für Open Source zu profitieren, und auf der sicheren Seite zu bleiben:
+Längerfristig kann Ihre Rechtsabteilung mehr tun, um dem Unternehmen zu helfen, von seinem Engagement für Open-Source zu profitieren, und auf der sicheren Seite zu bleiben:
 
-* **Richtlinie für Beiträge von Angestellten:** Erwägen Sie die Entwicklung einer Unternehmenspolitik, die festlegt, wie Ihre Mitarbeiter\*innen zu Open-Source-Projekten beitragen. Eine klare Richtlinie verringert die Verwirrung unter Ihren Mitarbeiter\*innen und hilft ihnen dabei, Open-Source-Projekte im besten Interesse des Unternehmens zu unterstützen, sei es als Teil ihrer Arbeit oder in ihrer Freizeit. Ein gutes Beispiel von Rackspace ist deren [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Richtlinie für Beiträge von Angestellten:** Erwägen Sie die Entwicklung einer Unternehmenspolitik, die festlegt, wie Ihre Mitarbeiter\*innen zu Open-Source-Projekten beitragen. Eine klare Richtlinie verringert die Verwirrung unter Ihren Mitarbeiter\*innen und hilft ihnen dabei, Open-Source-Projekte im besten Interesse des Unternehmens zu unterstützen, sei es als Teil ihrer Arbeit oder in ihrer Freizeit. Ein gutes Beispiel von Rackspace ist deren [Model IP und Open-Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/de/metrics.md b/_articles/de/metrics.md
index 0ae3ec4be40..2fbe5e037d7 100644
--- a/_articles/de/metrics.md
+++ b/_articles/de/metrics.md
@@ -29,7 +29,7 @@ Mit mehr Informationen können Sie:
 >
 > Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
 
-Popularität ist nicht alles. Jeder kommt aus verschiedenen Gründen auf Open Source. Wenn Ihr Ziel als Open-Source-Betreuer\*in darin besteht, Ihre Arbeit zu präsentieren, Ihren Code transparent zu machen oder einfach nur um Spaß zu haben, sind Metriken für Sie möglicherweise nicht wichtig.
+Popularität ist nicht alles. Jeder kommt aus verschiedenen Gründen auf Open-Source. Wenn Ihr Ziel als Open-Source-Betreuer\*in darin besteht, Ihre Arbeit zu präsentieren, Ihren Code transparent zu machen oder einfach nur um Spaß zu haben, sind Metriken für Sie möglicherweise nicht wichtig.
 
 Wenn Sie daran interessiert sind, Ihr Projekt auf einer tieferen Ebene zu verstehen, lesen Sie weiter, um die Aktivitäten Ihres Projekts zu analysieren.
 
@@ -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-Stern](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://help.github.com/articles/about-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.
 
@@ -72,7 +72,7 @@ Wenn die Nutzung im Vergleich zur Anzahl der Personen, die Ihr Projekt entdecken
 
 Wenn Ihr Projekt z.B. auf der Titelseite von [Hacker News](https://news.ycombinator.com/) landet, werden Sie wahrscheinlich eine Steigerung der Entdeckungsrate (Traffic) sehen, aber eine niedrigere Konversionsrate, weil Sie alle auf Hacker News erreichen. Wenn Ihr Ruby-Projekt jedoch auf einer Ruby-Konferenz vorgestellt wird, ist es wahrscheinlicher, dass Sie eine hohe Konversionsrate von einem Zielpublikum sehen.
 
-Versuchen Sie herauszufinden woher Ihr Publikum kommt, und bitten Sie auf Ihrer Projektseite um Feedback der Besucher\*innen, um herauszufinden, welche dieser beiden Effekte Ihr Projekt betrifft.
+Versuchen Sie herauszufinden, woher Ihr Publikum kommt, und bitten Sie auf Ihrer Projektseite um Feedback der Besucher\*innen, um herauszufinden, welche dieser beiden Effekte Ihr Projekt betrifft.
 
 Sobald Sie wissen, dass Leute Ihr Projekt benutzen, möchten Sie vielleicht versuchen, herauszufinden, was sie damit machen. Bauen sie darauf auf, indem sie Ihren Code forken und Funktionen hinzufügen? Nutzen sie es für wissenschaftliche oder gewerbsmäßige Zwecke?
 
@@ -101,7 +101,7 @@ Beispiele für Community-Metriken, die Sie regelmäßig verfolgen möchten, sind
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
 
-  Open Source ist mehr als nur Code: Erfolgreiche Open-Source-Projekte beinhalten Code und Dokumentationsbeiträge sowie Gespräche über diese Änderungen.
+  Open-Source ist mehr als nur Code: Erfolgreiche Open-Source-Projekte beinhalten Code und Dokumentationsbeiträge sowie Gespräche über diese Änderungen.
 
   _Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes._
 
@@ -125,7 +125,7 @@ Sie können auch die Zeit messen, die benötigt wird, um zwischen den einzelnen
 * Die durchschnittliche Dauer, die ein Issue offen bleibt
 * Ob Issues durch PRs geschlossen werden
 * Ob veraltete Issues geschlossen werden
-* Die Durchschnittliche Zeit für den Merge eines Pull Requests
+* Die durchschnittliche Zeit für den Merge eines Pull Requests
 
 ## Nutzen Sie 📊 um die Helfer\*innen besser zu verstehen
 
diff --git a/_articles/de/starting-a-project.md b/_articles/de/starting-a-project.md
index c8fffb06f98..d281d3b9dd8 100644
--- a/_articles/de/starting-a-project.md
+++ b/_articles/de/starting-a-project.md
@@ -1,6 +1,6 @@
 ---
 lang: de
-title: Ein Open-Source-Projekt anfangen
+title: Ein Open-Source-Projekt starten
 description: Erfahren Sie mehr über die Open-Source-Welt und machen Sie sich bereit, Ihr eigenes Projekt zu starten.
 class: beginners
 order: 2
@@ -10,29 +10,29 @@ related:
   - building
 ---
 
-## Was ist Open Source, und warum?
+## Was ist Open-Source, und warum?
 
-Sie denken also über einen Sprung in die Open-Source-Welt nach? Herzlichen Glückwunsch, die Welt weiß Ihren Beitrag zu schätzen! Lassen Sie uns darüber sprechen, was Open Source ist und warum sich Leute dafür engagieren.
+Sie denken also über einen Sprung in die Open-Source-Welt nach? Herzlichen Glückwunsch, die Welt weiß Ihren Beitrag zu schätzen! Lassen Sie uns darüber sprechen, was Open-Source ist und warum sich Leute dafür engagieren.
 
-### Was genau bedeutet "Open Source"?
+### Was genau bedeutet "Open-Source"?
 
 Ein Open-Source-Projekt kann von **jedem Menschen für jeden Zweck verwendet, inspiziert, modifiziert und weiterverbreitet werden.** Diese Rechte werden [mittels einer Open-Source-Lizenz durchgesetzt](https://opensource.org/licenses).
 
-Open Source ist so mächtig, weil es Barrieren für Nutzung und Zusammenarbeit senkt und Personen somit ermöglicht, Ideen schneller zu verbreiten und Dinge schneller zu verbessern. Zudem ermöglicht es den Benutzer\*inn\*n, ihr eigenes Computing besser unter Kontrolle zu behalten, als mit proprietären Lösungen. Ein Unternehmen, das Open-Source-Software verwendet, kann beispielsweise jemanden einstellen, um maßgeschneiderte Verbesserungen an der Software vorzunehmen, anstatt von den Produktentscheidungen des Anbieters abhängig zu sein.
+Open-Source ist so mächtig, weil es Barrieren für Nutzung und Zusammenarbeit senkt und Personen somit ermöglicht, Ideen schneller zu verbreiten und Dinge schneller zu verbessern. Zudem ermöglicht es den Benutzer\*innen\*n, ihr eigenes Computing besser unter Kontrolle zu behalten, als mit proprietären Lösungen. Ein Unternehmen, das Open-Source-Software verwendet, kann beispielsweise jemanden einstellen, um maßgeschneiderte Verbesserungen an der Software vorzunehmen, anstatt von den Produktentscheidungen des Anbieters abhängig zu sein.
 
-_Freie Software_ meint dieselbe Art von Projekten wie _Open Source_. Der [Begriff](https://de.wikipedia.org/wiki/Free/Libre_Open_Source_Software) wird manchmal auch kombiniert mit "Freie/Libre und Open-Source-Software" (FOSS bzw. FLOSS). _Frei_ und _Libre_ meinen hierbei die Freiheit, nicht den [Preis](#bedeutet-open-source-auch-gratis).
+_Freie Software_ meint dieselbe Art von Projekten wie _Open-Source_. Der [Begriff](https://de.wikipedia.org/wiki/Free/Libre_Open_Source_Software) wird manchmal auch kombiniert mit "Freie/Libre und Open-Source-Software" (FOSS bzw. FLOSS). _Frei_ und _Libre_ meinen hierbei die Freiheit, nicht den [Preis](#bedeutet-open-source-auch-gratis).
 
-### Warum öffnen Menschen den Quellcode ihrer Software?
+### Warum veröffentlichen Menschen den Quellcode ihrer Software?
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
 
-  Die lohnenswertesten Erfahrungen, die ich bei der Verwendung von Open Source und der Zusammenarbeit daran mache, kommen von den Beziehungen, die ich mit anderen Entwickler\*innen aufbaue, die mit vielen der gleichen Probleme konfrontiert sind wie ich.
+  Die lohnenswertesten Erfahrungen, die ich bei der Verwendung von Open-Source und der Zusammenarbeit daran mache, kommen von den Beziehungen, die ich mit anderen Entwicklern\*innen aufbaue, die mit vielen der gleichen Probleme konfrontiert sind wie ich.
 
   _One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am._
 
   <p markdown="1" class="pquote-credit">
-— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+— @kentcdodds, ["How getting into Open-Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
   </p>
 </aside>
 
@@ -44,19 +44,19 @@ _Freie Software_ meint dieselbe Art von Projekten wie _Open Source_. Der [Begrif
 
 * **Transparenz:** In einem Open-Source-Projekt können Fehler oder Ungereimtheiten von jedem behoben werden. Transparenz ist sowohl für Regierungen in [Bulgarien](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) oder den [Vereinigten Staaten](https://web.archive.org/web/20180306072551/https://sourcecode.cio.gov/), für regulierte Industrien wie den Banken- oder Gesundheitssektor und für Sicherheitssoftware wie [Let's Encrypt](https://github.com/letsencrypt) gleichermaßen wichtig.
 
-Open Source ist nicht nur für Software, sondern auch für alle anderen Bereiche geeignet, von Datensätzen bis hin zu Büchern. Stöbern Sie durch [GitHub Explore](https://github.com/explore), um einen Eindruck der thematischen Breite von Open-Source-Projekten zu bekommen.
+Open-Source ist nicht nur für Software, sondern auch für alle anderen Bereiche geeignet, von Datensätzen bis hin zu Büchern. Stöbern Sie durch [GitHub Explore](https://github.com/explore), um einen Eindruck der thematischen Breite von Open-Source-Projekten zu bekommen.
 
-### Bedeutet Open Source auch "gratis"?
+### Bedeutet Open-Source auch "gratis"?
 
-Einer der größten Vorteile von Open Source ist, dass es kein Geld kostet. "Gratis" dagegen ist nur ein Nebenprodukt des Gesamtwertes.
+Einer der größten Vorteile von Open-Source ist, dass es kein Geld kostet. "Gratis" dagegen ist nur ein Nebenprodukt des Gesamtwertes.
 
-Weil [eine Open-Source-Lizenz bedingt](https://opensource.org/osd-annotated), dass jede\*r die Software nutzen, modifizieren, und weiterverbreiten darf (für nahezu jeden Zweck), nehmen die Projekte selbst meist kein Geld dafür. Wenn sie es täten, könnte jede\*r ganz legal die Projekte kopieren und die dann freie Version nutzen.
+Weil [eine Open-Source-Lizenz bedingt](https://opensource.org/osd-annotated), dass jeder die Software nutzen, modifizieren, und weiterverbreiten darf (für nahezu jeden Zweck), nehmen die Projekte selbst meist kein Geld dafür. Wenn sie es täten, könnte jeder ganz legal die Projekte kopieren und die dann freie Version nutzen.
 
 Daher sind die meisten Open-Source-Projekte kostenlos, aber das ist kein Teil der Open-Source-Definition. Es gibt für Open-Source-Projekte Möglichkeiten, sich indirekt bezahlen zu lassen (z.B. über Doppel-Lizenzierung oder eingeschränkte Funktionen) und dabei trotzdem die offizielle Definition von Open-Source weiterhin einzuhalten.
 
 ## Sollte ich mein eigenes Open-Source-Projekt starten?
 
-Die kurze Antwort ist "Ja!", denn egal wie das Ergebnis aussieht: Ein eigenes Projekt zu starten ist eine großartige Möglichkeit zu lernen, wie Open Source funktioniert.
+Die kurze Antwort ist "Ja!", denn egal wie das Ergebnis aussieht: Ein eigenes Projekt zu starten ist eine großartige Möglichkeit zu lernen, wie Open-Source funktioniert.
 
 Wenn Sie noch nie den Quellcode eines Projektes geöffnet haben, werden Sie vielleicht nervös darüber sein, was die Leute sagen werden, oder ob es jemandem auffallen wird. Mit diesen Bedenken sind Sie nicht allein!
 
@@ -66,7 +66,7 @@ Wenn Sie noch nicht überzeugt sind, nehmen Sie sich einen Moment Zeit, um darü
 
 ### Ihre Ziele definieren
 
-Ziele können Ihnen helfen, herauszufinden, woran Sie arbeiten sollen, was Sie ablehnen sollten und wo Sie Hilfe von anderen brauchen. Fragen Sie sich zuerst: _Warum öffne ich dieses Projekt?_
+Ziele können Ihnen helfen, herauszufinden, woran Sie arbeiten sollen, was Sie ablehnen sollten und wo Sie Hilfe von anderen brauchen. Fragen Sie sich zuerst: _Warum starte ich dieses Projekt?_
 
 Es gibt keine richtige Antwort auf diese Frage. Vielleicht haben Sie mehrere Ziele für ein einzelnes Projekt oder verschiedene Projekte mit unterschiedlichen Zielen.
 
@@ -88,7 +88,7 @@ Wenn Ihr Projekt wächst, braucht Ihre Community mehr als nur Code von Ihnen. Di
 
 Während die Zeit, die Sie für nicht-Programmieraufgaben aufwenden, von der Größe und dem Umfang Ihres Projekts abhängt, sollten Sie als Betreuer\*in darauf vorbereitet sein, diese selbst anzugehen oder jemanden zu finden, der Ihnen hilft.
 
-**Wenn Sie Teil eines Unternehmens sind, das ein Projekt öffnet**, stellen Sie sicher, dass Ihr Projekt über die internen Ressourcen verfügt, die es braucht, um zu gedeihen: Sie wollen klarstellen, wer für die Wartung des Projekts nach dem Start verantwortlich ist und wie Sie diese Aufgaben mit Ihrer Community teilen.
+**Wenn Sie Teil eines Unternehmens sind, das ein Projekt startet**, stellen Sie sicher, dass Ihr Projekt über die internen Ressourcen verfügt, die es braucht, um zu gedeihen: Sie wollen klarstellen, wer für die Wartung des Projekts nach dem Start verantwortlich ist und wie Sie diese Aufgaben mit Ihrer Community teilen.
 
 Wenn Sie ein dediziertes Budget oder Personal für Werbung, Betrieb und Wartung des Projekts benötigen, planen Sie dies frühzeitig.
 
@@ -106,30 +106,30 @@ Wenn Sie ein dediziertes Budget oder Personal für Werbung, Betrieb und Wartung
 
 ### Zu anderen Projekten beitragen
 
-Ist Ihr Ziel zu lernen, wie man mit anderen zusammenarbeitet oder wie Open Source funktioniert, sollten Sie in Erwägung ziehen zu einem bestehenden Projekt beizutragen. Dies kann so einfach sein wie die Korrektur von Tippfehlern oder das Aktualisieren der Dokumentation.
+Ist Ihr Ziel zu lernen, wie man mit anderen zusammenarbeitet oder wie Open-Source funktioniert, sollten Sie in Erwägung ziehen zu einem bestehenden Projekt beizutragen. Dies kann so einfach sein wie die Korrektur von Tippfehlern oder das Aktualisieren der Dokumentation.
 
-Wenn Sie sich nicht sicher sind, wie Sie als Mitwirkende\*r anfangen können, schauen Sie sich unseren Artikel "[Wie zu Open Source beitragen?](../how-to-contribute/)" an.
+Wenn Sie sich nicht sicher sind, wie Sie als Mitwirkende\*r anfangen können, schauen Sie sich unseren Artikel "[Wie zu Open-Source beitragen?](../how-to-contribute/)" an.
 
 ## Ein eigenes Open-Source-Projekt starten
 
 Es gibt keine perfekte Zeit, um Ihre Arbeit zu veröffentlichen. Sie können eine Idee, ein in Arbeit befindliches Projekt, oder ein Jahre altes Closed-Source-Projekt öffnen.
 
-Im Prinzip immer, wenn Sie sich sicher sind, dass andere Ihre Arbeit sehen sollten, und Feedback dazu geben.
+Im Allgemeinen können Sie sich für Open-Source entscheiden, wenn Sie möchten, dass andere Ihre Arbeit sehen sollen und bereit sind, Feedback zu akzeptieren.
 
-Unabhängig davon, in welcher Phase Sie sich für Open Source entscheiden, sollte jedes Projekt die folgende Dokumentation enthalten:
+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/)
 * [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 Erfahrungen in Ihrem Projekt bei.
+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.
 
 Wenn sich Ihr Projekt auf GitHub befindet, können Sie diese Dateien mit den empfohlenen Dateinamen in Ihrem Stammverzeichnis ablegen, damit GitHub sie erkennt und automatisch an Ihre Leser\*innen weitergeben kann.
 
 ### Eine Lizenz auswählen
 
-Eine Open-Source-Lizenz garantiert, dass andere Ihr Projekt ohne Nebenwirkungen nutzen, kopieren, modifizieren und wieder einbringen können und schützt Sie vor unangenehmen rechtlichen Situationen. **Wenn Sie ein Open-Source-Projekt starten, müssen Sie eine Lizenz angeben.**
+Eine Open-Source-Lizenz garantiert, dass andere Ihr Projekt ohne Nebenwirkungen nutzen, kopieren, modifizieren und wieder einbringen können. Außerdem schützt sie Sie vor unangenehmen rechtlichen Situationen. **Wenn Sie ein Open-Source-Projekt starten, müssen Sie eine Lizenz angeben.**
 
 Rechtsangelegenheiten sind kein Spaß. Die gute Nachricht ist, dass Sie eine bestehende Lizenz kopieren und in Ihr Repository einfügen können. Es dauert also nur eine Minute, Ihre harte Arbeit zu schützen.
 
@@ -148,8 +148,8 @@ READMEs erklären nicht nur, wie Sie Ihr Projekt verwenden, sondern auch, warum
 Versuchen Sie in Ihrer README folgende Fragen zu beantworten:
 
 * Was macht dieses Projekt?
-* Wozu nützt es?
-* Wie kann ich anfangen, es zu nutzen oder etwas beizutragen?
+* Warum ist es nützlich?
+* Wie kann ich es nutzen oder dazu etwas beitragen?
 * Wo wird mir geholfen, wenn ich Hilfe benötige?
 
 Sie können Ihre README verwenden, um andere Fragen zu beantworten: z.B. wie Sie mit Beiträgen handhaben, welche Ziele das Projekt verfolgt, oder wie es um Lizenzen und Zuschreibungen steht. Wenn Sie keine Beiträge annehmen wollen oder Ihr Projekt noch nicht produktionsreif ist, schreiben Sie auch diese Informationen auf.
@@ -174,7 +174,7 @@ Wenn Sie eine README-Datei im Hauptordner Ihres Projektes anlegen, zeigt GitHub
 
 ### Ihre Beitragsrichtlinien aufschreiben
 
-Eine CONTRIBUTING-Datei erklärt Ihrem Publikum, wie es zu Ihrem Projekt beitragen kann. Beispielsweise können Sie informieren über:
+Eine CONTRIBUTING-Datei erklärt Ihrem Publikum, wie es zu Ihrem Projekt beitragen kann. Folgende Informationen können darin beispielsweise enthalten sein:
 
 * Wie eine Fehlerbericht eingereicht werden kann (probieren Sie hierfür die [Issue- und Pull-Request-Vorlagen](https://github.com/blog/2111-issue-and-pull-request-templates))
 * Wie neue Funktionen vorgeschlagen werden sollten
@@ -183,11 +183,11 @@ Eine CONTRIBUTING-Datei erklärt Ihrem Publikum, wie es zu Ihrem Projekt beitrag
 
 Neben thematischen Details präsentiert die CONTRIBUTING-Datei auch Ihre Erwartungen an Beiträge, z.B:
 
-* Die Beitragsarten, die Sie gerne hätten
-* Ihre Planungen und Ziele für das Projekt
-* Wie Beitrags-Einreicher\*innen Sie kontaktieren sollten (oder auch nicht)
+* Wie Sie möchten, dass andere beitragen
+* Ihre Pläne und Ziele für das Projekt
+* Wie Mitwirkende Sie kontaktieren sollten (oder auch nicht)
 
-Mit einem warmen, freundlichen Ton und spezifischen Vorschlägen für Beiträge (wie z.B. "Dokumentationen verfassen" oder "eine Website erstellen") können Sie dazu beitragen, dass sich Neuankömmlinge willkommen und begeistert fühlen.
+Mit einem warmen, freundlichen Ton und spezifischen Vorschlägen für Beiträge (wie z.B. "Dokumentationen verfassen" oder "eine Website erstellen") können Sie dazu beitragen, dass sich Neuankömmlinge willkommen und wohlfühlen.
 
 Beispielsweise leitet [Active Admin](https://github.com/activeadmin/activeadmin/)  [ihre Beitragsrichtlinien](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) ein mit:
 
@@ -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, sodass mehr Leute sie bemerken. 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://help.github.com/articles/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)
 
@@ -219,11 +219,11 @@ Verlinken Sie Ihre CONTRIBUTING-Datei in Ihrer README, sodass mehr Leute sie bem
   </p>
 </aside>
 
-Letztendlich hilft ein Verhaltenskodex, Grundregeln für das Verhalten der Projektbeteiligten festzulegen. Insbesondere wenn Sie ein Open-Source-Projekt für eine Community oder ein Unternehmen starten. Ein Verhaltenskodex hilft Ihnen, ein gesundes, konstruktives Gemeinschaftsverhalten zu fördern, das Ihnen als Maintainer\*in Stress erspart.
+Letztendlich hilft ein Verhaltenskodex, Grundregeln für das Verhalten der Projektbeteiligten festzulegen - insbesondere wenn Sie ein Open-Source-Projekt für eine Community oder ein Unternehmen starten. Ein Verhaltenskodex hilft Ihnen, ein gesundes, konstruktives Gemeinschaftsverhalten zu fördern, das Ihnen als Maintainer\*in Stress erspart.
 
 Weitere Information finden Sie in unserer [Anleitung für Verhaltenskodizes](../code-of-conduct/).
 
-Neben der Klarstellung _welches_ Verhalten Sie von den Teilnehmer\*innen erwarten, beschreibt ein Verhaltenskodex auch, auf wen sich diese Erwartungen beziehen, wann sie gelten und was zu tun ist, wenn ein Verstoß vorliegt.
+Neben der Klarstellung, _welches_ Verhalten Sie von den Mitwirkenden erwarten, beschreibt ein Verhaltenskodex auch, auf wen sich diese Erwartungen beziehen, wann sie gelten und was zu tun ist, wenn ein Verstoß vorliegt.
 
 Ähnlich zu Open-Source-Lizenzen, kommen auch Standards für Verhaltenskodizes auf, sodass Sie keinen komplett eigenen schreiben müssen. Der [Contributor Covenant](https://contributor-covenant.org/) ist ein einsatzbereiter Verhaltenskodex, der von [über 40'000 Open-Source-Projekten](http://contributor-covenant.org/adopters/) verwendet wird, einschließlich Kubernetes, Rails und Swift. Egal welchen Text Sie nutzen, Sie sollten vorbereitet sein, ihn wenn nötig auch durchzusetzen.
 
@@ -256,16 +256,16 @@ Nutzen Sie die [WIPO Global Brand Database](http://www.wipo.int/branddb/en/), um
 
 Zum Schluss noch eine schnelle Google-Suche nach Ihrem Projektnamen: Werden die Leute Ihr Projekt leicht finden können, oder erscheint etwas anderes in den Suchergebnissen, das Sie nicht sehen möchten?
 
-### Auch den Schreib- und Programmierstil beeinflussen Ihre Marke!
+### Auch der Schreib- und Programmierstil beeinflussen Ihre Marke!
 
-Während der Lebenszeit Ihres Projektes werden Sie eine Menge schreiben: README, Anleitungen, Dokumentation, Antworten auf Anfragen, vielleicht sogar Newsletter an eine Mailingliste.
+Während Sie an dem Projekt arbeiten, werden Sie eine Menge schreiben: README, Anleitungen, Dokumentation, Antworten auf Anfragen, vielleicht sogar Newsletter an eine Mailingliste.
 
-Egal ob offizielle Dokumentation oder informelle E-Mail: Ihr Schreibstil ist ein Markenzeichen Ihres Projektes. Bedenken Sie, wie er bei Ihrem Publikum ankommt, und ob dies dem Tonfall entspricht, den Sie rüberbringen möchten.
+Egal ob offizielle Dokumentation oder informelle E-Mail: Ihr Schreibstil ist ein Markenzeichen Ihres Projektes. Bedenken Sie, wie er bei Ihrem Publikum ankommt, und ob dies dem Tonfall entspricht, den Sie herüberbringen möchten.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
 
-  Ich versuchte, an jeder Diskussion auf der Mailingliste teilzunehmen, in guter Manier, nett zu Leuten zu sein, ihre Anfragen ernst zu nehmen und Hilfe anzubieten. Nach einer Weile blieben Leuten einfach dabei, nicht nur um Fragen zu stellen, sondern auch um anderen zu antworten, und erfreulicherweise übernahmen sie meinen Schreibstil.
+  Ich habe versucht, an jeder Diskussion auf der Mailingliste teilzunehmen, in der Absicht, nett zu den Leuten zu sein, ihre Anfragen ernst zu nehmen und Hilfe anzubieten. Nach einer Weile blieben Leuten einfach dabei, nicht nur um Fragen zu stellen, sondern auch um anderen zu antworten, und erfreulicherweise übernahmen sie meinen Schreibstil.
 
   _I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style._
 
@@ -274,11 +274,11 @@ Egal ob offizielle Dokumentation oder informelle E-Mail: Ihr Schreibstil ist ein
   </p>
 </aside>
 
-Freundliche, [inklusive Sprache](https://fairlanguage.com/service/) kann Ihr Projekt einladender für neue Helfer\*innen machen. Bleiben Sie auch bei einfacher/leichter Sprache, denn nicht alle Ihrer Leser\*innen sind Muttersprachler\*innen.
+Freundliche, [inklusive Sprache](https://fairlanguage.com/service/) kann Ihr Projekt einladender für neue Mitwirkende machen. Bleiben Sie auch bei einfacher/leichter Sprache, denn nicht alle Ihrer Leser\*innen haben die Fähigkeit, komplizierte Formulierungen sofort zu verstehen.
 
-Neben Wortwahl und Schreibstil, wird auch Ihr Programmierstil Teil der Marke Ihres Projekts. [Angular](https://github.com/johnpapa/angular-styleguide) und [jQuery](https://contribute.jquery.org/style-guide/js/) beispielsweise haben strenge Richtlinien dafür.
+Neben Wortwahl und Schreibstil wird auch Ihr Programmierstil Teil der Marke Ihres Projekts. [Angular](https://github.com/johnpapa/angular-styleguide) und [jQuery](https://contribute.jquery.org/style-guide/js/) beispielsweise haben strenge Richtlinien dafür.
 
-Eine Stilrichtlinie ist nicht sofort zum Start Ihres Projekts nötig, und vielleicht genießen Sie es auch, unterschiedliche Programmierstile in Ihr Projekt zu integrieren. Allerdings sollten Sie davon ausgehen, dass verschiedene Schreib- und Programmierstile verschiedene Leute anziehen oder abstoßen. Die Weichen für die Gemeinschaft, die Sie letztendlich aufbauen möchten, werden schon in frühen Projektphasen gelegt.
+Eine Stilrichtlinie ist nicht sofort zum Start Ihres Projekts nötig, und vielleicht genießen Sie es auch, unterschiedliche Programmierstile in Ihr Projekt zu integrieren. Allerdings sollten Sie davon ausgehen, dass verschiedene Schreib- und Programmierstile verschiedene Leute anziehen oder abstoßen. Die Weichen für die Gemeinschaft, die Sie letztendlich aufbauen möchten, werden schon in frühen Projektphasen gestellt.
 
 ## Ihre Checkliste zur Startvorbreitung
 
@@ -289,7 +289,7 @@ Bereit für den Start Ihres Open-Source-Projektes? Diese Checkliste hilft Ihnen
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-    Das Projekt hat eine "LICENSE"-Datei mit einer Open-Source-Lizenz
+    Das Projekt hat eine LICENSE-Datei mit einer Open-Source-Lizenz
   </label>
 </div>
 
@@ -378,6 +378,6 @@ Wenn Sie als Firma oder Organisation arbeiten:
   </label>
 </div>
 
-## Sie haben's geschafft!
+## Geschafft!
 
-Herzlichen Glückwunsch zu Ihrem ersten Open-Source-Projekt! Egal was dabei rauskommt, öffentlich zu arbeiten, ist ein Geschenk an die Gemeinschaft. Sie erschaffen mit jedem Commit, jedem Kommentar und jedem Pull Request eine Gelegenheit für sich selbst und andere, etwas zu lernen und intellektuell zu wachsen.
+Herzlichen Glückwunsch zu Ihrem ersten Open-Source-Projekt! Egal was dabei rauskommt, öffentlich zu arbeiten, ist es ein Geschenk an die Gemeinschaft. Sie erschaffen mit jedem Commit, jedem Kommentar und jedem Pull Request eine Gelegenheit für sich selbst und andere, etwas zu lernen und intellektuell zu wachsen.

From 5ceab656bee5eb4865b98d04f0b5238d3987882d Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@gmail.com>
Date: Tue, 7 Mar 2023 12:24:14 -0500
Subject: [PATCH 433/749] update link

---
 _articles/de/legal.md | 4 ++--
 _articles/el/legal.md | 4 ++--
 _articles/es/legal.md | 4 ++--
 _articles/fa/legal.md | 4 ++--
 _articles/fr/legal.md | 4 ++--
 _articles/hu/legal.md | 4 ++--
 _articles/id/legal.md | 4 ++--
 _articles/ja/legal.md | 4 ++--
 _articles/ko/legal.md | 4 ++--
 _articles/legal.md    | 4 ++--
 _articles/ms/legal.md | 4 ++--
 _articles/nl/legal.md | 4 ++--
 _articles/pl/legal.md | 4 ++--
 _articles/pt/legal.md | 4 ++--
 _articles/ro/legal.md | 4 ++--
 _articles/ru/legal.md | 4 ++--
 _articles/ta/legal.md | 4 ++--
 _articles/tr/legal.md | 4 ++--
 18 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/_articles/de/legal.md b/_articles/de/legal.md
index 92fcdea794f..b34b63e7a0f 100644
--- a/_articles/de/legal.md
+++ b/_articles/de/legal.md
@@ -142,7 +142,7 @@ Wenn Sie das erste Open-Source-Projekt Ihres Unternehmens veröffentlichen, ist
 
 Längerfristig kann Ihre Rechtsabteilung mehr tun, um dem Unternehmen zu helfen, von seinem Engagement für Open Source zu profitieren, und auf der sicheren Seite zu bleiben:
 
-* **Richtlinie für Beiträge von Angestellten:** Erwägen Sie die Entwicklung einer Unternehmenspolitik, die festlegt, wie Ihre Mitarbeiter\*innen zu Open-Source-Projekten beitragen. Eine klare Richtlinie verringert die Verwirrung unter Ihren Mitarbeiter\*innen und hilft ihnen dabei, Open-Source-Projekte im besten Interesse des Unternehmens zu unterstützen, sei es als Teil ihrer Arbeit oder in ihrer Freizeit. Ein gutes Beispiel von Rackspace ist deren [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Richtlinie für Beiträge von Angestellten:** Erwägen Sie die Entwicklung einer Unternehmenspolitik, die festlegt, wie Ihre Mitarbeiter\*innen zu Open-Source-Projekten beitragen. Eine klare Richtlinie verringert die Verwirrung unter Ihren Mitarbeiter\*innen und hilft ihnen dabei, Open-Source-Projekte im besten Interesse des Unternehmens zu unterstützen, sei es als Teil ihrer Arbeit oder in ihrer Freizeit. Ein gutes Beispiel von Rackspace ist deren [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
@@ -152,7 +152,7 @@ Längerfristig kann Ihre Rechtsabteilung mehr tun, um dem Unternehmen zu helfen,
   _Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention._
 
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/el/legal.md b/_articles/el/legal.md
index 343f6320b98..e3766ee754a 100644
--- a/_articles/el/legal.md
+++ b/_articles/el/legal.md
@@ -134,13 +134,13 @@ related:
 
 Μακροπρόθεσμα, η νομική σας ομάδα μπορεί να κάνει περισσότερα για να βοηθήσει την εταιρεία να αποκομίσει περισσότερα από τη συμμετοχή της στον ανοικτό κώδικα και να παραμείνει ασφαλής:
 
-* **Πολιτικές συνεισφοράς των υπαλλήλων:** Εξετάστε το ενδεχόμενο να αναπτύξετε μια εταιρική πολιτική που να καθορίζει τον τρόπο με τον οποίο οι υπάλληλοί σας συνεισφέρουν σε πρότζεκτ ανοικτού κώδικα. Μια σαφής πολιτική θα μειώσει τη σύγχυση μεταξύ των υπαλλήλων σας και θα τους βοηθήσει να συνεισφέρουν σε πρότζεκτ ανοικτού κώδικα προς το συμφέρον της εταιρείας, είτε ως μέρος της εργασίας τους είτε στον ελεύθερο χρόνο τους. Ένα καλό παράδειγμα είναι η [Πρότυπη πολιτική IP και συνεισφοράς σε ανοικτό κώδικα](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) της Rackspace.
+* **Πολιτικές συνεισφοράς των υπαλλήλων:** Εξετάστε το ενδεχόμενο να αναπτύξετε μια εταιρική πολιτική που να καθορίζει τον τρόπο με τον οποίο οι υπάλληλοί σας συνεισφέρουν σε πρότζεκτ ανοικτού κώδικα. Μια σαφής πολιτική θα μειώσει τη σύγχυση μεταξύ των υπαλλήλων σας και θα τους βοηθήσει να συνεισφέρουν σε πρότζεκτ ανοικτού κώδικα προς το συμφέρον της εταιρείας, είτε ως μέρος της εργασίας τους είτε στον ελεύθερο χρόνο τους. Ένα καλό παράδειγμα είναι η [Πρότυπη πολιτική IP και συνεισφοράς σε ανοικτό κώδικα](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) της Rackspace.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
   Η εκμίσθωση της IP που σχετίζεται με μια επιδιόρθωση δημιουργεί τη βάση γνώσεων και τη φήμη του υπαλλήλου. Δείχνει ότι η εταιρεία επενδύει στην ανάπτυξη του συγκεκριμένου εργαζομένου και δημιουργεί μια αίσθηση ενδυνάμωσης και αυτονομίας. Όλα αυτά τα οφέλη οδηγούν επίσης σε υψηλότερο ηθικό και καλύτερη διατήρηση των εργαζομένων.
   <p markdown="1" class="pquote-credit">
-- @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+- @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/es/legal.md b/_articles/es/legal.md
index b7dfbe84e46..9ca5e57f0cd 100644
--- a/_articles/es/legal.md
+++ b/_articles/es/legal.md
@@ -139,13 +139,13 @@ Si est&aacute;s lanzando el primer proyecto de c&oacute;digo abierto de tu empre
 
 A largo plazo, tu equipo legal puede hacer m&aacute;s para ayudar a la empresa a obtener su participaci&oacute;n en c&oacute;digo abierto y mantenerse a salvo:
 
-* **Pol&iacute;ticas de contribuci&oacute;n de empleados:**  Considera la posibilidad de desarrollar una pol&iacute;tica corporativa que especifique c&oacute;mo sus empleados contribuyen a proyectos de c&oacute;digo abierto. Una pol&iacute;tica clara reducir&aacute; la confusi&oacute;n entre sus empleados y los ayudar&aacute; a contribuir a proyectos de c&oacute;digo abierto de la empresa, ya sea como parte de su trabajo o en su tiempo libre. Un buen ejemplo es Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Pol&iacute;ticas de contribuci&oacute;n de empleados:**  Considera la posibilidad de desarrollar una pol&iacute;tica corporativa que especifique c&oacute;mo sus empleados contribuyen a proyectos de c&oacute;digo abierto. Una pol&iacute;tica clara reducir&aacute; la confusi&oacute;n entre sus empleados y los ayudar&aacute; a contribuir a proyectos de c&oacute;digo abierto de la empresa, ya sea como parte de su trabajo o en su tiempo libre. Un buen ejemplo es Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
   Liberar el IP asociado con un parche genera la base de conocimientos y la reputaci&oacute;n del empleado. Demuestra que la empresa invierte en el desarrollo del empleado y crea un sentido de autonom&iacute;a y autonom&iacute;a. Todos estos beneficios tambi&eacute;n conducen a una mayor moral y mejor retenci&oacute;n de empleados.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
      </p>
 </aside>
 
diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index a5b666c58d8..6184e649a43 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -136,13 +136,13 @@ related:
 
 در بلند مدت، تیم حقوقی می‌تواند کمک بیشتری به شرکت کند تا از مشارکت خود در پروژه‌های متن باز بهره‌ی بیشتری ببرد و در امان بماند:
 
-* **سیاست های مربوط به مشارکت کارمندان:** سیاست‌هایی را تدوین کنید که مشخص سازد کارمندان شما در پروژه‌های متن باز چه نوع مشارکتی داشته باشند. داشتن سیاست‌های مشخص و واضح باعث کاهش سردرگمی در بین کارمندان و کمک به آن‌ها در مشارکت هرچه بهتر در پروژه‌های متن باز شرکت می‌شود؛ چه به عنوان بخشی از شغل آنها و چه به صورت فعالیت در اوقات فراغت‌شان. یک مثال خوب، [مدل‌های استاندارد و سیاست‌های همکاری در پروژه‌های متن باز](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) «Rackspace» است.
+* **سیاست های مربوط به مشارکت کارمندان:** سیاست‌هایی را تدوین کنید که مشخص سازد کارمندان شما در پروژه‌های متن باز چه نوع مشارکتی داشته باشند. داشتن سیاست‌های مشخص و واضح باعث کاهش سردرگمی در بین کارمندان و کمک به آن‌ها در مشارکت هرچه بهتر در پروژه‌های متن باز شرکت می‌شود؛ چه به عنوان بخشی از شغل آنها و چه به صورت فعالیت در اوقات فراغت‌شان. یک مثال خوب، [مدل‌های استاندارد و سیاست‌های همکاری در پروژه‌های متن باز](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) «Rackspace» است.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
   منتشر کردن شناسه همراه با مشخصات سازندۀ پَچ، باعث ایجاد اعتبار و شناخته شدن کارمند می‌شود. این کار نشان می‌دهد که شرکت در توسعۀ کارمندان سرمایه‌گذاری کرده و باعث به وجود آمدن حس اختیار و استقلال کارمندان می‌شود. تمامی این منفعت‌ها، منجر به روحیۀ بالاتر و حفظ بهتر کارمندان می‌شود.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index b68a74078bf..4eae765f715 100644
--- a/_articles/fr/legal.md
+++ b/_articles/fr/legal.md
@@ -133,13 +133,13 @@ Si vous publiez le premier projet open source de votre entreprise, ce qui préc
 
 À plus long terme, votre équipe juridique peut faire davantage pour aider l'entreprise à tirer le meilleur parti de son implication dans l'open source et à rester en sécurité:
 
-* **Règles de contribution des employés :** Envisagez de développer une politique d'entreprise qui spécifie comment vos employés contribuent aux projets open source. Une politique claire réduira la confusion parmi vos employés et les aidera à contribuer à des projets open source dans le meilleur intérêt de l'entreprise, que ce soit dans le cadre de leur travail ou pendant leur temps libre. Un bon exemple est Rackspace [Modèle IP et Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Règles de contribution des employés :** Envisagez de développer une politique d'entreprise qui spécifie comment vos employés contribuent aux projets open source. Une politique claire réduira la confusion parmi vos employés et les aidera à contribuer à des projets open source dans le meilleur intérêt de l'entreprise, que ce soit dans le cadre de leur travail ou pendant leur temps libre. Un bon exemple est Rackspace [Modèle IP et Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
   Laisser l'adresse IP associée à un correctif crée la base de connaissances et la réputation de l'employé. Cela montre que l'entreprise est investie dans le développement de cet employé et crée un sentiment d'autonomie et d'autonomie. Tous ces avantages mènent également à un meilleur moral et à une meilleure rétention des employés.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/hu/legal.md b/_articles/hu/legal.md
index 8edd7d79069..2762bf09b2d 100644
--- a/_articles/hu/legal.md
+++ b/_articles/hu/legal.md
@@ -134,13 +134,13 @@ Ha a céged első nyílt forráskódú projektjének publikálásán dolgozol, a
 
 Hosszabb távon a jogi csapat többet tehet azért, hogy segítsen a vállalatnak profitálni a nyílt forráskódból és közben biztonságban tudhassa magát:
 
-* **Munkavállalói hozzájárulás szabályozása:** Fontold meg olyan vállalati irányelv kidolgozását, amely meghatározza, hogy a munkavállalók hogyan járulnak hozzá a nyílt forráskódú projektekhez. Az egyértelmű szabályozás csökkenti a zavart az alkalmazottak körében, és segít abban, hogy a vállalat érdekeinek megfelelően járuljanak hozzá a nyílt forráskódú projektekhez, akár munkájuk részeként, akár szabadidejükben. Jó példa erre a Rackspace féle [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Munkavállalói hozzájárulás szabályozása:** Fontold meg olyan vállalati irányelv kidolgozását, amely meghatározza, hogy a munkavállalók hogyan járulnak hozzá a nyílt forráskódú projektekhez. Az egyértelmű szabályozás csökkenti a zavart az alkalmazottak körében, és segít abban, hogy a vállalat érdekeinek megfelelően járuljanak hozzá a nyílt forráskódú projektekhez, akár munkájuk részeként, akár szabadidejükben. Jó példa erre a Rackspace féle [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
   A (nyílt forráskódú) javítások (patch-ek) szellemi tulajdonának elengedése építi a munkavállaló tudásbázisát és hírnevét. Ez azt mutatja, hogy a vállalat befektet a munkavállaló fejlődésébe, valamint erősíti az önállóság és autonómia érzését. Mindezek magasabb morálhoz és a jobb munkavállalók megtartáshoz is vezetnek.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/id/legal.md b/_articles/id/legal.md
index a65220e36f4..d688d4cefc3 100644
--- a/_articles/id/legal.md
+++ b/_articles/id/legal.md
@@ -133,13 +133,13 @@ Jika Anda merilis proyek open source perusahaan Anda pertama kalinya, informasi
 
 Dalam jangka panjang, tim hukum Anda bisa melakukan lebih banyak lagi dengan membantu perusahaan untuk mendapatkan lebih banyak dari keterlibatannya pada open source:
 
-* **Kebijakan kontribusi karyawan:** Pertimbangkan untuk mengembangkan kebijakan perusahaan yang menentukan bagaimana karyawan berkontribusi pada proyek open source. Sebuah kebijakan yang jelas akan mengurangi kebingungan  pada karyawan Anda dan membantu mereka untuk berkontribusi pada proyek open source yang penting bagi perusahaan, baik sebagai bagian dari pekerjaan mereka atau dimasa senggang mereka. Sebuah contoh bagus adalah [Model IP dan Kebijakan Kontribusi Open Source](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) milik Rackspace.
+* **Kebijakan kontribusi karyawan:** Pertimbangkan untuk mengembangkan kebijakan perusahaan yang menentukan bagaimana karyawan berkontribusi pada proyek open source. Sebuah kebijakan yang jelas akan mengurangi kebingungan  pada karyawan Anda dan membantu mereka untuk berkontribusi pada proyek open source yang penting bagi perusahaan, baik sebagai bagian dari pekerjaan mereka atau dimasa senggang mereka. Sebuah contoh bagus adalah [Model IP dan Kebijakan Kontribusi Open Source](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) milik Rackspace.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
   Membiarkan IP yang terkait dengan patch membangun basis pengetahuan dan reputasi karyawan. Ini menunjukkan bahwa perusahaan menekankan pengembangan karyawan dan menciptakan rasa pemberdayaan dan otonomi. Semua manfaat ini juga menyebabkan semangat kerja lebih tinggi dan retensi karyawan yang lebih baik.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md
index 9e150ad769a..4d9ec76ae28 100644
--- a/_articles/ja/legal.md
+++ b/_articles/ja/legal.md
@@ -134,13 +134,13 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
 
 長期的には、法務部門は企業がオープンソースに関わることでより多くのことを安全に獲得する助けとなります：
 
-* **従業員のコントリビュートポリシー：** 従業員がどのようにオープンソースにコントリビュートするかを定めた社内規約を作ることを検討しましょう。明確な規約を作ることで従業員同士の混乱も減りますし、従業員に対して企業が最も関心のあるオープンソースプロジェクトに業務の一環であれ空き時間でコントリビュートする手助けにもなります。 Rackspace の [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) が良い例です。
+* **従業員のコントリビュートポリシー：** 従業員がどのようにオープンソースにコントリビュートするかを定めた社内規約を作ることを検討しましょう。明確な規約を作ることで従業員同士の混乱も減りますし、従業員に対して企業が最も関心のあるオープンソースプロジェクトに業務の一環であれ空き時間でコントリビュートする手助けにもなります。 Rackspace の [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) が良い例です。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
   パッチに関連した知的財産を手放すことで従業員の知識ベースと名声を築く事ができます。そうすることで、その企業は従業員の能力を高め、自律的に働くことに投資していることを示すことができます。こういったメリットは、モラルの向上や従業員の維持にも繋がります。
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index e23bab5555a..37bc21b9f71 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -133,13 +133,13 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
 
 장기적으로, 법률팀은 오픈소스에 대한 참여를 통해 더 많은 것을 얻고, 안전을 유지할 수 있도록 더 많은 일을 할 수 있습니다:
 
-* **직원 기여 정책:** 직원이 오픈소스 프로젝트에 기여하는 방법을 지정하는 기업 정책을 개발하는 것을 고려하십시오. 분명한 정책은 직원들 사이의 혼란을 줄이고 작업의 일부 또는 자유 시간에 상관없이, 회사의 이익을 최대한 활용하여 오픈소스 프로젝트에 기여할 수 있도록 지원합니다. 좋은 예시는 Rackspace의 [모델 IP 및 오픈소스 기여 정책](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)입니다.
+* **직원 기여 정책:** 직원이 오픈소스 프로젝트에 기여하는 방법을 지정하는 기업 정책을 개발하는 것을 고려하십시오. 분명한 정책은 직원들 사이의 혼란을 줄이고 작업의 일부 또는 자유 시간에 상관없이, 회사의 이익을 최대한 활용하여 오픈소스 프로젝트에 기여할 수 있도록 지원합니다. 좋은 예시는 Rackspace의 [모델 IP 및 오픈소스 기여 정책](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)입니다.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
   Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["모델 IP 및 공개 소스 기여 정책"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["모델 IP 및 공개 소스 기여 정책"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/legal.md b/_articles/legal.md
index 312c51dfa1a..8adc3897659 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -134,13 +134,13 @@ If you're releasing your company's first open source project, the above is more
 
 Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
 
-* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
   Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/ms/legal.md b/_articles/ms/legal.md
index 6bccef8e1d6..0881810920f 100644
--- a/_articles/ms/legal.md
+++ b/_articles/ms/legal.md
@@ -134,13 +134,13 @@ Sekiranya anda melepaskan projek sumber terbuka pertama syarikat anda, perkara d
 
 Jangka panjang, pasukan undang-undang anda boleh melakukan lebih banyak perkara untuk membantu syarikat mendapatkan lebih banyak hasil daripada penglibatannya dalam sumber terbuka, dan tetap selamat:
 
-* **Dasar sumbangan pekerja:** Pertimbangkan untuk mengembangkan polisi korporat yang menentukan bagaimana pekerja anda menyumbang untuk projek sumber terbuka. Dasar yang jelas akan mengurangkan kekeliruan di kalangan pekerja anda dan membantu mereka menyumbang kepada projek sumber terbuka demi kepentingan syarikat, sama ada sebagai sebahagian daripada pekerjaan mereka atau pada masa lapang. Contoh yang baik ialah Rackspace [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Dasar sumbangan pekerja:** Pertimbangkan untuk mengembangkan polisi korporat yang menentukan bagaimana pekerja anda menyumbang untuk projek sumber terbuka. Dasar yang jelas akan mengurangkan kekeliruan di kalangan pekerja anda dan membantu mereka menyumbang kepada projek sumber terbuka demi kepentingan syarikat, sama ada sebagai sebahagian daripada pekerjaan mereka atau pada masa lapang. Contoh yang baik ialah Rackspace [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
   Membiarkan IP yang berkaitan dengan patch membina asas pengetahuan dan reputasi pekerja. Ini menunjukkan bahawa syarikat dilaburkan dalam pengembangan pekerja tersebut dan mewujudkan rasa pemberdayaan dan autonomi. Semua faedah ini juga membawa kepada semangat kerja yang lebih tinggi dan pengekalan pekerja yang lebih baik.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
index 1b06118b779..67be0267f2b 100644
--- a/_articles/nl/legal.md
+++ b/_articles/nl/legal.md
@@ -139,7 +139,7 @@ Als u het eerste open source-project van uw bedrijf uitbrengt, is het bovenstaan
 
 Op de langere termijn kan uw juridische team meer doen om het bedrijf te helpen meer uit zijn betrokkenheid bij open source te halen en veilig te blijven:
 
-* **Beleid inzake werknemersbijdragen:** Overweeg om een ​​bedrijfsbeleid te ontwikkelen dat aangeeft hoe uw werknemers bijdragen aan open source-projecten. Een duidelijk beleid zal de verwarring onder uw medewerkers verminderen en hen helpen bij te dragen aan open source-projecten in het belang van het bedrijf, zowel als onderdeel van hun baan als in hun vrije tijd. Een goed voorbeeld is Rackspace's [Model IP and Open Source Contribution Policy] (https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Beleid inzake werknemersbijdragen:** Overweeg om een ​​bedrijfsbeleid te ontwikkelen dat aangeeft hoe uw werknemers bijdragen aan open source-projecten. Een duidelijk beleid zal de verwarring onder uw medewerkers verminderen en hen helpen bij te dragen aan open source-projecten in het belang van het bedrijf, zowel als onderdeel van hun baan als in hun vrije tijd. Een goed voorbeeld is Rackspace's [Model IP and Open Source Contribution Policy] (https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
@@ -148,7 +148,7 @@ Op de langere termijn kan uw juridische team meer doen om het bedrijf te helpen
   _Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention._
 
   <p markdown="1" class="pquote-credit">
-— @vanl, ["Een modelbeleid inzake intellectuele eigendom en bijdragen aan open source"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["Een modelbeleid inzake intellectuele eigendom en bijdragen aan open source"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/pl/legal.md b/_articles/pl/legal.md
index 8de980aee30..20e7a4f713d 100644
--- a/_articles/pl/legal.md
+++ b/_articles/pl/legal.md
@@ -138,7 +138,7 @@ Jeśli wypuszczasz pierwszy projekt open source swojej firmy, powyższe rozwiąz
 
 W dłuższej perspektywie Twój zespół prawny może zrobić więcej, aby pomóc firmie lepiej wykorzystać zaangażowanie w open source i zachować bezpieczeństwo:
 
-* **Zasady dotyczące składek pracowniczych:** Rozważ opracowanie zasad korporacyjnych, które określają, w jaki sposób pracownicy przyczyniają się do projektów typu open source. Jasna polityka zmniejszy zamieszanie wśród pracowników i pomoże im przyczyniać się do projektów typu open source w najlepszym interesie firmy, zarówno w ramach pracy, jak i czasu wolnego. Dobrym przykładem jest [Model IP i Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Zasady dotyczące składek pracowniczych:** Rozważ opracowanie zasad korporacyjnych, które określają, w jaki sposób pracownicy przyczyniają się do projektów typu open source. Jasna polityka zmniejszy zamieszanie wśród pracowników i pomoże im przyczyniać się do projektów typu open source w najlepszym interesie firmy, zarówno w ramach pracy, jak i czasu wolnego. Dobrym przykładem jest [Model IP i Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
@@ -146,7 +146,7 @@ W dłuższej perspektywie Twój zespół prawny może zrobić więcej, aby pomó
   Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
   </i>
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/pt/legal.md b/_articles/pt/legal.md
index 3aa0babf75e..be1934460d1 100644
--- a/_articles/pt/legal.md
+++ b/_articles/pt/legal.md
@@ -134,13 +134,13 @@ Se você está lançando o primeiro projeto open source da sua empresa, as dicas
 
 A longo prazo, sua equipe jurídica pode fazer mais para ajudar a empresa a obter mais de seu envolvimento em open source e permanecer segura:
 
-* **Políticas de contribuição para funcionários:** Considere desenvolver uma política corporativa que especifique como seus funcionários contribuem para projetos open source. Uma política clara reduzirá a confusão entre seus funcionários e os ajudará a contribuir para projetos open source no melhor interesse da empresa, seja como parte de seus trabalhos ou em seu tempo livre. Um bom exemplo é o  [Modelo de propriedade intelectual e políticas de contribuição para projetos abertos](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) da Rackspace.
+* **Políticas de contribuição para funcionários:** Considere desenvolver uma política corporativa que especifique como seus funcionários contribuem para projetos open source. Uma política clara reduzirá a confusão entre seus funcionários e os ajudará a contribuir para projetos open source no melhor interesse da empresa, seja como parte de seus trabalhos ou em seu tempo livre. Um bom exemplo é o  [Modelo de propriedade intelectual e políticas de contribuição para projetos abertos](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) da Rackspace.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
   Liberar a propriedade intelectual associada com um patch constrói a base de conhecimento do funcionário e sua reputação. Mostra que a empresa é empenhada no desenvolvimento desse funcionário e cria um senso de emponderamento e autonomia. Todos esses benefícios também levam a uma maior moral e uma melhor retenção de funcionários.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/ro/legal.md b/_articles/ro/legal.md
index 0dcf7c8dcec..14a1c197dab 100644
--- a/_articles/ro/legal.md
+++ b/_articles/ro/legal.md
@@ -147,7 +147,7 @@ Dacă lansezi primul proiect cu sursă deschisă al companiei, ce este scris mai
 
 Pe termen lung, echipa voastră juridică poate face mai mult pentru a ajuta compania să obțină mai mult din implicarea ei în open source, și pentru a rămâne în siguranță:
 
-* **Politici de contribuție a angajaților:** Consideră dezvoltarea unei politici corporative care specifică felul în care angajații dumneavoastră contribuie la proiecte cu sursă deschisă. O politică clară va reduce confuzia în rândul angajaților dumneavoastră și îi va ajuta să contribuie la proiecte cu sursă deschisă în interesul companiei, fie ca parte a locurilor lor de muncă sau în timpul lor liber. Un exemplu este [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) al Rackspace.
+* **Politici de contribuție a angajaților:** Consideră dezvoltarea unei politici corporative care specifică felul în care angajații dumneavoastră contribuie la proiecte cu sursă deschisă. O politică clară va reduce confuzia în rândul angajaților dumneavoastră și îi va ajuta să contribuie la proiecte cu sursă deschisă în interesul companiei, fie ca parte a locurilor lor de muncă sau în timpul lor liber. Un exemplu este [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) al Rackspace.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
@@ -160,7 +160,7 @@ Pe termen lung, echipa voastră juridică poate face mai mult pentru a ajuta com
     </em>
   </p>
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md
index 00cd216088c..b010b6a7046 100644
--- a/_articles/ru/legal.md
+++ b/_articles/ru/legal.md
@@ -134,13 +134,13 @@ related:
 
 В долгосрочной перспективе ваша команда юристов может сделать больше, чтобы помочь компании получить больше от своего участия в проектах с открытым исходным кодом и оставаться в безопасности:
 
-* **Политики участия сотрудников:** Рассмотрите возможность разработки корпоративной политики, определяющей, как ваши сотрудники вносят вклад в проекты с открытым исходным кодом. Четкая политика уменьшит путаницу среди ваших сотрудников и поможет им внести свой вклад в проекты с открытым исходным кодом в интересах компании, будь то в рамках своей работы или в свободное время. Хорошим примером является политика Rackspace [Типовая политика в отношении интеллектуальной собственности и открытого исходного кода](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Политики участия сотрудников:** Рассмотрите возможность разработки корпоративной политики, определяющей, как ваши сотрудники вносят вклад в проекты с открытым исходным кодом. Четкая политика уменьшит путаницу среди ваших сотрудников и поможет им внести свой вклад в проекты с открытым исходным кодом в интересах компании, будь то в рамках своей работы или в свободное время. Хорошим примером является политика Rackspace [Типовая политика в отношении интеллектуальной собственности и открытого исходного кода](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
 Предоставление IP-адреса, связанного с патчем, создает базу знаний и репутацию сотрудника. Это показывает, что компания инвестирует в развитие этого сотрудника, и создает ощущение полномочий и автономии. Все эти преимущества также приводят к повышению морального духа и лучшему удержанию сотрудников.  
 <p markdown="1" class="pquote-credit">
-— @vanl, ["Типовая политика в отношении интеллектуальной собственности и открытого исходного кода"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["Типовая политика в отношении интеллектуальной собственности и открытого исходного кода"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/ta/legal.md b/_articles/ta/legal.md
index 5807627bea6..57a0ca8ce29 100644
--- a/_articles/ta/legal.md
+++ b/_articles/ta/legal.md
@@ -133,13 +133,13 @@ Yஉங்கள் திட்டம் **சார்புகள்** கொ
 
 நீண்ட காலமாக, உங்கள் சட்ட குழு நிறுவனம், திறந்த மூலத்தில் அதன் ஈடுபாட்டிலிருந்து நிறுவனத்தின் உதவியை அதிகரிக்க உதவ முடியும், மேலும் பாதுகாப்பாக இருக்கவும்:
 
-* **Eபணியாளர் பங்களிப்பு கொள்கைகள்:** உங்கள் பணியாளர்கள் மூல திட்டங்களை திறக்க எப்படி உதவுகிறது என்பதைக் குறிப்பிடும் ஒரு பெருநிறுவனக் கொள்கையை உருவாக்குங்கள். ஒரு தெளிவான கொள்கை உங்கள் ஊழியர்களிடையே குழப்பத்தை குறைக்கும் மற்றும் நிறுவனங்களின் சிறந்த வட்டி, அவர்களது வேலைகள் அல்லது தங்களின் இலவச நேரத்திலோ, மூல திட்டங்களை திறக்க உதவுகிறது. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Eபணியாளர் பங்களிப்பு கொள்கைகள்:** உங்கள் பணியாளர்கள் மூல திட்டங்களை திறக்க எப்படி உதவுகிறது என்பதைக் குறிப்பிடும் ஒரு பெருநிறுவனக் கொள்கையை உருவாக்குங்கள். ஒரு தெளிவான கொள்கை உங்கள் ஊழியர்களிடையே குழப்பத்தை குறைக்கும் மற்றும் நிறுவனங்களின் சிறந்த வட்டி, அவர்களது வேலைகள் அல்லது தங்களின் இலவச நேரத்திலோ, மூல திட்டங்களை திறக்க உதவுகிறது. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
   ஒரு இணைப்புடன் தொடர்புடைய ஐபி முகவரியை ஊழியர் அறிவுத் தளம் மற்றும் புகழ் உருவாக்குகிறது. அந்த நிறுவனம் அந்த ஊழியரின் வளர்ச்சியில் முதலீடு செய்யப்பட்டு, அதிகாரமளித்தல் மற்றும் சுயாட்சியை உருவாக்குவதற்கான உணர்வுகளை உருவாக்குகிறது என்பதை இது காட்டுகிறது. இந்த நன்மைகள் அனைத்தும் உயர்ந்த மன வலிமையயும், சிறந்த பணியாளருக்கும் தக்கவைக்கும்.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["மாதிரி ஐபி மற்றும் திறந்த மூல பங்களிப்பு கொள்கை"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["மாதிரி ஐபி மற்றும் திறந்த மூல பங்களிப்பு கொள்கை"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index 9fd2f1a1c94..0a63171ce68 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -134,13 +134,13 @@ Daha iyi veya daha kötüsü, kişisel bir proje olsa bile, onlara bildirmeyi d
 
 Daha uzun vadede hukuk ekibiniz, şirketin açık kaynaklara katılımından daha fazlasını elde etmesi ve güvende kalması için daha fazlasını yapabilir:
 
-* **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)'dır.
+* **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)'dır.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
   Bir yama ile ilgili IP'nin serbest bırakılması, çalışanın bilgi birikimini ve itibarını arttırır. Şirketin bu çalışanın gelişimine yatırım yaptığını ve bir güçlendirme ve özerklik duygusu yarattığını göstermektedir. Tüm bu faydalar ayrıca daha yüksek moral ve daha iyi bir çalışanın kalmasına yol açmaktadır.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["Bir Model IP ve Açık Kaynak Katkı Politikası"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["Bir Model IP ve Açık Kaynak Katkı Politikası"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 

From c36b0d279632a4b26a1dd66ee9f80513cfba0d98 Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@gmail.com>
Date: Tue, 7 Mar 2023 12:32:21 -0500
Subject: [PATCH 434/749] update link

---
 _articles/nl/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/nl/starting-a-project.md b/_articles/nl/starting-a-project.md
index ec42aa7bd21..6cb613a87ac 100644
--- a/_articles/nl/starting-a-project.md
+++ b/_articles/nl/starting-a-project.md
@@ -16,7 +16,7 @@ Dus je denkt erover om aan de slag te gaan met open source? Gefeliciteerd! De we
 
 ### Wat betekent "open source"?
 
-Als een project open source is, betekent dit **dat iedereen vrij is om uw project voor elk doel te gebruiken, bestuderen, wijzigen en distribueren.** Deze machtigingen worden afgedwongen via [een open source-licentie](https://opensource.org/licenties).
+Als een project open source is, betekent dit **dat iedereen vrij is om uw project voor elk doel te gebruiken, bestuderen, wijzigen en distribueren.** Deze machtigingen worden afgedwongen via [een open source-licentie](https://opensource.org/licenses).
 
 Open source is krachtig omdat het de barrières voor acceptatie en samenwerking verlaagt, waardoor mensen projecten snel kunnen verspreiden en verbeteren. Ook omdat het gebruikers de mogelijkheid geeft om hun eigen computergebruik te beheersen, in vergelijking met closed source. Een bedrijf dat open source software gebruikt, heeft bijvoorbeeld de mogelijkheid om iemand in te huren om aangepaste verbeteringen aan de software aan te brengen, in plaats van uitsluitend te vertrouwen op de productbeslissingen van een closed source-leverancier.
 

From 68dc43d2678cda2a7ccf054717e1af27d21aca9c Mon Sep 17 00:00:00 2001
From: Brandonawn <abibangbrandon855@gmail.com>
Date: Wed, 8 Mar 2023 12:26:06 +0100
Subject: [PATCH 435/749] Fix editorial inconsistencies or inaccuracies

---
 CODE_OF_CONDUCT.md | 8 ++++----
 CONTRIBUTING.md    | 2 +-
 README.md          | 5 ++---
 3 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index 419c8a40892..01e0b2a361f 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -26,7 +26,7 @@ Examples of unacceptable behavior by participants include:
 advances
 * Trolling, insulting/derogatory comments, and personal or political attacks
 * Public or private harassment
-* Publishing others' private information, such as a physical or electronic
+* Publishing others' private information, such as physical or electronic
   address, without explicit permission
 * Other conduct which could reasonably be considered inappropriate in a
   professional setting
@@ -45,9 +45,9 @@ threatening, offensive, or harmful.
 
 ## Scope
 
-This Code of Conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community. Examples of
-representing a project or community include using an official project e-mail
+This Code of Conduct applies both within project spaces and in public spaces.
+When an individual is representing the project or its community. Examples of
+representing a project or community includes using an official project e-mail
 address, posting via an official social media account, or acting as an appointed
 representative at an online or offline event. Representation of a project may be
 further defined and clarified by project maintainers.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d4c334a2ac6..05e35bdc5e6 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -4,7 +4,7 @@ layout: default
 
 # Contributing to Open Source Guides
 
-Thanks for checking out the Open Source Guides! We're excited to hear and learn from you. Your experiences will benefit others who read and use these guides.
+Thank you for checking out the Open Source Guides! We're excited to hear and learn from you. Your experiences will benefit others who read and use these guides.
 
 We've put together the following guidelines to help you figure out where you can best be helpful.
 
diff --git a/README.md b/README.md
index df7704a20fc..75b29760a22 100644
--- a/README.md
+++ b/README.md
@@ -1,11 +1,10 @@
 # Open Source Guides
-
 [![Build Status](https://github.com/github/opensource.guide/workflows/GitHub%20Actions%20CI/badge.svg)](https://github.com/github/opensource.guide/actions)
 
-Open Source Guides (https://opensource.guide/) are a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project.
+Open Source Guides (https://opensource.guide/) is a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open-source project.
 
 ## Background
-Open Source Guides were created and are curated by GitHub, along with input from outside community reviewers, but they are not exclusive to GitHub products. One reason we started this project is because we felt that there weren't enough resources for people creating open source projects.
+Open Source Guides were created and are curated by GitHub, along with input from outside community reviewers, but they are not exclusive to GitHub products. One reason we started this project is that we felt that there weren't enough resources for people creating open-source projects.
 
 Our goal was to aggregate community best practices, *not* what GitHub (or any other individual or entity) thinks is best. Therefore, we used examples and quotations from others to illustrate our points.
 

From 0f0ba2f52a041b08d16f40190a8e41e62b0e5cfd Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Thu, 9 Mar 2023 20:11:30 +0100
Subject: [PATCH 436/749] Apply suggestions from code review

---
 CODE_OF_CONDUCT.md | 4 ++--
 CONTRIBUTING.md    | 2 +-
 README.md          | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index 01e0b2a361f..25a53c4ea47 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -45,8 +45,8 @@ threatening, offensive, or harmful.
 
 ## Scope
 
-This Code of Conduct applies both within project spaces and in public spaces.
-When an individual is representing the project or its community. Examples of
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
 representing a project or community includes using an official project e-mail
 address, posting via an official social media account, or acting as an appointed
 representative at an online or offline event. Representation of a project may be
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 05e35bdc5e6..d4c334a2ac6 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -4,7 +4,7 @@ layout: default
 
 # Contributing to Open Source Guides
 
-Thank you for checking out the Open Source Guides! We're excited to hear and learn from you. Your experiences will benefit others who read and use these guides.
+Thanks for checking out the Open Source Guides! We're excited to hear and learn from you. Your experiences will benefit others who read and use these guides.
 
 We've put together the following guidelines to help you figure out where you can best be helpful.
 
diff --git a/README.md b/README.md
index 75b29760a22..fa135ab3dbd 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,7 @@
 # Open Source Guides
 [![Build Status](https://github.com/github/opensource.guide/workflows/GitHub%20Actions%20CI/badge.svg)](https://github.com/github/opensource.guide/actions)
 
-Open Source Guides (https://opensource.guide/) is a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open-source project.
+Open Source Guides (https://opensource.guide/) are a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open-source project.
 
 ## Background
 Open Source Guides were created and are curated by GitHub, along with input from outside community reviewers, but they are not exclusive to GitHub products. One reason we started this project is that we felt that there weren't enough resources for people creating open-source projects.

From b545223ef1298587f170486baf0c6ebd93fb6f1a Mon Sep 17 00:00:00 2001
From: Justin Kenyon <kenyonj@github.com>
Date: Thu, 9 Mar 2023 20:12:05 +0100
Subject: [PATCH 437/749] Update CODE_OF_CONDUCT.md

---
 CODE_OF_CONDUCT.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index 25a53c4ea47..5833ae49be5 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -26,7 +26,7 @@ Examples of unacceptable behavior by participants include:
 advances
 * Trolling, insulting/derogatory comments, and personal or political attacks
 * Public or private harassment
-* Publishing others' private information, such as physical or electronic
+* Publishing others' private information, such as a physical or electronic
   address, without explicit permission
 * Other conduct which could reasonably be considered inappropriate in a
   professional setting

From d2451569066db54dce186a9dc2d3e02a58d7df9e Mon Sep 17 00:00:00 2001
From: Peter Pan <Peter.Pan@daocloud.io>
Date: Wed, 15 Mar 2023 01:56:37 -0400
Subject: [PATCH 438/749] Polish and fix translation of simple Chinese

---
 _articles/zh-hans/building-community.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/_articles/zh-hans/building-community.md b/_articles/zh-hans/building-community.md
index 2c77538531b..1e0591f409e 100644
--- a/_articles/zh-hans/building-community.md
+++ b/_articles/zh-hans/building-community.md
@@ -132,7 +132,7 @@ redirect_from: /zh-cn/building-community/
 
 随着项目的成长，好的文档会变得愈加重要。临时贡献者或路人是不可能一下子就对项目非常熟悉，一份好的文档，能够很快找到他们需要的。
 
-在 CONTRIBUTING 文件里，需要明确告诉新来的贡献者该如何开始。而且若是可能为了想要达到这个目的，还需要准备一个专门的部分。
+在 CONTRIBUTING 文件里，需要明确告诉新来的贡献者该如何开始。你甚至可能为此专门准备一个独立的部分：例如 [Django](https://github.com/django/django), 就提供一个专门的首页面来欢迎和指导新晋贡献者。
 
 ![django new contributors page](/assets/images/building-community/django_new_contributors.png)
 
@@ -144,7 +144,7 @@ redirect_from: /zh-cn/building-community/
 
 例如，这里是[Rubinius](https://github.com/rubinius/rubinius/)如何开始[它的贡献指南](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md)：
 
-> 我们想感谢你们使用Rubinius。这个项目是一个充满爱的工作，我们希望所有用户查找bugs，取得性能上的提升，以及帮助完善文档。每一个贡献都是有意义的，所以感谢你们的参与。话虽如此，但我们还是要求你们遵守一些指南，这样我们就能够找到你们的issue。
+> 我们想感谢你们使用Rubinius。这个项目是一个充满爱的工作，我们希望所有用户查找bugs，取得性能上的提升，以及帮助完善文档。每一个贡献都是有意义的，所以感谢你们的参与。话虽如此，但我们还是要求你们遵守一些指南，这样我们就能够解决你们的issue。
 
 ### 共享项目所有权
 
@@ -164,7 +164,7 @@ redirect_from: /zh-cn/building-community/
 
 ![cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **在项目中添加一个贡献者或者作者文件** 用于记录每一个参与贡献的人。
+* **在项目中添加一个贡献者文件(CONTRIBUTORS) 或者作者文件(AUTHORS)** 用于记录每一个参与贡献的人。
 
 * 如果社区有了一定的规模，那么 **发送一封信或者发表一篇博客** 感谢贡献者们。Rust的[Rust周报](https://this-week-in-rust.org/)和Hoodie的[Shoutouts](http://hood.ie/blog/shoutouts-week-24.html)就是两个非常好的范例。
 
@@ -174,7 +174,7 @@ redirect_from: /zh-cn/building-community/
 
 事实上很多项目只有一个或者两个做大量工作的维护者。随着项目以及社区越来越大，就会有更多的人参与进来。
 
-虽然并不是一直都有人在回答问题，但是你可以去增加一些信号，以让他人有能够接触的机会，越是尽早开始，越是能够获得帮助。
+虽然并不是一直都有人在回答问题，但是你可以去增加一些信号，以让他人有能够加入的机会，越是尽早开始，越是能够获得帮助。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
@@ -213,8 +213,8 @@ redirect_from: /zh-cn/building-community/
 
 ### 将你们的README视为最高法则
 
-README [不仅仅是一组指令](../starting-a-project/#撰写自述文件)。它也是一个谈论目标、产品愿景和路线的地方。
-如果人们过分专注于讨论特定功能的优点，它可能有助于重新审视您的README，并谈论项目的更高的愿景。关注README也会使对话变得个人化，所以可以进行建设性的讨论。
+README [不仅仅是一个简单的说明](../starting-a-project/#撰写自述文件)。它也是一个谈论目标、产品愿景和路线的地方。
+如果人们过分专注于讨论特定功能的优点，那么你可能需要重新审视您的README，并谈论项目的更高的愿景。关注README也会使对话变得个人化，所以可以进行建设性的讨论。
 
 ### 专注过程，而不是结果
 

From ee37ed6266e1fb967fb26b2110904b195c798895 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 24 Mar 2023 05:07:06 +0000
Subject: [PATCH 439/749] Bump actions/stale from 7 to 8

Bumps [actions/stale](https://github.com/actions/stale) from 7 to 8.
- [Release notes](https://github.com/actions/stale/releases)
- [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/stale/compare/v7...v8)

---
updated-dependencies:
- dependency-name: actions/stale
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/stale.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
index f77f3c3e108..8163ee6e226 100644
--- a/.github/workflows/stale.yml
+++ b/.github/workflows/stale.yml
@@ -8,7 +8,7 @@ jobs:
   stale:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/stale@v7
+    - uses: actions/stale@v8
       with:
         stale-pr-message: >
           This pull request has been automatically marked as stale because it has not

From 4034802de7dbb672167ff6fabe9152745855e379 Mon Sep 17 00:00:00 2001
From: Hershel Hahn <hershelhahn@outlook.com>
Date: Tue, 2 May 2023 16:18:10 +0800
Subject: [PATCH 440/749] fix(zh-hans): typo

---
 _articles/zh-hans/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index 41a505b3191..ca8ac47e9be 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -89,7 +89,7 @@ redirect_from: /zh-cn/legal/
 
 ## 我们的项目需要额外的贡献者协议吗？
 
-可能不要。对于大多数的开源项目，一个开源许可协议可作用与所有贡献者和用户。
+可能不要。对于大多数的开源项目，一个开源许可协议可作用于所有贡献者和用户。
 
 贡献者协议会给维护者带来额外的管理工作。这些协议增加了多少工作得取决去项目和实施。简单的协议可能要求贡献者确认和点击，在项目的开源许可协议下他们有权利贡献。更复杂的协议可能需要法律的审查和贡献者的雇主的签字。
 

From 8b14fd1d00b9552f3c37ca9278153cca748791cf Mon Sep 17 00:00:00 2001
From: ItsQuadrus <quadrus.yt@gmail.com>
Date: Tue, 6 Jun 2023 18:25:13 +0200
Subject: [PATCH 441/749] Update new GitHub create repository UI

---
 assets/images/legal/repo-create-name.png | Bin 31792 -> 61486 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/assets/images/legal/repo-create-name.png b/assets/images/legal/repo-create-name.png
index d77b12f60651666a78e870128248e0263a0f3983..4df8db79a1bfad1c78c4372ded11b370c8aa35cc 100644
GIT binary patch
literal 61486
zcmcG$byQoy*EZS~EyXGB&{EurJ4Fk{ic6qaiv@Qr(BfL$DGtRQf)<D3PJmD#SbzY*
zgIwtEeb@cx{l4|xd)GZ{ot5Nd&OVu$J+q&A=Gh5XS5?5lqQH9c<O$AuMcI!}o}f@X
zocNgN4_9)*M0^h~PhCDLyn9kPMz#C!0riWtiu98wHL)*lOwk@bKX+8rcX{#zx99PE
zI^a-Z@#G1-=e?}7mZ$Ol$_pcH?Nz~}oWhUEsc2y#`EL!Py~w*h473$M`9ElGAAd~e
zE1gMQN_anRC9=BpyzYJU`zfYB@}nLTj(lx}MdZP;&O^#tO4hjy>P$>>2HOBzc*FSO
zw*S`+f}@KA7iY-Dl5LgW*fqT2yeLNQ3BltLPYWo%d(H58oKT`u$UYvM9@u<gkH;XK
z%nJWsDG1L5-M>Pe=DE`U3i%I61^+8_6BCI3&(sw)3eJBFi9Q(Oe<vKngezA(2b{3}
z?Y(KDlMwz;ysY#Wg;nB~<)@AHZ34j(kWQdYsUO4fTJF!VoOX2m?U^9i`8K0{<IG4i
z9<4T8(ORX`(#OZm&dxsPQ*x;}O!JxiX~JIg%D#VYnXuwnA=|*Q5l_IGSiyGb``IC=
z^Gn**D7U&d=2m7g>58s}4boNQfC(yTD{(9QJee7bo))o!V)pLx_;GXFpXu@smR*Tw
zYcOquxUt+n&C$LwPvQ@=3ft)j=3eVyt_RZFs7Yr1K9=zk%B~|FeFN;j^qDc6mHX@6
z>y{B-;p};1kQo*`!$bs7(SHu)cKuGZ7x)^v+O_5g<b7z8No}G9lIW2ZJyR^+bUaT2
zT8mp+fwnt_eo2bp%9Yk!TevBisGG=EWqFA7e>LH&+(7xe))u|ops0yeM9tRhq!o2}
zEYV~8Y8((WOKmuFHdb<HTkiyWJ@1)ltE4z9L#4d85@YYc*FO=CN%RUkcr^h3?p8Mi
zB`m1&q;a}E)E<FE{@lnODD$(=&gS^z<WJYGiM?L*nsMZOEo{|NY3yyQ%6m5XQonj>
zqllh!wsc$%&J>1#c?xz<Z{`r20XE5#z^fs}<-|A6zjcKbwXA_x183JVeaIg?wgn=G
zxGMyrKH@Pcd&;0Z4oOb*m09=Ji^#rmVsd7I_NTj6A8C{N_3YTyiEyAkHBuGelSS%k
zh&GG6B+Nd$Zap#FMiLn3scv^2d8Ws0G!8q&9Un{FvX{>r?8Fe=8S&T?czOIh13>l5
zg(hh$;()@dAgjk~Ar(gNR_L|R?oG3<0(}pL?DH#nT<m`{8mKHEY)gXeOLZ9ZUQtX8
zacVlJuL6~pB3V{4Q{KL$HHsykHdC>D&y~U^0L`1(Rnd_!@^~{(r<1`YQFqbG8S7=s
zZNNd)IRs977!!F*432^QHR6i=tl6=+3RV3!&4e)(6rmU<dciA8hNYaj%O!L}+mbYU
zF_U?OE&TAHbkC>yNP$SKlVGxTp@9wttu}qFVR>Q6IDbw&Lrqe%9TcK0wvmn!D-kiF
z^aYfaH-CB}4qA$u9EUKrJU&g<@sK60Ashdk$jSMwHGkK0Q>XUO4=<q`?+p&n3(Ak7
zY%}`0!quCbVB~L--EfkTlM<-?yoT&@kkBG&cY0}65F6O=6WfBuy+n&<Osb5ccg&7T
zP}hztAmWe8^{0Deo_c&pC9NbNxH<5xT%YbZ>?U$a@?8t2ul(OY>2dS;!OjiV=)UhQ
zdT&_I@g%s(4aGA}(iHHp3Bmj)ilU*m+?Er;VNE2TGfsNmhaHeGK5OLH`@*WWbSHbn
z(+X}^g(Yn>!C(tX#A!{=S$2kL<*XZ2F`40LrQ}7m1t}wF<G6h&MTnh<5m==h-l-ss
zra?PK8Yh<d-2jW?e8_dKuAqP^Aprq^?HP$xV)kH<2LJN?A%sp5M|YWm-N5x}LNdH-
zI|sVndu;UK$GCIiHr=G>UH&XLyO%?!0K9jST9F2<#QF8KcU!J-Qj6%ig$f!C`n05M
zd#s@o({b|!d3>kbgU_*@a?p1(yLafRh)qJX5G#{mEF0j5#eI%L^<%pC%U`-PirnFX
zo?z!1y?N>B__hN^*s=eeDR0qA{`RN22utFCk%>UBRH3Gqv0RWS6y94=NLPWtUexAm
z(^+?yuXOkRGE`=o^(em=QUuoGJ`8*j7OM8GPgd(|dGC45PkdCr8}t-s^GP);Ow&(F
z*xNC*V%?|_C2e4)+Lavx)DWn6y0>|$^m=@b!ypW?ZbT(iwjF!?)!%8)BFZq4@tpjd
zal(%Z1YY|E1NsPGHaM_((R<`OQ9K@3ha(osR#@%NtPSb~ZiS>58bii{w&7)tY-li^
zTMZr+of*pdZcmsu?cZRi=7h<M@;>kB^=bxPTxB#xKc}At#TbOEZ?iVCY~#5ZW?*iF
zw^7D-KL*O4?*x5QxvrPNC@MKkW`q%MP(2$3sZ0(hG)6V%2w)OVL%lMEdH}XRGGMp_
zWJjK~z~?Q04zUNEvmz@Tb}^_#++CCGxgX+)#wcO6RQ^p~>9zAMj!iD_@TC0`;RhIX
zAf4v?ubV_v_NhIMctuY?3G^mi57l6X3D`K7x%@XOmM#X3=XE;YDK2_{iw~vpi4l$l
zYbRCOb1&h>_G|!7C)cCY&O|TWg7KGy^n5>PchU)0O4v9TPW_dJy^-ij*EOH~r5$$W
z8O+f7X=-Nj8uNU8aJ$29sDS+?V{%n*!D<CQ>-1_KMo~L28en$c4MU~k)th;9jXY!N
zgV(I{E}>1*)gM9!V<%R*%vQAyzB;=0G2Pm`uLy+s%VwbN57wZk<ZZ<;f;U%g9wv07
z7*aY!Nd=|;-Ot<W+5?QAwl9D`#v|aFF|Pv-1JzwB+Qd*C#+QDf5&Vqhl$)C2oV)5i
zP%vM8rY*c$M*%wRsnb=Ds=U{WZHbL|>`P2pNfBCQlGBOp6kvaAmi)Ec(dC?&-HZW>
zf$5T=El*FYF{Z&qjLZ~>D=($dj)o*`xYeIOF?V4HI$O%+-6WW`K@v|^L#NY#>op<8
z6%buMU`#7$g-oL5*U0Rd*V(}+6{kG=oT-ytZ&`m^-uFY{%ra7tqgTY1&SLAjH6aKY
z)BlRtsOWI0k!!w1UimXBlh{-tmLS<fI4>!BzSFaIH;E=Ai?(R|Jmye?zmc<Na@MJ_
z<i?%PzO^GIdcy`^I<NLMt0MG`OMHhljt+Zv=%qr4nQIf-havS5D$WwAizKC@p5V0!
z{P-?HD#>P2N?rEuJnI^=TSe?v$>j26{G?Me!xYLKS?r##oVeN@qWR^4A>|g7rlwBk
zG_zA{tdPLQ3o?v)8hryae$0c`UMo%YYHEcjC0|oqcUqEri6zqU)0u6DTOq@P;+F$&
zPq7`qTv($G^pLZA8NBUnKj#bctUYu-Gby}cEPF>SwOQWRW4ETH<D;^@rh|TCv+G+Z
zAw5=N3+Z26gNNmGBFc>M!g};(mn@34qZC6aRxMm9kvImF)90_&`g+@i?CoD46M=<a
zCf$B95~n2oR>{yj7feC$gvR-hWb5$8HmLPe7pnLgyXvCpyx-nV_L=t+mSLlLfu&au
z@TpZEm3;y;x?1}qZv}DvuvPGucUFJFlL3#??x?i6(4^6vpYrW(<;(5^4eX@9`d1=B
zH2B?pb%<&@C!9Izu|6IRdfSS_37rqGr~gXdC8v?Cl#0?&2@_}%{)kIWr)TY#!vxN%
zb7(xTct=o#-ad5iTSYP4m59uWEiU9=BT&fCZo%xRsw#`xUf&^QO&lDXpvj{Jzb5=C
zuWl|@>~y6}wZifS)wD~TxGK8Q7OF+3?t7zY`!)44HPRL0;8Oy*j*3nD!&r>ff^Rnr
z;yO9?d%5*D?AT65_FKlbauC61mCrOM4GT<Uw;Lw?n6ni&u=Q}yYE4R4S_wQDuFg^6
zQ<{abzYh3JNW~UH3LBiG#%#w12i^HB74XxVYhez<*i)1;3lkFQWzcoQs;w{fQtPnV
zL%WqVJe$v(tW7#w3|Z#@$3vAlkP)oibEWy*wh**j=~qSVt<o?}E@TevLKES*>&Hld
z98_4D8%nO>M3l6!^OwskdS5p{@jUik(oQe;OtLIHD1V}+SfZI##=VDiAU<l;tQ<o`
zKHSFh7xU?lB%KZ6Xmj#~Jn>>~3V`htL^2AqVnPPSDc4K)SCZDWN4bWKs<P?Z=61RC
z&EO%~^>5rw5LQrGzK%Gzo~Q>@uSwZ0r`A1VFOVM3GwkEzP}0FN$|YFEkcqNqKpRRm
z2^8e=A`RNwOT#+Nj72#K{M3}QdyP_ymPc5xtR_8gjo`6Xr>szGU%kIkI6(L7(`KNi
zq4JY_-=6KtS2RkH<hWS1YGwUg9gVNP&`IiqOBE!73swja(!-K=eQ@xaZA~h!artW>
zvt~avS=)e`RvZ!BxFnlf;pp}JMemDrh1Sc1%BB`H;1Z~E+Sd0+2*~r&C^J9<D--Hh
zwwjAt4=kgZ!)>9iXkd9K9hebXs_eAtY1P@iVg<Y#S#gu|$I0P55yZ%W^NH`|@RGB+
zH?JDVJ@jk}v-3ROkx|VV&@32U_CfuV5A*Vlgyn$%|0jI!W3HqJtP5~?b{QqleJu%W
zLsRJBu%=ok0pH`G*RA_0SC4tB&;7!zKg?rQ@cC#YxeP1e9$#`}5*qxe=GX0S$CEu-
z5~ozqQ$e^HP>L?+b{+zo%`KwR7xgIl%l7MPB}*G}+pf5Bh<wW5>Cn8IBrj1MpC`#>
z>VKC9Ofg;RG?ZM80now#J{C=^p>H+3JXWF!Y>p08?C&~)-;lE?dWaas!{JQ7q<UsX
ze;uyu2r1I`Cci3A7|#<L21jY{owfh$5d}XZ!jR^8h&2r0j8PrxT9P0o+tqHNP&B=}
zxzD8YM#57Nm5+Fb3VF6#eXG}&)e<i`L28!!eTUFmVMfdZ`O{MG5xfV)KPwdIN7kl7
zmE1NX<C9cWzPzs*C07g?p!0X<6*wH0x|X==LWuQVfJn3YU$@}AGm3YJm}2`P97anX
zNt~B#;;UL^oSc%(a9>@rqmuE(huH301>5{w(~lZtf!?{Zu#((&$4Oe1fW&c);7^9M
zw;UP0-i6E@f4b+yy*tmbihC;X`8uad+^f35w$2)?f|@#C%L|55Q;m|gjaYMU9Y3hA
z<hqYje;2yyayBi!Gm>c$I!`#k<B^C(%b>bGqg=_4i;QORQD+aTroULs?!=7P%aa_4
zZ%2pKZ@)F0fJsQ|C{SK>haG!Q=(c(DntdskP8QSU#e;g01b+4&e)r+MGwEm<qN(ah
z;r6ERSkGbKhTYXFLN2PhaSb(p9+fd{tS3l8!Bj&D_XO&_t>oydOSmpSHcdNdKY@Z^
zB6Bbq?k@Wxw>ZL9BmU;2aZo;}kx?@`=HQ5ue^XzbF`w9stI=+V*s}8FfTqVzw@k)l
zs(>QI{J3bF$EmhM?Vwq8>(fe<Mry4ASN>$eI!{56!)<NtLvK|c%qQ!Edd}Q^j~`dj
z0HQrTRDLS%LLU-_!!(P7MHDrQ6w-Fln41@UD?FC5R55+%f-5nb!P6&c=mVW0c8s9=
zw!m%!!5HU)@x!RevLH(maes*rUml`5qeHbjG#E|TibbdKeTqb_dv~dxh}fWE@PdC?
zkPQ>-FXhkmzZ1!?gBP~^KyU8%8cLpwNH12vXnVA}z8rCz+&z7_;Sk*Xmla3<c|2L`
zJE$f~e5^hLZ3Q6z&$gCh8q>w52|D~VXqC{6?G5g*bIp3VhTht)Lvoaf?JbD%+>0B{
zMF#S_{3WTwDWUX-DIeuYNC}wDc*HGO@sD0R;RcwJ*kSt4D6T4R<*4;InVD-|%APO;
z*I-?J>%&MA)D&>T-0R?UA5y#XSGmT*pLW`?)E9KPALc6dYU*cGOjwuC9(tQ(cvZ$@
ztRq2dl#_XWC`@g;Nh{^Uf@=<H;A#KMf>{Bs?+#Nikv(a=tz?U(;iIKv{fzt(e`H1L
zs*N|NG-}u&eNXSCcXIel6DolTFu8d`xo$q8%t1*(6MoDE>>A$o&Wji5OZs$bP)(yu
z6J1|qSUJzx)*->5#ZFCAPZ3>EpTbk&z%~mlq0d9AcBdaOC^{jECfOMB@U}Yc3FiKg
zM-u?w*>y{8=<F<UpuaUXi1d=lM4`UY{arC4A|5~xG?!(^e^x2Z=!eVe%XII!DtWOU
ztZOO!_C(zZKdABm`ROK8@Mu!=Fk1qz@9UK{E>tFQ^q6ZSIBQHgq#y})U|VC+CIp{r
z3L4^FK{Maz>o~9AM<btdn9$y`_6e;I7s~?qzI8VU#-^<g?->qI?Z$-pTk2a|j!dIh
zaIeqe9ZjC>p3i5Bh5DJxr6uAOWCTYk*$@TS%&|xJE=XhZK7^D?ZQVk-;1chXxjmUx
z;!i6_5@9LgQ>md3tjB!)uc<s~*@l^+_JuMUA99`oykP8y6|XJX1BY`$bX#F`Ed$Tz
zY373P%RO);9FMGzHX}sBz4FQKNre&HsqPYPHu7a_I;{fz<88PPx0MA^y=pv&!p*w=
z<Z6by2|<aX=_GssXruc2_**z0IHeMsat9Mwpmo)7Q{&Y!9@oQKPb0doN%fK5Ac%+5
z$o+2_rAHp<e@jh)SOevCoW+>f7rwu>X}cB;vP{^h*^i@W53%0nyb7au@l^(%IvgQ}
zS4DSFE<lJMC}s>a$;%wN&04%x>WTsTn<Nzji?O^co9-3?snioL)R(nTB3i`Xh-6KW
z?L=DVu-d1W^uRz^Tba#OMe1;JlZ}BYiqckh!<i4&5o9Ie=;U@yEwEF5)}i(qP&EA9
zH<#XDNHE(zl-Yt2)bFd`*rTaTbfksBUv_)h8O+Xakgt8DmuF5?E!LPt@$2@+rA<N$
zw>QOYYS%xNaX4++WcqI0^eSrAs_e7L`@rRt@$^#?uVX570gVlRk_Fmw)*~L;$}P8D
z+pGAb!bQW#nFVcUE6R@<;gFpD{iWkuKNaUo@yc?FQ_(|DKix>%(ne9OZzOMJJ4PUz
zh335;{i1D)M(>~E@r{LXdAjb0(o+Y{@X3eCPNhw+E9C3zot5nq&GPD}Dd5jKVT&kG
zcgyR{gbillwyOwwE``IfbJg!uHNXGk&z@M+or!iOjGNNAo1O=0lCd-NS@F-ux50#v
zA6|xJu7=FinUe9!bk-HCsJ&J76zwGk$EkQ`*bih%7jq+3h<o{VLxtTv9@bD$54zvf
zef1q{-eBI9s<q8rR57#~Jah2J88WwGX%nVd@A;)<<Dp%>kWl(F#&{i<C5vmwH-NVt
zRilFlCz20E1w$fK__pViAnA=0bzQs#yLo{=I49EFDb;>8+n?&zZlnd=*e_9aFl9OL
zH#2oSZ7EcOGX)$%QsmpfGdAgBRWp>VrlGcU=qsFsk^&v-Ikpj_O=z1=v=GPF@c+CV
z6aAubF+C}3IDbQgb+k6qOUNF{moZXZ<z>Il8k-aK`%W<06>P$IILz?D3!3RrWINbQ
zWUV{4WIEWzP+&06Lt9sKNVcZ3v9MpoHNYn)&XVE=&@tNbz%Ypc&$nss9xUK}w>C4J
zb2<F%2fEQMpYFZ*cC|bLsxCUQNOUN^X&f=^-fcZ~FK1%qu&;6nJq1In-1iUSfSg=g
zF5Ai?7!hJ|f`v=6dDe%PNC-BEWbNc)pO-sR)0^ZZm}r51?YK<ngJFBuV`_(M8lHd)
zq2%!*6ePVEhoNNEm#pbL_`s|~;DyUJC-q62o!#DzpJmq8-vuf!37xk|tK_$iA8*b@
zO+Xz0w(|iiU)t33U7mw;ud1Z?F4WSsY#!)>mR<C~M)*@kz+ph}tAVz<dm5*9py48R
zon-P8W99Q*fh@chli2xAjY<G*hIz}(c>=km;ds5@h9HybjRXa<dR!8|OEvZ3<}T9h
zphFbE;ZOvv0JV~Py+(=t%Cc;o#vf1&tru{fJGr~rO`eyWls6J-w~V*Ec^k<NCoOv(
zBrw{F!+$qt>bIGoZFaTW=tPg;KwO%Rz|8K-Iljy`_ncc?XX{%I&1_-jQ0esGTDuvk
zjtatc)gpo9+vf4sHIf2p4~}JbdXTYgX+Jq#?l7N8a!XcWt?gw7&{YN%o5$~RZwE$h
zI1V~^fEy*V>yrPd8Bu4@HJY<wa85ahL&m&5=Z^(?btKb(n-RiC*#YhYuvCH2(}fiN
zmP6GBfZFcdB3$9fae1lMzVc}fV)>7?$+}SaMvNs`Szl{Jm^#*A{ID$@0Z5_-i)@(-
zj8y==II5_ptWubSAu`#b#p7Tn7-A*M$HxXREqv0}vC;U)%QE{*HfK2e4Zod-n8B)u
z!+5f!x4|;)FBG6p(HV88%pd4LC40DQI9%O)p~DWVqi8yvb6~^6jYd2UStpva<tJ)C
z;sgmwHV%c$yU=u4irBYsgx<KBNMuc~C+g~~j%9_q3T0A);Qp}#TZ7XzA|H3%mK)uS
z3L*A>e$<F#(6AclWP7(wXsi9YqgK>E#VGM9|EMpHh;fd)<r35(&MW5}Tqg-{ggXGm
zHASBJaR_IdgDgj{fGHPd!mu+qJ;W%J3sE!ZM?UcLV7`qybmKf-6~yPMznWXIU78su
z`1C*|DX9@>X93sSl`^Cx#&mFuPj0PJ_N)%{Ha<)LTZwd|sH6(=q7LrB#%ML26}}UA
zJ28_Qz)ZPl=AX%OJv%39>u+3u`MuvU)V)Kl>PzgWdwqiE8SpUIolts}URReK36Ocb
zhvVqVKyU4$=?;~paz@g=E;iCt;UdK=_hjR}OCm=TEUs$H+<uBOxSj8*{6Ko+JUy1i
zmYCC~CHTu2S&wPh;oAB_0j~K658tvmS@PG0BT-^=Q<|?%X6re0p+kmu<XTtcW=g-r
zLYL0R4}bUDA$cdXG8yk7w@3asmx<dn-%SS-`p<i~9pi+UoFwW&#r7j+eS@6rCzX}_
z0lh5|L|2F5S7O%lXN#KN=`&}73z<wBA#yxrbZP?!f0sd~5(?S#DVD2Rs<X$gjhwdQ
z?!Ykk8`6;-FVTLju`_dF#v+(U*K53iJtesgnJ5GUA2H<T;c&?KE|ry$=Jn0KN`G+i
zo&kO*%PKKFFkxT7k{uSe&6##_koRX8?n%~3%>b-vM6B?!mOX=Na=nnaC9x9A62;q%
zgFuTQB8$;iQK?+91Be>olWM#aS?@2Y0h+yy)c%wJ0NWOvY#U-t8Eaj2a*^amegyUD
zx^;+i=oC!4y6dQ&|8W7K60NKZP`fHhQZ~<G$b7kN8#Y*%u+)-_47qK<w=CnbvK(qF
zPjOu;>`vJb39@t`Sxhl0tA2t`aWbN5Bx_xzm$N>f{;Rf0dku%eJ8;;4`jqKO1<RPG
zoDlY3n+Z3`OYVAZtg_3Gsc#vvkWj<-y^VhUM+(NTRO~&L>^<L(6MsH<vBW%c@~-|D
zD!3Wm$u-R}T_vAXWTqdRgziuuy7}kIQ26Ajz+!JHaA3obMfSB6wB;rh)S#t3U6kEX
z!j>Gc<Rt_eO%(JdpYta(N)BY}M)0rsWb4KRWWOe`7RPb&yF6#y(|&TYy3ukG*mP#O
zhN{gnk!}7~H?v$8`l;V#C$qFe1|ae0kjcUFE|v9(?uSqwy}MU&1=RV)q;y)mSzE)k
z<y|96;gO$4!gUs#I_)<v{-o6dE7_D)PfybWIya9Cv$Z>^f9xBZ{(0+>a{ANv`r2@f
z$YZzq*Gm|&Q2Y9BPmQoM2+w4vGy1UkE{5k;6?~lOe(!6tsI}$Obx!$edh_a{$Qc6B
zy*8LaOci^lWWXRU9YbOofyK<o?+gp%%n}Aig@wum)5W$wpY6_Ewze@>CAE{hCu)|G
zk*i-abo-DaROONM$09J%Lt($EW_j9Bzn4_?CxxrYQ$fHD@4`eQ3(^xwX6M<QE3Q+N
zUN7^-EpSMb@bK`Dmui!LjSvA$Yi~pwR?L!<#dFfg>k$I1Z?X(K__LeJ(Fog%)I=xu
z4lvyC?bo&p#TC;<{nzYqx5gD-`4Y9njOxU~w3SccUdCRBBW7~VxWD}>>Oq^S7e%mD
zTCr>&T2Fw9KWSJ_vt7J>v8boJMfK0BU)qY9K{$AVLTy^^xAHmyn>E&gz-2VbB$eWd
z*Y5&q!jL3HZ*LFV&F>_)m-qIQvyB(4!2XnF_w9T4z+1nJ$?;@PT?kGLbb0{ttV*m<
zChlo8$;6WOS{qdcBNy^Wl?qfs2HLo~P{lFuQUwKcRN1j2#6Ka85eFAV>;Ibi<SxT}
zpzjPW46$oBtmTb7g-ej54s{tC3l_B<mj~^hT6<lEylwofrQP)mr^0$%PCABUdOzbr
zEFO(e(Qmq^?@iv877Q=6q_?AG)ZIfpa;=Ge=(I8Ztsz9Z?D#udhZHdI`!6nj!I@au
zA6E({c5Ez$A1*wbMy)!0(J0k?n%{0StmqqB(v-Y7RY9;_TWFdP`<HBf2i`gVc$!C1
zP8NSL)QBkXn{0m7={f4f;s1oKNhZ32MNfUZYuU2f7!9F@JaIuph>}{aMF}Z%tZ-Cd
zs?C2zilyK!UqRi%>__s%fslS`18LCM2g&La&YYDMiwam8MJ00@lhf)S2ZA3fd|8NM
zEU_#flZP&ntU}7Qu0XnpET^?PmK)}*A*I&vRMyKqpNYPUs?H&V-AdIZfuKPGpwv#}
zY>w6mSo}S$5?FKi%)`>iE#9%UX!eZDKfsrM+V&n`y5YHP^ulhYIva0wxHz^G&Dirp
zXu-3k89ro0VX?W(rW>tl#D|sNy(dc!_I>{Feg9%=&kvwjh^_?U@4soP2|{TS@HXq}
z!oYcRS8yO341*|lSaWz6H-*<aWSWa(E?Ld5Oj1IoOA(e{PX0^?hZ1dVz!^NLP@CcR
z#G*E>o&J-)?<w9TO)$_K+)YvN##k6_;?Oz+@1WwM_m^r~1B-rJ2h52<ueleBv8qrA
zUus+t(~u6y#sPX>5P%tUWc9YUV-t*RRQMj|L0-j=M}bTRP|)RFJWrVAH8YWD|0zWs
z@K;LB1e0@$<AUv;_=*Rk%1Y%2`aqMB=cX(BI)>EEf<8h}>25S(IL?H(wsb~FjaSm>
zEIMiQ%1k&OUTR~s>iUcQs*gTa?tVSagDo53iEH6?B7WcNl{%@W{7XYV$`AXcNtvpp
zRC2|gbC+w>)``yh?8>L}UYx83#VbYu#9JNgOMdzuWWhrDM$c>SkK&l%YXt&Z3=p}F
z!7qG2e39QBKV^~{rdvqvl-OzB2~AwDtNLRQ$@+~n!TP3Kbn|JvOiVyvcGld#3<s4X
zp_qeeqKQ@HmCwwaB(h%)d~PqYxC3{lL6xkRu)T$KH+UVQHxiQ4qnCs~4geNiZIYls
z#c1c*_CIKgY9<mg+v`-e#8mOy*6YZ5*nEs4JTvedLOch-)Aah09sySY3%hoFHcD2@
z@qZzP$i#iGUD+!f7Re8-D>m26M~5RFUyXT8+f^7wjIB5XcK3Ni6~k3xtvzZuHkzjU
z;LRSZRpx4)(%AtH%lDr}{5jCC4NeT;AD2z;jZahx%{y7RZCKIA2I)rUTcg%&MR14#
z*{pB6s+!t=M=`Ci>TEt!mj82d7SPDWT88bVF#R_v)PHR+DULs8ANP%a+#jy@C1>S;
zCyV<4q*0pf?cT5GPBh*1)G}L%*<NRT!>ZS1s?Y8)kb}lLC!*RuN3oT3i_s&~U=th6
ztK~_4w@`Vwz^68iP#e-JfP)S59m%Dl&+7D!nT)o^<GsdYRz@7PXO_-lKU6P3{j7of
zfva4a0%xR4?YwbiZ@hF>v$-}9SRXTLu0V6~6<X^z!*eao6tgx5XaO&L^G~dUd{;`&
z&N{SM8qN&zY)akTvi?ax@@xV*{=bPy0Bg^pe@~O0oz5>*$?sxKorvJUux5oGnF5Wk
zfDI0c*NP?4#3x6e^^o3dQJC`z<3-S)-5Ia1G5-~LQVo0g_=eyLKpmMIQpLWQ_2tm=
zgWs+04!b-QaBh-g|7}Gm)L7p+kZzv@VKBU#5fD$rEyP4+iy<%*5)JLNabFdoos8Bv
zw+NG9hx$gNkBrQQeG)WjG|p5QN%am}VNY%W(Vz!-Kc}2E`Ud${^_gFWh~I{BUNltL
z=FhD&X|=sQz3Q?Hk+XnFuRP58`cyA}wl}e;jFzbSe$<@x9u+1rTQg?!Jvl=K@qLl#
zP|CM}%2|jr>HcK7StR*vl+#T6E%+*~-mizg{gL~S{XGku925z~gSVhqRzU(+CZRiL
zr#v6zQU#0!=rJh;bLs+$WY`_D?!AS6sO9vO)W5hEt9a-Ce5mg9KzMZiCTL+A=kzMU
z!0Z4P&0}a0*cdaiCOyc4A`3Nw6zO#wG3acScyay_#$-<(Ne_ye@%eo)mH5fHlXc+L
z)`bX1&<o%y_2u5*>ucA9F|~+Yo^`&FCvxoOxV+A?bj1$3oG#DXx3c^7fgD*^dg#lH
zV*}kUimqN?aw~5Fupika1_oz$HxwL=t68>=ym#!ZwI`L=S{pH57AOR$M!%mU5JYBP
zVCu6Fvg7KC6VUx9Vf2A-`Z>yunN`1J`-Dz(=lGt{H%l7Kz|}H>Nqy>Q1<=^Plg1fX
zi7+J<31g^?D{GylVsUMJqp%|+Ul-AHeic+K{8!MlrqnHOs7sz9?D{Ef`U&_@kAaer
zyogR2+#lTxNf-F%uNixYD0xo+Hc3vh&CDBTYT(*4)l3q%zn>c;>g2}+wR_nV8kMMI
zf{V{$TPT0%nn5UkHqDU1Y*%ts?=7(WskAmzW%0EHp4uQgBxn53PhaQi`-SGd!sO@)
zsKMLc=j*+_F#3Y?!vf!eH0+<EDs5&zw7VgqZ3dqsqs7{~#OlaQLHyTI^`zT-_v4Rs
zzVyM*u9m+U%wIdrt0<T4@C<#D0dGYsX2A@rCkyn&1-r-G7#7rnIr+jn2!iW|t4&}6
z#NUt=9OC~x<=jRmH{NYkE1pyOw=)>vws>Z<vBfa$OYn-l6LWdG8p~s4#3^sW=qj1m
zj(;ceD1<C1GS%iHGc1^uYI?E03W)d(>)H11+)viA%BifgmJ9oyQmOuTl$*bmDsnqp
zLG^?A*;+GQ&g;Jr#RvY6fgvHC*h&_H$u8JRzl-<QFehiCm0(t;ydfju4!`k=<Neq>
zZcg-T5nQ}?un&j^U~)KLiN1t&7(pEcqqECT1C#p&actx7<~CD*G8<jGP{EKf?&<8#
zL6KsPVz?;kaTT~2Hjm-piV)!NF*srj%AlXjK1q6@6~ijs0)5(n#N<^$6)II9E8+)U
z8FJkL=8JQ`{reWck0i&z;zm{i{<X^?_XJ(epyb&0Ohe@3_k+<C({2%u@4{?w8~<Nx
z-5zcKPs}9RK38zS-7E|LzlUofSI%JI*@*_0PyeNu1BfpC*VF$OBD(*T;s3{Ky#K!p
zJ)^WT;_N$Cc|iby8`s;dpmT`24(t>s#2J@t=^6?v+KCewM$R$=<X$gaDrmS{TxsN}
zuE?88E71(k66&hx<LX33%B^RA<PTgPQnCtWDSd4d_1GEt56ihi#T-EjJP8o`m51c_
zf}|nEY<{XyL;`m!oVk2NGg6zaaN+tl^B;rwXj(Y-ySwb~sl2KMCZmPFO8m-oLgvbS
zQKnk~T@j=qrrqbijJmlvy5h_2s6;OkC`bbbrez4mu^O~@i_*fflA{=*6^=69G_O>{
zDvIVM9-@Z!1HO(v@l)oubbE^4Sx;_j94&Wm516pMeEF)}Fx*<j1)tW0n(e52hxndX
zp6~LdVdp~N#`g7kT8bIIyZ&g=ukAUV9p+*6d3$kgv%3!;-U;hi29$m_e*Kq6&zTuR
zIpo{UhNaiwa&{zwolB=1@58|IK#-%aGR>TyK}6;HH3k09&yVzY1!1mK{>xq1e6A1!
zE>Vc+3@e4K*?xh9lq%K~VmMv`gkvCK_CiFdNh~(Gf-&AxU4?lyilyK4L891TAKdIF
ztf)rz{m?)#JzURiVJ5st2!$;>W^$`x|7GwcamyU1KrK>!WbQ?c)5wRYL%PO<b>D5_
z5_(79ahiH+nqWp2um%NHRBo#clQy2@eL>cAV|37|(@#Fep(VL0pU$BoUV2b>I3hbP
z@J0oJ4}OpBu@l1*PR`tbjtV^o+*q{mjCUGE<g+oEml)}S@5J_#qgmv=5}`Y5@9Osj
zhz$ESE4W-qM^t*{D<X4KfRtdx)hO+aP2LyrZq7Jnef5_rMI;$683b@46&BUB5;)fv
zF2c|epzM10^C2OFA`+pLVC`x7ztS384X1ddyIkss@~b*sstsAcG}Rh|yChoG{zUtD
zvn-znks`*)=v5NK$;XU0=loM`;uttVP_*wW2cf3>#jtq)O8OvRarC3_#Xmu#=wlY4
zzuP4WZ@fko?N+foijQ1(k+zzDjV{!Np<njV{grv$IXpSI#rfH=<Y>P<wv4L}P%ELu
z>Ur&<4>@IHdlZ4-L0|b7*+Qi;W}>8`0kfK$6RTGT;MiC~k&RSLMG`w6-LW6X=Re6_
zSwb1Cn_G#1?lzKB0qGIe2$SCW5+f>><~_A%ai>5U-U~}QKZtR8Mms(m1zt}*0kB>l
zn)gHUu;$gx<qlZL@e{_@>c#8N;vz(#aqBua!!7f^Qi;^~T5{X$4$9p~a~^=3)391v
zl*ag>+{8lR<tGTPT`EPmx!GNFFO>$N9DbcS4UN*E+yI)WqoSRpsTBTjv{D<rGZrq;
zo8Y$Zfgq#ob>_<NWHw%H1TI|fG4Z7%0)(7=Me+<!rS26!t(><rSj-c{m%q8;$eTNw
zXgGOTOOkMm$)B=WU#`uXVy-sePwVc^<EwsVlw_qD@;Tq=^5J5*enBw!$C#_~W5R4?
z&1+wg9}pk%1p86^`5EqBPOgECUvmD@4&PUP<qWi9i}x+@v{%ytx9$6X`q}bGc#50d
zr+&+?G;kh%5!bN&=0ikIto3ockn;jS_T9r=$DjS0PNIPwer2c}d3CR`fs6Y}&!GOg
z0@{FLb_rHV-Zk^Q3zalrPpRdoY6$2*IW(MR=g3y9c^ST_V0@cZ*f(>KjBsv$%aR;!
zwisCD$2!1g(kZHHXB+hTEUNG0=_)GEO_b$GlTDGH?Yvfe%yC9N(6ZxIh@nc|{*-_`
zzf8^Rv*%u`b~zYD_O-qo5s{S(wU%wE64nXE@&yPm2Ui4?sZ*C-UN-FqEN$B`#&DII
zp~xEgF1ZC_aF~XmjdV-+9Y0U=5}9s$rT0NBhiTaS7X}BS32NxyRzMPWUv?sNY~n1*
z+3&Z|*zkd?F3EcLrZb0Ngv?TZ9L1$YknK8!{Q}P*nf4<Q`&IIcLf>(z?O?n=^(#Hz
z2A=JktLp=W-WvsWIE^k*gn&MiVXU$w6R6&|^$&0LES$Z{@|V*?OmAgEE0No9ua6<T
zr@EPfx{wuq*#wMoTG4RcSudjje4dq(w{+ED+wIN}wIf}n@5RZ5KBk8<`V8|lI($im
zZwTPwY0Grs%+Kq}NZoDw^xb>Vsk%8?FSfol6AXVZnE|H`&5H+R{MPb2dr-IxxH#?P
z)L^di5k(4+d-T6>^i8?^GJ@F2&2l*o&yLbI``B`Y>m&QE6r2AyPE$mHMGG@$R}F9O
z#!7|h;Up2s9p&-;vzIw2LC9Y7o*Brei+YJ>wpP)i^1+%$KF`gbMx0R@J4*wsLs5zZ
ziv6xbKQp!OKGl|Ls3E5_hK@!^oZsac%}?D$*+={4h!ObrgX&R-B;h~VW?bKD-Yri^
z*)zWsTrP-Z<a_2(BK<PL_9NBwWS`6|Ka)go@>+>qj??VJe(J-<YShE*(Y>=Ei2gH_
z)J!8nMmM~cs$6OLsqDFQ{rROlW}X~cnWr+k0L?;-yf~v=`<A_H)IwlB?StIvFU<}a
z)X-w$rjlm;o=5T8Q4*J$+s~NTdXn@f1!wb!D|^~3I;DxHaeF)SvkITcfRMH*lr0xd
zi5D1Yt^G+!ORcN`PWgBvU5Nljwn?0?f7D{ZZkDX9H-uIbN~llF3M!fN6IQ!0^dEGv
z^`Q7{Zrl-VL55i0#YRzS0QaYNsB;HPvH7B!)%?69w<;?be!5@X)Uf4@<eBB!jl&D-
zZx^_YN6Vs)bgbUQuy`*SfZCFCj^k~}|KltB6`I|CMW2dFp4j_JYdL?e>Yno>U&yM(
zcM?}HolK+AtM%kd|7Dp05u^gVSpA(h&zY-RtYfA`=}PsafGgm|F9sh5gGS#=y8011
zZ2M~R5hB5jX7`bnmjfP5rXwl7*YyI{5)3rc22i@YDp-7gFe)|1xs;U+p|LWOa2xup
z(8TNlmJ#nDaRBEak#^vWc!8)Eb>d7WMKztOreSy$BU@E$_|tRNmt8L_aN|3gP&zLj
z7bmCG>2xqYfRuSP@tZcr3w3YlMA#ALw^9|6770aL#X(8-Mn(yR$aV*CLL(lw3|K|^
zXuXUo%2TZ0yIt$U^N7y4`-uAR-mH5Da)+w9&srZTPrdVqYmL>q%J$7TzOvp6V3az*
z6<AEtr5^UtRbJ@j2DTEA-CP^{9!=5Fne(jo_c6F1G9_MQ#^5~Yh(94lN(|(F>h_{-
zLin%&+O*M)fDrmyN6uD><;4pu9ZzhMqCW})L?hhCfnz%p*34V*AApJ(-!keT2A;d|
ze1g_5G$cSy>7BSjJ><tPn_QHkhgrQ|v=T(Sc{ht_sEpZCRc$R~50ZwOygc#E+0oQF
zl~~y&i5B@p%@%(un*BM94U&L}m`4r8o3lzK>FALfADbv<wJaXj!{VLmDQ~g-xdx&o
z45D>VuIm}X^C<j`nJ}RZ2+kMaA)`zSEpL<9nXRb3y=CALGUfB8HV6xC6%W%Fh4+6Y
zu+b?*{drK3w7^aO67-<gc)vN+HIVYxv!unA;sJ93BKHO{_-D8$`K3BK++LDIn?w>F
z^Ork}L&eG|$%Eynf7CeWkb(v{AA)pPSw>fb6~0Dck}aU^vzdk}+lNb(e{0OLyN8?=
zZIACTo<c+HqGD9@-;%m!ZFueFk9SoHxc`TrVCXcD{GYN`{#Q5|kkq8=hd2;UG`^&P
zLL~#a+RME5W=ex|bFVQU_6+Pn4K?W$o^p`v0gpn+#=wa(yMornAZ#Zj*Sq=k<>zlJ
zONuHF83kqH&nT>JPN!dIifD%A1YDufH?2lcQZAQlsjE0&omd(XZl8dr5Y;zk-3KZ?
z8lC>){1?M)q(}*`R!r%$y`Ph#II<I(x*sa?$6u9656i{*-XVDtO<KQ^jQ+-d*#&#3
z;*Qb_tK8$+A>SFIq@K7qe5w89i(Fey{ff>T#Q5bM5`Nr+C%HDykq&$NY%P+g7~fYD
zW!ZaVw8X~`VB|p^j9r%IPY`$w&EeVrBOv)&s8k+}ZGh2-RbJWEv-7BseNJr!ElkTe
zdUHy2a{dglfO(Suar=&|&j)S82ujRaP@>%srZrX6^|}c<xmLo^3EM~w`*^L<$cc)q
ztd`+}xK+r+`>7zr^(}I0o|kvQ>gBScXlEc@&XCpe&gYp5pZ4^3T8LTV`ALp$L2GEn
zgEF!aQ!kf3XB-m?>!W$n1!7!sBdBC1Tio#5&CRn+A*YYXK~rIsv4j!zwV7Xrx{t<a
zZ#s7S%TgHg_O`ar1+D&XD~7y#5m?sRz85RPFJET<F3jO*t}!)VCY-{K?n$?$6=p9U
z@^U6`VMpsfTW>=zD^xmEXw1W(6{t0;>q~jSh6xnM9(<gD)^BgWU>!$7z4>t4spm0P
zur*d*ZrD7P#vQSCHr|-{yj1H<-NLCIpg@GowS;Ntd3;oPOrOf5s93_F;8ka47mLiG
z5J2Bs4J&>V)3Z-L?X><&ER#blxNT$L$a2*QDD;5%Zsr+Lj=k4Ea;(L{2HnW*v|OO%
z3$<-e$c~uN>(!?p{kcT`*Lk4)`yoNA8KIZSu)V)2CjR{a604!mkz_OVd*dB2>|$rS
z?k&x}R~6Y|P)&ZwdcHWwamzJu4o$j}aXty0yZ6f#N%1Nf&2%bE0#oNdRzLrm3k>lc
zW7r8nH|U}pIvk01XxFCXWZ`@_x%lqpNQT^>nT@FDi_>x5U4Qb6!os<ZF=s#vjzpaX
zAc?^biA%?Ti_&^T@9<dVrM#twow-qs?Qs*Sc1n94&9D6MR~yrep|hzzu=@s*P&{Y}
zj}<r$ybdlY`<akYWB+2}EL_6Mu)zcEktxyO{|H2hu8p*`BJ+(r3xu2aU!mRW-FX0;
zy*!!kJobq6PM1B!-g<KviJfB_N5}Rozc+URb967gCAZG_*kJh}jBMd(8D-n%oBAvf
zO+SKHddvo!dC)~mo^tr+_1l)^XZ)z4j3-;JOG<x)j<OBXXE=QRmrvb-?X}EB7OBfd
z9n#J3LE&VAu4Mi9^F0P#HJ?s|#CT5W#f0t1a4UVNM}OP*6pozZeH{S~0gZ)U5Bl9d
z>1g{=6ZL**8(e+=tLrAdjV%N(@G*^R)?ij(;&Qh*=c~xPH3xa^NCGx*tLs5b38b-K
zMQ|mG(NI$AO0BF#hWY-OP-3wjO%MZPV~nI}V@wom1sjT84p~laRN+#>y&>Z2#g!^9
zQQdKbJc+u3$s^bP{@z|VntwBal;Dvpqx8N%GdB_f5d=hBGp;5hAb0txtIw-SvJI1#
zvQv%jX6@TfmT4VxjMP+fuGM^tDs+Qz5=2a+8tVegqB1*$xGR|N`a`=OllE+?Y;L3E
zt#{E90c|DXN4KMbugOI0P*0SVG`#<ciNsKZQwCM`Kyx_%ZY!rang`P@Q&L9K4s+(!
z-+Wni+6F9%JbFh9hr_s4;x>DC0?`l0z133BZHQsq^?YdH#kP5GPE+_^yU`jxA#DJ5
zfbb>d2T!QU!Wn#?=dZ4rvtmG7y$_H4u%$d_{{YCt^dpkhPVG<Y(IP#c@1>>POYl<d
zr70?0KZwVmsT^PIv=emX0sIos1?jtqed8L(NL+gi$!PdGIIA!QI>D-j0wqvYA39pg
zP#Y{I(|X*G&hXXhYlee;SamhirC$?`=ib$#CzC1Ks*eLTrxCMUmWZ4Bb}Q^?BbKxV
z-ouf4+F4~j{K5s_Z@m4#t2VAw?E;lNwnVac?w0yr0ulH(McbO5exJD#;a(WDzOPyD
zeeP+K1Kdcn4TXppLG`kV2wbwO1wYId2}~RZYs`vPsu^|Kjt(p^QO0v}ZZsnAhzAK!
z(}nLdb2!n{!Q-m>C$CFPWl&+FGS#V&3GmMr?#sVqV*E~R6m@BWUm6AA5hLKpXkn?U
zV;*13%*VNbq^vQp|7_kQ_WEqk=3ePF#5ef8nq**Hwfd_&m$wEN<iW`P@!ksYyRU{I
zoPl<86RDn((4*^gjvcV1{0k}U7_jpJUxygoU3kZfCKwSPPR4M}xYM545%d_Z&+(0H
z<J@O2jlP2{@vj~xY2nAQ;vw|y=xbcGzjpmkwU$vqpBO($hd8<_^G;1-Frv$susn_~
ztqd)&RKEZ1b+w)yAj`hxOy^J5J@2Yf4K_@$yl*dnDSsas*?iWh&PS3HX=y3sxA(HL
z3U+<oyqvsT<THAdp}L;KPJp^Y#78<dSc5!*6?GkSwklu;1TFgllS#D~jIW;Fxa~}P
zg4#sywv#M9w{N2_NBnHEbI7~p>4LFgGHb!;KW)wVAD8-JHc2*=R(#FJ@<yCZ?XS!1
zvqYK?8u3pL-r`4+{OJL~%YVb+F#2cF_y^M!3S5cF*}BT23E&@KS1!~Q+P%=+9_6Fo
zwZKdEPE?c6ZQn_^;PMk+yLYB#*_|Mtu<abls>CE|;h!_5-rv!;A;)9SwmH7hEq>p<
zl=eNDed_Dnh6P668D>t=+*HQq<~qNGU%k;0ZnQ!j>d-VX4H$cVph?WTfT<TpuSffg
zb}sn8W{{7wf)mZ9PdO9)Lt%E}xqNsy6hWsb3e|Lf9ZGbovQteI?v1wZ)Hek-8#e{S
ztrxyXG_w0VqZcJSGQq>^io0J7x{mFP;Xru*{Ask7Z0xza(nscneB*ggDw%sR=-GCk
zg^6C@Ai5UciQVr|mty+Iysp}$S21aI6?n0cR(kRC=609tXo8IW{!T({eIoA|)Q#Xi
ztqfLt*ciM|&@U^RL;a5j?ii>KFhD3NpS0xADvTr(Bh8;f{5)_w^(qI>q#HYNIqxr5
zcTYw<w{sjere%bMl5Yc+PDS$$<uY*N$#}fk4VLxr+*F<pk3%7mpEkZMJHJ5g8nL`l
z&6Ldm`FeUn9SLc?EuR10+Lt=XCk~L<NEq+<4fjXd^2=+1s(pzFG=Lw0hJ3Hc$rA7N
zLPR=u0({{=!onpaOk&hHjoz`?zeAK9?ucD#959A*g<0nS+M?RGhc(XYXe5W+paNtT
zT6p@_?}di{YZ7d?p|(<_r*Hau(_+T)sf6)vdOcLc?FfWnb_Clo-kETSI*;#hPS3ok
z!&I~g4lz=wWNVV1mGVM&ui#YJS(x1EYmR*!mO2k1JH!{4QLODbr?F6|h@@XE(!Mmd
zQE<Mm%DyaetBFr)Fxt%tjC1Yi!gElG?lzh4<Tumlt6})hqHfL|zUN~KmYn$ff8v#P
z1KvX=nfZVemEvEVYBpb{&tDM$WMFyYRTQ}<BN-F-^Mckr7va{O9d`;hN2At2{TAHd
zsJ-8wn7(AKjT#A$BcWst>j7lle_e%+q|E9;2e;W780;0=VX(CUcxO+a!}waLgPQe!
z10;zA0=+HCxSgrLqk7QLPE^hdqTCBoe6&RNdE+X^N1*fSlS9@pa_<#|pnVjj_#MZK
zvha@kJD<el<h<D`wsW1D;mh@2mSq}uN_!i};0MSjYQ&BtD30jp&f;*;)qEVAjb9tA
zmVKvHF1NrAvt+YO5R<l&EQr)2p7uqopgr`m&!98Mh~NW801{M7ZOrvISq139K?q1G
zixy>KV&Ym#PQcul1Kk7q#+1A}C5q^DyVqR{x1rF_wrolMZ%{bTvWtX|I5swub%p^}
z-C-5`^4c;(Ux1G&4^dcX5I6aX@1-DQ|Ej7Isd=TA;&|dpU|(WF+q5!;k7JK*25~QQ
z+SGMe#Df|rhhXy>@V$^x_v>g2dZ<C{S9A(zUCD5z^%nTphM9g^NxAV>a65lo`ON$;
zT~a}QtFQe{eDC};gj*?yZ}S|+H$YSHWAm%m$&3#+`CVkx#VbHB4Ii}JB?4Ghxu$VX
z`?)%A^889Zw;r~_>SM8m9=k4#3Xt?)x%f6s6vr6Ie-}$WoBkhW>OW4)|I_Zp|H&o;
zU=1bu_gR?j1MxqaBU!0XlkQi+s+u<FTXOCkx8ThnKvFhI!OHd%XZ@qnj2=)YC_2C{
zxHs5l2JN6#c~HYVsSsXl3Hv_yQM0@rE=oFm`&-j15g|qklDtIvjC6wEjz!{izQrJI
z%?^+o&xu_wte{|CLO_~tx$dJcmVL7lw<~)udkZg{wN!E`-XKf>y~4&3ANUUyL7$^-
z%Smn|e%zz+O-x`}G#!vtbCJG@q0EV`M)exh9l6vUEhP)V4M2Hw$AkUTW?7P$uIzbb
zRzv`B4&~N|$=s_!I5s}@Rfox&m3;Xs`~i4Hgflx*dnG&Tw|JN479=grGk!izS$9u#
z$9IUH>gF7E?7o0W>uq69Rd2mqUA)eV$i8{n@&3#2Y%A!PcN#&iVwM%-)Sk~%dGo!|
z`&`dZIVYHnVo6P`zT*r)9{w_bUxg^B`#v?sieFw<3$ZT;dWr}n{d^Q->_#Ag9b6Hp
zgV~C^6IkJeW|R4hz8ndO6NfpFk>x!+Qj&z`_Y#~d*C=|Psjs++zG7cV@OAh#_(+i-
z`<pu~^3JDnCfdBL^dYO-qFtQGbN4yd)9-tGae1w}`Wcbb>0Jkhr!W9&IU>rfo(Zm@
z_lot2W@}mz*r`bp2~3Bdl5ya;kA9Egz^g3<*LM`38Z-fIXi_{<MB1xK^>~yF`{!=E
z|LPs2pHjy{fo+Tf2d%0*Bh9TYmQ*RrO`1!5_9yxut;cJ(!foVuw}S`7Y8~8oi@VRf
z5~zm10gMOhBY;IEeq_k=YBdF#Y4zL_J*1H9uWE4UrBIfSOY6DS0Jkez_1X7Bvvd$&
z%eW7GTZO~iV17FGE8_fg<E=wa=}q&fu3H-h@T#!NR)S{0o&|ScuO<q1^~u9`ePbCg
z*ir7euc{TuyIuh0{)6}%lkMj%o<uuv3#L^tQp!$0j2LFy(1W_m`7c&#9P_07U(~&Y
zR~%p0=lhEw!AWqpK=9yhK@)-ncMsY)G)@8u?gV!T?k<glAWdl8o#5_HLo-G4&NI)*
zn!E0u_pZC{AJA2G>YP4x_TJy`XDbA;mGyYacvQ;Qc!<>L-?@{+8rsr!Pjd@~iuUF}
zO4VW?p~4)an?<)awWRt#Vxge;oIWREid{rnv-Y<6jK(6_U<i4TlYJseXp=4fz@^JV
z;i(Cm{G_*=GvLwlBVtaB>N>oqfsCAWblQv=Yks|>CzrpUl<nX3U%Cgq<n$Y75OOQy
zY+l~G5kwk8%u3EpCQVST>>76U|HKQ&-Bp4QA^8{=xsc`yC_10Kh`h64%x4|H^n>5V
zB-I~Ny<6vvAFV({G=)*V`IaVjN!>rtl9l(;8r+<e8u>QF#B-%xg^mz${B#s?{+J?z
zeT*s6Vj10i^@z_YQr7U^0=LH!N>>k`I@W^MC25`5hZC-@UQSPfCl*S#;^OnqN?h{}
z+kbeKKvxk>oU9@a_tv^?i4+C_#QCNqH8)HA`Ri~#cO|l+PTBP%5@D9j``t<+0_ZKm
z)`n!=cjG{em2ec_t_GINA*5JH+<ZFeOh0<O!F!iBgKKUT$bK%|yrK0tXFB$#%N|fX
zE9cs6!|L2=x<7o+CmN$iluX;rH<vwmmcRc|*TBYnF^VkH=&eYuOnT#N<|YX5&c;9Q
zYtms7#crdV5<0|Zc4)}^m+wOVll=4d+rt;9AL>cs&Rk|D)nQswj-mtwptQGD?``9a
zeyQbt>~Ty!ojBkZUazSyWd-%rm%=A6Y}(5RHe8aT7KB;w$b0Lt=5Xh{2fjtQZHng&
z9ZZYtkHyS!7w+q9776oR<nDLgHGz}aI@;bhQq}LW9k!<P!8vIxPZth{9KAR}ZZMl&
zp|#vOZ`WS-GP2%%Vi;tQ(s_1o>`<?#&We4eN1x4JlmW|JMR)Pw_F7A3Zwo$h+P|Dc
zRxSWNU4|pb>zTJUd-N9j`>meWf`sy6q63rW-5$MaojNyrgCUZFd!t*$-eKzt8I*+P
zOWhoEpdsq0@Ut1p0?7>iH0MM$L?eR#V8|tMuUvM@!%n_kZ?dI4L~Anbe#2(oLuhAy
z4m2f7xqqrX2<G=~Qc&9LP%JXv6cf}<xjTd<q+7gW-5esTWbpu(td}M^Uvyfq4txYR
zNVVNouixFOCa{kh)?=hB%#2<xW!l*6oMzV9DyNEG-FLZlo%m_hjW}JUswM=aX4XlC
zuHUDrFl}U1mwKr8`<a%kx3o33A<`0A;e8WN2^B-lX)K~DZ$03TV1!PobA*;wM77J&
z>#`j8(4mCwRpxthK=ErLaJ}8m@(V?tC4urCtD)^(oZL_*i%lCI)Kz6~ZBsP?6V|Mo
z@{*;pRNyRreJ@!ufrnW(*jz>{!Fz)m7aGUv(=D3u9zO4M@g`*bC<vY9S7zvTHz})9
z-!^6F9b=@2lUv1mKQPRcv|a}*ld;O%@%2pgGCD`@ZM6AY|6XiooqFHWb$C=J8!pt$
zz#@6QN+6vz26lFOvMTL3IN94mu({{YUr)J~fu$X*c?WY+&girkZ77X_S}8y`6TaW$
z!`kb0(h@(wW>!gA{T99D1}iga*zD=TT*-%$JC?mZ_pa@<y7nDlrQGR%vr<aF*&;aT
zND!$?dMzxafZFl9z@*Bupt;0t$VF9bP0ocJn@nJNB{BiU4KCD39_Bd+MIGanZFy=t
zV==pNRVU{p2LL6!YK7iw3&oAx=ON`E7+;*e)IIe<%{k<#U;X-SN*FMh`E3-u1`WA=
zhx`%(Awtb3TUZwx$aSHYu6_*?WQjcNhaQjRJrAVYV$|%fZQrF%dWTZfLxPq?IDXW!
zibTB!i>$R731X>^*=&i#l*4U;usi9-1RM?s0Bh}U*UZTId<k3d=NRZsQ#YZ9Xr>p`
z<+@9E5h7y$Qf{ews?9qL1j5<%GMhCxd$Mw6)QmXT4zoH*W{S68Je~Mvs3Y*n$|LAh
zBZRYj-La*pA7a^@c~M>j$$!Q7qUW%#JtH115f_k~6ZE4PxWlsZWSm4PZ+M#ZbthL5
z>1`<8O(BNNgVIPzry4L6xRV)aB;Jy|werc4&t`v>x0jfhU6JV`j{R(gMq6BrogMzs
zS!>=wbv;+&Bd`>LOxb6kEYs(-8=NeW-VPqn_gO!b#6I`>o@hZ!8K$&mJS%T<$9{H*
zQsxbTBhHuM=bsoUb0`Vt)Yp5ac6-G9amakJ>F={Ce~#lZUSwMl5shGgZ+-b?kiu#+
zZ{ORKI}|bZVEPj6+kpZjpU9YgPpUq#@wjXurr7ZobMWN5uxi+E?|=r4jU0fnSKDr!
z=Hol%7UHnxc`$2k<^zP*c;UCiei7Dz{Yv%Azm*7&j-kvk#KOcC;lz<}8oSPlSqx}n
zWWysqZmC?-wZPr5jzCm9s=%l_QfKK5g#$j!+}Q>xEqAYQ5-!3TJO0mK0#JN*Ok5@J
z=7!5RGdT{}csg>~j~1cZuWrue-A`kDEeU-|54QNRqUIlc`&dAgy{E`RbZw!lbK{DC
zjlgs}&<^O=r8oWTn$CaQI&}AnNiQNjXAgx32dbfI*Dgx3z!JHSEHF>8Dn;RfLActm
z7@{H)6lS&E3vP+7K!2lE5>#a*?!_a~j4~D!`C_;4mON6n3-2y%J5=?fQD6GT;WL_4
zpwdQd>08iASa6jsKibycdaFgSX3QMRF+R^C%sHdeH0CS!USYTTStHY0)RT*TDTXnG
z86SO=j~A^@5oIo55r0%`v+Ypz>v{*uBPdEpngtGVnh`z-Oeh!9O=i;i@HA!au23*m
zOiL#39YRhcZ&w`YM4$zKHXA<$a%((wDrcY1S3gCrdQrHFBi6{U_*HPpF69{C8T_oQ
zBw5$sV!QCMRpqho0doaV{r%_K%QMU43rQJ9G9qI|uUN$kzhCoQ<o7q(ck6wPMh728
zLHSp0N2MMm6xO|^Inb5Q8X<&B+8b;#Bp#xlq-i7eVNrXFj8FL3;fYHDc0-ctAx6I`
zDUE*+)Y%uf2vzznT^IUqLi^S^AXlu%#i3K5;&*o$Yt5N=4`awC172VI%%SNAh5gn+
z3ge7UyZ8h-TtYKgoduVck4{Alk>p$sOZB5IMr_7<QtedSN5n(>^^*@IoOcIFLqqFH
zTuO*jf{mnTnd<n8B^Vo59p1McNbU(T)f=90jJ``T-db4sg6^3}JM&fUo@D_4MY~7@
zyDu)I<%JFI<C!lDqaSYXxkKM6{SNLA*w}Xr!mdlt$zhlJ<br+BvfzR<wGddD+T9LV
zxD9SsImydpXsf0iZj%HEKnNyCK+}%S+Rp~V<)f${KN7$*d4@MSPxUzM=kDK8HV8zl
za)v_g*pe)emH@-pJvts_*Zcy8L<S!s>DLz}xUbuymMYWD{U`@EncosKT~YeA)zFCI
zd*2`}R}+S(yQ0}M<#rd?D2<tNZoi%w7H*vlgq^)Yxd(^-9$D%xdh=GJi|=XL(;&1<
zHy?3TLN47JCeZ<2%dHOF=U3Eqc?vBnQLOMSYKre`^GfOl52GJ$E+-t*ukVv)PH$<g
z2f!X+9G{ViIen4D+vFin3I(sJde&7_2s0zojniyf+w|ywt29t5f$92~>0kbkFK3EE
zro7nh4dR|Y-JjRgQ$JZ$H<zp!zL9--G7<1D-cdV5f3ol5&IpV$TX!q0DN*DXC2a%J
z;y??5k3WqNrWC2{Iw<oxp*^hknrScjRQDQNcHC$J&<`$Uy3uy2RvO>6ol3kMjEWDU
zTF|fDc~6muT}CW=tn9(ZbW`1}R8L2Sx6}acn?#@Kqt@+m?sDBMC(~RZ;Y)}2A$Zk#
zSuc%N#tv!W?V83nWhfk`3#3<9?^@m#BShS{zyp=Md@p3H`Kb33Mu;4OM49(4ouh?7
zLFZg5itTm82Y7W!0R`>VHlSBG2VV*og8QnHmUMVq({9LmOtCY*d|e26P1Z$N@E+w7
z#`o&Rpx@@irVJlyE~rciK1&M(BU%V&0&bRXt7ej_;I#yDzy4XdjjEr$k7`e<->1L(
zpcUM5guRMhutYHhRl7;|Ud$<B+^V@eAH46mo5RX^dzpCjaURl3#H%wff^@fI+<$XO
zes!|lZrr<$7w*T`T_7B{Hn%dJB5?qesiN^4Fu{EZkD)<gt<ejt^KA*k$5^UZqb1Wh
z*>}plX#Oyi3p`aY-M$1Q=GWu_j!yUD!2s8atduAfPgVg1(aY(_==&%?HD|Gtd_*k=
z;url<Chk_GXMBE?!`@0?@nxD*u##*yli?Mx)UKy*m#2$BC!e&+2QXv+v){nYf9id}
zT*Bm0p=m(K%7s*evh?$ti1jo!Q*4ESdQP~|;=n{RO0jXk-7$ODF#d&pGzLYK^zP2K
z&29o-$lJrv{Z^y4fC^2)1re45$9o-tT0ft1?~cGBeBY=pa1vvsgZ1$-@a2nO--NQ3
zm846;q6Pi*eXtN_FBb=%tl;N^BdWz@nZ!z2@r&_2X54C3$IQSS937nz6qMzTj{2os
zVrq82Ta&x4xhQh=2mYQZK9`uIyyX%fmyy01fVon*TdMK<-1aGCAQf>(n|qx^6HS@>
z<vw?Ts0j<7#u?;xNyaH!b9HjIPNkC|t5lIbUL>*?EYEi{WT1tJE%yb`7QqCz@e*ry
zE%?KcV+Y@rARiJl*F@)x4(8TVEI;4JvRITdBjl~PQ@<Hl7V1%LurtL~mI>YM7g+l5
zs$Q<-sB6+_ZeMw0K1a|du)kRT$vQABW%%Lg^L80H>8B_$?SRXZwKh$YW!a6suQ7=G
zj_(n34&RSR$zXaRmysdjt6*%?dDoz-qf9?_D}nI3xlxs;a~uQiN@dROFA*)Pl3zlM
zmLIu#`tS5<B){NK@_Gy$1GX<ScgJ?ahBx6awBU}RyyZgS@w@dQw~$XK&D55o;tCfr
z7ye(+&W5vW<bOZLlvw;FcJv{`hp%ul*P*N25JKxAYt1@4<I4DYaXwp2EW1_xU1}S7
zCFF%!%HgRr6%#6aV>MX+5;+L1$NjjIqce$N>^|mh;R>vqJUULUi|qY9$4BM(g+yGP
z?xdViKq|Or*Qa5?K0WrZyJ09uQTJx$(-e4cH$Jt@i|J%_uUA)8GrE_yz$t4`$x{B*
zSLP8LTqBJ0_*>~WV%UH<B0WQg`zbcuWlfhv@5udNA?~g$J6%%~f2Mf7by8gk{b=Gw
z2(HmIF{FreG64xqbUbyX5o6yF0PiN#_uYqC`@&*8w5o>&c5ClES^TFnObuW{er}tR
zzTu&@&^w_`g_|e%-ZGu6D!6w)6M}RyQgt0fe3m?x_ix?V;GT))FY{}ymXe_ri@U??
z*EM3YC-9E833<qJWkLKtTmw18>%y~f`FAJJqO)kqA@>FtyoG(Z-;8@*D8gsfzZ6+c
zgUWmAO|g?ZvcBMM=RsMk&Hdat3_{~LZ-zajpr%sNMg)dEGfP;AS_F|6haA*-St5z<
zxnj489xXNcZ7YXgUpdc@+2A9thtp?oe-AoW9%nCKO(gRj8QP0}>Bw<1&@oi<)+*p<
zL2dfP=N8^|bw_j6c%b;++Y|q}{XLp}3*U2<w@N0zX1t=WuF&3}xfoV154=KH3g-}<
zON`I@<*KOBAP}GS`dk=#FjK>2+3dT&gDE<uqwITz74^?u@sbgsOV{owS;8#CQAr}m
zDc5g$4%#bUmZT%TE@aA|qvtfNFhlX#%X4bVhG=N*ehkC#+B6L)9nNRhjoB{WRbO@4
zxfMTo(AJdXek#$g&qu%&X*diGz&7m>!p>ewS!m2{1t!3Olq6lLXF6|%jQ#Ef?|4*a
zJ2XUC)j6a%C(@fn4>JziY;BS8ka0-As5m(#=_5_^&DDa$qf6McQhmYa=&5uxrsE=t
zLu@zz;BA-yvl;F73gHeUftmAe=Uz<LIX)uroqFzg$=OR)j7elUuH(66cAY?&X|OK`
zNMh=~-IB&7M0PnhVdC=b9cDn704797x#~k!5=cwhj{M)`j{g1Ge*(btf4I<NLQ68e
z;DoZdB+*Ngt;WqNYfXxG>?P)p^H@-r0TGX*Qc;TXvqbbt*IDJRib2&Ef3mQ>I7b8#
zxLmPSAM>tQqM)C8JlsKVFep6TxK5rB+kPYXEvLa7nGS!eaKz>}b{f2!_=SZh60khn
zI<Q6J8;UojtoeyiF<-MMrE7fex%+-g=Vm`2#_p%Q>Z|^x7U?)C+FOcF3<ZX;cs4p%
zsQvKBE(56UStBhzgf9E^qOC#3w<V;N%Xt)6fWWtOTIK8H*HE;mj#x<nElxTqg`@JT
zu>k;U_Rdt9jvfT-4lIg6{SbG1P;*(eQ{zUoDE3~VFzr<K!|Qv$54I8?jxDCE!0enA
zF8?@~(#c#ReVEEyZAp2!tJG9r2_jtPbXk>yI)|);)2Wp8Ngnar;6rf5WOp$j6b97C
zlOLnottd<&($=SfuB2aG4GW1A<)btBi6w=$^=q234Fgt9oE-b4I7D$vcwf>g4$AjF
zLYtyhWO<SJA*almrG|qKrG(x^mH~9<F@5!Q-u@Xcq6#yxJX#)57bg{fo(Ra*V(q@;
zdf<|_`NIAyn6xN)a{Y4UYG?D<2!&(b3Xi~+QTa68{BH9f5|{nZ3w2?6b0mi2b7|F6
zX(_SW^Z4YePW$mI{P98?rCPCLN^ftCzuFC(pX%7$pOnAUJ-^4pldLEFMyVI<81-@)
zD!bJ4`H9f$%Qkk7-I3&JAI1KDg*WpxHaKU{I+I0NErB}xzB-w}=e9mK65$30;fpoA
zzjJ+3IW7@Ys)_ln?jY6IA8#258CGZ~xMdAZuG17O&-!(2-R(t@4YdLoUnEeK2tU0u
zT!>n$a!MYN6Ro5S%5Yo^%s6=2d-yymUP$aGN?6d7!-1~CqEwaAgppE%a90T>qy7B4
zB+~dW{2`VOyTk|q5B`&xh^u}5f$>IEqPF?3Qy&L@eED^pbTseXQh!cY%fGS5)=w~&
zke8>sspKU>ZsGfA(AG!VwN=ocuBo4z!+ndqs-Ia-HU2)fAFtonz*g1n@>;W!=~UMz
z&=mqXiskh~{&?R$bmp_d?Z%?`BQt+z_io!y)p1%~vouS?a;h3NNVGkR{z20*QkO;Y
zl;q>f=~iK4?I#<ii_^TQAhOQ}ss%>2GatVnjObEgNMODhcDwQpk9S4P<F(Y6keLz!
zs749Uuy6~$rvgb}{Y}mrpbRF2F|b>#!WY=@jvFv1o8<vFcHbDvl|HIL-fl86?C7xk
zejbJPCby>p)h>(GE@zZnfZVyDCkqsYQ+ptS1Yi{<j>{V=VYe;rLkvg#4vx00G#nSt
zs<3T)RC3jON^f=3?z1`G*r~4OjNUio%{jEep0fCwKQf@8{CcWu2o=Mcrm(xdwK2L1
z7r27oW5|TXkxDzbk|@B%f&`wJPnEa@>!y4v5Zr>1u#szrUE5PiT={jc9-2U$DVp%L
z?JIt?zsF?FB;@W|Jth2I5nvBZ_L)1%CJ^B1(wFQpJzjcVc^j`K<#S1CJ74e^PYAQl
z^wo9GgfO72p(!pa_sw!_`sW(u)3A^(H69XwoBaE^6Jfz#JDHOgBE%(K-<`BG?Ouev
zWRH-!-jy85-fs;~ZzaAqaXQ|d;SZ(Qa&LeXyz~vI?6DqZt$JTbg6D4+JI6%0Jq8td
zu|0@$@6t><aQ-aicRudQebcLiGLFDt)Tbp9?r7d^5UQVvy13<|YEE0P+pu=NEI-lB
zl4xzVJe%`vyl?oiOq;ol{#!<BX$fB;U?<05th`aFpZR*yYaLOuNA~S5pIrvrjDOzc
zmg=@20k^v*kd2(C5N|J$X8=K{_kF|i`5F9?1?t$?{OT|(ZV$cR!<{)1hbXwUw|jy$
zZ{Bn&GerhHY_R3znj*u!h7A~DeKZ`PM%$EN@!iFhOltPkPkT9LH!Ngyl=E0`c9+>{
zuEicOtT=-ez7#c+_*Av)3p8>wQKnE(dLC0bk(hy6z?*Gi4|%aSPswf?Eoc_>yTnjL
zCmvG<v_()@vaLphHXkG73VMgVac(ckB2_WO)S2MPiEnnoFM)}bJTjbD#*U2OJ}(Co
zBHeuo6MM9I*&2{oZy?hk*7`}BT?}ALjN1~v3k}2ZmX`zyJP$jj|0fiZ>maV^HYIPj
zGTD_zuMr<NUKtioV%jxl5>yH3XAzu~lrK}GZR1O7YBw+4+S`b)t3OjS5Qp)uXJ7fF
zzIsDz<U^<mX-gU|CJPzrG49USTO-^s2CsOMsn__NzI?vPDsl7c!y2VtfOLq^r(Ufy
z``jT+wAg38k{cbu-@~F>aa?@pkh2BQIc$zUl8I>hufk)GR>H|q$+^i|e@>X-<IX=F
zu;bRj?xGN^l^r|0Fj1I&`%S+&{4^8P8I-vY?3Jsti~jqu=wf=nY2qh&L;KDP+8_3Z
zme~W(n$|Ur?<pM?yKAW0@AQSZug-j0JbvryJ)aYaYeT0@<dt+mX^QkRUoyl=9>t;N
zo4|*|dVCwOy$pvVsn>Xi=72IXpdNeq`*Tk-QWcSiqW4OiBi$Nf>CB~{9FYlRol?+@
zak6ck_!`!e?Nu<i_1c?$bhkJw$MJRO3)$?rq{Z!!b4zX>VtJWh*WLP#E59=7H$#+F
zc0I~2hrDQjrhjK=mcVC%coiCGvYIP0?6dafdqYy><q`>KA8o?z3P!Z_QH&s*EKnOI
z9r6eX+nv~oc@?MLoQ=XWONheTjms`6I=nU!uJ)QdP{Z<aj`C<`v*3J$zV&$Ng)g>u
zEtzU&>gUb-V`4jaMZvL|kS?sVVkh&*l0h&u6H!l?*xW-?p1K&Sd<af=uy>%C91Mr1
z()`0wGG&a1fX5K@-upefikm*TEff3Q_Uy&$VM+9_<FyuIE}f5V6-rOVC?`7Y7g!B5
zf@m3j4llF)HLvN*Kal9W2VyH4_Rk(ynk|tM=>gDC=Jgu9U@bJi+ok0ULr3N%tU4po
zpP4Sc({O8{cCTj{_bto>P*<m&41o0o2;inB{D{)#;ro(A@Htw!nVrpc42oA`YeoZZ
zM!mFu$YR0eJQ&=?b)>lDaKdxXS(2?DIpOnm)fTtThm9#`Hb}qV@A2nw`j0AJO6va#
z7yoeMHL&J-nd-lZXn)IBJY1%bzC^VE%MP_TNY~$9X1Xk5Tn(s(s~`Xwt+4)=EYI`d
ztqo*Uv|{G`$q@^{GzF;a<Osec8unZt!jyftpZ_Vz-+5Xu)-h*&?jdAQq`t~WZahy&
zRk^%rZafe~CVsfP+Uea%7*e8NTey8YoFb19=3oJvn@F?K{E;ydy^v=nFC({VG){OA
z9Ap2C@y#U2oLqC#)jVBu(x<}p5jyu87jXpXLU^-l#UB9!AOIlLo{D!h(7tS)L;?~D
z*uG0HrqLu13!A1m-R!^pE|+S`aA@+6L$-LqES>LDl!T`4t<e9Of%?Cr@&A3j|M{ol
zfAt3d##abT5(`1t|2)2jnX9Jkn;?3a8kK#z-4?(lRR&1m9p#S(t~Ma(e>{J|g>JF`
zdRM5BI$Yn|Z3a9)F9U@?4%1?NGkwiT5A%gf9Zl%-A1Dlce$8Lv3c?&D?`|6R69O$A
zOmW~9f9?=LUo!Sbha4>-6ZX*<wRosp^${jFhBVD6y!_1TR?9a8JNQA2sS-hNp9Ztw
zGy^l%n@#KeOGUwlApf^c2LG?WyZ?>QqC8Ssxl?m|(=h#m<im4F)h+3_x9MZ*rvk<N
zKStt_x`2QE+5R;f|C=lRue&w;e>uj;&oWtmL#t`gbQ7G+N@6H%+}r-)=wC_*9R2C}
zVeg{n41!q%oSOd8Ex?q%-4O;+{F!Mg{hH4*5*>{1!|rQ**4rOv#zcvh*Q;^Rexx%U
z=rf~JijYF=Y;sulV0|n0@I7~a7D+kSUA2P#O7oBCDfsbv3I;dl#XV*7!adc8$@YSL
zwX}H|b8h=3Bz=ghM1|}ot+5U%p8afOKQpe?Q)!dYdOcg5M+(t@gC4wBQ)XFJ?%PXs
zezY`p(D7e!M+Z9%J_wd~S0(l3hEI7uJn`SriFa3yKzGy6#t<W1-3kR@#{o%GKp66U
zt;wpYS0cyO=WVabs<_pGCkxRGdHUKJ)<Tuh6uy=GpJm_drpx`kXz2FsQxd;7iG!Cn
zw=o?dV&4e&x|<s~KRpr|;m}ezlR)UA$ISj_q_bZN|1LpTx$>32lz*$$S<Pecc{nNe
zi)7Z!pRpjy<=lphH_o@;H~#FA*Hb)quN&L_14FgAKlt^mmctoL^zXDvlko%4x`=;d
zZ6_UD(xn77yt%*HCW?C8(#ozm;8K9MZO=ema_7R5CPt#K`!(xYB$uNe9Gs%`X9XEf
zxnw!=Y+(mfbORMO2ct0;7ff|7?{VSz+BeFt%{EI+Dlkb5SGE+7l@edomX|2~9b;^{
zPFB@DjPkfYh358vodH*PJL#{OPE&UqJ3uzawXu_S)-`}iGWe8GL8a6DyyC6Zj0X>0
z8nbxYRRM_BKFUir%a!nW=(AGY`h#RSxV*OHx#fEU-7f}VC&y7fn~tSh40;IZ@uF_o
z2a$e;-bTtvDuhG)Hm;fF**1f`gZG$lztW^dGPxH>^f?$fV3}cQ45Wm)26s(A0*&i|
z-wdC}5PjKTk-81%ksD%`Ky>hE)xqwT*8b!tibH|J95zG7&s56fgFXm#VhqfH%O8M%
z+T@O~u|LbDBnn2#yy*I(#WVDMwKl}E)rt&R^fg+AxvX)Im|<ryfptDg#}k8|!1dgb
z+utVP2UFyd1$J+&?ryBv9#(pc-vedwDm1PPuk9)EM<qA=FL}8?0kBzbP}R%pW}R#L
zqR?pjQci@{QpoBe#ZUT&Z%i{UQmM40D0rF3OzMsa^*+=l(4L@SRMbgJkt=R@e8YnG
z;Y|T%>rY4|_x+Xks}7u5SHGK3g~yla=e6zy0bS%eH`J)pQUBp;G{uX+p0jtig2MA1
ze)?n1!Bk{(;o(&#uQoqSzLZ)k(jGD9^^MN;N5+6XrkA=Lde_SZh7NP%!aT_1_+jz%
zi`hNJgYGh>DnAWX9Cm7X_e%U#3!<wLBA}$9zq?tJn*s`ndiP&BTW=lkU?)+>zuM!B
zfsZG!QR{i!4@=)t|C$_ikk#_>J|U!BT;8E|&celY6r!<f*N?cCY4dnz@>lq_rUNjN
zt_j=MDOb6Oumgld3ywSU43B;@BlRL?F9@ser^|2+NcY=;<`SQKfd6jSrqXO>#g(V-
zpV1!bUFtVKrr3R68tB3q9sTI5ZELiC-kL0y5HfM>YBS=wqZij-U%wOr4`^#}YHv4;
zxXMVzcx6V&cr6@w+iMJ^k_0>!=M1Y+XL+`A6A1m5vqK%`pjD{*79{KUx5?OSKP=0!
zKXcIA3Jf*&7JUhOaX~!7gCX(!(hw<eZ7$#2xFyDV%{0npA#cs%cvK3clSl4}@`C;W
zAL_{}P;-vozo_%QhiMsz-rHnO*^VNOlIL0yP7NexwRv>N_2a8QJS2*=+~gvx*J_!Q
zH8TcPUDd`$N!_)79jn7L=xB;%08f(KeTEA}6&A=0m|yndsVM(hx?Dza2cOSbhg!&>
z2hSWCM-^s={_10Sqo#(-Yk)3B$65GJG)Lw(>#cpiwjlC|^*F2cFTF~1i}9^^dS>K{
zcv#A>%T>#uf&|f^&kEy~u4bAV<u2w+IDwx7W~qh7)Ha4FIuIZ4iopgdb<fFDKMCBO
zliJp;L%s%=>jOkmx|w%XUOLYE)b`ghj1Oz-kG2;4QirqOta3TDWV;$kO7seZxSC}$
zQBo6Blm+0Luf)}49;@Th=lruhj4i2XUxUn}Z8e9pSd}gcC}mwDo=xi(6mwkz9;W9n
zm)`JrZ{h6EV4Ak%*yo*W4GSgtG*fPzp^Or=JQ22nFtZ%$?H}?ZyPuMq!Jes@RtodJ
zhrIA|QhuDVlf{}3784v(>VFYWIAd~@?|8|LA^EXz|Ci8>{o??kkF<;m^=U~PZ#T|U
zg3tQ5BJyvNLVOANCmPX9^JFVtHz}4#n)gZ1=2RO>Jip0y-VnNR+rI#{w-+*iptgCD
z%!=i!2Sn7mT=m)k{H8*j18;RqKIcEl96KZ`2D#YPV;0Tq<1}!i!5J)aPvgX6-$C>R
z_15Ny$J`dy^G@5=ufg#R)w&@;ce+h5=1Y&QlPiV()ALnS$>O=%LKkaRWKT^ZAN3%o
ze9QGbD>1y#cYJze?XD2T&GF@{g?O;0RrI<zGxL7*K2t@jo{(p9<C9BXfk63#axuPA
z7zWD+t7!9|3+HqNsqN@w&;h-4Lw55XP{uR-UrGWC($@{lyBoWz;eDrVRYfY3UA%;N
zAs`PXP5=48u-&O-NXzTdeeZP0ohWzBT>Gu!ux@u+1@;}$dK0f-ffXFj9NNoZb3;C6
z)Y_BQE?KvmXX-zle|bnilVh!fOfuE%muFjf%V640GPb@+$gfb6Qj>7G$zI)JSQwSQ
zSl!EM1Jm}A>h-p123VjaEXlLe0P}OG&|FO0ocMmy7*xE#yXLZc@@82P#$u{Rnqjxl
zHlOH9>Ne-B7^HXrt#6|nvj~SMl+Y5wN$mACmY}<tM4cO;UQkNp09BL?LJ?+VI=#S=
zlK8^R^ZZUO-=_#Pz47ZV)Rb#8zKR_C`eVC~m)o|}FYi5y3;T^|f^@jBi`OmIUgGID
zg1LJAL`p9mkE-(BWj&!ZRUf^9I5=P8voYaBt4ii4Sn#t-R$9zS?@E}>rH6%*SpHPm
zHRF^sSVX{X>`v5nH_3xvDI>Bb=h`X}`(O~Vt=DJlNH*zgq`xHTS;x(v5D~ieHJOoh
zCyfLKX{XmeRAO$&g4%`KbWXaqkf*X@&hid;n9o+ES$q>aeT}Q4;G*8FsLprdfezh#
zZAQqXIrLF2Wv?XSl~fVLQXw}Dq9iS1b;f8PG^irY&v-cLinD8Gv5T#gQt!Co5@Y3&
z{nj2M^7&~5qDA3`T5+K+0dCEdkO+_6rG}HgPa>=E`B)ILZE*&H@|rAFma$7??^z@o
zBwC$IjD0p8Pw#py<%%Jh{XS}bX@=%I+wd42Wx^1_7+Nc6Y=C1HXr94}b**4JcfwZ4
z*lI#5xp$CMFPY}pptEr|ql(|lCoA1M_%sm1#qknw&b!4^@WC6#*4()9t*ZQt#`P&Y
z1$?7g3i7OKUZ=hF>b4O(DU|40&|=@5bx|BJpH=m^<iSKXEGM@~c5uG)m{d%2c05ob
zox_Fht$Us*?g>H2kyGo9SKIoVg$6@63hdVbQedIC@VAJck$1zy`L$Y*=q5(Z6+^9d
zO1k7I9O!-{<)sI;E>TN7bHfro&A^OG<j`2}F7%s0w$;6FJts9(VabX$<;zSt*du*M
zQqY+sB{1atrsy_t*Xjvyq{n&^@s9wlZ_;4eLg36!kf*<Gh8VN&bc@E-*}E_e0h~G1
z290SZCEi1J!xSTUlCM++#j&ZKVw@o*Z-V~I{yDcP^3Iyj&D2u0AnN&JezWMRZMS}v
zxsVqe7GHzkW$W=_d3FzJP`e}sAq0FA1;a<`86Y0LR6PwS<#*oY%<;&E>IXM*@vgy9
zOU=!_pGK-yJo6fVDH-<p)uPg`bskwrIm`(Zr=zl&E&lo>gpq!yzA?Y{wGNh&(6;&d
zyTAE6WJ%6{fMd|TaTYGl&S1Tyx&5Fx70<vH?S4kf6V0S1*a1{W!>oFVyOsWAkIlB<
zZu1<f*RI<%0NZ`pIsAAo+N{|$<0X75>|IxU(N?dJr)>FfYNM2NyLODy^<Iem^@dz~
zXX@I~2J8MoW!-b8!$IpO_>;Bmg;ye0E$hAd6gQh!ts{%yR!<IUXn|=a^G@xnWnW*I
z;#NDGb#%S6>c|<gS37kP+1`Yve4MdfVN$lH8QrYJv==6~kUkyTJYm;;rD#EW-oLK{
zi%I~eE&`t>mHNpSV5y@|wcz)kS8!GA%zvyXUxVWatG{-WylRBWVw>sgU$Xx?HTA>H
zoN30KG10C7Sh~`)&Ws4m?;*kEEXX9Ef9J!#PJXes_6N%&Dl--X@5m$a-LgB0RGz(h
z6I=I{jx^mOsrgOgYGcL%xuYZzawzC)0r3LPO3c%$4454$h2?_cnm*WGEOHQ@svJKx
zRva2^D-sJOAcvC$rq#Q`3&)o@j-%~o_4Q_Weo3d0U$R1gS_*r(6-{5EWmsU{T>MpU
zkbRvH?BH~GYW32E>|naNIM@^xUcF1PmXheaK!?E)VP~+xxu4zQr4+E2&*1Mlqc5*P
z#O%4>*o<K6Iz9jHn#;M->e1JP^nSGkb8~m{bHQq<rLX6!`wJ<9kWdd}RaezF5P~po
zuhRtEA}`MVa^3XZpcVbiulCnlpTq88yItEP1Rk6W;$=VLo9IJ=i(j<47Ry9~tLN{w
zo=-ft*k967^EtW!vLeM8^_JsLgX*a#3WAhFdJo<2fRnE}+LH)tg~hk=3;z_a>Ko+D
zMov)zk-Pf8_-^F7|L4sL{{%1pkGmd5hzm60u<ABc`3QDXi5hc7CKg?ne_J=|Zq%YX
zU{wEG3A9E=CZT8CUFz(WrJQ>F+3r%T5R={D2Fx=hCett1lk&hfA_=*j7&09XCwCx~
z`M26&Vau(;5N)~P^Xl<G{JW8OH7HHtvW>>y$d?NUU^7!p*lAYW0FzlmogcG8y=D0O
zo?5Uo$2Nt}2Sjo9mS_WhY>k0Tg^|x}d~EzMvZQ90N$2r)@L$7ka5-MRCF%y1>CW0)
zt#3z~`&{1Bw6ol_ILDAI8EbLCrqDPE!bxl)e&{!pP)0}tOG^0gc#VFUnnTzotmsZM
zl^{eK-uKyAK#K>2N3oX$9@r7}rf?(d{rax*IEu43y7Lzi(?;F<-WXbOM`R6Q@_+-U
zl)b(>8bTBKKe2<l+W-m)kh8%xYk}N=a4m1&qQ72~MJ9Dhp#wsx8+nfogHkW%Cq%<9
z$Q8<nbqyE3$T%ag8OU@gX1k1R=_;+^zBZaAxn7g2mQrNMF3%qS53HFm9-#6;(Tyr`
zuX#!9QL1Ok9gDpO&9>+Y>~o5~(qc(4q=@+L13y-IV?icQ^c87CJn-RMUKm?`El#_7
zk7aq^_ajGs)2q&yOJKlqMs6m$_)Zr;OlF4_3%nqPySoE587L)6@=~bt@nk}7P^NXG
z89v9wrLyh&fm=31O}KqXkhOo5VX3PbF4JSulN)2X$WN5LFS~jy+g&T-(Mx#$6bU6a
zCRn-)ha}{>1M}0$KCJRp1@^|vaGALyBkn^Hq#+C@Xz}Gm=<h#dvqEbk%fiWUwoA8B
zgsb`0F!gLZQh}n?y~bC>>nk1aN_G?!UIp1HWgbZ@ij~(L->-kjay+)F6q1x8Y4VEJ
z!3n7fnBC%%cdl~n7VZ+`#LI<97ngrHSodqwy!As_5#0W)1e;99g}i-#lbrr1nOnF6
zMCpzzyN^q~4t-d(&cMR(&Fk4e(X>HU?<PB)A;lSQLRsj>J|wFI^{GyfjRFS#SR;xj
z=06`U&1mJ_Qb_>gx@8$94SOb0Xk)l?xK_*aw^r~f<CgkB-GRd$Y6NA#ckIj6=siVq
zZ-a=>aOFQGo?br9m%~?nMOIo(A4T5Sfx^Wiui05rF2(-dJ3}v!3@LZ&XyldR+ny62
zB%+aqpdB}L{}uMNb_vwy$FOU5fU{%`3RI6y`z&lm(J$G2^~H_&O9v*esmIDkvMCDK
ztM23Ux6>!)FCYKa8lV92M?z~IN&D?Bmw~tMbBe7Q{AGnVj(6u%|Aq*dLEjlgiK`^k
z#g6Ft-PSWk9z&G&nxqwrwM%k=qN_9=Z2AM0N8U>4);!$4h7w%{tFttK@Y4|y%lqW0
zNQMOCl_%*V*<;H6OGw<<n#_N4dFm44_mP3NdC`x$dW{3d@rD-l+n-H^{Ik{`h@qx>
zD~q6R>z02pk#uNASh6fhIg&9~IJz|PHv!T8cru4N6LNJ{V|pct<d57`ss~*fvh8gT
zQAwtfj2*J-btP=ySZXJFus#De+@}wzfi>35_GtZFCX>w!mv7!)ShN%#atcMw51SJb
z#!1wv>-HW3q*`vaCzgdoQq5z!6hvA0ryr}789}AEWSh!6(LGjxG#UJ}ruzyibdSxI
zfA?0QNbp)v^DTlyRMStW^ToB`{6kg_Gm}4~<nHgk{o?VY>%01QUjpZgd%PK@Vs`%|
zq*MkRClHZ;sT>mq5Bc;{;_jDA#T-k&T-W|1#o!DG^DGyNUq<@6y^pw71j6e-y=!w)
zXpKJ0Y(}<s%H9in%Jf5MD;z7bG5@zK1OC9=^$Hq?OZ&qg?H|U*@ebGiAQ~QWE4UM6
zk9>&q5MK|0<_UG}SNlcgk^oJj*Sw<35UB#~`jU@n4~VWaZn3Jz3uP2_AA;P%CH?Jv
z_yR7Ab3g6L9uPbNLW~GCF(9T+YORxtK=KdbT-zZj{RouM^K>$S{$x3!Xwyq0ui?Nt
zo;AEZK)@9(;d4Tz6|M1q5*t7UdM4H}&mUtI`{I{aGod4V-@4cyO)<S1nH2w8h@^V7
zuHEz@^o)YNleVteEM4_wVAimI?8xPrTa=>K`s<wuuOK^lfF;k@mgvtiAMp~P^{Ow5
z*`X))1*7J5s8;BUk21Wmo}~63>!<}<&z}PmvBr|cN`g!*4)`<Q!{J0gqD8^$*sm^%
zEMaV|g?T2H<DB>|>i*X!3B;qeQ15UmNkmn9XfOrPoFX-xAdps00bO#F8Q<*B%GEaq
zTFvANzV;6XGCC7@OPG{`QZ|@HL>`yt_-SO{K2a9{v2Kr%;{EH1ZmZO~FxBz6o$`uR
za)l@`|2e22V**+W;vPw)oaZ2YYgG+@M-<rq`rvj4oD^4mZv4<1B!9m-o#8O6y{Osk
zigUpTyt$BoJ-Lb}F_osZ1<uWU8arNJ>Oq}+x$MB=ws%rPzOuFe0`C?JyC%x=dM1*I
z$iIg*3fXB|4F?YN&pl1S@*dQnn9u*^ozZ>v*;r0wHD9_@fn+{icjjlp7vHV4>&SW^
zR*`{v?WmzDJ)N-vkmUDH{)9q~$upudqI9l>L>{=y?8R!4_s$-yrOgoATrN)+;@c9h
zIl(z<VuZU!Ywn4FH1>44k)IA6duy)g_}8-@x8k^df8&u;K#jI+H5W}j@j_*$$<mk!
z>eL#cpneTxozUorEtNlcSNCxu%G494GJy^i-&Vg0vDRd0n|ZV=r!tcfoQ^l9@%aJW
zFGM>%=IKt$wiC2<2a7qR=juT>+pJ+-ZP+%QP9COOC!j@b82og=O1;*!+HlcaC%o3C
z(}cJ#66E2rm+u4HC)w>arX8Z&pMJlpk$>w9O*6puFxxmunkR3#)_NJVt{1n>oA}Id
zFjbiHVzaNuRn%SZaJJHw9DDO8wa+YX+2&8*cBjSNOnz)3$6hX_?b=N(`quBdq;9H_
z`&)BW>CT$)k*FEbCE;}TQ{gGA=+iQIsd&bgRi!?*+Z;z80PlP?T>fsV$VMZ`m&oY`
z6%FNL?9e?!1PO!8v^iiAs~S3u*b5aF_mW~+!V1t|D6<{KcC_{!D}2Q*qW^{K)tlvQ
zw_vUXB>UNR%AD$&m~}@3qMxbw)UKcJp43@%@y6U?(Z7$J60I5Q5*_6K-u_m|MTWO}
zD0IEM{wK=0WMcvW2ODBapid5BwM3qS^YTPiSB8c3{Ckl)kkSGoTd0p*1SwXCkJLHW
zdO<eu2Rb{m0>@0W@vxot8jO83=8wBTOGv)hyl6B}8M5oN<yo-uqo3_;pLMF{5npR{
z1TPkx5&+3A+s$8*Fz+K5yNSj+mcVT37c(X~2_Pq-y@RXNu_^BNr3HO8^%=a%NQ-0J
z$-A6ptIcFWT!uii0uPPy+`*#G>+1DXfwGLq&M9spZvk+R08VF4Kh<fl@4Sw7aJ9Y=
zu$e#V5~s~FLwd4es%CU6uJ#FyoY`Mf&c*g|0(-<yU+o#r){%E^HQH@zgQ}FOU*!ma
zz8RkXxNd}d^GZLZ7%=-y?f-Qwhf{04uSih?VctEJfx&rJuA?*i@vOw%z?CSsj2ZHe
zLeeeTXes`CJ}4{XIH^F$bzmeQe8%FY$ULJHr^17Z8Dc$*K6NdQ3|^n+QW@dPRCOFo
zd!n<X&W0%(`?=B0=aF`@bp59oVA_8G%xMK0aq(H9$<Pu+bYpYplGM|e7UzBbbh?lA
zG-PTg{Xudk*E~6#(*pi<V>aAFw(&lYb$unJQ;hwiZ>2;f1Za15_q-M0k9Ckzi+W?R
zGmtbGqZ7f`kX>miRDti;6t%~v0QURSTElU^`mi;m9vgD|%?xS5tzZEpdLyoZwOL5O
z&;Vr(Xxjr}Svk<_ij{VJ!f0$^VLxqk9>=w<&9J}~2UVvta7|tRhBcL8J&sp|JMAU2
zh;6hqfO{-OqC3?a6Xr|YGc2bxFW4aB2BIa#cJV+E(>(exJOxkF!8l_#eNNkoopFc?
z@oDVfm!_iVAmiWR9H>fM&CBi;@1>xjeFIji4VnF~`c=TI3qxG4Vkx(17htsoX~A&Z
z_(K}HqV;v?I>KDsMMv$Mlu`CJ&dbM)&JB#%WS3P`r0LxpLh99eYZeJZ*IOB7VR0Fh
zIt|od=>9k4s>m?3VsCWfaOaB+#xHOOu(05ycZRe!$H{06uo%4;D{3ucCinQdef1Yw
zH9M;J?C4L2FI{$6&1W4`n3gk|7@-sbhNf<;o&$>7Fp2o`mo@J;Lue}4aZyd9ogZjj
zDp`6p_5e$(nCUJ;X$RA30_~m+6JU7xJP0<6&5JD>_<?sZ3GjAlig|$Axe=rr_|i6Y
z{^tujk@m1JeEw(1ZipZ80|g~G_%`zY=k-xGpb2@$S4$wr@Ep6?(Z0{A(nOEt`Q^9b
zXM=s%^wf6qZ@y=$z7T$;nEdKO43`wWyLbJuZ9335z2x*PSu=XUSO0jKzXTGR7G&KK
zbb5H+@^I#fk)3Fe&aM4Nwz}GJZ(hmTzm%-U#L^^^Br(j4mWvrXZ{6Cz!k4Y%xU-30
z!}}4w{sh-1x97S`8c)=i$1D7fv9TPQOq~b!x#DK~^UXgr72)Ex&ob^931od8vDDPo
z{)J@uAE|b8NbuhTwS0aOv?zY>z|)~A5tCHQN=TY7LnEhfg8gq7g-LE)=%uxn_LPto
zoEnCl{!vL$=+}vN&hor`;Jz*~2htw@{$fVPs)~+RE~~f88!XSL(wSQ+r)bFWj->?L
zQGK}hA@Y_Lpb;zCm0;?)0Wex-r-fRrH7XUhxU8j)!FM>FPV=|hl}}~sn%4O<II*i1
zXu4fudSXs1A>ygVLkc8iXc4Qn0SBFN(d#?>d81^do`T2=buRN^+0K_g)eD$J2L1z<
zYgBqjUDo3}xxVsH)KxAWs~&sBBKM1HJx0qfjuBf3NCj{_$&>l<n;zu0Dd85g`+&Rs
zJxSO+m+v)GUlpOA8jCyiwx4h_-+M{e#d-mS8EY42iN&x?4Yhi6o#A0}m#t-S7Ra>l
zS=&S`eOw@+qigb6PviEj=1EIDfKeKr<dEw>woiRfRj7a*<8`?&Oh;C1rP^Zyu?@%r
zf9s=j_^6ksSUi6o@D*k82c3X0(BNFKl5&-{PJo`!;Y|7UO?w9Y#-aGhk<4_`YcytW
zcY3;;<hxnk_08O=z-%6x*H#{6v!Nc>jBy-0U+*l1z+71Sx?#s1ySQ*D9hqy3?jc76
zoa4S*#4^27f^5_BOX$0uu<}S%wK?z*#aHc2x1RZQ8WEwyoXhjPeDNPDoQtA(0pCmY
z=rFO58OyF=8z%CrMRJR^kK~abIL#|k6x&|IlYVaO{yl6!{n*VCd>h3Y+1)6mvVF+|
zicxj291GiGM}`m0Qk^WDpJ5-@gE|db>KTc+5ODx1Fa~vJ9EFwykIFTQwW4~o>sYEM
z#}BX&J`3IPuj=hSuoW?49vb|?bZmc|fFWYUa*vk``9!Th+si@Pp2qi3^mB5Fe-fb_
z?qi46T#qWTD^ca%g6?qkqu`Z>bJ-3ub)(~JyXa1dj#&p~eNg0E)Eg)?TeAd*L+o)Y
zeQ;l4;ZF*I<xc0vm}ekl6rWJnXS=w<2y@{vX}98E9X(B6xV-1)58cjxAMp|$m!gWF
z#8$$C+lu28xkW{F)!KBWgICESaC2h!PWbnO_v^O&-yU<&B+iF)a4ES;RMt~cjtP1b
z<YU?gY_QH6Io!I0%RX9MWMCe;xgipI!9}s}Ke>z>?CT=Bp%5Xiu|jV)D~(4nn!g^f
z6Fo_#wjNM17y09hMNoEAjQwBQXJr1~NI)J;K+aG<5;qE()ztPy!NJ0X{2yD9+aiKS
zvH`6qT&{dmTM6Ds7(x8J?f1~z9g_87?ef@7R=KBYq>=VL-{tPz+8*>w#jNE{S;wSb
zv~7xWiZ#0hb&uP4w76Lbaw$V3z!N@D3qTm}XifH9(x5ALQ*G()r!X1gi+EVK<oSW<
z374E((Q|ceC;?`aU@qX0l%kz?C?Roq9&X^L*b^?)V0!Z;W@{Woqd|Ur##^k+jiwPG
znqTM9$jFU@zbmtnX`;==&h~?&$`=aJol6g_JX#9AC(OFilOFrH;yQQJs6jzeB9T{y
zD(;0}D%(te4uZ~^`wW+)Iu3sXNUb#}M+SkY@0?<qq>(9nhO1x(W*-x2?uRMxuy?{D
z%QakKQ-8Oj$l}A!-}rR!Q*5%t@RJO#s<kqnE2B;CGI(Ug$<$Eix9~xLaay|{>FLf~
zYx9qklCI6Zj=6Ul#P0g7C1JQB0vC&H`jZv-5L#L#A8psVdiXiYij`HUBJhhd5|9C^
z1<@7XXX7?XmS$dWJF05ZXB8gFXGt(~W8>1sE2Of|xfMub$Y8t@-+=;DZ`~*1<Pio~
z9l_Mx#SF~}`{Ez1dENL9Lbi^8?#Kk6S%WTCE#25|mIz<|#C=%XXkP$Ce{dgDTd%lA
z#+7%r66d!Bye<70e}5b`gYX4=2KaoAimwB8e*bis!H}YKMJhmdQ}i{9Z^ZNz89~#o
zU@%g5tI~MO_8&ykq9U&da%`)!@~65l;$mDs>``LkPLBH&Fj}<bolo1G#xw$Ldl{T7
z*{GlG0@<b~YtHB~Tjws!coiv8NF`hjEtUVss%|WIcOwP+dgA2lYEXfu!knoPzy2$6
z6{Kr8P-o;qP85)PIM|i*P5Hh1_b_;1g+@9@qt7Famn=QkzA8GG#r2nGk2n*IC+K4W
z6)9*^&@%W$F&=UpYucD-+z%8|qGk#l{1({^*?doU6m{*PTL1nX?T5^R0F*$6W$y-K
z(R#}@lL>B>&jgYXLJa93#q<e_kR*aH^>G>|onMsqLZc)YIDCGu!W@LTe-5NO4grG}
z_4k{P+zwbnm{$HirO=AyB-dY<EFJKcw}BRz;x_x@QMeo75$r?AomCfq1QXn})GL*D
zps>5jAgcL=r^~Q=SP^*ShO?jImHNcLKej^O4|sO0uiSj&A$-;43HbLi8uqmv4vmul
z{&%$<zQ?ZPF`%Gle|)`30yLzz?zqr@z2?9+I*0v6(=~0d*mLpWpwp}J(CMUzH?G2Q
zpBJFK(C%ZZ^SqleVA<lt1u7F%*DAY`Fa9KdA|_HSxC;rI^~%A=DG(fHoPeq)#D4<$
z2|Nt$!ka#Ae=O|qH!H`3z{r;NC4c|<)!lzu${q3vK_1};df(Ym+IdygqNi}Y7nnsg
z|6+l{k4RYguih^wh05qNz*7P+OyNN&!T_JI`K`h^0EZ(yK4cYAsW8w-CVhA;DIU2W
z&5FMg!b6`D$LeYPcNw7vSZNGZC)Lz(T?zifsRvgbyY9&N=y56OA~LJ4EX{FN%G%ri
zK;?gX&eNd+SV~lE52JQfO7qnWu%36f>7<A*z!iEzF~-`k*=kcO{0L~|2YA;iDDnn&
zzeVTfPvaH5uQhC!1c&>2Qu9*Oipk75#Z{fBrC8FBj=oKOIFFsbRh&zp#P(24iTT2~
zKvTEAcHOJwWANP^Gt!WNt93)<;lU=<>ez>S9|(RvuT8`S78POQb++ilugPsR=);C!
zL?iC(1j4*nC2h*5-*CCsyjQs}$|hX&DMnSDx;QQ*j&~H~z#h?{*W2oK2>*iNdKM&A
z8PVX8FlW8BUs&G{TuS#6X+=O0ssH?}1zmgObNNq@3FQe@ZdJXMYxfddTxtN$1uzv)
z8p3Ul?pOEPtbf#obsx&mxg+h~%G_j0B=LH4hiU@bjB7YIP0nzgF5z)V$9HM=oOTQ{
ztQpO-)P}^<2qk8C=<PDOmMcH<odpK;s+wmyeR+pU(ovS74v{sIRCPjYOGNqktSeb7
zzJy=|fQDyCOy3;1t(7pQI15!es=w;N+R3I*O0H)Wi@`<x;Jo)OK1c3$tjgZ7786@W
zd4Z}ny_uMyUO_@P@lVQB1*8Ib906;RQ)2uv-Ik6^GJ#}Tg{%vXFHU|36dK-dmAgLM
z`Sa;;Nb+lXsvYv;*eHlsCoz|inbW~wz-e0#OGAM)kDa}K#^*|Sk4^d1Tg3n?*}pP%
zXLnVUzu7`05)1eWEXU9U|D*B!V4{9m8z(0-h313~8-l%7Wc9%ZgXnosy}++&Yc%mt
zu-(sQKxN;qq)_;32B~!Jy)Ax#uHhEjiOeA)KA!6IR}*uRgj-!G;EKvfyrU2MRIF3~
z_F?v82<w=JUk&{i-rhT^sju7n6;TicQBjeuqVyutyNG~v>C&aw&_fALL_xYp?;yQ|
z-a}KADukAVmLO6B2@oLEgmT00dCoa^ob!%5?mO-~?q4Z;ueJA@W9_}>TA#V*_x1PP
z4{~d>Paj;{inaK5r;BGqpNc+gAetl}@W)nLBhZg>0u^$%xH8Q##j1B)yx(f=uihGC
z_kA{iWz-{jqopQU=MrAdhD5e|3CprX&p(~?r2PGiKSvLCWmFWzCJyaBL+zi8zWr<i
zD6x6PMjTa%QLaF<E%%>LzY3se<`eAsjH-v|K9f3#BNGF>Y_D|SW4;>sSmPuqWc7ob
z+uGgmy2Pumkxs7|uTJl8S&))oQ}~r}9~@Y#iR%%}WH>(za7#3*Hp4HSIskeK$n|c4
zp`MjyS2&kg)qf-;bj6WV`o7x=wzP&93fIl0*<APy-<*r@Uu9ewn19N%EF1XE#zs<r
zXR(ub$yCg$1@whMrP(IH;uc5e(PQO#y09@r*=J7QeS8cWR(fY4mQcmD>5TsfQmiS*
z3xPW`H`Q#bx?GpueQain>u0++d9Xa=r|8va_eeP*=3X8;aR%_zw~Ice83>d4wZ%X)
zDST_?+vTq6D#~`>iP9^6>ruA_^6JVyU!(T#pp6&M9?v_JAW<(bLcWnW@lSu>B14=?
zNMT9V6wONy8<>2BLK$Ehd}qTVH@1olFXZmZ^ieGSR)G9fn_)3_AT8T{&I{Mb$yqyJ
zr=8x^D9U6vHv^-o3K(0QVX^MB(4j&QpWn+ny8CM_R@x+sr&B!YdL82{PqO$FG8UX0
z0JNHa+pX1rrd>BP2F$zq=q$0|0h0fYqEXp;ZY(J|cE9(|_y<;rdjFELDQQ32`atDg
z0`)8I3B)jEqbC3LoZNmXq5gG-8%Edh9<NR&yA3|dx!suu3o0jrRS02Tw#82i95)>I
zCN7H^G3SoAPMW{ay?wEX=%isKz~`BX+BZ&{lyrT8g*X3f3lLQUQ;Db@y532dc&!mg
z3Iz>b(bb5#;#;}_<5?_N1phogWM4R;R`RR^e?UoG8Tloj5m0hffWC0x<aKxsi5gjR
z{eAvY$a+WZN%3ZX#Ex?+ZDzvT=%)$y-;LAVNEEotTr(Q=&Y5nE*R6d0K~myf&YRCU
zudcgIa+}>(7?S^5+w|QrmW7n?EK_7F{JTxq&*ee?K+)}^9)W7M?Jn!bW9=<R4g<p^
zJq-Dq8Kji>ZLb9{9xVfxrYB>!Qr0#}8(<V3$n^M>cAB!qKA0hwsABbr$AqcU4AnXI
z$+*gxy+7&2);WF$1=HywxqMidKK{KYT*vj4{+QFdZl}gOvBF-OSE25}WcJ~eD3fCn
zR%%jf$9)*vFF$?|EBbc3;<VBqPdn@&;hMLE{;9Jy7Y}@#jyaE%E3w)5aF#%$5=!zi
zZsM^;(ViRcO+xja|7BYb8^<zQ&zeq-H-(w}jDJ1M?&%0|5EMf(Mp``f^@KJ8Hj~2t
z^2j%^e26Cxd?+GHRZ|>XF8|*0-@Adr;{5*^_-RRjnez{w|6XKB{1;FG`FIJ#0c4=4
zp+?ulXE!$CM*2Ts;iC%X+ZsbbvF@!@daO|j8!o@rPG4p_vFOa?HnXa;0zStHQvVuL
zp)V|Rm*E(QxRv(5O5&bc^TXyDz~o6h2ekjX9(@Jy#<DPTGZfx&*)_nFwxqrJ%?*Yh
zfz~gy|Exg*J*H+yxagyx7_64+^cA111lj{YPf?)EvK=w^!JS9Do<Xsb!t4jGb8z|L
zpuh*nn6XFdbqB?x1D0Ypk<vir$VK5q3-OnM?{h91>YOTdUxCI_=X^FjLOo4jX_1Wf
z&uW&NuAXd?LSJ{w#;Z;ca3}IRIZXe;<9%GQMY7B5=hG7Dzz6cFL^xEr*_PyF<SP8b
zm~?39#{Qi)v6`l74fn4AR2|^=fB*TvDaizjf3Za3K+hym$4Nm~Bp^2$=r?{aG?mR{
zfNR!<k6yYt>`D*l78<NRGS_ENsde4ueJx$7T=SrfO+GdJI`_-j54?e~|G|%rtLw3C
zoCyZq@o6l&N!1KwT*H!<g(P)5=Z`*5U;7hWHjHe-JjD2EX>#T4iRsWN8I{!lZ|&ad
z*N*s{No?atDZaM)&B)Zil1zk-6a7>xX*9}m$wc$hyn1CZ75}2J_W_?}=0iEC)$62Z
z)ESQ=e{nYFnDjK2oaW)%V-1o}=?y;A-(Xw@;-m#viF5L-HJkdsftv<zDg~s($h--W
z<wCT!9`4sCf-Rs%q=1d4j1Y5qn1Uw6emZR>x^4G6m%;Bd@q|Z@RN`8nku>#4a&?d7
z7GKK+kA}>w^*QGr{dT7CPMi+izGJUq`NNu?EF6&K)yb5|^MMkw84;6r7EYfX9+B<+
z8d!DT|26sTMDYzN(o4t(CVC;H7MVR+ZNkW$@~3xF+}iASTs1jG14#!^8q2YKGB?Gj
z^OiP|B%W8Sc<D)a+M~lMJ)2jr42&)!CQM$SMgl4QCw#=;`09Y@9{h_oxkS3|jG>3C
z^;91eE<~mHIWFk?IcDwkW;1k->$6RkZ~k<e+}{$OnWdgPs9J7*Ua0R96%x6#{1E71
z=*G!U?M-pNO*8EYZh&)L`o&}zv>fuwt9!=r5nNL<yi3NGz6wxr!%+ICWOMsKqiZ|T
zN5+e3ZtUgea0eUSb9kL7J-fvr9iJsxdT&;!l(E}c$EJ#3h2YzF$-Ux4c%)(X>ACgd
z7y45VF9k8Fn5D={n~C;{fC0|9W0E>JQbV57OMaH%J9jS<UzDig+{PL9#Gu+0zgI7A
zDvk4!KfRUfJJhTx?A;cNiF{P5gsECFg)*_{f#>}6QgfhsiHfXpoD){kP%ZS(bZP*x
zVm=e$tzlF=+6^RP%mM}-ATB>z@2~jIrv|$_HRkZ*TgB!Z*{)AElf|znmW*#@iWTdP
zVCP+#bQ@qoZ38N@n>X!#j~q7&26|;ZHg}63jM}*4T}w8UORYmkU60jxWNl!S^)Ic%
z2VaH-1reNorJg{YKiyt@Oyv}i9?f*S?fCKPfb@cpyw#M~JB+M+K4R5!BehA-e>S9T
zJ8K(OMR<F>C;2-OztUXg)S#Udkn75SRGU%uD&~}(;~(+Hl6~D^rj?vv$&p;h=AeL*
zU2Ev&F?E*8Q^FQJY4X=`?mOmEK*x%`smY#Aqx<bKyr9Nrua&eLH1XkToD}kH6=ftz
z2z~M$s(D>vWKKLM=~o|NYvP>%tw4Ot=K(be#-{!Yv_@}?64Wo$C54h!Ih2^%10*Zs
zaxX$q&%nJT;raHMedfW<-wRHX{1gCeo0W+n+x=nbtx3i9=L?x`0jG3;H_u8pYgd4i
zQoh7QIb%CyL|kuOMrtBaNDwDSGrB~9m#Ut@S<a#ViDONdVWmIbQa_Vi{Uqk*ig?s1
zx01w8+?+`-aY2t|hv0YC)*H4|wkBVPGm8OChZT*8Uh`eexk6iS?c;pf1cs}jNx90T
zU>S7QY1>3Ucvxz=03h2IiUu$)9n6WK)5!4$!2=HXGuQc)V4RbW(LvK**6`PiRIN$h
zCQo3Mb1o2a)2_$O7~6K2d3UDk1TrLzKrg5ss1C>RM#DZAOzm!EFQxiH%XHN1R*Flt
zOrB4rr#K;h9445$i3obHCfhCRS-w^7vaE=6#^)TcOYo(Uw&6_rE{DYV42aC6CN0<d
zVn-zHgl-zecPE3Dv*Y{k;h%eTTL;4T2$?tgPp1>+N(XauLwBcF`X7Ox=YjFR*XtL$
z<|8D{<CmoRmy!cEJ6JNbAp7Pe-*^0@KF>qM+O<U2BPD?7Iw$?RnYjY>C<fT4M;*qu
zb?J`|zPSGj;YAZ2E?p>3+p-h+JUFD87Q+dT%r^0{N0w+VApMkGd-QVLQ`>GQnJEF>
zoBNAJo@sYBpG~*MfDZ2d6Rp|Ti`%U(jj@TrT-$&OO!U=1Px$N^kfyg)%JNskPbTXC
z7s-`qvB2gd@Y0v#nQeXyq-0m1YItuL($SX_n5eCDfEVdn&65<A+2PLfnZ0qjab=ms
zFHt4lNtkZ#SC3G$^x9)tMT*&76UeaZvU?=gt3jX7--WFg>hJYBc8=|u)699!hmZ)W
zH8SnDxUoG<$aoT4!51i@ZLvG%Tm9ZK(f;%963>F`tM+%ih_6c^3urex+wRQ1P^%yj
zHL<2T^|0{M&#RN7{CQYLX5bZK9F9uJ{j>AaM7y5s7Oi0(FG*V_gl-4?y6<Xiy6<Z<
zHl0(AfWNdW5;{jWtkI0L=R@#M>eiXroVd@G>$_S9>v>g34~l+~`-n=_Bh9x}TP5Nb
z3YD6}vqJoc`Wax!=9PltrmL@tsG3)bMuo&@fb^NCwVvXqm$g3QMkR;i_J-k+mih#i
z0qI?VG^!tNSS0aQYz&!hgRKz<ZoQ0eDIgj--dz@)F<?lybbQTaxc6$&U*-9l-Pfyi
z?(1a^Lq@8;u;=kLS9rw{y{Gm2Ly3BfjM4a~!>aGtvN^wHMnN69cCFwm>V>tIXZeAF
zOv#|54)2na9l!lQ#o!O#s~Qia{BGT=u&@8i$8)Dt>C>dk$_wAZH?)nF3FC3SQ5&pQ
zCT?v_S)b#o1|nQixY|NZ?MgAWPj&QNSrYo!>c36gMc3coR5iduud?l`Vn=;S@=TPw
z-o6;w7B<$QrvF|cZt`@Jea5`cM*~A<jjrEVl`$u;Hk+Yko*5bOjsK-`rN*Rob}Epe
zLPBR;j3;GQ#kVO@LHUuEOjXH9J5@Mr0+z5*VW-uNA=q(*$A%()89AT1xitC#fg$xm
zkHz!wCIRwU`{ZKxEq>NCy-*EWwYa+^|3}e?EaefJ*;<F5A68aC(nBT4c@KSAdhiT1
zcC4D=N3&hf9NHBX{dwLd-%2HPZuk~Z9Lcn)DedcL2(Z0zb<~wko>6Dke0VM1YWjRt
z?5?jX`pm6N8JVahOmGVvBSl}2pjLaC?Dds`U7DTFz2sHC*n+&rGQe|R_$T-$d3l9q
zzI`a6OA%T6epPxmzVTG-3HSpa&jcZ49*i|!xv&;qmEsb7D2v*;W2JIhU;-rsIQ)E&
z{T}@5SCgYB^-PxQ_o`H!^R&ircq5=WmFk#-1Kagu?AzdNS0AF9vA3~raBh$lFZqkq
zAc60ZyK@(D#cFBp*nl^KLGU&KV(!G6>5Sh})jDM9A_)0D(eL*BfZ;d^6@#_hQemdr
znszV7ha)7l=f5a)L(%5VPm&@2F^R70t)n1uv&uD0IN8IAk0hN`waJiUnLb$>a~Zn)
ztw#5QlUY<lsbCbYl;C`NC&)3aZRKc;@V>EQn3g&!75pG~q5y}OWqf4HEMq`Ge&y#%
z8yjA7i4^?P8}4zvq$@g%xCGBFZT+}RRh?US?fWT7*7xZuw%_>nqt9vXLm#etEr%Qp
z**^B_d7-FxWhv*h{?kjjDonZh2XLUKjJ<>M4DfsHS7fMG44c1Bz_`!nm#t-Yk8~xY
z<L}-3IoZ5*r`|NyMoE#~vW;k)UQUc9cH2GV#ngM*Z(09sWeec*);D77WJ(dzo@$(L
zRFeQGZY&^xvK24SR88zGeC3n;_JV(Nf{7ZLQZ4SeyQs^58qFi=Z?{fbQUA@HY4>^>
zMeUWLWKHxWkNHxRn)M|BQl9dZn%p5)p*7LsSO-jBJyc(bUyk9rUG@O`)-wCyVD-CM
zNnh7-Z>=;WC`D%`$S`}j3oT+;ej-NIt6Df$7$g}soiNO_`i**k{^eUJ7-GkgM#lyo
zE{TyD?`GeFzW}tiTw=#&W8|L5*E4A-#-=~TRnX6txcF7>3%pWJt0*tUUaeK?mDKEf
z$o9e4oO|n}=q&oJ3&H#(hbn+Rw0VDe_!XIsu!usBf(_EUB(h4jR1vFe_uDjtA+bb2
zEeA(60r5WeKrg(`+Bay7M-LRtB`aXRr5f1F!sAxGTbZZ9O&aAHH*IGrRm8od7uvGZ
z+s9?iKa&KL=WEnoAv#PB;M`v7sF}vD!KjLR`^t|`<LqIPOLJ+?RWDM4yK__`TeL`1
zQ`j5V@m7wzj{r$K5BUtl4Yo{Pu}<~W*T}Ac{TQB*<}ZV!Y)QVeb9uJ(nP}&;ob}n4
zsADnUr*bdEV=r(?N^qfBhw<_%jn%~}=ncq4m87Mlg*v71i^&oReE(Z!_W1wbt>FL1
zHXoaRdQo@@8_}XL3{QM5Q^paX+sf(*o_i=z{7Tb9pOi}e?i_Imbhnb*KqurGmFLp^
z$EVque_n=Q@DEP+7@51P{z*1-J29t+k})8#PN<ZYL{IwXoES*ke=B1qKDgT2uN3G%
zt<t~3x)Yw;4}TeK_VF>7Y+}q_hjsFK7018qnM2yysnYU<J$US)29q4)uS(yC4Vg-e
z1&XMiFh%$L&{jE%kjG3|FLg~aom;b7$XL3$l6=6wcL=}oy->&<RRXDz^&M=+j+F^K
zh!LG`uhbvWj~1@Ae(6U7zZ5y`nm;SZZ{h{h9`brVX5AS3M@2XJ9)m=U{qavvV%FEq
zcKds!8n1@obai#N2Gnj1chnkbAY-_ZuE>Vvy^Dx!byLMF?3Pvi9~KXzod9DOi<uTJ
zZ<xf|BN&EpXVx@-AxhDU|58EKG_UzrlB8UL0JFLV#FBqTrjrkw`ajC6AyZu|b^pX?
z=V%FiwoEkLH2J49t<ByYdr>IEes%Z;A>SqK-NU2v7C(6pvDD-9{)Ovw#|=Nzb-vX$
z*FWbNZZ4jV{#hS9*Tk(BQyjXN@2dXFmHRaHY+z_&Lf#Zmb$%NVIs$+2vH9CIVVf_a
zua*{0s<B--?^QX6(Tvb|o8|o=nVW|T*sd*XJ1qj;RZWxwOm$U?crQY(N8I7K6>tWZ
zV{BRBp$P_--#<IOztSb58q*1b6P#MGeNl73<65IVl&N4D(NA!FJv5LvM(@MksR=Tv
z#EyL~v%Hy6UQpBJd_oC`G`M=eC#ukQZKT{k#-1-gTkyQD&QK$75xf^@3_X`s=(NnM
z3B9Q~-k!Dv!>c2Op~PiRWC->N03fX)*m0Vhs@b6m^8V<?DkHz#mh>w$qcpSdyl{kx
z?M)?l<$kPWTDc0yd5Gu)at~q(mOQhMGrfC1o$S)3OPmVK<Z&{^f}x7iHSKEUO&dWp
z#lEeECL-Frm!a}if$DnVPuI30S#=YJNA-|>n?8rFls;`OCMMu}N#f;hxZ8{&>guAe
zovRMQ`<>UcJ7K@L#ZI3YxRlw$hU~x9k5(8ciaOtA<!!<*)VQpMr7}u|e3=!mE~H4?
zpW2q+--8pH^l$~|rRrZt^(wo9r+WD^+75W}XaR7#lwzfcT)t2^WbJDNaH^>Hp(djr
z*jFI0dL=76hb3)Z@-33FeNuV>q(vuYUa8V|DB=WvL*4+DHOGtKNBnGd-^h>}=ppl$
z-f_9B@|Q5aC^W$%k}^X(hM1ap59d5OH<zvH>xO#AI0%?(jH*!x_5DDlDkI&pK1{BQ
z`K75}tE8D@Fqg%rT(_R4FuE#&cZkjek-blOH^H|d^Hho~RcD7UXGL?i#RFjGbmkmf
z$Jly<S@bJZI5earr>n(Mv`lX-uYTWKy2z!RqS1G_UMEQmBMjw}8v4Ucy0h#c&l@6M
z=d#+uFkQvG+=4XAYeBgaW2qC-hy|EogC?@5Zxt#60507`jOL6=seq-lY-ECy+{4+W
zQ<flD%Vg_G!EnYw?p3JfEMpLFiX?*XoGjWqH*<R2n9cp#U}ToEv}o;)@)erQCgD)u
z@npY=#sixL&WUXS($yc1{=MtCjOlGjRpW<L%<Th!$M?dZO_&|&$#-Wy5%)vw#nhcj
zA(g96Kekmw4krP#gmtFOXInJlRF&4z0=S&~9B9JWM}+(&oIlTLE3e-%zNNiZ2Anso
z6ep!M0SYXX*Cm8zeq;7q8sM3g@0w^&5O+Eqf_;j3D(V;rp2eESu}CVhWnOYzBI=2_
z#cl$)%B9**5F8S3Pg|9>vTOEDeI=b_M1smOzMZO@oh_E1D(B$IcCh12!tWq}59{y%
ztgofiaoi{oq(^Gc`=e;>{5rcXd%>@>=k4YL+Yc+Z?jg#Pnw>`HI3`{@Rt8$IRffRO
zPG6jY4g)}?QYW78-Se)P%k9x<wimarp6w_j{fA$zn2Bqg0#uY#U#XoZMkYHONs=j9
z0c)75gp4*|_(S0M`<dIhA&%2}NfyjS!{Qn`(0Fm@`H6OnI7+V2it$8eg4$?_z}dL{
ziA>E*L|Ob~SIyjeAt(nH8gXCF6R>Axu4=y5Dw#Gl0$r!=b}hUQcAuJF;n<G4lTK>H
zr5*i83)>~y>H)(lWya^nj0A!+5;<Y&pDi}ps)LBFtmI}pHOP6;e}&ZG$v4akQU<IW
z6MuK~8jq4RXWJaI;Lxlhvham3qzA`sq*GH3&}4rz)R<QeSu($&N!TvF4SF~4P!TxH
z@2vfW^!UG@oN|H}CRWmNQcrxG;cXh~8Ywrl0b=G=6eCaaGLw&CdUGO&qk;Q-#5_s)
zS|joG$G{^bIiplQ7?bL;c9(R=+lt<^v^kea-);q#&Wv4j>`OZ@@-N;k4_B{=T>SjW
z97aL<c%RNbcJcF;Hzz5#4x}4dI3G+*N%MQ%v3Gq%;nVed$zR?Wi&hv-N;bI!sFNyq
zW9UgEa+5`>YSVZ|3bc`qnW_f!7*zVZyidZCw(m%}RzuHMwhYedf^xF5i-uBo16(dj
znUG3#q3R7%cnow&dTCF*-x8j`$<=?B$F7p#e13K+<-eUT;5gl5eqjLJm^ooa-&Xxk
z!aNcR5pjTP&)=Y?U3Py9L-m`SNhx<=77e6Z=E`cl${6T<SUx)g^XDL6$)yo<hL^3I
z{pYcR<JgZMuejgjTHrCPTKlj6n>l;MQ1A7^It|x@$w~D{hp3P~F1`4D+wsB_pCvET
zTzm@oIa4qOEUa~2#kt@W+~t1CfsJe5u6JZiO_#UiJ}6KSblYCl&Ne@1th&z)1|qtB
z1Juo2IGPP(qFg#9Nfl%ZXpOwELC~A*e5W+&>>agr`qiL~5ghiDs!Tp?k~@A^Y#5@$
zYN^SXirBTr5(&e3r5G@?dskHj$C~^SCuZ|J08gq$0+5p#*4Kt`T+WLu4`i2aP_YD{
z3ULWiE=3>j6HfEk;O2mez#BtJwH>MSf!*UIU<`>=TX#l!z@#&`TM|;x{3N6Hte3wG
z$wn<6&!CxLWjc!P)mLtY6iQAyte=ih0$T~62m!sa1TIbkT2yG$S9oWYLg+#{(^j{k
zX`a9F_b|yQ#M<|{A_i?fy}tmPed4P9Os>!AW?O&>1pS%kY4f-pY;sShDL2yx`^yCX
z_nIcuxsYjeA-_d#2F;8vIrCc^deX2^C#x0;D6ueZ(u+(`P5G(|#Itl8I`cP-N`|DG
zG*(nY4cVrEiWKWZ<T%IG7@T9Tg?D!5h>v1k7VOOI92+FQ=6)Et0?Sq(8A&{tBc&@z
zFS<IIGeumZ%xrVZt2l3s+1es>S_If<h@lPibs;Fm+5MLWLjfuYv-r;DnD`Tix}^Aq
zP23#MI<>UVP{~p*uGz1|nNaWEIHycT1q7~uPl1z(;v;Q$sljUPZeLhCnyY;sI?Bu4
zi+JZ;O}WeCw$>I5=#9jI&+Xg0I{peE7YeFdB8PA0V4h(vkC@EA)|2imQ@0G(Jk4rT
zECsE*n@G2Q^6^QVI1@9ZJv$}el=_k{WrQqHVQW_ej0#az<rdu!?t*_A=WpB)ggT8B
z*thR2_U~^u?IZW(bE|dOOR$~H8K)F$f(i2#>M>DI(Pu7Qtc;?wSvU3v)^sojl>#U;
z+bnVSaix(=e{WKE;fnK`E%bclf=VyGM`==a{y9?AY7AD9PPbkV6SGg`1PzH;<xuQC
zVfxt0D^pS+yQvv$T$9AgOsr+yG%yMj?ld5Sbd854OYg4@SP%k!)$9?Xp(8)oXP*Vu
z+q;!jW}Q36%lm#gt2v+;3397zZVO}xOvV>hgM3aNny1z3>XlR@0)mwtC+KKhJTNVp
z_(Quc0Qgz}()4$TWe7Wv?VAe7qKe(}H=?kHdEA{9G%d30!c9clnXEIh9IP0Y&z-W1
zSiPnfotCoHqqhrixjyAMtLi5!0+)od3Cz?S-Y<6Y^QQYa?^|bVin!v&aqXExM3=vw
z_HQAwsb>wFM^^1^qb8^O`%OIKPy`HH@`zR+A*>CB9el~nk^yH(y*a&anXhub-vzHe
ziB#qk)a@o(O!~UtSf@KhLo6M4|E^>LP3=zci)|)0^r3R*!EDG<R87{YoN<u~Q%6Zx
zQVdSCF6?KI{2qSwdh(M2lFfT|xJ$$OIKany`HbcvO(A9t-*{jhZ;TqLJHss=L*Oo&
zTKAed>cL;{Xh^97U<duE_V-e0>2@%Ka*(jOPglmdZ-Upzj=V7-KGfW(82+62bP5Iy
z&8WZx${`~DcvAyYGBc~x?4A8U?P6@B6Q*=*@O&a0obG@jR(8R;1!ATDYYWj>tUGdy
zc<oePV&6Oton4dhW<?iUIA5*^mwLdwsei=mhvQ~WH;_7syRVT|blav6Q&ahSROPOa
z|Ma_E;P!i}s=nB<e5)l<@0=Omv=PKHMs9*aN(u4nQ#VTqL^yA3a`+TF7*u^|F<&)G
z4xm;3ko?Bd=<J|{Fj&gQH4*^tYuD)B7}J2!RbVIb%z0R*tIav0M2AbUl{J?7-M(Ph
z-};-FL+g^=X8VdK+Kbf8WAaa?A6^*nbAlJ6BQr39*8ptxD@%M=v$C~OgHc6a$028B
zgh?ejQ0{Nfq0}GE2<8PHAyAZoD$HDa8ug*4v{XZ{&A)iMMtQ{1=98L7JkijZ;C&8X
z%tIFFaJ=>3ZnwVNqHMnRS>Ey!C??v&UKn}s$GvfN5#9KZ4^^(yR4;Dur>ac;LAPZf
zd5Y)h65-*J4VWe<cfCXkRq^-A2bvGmqyg!OTP3VdE_m;xm$1Z}hplB?>yIm@!3j>%
z2PUj-=Qf#aD>NR$3@0T;i*W~=yg`0)J1<4S?b^Hx%}_?>@$c@bP61J<z1g>EXN}Qf
zzt1Bl4%3&=n^P(ral!k7Ix*M4bKaSva7oHZ(L*pF=L@NhL*5Z%x5#&&Zj87L9`eRZ
z_WL1t5Kln<m4Wf{Zu32+Xvw2auLJ}Aky!(MZb9|+%3$}d3LR6J9USK!-c~Y_shYI_
zcd48YVja~&WG8GK95B$-po<?+fpKGFm1o69=PUeggw2n$2%!BzZnXy5sAW4$XXuHd
zr6sU4#6EAF>xZ^(NbyIdBvBX>Z))0cm<4GYJtOk(^t<qfq|x$W$dFTlGSGZx3E{kh
zRFjoHu#%MsjuFs^@})crYU-3RUI-O2S3KX<n)WEh0~Pal_1!14Kt4a;#+jOE($DqZ
zjyBLqJ7`rzLZK7939?lM?76TH<mH6k_gsGa(9I$Us01?rfjY0%-Ue--^G|HC!43=w
zpH`ZF67SV06!U|8r>@ZiuLiR?O{)8y$W$G&*TqR$a)7g~N6}F!6;o42x#;2w^YCyG
zloVQU%xd5aOxl8M1qGiH{AoHDmR&&YJUKRb9|Yqtgq3_EuvpyTC9OFK>J8ec7X@t_
z8I>u`nTi4z+(ofamYB_q*N)P!8&q207)t3frJ;N6AxDq(R#$ew)}-EhjjP)|=Q{ou
zc4=<|Zt1ujY*d-f^hasB^e~sD2H|ozQIwSxFs$Vn)}nP4RsSh{5v)flWoM)nC{nbM
zu(}QwJXqUaWS>3#Wj%6wl>ar;QWx{kruSPYS1?f_X;cBAo>h1?tFr8uHdEk*H+3od
z+KSj%83?Wb&OR=RI9s=h3$TjgX~q^qLW~LG+As<4Qj0*}Y*mNs-1I|mCdxk&B%VOn
z6CxFT|KRi7SowKKohmxl)bbwh#6W+!)o`l&9v#u}!eLA{nFopR7*v$?MzWtelfOCJ
zSm<78v%m1+#7I-4ik#qP-%ui0oHE&+*i9V$uOrR~LgHxI8-?>ZqP#oR8@bKdCiVV!
zR$#U9MXj3ix#P75IQe`QX+KQ5<TA;ftW-<cwnR~A#j~r#ODGZ#R#&AIlsnsj24E8d
zcYabKHQws52-&Fu#mFXfXy86FjC{1xWy#<FVa4@(JQ7gbZ1biH=hLzh9;51IK2o22
zG4oS&>{=~ZU!6^VHtidWY|lQ1(a6Xi(!Iwos8apo_MX(H%&~1;xO*O$$N%<xuP~B+
zUb2pV@xSx}RsNsd=6@F!*b3{bVCbDXx4;Rzwbf@AWB2Ae8ybf)<nG-~v4m`?^3N}h
zD8C#2)7FI25W2h~>g*XW3^<qDAHv#lIWep_E=sh-s+(}`{OMM{j*&e$K_CW`n~nyP
zk|WI-L($@D_|-pZSqH^^H3#;8-}V2{tdIhviTnM{`Mfmqyb^>?YY$kIbC^A2dCLl|
zzw&<fNqkrY;D}~&e)&-*Vaoq-(rAcFB@Qy}SRJNKqk{&aHg=}#%)EuAog29;$8+w$
zDiVl?st&uNJP)2kG|(J=BL|nkM|IB`upJo^#*kOum_x7X{xJRyyA_SPeG9nP4M^8Z
z78TiCE+q>;E?l&;2Le0)mXZM9S=H)DXA_jxqZ5Y05lLB?lu;P0q=qPdDSPWLNnnuQ
z;@ifk;!7rxeW@~UNx=L?cjkgzKaLO&zB~gdY$)m)-`bl)#Zxz}^J-?SqB1nsv5;O@
z+%#yo_!W?COPv!V<+rAxeB_0$Ub};<cJ!w4uSheIoMeTBWQx4=r+k`aEZz9?;72Rj
zS5<GbcvW5<?{BLJ>9iN^XD2Xh**FK1FUj7-S<opntvlHwbGEdtLG{gRIphf^e<N{b
z=_3pKkfda<&V5j?&Nr6cY?qcPYE94P8~mn$TYB@CsaItsm)~0LFC(w!(Y4-Sm9S4F
z`ahm3^zIsDN$K>6vJIaisDHDdJnP_)CIiIR#CEtm>Y#oZ?=;M><Yb>0k>f4mP|&eg
zn4M&muwJ7QXn_<aw`0xhzC1pO_n!0}9+WpP)6zsL@g}|hixmp$<_d`Q;OC?#Y|VO!
z0Pj!Bx0)~R?$$J*MU^_UamE9Z6xC=h#Fz8=dC*~3X<`@g_Dq2urO*B{9@b}i=N+!6
z<**M0#C}~y7BtV{#vT1Uzwd5nAZ1`?!lZnxc?MJ_LTweOy7hy!S?v+;W)@g?c|?;B
zM{vgyWlIAQKCvn^gGmC|Cyl}p?AYOvGr5tQd@Uxh>!_3##W0G>Xp_-%t-{WgL_CgO
zRu+PjPJ?|d0ijL41x>G%pa|lI2~Qy3-gS+ieCYUCvf_o$dr%NdCsH_UHL?S5n}g{e
zY9Az51ZCsPLz@k=b`!Z{qE;DcnQO+{2nUlGcYRo;e3O)^@N-(iDAWcU^4l*H`#ZaU
zfgOntMn7-qLhg08)6T%*O@YW6eEYjIAqS^{9kM_A4&-rkxXF{j!{5KP4_B`@VA%$6
z;-`9kz9YX+LTnaBq0}10!;ui_P}_H1pMe=M9Lou2jlJfq?+}y|O&e!nHWbHr=aT+R
zpOXO3X2HkZXQ!tD`>J_v2m5SGxm3qD>T@#QSRFSJH7#sPf5hM3$qt%(wX}>2dnY;b
z{6=<Cl8WWb5#pYd{b!cr8yXo`q5YB(=O@t;3$+A~-CLUyT>!=1`*$Tmv+`cFDc$nY
zfM_cOw4(p!`Qh)T)0X!?9(vwhTffU)=5p?nEJedBF3*|J1+=T~ueF)>nfC?`^VN>3
z%D?R{uw&D;Ky`F?oUAb4s+ZyGK6}247B?|T-25Ht`X}`y1!dMVgzg>)<?GEFgpPy)
z_xetZ8aiekE_4~s;X}p8x)aO~l|oX`e(enmrn{A~s9ej|3dNRTi&~-Xp`M<)4Nr2X
z_Q`J3FD?$uVhLdZe%&ANT*haoFI(z}k)>$X%Cex3Y^5HVR|Brw;n^gETY@g*?fBWy
zK|w2)9y0Fc+h&_P9eX)a`#A|<#q*9lBs{I_+$?<3YEEKZa(@dFf9Ve;hn8aL9aybJ
zd_B3}Yj)>qvM^}~zix894aEEKIj^t^cW|flp<(AuOlrNBlS_<6nwh+g@r^v{;2uOt
zn@yDR4CVM{KPpVr>B`pE_RPw-v<SF8mvmF%>_A%DR1Xq8aJ)Y}H1I{rk8dDPTcK-n
z$E&e;pq~5Xly|*dmzG{M)1*aBA%%bM%vU|#<c$p%49}!rh_Y8{yqXYN4?{Voc{bIS
zhKu*|2IBaN?XGOSrROiM4D6pvDeMWKyNb>zjP=P7xv^{VP{q4nww&LbeJ}qN%nbRV
zm#EQMmLF7QSR$9wCGfW7JE$tH?8!pc0U>7SfLdbT4o65U*;0R7s!&&{61d6B{sm{H
zm7r*tT7&p59pR1QX6Yn|+37AAGcTWaMWor0&9UEJmk2qS*GMf1K!n%uv4<S0+vSO6
zHL7TnUW#B)X{UOKMpmcv%4qn{QLjMC6AzEJPDn`L>jb3_hF7*UTB<5^W>gwya&G9=
zns*XXG`>&mZKWF-6}~%O$q0tRUs=|?$`Wu;&)d-Zv%3y2PDSwQ`J5?EOCRVoGr+p@
z(@Oum{e@mSO5bas6Ol*{VL_sv?sb>DncoRt@!q#{a0HeFueBcq#Ssh~1*0v$x539@
z;0~{6`=a7+>6M2~G8b`!T>M!U2Y&56-0t`~*{2zi8fSN=xVW`9`)&KmsLAqAKAYwz
z>dTk@j2ljO93KwoY0+$-yGA89<s2C{O*u}^=DrqT$xEkUJ5BNB7}~C>=1pgo-ci#;
zGyAHE+cO*{GO9t&U0z1vQ1wct^c9fRt%Rti=c>quqBZW%rg=V}|6R5}-lB7+ueh!2
zThqf>*SXgMg05eLaAs&S*FaWs-Hw%~US8O#o0`|#MuW&SHl`oiL^00d8~fKxr-U|Y
zxhz9|_fv5d1|O>bx*6tFL7sF&&UY<F_~+Axk`})8BgR}#{pFL$T2iPXj}+~*xqaTp
z$lFmZ8;T}5`Z{qPGf7S=t5(3uygwtqKC|3ksZ1gtt*yaetgsc`BGVKPJ%fn%FJ(J=
z20oZ4O{qiD#zoqrAy`M8mc0hPv&5(0Yh=W6OXMiVg#J%Q9j6CnC#p?t^sR1CZ|}hy
zTYE<>c$=CK&D+3I`9Kt3F-$vZTKaYzUF{Lx@9|wft$nF<Wk8KC>Q{5vqLk*2sO@I&
z2}2398uGr-@#GKVt`o3#Zm46D?(C)CG+c}zvQL}*Ubv4C**9k$_h0L`EGlY*H&oSV
ziS|$4(cIaD49N*vV?<>n__<3Rddyn3&al6M>l(>gQCJb*{k4NTe3Dx(GZfoow}-t{
z;_Crjogj;qIl1IOy!Gf0M{I8wQLKm8^PPR*op@5}+8;DsBN_eI8S`d{BAmK{->DMc
zF)l1P)gBJ%^Nz^5dl>Iu^II=OFF?hL47%%E&ILN@4BHCjxu?7Tyj5E1mEFoVK(*H=
zYwH4m;_KbFf}~*rowxjb3tks<=Y1_lR78t}YJaaxFbafzN=~85ZwJp-&WumIuBb8M
zKunYwP-ffAI!OET3%u7epT8XUV(Inwf}5*Jxw<D`Qtx+a*gWd*40n-VdOl^}Dt_|q
zGw>j6qQ_G?V@aad(v_9K;jH!UD9)U|j?9^{rX(yiXG8P@CL>^SO!NB9ES`dw$I@gq
ztFa)htG(KU1sArTf)DC-?|=!^I)@qyZy59<3d#Lyb9Ox<UGCkyOPBJMM_j(y%7`me
zspD=Bh5zVw_G`Za<RhanpAy@vjM&?|jJl=G^gT3UYL;id3l?h6$-EwJ_K*+Tt=u%f
zz6^WCP>dP>tXry-Y?`?Lwx||F-JLp8%BPs5n|ym--r6`5`|D;XH8bbPRN$LwAbp5i
zvxcjw<X^w;*8$FK4@Rx!nmrLE?qBU~x2OavF{khdVP=PrW{4~1c2lfrLPRIlT%Di1
zUo7vS;@%>eyHVo_5r#FJ6mce>V}5oO1Ky6E2>Ww(wVy|dO({h?YxvImqM6do+t1ez
z<xMNYd%JFy=}eE652zW*J+)>$qk}LDw2H}<`v=Ls75lPgsT$mOWt4y0l<8pcu%}-3
ztNQ@srEJXKJvjHJQt9)#hWB5u2e?eC-aDnSyYznGFQSm_(hH|)wjZV``IXwBFON3g
zwi*?h8ay2!tsg%mdG^Un&6MoV8p|;0;TXAH+x>?}ks`t6H{{B{)f@-kxWsiYLhHi!
z{45FjU$2M%pO_W=f0|PKx590$l#Fe8BM4zXRGEv3S&_1)fG(ETZR+Dn+i1JN(q?^s
z(@+M{YWkSK_FM8)!Mg!@4EEkKf=XM$``EWGsN1&UUBn9;Y<3_}5kcHP1joT_mM!;p
zZ-l}=&*}QW{UST~L)LbaA;-eOtxl!8@t_z|q4#Y0M^_oMEZ_qL>IN+f)SaiRbQnK9
zY4Z>zX(0CS%hr}j|J+)nfI=E|Zq0}~#roGP?zb;4Mt-;Dg$)dw;GzV}Wt3_KJL~V=
zSFSsZNfX_OPIaCtDz0vG?`o!qWLR-p>gX4(T7qU<8O53Sjn_ID@*w1?ozQ9{%%BEw
zk>QPV2nlw@$ha3b0#WRkr6NEi09iF->Cb!9bz)uz6~bSwpQoc9+)vZs(1d$Hzdn@3
zIvx!`wOik1WKAU+fA<80sC4rBJ<Kp}@>1J2tJ(0cu@7OCNPvO*a?g+ans$nb$Y9fj
zD$khf&u=H;NgU_W5SLb1p8%jK?i5a6=~U;pYY87H^@c4K9~01HVzbh?5ZUf20LVS~
z)B+i_08v{zO-}9X)<0*S*R|BzD4feP2E4qr^xo<H!mNt6yGvz(AU~{MJy+MSvp_){
zS^4XLAqraJ*b^+syLec$wv@0ic_W;O7s?TAo3(oLOrD062Q&hzKG`owqaP=ZgXKHr
z&FJ5l`&t0z?iE>Du%8oW)8(amu+Oj`;R~u%=YuXEii>A1i5Yee;`evv1j{VhnY1#X
zoC(+i)6zAf>6zPZyS`1xPKq+>`Agn|R)~~EX4wpt-&#sQjibhp1L!PQ)x-+QX^5sG
zH9lEqo{d7#f{BJj?gf}Jx70A$O(^Vxi1((^DioF}y=q>5c#WpJ7@YYeW4|R9#vTrx
ztZ-Q6MmCQ6b?s+!xH^{?EK!zEYD518r@d`pOFfXxV>k!r{`-#=K%YTP8yKWG!}u_w
zPoSo9k&acD7$K^ESSkxU*Gk%2ZfQgzW%P&TIB5A{`KgdiKufyaIjRV}HG5~+{Os!>
zPKgoUIJk5#&Y;CgeSd9I3#j?7*&0I)ZbxNX;$rk$-~rC^{$D_B={1t)sFh8C88C9I
zZLmt5xZhP+YW&O+OD;>FyCkJeYHEHgiMZ+;A@RR0vwV3<r>&&oU=IhgG|CDxQANIP
zlWCMiQ!!Zs3*2AReF~1fvwXJ_y~Ij0*6)e})~dWRltJWpM5HmXD2CuTVI!L&eyrTo
zy6k`vcJ88M-k5Jykk({e3IRk4w&gK#xF+3PZj*hw=p{e-7tJ<aYq?OCYt%Ru2Mrun
zcfz98NAdu$lm4xsFu-i<{7KVVNYnQ2WEre8)9L=o@i49fuiu-M94cW_HA+XibFM;(
ztBh1?oz0~fx2&R4hqP_02oDZjCldp;g<7E^o$RF36n)qgPN2rvcv+nB*8;(oRxER1
zvt-<cRve%xDW5}JwupfZ4DZ*2IOEh0U5W;^ksS1u)l?o4-I*m#Y()9+sUg*$?pgK=
zo`n=uRh6uCmSf4EoCpr`?grdSziXCcMAzS)Va`6v-5k`;WEC6_$Ja^xW7LhmVm>^J
z(P5yIl0Fj|jEQ*wkv&t^y;v^j+<YX*zq@Y)PeU19Q9Qda^H$m+9@d&>=xlQ!1`a*F
zEi2-gWrCbB0P|$NU9QNQf?%9AABd^O$RkT~vJ9P9Yj0<oH^qQXCPc=Jpkp5cvKqbf
zs0=jzd|fN9im9Fe#ECm$J~F7C!@Hahzj!@Ijcp_xwqX@FCbS&<bwAv>vk{IJ-aAao
zzE^zzHx9{>fXfO37=veoQ7|o-jx*Y~LfRoZ*WxJUU^dRXdm?%e-_-QPy)t?*;9_yi
zj=tYP1XFf8oz}D=80-@Om!W~wB!EyMHMt?u+EIfkoq%XxRm+BR8$jcJ8(I5mv<r~<
zlSVCgBM(%7Q`(|vs)nVv*q4QF7Be1VU104?otb)`?=3>GR82K@2*lW^gPS214wxdu
zi|c!DQ)^;8bE6ncFkAG<Q)S-{U49eGLNYz^GUafLTl*uEin*g)=k5bfq{lB&#^Zxu
z?Ol;A6^*VT=u?9h(YIg+H{3V4Id1$fG9{<L3J8%eHp=$yG&jmTX>N7;C|9+1gE9Kf
zzh8INFS`~s|5^XiNbYU<XJnLs{Wl)^|86C0tLWt2!j}6Xm)}Cj$_mS!ZhHS+1Jb%6
z6;+BsAxJbwZ|>})6v>tzL4Qe0{!%_~=NjsPd(%R&a&uFI3d0@vA6qG}<<B>>+K(-_
zELPZt5p9F26=rQ;Tkc=<`p#AgMoagZ3bhoTa;+SxuabPh3@a*E@seJ9We2#0ns7>5
z%!de?`Fo_3UoiaKWT25YtN6iiFZ*F{pV$?Kl^Ae>FjPhlR$<_c8HCf5&LR=*8zKj*
zTY60ml{*^Bk`Cc<nWD~8`&UWFk`3lB(-4D{U%vbx9=Thk`zu;2_`++jyVvrf_rO+P
zgywB>s6!^`+duEk{_ury(m@hT|8LGiO63do!1X6I?dNvjomFx#1V21Gc9+-=6Qwh)
zR8kX{ZIgnUT5nFs<J`cIv!>xJN>VLaY^5&}`fdkjbm`(kcT>DNpRVY_kRaf1bplSu
zot1QkL|o40FlD7;)IlxBp1J{zyJ}nVgsS+Oq^zv?r0K<-WOr$Wy|5`ofvi7Lbhdua
zk!@C4Z^(nOo!h3;1inq^N?8$*KZ-*U<}TL6`OYW(Pxq00GnOCT;=g5tTIZrNH^EH8
z<~X}R$cbNW?t}eW3Q1xIH}2YO&Q1v{i&bjIieg@NDa}C(R!k87SzflX#cLjLomdV^
z=rFL9l{9ughng<?k??29O~XjbX)8mcvfe-IYIB=lQ`td2rmF69mv&H-I5yO?lGVcG
zR_zACzkLhi|EXmm#zgPK!bBFa=GZ<ku<8dJ<mN?#6SdkRzjq&@ZAa$cC?dBQtEt%C
z^sTFdeQokkS#stsjC=4x?O51Hi0=MoM_SW62qeKbxR9LN4>O+FxrdLoT;IQ!m-Q(R
z+r;2haWwoW)Ak@^4{eFHhHTQiW1=J}fyieKt|!lsW)9#p0>OmSky|S+m3*(12{rz)
zJD6l4#^>HHB{%iEf6=dvhj!L9@tzlq55`R4x)65<zU@Vw;gNzO0XtqJ?cn;e<88A;
z;}mFVC9aS-MFci1aK`L8h9jo@y!;8DfJ6g&niEBN_v#+@LKR6Ysd?||*6-dB>6)l$
zqJ*urZxN2$4D`!EH;`l1)l^R=n!ND00j7kiNf#lXztTf+*3FwT@)qbjO{bo~hT#9i
zhz6GQW^Z(|=(Q0GscvtY5nc;la;w8B#T-}DZ!?OxcGy=-J5HP%LYROP)A9?&*gMG0
z$LeD#esbT`&yQQr&W<0sXY9A30zDg~Xgf%ZTJ>2L43W}(3J%#_r&OC;1bicHPq;av
zFI&(qa5_^w5k^|**EVSgYVRTtl=fW^Cj0`}{18EV9(R`#DsZ&8$BXkX|6)d$cD$mm
zGDZRiu3RzTHQHG%E_y}hC{eM7KJ9Doq(h+(M>-7_ZwA$nS5)&76UM@21r3U!sHwuj
zQfy}@ig1DP1anjmEx}LR4eCOsEDot9ji9lCI_LZSjLLBpDV^n)9h6S%_D*L5d$Kyt
zJcGaN)WIp_pgwvm?gpNhzf&k&M7;bhXQp6O0lr(1Tan5OmkRoAy5U%*9`YEFejY71
z>jqyTVY$k#M2v{uqzUEz_y@aL`#_GHxJi0Eib~G=HjLq3%G8PT{uxrx2enwUx9?l-
z)L=ic+Oj`e5j^Tq-aE6Ni60-mBU7mJXWoq*czA}`!}Oyri%zC=m)98OWq)f#a)bwD
zfN*T*V+bSjn!KDPz@1<J0o#DZbCHSv&^C*9qt)5}Fq}Rq2RL*elfDBQIM#qge-Q(c
zo_bJPdtP3lcrIgU0ec=y8p4yYGKi7eZXq1k9qxY&{v0@^mkDWUc7{kRS;a5OZp%9U
zrJR5Uu8Y&Fr<fp%h}F`Tmfc%&GG~AGd<>*YQ(LsDa%MDI;yMh_pa$R9u;N3R(tZKc
zLdsC!CzHlb1HHpj!-li@y6N1gkImsCfj%zaklOH#-aiOhOWVg87?cUgy!k;DU)=pC
zIj0=*-1Q5UX*wm7{r>Oa2`|>Oz1;r^O?q?o@A0LL6vuOqM}I7lU8RF`c5~Ooqfj4h
zny*u?tHdH__BF4wcd$A1Jf!r$j%;o;G!f_ANwqs%V5oAzi%VCL0K-)EK6{Q%!H2V!
z!%)<nWEF_-=0shgN)F*-{2t<Qt7&Qa9~kO`<x$_DO<qo2@9h7iP;Wq_(4~!ni;yST
z^SMggP3C8DbL^wfv&{~^yAw6~W(+DT;0ewZUMp%c)TEcx`=vXG7wkP05BlR-yydvq
zMkSW0(Y=a)NSFWoDe2BXAx1}5OO!;?AOAB7>%R>g|9d0w4z0)qvk7!?N)cyLh5zLw
zQ6?>q_VZZa=w7*9PVS9tbo>gV=mnozscUlXdnVfg&ytKf0s6ko?s?AFvf;OK#gf>J
z8uB^K&hNOlA1uF!m{#>NLpKqa404)>v%*}``WBAkCOX>uU;hK61k$@m+{usPl9sn8
zt%zYUn(OIP6>s$;HW#nbM;B~G+~{WZ28BB_W1gp;t?{bkVk>8pN2GWRT@ACD>7#|i
zNukzPZ7Z}K(Gw-^dYuz(?c$V|N?Rl-8L`Q!8Q->Y^osU?A`eNHde2t&4<z~v&MDT(
zU=eLkYV?@rE63deR-?iAIz_6Iva}fiAzLYrw7_`3H0ffTKaHyuN49jHdPh%j8-)x^
z9sE0)#V|Q_Ry|Wpox#^YO%Uhiv_3&~-556qMN#FhBB`n!M%_sSNm{Y=`BYzt)nOI~
z%{76;-9i$0VlAhBiKqYFaxQ`DQoT`_L(*n$d*Y{m@Z+g2`VpgfsOrZP%IS_H%+RV8
zs_i?#aKvACh9fSS+Ekkb#u1#F<!&i8I`-vL7%QJ3+xXDL?Zp#mw1nL>zo?>KcH@ts
z>NhMRMiHtu>WB|MIYG8SzIny_<=Kyuo4omI1PWK#2P~nw_52QjH1uuV=N%)vqfwbj
zDY_EfhE;fGz(W2vynRhMcUTg?4^7)VuJ9bvY>w=3nShUE6BMUpCy8C9RlGjIt=Pww
zHdkHS1a%ZG&o({L93+)Q{=7#4H?sUnP8aCW3y<?&B62l_hy11&yTvlI>VNB)c%Jtu
z*+gmu>l$3Zz57=-CO0ma(B^0yW<kH#B$EnqIwj**Fgg~S7zbk?)F+`y#ws3X$#dyA
zHv@IbcIJr@z2fg_Ec(Rb{+G=(i8&1I<`XjnkgZ*(2bwjm84ED^-tlR5uzU32euv(<
zD_E@GDD6q-gmEIC?Xd~ScWsKy9BJu{%W)Cs)T~MSz8Y|Wfky8YZRQOBOx#~Flj=Gi
z;RxL%Ukc9g-fP~GIPU(f*)Pums=5MB59*rrpQD`M9WY%CqR(zIN2io`3!LmT{5DE%
zr+lCEoq}<vjy?4I^aa#Gw*6M3+f@;mT^#+mQ-jwo)eg<ymYZ=$ComIzLrTQ6y6x>l
zy4Ulhl6;9F7ih_ERc<6ND8VmiK}<oZi0)hZ=Jj2d1T@QBi?$AWvwr0+DEASX#kZpj
z{no7Q3gQ!7{fRGe(B<+Z$NBfo8>8d7M%_Jio!-|rmgv3C76YhnrwT$gWv{OMVHSLI
za~$)~HlPu|mtrh(<`X@nqHl$GnS7c9q8h9TMd7ZjNLDeQMh}^;wXdyHVxK+(V0t@A
z+_<k>^Jssu$aL1_x6y&p%4BGq=~;k7w<DrluQ?27`97=VgG{SaD}E8{dUk?6*~dWK
zz70-)wOl#QL20~jJF6@dU+vCZ8Ck{sCqw$;zOZqX314~CGB}%i4hgedK6g{77RFWy
z`Y^M*LQ<fii|YNX;$LX9N<VD!K>!0Gg)L}Esl|_z$ZecWi}?CgJa#xTX<@rD82cgM
z*^gBKE8Fn4{SOi$(;z~-UpPuBEziM8Rx~|3tM~p03--wRjJR?sn|X&xs>vp2BKg~0
zoY)&LHK$1Jj8oyvO4B3cPnNlqCKCKXN^6{w=#TO5-#bVuATE7YIufAk)%dH84pjYB
z*#48;dt(i$aoY@l?S$8X5L+Nxj(0fCEq$2~HDvO3ioBI00aHfSg?ELu*(BQC+hLC3
zO{)%*{vM@P@qg9!-O+5nf8QNSTScp_)@rN1Ru#4PD%BdXN)<KwRV#Ll6t$IBi?+7d
zd+$v`X|32n5D99e1VJPOi97s$_j%6wp69vG@0|NQ|L4lNKG)|upX>cv?<+G`b}>ge
zYwkgPv)I7)d9}Hg{C;_jm>Pg0tzW=*`MsUZ`+N_0Bn_q;oH>Y$u6_N5&j^?Me_1N`
zp-JlHVJs_tu->gZy-W~FC{>T*&Zk}q<1hG>zUPT>s{`qxJ#MVkw+2)RFukzp`gC@#
zY}mQt?2lITr?pwh$9fUo=kOe+2EO!G_G7s5>a5v-%TT=Ril3HIV?~J5PfPr@HQvxa
zh?gOui??-6r=9ASNMG{i51Ajp)<y8-EAQ!EJqd{HLQLO@?x-Vg&fs!PA{P*VPs@&;
zL~6%oe0~YqQJJW_|GIXdq88K&StjbfTj9F!9Y@uCJR24HSDgX7erMO}OLAPPLgjvg
zlhN@NE4fR+8|!C9eGPy3y!e+&L|-7gW)fl<nzM7a8$AkYs0MAtk{UEeqOA3_sM^qz
z)LLL>e1Q7e_dnQ_?efp{6Lb<S#)DOsSphR?0?`?4GL83lP&FkQDMzkSafCIKv02hI
z*YL;nUWJF{GmH87eBtCE9ZzvUI<K*jbZr{l*x7hGDok4s>g8gvl7IMjq$5rIuCf8L
zsQzrIG<zqb_B-JFAAFrv(N_s_4t3M6!L!|tRijojUJ5=hb$SD#-8x)Cvo>{_jmz$#
zcYTBxNOfyAh(i9s;-rgAbF^&h1&nV(V_p<2B)YHz>`cF>h?rUPe@=>o{&KOB`iAXb
zPyBlg(dQK2ox@=GJ&v9&To`E$inM56o~%|!gjl&JC&p!RtywyA&(L4ho>yO%ZTXHV
ze@4)`=bSpkx*|7YI440F^iFtF$$kCG8!(pNjwCsUb0wgH%-3OjEg&UPM4IjSnY@Dq
zZv&b`T(UH43MVaQA{(@EgOOjmlMzl;n|{P{0v8#Jr;h~Prh98A29YgCpW=hujDs1(
zD8>d>{>ZY6(L`N2_KRL85))}UTaV%?_+z9X5hIVZAb(<bAm!Kqx;FjVgyNN!ZKFvb
zM5SanKpUmb2=tv_KjWVBQ(&YD^eCU|V=35UMVY47j-UlZ&K7>FQGeb!_hNZh_o2Y^
zFqCgswBx=U2n$P&L8?{fse_)7ofpv=L1r5JoYU%(SLBC{eVpGpvj3g0l)1v@!2VNL
zZN&V>5-~ncXtp9kpuoTudmp|es%YR6#ir~k%TTJ$;~SlC+)!pyRwP#iYOIAP$%96?
zmnWJJA?`0;%1%er7t@Ih>r$KkCnmcD(}tZzf(@M&r^GBV{_NmO94k+RORpzj{zUbI
zH?El%3P2l;ZG|j<6YhuCLavS_eqbFUtmiqM3l+e>)j7y_C`(c)9aqPr%r<vBs8rk&
z416*H>102Re(qLtTi0!_ZVTOUAKHa(xA6>Bq`D2-Lqay3$t2ixj}o2XZ|TtKjBo|O
zL$9Yu;*GRx>$X$XYt~z`AFdBCX;K9%5j{tu?-y7}qylz6D)Cr<h?9Jf03m}`)4yu<
z!sUO^5``g;=8lfxB`uzfR(Q`)2EvGU!i3mi7J7S<(~UG`nKfc#Ix$g15hbKpHJC6X
zrOg612pvrj4*wizccUeyTW&;IHCMU1r$*IIHTc|_ZRSiB?*6KqNNcSIP(Or}!&8Fa
zveYuWeLLniL46AS3Hk}TK-(1+#0MekA(0L30nd<Vvaq9^rP>eTfJ~3uD2(QcY%23J
zkt&6#&;<!z@^1Xsg_{+f7}KpsZ40}?Q%ASp?1sPJZZkBBI?m9+xKXP042@p~Jj0@;
zkk$h=p#1duCsm*%0Jo&Rl4F4f>kZ39u2~xyl1N2}u@UDxRRc5N{uYZ~_S>3h4dnIT
zoXCgZ?+Gv0S~rIDQ&c#0k$0}tMU9ojwxjKRqqi^W>SugzX`r5KrAkDu%}`uCq~ht*
z)d|mY%J7d&Gy%kx{wOKul3r}??S{smQkww~ssIS*)VTT5Ud-X|X68%n#I!p<a-dyy
z7IQKE87nSsF%yquyh^qLule8ZB1H@vc?T-zwD^4~%TL7D(kI6DjWfC>>svn?n;+2f
zSRdt2E2K(W%aT>2J9kSgF{x}f752^-ghFn{(DXGQx+(kTQ7mIWLXdOqhP_o~^DTe(
z7Y^DMjJifDJn7X|{}8iGX?O~TYNmc;wX}ay%Y>zCXrGUJuz9sE5d+RzteT;NZ~KXa
zcJ&R|m%LZ&J#&xp`*2d=-lp?Cs;FhZpIxIyY-@!2YEy};_rFLWiC`IXs_{x|KT9-F
zCWmQ`3ShP$$I=F7%|_;8)~lEhZ%qz&7swh<w)P%UEy#V3|7}#eEqB6P{XcUa|0{&?
zKMyuJ&B+uEx1%=!CoGxr`$1tD1Xxb-m(Z!z&i%mpG@kN*LMQ+8|NUo#<3Dt=|4wiG
zXM<09&rG9};0qIcjPR=)aBu{x^wQlhEAiA7!h>AAArv<I6SA$NIQtb18=gf-JTrf&
zj)7m;%`@ftyLAc?X+82fX*&3nJSBm~B6Sr>yH@G<a!uj%l7!-Izug68xwF4E8jm#8
zHc4UPZedqiqft^hoG{5X^eGs+JO3~<-x&Qc>T3BFJyp}snMNnJyXMZvlbJghi0&}8
z&KWKz*e!0*d7;uuqFT{s&&ZhS0<*SX&+zHSeqi8V=VL~KU!RYyKv-d&o&1$A7b8^9
z%V~SEL{RKofeXw$gpK?cXobr+fN9BM9OUs6%ruxOtV_bXR)p}X+@0zKd!LJykvh^t
zU}^cDrBzy;>A2)Qc8)<_V(mkcrKg|Rde1QNmBRj(4LS`*%idt$Ma$<i=iZkt_khPn
z^GA@rlf9#s-BWKSsSfH&o%spV^w;3tdKJORc9W9T$e^;0XI+4BNOe@5{kVbpxZ4&1
z(N=y?np;5B9Pjkd18O5W($Q3@S$9j=G^d40q=~+j3Qh+BcXFuCMAU^Li+Ud5A0%)1
zrN0mK1phER+vJ!+C=Ml#$Mjn^shbkyfV*3aT8zqpS|V{hD`=h9Qp(T8+E^tK!G(Us
z35qLio)ZuX^Pni!@W2nl@;zw;|F+-eb&R|X4e=5{xoS3O2<_{&!2<yEfZ!u_T`-CK
zN>sx`TNYvWbuOUHaAx2Si^Jb*g6^DObS(|tDNr$yCf)V-;Vq1?(&H&rgEj8D0Z5By
z!TFxmBB8~cgkltL)zA*^uF!^xZ^|OVyux5{z#HR|Jx?&%H`_{TH@_pWmf<*L8`%d3
zd`iVr(P986wKw-)$`!q~$|}4gd%Ay_S=_34ikmUYs)%|J%TKUd`+1x$cx17A$$8GZ
zRpY{1>xfUbFMrLfj-{d4{fTck4+1{zTL_iRc2@Ltk}kd)Ug(Tv_XEhP&Amr_QAT|{
zW}NP;Y70N|U&(8<K)vs|*q3Rta^6r}g6F7}H8H8vo4TQvr&Jc-Byay#-r-Y_`~?=2
zZPnW)p8%ZU@S_W#?N;{KPf$>;^HWM_HPg}_m{Kf`d1*5_CoZmx0s}HBDwN(Q@@=v(
zZ9XKJAx;TmJvUO<W^*Cdr5Sd4420pU+_vkY;$wVj^B)&!7mUp7!w>0^;y7j8>IG8o
zD+#W@tcKd!bsi5*%g0uUT^4yBlp>3T8QCqI>mlYRkbNl6=H7b{mearjrCVZ51Cbg2
zFD)W5gB<><c`Z@;cb_CxE9yF=MBIT{;FK%B?xu-t;SP(XH!{psl{$xd++kf-=*{YL
zhfP@W;SJqf_Y}HtS8TyDEY>q7+wsD*H+1JR05)hdzVq>G&&X~Ymj5sEBTLSMcDn32
zWof3-{s#T#o6nze%{6{)5rNJ|9Z+Nr58y;`-&Bre|Em;84W_Zf{FWIb@irwW^5{@q
z3m#PdVR={(KeF)|8hG|hVMUyj*BV|#x)0hSl@`F5dkpEi%#eP0-y^PjroMG+M8L$8
zVIBNOq4e9>MC<hiD(>--K%6;7L0LE_AQ`5X-E<D-gl*I{=WjVTmigu1_2^&dX=qyn
z(WC1DMwp7hgm0Uz+_$T2npf<?S0tOCM~2!=&~sjH=+FB$+ng&RVh0h6Us(FZQK+Y?
zbYgXDv+@6d>SV5h+z6>NPg$hd6Y<h@P04!)|8~Q~Zo%;2VABYJ&2klx)q?RiQFG(*
zmQeX+*A)Adod*X;o^|dS%|1uNgk&2KBX02G#o}0w=Y_Id-Z(}KYzy+G1O1Db6o!*~
z<+L`KC*5IEFhr3*M{p$dmp#FUdPOZQ3oe=FudJbEMR(bBR{vm4tFh!^g%kz5ze)gF
zs_3XU{Yq2km(pxv8q`aiFn$&}vLU$a=d>#`RV01`-y0%Jt+zixoHh@kvIyU-p*DpZ
z<JIQET!`1tnoX~*73Ce%-ZXH{CsSxru%IlQ|JU!SMP(1Ak4ssEzsc=gF5VmRLEfiu
zzC9k?#yuayCC0W}rsEpo(@mprQfKDlJq+*C#_l3-6C1_PRW?Td4A^j~Q|T%KRXDzs
zFadW2O*MF|Kg4Sr8Il+GhX;MO!PdRB>SVPDAN6^OA%vrryFb3Vi*cZup4`JBS~;2=
zp-~WDzttD&g{xQl>wUDGybf2@kn&#(?-CwlW{ky~()9K5I4@~D&pDc@(KhP(8eyZ^
zyqqB_<Q@}(e^{dW$1?IoB7_CY$I_z9PRj-+W@8rwwAe8P7CVhPPm~JZc$R%cWc6Iq
zAv0_~W>|aa&JGO;rrxP}K18*8*&}CM-1|2`&UdQ%CkVyp8S&%-+u8^9(%hFv>|Pvm
zcjamNGlP;2aZkTP7(1Vk1D{U!xMGjw>CUJW#j!X{1$R<ptYp~Vt6x?*=dAaUL0zlt
z<1r04h0mPh@GexG*0&8Whc4E;8NfFu3xznb&7u$0+5BIX99N+tq5`Du{bhmo*o>m>
z&ZJ9Z!rjhZaOdd6JDy8(cB}b1mS{?2zz*Uu&Uvet5mAOh5MR;^iEeExhg}<TX)+yU
zr$F!hka`2ziM!;W#o~O!L-zyQjuJtqY7^xFIu~p-huXjW;G%<brREQYQ09c5PxGxY
z=?YUAy2oqq_eYA?7w%7tZc|PkGPA?;QAk_tCWnmWwGiF$BbM4&=}Tu+IyC7e&Z%W}
z`tz;7zjvnEEqRB2*Y3v6k2iixCKv2mEd$vWo*zZ0F8%ykacnFe)nwyve4cn*2*eTn
z;;v0EI(;g5D6Fa```EIUMI`n>{$9DxqKJ*z(%hv>?c8a$Y@XlP<ZORmLA@+&hI-a?
zJ<2Jtnh_HhTM-g@He6cSp<m8Ck#x-Ph8Ti&gf4g)_=2X$wm>#tdhMw!J<Ws_9sF|Z
z*R-!DkL-mq@@01-R;I*I*Zk6(u;<l2*^$nD9+PO`PJ5oE5Ow8F8&@DcV|?~Hi6~|N
z=Sy>9w~&EP@1u^t`@00rAG^!#rBPip+%jIU@!?KKADM4SOyI~XLCv?g%{UY0=d$i6
zEF3Og#)Y^?j$W7wQm$bcx=hM=ShsBPvt8}O-gf`ML(mRp_aZ4GJO!t>m5mb<U5#Zg
zFyJBWT|cA0nO3K=xFc1pJ93rMdb^>gQ>pNEz;31&1{ZwG@*oo5h-zHY33J@P>OH*6
zz<t@@U-xaH<<QIRj*;-X@%x*%{TBPfx^C;Re1^6<#Lj7Ja;c@|prVD-5C**DqUc2y
zh(wF0?w_hM4_7rrfKt}IbOF<BP$e0wJ^S@Cup*>OUJL3O<&u&@D2NKfNDA>SO-C?K
zm_(T}b976<B>s-P5$I_|)0Z9*p13Ll&l7x|i{6ya3jCuF9=U6%ZM3)aWxmCL{<`G7
zsao40ChlE1)`Sehtw~P!$N*!;aNJ5-ZhGwA`wyJZ>uoHZLw)g)_aT~sY49m&hBg)M
z9U2d+-*18K;L0=6<=5?k0c3=A#LTXcTBSB52AF(@KZ#GW5PCd)XHQOq9|QsywQpao
zkBK^#E_!CWPiY$PaH;xpc*l8rFDp4nxnRbArY+m@0`~JhsAxoK(>EeMr8sh4bkNs_
zo|qG_zJR?&jjPBxQnd@`*kAM_5Eg=WeW28SReR;@Akj7>wZf}+e=KnFI4eA{#aa7R
zItlfm(9bo(5!H$Q9{qSTcoqXRQ7T4v(t~=?1JcGLf4Fp5D--u5oI9>5ed(`(IS0R1
zCPtDkiuH4Y_SIi#^?T5=^6RB>Ir1%Wxwn63bfOlwg{g5fx!11lZ$mq3Zw;nO`4nu_
zvW2`h;#noAv^7B(FDRe0qY3oFHjU<bj7`gviN17)%wgBxH7aj~xsL{p;KFmMG3(&#
zCDbbV#k?=W;pcg&rmB#L0P%zXhgqdKgA%%vq|TW%qh;Pxw6N9XVVHTUr*Czs|3@L5
z{}mGW$Kd8uwc&99h2Z0MnL4fg1t*^$&FJw}0oQ*8=izi}g{Q^tKZErDA2H1-z@jda
zzD7{Mp6%eVR|*A8PGG#NxGwZ-HES#-VK*+1eqy;0@rP-{&re(RWYyd`8rIPjtyTfg
zGVKC{jb+tJUj8r-gLjJ_iUQW!Yz`bDc77|M*rEklObb@m=5+Qw*)Z{dI#*1Rp|M6@
zCegXWV?Q|+;aWlh4ZA0$ckgRZA3XjWr*OS6hCcL4)4Hwx>J?0C6{34J#*GR-RanVR
zgXV^|sn55nlhis{H|sr87s03Vwpwyd99l}b5-yt?>hF^FuVw`Oy}qqC$_2v35j1Xh
z7E4cd!92~0hx7kpr8rf@ep=MDc)xoE+q5Vc>_U4h?}@<uQ5D;h+$FqSb<SIlg|L2M
zjc1l`p1diQS3IRwu^5SBZ*$4wIxF^eUlUJ6dnuErk6`7FELy61q8vU~=hMppnVm6r
ze^8oG_A?x)Rc1Dr-u@<;B{_Iw@s8rGZ#?_y!g!3&_kUxXDQej95rJo|qPzzMxg{JZ
z7YRrHOcwYVXSdQREs1D6+f6}#&%&lyy3$|!K0r~VU};GoP(Qzh9IX&9eshPx?IdxQ
zKk`Sf{VOnIbudA_rh6~F{0`=g<L3Guwj0aRsP4T0#Pmv6v>`C=&2j*~%&e{ENtYW`
zPjN_GHO$2bW9#_qY1jmx5Nu#JYrByECw!_$dG|0nVoioiG3>S8jd6*9iMU3sMP9~9
zJYaJShM3KQIkhOBZ}vA?Tb*Y5LsA@a{%D9PB&e5fjA$L$HLMsxRUvT$qRtr&km7HZ
z3Z*x7OI#$6q(Q|!BnH6MH+F*uvnU*}6Ko>^U&{XRYtJ#NZ;preW7Q6^t(2}HW@OfS
zhL_2|)d8=^E{C-^BrNO<t&u!N9qI5%5JPjP`U##(=DR}?{VfN--<0d&ve^@-#Uy>3
zR^0qV>K%J)n34WQ;NznZX-~iVMC$kEBiILMjU*HpKr5#1#^}BPmJ<p*P(u=HbH?r9
zrzLYFj03LQk*#hWP%f8PMl|^{v1R6iTmhQ#Xn#htFIK=x%V+_v@cqfL0Z{iJ(g4{G
zOg2lfn-s|?{#EbyXL(4`i!^;$w?AhiAr=6+lsp4;*lQi{;JszwxU*Q|fo1?6lMMm;
zd*B22O2?+mIkhf%FfEi*$!@QGghpr@wmVScnCh~VtiQ*`a7=h)QQ;&}&{YXIQ-$oC
z%L)>Kzc7BD19lEE9tP^q_${aQ%??bnNgRtR)>b#w(T_g^RzQwP5VmMsK2q7jEr!ct
zY#wCE`WJRn1CXzVtuLxmrR6x?a?4|l2V1$Kso32|yDwt#fbj3NDvEPy#m%chqtRGs
z`~xZDLn$BfJCuxVRz&%$l?r6juZQ9c_?EGQXjr`GPgm}M<8;&GIpdj`g3rR0e@~XP
zmYucBOo7n?ePZIjPQ3uNf;IG0kKXwR84phfjfx8%=VZ8*d$H{RzE?;F`5oeXO~NeM
zaxbllORn>XFnOC7gShS8h67z*$!Z|lq%1!}cvPnaCHGntKnK0Td!|W>`OlCm$7*qI
zPI$c8>js1Ll{NdYd^1RbUre1R^1b4sbMV+{_VOcGB;gQ3DmC<$+(MCJoipD~`p1>W
zp;}3w+9&-(8jb2**UH|SdDd5qZp|G5aHv+DOeRt6<B01wCo2=>6W6|vPycANBnXaM
zT&=i4+FlCGT&1}cGkCZZPU90$(i*f09VTR3tn`je;#`Kcy(fxVb-0yZ7DW5@t$9r>
znz<i87IFyq)N1Mx1wdN-y&TvM1J~3@?BEIg^0~!^05*m|^ecdld;MlReH(#a=%g=5
zaFc0%3bIy*zO1+fv{}w9m7X74`^K#Sv;1%*i)8ayY4L?72t>&hH{##>oZ@G_eUb3W
z&0iwNKXBL;kKrn}x}G|jMH&Vcv}%q<_35cR{<VgV--de{!6^ab68mrz*~!Rlg}wg`
z+n)Wjhiz-UcW#}e&6f(_l62RX4w0e8a2^4&ghXB;cNB9T=R_o)umJMeH*#Z89Hw#d
zf3Zr^gLv~xp3YR}z#Xkz|89<JLZ-5k<w{0*5XCN!*PFF8374F^7kGW+X1R6(6#tc(
zxpGWV*>y=`%4xFMjEsC$&O2=wMuUqsd`i@u2&!1P6+v`Z;;apN@jOf;K(YY#h(N)~
zxhNQ#CLJwFSy=VZo}ZZ5?U4r8u|F7bG^oqLU;p~mD>u=5wcOPuay8SW!O-IRY}vt)
zX{}wsizSZlz<PL|xdzYy=oY;yYM{vMvQ=X^yuO;v3OWKTA}w=ydwgK7YzdyOyj4Xh
zCE18C<NM>k$9x)NokLdM1PD$vzeopaV%z=D2*J>Q@1)Xcwyk~}KT4@kzoNKlxp12X
zO4zXw=4AY0Qwa&b+V_CLA8$H{atw{)Em)Yf&FelYOJK&=q;<@v5CrQ9`jQsk{W5vU
zZOsi--LOqTJfL_IlM*1ZUXG3)`X&`?lDQ14+kROiS5Ljzvsn)$t?;zjAA-3VW$YDr
z?yctw0R)Y7Tt$m&`H)f`fi>3gEBx*7Sd(nQ73g$%_yOY2rqe;m9%&*0Kj^IZ2xICp
z;kumht?Z7;^u4l5x%7m5COCzeBxJE#3DhM9VqOzlpX=O-0<=1K!c82ptO*J3>)QE+
zcxv%APiUYX9kxaX2xJEDQDs)Z^3Nlw-b?T|W$43pAFWv_z@X)WQI(qBcMu`PlT#)b
zSZ~ND{}bEN0JNT~swc{XUXeNN02G`#S191~(WKKgAeoqauyu9c!{&sYRbdtNx@;io
z6?Nyd3r_VZkE*Y6bGYdCd&q-%%q#Z7Q;IcM3~1JveM#c>hnPo^c$Cwk#J_)ukaXhX
z%+o&qnvv79G8%qb9;vVr+z`)|i;*&0aAdI8d~)DhT^r1d4C?eaj~}I)Xn^mNULR-<
z(&q;}&F8+7D<?E91D_;=o)Y3_Zpk6SAyT@aHZ;`&IxoYa=x20{Y&8)ndvBrL{@#im
z<U0Dz=4o5K4CfSGJ9yls$O&wjjYOjJ?oN~yiw`f=_ndx7MYpIC@&n2tF1;gcWnwk|
z@rTR0)*h3l_M>qNYX2@U-)Wrkxc_Vg^q-N*|0p5<n~CNn2LZl4D1Rx{V?=!+XEdMa
Ks#iR=4*f6E91R-)

literal 31792
zcma&ObwHF)_cx5<0!kwtf&vmQ-7QFp(%s$N4K5-`cS$JS-6_)D-5t{1yu<gtfA{k~
z{ak-6%k1u4GiT16Ip=de=lU)qC5HNf@C6(k9IAx4upAs5yeb^rlWU}>pvBDr6BQ25
z{X#-mP{HNNZW5#z+Z6Zxg~0OuK1LGiE8Z5mny}UVqM#ejeQ*^uQq5WTol2HB-Hg}|
zz}esYEsLw`cHUViUPzUD1FmB+5j<>6Ow3`3h%mVRd5@_n^Z4FD5VZd<KA@;3tNR%M
zt}WPO4{6AOkN?n9KmPN-`{4inB?heqPTQ5XFYt)3cwNG=t_F`b`hOS?rZl==&{Mv7
z6N#)T!|!#=X}{4Y<o9Czis<h8%>DY*^kZ4*8vTbRk1MmW945n_XmnEkjQbyb2`v7j
zh3eIz@%|z0L3oSJ-U5_wYM+6LflfOWG{N_6S3Br5YD%;k-8^>ZYFR?#d$=70e?RD)
zZVltmDlBO+s8vv(Ev|J%kdJ0d3%H*{k2n@RS_#5l@g??9KF-&~yypFvr=JEVi?yW@
z-YMp_bqyr*AfghERhY`xb-3vMohbalVJ+1hW<)A@u+VrgSNnm{a;BoV`9AT5e6`hl
z{8`j?>RxXwT`z*b-Kjjv`SxhGWE{PEm4)e8&afXcp4<bvL(58g5EW@0RP|5D{$jJh
zQMy<d0vd5wVX=JnKs=NFLbLav&c*(``{`Dx-Fna4&xx!iLpo<W<0yY-tF5QA+|G8|
z198YdobOJ*Tm|>MzP~w;`1TEzC=$m2+4t{cvGI?++3Irl7+OV6a#9+MW1Lz+W^6jO
z3Z+7|%QrYZ6}((P<}_o!KKQ#ZPnYT=-q=mIJvT7z3?<>}O%;gnaNnD$EYhsE6Qwt5
z3&4~O)+p73AZpY*S!PQmn@tw+nNJkxcZOD4OqZ!unz0!5btN@|walcaF2FRfGP<Uc
z!e_U@_pLamCc(VDJsFIn*L)KYD7AY$uB@%u=oSMPQ=nRIRPVGGpk86pvTs5;(4xTY
zacSf5+Ipek({iwV>>nT~s7i@Ku3Q|0wp8~+E2NYo7<C|3fYcdPq_v{P*&*bp<a}?I
zh0~x5qpCB!rWxst@0?giwdHKb<<PGW<dz61_`mrKJHaZm47_~WNo9XnF8*uKy)8p<
zwIf6y^G^bcvD4m+NbnD|SG=6Wwtv1p=Q_!-oUQV3JYJJ%(v#HN4dHw;zWNlS2k6of
zJl09{A5Q*GL2;pu=^)Y&K`FsLkrmk0$)@zmR*L?YgfeAe;j&T4dYrbGL{@i&9p+wx
z=gm2$%#*Y&xgrg&B%im;bRq}|WUUaOKt$`Ld7K^|mxs%jN2||c8MN=g-}!pym+~9m
zxl&yA=V}#V<c=S-81R=)gZ1s&s4=U9c>)qj*H1PFZCf&of|;>a6{S;nTdF_C(UTZ9
zu$fO#w6`-G_F&V<eWiFl{-KcHxuxP2(>T8#^Vj$|Nk$frQ2nfRiKMtJcBapkuXvG0
zG{RA(lDS3tdX!f(CFAs}qv5>o&XjkOiP$Z4!bgl&U<%ydy)T#jIWdpcx}&};7ple3
zxC2{)*Cz$`L#IV2_KyOz;2kL_c{<6b@eIX$rBBNhKBjnJP4H|D209-8K-|xF3EV{@
zwn0;=yU?Xx4VhvrM&|=w9og;rODH;>Y}&J!@*q5hk>~wU@Ex{-DNpnk!Pa6HpJjc~
zT0k9g^iH`*cs9;uy3CMLGIovpr^&Kwf=0M+6ne2%<Hu<FV=6jn8M&eaD%9IZ)bOe#
z`mXbc-<PDbeW?NhdUd}&3N&h&ALJrGX@rZB=_USYd)&74k($hg#g8^_`Z)`|Q26Qm
z(%Ik1(~ZdIM34;KPUeE?a$|YHU*;XyuVNx?1jiWrA*$54l(C4ZI?1?|2{wX+p}88q
ze<3s*B4L+HExxjFt6r4OA(Xzdcx~rX@euE}0<sKv$=}Knrd%D}#INYKcFM-W-ZEFV
z<|*dOZT7CgOemR*2#_&cf9v33F&n1{M>zvy)ZM=3&=T+xFC$h$rrFC=3H7-Ac9lN<
z-x60#Llo<^9?6jC3;2{O(aVsa@umIVAB`k1K5qn1BRozj4Jzy(Dxy5RGzzi*h5QX)
zSE@lsp;S+#u7U#InV4?X(T){uIcR~Y7r|uU8)upR4|dA{RqXh&1r>$B4q0IXJUux-
zO6M(QHO+7i$v31!(7=FSCd5%<p%ig;8{O8;ceu^Z{Ee~r@5$){BC$#)!VM!zd%}BG
z1Xf`GD856Bg;5I(^66pO^;15!qe&kVS`CS>%F{;P7Xn8kOfkP0YIJT>2q!|0Fiq+j
zJ+9>N`uym->gs9)kB%*-UL7hipiY~t%260u!l`01M3V&^HQAIK_2Yk^Tf$jdt9?^@
zup6M9S-Z5*=&lcs68ypQV&2)-K<7#)>zc_NCr#;d+PyD5zM}Lgrj3%9A(oiSwetD?
z)0&WXUs_${jI#8N_$xa-vIpkhCxmvt;4<|0q_6%3A6L6vL$4oC%+f|SyAlJ*r!=ip
zqeFro@R<_fWlmLQ$E-eBGg~{QEV{p*y%zosjk6N8qspE#W`KkH2|>3{`1CC;r=>+u
zQ8A?Z{mk&5lVqg9C(QRNPz<E6t-2?b&PK?Q{uf;$P+Un0td7|uUg=2L$usBMcOq*C
z^P4A`ax|-r;n^t?ClQ0y!)H?2QAyU(2IbS@WPxcW!H8V3r=<Muo#=3IbVzXNbeF$g
z_zA5^><o+jd;$kI1cM_DPfR2{Ay`Al6p>xid|O#rN!&>Q+z1mv@B;T9`O&3-Q^R<C
z1>XkOVG-`L$G;V1kFP%=pqqdC2CpW90iCPZBB;M_L}a6(y&VQ!M&)1L|E#XAK4FBs
z=WjGkWPj|%P$-h3d9nEKHDiNzT~U-ktHf2axdhV8p3^towpMJoR>rlcB#%5I&|!<+
zl3gw9=iWbUCW)f5(M-CCXv8|IO0kCP|8&?*#pUWS^f=5|_+xBi+_&&oQLJx+d41pZ
z+R?`J5NE-4Wpi9nP^Io5z(u21kf||7b?YQ8ajMegP=DMgL3q#KJq$B^21gfw+xOc5
zO!g-vn-<JWjWJnDKWQld_t|@7DG4yI3Z3mXS%rS4Ha7IH=Vy?M3x6WStvh&!a$igP
zqe7{oaS8gGtQPT6vUyJY*T`MWWm6<8+3IL%kS9Yhc^n`=y7-Tofgu#nh<01DzSsms
zZ66+be)%fa#a$ciJDh7Wf!EJXp2(1B&z$?Jd1}L`yR74j%?E8C3s&iPwACr~aMR-a
zLQkD+O(Eo`kBdR4f=j2uZL5X=vqY=w?RUCyLC?NjF0Kk<Xf_hFH;$UWn~U`vv^F={
zzTmH0o+iCJRjv%P_^G!|k3PF?)Ez6OJjJV<7_4vJ@@YO&Rd`Pefez_$#Vd4bD}EOJ
zZSSC0&Kc}QxrP{1<6=ZJc&?j+vzhZ~ZB&Zyj@6C{I9XBBd}jgVVQ(iDCGT-034Fc0
zYyu9>M7u;!zHT#yRzk+l^Hkd+_fb;F5gs)~t%O(Y5aas?5e>mFY3&$P_G#C92U<3#
z!=1$5w-REc_H##6Ne;KqsUm}-r1<x8(nD{17vDvX1*C?`I*buu>^60+wa2dQSXk{l
zyzM!t7`BDdb?p`=i_G0?OgCs@JZksjGD$4>VEkPD5|D!)##?IC8r(o`+~A)e_R6&{
z<(rb~AcD%UbkIIrwlv{|A?^yZ`&F_Lp+53{gC}mO8-qMO9g+`FZm|9`qpXq4?Hy#T
zV$UKlh4l>#tkylSJn`<k<eVRl&+_Bun=S6)$0sc{G#if=>YE-4t;5mhFP1)#cZh$*
zGhxU5Svx}2`GKStPf6vt;GsZkw39UHf-S-|f81?56Q_65BAsGq+U!T>QkkE*r|st#
z&h*-s()RiyXER#+AuN=634M6%_x4vamIjmw7i@ey2P2XvQ8*{D)@Cbb&M8Lw$(Jr$
zxP4P`eQ)w+DAR+1O8k5N&%Kl~MEo$vF<aw#9y;WudFdxgW2~otO<&-rB!6>vcGJ-=
zaEvoHzAF_YJ!|%VMamvrLWbz~l>=%*Y4bTw?S(~5Ok9HUiQDRxYrd*$+;o@7!hCTd
zD;~x~jFnp-kuqz$`((U*khxjkbYS+61t&Ej_iE!*&xvFD@$qpr8h<On+`BJe<?DjK
z;3mEKuVJNXn-HO}pSdCWMi9l#-RIg%v1~1D#?7%F{!y#F%QW~Kv_HwgSAFQ#KkhO?
zLseM!(CwvNbL5lVzJG9Tqh=dg*W(dfI1|$wrIlBK5i`g`>{umKZ#ito)nDCiRH;>U
zNlCZ)&SP$)cb!){%yTuU!r1#RDnG>|S2I%RYy*>sxVAbe_Oof$2$#vXrDy6kn>(%)
zkb`Lg)}HLgJqqW8D~y~+c_tUZM{+*FFCE6SmRWnkaM_Z`W6ccX`&O-Loj1rTVC_OA
zLBel)6S8JWiAFoMhg5Z1<5Yd_RQt!wc3&uQ+~T<zZNxEd;y~3e0Ria(vr$FGK?8f&
zR=0-5f@=7qBg;>nb;>jJ<qZ(k+@|#kEKz$K;FIj&6X!vas|Vi{ExyAyX`zAt_jug4
zFENU3zN5SxC7eZb@wFK5M^>V5^t#L2$==UVbKZnyKREw|uV!dEy8eNX8=lA%FU$?y
z;TI)DdSPaJM`S@!PVc_rqc&7>%*-;j5U)L+hh=fYhl~q#cgUwsI8)l5=&ZKAdGRhm
zLu0XM-LA=ZJf~@$HO&Dn@ipfWuEL&l|C_v&$Y47&!AE2N6EY0@D6t^!5g_>$!j)xs
zP~>?Sy8f=4UOAlatnb7KJIQInbskN7f^jXnrCmNa2a;A6_nikOn^|LE6O^g5&nM02
zI7npu%yf;pyT#4kYg(S@Ah%>~oOSES3(Ku7O-%bmu<`0Wp*jC`ic6tuujokd*TRLu
zhBH>fk!Y)yteL;a#W)UxCM~(o{w<)9VK|~}KMEr0OtIkn`@?K)HHO=51~1QnTGG3n
z$>yt=V(*h+mcfPTp~wN$lOqMz2qS&9fH=>Hns>k7wVQ5R<aqjyGw+nexn)><9A{|_
zjWZK9E)4p6rJ*z)Rj;IJB;`QaSt@&KS^6p|CpVXMkzvKP*ED$raTL}vULN4eLy*4v
z-?koe0+ikD!yk+fYBIVabP;``F0TEFjwhSi##|3D(z~@yf$MFsR+hc7d-Y<XqR(hZ
z=y+p@SFpUeH(u#UrX~%bY_fhw$83o0H5_%*)#^5|H)vv{Ti1r>grBK-Sqh3O%N<O`
zOW+JBj9M?o%i$C<wx2X)tfLW1<y-R<mN=*BZ{zlH{(V7n>7x^^`goQ-c|6!Y#jZU+
z#wJPUN(eG-$e@ZwnXXJPT`$+Z9H}0BxOavMT+ZP&-S+)e?=GOohS0Q&j+4b5`lU+=
zMDbF59+m%EL}UF!2~Dcm({iDPBa%jw;{u1v(k>cATVnYyig7B445wg^-okt2G>D-p
zJ$v0Z6>D)M=A(e{r3?eAbY4<%E!R=Y#k=(bFQ@iYFR!aqy5`%xapVIR`T{mFY$=5|
zNxW@s5`x@00j_@>@FlCr<aw-dWjA}HHUBe*Xi371Hz}_NNCStHSSh-~crw+p8}jJf
zMmLIZP@CKdZ#gC%@9Sfl2QwEA!Zj^mx+2<~qA%=z6UAmnrP1X$DX*uJ6&a$W-Tt@L
zdJ{p-j^^@#KJW-~`TpzL&#8WK2FREgVg}E-i1lpmVqI9hrS<Oemp0@NABmEYPD<hE
zT;Q(|AtX&Du74`<`*ER#DC++)yW4F9FUoxvN@fRT1ih&LlxqZsQ0C+q0Q2?Jg^c=a
z*fvnw2G({s{Qm0+L^Upz;P4wft8ohB=Z@T&{|Jv#f|lv}LqSlWi#Xc1H(rUzWlzc5
z($cVlHocK-zhkyxygc)lKoXtvN`#_)Rkc50CCE1WkA#w<@&5$i-U{3}eVG--fRj13
z>ZW|U8Ia=<b%|goTMM(1GujB<rF2yHtw?5G#YQ=hU|t>gQ{8B!U@G_?*{ns_L~sc9
zJE!U=ZeJNRE4a1o109kY2L3qi7%XEH22_cT(~VxcY0j#;9QxORyV-M#@v9AhSl&)|
zbcm*GHkKmTCIhb^!3ZBtExZg`tXYpMv~^1_gk($DK{HKJ@BMK9!`tbi1H0jB)H7-P
z$Ll91f@RQp0J8WkiX^!md|;eU=5ZcK;wop)A{$uHMizWLIv!8sM;G)_l^?y&e_WJD
zZ{pDf`fnfqFPqEiKv+;SWmd_~!BIbN#gZ5s7njQGI&%9=DwY3kF?(ExkrN;VycXZ4
zhSSA@(k^%Z#KgpCC%YY;AN?wWx_e7#P98;GSPOVQ&0>J$hD9Cjs;jHtobS2cUfQ1c
zVf;B-?G$Lr$jjs0uAAT2CO%po-E+>b+eN?be~{sSr{$1(aou=23HM<VHs;t^Qo_i`
z*9Zc67d<mGGbbnZuR|0y0Fg=Ib5HcP^76W;biY`#R6d5<+%mXUk=R?zvXlZ0!P3}b
zR<t9OB_-86^=zk5OLg;{%NlWY-aPVjufD!6@r+NgagejqklkYHchQ(j*(W@058J6p
z^3U*yXdWQ82@68g_B<Q+zMJ$`{UWgOg?l?AO3Qt(GVo7+QQgk@thK-!u9V5?`@5U$
z$csg9?QVcNxOyNmI<*|ld~UzEDXri)9!LUs5E?$?(&?ylDx<DYyY)f+L6c|*p<+eO
z>dnQ$!-CQ6)J0dVCsFdkYV(VaHD0G&XI7W;OK08p=!R~CW`#EEbSG=pUM}{6uUXiG
zt%j}{QoQzt^|OB?BeG7O2C8pZ)fxNsS%z6Mgbk%C(yEqx0^VlLTBPJ71|V>q<GJ9v
ziAu_Ui_iCB;FPpPUcVza0bmr)uWJojV(HYI4*wvF$(9<l0PIdb(Vx`o^0IshJu%d_
z`Qdu9ng41nO5pxd-xU#)`kAYMDQ@3>M7cW$XXdOoF*0(~;l`+>RZ{I=U*#7s5}LfC
z>!h2{yO_|rKBHT{F>YH)Iq<$dH$P~qx!vHh_C6JL{TiEV(2^>B4ZtV>kEI67XFQ4w
zAZpA2rKny0M)d3@L;Y@9^@7`9j^?Y7umf>SQK(kK<wf&@CvP**ck`m!jbN66!_xco
zFn+g##tYsLyOon#KMZiAtIWn}ZOtg$W=yjy&Bk{^I2L5^z4)cs0Z67^Z3X6~iwzK+
zQ5Lj)5Wo5>;xiir=v4dHa;e7E+HcZ&tj8!9HQ!%neg2^Zyv*-jyxr^<Tf_Pb4X(=C
zo{nZ)0NYchjvARLRL7&&;B?#>V;SU)>Qt~{?9ui(5|K`^>!Bgxc0dvfXfh9&dRJ8Q
z^xf8WB&Fm4|BXduir4ja&RI8A>gn#Z{J~6xX)8?hb*ui?R$sQzLtW^sY`Ul)@zN_l
zjs=(1+p7~)GA`9p9IP$x0j^DqGLzvne6!XjhwTx76cJF9lw!R(1scnk$hgO1JaF3b
zGp!InV|RlOw}TKo4Gg}#LW5?nyZwff0e}z@QND~@u>vAEI%+*;ta6kUrQ@FmkYXge
z`?&=w!6#qo6Bn|2yMRPC^H_8^v+YnwN4MurZnhJ^RCOlH><JBYc(&sD0F>7)0gYG8
zLO@P&->(I*YWgw&Y~@>EwFG@g49q^I$YraknkccP*6VeSf9dPC-dI{rmt_h`%|IvY
z=f4+C9poxG{Vt~^@P{DdX83)DkO)Fl8S7iPX!;9+0~+`Y<;51H9>A803SVK-+QS}k
z7SoP2LP+(#zuJ8z0j=5I$B9Gdy6Vx*wyO8GjP@?M(adp{IzV{QSxj7WFqC2jb?GHn
zj}f@N<vS*iJKf<v+fjctZMWA|UPR=0-ccW`tlz>`&9KXOG;(sy{;EFhL3z<Dcdm7f
z_vBjt*d2W@_9CNU>7YbpetX*M4`nrf-RG-h>A5b5i{L}nng-h~D}DD(N^QUO_WRPR
zRfZkTZRW~z;@gV;8svKE`i;NV&DZk>-qq*lB5|nv+rh6M=FN@r!!Equ+hMzH6lk3x
z_8*{7ORlPCMMAuVySo)zi{Y$x#`8Df=9@fu(AxmEN8*v!aJBKnrt^q|Jy_RfhlJC{
zCjy_<BwYFmNV<Gg@r*o%-Rsr`7%WXLz0$+X@|y{D>locqG!pKNaLuu=i0^~n2Y(<C
z&&Bs>9bshDV<i_0&A@{HP2fvc(M7?CuWK}A_crjCVlu&R;$IX6N&KF5pFX}1{|Mkc
zgVNIhOw#o}^x2<uZ-sS|Z>tx*Zkiu%nk8J$#+BP^r{H75h6y>Wh<&m7mG#$^2^E86
zkJQ)u1k#I~0i4Hf)qFF5fSpz0w5O)>GQ9t5dC&{Y@+Rs|)bX|~VQDpj7o*rwIQotg
zs>Y?s#Q4F~6mng`!_zgUy&3qifmJ9xS8C4_a|<)xGA5}N!3a2}NGkf<)ZoWT@OS71
zD#hQAe8q1)85Br;R>^zSf=K$PuzHC(fha1rIA?B?MVglgUO3xoPEx)oTT3UAVNV>&
zi?EP4Vsg7-`{!5CuOVp0ExRa2et5+1>&bZTr`r$5<fRGdQ94<~II-dFC8XMoa(RYv
zZurJ~&|H)<qkU-3kFPTHkWJdx==q?ZlQ@}FfTn&Q@2t7XPP3OtQQ{9$`t<RLU@%1}
z>-jS(Q*qfsGxulu<JM=!#^-sH#!5eMNgkePLa-`{ylq#jydh%<eS1GKXmP${lCvBw
zZjjt-6~5iO&l1cRSoB<4g(6?my{-T0&2q){qw`&At!*%GUR0;qF<+K8m4K70z*W9j
z(y&>dYsk!P=Iu349RJx4`I2<g;%-$~^Q}%>fHQwh%SkzVNK9&()8%11pMjN!N%|j0
zXDHh1^w@K&iTeYL*Y6uPbJej!RTrFxLrtk1uapnf2p5@SpqJzy2gJm@xm}a<Ox{Mm
zoLk=iZ5RmCPjb^`UJW;Vz9PyS^lo)Y-$AwBj4A!i2pLJLAofU4#PyVZ7+3N1FYG@~
zH7pb^K^s!uO)sf9DLy+<w+FQPuBb?JGwSb}$8(@lkgD^3K)d(=5&wd+(AkyFrz9T)
z<zD|FvGGgL7vc0son-AEMcc0-@{kXMh}B115#2P2Dc<L9l)LbcnBLSoEeILyE$O{z
zNQ3qhCTLXMc$<<&hhA`P&kAAFH@yNBDPFi|A;GyB_B;Hga|$??hAZ0RF=K7lXMaZ-
z&4j)g8h(rl8B9Z23gA_dWje-R`GWW=r^=4kC|UT|zWomoFJOxg)5QNVbm0guPN&Gf
zLr!|e3|dssV~aGSR2X@DRhJ=%L-bvt-cC$9f<loOLGqR$i6sFH8{1p%y$gl>9-mFc
zkKIpTtMFa4DvTy<lqt13ExQQS{8!|k-x-YI1>hP#Z8mZ{7B}W~e_^OvA{va3?w7h7
z+UeZIFvXq_IlHfJ|G-jBdaEa(ob<<BG)Xla^71o%vuPFY$Cs^?boajBT44EB$p;C8
z&Aek}qXJsYIfiVw8Q=c~hchi8f5~Wp9rs!#QhE=LR`*ch20N=>J`h&jO9ms`r2j|?
z*g9$DJ0Q7U`Q0||%h#98r8`bW;BeXY4!!Yof+eiUC3RBf<BfV2DKc{Gc4nNGT?Vt%
z_BCejGcoM9xF~W4ylbij;-PArn!;KtZ)1HvJ8Demw7eN9S;~-zlEZn0ZCsju^~?X&
zN59J@a56j}7&VD{`&rnPxJMOt&0NBnbk&X`PPg5&`2BlbJ<1jg9B9`8zAFRQ+tGK?
z9ah6h>P)3%K{(QOYZ<&J-F97ve_fc*>O_KYm+gLcej7NM<8{<_W#ZA3?(nzj)6#1>
z^cchV5y`baJl0tgA2y?3ASV-CL9bb7gK3)||1*QV)a#R_qHaq=B+h4~I#Z!<Xqe?e
z?NK5L3V;6~GX&R4oup`T;f%J?8N|NC>%se%&A=LM!?s6izs}A2WQiNi7)THnV&qiD
z5|5*01Gfj;y)?#y$Ho36Jq}5?%z1&E;c@nTphTzg$zWcz73vBtkyz7ZJ^3_h(Q7Gw
z_$@dl!{aIJoJ?2Vz(@0d1I;O6M^2f!6EMK~a#Y>DS`~y?b(oI$CtWEVf;sh|8D3-U
z*ao}%`1am?H}l39LXHbP>bSymcr^ec-SZSs8Nzv=aBn~R?o*%g4+y1DTCKBy>pQ)c
zh8Wq%`&DFz&ZChQs*bQ*SdjB4h7junFJY)k)^D<G?{;O{F+)M;y7lC-?I_!tm9JjH
zT2mCR{`#1>1+P(&k5`0Wzgu_k+DI^tC$>$>C}~x;f5W!C_@=FrB9^TewoR)-Q9YD&
z?|5+EiUik^3x~E-MmDS30&76pR*HJn{Z5yCE7q{3>m&e4wTI$E5%RTE0jbF7mJv5v
zSfT&qP$T^W^@8*#XuJolYAG`ffqJ2M82`129b%TV7#1?K#cj*3xm_G{cy1vSc|wUf
zF^BPX*U;`JVGi1pqZk4yf0wP7_{q>l7v}p$vv<HWyoEfB7i)0NaZ*#sT}?pMFtFsO
zp@nZv2nIAhxuxI`25*9A&?!)lU-A=Oq5A+i^odd|<m6?tehV#pin2uD*&t=^cXGWJ
zGom>?n*u*25J=!Cp>-N$q{koa(g=rC^w&CiuI2Z`w)TE+-mH;&Eo&)Ibo6+?wZ9sY
zpCfdTKNMG$*|5QNuttB{;XP;90{d~GdeuyFyZ1c#zPnJ+)h2cU;$<}%)dHJ2hWo7d
z;_}d}T&D~BGuj`bx)O8h*4n9tR)MX_`@!>T>1+)-;XrGz%bD_GfdL#h(ZPo!-UA&|
z@7_}|Lgw#34!Id=ZEa^O@qbYxYCw=Xszn&F3IaNp;>4An8Lq&R?Y<B>uDe1!aKi#=
za3a1zXvq6^c=a+pw2Wz5zhjjuPiCyG1{=YTg%BxNHBj<k+b#VJE|z>2oyH|-$4k%q
z%u#h{kJTxWs?|EE<Y%25p{K4p_BU;yrcEaUJOzF^)eZT|!F5_C@1SBH@P52J!cvd|
z|5|2pgs<uOPxZ?5*5#S2QaCbfD^uwP%gEpv(0Xfnwi2=AW#S;F@lWH}V)}@@qV~~}
zB3REh?!;9~W_oh_VIp<0$)j5g((!gBX>anx|7IsLr>rfaKA6Ws^oJ8Gby{vwHvEhc
zN;r{?@IJH!Sl91WsZ^gMo%fXLc%{8NcOUCPclnHa8Yq2T)xH8%vGl!}5uv?Gfx1rG
zSeDkX;crtL0pps$)77huUpy4y0~vkQ-4W0zuzZGDI&(Png@V9Z=Y3|xAu=+Wz+H|i
zqr3J{NaJ`l-O^!HYK2?CaeYdIgqBO(dxO}0<P|R0IOO>Ud%se4<gBTR_l%aK@ab`9
z5zc3a3)$8$51b;7`q8x<<r!H$uJ$&Cqi~uow$+&+wwk{_8D4(@;TQkF@gA2nN%|ao
zACCVQ9YalA1FAOFl0<V4kj}TCrq+@4c^>GB*<#woThe2J;I6bx2z`Uv`kEI<LSK?B
zQHUSQkH0eL(nK=o7ds`*?w$z3H$%QTx2p)1PUo*Ozv8uPFJ9s+#6eWa68#Nn|G@eV
z!N#Bx>W?kyryVI|M;7%0p)a>y_+7Hq*)Z+Xww}LUIB0jO%*P3&J&Y`RJ<q`^{zb5n
zU?g906OHuiEz`kwWclN(clbFlqPQ1EM#QR4@lYJ8+A5u8{DxwOnG}Ir2)C~|X$Gp2
zVLr`;T8~ycHf|mi!a-e_YSwf3yuE*z5K3*zt->ha>$;rq1UdklZuf!cMm1EOMtll0
zR4KU@&b~`ATSshoi!9XVU|GtEtTelnCGpxMDon*gO?)I`(B&Tc1uK=tA|2PV5m?_a
zotDwM2jfA4Nqx?T7II9*b*=e!(fboK#_U9lyn_>-P$;K^EC=4DK|}MWL^}q1mvWWw
z`Cd)FjHOFdH~hP-+ji(dZ{6c4_sNv>1$DI>Ts}^EJHNzSmhDg<X-Ls}C+fZor7-Jl
z%pbFh80Py!JtiOM_pO62Y0i*#Gz<pmU31jzG*2pI!-~{T<t(Lr5p&7I8)Tbk&&$ad
zra*}M>_gY5*Uxh`QkvVS#GAPrxNqfD3dQ8sOrLg{c}Eb9;w$C3q+z|o-zgn!Up?;A
zYL{6>@WXV=|FM-y97{|1^{F09GwO?iWPI^=g7%fofn7_aevzi^pEdT{ov{BN;@2y=
zOVPa|H405<t~6$3xSc{|ti~_V(Mdv6(lI<5$G>U3^dT))aPcL*3Eq_cWilU1T_*OX
zw$wirjR8}#-FtESp=53JE+$_Y<0{{}iL=33uSTfD_Rx(7znX@t4)-j8N2Wek`2Cgd
z{DI4~$c6bhR6gM&E>yl`>0*w$eCKWW&3jv?xZF?8IoME@&<_bN7)RO{+mpv=J%?9!
zaMm}mxt}PJV<n=eIrcmULyA;S#Lfp=l*6o%e|nGQ@0}~pR>jOzSuWN|SY}np&sIfL
zAM?0IF<f}c*PBybl^HLx7-JOfdJfECSH1Zra{b1e$YcJSpKlZ5FTGChgjUG(QlGMp
z5RL5r6JzRsOQrh1eQ?#N@qeUZf#16V`cD*<v{r-5(O#!_@aABufZJ)nQm+euvhtOS
z0Ym5kRl6Oqs4gjSF)<@jw_(@Q-dJ6L)dJk0BCW=2z9PrH88-Ui0#%k3PJlnKIPcH-
zBBFPMJy_V(EVud>t5@%r53ESBTg|!rouFHZd8b@uI{LOvyW8gp{5Ld`9y(NFP8$$#
z8$6Q6@NT>5<LT6^0D2Zi#8CtYO@P)kn8@}QFkqUmDqjhB@tTfg03HfP=NE{b0Ju>o
z$-@<3V7-iTKU``tPIf%qk{tjXA4Vo?{gaLU!4$q5C3<lm6Q}*T1Y-&?1x(FD<GLk*
zhufEiS)USwvdkxo+Ad!{@upME!_H(=%cQWLt6?(e3fF57RLqfiQvS>JBi2NbraFLJ
z0CUW7cghw>#-K=}R<2O3GCCT2t_b+~)z*s};r3Uf4X!5vM-8}iYL6r+>&2${iS^#N
zgfIC3QE^#m`~H1ZyV<KBl@Uvtvex~=Dsl*L%sN7did9O}dYT#Ox)n|j7QJ_;N@XqW
z`r?_y@eONDu!=<1!zA#zJg*(<y0Ibts6^k8kKF;3O2Xq5OvttausK_nz9cUD?nugf
zr9wS~l(<oeV<TL8jj3X7fi>&xkxb&Zb!6pC-Z@H-L_7M+{F<dE&zr7jI`vq7qy9v;
z(X7w2py83#wL6@S2tQM4?jOGV$pv5HY2=h#JR)WvKzZsMwgK4Ue7>t1379LJfD2al
zolm<hG~SgH1wLFVu_Q?<cwE=$`znCBB!VO5YWt#TUOGQgoQ^N4nUpPn!R`nq_?|#9
z{!uXcorC`HXQ_jsU#(!=@!_|n`kh_&rYV@)!Uy7Vq#`gt{`%O*AWC!=uxj+%FyWVS
zv6ji3Za~C~(rEVLJK6;!=!?fR)n0@7nCLA$`-en$PfL%F0+={<UARwr5lQ(y#4&?l
zq-AHP+oN-}_5h_MXy<a=!QPu360uxp;POQ$;THbHQz@S<HP#112GHQe?=SFc4~vlO
z&p&YU!U&iR-jn9?i1Mwp9bxZ;H-L`)`f<mmy5tj(>BT+3TIQs2dEa}i1OVdKs_t?}
zmF28xAD@_E?emv!pWz9w0$8o}7623!(tp`Y#fWQl=1^+LjEJjhG31dcH~}k;;fozv
z6l0`gc&<h`ktp?ZVc|7pK?gz2@N;^CuSTukP@m=Mtk1z9$aZU8f+#st0Mp{k|CGQ?
zoTVlU$T;+jwsLqVp-9+IxrD1C>&WCpe5@kBg8gDEp3PaKlgMiN2W=6=84;;$=D4<P
z0M$EUtcZzcr)L_)f`8SakARoN>&pBDs$Lb$H1;&A4vg>iSXj1_0sj@9b<fvm*<s;<
zwCMOANOw3o!)IY(Fa9*-9hkTx(3b9!NOW1`x6TLNbB*qJwz_w7U};oI0*+*g^esuF
zWRMJO!YO95DwJrtAb1&jM4PZ*A9}Vev~+24A#WW8DT05BN4%lX1w9czLYj7hFiyO=
zdS`~Fc59OvQ8zKvu&Uz#OmZ0VF;tM6Mv?hjqP84f@Q){W89%{zOu1QDM8$R4a*^fa
zDM*!c0|UCGKRn9q%xOy!7&F!IPF<k%rjco$kQdlL9VMAi`t?wPkTA*InoJ00b&jfd
zU5^#=6lhG8sOL+)VT8IW)fa$OB{;45#p;_8>lIiujPl{HAGKC40sj$GUT0P6V=Ppn
z57i?OS*yn8$>K^;K(ThSRB+lbvk^X1)H6H^08g@I%1k^>Gk1C2E*=S0&!Br%t8+}C
zrx7m2gp9H6bMh$RRDMq(Raqd)w~wO4)IC8wYd%zdp#!8xg--b~I)J;d057;ntg8q!
zl0mx(kRA=i%L>9NJt+isV7loNDk)vstqbb(!dZ@gC%&&vH)u4vIifw`TUTeH5NL<E
zz9){GCu-B}Ci}t5$f83L)3pS<RGs4dqvO;V-u6u*QkUiP8m!wmz*ewsFP^e>O0|#D
zWlb1wP58d87g)v!ZM<PfjL5|1(b@Kp5ULDw1|*o}myaw~xVQ&q>djU~3uG9IfQTHt
zBxHdrQ5P6m+{gH^c~2DyOk6p9V&Uty_dcp`2S^L?GQQzeWeeN5f9IR4Ay`>bqIviB
zPCkd{n=#%$=J()@o#4s=YHG}{TH>8JiSHVRV$5!*TSILBvd+c642NuHV*x8~j?jJj
z>6btFNa!Xkc~93PFIJWDhNeG^G6u#bB&ag>Q52XEq%+gSCHVj9>zm8brTx0-rC0(L
zld4^)+oV1`>6iRCIv{qi@wPhqW3M%b5#sc7z5i39=wEpxj-v8%dw>oTJ%JMyr=Y;8
z(3$79TNA$z{*jodrmj8<2iHS^j`du^@0l-df%NuWY;0^%QBg`t3JV;ZVI<=BuNgwH
zUsmce$WG4AsXWd_fZv1;_w&;+Swy%(&L+s1<=)@wUckczhl`8Tnh1hK)toKhlwg37
z{X0+kPh$2TqRC_9nHWfM0gBK+43>W-+W+Ar{8wYkb^5<jx&Qga|Im%jV*-pW2YjjG
zC&-u$!N9$0>`ev#owfh(IuoRu8XwPu<bxr^D-6LL{{jLtNa9EzT%4bu$2@@(e?@^6
z`QkYOok}$~4-eRG^_XxvUxkI_e$|ZsL*)7IQ*Zy9%-sLf9R5N1$^T0#?|=H?f8Fl(
zVSISF6r4(m9ApP6=yGEiAS=k_n0It{A&|(V@ARRyjn}ZN6^ffq>$ilup(FbaOxxgO
zqi{6q?yt4?4@Rfm4BOSWn=~I@88KPY=BX=Y)zD{NK!CI=pSP6iQ@y?K2uqbaif(V9
z!5b4qMngqCJ3UPj@NRl!MSU+^p1aLQY6&FngVgTQs+X`X>LByq9=2X+o%=C(ETem0
zwt_=0aL2BnO5mzn?<?uume>{2-Q68H>Us`A<_r%EhhhZ`wnxjx^@@%4Q<uCe$p%cr
z=|=q!BxXpxTORS@;G4Nk{y2Ac5uDV!U1Nd!qp+|M*!=uFaK+RB4f6@efWEO4&4~6S
z*yvLonwgncSV;Nh!525b!M9Se<crR);&z$I;7KFle0zCBz+yykz-~Dc-3~Okuhvk-
ztfk@X$KvgVbJIyO$QUVA=-AuaZ?CA-+O0oM;B@^jAfFG5k>WVN24Y$3vXKhZuxOe?
zv#>s(rtb>($D6blq|etyW@l&TKkg!zs0$4Z6?nKBBmnuj<bpWsn=Hs<YH-kFgQfQS
z<>hLau_tiP#?J%5`JT*$NA--<eYX_xmCF)H#<XjqJ!-3knHfEOm&`DX?aHGCTPu(*
zBJK)gnfk7&>EgNGC6r?(xdL}-T<tKyIHkJ*n8m(>rki~t>xSjOGuS`__AohEg9SY6
zXru{fF9NLHk>5T^Z6v#kQ<5AES%9Tpwox%hPk3MTYAczySbMAzC4d2`Khn|KrXv;~
z?im;w4$V@S6;eoY=U>^@5>rZa0N)g9Z?&tqiwX9%@%>hMSXqi$!33-pQ>E^Ejs508
zu6#D2+Bf5qfZKb1PDrfQp_l4d?^pnih``;pwDK<I16aBrO!^&@P3M(;T-tJlkVTJ^
z{=R7%Dfx{L>%Z;f<>hUC!H(TB{~WiWJ_g$yNWK{__KJz@{Sx-r1&(`Lcl`}LKFER&
z4arpE?(Xe*?$>S}Gakb~mL%k$fz@e3oZqu*8FqAXQo6Bd1`7d9)Cz4yRn`7%buqYr
z*8c2YxmbLlHWs!s;FKmfW(*R!^lJMrV-QYwfC&%O30R#+DgNiJ`4EhwXo(g@Q$~XU
z0RiEgzkg6-kF<`BO$pe(TBvlFj|v1(R@%FVoBayF-S6n=Kw&Yu4Qs4FEG1Vy=e%DO
zZ80=5LK$WD&$O|^$2KxjGtxS8C+(Lm3%%w{R{dtHdF)u<yIv*+lGpRIq)_dq2KyNA
z$IaB-Th(Xf3*v}Ne=;;hX;AfWbI`2q)^xp--yKCoD&TdCUdo<wOSBF$jOcu);T_(e
z3jTu4GkFO%m?yDZx&+uKgvg<<ac`qoJ&xM(s;^j&=bclz9nGLTt`h~Spyr{tOh-nd
z?(abvU3srkC=tiNq{cl)@{%1OMMG>rISHTj0&hqM?BOuUya}NRG<dvd_*b|0TBgv)
zl>NnmyEWh_TQ{C5xjn{5*MEzPRm(R3cI>)a+Ig$3P3n4k)Y<%Se}i%uu>t~^9y*{?
zyC5@&cS9qgChK9>tz$#;T@joAX1ClKY#sCB#`9i=W(O2byR`rX|NOo~ocfF{&>t6H
zal>&By1*^Q4Tt5-SLHr75PG4!(?eOsq%&vGs0kkc;RQeE8$h)eM-SBFs*DCOfvpU@
zyr)W7za5=QI3-B0W?;O6JOS?X(bZ;ZCsw%b8gT!4keN1sH#~t>@@<nFl&<vO7My^O
zFSu}%6-iUL?7tCtHdzBQ2Cude@M*YlPv-?lZI2}4O-HllZCX*oc#i`H>+nw=H)^WD
zqEO!@m>f7zd6f3%>jCRvvC!%+O(Y0q0u=0g9YnYe|1_S0r{&Uuju2AeX_s{ZA=IW>
z<72c;Z-sfJu#~u-Y@kHhu5lm`8Kn&uHyTfZP_EWySqRm?$6<e*A5=GhB9~Sezk3%#
zoCjekxBlid90$m+7fSOUwS|)Kj7a#lc6Wo==%e)6*9#YYm+Vs>W$Xp_gT_#Yd+z<Z
zzeT`qXkO&`)tD9ES&nS~+_3<w9n}HT4~LvNtaFqv!K3rq?9XwPo^1TEmb#M#43DE1
z0Xs56gwKYrK&I_^`1kskR8rU{&x9~#WB)LI)Idc<%G5!syGmm+W70C=;JFsGD9JkU
ztD}+63Rq;8$b$R%rh>W%(M?aVg{PLgq|E!l>qrX);R#6++i#bsz#2EQWL;1rqyKys
zl#XOZv41sw!-X?^-AU>VC9Lo}9M4xSkENBJpqsN>^t>>QrY*$pV>dTO;4VEBWcg~m
z)lC<TGT2Umrdq1!N2$*SKPPwgixRl|SYCopB;S?)ZGkQM1Rb`3ux<z|b&Au$@#@$x
zML0n`u^Jplg!vYWjAhuI2n0#p7De^3e1|z}R~ClLf5grDt)9s3hg4QYUaYB-P%Q1!
zQjtlGS?yU6-Oac=p%Tvcl@xrp`N4k2%G26_8gq%tyFR99425a;-%lH-a<MaK5h@pH
z*v5ahY!Er}0Bhk6*5deLJ-$@HW0&fywr~X(*JNYh=R1B?5a#v2KY0LA%t%J*(m_NA
z43zf#`7{MXvJ(m&u+d#eMM4*Wr~i~9@mq3=epn&8UG97IQ+w{0{Gc%BtyAo?g|E+F
zl68@F;BXrRyU^6UDU5Cvb~cSK(UDL$W6-RtFcH7>N0w0krlti9L1gu8nPCvkGyT`>
z)10t`r>^6KrNRo_Ezj`jSP|rXFolQ67lQgpa4S?ob~IE<c%!@FPfgHoFhYC9R!~r{
z`{j%n*!1GDm~Ch(TI`@Eayi(uL%|VA+cduoj`RM|I!}{zC|p#eLIklSBeTvH#W@h4
zOBwo9a>AEs_<e2(S7h{JH9uHnLlg8@%FaS3Scf{UP<8F2+#LOmH!!gOmY@G_#Y{Fd
zjBfg4Ew=zpO+ZvWRYNC{+c)Px%f3)cG!?Fgis`odeBBl$a;uSy?s)x{w>zE>H}gW>
zB}Q}PhrH}>^s;>jaighe*XJ{|c+1|3d>IUmh#J!O5PVikUD+#KFt!@-QzYiubNZH-
zn7@+q^nU-aZlW<CaV`8(x&OJpx<sdp|5;LQh0_cBr7$DIwk0UEyr?hd^=AmH$hsba
z(8uAz9+)A0RYLxd%1++xdx3i$Gk=Kh_wia8JZx&;!qAI6{^*zO^pPI4XEp}$ka6{1
z1kBdoxH3pb!cbM3(Tpb-uWXeEL>;Ahpj`>R&@QaZK0(W5mZdxvowy*$@0m2NVMcrD
z(`?P8G9-gUOBX(?GhD6ondRL2n95f+C1Ml(gD7UnqR$mN)7}2KH^|QC>ZymyU+JzY
zCr}Yz7l+E?KJIBC7nM!tm7lZzQ6HwBMu>k&BEm#vQsE~bRC82eba|~HNg#^Tg|YK-
zVfce-@&y7G4Wv18woC1W(7Gr(W)>Zyy^*krA5LTn4K$#!s2%1ygo-GB&WKL;{DiVo
zU*woOIxgBk&e_hW@gP(|<#03A+X;_M6f0chsHg`vUaO<}1wAW`TM6|h-0tqEfr@;b
z!(TNVU2=!|W<{_94SD2ky~NXfJ{a$k!pt}y9hADc-RBQ%9ZyKEE7H|tfeT(&ki8^>
z*k?^xto;1%ej-KM-HPjrJFNFfF8K{SBf2d+JAu4_&UE!UBCWh2qk@>FfIHLaKN6Xm
z_~3q)9|HLSHkC?A_dyQkq{wS&AA(O^&l5iWR>bYg*fF6Te0IEs6cI}lvuW@vFCr2t
zyc;4k^5<P<foSuapGbMZNFN(cB33lrL|b7UzGHIkir?Aa9~u#T!G20>i7V;)F-MCG
zsT$|Vhp=SJSddaDCt^s7jx(oB$B`bo#nqb;O;L@ZGVUL|i7~WIJ5h1VT+b9~K;zfi
z12R@3&2@BvJ0)cPAIz|9stc`lbz4&S&gO^)GiDZaTcVX{CYOlU6buE$sfuIeimN3W
zR+)P$FAmfO!q#X1Hf%1(!9C3{*Rkvvkk3Y0mDqm&Qt*BEhD9mmhdM3X0{8Sfd2b}-
zk%SAcx*xN^yfaaTK!}jPRd}%=2L{3Vb)*+k8*z~X*Ja=^OsJ|_kbcS99A{-<sE0)V
z;=ngxB<m{oNzT5*j`$LN`fG~eVpVip_hHWv&B8zJT2+SIA3*}os6LO1hJ#|w36n3E
z<Y9=o;5W*)^p|FRge8mvSy^wb@Z_|zT5OMB#-IksUeyn0`)H9>yiLgy-=F%M8~gsU
zKk50`6&*i9;#TYvAxeFlZ;*}ga5Ut%!+tI!8{P!DuW$jkYH%vIS)HUt*VP{)Tf?Tu
zk8f}VR<3^2Vu^#0I1e0;-je|*+cD&*tI5(5E8NHvM!N=!bS;Y6tn`(Jp%_1sGYv>d
z243M7xB=UHkAZvIDXts&)6o7=DS)NLkMz-*X=!QJk)xoX_0RtpGi`s}&3hIUjs7&}
zp8OhS6^(wLgDIa<XQ1cQj5H!-eHzEQX-v+{*#~FDxS@71ZZz`hm!K8H?_q}IS|3Q8
zE>7(6;vGNsHazio46gY$dYF<(6_hLQ!T8|S9J%T_W9WmlyHi+5rKS5IfYWCOW~vIO
zs<<2%v+YxxTsNeuSZtXW2lMi-Iav6X>lMcdtX=p?`2t^Eyc-<LbN+e7&POxf%rQ8B
z)u>czyeZ{cx<;_0Ke({4!+Wu@UATOhk_SikVfNxVoPl6!`t9aIp<bfHFmIZXSn!38
zv7kI1Hpkf_e7_V8eS9E1oDURfPjNDac-?Cc)x>zV)gS$H<xoT7dB=3QJRDp&h@au!
z|5Mzg3ZhQ9m>>T`g8_)L|EF*LKQ{VZ5hO?)$ffVUeRi{5O}K-*kqzpbeAMD0m_$T3
zfIJ0I#)FESUquKZ7iDryZHUA{Cjz_Y>b~3t;HF)$${rA;1Mk!wK;EE)Sy+8cMj3q8
z5P{_=R(kNRSy2aWj24WZ0tw;Sv$f65dJTGg*$<kiZa9c+d&<n`IK^mxs|hJP-`P4b
zGB7ZZlc)du`TL*gG~(dlIRiWmFjVDVkjQ=M=_wOC^p<RWB32$LKr2TWM5x-G%4))Z
z%d<~%3v{@tR2;Zkp#FFLhyuU^`7lsQN@PtzK|#!Aw+0*+ghv^9PD@I*n+q%ZPqBC_
zVK`)Sn&9P3F(I>?jhW;dK6+Ok06wRtrL}waI3eJ}-QL}Wa6~_K^aornRv;MYR&NE(
zknMmpgqB6B0{3<?bNT0JM@=vyy?d!jd#LImh%?LULAkW78!|e&fa8t=a8w_Y6GnaU
zeD3EOH8z6tKw<(OmolgjG5zThUEezGCXep{0r(tNNp=PR-v%IlbbNdc&-Q$M^?spY
zZ!Cxo7|^195m2u|*l~0A*Lk%Ab(I_rjtqGPAj~s%n>AF@h8+^Bb}7ktiW=w89CKB#
z+as~e>ged`{vRCqN3+(=o)32yi0H2>CId!CM;)U87c)<5)E{sFAG0ZAGF|fPpdgt_
zI;Efogpsr}fQqcS2f#&|kD{WYJKtWw@=WLJ904{=%Il)z0rb&8kQyb15;?DrvvksX
zbTuVGZYx|<DfSKqZfHGGkZ_zZ1K`Xt7h7CnHnZqA$+KQ9D;3$bzd_M?eyLGEVO%eO
z=)1wp-U)*YkgP9|je|P*1WMWrl~j`W=g*$Em!&fxiem#X2V5B$E22^?n_i5fH?G1n
zVslkcSPfD~4w~i3kUa}EW@JD+RkpmdX<Kp04*JQK1DyhCg%y?DW>8+f91F?*l#u2m
zk<9JL{IAaVJ+Id;$@LX}mhB9}&IwEV2VjpS<_}O66_uRK1(4VPdM8p3&z5$kO`@n=
zk5DN;q>rmnWsxxB<>e)T8)J$!d<p6gyI?Z=!-{xJOiWqW+!;?}#_yrjy>Sea<DG=V
zN<xkwK71H|#qD6Cqq78-X&i84>pK>kJoC>>bXzNa78qw&m8Hi<RvOA!{(Xx5xWi9T
zU%!5>_VgSdkuB!~En{ZaV5l@&bDoa!{$gG2enwf@Pc3?pc~GpX#NyGx3|Q@=v0U~W
ztRO566SyBzd^_`Gx=52pQ7Va3mhF-Myq%pohC@eSY-~&f#}9#14d=|+W-5f3o9m>A
zpgOW$#*k6tpun7nSrsK}Wv&J-ht};fGcyeh4GAQrq(YmUo9RiJ{!#fKLG3fxIjX;d
zaM{KjH3;bmwm;QQRYM*%aDv7_5Eu+H<VX;#my!L`g#Y*#+>TA}AG`Hvw89}Rgtmf$
zUwYS>**;RqsHm8Dh(@%J`P5zM!vFJQK+Fe-P{j%!8Se1kc2L_ts4xW%%e3_L&mk{f
zyhvm*4m~0OPCS>>ZhWqmo7i6*B%CFyg@*0e27P^fkleCNnyNm#)J=C@0nbqQj9N-M
z??n$MQydOaC7)m&0fG5oGLJD7SSlg`FApQ5x2oY#m2*<YqHbPKGVt^XP7aRA=tBUN
zRGLo`Qk`4!c};B%L`6mY|9k3&VG$Gaf~-heo3JNK3PAJ0Qw><9S2s5~Y*)Oe>XB0<
z?1<r7ADj}vr5peFnvh_t>JVnoZKi0vV?KZQ$)nz#EmuL0hwXUQsqUogH!oPloN3RK
zeh!fTbjF+vA?-Zxd_<CJH&g8G=0P%&JO>2SL$$2{0jq-#I9cPiIqzc`+}dEoqHC`u
z{`6-5k!6ks4TYE7+Q8u50i=565O_6eUa#9r&fzwP6vxI#%>E@60<zQ(_7F6yWM0=Y
zPJLfVUZenltF@N`@UKEd!-=l}Mt95ZQXyjv%${y?QfzGW!r3NuC$~8<uM6Wkk*~#K
zlcupVsB(1y#TDW!+*pTz$eQj7=+FlCtw{igXgr%x2f)ba)^K{MPCb{%iD_@hH3pR!
zkN%9N`I<%&|G_<=rUOKYg(u~tR!IL<KJ~gqp{b(Ab@YI7y*5$)M6<UyUeXduYaC#S
z0}A@_2z#gvF{6%;-%@FszURzx9Uz*2Sq3&C<YQf{^`nKORaJE|%t}fzLY&}oPpyhi
z9QtBSlbU^?;&AXih*mLAAs4E$p0dEesn>=iYYFU)km)n_qfgwzn!Cx)3(vp(ewk1r
z$kpOU^GJpUPo?06@$wQuFG0)*D8f460Tf|;=lC|Zc+mZsN=X@x^xq!owQWYmrSVTM
zmT>4?wgAKam(OXiAU8|g(8n=nU4xg)RV7_rDu<6)Wit+wh{Kp%O6domfaz78-&Cm{
zBkcf-Wem?fGggQ!5^a5hB2NJq@#?ITdM<!hhO_OLdb&j*I|g0eA@t7>l3t4E`E&>o
zhu-HB*dXf&Y4+1jknhlUgHBmV4SQ^;2=1pnCnfwk4z$H8%=zj|sY|H6NeV$FV1er}
zcm0=Ke-w-yQ=r=*rLugK>;d&8(^l^A0@x(I{u+pvB_#dnGm;$ms1voP0A&$#j1Qaj
zELqlNz`<+Z^_<Zo4!M7E$avSv!s@#6oho?aIwkhsLRFRFjJ9$GWcIc{?-M8}w#b$z
z2Vg>PUj?$pJb=f0ki)p|1JDrgwkgN4p0;T&YnSY%^focwwY%eSBQ=isLWJD+O*G1l
zJ{#{y;^W$`dwuobk_>snt^UmJ8HU3nDA8S>=7<{H+tPv?rAqtzhTNys8=n#m301iI
zSzGw4Gk+`5AY6qbfaE&ks<coNKTi{?X0`|DLWhWkzB3-y*94~+9eA_74eb8G_7%!Y
zp{V$$E2nmN$W@a8L6X`<n9hyt-LT)t(qcU!uTgQ=mM_1`I27Q)=VX%B3@5so%A+P3
z8)7zG5O156+U#%a?p4`{G>J2gQRPqBe)*+2hbWi%F@`n<^4Gct?*D7;tHYxFx^_Vv
zYCw<}K#-6Sq@<-Jloq6=LAtwBhLUcSZjkP72?6Qu77*!f&c@&OzTbDwxlUZyIs5_4
z%u{<m>sf2<weI^Ks5fWvfkKyBAgr?i8LC^N-$onX1mNcLSCC8^sX2TF4{GWtM+zKn
z)8Nj!wRY>oM{oQwScW4h#e6N$eRU>4mC0d%`dD%YwJW3cku?RYA5HATpx2fndNy5n
zPTnF$!HU@EEDSWxJ5`g|Z`yfwXnJq?x0t<O$bAWw?dob6Xe7^iX&du48Zzq5>gVl|
zB8?NvJ$i2>*X&|Z9G~OgeSIl(&~#%N&Y+@ki35dcC1$bI-tE*Z+Qw|3fYkR1!`C4E
zr@;_!E9HF;#r=`>2BAW{ZfFCZmy)kXWhpwhTLYuY%b}#N1E}N+S>=IhyGVKW<L`yX
zLj1Uhav08oV&c~bIZPGHbrhT5?&`N;cs_I0@1)9jqW$1=8WYpZ>)0zOChdgdAoXWa
zILeBwgvAH+=c9&^o#tcu)XUaU=N5u#t+4c_gZW7PwhRZlRL@HjTmQb)wFn$G4wa{Y
zTnt|)@KsC2ZX(5Em`5ohTi$62c_Y3%ROx{uWVgYS(Pv3>%jT0ZE<VaYck0~O?gtvT
z7lx-Qi!-1gNH$LQdrKP}Snp%}sk^#vdqFsRp8xk^^h0g08v~O<a!Jl5kPq3OI;uxO
z?ATLLXjP#dHSd7;kXJ43&DJ}Ln3KNMi_lV$9mC^Qa)WTov2nJ{>eGC#SE;u*Db>k@
z<voMp^Q_|e@K8m42$s()&j~&4tQ$KKO#HT8tiyny2bo<3bRbwP@9dqo=4y>pOp&)5
z;WK2EaF}YTv1ZWNlg^<}_Gy9SX&Q?AWYNQKQW>T)Z%Gk{BBA$+G->aG2ITCH3xo8b
zP<cYjXN2g9AN1}$tW^pml;(^GG8cnM%-Qj1Y-J>Otzw6vn*!k{1pTefwZ{FJ<F_H}
z?*_|xaNKM&*h54PZug^VCUZX{yw$1#PP2g#6ZUZWR<w0@Nu<R4-##;Et)*pPp6Ze7
z9C=e|+R!(5nis+FX5&EO6<+jS3tOvtibP~6`bdxgyapT9K1hhaS=ppLzA*4{M!9N|
zl(aI%cym3VZ7sr>7y&Fp$k{akvS|MY%LkxGR)xL3y$Db=Y+DI=`plNCP4nP&eo(U!
zxrmriI)8aMjvFJxRKu-v7#Dj2y(3D_*YBnI?YF#uQnUFc^cj>DWp{~B^3fA^@qf*L
zW=D-Z@2JD4!1c}i+GD!p!Rpeqhq)^yj|=IJesZit>G?n+ld4v!8Bmjb#u#y*W$C{{
zY5Vi$O~sUucxqD9cpMFMYn%Ewk8XhstNz<RcCEBqfy>~2mLa!{^Mpn6Cv%y|onvGg
z&UWbH>o3On>U!=r9{@^M?E|cJERRB`x8FUo+4Rf8$(dNFB|eHA<s*)@qs<}RusVBV
zuG|ktR>Jk#SZ>HskL-TWrdp7ZjV^X;GKO`+ZJpVFduBUGVFrqstAq^V+|@9C#ku^^
z3~yk#4_(0cfR9mvL-zVKSle=<JDQ#|l>Eo_fsZpt+}8kNrz*Bx7EiG4mVOF`SAazQ
z9rg~=9T>m!B{8m#Eq+tMJ{;NSs!wUsK@RVS05jtMeWUchXE<U#1kIR#Q61|S|B=`D
z-w+@FbK`&XIQ|D-<o(Czi!gmY(ho|pR6UcCwM5}7klcp|jYiNBcIh~Sc}pi}D$A}+
z=Vj*A_qn6rdVZcUt22E$Sa)q|o~JOcnf<E!I`wX4)=6{xpbV*%xSHG~q1vKhb|;MN
z=@c)Nv>}oj{Vw+<8yjsBfvBGg4F<7H97W&#Pm<pfE8CuDf~$J@jGmb>1=ogn{R^j>
zMDx&=ysc^ps^A9_8zB8^0MLlNu{;II8<2|T_JRERa}$TyM^`wH<F>drNEckd%9N1T
zahrAu;XaKbNdhWPT_ESO0oaKjAw;+_E|<r2(ins<5w2R&OFs}WYw6=@gn1P@q@JcZ
zjKsHtH9kR(t!bLA0)S5ub6N5^?P^SYDFhgv2*S^g&g-li50L4AZqa?x#BT$77+SS&
z191SI&keBYT2;$GnMeVRp!)fZYvlsvejIL)j8ciF0mxc3wL}zEAcRdDti!^5(t;V#
z@%$k*0Men;1_%BQA1s|_Kt>pvn_IC2R>gEK;Mj0XZ1k)Y0B+I)5Ij^~@I!laGO0cK
zkk9*uOm3(EVD3ha09@@xujr~0r3fgDp<V%LAU}Pfhj-~935qB7;Q_7G9fq&5u_vx?
zb;=eafaXx{r&uhNQqY)GJfATuaoAg!e?(`+pwjH_;%Vcc@KyW04a|HzU#U`rZ$%$m
zvxIJ2A3<2XJuFL5OT`+j#X)6m9(056Z12fWIE+v8+u!(nd??7mCzv8b)cSy!d~>{j
z!1DQ%&~kDI-PBh$aIsgSieh0TET+rT+L@x5DL06j2ws3Wn3jT!`Q*MKq+-1}lnxe-
zIoy{nzk2b5JU~Be>~tlVSxw*ZS8uFlgCj&ey$dW#Q8H<4hSG!p-p*{cno+a-5L5-y
zghxWv2w&qrpv__j<$|rTJirdGX|vV!L&s0xv_Lnvah1<ppl9+%#13%oj(Ra&X@U#+
z^cCpB4J2}fPj8OqhD+1bzKPSuD<Rqc4oHVMoMG(Spb@46aDT(O{KoSt)(0z{V3}Q@
zQ~(<~1wvcM3chy^09=?f4&oDN;Vj99ROo=ndmRxb_xx7PNNA=r><?I5u7#2EKe2jN
z{Oc1W^jx|xd|Z#Ay9)UhP#FbbEkL*ma+|@>jTy-J*D_Ln5ZdrS*I7jS6jFb%*|UP&
zIOTYX%;Q*&9oDGdgJVmtT!?BXTa=62p8c}W-|HK&7AmlgrJW>Xp+b31p%eCsJP>$w
zm%}x*enj}v(=idAaK}9g50C-Gq$61CF^Cgg&H)JEHefzJkS7i0==+|+Zh}Kf^Vu8M
zM~({!paD!9P`sl!Yx6;QN%Cv9$_%ALkQjRzM2tZ~3H{PBRq**XprqRD0)sAVBS$CJ
zd3^BBbj+>u^S4F9O@RH7h%KE*NnGC~ZhBD24chN<NE5)~$~5~xty+XU<{gub5>6dD
zEc(O*ON|SrKTwAa6z1CePvLYA`hO#R@J*!nAjXi(#!a@i2@)Z2K(5YDGJ7xXUN-K3
zxerp$LFp$>V{=i)yE9tF8c><CUb5>66+46VBd{<DSW932y!ilJmcyb>$DsU>;@*B4
zXki_k0ddRU0ZlW5fw1E<|I@GS@82-sAn81NY}ywKX_6|1&<T=qF7uh2w(|PDhZ29#
za1EJCLs{-y-7hF<4k{;q&1e4Emw&8v6jWh0^;_Y1D%Ivh9;*>mmJyiAxkwDGl+aCI
zhzB_!#zJ)Nv1AWcUTulzrdInTzC9--?5~pBQ^L-c&hJnu1<ZEQ<uv?&*6e=1IseD_
z7-HVQC9vv=x*=dU_kcuxXneEshhB#>J^vJX9OMkcQbeN~!yS<R@RrnmsJ=AuNGa3l
z`E0#(;Ylgl%lH--(28@Xz-1<Mz>fuV+5mNO)Kb9nzzmt8+Y5DAG@142#eYo0nu)2B
z_k%2eE`7$#@Y(r#6=T)jc2pG`U_OK2G`d!I#u6F`;$v&^Kpzov_RW7F!D$PTCr~sE
z`MinWHc_h`QLJW9{J@78{^*l-7rX<IR<GSj;Km@!S<_g2VvcYF%6;oI#yC(KC0z#8
zK($M-7KPeAe$g2(R_`{c@itn*NC9;cV*OAB%{{R_e9j(LsT8uk(27jvlTe2U%+hem
zLT2<8G((zO*Cq9WwJv!?uLC^x&w~#}P?%^rxiG$v55Tnsfka;tB=jQ9qJh0MO}9gY
z0gSIKO$D2>g~7NF(PC)@E;XV$WM2NcU5y_U_{jZ|X;XipmbO2Q&26GYV-TPE@{PI>
zL2W!w;W??AA7r{?E1)o*axPGNi1*V~uL`z4ixyQ1l$8}Wu^&$#X8-8GHu913zXwJ*
zzidXKX2$~>%|oNoeH0H3qXpF&3aJXW+2aS`538b8BJxU$2n(O+bA~`hC!yu?L%JQm
z8N?%MoZp>`tulyj5@i|M&*==n=XBoT#YPO+2SPw_=zx#h)v#hyN%v9*KM?7Je<EM9
z1yB}a9(A&p<XA9oZ`Cka8`#?01i?ZR^(4x;s>d=M+K+`KVBcI6#~^JgB)DfPS}GAD
zZWAs#X5A4KLr8eB-{GJQoyAArr?TFiMhh&@Lr<tnYCi$Bkeik6o&M+)>TbI2pLg<^
z!&;A{tJ1v_C1N{Nhxok4458Sox@zXbSx97lXpUm4FOB(=A(%N559!m@k$Byse=~Hu
ziV-(gkP|DEKU-OWJ88I1h<RRr0g8gVyfPsWAUfIePPp|GdBAn5U|a=x^$r1IP8kxc
zWA=%~aK>Of^WQtxf!@OFwA<?5^5g9@RXo}kF!n6L+FriofO-p|)&}ITSJU8XFuv@?
ze?r^7A^)8FYPWbPxyKw@I%KV-f{m(&mez7P0PD&wC10RHVtu$WC8MM=q|E-kd7UZ~
z?db7JLwP9k=U6XimgpxZTGO|x#FRtPiV{f>v`k|BvRL2t+FH@I@(qH-&{tEM_4a5B
z%!HLG1MuAqJv>w+Vo!z3)+-x%m5A(Y$DJeyQriubfT?3?5kVjr`h#kSg`}(t{@Qyk
zv}3w100~w}9i@>R0nuaC&Y_Zsin(B*J;?Gsb*{7u4t!fqD_hx5RQvE*O1G!qcg3Gk
zymrQ&1{zS7wHqHYSxUW{;&qW%eby*5&xDPHU<Hx7c!c=;h~?bW+M%oh`iMV1Qs=>)
zZmRnHB5P94&{%Gx!5OkP!XVT=s@PYHIL^{KGdF3#(M3_gVzRu%w+$%l&B%7nYu-Lg
z^|O)9Ytqf3z5h@`SLputUyu0DKY#7+{++V4zwh54z}Y*v>1mEQ)j?P*260%^>3i4L
zow<))kc<uQ+Lmu*Peqj^qF7TQ)C+U7ykh*W$4k7phDS}4=NpaZBP||e89HhWj*Pr^
zETUl~JyPe+Y)7E*lnH^y2)YmM+?*}`pp|qfxs^HKF=)<+T!0M<zjlc_e)TSuNYU3Q
ze#GrwVWR<dSAU(drZ51?ige{HhTqTyL>H2Kq{iw>ZuR$=oT;WG$r0{mfwtZ<3)|<g
z`(oaEdxn`C+_T?)G3C8=3n?jDd1hLwBj0jn4a7fV<QB}xthnr$X(whrO-5dG{>oOG
zQJM3)wXVrZIkDy~65~03E=h*-)yj`?w5=zCdA<th^(j%RC2d~C70jqSy=@RD*_5-!
zjbF}lL<#i7_KB&yaZ>xEy+(FID7JH?2?Uw0V;a`;U#K23F=5$MX_SgOD`}LPkL11J
z4qTJBoAau>CYiq~G~)ls9UXZc?s=S<%fDm7^c^zT8f09AuyNX~YO#QWNs^m_+r%tS
za=pp$!wexCM}}_GRno8t`L1qYfnt*ug<uYmz}`HtvkVDtx8>im=XG~wr<+K*I_C7L
zgshdA*rs+m_3qk;pyg)ADjTyr`urf=>$=42rT|y=VK{DGnqIK>g-Q>%2`dpiqHXLu
zy-`Vz_WI?AmdkN5flE1p9G$g6=PtHZu>oU8hQtYZFke>*72!W*%oOL&jRdaZ8S<W0
zbMIrW4vU9TsCv<t^Xy<QyR{Q9><@a~vN1yA-{!hs%`TpfPkm_@5SNEqc^)O&@h$N#
z96WkF!`=8KNj+HqQ`*E9Ikto6S;L}*j77Du!|IRMrz`=%F?=R%x-$nJu6WDWi9~gp
zK3S5DC!-T#*kkacm97d?PRg;cx;3p_41r^<AK1KQYRraX6W1eOn%AcIf1nU&WeW@}
zzj;2?2u7YOnJW_Ql5jau(=5_*>7b)IopnkSn?SQL^QjnLk32xte}`maq2QGe@rQ2+
zT~vL##e46Jj5h1KtB%gPB4s;-opu=d<_jM~qYcJ&!`1C`4^Vn!AMJtO1Cwq4J}i#Y
z%rtCb_g7=A?wTrRa4^(#)Y!$~qX=()jGP(cQcTNv===4p7!f<Nyw(sAy~O8gGa<;v
z0l0KkM@Qi9JTrdNZOESQ>0iqx7#J23foN^V`8&GmAkhjf7q8<R>Kgx^OL$zonK`rL
zVbF(0xM-jKwaqB3xjSC$Yr`qs_ZFo(2#SfxfbKr`+$KkfODN>XXN({2HEyyjbs6z7
zn74xoXXi0I%+|WCU={w}eFZoE<nH!Nz(0l3ho0!sPiLsvI$x5$`I<uNWsIGPU32Nv
z4ILhxUs$<&kBxkgbH{l39su+3fK5GVVN6}C$M1AWI3XHq<rP7lO1An)B=DX?2fcJA
z6m1CkZ66CI7u3gh>`}ePX3h8OhJ_QRJl5rDgb-yLE!0vFy-X^^uImOpWT5)GrZluU
z=u;UCzP9`|%29|3zavRf4r6i=ez9DA6MHxonjddCFTy$$V7;xoS!_tv8u5~Pq-rxm
z`dlhMfwiBusrQxe*_Lqrn=vZP13izDNW#RUFWwI7qcKmX-zj7GE4H6|p8y+GZ4*qY
zpp?)+Ao!k8Wh|7HgPT~%E>=4pFkgge{3Bq3DnpIA-6YIzPf3~}B@>nIasIfum>Ey(
zA6sciVkCn-D3;!wM<}6^Dt3`Sezl%#rA}nq)VqY!fL6?CF{T)dBTTnrXSYivD(}|u
zpb^!gl2W-cQ<A7^;(^QsG@^|=gv5Y|`}p7YJ%-j736p?8i1@kslfG}4L@NUb)Dyvr
zX8qIRYMf_P2MYG!u4gen_*m)Q8!=UZ)f3Nj>?b!YRpyoL$6Q2|!c<E&966}cqV(|f
zPW$JCA=nmaTgz78KE&^xFYUWUm(4V*aBO>rUrTTlf;GY<KCq~Gajvr{EUwI%*d)B!
zHKb`xxNzb_b}a~*<Z{&-vSpKE5`nr`%~P)14nQJj5gwlAJCEIafbV9W^y@a&qjhO*
zM$Oj>6&G<>B`tn<*4TwvLe@ynJ_ZE4KhWaRzz!aHa1iwdS(Vqx!i<{eT;!3EypS#~
z9$J36EV8Uq+l1hIX9}JEkhIuf4N4T)+)~vD<7U`FpIb0>C~M+L({Q0goBgDPbj|~6
zDGh`ty72RiTfw+f5!5yRp$w13IOz#wX)~m;7}XL36+3e`GBZ|Nej3wWrOFdGCKXE6
zt>R?JRip@QS%6?ftCaSoJV6D9I#X?RrJRDrvYB~cz~L+Gk8ANyy}MsfAQsk_W{{0H
z8cZXCdlO_*F5C<iCUoL7V#w!wUsDOgv?fQ}`<Wq~*X#$L#h&L8S(|iDT7-8D`zvtj
zhm+2v(BYC6?w20xa5i@nOeI^X=6QrGpVl_ncue!L?`rdiclo2=38KWz#`ThPo&I$f
zDmi;O8a9e4-CKoJx~izqwk<4#{W@NuU_<=a2TbUFkrqEg^L5ZVf8i1A>#oD`qkf4O
zF0aUuT`!?nn2y!J;GjWHJRBbYRBOw>+A?yKzW2Hul_&pW1+j{V9DcFV0VIN?lTE8r
zCKs%Q%0}U&uHV045}2#g_e{N~&@z+lHXu@~=$>nnrhhNT`LVoOu8W9nOtLQZqR;4U
z!&ZW)!=zo?vewszTBn5@E3*U{i(?gQHqsmw*w>93a&vu|2MoS4BAG;=)rrZ8ga%s7
zh$cv`76KmhTbvocRhUaJ60jArp$7r3d`wdSda6LyyeY!G@|LArWs;#ClVDA<b}2Bf
zn(4rvN>t&JRY6(~odR{)5C7(yE7KH$%tdfWp4{UHZ3)8jul3}rT<WtKYnKd$a}*ba
z=ZMmL0WCh0J;jrtt7Qr95G+G|9Z@I8aLj7k25S~QNjH#7Ew{c1Y1=tytEx9*de#1=
zr1|<6^9HWAA9NQ2ca(j^<lM;1YA2)^j`fLR0O@f@Y(Epu`%gYEtOeG?yyiYbpV3#D
zJUg;t;j(K(?_s5u<m=U*#HTv1vk~4neAisR1kW(UYWQizNM@Fu7+d+0uFw@Hn-oH<
zrye&Sm(peENX#@<tsEsG2#@WsgcHjthCe|xa`-YNQlS(o*hPf@Rk)r-Al-vfqlH&q
z!`fr-)onEmC0#i+b;R@8j&9SALJ{)toJeF01Gy*1@3tOxG-2Xl|6}HZ4(WBXCY+UN
zMJ0+1AL~;xpP;p=fiN@`zF)BfCngHhhzN~O=yt8o?iYDN8B!hOWuV#@1Dj()Vw_h}
z84fqS+3oIt<nf|@(ii7nr>l9v2FvarWwhvrFn{LEzJ%So9gPSasDs>*qqrH9il~yt
zklvR}mIlB`f@)_she1z+#AT9wzJ76>*h;Be!qC=-`;L#$Yghxjj`4x+210usHZ+C1
ze-33&a}jGfW_}Wxh)Gb|5!JvZojydsMrZg8MSR4xrHdO?Rnn13o=F&Q!7R&U7oA&I
z_btcWlEcx436+H3i1H?06DgcDQPb8t&ZimwL)Vn3h9IBwM)4=Q(g@YZBkL2A%J>m)
z=Uj{^_!BZ=+p=S%Hl<i2k)O15lIBFAIp`PqJ-aLyp^m1$j075sykRXxCeA7%p2Pj9
zBBLEr@9*9|VtBz^td@+DOys{W%bAyBJvG~k?LWy{$X(rJ^#VA$k_mBRA$5WGh?fPb
zbp;TDB!|fX-5!V=(Iu6Z53MgW#nMDSu|__hFx*#?U$PrHD+x1g;pxTI;+<u0QrYoH
zSiWRs^*a2zvqjf>L0qb~h*eK+hHrjkLSr9ptdPG)vCF{JU8N^5Qr|r~b1t=H#)KMX
zoz@t#LLK6&PMhsh!a=Z&kLV{pg8q=6^?Ox4(ybZOxAM9Q{a%rirI9f5?ici>cK^(|
zWB@9fyGruKWC{a4uEQZaz<{(oCV0r6)ZzT8fgIfo&MWkdn<_lm4azEOV7{WEW%Q;S
zAz<QFwOBCI00j3z(LT1ecWH_R3ezEz|8iM6OSK3?>vw1U$9#2B8xDu)#8e6D#0C)E
z&mW9aIlig7QfSGdj%_gs=5Q#ay)NlQ6JY#GLl}|L>;Ig$%A`f~m0jCO)9U$bf<8nv
zG%3M&w3jzh(3g_hFk*-JvGCJp+1ic<R0h!<8Be~ZSm-=hiN!Djfj05kiB!vpjD)&&
zWA5X@NriqmbfEr^Vc9yo34?#u2-+7Q&oHwbo2#CH94$;5%t6YPW#9b%u;&4c;2pYH
z2t!k4X1=_dx^)|BfI0v0X7Z=TS~Y{N4AUcfDRsLxsdV7K18OU3$@BGB2wg0~i$hy{
z!87B6Ik9i-%@L)v)AfSUy{K-f5cNpfmgU4`Xwk18dQG75(gZbg+z)nKMTsiU&5I?*
zUAr_8bVAbYY5&7S#aUI8ZZ&{}`D3}{_ac$;^FXe;*0<yD%))u_-{ZMA%V+)CUq-iM
z>3)c?ibp7!A3P!dDe`=0f%qwEI)PPd^0SA@Tdou4q5F+)lN^X;Ly7&<p<PNxPB9hT
zW0K?1rltd&)(S)kdW%;bLHj8u#`teIO4%MAsr2i<Fe4fOe6pE(6{%VgwO^c>302ih
z8iBMED(p4DTNeHNHEam4WkY}P(eaWs*;CvIZ4Q(bW#9({TtUYZ`wmh%ss(Ofz0h6I
z6P~ZvcltRS=L|*YesFRFv{59iJMwtpsjG*DQ6H5TI_spU1sf@eW?n??9L3x;>pO?!
zcU3r5(lMRWs#PB`32ovVUN92<($qoSrSAE`vh#Y@vr5nH3&rLVT#Q>1zkn(HCtq<&
z(}{Dr{n%69`B!c%q|&pI7&|N!@P_DRmi&+n%d}9BWpe|qMse3^oT||v(j8O_W6s&R
z)7m}0hfg*3@3!atthT#H{0{_7?-z0L@kChBfXDaYC+G(_e~DMU^mLLcFYJCEJ!jm^
z-Qz+gAy-#Fe_AV*@033qjV+8y;fu{k`1el+<jwsn;Yyvqe?G%7?q8t}!~g!FP<wg*
zisCKQ|L<PLZU65(zbr9n+g}YAXa=;6k}!4nZ?-_n)B~dw7aE~MZ5-0Smv(!^>;)>>
zi>q-um!_m*xe#0`v~X-;aCN=NJqNgyi;2B*W^E58zEk>QXFxI`cL~_OcOp<4@&DML
z@qELVJVf$8--uez{P!{XJloKO2peGUBB=QG2L<ljPp6Fl1nD&R?z?q&o=G#!{p2v7
zgYUg)Iv$boOv<P@0d-t20ARV^`L*2-;M^CWl~BVEup!Y>Y{F!fOSKqLK!s2$!d_I0
zP|Eph185*z0EXB(Aj}k`bz66HfAsqLA4k3Fu07}?2HltQAEa)D6-p^XTUN|QRs%eL
z7+m4^?f-kkNyt4RCo5V;7bAlIY|hRb0(%8GJH&&wKN)Mb@(WnkAB$!~ez-*>0X)V1
z0O-|_(W<C8tq1wfVm2bhNNw&V2M_Q`4TUI%7D=U#C@6f5+l+-`>j1Y$+oluW*1BcX
zy}cjQJ7+Cwsz`h$;m!aKkpV#=r3!^HtUqR~T~9E(-EYTQRfMWRNae39c&-O{_b}*)
zWLi5{?v15#$%=9bpi206Do4jQvMjua@7l2h`tC&tWyKSyzFTf+M7%9&*sTX}E)9oq
zB_8?$>w7g!*zH(c*2q1%1;~(ql5ZzK1r?x`7q;CGLw+eEnCTMCEl?D&^UvrcGD>0r
zZBm~~6s~Rnf!eEG4Fi3uI%KC6gD;wnfUdzEGy4twX>s$VsZ=PR^>a`&<;|2fX}kYI
zkJV7F;`BI8M^&{5#8s>M-#JoDb!&j1;s#`lZV!JlCk5%xnpgB=a?O<jmQhK?0FPuM
zxNFoc%3O^=TCy0hfdFS{5HMSQa64Y6K~RXO9;C%TQQ*s}s?@<{3;`GwnL*INFvg+c
zOFrVQF}}x+fH~qj5dEn<7#R>C6^waMx&()&xNha0{C1whNc08d$u2dsqN*`@DT}Ic
z<%Cx@V{&3Upf?BC5B919w)S)H5g`1Cr&rxx{^6A?y}9!ZkoKN{6D6ya4heB}`9Ax{
zGXJ2~0)!Nq^Ae&zHTOygV!ZsW`(e*>YQ5XlFy651E&Blrl>`i&J^(r5F&UvU`KrJf
zyABLo9qk-2sA?cPz{)toXr#IT5*B=e$fUO04hIl}FCLM6C!U?^ei&$Aa0;|Nza8CA
zBxug@Bx|p<0KuO>x7m(lLXs65eIkJfI6HCbmNuH1zuQOMyZrf2r`|YnrM09Wzc&%`
zf8KsS8qk0l2E}!r#QGw$G6Gfo$8=ty91}WUoE>=FD*8D`y#lG@(okD2)`@SCoif_7
zX>+v$vaQst5rl+qa81>u$ygY1Ud_Jx$<$7xmY`yr(ZCM?`4EYXYe&)GM=L>Misxz>
z<QA=9u2ndM)UBF0TxzCtgCk`DUrp9TsOSfY9Y$g)@5*ON7%((HnA&HYUyJ(D(o@X>
zB+g6T1G){kU#1*qEv8Y(-1mzccDLT<-UZzT1k7?m+s}rDxI|GY`n1(vs>!Ac_r^Sy
zIujp>#Y3wC=c$soh#lrlPHul9YlaCG#@^X3)|Y?7p(aZt5ohoT&$yD@$Jm%PJLgGK
zuQ^Zjr)-LlX^mm(-s<Li%+cjw(RPLc^ogu@#P$(c(-X$pS<40!*Znq>X-mCjKZ3ZW
zSUXAR0B9>{BOBaX{JmnS`tApt108(mMNjhbk%z%0qDdR#!$2F!p#p*hue+PdlYO<)
z9CfPwPd||Mk`@PymnXMm`Vx34XvOeJLt$Aoo&KmMm1*gyyt8N_g}E;bcX${XyFJ0#
z5=t;D8REP5f3+Pcs-KJte;b=W<>k|uNqlBuLM!7>EAZ4_&lmf<?+APt-g5k%X9n$g
z68Yk%@<_===T%Hks7mz?8@c9zIuI&$d}N00@MT^0Qn5!*(bcfKV~ZsO=y-k8Pt_fv
zFKPV#iQy+*r)jpZGkUPA@&QKitE{Rd@DLSiXkGTn)4bR0#w4s5YC+!1swC$~QvoH6
zU{c4akJ%88X=+0oS&Q({-UC-<cu6>URR!Z?dHfE<2I=u6|JG^C9f`%tB?P$dsNE=L
zGeS(c`DmY>NU+)X^`Xw!i=B`-bb-kcv7Vv1&=-8~JWPbD=b`4$<6!pDAx)<<1%Vgn
zK0&x270%u{9r8{ht9D^4wp|gC&a0KKJUnUu!SF3q6xypKf7NuhASHv(3X9DN)JC?5
z(l9udG1}-x7bq_;9P}5Kd(Y_HOP8x6Z78T&Gz?elj@V{Ou0g3GacP4PRB}Ar#%cf^
z_@DkKLh22!rfnl!=269!Y0}=0%v6-9MTDeZJD3PfHx)sq>5D3(iu7JE1qI9I<zH?0
zo#|jGLLZTfZ?{k({we#GbTS6#Jc_r}#!3*QsOQ<JVN**A3zEp@{X(kbTv?SSybic}
z&k-b{FQ_JYsrxr<Yk@W=hg!t&1l&=A)%+zsp|o?Y<z0KGUZ_eExmgE=Z(s=spI)S}
zJhk1JohRXQza8Yb_i_>~%T2<2BPoD@?h~SUUDezQ{<L3wl-)O?<oV{S(OXn}%q}XF
zquxu=>qP$L&b<-op$eouv#7`)T9y?J>7}Pb-cu7UE}itEzDW&cZk~Eltb9h(#3I-r
zo^7dwBIB1@uQV+)9yFX&nRdoE#oqg(pl~GuX1`f&c9&{l0j7%iD$VCnzF90xUjZi@
zGF^>U4uFd)(jfM7&&z%xrt}zvBcbAiSEeLB27Vo9CUSnLPmfp4*rUY$Gj;e(Hs%6%
zOY*R=v@3VsuF(8X)l76Op7Kg^Vl63K)SBg?E`;hyA@}hEQ#o85X-(_|NvN{%v>|!i
zE02=>ut==&yZudPr>shyg{Sf7|M=X|Qt@$H`B_R$iEEsfKCF7`LJF<X!+G8^MpyRg
zhdty(evCy?_Px*11(??QF=VDSk#%WNC0cu>SR)j+M!G8d7nim^pQux*5%r&!H#j{Y
zTp&$jcF1`(?ws^f;*B$+AEI!Fm>tvjx5S6qo+XdYQA0ShAxe!?rK?4i<cV65C%+s>
zrw&V!6eevqUr(QUmetJJN^!a@pL`4`B@WqLCgJ^ON>=1?=?qO9o#}-ei-#*YkEX(4
zWovj}C0Q*kk7kJ&4TnCRTJo@`wGt~ipTFuy{`5V=8axvZs%Zkq4`l>y>}6tL3=NfO
zv<9O&jxjvGlY=`R+g{H0cRBAW3|_X-u`S}<M}HkF$spClKg-)0u<fjm5|in=fz;fh
z#J}FK2jFEj{=wUbGN{hM^g^Tjqg-!iX&k$=^+HdmO5UaC`IC=c{IO}0NTC9ZQ+MQf
z`}<#Z=<=FE*Mt>oTQZXu*FA@F_e&c-<>NMOr+nUb#hTGP;paP4AN`xbw2`3%EUH`x
zobG<l3vIGkJ=Z>~S8u{}=$y|>3plNn4ZF&FhOe>OR)yz;wwusA$zJlZ?@f9*19$SC
z(eB6Hn_mOvJ%;{&rulzo&id6`<O;CW`)}N=o*^q2DBbadG&iN2G1jN&NLem8bZfIi
z2UeX12<`+n0Y^d{MnXa|#;BvYFzPi3L}4}>i@$8nd^|O)H~H4@5&=0dx^doQDlPWk
z^0MS;&Jj)AJ1qJLC<Wz9bG(RFv5<?1{eyj$d)5dP&VX8;b^!3>J#e;)iZNbUuXnJu
zH{X9C0rb7TkcXI^q2Z;IW{k{=x{=UpDtA6`_Rs0*=?e=Bi&xsNw<CY3wiKHk{=LhP
z6UIqy27Ze=kB8OCo(C=TkYafi5u6$T*8fMI&40eBgYg&9-VK!A0azU%{{dkK{QG}+
z^FR0hFXSD4A$ueQgl#0%eP$>)#Q$QO|LxWMFD_%h@o)@lHd+cU-Ew_`2+LMT!(ARm
zW5KvT$y}AeL;R;QW?0?Z7_VD1?9uI?+4E=-0ZL3cxxL7XqH%!=%FWi`k-(wf&IVNX
z%m)3o5CX)Qa6Hu^<NJ+NUpCDziUmD`KEeEZTXL$kjv_O<;i5=?Z%q&52lp)6^0eXm
zla((O<@|gt|L<M*4Ogkj=z<uG0e=Rd?wy;KGs5viVC*D+Ev1n6PC0goFHzA>rk_{C
z)f?sTNzcCyD^ay^sv7z0Ig;I@=P-@H?lWi~FNuQ1$V#d_+5npzey(nj=axr)2Kx20
zL+L<{lB-^YVI>+pPv(DLb(@2u0KS~#;m6S$dg7l8&t({;^`}{5qK}8jH1h`1+%UC0
zwi?qHa!rk!Ka?C8_8XiCjC<TF%o}xGYyE3DI*muiDfmWbKP@gKjtUZgPLw_S;XJ)^
z*|-tA@u&VB|C8%&>!H#1Nc`syZ13p1bVscBk0>We?{d9%z5HOLp-xE?A)fxQr{h6h
z174=D^SAU1$B(_ag{~O>^kUJ!&WYdLQt-YADCWO>e>1k=NaC}Oboj{c3+d!*q*Rg_
z3oWsXAX?tyk59uB?%e7pI0}(Q5j$qyEjT<4<gEJUal5!*(y#h{)=SzxWgHr>8K0t>
zGG^CQBHW_Myu8(ZH*|ZV!MN*;@?A3QH^t5I>ns<GEep98qew_7@?Yk~Dv77tg!G@-
z&?3x!BTiq}59PB_Mw2weG(}rx0Suv(1I#<|K5YDZlOkdSNo6OogN5%x88Pr%y3rV4
z<-~tuRag!d%RKTK{b||nr5J19z}e`Pqi~g^mO{H-N2bRet4ccm+fq{{@lX6#ty#Zp
z<%}oBUY)R8uGVYg>zr)^&wvJ#nhXEOVmA@e9}bZX8v+ckJgq%49H?75zSH+pas-<l
z*%h!=`NVzQ*oaZBx|MT?3N!Mw5WTuCTUXdo<}JgD`Qt>*J;)tE&s9A!$u+56ON{@p
z9X<RHejULNWv)1m{f`E^_9s10_XLIZtXyepeu)(o1Zl4y%d}jVvZ&pphyZTgCkA7C
zSV-B$j%w;8jhVCi$8)ULJe&fR&2`mvRb`E3UsZ93e_1Xbnse0eB(pKP#?|Fg&FH#b
zAF7{dR#?RPy#K(Z%$~Z7UPM-7Dwn?FxiOy@izumy?if~9p7+Z})BgH<Wcf|aTwdtJ
z{^4bm=V@Qn9;ZMZds$r-cMaz}_iTm;rV;l@#!s0+ruQZl9`(&`#nQo)c0Q56a?ZDo
zW<D<38)<EX`#|~CQ~LW7tatQva@5%ZPoa>Tvk6XR2ct&QbJdW}!8y&slfYk*^=L<z
z6A3?7T}ocq{@}H)p%!5VYQN=Mii+7LE*^3RToaD20()%t)Er>usxN0uXDU1`evXuy
zrMX_|>W}wyZz-6@_#SUoENHKq8|}T)8|Mli^XKEiKb>N)T2t1Qda2!QDS4H>Y}vi4
zK-c+kx6`ISi}%gzqK5RG#<M&}`LPR?oA<@c#~oNNqQ?G6&Yo&J<<dw79~D%nGWJ+~
zP1Shv;Z95Q>*dwc>8(Hhg)Qtxd1aWfE>7d?#gm4Pnxc+o2?@8qcg_FoBtqI!r=w$K
zIfm|dpfpnh1!oJC%F#N_-}ZCqgISaXEEfLM77+aq{1xUTn79*-IrEM!z(Ze3QQ>t&
zZs!f&zsK0?Zadg(DLKC1@!i<@f@M$A_+a?!H54uT%UJjT*6%3wq?3@#y@c08Ymb~v
zDS;#9?NaCDPpnU>uB}e%WOv)ot(qK<IpZ6~{o`N6o5E4eUU@@k$xB%|#l9tf=YP@D
zc~BP{|2b%N%PRh+s+hMso8QIM)A+pOYOb+5wJLu0;Em#Vo?(p?+WW-%uNzxjKfY)T
z3EsW?qP)UrG)@ndVSb-~@r_9<SelaQBp*+zl+)qP=?8Dx<w>WJD{bztfQ=ojvCZZ>
z*qOq8*Z|JgsI7Yo7d*UI_#o1{kFedD)!n&pYzUMW#m|gkYV+q)WzCi^^b8VP8aI9H
zeyr^%lr7~Gd6AphpL6@0Nu-#Wc;pRwxPwfkDa|<Pv4llb!pJ~lX?f;25@gHk+XZ|2
zimrXz^pIH2W(M1AIK}AWbi_%WSSPz07XzW9=lFod>A4xbmAIAImE@u+@Qu#g3-A0`
zwl(_B_E^dEXyf!f4n6a4eCjXA0<H(rXZ8)SpRR{hxKE2NUmX#h^ukA_qA5DXqMqKW
zjop^~x)qacTOMT0n=yal1pJla!9;~wV!`~bqoxf>!ro}_>z|wVQ5QrILM<0_0i}u5
zf{T;>s@?&3g6C13k)44a-LR_=)^B18N#TVum81B&aTET_(4F?Zozz0h!Vo5mw~C}>
zDSM-KR{U7EGY8G5lw1YZ0>x6YqntAl8aNq=-CHPzuCMcIl@1Q;E;ANTX0gcINsC1`
z1pf}%3TFPa;A;A$^Zfer<swgc)Xwd~pGd4fEp8*%1@MGslw=+5jiv?FSt|+Vpv&pl
z>|2vF=9xe)XqVze-Xx}OQ&4!X)wjJQ%klc`hPTWX_Lkx|PDM_RjYtdmM0uy(^zS_<
z-_Oh$5hVk3^gW-h{YBVr?z0!~@lN>1q_y^NPdaC<64;usLYXnmZtiGe_ve1<EwG#&
zZYC$tGTx4zmYprqkf@Rv#}~>SY5sgVpE3UFG6yZd@UX#CV^L!~hyC4@ZvIU*nP3jR
z@E?a&!@YIOqh7d_8C2Rb_biw)Y}l4suE=ZtdST=e?xeEFa8Y<$@ANzr*KsccgZa2K
zanRJpx>+m{MA(!1(>$%pRCUg~<~o^^j7Ie#w>_+8r2K7v#eQ1Mg-Xrw_5X6W)I6Q<
zvia<1@gtWpLchH_^)D+8qRcyO#cS|Vxrn?|4=Ln}G;gTZlSi@{H?oHeH00TT{f!>Z
zl{$N+;~4(|Hg+a8Mx{1DKV?DosN_}LGU~AR@BQkM=c-Jevbf3Sv!0c_UQ*wywQc5I
ze^=AX2RA&8y&Lty>gP_cIrD1}O1xsutRVlJnCMvlPIt;{RNdDJU!I-8@;AIXKJ^@p
zxln%3&I8iA`+O5Q_Ik2GaUe42lI2euX?uHE$?S9D<0Fey5FYNMgg6X?;S!6CuJ>QY
zxT$@<_gX$?_^+EGSKU`@Yq=1Y6E*t#gzC4^58jT81+o6?@LH~yga37F-CKeGx;510
zZj(~v-xe_V>$<&8V{1w3`S+o}wvX*(LF9RMd%C^alKZIfZxRQ%xb5ZSd?kD*?Wb!|
zI+~Fgk4pc^@6O+?w9FRifejEo3EfUaPpRS|E`b!b7EA^c_>v+p;{WL-E&>9<Lxfgf
kf!1IE8X!FUe|q^KRQI^NI2zXvTn&PRh|Jq!VIBB?1BYwm-~a#s


From 3dd708f5664f708f7690625fd58fcd1851cfbd1d Mon Sep 17 00:00:00 2001
From: YAMAMOTO Yuji <igrep@n.email.ne.jp>
Date: Sat, 10 Jun 2023 10:35:12 +0900
Subject: [PATCH 442/749] =?UTF-8?q?Fix=20typo=20"=E6=9C=89=E5=8A=B9?=
 =?UTF-8?q?=E7=9A=84"=20->=20"=E5=8F=8B=E5=A5=BD=E7=9A=84"=20in=20Japanese?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 _articles/ja/code-of-conduct.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/ja/code-of-conduct.md b/_articles/ja/code-of-conduct.md
index b97a1f92d74..25b7e93c18e 100644
--- a/_articles/ja/code-of-conduct.md
+++ b/_articles/ja/code-of-conduct.md
@@ -111,4 +111,4 @@ _厳密には_ 行動規範を違反していない行動に対して報告が
 
 ## あなたが世界中で見たいと望む行動を推奨しましょう 🌎
 
-プロジェクトが有効的でなく歓迎的でもない場合、皆が我慢している人物がたった一人しかいなかったとしても、コントリビューターの多くを失うリスクを抱えているのです。そのうちの何人かは一度も会ったことがないかもしれません。行動規範を採用して遵守させるのは必ずしも簡単なことではありません。しかし、歓迎的な環境を育てていくことはコミュニティを成長させる役に立つでしょう。
+プロジェクトが友好的でなく歓迎的でもない場合、皆が我慢している人物がたった一人しかいなかったとしても、コントリビューターの多くを失うリスクを抱えているのです。そのうちの何人かは一度も会ったことがないかもしれません。行動規範を採用して遵守させるのは必ずしも簡単なことではありません。しかし、歓迎的な環境を育てていくことはコミュニティを成長させる役に立つでしょう。

From 8d9f775e004e3668a4bd77ac55ff343737f6db7e Mon Sep 17 00:00:00 2001
From: penrose15 <seongju99@naver.com>
Date: Tue, 13 Jun 2023 22:40:20 +0900
Subject: [PATCH 443/749] [fix] fix korean translation

---
 _articles/ko/how-to-contribute.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md
index 44a441e8e9b..58ab9493e0c 100644
--- a/_articles/ko/how-to-contribute.md
+++ b/_articles/ko/how-to-contribute.md
@@ -185,7 +185,9 @@ related:
 
 오픈소스 프로젝트가 어떻게 작동하는지 알았으니, 이제 기여할 프로젝트를 찾아야 합니다!
 
-이전에 오픈소스에 기여한 적이 없다면, 케네디 미국 전 대통령으로부터 조언을 구하세요. _"Ask not what your country can do for you - ask what you can do for your country."_
+이전에 오픈 소스에 기여한 적이 없다면, 미국 존 케네디 대통령의 명언을 떠올려보세요. 
+_"Ask not what your country can do for you - ask what you can do for your country."_
+_"국가가 나를 위해 무엇을 해줄 것을 바라기에 앞서, 내가 국가를 위해 무엇을 할 것인가를 생각해야 한다."_
 
 오픈소스에 기여하는 것은 프로젝트 전반에 걸쳐 모든 수준에서 발생합니다. 여러분의 첫 번째 기여가 정확히 무엇이고 어떻게 보일지 생각할 필요가 없습니다.
 

From 35c62f865699bd2feede66c17a365e0659b4f51f Mon Sep 17 00:00:00 2001
From: webfansplz <308241863@qq.com>
Date: Sun, 18 Jun 2023 14:30:03 +0800
Subject: [PATCH 444/749] chore: fix typo

---
 _articles/zh-hans/starting-a-project.md | 2 +-
 _articles/zh-hant/starting-a-project.md | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md
index 6ce2f91161e..c0e03af3875 100644
--- a/_articles/zh-hans/starting-a-project.md
+++ b/_articles/zh-hans/starting-a-project.md
@@ -243,7 +243,7 @@ redirect_from: /zh-cn/starting-a-project/
 
 ### 你的写作（和代码）如何影响你的品牌
 
-在项目的整个生命周期中，你需要做很多文字工作：READMEs，教程，社区文档，回复issues，甚至肯能要处理很多来信和邮件。
+在项目的整个生命周期中，你需要做很多文字工作：READMEs，教程，社区文档，回复issues，甚至可能要处理很多来信和邮件。
 
 是否是官方文档或者一封普通的邮件，你的书写风格都是你项目品牌的一部分。考虑你可能会拥有粉丝，以及这是你想传达的声音。
 
diff --git a/_articles/zh-hant/starting-a-project.md b/_articles/zh-hant/starting-a-project.md
index ca4a49e897b..537bcf8ffa2 100644
--- a/_articles/zh-hant/starting-a-project.md
+++ b/_articles/zh-hant/starting-a-project.md
@@ -243,7 +243,7 @@ redirect_from: /zh-tw/starting-a-project/
 
 ### 你的寫作（和代碼）如何影響你的品牌
 
-在專案的整個生命週期中，你需要做很多文字工作：READMEs，教程，社群文檔，回覆issues，甚至肯能要處理很多來信和郵件。
+在專案的整個生命週期中，你需要做很多文字工作：READMEs，教程，社群文檔，回覆issues，甚至可能要處理很多來信和郵件。
 
 是否是官方文檔或者一封普通的郵件，你的書寫風格都是你專案品牌的一部分。考慮你可能會擁有粉絲，以及這是你想傳達的聲音。
 

From 4194f82325844bffdfad4c935f7ae307c233849e Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Mon, 19 Jun 2023 11:21:19 -0700
Subject: [PATCH 445/749] =?UTF-8?q?Add=20Fathom=20Analytics=20=F0=9F=93=8A?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

#NO_C🍪🍪KIES
---
 _layouts/default.html | 1 +
 1 file changed, 1 insertion(+)

diff --git a/_layouts/default.html b/_layouts/default.html
index 7cf57d4efa6..89e492849c5 100644
--- a/_layouts/default.html
+++ b/_layouts/default.html
@@ -9,6 +9,7 @@
     </div>
   </main>
 
+  <script src="https://cdn.usefathom.com/script.js" data-site="BFHXUQHJ" defer></script>
   <script src='{{ "/assets/js/index.js" | relative_url }}'></script>
   <script type="text/javascript" src="https://s3.amazonaws.com/downloads.mailchimp.com/js/mc-validate.js"></script>
   <script

From a0fac591a799842594fdfa123f1877b1fbabbbf8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E6=9D=9C=E5=BA=9C?= <dufu1991@163.com>
Date: Wed, 21 Jun 2023 14:28:12 +0800
Subject: [PATCH 446/749] Optimize the article according to the normal
 expression in Chinese.

---
 _articles/zh-hans/finding-users.md | 84 +++++++++++++++---------------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/_articles/zh-hans/finding-users.md b/_articles/zh-hans/finding-users.md
index 37d969e64cb..5a842f9df4b 100644
--- a/_articles/zh-hans/finding-users.md
+++ b/_articles/zh-hans/finding-users.md
@@ -6,119 +6,119 @@ class: finding
 order: 3
 image: /assets/images/cards/finding.png
 related:
-  - beginners
-  - building
+    - beginners
+    - building
 redirect_from: /zh-cn/finding-users/
 ---
 
 ## 四处传播
 
-并没有什么规范说当你创建一个开源项目时，要怎么去推广它。但没有任何理由说必须默默无闻的在开源项目上工作。相反，如果你想要有更多的人发现和使用你的开源项目，你就应该让所有人知道你所努力的成果！
+当你创建了一个开源项目时，并没有规定你要如何宣传它。也不是说你要默默地维护你的项目。相反，如果你希望更多人发现并使用你的开源项目，你应该大胆地让所有人知道你的努力！
 
 ## 发出你的声音
 
-在开始推广你的项目之前，你应该能够解释你的项目是做什么的，为什么大家需要它?
+你在开始宣传你的项目之前，应该解释你的项目是做什么的，以及大家为什么需要它?
 
-是什么让你的项目变得不同或者有趣，在自己心中问这些问题会让你更容易说服别人。
+你的项目有什么与众不同或者有趣的地方，如果你自己心中明白这些问题会让你更容易地说服别人。
 
-牢记一件事情，别人之所以使用你的项目，甚至是为你的项目做贡献，是因为你的项目解决了他们的问题。所以你要找出他们需要什么，然后把它当成你项目的卖点或者说价值所在。
+请牢记一点，别人之所以会使用你的项目，甚至为你的项目做贡献，是因为你的项目解决了他们的问题。所以你需要找出他们的痛点，然后把它当成你项目的卖点或者说价值所在。
 
-举个例子，[@robb](https://github.com/robb)用代码实例来清晰的阐述为什么他的项目[Cartography](https://github.com/robb/Cartography)是有用的。
+举个例子，[@robb](https://github.com/robb)用代码实例来清晰的阐述为什么他的项目 [Cartography](https://github.com/robb/Cartography) 是有用的。
 
 ![cartography readme](/assets/images/finding-users/cartography.jpg)
 
-如果你想深入了解如何挖掘项目的"卖点"，看一下Mozilla的["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/)，练习如何建立用户的形象。
+如果你想深入了解如何挖掘项目的"卖点"，看一下 Mozilla 的 ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/)，学习如何建立用户形象。
 
-## 帮助用户找到并且追随你的项目
+## 帮助用户发现并关注你的项目
 
 <aside markdown="1" class="pquote">
-  你最好有一个唯一的"主页"链接用来推广，引导人们关注你的项目。你不需要找一个炫酷的模板或者域名，但是你的项目确实需要一个入口。
+  你最好有一个唯一的官方"主页"链接用来宣传，引导人们关注你的项目。你不需要找炫酷的模板或者域名，但是你的项目确实需要一个入口。
   <p markdown="1" class="pquote-credit">
 — Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
   </p>
 </aside>
 
-通过引导他们到一个唯一的地址来帮助人们发现和记住你的项目。
+通过引导他们到一个唯一的官方地址来帮助人们发现和记住你的项目。
 
-**要有一个推广的主阵地。**一个Twitter账号，GitHub链接，或者IRC频道是引导人们查看你的项目的一个简单方式。这些方式也给你日益增长的社区一个讨论的好地方。
+**要有一个宣传的主阵地**。一个 Twitter 账号、GitHub 链接或者 IRC 频道是引导人们查看你项目的简单方式。这些方式也将会给你后续成长起来的社区有一个讨论的地方。
 
-如果你目前还不想给你的项目搞这么多乱七八糟的东西，只要在有机会的时候推广你的Twitter账户和GitHub账户即可。举个例子，如果你在某一个讨论会或者活动上发言要保证在你的简历或者幻灯片上包含这些信息。只有这样人们才会知道怎么找到你或者关注你的工作。
+如果你目前还不想给你的项目搞这么多乱七八糟的东西，只想在合适的时候再宣传你的 Twitter 账户和 GitHub 账户即可。举个例子，当你在某次讨论或者活动上发言时，你可以在简介或者幻灯片上写上这些信息。这样人们就会了解你或者关注你的项目。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
-  我之前犯过的一个错误就是没有给项目开一个Twitter账户。Twitter是一个让人们知晓项目进展的好渠道，也可以让人们持续的接触到你的项目。
+  我之前的一个失误就是没给项目开一个 Twitter 账户。Twitter 是一个让人们了解项目进展的好渠道，也可以让人们持续地接触你的项目。
   <p markdown="1" class="pquote-credit">
 — @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
   </p>
 </aside>
 
-**考虑给你的项目做一个网站**一个网站可以让你的项目更加友好，而且更加容易浏览，更重要的是附上清晰的文档和教程。这也是象征着你的项目还是活跃的，这会让你的用户在使用项目时感觉更放心。可以用一些例子告诉人们如何使用你的项目。
+**考虑给你的项目做个网站**一个网站可以让你的项目更加友好，也更加容易浏览，更重要的是附上清晰的文档和教程。这也证明你的项目是活跃的，会让你的用户更放心地使用项目。可以用一些例子告诉人们如何使用你的项目。
 
-[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django的作者说，我们给Django做的网站可以说是"在早期开发Django的时候做的最好的一件事情了"。
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django 的作者说，我们给 Django 做的网站可以说是"在早期开发 Django 的时候做的最好的一件事情了"。
 
-如果你的项目是托管在GitHub上的，你可以用[GitHub Pages](https://pages.github.com/)简单地创建一个网站。[Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) 是一些优秀的内容详尽的网站[例子](https://github.com/showcases/github-pages-examples)
+如果你的项目是托管在 GitHub 上的，你可以用 [GitHub Pages](https://pages.github.com/) 简单创建一个网站。[Yeoman](http://yeoman.io/)、[Vagrant](https://www.vagrantup.com/) 和 [Middleman](https://middlemanapp.com/) 是一些内容详细的优质网站[示例](https://github.com/showcases/github-pages-examples)。
 
 ![vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
 
-现在你的项目有了"卖点"，和让人们很容易发现你项目的渠道，接下来我们谈谈如何和你的用户交流吧！
+现在你的项目有了"卖点"和容易被人们发现的渠道，接下来我们谈谈如何与你的用户交流吧！
 
-## 在线上寻找你的项目用户
+## 在网上寻找你项目的用户
 
-网上拓展是分享和快速宣传项目的一个好方法。借助一些网上的渠道，你有可能找到一大批受众。
+网络社区与论坛是分享和快速宣传项目的一个好地方。借助这些渠道，你有可能找到一大批受众。
 
-利用好已有的线上社区和平台去找你的受众。如果你的开源项目是一个软件项目，你可能会在[Stack Overflow](https://stackoverflow.com/), [reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), 或者[Quora](https://www.quora.com/)，找到你认为最有可能从你的项目中受益或者对你项目感兴趣的渠道。
+利用好已有的线上社区和平台去找你的受众。如果你的开源项目是一个软件项目，你可以在 [Stack Overflow](https://stackoverflow.com/)、[reddit](https://www.reddit.com)、[Hacker News](https://news.ycombinator.com/) 或 [Quora](https://www.quora.com/) 找到可能从你的项目中受益或者感兴趣的话题。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
-  每个程序都会有那么一些方法只有一部分人才会用到，所以不要想着去打扰每一个人，把你的力气用在可能会从你项目受益的社区就好。
+  每个程序都会有一些方法是只有一部分人才用得到的，所以不打扰到所有人，把你的关注点放在可能会从你项目受益的话题就好。
   <p markdown="1" class="pquote-credit">
 — @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
   </p>
 </aside>
 
-来看看下面的一些方法吧，也许推广你的项目的时候用得着。
+看看下面的这些方法，获取在宣传你的项目时用得着。
 
-* **快找找有没有相关的开源项目和社区。**有时候，你不需要直接推广你的项目。如果你的项目对使用Python的数据科学家来说是无可挑剔的，那么就去找Python数据科学的社区。等他们知道你的项目之后，很自然的就会谈论然后分享你的工作成果。
-* **如果你的项目尝试解决某些问题，那么找到会遇到这些问题的人。**想一下你的项目受众会在哪些论坛，然后搜索这些论坛，回答他们的问题，然后找一个合适的时机，向他们建议使用你的项目来作为一种解决方案。
-* **寻求反馈。**向一个可能会用到你项目的人介绍你自己和你做的工作。对哪些人会从你的项目受益要很明确。尝试完善一下下面这句话："我觉得我的项目能够帮助到A，那些尝试做B事情的人"。听取和回复别人的反馈，而不是简单的推广。
+* **快速找一下有没有相关的开源项目和社区**。有时候，你不要直接宣传你的项目。如果你的项目对使用 Python 的数据科学家来说是无可挑剔的，那么就去 Python 数据科学的社区宣传。等他们知道你的项目之后，很自然的就会谈论然后分享你的成果。
+* **如果你的项目能够解决特定问题，找到会遇到这些问题的人**。想想你的项目受众会在哪些论坛，然后搜索这些论坛，回答他们提出的问题，然后找一个合适的时机，向他们建议使用你的项目来作为一种解决方案。
+* **寻求反馈**。向可能会用到你项目的人介绍你自己和你的项目。请确保这些人是从你项目中受益的人。试着完善下面这句话："我觉得我的项目能够帮助到 A，或者那些尝试做 B 事情的人"。不要只是简单地宣传，更需要学会倾听和回复别人的反馈。
 
-一般来说，在你索取什么回报之前先把精力放在帮助别人上。因为在网上推广一个项目对任何人都是一个不难的事情，肯定会有一些不同的声音。告诉人们你是谁，而不是你想要什么，这样才能从众多推广者中脱颖而出。
+通常，你应该先想着帮助别人而不是获取回报。因为在网上宣传一个项目对任何人来说都很简单，所以肯定会有很多人在做同样的事情。告诉人们你是谁，而不是你想要什么，这样才能从众多宣传者中脱颖而出。
 
-如果没有人对你的推广感兴趣，不要灰心！大部分的项目的开展都是一个要花费数月和数年的反复过程。如果你第一次没收到反应，尝试换一种策略，或者找办法给别人的项目做做贡献。这都是些需要时间和奉献精神的事情。
+如果没有人对你的宣传感兴趣，不要灰心！大部分项目的发展都可能需要花费数月甚至数年。如果你开始的宣传没收到任何反馈，尝试换一种策略，或者想办法给别人的项目做贡献。这些都是需要时间和奉献精神的。
 
 ## 在线下寻找你的项目用户
 
 ![public speaking](/assets/images/finding-users/public_speaking.jpg)
 
-线下活动是向观众推广新项目的常见方式之一。这是一个接触某个忠实听众和建立深层次联系的好方式，特别是如果你对到场的开发者感兴趣的话。
+线下活动是向观众宣传新项目的常见方式之一。这是一个接触忠实倾听者，建立深层次联系的好方法，如果你对到场的开发者感兴趣的话那就更好了。
 
-如果你还是个[公众演讲的新手](https://speaking.io/)，从寻找一个和你项目使用的语言或者生态系统相关的当地的聚会开始吧。
+如果你还是个[公开演讲的新手](https://speaking.io/)，找一个你项目使用的语言或者生态系统相关的线下聚会去尝试吧。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
-  我去PyCon的时候非常紧张。我要发表一个演讲，在那儿我就认识几个人，还在那儿呆了整整一周。但是其实我不应该焦虑的。PyCon真是太棒了！每个人都是超级友好外向，以至于我很少有时间不和别人讲话。
+  我去 PyCon 的时候非常紧张。我要发表一次演讲，在那儿我只认识几个人，还是在那儿呆了整整一周。其实我不应该焦虑的。PyCon 真是太棒了！每个人都是非常友好热情，以至于我也非常愿意和大家讨论。
   <p markdown="1" class="pquote-credit">
 — @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
   </p>
 </aside>
 
-如果你从来没在公共场合讲过话，感觉紧张那就太正常啦！记住你的听众就在那儿，因为他们都是真正的想听你介绍你的项目。
+如果你从来没在公共场合演讲过，感到紧张是很正常的！记住你的听众和你在一起，他们都是真正想听你介绍你的项目。
 
-当你在写你的演讲稿的时候，把重点放在你的听众会感兴趣而且能获取价值的事情上。保证你的语言要友好和亲切。笑一笑，深呼吸，幽默一点儿。
+当你在写你演讲稿的时候，把重点放在你的听众会感兴趣而且有价值的事情上。保证你的语言要友好且亲切。笑一笑，深呼吸，幽默一点儿。
 
 <aside markdown="1" class="pquote">
   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
-  当你开始写你的演讲稿的时候，不管你的主题是什么，如果你能把你的演讲当成是给别人讲故事的话，效果会更好。
+  你写演讲稿的时候，不管你的主题是什么，如果你能把你的演讲当成是给别人讲故事的话，效果会更好。
   <p markdown="1" class="pquote-credit">
 — Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
   </p>
 </aside>
 
-等你准备好了，考虑一下在某个会议上发言的时候推广你的项目研讨会可以帮助你接触更多人，有时候是来自全世界各地的人。
+等你准备好了，考虑在某个会议上发言的时候宣传你的项目讨论可以帮助你接触更多人，可能会是来自世界各地的人。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
-  我非常认真的给JSConf的人写了一封信，然后求他们给我一点时间在JSConf上展示我的项目。同时我又非常担心，这个项目我做了六个月，要是大家不认可怎么办。那时候我就一直在想，我的天，我在这里都干些什么事啊？
+  我非常认真地给 JSConf 的人写了一封信，然后请求他们给我一点时间在 JSConf 上展示我的项目。同时我也会担心，这个项目我做了六个月，如果大家不认可怎么办。那时候我就一直在想，我的天，我在这里都干些什么事啊？
   <p markdown="1" class="pquote-credit">
 — @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
   </p>
@@ -128,22 +128,22 @@ redirect_from: /zh-cn/finding-users/
 
 除了上面提到的策略之外，邀请人们分享和支持你的项目的最好办法就是分享和支持他们的项目。
 
-帮助新手，分享资源，给别人的项目认真的做贡献会帮助你建立起良好的声誉。然后他们就很有可能知道你的项目而且更有可能关注和分享你在做的事情。
+帮助新手，分享资源，认真地给别人的项目做贡献，会帮助你建立起良好的声誉。然后他们就很有可能知道你的项目而且更有可能关注和分享你在做的事情。
 
-有时候，这些关系还会进一步发展成更广阔的生态系统中的官方合作伙伴（意思是你有可能成为那些知名社区的成员）
+有时候，这些关系还会进一步发展成更宽泛的生态中的官方合作伙伴（意思是你有可能成为那些知名社区的成员）
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
-  urllib3现在成为最流行的Python第三方库的唯一原因就是大家都需要它。
+  urllib3 现在成为最流行的 Python 第三方库的唯一原因就是大家都需要它。
   <p markdown="1" class="pquote-credit">
 — @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
   </p>
 </aside>
 
-种一棵树的最好时间是十年前，其次是现在。所以任何时候开始建立你的声望都不晚。即使是你早就已经建立了自己的项目，也还是要继续找办法帮助别人。
+种一棵树最好是在十年前，也是现在。所以任何时候开始建立你的声誉都不晚。即使是你是在很久以前建立的项目，也需要继续维护它并找办法帮助别人。
 
-建立用户群没有一蹴而就的方法。获取别人的信任和尊重需要时间，同样，建立声望的过程也永远不会停止。
+建立用户基础并不是一蹴而就的。获取别人的信任和尊重需要时间，同样，建立声誉也需要一直坚持下去。
 
 ## 保持下去!
 
-有时候，让人们注意你的开源项目会花费很多时间。但是没关系！一些今天很流行的项目都是花了很多年才有如今的高活跃度。把重点放在建立声望上而不是企图一夜成名。耐心一点，一如既往的和那些可能会从中受益的人分享你的项目。
+有时候，让人们关注你的开源项目会花费很多时间。没关系！一些今天很流行的项目都是花了很多年才有如今的高活跃度的。把重点放在建立声誉上而不要企图一夜成名。保持耐心，请一如既往地和那些可能会从中受益的人分享你的项目。

From ce391c09de4a482c77766e09c22599d5f202eec5 Mon Sep 17 00:00:00 2001
From: webfansplz <308241863@qq.com>
Date: Wed, 21 Jun 2023 16:37:45 +0800
Subject: [PATCH 447/749] chore: fix typo

---
 _articles/zh-hans/best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/best-practices.md b/_articles/zh-hans/best-practices.md
index 4549cdadebc..f68fbfe41ea 100644
--- a/_articles/zh-hans/best-practices.md
+++ b/_articles/zh-hans/best-practices.md
@@ -94,7 +94,7 @@ redirect_from: /zh-cn/best-practices/
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
-  管理大型开源项目的关键就是保证 issue 活跃。尽量避免让 issue 停滞不前。如果你是一个IOS开发者，你会知道<abbr title="提交问题到 Apple 的 Radar bug 跟踪系统">提交雷达</abbr>是多么让人沮丧。您可能会在2年后收到回复，并被告知要再次使用最新版本的iOS。
+  管理大型开源项目的关键就是保证 issue 活跃。尽量避免让 issue 停滞不前。如果你是一个iOS开发者，你会知道<abbr title="提交问题到 Apple 的 Radar bug 跟踪系统">提交雷达</abbr>是多么让人沮丧。您可能会在2年后收到回复，并被告知要再次使用最新版本的iOS。
   <p markdown="1" class="pquote-credit">
 — @KrauseFx, ["开源社区黑客增长"](https://krausefx.com/blog/scaling-open-source-communities)
   </p>

From 8bc85da7600c5e1d0faf98ab6af0bff9bdf3fca1 Mon Sep 17 00:00:00 2001
From: YAMAMOTO Yuji <igrep@n.email.ne.jp>
Date: Thu, 6 Jul 2023 22:30:03 +0900
Subject: [PATCH 448/749] =?UTF-8?q?Fix=20typo:=20"=E6=9C=89=E5=8A=B9?=
 =?UTF-8?q?=E7=9A=84"=20->=20"=E5=8F=8B=E5=A5=BD=E7=9A=84"=20in=20Japanese?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Same modification with https://github.com/github/opensource.guide/pull/3028/commits/3dd708f5664f708f7690625fd58fcd1851cfbd1d

"有効的" in Japanese means "effective" in English, while "友好的" means "friendly".

I guess the original translator of this article made this mistake because both of them are pronounced as "yūkō-teki".
---
 _articles/ja/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md
index 4d9ec76ae28..a1cc9912732 100644
--- a/_articles/ja/legal.md
+++ b/_articles/ja/legal.md
@@ -92,7 +92,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
 
 追加のコントリビューターアグリーメントはしばしば Contributor License Agreement (CLA) と呼ばれます。これを作ることで、プロジェクトのメンテナーは運用上の手間が必要になってきます。どのくらいの手間がかかるかはプロジェクトとやり方によります。簡単な同意であれば、コントリビューターに対してプロジェクトのオープンソースライセンスに従ってコントリビュートする権利があるとクリックひとつで同意できる様になるでしょう。より複雑な同意になると、法務のレビューとコントリビューターの雇用主の署名が必要になるかもしれません。
 
-加えて、「書類作業」が必要になることによって、中にはその作業が不必要、理解しがたい、公正ではない（プロジェクトのオープンソースライセンスによって、同意を受ける人や一般の人がコントリビューターより多くの権利を得る場合）と感じる人が出てくるかもしれません。このような状況では、追加のコントリビューターアグリーメントはプロジェクトのコミュニティからは有効的でないと受け取られるかもしれません。
+加えて、「書類作業」が必要になることによって、中にはその作業が不必要、理解しがたい、公正ではない（プロジェクトのオープンソースライセンスによって、同意を受ける人や一般の人がコントリビューターより多くの権利を得る場合）と感じる人が出てくるかもしれません。このような状況では、追加のコントリビューターアグリーメントはプロジェクトのコミュニティからは友好的でないと受け取られるかもしれません。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">

From cb3606abc88abc08e3be90fd75c5ec7b1b6dd784 Mon Sep 17 00:00:00 2001
From: YAMAMOTO Yuji <igrep@n.email.ne.jp>
Date: Thu, 6 Jul 2023 22:35:06 +0900
Subject: [PATCH 449/749] =?UTF-8?q?Fix=20the=20wrong=20translation=20in=20?=
 =?UTF-8?q?Japanese:=20"=E3=83=A2=E3=83=A9=E3=83=AB"=20->=20"=E5=A3=AB?=
 =?UTF-8?q?=E6=B0=97"?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

"モラル" in Japanese means "moral" in English (a katakana word pronounced similarly with "moral"), while "士気" means "morale".

It looks like that the original translator mistook "morale" for "moral".
---
 _articles/ja/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md
index a1cc9912732..707b71ae1a1 100644
--- a/_articles/ja/legal.md
+++ b/_articles/ja/legal.md
@@ -138,7 +138,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
-  パッチに関連した知的財産を手放すことで従業員の知識ベースと名声を築く事ができます。そうすることで、その企業は従業員の能力を高め、自律的に働くことに投資していることを示すことができます。こういったメリットは、モラルの向上や従業員の維持にも繋がります。
+  パッチに関連した知的財産を手放すことで従業員の知識ベースと名声を築く事ができます。そうすることで、その企業は従業員の能力を高め、自律的に働くことに投資していることを示すことができます。こういったメリットは、士気の向上や従業員の維持にも繋がります。
   <p markdown="1" class="pquote-credit">
 — @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>

From 1bc456d0b618d112a9f31b8ca6d691dce239ecd0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?= <websnke@tutanota.com>
Date: Sat, 8 Jul 2023 17:09:05 +0200
Subject: [PATCH 450/749] Update German translation

---
 _articles/de/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/de/how-to-contribute.md b/_articles/de/how-to-contribute.md
index af73a79748e..07a283b05e7 100644
--- a/_articles/de/how-to-contribute.md
+++ b/_articles/de/how-to-contribute.md
@@ -62,7 +62,7 @@ Wenn Sie gerade erst anfangen, Open-Source-Arbeit zu leisten, kann der Prozess e
 
 Keine Sorge! Es gibt viele Möglichkeiten, zu einem Open-Source-Projekt beizutragen. Die folgenden paar Tipps helfen Ihnen, dabei gute Erfahrungen zu machen.
 
-### Sie müssen keinen Code beisteuern
+### Sie brauchen keine Programmierkenntnisse
 
 Ein weit verbreiteter Irrtum! Aber in Wirklichkeit sind es oft andere Projektaspekte, die am [meisten Unterstützung benötigen](https://github.com/blog/2195-the-shape-of-open-source). Sie tun dem Projekt einen _großen_ Gefallen, indem Sie anbieten, bei nicht-Code-Aspekten mitzuwirken!
 

From e709ee2aa550f7e25e022a9cacee2891e45c230f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E6=9D=9C=E5=BA=9C?= <dufu1991@163.com>
Date: Sun, 9 Jul 2023 09:11:13 +0800
Subject: [PATCH 451/749] Delect space indentation

---
 _articles/zh-hans/finding-users.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/zh-hans/finding-users.md b/_articles/zh-hans/finding-users.md
index 5a842f9df4b..01e4548b564 100644
--- a/_articles/zh-hans/finding-users.md
+++ b/_articles/zh-hans/finding-users.md
@@ -6,8 +6,8 @@ class: finding
 order: 3
 image: /assets/images/cards/finding.png
 related:
-    - beginners
-    - building
+  - beginners
+  - building
 redirect_from: /zh-cn/finding-users/
 ---
 

From 89f4912edf36dc5d0b6a5738d77ee94ed4a99497 Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Mon, 10 Jul 2023 16:33:18 -0700
Subject: [PATCH 452/749] Kick off burnout article

---
 ...ing-balance-for-open-source-maintainers.md | 32 +++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 _articles/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..57da7a08fb8
--- /dev/null
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,32 @@
+---
+lang: en
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-Care and avoiding burnout as a maintainer.
+class: balance
+order: 15
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain a balance to stay refreshed and productive for the long run. This is where the concept of personal ecology comes into play.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— @gabek, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work.
+  </p>
+</aside>
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+### Reflect on what causes you to get out of balance and stressed out
+
+### Watch out for signs of burnout
+
+### What would you need to continue sustaining yourself and your community?
+
+## Additional Resources
+
+## Contributors

From e977df35b58373898424d0054c3ae978e8e9f243 Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Fri, 28 Jul 2023 12:41:25 -0700
Subject: [PATCH 453/749] Add copy from Google Doc

---
 ...ing-balance-for-open-source-maintainers.md | 194 +++++++++++++++++-
 1 file changed, 192 insertions(+), 2 deletions(-)

diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
index 57da7a08fb8..3038503e27f 100644
--- a/_articles/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -7,26 +7,216 @@ order: 15
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain a balance to stay refreshed and productive for the long run. This is where the concept of personal ecology comes into play.
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
   I was unable to focus or start on a task. I had a lack of empathy for users.
   <p markdown="1" class="pquote-credit">
-— @gabek, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work.
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
   </p>
 </aside>
 
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
 ## Tips for Self-Care and Avoiding Burnout as a Maintainer:
 
 ### Identify your motivations for working in open source
 
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
 ### Reflect on what causes you to get out of balance and stressed out
 
+It’s important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying ‘no’:** It can be easy to take on more responsibilities than you should on an open source project. Whether it’s from users, contributors, or other maintainers – we can’t always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it’s harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you’re paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer’s focus and what’s best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
 ### Watch out for signs of burnout
 
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla’s [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I’m a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
 ### What would you need to continue sustaining yourself and your community?
 
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you’re looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you’re thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night’s sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I’m finding more opportunity to sprinkle ‘moments of creativity’ in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can’t say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It’s okay to not give energy to things you don’t care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, , maintainer of Leaflet
+  </p>
+</aside>
+
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, ,maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
 ## Additional Resources
 
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla’s Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
 ## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
\ No newline at end of file

From 72a205a5cfea3378076dd0218757f27006fc6747 Mon Sep 17 00:00:00 2001
From: Abby Cabunoc Mayes <abbycabs@github.com>
Date: Fri, 28 Jul 2023 16:20:03 -0400
Subject: [PATCH 454/749] Update
 maintaining-balance-for-open-source-maintainers.md

---
 _articles/maintaining-balance-for-open-source-maintainers.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
index 3038503e27f..0f474b15a16 100644
--- a/_articles/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -1,7 +1,7 @@
 ---
 lang: en
 title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-Care and avoiding burnout as a maintainer.
+description: Tips for self-care and avoiding burnout as a maintainer.
 class: balance
 order: 15
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
@@ -219,4 +219,4 @@ This guide was written by [@abbycabs](https://github.com/abbycabs) with contribu
 [@thisisnic](https://github.com/thisisnic)
 [@tudoramariei](https://github.com/tudoramariei)
 [@UlisesGascon](https://github.com/UlisesGascon)
-[@waldyrious](https://github.com/waldyrious) + many others!
\ No newline at end of file
+[@waldyrious](https://github.com/waldyrious) + many others!

From fbef22e64181c84a02f099a0c997ce543d4a58b9 Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Tue, 1 Aug 2023 10:14:09 -0700
Subject: [PATCH 455/749] Add illustration

---
 assets/images/illos/balance.svg | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 assets/images/illos/balance.svg

diff --git a/assets/images/illos/balance.svg b/assets/images/illos/balance.svg
new file mode 100644
index 00000000000..6348f827513
--- /dev/null
+++ b/assets/images/illos/balance.svg
@@ -0,0 +1 @@
+<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 394.89 211"><defs><style>.cls-1{fill:#fff;}.cls-2{fill:#b8c0d7;}.cls-3{fill:#e18173;}.cls-4{fill:#d1725f;}.cls-5{fill:#dee6fd;}.cls-6{fill:#a6aec5;}.cls-7{fill:url(#linear-gradient);}.cls-8{fill:url(#linear-gradient-2);}.cls-9{fill:#472f5b;}.cls-10{fill:url(#linear-gradient-3);}.cls-11{fill:url(#linear-gradient-4);}.cls-12{fill:#29163a;}.cls-13{fill:url(#linear-gradient-5);}.cls-14{fill:url(#linear-gradient-6);}.cls-15{fill:url(#linear-gradient-7);}.cls-16{fill:#6e425a;}.cls-17{fill:url(#linear-gradient-8);}.cls-18{fill:#b1615f;}.cls-19{fill:#aa504b;}.cls-20{fill:#b97577;}.cls-21{fill:url(#linear-gradient-9);}.cls-22{fill:url(#linear-gradient-10);}.cls-23{fill:url(#linear-gradient-11);}.cls-24{fill:#283047;}.cls-25{fill:#bf6e73;}.cls-26{fill:#210e26;}.cls-27{fill:url(#linear-gradient-12);}.cls-28{fill:url(#linear-gradient-13);}.cls-29{fill:url(#linear-gradient-14);}.cls-30{fill:url(#linear-gradient-15);}.cls-31{fill:url(#linear-gradient-16);}.cls-32{fill:#020025;}.cls-33{fill:url(#linear-gradient-17);}.cls-34{fill:#1d002e;}.cls-35{fill:#e8aa5d;}.cls-36{fill:#66263f;}.cls-37{fill:url(#linear-gradient-18);}.cls-38{fill:url(#linear-gradient-19);}.cls-39{fill:#d2d1c9;}.cls-40{fill:url(#linear-gradient-20);}.cls-41{fill:#51102e;}.cls-42{fill:#351a48;}.cls-43{fill:url(#linear-gradient-21);}.cls-44{fill:url(#linear-gradient-22);}.cls-45{fill:#e9c35f;}.cls-46{fill:url(#linear-gradient-23);}.cls-47{fill:#99660a;}.cls-145,.cls-48,.cls-62,.cls-65,.cls-81{fill:none;}.cls-48,.cls-65{stroke:#99660a;stroke-width:0.44px;}.cls-145,.cls-48,.cls-62{stroke-miterlimit:10;}.cls-49{fill:#3c93be;}.cls-50{fill:url(#linear-gradient-24);}.cls-51{fill:#281547;}.cls-52{fill:#e5f0ff;}.cls-53{fill:#b8c8e9;}.cls-54{fill:#c8d6f3;}.cls-55{fill:url(#linear-gradient-25);}.cls-56{fill:#190e30;}.cls-57{fill:url(#linear-gradient-26);}.cls-58{fill:url(#linear-gradient-27);}.cls-59{fill:url(#linear-gradient-28);}.cls-60{fill:#1f1a66;}.cls-61{fill:#2d68be;}.cls-62{stroke:#1f1a66;stroke-width:0.37px;}.cls-63{fill:#8aa1cc;fill-rule:evenodd;}.cls-64{fill:#5f223e;}.cls-65,.cls-81{stroke-linejoin:round;}.cls-66{fill:url(#linear-gradient-29);}.cls-67{fill:#dae0f1;}.cls-68{fill:#6c3e2f;}.cls-69{fill:#23001a;}.cls-70{fill:#ed5e41;}.cls-71{fill:#e8225e;}.cls-72{fill:url(#linear-gradient-30);}.cls-73{fill:#622f20;}.cls-74{fill:url(#linear-gradient-31);}.cls-75{fill:#e20040;}.cls-76{fill:#c280b6;}.cls-77{fill:url(#linear-gradient-32);}.cls-78{fill:url(#linear-gradient-33);}.cls-79{fill:#d8b2d4;}.cls-80{fill:url(#linear-gradient-34);}.cls-81{stroke:#d8b2d4;stroke-width:0.79px;}.cls-145,.cls-81{stroke-linecap:round;}.cls-82{fill:url(#linear-gradient-35);}.cls-83{fill:#ece3de;}.cls-84{fill:url(#linear-gradient-36);}.cls-85{fill:#efb94b;}.cls-86{fill:url(#linear-gradient-37);}.cls-87{fill:url(#linear-gradient-38);}.cls-88{fill:#e9043e;}.cls-89{fill:#176498;}.cls-90{fill:url(#linear-gradient-39);}.cls-91{fill:#a26200;}.cls-92{fill:#2a001e;}.cls-93{fill:#f0e6ed;}.cls-94{fill:#8a0e2f;}.cls-95{fill:#133963;}.cls-96{fill:#d8d0ca;}.cls-97{fill:#ed7652;}.cls-98{fill:#de4a6c;}.cls-99{fill:url(#linear-gradient-40);}.cls-100{fill:url(#linear-gradient-41);}.cls-101{fill:url(#linear-gradient-42);}.cls-102{fill:#e05b7b;}.cls-103{fill:#c6a9a1;}.cls-104{fill:url(#linear-gradient-43);}.cls-105{fill:#ee8b6f;}.cls-106{fill:url(#linear-gradient-44);}.cls-107{fill:#d46655;}.cls-108{fill:url(#linear-gradient-45);}.cls-109{fill:#254870;}.cls-110{fill:url(#linear-gradient-46);}.cls-111{fill:url(#linear-gradient-47);}.cls-112{fill:#e6e4eb;}.cls-113{fill:url(#linear-gradient-48);}.cls-114{fill:url(#linear-gradient-49);}.cls-115{fill:url(#linear-gradient-50);}.cls-116{fill:url(#linear-gradient-51);}.cls-117{fill:#001e3c;}.cls-118{fill:url(#linear-gradient-52);}.cls-119{fill:#d8c570;}.cls-120{fill:#d8c670;}.cls-121{fill:url(#linear-gradient-53);}.cls-122{fill:#d67d67;}.cls-123{fill:url(#linear-gradient-54);}.cls-124{fill:#d67c67;}.cls-125{fill:#06061d;}.cls-126{fill:url(#linear-gradient-55);}.cls-127{fill:#d56348;}.cls-128{fill:#d67b67;}.cls-129{fill:#160828;}.cls-130{fill:#392034;}.cls-131{fill:#ddedf7;}.cls-132{fill:#4d2839;}.cls-133{fill:#d67066;}.cls-134{fill:#ca2f79;}.cls-135{fill:url(#linear-gradient-56);}.cls-136{fill:url(#linear-gradient-57);}.cls-137{fill:url(#linear-gradient-58);}.cls-138{fill:url(#linear-gradient-59);}.cls-139{fill:url(#linear-gradient-60);}.cls-140{fill:url(#linear-gradient-61);}.cls-141{fill:#662234;}.cls-142{fill:#170829;}.cls-143{fill:url(#linear-gradient-62);}.cls-144{fill:#03030d;}.cls-145{stroke:#d9bf6b;stroke-width:0.45px;}.cls-146{fill:#ccaa38;}.cls-147{fill:#d9bf6b;}.cls-148{fill:#792c29;}.cls-149{fill:#ac5642;}.cls-150{fill:url(#linear-gradient-63);}.cls-151{fill:#e4b17f;}.cls-152{fill:url(#linear-gradient-64);}.cls-153{fill:url(#linear-gradient-65);}.cls-154{fill:url(#linear-gradient-66);}.cls-155{fill:url(#linear-gradient-67);}.cls-156{fill:#926948;}.cls-157{fill:url(#linear-gradient-68);}.cls-158{fill:#340c10;}.cls-159{fill:#40151c;}.cls-160{fill:url(#linear-gradient-69);}</style><linearGradient id="linear-gradient" x1="257.24" y1="132.03" x2="262.09" y2="132.03" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -17.4)" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#c36750"/><stop offset="1" stop-color="#e17c6c"/></linearGradient><linearGradient id="linear-gradient-2" x1="259.48" y1="142.34" x2="261.89" y2="134.81" xlink:href="#linear-gradient"/><linearGradient id="linear-gradient-3" x1="291.48" y1="186.75" x2="306.1" y2="244.08" gradientTransform="matrix(1, 0, 0.02, 1, -1.52, -0.03)" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#472f5b"/><stop offset="1" stop-color="#301342"/></linearGradient><linearGradient id="linear-gradient-4" x1="295.21" y1="221.18" x2="334.03" y2="221.18" gradientTransform="matrix(1, 0, 0.04, 1, -3.49, 0.17)" xlink:href="#linear-gradient-3"/><linearGradient id="linear-gradient-5" x1="260.93" y1="170.36" x2="272.13" y2="170.36" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -17.4)" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#b8c0d7"/><stop offset="1" stop-color="#a7afc6"/></linearGradient><linearGradient id="linear-gradient-6" x1="296.19" y1="187.03" x2="298.25" y2="160.53" xlink:href="#linear-gradient-5"/><linearGradient id="linear-gradient-7" x1="284.6" y1="143.66" x2="281.11" y2="160.42" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -78.34)" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#b8c0d7"/><stop offset="1" stop-color="#d4dcf3"/></linearGradient><linearGradient id="linear-gradient-8" x1="280.95" y1="121.87" x2="288.88" y2="119.65" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -17.4)" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#673850"/><stop offset="1" stop-color="#55215a"/></linearGradient><linearGradient id="linear-gradient-9" x1="295.67" y1="177.6" x2="295.77" y2="184.08" xlink:href="#linear-gradient"/><linearGradient id="linear-gradient-10" x1="297.28" y1="168.09" x2="304.98" y2="154.6" xlink:href="#linear-gradient-5"/><linearGradient id="linear-gradient-11" x1="260.83" y1="139.26" x2="262.71" y2="147.74" xlink:href="#linear-gradient-5"/><linearGradient id="linear-gradient-12" x1="283.08" y1="134.46" x2="282.39" y2="137.11" xlink:href="#linear-gradient"/><linearGradient id="linear-gradient-13" x1="280.83" y1="134.15" x2="280.83" y2="134.15" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -78.34)" xlink:href="#linear-gradient"/><linearGradient id="linear-gradient-14" x1="287.52" y1="108.31" x2="285" y2="105.58" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -17.4)" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#b8c0d7"/><stop offset="0.56" stop-color="#c7cfe6"/><stop offset="1" stop-color="#d4dcf3"/></linearGradient><linearGradient id="linear-gradient-15" x1="297.42" y1="122.43" x2="298.95" y2="116.57" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -17.4)" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#b3bbd2"/><stop offset="1" stop-color="#a7afc6"/></linearGradient><linearGradient id="linear-gradient-16" x1="290.59" y1="106.33" x2="299.53" y2="106.33" xlink:href="#linear-gradient-15"/><linearGradient id="linear-gradient-17" x1="320.5" y1="131.82" x2="315.99" y2="129.8" gradientTransform="matrix(1, 0, 0.02, 1, -1.98, 0.2)" xlink:href="#linear-gradient-5"/><linearGradient id="linear-gradient-18" x1="229.22" y1="103.03" x2="233.06" y2="100.98" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#5a1d3b"/><stop offset="1" stop-color="#51102e"/></linearGradient><linearGradient id="linear-gradient-19" x1="228.66" y1="131.59" x2="226.87" y2="124.42" xlink:href="#linear-gradient-18"/><linearGradient id="linear-gradient-20" x1="223.13" y1="100.69" x2="227.89" y2="99.89" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#cfcdc1"/><stop offset="1" stop-color="#bcb38e"/></linearGradient><linearGradient id="linear-gradient-21" x1="231.1" y1="130.78" x2="262.61" y2="130.78" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#e9c35f"/><stop offset="1" stop-color="#e8a35c"/></linearGradient><linearGradient id="linear-gradient-22" x1="264.21" y1="128.56" x2="240.9" y2="136.27" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#e8851c"/><stop offset="1" stop-color="#e8a35c"/></linearGradient><linearGradient id="linear-gradient-23" x1="238.57" y1="180.09" x2="221.57" y2="142.02" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#e89e5b"/><stop offset="1" stop-color="#e8a35c"/></linearGradient><linearGradient id="linear-gradient-24" x1="235.93" y1="214.44" x2="244.75" y2="192.83" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#0b78a9"/><stop offset="1" stop-color="#2e8bb8"/></linearGradient><linearGradient id="linear-gradient-25" x1="234.02" y1="141.1" x2="229.51" y2="146.32" xlink:href="#linear-gradient-18"/><linearGradient id="linear-gradient-26" x1="237.74" y1="110.57" x2="245.38" y2="110.57" xlink:href="#linear-gradient-18"/><linearGradient id="linear-gradient-27" x1="208.06" y1="150.88" x2="217.53" y2="150.88" xlink:href="#linear-gradient-21"/><linearGradient id="linear-gradient-28" x1="206.71" y1="160.56" x2="226.68" y2="160.56" xlink:href="#linear-gradient-21"/><linearGradient id="linear-gradient-29" x1="225.91" y1="91.53" x2="241.05" y2="103.44" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#351a48"/><stop offset="1" stop-color="#1d002e"/></linearGradient><linearGradient id="linear-gradient-30" x1="123.77" y1="205.71" x2="130.19" y2="190.89" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#ed5e41"/><stop offset="1" stop-color="#cd4a41"/></linearGradient><linearGradient id="linear-gradient-31" x1="127.76" y1="224.14" x2="122.74" y2="250.44" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#5a2614"/><stop offset="1" stop-color="#5a2614"/></linearGradient><linearGradient id="linear-gradient-32" x1="144.89" y1="255.36" x2="130.18" y2="225.45" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#663526"/><stop offset="1" stop-color="#622f20"/></linearGradient><linearGradient id="linear-gradient-33" x1="124.91" y1="204.81" x2="133.4" y2="213.71" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#e8225e"/><stop offset="1" stop-color="#a2225e"/></linearGradient><linearGradient id="linear-gradient-34" x1="93.22" y1="147.16" x2="115.07" y2="176.03" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#6c3e2f"/><stop offset="1" stop-color="#592613"/></linearGradient><linearGradient id="linear-gradient-35" x1="113.11" y1="200.09" x2="117.11" y2="189.06" xlink:href="#linear-gradient-30"/><linearGradient id="linear-gradient-36" x1="143.23" y1="250.71" x2="147.42" y2="265.43" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#ece3de"/><stop offset="1" stop-color="#e5dab6"/></linearGradient><linearGradient id="linear-gradient-37" x1="152.6" y1="268.53" x2="148.37" y2="266.06" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#efb94b"/><stop offset="1" stop-color="#ef9c32"/></linearGradient><linearGradient id="linear-gradient-38" x1="124.26" y1="253.34" x2="117.56" y2="262.67" xlink:href="#linear-gradient-36"/><linearGradient id="linear-gradient-39" x1="124.39" y1="272.13" x2="118.17" y2="268.22" xlink:href="#linear-gradient-37"/><linearGradient id="linear-gradient-40" x1="171.58" y1="229.01" x2="154.28" y2="251.2" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#c1447b"/><stop offset="1" stop-color="#de4a6c"/></linearGradient><linearGradient id="linear-gradient-41" x1="168.04" y1="222.36" x2="171.92" y2="218.09" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#d8d0ca"/><stop offset="1" stop-color="#cbbfaf"/></linearGradient><linearGradient id="linear-gradient-42" x1="171.37" y1="271.74" x2="175.94" y2="265.16" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#ee8b6f"/><stop offset="1" stop-color="#de786b"/></linearGradient><linearGradient id="linear-gradient-43" x1="164.61" y1="262.5" x2="183.62" y2="234.52" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#c6a9a1"/><stop offset="1" stop-color="#be9b90"/></linearGradient><linearGradient id="linear-gradient-44" x1="165.96" y1="252.85" x2="186.83" y2="220.06" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#c1447b"/><stop offset="1" stop-color="#e05b7b"/></linearGradient><linearGradient id="linear-gradient-45" x1="141.67" y1="210.67" x2="166.7" y2="210.67" xlink:href="#linear-gradient-42"/><linearGradient id="linear-gradient-46" x1="238.37" y1="278.76" x2="239.37" y2="288.34" gradientTransform="translate(5.94 -32.43) rotate(1.76)" xlink:href="#linear-gradient-42"/><linearGradient id="linear-gradient-47" x1="186.38" y1="282.19" x2="226.96" y2="282.19" gradientTransform="translate(5.94 -32.43) rotate(1.76)" xlink:href="#linear-gradient-43"/><linearGradient id="linear-gradient-48" x1="188.7" y1="254.65" x2="188.15" y2="217.84" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#e6e4eb"/><stop offset="1" stop-color="#d8d0ca"/></linearGradient><linearGradient id="linear-gradient-49" x1="192.88" y1="213.3" x2="209.58" y2="240.3" xlink:href="#linear-gradient-48"/><linearGradient id="linear-gradient-50" x1="173.28" y1="211.38" x2="190.58" y2="220.17" xlink:href="#linear-gradient-48"/><linearGradient id="linear-gradient-51" x1="185.1" y1="292.67" x2="210.84" y2="292.67" gradientTransform="translate(5.94 -32.43) rotate(1.76)" xlink:href="#linear-gradient-43"/><linearGradient id="linear-gradient-52" x1="82.12" y1="138.23" x2="79.09" y2="128.18" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#d8c570"/><stop offset="1" stop-color="#d7a66c"/></linearGradient><linearGradient id="linear-gradient-53" x1="49.85" y1="172.47" x2="69.63" y2="142.8" xlink:href="#linear-gradient-52"/><linearGradient id="linear-gradient-54" x1="82.5" y1="139.38" x2="70.6" y2="123.76" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#d68168"/><stop offset="1" stop-color="#d55b62"/></linearGradient><linearGradient id="linear-gradient-55" x1="87.4" y1="161.54" x2="88.73" y2="150.72" xlink:href="#linear-gradient-54"/><linearGradient id="linear-gradient-56" x1="76.75" y1="148.76" x2="69.33" y2="134.41" xlink:href="#linear-gradient-54"/><linearGradient id="linear-gradient-57" x1="67.07" y1="147.48" x2="84.14" y2="191.82" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#160828"/><stop offset="1" stop-color="#0a061d"/></linearGradient><linearGradient id="linear-gradient-58" x1="94.28" y1="170.66" x2="80.08" y2="158.37" xlink:href="#linear-gradient-57"/><linearGradient id="linear-gradient-59" x1="38.17" y1="101.39" x2="59.87" y2="139.52" xlink:href="#linear-gradient-57"/><linearGradient id="linear-gradient-60" x1="84.05" y1="255.75" x2="77.51" y2="245.22" xlink:href="#linear-gradient-57"/><linearGradient id="linear-gradient-61" x1="78.44" y1="244.6" x2="50.68" y2="199.13" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#160828"/><stop offset="1" stop-color="#281a3b"/></linearGradient><linearGradient id="linear-gradient-62" x1="55.63" y1="-189.68" x2="52.32" y2="-193.07" gradientTransform="translate(71.05 277.79) rotate(-18.92)" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#170829"/><stop offset="1" stop-color="#03030d"/></linearGradient><linearGradient id="linear-gradient-63" x1="274.2" y1="235.63" x2="280.2" y2="252.92" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#ac5642"/><stop offset="1" stop-color="#792c29"/></linearGradient><linearGradient id="linear-gradient-64" x1="275.36" y1="272.11" x2="273.89" y2="257.53" xlink:href="#linear-gradient-63"/><linearGradient id="linear-gradient-65" x1="242.52" y1="257.8" x2="260.29" y2="257.8" xlink:href="#linear-gradient-63"/><linearGradient id="linear-gradient-66" x1="270.32" y1="267.81" x2="267.1" y2="253.12" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#ac5642"/><stop offset="1" stop-color="#bb776a"/></linearGradient><linearGradient id="linear-gradient-67" x1="245.2" y1="254.46" x2="250.59" y2="249.3" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#521c1f"/><stop offset="1" stop-color="#792c29"/></linearGradient><linearGradient id="linear-gradient-68" x1="675.88" y1="925.53" x2="688.25" y2="925.53" gradientTransform="translate(459.18 -870.28) rotate(45)" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#926948"/><stop offset="1" stop-color="#774d2c"/></linearGradient><linearGradient id="linear-gradient-69" x1="675.25" y1="919.1" x2="689.69" y2="919.1" gradientTransform="translate(459.18 -870.28) rotate(45)" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#44171d"/><stop offset="1" stop-color="#2e080b"/></linearGradient></defs><title>building</title><path class="cls-1" d="M384.29,201.55c-15.51-17.27-31.23-32-48.83-15.08s-24.26,5.65-36.84,18.24-26.44,17.58-44.32,18-36.22-14.53-50.9-17-14.11-4.44-29.63-7.41-20.19-13.51-37.69-3.95S89.76,208.63,63,188.26s-39.55-19.78-63-3.08V238c9.48,2,13.94,2.19,24.54-1.77s28.36,2.26,41.9.57,33-11.4,65-3.54,54,15,74.8,9.45,24.81-.54,37.27-6.21,28.58-17.5,58.68-5.92,48.59-3.71,63.1,1a114.12,114.12,0,0,0,29.56,4.92V206.89S387.64,205.28,384.29,201.55Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M301.09,265.63c-0.17,1.23.79,2.61-.18,3.25s-6.39,1.81-6.71.32a8.21,8.21,0,0,0-1.06-2.58l1.46-2.33Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M339.61,265.63c-0.14,1.23,1.8,2,.85,2.61s-7.31,2.44-7.66,1-0.44-1.87-.44-1.87l1.41-2.33Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M309.28,127.58c-0.95.09-1.88-.45-2.83-0.36a0.58,0.58,0,0,0-.27.07,0.47,0.47,0,0,0-.16.22,4.6,4.6,0,0,0,.33,2.91c0.72,1.59,1.44,3.19,2.2,4.77a0.49,0.49,0,0,0,.2.25,0.17,0.17,0,0,0,.25-0.11" transform="translate(0 -60.95)"/><path class="cls-3" d="M316,129.36l0.11-5.81a14.67,14.67,0,0,0,4.12-7.94c0.79-4.92.14-5.32-.82-5.92s0-1.43-.93-2.71-4.85-2.78-9.67-1.09-8.57,3.25-3.91,4.79c-0.78,7.33-1.7,9.66-.78,12.66,1.14,3.71,3.84,3.44,3.84,3.44l-0.11,2.81-3.59,5.69,5.1,9.12,9-5.46Z" transform="translate(0 -60.95)"/><path class="cls-4" d="M320.26,115.61c0.06-.36.11-0.69,0.15-1l-0.16,0a3.49,3.49,0,0,0-1.74.47,5.28,5.28,0,0,0-1.5,1.21,2,2,0,0,1,.35,2.56c-0.44.83-1.19,1.47-1.65,2.3a3.93,3.93,0,0,0-.48,2.21c0,0.53.19,1.06,0.25,1.59a9.58,9.58,0,0,1-1.1,4.71l1.2,2.1a7.37,7.37,0,0,0,.91-0.55L316,129.36l0.11-5.81A14.67,14.67,0,0,0,320.26,115.61Z" transform="translate(0 -60.95)"/><path class="cls-4" d="M304.8,117.82a44.28,44.28,0,0,0,1-7.36l-0.85.23c-0.78,7.33-1.7,9.66-.78,12.66,1.14,3.71,3.84,3.44,3.84,3.44C304.28,126.18,304.28,120.84,304.8,117.82Z" transform="translate(0 -60.95)"/><path class="cls-5" d="M308.72,121.43a1,1,0,0,1,1.47,1.32,2,2,0,0,1-2.59,1.57c-1.23-.43-2.53-1.59-1.78-2.17,0.55-.43.9,0,1.56,0S308.05,121.69,308.72,121.43Z" transform="translate(0 -60.95)"/><path class="cls-6" d="M280.4,135.19c2.14-.26,6.68-2.42,9.58-2.75l-0.82,5-8,1.12Z" transform="translate(0 -60.95)"/><path class="cls-3" d="M283.15,136.3c1.19-2.54.79-3.57,0-6s-0.42-3.27.13-5.12-0.92-3.66-.58-4.24a0.44,0.44,0,0,1,.74-0.12,8.37,8.37,0,0,1,1.12,3s0.48-.51,0-2.07-0.76-2-.09-2.24c0.26-.11,1.75-0.69,2.06-0.26a5.75,5.75,0,0,1,.77,3.63c-0.16.9-.42,1.82,0.22,0.47s-0.17-3.83.31-3.95a1.07,1.07,0,0,1,1,.11,10.14,10.14,0,0,1,.28,3.65c-0.93,2.56-.64,3.29-0.64,3.29a1.27,1.27,0,0,0,.8-0.47c0.63-.73.5-1.75,1-1.75s0.86,0.27.76,0.65c-0.2.69-.26,0.88-0.6,2.39-0.29,1.32-.53,1.44-2,2.6a27.18,27.18,0,0,0,0,4.88" transform="translate(0 -60.95)"/><path class="cls-7" d="M285.5,119.2a0.64,0.64,0,0,0,0,.07,2,2,0,0,1,.9,1.32,5.11,5.11,0,0,1,0,1.63,9.89,9.89,0,0,1-1,3.85,5.56,5.56,0,0,0-1,2.21,0.27,0.27,0,0,0,.1.27,9.15,9.15,0,0,1,1.13-1.34,3.31,3.31,0,0,1,1.62-.6,2.28,2.28,0,0,0,1.27-.15s-0.29-.73.64-3.29a10.14,10.14,0,0,0-.28-3.65,1.07,1.07,0,0,0-1-.11c-0.48.12,0.33,2.6-.31,3.95s-0.38.43-.22-0.47a5.75,5.75,0,0,0-.77-3.63A1.14,1.14,0,0,0,285.5,119.2Z" transform="translate(0 -60.95)"/><path class="cls-8" d="M290.51,127.29c0.33-1.51.4-1.7,0.6-2.39a0.27,0.27,0,0,0-.32-0.44,2.06,2.06,0,0,0-.41,1.2,2.65,2.65,0,0,1-.26.7,2.26,2.26,0,0,1-.63.64c-0.71.52-1.55,0.86-2.25,1.4a4.65,4.65,0,0,0-.85.86,5.61,5.61,0,0,0-1,2.76,10.3,10.3,0,0,0,.16,3,4.42,4.42,0,0,0,.14.58l2.88-.82a27.17,27.17,0,0,1,0-4.88C290,128.74,290.22,128.61,290.51,127.29Z" transform="translate(0 -60.95)"/><path class="cls-9" d="M298.39,178s-5.6,63.67-5.36,73.35,0.12,14.72.12,14.72h8.11a73.51,73.51,0,0,0,4-20.52c0.53-8.72-.32-19.22-0.31-21.52a6.39,6.39,0,0,1,.53-2.51,124.81,124.81,0,0,0,6.58-27.72s3.07,23.06,6.52,35.27c3.51,12.39,14.47,37,14.47,37h6.86s-5.42-33.45-11.08-42.4a6.82,6.82,0,0,1-1.09-3.9c0.29-7.52-.78-33.71-2.6-40C323,172.3,298.39,178,298.39,178Z" transform="translate(0 -60.95)"/><path class="cls-10" d="M310.81,193.42l-3.17-.21c-2.55-.17-3,0.11-2.83,2.65a61.52,61.52,0,0,1,0,7.62,60.24,60.24,0,0,1-2.81,14.6,8.92,8.92,0,0,0-.49,2,8.75,8.75,0,0,0,.08,1.74q0.07,0.61.13,1.21a112.71,112.71,0,0,1-4,43.09h3.57a73.51,73.51,0,0,0,4-20.52c0.53-8.72-.32-19.22-0.31-21.52a6.4,6.4,0,0,1,.53-2.51c1.41-3.26,5.14-15.73,6.4-26.06C311.89,194.34,311.65,193.47,310.81,193.42Z" transform="translate(0 -60.95)"/><path class="cls-11" d="M328.84,223.66a6.82,6.82,0,0,1-1.09-3.9c0.29-7.52-.78-33.71-2.6-40C323,172.3,298.39,178,298.39,178s-0.07,2.25-.19,5.95c0.6-.25,2-0.82,2.47-1,1.74-.57.25-0.73,1.85,0.2a10.44,10.44,0,0,0,2.41,1.33,5.9,5.9,0,0,0,2.71-.16,17.22,17.22,0,0,1,5.62-.52,6.74,6.74,0,0,1,4.85,2.69c1.17,1.74,1.17,4,1.17,6.08,0,2.9.2,9.07,0.52,12,0.61,5.42,1.06,13.87,2.51,19.21,0.95,3.48,5.44,6.66,6.4,10.16,1.95,7.1,3.16,13.14,5.41,20.29,1.55,4.91.24,6.83,2.21,11.85h3.57S334.5,232.62,328.84,223.66Z" transform="translate(0 -60.95)"/><path class="cls-12" d="M305.11,182.26c0.56,2.41,1,4.83,1.39,7.2,0.06,0.29.12,0.59,0.18,0.85a1.71,1.71,0,0,0,0,.18l0,0.08v0h0l0-.07h0l0,0.05c0-.07,0,0,0.1.06a8.23,8.23,0,0,0,1.44.75c0.54,0.24,1.09.45,1.65,0.65l0.84,0.31,0.8,0.27,0.08,0a0.67,0.67,0,0,1-.31,1.3,33.15,33.15,0,0,0-3.66-.38c-0.62,0-1.25-.07-1.87-0.06-0.31,0-.62,0-0.93,0a3.09,3.09,0,0,0-.92.18,4.63,4.63,0,0,1,1.79-.72,16.63,16.63,0,0,1,1.9-.31c0.64-.07,1.28-0.12,1.92-0.13a14.47,14.47,0,0,1,2,.06L311.34,194c-0.39-.08-0.65-0.15-1-0.23s-0.61-.16-0.9-0.26c-0.59-.2-1.18-0.41-1.78-0.65a7.61,7.61,0,0,1-1.78-1,1.88,1.88,0,0,1-.51-0.61l0-.05h0l0-.08h0v0l0-.15c0-.1,0-0.18-0.06-0.26-0.06-.34-0.09-0.64-0.13-1a35.44,35.44,0,0,1-.2-3.7A26,26,0,0,1,305.11,182.26Z" transform="translate(0 -60.95)"/><path class="cls-12" d="M318.51,182.26s0.08,0.13.2,0.35a6.82,6.82,0,0,0,.51.82c0.1,0.16.25,0.3,0.37,0.47s0.29,0.3.46,0.44a5.55,5.55,0,0,0,.52.41,5.86,5.86,0,0,0,.59.36,7,7,0,0,0,.64.31c0.22,0.1.44,0.19,0.66,0.26,0.44,0.17.87,0.29,1.26,0.41s0.72,0.21,1,.27l0.38,0.13s-0.13.07-.37,0.17a4.62,4.62,0,0,1-1,.29,5.93,5.93,0,0,1-.71.06,5.1,5.1,0,0,1-.81,0,4.92,4.92,0,0,1-1.71-.55,4.44,4.44,0,0,1-.77-0.54,3.76,3.76,0,0,1-.62-0.68,3.83,3.83,0,0,1-.42-0.74,3.19,3.19,0,0,1-.21-0.72,2.9,2.9,0,0,1,0-1.09C318.47,182.4,318.51,182.26,318.51,182.26Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M309.36,137.24s-1.74-8.46-1.57-8.47c-2.15.12-2.71,0.82-4.45,1.18-2.14.44-5,.85-6.72,1.94-2.62,1.64-5,6.51-6.75,10.08-0.59-1.75.15-7.94,0.12-9.53,0,1.86-8.88,3.18-9.58,2.75,0.08,4.33-.16,6.11.58,10.44a42.64,42.64,0,0,0,1.65,7.14,15.8,15.8,0,0,0,2,3.63,5.48,5.48,0,0,0,1.81.95c3.11,1.16,3.9-.65,6.19-2.79,1.46-1.37,2.5-4.24,4-5.5-0.17,7.76.47,16.66,0.4,24.47,0,3-.12,4.91-0.15,7.9,1.86-.07,15.4.85,16.41,1a31.23,31.23,0,0,0,6.3.29c1.47-.06,6.91-0.23,6.91-0.23a3.36,3.36,0,0,1-.76-1.91c-0.11-1.63-.25-4.62-0.36-6.25a101.42,101.42,0,0,1,.85-19.18c0.34-2.8,1.28-5.32,1.58-8.12a49,49,0,0,0,.12-8.44c-0.12-1.88.82-4.83-1.86-6.85a17.38,17.38,0,0,0-9.53-3C316.39,129,309.36,137.24,309.36,137.24Z" transform="translate(0 -60.95)"/><path class="cls-13" d="M298,154.28a53,53,0,0,0,1.19-7.42c0.14-1.2.09-2.74-1-3.23a32.49,32.49,0,0,0-2.89,3.82c-2.24,3.29-5.08,6.63-7.24,10.25,1.9,0.08,2.77-1.42,4.61-3.15,1.46-1.37,2.5-4.24,4-5.5-0.17,7.76.47,16.66,0.4,24.47,0,3-.12,4.91-0.15,7.9H297c0-.2.55-0.92,0.56-1.11,0.23-4.87,1.23-7.81,1.45-12.62,0.11-2.4-.9-5.61-0.38-7.94C299.09,157.72,297.49,156.28,298,154.28Z" transform="translate(0 -60.95)"/><path class="cls-14" d="M326.53,182.44s-0.16-.94-0.24-2.11c-0.11-1.63-.77-4.42-0.88-6a101.42,101.42,0,0,1,.85-19.18,30.94,30.94,0,0,1,.64-3.36h0a21.17,21.17,0,0,1-2.11-4.46,78.93,78.93,0,0,0-2.29,19.27,38.29,38.29,0,0,1-2.86,16.12C321.09,182.61,326.53,182.44,326.53,182.44Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M317.57,129.06s0.42-2.61-.42-2.87-7.79,11-7.79,11Z" transform="translate(0 -60.95)"/><polyline class="cls-15" points="312.54 71.29 300.67 76.44 301.99 121.27 312.58 121.6 322.1 77.86 316.48 73.86"/><path class="cls-16" d="M319.44,109.7c-1-.6,0-1.43-0.93-2.71s-4.85-2.78-9.67-1.09-8.57,3.25-3.91,4.79c3.06,1,8-.16,8.53.3s-2,2.31-1,3.16,1.86,1,1.44,2.75,0.6,2.61,1.34,1.5,1.8-2.2,2.5-1.24-0.38,3-1.18,3.68a2.13,2.13,0,0,0-.44,2.71,14.67,14.67,0,0,0,4.12-7.94C321,110.69,320.39,110.29,319.44,109.7Z" transform="translate(0 -60.95)"/><path class="cls-17" d="M318.44,120.58a14.29,14.29,0,0,0,1.82-5c0.79-4.92.14-5.32-.82-5.92s0-1.43-.93-2.71-4.85-2.78-9.67-1.09l-1.38.5a2.21,2.21,0,0,0-.41.56,1.51,1.51,0,0,0,.55,2c2.38,1,4.75.67,6.65,1a0.74,0.74,0,0,0,.19.83c1.17,1.42,3.3,1.89,4.33,3.41a4.48,4.48,0,0,1,.56,3.2A23.59,23.59,0,0,1,318.44,120.58Z" transform="translate(0 -60.95)"/><path class="cls-18" d="M300,152l2.56,3.43a1.12,1.12,0,0,0,1.64.16h0a1.08,1.08,0,0,0,.14-1.45l-2.54-3.44c-0.39-.53-0.91-0.34-1.4.11h0C300,151.14,299.66,151.51,300,152Z" transform="translate(0 -60.95)"/><path class="cls-19" d="M302.47,155.27a1.7,1.7,0,0,0,.47-0.23l1-.7,0.37-.28-2.52-3.4a0.66,0.66,0,0,0-.8-0.28,0.35,0.35,0,0,0,0,.14l0.49,0.07a8.77,8.77,0,0,1,.87,1.54,1,1,0,0,1,.12.48,0.39,0.39,0,0,1-.29.36c-0.34.06-.62-0.47-0.93-0.32a3,3,0,0,1,.66,1,1.27,1.27,0,0,1-.24.61Z" transform="translate(0 -60.95)"/><path class="cls-19" d="M316.24,172.63l2.64,3.52a1.12,1.12,0,0,0,1.67.17h0a1.12,1.12,0,0,0,.12-1.49L318,171.29a1.12,1.12,0,0,0-1.67-.16l0,0A1.12,1.12,0,0,0,316.24,172.63Z" transform="translate(0 -60.95)"/><path class="cls-20" d="M301.59,156.77l11.5,14.74a1.51,1.51,0,0,0,2.2.21l2-1.85a1.49,1.49,0,0,0,.14-2.06l-11.58-14.2a1.51,1.51,0,0,0-2-.3l-2,1.34A1.46,1.46,0,0,0,301.59,156.77Z" transform="translate(0 -60.95)"/><path class="cls-18" d="M317.33,169.87a1.49,1.49,0,0,0,.14-2.06l-11.58-14.2a1.5,1.5,0,0,0-1.36-.52c-1.19,1,3.42,5.14,4.17,6,2.56,2.91,3.46,4.49,2.86,4.95s-4.13-2.91-3.78-1.35c0.24,1.09,2.13,4.36,4.19,7.41l1.12,1.43a1.51,1.51,0,0,0,2.2.21Z" transform="translate(0 -60.95)"/><path class="cls-20" d="M315.45,168.84c-0.32,0-.74-0.38-1,0a1.48,1.48,0,0,0,1.1,1.17,1.3,1.3,0,0,0,1.42-.66,1.23,1.23,0,0,0,.06-0.89,2.24,2.24,0,0,0-.25-0.5,11.19,11.19,0,0,0-2.08-2.49,2.06,2.06,0,0,0-.88-0.53,2.11,2.11,0,0,0,.71.94,5.53,5.53,0,0,1,1.57,2.34C316.25,168.65,315.82,168.8,315.45,168.84Z" transform="translate(0 -60.95)"/><path class="cls-6" d="M322.49,166.55c0.11,3.29,4.7,6.15,6.27,8.45l0.94-4.92-2.53-4.38-2.91.66Z" transform="translate(0 -60.95)"/><path class="cls-3" d="M323.1,166.7c-1.08.77-2.7,2.6-3.69,2.53s-2.65-1-3.52-.42-1.38.47-1.36,1.5-0.44,2.31-.06,3a12.8,12.8,0,0,0,2.84,3c0.77,0.46,1.68.49,1.94,0.07-0.49-.46-0.28-1.18.49-1a3.05,3.05,0,0,0,2.81-.33c0.92-.79.8-3,2.55-4s5.23-2.7,5.23-2.7l-3.62-3Z" transform="translate(0 -60.95)"/><path class="cls-21" d="M328.83,168.67a0.7,0.7,0,0,0-.31-0.23c-0.13,0-4.54-1.82-4.67-1.79-1.42.4,1.66,3.18,0.23,3.55a2.88,2.88,0,0,0-.93.33c-0.73.51-.67,1.71-1.4,2.23a1.74,1.74,0,0,1-.73.26,3.73,3.73,0,0,1-1.21,0c-0.85-.14-1.76-0.56-2.52-0.17-1.19.62-.83,2.17-0.35,3.23a3.26,3.26,0,0,0,.36.26c0.77,0.46,1.68.49,1.94,0.07-0.49-.46-0.28-1.18.49-1a3.05,3.05,0,0,0,2.81-.33c0.92-.79.8-3,2.55-4,1.07-.57,2.79-1.46,4-2.06A2.63,2.63,0,0,0,328.83,168.67Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M326.1,131.69c3.3,2.08,6.25,10.45,8.86,16.14s5,8.85,4.59,12.27-8.61,13-10.78,14.91c0,0-.94-6.13-6.27-8.45,0,0,8.09-4.25,9.05-7.27,0,0-6.67-10.37-8.06-15.38S326.1,131.69,326.1,131.69Z" transform="translate(0 -60.95)"/><path class="cls-22" d="M335,147.83c-2.36-5.16-5-12.51-7.93-15.39a1.74,1.74,0,0,0-1.33,1.09,4,4,0,0,0-.05,2.18c1.35,7.42,7.17,13.51,9.38,20.88,0.24,0.8.43,1.6,0.68,2.4a2.9,2.9,0,0,1,.19.94,2.59,2.59,0,0,1-.6,1.34,24.66,24.66,0,0,1-4.11,4.89,8.51,8.51,0,0,1-5.93,2.19v0a12.8,12.8,0,0,1,3.52,6.62c2.17-1.95,10.36-11.47,10.78-14.91S337.57,153.56,335,147.83Z" transform="translate(0 -60.95)"/><path class="cls-23" d="M292.09,139.46a19.7,19.7,0,0,0,1.8-4.73,50.67,50.67,0,0,0-4,7.24c-0.59-1.75.15-7.94,0.12-9.53,0,1.11-3.14,2-5.84,2.49,0,0,0,.06,0,0.09-0.12.87,0.58,2.07,0.81,2.89,0.43,1.52.75,3.08,1.13,4.62a23.65,23.65,0,0,1,1,7.91Q289.47,144.87,292.09,139.46Z" transform="translate(0 -60.95)"/><path class="cls-24" d="M301.52,137.46a0.45,0.45,0,0,0,.5.47,0.65,0.65,0,0,0,.53-0.51,0.49,0.49,0,0,0-.13-0.5,0.48,0.48,0,0,0-.57,0,1.35,1.35,0,0,0-.35.49" transform="translate(0 -60.95)"/><path class="cls-24" d="M302.84,145.78a0.52,0.52,0,0,0-.47.31,0.53,0.53,0,1,0,1,.19,0.57,0.57,0,0,0-.64-0.52" transform="translate(0 -60.95)"/><path class="cls-24" d="M303.86,166.18a0.69,0.69,0,0,0-.7.75,0.87,0.87,0,0,0,.8.73,0.32,0.32,0,0,0,.17,0,0.37,0.37,0,0,0,.13-0.15,1.16,1.16,0,0,0,.22-0.84,0.45,0.45,0,0,0-.69-0.29" transform="translate(0 -60.95)"/><path class="cls-24" d="M303.3,179.75a0.63,0.63,0,0,0-.73.51,0.61,0.61,0,0,0,.58.67,0.56,0.56,0,0,0,.51-0.69,1.08,1.08,0,0,0-.41-0.49" transform="translate(0 -60.95)"/><path class="cls-24" d="M311.88,180.12a0.48,0.48,0,0,0-.78.12,0.82,0.82,0,0,0,.2.88,0.48,0.48,0,0,0,.5.18,0.55,0.55,0,0,0,.22-0.21,1.14,1.14,0,0,0,.22-0.44,0.46,0.46,0,0,0-.15-0.45" transform="translate(0 -60.95)"/><path class="cls-24" d="M315.29,156.83a0.81,0.81,0,0,0-.15.82,0.84,0.84,0,0,0,.67.52,0.57,0.57,0,0,0,.27,0,0.58,0.58,0,0,0,.28-0.25,0.85,0.85,0,0,0,0-.89,0.77,0.77,0,0,0-.83-0.32,0.65,0.65,0,0,0-.45.72" transform="translate(0 -60.95)"/><path class="cls-24" d="M317.79,147.1a0.5,0.5,0,0,0-.73.27,0.68,0.68,0,0,0,.49.84,0.66,0.66,0,0,0,.78-0.57,0.69,0.69,0,0,0-.69-0.7" transform="translate(0 -60.95)"/><path class="cls-24" d="M319.16,137.67a0.51,0.51,0,0,0-.41.74,0.74,0.74,0,0,0,.92.26,0.58,0.58,0,0,0,.27-0.21,0.52,0.52,0,0,0-.13-0.65,0.7,0.7,0,0,0-.69-0.09" transform="translate(0 -60.95)"/><path class="cls-25" d="M307.55,119.46c-0.18,1.13-.65,1.25-1.19,1.16s-0.95-.35-0.76-1.49,0.89-2.7,1.43-2.61S307.74,118.32,307.55,119.46Z" transform="translate(0 -60.95)"/><path class="cls-26" d="M311.37,116.23a0.65,0.65,0,0,1-.34.88,0.71,0.71,0,0,1-.91-0.35,0.65,0.65,0,0,1,.34-0.88A0.71,0.71,0,0,1,311.37,116.23Z" transform="translate(0 -60.95)"/><path class="cls-26" d="M305.74,115.88a0.62,0.62,0,0,1-.33.83,0.67,0.67,0,0,1-.86-0.33,0.62,0.62,0,0,1,.33-0.83A0.67,0.67,0,0,1,305.74,115.88Z" transform="translate(0 -60.95)"/><path class="cls-26" d="M310.78,114.53a1,1,0,0,1,.3,0,1.64,1.64,0,0,1,.58.29,1.62,1.62,0,0,1,.4.51,1,1,0,0,1,.09.29,2.63,2.63,0,0,1-.25-0.15c-0.14-.09-0.31-0.23-0.48-0.35s-0.32-.28-0.44-0.4A2.84,2.84,0,0,1,310.78,114.53Z" transform="translate(0 -60.95)"/><path class="cls-26" d="M305.54,114.26l-0.22.1-0.2.08-0.22.08-0.43.12-0.23.05a0.6,0.6,0,0,1,.11-0.23,1,1,0,0,1,.44-0.31,1,1,0,0,1,.54,0A0.59,0.59,0,0,1,305.54,114.26Z" transform="translate(0 -60.95)"/><path class="cls-27" d="M312.17,126.81c1.19-1.31,1.33-2.6-.18-1.22a6,6,0,0,1-4,1.19l-0.11,2.81C309.36,131.11,311,128.12,312.17,126.81Z" transform="translate(0 -60.95)"/><polygon class="cls-28" points="307.99 65.84 307.99 65.84 307.99 65.84 307.99 65.84"/><path class="cls-20" d="M310.4,166.21a1.47,1.47,0,0,0,.83.56,0.21,0.21,0,0,0,.26-0.21,0.31,0.31,0,0,0-.09-0.14c-0.36-.39-0.75-0.73-1.12-1.11,0.23-.11.61,0.31,0.66-0.12a1.23,1.23,0,0,0-.31-0.64,2.4,2.4,0,0,0-1.14-.85C308.15,163.34,310.1,165.88,310.4,166.21Z" transform="translate(0 -60.95)"/><path class="cls-18" d="M309.81,161.46c-0.74-.9-1.34-1.92-2-2.85a7.2,7.2,0,0,0-2.59-2.31,18.62,18.62,0,0,1,3.71,4.66,0.37,0.37,0,0,1,.07.3,0.83,0.83,0,0,0-.38,0,0.37,0.37,0,0,0,.29.27c0.72,0.31,1.15,1.17,1.91,1.33,0,0-.32-0.57-0.37-0.63C310.21,162,310,161.73,309.81,161.46Z" transform="translate(0 -60.95)"/><path class="cls-18" d="M304.13,156.79a1.86,1.86,0,0,0-1.11-.54c-0.19.34,0.92,1.15,1.14,1.36s0.57,0.55.88,0.81c0.56,0.47,1.18.87,1.74,1.34a0.61,0.61,0,0,1,.3.66,2.91,2.91,0,0,1-.66.42,0.83,0.83,0,0,0,.16,1c0.21,0.44.31,0.92,0.55,1.36a3,3,0,0,1-.05-1.69c0.21-.4.85-0.45,0.81-1a2.27,2.27,0,0,0-.94-1.2l-1.33-1.21-0.75-.66A3.84,3.84,0,0,1,304.13,156.79Z" transform="translate(0 -60.95)"/><path class="cls-20" d="M311.54,168.43a2.21,2.21,0,0,1-.43-1,0.93,0.93,0,0,1,.77.15c0.23,0.15.42,0.34,0.63,0.51a0.42,0.42,0,0,0,.23.1,0.3,0.3,0,0,0,.26-0.37,1,1,0,0,0-.25-0.44,8.71,8.71,0,0,1-1.15-1.81,0.85,0.85,0,0,1,.63.28,11.61,11.61,0,0,1,1.45,1.51,2,2,0,0,1,.38.65,0.73,0.73,0,0,1-.13.71,0.89,0.89,0,0,1-.82.16,4.53,4.53,0,0,0-.85-0.17c0.15,1.09,1.42,1.62,1.66,2.69-0.5.11-.81-0.71-1-1C312.42,169.72,312,169.08,311.54,168.43Z" transform="translate(0 -60.95)"/><path class="cls-20" d="M312.69,163.9a0.27,0.27,0,0,1,0,.17,0.3,0.3,0,0,1-.31.14c-0.12,0-.28.08-0.25,0.2a0.24,0.24,0,0,0,.05.09l1.58,2a15,15,0,0,0,1.31,1.52,3.17,3.17,0,0,0-.77-1.52,15.79,15.79,0,0,1-1.35-2.19,0.13,0.13,0,0,0,.13,0,17.47,17.47,0,0,0-.9-1.9c-0.16-.28-0.74-1.58-1.09-1.53a5.5,5.5,0,0,0,.69,1.14c0.16,0.3.31,0.61,0.46,0.91A3,3,0,0,1,312.69,163.9Z" transform="translate(0 -60.95)"/><path class="cls-18" d="M304.69,156.26a0.26,0.26,0,0,1-.38-0.08,1.93,1.93,0,0,0-.25-0.37,0.73,0.73,0,0,0-.47-0.11,2,2,0,0,0-.76.09,0.45,0.45,0,0,1-.39,0,0.34,0.34,0,0,1-.12-0.27,2.66,2.66,0,0,1,0-.49,0.09,0.09,0,0,1,0-.09,0.1,0.1,0,0,1,.07,0,0.84,0.84,0,0,0,.89,0c0.33-.22,0-0.54.17-0.77s0.28,0,.36.13a10,10,0,0,1,.36.93Q304.44,155.78,304.69,156.26Z" transform="translate(0 -60.95)"/><path class="cls-18" d="M305.12,160.35a4.78,4.78,0,0,1,.65.51,0.32,0.32,0,0,0,0-.28,0.85,0.85,0,0,0-.18-0.23c-0.27-.28-1.52-1.69-1.79-2a9.5,9.5,0,0,1,1.94,1.85,1.4,1.4,0,0,0,.43.44c-1-1.55-2-2.56-3.09-3.91a2.75,2.75,0,0,0-.85-0.49c-0.06,0-.13-0.07-0.14,0a0.6,0.6,0,0,0,0,.2,4.12,4.12,0,0,0,.63,1.09A25.22,25.22,0,0,0,305.12,160.35Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M310.75,105.38s8.62,2.45,9.45,10.25c0,0,0,3.35,4.15,2.12s4.64-4.31,4.64-4.31a8.75,8.75,0,0,0,2.56-8.92c-1.43-5.74-4.71-5.14-4.71-5.14s-2.4-5.43-9-2.84a6.8,6.8,0,0,0-7.36,3.22c-2.75,4.3.68,5,.68,5Z" transform="translate(0 -60.95)"/><path class="cls-29" d="M317.82,96.53a6.8,6.8,0,0,0-7.36,3.22c-2.75,4.3.68,5,.68,5L312,103.5a3,3,0,0,1,.3-4.71A9.18,9.18,0,0,1,317.82,96.53Z" transform="translate(0 -60.95)"/><path class="cls-30" d="M331.55,104.51c-1-4.06-2.94-4.95-4-5.12a4.79,4.79,0,0,1,2.4,2.55,9.65,9.65,0,0,1,.36,4.44,5.73,5.73,0,0,1-2.3,3.37,3.82,3.82,0,0,1-4.13.12c-1.1-.83-1.27-1.65-1.39-3.43a7,7,0,0,0-1.51,3.25,10.39,10.39,0,0,0,.47,5.34l-1.25.6a2.86,2.86,0,0,0,.36,1.3c0.45,0.78,1.48,1.5,3.79.82,4.18-1.23,4.64-4.31,4.64-4.31A8.75,8.75,0,0,0,331.55,104.51Z" transform="translate(0 -60.95)"/><path class="cls-31" d="M323.68,98.83a5.83,5.83,0,0,0-1.06,1.16c-0.57.81-.05,2.26-0.13,3.25a4.59,4.59,0,0,1,4.26-4.05c-0.49-.91-3-4.94-8.87-2.68l-0.07.08a8.24,8.24,0,0,1,4.67,0,5.82,5.82,0,0,1,1.55.63,1.18,1.18,0,0,1,.82.7C324.85,98.27,324,98.61,323.68,98.83Z" transform="translate(0 -60.95)"/><path class="cls-32" d="M340.65,269c0.15-1.25.65-2-.25-1.64a7.33,7.33,0,0,1-3.88.15c-1.78-.29-2.71-1.88-4.49-2.4s-2.05,1-1.28,1.67a47.52,47.52,0,0,1-5,2.1c-2.21.72-3.39,2.2-3.39,2.58a0.56,0.56,0,0,0,.48.47H341C341.5,271.94,340.54,269.92,340.65,269Z" transform="translate(0 -60.95)"/><path class="cls-32" d="M301.48,269c0.18-1.25.69-2-.21-1.64a7.35,7.35,0,0,1-3.88.15c-1.77-.29-2.67-1.88-4.44-2.4s-2.07,1-1.32,1.67a48.66,48.66,0,0,1-5.06,2.1c-2.22.72-3.44,2.2-3.44,2.58a0.55,0.55,0,0,0,.47.47h18.19C302.27,271.94,301.35,269.92,301.48,269Z" transform="translate(0 -60.95)"/><path class="cls-33" d="M323.83,131.67a3,3,0,0,0,1.29-.6,17.66,17.66,0,0,0-7.46-2.24c0.09-.68.26-2.39-0.41-2.59-0.43-.13-2.54,2.82-4.49,5.71a2.4,2.4,0,0,0,.47-0.29c0.92-.71,1.68-1.6,3-1.46a7,7,0,0,1,2.25.92A7.91,7.91,0,0,0,323.83,131.67Z" transform="translate(0 -60.95)"/><path class="cls-34" d="M235.84,104.35a48.52,48.52,0,0,0-10.64-6.83c-1.49-.69-3.65-1.17-3.77-0.52a4.35,4.35,0,0,0,1.22,1.65,10.91,10.91,0,0,0,3.23,2.38c3.17,1.71,5.74,4.36,9,5.88l3.59,1.67a8.43,8.43,0,0,0,2.6.88h0.13a2.32,2.32,0,0,0-1-1.86C239,106.52,237.08,105.34,235.84,104.35Z" transform="translate(0 -60.95)"/><path class="cls-35" d="M228.19,125.86c1-1.6,1.7-2.13,1.7-.63a11.2,11.2,0,0,0,1.21,3.84l-1.11,2" transform="translate(0 -60.95)"/><path class="cls-36" d="M230.41,129.81s-1.85-4.93-1-6.9c0,0,4.55-.56,5.13-3s-0.5-11.75-.29-14.58-0.69-6.11-6.25-6S218,101,218.16,108s-0.93,10.89.35,11.23l0,6.72,4.3,7.13,7.69,3.67,1.9-5.29Z" transform="translate(0 -60.95)"/><path class="cls-37" d="M234.23,106.77c0-.57,0-1.06,0-1.44,0.22-2.83-.69-6.11-6.25-6a14.85,14.85,0,0,0-5.74,1,3.82,3.82,0,0,0,.18,2.88l2.4,2a10.31,10.31,0,0,1,2.59-2.27,3.49,3.49,0,0,1,3.31-.15c1.48,0.84,1.84,2.94,3.28,3.84Z" transform="translate(0 -60.95)"/><path class="cls-38" d="M229.41,122.91a12.45,12.45,0,0,1-6.14-1.25s-0.77,4.48,1.85,7.11,5,7.29,7.24,2.68l-1.95-1.64S228.56,124.88,229.41,122.91Z" transform="translate(0 -60.95)"/><path class="cls-39" d="M218.36,119.35c2.1-.69,3.51-3.33,2.85-4.55s-1.84-1.13-1.72-2.92,1.39-2.54,1.88-1.13,2.66,2.82,2.56.94-0.76-3.2.7-3.39-0.29-1.41,1.34-3.2-0.7-5.58,3.92-5.68c-6.72-1.48-10.81.91-12,5.53s-0.61,12.3-.5,13.28A1.21,1.21,0,0,0,218.36,119.35Z" transform="translate(0 -60.95)"/><path class="cls-40" d="M229.89,99.43c-4.23-.93-7.43-0.32-9.5,1.41,0.88,0.76,3.08,0,4.1.12,0.65,0.08,1.27.32,1.91,0.42,0.15,0,.3,0,0.45,0C227.09,100.34,227.73,99.48,229.89,99.43Z" transform="translate(0 -60.95)"/><path class="cls-41" d="M240.7,104.22a3.43,3.43,0,0,1,3,3.2c0.16,1.71-1.48,2.77-2.7.92S238.06,103.66,240.7,104.22Z" transform="translate(0 -60.95)"/><path class="cls-42" d="M241.57,102.88a4.87,4.87,0,0,0-.88-1.26,16.76,16.76,0,0,1-2.23-2.36,11.1,11.1,0,0,0-2-2.59,39.09,39.09,0,0,0-5.51-4.7,7.44,7.44,0,0,0-2.3-1.1c-1.71-.41-4.17,1.2-5.33,2.34A5,5,0,0,0,221.42,97c0.12-.64,2.12,0,3.61.72a48.73,48.73,0,0,1,10.64,6.83,30.72,30.72,0,0,1,4.37,3.25c0.54,0.49,1.28,1,1.15,1.66h-0.13a0.75,0.75,0,0,0,.4,0,0.81,0.81,0,0,0,.19-1,12.08,12.08,0,0,0-1.77-3.24c0.41-.34.92-0.09,1.35-0.37A1.55,1.55,0,0,0,241.57,102.88Z" transform="translate(0 -60.95)"/><path class="cls-36" d="M238.73,109.34l1.33,0.26a1.68,1.68,0,0,1,1.43,1.18c0.53,1,.65,1.9,1.63,2.56s2.68,0.46,3.73.19a12.75,12.75,0,0,1,1.42,4.09,19.44,19.44,0,0,1,5-.92c-3.63-6.39-6.95-10.1-7.94-10.36a6.4,6.4,0,0,0-3,.17,4.06,4.06,0,0,0-1.61,1.55c-0.62-.26-4.14-0.68-2.74,1A1.16,1.16,0,0,0,238.73,109.34Z" transform="translate(0 -60.95)"/><path class="cls-43" d="M262.5,139c-0.7-6.32-3.57-10.9-6.28-16.65A77.68,77.68,0,0,0,251,113a10.47,10.47,0,0,0-3.56,1.82,30,30,0,0,1,1.5,7.76c0.2,3,0,1.95.24,4.92,0.42,4.39,1.56,7.57,1.6,9.05-0.06-.13-16.43-8.21-19.7-8.63l0.21,2.54c-0.35,3.31-.13,6.65,1.81,9.36s1.76,4.61,5,5.36c0.94,0.61,4.14,1.27,4.89,1.56a27.05,27.05,0,0,0,7.37,1.66c3.39,0.27,8.38.92,10.5-1.73C262.56,144.53,262.79,141.64,262.5,139Z" transform="translate(0 -60.95)"/><path class="cls-44" d="M262.5,139c-0.7-6.32-3.57-10.9-6.28-16.65a80.51,80.51,0,0,0-4-7.5c3.42,8.87,6.63,18,6.59,27.46a2.41,2.41,0,0,1-.39,1.58c-1,1.13-6.95-1.06-8.27-1.45a53.25,53.25,0,0,1-8.44-3.28c-0.88-.43-1.75-0.89-2.59-1.4a24.54,24.54,0,0,1-3.85-2.88l-1.46,4.95q0.42,1.33.91,2.65a4.54,4.54,0,0,0,3.41,2.65c0.94,0.61,4.14,1.27,4.89,1.56a27.05,27.05,0,0,0,7.37,1.66c3.39,0.27,8.38.92,10.5-1.73C262.56,144.53,262.79,141.64,262.5,139Z" transform="translate(0 -60.95)"/><path class="cls-45" d="M237.81,136.83c5.7,14.48,7.22,23.55,6,39,0.26-.38-0.32-0.77-0.77-0.87a56.31,56.31,0,0,0-10.9-1.32c-2.5-.06-5,0.05-7.51-0.19-3.59-.35-7.94,0-11.39-1a21.49,21.49,0,0,1,.57-6.1c1.71-5.05,2.26-4.27,1.45-9.54a69,69,0,0,0-4.55-15.3c-0.65-1.62-2.16-3.93-3.82-4.48a35.35,35.35,0,0,1,5.88-5.57,34.36,34.36,0,0,1,5.33-4c0.71-.37-0.61-2.7.16-2.94,2,2.94,9.72,9.08,11.37,9,1.67-2.47.3-6.75,0.3-6.75A32.08,32.08,0,0,1,237.81,136.83Z" transform="translate(0 -60.95)"/><path class="cls-46" d="M238.26,138a1.38,1.38,0,0,0-.39-1c-0.36-.31-0.88-0.45-1.24-0.82a3.54,3.54,0,0,0-3-1.3,4,4,0,0,0-1.61.81c-2.07,1.5-4.05,3.4-4.7,5.88s0.11,4.92.47,7.37a18.4,18.4,0,0,1-.38,7.7,12.36,12.36,0,0,1-4.17,6.39c-1.66,1.28-3.67,2.05-5.26,3.42s-2.68,3.71-1.7,5.55a3.67,3.67,0,0,0,.92,1.1c2.47,0.19,5.06.11,7.35,0.33,2.49,0.24,5,.13,7.51.19a56.3,56.3,0,0,1,9,.94,13.64,13.64,0,0,0,2.61-1.17l0.28-.18C244.82,159.72,243.27,151,238.26,138Z" transform="translate(0 -60.95)"/><path class="cls-47" d="M230.38,136.15l2.14,5.42,2.14,5.57a13.09,13.09,0,0,1,.54,1.6,3.17,3.17,0,0,1-.1,1.78,9.32,9.32,0,0,0-.64,3.33,8.93,8.93,0,0,0,.61,3.32,8.74,8.74,0,0,0,.76,1.49,3.87,3.87,0,0,1,.66,1.6c0.09,1.23-.64,2.14-0.89,3.06a6.79,6.79,0,0,0-.06,2.74,14.4,14.4,0,0,1,.19,2.39,9.29,9.29,0,0,1-.23,1.83,8.07,8.07,0,0,1-.49,1.53,8.06,8.06,0,0,0,.42-1.54,9.18,9.18,0,0,0,.14-1.82,17.45,17.45,0,0,0-.28-2.35,7.05,7.05,0,0,1,0-2.86c0.25-1,.92-1.92.82-2.94a3.54,3.54,0,0,0-.62-1.43,9.15,9.15,0,0,1-.8-1.54,9.32,9.32,0,0,1-.67-3.47,9.74,9.74,0,0,1,.69-3.45c0.43-1.05,0-2.1-.41-3.13l-2-5.62Z" transform="translate(0 -60.95)"/><path class="cls-48" d="M219.08,128.68c1.73,2.88,3.34,3.9,4.93,6.86a0.51,0.51,0,0,0,.21.25,0.53,0.53,0,0,0,.57-0.37c0.57-1,1.18-.13,1.74-1.14" transform="translate(0 -60.95)"/><path class="cls-49" d="M212.83,172.18c0.3,1.1-3.18,11.81-3.38,20.61s2,22.26-.6,32.69A230.32,230.32,0,0,0,203,263.41h9.15a101.64,101.64,0,0,1,6.3-26.84c5.58-14.39,8.55-39,8.55-39-0.47,5.28,1.8,22-.6,35.08a192.08,192.08,0,0,0-3,30.74h7.92c3.21-3.82,13.31-76.56,12.71-89.85Z" transform="translate(0 -60.95)"/><path class="cls-50" d="M235.89,242.8a189.17,189.17,0,0,1-1.3-24.63c0.34-10.19,4.55-19.89,5.48-30,0.22-2.39-.28-5.52-2.63-6-1.63-.32-3.18,1-3.86,2.51a24.51,24.51,0,0,0-1.08,4.84,13.62,13.62,0,0,1-5.05,7.9L227,202.86c0.31,7.51,1.23,19.76-.62,29.81a192.08,192.08,0,0,0-3,30.74h7.92C232.33,262.19,234,253.76,235.89,242.8Z" transform="translate(0 -60.95)"/><path class="cls-51" d="M222.72,172.41a0.42,0.42,0,0,0-.56.38,0.89,0.89,0,0,0,.36.68,3.83,3.83,0,0,0,1.89.74,3.26,3.26,0,0,0,1.26,0,1.24,1.24,0,0,0,.94-0.76,0.85,0.85,0,0,0-.16-0.82,0.72,0.72,0,0,0-.79-0.19" transform="translate(0 -60.95)"/><path class="cls-52" d="M225.85,173.07c0.52-4.71,0-11-1.12-20-1.87-15.53-6-22.42-7.76-25.35-0.52.34-1.1,1-1.62,1.39,4.4,7.41,6.18,15.7,6.83,24.41s1.26,10.54.59,19.29C224.27,172.87,224.35,173,225.85,173.07Z" transform="translate(0 -60.95)"/><path class="cls-51" d="M240.62,173.22a1,1,0,0,0,.65,1.09,5.34,5.34,0,0,0,1.38.21,1.68,1.68,0,0,0,.81,0,0.72,0.72,0,0,0,.2-1.16,1.33,1.33,0,0,0-.75-0.24,17.64,17.64,0,0,0-2.24-.07" transform="translate(0 -60.95)"/><path class="cls-52" d="M243.48,173.76c0.1-4.9-1.49-11.78-2.93-21.07-2.12-13.67-5.1-20.91-6.93-24.66l-2.07-.29c4,7.71,5.93,16.34,7,25.42s3,11.55,2.44,20.52C242.19,173.7,242.29,173.73,243.48,173.76Z" transform="translate(0 -60.95)"/><path class="cls-41" d="M226.64,138.5a1.32,1.32,0,0,1,1-1.07,1.19,1.19,0,0,1,.78.51,7.37,7.37,0,0,1,1.61,3.36,1,1,0,0,1,0,.51,1,1,0,0,1-.31.38c-0.82.71-5.09,3.39-4.79,1.77A39.85,39.85,0,0,1,226.64,138.5Z" transform="translate(0 -60.95)"/><rect class="cls-53" x="226.3" y="131.66" width="6.69" height="12.89" rx="1.14" ry="1.14" transform="translate(-34.4 31.46) rotate(-21.2)"/><path class="cls-54" d="M227.86,133.08q0.57-.41,1.17-0.77a1.79,1.79,0,0,1,1.53-.37,4.91,4.91,0,0,1,.44.38l-0.24-.61a0.89,0.89,0,0,0-1.15-.51L225,133a0.89,0.89,0,0,0-.51,1.15l4,10.35a2.82,2.82,0,0,0,1.06-.64,2.3,2.3,0,0,0,.68-1.18,0.41,0.41,0,0,0,0-.31,0.51,0.51,0,0,0-.23-0.15,2.81,2.81,0,0,1-1.42-1.69,5.76,5.76,0,0,1-.21-2.24,1.88,1.88,0,0,0,0-.58,2.1,2.1,0,0,0-.63-0.87,3.44,3.44,0,0,1-.86-1.4,2,2,0,0,1,.19-1.6A3,3,0,0,1,227.86,133.08Z" transform="translate(0 -60.95)"/><path class="cls-36" d="M233,138.45a12.52,12.52,0,0,0-6.11,3.12,67.21,67.21,0,0,0-5.63,7.9,6.35,6.35,0,0,1,.8.85,42.81,42.81,0,0,0,3.36,3.93c2-7,1.06-6.55,5.69-7.08,2.35-.27,4.5.54,4.48-5.25C235.58,140,235.23,137.92,233,138.45Z" transform="translate(0 -60.95)"/><path class="cls-55" d="M235.59,141.92c0-1.7-.31-3.59-2-3.53,0,0,0,.09,0,0.13a2.13,2.13,0,0,1-1,1.6,9.24,9.24,0,0,1-1.75.84,13.3,13.3,0,0,0-5.14,3.92c-0.68.85-1.17,1.81-1.76,2.72a3.14,3.14,0,0,0-.05,3,13.82,13.82,0,0,0,1.42,2.56,4.42,4.42,0,0,0,.32.44c1.77-6.26,1-5.91,5.5-6.43C233.45,146.9,235.6,147.71,235.59,141.92Z" transform="translate(0 -60.95)"/><path class="cls-41" d="M230.36,113.65c0,1.54.63,1.79,1.37,1.77s1.32-.29,1.29-1.83-0.68-3.75-1.41-3.73S230.32,112.11,230.36,113.65Z" transform="translate(0 -60.95)"/><path class="cls-56" d="M227.6,108.91a0.66,0.66,0,0,0,.22.93,0.72,0.72,0,0,0,1-.22,0.66,0.66,0,0,0-.22-0.93A0.72,0.72,0,0,0,227.6,108.91Z" transform="translate(0 -60.95)"/><path class="cls-56" d="M233.31,109.35a0.63,0.63,0,0,0,.21.88,0.68,0.68,0,0,0,.92-0.21,0.63,0.63,0,0,0-.21-0.88A0.68,0.68,0,0,0,233.31,109.35Z" transform="translate(0 -60.95)"/><path class="cls-56" d="M228.43,107.29a2.88,2.88,0,0,1-.23.19c-0.07,0-.15.12-0.23,0.17l-0.27.17c-0.19.1-.37,0.22-0.53,0.29a2.67,2.67,0,0,1-.28.12,1,1,0,0,1,.13-0.28,1.65,1.65,0,0,1,.47-0.46,1.66,1.66,0,0,1,.63-0.21A1,1,0,0,1,228.43,107.29Z" transform="translate(0 -60.95)"/><path class="cls-56" d="M233.74,107.75a0.6,0.6,0,0,1,.24-0.09,1,1,0,0,1,.54.08,1,1,0,0,1,.4.38,0.61,0.61,0,0,1,.08.25l-0.23-.09-0.42-.18-0.21-.11c-0.07,0-.13-0.08-0.19-0.1Z" transform="translate(0 -60.95)"/><path class="cls-56" d="M228.43,116.19l0.21,0.18,0.52,0.48a4,4,0,0,0,1.63,1,1.76,1.76,0,0,0,.92,0,1.81,1.81,0,0,0,.4-0.17,2.62,2.62,0,0,0,.34-0.25,3.3,3.3,0,0,0,.46-0.5l0.16-.22a2.05,2.05,0,0,1-.31,1,1.85,1.85,0,0,1-.33.41,1.74,1.74,0,0,1-.51.34,2,2,0,0,1-1.33.07,2.68,2.68,0,0,1-1.11-.63,3.53,3.53,0,0,1-.65-0.83A5.26,5.26,0,0,1,228.43,116.19Z" transform="translate(0 -60.95)"/><path class="cls-57" d="M238,109a1.16,1.16,0,0,0,.69.31l1.33,0.26a1.68,1.68,0,0,1,1.43,1.18c0.44,0.8.69,2.15,1.69,2.46a1.83,1.83,0,0,0,1.17-.08,1.47,1.47,0,0,0,1-1.06,1.67,1.67,0,0,0-.11-0.77,3.76,3.76,0,0,1-.42-2.39c0-.22.06-0.53-0.16-0.57a0.43,0.43,0,0,0-.37.23,7.84,7.84,0,0,1-1.27,1.29,1.42,1.42,0,0,1-.67.35c-0.67.09-2.21-1.54-1.6-2.17C240,107.76,236.75,107.5,238,109Z" transform="translate(0 -60.95)"/><path class="cls-45" d="M224.44,157.44c1.3-4,1.8-6.32,2.24-7.73a14.18,14.18,0,0,0-2.93-4c-2.75,4-6.05,9.36-6.05,9.36a96.07,96.07,0,0,0-2.8-10.78,11.21,11.21,0,0,0-8-7.31c-3.45,4.44-4.1,12.53-1.23,24.67s6.58,14.38,11.1,9.53S222.31,164,224.44,157.44Z" transform="translate(0 -60.95)"/><path class="cls-58" d="M212.58,163.63c-0.81-.29-0.9-1.37-0.85-2.23,0.4-7.42.21-15.23-3.39-21.74-0.26-.48-0.48-1.19,0-1.46a1,1,0,0,1,.73,0,8.11,8.11,0,0,1,4.35,3.72,24.11,24.11,0,0,1,2.15,5.43c0.7,2.3,2.62,5.8,1.74,8.14C217,156.22,212.73,163.68,212.58,163.63Z" transform="translate(0 -60.95)"/><path class="cls-59" d="M216.72,171.19c4.53-4.87,5.58-7.22,7.71-13.75,1.3-4,1.8-6.32,2.24-7.73a14.69,14.69,0,0,0-1.31-2.15c-1.39,3.08-2.43,6.31-4,9.31-1.67,3.23-3.93,6.15-5.24,9.54-0.45,1.16-.86,2.47-1.91,3.13-2.81,1.4-5.26-1.16-6.9-3.14l-0.62-.76C209.41,174.23,212.75,175.45,216.72,171.19Z" transform="translate(0 -60.95)"/><path class="cls-51" d="M219.83,141.95c0.12-.06.22,0.1,0.25,0.23l0.39,1.51a6,6,0,0,1,2.8-1.5L223,140.81a0.26,0.26,0,0,0-.06-0.14,0.27,0.27,0,0,0-.27,0l-2.63,1" transform="translate(0 -60.95)"/><path class="cls-51" d="M235.8,140.06l0.3,1a7.07,7.07,0,0,1,2.13.33l0.11-1.47h-2.45" transform="translate(0 -60.95)"/><path class="cls-60" d="M227,197.58s0-.12,0-0.33a2,2,0,0,1,.12-0.38,2.24,2.24,0,0,1,.25-0.47,4,4,0,0,1,.91-0.93,7,7,0,0,1,1.25-.75,12.33,12.33,0,0,1,3.75-1s-0.42.26-1.07,0.59-1.53.69-2.37,1.09a9.2,9.2,0,0,0-2.16,1.29c-0.11.12-.25,0.22-0.33,0.33a1.79,1.79,0,0,0-.22.29C227.06,197.48,227,197.58,227,197.58Z" transform="translate(0 -60.95)"/><path class="cls-60" d="M235.28,173.94l0.08,0.9c0,0.28,0,.63,0,1s0,0.85,0,1.34c-0.07,1-.18,2.13-0.37,3.34s-0.44,2.5-.71,3.78-0.6,2.55-.92,3.73-0.66,2.28-.93,3.21-0.55,1.71-.72,2.26l-0.28.85s0.19-1.3.6-3.21l0.7-3.27,0.83-3.73c0.29-1.27.55-2.54,0.8-3.73s0.46-2.31.6-3.27c0.06-.48.15-0.92,0.18-1.31s0.09-.73.1-1Z" transform="translate(0 -60.95)"/><path class="cls-61" d="M214.45,175l-0.32.94c-0.19.62-.46,1.53-0.71,2.71a60.4,60.4,0,0,0-1.08,9.91c-0.08,2.06-.06,4.3,0,6.67s0.15,4.86.3,7.44,0.37,5.24.49,8-0.09,5.49-.29,8.27-0.54,5.51-.93,8.2-0.83,5.34-1.29,7.89c-0.94,5.1-1.94,9.83-2.84,13.87l-2.18,9.77c-0.26,1.18-.45,2.11-0.57,2.75l-0.19,1,0.17-1c0.11-.64.27-1.57,0.5-2.76l1.95-9.82c0.82-4.06,1.78-8.79,2.64-13.89,0.43-2.55.84-5.19,1.2-7.88s0.66-5.43.89-8.17a80.22,80.22,0,0,0,.25-8.19c-0.16-2.7-.36-5.38-0.48-8a125.58,125.58,0,0,1-.07-14.17,51.17,51.17,0,0,1,1.41-9.92c0.3-1.17.61-2.08,0.83-2.68Z" transform="translate(0 -60.95)"/><path class="cls-61" d="M230.33,197.06l-0.07.74c-0.05.48-.12,1.19-0.17,2.09s-0.09,2-.08,3.25,0,2.67.1,4.21c0.12,3.09.46,6.68,0.59,10.56,0.07,1.94.09,3.95,0,6s-0.32,4.09-.6,6.16c-0.63,4.09-1.52,8.13-2.3,11.92-0.38,1.89-.78,3.72-1.09,5.46s-0.6,3.39-.78,4.92c-0.11.76-.18,1.5-0.25,2.2s-0.15,1.36-.17,2c-0.1,1.25-.1,2.34-0.1,3.25s0.07,1.61.08,2.09l0,0.74-0.07-.74c0-.48-0.15-1.19-0.17-2.09s-0.08-2,0-3.26c0-.63,0-1.3.09-2s0.1-1.45.19-2.22c0.15-1.54.38-3.21,0.67-5s0.61-3.6,1-5.5c0.75-3.8,1.6-7.83,2.2-11.9,0.28-2,.55-4.09.64-6.09s0.1-4,0-5.93c-0.12-3.86-.31-7.46-0.37-10.56,0-1.55,0-3,0-4.23s0.13-2.35.23-3.25,0.18-1.6.26-2.08Z" transform="translate(0 -60.95)"/><path class="cls-62" d="M233.17,175a0.22,0.22,0,0,1,.13,0,0.13,0.13,0,0,1,.07.09,2.8,2.8,0,0,1,0,2.09,0.68,0.68,0,0,1-.69.51,0.6,0.6,0,0,1-.32-0.2,1.22,1.22,0,0,1-.18-1.41A1.79,1.79,0,0,1,233.17,175Z" transform="translate(0 -60.95)"/><path class="cls-61" d="M219.8,176a2.84,2.84,0,0,1-.15,1.18,3.44,3.44,0,0,1-.6,1.1,3.67,3.67,0,0,1-.5.51,4.9,4.9,0,0,1-.61.42,5.92,5.92,0,0,1-2.52.68,8.4,8.4,0,0,1-1.17,0l0.3-.12,0.79-.27a12.54,12.54,0,0,0,2.24-.9,4.23,4.23,0,0,0,.52-0.33,5.11,5.11,0,0,0,.47-0.39,5.06,5.06,0,0,0,.7-0.85,5,5,0,0,0,.4-0.71Z" transform="translate(0 -60.95)"/><path class="cls-63" d="M228,133.77a1.15,1.15,0,0,0,.42,2.24,0.06,0.06,0,0,0,.06-0.08l-0.07-.18a0.29,0.29,0,0,1-.42,0,0.31,0.31,0,0,0-.18-0.12c-0.12,0,0-.07,0-0.07a0.24,0.24,0,0,1,.21.05,0.25,0.25,0,0,0,.35,0,0.25,0.25,0,0,1,0-.17,0.51,0.51,0,0,1-.69-0.36,0.45,0.45,0,0,1,0-.33,0.41,0.41,0,0,1-.09-0.29,0.43,0.43,0,0,1,.34,0,1.09,1.09,0,0,1,.54-0.2,0.43,0.43,0,0,1,.26-0.22,0.41,0.41,0,0,1,.11.28,0.45,0.45,0,0,1,.22.25,0.51,0.51,0,0,1-.3.71,0.28,0.28,0,0,1,.15.17l0.11,0.3a0.06,0.06,0,0,0,.09,0A1.15,1.15,0,0,0,228,133.77Z" transform="translate(0 -60.95)"/><path class="cls-64" d="M223.4,263.41l-0.61,7.47a1,1,0,0,0,1,1.06h12.65a0.58,0.58,0,0,0,.48-0.91c-0.81-1.2-2.48-3.13-4.68-3l-0.91-4.63H223.4Z" transform="translate(0 -60.95)"/><path class="cls-64" d="M202.95,263.41l-0.61,7.47a1,1,0,0,0,1,1.06h13.93a0.58,0.58,0,0,0,.48-0.91c-0.81-1.2-2.48-3.13-4.68-3l-0.91-4.63h-9.2Z" transform="translate(0 -60.95)"/><path class="cls-65" d="M233.81,148.57a0.61,0.61,0,0,0-.63-0.51,1.29,1.29,0,0,0,.83,1.25,0.89,0.89,0,0,0-.15-0.81" transform="translate(0 -60.95)"/><path class="cls-65" d="M234.92,160.15a1.62,1.62,0,0,0-.66-0.62,1,1,0,0,0,1.11,1.23,1.15,1.15,0,0,0-.79-1.08" transform="translate(0 -60.95)"/><path class="cls-65" d="M233,154.33a1.1,1.1,0,0,0,0,1.07,0.21,0.21,0,0,0,.1.1,0.22,0.22,0,0,0,.23-0.19,1.49,1.49,0,0,0-.13-1.23l-0.16.27" transform="translate(0 -60.95)"/><path class="cls-65" d="M234.26,167.22a1.27,1.27,0,0,0,.52,1.59,1.49,1.49,0,0,0-.36-1.59" transform="translate(0 -60.95)"/><path class="cls-66" d="M232.11,96.17l-1.66-.81a2.46,2.46,0,0,0-1.31-.36,0.85,0.85,0,0,0-.8.92,1.24,1.24,0,0,0,.53.63c2.09,1.58,4.18,3.16,6.36,4.61a18,18,0,0,1,2.07,1.51c0.9,0.8,1.63,2.14,2.72,2.7l-0.14-.21c0.41-.34.92-0.09,1.35-0.37a1.55,1.55,0,0,0,.34-1.93,4.87,4.87,0,0,0-.88-1.26,16.75,16.75,0,0,1-2.23-2.36,11.43,11.43,0,0,0-1-1.47,18.26,18.26,0,0,1-3.77-.91C233.15,96.67,232.63,96.42,232.11,96.17Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M217.06,262s0.77-.14,1.55-0.26a5.18,5.18,0,0,1,1.07-.11,2,2,0,0,1,.37,0,0.22,0.22,0,0,1,.13.08l0,0a0.17,0.17,0,0,0-.12,0l-0.34.09a5.18,5.18,0,0,1-1.07.12c-0.78,0-1.57.07-1.57,0.07v0Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M217.42,264.95a0.13,0.13,0,0,1,0-.12,1.13,1.13,0,0,1,.26-0.15l0.81-.39a3.58,3.58,0,0,1,.83-0.33,2.24,2.24,0,0,1,.41-0.06v0a2.23,2.23,0,0,1-.34.24,3.58,3.58,0,0,1-.83.33l-0.86.27a1.12,1.12,0,0,0-.27.1,0.09,0.09,0,0,0,0,.08h0Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M221.17,265a4,4,0,0,0-.81,1.21c-0.13.34-.22,0.68-0.3,0.94l-0.14.44h0a1.57,1.57,0,0,1,0-.48,2.18,2.18,0,0,1,.32-1,3.56,3.56,0,0,1,1-1.14Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M198.57,262.37a9.63,9.63,0,0,0,1.55-.1c0.38-.07.75-0.15,1-0.18s0.49,0,.49,0v0a2.23,2.23,0,0,1-.45.22,3.22,3.22,0,0,1-1.07.18,7.22,7.22,0,0,1-1.57-.09v0Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M199,265.27a5.69,5.69,0,0,0,1.32-.47c0.31-.17.59-0.35,0.83-0.47s0.41-.19.41-0.19l0,0a1.69,1.69,0,0,1-.3.35,2.39,2.39,0,0,1-.87.49,4.63,4.63,0,0,1-1.41.29v0Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M200.69,267.4a0.6,0.6,0,0,1,.11-0.47,6.75,6.75,0,0,1,.68-0.8,3.58,3.58,0,0,1,.79-0.68,2.34,2.34,0,0,1,.43-0.21l0,0a3.9,3.9,0,0,1-.31.36,7.33,7.33,0,0,1-.78.67,9.43,9.43,0,0,0-.76.69,0.55,0.55,0,0,0-.16.41h0Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M193.22,265.29l0.17-.06a1.22,1.22,0,0,1,.48,0,1.88,1.88,0,0,1,1.26.72,2.45,2.45,0,0,1,.39.68,2.88,2.88,0,0,1,.17.66,3.73,3.73,0,0,1,0,.65h0s-0.1-.24-0.23-0.61a6,6,0,0,0-.53-1.26,1.8,1.8,0,0,0-1.09-.75,1.08,1.08,0,0,0-.62,0v0Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M212.74,265.18a2.55,2.55,0,0,1,.62.07,2.28,2.28,0,0,1,1.2.69,1.56,1.56,0,0,1,.37.68,3.39,3.39,0,0,1,.08.64,2.63,2.63,0,0,0,.09.6h0a1.34,1.34,0,0,1-.28-0.57,3.29,3.29,0,0,0-.41-1.22,2.25,2.25,0,0,0-1.06-.74,2.52,2.52,0,0,0-.6-0.14v0Z" transform="translate(0 -60.95)"/><path class="cls-68" d="M131.8,180.11c-1-.36-0.64-4.8,0-4.71a3.52,3.52,0,0,0,3.19,1c2.07-.32,8.06-5,7.1-10.77s-5-11.65-8.94-10.61-5.19,5.11-7.1,6.22-4.51,4.25-3.11,7.58a11,11,0,0,0,2.23,3.51l-2,5.75,2.15,10.13,7.74,6.62,0.8-7.74Z" transform="translate(0 -60.95)"/><path class="cls-69" d="M132.42,172.77c-1-.63-0.94,1.68-0.62,2.63s3,2.47,6.06.88,5.19-3.51,5.82-5.11c0,0,0,2.19-1.2,3.17s-4,7.84-.3,13.58a5.87,5.87,0,0,1,1.81-4.79c2.23-2.23,7.18-3.35,7.82-8.78s-3-7.66-4.63-8l-1.52-2.55s0.84-2.39-3.33-6.38-8.8-3.75-9.2-2.39,2.47,4.55,4.39,4.95,1.44,1.6.32,1.52-3.35.48-2.87,3,1.2,2.71.16,2.87-1.6,1.92-.32,2.15,3.35,0.48,2.47,2.07A3.18,3.18,0,0,1,132.42,172.77Z" transform="translate(0 -60.95)"/><path class="cls-70" d="M143.69,171.18a17.32,17.32,0,0,0,2-7.34c0-1.43,1.47,1,1.52,2.55C147.3,169.66,145.28,171.26,143.69,171.18Z" transform="translate(0 -60.95)"/><path class="cls-71" d="M144.25,159.59a16.27,16.27,0,0,0-1.9-2.13,14.38,14.38,0,0,1-4.92,13.1,1.1,1.1,0,0,1-.13,1l-0.12.2C145.51,169.9,144.26,159.65,144.25,159.59Z" transform="translate(0 -60.95)"/><path class="cls-70" d="M115.36,206.69c-1.76-7.42.16-21.94,0.16-21.94l-0.72-.48a22.9,22.9,0,0,1,3.27-2.63c1.84-1.2,1.52-4.55,2-4s1.84,0.32,3.11.48a12.82,12.82,0,0,1,4.71,6.54c1.52,4.55,3.4,2.31,3.82,1s0.09-5.51.09-5.51a3.1,3.1,0,0,1,2.31,2.23c0.64,2,.24,7.92-0.4,10.22s-0.41,11.49-.18,14.13H115.36Z" transform="translate(0 -60.95)"/><path class="cls-72" d="M131.8,180.11s0.32,4.15-.09,5.51-2.3,3.59-3.82-1a13.93,13.93,0,0,0-1.12-2.5c-0.75,0-1.41-.78-2.14-0.59a1.42,1.42,0,0,0-.74.61,6.56,6.56,0,0,0-1.05,3.85,19.54,19.54,0,0,0,.6,4l3.68,16.66h6.43c-0.23-2.64-.46-11.82.18-14.13s1-8.23.4-10.22A3.1,3.1,0,0,0,131.8,180.11Z" transform="translate(0 -60.95)"/><path class="cls-73" d="M116.22,266.94c-1.43-.18-3.63,0-5-0.6,1.37-2.66,2.35-6.12,3.73-8.73,1.28-2.41,2.12-7.31,5.4-11.09a23.93,23.93,0,0,1,3.24-3s-0.91-3-1.22-3.93a34.94,34.94,0,0,1-1.44-13.2c0.05-.74-0.08-2.3.49-2.86s1.73-.54,2.35-0.7a26.05,26.05,0,0,1,7.19-1,0.88,0.88,0,0,1,.79.32,0.74,0.74,0,0,1,0,.41c-0.3,3.41-.95,6.68-1,10.18,0.09,2.9-.1,5.85-0.14,8.8a15.3,15.3,0,0,1-1.81,7.8C128.24,250.46,117.58,264.83,116.22,266.94Z" transform="translate(0 -60.95)"/><path class="cls-74" d="M131.34,224.54a11.13,11.13,0,0,0-2.07-2.63,30.27,30.27,0,0,0-5.47,1c-0.63.16-1.88,0.23-2.35,0.7s-0.43,2.12-.49,2.86a37,37,0,0,0,.41,8.91,1.86,1.86,0,0,1,.87-0.73,3.62,3.62,0,0,1,3.25.6,6.78,6.78,0,0,1,2.27,4.67,14.2,14.2,0,0,1-1.39,8.07c-1.2,2.4-3.1,4.48-3.8,7.07a5.68,5.68,0,0,0,0,3.16c3-4.12,6-8.22,6.33-8.77a15.3,15.3,0,0,0,1.81-7.8c0-2.95.24-5.9,0.14-8.8a72.52,72.52,0,0,1,.75-7.76C131.5,224.86,131.42,224.7,131.34,224.54Z" transform="translate(0 -60.95)"/><path class="cls-75" d="M118.72,221.07a17.26,17.26,0,0,1,1.19,4.46l3.33,0-0.55-4.47Z" transform="translate(0 -60.95)"/><polygon class="cls-76" points="119.92 164.35 119.94 165.7 124.43 165.63 124.27 163.97 119.92 164.35"/><path class="cls-68" d="M139.6,230.19c1.06,1.82,1.82,3.65,2.8,5.54,1.92,3.71,2.54,7.74,2.93,11.84,0.35,3.65.86,7.43,1.1,11.16a19.06,19.06,0,0,0,1.07,4.91c0.13,0.42,1.44,3.79,1.13,3.84a59.65,59.65,0,0,0-6.13,1.16c-1.34-3.78-1.17-6.89-2.4-10.22a46.09,46.09,0,0,1-2.42-8c-0.46-2.68-1.44-6.71-1.05-9.2-5.76-3.34-10.26-10.15-14.15-16.28,0.78-.65,2.45-0.86,3.23-1.51,1.77-1.48,3.65-2.82,5.43-4.26,0.52-.42.58-0.7,1.13-0.28,1.45,1.08,2,2.79,2.77,4.3C136.14,225.3,138.7,228.65,139.6,230.19Z" transform="translate(0 -60.95)"/><path class="cls-77" d="M144.47,261.14a3.33,3.33,0,0,0,2.51.78,14.42,14.42,0,0,1-.56-3.19c-0.24-3.73-.75-7.5-1.1-11.16-0.39-4.1-1-8.13-2.93-11.84-1-1.89-1.74-3.72-2.8-5.54-0.9-1.54-3.46-4.89-4.57-7-0.74-1.42-1.26-3-2.52-4.09a18.72,18.72,0,0,0-2.82,1.19c-1.34,1-2.69,2.06-4,3.14a2.78,2.78,0,0,1-.61.36,7.49,7.49,0,0,0-1.45,3l0.83,1.28a3.65,3.65,0,0,0,1.44-.36c0.19-.1,1.91-1.72,1.64-1.81a4.25,4.25,0,0,0,3.37-.35c0.87-.5,1.82-1.33,2.71-0.88a2.21,2.21,0,0,1,.77.81,78.32,78.32,0,0,1,4.65,8,14.22,14.22,0,0,1,1.39,3.58,16.13,16.13,0,0,1,.21,3q0,2.91.11,5.81c0.13,4.16.37,8.4,1.84,12.3A7,7,0,0,0,144.47,261.14Z" transform="translate(0 -60.95)"/><path class="cls-71" d="M115.2,208c0.49,2.05,0,4-.21,6.84a10.48,10.48,0,0,0,4.82,9c3.36,2,3.39,3.68,3.39,3.68l2.18-1.14,0.58-2.86,3,0.65,5.13-3.27-1.14-2a11.4,11.4,0,0,1,.06-5.15,11.17,11.17,0,0,0,.13-5.82C132.88,206,115.2,208,115.2,208Z" transform="translate(0 -60.95)"/><path class="cls-78" d="M133.05,213.75a11.18,11.18,0,0,0,.13-5.82c-0.07-.42-1.23-0.64-2.58-0.74-0.13,0-1.69-.51-1.81-0.49-2.72.54-1.6,1.65-.79,4.49s5,7.72,5,7.72A11.4,11.4,0,0,1,133.05,213.75Z" transform="translate(0 -60.95)"/><polygon class="cls-79" points="133.5 147.34 115.18 147.34 115.18 145.34 133.6 145.35 133.5 147.34"/><path class="cls-68" d="M92.14,150l22.66,34.22,4.53-3.42,0.74-3.2c-1.2-2.33-7.49-7-10.7-13-3.91-7.29-15.13-16.05-15.13-16.05-0.88-.57-0.07-1.26-0.52-2S90.8,148,90.8,148a1.11,1.11,0,0,0,0,1.5C91.52,150.1,91.69,149.37,92.14,150Z" transform="translate(0 -60.95)"/><path class="cls-80" d="M120.07,177.64c-1.2-2.33-7.49-7-10.7-13-2-3.64-5.72-7.65-9-10.75a20.43,20.43,0,0,0-1.87-1.05,1,1,0,0,0-1-.11,1,1,0,0,0-.23,1.07,12.65,12.65,0,0,0,2.15,4.08c1.32,1.86,1.94,4.06,3.39,5.82a25.12,25.12,0,0,0,2.51,2.72c0.8,0.72,1.68,1.35,2.45,2.11a18.73,18.73,0,0,1,2.59,3.49q3,4.86,5.61,10l0.52,1,2.84-2.15Z" transform="translate(0 -60.95)"/><path class="cls-79" d="M114.32,183.88l1.2,0.86a7.66,7.66,0,0,0,3.84-3c1.73-2.45,1.13-4.16,1.13-4.16l-1-.64a6.58,6.58,0,0,1-1.7,4.2A10.22,10.22,0,0,1,114.32,183.88Z" transform="translate(0 -60.95)"/><path class="cls-79" d="M122.65,178.07a19.92,19.92,0,0,1,4.88,7.18c1.31,3.94,3.3,3.19,3.95,1.64s0.91-3.23.58-6.72l-0.46-.2s0.63,4.77-.51,6.44-2.23.42-2.75-1.2a12.87,12.87,0,0,0-5.16-7.1Z" transform="translate(0 -60.95)"/><polygon class="cls-79" points="122.98 166.05 123.33 167.06 125.68 165.79 126.18 162.96 129.18 163.69 134.31 160.31 133.88 159.51 129.15 162.61 126.08 162 117.75 149.52 116.69 150.14 125.23 162.53 124.97 165.04 122.98 166.05"/><path class="cls-79" d="M123,187.67a6.55,6.55,0,0,0,.55,2.07,1.07,1.07,0,0,0,.92.85,1,1,0,0,0,.68-0.71c0.4-1,1.11-3,.33-4C124.28,184.31,123,186.42,123,187.67Z" transform="translate(0 -60.95)"/><path class="cls-81" d="M130.88,211a0.43,0.43,0,0,0,.15.4,0.3,0.3,0,0,0,.34-0.08,0.87,0.87,0,0,0,.17-0.32c0.12-.32.23-0.64,0.33-1a2.11,2.11,0,0,0-.09-1.93,6.77,6.77,0,0,0,2.49,2.87,0.42,0.42,0,0,0,.48.06,0.36,0.36,0,0,0,.1-0.23,1.94,1.94,0,0,0-.27-1.13c-0.4-.75-1.59-2.08-2.59-1.79S130.88,210.18,130.88,211Z" transform="translate(0 -60.95)"/><path class="cls-82" d="M119.5,188a5.91,5.91,0,0,1-3-1.17,3.89,3.89,0,0,1-1-2.13c-0.32,2.73-1.36,12.62-.63,19.14a61.33,61.33,0,0,0,1.22-6.15A39.81,39.81,0,0,1,119.5,188Z" transform="translate(0 -60.95)"/><path class="cls-83" d="M142.5,268.63a59.66,59.66,0,0,1,6.13-1.16c0.32,0-1-3.42-1.13-3.84a19.06,19.06,0,0,1-1.07-4.91c-0.23-3.73-.75-7.5-1.1-11.16l0-.23-7.92,1.59c0.11,0.52.21,1,.29,1.47a46.11,46.11,0,0,0,2.42,8C141.32,261.74,141.15,264.85,142.5,268.63Z" transform="translate(0 -60.95)"/><path class="cls-84" d="M147.5,263.63a19.06,19.06,0,0,1-1.07-4.91c-0.23-3.73-.75-7.5-1.1-11.16l0-.23-4.78,1c0,2.48,1.2,5,2,7.42,1.21,3.75,1.55,7.71,2.44,11.55q0.09,0.39.19,0.78c1.32-.25,2.73-0.48,3.49-0.58C148.94,267.43,147.62,264,147.5,263.63Z" transform="translate(0 -60.95)"/><path class="cls-85" d="M141.15,265.86a12.93,12.93,0,0,1,1.07,4.19,1,1,0,0,0,1,1,53.77,53.77,0,0,0,12.08-2.77c0.5-.16.9-0.24,0.66-0.8a3.07,3.07,0,0,0-1.5-1.51,5.88,5.88,0,0,0-1.6-.11l-3,.07a1.06,1.06,0,0,1-.06-1,4,4,0,0,0,.08-1.31,1.34,1.34,0,0,0-.68-1.17,0.85,0.85,0,0,0-.92.31,3.15,3.15,0,0,0-.44.95,8.63,8.63,0,0,1-1.35,2.45,1.44,1.44,0,0,1-.57.49,1.57,1.57,0,0,1-.91,0C143.72,266.34,142.35,265.46,141.15,265.86Z" transform="translate(0 -60.95)"/><path class="cls-86" d="M146.95,268.77a5.7,5.7,0,0,0,3.94-1.12,3.69,3.69,0,0,1,.69-0.47c0.37-.16.79-0.16,1.16-0.34a1.33,1.33,0,0,0,.72-1h-0.62l-3,.07a1.06,1.06,0,0,1-.06-1,4,4,0,0,0,.08-1.31,2.34,2.34,0,0,0,0-.25,1.56,1.56,0,0,0-.29.25c-0.64.71-.54,1.92-1.09,2.74S147.07,267.77,146.95,268.77Z" transform="translate(0 -60.95)"/><path class="cls-83" d="M142.55,271.85a1,1,0,0,0,.71,0,82.35,82.35,0,0,0,13-3.33,1.75,1.75,0,0,0-.48-1.37c-0.28-.13-6.11,1.94-9.33,2.25a20.68,20.68,0,0,0-3.7.43c-0.51.15-.66,0-0.67,0.5A2.36,2.36,0,0,0,142.55,271.85Z" transform="translate(0 -60.95)"/><path class="cls-83" d="M115,257.61c-1.38,2.61-2.36,6.07-3.73,8.73,1.33,0.59,3.53.42,5,.6,0.9-1.41,6-8.31,9.41-13L122,250.74c-1-.85-1.93-1.69-2.91-2.49C116.86,251.69,116.08,255.56,115,257.61Z" transform="translate(0 -60.95)"/><path class="cls-87" d="M121.49,255.05q-3.46,5.8-6.57,11.8c0.47,0,.92,0,1.31.09,0.9-1.41,6-8.31,9.41-13L123.46,252A28.13,28.13,0,0,0,121.49,255.05Z" transform="translate(0 -60.95)"/><path class="cls-88" d="M123.43,254.68q-1.54-1.62-3.19-3.13-0.82-.75-1.66-1.48c-0.1-.09-0.22-0.21-0.35-0.34-0.12.23-.23,0.46-0.35,0.69l5.42,5.07c0.23,0.22.46,0.44,0.68,0.67l0.36-.49C124,255.34,123.74,255,123.43,254.68Z" transform="translate(0 -60.95)"/><path class="cls-89" d="M122.5,256.38q-1.54-1.62-3.19-3.13-0.82-.75-1.66-1.48l-0.26-.25c-0.1.24-.21,0.48-0.31,0.72l5.29,5,0.51,0.49,0.36-.49C123,256.92,122.75,256.64,122.5,256.38Z" transform="translate(0 -60.95)"/><path class="cls-88" d="M144.9,249.81l0.64-.14-0.06-.59-1.19.17q-2.21.36-4.39,0.86-1.08.25-2.15,0.53h0c0,0.24.1,0.48,0.15,0.72Z" transform="translate(0 -60.95)"/><path class="cls-89" d="M145.75,251.55l-0.07-.64-0.51.07q-2.21.36-4.39,0.86-1.08.25-2.15,0.53l-0.5.1c0.06,0.24.14,0.48,0.21,0.71Z" transform="translate(0 -60.95)"/><path class="cls-85" d="M111.23,264.9a11.6,11.6,0,0,1-1.08,3.8,0.69,0.69,0,0,0,.37,1.06,55.32,55.32,0,0,0,11.87.67c0.51,0,.91,0,1-0.52a2,2,0,0,0-.58-1.65,4.87,4.87,0,0,0-1.34-.49l-2.63-.68a1.08,1.08,0,0,1,.41-0.83,4.51,4.51,0,0,0,.7-1.09,1,1,0,0,0,0-1.16,0.92,0.92,0,0,0-1,0,4.17,4.17,0,0,0-.84.69,11.59,11.59,0,0,1-2.36,1.74,1.89,1.89,0,0,1-.74.28,1.34,1.34,0,0,1-.78-0.24C113.23,265.93,112.47,264.85,111.23,264.9Z" transform="translate(0 -60.95)"/><path class="cls-90" d="M122.39,270.42c0.51,0,.91,0,1-0.52a2,2,0,0,0-.58-1.65,4.88,4.88,0,0,0-1.34-.49l-2.63-.68a1.08,1.08,0,0,1,.41-0.83,4.51,4.51,0,0,0,.7-1.09,2,2,0,0,0,.15-0.5l0,0L117.27,267a5.76,5.76,0,0,1-1,.78,8.28,8.28,0,0,1-1.54.52,9.46,9.46,0,0,0-1.46.57,0.73,0.73,0,0,0-.32.25,0.52,0.52,0,0,0,.16.63,1.51,1.51,0,0,0,.65.26l1.4,0.31C117.54,270.49,120.08,270.47,122.39,270.42Z" transform="translate(0 -60.95)"/><path class="cls-83" d="M109.5,270.3a0.84,0.84,0,0,0,.6.21,93.11,93.11,0,0,0,13.1.55,1.31,1.31,0,0,0,.24-1.22c-0.19-.17-6.36,0-9.35-0.5a21.12,21.12,0,0,0-3.46-.56c-0.52,0-.56-0.19-0.83.23A1.81,1.81,0,0,0,109.5,270.3Z" transform="translate(0 -60.95)"/><path class="cls-91" d="M118.82,267.09c-0.14.24-.25,0.59-0.35,0.8a1.1,1.1,0,0,0-.13.43,0.28,0.28,0,0,0,0,.16,0.32,0.32,0,0,0,.15.11,1.09,1.09,0,0,0,.43.09,3.2,3.2,0,0,1,.59-1.4Z" transform="translate(0 -60.95)"/><path class="cls-91" d="M149.54,267.73a0.17,0.17,0,0,0,.1,0l0.65,0h0l0,0a12.43,12.43,0,0,0,.5-1.8l-1,0C149.62,266.28,149.29,267.56,149.54,267.73Z" transform="translate(0 -60.95)"/><path class="cls-92" d="M128.52,163.49c-0.91.75-1.35,0.52-1.7,0.09s-0.49-.91.42-1.66,2.51-1.47,2.86-1S129.42,162.74,128.52,163.49Z" transform="translate(0 -60.95)"/><path class="cls-92" d="M132.49,163.62a0.63,0.63,0,0,1-.81.42,0.68,0.68,0,0,1-.44-0.83,0.63,0.63,0,0,1,.81-0.42A0.68,0.68,0,0,1,132.49,163.62Z" transform="translate(0 -60.95)"/><path class="cls-92" d="M129,160.06a0.52,0.52,0,0,1-.67.35,0.57,0.57,0,0,1-.37-0.69,0.52,0.52,0,0,1,.67-0.34A0.57,0.57,0,0,1,129,160.06Z" transform="translate(0 -60.95)"/><path class="cls-92" d="M133.14,162a0.94,0.94,0,0,1,.2.22,1.58,1.58,0,0,1,.24.58,1.56,1.56,0,0,1,0,.63,0.94,0.94,0,0,1-.12.27,2.54,2.54,0,0,1-.09-0.27c0-.16-0.07-0.36-0.12-0.56s-0.06-.41-0.07-0.57A2.74,2.74,0,0,1,133.14,162Z" transform="translate(0 -60.95)"/><path class="cls-92" d="M129.72,158.92l-0.19-.06-0.35-.14a5.37,5.37,0,0,1-.52-0.26,0.51,0.51,0,0,1,.2-0.09,0.81,0.81,0,0,1,.45,0,0.82,0.82,0,0,1,.34.3A0.5,0.5,0,0,1,129.72,158.92Z" transform="translate(0 -60.95)"/><path class="cls-93" d="M124.16,164.61c-0.64,1.79-.07,4.47,2.29,4.9s3.15-1.84,2.09-2.72c-1.69-1.41-2.95-2.36-3.06-3.29S124.59,163.41,124.16,164.61Z" transform="translate(0 -60.95)"/><path class="cls-94" d="M129.32,165.16a0.36,0.36,0,0,0-.09.22,2.69,2.69,0,0,0,.51,1.65,5.81,5.81,0,0,0,1,1.29,2.5,2.5,0,0,0,1.42.7,0.93,0.93,0,0,0,.74-0.19c0.69-.66-0.31-2.15-0.82-2.65S129.86,164.65,129.32,165.16Z" transform="translate(0 -60.95)"/><path class="cls-94" d="M126.71,161.66a0.23,0.23,0,0,0,.05-0.1,0.9,0.9,0,0,0-.09-0.66,1.5,1.5,0,0,0-.32-0.48,0.79,0.79,0,0,0-.59-0.21,0.59,0.59,0,0,0-.36.14,0.83,0.83,0,0,0,.17,1.13A1.12,1.12,0,0,0,126.71,161.66Z" transform="translate(0 -60.95)"/><path class="cls-95" d="M143.61,211.43c-0.18,3.06,2.36,5.22,5.79,4.14s-3.37-5.81-3.37-5.81Z" transform="translate(0 -60.95)"/><path class="cls-96" d="M176.47,241.59a3.23,3.23,0,0,1-1.36-.59,3,3,0,0,1-.57-0.76,29.17,29.17,0,0,1-2.43-5.37,4,4,0,0,1-.28-1.38,4.44,4.44,0,0,1,.61-1.8,73.37,73.37,0,0,0,3.94-9.43c1-3,2-6.29,4.77-7.83a8.85,8.85,0,0,1,3.88-1,7.72,7.72,0,0,1,3.68.53,9.93,9.93,0,0,1,3.17,2.78c3.52,4.13,7.17,8.48,8.33,13.78s0,11.49-2.06,16.32c-0.9,2.14-2.57,1.48-4.35.74-2.66-1.11-5.32-2.2-8-3.15Q181.18,242.83,176.47,241.59Z" transform="translate(0 -60.95)"/><path class="cls-97" d="M159.89,254.58a4.39,4.39,0,0,1-4,3.41c-0.95,0-2-.21-2.79.3a2.9,2.9,0,0,0-.72.72,10.89,10.89,0,0,0-1.14,1.85,2.58,2.58,0,0,0-.31,1.06c0,1,1.25.55,2,.83a0.43,0.43,0,0,0,.59-0.27,4.92,4.92,0,0,1,1-1.24,1.51,1.51,0,0,1,2-.5c1.21,1,2.83.42,4-.76a7.62,7.62,0,0,0,2.1-4.37" transform="translate(0 -60.95)"/><path class="cls-98" d="M165,220.51s-0.86,7.08-.43,10.73-2.16,4.22-2.58,9.62-1.17,11.36-2.89,14.33l3.43,1s2.12,1.3,4.76-7.93,5.16-25.73,5.16-25.73l-0.6-2.05H165Z" transform="translate(0 -60.95)"/><path class="cls-99" d="M171.84,220.51H165s-0.17,1.38-.32,3.22a8.91,8.91,0,0,1,1.53.91c2,1.6,2.12,5.09,2,7.43a5.62,5.62,0,0,1-.75,3,22.19,22.19,0,0,1-2.22,2.1,8.48,8.48,0,0,0-1.6,3.27c-0.82,2.59-2.06,5.5-2.3,8.21a5.51,5.51,0,0,1-.79,2.42,15.86,15.86,0,0,1-1.48,4.08l3.43,1s2.12,1.3,4.76-7.93,5.16-25.73,5.16-25.73Z" transform="translate(0 -60.95)"/><path class="cls-96" d="M165.77,210.93c-0.41,2.91-1.06,8.37-2.36,11,2.81,0.39,4.45.44,7.26,0.83a5.36,5.36,0,0,1,1.41.32,2.58,2.58,0,0,0,1.54.47l0.21-5.36a26.27,26.27,0,0,1,.43-4.41,12.14,12.14,0,0,0,.61-4.15,0.43,0.43,0,0,0-.3.28" transform="translate(0 -60.95)"/><path class="cls-100" d="M174.71,211.84l-0.09-.13a2.21,2.21,0,0,0-1.87-.85,2.58,2.58,0,0,0-1.11.47,9.06,9.06,0,0,0-2.32,2.51,23.3,23.3,0,0,0-2.46,4.73c-0.47,1.22-.87,2.44-1.43,3.6,1.74,0.19,3.17.29,5.24,0.58a5.36,5.36,0,0,1,1.41.32,2.57,2.57,0,0,0,1.54.47l0.21-5.36a26.27,26.27,0,0,1,.43-4.41C174.39,213.14,174.57,212.49,174.71,211.84Z" transform="translate(0 -60.95)"/><path class="cls-101" d="M174.11,264c0,1.23-1,1.8-2.87,2.59s-4.78,2.87-5.91,3.15,2,1,4.9,1,6.59,0.73,8.27,0,2.82-1.49,2.25-3.21-1.18-2.36-1.07-3.32S174.11,264,174.11,264Z" transform="translate(0 -60.95)"/><path class="cls-102" d="M168,268.37c-1.52.09-4.17,0.54-5.07,1.55s-1.35,2,1.18,2H178.5a2.88,2.88,0,0,0,2.95-2c0.38-1-.13-2.81-0.69-2.36s-0.45,1.29-1.86,1.46-9.27.54-10.86,0.39S168,268.37,168,268.37Z" transform="translate(0 -60.95)"/><path class="cls-103" d="M196.57,242c-5.67-3.12-11.93-5-18.14-6.8l-3.22-.95v0.49a25.93,25.93,0,0,1,4.91,13.31,61.84,61.84,0,0,1-.12,7.22c-0.06,1.17.79,9,.81,10.18s-8.1-.41-8.11-0.61c-0.14-4.16-2.67-15.59-3.19-19.73-0.33-2.6-1.51-5-1.83-7.56q-0.28-2.25-.7-4.47a16.61,16.61,0,0,1-.65-3.52,4.65,4.65,0,0,1,.73-2.75c1-1.31,2.49-1.32,4-1.57a29.12,29.12,0,0,1,5.06-.5c2.55,0,12.54.3,15.07,0" transform="translate(0 -60.95)"/><path class="cls-104" d="M178.43,235.21c6.21,1.83,12.47,3.67,18.14,6.8l-5.39-17.26c-2.17.26-9.83,0.1-13.57,0a18.54,18.54,0,0,1-1.91,2.2c-0.87.77-4.1-.05-5.06,0.61a4.75,4.75,0,0,0-2.11,2.68,5.63,5.63,0,0,0,.43,3.06c2.06,5.88,7.43,12.69,8.9,18.74a60.14,60.14,0,0,1,.81,13.79c1.22,0.07,2.15,0,2.14-.39,0-1.17-.87-9-0.81-10.18a61.85,61.85,0,0,0,.12-7.22,25.93,25.93,0,0,0-4.91-13.31v-0.49Z" transform="translate(0 -60.95)"/><path class="cls-96" d="M171,222c4.21,1.83,11.67,2.45,13.48,3.78l-1.08-4.57-8.51-1.91Z" transform="translate(0 -60.95)"/><path class="cls-97" d="M158.66,261.1a2.93,2.93,0,0,1-1.2,1.71,1.53,1.53,0,0,0-.46.57,0.77,0.77,0,0,0,1,1,1.55,1.55,0,0,0,.43-0.34l0.62-.63a16.23,16.23,0,0,0,1.81-1.71,1.69,1.69,0,0,0,.17-1.34,0.18,0.18,0,0,0-.21-0.16" transform="translate(0 -60.95)"/><path class="cls-97" d="M156.14,263.85c0.11-.19.19-0.39,0.3-0.58a4.31,4.31,0,0,1,2-1.77,1.63,1.63,0,0,0,1-.79,0.41,0.41,0,0,0,0-.28,0.58,0.58,0,0,0-.54-0.25,3.82,3.82,0,0,0-1.08,0,3.66,3.66,0,0,0-1,.46,2.77,2.77,0,0,0-.84.65,3.67,3.67,0,0,0-.36.66c-0.12.25-.26,0.49-0.37,0.74a4.67,4.67,0,0,0-.33,1,2.1,2.1,0,0,0-.07,1.06C155.06,265.22,156,264.08,156.14,263.85Z" transform="translate(0 -60.95)"/><path class="cls-105" d="M159.53,261.47a9.83,9.83,0,0,0-1.16-.12,2.47,2.47,0,0,0-2.32,1.2c-0.41,1-.67,2.09-1.21,2.38a0.88,0.88,0,0,1-.53-1,8,8,0,0,1,.22-2.13,2.7,2.7,0,0,1,1.25-1.68,6.71,6.71,0,0,1,1.68-.43c1.78-.4,3.18-1.72,4.57-2.9a2.48,2.48,0,0,1,1.21-.68,1.76,1.76,0,0,1,1.82,1.23,3.9,3.9,0,0,1-1,2.15A5.25,5.25,0,0,1,159.53,261.47Z" transform="translate(0 -60.95)"/><path class="cls-102" d="M182.26,220.51c0,12.2-5.58,19.89-8.26,25.12s-9.12,13.52-9.12,13.52l-2.9-2.92s4-5.18,4.76-10.08S168,236.73,171,231,173,216.8,173,216.8Z" transform="translate(0 -60.95)"/><path class="cls-106" d="M164.88,259.15s6.44-8.28,9.12-13.52c1.57-3.07,4.14-7,6-12.18h-0.06c0.06-.1.11-0.2,0.17-0.3,0.35-1,.66-2,0.94-3.1a7.77,7.77,0,0,0-.22-2.71,1.22,1.22,0,0,0-.69-0.95,1.07,1.07,0,0,0-.88.25c-1.1.81-1.45,2.27-1.86,3.57-1.45,4.54-4.53,8.38-6.41,12.77-1.15,2.68-1.84,5.57-3.4,8-1.38,2.18-3.37,3.95-4.6,6.21Z" transform="translate(0 -60.95)"/><path class="cls-95" d="M185.84,198.3c1.87-4.17-5-4.22-6.5-1a11.92,11.92,0,0,1-6.16,6.28c-3.76,1.67-7.68,7.74-11.61,4.91s-3.69-8.18-3.69-8.18l14.9-9.12h9.48l5.8,1.17,0.42,5.61" transform="translate(0 -60.95)"/><path class="cls-107" d="M152,216.16a29.75,29.75,0,0,1,2.87,2,1.57,1.57,0,0,0,1.32.49,1.48,1.48,0,0,0,.79-1.26" transform="translate(0 -60.95)"/><path class="cls-105" d="M161.3,205.14c-1.32-.28-2.5-1-3.79-1.44a8.78,8.78,0,0,0-5.6.2,12.09,12.09,0,0,0-4.66,3.19c-1.15,1.24-2.13,2.85-1.85,4.52,0.32,1.94,2.21,3.21,4,3.93,1.12,0.45,2.48.51,3.51,1.11,2.46,1.43,6.58,1,7.8-.26a1.83,1.83,0,0,0,.24-1.65,3.59,3.59,0,0,1-.16-1.71c0.33-1.16,1.54-1,2.45-1.07a20,20,0,0,1,6,.2,2.16,2.16,0,0,0,1,0,1.81,1.81,0,0,0,1-1.6c0.23-1.54.1-7-2.24-6.89a19.29,19.29,0,0,0-3.25,1A9.91,9.91,0,0,1,161.3,205.14Z" transform="translate(0 -60.95)"/><path class="cls-108" d="M168.75,203.77c-1,.17-2,0.74-2.89,1a16.88,16.88,0,0,1-2.24.46,0.71,0.71,0,0,0,.22.47c0.12,0.11.26,0.17,0.38,0.28a1.1,1.1,0,0,1-.2,1.57,3.93,3.93,0,0,1-1.66.64,11,11,0,0,0-4.83,2.6,2.65,2.65,0,0,0-.87,1.27c-0.16.69,0.17,1.43,0,2.1a1.79,1.79,0,0,1-1.14,1.09,4.39,4.39,0,0,1-1.61.18,17.7,17.7,0,0,1-6.57-1.53,3.53,3.53,0,0,0-.91-0.3,8.19,8.19,0,0,0,3,2c1.12,0.45,2.48.51,3.51,1.11,2.46,1.43,6.58,1,7.8-.26a1.83,1.83,0,0,0,.24-1.65,3.59,3.59,0,0,1-.16-1.71c0.33-1.16,1.54-1,2.45-1.07a20,20,0,0,1,6,.2,2.16,2.16,0,0,0,1,0,1.81,1.81,0,0,0,1-1.6c0.18-1.21.14-4.89-1-6.31l-1.07-.38Z" transform="translate(0 -60.95)"/><path class="cls-109" d="M142.2,206.46c0.2,3.49,1.68,7.44,3.87,7,0.2-1.77,3-.91,2.75-3.26-0.11-1.31,1.24-.35,1.83-0.08s5.19,1.28,5.53-1.49c0,0-2.25-1.46-1.18-2.85s4.09,0.72,4.09.72,1.91,0.07,2.21-1.32c0.51-2.36,2.31-4.26,4.05-5.84a21.47,21.47,0,0,1,6.46-4,33.16,33.16,0,0,1,3.56-1.15q2.21-.6,4.46-1.07a11.68,11.68,0,0,1,5-.26,4.42,4.42,0,0,1,2.51,2.47,2.35,2.35,0,0,1-1.46,3.05s5.91,1.49,5.13-5.42-7-9.75-10.84-9.84c-8.86-.22-10.58,9.18-16.71,10.35s-9.27.61-14.48,2.94A11.08,11.08,0,0,0,142.2,206.46Z" transform="translate(0 -60.95)"/><path class="cls-110" d="M232.75,263.46a8.72,8.72,0,0,0,3.78-.89c0,1.23,1.22,2.63,1.74,3.74a5.32,5.32,0,0,1,.45,2.93,0.59,0.59,0,0,0,.18.66c0.66,0.28,1.51.66,2,.12a4.17,4.17,0,0,0,.79-2c0.65-3.18,1.13-6.58,0-9.62a3.3,3.3,0,0,0-1.38-1.84,3.82,3.82,0,0,0-2.8,0,42.48,42.48,0,0,0-7.48,2.92,17.56,17.56,0,0,0,1.12,3.11,2.53,2.53,0,0,0,.77,1.06C232.23,264,232.45,263.78,232.75,263.46Z" transform="translate(0 -60.95)"/><path class="cls-102" d="M240.48,268.42a4.3,4.3,0,0,0-1.77.81c-1,.73-2.58.36-2,1.35s1.11,0.85,1.11.85l3.82,0.12c0.65,0,1.59-1.33,1.78-2.47a60.28,60.28,0,0,0,.29-9.39,3.83,3.83,0,0,0-2.26-3.3c-1.28-.66-4.14-0.44-4,0.22s2.71,0.42,3.54,2.64S241.26,266.65,240.48,268.42Z" transform="translate(0 -60.95)"/><path class="cls-103" d="M234.19,264a14.11,14.11,0,0,0-1.83-6.7c-4.24.87-4.08,1.14-8.41,1.14-4.15,0-7.58.21-11.72-.14a13,13,0,0,0-5.14.33,10,10,0,0,1,1.07-5.34,69.81,69.81,0,0,1,4-7.32l-17.49,7.54a5.59,5.59,0,0,0-.65,2.33c-0.48,3.7-.91,7.66.77,11a18.85,18.85,0,0,0,2.39,3.4,2.21,2.21,0,0,0,.87.74,2.19,2.19,0,0,0,1.13,0c4.59-.79,9.1-1.91,13.64-2.94C218.88,266.67,232.24,266.87,234.19,264Z" transform="translate(0 -60.95)"/><path class="cls-111" d="M234.19,264a14.11,14.11,0,0,0-1.83-6.7c-4.24.87-4.08,1.14-8.41,1.14-4.15,0-7.58.21-11.72-.14a13,13,0,0,0-5.14.33,10,10,0,0,1,1.07-5.34,69.81,69.81,0,0,1,4-7.32l-17.49,7.54a5.59,5.59,0,0,0-.65,2.33c-0.1.8-.2,1.62-0.28,2.43,1.38-.18,2.83-0.85,4.14-0.76,1.8,0.13,3.66,1.34,3.89,3.13a3.88,3.88,0,0,0,.25,1.46c0.46,0.82,1.63.78,2.56,0.63l7.6-1.2a17.24,17.24,0,0,1,5.74-.26,5.84,5.84,0,0,1,4.48,3.25,5.13,5.13,0,0,1,.33,2.28C228,266.31,233,265.68,234.19,264Z" transform="translate(0 -60.95)"/><path class="cls-112" d="M167.44,203.6s1.39,6.49.69,8,1.67,2.82,3.63,3.37,14.41-.52,16.61,10.42c2.53,12.57,3,20.78,1.77,26s-1.67,4.36,2.65,3.8,16.79-1,20.42-.28,3.35,2.5,2.93-6.08S215,223.74,200,209.06s-26.8-8.41-28.19-6.87C171.76,202.19,167.16,202.19,167.44,203.6Z" transform="translate(0 -60.95)"/><path class="cls-112" d="M185,209.32c-1,5.89,0,10.53-.55,16.49a27.07,27.07,0,0,0-4.35-2.95c-2.88-1.28-6-1.1-9.13-.83a33,33,0,0,0,.87-13.25c0-.32-0.09-0.65-0.14-1" transform="translate(0 -60.95)"/><path class="cls-113" d="M189.51,220.37c-0.58-3.38-1.26-7.92-3.28-11.07a0.91,0.91,0,0,0-1.66.58c0.07,1.29.28,2.75,0.28,3.32,0,1.88-.08,3.76-0.24,5.63a11.26,11.26,0,0,1,3.76,6.62c2.53,12.57,3,20.78,1.77,26-0.71,2.93-1.15,3.94-.62,4.17l1.33-2.41a11.76,11.76,0,0,0,.92-1.92,11.42,11.42,0,0,0,.38-3.93A185.12,185.12,0,0,0,189.51,220.37Z" transform="translate(0 -60.95)"/><path class="cls-109" d="M176,184.51a3.07,3.07,0,0,1,1.29-1.84,9.37,9.37,0,0,1,2.55-.87,7.2,7.2,0,0,1,4.77,1.25,5.91,5.91,0,0,1,2.12,4.12,7.72,7.72,0,0,0,.12,1.79,4.88,4.88,0,0,0,.09-3.1,7,7,0,0,0-.84-2.26,5.46,5.46,0,0,0-3-2.16,9.32,9.32,0,0,0-5.85.09,9.1,9.1,0,0,0-4.09,3.3,3.46,3.46,0,0,0-.69,1.28" transform="translate(0 -60.95)"/><path class="cls-114" d="M216.14,248.87c-0.42-8.58-1.12-25.12-16.19-39.81a37.33,37.33,0,0,0-10.28-7.35l-0.21,0c2.75,0.93,4.88,3.14,6.62,5.47a37.59,37.59,0,0,1,5.09,9.34c4.34,11.65,2.68,24.66,5.32,36.8,0.09,0.41.19,0.83,0.3,1.24a42.12,42.12,0,0,1,6.41.36C216.84,255.64,216.56,257.44,216.14,248.87Z" transform="translate(0 -60.95)"/><path class="cls-115" d="M181.46,205a2.13,2.13,0,0,0-2.29-.54,2.62,2.62,0,0,0-1.18,1.6,61.44,61.44,0,0,0-2.78,9.73,18.69,18.69,0,0,1-1,3.89,9,9,0,0,0-.87,2.29,16.3,16.3,0,0,1,6.83.89,11,11,0,0,1,1.3.66c0.49,0.28,2-12.93,1-16.45A4.47,4.47,0,0,0,181.46,205Z" transform="translate(0 -60.95)"/><path class="cls-116" d="M212.82,266.64a36.25,36.25,0,0,0-8.75,1.5,13.88,13.88,0,0,1-3.5.62,6.75,6.75,0,0,1-6.73-7.34l-0.21.17a12.27,12.27,0,0,0,1.18,5.24,18.85,18.85,0,0,0,2.39,3.4,2.21,2.21,0,0,0,.87.74,2.19,2.19,0,0,0,1.13,0c4.59-.79,9.1-1.91,13.64-2.94a56.11,56.11,0,0,1,6.37-.88A57.31,57.31,0,0,0,212.82,266.64Z" transform="translate(0 -60.95)"/><circle class="cls-117" cx="151.37" cy="154.52" r="0.38"/><path class="cls-117" d="M157.83,215a1.16,1.16,0,0,1,.54.12,1.38,1.38,0,0,1,.44.35,1.56,1.56,0,0,1,.25.63,1.51,1.51,0,0,1,0,.35,1.18,1.18,0,0,1-.07.33,0.88,0.88,0,0,1-.38.44,0.69,0.69,0,0,1-.52.12l0-.06a0.6,0.6,0,0,0,.36-0.23,0.73,0.73,0,0,0,.16-0.37,0.75,0.75,0,0,0,0-.22,1.08,1.08,0,0,0-.08-0.21,2,2,0,0,0-.28-0.37c-0.09-.12-0.17-0.26-0.25-0.37s-0.25-.44-0.25-0.44Z" transform="translate(0 -60.95)"/><path class="cls-117" d="M150,215.08a1.06,1.06,0,0,1,.12-0.26,1.63,1.63,0,0,1,.94-0.69,1.07,1.07,0,0,1,.28,0,1.6,1.6,0,0,1-.17.22,3.63,3.63,0,0,1-.42.38,3.7,3.7,0,0,1-.49.29A1.67,1.67,0,0,1,150,215.08Z" transform="translate(0 -60.95)"/><path class="cls-118" d="M81,122.54a6.41,6.41,0,0,1,3.9,8c-1.32,4-5.52,5.41-6.5,7.36s-6.16-4.22-3.46-9.82S81,122.54,81,122.54Z" transform="translate(0 -60.95)"/><path class="cls-119" d="M81,122.54a3.9,3.9,0,0,0-1.6.45l-0.19.35a7.13,7.13,0,0,1,5.26,8.21,7.36,7.36,0,0,0,.44-1A6.41,6.41,0,0,0,81,122.54Z" transform="translate(0 -60.95)"/><path class="cls-120" d="M61.47,128.4c-0.15,5.49,1.1,13.11-1.1,16.91s-9.78,7.07-8.2,14.2,11.13,6.3,15.16.44,6.23-12.28,3.22-20.65S61.57,124.52,61.47,128.4Z" transform="translate(0 -60.95)"/><path class="cls-121" d="M70.55,139.3c-0.3-.83-0.63-1.64-1-2.42l-2.34-3a11.38,11.38,0,0,1-5.71,7.43,10.57,10.57,0,0,1-1.14,4,24.23,24.23,0,0,1-4.11,4.42s4.68,7.68,1,14.72a10.47,10.47,0,0,0,10-4.5C71.35,154.09,73.56,147.67,70.55,139.3Z" transform="translate(0 -60.95)"/><path class="cls-122" d="M68.69,145a25.74,25.74,0,0,1-1.3-12.3c-2-2.31-4.64-7.11-.3-8.48s12.53-2.59,13.52-.35,0,10.79-1.86,14.38S74,139.36,74,139.36s-1.12,3.6.87,6.08a65,65,0,0,1,4.84,8.06l-3.22,5-4.22-3.72-2.11-7.07Z" transform="translate(0 -60.95)"/><path class="cls-123" d="M80.6,123.87c-0.49-1.11-2.75-1.36-5.44-1.17a27.29,27.29,0,0,0-6.94,4.54,9.85,9.85,0,0,0-2.15,2.4,2.21,2.21,0,0,0-.27.83L66,130.82a0.55,0.55,0,0,0,.26,0c0.6-.17,1-1,1.69-1.17,1-.35,2.29,0,3.37-0.18a12.25,12.25,0,0,0,3.75-1.31,32.79,32.79,0,0,0,4.77-3.3,26.72,26.72,0,0,1-.55,10.54,6.3,6.3,0,0,1-2.34,4,3.54,3.54,0,0,1-1.8.53l-0.25,0c1,0.44,2.61.67,3.81-1.66C80.6,134.65,81.59,126.1,80.6,123.87Z" transform="translate(0 -60.95)"/><path class="cls-124" d="M68,258.24c-2,2.68-1.85,3.69-2.49,5.36s-2.68,4.43-2.77,5.82-1.94,2-2.31,0a9.94,9.94,0,0,1,0-4.94c0.46-1.89.37-3.37,0.83-4.48s2.64-1.57,2.8-4.89S68,258.24,68,258.24Z" transform="translate(0 -60.95)"/><path class="cls-124" d="M74.92,255.19c0.74,3,1.75,6.74.55,9s-0.74,3.42.09,3.79A26.84,26.84,0,0,1,79,270.7c1,0.83,7.57.74,6.93,0a28.29,28.29,0,0,0-5-3.69,2.43,2.43,0,0,1-1.2-3c0.37-1.48,1.35-6.43.63-9.82S74.92,255.19,74.92,255.19Z" transform="translate(0 -60.95)"/><path class="cls-125" d="M85.78,153.22c3.12,0.58,4.86,6.08,6.59,7.32l-5.49,3.2L85,159.42Z" transform="translate(0 -60.95)"/><path class="cls-124" d="M87.9,150.86C87.71,152.6,86,155.3,85,159.42s3.49,5.87,4.44,3.28S91,152,91,152a8.74,8.74,0,0,0,2.8-2.64c0.69-1.37,1.06-1.11-.42-2.8-0.87-1-.83-1.62-1.89-2.44a0.78,0.78,0,0,0-1.28.06L88.32,146c-0.2-.18-0.51,0-0.69.25l-0.56.66a1.82,1.82,0,0,0-.56,1.08C86.49,149.48,88.08,149.13,87.9,150.86Z" transform="translate(0 -60.95)"/><path class="cls-126" d="M91.12,151.92a3.18,3.18,0,0,1-.29-0.36,0.86,0.86,0,0,1-.14-0.76,1.26,1.26,0,0,1-1.15-.61,0.51,0.51,0,0,0-.18-0.22,2.73,2.73,0,0,0-.31-0.06c-0.32-.12-0.14-0.67-0.41-0.88a1.58,1.58,0,0,0-.49-0.13,0.62,0.62,0,0,1-.37-0.61,1.38,1.38,0,0,1,.28-0.7c0.31-.46,1.12-0.89,1-1.51a1.23,1.23,0,0,0-.28-0.51l-0.44.43c-0.2-.18-0.51,0-0.69.25l-0.56.66a1.82,1.82,0,0,0-.56,1.08c0,1.49,1.57,1.14,1.38,2.87,0,0.07,0,.15,0,0.23a3.26,3.26,0,0,1,.59,1.06,5.3,5.3,0,0,1,0,2.33,59.34,59.34,0,0,1-1.26,6.44,3,3,0,0,0-.14,1.19,2.24,2.24,0,0,0,1,1.36,2.1,2.1,0,0,0,.51.28,1.78,1.78,0,0,0,.93-1C90.43,160.11,91,152,91,152Z" transform="translate(0 -60.95)"/><path class="cls-127" d="M33.48,106a22.29,22.29,0,0,0-4.55-1C28,105,28,104.91,28,104.35s-0.1-.51.41-0.43a2.73,2.73,0,0,0,1,0s-1.49-1-1.1-1.33,0.66-.76,1-0.08a3.15,3.15,0,0,0,2.09,1.14C32,103.69,33.48,106,33.48,106Z" transform="translate(0 -60.95)"/><path class="cls-125" d="M46.75,111.71c-2.79,3.31-3.14,13.06-4,16.49L49,128.89,48.34,118.2Z" transform="translate(0 -60.95)"/><path class="cls-128" d="M39.8,108.56s-3.7-.78-4.49-1.07A19.79,19.79,0,0,1,31,103.72c-0.93-1.14-.85-1.35-0.07-1.57s1.07,0.36,1.85,1.5a4.32,4.32,0,0,0,3.88,1.62,1.66,1.66,0,0,1,.07-0.9,5,5,0,0,1-1.62-1.57c-0.27-.71.73-0.71,1.16-0.36s2,1.78,3.49,1.85,2.35,1.78,3.13,3.63,5.41,7.83,5.41,7.83l-1.64,7.83s-3.06-4.77-3.92-8S41.93,110.55,39.8,108.56Z" transform="translate(0 -60.95)"/><path class="cls-129" d="M66.3,225.83L62,256a0.55,0.55,0,0,0,.26.52l6.25,3.81a0.56,0.56,0,0,0,.78-0.2l1.66-2.83H82.46l0.39-23.62s3.12-5.86,3.9-7.22-2-5.47-2-5.47a108.46,108.46,0,0,0-2.39-49.44s3.08,1.61,5.13,0,4.83-11,4.83-11a13.42,13.42,0,0,1-6.59-7.32L84,158.46s-2.2-6.27-2.93-9.34-5-3.37-5-3.37l-1.21-.31,1.21,5.51s-6.52-5.71-7-6.74S67,143.4,67,143.4L46.75,111.71s-1.61,13-4,16.49c0,0,14.88,16.42,18.39,25.6s3.9,13.67,2.93,16.6-7.93,12.5-5.86,20.89C60.7,201.19,67,215.66,66.3,225.83Z" transform="translate(0 -60.95)"/><path class="cls-119" d="M80.28,120.93c1.78,1.48.51,3.08-1.32,4.39s-8.33,4-9.59,3.29c-1.8-1.08-3.36,2.67-1.12,3.68a15.89,15.89,0,0,0-2.45,3.8c-0.69,2.09-4.92-.67-4.34-7.7S72.08,114.12,80.28,120.93Z" transform="translate(0 -60.95)"/><path class="cls-130" d="M62.49,258.65a1.44,1.44,0,0,0-1.68.23c-0.82.74-3.14,2.88-3.32,3.2s0.27,1,.64.64S60,260.94,60,260.94a7.79,7.79,0,0,1-.32,2.18c-0.34,1.1-1,6.2-.34,7.43s2.17,1.82,2.86,1a2,2,0,0,0,.56-2.19s-1.74.23-2.19-1.09,0.59-4.87.73-6.28S61.66,258.69,62.49,258.65Z" transform="translate(0 -60.95)"/><path class="cls-130" d="M74.75,266.26c-0.62.11-.64,2-0.33,3.19a10.94,10.94,0,0,1,.32,2.49h0.64V269.1a6.3,6.3,0,0,1,2.23,1.6,1.89,1.89,0,0,0,1.59,1.24h7.65c0.87,0,1.31-.34.32-1.24a5.82,5.82,0,0,0-2.21-.78,1.34,1.34,0,0,1-1.39,1c-1.17,0-3.4.18-4.1-.44S74.63,266.92,74.75,266.26Z" transform="translate(0 -60.95)"/><path class="cls-131" d="M68.12,143.45a4,4,0,0,1,.49,0,4.66,4.66,0,0,1,1.27.31,5.1,5.1,0,0,1,1.6,1,10.31,10.31,0,0,1,.69.77c0.18,0.21.41,0.45,0.62,0.66s0.44,0.42.67,0.6a3.75,3.75,0,0,0,.64.43l0.11,0.05s0,0,.08,0a0.09,0.09,0,0,0,.07,0,0.54,0.54,0,0,0,.28-0.34,4,4,0,0,0,.25-1.1,1.94,1.94,0,0,0,0-.47,1.2,1.2,0,0,1,.31.4,2.66,2.66,0,0,1,.34,1.33,1.49,1.49,0,0,1-.44,1.09,1.29,1.29,0,0,1-.75.35,1.46,1.46,0,0,1-.38,0,2,2,0,0,1-.35-0.07,3.75,3.75,0,0,1-1.06-.54,6.17,6.17,0,0,1-.85-0.72,6.88,6.88,0,0,1-.72-0.85l-0.52-.77a7.64,7.64,0,0,0-1.06-1.18c-0.36-.32-0.69-0.58-0.93-0.76Z" transform="translate(0 -60.95)"/><path class="cls-132" d="M87.82,146.5a0.47,0.47,0,0,0-.15.41,0.26,0.26,0,0,0,.17.24,1.29,1.29,0,0,0,.59,0,1.22,1.22,0,0,0,.78-0.43c0.21-.22.53-0.46,0.74-0.68a2.84,2.84,0,0,0,.91-1.06,0.33,0.33,0,0,0,0-.16,0.38,0.38,0,0,0-.07-0.16,1,1,0,0,0-.65-0.57,1.94,1.94,0,0,0-1.47,1.12A7.73,7.73,0,0,1,87.82,146.5Z" transform="translate(0 -60.95)"/><path class="cls-133" d="M79.17,132.92c-0.11,1.06-.23,1.2.31,1.38s1.54,0.32,1.64-.73-0.18-2.73-.72-2.91S79.28,131.86,79.17,132.92Z" transform="translate(0 -60.95)"/><path class="cls-134" d="M72.94,135.13c0.79,2,2.22,3.45,3.84,2.56s2.42-2.79,1.06-3.58c-1.72-1-2.45-1.8-3.79-1.84C73.11,132.25,72.41,133.76,72.94,135.13Z" transform="translate(0 -60.95)"/><path class="cls-131" d="M77.84,134.12c-1.72-1-2.45-1.8-3.79-1.84a1,1,0,0,0-.73.35,8.36,8.36,0,0,0,2.46,1.57,19.43,19.43,0,0,1,2.66,1.63A1.35,1.35,0,0,0,77.84,134.12Z" transform="translate(0 -60.95)"/><path class="cls-129" d="M76.87,128.19a1.37,1.37,0,0,1,.25-0.16,1.07,1.07,0,0,1,.29-0.1,1.49,1.49,0,0,1,.37,0,2.16,2.16,0,0,1,.57.23,1.32,1.32,0,0,1,.24.18,1.28,1.28,0,0,1-.29,0,1.91,1.91,0,0,1-.29,0l-0.31,0a1.13,1.13,0,0,0-.27-0.06l-0.27,0A1.27,1.27,0,0,1,76.87,128.19Z" transform="translate(0 -60.95)"/><path class="cls-129" d="M76,130.38s0.12-.26.34-0.64a2.11,2.11,0,0,1,.53-0.59,1.11,1.11,0,0,1,.53-0.2,1.27,1.27,0,0,1,.55.05,0.86,0.86,0,0,1,.5.45,1.11,1.11,0,0,1,.07.55,4.61,4.61,0,0,1-.14.73c-0.12.41-.19,0.69-0.19,0.69a2.52,2.52,0,0,1-.18-0.71L77.9,130a0.48,0.48,0,0,0-.1-0.23,0.32,0.32,0,0,0-.13-0.06,1,1,0,0,0-.27,0,0.42,0.42,0,0,0-.23,0,4.29,4.29,0,0,0-.56.32A2.88,2.88,0,0,1,76,130.38Z" transform="translate(0 -60.95)"/><path class="cls-135" d="M74.36,144.6a7.77,7.77,0,0,1-.35-5.19l-0.28-.28c-1.06-1.07-3.29-4.33-4.94-4a7,7,0,0,0,1.08,4.42C70.78,141.09,72.46,143.62,74.36,144.6Z" transform="translate(0 -60.95)"/><path class="cls-136" d="M87.27,166c-1.1-.07-2.29.51-3.46,0.46a14.47,14.47,0,0,1-4.15-.9c-2.52-.89-4.95-2.14-7.6-2.47a0.73,0.73,0,0,0-.44,0,0.76,0.76,0,0,0-.29.44c-2.08,5.73-4.17,11.53-4.88,17.59a10,10,0,0,0,.33,4.82c0.64,1.62,2,2.85,3.1,4.17a20.24,20.24,0,0,1,4.3,8.53c0.37,1.62.55,3.29,1.08,4.86A22.51,22.51,0,0,0,77.53,208l6.56,10.74c0.27,0.44.56,0.9,0.87,1.34a108.52,108.52,0,0,0-2.54-48.59s3.07,1.61,5.13,0a11.83,11.83,0,0,0,2.37-4A4.16,4.16,0,0,0,87.27,166Z" transform="translate(0 -60.95)"/><path class="cls-137" d="M85.78,153.22L84,158.46s-2.2-6.27-2.93-9.34c-0.53-2.23-2.9-3-4.17-3.25,0.1,0.88,1.1,2.15,1.45,2.81a108.08,108.08,0,0,1,5.88,13.57c0.62,1.75,1.17,3.77.23,5.37-0.65,1.1-2,1.92-2,3.2a2.07,2.07,0,0,0,.2.84c0.82,0.35,3.16,1.17,4.83-.14,2.05-1.61,4.83-11,4.83-11A13.42,13.42,0,0,1,85.78,153.22Z" transform="translate(0 -60.95)"/><path class="cls-138" d="M46.08,116.26c0.25,0.29.5,0.59,0.75,0.93a46.89,46.89,0,0,1,3,5.31l5.81,10.45c3.42,6.15,6.87,12.38,8.72,19.16,0.9,3.31,1.46,6.83,3.38,9.67,1.69-5.65.43-11.71-.84-17.47l-0.41-1.83L46.75,111.71S46.51,113.67,46.08,116.26Z" transform="translate(0 -60.95)"/><path class="cls-139" d="M70.94,257.28H82.46l0.39-23.62,0.72-1.35c-2.11,1.91-3.41,4.6-4.63,7.2l-7.26,15.55a7.55,7.55,0,0,0-.76,2.25v0Z" transform="translate(0 -60.95)"/><path class="cls-140" d="M76.51,222.31c-1.76-12.07-14.69-20.64-15.14-32.83-0.14-3.74,1-7.52.23-11.19a8.69,8.69,0,0,0-2,1.54c-1.39,3.57-2.32,7.64-1.38,11.47,2.45,9.9,6.88,26.79,6.17,37L62,256.32l0.26,0.16c3.65-3.9,6.41-8.7,8.9-13.48C74.45,236.56,77.56,229.48,76.51,222.31Z" transform="translate(0 -60.95)"/><path class="cls-141" d="M90.38,152.57a3.54,3.54,0,0,0-1-1.35,0.69,0.69,0,0,0-.25-0.16,0.66,0.66,0,0,0-.44.08,3.4,3.4,0,0,0-1.56,1.44,0.81,0.81,0,0,0,.1,1,0.44,0.44,0,0,0,.23.18,0.41,0.41,0,0,0,.39-0.21,1.26,1.26,0,0,1,.48-0.41,2.31,2.31,0,0,1,.66-0.23c0.36,0.88-.71,2.41,0,2.93a10.45,10.45,0,0,0,1.35-1.22A4.2,4.2,0,0,0,90.38,152.57Z" transform="translate(0 -60.95)"/><g id="_Group_" data-name="&lt;Group&gt;"><path id="_Path_" data-name="&lt;Path&gt;" class="cls-142" d="M48.86,83.47L56,88.17l0,0C57.39,89,61.14,85.92,63.72,82s4-8.58,2.6-9.51l0,0-7.13-4.7Z" transform="translate(0 -60.95)"/><path class="cls-143" d="M61.37,77c0.36-1.56.73-3.12,1.15-4.66a14.09,14.09,0,0,1,.67-1.84l-4-2.66L48.86,83.47,56,88.17l0,0c1.07,0.68,3.53-1,5.77-3.57A12.43,12.43,0,0,1,61,82.34,12.23,12.23,0,0,1,61.37,77Z" transform="translate(0 -60.95)"/><polygon id="_Path_2" data-name="&lt;Path&gt;" class="cls-144" points="63.01 0.01 49.91 13.61 44.77 29.52 45.25 29.83 59.3 16.49 63.49 0.32 63.01 0.01"/><polygon id="_Path_3" data-name="&lt;Path&gt;" class="cls-142" points="44.79 29.48 49.92 13.59 63.01 0 58.84 16.16 44.79 29.48"/><ellipse id="_Path_4" data-name="&lt;Path&gt;" class="cls-144" cx="54.1" cy="75.82" rx="2.65" ry="0.74" transform="translate(-38.98 18.25) rotate(-56.57)"/><path id="_Path_5" data-name="&lt;Path&gt;" class="cls-145" d="M54.1,75.82c-2.58,1.86-4,5.16-4.83,8.21a8.23,8.23,0,0,0-.43,4.07,1.21,1.21,0,0,0,.39.73,1.8,1.8,0,0,0,1.34.06c0.74-.11,2.19-0.07,2.41.86a1.36,1.36,0,0,1-.17.95,4,4,0,0,1-.61.77,6.5,6.5,0,0,0-1,1.13c-0.19.35-.36,0.74-0.52,1.11a4.13,4.13,0,0,0-.27,3.13" transform="translate(0 -60.95)"/><g id="_Group_2" data-name="&lt;Group&gt;"><path id="_Path_6" data-name="&lt;Path&gt;" class="cls-146" d="M53,101.31a0.26,0.26,0,0,1-.17.31l-2.21.55a0.26,0.26,0,0,1-.3-0.19l-0.45-5.14a0.25,0.25,0,0,1,.18-0.3l0.63-.16a0.25,0.25,0,0,1,.3.18Z" transform="translate(0 -60.95)"/><path id="_Path_7" data-name="&lt;Path&gt;" class="cls-147" d="M50.71,96a0.12,0.12,0,0,1-.08.14L50,96.35a0.12,0.12,0,0,1-.14-0.08h0a0.12,0.12,0,0,1,.08-0.14L50.57,96a0.12,0.12,0,0,1,.14.08h0Z" transform="translate(0 -60.95)"/><path id="_Path_8" data-name="&lt;Path&gt;" class="cls-147" d="M50.77,96.26a0.12,0.12,0,0,1-.08.14L50,96.57a0.12,0.12,0,0,1-.14-0.08h0A0.12,0.12,0,0,1,50,96.35l0.67-.17a0.12,0.12,0,0,1,.14.08h0Z" transform="translate(0 -60.95)"/><path id="_Path_9" data-name="&lt;Path&gt;" class="cls-147" d="M50.66,95.81a0.12,0.12,0,0,1-.08.14l-0.67.17A0.12,0.12,0,0,1,49.76,96h0a0.12,0.12,0,0,1,.08-0.14l0.67-.17a0.12,0.12,0,0,1,.14.08h0Z" transform="translate(0 -60.95)"/></g></g><path class="cls-148" d="M270.58,244.71c-2.57-1.06-4.55-.26-4.55,1.78s2.9,1.32,4.55-.92" transform="translate(0 -60.95)"/><path class="cls-149" d="M272.51,250.16c-2.55-.76-4-4.16-1.87-8.06s5.52-2.46,6.28-4.07,1.36-3,3.22-1.7,2.12,5.6.85,9.59-4,3.56-3.48,4.84,1.78,3.13,1,6c-0.68,2.57-1.87,3.73-.08,4.41a2.31,2.31,0,0,1,.93,3.53c-0.68.46-.34-1.07-1.61-1.49s-3.14-1.78-3.22-3.22a3.66,3.66,0,0,0,1.44,4.38c2.55,1.9,2.89,4,2.29,5.65a2.28,2.28,0,0,1,1.87.59c0.59,0.75.76,1.33,0,1.33H262.07c-3,0-7-3.88-8.06-10.5s0.68-7.89-1.87-10.78c0,0,1.19,4.24-2.55,5.52s-11.88-.08-10.69-9.84,15.44-13,20.37-5.08-0.25,18.5,1.87,23.63,4.33,4.7,4.33,4.7-3.31-3.65-1.1-10.82A12.42,12.42,0,0,1,272.51,250.16Z" transform="translate(0 -60.95)"/><path class="cls-150" d="M280.15,236.32c-1.43-1-2.11-.4-2.7.64h0a3.08,3.08,0,0,1,1.64,1.81,6.3,6.3,0,0,1,.6,1.53,4.1,4.1,0,0,1-.07,1.67,7.29,7.29,0,0,1-1.73,3.89c-0.73.71-1.7,1.12-2.44,1.83a4.15,4.15,0,0,0-1.22,2.36,0.87,0.87,0,0,0,0,.44,1.08,1.08,0,0,0,.43.44,5.5,5.5,0,0,1,2.12,5.43c-0.14.68-.41,1.32-0.53,2a2.6,2.6,0,0,0,.3,2c0.79,1.1,2.73,1.12,3.17,2.4a3,3,0,0,1,.12.67,2.27,2.27,0,0,0-1.41-2.25c-1.78-.68-0.59-1.84.08-4.41,0.76-2.89-.51-4.75-1-6s2.21-.85,3.48-4.84S282,237.6,280.15,236.32Z" transform="translate(0 -60.95)"/><path class="cls-51" d="M276.92,238c-0.82-1.23-.42-3,1.27-2.89s3.21,1.13,2.71,2S277.6,239,276.92,238Z" transform="translate(0 -60.95)"/><path class="cls-149" d="M271.38,246.36c-2.88-.8-5.84,1.52-5.28,4.24s3.84-.16,5.28-2.88S271.38,246.36,271.38,246.36Z" transform="translate(0 -60.95)"/><path class="cls-151" d="M266.91,250.09c-1-1.36,1.53-3.52,3-3.33C270.2,248.2,268.28,251.9,266.91,250.09Z" transform="translate(0 -60.95)"/><ellipse class="cls-51" cx="274.91" cy="181.22" rx="0.72" ry="0.44"/><path class="cls-152" d="M272.5,265.09c4.24,2.8,2,5.87,2,5.87a23.28,23.28,0,0,1,3.78-.93c0.59-1.69.25-3.74-2.29-5.65a3.66,3.66,0,0,1-1.44-4.38c-1.32-1.33-1.24-4.12-1.24-4.12S268.26,262.29,272.5,265.09Z" transform="translate(0 -60.95)"/><path class="cls-153" d="M256.8,257.77c2.3-8.23-2.46-15.53-9.81-13.29s-4.59,12.11.68,12.08a7.88,7.88,0,0,0,1.93-.37c3.73-1.27,2.55-5.52,2.55-5.52,2.55,2.89.85,4.16,1.87,10.78,0.82,5.36,3.65,8.92,6.27,10.09A14.43,14.43,0,0,1,256.8,257.77Z" transform="translate(0 -60.95)"/><path class="cls-154" d="M264.36,258.77c-2.21,7.17,1.1,10.82,1.1,10.82a23.3,23.3,0,0,1,2.3.68c-6.79-13.54,4.75-20.12,4.75-20.12A12.42,12.42,0,0,0,264.36,258.77Z" transform="translate(0 -60.95)"/><path class="cls-155" d="M252.14,250.67c-3.2-2.92-6.18-1-5.84,1.1s2.91,1.38,2.91,1.38-2.49-.63-1.15-1.58S252.14,250.67,252.14,250.67Z" transform="translate(0 -60.95)"/><path class="cls-156" d="M286.34,258.48c-0.91.91-4.37,3.19-4.53,6.75s1,4.21.89,5.36a2.08,2.08,0,0,1,1.65.57c0.78,0.72,4.11.92,6.55-.36s4.47-4.47,4.47-4.47Z" transform="translate(0 -60.95)"/><path class="cls-157" d="M286.34,258.48c-0.15.15-.38,0.35-0.65,0.58,0.47,1.76,2.51,3.85,3.18,4.82a2.83,2.83,0,0,1,.63,1.43,2.86,2.86,0,0,1-.89,1.83,7.93,7.93,0,0,1-3.09,2.6c-0.68.25-1.41,0.31-2.11,0.52a3.55,3.55,0,0,0-.72.3s0,0,0,0a2.08,2.08,0,0,1,1.65.57c0.78,0.72,4.11.92,6.55-.36s4.47-4.47,4.47-4.47Z" transform="translate(0 -60.95)"/><path class="cls-158" d="M292.27,260.31a4,4,0,0,1,2.84-1.47c0.39,0.07.72,0.85,0.26,1s-2.05.75-2.35,1.5S292.27,260.31,292.27,260.31Z" transform="translate(0 -60.95)"/><path class="cls-159" d="M288.33,256a2.17,2.17,0,0,0-2.51.81c-0.62.68-.52,1.57,0.36,2.38s7.38,7.65,8.32,8.33,1.47,0.6,2.41-.21a1.68,1.68,0,0,0,.13-2.6C296.31,264,289.4,256.46,288.33,256Z" transform="translate(0 -60.95)"/><path class="cls-160" d="M297,264.74c-0.26-.28-1.31-1.43-2.61-2.8a5.41,5.41,0,0,0,0,.76,1.59,1.59,0,0,1-1.77,1.39,4.14,4.14,0,0,1-2.22-1.13,12.94,12.94,0,0,1-3.13-3.39c-0.28-.48-1.1-1.73-1.81-1.26a2.47,2.47,0,0,0,.65.91c0.88,0.82,7.38,7.65,8.32,8.33s1.47,0.6,2.41-.21A1.68,1.68,0,0,0,297,264.74Z" transform="translate(0 -60.95)"/></svg>
\ No newline at end of file

From 24919547b8f762a9f0e53f65046691912ebd0aac Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Tue, 1 Aug 2023 10:22:35 -0700
Subject: [PATCH 456/749] Add balance card

---
 assets/images/cards/maintaining-balance.png | Bin 0 -> 63884 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 assets/images/cards/maintaining-balance.png

diff --git a/assets/images/cards/maintaining-balance.png b/assets/images/cards/maintaining-balance.png
new file mode 100644
index 0000000000000000000000000000000000000000..ee65178762ea708a9302beae65fbe40156e6ad38
GIT binary patch
literal 63884
zcmeFY1yGz_vo4AScZc8_2<{FEPOuOpxDL($gF6Jbpur^s0t9!r!QCae26uPPkWc>a
zKWE>4?ykD$R-LLnsf71kt5<igUQf&FA)(5O(rC!U$WTyFXtFXADo{|c+fYz2goyBv
zkw>X+Stux+SMI7G9aRinDC|JCrWV!!3P(3P00qF+!W0V1b*?zs!hNF#E9hw*mmfy?
zBQhU4^1#^!Jiqr66)k|Prsp%xh0Ks)9EI{g?bnW*8ByD71X0QAK$Ys+F|Ccf2o4j_
z==vRJW-CL&*3p@R`yjblYdXdcX}8Y-AH4fKH1`j@lrpzOf!Cf&aoM*WVqRXJ2Fs#^
zzq}G3C&Z47jW3CAP96!(JyGL-Jy3X|vMmF;cp4t--~^BEdLC>EuhAa!&W|P@hn~J{
zAM`s^^!71GKguPzz|8tM^v3x=-qVtJWA&Wg7i)^bQ&Y4O<Xv|ZwU21t2;4Hf_VVo7
z)>Z*|lp>~GlMP;8JT`89c-Xn`@m)na!B86BTbF6cv}OLDnRs^Nadf!4bXEdPkdm42
z`6iNhO=6#gb$Y)r?aI*l#n?;FUjsw+i0YSMiFuPcv24h-0__3Ugu<4az6E<1m2|vI
z4DAj7Ol5!c7h?*gF8!Ub%@|&y_$C?K%_7esTHz7Wk#+pVvUNorhEQ;9;@e}<r>Gfn
zbjQ*}A?QP;-HEtN8odDd4$du~`mlhUJ5A{eq~oo<E%Fg7I{ynK2Qxp;Il+Lb^Y_|%
z(l@e>o9+E~^H#D~Jx~E5W*T&H97G|^zf!cq7{4)K^(cDN!8-LxM&RaX0XW|=@bkt_
zbY%_+r({@t@An`cq{8B^Ey^+7kS#%OlX@`UnH(*uPtdX|)bb#8s#%aLEatXB_x@0c
zUp%K;y*E1Rz}kE{U41nwohdE_PqJq&E=_Jc*e6a;t#p{7!<H8cc&%QXtW|61@Lr^_
zs9|n=s)N`HIP2z*(`d8k6(y`B5I@e4m*ISV&N<u^KQ~mn;66V!e^ht&+KQpc;$dj7
z)Qs87R3StDCh+zPH&E??go-~+b%cm0F1EMM9sZU1Nm^HiT+GUkv$QVg!C#Dn749JC
z(})-_D0VWn1$31;=ry4I>X%P{s;4Q7>+U0YGD=2+XzzmU*`=W7{4me!&0~|^`B8sj
z&VwGw4+2jsIjxUm_Y^}8K~H1&^k>9{_{~G|tgunyFHTx)WB5}Js)EwqlrkGkb$|K_
zM5?c-6LMO%@IbdK=@HRrGDyQEUzxUGYDrIE9F=7OA>0&M7xPC|Yb?SFRd^Kx&$Oqf
z4v)4JTcwTkJ9Ei8yVJE;i82q)8=_y@V>S>ewMY~k;_SX+d^aB#Cq*-%={As)ahtwT
zYQt!u+1O($iWITb==|>csghZ?;ys^o?+Ezm_R$RXhwI%^mAVMSAyr|`>(sC+0eS4P
zKC6xIlqzqHDfwi6e%wJ%krrgeiAona8g;tM-K|+zQeuBwrrl^y<OYLT^MUHck8kOw
zl`UMhr;@5WfE}r>50L<{bbN!0H;gN&)#e}~Db{6eo2&FY(OM69*&~y4LM)Og0HESN
zU=RGz0GQV5CVHJ0w*|i`I}XK`pY8dfX7V!{TZuV&-hO=0e#Zco3T24%s|?z4hKbtG
zXF#3-@oQyi**pUJ;FN){`@6G3Q(`Et9>iVP)8}M1>NyD=sHbUh_)}9W30()--#_>T
zyro=B>1jcnlAS)CBfd(L(CtA?DH?v|!Zt9~Tcb6>S+m49g01vPVZ23BMrUKr>bs)j
zJNCEZce?8DT@AksG^8lk&}7q1=x*v+MNd&WhWQa&P`-phUok#R#f;~fl*_}7KQ!9M
zQ>0s<;|B46{h_i0n&J%Y)Fdn3#`5NH3h4DR3eFDvo?NM!69fA|&!u0$TYFbiwBgP|
zKyD#L|9-M}f`cUv{>zU}Z<#PfsJ9cJ?@Oj(er8GcCtn<9<=5(J%X%&Ae2kl>2O%3U
z+DWv15Y{w<cefOQ$u357-o(B9eg)9&JAk?g&yfUYDt8)Rpd8M<%2W0*Q?NrES`c9L
zp_MfE9|0*EM)+=hg^`+s&3`$fJ4geNGwOlXDTq$kX7noejfLj9KtPm{jTTFqqsGJP
z&$x-$GqPj;27>lfsl~56o0Oir#^0SB$jvlmd3U%9YAoI#-=3c~pQ{`acxY3Lv+js(
z9NEDoxN4|m<Y=3%pZ~PNBahNE9P1m_i!8Ss!w?>z&9mqbpZjLpCQj&cM++<>4t)y|
zmCP6+G0dPp92dfA3eNY`BW)_q1zB)M@Po9fFEJ2CKSE$LLpRb*gAmJIA&^#eF)k>h
ziiY3sKnlu!GZkmA%b|j43|i2}@daPk!iO1Tt1{n=P|hL`tU@vOJfC_SlwM2{jF;Sg
zr!Q4I6_w$y8nP<lOF!ksG}yIJn9hT37=VTZUolpiEM-kA#c&9)uob3=nO{&*m@lA%
z0vkCJD$M+>UzxoM!F}5qWY%Y)s7h}2zL+y9(Sy{yN>|2JTgk9KIdv}cG<dX0E$@qi
z*1UX^kFSXvf1iyRS|-AgM{!%@xjF-vZzJ(96cRP4u;UGfF-0#PqmBlCVlw!A47Ug-
z#Zj1HWAP|6i7@+!LRyRlrCUiar|fT<;S;UnO%(fIKHzJmi7o8Uz9Hj%D?}u|{aRpy
z18MpV>q!(zwbvK@4Od`Ec(iZ;L*?eLY6e7m$1it}i{*R~abD(SM3_2{g<*01VIH5L
z!%44Yw)=wMbIe|2#`RN}AV-7+Ifzw-9>PRgkwVFdpXw4mMQ&>;S-;`lkdY|Q+PROe
zQ&>Px4ziL3<zMeW$I@<*uk6Rl-Rhw%w#o>}Dg2-|(IX-%sNWj22eYQsuqchb*tF0R
zfqM`Pr_BEj+b~H>%B|(cvF4PCfheY$PDVx{sem~HJqs2#A!sQ4B<I^o-4%3w0{DLL
z#UXDo3WRO2P_s52!N`mQQwfc7Y?#I+;0rG>=oLg-v@N{X#{H6paRntI<OjHJ_$eEJ
zI}ZA^uUJjW8bQOH*s_%Zs{{=zWp+6ljgtJ+CV`K*ftU=&LheONTKziwcjal6a*T1Y
zk(LWs7Y;P&Qpy*>F<8D74nZ*0g?%p)6^V5N4WRNzd4!}M><Hv-Ti%VwJL|u&-o;dY
z)1^*9l|<Xm4$QuiDyVYEO9+20K~Inbj6+^=uR<0&NsA3#pxg*#`NmNEwvO1H2N~-y
zbwd0AMKa?OwQJeUl_Gf$N@Wk%P%3*Wc&{mKB9v#_Ng-s#S9%t4JumCW7wT5Pcsbm}
z8#X&B1WSIhZJVzqaT6@`zMr9F#93pe;jJ~~xk%#0bsO%o`&je*V7|Rz7XzUYwR6eG
zz}qmBuqnSL7Kdi#cpI8ZKwwsf_sgm5^)WJL%uBpr!v0jp@j(fLY<L~Jke#F-RWaxB
zzC3<&P+}Td`GKHCyAKC?7;u(^#`5Ya0R?aU!Lj+s057#n1$^<jJzq(K%+Qg65Xw1T
zEjT8bIX4PaUUhb)ddDkhV4_`05x!LO?rzzEf-+pdK7kr_ocF73E&{8XPRZ&l%*n#g
zL4RbizLoc#HSgb?-XcueTs+`^#g|krj;HH9p%^3EH`lMn$!<AHM*p%7vlnl2QLI!p
z6UyMBp>D^-M(q3D=U`V~hvad^5<jF9_MC*DIt+=LcenEJ(@i7=V<8O6wn;C%n&3kP
zl^JDvd3PR$1lLkKCxW+5ViTW#<y>wh)&ui9*lcS1B2W3iy5qXl6Jx-*U|A=4!n6wN
zp`s@Lz3O&>4qTxIals3oIfSz8x@*k#+<d8}kUBB0_ZC=z_H;B+BhuZ|JaIVC8v{sn
z=s2?{HY-eTkzi)q_O(dE7Z#FTgs;72B8!Z`7E1VjJBeI6e9Bgsn>o7Xx=^3`SSfP(
z<COBls9-i1FD{LsW%)N$9=637VBeh5OGzrDHBB2hjUfoa?-{2-6Eujof*cWesOFJk
zo3IjWyUWPtx@f}%NnK~Y5W+xnsbA?YWH@I#YMi9&_{(k+kjoyTZ@?jHPBP}2&}JAE
zyRdi^W_jWc4dOW8OM(Mib?kjqGFI=VM7QHJm&+Ll1m2z_y2AFoFY`rXy!I`95wJj1
z0!C^#Gncg9``+=&xch4mF$=E$H#@~eBn7lwG3lk|5_hi=TVh@WyAq%n;e>?BcwG<k
z(b{7kp)7eMMl6>l{z&vo@xcJTESCE1nqXFWugc-tEQ1ig*gV0s=<;!_QdAExft{TH
z@Nrff{U(a#i|+)g!IOyy{9^fK$s#|Sjn5v?4G84&;24IX5xYVkbXYzz@x!kQVdQI^
zpv!-t+^_K5dZG3*9I62m$1h-rqpQ5;s7nF<WC$jS2sYeZqWu*q#laW2PN<OpWQTMO
zP2$d_Fsh&(Rj#N8d1=A)rTjXn5R5muHx9&5E@vxXZ_ER591j64PRk<n4NP2Y{|h<e
zmS|R>uyji=M(6o<>apRB9kGyTJD<!|vxRAqA+A>XCKI-i=z`a`5!~$dpDr4?lZ%{V
z^#qy@*ladP8n8?w&AfJE_jrMZ_B5<7P>2vBgga1sRt1d*t9JY!?dUF?Ww?<WsZ}w9
zlddT-c_NfPdx?&-tC%wx!DZ0ggW}I|VNTv^%>uYi>dS>xrg*CTSbU*Yy?DQ?!sa5@
zeqNTON63Zh!~`B5JGYTPJUmbfkr`;KCzlXoQ@Z@H+!pjb-f#4j%&Xefmh{C^Kh(2C
zB6?Thu%3aFR-d=d_L%NQbye2&x<;FP5BT!VzV^+-K-x#U5*@$P#?hXx@><z40Q`04
z9gA|<EMI+g=I{rjl4?qWCz0$%hD~a@RjijdKEAd=3HC6DfswgGW4zecW=J`D<zLUz
zCu__wVHhR}NxVHr)OBYmlw6NbnP-rwz?2<0c<?o!a|7hzl-{nlOI;v;7gdPTIF~|P
z;~pcfi&?}g`iT-Axy6z{*~^rLWrEff(mW<@gDjBIZW!?Hy@r+j*D;h_tmT9x_zR>)
zr?e1>W!smzLR`{lsv`To@s{#(KM*%2a23%2OJeA&1JzU}H<Mo8)!Q8ChzRMJf&{l!
zxc<aL2BR7&V&YkcUfH2|P6WUf8~CVko8%(QJm$hW`!)Z*97-ot+~`?x=}Rz+IZwR#
z+i^PVx5D%@b9GJxiX)d+Sx+Yh^bHs$lBnHJuL>Da;*nskOycA8i@x9BBV9Iw2NxAW
z=P{SP!HVP6A>2h-cMJi{q^|nVVv>`-juJ{=LcMI3I4v6B?ZrQ_E4jxo&NRh(@%B-8
zv~i9NBW;B|Ms#<u6l0>dtvesf590r@=}|@pv9(Yz+(HjHjn&GScZP@6GHf#HyF>#M
zKVo=ggR3!<hU2j3Lf2FkY|yN?9W$d?B0Gt+CG;tZBWBlh&DmA_=@`tj1D}3CXU4pN
zB}P)9o8<A9V;`TNM~y;FD?=6tbZ@u$+A1|N)_NAm#|dW^A?pqE^ANOS;i;^2eydLV
zI-EuCI^M`EaP1+0{Ay^QF5@L~L?88gWyzAL(Xsg0hWd!1NFmov>QD63_5eaD-nEw5
zE%(xFB5KrFuRMSjI6!^*r=~Jb5`uUYODcADF%!xG0yt4-Q9vat^{c?f*P{m2=$lKI
z)ZQx?p26UJ<a)8e#t1XmU1WGvD*hMm2CvPFKZml7v^RVWQ(YE6_C8}(Ahw}ZU6zs$
zSR?i`qxRLL4oU$XE08+5bST^7XHsBB!j(&SEv+?vi}(p|7b4h$i(^eD;+5BVcQTee
z6c?%RO-kjm6!`Jd{g=XHmj=`7I+SY~V*Y_gF@^JY9z(VKsz##D6j-fuG-Qe`e=lg3
z>_UTAI;8H>nDNFm&A5-y%*YwRnlcxx{3@p(Lw#4=fftL2seC5xU01oDtuS8lp-3+@
zQ73F3Nei88KL@@KLl{2*Yw~zzHh1&K9Zg6L3N*w0I+m|ngflozT864vLkqG}LXD4u
zeI?f6uXmj%MR1i^e@gxGPOKkona1+t>AFl1QxMeKdNjqI65$h<Ett+1G5#gT%uKt9
z0;i;k%lV{j@%2hl_CxH$<_EJatjfqdg&0sCeEZa2jQw#2D^NHF9~{5Hv-sVU;wU-4
zH=M2A`*uW?wtoHz-;x??lArc!@@u4rcnWdb6iOUJwa<{l+k1OKI~Z&fB`VWkp0M7q
zO+d2em8+4W>-)IsaTN(R4Ihy7sK5Ax;X-IyMQICco)dWWqTr|$zc%ggjZ|;1%GD{R
z$lJ+QlbpyCgEB(+4H4{mdHhpr%le=G-x*1NX(QGY9I=#!>1(TpgnlSTvAH%lygdxP
z;aPW{9|c>+(@Va9+1O2O$xrBFBlMFLU(MAiM>A3AG8TOCd3!$ZlM45fK;nndm%Hg0
zRtP@6*=wW+`g~)j6U9`AjeTf{Wg9G?)F?2rHe^Y+knt(@-(&YKaIcnbdMxyI>3X?L
zFYKG$kBebY6|W%%4^sq0{$yPi^JvLY(Zx&4t3(8P2-b8z7M5nW`<y*YeIg_c^?F3Y
z(a16ju{2Z#y0*095+i}6bsqBUbbi)No-Ud#p<$<}QuDW=m^8rw{SHMDygq1Sv_P|0
zqIlCFS)HcZ?XFqEkRDJR^`nM*VyS-s&xg*EsxRAeGL)I^tj^FK%nM@7Qs2Ks*qT$1
zLQ`RYf`SgT5EoaL6&L@jX9nq%rFq2&%XBE?1}c5%qEf@+4B<1$SHzc)B&kN0%*V70
zR40|!yG2kSj>RRA23N1Fj2KOUyEHWrG~Qs|L)$yqt2oABAH73nHflb0CEr?fa6J+c
z%m0!Dbcuj%SpC@NDlccI{=Gya08>oVosw~oXUl}&ujax@sae(Kea2MF(a7#t1rIC?
z_6ZXwbFizwtNR2y{}E1j(O2`%txjWn-RSF>y@C<jv@<dkp$}CmeQriEANy;|=Gu!4
zb~-<FVkz*x(wDg_vR_&&N@OguS9)x>oBpV|DNt<KSsp^$8~yd$Cn`BR%<qd7T~e{b
z#y0oj8TxdIawSxR{P@a2=v`<2PvE23x%xgNQ3euN0ezh-W4P_P7rSaR4<gQsw@8?t
z@Ffwstvax#BC@4C)xB7wwP-pzyxdM0bqmn&netsKLJTtRdVl#|ao*;lve}_Hmfkp6
zLA(H3W~>OCw+&3mmXf!B!E=OOJ$$g7(S7d?g^&yKtf4{6gMz~NY5{3tepHYbFt)W}
zF*LC?0<gH+*g=|{P*6gmu6BmTRscr|BY>F&P?+kdv6YI#!bF%#gIj@3!A=}tZXx3i
z0(@{+R5f<DGUhj-5*0xfaut9uumLz4Qn=b!104ihg{gk?6@WZH53^EH{3da<5~lj7
zpiCid3j$DZv2d}lF-y8yICD^mAX5l|OiTq-B&7ai0eKUqGIw;e6JTX^adBaB;bgG|
znX$6-^YgQ^aj<f5FheMq9o&G9hOW#&2kK`QfAEk1I2eO0>>Mp@ffUa?4UKG_9EGW<
zAoCP|GKb6>OS(b^{}k~2{+qpnqY0}l<b?~e9|!>}2OAq7GaCmp2S4jS*F$C%6#iZf
zbokSX5PPz^8rre4v#_z+*!<fH2S-Wgf64m~S2(CbddaLR00&zqkTF2g831&o{-;no
zYbS?)%5-u7JP-ZW+uFpG6{6H{$^Tp<EvumX_nK!jnpxP`{a*1*{ZC30<G<<boIuvU
zX-te+0oDK;h$0RU&g}n2?`UEAuLJtG{XEb7FN#3K{muX1sQ<FpZ(V-dRY1bl*y&lQ
ztb{Ptv%Uf*w#F7F0>2;GP1rb0`FM<(`2c*J%v?O|hRlWlP7`J$E^cFXQ#Kxc0Eg*6
zSjhq%91VfSfM-?^<}4NvKBnxZ0AoI5er9fCE<R>14pRVx84oWrfSZ@ogpG@hlaGh<
zA1stW77$M`wEm}7&#X)!tT=c~xlPzjO_)vDj7^xiIQjXR`3!lvnN3ZM0DJ&mPBuO^
zp5LsV&q3ggvaB!_2MgQ3MwG1$9ZhXPHo{a2hLCpmhkwneTG#+SI2t}%jh%;|jh~&3
zi<^(1i=T~~>t96b0FVO&<<Csn*;qI@e$SW~3rIm&8bZ)!VPj|pV6_99{hoL}7Xip_
zAeJ?Jb`A*V-{X+Y2#A9KhK{x%Ra;wYVX9|kDV|yW_9+UXKfOgj-q!f{!r#OIlV^wf
z)8*b8nz8<V6=MC*i2oN(AIxoCfdB9K{EPH&E^k1NF18>mC6JPlCBWG6Kj-rw5&z9e
z1rqEW96@ff|C>$yPjo_m;8g~)))wUU5BVPe_J6$n5s|Ddew&Jd;&&7fFf{(d{0@fB
z0F&QG0I}mAQ^w|oKr;X&-2Ulne~nxG2RJq{;^5>m<=|vC;^*gO=3?hHWaj5&=VLZv
z=VRmNG~zOa!13R?JJ^~!x)_20Z_FSVfSfbLw|<{9#j8Ky$MEmuF6Mw|Y_UN^JV!xx
zRdzN34mJU9$TP118ynRhM@}Kc`W$8d+Op7d98ypa_@_~Xp5v5&>@ylaIN8}*TL3`+
zZmhq+^Z!8ikM(~7^?$egpJacm7Pqx?gLtyJqmm2oKNbHU5dOhI-oh9Fbg=!;RR1T*
zA7=SSGJ@#*#~38ZL2@SR-%0aNs62bq|H03n5d1$V0mAyfh5VQ7``_mJZ*%>ZEbw0<
z{%>^sx4HgH7Wgj_|2Mk+KQkBdzpmW?Af)(nfn2Knx{~xE7jk%`chVA2htGe)ERJy@
zBS>~KnhsD<C^*l5p`lXJ2qA+Aj<O1p2wRBIShxZW<dzvwP!v$I5^q#p=k^y}TvgT9
zx=)VIW$A>WvE7kqDI~=t%b+g9DvS^s_ZSPc&*?9hW~S6MbzPjMbTzPwtRz+8Bvi%R
z>HTN|;ACtkwyvb@@WxFczaF#tAcQee!daWfzood@a+TpwLWzk8hl%z36XOg}#S8i4
z^XhB(pHDCi|MSD&bALaC{9i^SL0(xPCLuw?_vjlXcZFWCD0p)F8j-Lm*wHH~q{~!}
z8k`V1l=cl)LP8=Z5Y<nN;;SXZMiyGtjlQ~SXLfhUYD8!<6{O-<*KusbOa-VA^SyAy
z!it%G|7+OT>}DBhMGe43IW3gbBAaNymG7Ss5+cLL1+NQXha}P(-V`>2H|(#xzBrh%
zYpaGu1!-+;L;i`;*wqPURn7`SRIxvR@r15rd<#(k8nTL}f^jib4T%zQC9Avn9UdhW
z6*fE?HV#CkPdyq7o*`EWWm%T&zm|lr?-85>d5I%BQ?QA)`93+$`%1lK-k2<+s&yu<
zZt1@jorZsHF|CKHz=xkonG3d=yk`8UU!TOG1ijSe2VgUxm`)RW`Z;!9g<)~+aI0&b
zuh*_OqbTI9(R_8#&F9`_!rsOX4;w_c*Ktrf=|@dP_05+BqKu|@%3+D_exKR<lhkXN
z3_4iPnAgFpNO6Swgc?T=<ozNPwa#8~cMMmDS#8zHeLplXjl%@Do4uHryo<pG4{?n8
z3?4dyMEit2#{sekFLt$BeqJF@wNyyWlwN*$58)f-fgnwvIb$M$0mr4M4>1VI?%K29
zT&S|9{dKyI8`k1d9f>cc=e{$@Y1*l1TcSTM)XH-~Z<=Q`61>Ju_@2HqPc6US<v)IJ
zzsE?xLo|%RVykx`z}*4?_cM59dfxwH&KlPyIX{J9f=Xi;y7a)=2E`(?F&%;B=u(j3
zawFL8J*8NdmB&E8-RLbsp<S_={so3=9q1Ur?d18OCcB<b%6f^-^tI@<qDww!h6gMe
z474b`_#(HnQrpxThwJ?zez8v(@sX5e(@SVJ;{BZN42i^~azZqGQZ5Jp6h=uQD8jPf
ze)NrNo_eBfJjW9fQ6QuL)67%{{W}AcdH39&-ieIje?miIE^fXy{M&Bnzi>3ZB$pO$
zcgLvuH?qcC?p5n*3Wy<Va7QH}C~Tf`JyS#a3wYy8O)VU1pZ+vONY!0mFgRBZg827h
z1Q1kTnzGXsV*hJxmnK5~zg~rtBY$+x-{w>OO(6VTaJbF9>>ne|IX{(X`a~q2kvop~
z+xH~2;-EQojYo3Bjf?)VnUub0u}@xHx<;QnE#*`KAu9b2GF9qO+=1o8exl7mm_A{V
z@Hm7KkwDfoP%7JM<jR&}IDg<|5_^&YIx3;#SI8Q;JHb*$i2g`X9ciDY%rPv|ajl~K
z9|ftaE|?cFLYjE8VS^diJ8eil2ANo0;d=%7Cr6%ql($FT`pYCX9RZ<OC-iX5o<~WB
zIa=tb9S=rQu_inC3sE)T-rfKl4A&v32zfq+ZH}Dz+c@Be&`LGdNgVqNH+s>fG&$3v
z?pR0w{X=*5O3ISHtGn*cEBQGL5YHsm?KUcl#pBH=4>jY$Y)~Lc1Yvm@1<g3=+e%b?
zf7z3#Cs#q+yyUTX0Gk{w6v_7iv`&D7iqAo6Oq3{8z2tQO_l`JjJU4E<Gu_c2EK{1q
zM3<{KXI<+a2QGn?hF}miNQ?qgnHypVE~e5o@qXQR{#w)PF4*R5U+38fQ;rS~Fs_f`
zh0p?AsZIU4dpYV5xs;K^!C~OhdnY&BHh<BTLh^=4e0ezD%@&{W$W9(R$~TbHP05vA
zd;Sq^{u19&td>yQdF!V+n<1L<T0QK5fz@oN9~cJy-OoMkNTN=-SpdXMCC~*3l%G=y
z7YlfrAov%Xnnd*Y`tan2-CuSt28)#jIFxJN7BZ&%$OC@<LG$zW2P0%<`vdnB;d4yg
zyn!XVRQFLTcc6R}t7hCFFd9sDbV!p(tNxc0<k-N$h@>qUH9e-l(;ExM6QY?~=h86c
zx{?z9B?$79D&4>PueA1mZR+~}S#d`gQ#C(Gc--2$x|?nG;B|9z!zD;m(b5WAKI$-F
zi%v_Emy<*8>+3Ty$%%`P&q0PHr9YyEOhG}x+FmKa$*HJ5Eo&)7zSHgbPM<8jqUmJ*
zdsJdBWxwZi7)c1@Cnh#U0f`GY*2^vFPmLFsU;W*TbLIKdap;sFv@t&qoYjgT82Vjf
zz*+6p*yuP-Iq{{JgxGL4YZH{z8NtWVDNO1*{h5WaEIv={Z0r{L3?&rL7FRr6U-Nkj
zo(U+5+|U>q8>_8CfPnQ)a{&?t1(I!Bb*C*?NxoK8gawn|;ArSMF<Z@)s0IGzyN)ct
z+QzPVL^znHvtbV#m8JdtbRDOQi>AxD)?@c(OR>K)|M2R?%+ti$*VM$s9+%}(^9hhB
z@0}!>$30S-Vjl5(2%vxG@!Mjp=Ains&1&<P+O;-Ti50C+k3EAK4^4+Te~FZ6-PoYX
zaJS^q_q+l8oc~zstlRj-XIT5_cuE6hD*7)xk1-1illsmB8-wv)s|Qs_etE4?y=Qhk
z5$BWD(4ZB`@K<VXhQ}bjZhaCxt8F!#tvGtCwY+s!Za*>Y{DAuXJHUE5qqrOQ&m#-f
zYxcOhk^Fh-u&%&cX+HMt>&(%sxT-H-z7()Sto1u{eACDjY2KMCyn`-X^c)~<x;yl^
z_H3bmX($x;{9IMVVk!TZMYaJvsmb0uT^D*j8)Nit8)H4MSWC@8Ug2E}hnbXCy<!}k
z2>E~W6<}#yUf$<`93%}pd)Cq(x#uxbYs;ZKkImfVc7t<c^P=cF8t*-P;Z#94{-65p
z)LkCV_cR{0NCN<X>;W1&I*z?*QLbw}=SxLX9cMJw=5vt$e3@49MMH1x_w~=DBT4Mp
zQ=@-bkW{<2MEA#!AFH2GSXLKZmb1Tp{R;j?r<m3o&ydI4klxySt(2?O`iZsW8m4yM
ztIY$an|u+Nc{J17LLAqZ69iEMDQ;)U<EUBVH-33;FAqAJ+>Y3u&RE?XhJ|W?^I=1#
z9jkVjI5_@bgEn(6j@#pozTqWBAkf=?{zp;4W;iQ;g-IXw+WPv=Tr~<$YUJrDs70$T
ze@Jv@)-1ETek&~-9wNp9TATtCG5<Mz&kb*7vaWm<JSx0$Z*6H#=DKl(9I%9z7BRfP
z9|F0100f{zzzJZj{S6>-G*8JE*!Zx-^CVx|a!RGCscEV6_wlTr-PBzz-Q8F}CZ?~Q
zo$t-3&glE#Rn8W5<2_4^d;>}S7RGdOp~;-3^dcf9A3QUDe8_v1_BT%RfQt<$+tgPs
zVIv%_#|GT_fBLA*xxiWo^>wSZH^D__w#$*;KQQ5ZSifcW3olX1=B5}QB{VeDQs!@k
zOgWP4Hd6}gPy2V?Yd)@a1n<uNosQG#bM(EYzUY8Xs`6iZTpbeq!}B_<c^o>>W;oA+
ztg;Ih=!TXch2ihAbeu^1HiBrvZGQ}bE&1Cz{hWbvW9Xkr*--@owT&r_$Ke%lGHFZE
zFTgKLw!c&vwi^BV=KdgXR>$E2K-!R2?{;I!1W84R>~JuCz6Fq6n6s|c>J3|ICOUG8
zS14d|gU_nvJ7oGn{15grIg{>&0CpyZKu=zhOvJnksNhXsYzr5NCoQ-v`!i`ZRdswh
z_&je5HY!(E)0G5B(*F8|7q1a-T>cSCMotcfVtAE;lG2Yww;?(u<*kYewydmdXLomj
z-yd!W_w_3=J}x-!&LHxs?J8GuwaYL%C)Jqh;9FT)G;8a9n1=ox2E@D5PdQD|h<eL=
z6b*W#DbEk)gU`<$2UAG(emnDqa;yg0+370AcLmlf6OMbsvfXz%%)d4_Pr*K-8`U#Q
zd>bMjo}MHha?`-q*-><_tq{?J#SsF2TTo^TZPRuGT>NG!A{+s^TP#h|iGF<U@^G=|
zrEN=J>yxnb7wC`7__>P0sm7m^+d{B9%I6OX{)jX&igs)ID7L@AgR!GC%!KGf4WYE-
zmT8LgDEOY>btR#|i5-<dE((7B(AO-j@i<CCepOXmY7lfma-YmOgG<NVjopCWPn>Sv
zmR9KLNIya}Bs>eeR9@T7)nIbt_1xlu2#O?mDO35@kO?KxbP+H2!apxk0wReR__%Ec
zjeAOu_+f5D$AuyVN-;7Hjf<Y=V?9Er+i?XEY(q)*SX)Y|QZpsGsziT4i8M+SYWXNI
z_-v&$1K;`;<_fPVy$=zNe^<UcUT98x`&%;aYxV@MTAeRrZ`H#Cmmdz{6@@Qw*Vfil
zAr<d47)iwyX@wGDeM*pc7w@vZ5r&0_urhDV|B&V=^7zE4PV)&8=sJgZM~p_6jMSvy
zoJO|0(_NOjf0i5nrNcp98NA*Anz!jCEZn_v1;XWq_zu~z8}#+oNp{`6Oym)6XpU{m
zO^~*2GfHjG#329)4u%jlNKvDQ(^RJuz?q9fPF@PD`1|N{4pjFup$<3g=zI%{KYi1A
z)er0PpqZ_q!xb|o>~y6=qhfe{P`kW(LZ1Q5d$_Z2Ty$;H^VDP2%fz_MgdtRrvQ~dt
z&R#w$3*!L^LiK0E^MoSzY^0ul?6r7c-M=(^<<j$-G9GE=-utIEl%!x*liy)A{%gmB
z7mMy^23M|!y(+rl676^7o^9e7!eg6vPW8HVX^KsHtV0hQsY9mNIB^1M&C5J{QS!+k
z9;s})aY#K6xnzg3`9P`TcVyQe*9ZpSH3MJ$gnq%l!oLly2Sdr~QZ!@aIQr|S^#Wfa
z!#d*V=17X9ie@$*x_=$IBtV3-t52Jpo?g2OzC;Y}?35TZeV148gfg7je=(ykEiWH|
zF7-RL#Pt4DMjqL0N2#VP+HeLRk}5}|E%|phr3{W%BRC#ml%qvWHF1)W5#}}!AkD1N
zzPny0x3#K#s83V0w6uDQzA0+YNAmN48Kpw6l%RAZe0i(m=<Mm}n;+P`)11qIBZVz_
zC`mq-=OwJqKKpvz!{xk;g2LDvNX~}z0kB(ir;el2?QA7qfftYjd1oS7F-RQ09m@Dd
zc#l@oC&>@#6B5E`%331CC?71;$L(;IwC^}p-?l)`XKG5#wP^|8rU#24c+nKYO}KSA
zYC<!7{-As7>_v0NtTouE+MrU4J$bNLOZwsNYL!(<RJInl=x7)AyS@tO-V1iCx3i&C
zg>Q~UIIV3jAvq>@j7^J%Y387$70v<OFF`AjO<Qb!#<sx0!^6A3tZjXExZ)Ppyvl@>
z6k@8AI5GnAs3A)f!$>IZ>gvhqNf_q&);^PV(@Nu7$mK)JY_RSv<i7pv%Dt9N$8Dyr
zTt7_?uV$Q#M;4J=^c?}bgjw%gw)vq*LJbqmro;%73!Jf#7%SjmAnv)|bhQ**+)T|_
z$OyqC*1U;|3P&!5`}E|)ERwRC+UK72$n72uLe!5oJVyKMZxU&7{SnMgH!{ictY%mQ
zK0=}=qzX&fJOMAJzD3*u+);Qit7?!D4mLUm>-kf5kF9a&8V7Glf0A_>lT4|$p5*{G
z?Ifr#1}`7wRaC%~@`6@>8nDI2V&4-UgoRav1fTiO7V#Jv8B>!@B47+}B)8rtZ)}*5
zmi^%ekshK1!wiT<Z#0-qO8vbWF;F*mnzLra$|Rk;*Nza{uo_lr#&i1n<yac`8Bbjf
zfL(Tn*-cF_t;+;s2Xi(&B=#q7n6-6vBPTTH>6|Rt2t&$yFmYbON*pq-Zpik4mc6bF
zDrX&6!a`(%zXpE_b7ZU5t7~KndEs*8i>LoUmG<(hwk_WpTrUaMi5>d!R#Suh3DtNV
z?{eBi|LTI0o1|N32fr_E@7LWk_j#r?@x^GrlsV%5{{CZ<d#*72>(j!nrt@*pj*JsX
z!k`&<M9|Ig*Hl9d=H<?duY|8D394uoZB3Ybaf{|(H|=9^v*v9Vv8j%2F<PSA$mg;f
zSlkc=sb`w7P=AQB6Gzg}Bg`~67gQi8&d&lbtZRE#?D(i^nmrC%A~}cobP>uzLaGE8
z-w^B=TykA;<yJ30k_@lM8eF>)dOM~DIQWYG@}JLh#<u8fs$I62I?&M2sFmYGDC>cn
z+3P;SSOGQ8RcE9RYxNHdh`Xn0e>iM>!s4-ADuVs^N3s)3*bLHuzjs=k;goLAH>PAL
zRv5TyLBJ>YkuHIrkeWKMSK2ydIe+CUTs&R8V9o{iuz%Ko0(Y={GrV`9tfv<=gOiMc
zA0>K1Q(avx5d8;~ym_kX>9a0~RCtGlvXvTzlkUN~$Fd^(Ki+$U-fuvXkJYoHYSnW!
z2Q`GKX!pYG#Cxrqmvw^j=?E~;{jdA&>$R2^y$|Lhn@+k(NP8i-pb|)%FbDS51zp~@
zqj3`6K%Rtz48g)Q|Fk2Q_@my7??Xawb~51VYA_sK@)tKo)%5hhL}qFJ^AiG#Bf2aE
zYHDAKD{QjIWK=*LLH?%Fwc5-yU0uo_RqWgL@O}Xx(E)u1z8oEa{W3x6^UdySANto;
zA?TKnQjeg)pJg0cVGm7XcHUH9x~rq7V<nxbu8`oK4i>lr&59O)mu+wf#m7{0a&c7X
zE4yc)5IU!Tt~=18{d|QopDLL_m)2>vLuYfFq_~WqYJIhG<}xVz%CeyFN3o4tZAM<E
zH{G|91Ok55gZU2<3Qk`j?M-N1n%i0V<6Z;4>B)vWeqo|VPQoB=?6x6zzSl2ANZ?(r
zJ|#&#8d)Q?o!ji5vINt$E{~+~Zq>|PdWn#W=<mTvH3~!S1X@Q<g<YM!gBjNk2+kEK
za4;8od&-o}xj}RIpC_K|r?e87?-UVgWKiy1hF>m##y<iDR$uA)c=OEj*mN!q$Gr=a
zKyk7s*lFWQ1ly+?D!ul6=kaqTyn})#V8GGJ%Agzn6>vjpbwGC|4BC>HziR(yx&Ik!
z(vs!8%e26clF)nISCzB!Mn+Uzc31c9p~gG0xIL9e%tZvF@8rS+JyScox{OgylMm5$
zmRm7O@6X5~cUsaFDoU-Zb-9ctPr2q9h3StKihSWq{=t}u(IM27e&>h6eS`h&=99wW
zF;5R7g~$>DC16>$JYM-Zq8pp#CC(~{rG@a9h+rmoz!~swZ^LPkw?W&QEuNBvz~%MG
z`y6XX?H&*i0N>%JqJuh<#-63e7Yt8u6kSlj$etXLG?Y*_Ju<x1*B+?vu=^u#8;SsF
zO!~>Y8a(55NIdPu5$u#na(x@H!&$$dD{4^wQLAdX_$5!-eX8Vjvq;0$K~MB5b?^4<
z2ejWwOB084WlF2gT4|$($m~;GY`b=CCaE3?;+8E;Eu=<GxcS--YmZ-@N<w_^Eqc^^
z^``KUT4m%`ge{HUh>goL@Gz*79-G`MuW4>pOoUfLVO~{TJvJ!`_cFb{_3^@1K834X
z(q&B&o%<KyyS3J_qRgJ>S?ShxB6mE_FyHI_hs~n}Fm+;vY@5r<qCYijU66%_zO>d%
zi6u!W@vagT_6wE+gpnKxpa-=Pc<GbvlR3h|Sg+)cO6}Y`bkduf8|&GW#eM>4D&Foc
zYo561=%421q=I$4W>MtmVv<fB#`W3XUl%~qKtV;Uo%AUl{sCaBKuw@m@~v`(t^UV7
zuiLqIRVI@MCFz2DfeyY$TleW6d709W!=#oZkakE6qW60=J6*bkM9k!ai;y<7EFxV)
zb66#=f|LB_jZw&bJXd{L+P4?Zv2aSx2xoP{u-1O&yV?Db+jfhTVnVh>QGU-Jcn9@~
zXvblzCEH(z22MoD6-O)K*Vg@!tr8y-n!NK(+-^HbM(Z8V0&wvS=5wV)5sn2UMXg+;
zE-OYnSK%gF8D2tbDrsc|A!;_9&rd&P0avf44A?MV?oo({Koj#r^AMsgxb0Y&<lKAW
zv31WKf5eO9Z;<Mlnw$&}mNyt%`@X-BTnMX6Bl9`nSWzW+fvZsR?ts@^Iqry{NUJ^J
zVsBFHxz>#VaDqwwSLW~)nRKwSD2sb&+S-zC39u#5UrbF+4Q4(83XghBkVP@InbaX=
zUPx%D1*ra=65l5rbVxO5RbCSW+c1l3Gcf~~ZwanUN@UXf<_{6N$k8xib6vLr>*X$5
za(gzAX20};dCnFj$GEj{D-$=c&+tkaR#tVC#-8du-7riPz|RV{iFlJ*(jhJ8^@!V#
zW0}X1r}W%B>^@2=US5pMk>%aH@;Pf)p{z(!_GI}^0g{i*)24}}qD7)JO8hNLdls_x
zXqkK;za342_fA%v8_TrB$(PT-2;}x-k_5Z#%Hu!a?!A#woZr`35vbweT|YSa46I?V
z$wI<8#Cywl9Sln;rLtp)Y8SvboGBT{#Yfj4_)eNo_&pcKAkwgI<nz+*Ue}arcg#gC
znIAvoOsaA>Jr_oMG8N#7j<zajJ#=bo+k!wj^3GH(y#%Dtwntx)-mgG@(Du(78|~En
z9$@9VbA1Zh4!l2fc-N;P(;mxe`04{gFHYC%0tYs3Oc8`jbJuC(%D#v`^Y*PPNi`2O
zjhO(vQ3vM@6=h{HCE*fT0cbND=4IyF6bwDj&#^XzFEJ3=kw_f+xFb?Msr-Y`Q7k;K
zM`N<<9wJAskM>F{E<2v?Z9RfB-9&;(`9DL82aPss9N|au+aB8j<WXmqy+m!D-)-$B
zW(uq{>lxFtJ8rxpg~G-|^-GXXenoXq(2iCM3?Q%+*S{)-T^U3iL_I<io0hXXXpM1I
zf>~gf&|Um~)_B!&cXPcyGH;^qCkB;QiJv&&)aGiLJr*)+-ECcNP&xOuVPKwB_)F`<
zBX;Z>am%|JhSCtCsFv{+k7{o2$;oL6-BkXywX*rQN1JDDurBufee`=@6Z6%p8hy=7
zA7VbKWueUzdT(~6`5f48&*s@~Zy}OlkVPSQ$jf)ax_tmuR%+IQ_&r<*qQ@FprIk|T
zJ>Pyphk178X^kB}ZQiys%Aj*3q~q?D-gv_W%U9Q38~G#O+if|tMe4uENdE%W^Q{I<
z*m=x7mcQ^5^A-Dg_}Q&)t5N*U<oNtzf*5TJ3K$jD$155+ukE95+PW-lVPP>@o!VzY
z#lXP7aiJ(;fsG;J+KTQOx@4!P+$OG}D-Qr)9>e(ewVwxPtY3dnoU+4+QO~tal8Fzm
zZCe*#EvXxw*4BcyqH=^~I{ey7!x_Fxs^H0#{u5G-&C#Zb>$33@cVKK8!(W<SMiOul
z4MP{<<46N8Y_2!J=Iy4{lDdsIo-Ji$)#qJ_`s<*2$CY=gr>;Ux_njSv!4AH@BOO+i
z-a{{0TYP8s)V_y3<1`L>7RCi5(2Z!6vp4P%%FY8_!YHgT7Cz{k;yjxEf%?46R+X2B
zvueU!8WQ!*0NU1i83I9x5{Yom*cGH|p066P%&BX4Woa1MGFxu(5;&%1EY>YgW7cmW
zkFjBPeZ+bcz9YI9$z)XjUAG(Yw3pttMNu07;RhoEE1B$UVT58Qj|HqOSEjxt9MtwB
zbVV-6q*dT}Gd+v0bRSB|XDpqv-uxV{w0;?`)Mbg}?c56qGH*ei*8WGy@^sdh+aA{b
z^Xrex5mQ+|n;Vr8S|q-YEZr(e)LvZ-D4m?l+x{?;gfu>B2rby{^vGSE;XK*k4~dX9
z%OhEz#K@S6QGI++`gaezd2_J&Y+qWJDmTh(K{{*K_h+S46~!$(KNh@Ce%$Xg{74hE
zN3BtJ4bU{bVrc^Hq2|g%{*!oFZBpIJHG5>sQAlW)374eq%LbjSWyz6|kr^=S`@C;W
zY0+`Gum1X70A~Frf|G-mhta3<{k^~fgXilo(w<3GXsYBAluj+0cM-bnyzRct?ZZBl
zP6Ls%S|MqU!z(7HoT{p#u6d%dR)o^~Wz^whw%GL`jEzkT`qSyf8M}|Ihgb}G5G(PT
zk@r|tvQSrgB$m}WtZq;fH-~=)i|Kd@!G9|(^x#_`t*mr#JbpL%qol~X+NSmT?seZ#
zpE_;$@4Fm*_K;9v)*uRjO+n*JvM{&1m3a#9yTqH7+#%%x{)8MHNGroEycUbxYJIgZ
z7t>1c*zFe)15%USM3+1<-Xk?WDm*NG)R57k@Qhs-gS0VE^**{w(NH_Nx6|9~BS=GF
zZEZcf0IgY%^$|03UGJl6j=w%tznX4fVFPjLKw#+?y7Y)hhbpZbSP_gT*JHgj!@)fY
zsz}b~!l~8pM2vGQf!n(d^g1mQ-sSRBj_IR-rxtSM+g=9S#;iTM>j}1yDSfg~BS;qs
zc*4Vy>`9{=M~q&r9v&K8Dv&z=cp`$LVT<&LuxMg*y6Rtd-kD7}UZ^c0dd47)3IIo?
zUb|mR2Mt(PW0Pl!sj1P9ot~@L_V_R2-*=%zzDW!r^WmQI^x6Yl>x#Ota?(43$E+yI
zcZ5TaW)lMrn?sKh{D!c+dllv7Ob6XGDvXu}ick4Z6MVXYZ6AZrSXxyg8L=td(HnXx
zDWHVvk$_02==B|{1e1BW?PVX?UV1ML=W4kc@_H)6w6Hz8FW@1#0Q|agoMW~fe|?!L
z13u)I&D3fRdfp$)uNkLi$S(dm0X^t1nb-`M&?UYLiCkSUmgYF98;cBjl*uo$x4&60
zjjgRc*~+~0)MI3PeSCLM+Cpl>^U~fPJd-$OWO%a1`VF+{zT;X!-~~?b5yo1u1+~VQ
zM5Ib2QU=FFk5O+Jmlah7B$D|AIFYx`T4rt?y6KPFu266nJ%5V>SJ)3bQxwQ6PU619
z_9h6=2(@ei4UgIL-hu#S;S2hV3qstm18sl&moN6G3}%q8N+7sc1HT?dx15dbx6Bni
zMfMmdM0XWt>Fy5bfM>JcprAwDi(0g_h#P6G%nz{2bWb1ePmxN5G{7L;o)t#{!ShAO
zxG@P85J+Z^N%Q`NdZC&=oCQ{9PscaG(hjwX*BeeYi?<UF<Fn@iAfe0afavL=`IwFZ
zz;ea*V(rgb3rPvl53NXfpgYbHW1hnBwBNfZE`uM|LlCVx8DfruR#g1-uAx2Py5UJr
z4ato5hXPGQkzR9<RY`M}<h<)jSS3HeTK)KLp(T7-R5bC8a3e>BkCGI|e%H2Nb9vHy
z-pl@JU5})j{WLmp0pI1Lo}HquU!Y*2rN&|!`aB~pc%ScfJG}Y~zB1vzO7AnAMwS;V
za9rb(fjB;rPqKNjqs-JfP7fmFsWYX<hbSX4XG3{dcRHN<u5s+rO3JXmUG&v-d|NNG
zO(kn17Rv#$hEpIJ+WF?9$_sj$0tFg($oE@~LbpFNwW}hP$dY9(-<liC!TN~>?`oyD
z*2Y7Wj!KuLeZzcoadX_T==vZ6BO>bOoB5RPwg04}SDH5@D*g5?75=;9W{eiy2Fy6w
zbq5+x2mx)>;5Pv?h0dB;o3&Cx&s$ZaxDVo5BYP*uV+;IES3hmA7^I^*qJBLlJ_eQt
zF2{IDO78!x`I0_gQ(>k-_Wh3DT>fYx@zCpTtXNtJ9+m9v+t`xRcUw6FZR1(jFv^>s
zTv0wcp-(bO<+KG0uMVnv=9G3p5xDpz6O9&!E`3e5KNhDY!77Eg!tp`Hkye$rXOZxR
zonE4$;IwOWhHk9e#q@yddE|}fZO84V5|2FHAUk{H)4|ovtJkk>?v_b1d2@V$T)V5h
z;~XBfHlgNx2(PrRc|2NfLZBzS#h=y{+su&<&zG#r*?z6PgH)4EPEX`oI-hk#SxonG
zBT>nmKlbi5=(0>d)WtsMmFy84QP;5k7&E1<qz_7F8(7jtW1~1b67pBi-y;>k?;s`|
z1@63Dxm`S710HMmF+=t7lx?TI`UX!YHluZ2$8$PQMu1U@8gMpFQIZ_a1m9*7pu(H;
zagt@cTuoga^aLAKWB$_L-5Jn-9h3e|gvk^qP72NFyiLz~`1QA(WR@cZeP7?XxjCLE
zRJu5ZZT4S%eX{bI-sLTb<5YW_O%auB^rtT`Js30_Bbw)H<Kp>oQ>j_D)eun0+7k}y
z_Xn1Kt{GkLBSj?JS&t3~T3KmwJ#l6<-_$Zaj-cRf!HGhfjcsz@ACJv5X`eFNTj=&}
z&%PrV%lR<+o{6*_!(%n%pv>-xtxFg>Nex~a80`IeB`fmyfGq!{po9txr6UMMCKIy2
zgEM$+BAUbr$6=hJzw|5kDWOe)->xUOL3Uq4pdu}elzB-i6Zj*&M6Vll7gCn6tUs~v
zB`@iIXh+>Xa1dC#LJ+0wDa-P|ppC|7nExWZ6Qy6XE5gX*-BWutVsdpm1rCOe3uQ>u
z$BTLJxw}2vAGU1?&zL`0OJ&8k+q*G4E1mZdm-N0iKDq?n`w`ftfN`F#Jdj-u#{KBt
zE4hq*7q2r$DFT|HXIZYiBWO}ZK68fUHpn|1ZqQ6jYB%L-!|GFhkG@>XMiLbg_=FmC
zg5<Q?%23aeq>I=(5L6p(n2Ixf*QSTolQaG0T@JNY-LX~6!{r^m&HD9fas<(2-q{1B
zQ$#dJ?{Co)Wh&81=KA1$nV_+D2`9>*HnEd)X!zNt$AHbCcHUphd0|YN!~1^hmP+O)
zkIy}i8vmZQmnd{;>NfxiBA<%PP9o7HW^#NLmpaQ+OxU8Jws%aMvBBgR4slv3_`tc`
zXh$WZ@c}=f=}|-H*B#YmeYgY9$%UZp7_Gyr=G)5&X!`f>j7PsO)_WeyMnl`bg90)^
z%NYb<mAorKaq`FEHWemeH+3~&!!7o&U0AhQUt_WJu`T0qD5n{DQR&j5eb+YM#(yo0
zH|j&LQ?RVM;|t>lg@RvoKdce4IQ?U<&wz~$XfE1~b`U&rWTtS*GW`p;3{uN~8%MrO
zP<yYc?zc>CZns#IQB#uz;>xv3WO?4G<$xT6&b4Cdp~GG3$Vy3p$+qSM8`s3eyg7&c
zE^Xpj6rO&qYpdws1Hv!bJ3gyhyz||841chgg)IA?I+NMsYu1`=pqoQeHC~hJ1Zn}f
z=VzRely9&~kV>z;yd3qCYjj}LB>!cH&ac8$p+f_!dpj?7WmIXx)fC*MXk>qECo^H(
zP<2-plz!eeGs*>7-j^#%4+fT;!p>LjD`TFnd3CGK_uqFU*<PW4o^&g7WRsMXEYh1e
z71U2~zFk*cKP|J=CfjqtEo;n4t0>SivQdv+Ga_1Oe7Rn6J4VaS^6id`D3T;&HoSw=
zgY@_osrEjwpV;id*MMu~s@7=;j(pVPd_RlzQ-IA@Eeg{0oOhbuQt(sf(FN$|WO!<G
zoXBpz{ZH)16~^WHwFltMnsA1-NkwhV@ohRMH14=0r0Yf!9_I7-1aBZ`xtLv#?lL(9
ze~8qkPH&wbRN8N7$gfH^X?2PqdS8a|69GrwP7RqP9XS~Zc@Mme4LgGIiIcZIh(a;i
zIO5ooP9C_1Ww8WxZ-sGhq498O$&q8$p;11%nB^Sv*?7G>5^MJJz*G(W_8th?b-nNx
zlU5~OV$VA%Ihf|g+~}1M@UN3HN*CTEX5GN~b>j_RG9BmfF%nKsvBEDs>lg3U_AHN^
zFOwG-0(_Ump>^AZ4y~+u@6Lyu=buWHo&vc={J`{?QyZYqb$r8VZYZ{*=RWD*mh@X4
z=$h}$ILv>tkp@6o64*srtb<EWCh2@Q_fAmqLa)v>QQ5e150~96oWQo;L`_<7%j(n1
zo4g{|rmSTIbg8SSxP*zw4>-Gr{qH(%yE?RC4NnsqWN(S%3`$bJds*Y~&ezPe+g2Lt
z62=MGBDKNJuOxT0eKSNEf5W6%!9_Ly15`hk(?t7aO6a!R6Tf7sJz8(E&VHAM?lXx@
zV(0A$SCNz3#})wn5tCjQxn5Eaq>!;Yir|!S?38HI0ZdiH5%2T>xoRE=MB-U4b`~3U
z!YK^<w98TT72FyVD9sM7jXpGtTJ6`-B?=yHOk5w=(^G*6nyFn+mgeh@GE3J(CeCzd
z-M5#%RTW+Uocso%nxZvD(|9|reJA4fOi?lg;iUctPgfZhRoAr%>25^2K~ki<L0Y97
z>F$Q1I~C~$L8ZGpmF^f|=#b8#`3^q5-%qZKIeVYI*1p%h@^Cv9Un;N<&%+1vbiaJP
z23e@AYrQF-4gYEU>tq7P^1x!)J|rarW#<@wZaLDB=n*f)Gmj96mkSqu`u_d<>W0d;
ztf_7&9f95ZZKWn@{N$wbo&C{`I_(rLfJ$P7xdaergnkOQIGeuQIlWgRs^$h^rHDR~
zfYGQyK?d(9t|`L8=##ANx<m}yRdTX{>Wx1`lvL+FZ3p+B%HfPdVIUznZGZbOL$tJX
zPLHK`f=UlW4mXK?z$#++2(F1ntV^O^JJWCZ*kWY;$q2BH&AaOMM%eGtkcy76_ASb;
z`AhEzX0bSUFhu@<PeK!SkUA4%L(X+X@6COd4-RJ9lT$YCQ0qcn(SeGezMbgd)m?z$
z055aeb9=s6IwW~i{y0T5^&XE@?`b$=^N=;xvgv15`FHf);!IzY@u8^u$s@NC$HV0X
zs^7RLUfK_5A3QTh0eNiqe%a;UzE++>q<DJJUb1h%lmX%fR?4wNkJTLmb7uNIkhotk
zfD>Z)4WVO{VI`;Mmj5-dQ+HbdU+>jcWua*#WjSlln>KPj5S}l7*Fl~E=A;_SHMR2?
z>q>e@I7v#eBxohc6KQN%D98R6%Dw%Sp0!@0VAbWVFBwZNk_X9K>uEVZ9NG&pQsjj5
zJuul%#X7H73)gF{^eI(3c6#nZWLZUI%xLvr8favZ3IX@+Ekgt98Pvmpf*gEyxC}0_
zC-wRMco!|W|3R~Ri7dge?27*zl5ZtQxiGqU`oV_7ak@Jxwo;(mjYsiIuRM~fj?Qmc
z3h8p6LIA@ruUavmnm*ZSWVhNg6L2dV+_-ALfcM@I#)*;nlmYq1LlO)&G&e75N5`%9
z12?GFJq%!KmIsYJD#_bV1#)w}j-Ik_E}p9GJ8IP<O8_qKB<UQxec`lBF4Qu=$==pm
zq4hZM94&87r}19alN~yaxo>e5)B*kOGwLN-&$o6zk^n(HH^7*2RM~^kcqG30vVZfM
zrw+VxWB%ZN<a+~e@3ZIEu2a|a%dCaA|9p7ZDpQE(wKME8<l;J|zCD_J_%Tk@9}cLv
zxP2ox=<a)}7S0L|<9!N*%w0fFhtb%m?FLhoCkWNIwge~vC@tjIKX7|`m3wq*mB?{R
zv{As`&^1m-x>nJ=x)ju0>EHKLlB@Jpz-yoGWW;T^-|pRg8M%!F-unht6+Tkgaz1Bw
z55pOE%DoMDTk#o;Wu;c<W9Jjqb@z`I=cyegG=`;1y=5R!JilR?rE^y4%1hI$UEHRC
zmEn1U=)TE**tVPSg-oYgtLM%BMmu9NSaD)tC|PU{>b@+=(4(JSTfGg>?lh{F^7Bb$
z)gViHKG4h~%<GLu`{DTGplW0xa=ud{UP=37tk(mbKLbznn9;4p$9`#MiiTg7K*KM)
z(<L|KLjVUSz^$W^Pi-{}ji)DDF2p4sEy_c3MPt4S*4=)aRF*(yWPtY2c7L|4RI5o~
z9bD$-<+)X3X7}i2aC-qpG`K5L8Zxrmj;mW(su%CHwHL{aC*_wgL_}GL>q8Upec9l5
zBH$02(kH$%!`%GM@JM)hI6)_@kMs>t&lelpupARF1hY8Y@L0-h7p|@jv0{p~azR4#
ziX3kU?1_;}1|CUg?;0rY+iFEiElLALOG6P5RM!ud4o!JFBTp;ao9)A{O6n!l6n0{n
znL^x#R$Fc=*O2C`aL($*kIYwe+oTOKtvrANlm%;W_W7lAGEg|hnFvJg{I=9D4Jy7n
zt)F><OG!Deir_snR>XOU(+}7EA8&R(XJ(eN2Zt2amnL;rY`a}M&mQQFWh?Dx=-YR1
z;_>f=feY$|(dp6rxRCyIChhVcYY@o!yo(R@>RE#{IclQlHKN?kua)BSaUq2Dht#(n
zLvui*a<Eh4DLDssJ-34&8z<3pe;doA+&8_b?#bl5|M908wAp=3=IG5FBOhw2yJPb@
z8df<X*y7B{Pr)0jF{|=MmeJ<^<&eucTH4{MaYO0_U81|1hDLvfA*g1i{uqkXxc?O^
z)o&y8VoVOrYB@ku%xi-D=eu{O&BDYZG6zmhy>tw?8L1z6dA=DCa&veau_u?0iL74s
z+`12#TeW<E4If!lH0Lqm$vE}aeaa7{i(soL&UCJRzR*i%(a6`W6Kb=4=kgQ+tqaFn
z2%7rQeI{!g#m6>pkaMoU;FoUGo<Q)AiFIKhsxSKbcB^>tl8c<{!5h~tPbohF=ttQ#
zmYJmb=xwCW<g1My|5cKXgR+RNH0LWid<M!s*k*0>auucXDsNnLkaJj_T+3(NU-wUO
zr3eqfX8~<3D8ecQc&*vbxKvLU!zLxDq<%sA$!9S!(<`;PQ2x&I?$E>Y;B;2>hoWn*
z<JbjPkiS9G*oN^yyp5BFIyb4nA<v{Yl(xwS5pg3>lL;+q=w{h)r@Ek$H~{b#Z_eF1
z@*TXb!J&b|beSFyNQPcfa}lbA-M)uHluNI14fvHG=pa>1=<Z<Z@a&p5(ja?Lhj6r+
z)KKX{@tyl{!4owbcViR1hTjvJgU|z?&nyVkx&Ni2DfGjbU`JQ^<|~bg?S+i;er=t3
zww&YahK~G->|RQsDungJcGyhci4}@avnVH4<d2pTe+|?N!QD)28&<uhvhtF9GagSb
zeB)SS`(0{r+U{F^eIr-qUTp!{yBBaLx0tC0_}%Zyb+qalk1)Nl?MbIoIus}7Rjho}
z)zvcvFX4U<y<W7<*$BV1SUfG@H&Hb#Rk|Q$nr{r9Tpr2U)cItxo5-CyUkG3Eu~}Gz
zXY&Y1xpR~{$n+j%8{X~A?InNi+*AwZ+pbh(*$xx!X+L9D?(lQ}0zUI@OG-(p^Uh*m
zC^mY_BQklM)*;l@=(KSWnvk&RTaz$SAw;5XM$Y$Oj!5cZazaEUMDFZT%``mJW8N@T
z0s=Lg0iF3-K;rRa-fU;xrQz^}2$1bT{=nA$5vd4(2C4Uvcp6{3WqsDh?w-oAqC-zn
z5{!blXWVK!eV`P-_K|wVkuOYtI`-UF16XYFf-S^@yE7JrgP%aAFo5PaQtAsh4hsgo
zkHnkZHtm5?pK}{TsYSA9=9DIh#1@xiDg3(qprT7`clFxC=m!&D_eTYiX~HjrucLd5
zq#^5Q^>+=hlSmf~bsl3H>`)&_>GsC)Y!$r)5kPJo!P3Q!p5_&|3|9se1CK}Y_am9!
zKu~MlW*bM9)wpgUB0k#T;z1n#?)+>BG+;e5JccXOF*h^^9qz5Okp1`-%xQ!_Flzk}
zjXKn!-F>jnZe26RZFz?Ocruuie!xUCiDUJdZ|~&&0S7;PHYu!+Y}dU3#{vw9J%qud
zYsbuO?OqG7bQow-K$5HMp3q;5V_|%Sp>Wr8c)I4`ppwhB8$TBI`2P;Lj71AEx}&k-
zb*<*c&^;TW!69k~GlbwhAClGw_0XY>Ip9D(y18+K?!XYR-4k1Uikl$n_foeRA9ify
z)$=fH9eCA7){Jhug))O97y6jZK2g1HFjP+gIxSW1bBnRfrlak^AH5)zQrMUa=W0`}
zn;~MH!+*|;x`SKYjbW3|mI?pS!7#K2!@Ddd%MqPu1)9Qhqv+S4)jRA%@t!Z`d!hU~
z?a#u6wL)^Yr=!w9yRWKiq4qq)pI>m6xk@n{VeQL$ghB+3)lu#}D1`9LRmyU@1-8by
zkjlXz3%`%=_Wi<Uo!?>26Jm)T0P!>11RVIb4NCVXi>5{gk8F>|rqjFFRV+56-V9b^
zHx#wSd5fHp;z~=0mK2&_YEOleMjR&f+NaHWRCXnNyc9Jv?{r=*$sZ>s_fE~JY;36{
zpKUH7(DIw`St-uK4!No*<$tf;gO%bbiCs*e-9xqE(XG^aMd9$)|2~n_sTT*Z*K&X>
zypYpQR=36edXPq#^T!Mn2tn?sYUm9Yk1av0?})wsy!H13FZVLg|LJ_@y!F%E^+$$2
zdbE61KFb{~SK*f)&~8JU9<afqxbXv2-cf?YlrE6_-8MZ*f-1CPLiDW+O^0y3=ni>u
z*Vp5U&GWWCrKd)Lbx)r^I9iJDb|>B6DJXbdE$j$NX_IndKrSN{<nwJk)CR%e8et?^
z6Kc-LQ@i(%uT@^DI7xG3J?(H|jvYwrtdDt&v=q~wZq&EZ&+(=yrm_;YlB@I%5$;>w
zhHuQx85BgW(VF%x=>Ax2ruK%vjXNx~z;L*HAdZz8?O11C$Hh&Bu8!b99<_NzJGF`Q
zVx)zQXruNHG-=_C{jLU^kDxiwuzizmh=D)MqZVpGefPv`qpR8GUuR40qiTl2Up`%%
z_IqZFI1|S%lRqh$J0u(W2}w?FxCO{(cte+=-^+g-Vw-VtzZo)n7k~8jnzYXR1sp6Y
zj|0M@{bE|$j$*Gh=gj_}6=Cki7M&_iP8{|xK%usY{r%BR%uAxguiR1qFVP-Np^$dF
zL7S^z?n4Nk7<@U!wwgRALhClZhO@98urazC$A6wC@ZcQk@|+fg2fPNrU=IkdtrMab
z=<S84^<DOO*J2Ivyu?^?y@#nEN$r)__xEr8pwg11GAb0+ku4ZSTykU}|0+jsXY&Mj
z*`t%K82Jc>DqS6|eSwmn-<LEe-OcK>`K(+Chj=zgPrT!6SDPnvSTu&W2Ze9DE#Iy=
zz7=_F^O4~#GW3poHosBba8VskEY?GY1{<a;t#eK-nRd;PJQ~@v@s5@C>H!1Vyq(<2
z`b4k$v|-;hC3E3R(lp6xSB`hZxok(&W%#oy`zXa%Ap<{+y*OK|uvVPIDP}bZ;rkpz
zaM%>WKD{^6dXrjk@dg~ghPiDh5=aM*V)F3j<1Z;`u2pCO`XK<jckrFbp?_7;`Zx1Q
z2p=I?uF06l`qUy&_ATjMe7?e4a(eTSdIe4YbwGZPfEeC`lPFvM5*-n!faf44Ireje
zE;oGn&RK#RMyAjnu~@y6qH&^s#fBJ{6|pdRH5OF2aHuGB`IbJ@ks8eFU@`)QR2^kV
zZ?Zo9oN&916Ah(N=1a>fkeRaR4506rd#+4zUX`aBpHhQ5ymRn$25CJ(MLY$ED<6X?
z{O2iVRjN9_{c`-se4zsK0sm2k>`U5Dc<IF%pd_YdGvip`W7^NG*rz~_G}a4#Uq1dJ
z&5iRg9vLt}UgX@>SIyIku?_|Y2NZ3;H;tPiG?8^PqD?A}^Nv1ko~<H^v&{i3qBIyK
z3o(Kb1AS>D<_A~AnWM=V!VxaL++Mtoe@e_bye};MUecP5p1pBrPsMZF!o)UuC~qre
zpO^K9bS+(9oD;_$&iRa(RB>!puA%eW^6eOUadXeieAGzVC@t%&?a-sIN$cG-H6g<!
z^L(znz`@*aGtyMj*8<tGx4zmIlFRX0tr6}d=NmyMDxMC#gher$Mlee>CpcW_p^1O|
z(et(BXVG5EM*Y0jZ5+As(a%fIr7nm(*0rvPOi^uh*vt5~-+(QLNiGGC^6uB4PmZKK
z9<$x3FqdSd#>m(v=cw=w)8oN67gupMaD0F0>+fH`^gi+K@u4@<)ARijZ}-Y$S_|l*
z_z2vmq0wVPyc6lU^Y=E(<n7@0==|T-xbLUZF3(60s;bC-##CX32Q`vbPv?9r6z*=$
zWBZ;n^=g|OQ@486P~X@YjV;Y@J#^2<Xk3QRhwfhRRef@>XznecRm9lNMw5lb2W{<{
zwci?Q;Cn4qA3f5CIMPrW{%cv9KH6H}vp#5Y`J*A<)330s7QhX>@*XM&H)RA0x6JMb
z2>>((8N`m!JHTLse%cf*^J&?;p1#{l$NG)O5@&R(MrwkxfM~^({7UhJ8&s&GFjHmD
zuK0U3NljmWspfWK>gW7^{AUEnNsZy)08%ShIkAuYrNC%vm6~`Vz=`_t+V}`_utGyW
z`hN2MCg*(No?Xy%A?h7-kj|({-30Vx&2@|<q;KV-G>N_@v{s}|N3Y(`OkKR=ak-yN
zk<V7FZB7>JfXrl`=W{|T@x{j2usK&G$}g>q)R6_#H)p#ASQBNsynrIH+=%+eH#i%9
zOq$s{t#Z{RS7_MUxVq&q%7uO}kXKUCl>D2uFJSoEfxMp+e*<jNQd|oJf!`sLsHo%E
z0K92UV|~-RD_e5!-BV26cKyCQ#Tau+ewwVnjkv;{N~+%CZzi|WDbB$YV!k@e5B)K{
zB!Pl`1xT}4H!{J2YH62-pzEJZilV3Ay(=iP7hZ2hW+}?x$w$i1A70T1xAp+(4insd
zbNVdb`_ph@PLoCev<N%KWJehs-0p)A;ST0C`-^QFK0~9?K<*`J2NZ;7Yni;$snldK
zfM4((zElor=Mt!-XIVrV!|zE)7P3Bc7F3iEtoq@$d?<}c05n+WfqG(XS6a(@lAVS-
zvxS~ol7-KPHk@&gUsTSQ5~C-!kW(PP@U$J>X|1`I&9zs&iT%Lfyw+PqWw+CfWJvAf
z;psu~;4f<5fR-~R3&Zg;1~6_c;-eCN17r;xTL(3lW(k#t26r?iIZb7fDNcrF7_Z%r
zib}UTskk@^x$3fW21X#K+rDpVE+XFiP0&XVA-x(hQsW$E3uVQ*MjQhw7bcB-i6Uyg
z$9+3LyYU5*ZX2yY7Z}iIvTQQ!d(ulGaIq2Wj!*cdqajATt$C80>7wdz?8yV??VBTl
z|J4FK-Cuxt*r6k!)<mnR(W!zoT3f(b{RV0e|E&b^7(Dy>ai+T6h#kS~>*Y#~?l7M)
zlCpIQr-=~senZ`sr-ekb5MGtYBa!hFSJ(HCjZWC5B=AFAYbw9SYY=wQ$7VX2njCML
z2g_B-6m~9Wmzu~#GT{r;g%1{58q}d{&#i!FuQEDr;*_FO-dB3r$i>_3XJr58>_G}4
z7=@*eC7s^B^ahuTGG{786YSU?C#<zLHYZE#I^Xz8y7#Ot5q@CLgg-E-NjfHCec$s}
zD;4@ujTK4moj7dC;UO3SvY&HpQg^bW{T$CVM()|NrsfRU*MAh7%SvnGp_5nFxaip3
z0qMmhbsMH%?4A40Yv-O!%XJw`Gy8e5?N7lzZZyJlc_V)=0+Ei^mt4lw_)-YLr|JVu
zgF8^9!PiU{Yui~YS~(*}h(Y{f)({r+c0MFslN3Y<Xs3z6X?FIf)8DF(_a-BbrbMaS
zFY4pNzCEl3zCgZQnQbATFM(L@na)-ij+KIsqSDWrncv-ju8ssn;?71Xt}V>#fe(Pt
zX;-KFz-JJ0(51lReijq>Md#5W_}S5e>MPnWH9TB731k%PcWf7*S5+mD`;t^Kh~ata
zof^E^TXYV~>qnHm{6P`swk2M4hcP0@bJ3b6RvtTE+kyqlW20PSH7;{2Og;~f+dREJ
ziSYi}5mGo<;l<zLKhv%y(GV)$xC@c<`hy-EPEMy(b|S^X?fAyySNqejb|(s>SjqgZ
z?`GTP$EQOd2lG;*FE)wRx^<8Hs%bRW_B$Gna^q1N4!c*f1htH)5nZX%QJa)kuivar
zeiNIsUi~Vt%77>L#~ukvwIKWH6HWVh*10ip5#8cGA<5(qTK9wb$RDZn=6uB6MzT;U
zP{p^8Fk;Mvvd8W8wRQ_}S9XHqkm;anRlWkvc~ODBo+To-?*qafkg#~)O&TE_Mw-Q0
zQ9-U(gm8JDsDjN%Ko`V_r?U^<)g=aX*{cH3xTap?YW<zsd!FjdRZfQNkeQsP_+SzD
zfeeSrPATmGik?VYHV8s#8rK;FYpQdU<K&*w(Q0!w{>hF?b#>jJ#>djis>=)V2)mB5
zkB-I!g;5QZqm8P+!knI&H9e@qP?Cg}3lp=N`8c~^Q=k_3fiaQKAK1A~f~j5zHm{DJ
z=9QKc-k8yaQ@DF072AsX-(SS9g^LPNARr(-?;f#P;B={tH-GR@%($FL*~_}Z1*3S9
zIEHSVBDR2mR8nV-;htn?*^`%qkk$Vf0!VAa@E&!=`??&S{O+~@YuyHN%Y&xW8=x#T
z^>Q|z{ngE}5Wzey+$=&Mq(9IbrLmIudQRtvp*sBN$o_up>7F<-qRw1|1qxH;(JlsV
zJROloaFv`(jFC#z)vJY!NeZ`d$lN64XzHM=7_jN^I4rPdf)Yqna$N@4HdB&~jwVAB
zzW(w{viyUx+8mxUcK!GP|E1{T#Le|Zu_*VE*<3{br{$~$BVC)h7I`B7c(hOvc4uL>
z&Bm-jxA^;tfvsLo3jq$rKvNw_i79M_Z#eQlBj`U6N0q2D;0%iH9w=0FsWD`Fc8={6
zv4zkyAbYdaJ`uqQkBm=R@#)_uXGg$hMHK1hy}H)w8w6>l(ctwo;U5uIhp(&{_#WRq
z1!u4L57jNlbUcN2?>n?cvgbVT51#cZk7`*WFAGAA_GDGMk-h{af5f^WEgpz%iY9`E
znLMqMC6$5~FXUxVbJ={yr-z5ujiTNo-5?C7KE>619H-TUPNaYFX?kw%oHjRR=ryzd
z6NLoj=Z`r2gZy+uxJyxR#gc&^lGhv=DUdhmU3)^ziO11hhN=F1xtw^q77;n^tHF9)
zgY5MN;faJTj|tU2jk!dxuBPZnq3=p1A%KwiULh>VX=)O&T~CDW9voEZfwLrJsjnVc
zh7;xRGgcO(KE;bzn^bH#iz5fRG9#owAL?R-oA{CZT4{fM*QtLI<+AxHu;-BE^4(p_
z`zpT020Pj1KQxrDH|}t|@Zm(;?l^0q;cx08&b|isC*hC*tKuxw2Jpz2fTG@=u{#lg
ztAk$feh$e4F)zaBqBzsAjsTJhx~F?>-%CMA&Pf!)fd7?Y<8N3s!qow1YU=9P{(hNz
zC<uha%6gb=3sN5qq=Nonc;Z}}JKfw7|4c_K^7ey|xEH^WR};m%9kITA#OwQGcCTb;
zUfyXz*u@(0ZN@+c?UDn9Cn39?&G5X)-QwJ6e=yccxC-d@1NzR}Z?y8=UYdsS{O8*i
zcCUsA%lbXauV=nDc<iQ!U6mmzBR8yTDHq8-E4@?_RR)h8(A9Utiv9wT6&#*E3D5A>
z#?EFSyX}ttYMX87gy0&74Ef;6B|K(P{k5u&W^iUV9H7d%SAztMrKR)7PSP_jR7ys0
zrK%oSK$vlOV7dKBU8wP~Easr3W>f$k^mv|i{RnN32AX)XVcxPX8Bnk_?Nl%_<)paT
zof9Ul4e&0b8Y&-sj|aE7AmPH30m1pTk%38?IMcvL;&Gt86BB~Q-WqY<{s3S2{^z&5
zs>br$Tv5<To-BRqrjD8!U6>>lZ9&i7gPs$gnucaDuuZi#6DDU=G%U~Zsl)!vu;x<-
zMHtC8zXFlXiv5PwWVZ_PE0NoEBGKTxM_&fEwoMb3RM8wHQKgpFZfd>yE48GLrYdqN
z1Vn6&mm>Hn$+5SMrqqE*_5zNq7b^aD1A{wJNYBbAB^BPofi85i8hj0Gu|^scr{#O{
zYeYv!r^;%ow_Io^g`g)TC;mv^$Cv~!C*o&gGcLlGOaH_5CS%PO1iF;bcpC^Jy=p#s
zy3E;G9T07XIe$596}Cl0u+iN@E@A8>tx>xJ=3S1y4ULxZi%EaCHVSz_By%|E@D2hS
zMtvB)#*cpYSB!7HewpI(E;-_rH*G`fcU49*si!r_1+XE|6r{w|aqlDCpUJF&c{Y}i
zX0os%rAldB<`fnwHTA7)a{q(_yL33-#|Jt+=*f9F*(hwTt@2AO-`^yCTLjlPkjKC<
zf`L&>!FJCHbuGVplmd~Wh7!Dv$DHH!5hMq}Rgb6RGe~YkLnJn5E-;BeNyEW`-Tx$*
zV!gc%Yq3a0mi?!=nlY8LGp5LtHy>%2;StDEqGIo&QLW_<vgOaHB3>SvB`}t8oG7Eh
z=a8t-b54)Fb*Q<gXwuU9L-_CFNfNg92b`tz;r^II8j!yTmj7?&CVx@3_B+_jleCJF
z!K-CVB!lby2QBD0{5+sR-I7#=Q_QYPJ*t-2E%kOiIri;1DVc7lI)=iIS2qRi*KWR>
z1y8*axMnzPH8N6C$<?0*l=VE<=#sP1k8)xCx`gDaLvAoG=dZ4=f<?BsG<l3Bx^J{<
zwy#e?0b{3mkGnIw4%Xt(?6zGS>%g%bEERi9Q|UnCUB~970s|&?Ms`U9c`8IfAMB&O
z;G!c?1;}5UDavN01JqvTfK3EB^?2)s^rku9SA;?Z=C?p~{_0YWVJQE(_30o+M@T?w
z@?mop>PMyUW(PF#R+FKS97E7LgVX2@kyx@<Tii2%M_2}-_jGQ=iv}9rpYhi3XVA)P
zwHcXq{|H6fp?H%E-`NIgr#RnMFKBMIzIV7{W7uZX52?P@kwS!%lL^PcctNFz_nC#J
zqR?}A&eOxWsd|y*dnDhqM;O@0+1IfRFEbR|)3wL_{wmKR@tw^}h>CJ?Gy|MjSxx&5
zM9X>D=^7|UCkhK{`_Rl<oG&&LBQFXXjf!7w(Y#0HZ}MUx#eo;V!I|hq$G}*F@-9U%
zWPA1}Kj^AyMs~L*CbXFTBE}Q`!CZc`eC#w4Dk^o8$&a@fH?<-2tMzA(P3en97w6T-
zan<|mE@c0@E34M_7PsG5UxxYulo#x}a7s?1Wpf5{{Qc;7guE#z-+;K6sT9VQTqegv
z*M}?CGASO}?~$~-0wc`H2Wqi#)HJ~LcCSYHcl5wvE-=>(AL4zEpXO#}bF1@xrw3#U
zdajr2c&Yh_(@*Oe)G<7SnqUo^&aRk%TJcrKvt~FmQ3qwV(T5xL#_RHqPou5F<$RRl
zLA1ZVWV@ca5E+CX-(R4Hx#Y9Zqfou@fXBfx%WxHl1)67!^?a6<>W_A`2P%5MJ$d*0
zi~4M*?Nqvx;&tCV-0(f!L1dIhE-D6W)8SO?7DHcAc;R%(+3M8a?1(N0BA^kTY*G$k
z7e&tHc;RB*Z#$zS++p5bwtHQ&GL~hBD^-*Z^mi=BuVrsL2_J8|_y=%}KBE49y;IHj
zA1L8X&CP||ls6IX8?G4b`}?16syD74Oi?OK`irX2e&%}$C!)?$j=v$XkAL-a%Wl{o
z$v`g3YR41Wd9Hi4p3Gn%t_!(Pp7t0MZZJO0mlhHqbOx@|ZHH)#8>kgC7+(L2cdQC%
z$HaGS$)OGE(8Dplyb>3eOz&D>pL=syW(mHAi*bbuy?kAHGQUx^J2<1|y~#ZM<GU$N
z#9ut8Kf2^y>HL=Rh@L1nUGL}0PjJ7hP`trqqd|Vg32J(x5_%YR+3+9v6vvPHbhgEw
z>lhVQPX7@jzT=8#w!IQ%x$7k6prPfc6+t0|ZB1SxnNAVUq2r2qR@7ItUigVP#%V>N
z{dU8!)5G77wGhiMP4>TY`G5z5hqC0fqu;obT~~i(p)F2cE&#33G7!8aDEr798qL;3
zy5?xQ1dO3-IgO0ZiTdz#Q!qF(B79JvUeu`@o8`G4OXg`jWI#K85p&c6cDRGrDAgMM
z5^76D5dUd|OU0xILLoLZ8_R)tn&`W-uHJaD627`g8~NYzQ+eOMA!r)hygrz38kl|1
z<L)5oxZSo;O-kV^A8_zIbOSz5sE@Z2H?-I5G(Z;oDV`rSnus-XeABv14m|_vX5{h-
z$pAbP^q99+x&Y$6e<UIGSaK3F9&~@J-nUYgQS~sBQgs}Qv1_#w>8c~`FV0l%xv9NL
zMCinT^B**`PQ5*yRM>Y~FcX#4nX+A;8!O|-6}>(C;mG*AF^49kbL7e66_1^_%_P{(
zXX$%cTDaHD3?nP6xW56p^SN`LfKUYe6tc`ZvQ*dvCr3!p5iCHAs@*9b&xlesrawHT
zF<_3M24>qcVj@NT-gdOW9--E&0EQQs_l}Qa+c%!l3q4*>)gKkl9rn^03c?ptaG&}V
z)5&)?L9RVs1dG?!xhY!TS-<OBX^Wk2X*g}mAxIhNy8S-qeD{VV_N+HgyC8|H9B<^E
z9ufe8Max%*f+w*K_bG=xUg}m<_8qGbdV*01&<AqzaGV_uOah3hQ*iQOZ4za078L;o
zP5gx=#<xm6e$cYMXUgO123>5fuu0}#J)(FL9j;&zKA2->JlUvL@Q=A|UW}<#!VRN?
zS~(c9s{j*Bs<~H!0md|CVrhvyXW%28?S0Fy3;pn!*7qR>&++J`4dqapJ}y(470_MY
za@wDffwk|pM2>akwM~`$PS+YTJ2Tqz00j;Su#*2wCE(Ao-TfLHpPaPc_uuwhx?TYJ
zqB2xyaeM<W)Ow+jd!87-fa{8E+Z)1-(`$muxjRUk=i-P_IQB)?xFbGUM^ow9IX^7~
zHmAEz>m()h)+_|u6X+~FJ%8<w(8FQ3JeSTd-FORB5;vc%GeKr2WXrmL(rB*7^73vx
z8@A&W`qb^b@G?z}<PDku@@PC|KFq#8njvm=P5586VTLPEe8njNDq(!o=M5*?ouUHB
zu7sjA<v6GBu`vris`oQg(cz>Jy@RUI%<X3<9u~i6s;#Z1CPt?sjD{tC*>9lpJ|;cg
z>*Ven>t@M<=eS?x*qb!WDwbXK(eeC}@6Y!cp{|IC!DLSaK%{Tj66IDG_sa($Pwk_#
z4@q<=kn2qn-wiwl(|iB($P-T?t!7teuD%@qY23ljAvsHze6BQi4DmMhR_0>B$hJHG
z`c*bc>U>2KQuMX_X!bfgK4_Y3r-Lu5zY0qE(^ZP&5yRZDCEr-c2Tk_=nH_&jw&Ks1
zcFWCXuT<VpQ=2?LgG2!Y5^cY0qgVyTanu?g({83S^f>t9in!3B&N$@P{UHC5WE#Da
z)tC?4Ap&)A<gfN|T)w@0m7rYgRsBCD%LBAo@1y{2VtU$os6nCQ6lL?J&B|S5dUE9z
zCkmw1aubBdv=4P2sYcX0H_QnKr?pWDmstVM%Q^}$P3$kVM8d-icRKA$F$RS6s$H#F
ztq}B5<a{vr(Vq|VehYX?^T+-k6$LrkvSmm-OIgoxhYOFdy~S+36ZB|VXb+g(@k|wV
z0|EquVsh>`E#{l;!VhnYBJ}Y041;y2<8J01@f+_da7S+pQ5sg*jg7{e9}ECYn)AD}
zy<P(PO(3@^hHH_)cItc0W&zSM`Thq!TiZpk*3%gx_;Q5mx2kC-hV-Tq+tN@c=j*^J
z6<n=4z0Rof!Na57J`V>^><Jc9!jpIla-f%g2lzO!RDJhrfHS{kl0aT^g9_K9@33(a
z_1$(T3uM9v7{k44fD`Qy@8)Gsa)K1#-UiJsVkvB^uiiR<P`pG`X6x+c*f3q5g}g@K
zN===fw3F?FNu=-Fba=bPvy(S|jZ3RIa&q(sHIQ2to`H;2Royt&uezdy0@AeRAM$Cz
zh3<hX=Z2Q8>6#h{-bnpr%{96n9=wlRB~Ni5-vLP<!w89ungkBv{lK|lgg67HN@tu(
z({{1sl`{+&%l%iqUL8+pVcn=p`G^4_Awo4apGD6vJ~1*fuA;~TFSqtr^&-dJ$T}Vl
z>*~>V3|#n8V^oX<jvuX$5f@wN?l0v#_mV0r3ALKEj27SmZ@t9g9L%AS*kT~;`DI$;
zyA|BwiLu}hAm|VpUivhW(x05FD?9KNk23$3X?D{8_B?fa$-ePb)3Cvq@9AwoTE;J>
zser85&QY1YHuod~_&Rkl{W>u_0#$X)BzzRbKGwCw?;)cixh;mdC7Kd8DIv+2l-bv-
z1tNUaVqp+Ic=3T{7;|%u6<{Jr%oi0Al+U!My|e(HtYUirmjM(JE#-KX@<bphX$-#j
z^@&Y7&uKO$>^$<!OD4!$J}+clA~49eb06oVk*+Z_V9aGz*XKQ%c7bsA3*5-WOK`9;
zN?xTH2d%i0N;#|AmUizJuZ68)Y1^^=+qcu_n|~L27AHvq(5l|Av9@HxCKKpX^sSp8
zhW5RfY<x%@xo_?v#X*nMt&6AM7?-m6yG10)sNunO&$UpZXErg&(>P3mgA=Pji`zx<
z=vZQRyMd#iYUCT{5E?EYgm<%T#Z~{{bEF^b$Tutj%rkj50wd)6hW;;4r6vjeoYF2C
z$Hz9oMq!@A2qzKJT-Apk-}Rl3b#zky@1HT7%Re11A|2q2_6gy?G)%4kHf<j5yYW`e
zadfc$$#aM-Vqk*>?mtXVd^lWbLsC*IOFj;lOv+PzqNY{u`s@@nC|T~b6l3dS$ry9F
zZ)lG5?{*#>U(S_vl%`Xos@eJ?yjfz|#s9?_A0Bl7a^VVtcPVCV&6p4v1;;Xi6W!NH
z1l;BXSN#D9x!3TdUxGAw)MbT)3?`aDC@o)tMP^Lp*>$ahARk}I0J#sTMV1>q8Zb3!
z_F=eNADFvZu=nSW1SN;%+W4+i-f8H|mTEz;=g5|0)Nf!ZR-j$><uc%DKO@FLNn6`;
zcUg+6r7tF%T9<_KhR7JNa#|uQ!)GR;>v2PExPM6Lvsh!1V+KCrRSpK*8sQYDDNJ|M
z{j@Lz+suiCBqwV;@BFWX{8tvMXFeZ}a>fUa2}L1fQhD`9a@8M#?K|MZj4P4<DfU&O
za`D9cyh)RLi!|$5EXW+zVqDQc8q(;5XW*YURQ?ZJ7a|B4mfnX@AlzEO%CW4XXZ$MJ
zozrs>zP-ECe(}GZRW3G9;*v7HZHIYjK*)|Zys3U6^(IvG@l*rT4S*0J$Vy!uZu-XR
z$JK4DN+;8HrK7efeMNr9^<;@B0J&QKdl2HqUeYIWw2G!6>7h4lYG}o&f}g-0x4d)t
z#l_*Fzy!U&PvTKm(xrVdO9{DVAY@V4N*x%Uujf`8pm_3p?W%7<^-tEN3ZJV%`P>LM
zjMJh+4Ye%W+(hEyk1=*nfFU+nZf4L%{<nKHBv*bgd^3FL?G9DXfQi}707g!gw~Vgi
z@+I%5fjBZ2gnzom%}*9rYM%qS=F7|v3at(xtwP1k<XQ}SUEYe?wMrQci2vD=m<k&>
zTp6SR#~(JP_lsIPgjR@4B+`(QBVxb2g?!I79RV1a^!G&wbJzvpn-zwovrjn*2Th!Z
zKT#T+J7mnCEM{o6T(Pqt{#&?ib9>uVKLdX=U+hVUmXRf)k539mFW<f&>;x6IIlbL?
zsHFTS)mb%F)dcm!#N1r5Cpi4gYCgiRpGdzD9A5uYsStB<;X(t(ME%_)23ram8sW5s
zlFwPp)GF>*mYC2cX)@A$&wg;8l>l4&X7TRvv4z_I4s&g{K*LO0uyy;*W@?ER_RyDA
zE=>z*1-L-*`?C~H8p7xrmVY}~aG1!K=2}7QE0rmCB8fJ}GjKtmH66h92YVcJkMKUh
zrWe(4{O^Cuip*DH><w`Z3g0VWa|f}6*@^fzu5qTAD)~Iqz5Bf}P#AVl-@gO<Z9qUk
z;Mk(iRqyvf7$toioAcHP*<h;{Eyqhrqi$!#=PAf-Kiky!-=?cmhPJvRZA9L1IlSM)
zOL$wGn2QOoRuhj<HRMG1a}E2O_Dm7v@d(j&{)8kN7&iNSE=g^1qK}PMkRp?5s&cQZ
zJMH=1V3c5lDwLe2H~WhhQ$rQKU<U^ar~fT6Rc$s@<mU5vQ1-n(OyI*Y3QyiSb91a`
zAF7;c^-rZR<8=^wD}HRO5(@xt&!kT6DviqmGfvptJGuWeWsh7IjJ_q(!$ZOfJYFl&
zG9iUT2obr9_-vhm`c&iQ=bUH7mj?Lev%dTmdAd+3R{S6!fW!1bc(X!@82MEjON5eV
z-|tdeO-GIp1-1vKAn|f?0Du0zi;^)NUxdZu>A`dd(_S>r+<*avpvgs7K!5jq0Jt<b
zXsOgz*T;tln9buH(ql{r3`ly$56f*}{L9AuIeTX^>jy!nWLne&MNN2OAJ#vKCA*~l
zwkh${2A{NN>+O%*&GnqN*g1trKmGW39_FLlBN?Y<=k4J~**~&Vl>)N`>?QUyWrzKD
zCCn0SDRsk}I&6lL4;zn~_Y>cJ(_;DW4(9JQIBm$>?+&C$s84-pXO$O5_{m>&h-_>!
zcwmxe+e!6q75}UDazBxQF9PrK1(GF+L)kwxNS7HCI>*xU{WVs!6Dy}1c}>e;M!^H8
zDxHZ?16$F=vJbxQZMJX(Y9hNi&<SJyy`nV=)yYW@s7D>hKwq??MDj-z4{>DQjbbet
zzyx~>qFF=-v`^zwC;%RT!}XBiQ8;#xG%yPKSqkaRj*kr;!a=Vbn$6PdcO(SdXkTC+
zTbsU@O5_OF5*q?ho_5*IYUP(TK%Cftp=k~*fVuoj=P!HsIh-M0i^IbYhvIGUaP(+a
zPUKa+Z|vIkwslW8zo=AM{<{}xb@t0&rbtH34jF0Dg+EmkQ$>E~?3B<E&drFX60cJ9
z0lAD^dOlq8YVrL$z+un5Z<p7H$M&i9hw?Jq>w7^l9rlB}K`5h@c86GW_KhRn3UxP=
zL;hjQEgm(V|JDiLDQj5i9`k=J*+bjuj;?KXeHT`cF^)4WsQoeeJi;v5y23cM@t``V
z08qoe{~bW)>@1I-^WIpITZV)%PI_vy+f4Wf%txG0PGzLyBR2`5L+|Y{F+!bgwlt|p
zF>3<;Ery2&OeZ^~6Ak=XRBV?~?Jgm6EGXKm2}3-t%dubvw%nF??55k+Enij|DQmpt
z?Fjw(lZE=fqno(y-Eh+L+EU*=#!>|H5ENjZ)>`P)e<ehbit#60?3S68YRHa##k<yi
zH|rb=2<h3i$gfH(iUc1w;sL;u-XFV7{evwawZCMMssOE7u4a{Ri|{fbbndfV2UG>R
zF{8;_8S!tU1-cFPWaM6(kyhaB7cYyN5t~z27G{)okx9x}8l~k`R|(Nr!H>_VZ)bPN
zLi=xvU5E2kctF8g(cZG<tyJM~TGMAT-f(O#NtRaW8y10KGMKkY0~O`XB&VL4p#Twk
z)}=+mw<LWPAit4X2hAW<FGPrSkoRl!ymOdJ%9QVcF{DHF9aU8bSVAY1XaMDXzS9>X
zR4<Mi&+T2I7fN^aN^|=sUXU=^>@>3)bW3CsJ0WBi`Je$k(>?N~yW+blmmRj`&;L}u
zx1_?pvmm}aqv|lj8KxR)wb_KUmXJBs{*d}oYKe3`&`8{%s`JdRac}!cQeXrH?LU5E
zIs1y3xO1lCMqi`0&#@Jw;h1idPjOJS$PFysMnKOuy=<LnjzPOt<w|jNVAcD&qP5!u
z_b=_6ur((}v~Swt={1QgwfYi(y5^5!0NEdOQZ`hbOOz3FSQ9tq#KrgQ^&Nsf`?eCy
zUrogSEn0s&Ao^B!9Qwanfb70=_SVd=c6gH<A^UWmZ5at09Jz9FOc3*7bmMvSv(8H5
z5=b~E%)<k$?P6_O-+$+uzrYC8Z7%NH58t|@@}sXAV8tIxZ#ES;4za;ZCfTunZxF|0
z#==H(iWZP_)M=-P7rEt&{&&zd6FJ9sXm3XZpn7PQ9Hbd}o;fn*$99_n>W#%l68v}q
zh!^xQK}eC(a*o}se^?>$N*N9L4Gk#>bbm#gzhJsEs?Q~0b7vfG$%LG<Lr|LJ(B(XE
z{yiyp@XObj<%(?F9^yCNp1E2P1A3Ox{(u)>oeFqs%t#)vIEj9i>0!F|P0MEw->+H%
zU#t=wroOI=zgJbmPT8hmCc!59CWpd1iOtd5D~pQ$a{1()zvreN`CGzOLJZ=j%dSNl
ziuCmKO7jsE7RLY7a|CgJt|R79&|SNoBGmpRkW#m%ls%Bfyoxie^RQQUAb1MO<*)kI
z_(JjGRqXfA8j3?N++00P*FqIOQn9+}G*bu*ldc2Nm`|-cPDI!^3z9%;0fYCk3t;pa
z8##j`0XFZ!<DpUh1vsq~%OpZYmnphvn3&ZG|6QrKuY^u}1*8f%buaql;y{P)N{WxD
zo|7>~gS*>ZpJ44@m4+W(dTY!5cX6v*R2f5jj@rg}9wMb_HvCKdQ@;#gywsOVH71wR
z9tDg6wsi85q_#HG|89jlbjgKX%UZi`;(8hL`=9IZ#{F=9DSepTxs2T4{Q?WY6846A
zqeoxD#E1x)zBIskv#{Ytt^xzpOfw#bU%&25EA~YN8W<UwS;W+wa5CedkaAOP3F<^C
zAoi5C4DWgFzfsv>B_W$L8_^W^ErHhGBdZP8Ph@@Gbm3|&2hvIXpUNj@wOvmFA%YL}
zdt*WA%)VD#6cm@7eSKnXZUjp=Rxr9;)%xna97b=A<37QzWKd^UM-62nX*>1Qu3Cnt
zr!xaN+Zq6c-ZC4|Q&Lw~YOw%Qa9igz{C-w2zJz|tXsI1OQsD~0W{4fqDZ&p%w<*_u
zx^#IYi^_k-F5p+<48X564ZQkzxEeZ2@|^Es+X_UpP7kqOE<3&>-~2@<)L9)ue@VsW
zAn|?$rL$J=E`{ANW+P58`G1JiGU-MJ6+KBfyj3^kd`v5Ef!|}Y3>53M3{*JlWZgOw
z%ix6LU*U1JewFvmF8MGte~|A92@*cEWg`FI)g3GcCZvX6U9st2{$ONB3iWDt5^WbP
zRFW4A;g~2n?$R4@=A*;Hs<)!0LP)ux7h2c;`1N{x+CryURP^Cj-}jOdGvj|x8a41e
zl?Gp0QTKphDc@#hSJx8*5@^SA$x@&?KXfJu@_Ipj`bKE`JOLXChPK-uCN%kQDxU3H
zL|MoQBU<4<z;q|X3_l%&<W%Z+{9zy-@8Pt22mV5ca$)JiG1v40m#=H?qv|+p#f^~O
zItI)gdm0gn?CKD!gapy-pD)xvWRku27eh`j93IX@h$A83qN925mo*p>7aiWta0K3s
z!BUnN6}Kw=jL6djBf)mTvu~hZ$Cj+(R*+$jLImlfe3SpEnMuF2Z{HILa{<T${$Cjp
z1A*Z|2t|z<gkGRm_=nZhWO-o(WiD^QG-uB1LW?9g{hvXSwG?MKW(NB)de_}MW4&|j
zSL*oq_?5N)yHT#Lu0{iK!u9(pwDR9yQ-H)Mlv6oEMC=Y<@dPKhBE2K46GG-16k{dj
z<H&s-6%-aGkTj#d)^w$>y&Qgn;dZ?OZI9g=N~y~I_rQ#UrKX|e2WIwR+44EzqXAy`
z!s51AwHmCbyj-~-+kvT6%^%^Rf*x4-*AH5Ce~?S{n$UrGdC0(q_?XcPkT0iT{7uu>
zExw&hP)|BHL-*nK8|#0M-UntZ4%HvbNijs&>`#~%W=YEM;{Sr}(CZ53gb$evP|0*>
zj??j@CHb>Y_3I8IrK)`(t7d>H(Q^v4iUlEDUN35P1OZwa*OmF7F*7eQ;)nnMcd^<5
z<11bUWqBLBu#4L`*q9j+^(!-ZQn)<P*7dMOJIokkFhlZe(#BV^5w4Y4E)geYWzmPX
zEV}jhm`I`$|GBsmrS%n66ZL*26{+(C7umTY1&09Ga2V%nr47KJbELvq9wt?qKIU2c
zGBnWTFM#!%=tk6Y>f2&uVlwUm;&ktv(zpS=@H&rG0-S8A6fLxnDXx|6%86j{f?%X=
zV{2OqKa>_Tx364_?QM7IPD88>#+H^5eg9ZJ91!LMd>w6{_LuUw)<e<s7n$RZ0<Raz
zdAza5bz#fDh};CM@Z7Gu4Ouf&4so?~F4v5;g`AH);Q)DWZI1sSGySl+xjFBrmF`tp
zb1Am{PVZ53RBw%iq11@~ix>@=3wdi2n%o`l<y1|Lw;P8Cy9fOZqj%&ytyd(`KuY$R
zSk!1+SQOjc&8l*q`uO0bC#(BKkia98jI4gWh}<WGS&y8cs41;~^Lp_o;2pMI>}WL{
z$s>2^0I_u-!ZT4?>yYEe5RtKqegu<it}RA^vIl$d$Hz!w2UZYP0!E3fz);%I;EVpy
zqW(D;vXK`~9%hx!Lix`&mBY}SEZS6n>p_=z=(~YbWb`qm2MXOWxw>E!{X(x*Ww9yZ
z2KTWGDJP`!@TV3Go4J*-*L(ldTflX3b#(`Rj7PTKUP04Rp;|1ByL^lJ-8=~C*c0CS
zZnq-`h@!*~rMUr<h2nfp=0C;%kCeXEy|}oTuXkW84*FBwjUrrJCOdNLzegQQ?#F;j
zJq+(j+MoVwIge56qki&NyN;vVj4J<!q5siRN^~-FYQ#^BFkF4F-QA}rj3FrN);mdJ
zi40fn)7(a}KCMc`yE9kR)>r40<dT#x(4}QTiuH>49vmr82PyN_W@yg_EWEEvU(ECe
zBjyLCt{5yy+Hhl9JnSEQA&-x3<)0alRzgc)(jXlR@`i>v&+_3veYxZlWTlYR0NY0J
z6IV9!JrW8o)~=+bJ$#&j*Di#8Y&`%IhREOo@BZ}3Udql6<C)TY=~g+BS{Qz7)Jrpt
z*qmE`B;h<@BX{VJw-+Zo4!6wlN%Ah#1qN7l((iD|gJ)_1VC3yHDJnv_STfv0mt5B9
zfG}W{z5{>fRry`8vnS7Jn7Z8oVVAER*97?!jQ@C3{ov-07Z+k!)7x2cwh)*)r&qPv
zgv5!IAtLR@ZMR|!F<K#lQ!<Uci;ogLvzb)-1WvB|;6x5De{#hsV%WC)!FXJdy#^FW
z-H~}LdGV$g{^xWIg*kJh*yW=A63$3mtU=j3q9^VNriq4EdEfkr-N=#ETu|=Y``taV
zN(ZqV!P5Yd%xM;|q2%uF4Af{G82h-hX!vP=K3-d(f_ne%bhlu?(zwUwA2rerl`9#)
z6--=upnu;237MUOON_EOx%?mpt#y(G2V{j0-7YC75p647dqvjHgh!%<#FAg^`xplp
z7Ph^9BlJdl$ufCHT`Qkm^J&`y_=*Ax^IxqtJCt>%G75p0tFx7Lp4%Vy)}@->OtMp<
zI0(ccTaRn-wv3$j;B)meW1_V(`BIctB(^wiJMq-WAHrrQ_&x~A(qU7&HCyeM-{{e2
zg0kcXZNm=QpatOOo-bN(!u5rVez3?qlJGo6p3-q!jWyWbldwGO;MBC;FbtDeAS6$c
z7}1EBrX!*9>EWyhlL|)O38ord{xfVi9Lm{X2LZz8p1!mlEMreTb8x$oIU+Pp1io7)
zxW_FoUl$zf`wgG&9R@99&8??{HIlNHAD~txWdSS-93uy!h_k{sSef37q8o!WajO*n
zC34cOiqb>KcY{Rcu_E>|IOKLoCKEX(^C+jsDO>f)7#}t@=~w(&G4klCCYg}AQ9gX2
zn*1}^!F^eIlqkw59k_WW=G;gnsGs2S;D|qxb~%t(WK(~r>(|!{@9m<w80I5EX^l>4
zETdX99IiQ<Q8(Z-MGVcmTVk6|BFL+A7{`5Rx+xM}?|)ShJhZi*@t@l`GAMgki^@8V
zAv~XTgYAPHmhR1vfRraoeW!1%SbHd$Z%5%<hlX`(N+$CLlj~)$T)**8`P3itcbdJ$
z(Z*u58`u#&F9J?r@Ig4Vef%x(-iz(9ZFwf^c)fL(MRqNsu6g;gkWjd9aMJH)1{uF-
z7ggy8aUc|`HMh6cPriX|`_V-3inl!ui1J4|#QjC9w^@p;7=F1ni$P64_T|EZ<PdK2
zq`NyAd;BHYg%KTQpj1q#!yn<y-ym{{pwr+4%JtW{hNq7s-L0{dq%Xtj*Eosg^y1nq
z!?vjW<araQ*Nt8<JOR^?#8napmBQV{fcaX0o~^B+89BgX-=LUd-*$;f>M}e5w5|9S
z{B?=)_mH<`Kn%5A**~zhiy~e5LO$kF?2S|Q@`a5KvGJ0UQ<ylkA&0XgbxTMVU5XKr
zesf_EN=(fvoVsc?(M#Buc6#jXu`py57W~78yF2TiFZM$$?>&FXk&=V$7ghe9agajF
zoQBp<(Pd#j&+`$b)+oSd0L;sWcgU7`{=34gG<ZcyRCat(9}TglRgFv~>eb{DR!{EM
z*qB30Dv_gh9!hw+O`u$8tQcIRA@8*WY_PbLYAh(ThELpKh+_&ZlnxOT0f&c}2T8SX
zSTb7=uJh4QgS!s4nABqzGM1x@SOJbKw9e|V0Bl4&w~cZ@{_v4J%wIxj`7ZU;xUhx9
zn7-IC%+6Q>1A}^D3dN33z@2eyEWD%<Kl}5WLFGF|xk7|yb2l*+@CEtBFLVc_fV@<m
z{Ww^COXBeioUgZP2j4?wf7iKzUV&ww+F0ZP(-2ptl$E?Uwc<B2UuVPnT%*9N`qwW1
z)-s>vwiGTKm-PEkk3o|rRo#K~M~q$3@8b1&+>)>7@84@oY{8qgJ4|-;VaB}$s?KK?
zI~3O8!uvXgYC=DD`riL3eYpFA%Xwibm_U<~JFN!)@+woT>YHScF)Cw$629gK;~xOp
zkBL6PJtta#Fq0VzUpTy+2lr7&zeoRP(Ol{9goAx?Zw|gc0%O%v2p;k;h0L}bH#bM4
z{3?)q%<aUWH@;WsyI)#^vZq~#&Edp`(W!rgsug~uF=Pu~4r?p1%B_)=u$#$y!elEc
zsnzQs2dy(@x{P+vh>B7G6?uSgzbJ1b0zI@JTxOQ=0gX=B-3v%mjJs8}@P}>v>axbn
zlIHfM=%plVM3jIW8?;pLUWh!N^^QBuXMCzTz`jU4fXem7g+|CkxP&a7^VWOazKbIF
zT=ygd(&RZE_S{!tk%wRpqmgtxPZ)rOi~m|ekox4C8zr5%)WUzh1}uqjK~;N+fzEp@
z?8=v71{|uIXRjKgmOt&1^tT#U85dZ;N)HY4V0ZLgGX$@}bEW&C<ZU)GxC?QT&wxlL
z%Ist%LhPn0`s*h^qQx9o-~9JuDZRJ8YI=?T_39>i&vOH2!H9KMucZXOHl=W5(E7As
zd)v^2Wn6X2kqM<LM8UWJ^kOvd6FS@eKbo#GEUu<mB8$5dSlkH~+}#p1xNC5CUEG3O
za3{D!aCZp7-QC?C?k4YdpJ(Cko}Dw(U0qev%^X5OV>g#9PI3~6UdNo}!GA}{!Lo?3
zmByz!(Op6wt!IPQ@~iQaH7rDg?~lm^&O5v~8ODYc0to)+l?dtRPg-CS)|465freKj
zY|iB;-(6Q&2<t;0HKstO^qq6}45|Q9{f>Q)`X{`saQY$Cti0!WDijKWfL?w6vZqtm
zW#*jmDu&dVYu;y$EO=wsTLA2hX;1+%HofZ5j|hW)ubJgmNIB??{6B$>ZH1U%KkF}*
zPUK#3FE2h^X1zawKfvzKF0g7$Vnn?y&0#xi%?$_fIUr6N$eJM&4z<2wiA~}H^q#Fp
z-Vc4UCp<}a0o{4FHykU2`gfo_)%_qrZByjmecCZjm$dO&TMW9i5{?gfC*}m6@Q@<*
zMr*#={2iYGo%j#M54;HDqms`y!H8ytZ-!!C5#aV7GCxdc(zav$5empigOx@Md@P0p
zxwGUq0yX@J%)GNs(C_`p<k7h{JFP^;h7LrfJdpw<38#8^_s2EvbD2wPO@-INClF2c
z-{~V@6XnxQnaa(n1-$p{Dz=emaE<^qM|2#yHT^DOqq`Sfa0Ixx@N64L1nu~1gVJ~s
zTICE`e)|b(QX`8;3OZYAPZron&EWg_rOw*ef&nz%-eYysk|!CMc;)P7mm~g9BW5R{
zq9Mt8l#)GEwH`k7^Sum512}$S)zl#$gNo$Jfis)`=1|LEyc=EsW(8KZpxjpzo<->~
z_tEcV6(xX>`7nPMi+w2$_xlOBx0kW6;nOW!dE+-tb^<Y4>@9!ke`m}%3%f(7iBL`6
zLR!5|?*We)ZYK^cyN3mRu@$Q@w+>>PG}3u*AAZO&B6-0~v}70+9Jf+_e>_P222W&|
zkC(Z$d@$2s2quJ+B*ZrOJpFg@M|nJUp;WLR85_?7yG4lqV`<sXVg=vB=!jg;{@hbE
zy1qS=BqksrbDcrrc@Udbr<f%4&;BWEPymChN58BocNkFVPYK5zJr^6omS03+DeV)V
z>PD6ju*^?^+voL^oB2`<zgFI&`;GVyz+x&yMpXELBFR%5k3Cm;(9$oWo|LpQ*R`u=
z7EA}qXHQ8%QgB9eZtPW8H9iE<0CH$T;^g~ss1hbHKOK|+eyKo(qy^+!uyCM+WC;$H
z-(eES3m|2^1WZCd@g?+sW*RT&CjLlIZ#|uSG}ZH2z>eFn2OVg_iekp1f)Q9ch%U|t
zj3?w#B6Hj&Z`ysa(66qjk?Wa)$@g_?_7vfm>$oWFhk9Z`1J`n3_BhR6TE808a(Ws4
zX(s3<qvdfT0l_?u1%h;K61G1b+->*s+&PKifiyA-`3FQ&oDTuKzz~8cVWMc^lmV|8
zWgRB&b{>0AZ^ac`ZhpO?=0|&OT}2%x_`}z3{#u6K-4UYsyIXtovD#8i2L?4YwWUJl
zw~S#>$<#u(y&#rzE;;!V`lsg{Y550AA^vz0K^_v+VS(LcJ4=%1Pf}x50bnF1cZ@6&
zE}qZd^iO&*?;%^=4)l8aQaoxWW}b?67*9#zyUB`dvy9A^*)#Ohp>^|usQ%shoQ-He
z4*JqSC_WHcItWS{88#L%lr#uI^XtYXUU#OtUx3H0{XR}t=6>i$E;Lj-u+=s-p0mI!
zE!T>d->H;z(R<Y$JaMBy2G?lb_P8orCzh>wyQM&Tm*nRMQ+SkK@-RaHBs7?8a^LlK
zFYs<E(BUrl6J!3ts)PgLV&DC%zFt6KmY)lhCwC9@e|i%&(G+2{-%^{+7txjz=bldY
z4<QY9kU<EB_+e*@{sBMA%&c{t$pG=W5P9vHVYm0Bf)gkdnIT)wJ=z-KZCA~-x^0+Q
z0pvT0fBY#wPOnKKV1{J*0z9qpzsM8o?9N`O%yg;h!MGg)4VK`x<txB6!T>I$z&ckm
z`aDP1^LSkpwbDc+b{=>_Ep0rs?M@HHemCQ87u9YT8PS>!F$fZ&*TKInW0IuNbCX{N
z=H?q~KQws7!9p1|$y7T9S-Zu@psdH7jiFI7TN`MjiYN#Ofz&ShYr!4njE>#<n{QB?
zmAFBCS{Uc&;LU6A4jTGc)w42d6|1es;b_;CD9}BxtA%RAjVOQ{y!H$0dtoL7ghIa#
zHqZq#QAa3Ir<3taRljA1Sf)bGHOxyPmaWN*PwYUNG%^Uo=iDrO$4}<BKayY*C38kC
zoP5(}tPcKovbiY4=qcF2#`|<}t9o5_*%gsqaSi#WJI3H23QhEn?J(NOx}np+9M%4W
zw`32nwBNBzBmfHk)`uU@C`l)kjS9gyvljW84|6GuM#>kf|1~&#mWH&m4UyRQs~XG|
z+I3<g`P>pa>*_V!Pq-&TfR|yAq^VbOhV76?u%aVU&JM1yV>5%>3kUnm@)rM93r*uW
zT!=f&YH6+j9l7*YCfVw_tOD8RD?X7`XgD2v>9M$XW}e(G1PMoBTvX}!$N|ocp-&yz
zTAD)hO3xBsv5A5Ip4@qXY&9L}{^f@>hYd6`#dcLTmoLVRI8c%t6$0PZCWwL=E!sgo
zgOk`(OQNX)BX>_A491h}BkE3)y5U;dw4&lFM8D{!sv|cTl!)?Tubl4}=28%$^s2J3
z8aGX-;OBPSL$}hvebFPs_WiVz;VrFnhZf3AOWRd5SUv!r`ed?rT|_#MRAlVfO^IzR
z+=xXc`!h~li&9ExFn2?N8GBPEyPWXWq2Ns?@#z{pOvBjK`LE0ajwiprNmpq@*6-SM
zv9l3!o4~wDjIi9?QN#BFWU(eetzVnAXr;rwHL8eCZKdqj<;7dH$Ugh|>Om8zWqp6S
z@(6uhVjEWG-S-27y(5E-c0V6sZt4EqqOA#NUBB|KIDG(5C;k^7GRjaktLLYh7|_fV
zWP96?(BZzMQ3j>08mtHY0T8$zWI1w7f7vtFo^+5rJ^Xh&ILBsy*@uQ_78-!8&C$84
zs^j&htp?;!s!$Ym6<TvW(%N%lTo}dLnzQ?JKg;CR7B4symkK!|s(C-A7xO)0U5r=M
zJA+Yzo8hOOK-t0~R9J8^k)+Fta<B<8MdTH`(u`5E*O-fPC$~7|8EV`gzME7zo6*zu
zS%@ocPvD?VbxAhA#OdUTxvHXCHX9KMNmJwBf<3bZ2>j(IJagc>W-7mz?L2H&>T*)u
zn|tl4bm=PHt#u}V1kP8}1wX`-Z--UAap7iNN+dF9p!Od&C`_7ss6;y{yYEPx;5e8>
zU^1Zu{MlsrH3pJCb0;b(JUtJ(J;B%0)zgcnh^e-fuA<F&!EsjI=RK%fj7Y~a7Btng
zDKL3bR{7^zLq7QCBs!mSTMu36@9c)9B*#ZOHC%#n_!z8=JLN=(E9%-QwCz&vL4xdZ
zC3CH@DR?}51*FV@_9NiUFi8gdS(uR4SZ~I#96>$UG#Ie6N-;+POV-Ls71Q6Ua_-Rx
zSPcD4s~Yd3h$fQf62;;wE+-3fa{MIz=}5I)6^%BXi?gE(=<!~hVuS|->x%osA<n+w
z8ydJ~Zva)`kbX5_icbb3H6;3=L)VW^;{?s&;WaiBZjG-J7CQBVG#Mb$9R9FDSNg;q
z#d1&(zh)@%=C(LrO|0g?24Pp?F~L($84pa|of5Pf8w(C>JLYxd^<lmakB^&u{Z}`g
zjL7!opxqJg;8BCQoZ={LL+Wj1yeTA^&9p|^?W*HH_r2P>*K3`(o3vY*j0_K<;EIl(
z_ad;lq#(CH?}Ok1GJdXLvD|X(N;|@m@cl1Te{l2f!F?gOB&uU}vv|n%`t<wkaaaF?
zhc_SQ%B+N2kVC63Ej_)_|Gxf<@Tn~^MHd=H{W+sKh)CI$WA!UL+}KrGWM^enDeTzF
zeJCuACvUDqh{he7?*Sw4!w)tW78Vz&tTey5>Byb2DCx%2tcJ29u;s0k%1T9#8{Aur
zqsvcl`B1bsdaouX@KLoub3Hjho}XC0DB*t#e+bt&0U_=U?3RW%2iYjz+oaZ(9gbZQ
zaEG(;eT}31Je1jqAG_n$8PjFIO`H-UKt0OpLgYyg>B1e*x6w7^+wFsV?`qW4h&8}%
zcJ7LcP3*{dUy{XwE-H)$m&0izW;t#eMyK~VCpQ<8Cfhrp;ONAemiG5Z>Wq^Y98X`S
zA0AiCtDBdI$(_E4euwvmzw{bhzXbR26EcyO!f_vzA#2D?N8?6$abTUZ?EsCtlPZUB
z3U6et|DVkA4&aW;Jo(xu*0xpYvam)@3cI(wawY{{j8I;nq$f9&3pW%aMqt(#QJKEn
z0?Y|zI(Vm>;m*=%K@5`-wV3S)<PT$cM#cVbug4XIIsHb@QKBhR%s?fF6idwTX^w*B
z#}l*h9<T?O!KrkN?oTL#!kG?|B-l~xR}tj^kw5O!(FLVGaeQQ{`5zAVnu2YiZq%zs
zpYYT&K$Y6aXoPU2?oFiZ=CC7E5kPU`&ZtSgRZ|s1fywQ3QgE@%!8_Z+Y(k7MYeNkw
zB*#DmBP?<bY;hxdh!Sb|!cUkTR1zV4^JqoPc=A<fXD^~n-aPj1-m#fXwDS9W@5cc*
z{+cN`p;+OATxYIL5i+Ro2N1ESFhz_x&?!k?Q|gr({`oPynCYB$^^(HODKBqm{ePc5
zX|0AP{2B~Vj>g4ESu^Tii%UujKmB(Cq|7bM{VRKsl6nJK?!`AtH33vYP6>C?@yH6N
ztUuG%LsEzSz)2urUg0uGx-V0Qxg|Xj*sew7QN;M~qzpWN2o|Qt?6LRdG6JoJ!9B<M
z?8`v+ABI#F1DZ{K&}#mII^!2w@qn@4+mRn(wPW)AM5)QMQR>ah9+u(ZGVN|H56Ve2
z`S5;cr(Z8G%$)X8K3hWx%?sJB0aZvh0Q_E)Q_5}y{bW((lgQTekC0zfZt0|;uu?)2
z3tXy&j-I0D{&>uaM~MS-_GAJs>jD+o>WEu=j{~b(a4+xTa?eb8qcp6rz)zn#1*(wj
z4ZHb8F*hHq;fr>of?3=9J!8rdn~Nc&u^4%+$EfN0h0Rk|IviPDgltC9zBBvyJH9MO
z{d&ul@)zYI6Sk2g#$K>wX7D}tY&R5R0?PuYE)y9h9xx;tKpDl*Q7r8Tfc!vBNtPoG
zOPQi*ARK}!4GWZxc|py8M~SC`t_6?zJ6HTl)e<`G=YAg{0)zg$m4*y>t@`x;UVtEX
zw+>{F9XANTH{r+^8y6m3aJz2lV`_F?DJ`y?bZS|{=$5s11fq1;5^mSWgM9~(2Lk8G
zpRrk{xpE%Jf0V^HKJv@}hia2q)Icz2nTj9MYWj&XnUBqXax<XShi7J>;sfE`Nkw@G
z0kUvRj1Jisn5Rv8`ruY>r{i}-GIWvyiJxUSabs#f$;oKtX&guP@~jW(cYcfqS2ZEW
zmw#KW*`#L@ApM&H2!a}o&TfF&OE)WQj3cZak5Nt+M`eVD_@-*vbtVbGE!#9Gi{2;o
z36swuP%sp6s={%yv=h0)q0sah@rW>=xzPimKXDfra*Jc5_K_L_Uz4dHTR-zNF`HrV
zCM3L1^&L8F50`Z!h2{Z&t-S`qh8RJ`rT9zB4jL>7vooQ~9A0<~X011v$~(*v!^tEu
z>=APRrHK+=e?Bky(`hh`MoPslJ*!EEwvE^_uiSo&wOoRY{6x0YBq%0>d3A(G+6F@E
z<Eu*;)Vk~5y(gJdbR+Xy5atTex-%-yN06k4amylkE7ejV@nUt{R}oRF^}U2s|N4pY
za|rq~+}w?#{Ss7*h3q=cI(Q`0%YL)|Aj#W#LwV)Mw{wy61GY83vAPIA=ucsP0F5j+
zB?{B$U@Ql232Y`h#G<e+e|Q}w{4T&aD6YL;7R41h<pnR`GBJFW2&D1VZR3%41e5*?
zQ86uy-|(wI8Qu68$AE(1BOo!!^qtc6Kf1N%A|bLD{#Ie}xRY;ZRZ|aXKjSF!&lS_N
z<7SC=h|0)aq<786&`4-e9_H}cSsW;@;M2-f*h{bs&6^<~!N5ib5qv#|XariXvSQ>_
zLD@!CWoS{(g5zLlIrqk&5h>o5cL3;68qmW+N;hpkD<sff7w!8ro!!?$lP&7yr9L-T
zK)cRWvd`frcixc*L2KVd_1V6SO?-u}U<13?o(#5;AD#ww6H`Q*1?`ob<V8PyGX9f0
zs9!oQ;e2CY)dmjbAXQO4E7P}ejQ3jE8@dsnN&sGyFzDwX#4yTq99*w5Dp_lj(_bI)
zK|5M#d&P8JW(Q}=Fg_R@K>gm#W^&Yn%=m#a(UQ(O)d3DA(rB=TZBD+GV5DDK49JSF
zMQE2Fv>F#7iq0!`g$zH!>(y2<dNl6S)bJJ-4rPf$MKifk^Ap2Zx>;j8z4g3YJ@-b!
zdpU?dK{@bf2IB^8yFKU@WH?|vauxXotFirO4EH`#9r*5#E+QgZ6S>-c5Gp(Sc~rpc
zo9p$3>2N2ZX45ZAd*hdRr1KH>45=K?Wj~wXN0J;~okqNc<$v|!czmdJt=2xIJm|=e
zyQ>O0+zImidvl;J;{!<u28!JBU8FSnFbJXPI9bHi3r&bSNlg^ocO5#^w?J75I8>4y
zbC8vJ{>ren1mD;RAMf;1bRVEB1ot_KwS)LY))5Dne9dQLd^&gI2H-44lG>%1)u9cg
zR-qMK*LlMOzE-?mTS**Gnakqls6OEZh1L1469=>x9(Xr9Z_lS}E%kaoAN}F9&pvH<
zMT-LeofN@@GO!y;A|7Rd-wYYb8hIfEZrt=S)y$gMz}T4i+TGy65LnIFbs-(Em=@=$
z6nc0Fq~C9OyqAhGojEE!YEf-$Df7HDV`NMz?I;>+zyEo@_<S;2%c~&?*^3K7jglbO
z{SC`~ZT00#W4MvGLp}tJB{?bQT*IJQ($`p=rk{Hn<oC|O4*c`H#8hbQkAl+i;wVM4
zpIo@Ngdp_YTb4-tnfW0*+<}e<OvPuQn-%x~Qh#}!4%+2!0_!X|BQQf)<HA5*_%S?d
z9sawsU^={9vn`Zls$gDHnBLfgW0Mc1;VUQXZTZiP@F3UudaSiwSeh?*?MO@w*(yM4
zS(fFT0a>|v#sz~4@&_9`FC_Ua{@{e7v4)xF3vQ|~QIHf;64ovZFElQbNPzOUuZh<N
zDNtQh2GtP|%I@7tE#Z^P6KOu@0lhHM+mK0t2RirU6FX3mcz~!GY?w4H%PK*&-|WB2
zatUFh6&N>mLqpS*I{l+bqZJxMgp(;TxYq2U<u(|Z$56QQ-%%@_TLwDS$@)8CBs)>U
z&*?pV03xx%G)zJ_I<S&V^=#J-l_G-oz@Rll_{>*ue^hBN)Essbg=pvdwXZ`Zl=ft_
zS{61iN@jTC`WvjajL3b$@cs2sXWv6gMMq4@+|$pK%q@R6AUYeY&b~sExRb2ij&#Cm
zs%h=n1cA<4s&+MU=1Iiu`uqh}F;S6u?MESL?ocY=(4R*;UkHf#IFyt3n}7U4Wb(zY
z6ozZ-wrzsKa2H**_Y{le7nEjVrffuuAAt*9M$>Z?b=K-MlVcR2+abfNQ$##|AAV%m
zF~SA+aDG(5Zhk;SETOIaj)M&bV}%_Q=f4tlpn7jPb}rv%`mCn`o^A{4tf%jp=k9z^
z{v#gzwrD?Rw(BFV@kk3hpcAe|T+pV)DB%MDybd0@6{F|wL^B0WEQy#uJK_d(dNfg|
zvU+Ld1g9@NOvW~Y${Nvv`}ebBzOOWY22}CGh8Qw0-;o2jkeneDF)vRs4vxlt!XBTW
z4?dIlpb6ex3fZQ*VO+Hwb=<L?A6GoR_PuDWnh-7($RUU9VjK_%SG(bNj6ni;;Wp0+
z{Hm-VI;2UOU|A_=`00>PFMQy1-j)I~QVXNK=|ilo5lRX^P$rqhYGsKSIS?Gyd*FLs
z^8=h!gQZwvIgUt-vocbwv|c^MDjYa9;>A}SN6IXq>>Ri~P(<%&T=bc#-=WjClMNhE
zKh^=bc@X9Gpvwjz4_H26gv=o59tC%M9rU9E5S#<dbt8?sag*(}aSLmxhQg68%zeeW
zxA7eWq&zLI+<On_bzZ#`!z;U+Hl`}@u4tJUduF*N?#|cPQ4W~VTU&IXn0dOt&yH7y
z`x`tuTa^G-#Jtk=?R1xG%v`slxC|^k3G^R-&uecHg@8si%_XOKC~I%w==nUC#lnyy
z$!53$6wl$gbKA+;*pT5As*$n`@H_`9*SJlO2&T%Mq#5KWn)w4CRsd>a0ueXiU?q5Y
zUxZV&`1z^sx@-vd%S8*YK`4Dq+DfC`_f&mdV(yw#SoRe=O5E>TB!AyYT`ctc919OV
z`V|&BTTH;DQF`Y%<gx!jrQeqC2jp%A<}gy}94ztU+y=i}??CDCzOQMXs9P6?)hG-{
znni?D6Cy)wG=$nfd*BMRS8Qg7^IcOl3$)Zv=<*%&=6eeQ-b8O)M^0#-^Z+de;g8rk
zNmmm)<iCtCT1vYVaqyq^Mv>Huq2ctNyKu*Y;LdMFM}Km8SMEBos1)ShtECIiyPZ7N
zGDI|Xo>oZrVLgmXy;%*eyLFvfe`z+`QzK}3TR46v1TroNSzAB@V+_t&0@?{zZGRXM
zUpCiiq`8BugY1E&n>yN==EuX`$dDuR6zZ%jt*$8b$R(e5f!s_y4l%LUrrjiMb11vp
zjy&q_;e;sWQYQt`I}+%W-<O=+RFHIUr-+lATz^P6kZ8K_6vR;1U}o7QnZy6B3(|L<
z0)RmCoZ~HPxaQwTNx*|R_q7v=c^^&WfH0(mdsPtx%oL!lWE2}QWr7!nUQDHXKm#r|
zyO|Nhve98<eZo!{e^2()8tQ3_Ma$Zi2(v{4gkrUgpfnD`t!+Y$TyFp{%1QmPBv_ca
zl}J4;o%C@6bLF6jSaJ*FV|iQB7$#<kY_bDLH|Bj`)iGjdE_Rd$-F`9oxH*a2=Zkb{
z>|G(PGV!h+Ec&8&-suM#SLwbp)N#fX3~#59_+ld!5sPs)s4Oq2et|Y;80#rnEGUG(
z8Oy=r9~4>cj;hsvwd;f`nnuX$$LkH&1h-#~<maYB&<$64$o#;)^$tkEZ7Y+7QQFFe
zxV9}`6T7MX8#P3J!Tw%?(&BimF8Lixqfj2<to~}-CMrepM+sr+nlAfDiwGi1fI?cp
z?Pcp)3G)-}ckVt#ckQfDEe6uYhOm_*)~iVq>;#9D7H~8neT1@y?G1}03fQ?7yLlq>
znD2L=?h9iM<L8umQ*RK-F^1D!$sRm)-FEZ6e|3L&?Tm2RH+3r~7F2K&|6R9FfOYVM
z8s4bZGtUE|zYl@hwpEV@^Stt)@JZ;6c27YtT!~5duEod*CW9S<=r&s{TgQBC@8bx|
z0itIO{&H$pp4*BKTQpH?2!T3b7v0ERJs*djS`Je12k9ESnf9c(`1O$C=UkrWgJ6um
zv0}jxvYc*W`(uT!l&*xu5#Z-0#RmUvt7`abFH0g+q;;)N?)j}4q68^T9-h$1m@FxF
z6E5<|qR)Anj;QG+f33{*kVG<>nUVp17e-ju^kQH%NNNLFasxi7`)XNe$DWuOKYDq`
zw(=(?9_|;pUpWn74@j_q4?8r1A!wk3{FJn;#W>yvojW9FiCG6v*ZN#m{E+x;b<7hf
z+YYq9e}yF!yiNpc<1Y}?3Lw0iMYiMt!D;c(W&a=EuOFbPantsRaBf;$#dDs$iQBF-
zI{`^1C7<dcBa^DD%2_pW=2n+Fg9ngNsDJMGin_JoP>YSY{lyFDd||k{Eh&P3Y-`IR
zz+1LbQEEH*1MkkE85s&O1YUU^e~3T3Gep66GXwhDeQ{T`)8P0>Fk#R2?L%;|W)qx^
zG^BAFZQp#X9)HZA9tOlq90-OLqE+~_55cYZcxPk87t0xX<!KODZEr{cFECXysyVwz
z8>?r9uXpmTO`WmP(Wu^ASiV7Mz7J^ju122AzU%8jqy}bqYB}an9(49Vxj^lEGStjo
zsR<r$0CVg9d|VWx(bMp`;a)0<!RE|33p%PHmHs>RkrsV~N@bWZRvW|1S*8QC?|W}&
zpgp&2RFUpdlSOu8!f=PV>?aiI?@|zTmydpvTj-8Ox$ZGjG8FKb2Y?zj@TTQxSjecA
z!>SW{Q2<DxE>TP{hpBtqA&XB#kd%&t(l%kFz0h>SPW09X0Q=ziXOrz@{TdDq#7a$N
zwjx?z`s4V8g8Q1;V(Tm}P-)s$L1DlqlsEs)B#fP1^p|e%(T7NM&Kri(wJO<1|1N&<
zUBMgK_X3V&&}qA<K|O~{gf^3Veqmwb?tv5@3f{_{0@QRg*0@#5w;nD^9gP*^gQxK4
z)ke%jo>B5L{xz^+o@2wo=K0!VTcE1<7CihNr66;TpnQZ=pFR-HCc_tT+5qP{VC8D@
z@2|`$S<?rIoY3xgN&I5>bgZzj?OE)<Rz&0p3cX(zm=#OqL*meTPvx9D^yhZZ$<^Y9
zyZ7_(_bRYR8_H}XF5q-HLmudSqsn-iOUB6Njp~}9y;}#7R5smbE_iM0!p8uuEgVoG
z@;bf4DX3D-&(N$aM+73k9!{Z`UbO9&W4+pn&SNXl*d{C#Snv(l7K>OL^kn8pE8CaH
z5CIHoT(xv1p-wBW!9r-bfeY|J_NZw2Umrru$En+gJ#!<vqo4$y6Wfv8Y)~@de<n+!
zQ%)cl!Lf`MYJ%;#yq{1N)R}?)ipsy$_i1t~8D~KPBw@k_rR#Zp-!Xx!gn`4whuDeY
zf3~bxFjn}&U)|OtDDK-(K!bXaZa<OC^I>TB@BHW}NM~dT3Mbo~wkmeE-bBG|jRl|L
z)(6||JbUjDZm2UvNU}9851ypq5S;m9fv6`o_W4eZbW4dXJU>rItj;f+E?P;vg>;zk
zIKnx_l1~uY3Oy<pV~wI_Ya6u2nUl%}4hsGYGyVu{=|P(GoKpOF*Fy|rWUO;5H^xU(
z*faG{TpxnY$n4*wSLa)w;kXc{S03qP%$|BF;3nNpe%MR3EPqMtL<a}fhu?s6wkTG*
z1#9esw7J@G@p#IYE9OqDbFXtd+mUk*n}%;=QVC&ZS5XMgwK>ZJaTHM=-~Ln%q$@GU
zZ8w~L@IHwV4EOi<u|z%%vhYio?<$Rg!(`W_!9K?!6x`m~12mZo2gv_hWtxe+5xI|i
zf*yzrgA^?6OE=Go$%VO<vxng$Ea-4|{&7cjf~;*2>gNM6`FixZO|{O8^)$Hw>8)wD
zMnPuN#eC6S4YCjn5v^yQD1x^%??nE7RTiBT2>jgX`I^}&wkxfL`3Zm)U7+Anv9R5k
z1D41_mLea?;{}{O*r1^(W}e(%l@y%liFww~+|~T#hR!Nv-Xz=aizI8i{gs$6$k&5b
zfbwr45N0zF8!=HgT2tJ`4&I@`7eoFwGS3A}nSr<!3W_ZJXcp&&Ib+xsV{316_nIj}
zXv(upWt>!=BSoFctfSyUjG*E@BZjCIHv4@=e?zs(THfGea<329HVqBI_#rVhQi}~T
za&*r=(i{lXpeV{~*EyKj$F&~tHgfLCXWMc}Z3(b}$j94|enGD+7#ADzCW(xzud1MW
z$Ehsn3{8BYd)Nv-VGEJ{8+409v09-kzI%+b$vA<7MbH4M&9MMo#Po#Gtp`jsDqf#|
z%@Zyq5KU@a@?%S`#SrtKlkf(m;}4Ew+mO9B#8)@gxRPx76^+#}ufbrK_(m_u8~WP&
zh21jqM7lld!*E>`(oM898cKsJ0!c`Bcdt5^%D{^j){1MoH~oGt+<AZc+Kr?o1f$T`
zgV=b5uJ#*`i{`;e4Z$mVr}_p&vS%#rJpB-_OQel2qp4;nWWwi(q^_S5O{2`)J!aT*
zY0_vWwiAjrqMfzBR21&iro0}yeR8~BHF$jL52<BAs0KbL7Tt~!oCIZ!3&&`>DY)I;
z<^TFsEfSWbmb7tl1henh*ylAbLzU=gLEFqQBZ{k415vNyr$#Tzhy&T{S4qzz2OW~v
z#UhKJ1_goNbO-AUY_mjy><)1A;>zUVG87&8Nd}vqP`AJy+3-1}_nQB#?HV;QI(iG-
zkD%P9WFaHIz2uLnI+lhEhv}mcK5ni(9Q-r4{e>m}+kx*a=ygR4O6u-zNsC6#Y7KT#
zd(Ba3?J0>XaCyM#EXakM3YG5d++fy{a0gkX1gUfeK@PdwAd}?-ab$`Aw9>{8?7k^}
zZbtQIeB*C6^%Hj32N<3;01>E6(uS|a1=}p?iCJGh;>M;4g?1n7*&Mbk>^RXDZkbT{
zYvUeXn?XiHpEokW_jh0n_47xz)pwaP4E9b=NA&cpgha)@obWuL60gqPmti~77GTm+
z8~^=KZO1xU9E4xBIYOP=i^gVb=-R@g(opI{FpT)`!uV}>A&}#TK+=R8XyC4mEkUs%
z=;<%!*ni=jW%swGBGoTr;pGib039W`@5G&Nu=!r{6r&J_Rxby<1)<DcD;DQ(&KUGb
zqH>svWJfI7iKy4_Wz4?zHwp#8k$C&{c|=g`(2!BR;jq-#=C$n*i>$d(eL4GzzcM#@
z55t3Kc1OvdTGU-~NYqRdcpkzOCrtA%nMScsw+je@2#`m}s*7CR9H!aP!C7PIfQ%&)
zrASm3>-VFwfm9{L@uhZ4q9MMt7@Q*S^RHcOy|FAv>||W7rl65w?iuG&BZ&GCE^Ta>
z-~~j-Nt2!Vq_1HWqRMmQJC~?<8Qm=Ws~~tUG_jipQjgbIem!kY(ch@<YghggX&-3E
zz?<VFG>>*`-{;I$$7yu-;kol2j{hq2d|o%H4hDv|K%*|##yB6&gA`rFZ5%=^=~(9D
zEHa*3J;Lib-a7a|z3he3&U?sk$zv%UIlwQH{79A7+<6&{MQMjhGhnn0pm!1eVJk}Q
z2(6R4j~)iHTMlkH@}g_k{|Bm;xr^wj@E64s5V<h2`M*yL3EGREGBqAPUMohx1fBBN
z*{0EE5{4R|e5sa?;fQ1Uf_@M5<A2R4IMxvH%P)iL-;Ki9b*h_&*K<HQ;V!o@r?34O
zF~l%R)>!MOM2|YnPS(_Z;q09M{M%|13^I`=yZADe*E)g_3CXp{kd$Y;*eSN^EE-(0
zPfkz!;RG*Od^Yj)VwhiM@h)$s$F-Px<&jzpQ`}80$6)>C_s0nfR>B-ECT3lbZkjos
zp#v>jUU6^09Xc`hE864zC@#e=9<yzp3U`PlYOgsa`Xm`A7!W%?e!U?MV19#s*b)+{
z8>_d&fA1sv%R_}D{4FJ{NwmN)!(?9#_v`PU)%ziQjJkN)_@RwuB=Pg6AM0|(vWP>C
z*HsO~Lknbh?9fH$NoQ28MEe)H{I-tB4Ro}m&6^n##eqh}9WXL<38J31p1O%uOx^6x
z+%IGgo^TVO8!CIZTTy2Ztvpao9=uw-!O&I2ypv)ropdgB6AHm;HfpFL{>gG9TJ}qy
z@1SvvKnSzXrA$hCmB2^;OtT3ZT(!909K@%s6jLS+!)URT%V~k3l>_&k_v0?Qe4VD9
zG%{>DE7y<w?FUJ-d(^<ocPM>#&+WnTFqJ`~A(-gdnFJ2a0p;}<L`)ec{N}qK3-`a%
zN8W)Hq(sdqwNCh(yH$a+NTaPBV=+oQ91vocng1<Ik+1^0LXH&8;3l%f2I4$%j@+<W
zoMu{o7U7xsSWp=qtz4D%)Q7dSFpQSaoP9PH$9iT<p05GeXF)*S)h3TmT!D%#N_9|l
zRNK;Ha%3((i2W+SHrnoGK0k24L9siB5N~WWSx(uw6-(l3WMf<f`ma?ootb23c5SOx
zc~Vuj-)VunMr}VVGrtO$n&CC5<}7cnp+Xo&;5uXO*Vnvvscvu+dlIE$Al3$e;k4hN
z;CY%U;QPov(oLQ=w$#;NdS5fs1NyNSdbo;qHWxCH?|m7X(Os$w(o6pPg?iI#qhOGF
z$LZ>ieerwvIoLJ-=>AT-@R8PG7{wEB3gk5z=2TK9Xmi47^AC|msD&#T!7+ODWE^g&
zM9<|g;t>j2fRCTyk&)G3TiM?4RQqU-BiwC%!z7x@cmE=gjWi@hC4%VHbRu!RMX`=2
z^dv*$Y0#R!EopY*z8%+>y!qo~?{;T!GnYL$`MmbMoog-lVj(vPcmEiw{e{Q5Ky!b>
zEl${%_%o(MFG^L<zR-R0!^5CZz{e_Xo%YeigRQqZwtXAAqQJ2nE-6x;jD<S4^0Q++
z<GZ_F)21dTAY-N$#wRaK@3Wey?UsC!kAdfvni<etFW-xpz|!L5<vIv=4|ni~3SB_G
zzkYyiUDzDa^Vb6(_>lhVtABiD*Z`hViN^Hr=xja|SZXLQE1_1CG-2x__MTq2GFZkD
zsrkTco|oK~W3#<!#XXt|Hv^HNrhUHxEB9o$0N-oPlb07+xpY8B2N|&GSrFKMPlVt0
zX8Q0H(p7zmHJnma?Vp2lH9AaeK+xJS9-bGLtnVxEcBAkP@O{L4$8uYD@mlPx`zW1}
zXTdGlZXlz1>J0nZcPaJB;ZA&c=6)jA_!jA=sU1q!CO{ZZ0z=%Y`$rNP^*d<Wo$Qu;
z>D?5+tzIRsRA-4_i1v%zr8qm8pT@fwizeX`e6Q&3YNXNrvB4a=VHWA%Bw$z<_9>S}
zEnUsq`U*S1>pl>#AgyYcAuBX(oV-@TzG-360eqC3_z3HU4!^4wTSX*QZMQ*Q=msWL
zI^3aJzr89U6wFpo9Ml2f)PI)Q1X5nwD!}-fV0{_z`PgES(%SJ1rk4WY(6-voL1=H6
zR_}i6uNz(t4-;<@>#gEmIx7mY%%Zj|yMz$jlyGf&zQ_DsjA=va9WR<MgPrf-$?c)g
zp+^dhrj0NH>WMa;Lc?VK=0x~nArx<RguL<Ox8%GJuJ{?Z+n8eN?bx~90)&FCNBd`x
zy>kuU)P53EwyYZr?m&`VgQSPEp$g@h(@2>p4v={#F%N=~WmRpzEH>9uB`P@}>-t7;
zd=&y0DQ4gz<@aNai>jofD<WuK$4*9fw!oqqm4-W;!>VmT0MOgx;Y^1QweKv#Y|F2t
zsKJe9X2#WZw${!UvfcGr{-9vge_+NLQK`6hZ9ULI^LE#sJ962!6{m5{6KQWB@1hS&
zp({bRw%~+jY{BV`-{6|BAvaD%d|KtFvV*kIb6C%295mRbNQ+ZJqN!E87?3rFXVclK
z$O6c7iN$<Ji}azB$R6{;IQD{o)z;6(0Ls5i?RSQdyv!EGX{7WHjp%(>Z`)O8`0@3E
zIH1=TXXS7^s?-^NG23sJmDY9TGjsZ1UagN4@#fnv3zI<_g&quK?OOY?ekj(6I(+ZP
zQPp=QhcgD*USa#D+Vo}%D3;r_)vn#^qD}l(#PaC?ZQ@>Gf|Z!5#Ug__?2PaJbwy~+
zPK2vRC=wzLE+59SIvT9R3Y)X`Dw420+Xl7ua*9sId#&{fL1~8g$f&3W_Vy4fFP}-*
z-AUdT7q2-H%A*@RqQARig9|2H?O+Q6gC)`cwh>4CWjE~cO!t+mdROg<>BsofdpzVR
z&5b0@KHRZDW*y!)Lsotx5SlQaH_DIW<D>3lpZ6F-dWzXc0`4p2jbA#w_ro}Y-A7dc
z-OYyuSpS$KR6`R{1r8d|*2>?~S=r*}997i~v{}3eN!u8}QsNU@K?h8Kf&7hv-xgDQ
zB+twT;gRiJ9fb`fT+T!L3f-SvIq*B~n0|+0_Pu=?sw=X3@{*F`x~khZ=s1Wpb#Oo(
zJIf-H+szxM8d_ve)WNkRL#j^+RbvqSh?6@kagc_nJfB;JXn;R4BeM@Zc-98DR(V8-
z+%^LJ!GydS4{0I-#$KNH+>9mwMWntq7<24T#e!0{Fv|+(I1{e6o?UucxHx&ZeN!3Z
z5eSR`ZV_&ZSD{wly7K*n{dirFx>5*!?%Z>BoDYpE0xN2|t*cSL^;AjP-|C-e(D^g}
z5xykO#Z&lKD-u%ISYs9zaul5O-DsvzqZ6;$nG8bIluW}%oxo{Jkm7Aw(Ng9e_#UFD
za=~Nnk7>F3bM2DvfE{;Hz<TGobR<{5aq3*EhF}zP(Eob@a9NQDMUD<cEll#CYbu9m
zD=WJeSC?<xs&;B=3%CD*WGe7~EbwPyR;GIiP(;|)i_l&F)~Q4a2-)rWPOgyzGlFEm
zjmkjdhXruA3>zEuqTe@Bk9Xic#XczfoVgNWc5yQUg`A#cGSb|nj&qRwbhUJ(v<!bE
z7Ft<y+%o$Ox3o}f;}n74q7i0w*O?SZjd!mmJj9PAsi5=Hc(N2>eXz@@I;gWj;I0%S
z5=(ebidm}wE=d33U;*=zy_QC}P{}UU8vD+alPmrmS;S37hP9eu2WdSae%&9z){IOS
zI9yDQbj3*fq^OY^E%GOXAz2E&iH(9@hbL#NloOCS)!ayCW@ueYc<}P-*w{uNhosbF
zV=74Tbp3tEw3yEAdp?A9%}z#59EgMwlTgNx#1Cq71o*5%XSdc0Cu7yrirj=f8Cs*y
z(G>34lqs-G2ts|tZO7(kBhc*;(OJd4Jv$^4XTcX?wP556HB8g^Y|1h**+kf!XF*GM
zXKLDX+mKEM59M-{NvwQ>+4m=g`EB_dH)V@nL@6YZD*$(KV+2F%QEmIayniE1AVBE>
z*Ke~J<39lgwa`M?PRX-g)EXyP92+#hW?&=2&x5M|6RDD3jZ<toHZ4_reli(Cm0_j6
zsY`veEsQz9#j87%*QzsYn+%0W+~O*gkue#(o4b!g)8y>hgfu1T8la@iUQ3FRb){@g
zAQyK%z9sK}m6bG1^E+_t#W@ripG@w;ISQh{E_r^OY5#^PUY!RJTLh*kj(*EY4&MOE
zw-WHUI1_R^*iJUoLitNS!{6X(OsFT}EgfZ^3c2GDKOed=>NjG`ERusS1d*Qo{ur%f
zW)0bQ!fl{O&{>yzocq1P!?|Fi73yu_-kK+33{SqR!0c<}3QB^LqS$}APe_sp8h`XN
z31%jKXfH`nW1XwIjT{ph2Uno~v2FR2+xOJE300ijxZg>aS~?q6BAO`>$2WfU8?K`*
z{OB$B!n#?DS9V0Y0_gx=2y9$aG8boU#~Sr(P0IaoG66T#=6Vw_T{(>B*JuWzE2R(R
zCdJi<=rIHyK<VU_L%YigmqII{zDc}bJk1;@Y{!n*mUqP6T5Y850%e0u$wb`xO(a`D
zXi=@|btAXz80+BsFUHRGNC*cCir$%QH~ay`E;Ew$U(p*nLqWFYi%)6DF#+da+_8je
z3i#Co;pUIjzn*wfz(oBcP7Q@TsVBjsLg}P4vxUchFqc_wuKmK#;)e;@MPE^V{p0C<
zMEL^Ui(V?O6(g5begx&ar~l4O{v1Qj>gpbm{)seO2xkAS46?zsku$fB#FMkx<cNcA
z>if$d>_|KbUocNFG|9ou+sJ)wnWiD|$R5vz1&$&H9*}Px0{GsGQ5Scp!p_fHwWkj9
zc(IYmukw1@{#FL?ktk>J--O{N3`(1ookkQ@o;j}qa_^8Z;UJKllx?tvi8O>l$5@bM
zBQgy*QtLnGEL(}Jx0<1YK%kjSH+(WK$bq(BkMSsaXbCo_>_IT=Uzfpef@O&SShg-)
za~#FOgJ}5$y%i;i7_z1gN?<L~5o@2?0N+y;$<1REgqYj@Tv~WUUw}1KRY6+Y=~#^m
zo@tPlD*SCdu9gr0Mh4hhR`zrFa!ZLwihD(jV;jgnyFuFFo*^b=lD}Ig@RCg%*&)(H
zqGwjvGd58p*RHg5Jl<QY?+fQi`CXe#`gtHORQWNTn*mg|<C91s3<oHD82o%T*;ZWR
zNEhxeHkS)u91)tWO?x}l)p3{i>YrakZf;PuI&7)pYRsG{G8=Dw)-FQk{kIQJ&ZA>i
zAI+FX>ocI6H|iPn%_NTesh0?!17_7Wb)IqY#R?=v{)YD+;z*_3LSfTebZ|Y})dlY^
zb;>ugI4hAjg&=;X+Gs8{9xZ0?wRu_slxAoSM)LOFqRjATS&3V6s<Rr#8F}3LFbP@X
zW|b@}6%4%8%7vg(1z`nmx}S6&>mj$ls69O0b5a#+vu)_i>Ox0=2e?}(@710kN5Out
zyMAe2C#iL|Hl_hzdu+YU7806NJAX4Enp`=p&8aG=ZCD#|nQxDzKFcI-+~ue~D)5QB
z*GCDg@WEYXk4!4|8s;$aN-b}Jkb2?UDV6x|x7^5<((U3VeA+QCJDvlNAKm<(U=K@S
zFVRved&3*QKbB*BVm~Y4W9`_Mhtvj6>tpidZR?&b*d9JmA^mbFf>S7S+5&b}8@H-|
zUUfAx)_<JFIH|6;eRa|-KK!=5l}P5l7KX6OE*F`tUt2-ltw;zH7QtlqWNqo#HVSCD
zExs=M?8N|{WdeeF^@m#vlcp5a^$5kdGUIyTJFn`1WOsW(c-d`lBwK{KPB~ec&S)-o
z$28glaG?HU7hK_Q_QdUCGC`<$gK!FNrzN%Q5|Wm-mNH+nd4*tf<1mN?G%oF!TDsJ$
z`}F^ecDQxkrn5QI?ki{`xAY4WETCC$rX3#8lho*r{>(99Ypr~(0ivm)m%YiIz3`+&
zJ((p4+YPnUWeky~GA^j$_~wAdvImW=(gpdPp4_$DpFq!55aZf1G7U+;H3S>=N`Tq`
z^uewDvySwq%P};{jqoC-HyH<HVVp8E?yp}YC~?g$xjMbiqa&Obc@}=v_TRX54_nQM
z|C1cqSw@ctBE6UH98q+o98IC(YABMNzZyLu8>GRbs^g7L4m-F%-w79Eet*eB@(!*`
zzTGihw~y%uCKg=JvFFi>oK&3Y?T0z5%93eoELEu89NC^}2_kt^bRTR|PE3ZufQ$@h
z=hA{iPqDi}PRkLMj1(Al*}+YeJk@RsOQt{bj)rgvW4bz$elI$roqNtRgFCXNw_M7{
z%sV1S`dCaCZ1A=1a^%mi`oX=Q*u^S{yXpKqZbO5ecYl&kz!{0IiGJvWE|f<J{--Ku
zVySY@CbB6HUt>+E)|Upio`||1QG%-<f4q-U0YB<2cGQw5zV`oqYeVw>8Gz*dCTe?k
z(LsT-T7;`x4TQ`_a|^syZ6L1AgU=24*p?9{%8cWt%eSMeJxDt=K4u+mZ}&NS`om4g
z(^FqtJ5+n7V-C&7z6@^AQ)+|f>oc033CM|jx@kU$$ZSzc>Tc_-RZk4mgfnowHPA#V
z;buc9R6#kVIvI^33QKjru%}SZ5!ReAqxkPd%!E$<ys@mQ+rB_M@!u#F;4&9%2{0lL
zxxhUfGs4<N2g*M@(YKaVw00$<msE>@!vI1kvjH8K7ggfp=M>!F`~@L3j<9qUvNS%~
zoTgvZ$4g}DV(21bs<G+3%UxRG08cR}5SgWwYC!j$gM$L)@Ac=pasD|yDA4<lIT+7C
zj0KloVgBhRm{-vGvrW@#qE!nOZu!*-RqjU@jqva_dU9PXLK0tmG0C>)Tg8G=BYo+2
z^hmwD0nxulIxo6kdF&0sp}-mHaUtB~*xCDv68J{SPb8pv6YSr2^C4&uHLxVUfq|C?
zRUZb=T}&CQ*45|<5sIgm{8mghEtfk1uX$B%8JG`(tlm9V3uo$`aaHHV8`Dg0%>~Bf
z{nFCUVNC$=;@7>={>F;n)Sd`DH5RF&oKVQ}Ca7HzjJRm;g(HQZyHeqzugot2M#8rL
zBKBFgGhFWgu^To*6++54e-la0^y2c)j2WzEbwF$>ZTKZU@8QMir6DHKcCVKbc|m@u
z7nA}@T0;6OX~0KZmn#L8EOa(SW)X!RIQP!;sXTuxsf^eg!p-9m@I|#O@w+(4{Y`!b
z-be+)PTx}z@YA9vE+CiBG$WX`-CWRI{I8So=#ZI(Z;~6oq_p@e<?q*M%jNJ{3ZbQ>
zrv|81+s@|Gp4}!e4mIrdbx=+$_Xbp2(AVOy>K2zqDsL;)k9uJPAbTn12HM>VKOuRt
zucmlC|0T@-GVVt~6|8DypS#*9J8;b2``_PRnY{^o9S1*o-@Wl&?BA~h9W)Oo;T*zR
z#R%`;099(htthm)#xI+*{Xfxh@&5aTNC%JQrzV2FcYJN<)l?#h{BE!zHTCAvnM9#r
zWD`HH|M)kGC9jiejE@Q;cOTZ?uKjpKNJ&#wzyHeO?V;{Qr}P-9W9U(HS-e-l4)H~4
z)T~dgS9ouxj)g&+>2uEfu>?yiZsR?uj^X7^QJcR`g%vjc%iG@eAc;*GXZ3p*4lazR
zG44&j#;cyz{rWwU`?VO_<et{YsM+5G<;=Clx;f05KBz(uFYj$B$NbGKp}x-~o%;3V
znb?Q09~YHSjmyWy7B}h@`z!H4>Hz(eTuHHi38n||qkg?zz{BUNXYpJtsWL(?l7fW=
zsw13A6-@W(W=VZ3|6<>S#B`B6dBt>5@D2EQfY|ely6kgaSSqZ`Yi8q!Cmsee-i7gG
z(Qz=e9HJ`z{!nQVf!rGqXQ|I}7#=xOg2kfJA5Q;MUcYD}RlA-`EqM8~F5}9oNSd;=
zDA)U}Z<{6Z?)yU9yI;Mq!=bmap4#=~(_U(0$1Y^sHc=-)WTRxgVaiCg{YFquvdR6;
z+vVy{VWRg(<)TK0^I-DVs&xmnj`v`N?LpsX&2rf++q0;Jj>BH^Rfp?Bg<ytViGLN2
zp}%Q{P>e!mrTbkgX1_Qx805#j&W@K4QY!>tQ2}7@)%0Zb?ER~-flRy}jsmw@<HE{W
zB}p1JCr4v2d|gQnE@tkKZOn>~%@qu1rFZ82qeKulMi__6G?s!f<1Fld=D=^zs!sS`
z)ndMaW}>V}X=J}HC5v~J^S;jPTu>TUNyZd03gM>Td}@iitHvFy`A0Q&+>UN=N4Hp)
zF{;(e82eKLn4{@Hp;Zvqd2$nP6!SAGdj~FD8+YqZ=wMaB``yVmTuSizv-eqd>%|OL
z=ai%I=AIIh%@=HeXD*m*;~&=sH&7hFe~DMynBGx&EE`<VO*-A)CRKiy=Z70U29w&I
zjvzU#OK_<hLsUutWa4zdTs!lTHUV^9pWPD~ho&E~YU-=pPu6~2El}JQ*7`yZ)86Do
z?NbK!1pM+Q9^TKYJmr}%>a;DJJSlBoBOuQ1v?1244bj;jC$`HrKjUXMaQ}IClf2k-
zr#S&0I`22`d&X?PpXugD6_Y#%6rGWQ#L}mg<deGFKD+lt?g<{vUJI1EbRu~H_ax4G
zn76Z*W;Hw@=y)xO$x9q%-<KqSPtlaC#A{1OLGgBoBS8Hpp;k;@9~LGOF8X3uDxN+{
zfb+4X>2cW6U!%bFVrlm#*buf@&>Y^qnWfNf%E8sT>!JT6xAKoBAp`)!d)#y!f^O=o
zN&fnZs@jbwfVbNAvqF>*G)MZHX!;b3b|Vak(ZY(cZOyedXRzTVeS7@nSA|yh+iQKc
znB7c32l{f$DF8~)d*k)IyXbAl*TCJK*=1Tyuly*PQ^&cxakJIx9Q4uWJhbTIf<j?)
zRsW3>s{NIt5}KVM`@{N8vlhLP%aN?p9$~xrbWrDIw#4`zH*bb0SeX0kf@8!oVp_$#
zmCoRU)>Xw=Bd@i0HUh3y3UZeMlEVMTIin^s=YKikXr0W9U<scK_=vD+TW$Mpx_Ne~
z+9s)|9b7`#nkVO|^eW<otSaI8!hLnU{}FDSB0?t<*BMq*qOP7mPk~T#0!w?}S6^GZ
z=g9Jzq352cSb)T{l6L-;4@OgjReP~jB3}Gu&#sNo_r8F6E1J(Xl=Ab8l=g>dh(9u?
z-5Z>CrH%m*c0Z?=pi;IsPmk!>bUwk~+;Hux;ZGC$+jf|5t2^8X?+Xx~E9m7k{EIb4
zR%s4zZNys%G@B$VNZpz|yWhcftU7LWj;a<5sK4|}Oro3rI{mE{mKv)fZXx8yN8b;y
zM(+pI7*tPzKY~jtMJl^t8W~}`Ve$40E%I1=i4PNKa*`u1<e`X6iEy2jV=vb3+Xv@7
ze<egbtC>w?7iF%j+@qd{s^kxTp}@U)tiQVcBgfSN<$E!?-aFs%gy#Nw>`Say6-vF!
z>Gz2fc9$JL)W&4}<zr{vVV$v^JH*@BTFdWr&y&!HHM4iX;QQ?{%Wojh_OCX^Th1mt
zvp~a~FNFEcbw`K=+7w}&!99tX%Z<|Wsws{&Fh{w$v0;YJ5p2ho!wCjF#QxoJzaxgg
zf%He-;9#S4`y6tlH-Q!_qM%AEhrdfpw;QsscIyr~Gpr~r!ymP_!e1=_DKod_Mj82E
zgPw(j%F=?@Y}{T?8%OKVdp(Ozjt+2&gKRABaC%QuWfyy)XZ=Fnk5&yTy~m3JB3n#|
zH&`*74SZ)75ne``s1y{T_D4H&JS#}GP`&KkbDN+VbUD9m4IR)dPSf7P>;e~Oh=5lJ
zI%04!bHnz9p)Ga`wblC6?a_QY0`kbl`}2?&`VmRbEm}L$e8(Z9%a7ab&i`xbsl%e^
zzTTygSV~x>Q;=FDMLMMwMRH+*mr%N4S-Q&t1nCfv?(SB2fknDgccrD9Z{+>`@y&Dp
znrG(By(i|Lb5C9IF`fPUK=AqkNIi=KG|m`$i;=x(X&2D}AIh&5gbZiD>123dM&$Vv
zUsRNC6`x?3z`Ah`6KVh20HHs=eeE(lKk9UxCsYLz_><Qwe!53O3f}6Br(hKgqbUD~
zEdBgdV{93f9o;xQ$m$7^(<z0MuJ-%-As)At0IfO4?Fo!zAdB0MyS<s*!C*@bf3Gpv
zGlMi$o;m{kC6+X}G)NVvHG>_SU*X8<i_MOJiHpBuzW(~BWr@kj*8r`N#}+M0V3C$4
z5rq=K^-5&tDebw&)gR|TYmF(jad&T4Ir6uzp40C!pR~s0RPN69hQ79QDI+;J+1@?#
zV?Z9Id%U~4*>#esUa1D+u*hF=Y3E?@KU;WDy#1Gk)ZMZAB!Vkc+^_EqKJ>5Fx1E*9
zUg?0P9Z?alU2&=e3V)6$4(AsWL>PMoWh#4@pd1el=QStB?X=+Swht2$4_+}3G!<VQ
zXn?|lmdj--2ki#8%Ng&{#&XXZ<+BccOHWl=E$j!!pUZ5xx|q>ff8<#8^2gM>OeDrJ
zQ~#-pl6%*$&u@DdcWq6lPD^7tAnRDpg|oH|insXmLDT_U6xHH=S>g2zo-Tn8!rpuG
z@+P_b^|L_+7u`EaVzUOVAZ<Go<Cg=+<dO;>K7{y)Wx|`d+yB!MamjnT)TTZzovypT
zi|*f(5vtw6VP?3`+x{)1Bn=64owU?|?Hg)LIk!<XbZ}023mL$(k|tkyDpyF<smbS%
zDp#)eI-l`X*m-+i=Jn=}V7gUh_E{OEUB70(@t*A&NGoCuz98{A?pbpfqX|FW3hDk`
zq?N^cl%6T7M0eB(?}@QAs1THlU*sO7E?{YtCORY=hZ8)AmOyPT(96V-lI8BA^Ex7R
zzh`7QNSgVZ3hbVjKgVVJd&>D-E6Zj!zig+>^pMflC-H7b)b#l4P?h5(k0AX!kN^2(
zO<9P5FA1#YxqT|9ya*TkwL=@cva$Peie-wzp=n|Tuaf6yS&Un_r0k1!{41Zop;y;`
zWP6I8kX8#5d*`!jq{uFdOv$r(YV^^uL1Z;w#D~#YF{AY+J}fEesJx$}e(6i`w<9Hv
zyDp81-^Z}`r5jdCyro;N*)zL}{r^nCynBUAj%LMI9BwXnm(429cxf>Xh2<OAl8O(N
zGj^duq;F*LM#JB~j+my^)N1vvYh=XEvoSvNv;w<wh3&<a^IZ6$RuwjCvp=N!?VO3!
z0P!fYCKvm!C|HlT!m42S+6f(x7tk?@bV_-(cO@j7W>HsDUqm!o<kFcvR9rCPPAT54
zOsHjCh^4(fjoE3jpdn2-pA?gmu~hlXStFK0i^{<7Q7#M;-g?IKOW0}3G?b%VJ*x4o
zh;KNygqNFjv}=v9yZavo#J@+Pcm;EqxPk#r4r?3Oe!jkl$){!K)w-oqMDK21myhvA
zN#xIv>ME7TUY-DDMn7%pBJp}W5i|$Q8~#*dHV>ORQn@HHWy1FMIvpV7`kvq_6nTDc
zmL#fyu*7$P(SY>TJ5-7FNA#TSK^{Ze7;zo3MGE!Ptnv|&$&+BRwif*m?&yY_>x;d1
znJXSr$W#Vn=k{@(meQ5x!`Ejip6c~=<$X2roD)qk%{)zo?b|9JhT)PKUA$^@1MpNC
zl5X^<sOQ(hBb%dO2Z5cU+!i@Z%@9uOyrD-hixG2G7WJHP<3rBCpCHAhyC>8$0W}ux
zC;zVc0AWIGS{ZwG{>OQ2HK%t%pXzMW!N0|o0nQ{*6sV*dw{Hapvmba@se&AXbQbN$
z*Z-kF`)t;Wy3e<Fkivf`WV7qp3$Rw$tA{u#1TXXu+>c1LLJAWQML=6S{FnEd*g}L3
zk1jDqcNF!_x$husVK48dz01Lr2~w4kSjHE(RY)NZiDV8i0pYtSO!Micpg(b=$r0k|
zHdQAh=wo5>Pdn{2Z-x_@y`8#-_H5~kP7*ee+H=EIBp<dZ#5HwyKqwS~GdqhP#MFz-
zYUq0hDNTbzD5hH58xLxQ#lgvO#?@Nk5v$n33gTzh<km`Wq;4aM9*WdBi=R4+Yr=uP
zD*AWj^blX~XzGRY(3yWzPF5d1rg=EjvGDxyjTg$5A!FE70%zq@VR@Yt3F|c2xz@`E
zh~>1jUzk{`R$jJJ6v%Nuk2;25zE0xv;1dM3fJWtm^6f(^v1(lvqUpw7lIh+Ho2D_T
zj!l%Z=cDibOqBaEl92oqCh?wonpF@#>BiZgGiYFxrtGxzY;Y-)g=o6khB=?BznJ7u
zk`EiMM0>ap$?6`+n+|8rCA*iF5+oq9SfJ0P6J&1aPQGhbB`0g8@i;mc!u7)cK=-}4
zO#sX=x?k?^24*qnAqfdz1Aiw5r7ET*|7z;h<?l?;fN3a0^KfEy%lL;Y?DBAaklgwZ
zOF88{@ZY!-E1V!+4A^i!kVs-ivMyxcv<};jD#eXVSq$*TS6d(bIYTvE>@)*a;p@$j
z$onHwZVc~ajwSl~M{4rq>X8IjJ{i(~42+3@be|zV-XPNiwJhoplEXOqMcvm-_)qZ8
zXI>CNcEYgsi{X3)KbODh%;<jFDw=Os_OUu}Tl=0Hdi&GvzLNoFS6@~lc5b)bpYVXH
zQ>s*gUI=t>|3c7I(U)YF%GvI=MHfzaQh7L#qZ;Tn<JmsBeQ?COIXpy*em*ySaZxKu
zcTze(#|yYu$QdL8aS6$nfo{*LGMW7Y19v7TbH35dv8S||W4~E%Y^siAc$0c9dYBo{
zW3bbc7&OL`XK?#pif<MTPw>zC))aKj3GjD6gb#>lQ5V0kfgu;-v`U+wT!}!(GS>W*
zN3Qn|%2NoMc`%Q0Lkh@vZ|#|((6tUpX+%1`SE!b9`165o?sWvsBVeORJ|B+sTwLiw
z^E%m0B+AxI_z+zUMe&WCb!|F+*OJQV*u&|F*}U=Xqz?hR3Gp*PfmryCagXGDFtqQy
zQ5GIjSOgQby7I=?q{7ZMg1d}rv*xI$zioS3{__tWJ3IT+e5k>M?-O~+bQ7m$5188y
z-=ohQC<lrQ#6L@v6?}xb>LwoxdqwRO)4E^itIOsbjrPJio(49`yn1p6bAQ)vFoxSo
z7`y0I;p6tHush!WM}|#@Z<fUQfIo&?(`g5SN;+CozKysbGUn<aq4gT3Lk8Ijc7C(T
z#*Cq>d6Hd&m}o$vZFp_f%$n3cqJ^X&!+_f@O7v8Qkxtyg;5#u9mBDj7yuuZ!S~{bC
zBp;rY^l2(j5`sJIC=TCfUc4~g=q~nHN2_Uu>D|M`lJ*;Dc+ekAM$e#`i}B!6fud_x
zdw}4tUk{tFWn4Tbb=yTa1dnRrPr@tEd6dq1N7eH!9|M8TmLHHC0<Km$XW&(n&(zB=
zeWeDYGeW-7K+DreT3N|-n_2&Eu%qfZ3t(;cK$5Zod12AJDnbzU%%BXdu5UJb7Q7o)
zL9Z3!1mw2t-rh}zcp6Y)OS;MW*4kP6;E43HBPjlm10zBL9Qy*a$#K%|@Y?fLZiCx#
z0l|+sjvyt;yH4118y%@hTEGzPJ7z9@h>jpY@;jvbE(3Yg!DDwAnz+$Zy}J?#Z_n}1
z_YZJd4e#k|;<oj?v*#^aZmznFwcfDe$2R3g+$Xy=A!%v1T0q0}APiXvq57C8HjE+G
z<UW#%JU6-7J|m3QI2bJiQmMJ&lf;nV@HOukneIpfh<2h#djOiG2k}0;lRSvyiQ&f@
zr4k*!EUIJ}Dd^7(&VRT(m*o@}$Jlw&b}&@66!&(kms$FfKCsDXjb%jPApC3j_OHgl
zMna2^od>C#W&aX?VHfW%8H@9E*cVB=2BF|XlvRu4BOScNK;t4(dC%jdt6?DG{nZkK
zl0IE?;pl(9N_L6skBHrS!G+vtHy&&wO{_a<e%bb-Z@aBBv*WPak#bgnKpLYJv?7D$
zR1Pmqe41tonM0PsU?~b|G7n&kJ@$U}`=zC-65x8Fw#n?yX74w;HdQ@g1b4$=W;FGy
zvq`2Q5dS^%!++?4?srFFcbpd#;%p(Li@1ujxUVt{GaYOAOlC0ePvCm`K7;WE=rNAX
z$HhNaVgi=x_Fb=&az6S3;(YkahSR;90yS>?U&fALEO#)(0~k2Jps^NANG_L7Mw!;l
z9sL-71uWJn8ej?!oN#gh3NQu|^g6it(WtdSO_p0D2ip8#wG9pgI$>AIK@YV5^1#C8
zQEqWFGw<L5oviO*>TWkKWFAt`5n^0=Wr)?LVo$;?x`2Hl0eGb)DwA!uxhluIH1u@}
zR02u5U^zrgK^J>%V_577x1{4`Wp2p7G$_np`IhA3<i+&mzf)QZ@j?%Rl0n?bpFwD8
zq8A^4gjDp$(FOL&R9j^XDw_;^LDcnz#_JVO9l1uwiJtBRL9cQI0?{DUl;mIb!7X$c
z0!U9}Pm9Iy_3Q;KFWw@oe3%#+&0BU`+ryGt);SSS0+jVo%A8_z!&3^f>_%1A{CPyI
z6iDv9{)%>{+@jM^G~o2xIh!s>)m61Q76F8=E-{IujfTKj#xG0oj5^^!LU$o|+~5|s
zTNbSX>dWk{z<|B9TByp1?fS+!civWWN)=ibbd+F)H>w#lOl(l^JYm~6=@A))&%FYk
z+dw4K`Uj}uBTH5ueT?F!rL#uM!sho+o=AG)h4`7a{E2G^wJ!zyaTBlsT3!ojZP+Gt
z8*~w&=LN&wUv>75T>jb3UY5p-UpQ+ZX-QGAJu((s6pTo_nXOu?G-@mHZQg-~us-Wh
z3bwT|K;q$<XLl2^g*uBf<f^Vnpcq4g{1DQe$1V4|18L2&lho})<S^z>C)s|*RNkvl
zAI(@22j^;`=Erz^gVm*dFDvUBmXhEn5C0wsHpr&|R_srH8N#Y8GcoSAZjhT=tlJxc
zAgq^Xi)m~&OVw#W$A<FU0N-g@pup)MQ03y1D7NzP(~ynE==;RC2f9?7Z@Z^}{5ddt
z<Lm}gO>J*9<rHz(q_Rg(j_8yKOR4587kUn?r}vzDI{x|Uj199>jITA+<wdBU_Hf9k
z-r#mvgB0vB9nDg)80wdrG+5Pt^ADStFS(B20k6c#={qs}2lgep1YLtSMDnJ!<xf@Q
zBri9rmWW+xGR8;5{2YlE&}oX}Pl<AdSn0fiE7VG=8T}|E&jAG(O;wDh=H+K5TO7Y@
zTgZL-jILEFr_gqhLQ@+jcTm)<`!3b8u#j!rQ^ocL0r0BpOagz7xwkhFMCSAWVTc<(
zdVaCTd2g@5^mMVb|D1&mXeu}1MWe8z20K4+=vDGQqc>ngJrJq9^mf_zUFw?(*agCJ
zHdAHw7mo<$5B|v3XNwVZ@h*i5i<@ssTPu_oA*97A4KBo>Zf*#&-WzpeOD_t%O2wvN
zCb0bUd|{enq+ho)LnHZ*MfPRX%A_f_WVrra)CXIq4?ERNDe!1*QF}%Qx(6RL^RF9d
znck5=<^v!yS2h8$H&-+59Yf{*qAfee249oZ={F7E0g2Lrnks<|O?GSZ#dM>Ur&bk4
zZCj%6Q0HrOfHOJm^jN&odEZ;{2%$-~lIPTs=rcKaF@`T&m7SEdyIJ^Pg*$CdYFN!T
zyYcwh8cQS`WC+;aYA{lgVP+f*r1RxJwo!Vvm7K{bKa5Bi8$r^UV9cK}4fd4im5Piz
zG0!z9UhqB(ZcPf3(=j~1Xj^og_rEA@_?1#DBq@ob_EAh=9ZvdVX0m;EH74!hv~IX0
zNhN1WHFL^^)$&2oTem%R9QZ*%nC;SBR#ehzcXED|3Ca!BXX0MEvt)CG!xnQxr|U9#
z?5p814~}18=t$J3B2r@J(Wg&PsPA~w^f>shw$}5LcTyS98(B`vz|hYe<5-+nlOoX#
zuE=E*CZw9u*eK&pQyH}dCj0z}dDW4YVfZLh%qwMqjx`t7BwmwC&5uf33r|9K%Crwp
zPO<~Cm>1v+*v(C4ZknPL^`YOe&PSSq&8LF{c_ql${J>H5al^>jS#2z`VgSd$;}1TY
zSk!P>yK>2iKlj_CIBB3w+l^km#pRP5*TR5PTxiP%r^i)UE-Vf`ARF{zdr9*ll00Ww
zy2YnVj7I5G+nv7Ymha`KPQk2rh4QzX6$@XCd3d9(o_O?Q+fh#2@3o9%&K!qZ_<X+#
zxgwiFtFSoGNmpMRcYK96`08KV+m=MNYC^1jAI~{<T{$&T78NN_+}8>C1`C`c{)eR0
zZz-Sn+oNUY62eIK$doy9_N?)<1Lv|!X4rY2mXo$tuG>!ehqv?5_E;o{)bt`-N5NSV
zb~XKu0?XKu-hN=-fWxZM-oK%IYI%dNvq3Dv?vOj|`vL0@Z+xN*2nNOa&}V)3*EG?)
zZ{CpNRi+*)h^6Lr7vNRKlaRv0Xw5=s;emw%bLVp<bC7=QU7DBS(_$voBZ2%zvX=Jy
zZ2Rm}r6j1Be_TmlS(e_|OLlSLnEDRdr}{!th)%&mjd(5-$O?XbbcF5+)T3gMMmwsz
z@>mbn_lt~4Z$qW%fIPvZ+aqZN`betq!Lr8X^rXle!SlOH7t9LZrR&tvB3@nN?;O5J
z?N=6vR5($DJ$@jH6FjZ_9zUJM6B<s<;(i>oiw(<ot7x1a^88<iZiq0&g{oQ_^<4DM
z;S?wOo>tI%)3E#4%Ij1W;QZ^1OQNbFecNSM8J`G*NWk%+>OwNpb#r@4<JlZ;B5HcV
zckz7i84m&ol{b`SoJsL_&7q>iM!32zlz`sSAUqN*l+qlOK?c`XNuwt!y%e7RZ6g-r
zHW_Duk>(h_4I!r(8XF`9G!PUEsdRj3lO%*4Xn@*>nxZf$NM(|$9Ku<MK&ID+_27)l
z)mwGW2=G)ja;@vFNOZ847Cf@Enq+TGMI@e=#B(Y3yW3J(nODico+exwB_y$w39vSt
zJ3ag2_^nJH3vkFTA(R$Kdl919d&3aiLQp6Hs7x8&M4VGF-4Ao(sJ;#S(4=<YA6--;
zA?UHFiuvFC=4u8&7?PlaFa(V&dh%CxUe2+=EZm<6j(hkuijfj~)b-HEIgHdjsWuij
ze1^%C4HYkv-#>GX10MtHSuX2tx-(nz*lqnJeW1D$d2MM(ck+n6tH~fK$tZW5M83y&
zsb=N$t*~s+@<4mwm>6NUa3d@_y&a@TgpRp&O3B-c13HGwi2PnJ>(^p8^b0$(r0;uD
zJ<^0lDgj)P*5><cnw?;k(ve4;Up|$P9Ew$DiSxe7opWIO^ycbXV32ECaxP45ZRTh5
zdw%|I$}825gt@XE0*pe*?hs6Z4ut!*%g1|7Har&wKi>7|mrv-b?^<U#T>XzaPnw*)
znpn0UgK|aiJRF#i7I~&V<StkW=<}Qi^(|-<FOf{E$<miZIBxE{uJt!w2~H8hSkf^D
zIxi3fzT7fc&u-iE`NNc>Ow}w+nk3FNstERTy^fc2F4n5wYw30lsh1~!93&ixQiaQV
zD!~jbj71nwtNX1vr=+2UA%6gb62T-dfJ{gO+6{#pZVAE0UdktY==AF*d`V4el$bS-
zfyt9~c}&Vy_O>UuP}5E}#G)|h%Oldp1~W%kIF9O8=G;r5g)CVAc%4@KyP_L&$f_(s
zNN%#w?Wsg0E$v2`M>f;%uqH_oX~w0dYA<rR$U}5DyQgWEvHSA?Aq8Y_j-1n#O_%5l
zXv?#%O)klUoIs)i&2MJ+QLcUKy{;^NZm;Lh*3T%ymm_-Uc}tFe|3jSv=Qx}R$gx!%
z$;%cP>flZ=3p!XajcoPB22t_{u}acQMhw%AArje0E9(vwwpjpaBXKY2#_N8>&p5g$
z5`?oE*8g;3l>1xnm1}Uk<+7X3&f8RTZz$>kX*O>7I0U{CE<i9!{+p8cKXm2wM)yM;
zmlDzOLfnJGutbfn2#AN`7IXIZ3|k&|FDU9w<@I-7`Y<Y{60NLM2XsVgiQqkJ=?6%G
zrP(#Pj3Yq&$+W*{d)#BSW+Ft?>7{E;hFDAi0r8Zvg}9`MM>v|Vvd%uUM3TMNfy!^)
zhdOtXOOUtGbalwU(m-vw%&W`O=NoA(Mnpps2G^#ndKdRRtH~z+T#DHz`KFc1lCOV0
z|FQR3YKC4QHLN%VtS_|?E-G%m=a`&^ORyW>*=SzH7UdSqB34d}rKIQ)i2qHB%Q{cS
ziXKH(Gsure?Ko~RNaoUZChnsdjWb8=V}!Aq2VRsW!;|l<Gi^5Q=w9WVQ#-Ud^JgeF
z1F5uuLi@`ayy!H)Ln`9nuXlhg-lAS%HO<ysQ#){FPjs^9AZpgXm~3*Nuit*~{jz(_
zaW@(YezaLqEKQk2nBqp1vU$HI_vdHcp;40CA|$|8HJXCWa8{f;m?>qKNOiEVU2E7b
zw0+XhNXOUIn3^Wn?=8Si${MM=PD_JaBAd8S5BxCuG)w3Izi+$KhbL*Q9x__Hz>2Pa
zE#}#5bQ1&^$f7~R8snb@RI`VDSqRHj+jbY8;dphfE0nflU+H%y-*1(=-S+Y1DM}-D
z4m)Vl$PzmfU7HoMs^>)LNpM(dybnL)*o+2i<6Kqs{i6)1yWdXQ7+p`9uy6fr;U`|y
zv7d5*RAVJQ?xzgELMkn7+q8-P%$$cg2;ny1-fb8E7TiYsj^wGekwKO)Q!=7s97^;r
z1$_JiQQ%5eQ$%)CMCTjBy)ZWl*O9={oKih4#e6Si3Z<i3GHIM(79xv&ye9D<$rb#1
z`YHd&FKHGxH_|V&RM*BhzF-T|Zuv^~$CSH`_rtCay*eXA!3~ZND>aX|AWb)=kf+dN
zC6T<H5|$jIISN+cnW&%E(=aAFoP;p-Rn5__{mWWvymdsYEvt`cab__~g;Fz&e~7$;
zi-$WjLkNt%1~AH;9OXh~@|zT~6Z=fe&<II=E8IlEwhMPfM06fp-yHAkh(~Y6;_mrc
zZ!M%R)CNIetQ>iqubqm1<>+1q9pAKXD!){YrV>@wdQBzY+ARF!Nvm^S5%YB4^wyI@
z9}Y)~>HY}ew6kqr8S)#?*3Ag@`X-JnO#4N%f4|*~dQ|cVyD8V=9p6`s{e)KsyjL^+
zb%#)wFoaZ`<C&rR;7HDvKQm#mQ?9As-J^{`?(TEOy6(h4pg^je#oQX<6a?EWGvIhJ
zTQu&N)E;a)wR`O=kiu%(HZUh{^Ycx%uY~=4(6Fe&K1Wk;HQ*m&3tv(ON+^*}E-AI1
zTfSWIs=t;8{{?1rwZ-jOo%?lCu>1tyvw14x>!WaK>;#kRe$M0aFE-nmdXJla$h-Kt
z_2c%;@pv3otB#H^DbHWAskgsv@}tzdklHw^e_n5<O1eN6c3?$XD@+XnGX}0VHNUew
zzZ|q{LztbaGt4A4FmGiCo9a;x@vYh?R_l1?MSIjnT6_JGy!7{3U0G2fJL0PwQl$ij
zmp{GLv`VcHr3V0eC^KgkMQ!EP3ZeFj*KvmdMd#ix9iPf;UhnHAEF2G+eHEM@dmMcS
z*_yfAY#T0NY-Re(pFzun0<96Xy_yjbF-NxbljVHo^<ni`<mn{}d$jqrPF8v13aWR)
zR<v{Rbyn8w{`|!ZHRBzijAHCEXM<$qcIyL|)74G!3tz%9l6P{<-TZbQwVAJmQ|GT-
zU-7T42Zz*M{Jes`DHqyWxhY1{`bo$5BhQ`M1DNK`lz#(+yJpfmc{s46m$0q#{7AN^
z?(Fk0E}lE6FZ*ga_n><<ym;xx<2Tc~kV$o2!JYGUn8l+g+qo~`RtESZQ<-D*`$rA9
zEfc;$0w9+D!EJMQCuq}o?gd@I5al>}Q+l{(um_`;o|p?YJxKY%EFIhS_!tcW@Y3P%
zT1V!wS)G5LoNUxKXGCb6IRpvcE+1&OrSf{l^Jgu0<i<{FD}T@+;8X)b0@~%&m<K<#
z{JJqMbtz)KbhWY%3%J1unN-Q3Xd-&H|K#rfUcY2IZX1~qFAixII_sr#+1oFFUTW3{
z`>g7PIs6ge1%mS4bqDFrFv&*l?DQ5eo~S}{n@?8mQUzRR)|Z`3ebZ&5jY?`P7gr?J
zV_Zldn@;n;zunpobmPX61hr_Sj@gU~UZ3nA`MU^Cz6<ckD;G|<jOdy0&4>~fbX%(F
z?FRiV2<)q;UXpPs*%V(u`7`r{USZA?pZmoR+M}{fN~0xXfi^_7n9tra&3pMx(u9XD
z_AfwzsTL4P&}+r>U!7yNIx=so94x&guJjGsi`J(~CWv3z>FX&8$4D6e+{`qO#MWW-
zyTBbcxPMndUnJ=n|7)n*M``P$zS$;6weybEP6ikRP!HO=^(48N5A2swUobl?<No*F
zd$f~b`nueHcL-~Ke45{vVDi87-3@{7t2L|}8nxNG9*-g|p|}8bK=n-MgM?GeLD~iS
z;`)*f1h5;-;yc7er<zcj%|h~f_4>7}gQVp>Kzcw86M-28Z{X@Zt{K&tMuYQU3N$#-
zI6X98@03n0snMxU+m%pGjxf+g!ykf7v{ySrd77%}(4nWoAN|E_tnsll_WP{9x{~nV
zl+L!81(ek0b_wO{*<~-!WaJIFOn%9bQkI6Sf&j>JGVOr#y*w<Ygs_(w`*&g;rCMFY
zHY*|Lmjj}}bbysM2+fRK3#id2{}J&5?f`@1a4t18ez+@!%Pdu_w0QC_Bt*-Z)P<;>
znlQ$l>iL6a9LG%#po}GeyK+{S(b|L-jd_hI1CC}#2k5Y(<ShmiI9=q*<3~E&E`WIe
zD@u*`(sI}Px%fg_rvcJh3%UJNACDV;Ymuwd*RtYB>rcgTrJOsrFaHS4@TNwJ2H*1*
z8k`77olGY93*rOUVGp%);?2{2`wR5ku-gBgMP+zHkl))gk&;moPu&-0VM_MCYxn=I
zq>m2$LLc2f8gbxLcI=-1A5swRkIKW#R6YtPX;oS6l#2cbMe;K*HZPXlR!pnR-(C;>
zmoA7{@B+_{)50*-sHQN!`+p!+plE9SLe-Z<rW{7Ub_8yj1!^UyBLz<S!*Qrd*n8yH
z<7i|5moYjTaFDByjtq{oRFyQz*~uaMH3ct}Z^`=s-+iiNA-Pv-gzyeP*1wb$$ikHB
zCPAlOug7rd_%4LqGF&bRHtNChqq2*ZRKtwx`J$}9a03JVEggynzMZ>9p7E&~r>);U
uigP}s)xlm2eCywMllsZJJ~7a4K>+AZ3f%>n<Kk-&aH%P4E0rlAg8vUc&*U%w

literal 0
HcmV?d00001


From 3543283a4dba8832dfb5c545660574828c68b611 Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Tue, 1 Aug 2023 10:23:33 -0700
Subject: [PATCH 457/749] Update balance card

---
 assets/images/illos/balance.svg | 318 +++++++++++++++++++++++++++++++-
 1 file changed, 317 insertions(+), 1 deletion(-)

diff --git a/assets/images/illos/balance.svg b/assets/images/illos/balance.svg
index 6348f827513..e67de220483 100644
--- a/assets/images/illos/balance.svg
+++ b/assets/images/illos/balance.svg
@@ -1 +1,317 @@
-<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 394.89 211"><defs><style>.cls-1{fill:#fff;}.cls-2{fill:#b8c0d7;}.cls-3{fill:#e18173;}.cls-4{fill:#d1725f;}.cls-5{fill:#dee6fd;}.cls-6{fill:#a6aec5;}.cls-7{fill:url(#linear-gradient);}.cls-8{fill:url(#linear-gradient-2);}.cls-9{fill:#472f5b;}.cls-10{fill:url(#linear-gradient-3);}.cls-11{fill:url(#linear-gradient-4);}.cls-12{fill:#29163a;}.cls-13{fill:url(#linear-gradient-5);}.cls-14{fill:url(#linear-gradient-6);}.cls-15{fill:url(#linear-gradient-7);}.cls-16{fill:#6e425a;}.cls-17{fill:url(#linear-gradient-8);}.cls-18{fill:#b1615f;}.cls-19{fill:#aa504b;}.cls-20{fill:#b97577;}.cls-21{fill:url(#linear-gradient-9);}.cls-22{fill:url(#linear-gradient-10);}.cls-23{fill:url(#linear-gradient-11);}.cls-24{fill:#283047;}.cls-25{fill:#bf6e73;}.cls-26{fill:#210e26;}.cls-27{fill:url(#linear-gradient-12);}.cls-28{fill:url(#linear-gradient-13);}.cls-29{fill:url(#linear-gradient-14);}.cls-30{fill:url(#linear-gradient-15);}.cls-31{fill:url(#linear-gradient-16);}.cls-32{fill:#020025;}.cls-33{fill:url(#linear-gradient-17);}.cls-34{fill:#1d002e;}.cls-35{fill:#e8aa5d;}.cls-36{fill:#66263f;}.cls-37{fill:url(#linear-gradient-18);}.cls-38{fill:url(#linear-gradient-19);}.cls-39{fill:#d2d1c9;}.cls-40{fill:url(#linear-gradient-20);}.cls-41{fill:#51102e;}.cls-42{fill:#351a48;}.cls-43{fill:url(#linear-gradient-21);}.cls-44{fill:url(#linear-gradient-22);}.cls-45{fill:#e9c35f;}.cls-46{fill:url(#linear-gradient-23);}.cls-47{fill:#99660a;}.cls-145,.cls-48,.cls-62,.cls-65,.cls-81{fill:none;}.cls-48,.cls-65{stroke:#99660a;stroke-width:0.44px;}.cls-145,.cls-48,.cls-62{stroke-miterlimit:10;}.cls-49{fill:#3c93be;}.cls-50{fill:url(#linear-gradient-24);}.cls-51{fill:#281547;}.cls-52{fill:#e5f0ff;}.cls-53{fill:#b8c8e9;}.cls-54{fill:#c8d6f3;}.cls-55{fill:url(#linear-gradient-25);}.cls-56{fill:#190e30;}.cls-57{fill:url(#linear-gradient-26);}.cls-58{fill:url(#linear-gradient-27);}.cls-59{fill:url(#linear-gradient-28);}.cls-60{fill:#1f1a66;}.cls-61{fill:#2d68be;}.cls-62{stroke:#1f1a66;stroke-width:0.37px;}.cls-63{fill:#8aa1cc;fill-rule:evenodd;}.cls-64{fill:#5f223e;}.cls-65,.cls-81{stroke-linejoin:round;}.cls-66{fill:url(#linear-gradient-29);}.cls-67{fill:#dae0f1;}.cls-68{fill:#6c3e2f;}.cls-69{fill:#23001a;}.cls-70{fill:#ed5e41;}.cls-71{fill:#e8225e;}.cls-72{fill:url(#linear-gradient-30);}.cls-73{fill:#622f20;}.cls-74{fill:url(#linear-gradient-31);}.cls-75{fill:#e20040;}.cls-76{fill:#c280b6;}.cls-77{fill:url(#linear-gradient-32);}.cls-78{fill:url(#linear-gradient-33);}.cls-79{fill:#d8b2d4;}.cls-80{fill:url(#linear-gradient-34);}.cls-81{stroke:#d8b2d4;stroke-width:0.79px;}.cls-145,.cls-81{stroke-linecap:round;}.cls-82{fill:url(#linear-gradient-35);}.cls-83{fill:#ece3de;}.cls-84{fill:url(#linear-gradient-36);}.cls-85{fill:#efb94b;}.cls-86{fill:url(#linear-gradient-37);}.cls-87{fill:url(#linear-gradient-38);}.cls-88{fill:#e9043e;}.cls-89{fill:#176498;}.cls-90{fill:url(#linear-gradient-39);}.cls-91{fill:#a26200;}.cls-92{fill:#2a001e;}.cls-93{fill:#f0e6ed;}.cls-94{fill:#8a0e2f;}.cls-95{fill:#133963;}.cls-96{fill:#d8d0ca;}.cls-97{fill:#ed7652;}.cls-98{fill:#de4a6c;}.cls-99{fill:url(#linear-gradient-40);}.cls-100{fill:url(#linear-gradient-41);}.cls-101{fill:url(#linear-gradient-42);}.cls-102{fill:#e05b7b;}.cls-103{fill:#c6a9a1;}.cls-104{fill:url(#linear-gradient-43);}.cls-105{fill:#ee8b6f;}.cls-106{fill:url(#linear-gradient-44);}.cls-107{fill:#d46655;}.cls-108{fill:url(#linear-gradient-45);}.cls-109{fill:#254870;}.cls-110{fill:url(#linear-gradient-46);}.cls-111{fill:url(#linear-gradient-47);}.cls-112{fill:#e6e4eb;}.cls-113{fill:url(#linear-gradient-48);}.cls-114{fill:url(#linear-gradient-49);}.cls-115{fill:url(#linear-gradient-50);}.cls-116{fill:url(#linear-gradient-51);}.cls-117{fill:#001e3c;}.cls-118{fill:url(#linear-gradient-52);}.cls-119{fill:#d8c570;}.cls-120{fill:#d8c670;}.cls-121{fill:url(#linear-gradient-53);}.cls-122{fill:#d67d67;}.cls-123{fill:url(#linear-gradient-54);}.cls-124{fill:#d67c67;}.cls-125{fill:#06061d;}.cls-126{fill:url(#linear-gradient-55);}.cls-127{fill:#d56348;}.cls-128{fill:#d67b67;}.cls-129{fill:#160828;}.cls-130{fill:#392034;}.cls-131{fill:#ddedf7;}.cls-132{fill:#4d2839;}.cls-133{fill:#d67066;}.cls-134{fill:#ca2f79;}.cls-135{fill:url(#linear-gradient-56);}.cls-136{fill:url(#linear-gradient-57);}.cls-137{fill:url(#linear-gradient-58);}.cls-138{fill:url(#linear-gradient-59);}.cls-139{fill:url(#linear-gradient-60);}.cls-140{fill:url(#linear-gradient-61);}.cls-141{fill:#662234;}.cls-142{fill:#170829;}.cls-143{fill:url(#linear-gradient-62);}.cls-144{fill:#03030d;}.cls-145{stroke:#d9bf6b;stroke-width:0.45px;}.cls-146{fill:#ccaa38;}.cls-147{fill:#d9bf6b;}.cls-148{fill:#792c29;}.cls-149{fill:#ac5642;}.cls-150{fill:url(#linear-gradient-63);}.cls-151{fill:#e4b17f;}.cls-152{fill:url(#linear-gradient-64);}.cls-153{fill:url(#linear-gradient-65);}.cls-154{fill:url(#linear-gradient-66);}.cls-155{fill:url(#linear-gradient-67);}.cls-156{fill:#926948;}.cls-157{fill:url(#linear-gradient-68);}.cls-158{fill:#340c10;}.cls-159{fill:#40151c;}.cls-160{fill:url(#linear-gradient-69);}</style><linearGradient id="linear-gradient" x1="257.24" y1="132.03" x2="262.09" y2="132.03" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -17.4)" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#c36750"/><stop offset="1" stop-color="#e17c6c"/></linearGradient><linearGradient id="linear-gradient-2" x1="259.48" y1="142.34" x2="261.89" y2="134.81" xlink:href="#linear-gradient"/><linearGradient id="linear-gradient-3" x1="291.48" y1="186.75" x2="306.1" y2="244.08" gradientTransform="matrix(1, 0, 0.02, 1, -1.52, -0.03)" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#472f5b"/><stop offset="1" stop-color="#301342"/></linearGradient><linearGradient id="linear-gradient-4" x1="295.21" y1="221.18" x2="334.03" y2="221.18" gradientTransform="matrix(1, 0, 0.04, 1, -3.49, 0.17)" xlink:href="#linear-gradient-3"/><linearGradient id="linear-gradient-5" x1="260.93" y1="170.36" x2="272.13" y2="170.36" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -17.4)" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#b8c0d7"/><stop offset="1" stop-color="#a7afc6"/></linearGradient><linearGradient id="linear-gradient-6" x1="296.19" y1="187.03" x2="298.25" y2="160.53" xlink:href="#linear-gradient-5"/><linearGradient id="linear-gradient-7" x1="284.6" y1="143.66" x2="281.11" y2="160.42" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -78.34)" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#b8c0d7"/><stop offset="1" stop-color="#d4dcf3"/></linearGradient><linearGradient id="linear-gradient-8" x1="280.95" y1="121.87" x2="288.88" y2="119.65" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -17.4)" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#673850"/><stop offset="1" stop-color="#55215a"/></linearGradient><linearGradient id="linear-gradient-9" x1="295.67" y1="177.6" x2="295.77" y2="184.08" xlink:href="#linear-gradient"/><linearGradient id="linear-gradient-10" x1="297.28" y1="168.09" x2="304.98" y2="154.6" xlink:href="#linear-gradient-5"/><linearGradient id="linear-gradient-11" x1="260.83" y1="139.26" x2="262.71" y2="147.74" xlink:href="#linear-gradient-5"/><linearGradient id="linear-gradient-12" x1="283.08" y1="134.46" x2="282.39" y2="137.11" xlink:href="#linear-gradient"/><linearGradient id="linear-gradient-13" x1="280.83" y1="134.15" x2="280.83" y2="134.15" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -78.34)" xlink:href="#linear-gradient"/><linearGradient id="linear-gradient-14" x1="287.52" y1="108.31" x2="285" y2="105.58" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -17.4)" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#b8c0d7"/><stop offset="0.56" stop-color="#c7cfe6"/><stop offset="1" stop-color="#d4dcf3"/></linearGradient><linearGradient id="linear-gradient-15" x1="297.42" y1="122.43" x2="298.95" y2="116.57" gradientTransform="matrix(1, 0.04, 0, 1, 27.21, -17.4)" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#b3bbd2"/><stop offset="1" stop-color="#a7afc6"/></linearGradient><linearGradient id="linear-gradient-16" x1="290.59" y1="106.33" x2="299.53" y2="106.33" xlink:href="#linear-gradient-15"/><linearGradient id="linear-gradient-17" x1="320.5" y1="131.82" x2="315.99" y2="129.8" gradientTransform="matrix(1, 0, 0.02, 1, -1.98, 0.2)" xlink:href="#linear-gradient-5"/><linearGradient id="linear-gradient-18" x1="229.22" y1="103.03" x2="233.06" y2="100.98" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#5a1d3b"/><stop offset="1" stop-color="#51102e"/></linearGradient><linearGradient id="linear-gradient-19" x1="228.66" y1="131.59" x2="226.87" y2="124.42" xlink:href="#linear-gradient-18"/><linearGradient id="linear-gradient-20" x1="223.13" y1="100.69" x2="227.89" y2="99.89" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#cfcdc1"/><stop offset="1" stop-color="#bcb38e"/></linearGradient><linearGradient id="linear-gradient-21" x1="231.1" y1="130.78" x2="262.61" y2="130.78" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#e9c35f"/><stop offset="1" stop-color="#e8a35c"/></linearGradient><linearGradient id="linear-gradient-22" x1="264.21" y1="128.56" x2="240.9" y2="136.27" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#e8851c"/><stop offset="1" stop-color="#e8a35c"/></linearGradient><linearGradient id="linear-gradient-23" x1="238.57" y1="180.09" x2="221.57" y2="142.02" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#e89e5b"/><stop offset="1" stop-color="#e8a35c"/></linearGradient><linearGradient id="linear-gradient-24" x1="235.93" y1="214.44" x2="244.75" y2="192.83" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#0b78a9"/><stop offset="1" stop-color="#2e8bb8"/></linearGradient><linearGradient id="linear-gradient-25" x1="234.02" y1="141.1" x2="229.51" y2="146.32" xlink:href="#linear-gradient-18"/><linearGradient id="linear-gradient-26" x1="237.74" y1="110.57" x2="245.38" y2="110.57" xlink:href="#linear-gradient-18"/><linearGradient id="linear-gradient-27" x1="208.06" y1="150.88" x2="217.53" y2="150.88" xlink:href="#linear-gradient-21"/><linearGradient id="linear-gradient-28" x1="206.71" y1="160.56" x2="226.68" y2="160.56" xlink:href="#linear-gradient-21"/><linearGradient id="linear-gradient-29" x1="225.91" y1="91.53" x2="241.05" y2="103.44" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#351a48"/><stop offset="1" stop-color="#1d002e"/></linearGradient><linearGradient id="linear-gradient-30" x1="123.77" y1="205.71" x2="130.19" y2="190.89" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#ed5e41"/><stop offset="1" stop-color="#cd4a41"/></linearGradient><linearGradient id="linear-gradient-31" x1="127.76" y1="224.14" x2="122.74" y2="250.44" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#5a2614"/><stop offset="1" stop-color="#5a2614"/></linearGradient><linearGradient id="linear-gradient-32" x1="144.89" y1="255.36" x2="130.18" y2="225.45" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#663526"/><stop offset="1" stop-color="#622f20"/></linearGradient><linearGradient id="linear-gradient-33" x1="124.91" y1="204.81" x2="133.4" y2="213.71" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#e8225e"/><stop offset="1" stop-color="#a2225e"/></linearGradient><linearGradient id="linear-gradient-34" x1="93.22" y1="147.16" x2="115.07" y2="176.03" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#6c3e2f"/><stop offset="1" stop-color="#592613"/></linearGradient><linearGradient id="linear-gradient-35" x1="113.11" y1="200.09" x2="117.11" y2="189.06" xlink:href="#linear-gradient-30"/><linearGradient id="linear-gradient-36" x1="143.23" y1="250.71" x2="147.42" y2="265.43" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#ece3de"/><stop offset="1" stop-color="#e5dab6"/></linearGradient><linearGradient id="linear-gradient-37" x1="152.6" y1="268.53" x2="148.37" y2="266.06" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#efb94b"/><stop offset="1" stop-color="#ef9c32"/></linearGradient><linearGradient id="linear-gradient-38" x1="124.26" y1="253.34" x2="117.56" y2="262.67" xlink:href="#linear-gradient-36"/><linearGradient id="linear-gradient-39" x1="124.39" y1="272.13" x2="118.17" y2="268.22" xlink:href="#linear-gradient-37"/><linearGradient id="linear-gradient-40" x1="171.58" y1="229.01" x2="154.28" y2="251.2" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#c1447b"/><stop offset="1" stop-color="#de4a6c"/></linearGradient><linearGradient id="linear-gradient-41" x1="168.04" y1="222.36" x2="171.92" y2="218.09" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#d8d0ca"/><stop offset="1" stop-color="#cbbfaf"/></linearGradient><linearGradient id="linear-gradient-42" x1="171.37" y1="271.74" x2="175.94" y2="265.16" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#ee8b6f"/><stop offset="1" stop-color="#de786b"/></linearGradient><linearGradient id="linear-gradient-43" x1="164.61" y1="262.5" x2="183.62" y2="234.52" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#c6a9a1"/><stop offset="1" stop-color="#be9b90"/></linearGradient><linearGradient id="linear-gradient-44" x1="165.96" y1="252.85" x2="186.83" y2="220.06" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#c1447b"/><stop offset="1" stop-color="#e05b7b"/></linearGradient><linearGradient id="linear-gradient-45" x1="141.67" y1="210.67" x2="166.7" y2="210.67" xlink:href="#linear-gradient-42"/><linearGradient id="linear-gradient-46" x1="238.37" y1="278.76" x2="239.37" y2="288.34" gradientTransform="translate(5.94 -32.43) rotate(1.76)" xlink:href="#linear-gradient-42"/><linearGradient id="linear-gradient-47" x1="186.38" y1="282.19" x2="226.96" y2="282.19" gradientTransform="translate(5.94 -32.43) rotate(1.76)" xlink:href="#linear-gradient-43"/><linearGradient id="linear-gradient-48" x1="188.7" y1="254.65" x2="188.15" y2="217.84" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#e6e4eb"/><stop offset="1" stop-color="#d8d0ca"/></linearGradient><linearGradient id="linear-gradient-49" x1="192.88" y1="213.3" x2="209.58" y2="240.3" xlink:href="#linear-gradient-48"/><linearGradient id="linear-gradient-50" x1="173.28" y1="211.38" x2="190.58" y2="220.17" xlink:href="#linear-gradient-48"/><linearGradient id="linear-gradient-51" x1="185.1" y1="292.67" x2="210.84" y2="292.67" gradientTransform="translate(5.94 -32.43) rotate(1.76)" xlink:href="#linear-gradient-43"/><linearGradient id="linear-gradient-52" x1="82.12" y1="138.23" x2="79.09" y2="128.18" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#d8c570"/><stop offset="1" stop-color="#d7a66c"/></linearGradient><linearGradient id="linear-gradient-53" x1="49.85" y1="172.47" x2="69.63" y2="142.8" xlink:href="#linear-gradient-52"/><linearGradient id="linear-gradient-54" x1="82.5" y1="139.38" x2="70.6" y2="123.76" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#d68168"/><stop offset="1" stop-color="#d55b62"/></linearGradient><linearGradient id="linear-gradient-55" x1="87.4" y1="161.54" x2="88.73" y2="150.72" xlink:href="#linear-gradient-54"/><linearGradient id="linear-gradient-56" x1="76.75" y1="148.76" x2="69.33" y2="134.41" xlink:href="#linear-gradient-54"/><linearGradient id="linear-gradient-57" x1="67.07" y1="147.48" x2="84.14" y2="191.82" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#160828"/><stop offset="1" stop-color="#0a061d"/></linearGradient><linearGradient id="linear-gradient-58" x1="94.28" y1="170.66" x2="80.08" y2="158.37" xlink:href="#linear-gradient-57"/><linearGradient id="linear-gradient-59" x1="38.17" y1="101.39" x2="59.87" y2="139.52" xlink:href="#linear-gradient-57"/><linearGradient id="linear-gradient-60" x1="84.05" y1="255.75" x2="77.51" y2="245.22" xlink:href="#linear-gradient-57"/><linearGradient id="linear-gradient-61" x1="78.44" y1="244.6" x2="50.68" y2="199.13" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#160828"/><stop offset="1" stop-color="#281a3b"/></linearGradient><linearGradient id="linear-gradient-62" x1="55.63" y1="-189.68" x2="52.32" y2="-193.07" gradientTransform="translate(71.05 277.79) rotate(-18.92)" gradientUnits="userSpaceOnUse"><stop offset="0.01" stop-color="#170829"/><stop offset="1" stop-color="#03030d"/></linearGradient><linearGradient id="linear-gradient-63" x1="274.2" y1="235.63" x2="280.2" y2="252.92" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#ac5642"/><stop offset="1" stop-color="#792c29"/></linearGradient><linearGradient id="linear-gradient-64" x1="275.36" y1="272.11" x2="273.89" y2="257.53" xlink:href="#linear-gradient-63"/><linearGradient id="linear-gradient-65" x1="242.52" y1="257.8" x2="260.29" y2="257.8" xlink:href="#linear-gradient-63"/><linearGradient id="linear-gradient-66" x1="270.32" y1="267.81" x2="267.1" y2="253.12" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#ac5642"/><stop offset="1" stop-color="#bb776a"/></linearGradient><linearGradient id="linear-gradient-67" x1="245.2" y1="254.46" x2="250.59" y2="249.3" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#521c1f"/><stop offset="1" stop-color="#792c29"/></linearGradient><linearGradient id="linear-gradient-68" x1="675.88" y1="925.53" x2="688.25" y2="925.53" gradientTransform="translate(459.18 -870.28) rotate(45)" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#926948"/><stop offset="1" stop-color="#774d2c"/></linearGradient><linearGradient id="linear-gradient-69" x1="675.25" y1="919.1" x2="689.69" y2="919.1" gradientTransform="translate(459.18 -870.28) rotate(45)" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#44171d"/><stop offset="1" stop-color="#2e080b"/></linearGradient></defs><title>building</title><path class="cls-1" d="M384.29,201.55c-15.51-17.27-31.23-32-48.83-15.08s-24.26,5.65-36.84,18.24-26.44,17.58-44.32,18-36.22-14.53-50.9-17-14.11-4.44-29.63-7.41-20.19-13.51-37.69-3.95S89.76,208.63,63,188.26s-39.55-19.78-63-3.08V238c9.48,2,13.94,2.19,24.54-1.77s28.36,2.26,41.9.57,33-11.4,65-3.54,54,15,74.8,9.45,24.81-.54,37.27-6.21,28.58-17.5,58.68-5.92,48.59-3.71,63.1,1a114.12,114.12,0,0,0,29.56,4.92V206.89S387.64,205.28,384.29,201.55Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M301.09,265.63c-0.17,1.23.79,2.61-.18,3.25s-6.39,1.81-6.71.32a8.21,8.21,0,0,0-1.06-2.58l1.46-2.33Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M339.61,265.63c-0.14,1.23,1.8,2,.85,2.61s-7.31,2.44-7.66,1-0.44-1.87-.44-1.87l1.41-2.33Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M309.28,127.58c-0.95.09-1.88-.45-2.83-0.36a0.58,0.58,0,0,0-.27.07,0.47,0.47,0,0,0-.16.22,4.6,4.6,0,0,0,.33,2.91c0.72,1.59,1.44,3.19,2.2,4.77a0.49,0.49,0,0,0,.2.25,0.17,0.17,0,0,0,.25-0.11" transform="translate(0 -60.95)"/><path class="cls-3" d="M316,129.36l0.11-5.81a14.67,14.67,0,0,0,4.12-7.94c0.79-4.92.14-5.32-.82-5.92s0-1.43-.93-2.71-4.85-2.78-9.67-1.09-8.57,3.25-3.91,4.79c-0.78,7.33-1.7,9.66-.78,12.66,1.14,3.71,3.84,3.44,3.84,3.44l-0.11,2.81-3.59,5.69,5.1,9.12,9-5.46Z" transform="translate(0 -60.95)"/><path class="cls-4" d="M320.26,115.61c0.06-.36.11-0.69,0.15-1l-0.16,0a3.49,3.49,0,0,0-1.74.47,5.28,5.28,0,0,0-1.5,1.21,2,2,0,0,1,.35,2.56c-0.44.83-1.19,1.47-1.65,2.3a3.93,3.93,0,0,0-.48,2.21c0,0.53.19,1.06,0.25,1.59a9.58,9.58,0,0,1-1.1,4.71l1.2,2.1a7.37,7.37,0,0,0,.91-0.55L316,129.36l0.11-5.81A14.67,14.67,0,0,0,320.26,115.61Z" transform="translate(0 -60.95)"/><path class="cls-4" d="M304.8,117.82a44.28,44.28,0,0,0,1-7.36l-0.85.23c-0.78,7.33-1.7,9.66-.78,12.66,1.14,3.71,3.84,3.44,3.84,3.44C304.28,126.18,304.28,120.84,304.8,117.82Z" transform="translate(0 -60.95)"/><path class="cls-5" d="M308.72,121.43a1,1,0,0,1,1.47,1.32,2,2,0,0,1-2.59,1.57c-1.23-.43-2.53-1.59-1.78-2.17,0.55-.43.9,0,1.56,0S308.05,121.69,308.72,121.43Z" transform="translate(0 -60.95)"/><path class="cls-6" d="M280.4,135.19c2.14-.26,6.68-2.42,9.58-2.75l-0.82,5-8,1.12Z" transform="translate(0 -60.95)"/><path class="cls-3" d="M283.15,136.3c1.19-2.54.79-3.57,0-6s-0.42-3.27.13-5.12-0.92-3.66-.58-4.24a0.44,0.44,0,0,1,.74-0.12,8.37,8.37,0,0,1,1.12,3s0.48-.51,0-2.07-0.76-2-.09-2.24c0.26-.11,1.75-0.69,2.06-0.26a5.75,5.75,0,0,1,.77,3.63c-0.16.9-.42,1.82,0.22,0.47s-0.17-3.83.31-3.95a1.07,1.07,0,0,1,1,.11,10.14,10.14,0,0,1,.28,3.65c-0.93,2.56-.64,3.29-0.64,3.29a1.27,1.27,0,0,0,.8-0.47c0.63-.73.5-1.75,1-1.75s0.86,0.27.76,0.65c-0.2.69-.26,0.88-0.6,2.39-0.29,1.32-.53,1.44-2,2.6a27.18,27.18,0,0,0,0,4.88" transform="translate(0 -60.95)"/><path class="cls-7" d="M285.5,119.2a0.64,0.64,0,0,0,0,.07,2,2,0,0,1,.9,1.32,5.11,5.11,0,0,1,0,1.63,9.89,9.89,0,0,1-1,3.85,5.56,5.56,0,0,0-1,2.21,0.27,0.27,0,0,0,.1.27,9.15,9.15,0,0,1,1.13-1.34,3.31,3.31,0,0,1,1.62-.6,2.28,2.28,0,0,0,1.27-.15s-0.29-.73.64-3.29a10.14,10.14,0,0,0-.28-3.65,1.07,1.07,0,0,0-1-.11c-0.48.12,0.33,2.6-.31,3.95s-0.38.43-.22-0.47a5.75,5.75,0,0,0-.77-3.63A1.14,1.14,0,0,0,285.5,119.2Z" transform="translate(0 -60.95)"/><path class="cls-8" d="M290.51,127.29c0.33-1.51.4-1.7,0.6-2.39a0.27,0.27,0,0,0-.32-0.44,2.06,2.06,0,0,0-.41,1.2,2.65,2.65,0,0,1-.26.7,2.26,2.26,0,0,1-.63.64c-0.71.52-1.55,0.86-2.25,1.4a4.65,4.65,0,0,0-.85.86,5.61,5.61,0,0,0-1,2.76,10.3,10.3,0,0,0,.16,3,4.42,4.42,0,0,0,.14.58l2.88-.82a27.17,27.17,0,0,1,0-4.88C290,128.74,290.22,128.61,290.51,127.29Z" transform="translate(0 -60.95)"/><path class="cls-9" d="M298.39,178s-5.6,63.67-5.36,73.35,0.12,14.72.12,14.72h8.11a73.51,73.51,0,0,0,4-20.52c0.53-8.72-.32-19.22-0.31-21.52a6.39,6.39,0,0,1,.53-2.51,124.81,124.81,0,0,0,6.58-27.72s3.07,23.06,6.52,35.27c3.51,12.39,14.47,37,14.47,37h6.86s-5.42-33.45-11.08-42.4a6.82,6.82,0,0,1-1.09-3.9c0.29-7.52-.78-33.71-2.6-40C323,172.3,298.39,178,298.39,178Z" transform="translate(0 -60.95)"/><path class="cls-10" d="M310.81,193.42l-3.17-.21c-2.55-.17-3,0.11-2.83,2.65a61.52,61.52,0,0,1,0,7.62,60.24,60.24,0,0,1-2.81,14.6,8.92,8.92,0,0,0-.49,2,8.75,8.75,0,0,0,.08,1.74q0.07,0.61.13,1.21a112.71,112.71,0,0,1-4,43.09h3.57a73.51,73.51,0,0,0,4-20.52c0.53-8.72-.32-19.22-0.31-21.52a6.4,6.4,0,0,1,.53-2.51c1.41-3.26,5.14-15.73,6.4-26.06C311.89,194.34,311.65,193.47,310.81,193.42Z" transform="translate(0 -60.95)"/><path class="cls-11" d="M328.84,223.66a6.82,6.82,0,0,1-1.09-3.9c0.29-7.52-.78-33.71-2.6-40C323,172.3,298.39,178,298.39,178s-0.07,2.25-.19,5.95c0.6-.25,2-0.82,2.47-1,1.74-.57.25-0.73,1.85,0.2a10.44,10.44,0,0,0,2.41,1.33,5.9,5.9,0,0,0,2.71-.16,17.22,17.22,0,0,1,5.62-.52,6.74,6.74,0,0,1,4.85,2.69c1.17,1.74,1.17,4,1.17,6.08,0,2.9.2,9.07,0.52,12,0.61,5.42,1.06,13.87,2.51,19.21,0.95,3.48,5.44,6.66,6.4,10.16,1.95,7.1,3.16,13.14,5.41,20.29,1.55,4.91.24,6.83,2.21,11.85h3.57S334.5,232.62,328.84,223.66Z" transform="translate(0 -60.95)"/><path class="cls-12" d="M305.11,182.26c0.56,2.41,1,4.83,1.39,7.2,0.06,0.29.12,0.59,0.18,0.85a1.71,1.71,0,0,0,0,.18l0,0.08v0h0l0-.07h0l0,0.05c0-.07,0,0,0.1.06a8.23,8.23,0,0,0,1.44.75c0.54,0.24,1.09.45,1.65,0.65l0.84,0.31,0.8,0.27,0.08,0a0.67,0.67,0,0,1-.31,1.3,33.15,33.15,0,0,0-3.66-.38c-0.62,0-1.25-.07-1.87-0.06-0.31,0-.62,0-0.93,0a3.09,3.09,0,0,0-.92.18,4.63,4.63,0,0,1,1.79-.72,16.63,16.63,0,0,1,1.9-.31c0.64-.07,1.28-0.12,1.92-0.13a14.47,14.47,0,0,1,2,.06L311.34,194c-0.39-.08-0.65-0.15-1-0.23s-0.61-.16-0.9-0.26c-0.59-.2-1.18-0.41-1.78-0.65a7.61,7.61,0,0,1-1.78-1,1.88,1.88,0,0,1-.51-0.61l0-.05h0l0-.08h0v0l0-.15c0-.1,0-0.18-0.06-0.26-0.06-.34-0.09-0.64-0.13-1a35.44,35.44,0,0,1-.2-3.7A26,26,0,0,1,305.11,182.26Z" transform="translate(0 -60.95)"/><path class="cls-12" d="M318.51,182.26s0.08,0.13.2,0.35a6.82,6.82,0,0,0,.51.82c0.1,0.16.25,0.3,0.37,0.47s0.29,0.3.46,0.44a5.55,5.55,0,0,0,.52.41,5.86,5.86,0,0,0,.59.36,7,7,0,0,0,.64.31c0.22,0.1.44,0.19,0.66,0.26,0.44,0.17.87,0.29,1.26,0.41s0.72,0.21,1,.27l0.38,0.13s-0.13.07-.37,0.17a4.62,4.62,0,0,1-1,.29,5.93,5.93,0,0,1-.71.06,5.1,5.1,0,0,1-.81,0,4.92,4.92,0,0,1-1.71-.55,4.44,4.44,0,0,1-.77-0.54,3.76,3.76,0,0,1-.62-0.68,3.83,3.83,0,0,1-.42-0.74,3.19,3.19,0,0,1-.21-0.72,2.9,2.9,0,0,1,0-1.09C318.47,182.4,318.51,182.26,318.51,182.26Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M309.36,137.24s-1.74-8.46-1.57-8.47c-2.15.12-2.71,0.82-4.45,1.18-2.14.44-5,.85-6.72,1.94-2.62,1.64-5,6.51-6.75,10.08-0.59-1.75.15-7.94,0.12-9.53,0,1.86-8.88,3.18-9.58,2.75,0.08,4.33-.16,6.11.58,10.44a42.64,42.64,0,0,0,1.65,7.14,15.8,15.8,0,0,0,2,3.63,5.48,5.48,0,0,0,1.81.95c3.11,1.16,3.9-.65,6.19-2.79,1.46-1.37,2.5-4.24,4-5.5-0.17,7.76.47,16.66,0.4,24.47,0,3-.12,4.91-0.15,7.9,1.86-.07,15.4.85,16.41,1a31.23,31.23,0,0,0,6.3.29c1.47-.06,6.91-0.23,6.91-0.23a3.36,3.36,0,0,1-.76-1.91c-0.11-1.63-.25-4.62-0.36-6.25a101.42,101.42,0,0,1,.85-19.18c0.34-2.8,1.28-5.32,1.58-8.12a49,49,0,0,0,.12-8.44c-0.12-1.88.82-4.83-1.86-6.85a17.38,17.38,0,0,0-9.53-3C316.39,129,309.36,137.24,309.36,137.24Z" transform="translate(0 -60.95)"/><path class="cls-13" d="M298,154.28a53,53,0,0,0,1.19-7.42c0.14-1.2.09-2.74-1-3.23a32.49,32.49,0,0,0-2.89,3.82c-2.24,3.29-5.08,6.63-7.24,10.25,1.9,0.08,2.77-1.42,4.61-3.15,1.46-1.37,2.5-4.24,4-5.5-0.17,7.76.47,16.66,0.4,24.47,0,3-.12,4.91-0.15,7.9H297c0-.2.55-0.92,0.56-1.11,0.23-4.87,1.23-7.81,1.45-12.62,0.11-2.4-.9-5.61-0.38-7.94C299.09,157.72,297.49,156.28,298,154.28Z" transform="translate(0 -60.95)"/><path class="cls-14" d="M326.53,182.44s-0.16-.94-0.24-2.11c-0.11-1.63-.77-4.42-0.88-6a101.42,101.42,0,0,1,.85-19.18,30.94,30.94,0,0,1,.64-3.36h0a21.17,21.17,0,0,1-2.11-4.46,78.93,78.93,0,0,0-2.29,19.27,38.29,38.29,0,0,1-2.86,16.12C321.09,182.61,326.53,182.44,326.53,182.44Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M317.57,129.06s0.42-2.61-.42-2.87-7.79,11-7.79,11Z" transform="translate(0 -60.95)"/><polyline class="cls-15" points="312.54 71.29 300.67 76.44 301.99 121.27 312.58 121.6 322.1 77.86 316.48 73.86"/><path class="cls-16" d="M319.44,109.7c-1-.6,0-1.43-0.93-2.71s-4.85-2.78-9.67-1.09-8.57,3.25-3.91,4.79c3.06,1,8-.16,8.53.3s-2,2.31-1,3.16,1.86,1,1.44,2.75,0.6,2.61,1.34,1.5,1.8-2.2,2.5-1.24-0.38,3-1.18,3.68a2.13,2.13,0,0,0-.44,2.71,14.67,14.67,0,0,0,4.12-7.94C321,110.69,320.39,110.29,319.44,109.7Z" transform="translate(0 -60.95)"/><path class="cls-17" d="M318.44,120.58a14.29,14.29,0,0,0,1.82-5c0.79-4.92.14-5.32-.82-5.92s0-1.43-.93-2.71-4.85-2.78-9.67-1.09l-1.38.5a2.21,2.21,0,0,0-.41.56,1.51,1.51,0,0,0,.55,2c2.38,1,4.75.67,6.65,1a0.74,0.74,0,0,0,.19.83c1.17,1.42,3.3,1.89,4.33,3.41a4.48,4.48,0,0,1,.56,3.2A23.59,23.59,0,0,1,318.44,120.58Z" transform="translate(0 -60.95)"/><path class="cls-18" d="M300,152l2.56,3.43a1.12,1.12,0,0,0,1.64.16h0a1.08,1.08,0,0,0,.14-1.45l-2.54-3.44c-0.39-.53-0.91-0.34-1.4.11h0C300,151.14,299.66,151.51,300,152Z" transform="translate(0 -60.95)"/><path class="cls-19" d="M302.47,155.27a1.7,1.7,0,0,0,.47-0.23l1-.7,0.37-.28-2.52-3.4a0.66,0.66,0,0,0-.8-0.28,0.35,0.35,0,0,0,0,.14l0.49,0.07a8.77,8.77,0,0,1,.87,1.54,1,1,0,0,1,.12.48,0.39,0.39,0,0,1-.29.36c-0.34.06-.62-0.47-0.93-0.32a3,3,0,0,1,.66,1,1.27,1.27,0,0,1-.24.61Z" transform="translate(0 -60.95)"/><path class="cls-19" d="M316.24,172.63l2.64,3.52a1.12,1.12,0,0,0,1.67.17h0a1.12,1.12,0,0,0,.12-1.49L318,171.29a1.12,1.12,0,0,0-1.67-.16l0,0A1.12,1.12,0,0,0,316.24,172.63Z" transform="translate(0 -60.95)"/><path class="cls-20" d="M301.59,156.77l11.5,14.74a1.51,1.51,0,0,0,2.2.21l2-1.85a1.49,1.49,0,0,0,.14-2.06l-11.58-14.2a1.51,1.51,0,0,0-2-.3l-2,1.34A1.46,1.46,0,0,0,301.59,156.77Z" transform="translate(0 -60.95)"/><path class="cls-18" d="M317.33,169.87a1.49,1.49,0,0,0,.14-2.06l-11.58-14.2a1.5,1.5,0,0,0-1.36-.52c-1.19,1,3.42,5.14,4.17,6,2.56,2.91,3.46,4.49,2.86,4.95s-4.13-2.91-3.78-1.35c0.24,1.09,2.13,4.36,4.19,7.41l1.12,1.43a1.51,1.51,0,0,0,2.2.21Z" transform="translate(0 -60.95)"/><path class="cls-20" d="M315.45,168.84c-0.32,0-.74-0.38-1,0a1.48,1.48,0,0,0,1.1,1.17,1.3,1.3,0,0,0,1.42-.66,1.23,1.23,0,0,0,.06-0.89,2.24,2.24,0,0,0-.25-0.5,11.19,11.19,0,0,0-2.08-2.49,2.06,2.06,0,0,0-.88-0.53,2.11,2.11,0,0,0,.71.94,5.53,5.53,0,0,1,1.57,2.34C316.25,168.65,315.82,168.8,315.45,168.84Z" transform="translate(0 -60.95)"/><path class="cls-6" d="M322.49,166.55c0.11,3.29,4.7,6.15,6.27,8.45l0.94-4.92-2.53-4.38-2.91.66Z" transform="translate(0 -60.95)"/><path class="cls-3" d="M323.1,166.7c-1.08.77-2.7,2.6-3.69,2.53s-2.65-1-3.52-.42-1.38.47-1.36,1.5-0.44,2.31-.06,3a12.8,12.8,0,0,0,2.84,3c0.77,0.46,1.68.49,1.94,0.07-0.49-.46-0.28-1.18.49-1a3.05,3.05,0,0,0,2.81-.33c0.92-.79.8-3,2.55-4s5.23-2.7,5.23-2.7l-3.62-3Z" transform="translate(0 -60.95)"/><path class="cls-21" d="M328.83,168.67a0.7,0.7,0,0,0-.31-0.23c-0.13,0-4.54-1.82-4.67-1.79-1.42.4,1.66,3.18,0.23,3.55a2.88,2.88,0,0,0-.93.33c-0.73.51-.67,1.71-1.4,2.23a1.74,1.74,0,0,1-.73.26,3.73,3.73,0,0,1-1.21,0c-0.85-.14-1.76-0.56-2.52-0.17-1.19.62-.83,2.17-0.35,3.23a3.26,3.26,0,0,0,.36.26c0.77,0.46,1.68.49,1.94,0.07-0.49-.46-0.28-1.18.49-1a3.05,3.05,0,0,0,2.81-.33c0.92-.79.8-3,2.55-4,1.07-.57,2.79-1.46,4-2.06A2.63,2.63,0,0,0,328.83,168.67Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M326.1,131.69c3.3,2.08,6.25,10.45,8.86,16.14s5,8.85,4.59,12.27-8.61,13-10.78,14.91c0,0-.94-6.13-6.27-8.45,0,0,8.09-4.25,9.05-7.27,0,0-6.67-10.37-8.06-15.38S326.1,131.69,326.1,131.69Z" transform="translate(0 -60.95)"/><path class="cls-22" d="M335,147.83c-2.36-5.16-5-12.51-7.93-15.39a1.74,1.74,0,0,0-1.33,1.09,4,4,0,0,0-.05,2.18c1.35,7.42,7.17,13.51,9.38,20.88,0.24,0.8.43,1.6,0.68,2.4a2.9,2.9,0,0,1,.19.94,2.59,2.59,0,0,1-.6,1.34,24.66,24.66,0,0,1-4.11,4.89,8.51,8.51,0,0,1-5.93,2.19v0a12.8,12.8,0,0,1,3.52,6.62c2.17-1.95,10.36-11.47,10.78-14.91S337.57,153.56,335,147.83Z" transform="translate(0 -60.95)"/><path class="cls-23" d="M292.09,139.46a19.7,19.7,0,0,0,1.8-4.73,50.67,50.67,0,0,0-4,7.24c-0.59-1.75.15-7.94,0.12-9.53,0,1.11-3.14,2-5.84,2.49,0,0,0,.06,0,0.09-0.12.87,0.58,2.07,0.81,2.89,0.43,1.52.75,3.08,1.13,4.62a23.65,23.65,0,0,1,1,7.91Q289.47,144.87,292.09,139.46Z" transform="translate(0 -60.95)"/><path class="cls-24" d="M301.52,137.46a0.45,0.45,0,0,0,.5.47,0.65,0.65,0,0,0,.53-0.51,0.49,0.49,0,0,0-.13-0.5,0.48,0.48,0,0,0-.57,0,1.35,1.35,0,0,0-.35.49" transform="translate(0 -60.95)"/><path class="cls-24" d="M302.84,145.78a0.52,0.52,0,0,0-.47.31,0.53,0.53,0,1,0,1,.19,0.57,0.57,0,0,0-.64-0.52" transform="translate(0 -60.95)"/><path class="cls-24" d="M303.86,166.18a0.69,0.69,0,0,0-.7.75,0.87,0.87,0,0,0,.8.73,0.32,0.32,0,0,0,.17,0,0.37,0.37,0,0,0,.13-0.15,1.16,1.16,0,0,0,.22-0.84,0.45,0.45,0,0,0-.69-0.29" transform="translate(0 -60.95)"/><path class="cls-24" d="M303.3,179.75a0.63,0.63,0,0,0-.73.51,0.61,0.61,0,0,0,.58.67,0.56,0.56,0,0,0,.51-0.69,1.08,1.08,0,0,0-.41-0.49" transform="translate(0 -60.95)"/><path class="cls-24" d="M311.88,180.12a0.48,0.48,0,0,0-.78.12,0.82,0.82,0,0,0,.2.88,0.48,0.48,0,0,0,.5.18,0.55,0.55,0,0,0,.22-0.21,1.14,1.14,0,0,0,.22-0.44,0.46,0.46,0,0,0-.15-0.45" transform="translate(0 -60.95)"/><path class="cls-24" d="M315.29,156.83a0.81,0.81,0,0,0-.15.82,0.84,0.84,0,0,0,.67.52,0.57,0.57,0,0,0,.27,0,0.58,0.58,0,0,0,.28-0.25,0.85,0.85,0,0,0,0-.89,0.77,0.77,0,0,0-.83-0.32,0.65,0.65,0,0,0-.45.72" transform="translate(0 -60.95)"/><path class="cls-24" d="M317.79,147.1a0.5,0.5,0,0,0-.73.27,0.68,0.68,0,0,0,.49.84,0.66,0.66,0,0,0,.78-0.57,0.69,0.69,0,0,0-.69-0.7" transform="translate(0 -60.95)"/><path class="cls-24" d="M319.16,137.67a0.51,0.51,0,0,0-.41.74,0.74,0.74,0,0,0,.92.26,0.58,0.58,0,0,0,.27-0.21,0.52,0.52,0,0,0-.13-0.65,0.7,0.7,0,0,0-.69-0.09" transform="translate(0 -60.95)"/><path class="cls-25" d="M307.55,119.46c-0.18,1.13-.65,1.25-1.19,1.16s-0.95-.35-0.76-1.49,0.89-2.7,1.43-2.61S307.74,118.32,307.55,119.46Z" transform="translate(0 -60.95)"/><path class="cls-26" d="M311.37,116.23a0.65,0.65,0,0,1-.34.88,0.71,0.71,0,0,1-.91-0.35,0.65,0.65,0,0,1,.34-0.88A0.71,0.71,0,0,1,311.37,116.23Z" transform="translate(0 -60.95)"/><path class="cls-26" d="M305.74,115.88a0.62,0.62,0,0,1-.33.83,0.67,0.67,0,0,1-.86-0.33,0.62,0.62,0,0,1,.33-0.83A0.67,0.67,0,0,1,305.74,115.88Z" transform="translate(0 -60.95)"/><path class="cls-26" d="M310.78,114.53a1,1,0,0,1,.3,0,1.64,1.64,0,0,1,.58.29,1.62,1.62,0,0,1,.4.51,1,1,0,0,1,.09.29,2.63,2.63,0,0,1-.25-0.15c-0.14-.09-0.31-0.23-0.48-0.35s-0.32-.28-0.44-0.4A2.84,2.84,0,0,1,310.78,114.53Z" transform="translate(0 -60.95)"/><path class="cls-26" d="M305.54,114.26l-0.22.1-0.2.08-0.22.08-0.43.12-0.23.05a0.6,0.6,0,0,1,.11-0.23,1,1,0,0,1,.44-0.31,1,1,0,0,1,.54,0A0.59,0.59,0,0,1,305.54,114.26Z" transform="translate(0 -60.95)"/><path class="cls-27" d="M312.17,126.81c1.19-1.31,1.33-2.6-.18-1.22a6,6,0,0,1-4,1.19l-0.11,2.81C309.36,131.11,311,128.12,312.17,126.81Z" transform="translate(0 -60.95)"/><polygon class="cls-28" points="307.99 65.84 307.99 65.84 307.99 65.84 307.99 65.84"/><path class="cls-20" d="M310.4,166.21a1.47,1.47,0,0,0,.83.56,0.21,0.21,0,0,0,.26-0.21,0.31,0.31,0,0,0-.09-0.14c-0.36-.39-0.75-0.73-1.12-1.11,0.23-.11.61,0.31,0.66-0.12a1.23,1.23,0,0,0-.31-0.64,2.4,2.4,0,0,0-1.14-.85C308.15,163.34,310.1,165.88,310.4,166.21Z" transform="translate(0 -60.95)"/><path class="cls-18" d="M309.81,161.46c-0.74-.9-1.34-1.92-2-2.85a7.2,7.2,0,0,0-2.59-2.31,18.62,18.62,0,0,1,3.71,4.66,0.37,0.37,0,0,1,.07.3,0.83,0.83,0,0,0-.38,0,0.37,0.37,0,0,0,.29.27c0.72,0.31,1.15,1.17,1.91,1.33,0,0-.32-0.57-0.37-0.63C310.21,162,310,161.73,309.81,161.46Z" transform="translate(0 -60.95)"/><path class="cls-18" d="M304.13,156.79a1.86,1.86,0,0,0-1.11-.54c-0.19.34,0.92,1.15,1.14,1.36s0.57,0.55.88,0.81c0.56,0.47,1.18.87,1.74,1.34a0.61,0.61,0,0,1,.3.66,2.91,2.91,0,0,1-.66.42,0.83,0.83,0,0,0,.16,1c0.21,0.44.31,0.92,0.55,1.36a3,3,0,0,1-.05-1.69c0.21-.4.85-0.45,0.81-1a2.27,2.27,0,0,0-.94-1.2l-1.33-1.21-0.75-.66A3.84,3.84,0,0,1,304.13,156.79Z" transform="translate(0 -60.95)"/><path class="cls-20" d="M311.54,168.43a2.21,2.21,0,0,1-.43-1,0.93,0.93,0,0,1,.77.15c0.23,0.15.42,0.34,0.63,0.51a0.42,0.42,0,0,0,.23.1,0.3,0.3,0,0,0,.26-0.37,1,1,0,0,0-.25-0.44,8.71,8.71,0,0,1-1.15-1.81,0.85,0.85,0,0,1,.63.28,11.61,11.61,0,0,1,1.45,1.51,2,2,0,0,1,.38.65,0.73,0.73,0,0,1-.13.71,0.89,0.89,0,0,1-.82.16,4.53,4.53,0,0,0-.85-0.17c0.15,1.09,1.42,1.62,1.66,2.69-0.5.11-.81-0.71-1-1C312.42,169.72,312,169.08,311.54,168.43Z" transform="translate(0 -60.95)"/><path class="cls-20" d="M312.69,163.9a0.27,0.27,0,0,1,0,.17,0.3,0.3,0,0,1-.31.14c-0.12,0-.28.08-0.25,0.2a0.24,0.24,0,0,0,.05.09l1.58,2a15,15,0,0,0,1.31,1.52,3.17,3.17,0,0,0-.77-1.52,15.79,15.79,0,0,1-1.35-2.19,0.13,0.13,0,0,0,.13,0,17.47,17.47,0,0,0-.9-1.9c-0.16-.28-0.74-1.58-1.09-1.53a5.5,5.5,0,0,0,.69,1.14c0.16,0.3.31,0.61,0.46,0.91A3,3,0,0,1,312.69,163.9Z" transform="translate(0 -60.95)"/><path class="cls-18" d="M304.69,156.26a0.26,0.26,0,0,1-.38-0.08,1.93,1.93,0,0,0-.25-0.37,0.73,0.73,0,0,0-.47-0.11,2,2,0,0,0-.76.09,0.45,0.45,0,0,1-.39,0,0.34,0.34,0,0,1-.12-0.27,2.66,2.66,0,0,1,0-.49,0.09,0.09,0,0,1,0-.09,0.1,0.1,0,0,1,.07,0,0.84,0.84,0,0,0,.89,0c0.33-.22,0-0.54.17-0.77s0.28,0,.36.13a10,10,0,0,1,.36.93Q304.44,155.78,304.69,156.26Z" transform="translate(0 -60.95)"/><path class="cls-18" d="M305.12,160.35a4.78,4.78,0,0,1,.65.51,0.32,0.32,0,0,0,0-.28,0.85,0.85,0,0,0-.18-0.23c-0.27-.28-1.52-1.69-1.79-2a9.5,9.5,0,0,1,1.94,1.85,1.4,1.4,0,0,0,.43.44c-1-1.55-2-2.56-3.09-3.91a2.75,2.75,0,0,0-.85-0.49c-0.06,0-.13-0.07-0.14,0a0.6,0.6,0,0,0,0,.2,4.12,4.12,0,0,0,.63,1.09A25.22,25.22,0,0,0,305.12,160.35Z" transform="translate(0 -60.95)"/><path class="cls-2" d="M310.75,105.38s8.62,2.45,9.45,10.25c0,0,0,3.35,4.15,2.12s4.64-4.31,4.64-4.31a8.75,8.75,0,0,0,2.56-8.92c-1.43-5.74-4.71-5.14-4.71-5.14s-2.4-5.43-9-2.84a6.8,6.8,0,0,0-7.36,3.22c-2.75,4.3.68,5,.68,5Z" transform="translate(0 -60.95)"/><path class="cls-29" d="M317.82,96.53a6.8,6.8,0,0,0-7.36,3.22c-2.75,4.3.68,5,.68,5L312,103.5a3,3,0,0,1,.3-4.71A9.18,9.18,0,0,1,317.82,96.53Z" transform="translate(0 -60.95)"/><path class="cls-30" d="M331.55,104.51c-1-4.06-2.94-4.95-4-5.12a4.79,4.79,0,0,1,2.4,2.55,9.65,9.65,0,0,1,.36,4.44,5.73,5.73,0,0,1-2.3,3.37,3.82,3.82,0,0,1-4.13.12c-1.1-.83-1.27-1.65-1.39-3.43a7,7,0,0,0-1.51,3.25,10.39,10.39,0,0,0,.47,5.34l-1.25.6a2.86,2.86,0,0,0,.36,1.3c0.45,0.78,1.48,1.5,3.79.82,4.18-1.23,4.64-4.31,4.64-4.31A8.75,8.75,0,0,0,331.55,104.51Z" transform="translate(0 -60.95)"/><path class="cls-31" d="M323.68,98.83a5.83,5.83,0,0,0-1.06,1.16c-0.57.81-.05,2.26-0.13,3.25a4.59,4.59,0,0,1,4.26-4.05c-0.49-.91-3-4.94-8.87-2.68l-0.07.08a8.24,8.24,0,0,1,4.67,0,5.82,5.82,0,0,1,1.55.63,1.18,1.18,0,0,1,.82.7C324.85,98.27,324,98.61,323.68,98.83Z" transform="translate(0 -60.95)"/><path class="cls-32" d="M340.65,269c0.15-1.25.65-2-.25-1.64a7.33,7.33,0,0,1-3.88.15c-1.78-.29-2.71-1.88-4.49-2.4s-2.05,1-1.28,1.67a47.52,47.52,0,0,1-5,2.1c-2.21.72-3.39,2.2-3.39,2.58a0.56,0.56,0,0,0,.48.47H341C341.5,271.94,340.54,269.92,340.65,269Z" transform="translate(0 -60.95)"/><path class="cls-32" d="M301.48,269c0.18-1.25.69-2-.21-1.64a7.35,7.35,0,0,1-3.88.15c-1.77-.29-2.67-1.88-4.44-2.4s-2.07,1-1.32,1.67a48.66,48.66,0,0,1-5.06,2.1c-2.22.72-3.44,2.2-3.44,2.58a0.55,0.55,0,0,0,.47.47h18.19C302.27,271.94,301.35,269.92,301.48,269Z" transform="translate(0 -60.95)"/><path class="cls-33" d="M323.83,131.67a3,3,0,0,0,1.29-.6,17.66,17.66,0,0,0-7.46-2.24c0.09-.68.26-2.39-0.41-2.59-0.43-.13-2.54,2.82-4.49,5.71a2.4,2.4,0,0,0,.47-0.29c0.92-.71,1.68-1.6,3-1.46a7,7,0,0,1,2.25.92A7.91,7.91,0,0,0,323.83,131.67Z" transform="translate(0 -60.95)"/><path class="cls-34" d="M235.84,104.35a48.52,48.52,0,0,0-10.64-6.83c-1.49-.69-3.65-1.17-3.77-0.52a4.35,4.35,0,0,0,1.22,1.65,10.91,10.91,0,0,0,3.23,2.38c3.17,1.71,5.74,4.36,9,5.88l3.59,1.67a8.43,8.43,0,0,0,2.6.88h0.13a2.32,2.32,0,0,0-1-1.86C239,106.52,237.08,105.34,235.84,104.35Z" transform="translate(0 -60.95)"/><path class="cls-35" d="M228.19,125.86c1-1.6,1.7-2.13,1.7-.63a11.2,11.2,0,0,0,1.21,3.84l-1.11,2" transform="translate(0 -60.95)"/><path class="cls-36" d="M230.41,129.81s-1.85-4.93-1-6.9c0,0,4.55-.56,5.13-3s-0.5-11.75-.29-14.58-0.69-6.11-6.25-6S218,101,218.16,108s-0.93,10.89.35,11.23l0,6.72,4.3,7.13,7.69,3.67,1.9-5.29Z" transform="translate(0 -60.95)"/><path class="cls-37" d="M234.23,106.77c0-.57,0-1.06,0-1.44,0.22-2.83-.69-6.11-6.25-6a14.85,14.85,0,0,0-5.74,1,3.82,3.82,0,0,0,.18,2.88l2.4,2a10.31,10.31,0,0,1,2.59-2.27,3.49,3.49,0,0,1,3.31-.15c1.48,0.84,1.84,2.94,3.28,3.84Z" transform="translate(0 -60.95)"/><path class="cls-38" d="M229.41,122.91a12.45,12.45,0,0,1-6.14-1.25s-0.77,4.48,1.85,7.11,5,7.29,7.24,2.68l-1.95-1.64S228.56,124.88,229.41,122.91Z" transform="translate(0 -60.95)"/><path class="cls-39" d="M218.36,119.35c2.1-.69,3.51-3.33,2.85-4.55s-1.84-1.13-1.72-2.92,1.39-2.54,1.88-1.13,2.66,2.82,2.56.94-0.76-3.2.7-3.39-0.29-1.41,1.34-3.2-0.7-5.58,3.92-5.68c-6.72-1.48-10.81.91-12,5.53s-0.61,12.3-.5,13.28A1.21,1.21,0,0,0,218.36,119.35Z" transform="translate(0 -60.95)"/><path class="cls-40" d="M229.89,99.43c-4.23-.93-7.43-0.32-9.5,1.41,0.88,0.76,3.08,0,4.1.12,0.65,0.08,1.27.32,1.91,0.42,0.15,0,.3,0,0.45,0C227.09,100.34,227.73,99.48,229.89,99.43Z" transform="translate(0 -60.95)"/><path class="cls-41" d="M240.7,104.22a3.43,3.43,0,0,1,3,3.2c0.16,1.71-1.48,2.77-2.7.92S238.06,103.66,240.7,104.22Z" transform="translate(0 -60.95)"/><path class="cls-42" d="M241.57,102.88a4.87,4.87,0,0,0-.88-1.26,16.76,16.76,0,0,1-2.23-2.36,11.1,11.1,0,0,0-2-2.59,39.09,39.09,0,0,0-5.51-4.7,7.44,7.44,0,0,0-2.3-1.1c-1.71-.41-4.17,1.2-5.33,2.34A5,5,0,0,0,221.42,97c0.12-.64,2.12,0,3.61.72a48.73,48.73,0,0,1,10.64,6.83,30.72,30.72,0,0,1,4.37,3.25c0.54,0.49,1.28,1,1.15,1.66h-0.13a0.75,0.75,0,0,0,.4,0,0.81,0.81,0,0,0,.19-1,12.08,12.08,0,0,0-1.77-3.24c0.41-.34.92-0.09,1.35-0.37A1.55,1.55,0,0,0,241.57,102.88Z" transform="translate(0 -60.95)"/><path class="cls-36" d="M238.73,109.34l1.33,0.26a1.68,1.68,0,0,1,1.43,1.18c0.53,1,.65,1.9,1.63,2.56s2.68,0.46,3.73.19a12.75,12.75,0,0,1,1.42,4.09,19.44,19.44,0,0,1,5-.92c-3.63-6.39-6.95-10.1-7.94-10.36a6.4,6.4,0,0,0-3,.17,4.06,4.06,0,0,0-1.61,1.55c-0.62-.26-4.14-0.68-2.74,1A1.16,1.16,0,0,0,238.73,109.34Z" transform="translate(0 -60.95)"/><path class="cls-43" d="M262.5,139c-0.7-6.32-3.57-10.9-6.28-16.65A77.68,77.68,0,0,0,251,113a10.47,10.47,0,0,0-3.56,1.82,30,30,0,0,1,1.5,7.76c0.2,3,0,1.95.24,4.92,0.42,4.39,1.56,7.57,1.6,9.05-0.06-.13-16.43-8.21-19.7-8.63l0.21,2.54c-0.35,3.31-.13,6.65,1.81,9.36s1.76,4.61,5,5.36c0.94,0.61,4.14,1.27,4.89,1.56a27.05,27.05,0,0,0,7.37,1.66c3.39,0.27,8.38.92,10.5-1.73C262.56,144.53,262.79,141.64,262.5,139Z" transform="translate(0 -60.95)"/><path class="cls-44" d="M262.5,139c-0.7-6.32-3.57-10.9-6.28-16.65a80.51,80.51,0,0,0-4-7.5c3.42,8.87,6.63,18,6.59,27.46a2.41,2.41,0,0,1-.39,1.58c-1,1.13-6.95-1.06-8.27-1.45a53.25,53.25,0,0,1-8.44-3.28c-0.88-.43-1.75-0.89-2.59-1.4a24.54,24.54,0,0,1-3.85-2.88l-1.46,4.95q0.42,1.33.91,2.65a4.54,4.54,0,0,0,3.41,2.65c0.94,0.61,4.14,1.27,4.89,1.56a27.05,27.05,0,0,0,7.37,1.66c3.39,0.27,8.38.92,10.5-1.73C262.56,144.53,262.79,141.64,262.5,139Z" transform="translate(0 -60.95)"/><path class="cls-45" d="M237.81,136.83c5.7,14.48,7.22,23.55,6,39,0.26-.38-0.32-0.77-0.77-0.87a56.31,56.31,0,0,0-10.9-1.32c-2.5-.06-5,0.05-7.51-0.19-3.59-.35-7.94,0-11.39-1a21.49,21.49,0,0,1,.57-6.1c1.71-5.05,2.26-4.27,1.45-9.54a69,69,0,0,0-4.55-15.3c-0.65-1.62-2.16-3.93-3.82-4.48a35.35,35.35,0,0,1,5.88-5.57,34.36,34.36,0,0,1,5.33-4c0.71-.37-0.61-2.7.16-2.94,2,2.94,9.72,9.08,11.37,9,1.67-2.47.3-6.75,0.3-6.75A32.08,32.08,0,0,1,237.81,136.83Z" transform="translate(0 -60.95)"/><path class="cls-46" d="M238.26,138a1.38,1.38,0,0,0-.39-1c-0.36-.31-0.88-0.45-1.24-0.82a3.54,3.54,0,0,0-3-1.3,4,4,0,0,0-1.61.81c-2.07,1.5-4.05,3.4-4.7,5.88s0.11,4.92.47,7.37a18.4,18.4,0,0,1-.38,7.7,12.36,12.36,0,0,1-4.17,6.39c-1.66,1.28-3.67,2.05-5.26,3.42s-2.68,3.71-1.7,5.55a3.67,3.67,0,0,0,.92,1.1c2.47,0.19,5.06.11,7.35,0.33,2.49,0.24,5,.13,7.51.19a56.3,56.3,0,0,1,9,.94,13.64,13.64,0,0,0,2.61-1.17l0.28-.18C244.82,159.72,243.27,151,238.26,138Z" transform="translate(0 -60.95)"/><path class="cls-47" d="M230.38,136.15l2.14,5.42,2.14,5.57a13.09,13.09,0,0,1,.54,1.6,3.17,3.17,0,0,1-.1,1.78,9.32,9.32,0,0,0-.64,3.33,8.93,8.93,0,0,0,.61,3.32,8.74,8.74,0,0,0,.76,1.49,3.87,3.87,0,0,1,.66,1.6c0.09,1.23-.64,2.14-0.89,3.06a6.79,6.79,0,0,0-.06,2.74,14.4,14.4,0,0,1,.19,2.39,9.29,9.29,0,0,1-.23,1.83,8.07,8.07,0,0,1-.49,1.53,8.06,8.06,0,0,0,.42-1.54,9.18,9.18,0,0,0,.14-1.82,17.45,17.45,0,0,0-.28-2.35,7.05,7.05,0,0,1,0-2.86c0.25-1,.92-1.92.82-2.94a3.54,3.54,0,0,0-.62-1.43,9.15,9.15,0,0,1-.8-1.54,9.32,9.32,0,0,1-.67-3.47,9.74,9.74,0,0,1,.69-3.45c0.43-1.05,0-2.1-.41-3.13l-2-5.62Z" transform="translate(0 -60.95)"/><path class="cls-48" d="M219.08,128.68c1.73,2.88,3.34,3.9,4.93,6.86a0.51,0.51,0,0,0,.21.25,0.53,0.53,0,0,0,.57-0.37c0.57-1,1.18-.13,1.74-1.14" transform="translate(0 -60.95)"/><path class="cls-49" d="M212.83,172.18c0.3,1.1-3.18,11.81-3.38,20.61s2,22.26-.6,32.69A230.32,230.32,0,0,0,203,263.41h9.15a101.64,101.64,0,0,1,6.3-26.84c5.58-14.39,8.55-39,8.55-39-0.47,5.28,1.8,22-.6,35.08a192.08,192.08,0,0,0-3,30.74h7.92c3.21-3.82,13.31-76.56,12.71-89.85Z" transform="translate(0 -60.95)"/><path class="cls-50" d="M235.89,242.8a189.17,189.17,0,0,1-1.3-24.63c0.34-10.19,4.55-19.89,5.48-30,0.22-2.39-.28-5.52-2.63-6-1.63-.32-3.18,1-3.86,2.51a24.51,24.51,0,0,0-1.08,4.84,13.62,13.62,0,0,1-5.05,7.9L227,202.86c0.31,7.51,1.23,19.76-.62,29.81a192.08,192.08,0,0,0-3,30.74h7.92C232.33,262.19,234,253.76,235.89,242.8Z" transform="translate(0 -60.95)"/><path class="cls-51" d="M222.72,172.41a0.42,0.42,0,0,0-.56.38,0.89,0.89,0,0,0,.36.68,3.83,3.83,0,0,0,1.89.74,3.26,3.26,0,0,0,1.26,0,1.24,1.24,0,0,0,.94-0.76,0.85,0.85,0,0,0-.16-0.82,0.72,0.72,0,0,0-.79-0.19" transform="translate(0 -60.95)"/><path class="cls-52" d="M225.85,173.07c0.52-4.71,0-11-1.12-20-1.87-15.53-6-22.42-7.76-25.35-0.52.34-1.1,1-1.62,1.39,4.4,7.41,6.18,15.7,6.83,24.41s1.26,10.54.59,19.29C224.27,172.87,224.35,173,225.85,173.07Z" transform="translate(0 -60.95)"/><path class="cls-51" d="M240.62,173.22a1,1,0,0,0,.65,1.09,5.34,5.34,0,0,0,1.38.21,1.68,1.68,0,0,0,.81,0,0.72,0.72,0,0,0,.2-1.16,1.33,1.33,0,0,0-.75-0.24,17.64,17.64,0,0,0-2.24-.07" transform="translate(0 -60.95)"/><path class="cls-52" d="M243.48,173.76c0.1-4.9-1.49-11.78-2.93-21.07-2.12-13.67-5.1-20.91-6.93-24.66l-2.07-.29c4,7.71,5.93,16.34,7,25.42s3,11.55,2.44,20.52C242.19,173.7,242.29,173.73,243.48,173.76Z" transform="translate(0 -60.95)"/><path class="cls-41" d="M226.64,138.5a1.32,1.32,0,0,1,1-1.07,1.19,1.19,0,0,1,.78.51,7.37,7.37,0,0,1,1.61,3.36,1,1,0,0,1,0,.51,1,1,0,0,1-.31.38c-0.82.71-5.09,3.39-4.79,1.77A39.85,39.85,0,0,1,226.64,138.5Z" transform="translate(0 -60.95)"/><rect class="cls-53" x="226.3" y="131.66" width="6.69" height="12.89" rx="1.14" ry="1.14" transform="translate(-34.4 31.46) rotate(-21.2)"/><path class="cls-54" d="M227.86,133.08q0.57-.41,1.17-0.77a1.79,1.79,0,0,1,1.53-.37,4.91,4.91,0,0,1,.44.38l-0.24-.61a0.89,0.89,0,0,0-1.15-.51L225,133a0.89,0.89,0,0,0-.51,1.15l4,10.35a2.82,2.82,0,0,0,1.06-.64,2.3,2.3,0,0,0,.68-1.18,0.41,0.41,0,0,0,0-.31,0.51,0.51,0,0,0-.23-0.15,2.81,2.81,0,0,1-1.42-1.69,5.76,5.76,0,0,1-.21-2.24,1.88,1.88,0,0,0,0-.58,2.1,2.1,0,0,0-.63-0.87,3.44,3.44,0,0,1-.86-1.4,2,2,0,0,1,.19-1.6A3,3,0,0,1,227.86,133.08Z" transform="translate(0 -60.95)"/><path class="cls-36" d="M233,138.45a12.52,12.52,0,0,0-6.11,3.12,67.21,67.21,0,0,0-5.63,7.9,6.35,6.35,0,0,1,.8.85,42.81,42.81,0,0,0,3.36,3.93c2-7,1.06-6.55,5.69-7.08,2.35-.27,4.5.54,4.48-5.25C235.58,140,235.23,137.92,233,138.45Z" transform="translate(0 -60.95)"/><path class="cls-55" d="M235.59,141.92c0-1.7-.31-3.59-2-3.53,0,0,0,.09,0,0.13a2.13,2.13,0,0,1-1,1.6,9.24,9.24,0,0,1-1.75.84,13.3,13.3,0,0,0-5.14,3.92c-0.68.85-1.17,1.81-1.76,2.72a3.14,3.14,0,0,0-.05,3,13.82,13.82,0,0,0,1.42,2.56,4.42,4.42,0,0,0,.32.44c1.77-6.26,1-5.91,5.5-6.43C233.45,146.9,235.6,147.71,235.59,141.92Z" transform="translate(0 -60.95)"/><path class="cls-41" d="M230.36,113.65c0,1.54.63,1.79,1.37,1.77s1.32-.29,1.29-1.83-0.68-3.75-1.41-3.73S230.32,112.11,230.36,113.65Z" transform="translate(0 -60.95)"/><path class="cls-56" d="M227.6,108.91a0.66,0.66,0,0,0,.22.93,0.72,0.72,0,0,0,1-.22,0.66,0.66,0,0,0-.22-0.93A0.72,0.72,0,0,0,227.6,108.91Z" transform="translate(0 -60.95)"/><path class="cls-56" d="M233.31,109.35a0.63,0.63,0,0,0,.21.88,0.68,0.68,0,0,0,.92-0.21,0.63,0.63,0,0,0-.21-0.88A0.68,0.68,0,0,0,233.31,109.35Z" transform="translate(0 -60.95)"/><path class="cls-56" d="M228.43,107.29a2.88,2.88,0,0,1-.23.19c-0.07,0-.15.12-0.23,0.17l-0.27.17c-0.19.1-.37,0.22-0.53,0.29a2.67,2.67,0,0,1-.28.12,1,1,0,0,1,.13-0.28,1.65,1.65,0,0,1,.47-0.46,1.66,1.66,0,0,1,.63-0.21A1,1,0,0,1,228.43,107.29Z" transform="translate(0 -60.95)"/><path class="cls-56" d="M233.74,107.75a0.6,0.6,0,0,1,.24-0.09,1,1,0,0,1,.54.08,1,1,0,0,1,.4.38,0.61,0.61,0,0,1,.08.25l-0.23-.09-0.42-.18-0.21-.11c-0.07,0-.13-0.08-0.19-0.1Z" transform="translate(0 -60.95)"/><path class="cls-56" d="M228.43,116.19l0.21,0.18,0.52,0.48a4,4,0,0,0,1.63,1,1.76,1.76,0,0,0,.92,0,1.81,1.81,0,0,0,.4-0.17,2.62,2.62,0,0,0,.34-0.25,3.3,3.3,0,0,0,.46-0.5l0.16-.22a2.05,2.05,0,0,1-.31,1,1.85,1.85,0,0,1-.33.41,1.74,1.74,0,0,1-.51.34,2,2,0,0,1-1.33.07,2.68,2.68,0,0,1-1.11-.63,3.53,3.53,0,0,1-.65-0.83A5.26,5.26,0,0,1,228.43,116.19Z" transform="translate(0 -60.95)"/><path class="cls-57" d="M238,109a1.16,1.16,0,0,0,.69.31l1.33,0.26a1.68,1.68,0,0,1,1.43,1.18c0.44,0.8.69,2.15,1.69,2.46a1.83,1.83,0,0,0,1.17-.08,1.47,1.47,0,0,0,1-1.06,1.67,1.67,0,0,0-.11-0.77,3.76,3.76,0,0,1-.42-2.39c0-.22.06-0.53-0.16-0.57a0.43,0.43,0,0,0-.37.23,7.84,7.84,0,0,1-1.27,1.29,1.42,1.42,0,0,1-.67.35c-0.67.09-2.21-1.54-1.6-2.17C240,107.76,236.75,107.5,238,109Z" transform="translate(0 -60.95)"/><path class="cls-45" d="M224.44,157.44c1.3-4,1.8-6.32,2.24-7.73a14.18,14.18,0,0,0-2.93-4c-2.75,4-6.05,9.36-6.05,9.36a96.07,96.07,0,0,0-2.8-10.78,11.21,11.21,0,0,0-8-7.31c-3.45,4.44-4.1,12.53-1.23,24.67s6.58,14.38,11.1,9.53S222.31,164,224.44,157.44Z" transform="translate(0 -60.95)"/><path class="cls-58" d="M212.58,163.63c-0.81-.29-0.9-1.37-0.85-2.23,0.4-7.42.21-15.23-3.39-21.74-0.26-.48-0.48-1.19,0-1.46a1,1,0,0,1,.73,0,8.11,8.11,0,0,1,4.35,3.72,24.11,24.11,0,0,1,2.15,5.43c0.7,2.3,2.62,5.8,1.74,8.14C217,156.22,212.73,163.68,212.58,163.63Z" transform="translate(0 -60.95)"/><path class="cls-59" d="M216.72,171.19c4.53-4.87,5.58-7.22,7.71-13.75,1.3-4,1.8-6.32,2.24-7.73a14.69,14.69,0,0,0-1.31-2.15c-1.39,3.08-2.43,6.31-4,9.31-1.67,3.23-3.93,6.15-5.24,9.54-0.45,1.16-.86,2.47-1.91,3.13-2.81,1.4-5.26-1.16-6.9-3.14l-0.62-.76C209.41,174.23,212.75,175.45,216.72,171.19Z" transform="translate(0 -60.95)"/><path class="cls-51" d="M219.83,141.95c0.12-.06.22,0.1,0.25,0.23l0.39,1.51a6,6,0,0,1,2.8-1.5L223,140.81a0.26,0.26,0,0,0-.06-0.14,0.27,0.27,0,0,0-.27,0l-2.63,1" transform="translate(0 -60.95)"/><path class="cls-51" d="M235.8,140.06l0.3,1a7.07,7.07,0,0,1,2.13.33l0.11-1.47h-2.45" transform="translate(0 -60.95)"/><path class="cls-60" d="M227,197.58s0-.12,0-0.33a2,2,0,0,1,.12-0.38,2.24,2.24,0,0,1,.25-0.47,4,4,0,0,1,.91-0.93,7,7,0,0,1,1.25-.75,12.33,12.33,0,0,1,3.75-1s-0.42.26-1.07,0.59-1.53.69-2.37,1.09a9.2,9.2,0,0,0-2.16,1.29c-0.11.12-.25,0.22-0.33,0.33a1.79,1.79,0,0,0-.22.29C227.06,197.48,227,197.58,227,197.58Z" transform="translate(0 -60.95)"/><path class="cls-60" d="M235.28,173.94l0.08,0.9c0,0.28,0,.63,0,1s0,0.85,0,1.34c-0.07,1-.18,2.13-0.37,3.34s-0.44,2.5-.71,3.78-0.6,2.55-.92,3.73-0.66,2.28-.93,3.21-0.55,1.71-.72,2.26l-0.28.85s0.19-1.3.6-3.21l0.7-3.27,0.83-3.73c0.29-1.27.55-2.54,0.8-3.73s0.46-2.31.6-3.27c0.06-.48.15-0.92,0.18-1.31s0.09-.73.1-1Z" transform="translate(0 -60.95)"/><path class="cls-61" d="M214.45,175l-0.32.94c-0.19.62-.46,1.53-0.71,2.71a60.4,60.4,0,0,0-1.08,9.91c-0.08,2.06-.06,4.3,0,6.67s0.15,4.86.3,7.44,0.37,5.24.49,8-0.09,5.49-.29,8.27-0.54,5.51-.93,8.2-0.83,5.34-1.29,7.89c-0.94,5.1-1.94,9.83-2.84,13.87l-2.18,9.77c-0.26,1.18-.45,2.11-0.57,2.75l-0.19,1,0.17-1c0.11-.64.27-1.57,0.5-2.76l1.95-9.82c0.82-4.06,1.78-8.79,2.64-13.89,0.43-2.55.84-5.19,1.2-7.88s0.66-5.43.89-8.17a80.22,80.22,0,0,0,.25-8.19c-0.16-2.7-.36-5.38-0.48-8a125.58,125.58,0,0,1-.07-14.17,51.17,51.17,0,0,1,1.41-9.92c0.3-1.17.61-2.08,0.83-2.68Z" transform="translate(0 -60.95)"/><path class="cls-61" d="M230.33,197.06l-0.07.74c-0.05.48-.12,1.19-0.17,2.09s-0.09,2-.08,3.25,0,2.67.1,4.21c0.12,3.09.46,6.68,0.59,10.56,0.07,1.94.09,3.95,0,6s-0.32,4.09-.6,6.16c-0.63,4.09-1.52,8.13-2.3,11.92-0.38,1.89-.78,3.72-1.09,5.46s-0.6,3.39-.78,4.92c-0.11.76-.18,1.5-0.25,2.2s-0.15,1.36-.17,2c-0.1,1.25-.1,2.34-0.1,3.25s0.07,1.61.08,2.09l0,0.74-0.07-.74c0-.48-0.15-1.19-0.17-2.09s-0.08-2,0-3.26c0-.63,0-1.3.09-2s0.1-1.45.19-2.22c0.15-1.54.38-3.21,0.67-5s0.61-3.6,1-5.5c0.75-3.8,1.6-7.83,2.2-11.9,0.28-2,.55-4.09.64-6.09s0.1-4,0-5.93c-0.12-3.86-.31-7.46-0.37-10.56,0-1.55,0-3,0-4.23s0.13-2.35.23-3.25,0.18-1.6.26-2.08Z" transform="translate(0 -60.95)"/><path class="cls-62" d="M233.17,175a0.22,0.22,0,0,1,.13,0,0.13,0.13,0,0,1,.07.09,2.8,2.8,0,0,1,0,2.09,0.68,0.68,0,0,1-.69.51,0.6,0.6,0,0,1-.32-0.2,1.22,1.22,0,0,1-.18-1.41A1.79,1.79,0,0,1,233.17,175Z" transform="translate(0 -60.95)"/><path class="cls-61" d="M219.8,176a2.84,2.84,0,0,1-.15,1.18,3.44,3.44,0,0,1-.6,1.1,3.67,3.67,0,0,1-.5.51,4.9,4.9,0,0,1-.61.42,5.92,5.92,0,0,1-2.52.68,8.4,8.4,0,0,1-1.17,0l0.3-.12,0.79-.27a12.54,12.54,0,0,0,2.24-.9,4.23,4.23,0,0,0,.52-0.33,5.11,5.11,0,0,0,.47-0.39,5.06,5.06,0,0,0,.7-0.85,5,5,0,0,0,.4-0.71Z" transform="translate(0 -60.95)"/><path class="cls-63" d="M228,133.77a1.15,1.15,0,0,0,.42,2.24,0.06,0.06,0,0,0,.06-0.08l-0.07-.18a0.29,0.29,0,0,1-.42,0,0.31,0.31,0,0,0-.18-0.12c-0.12,0,0-.07,0-0.07a0.24,0.24,0,0,1,.21.05,0.25,0.25,0,0,0,.35,0,0.25,0.25,0,0,1,0-.17,0.51,0.51,0,0,1-.69-0.36,0.45,0.45,0,0,1,0-.33,0.41,0.41,0,0,1-.09-0.29,0.43,0.43,0,0,1,.34,0,1.09,1.09,0,0,1,.54-0.2,0.43,0.43,0,0,1,.26-0.22,0.41,0.41,0,0,1,.11.28,0.45,0.45,0,0,1,.22.25,0.51,0.51,0,0,1-.3.71,0.28,0.28,0,0,1,.15.17l0.11,0.3a0.06,0.06,0,0,0,.09,0A1.15,1.15,0,0,0,228,133.77Z" transform="translate(0 -60.95)"/><path class="cls-64" d="M223.4,263.41l-0.61,7.47a1,1,0,0,0,1,1.06h12.65a0.58,0.58,0,0,0,.48-0.91c-0.81-1.2-2.48-3.13-4.68-3l-0.91-4.63H223.4Z" transform="translate(0 -60.95)"/><path class="cls-64" d="M202.95,263.41l-0.61,7.47a1,1,0,0,0,1,1.06h13.93a0.58,0.58,0,0,0,.48-0.91c-0.81-1.2-2.48-3.13-4.68-3l-0.91-4.63h-9.2Z" transform="translate(0 -60.95)"/><path class="cls-65" d="M233.81,148.57a0.61,0.61,0,0,0-.63-0.51,1.29,1.29,0,0,0,.83,1.25,0.89,0.89,0,0,0-.15-0.81" transform="translate(0 -60.95)"/><path class="cls-65" d="M234.92,160.15a1.62,1.62,0,0,0-.66-0.62,1,1,0,0,0,1.11,1.23,1.15,1.15,0,0,0-.79-1.08" transform="translate(0 -60.95)"/><path class="cls-65" d="M233,154.33a1.1,1.1,0,0,0,0,1.07,0.21,0.21,0,0,0,.1.1,0.22,0.22,0,0,0,.23-0.19,1.49,1.49,0,0,0-.13-1.23l-0.16.27" transform="translate(0 -60.95)"/><path class="cls-65" d="M234.26,167.22a1.27,1.27,0,0,0,.52,1.59,1.49,1.49,0,0,0-.36-1.59" transform="translate(0 -60.95)"/><path class="cls-66" d="M232.11,96.17l-1.66-.81a2.46,2.46,0,0,0-1.31-.36,0.85,0.85,0,0,0-.8.92,1.24,1.24,0,0,0,.53.63c2.09,1.58,4.18,3.16,6.36,4.61a18,18,0,0,1,2.07,1.51c0.9,0.8,1.63,2.14,2.72,2.7l-0.14-.21c0.41-.34.92-0.09,1.35-0.37a1.55,1.55,0,0,0,.34-1.93,4.87,4.87,0,0,0-.88-1.26,16.75,16.75,0,0,1-2.23-2.36,11.43,11.43,0,0,0-1-1.47,18.26,18.26,0,0,1-3.77-.91C233.15,96.67,232.63,96.42,232.11,96.17Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M217.06,262s0.77-.14,1.55-0.26a5.18,5.18,0,0,1,1.07-.11,2,2,0,0,1,.37,0,0.22,0.22,0,0,1,.13.08l0,0a0.17,0.17,0,0,0-.12,0l-0.34.09a5.18,5.18,0,0,1-1.07.12c-0.78,0-1.57.07-1.57,0.07v0Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M217.42,264.95a0.13,0.13,0,0,1,0-.12,1.13,1.13,0,0,1,.26-0.15l0.81-.39a3.58,3.58,0,0,1,.83-0.33,2.24,2.24,0,0,1,.41-0.06v0a2.23,2.23,0,0,1-.34.24,3.58,3.58,0,0,1-.83.33l-0.86.27a1.12,1.12,0,0,0-.27.1,0.09,0.09,0,0,0,0,.08h0Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M221.17,265a4,4,0,0,0-.81,1.21c-0.13.34-.22,0.68-0.3,0.94l-0.14.44h0a1.57,1.57,0,0,1,0-.48,2.18,2.18,0,0,1,.32-1,3.56,3.56,0,0,1,1-1.14Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M198.57,262.37a9.63,9.63,0,0,0,1.55-.1c0.38-.07.75-0.15,1-0.18s0.49,0,.49,0v0a2.23,2.23,0,0,1-.45.22,3.22,3.22,0,0,1-1.07.18,7.22,7.22,0,0,1-1.57-.09v0Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M199,265.27a5.69,5.69,0,0,0,1.32-.47c0.31-.17.59-0.35,0.83-0.47s0.41-.19.41-0.19l0,0a1.69,1.69,0,0,1-.3.35,2.39,2.39,0,0,1-.87.49,4.63,4.63,0,0,1-1.41.29v0Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M200.69,267.4a0.6,0.6,0,0,1,.11-0.47,6.75,6.75,0,0,1,.68-0.8,3.58,3.58,0,0,1,.79-0.68,2.34,2.34,0,0,1,.43-0.21l0,0a3.9,3.9,0,0,1-.31.36,7.33,7.33,0,0,1-.78.67,9.43,9.43,0,0,0-.76.69,0.55,0.55,0,0,0-.16.41h0Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M193.22,265.29l0.17-.06a1.22,1.22,0,0,1,.48,0,1.88,1.88,0,0,1,1.26.72,2.45,2.45,0,0,1,.39.68,2.88,2.88,0,0,1,.17.66,3.73,3.73,0,0,1,0,.65h0s-0.1-.24-0.23-0.61a6,6,0,0,0-.53-1.26,1.8,1.8,0,0,0-1.09-.75,1.08,1.08,0,0,0-.62,0v0Z" transform="translate(0 -60.95)"/><path class="cls-67" d="M212.74,265.18a2.55,2.55,0,0,1,.62.07,2.28,2.28,0,0,1,1.2.69,1.56,1.56,0,0,1,.37.68,3.39,3.39,0,0,1,.08.64,2.63,2.63,0,0,0,.09.6h0a1.34,1.34,0,0,1-.28-0.57,3.29,3.29,0,0,0-.41-1.22,2.25,2.25,0,0,0-1.06-.74,2.52,2.52,0,0,0-.6-0.14v0Z" transform="translate(0 -60.95)"/><path class="cls-68" d="M131.8,180.11c-1-.36-0.64-4.8,0-4.71a3.52,3.52,0,0,0,3.19,1c2.07-.32,8.06-5,7.1-10.77s-5-11.65-8.94-10.61-5.19,5.11-7.1,6.22-4.51,4.25-3.11,7.58a11,11,0,0,0,2.23,3.51l-2,5.75,2.15,10.13,7.74,6.62,0.8-7.74Z" transform="translate(0 -60.95)"/><path class="cls-69" d="M132.42,172.77c-1-.63-0.94,1.68-0.62,2.63s3,2.47,6.06.88,5.19-3.51,5.82-5.11c0,0,0,2.19-1.2,3.17s-4,7.84-.3,13.58a5.87,5.87,0,0,1,1.81-4.79c2.23-2.23,7.18-3.35,7.82-8.78s-3-7.66-4.63-8l-1.52-2.55s0.84-2.39-3.33-6.38-8.8-3.75-9.2-2.39,2.47,4.55,4.39,4.95,1.44,1.6.32,1.52-3.35.48-2.87,3,1.2,2.71.16,2.87-1.6,1.92-.32,2.15,3.35,0.48,2.47,2.07A3.18,3.18,0,0,1,132.42,172.77Z" transform="translate(0 -60.95)"/><path class="cls-70" d="M143.69,171.18a17.32,17.32,0,0,0,2-7.34c0-1.43,1.47,1,1.52,2.55C147.3,169.66,145.28,171.26,143.69,171.18Z" transform="translate(0 -60.95)"/><path class="cls-71" d="M144.25,159.59a16.27,16.27,0,0,0-1.9-2.13,14.38,14.38,0,0,1-4.92,13.1,1.1,1.1,0,0,1-.13,1l-0.12.2C145.51,169.9,144.26,159.65,144.25,159.59Z" transform="translate(0 -60.95)"/><path class="cls-70" d="M115.36,206.69c-1.76-7.42.16-21.94,0.16-21.94l-0.72-.48a22.9,22.9,0,0,1,3.27-2.63c1.84-1.2,1.52-4.55,2-4s1.84,0.32,3.11.48a12.82,12.82,0,0,1,4.71,6.54c1.52,4.55,3.4,2.31,3.82,1s0.09-5.51.09-5.51a3.1,3.1,0,0,1,2.31,2.23c0.64,2,.24,7.92-0.4,10.22s-0.41,11.49-.18,14.13H115.36Z" transform="translate(0 -60.95)"/><path class="cls-72" d="M131.8,180.11s0.32,4.15-.09,5.51-2.3,3.59-3.82-1a13.93,13.93,0,0,0-1.12-2.5c-0.75,0-1.41-.78-2.14-0.59a1.42,1.42,0,0,0-.74.61,6.56,6.56,0,0,0-1.05,3.85,19.54,19.54,0,0,0,.6,4l3.68,16.66h6.43c-0.23-2.64-.46-11.82.18-14.13s1-8.23.4-10.22A3.1,3.1,0,0,0,131.8,180.11Z" transform="translate(0 -60.95)"/><path class="cls-73" d="M116.22,266.94c-1.43-.18-3.63,0-5-0.6,1.37-2.66,2.35-6.12,3.73-8.73,1.28-2.41,2.12-7.31,5.4-11.09a23.93,23.93,0,0,1,3.24-3s-0.91-3-1.22-3.93a34.94,34.94,0,0,1-1.44-13.2c0.05-.74-0.08-2.3.49-2.86s1.73-.54,2.35-0.7a26.05,26.05,0,0,1,7.19-1,0.88,0.88,0,0,1,.79.32,0.74,0.74,0,0,1,0,.41c-0.3,3.41-.95,6.68-1,10.18,0.09,2.9-.1,5.85-0.14,8.8a15.3,15.3,0,0,1-1.81,7.8C128.24,250.46,117.58,264.83,116.22,266.94Z" transform="translate(0 -60.95)"/><path class="cls-74" d="M131.34,224.54a11.13,11.13,0,0,0-2.07-2.63,30.27,30.27,0,0,0-5.47,1c-0.63.16-1.88,0.23-2.35,0.7s-0.43,2.12-.49,2.86a37,37,0,0,0,.41,8.91,1.86,1.86,0,0,1,.87-0.73,3.62,3.62,0,0,1,3.25.6,6.78,6.78,0,0,1,2.27,4.67,14.2,14.2,0,0,1-1.39,8.07c-1.2,2.4-3.1,4.48-3.8,7.07a5.68,5.68,0,0,0,0,3.16c3-4.12,6-8.22,6.33-8.77a15.3,15.3,0,0,0,1.81-7.8c0-2.95.24-5.9,0.14-8.8a72.52,72.52,0,0,1,.75-7.76C131.5,224.86,131.42,224.7,131.34,224.54Z" transform="translate(0 -60.95)"/><path class="cls-75" d="M118.72,221.07a17.26,17.26,0,0,1,1.19,4.46l3.33,0-0.55-4.47Z" transform="translate(0 -60.95)"/><polygon class="cls-76" points="119.92 164.35 119.94 165.7 124.43 165.63 124.27 163.97 119.92 164.35"/><path class="cls-68" d="M139.6,230.19c1.06,1.82,1.82,3.65,2.8,5.54,1.92,3.71,2.54,7.74,2.93,11.84,0.35,3.65.86,7.43,1.1,11.16a19.06,19.06,0,0,0,1.07,4.91c0.13,0.42,1.44,3.79,1.13,3.84a59.65,59.65,0,0,0-6.13,1.16c-1.34-3.78-1.17-6.89-2.4-10.22a46.09,46.09,0,0,1-2.42-8c-0.46-2.68-1.44-6.71-1.05-9.2-5.76-3.34-10.26-10.15-14.15-16.28,0.78-.65,2.45-0.86,3.23-1.51,1.77-1.48,3.65-2.82,5.43-4.26,0.52-.42.58-0.7,1.13-0.28,1.45,1.08,2,2.79,2.77,4.3C136.14,225.3,138.7,228.65,139.6,230.19Z" transform="translate(0 -60.95)"/><path class="cls-77" d="M144.47,261.14a3.33,3.33,0,0,0,2.51.78,14.42,14.42,0,0,1-.56-3.19c-0.24-3.73-.75-7.5-1.1-11.16-0.39-4.1-1-8.13-2.93-11.84-1-1.89-1.74-3.72-2.8-5.54-0.9-1.54-3.46-4.89-4.57-7-0.74-1.42-1.26-3-2.52-4.09a18.72,18.72,0,0,0-2.82,1.19c-1.34,1-2.69,2.06-4,3.14a2.78,2.78,0,0,1-.61.36,7.49,7.49,0,0,0-1.45,3l0.83,1.28a3.65,3.65,0,0,0,1.44-.36c0.19-.1,1.91-1.72,1.64-1.81a4.25,4.25,0,0,0,3.37-.35c0.87-.5,1.82-1.33,2.71-0.88a2.21,2.21,0,0,1,.77.81,78.32,78.32,0,0,1,4.65,8,14.22,14.22,0,0,1,1.39,3.58,16.13,16.13,0,0,1,.21,3q0,2.91.11,5.81c0.13,4.16.37,8.4,1.84,12.3A7,7,0,0,0,144.47,261.14Z" transform="translate(0 -60.95)"/><path class="cls-71" d="M115.2,208c0.49,2.05,0,4-.21,6.84a10.48,10.48,0,0,0,4.82,9c3.36,2,3.39,3.68,3.39,3.68l2.18-1.14,0.58-2.86,3,0.65,5.13-3.27-1.14-2a11.4,11.4,0,0,1,.06-5.15,11.17,11.17,0,0,0,.13-5.82C132.88,206,115.2,208,115.2,208Z" transform="translate(0 -60.95)"/><path class="cls-78" d="M133.05,213.75a11.18,11.18,0,0,0,.13-5.82c-0.07-.42-1.23-0.64-2.58-0.74-0.13,0-1.69-.51-1.81-0.49-2.72.54-1.6,1.65-.79,4.49s5,7.72,5,7.72A11.4,11.4,0,0,1,133.05,213.75Z" transform="translate(0 -60.95)"/><polygon class="cls-79" points="133.5 147.34 115.18 147.34 115.18 145.34 133.6 145.35 133.5 147.34"/><path class="cls-68" d="M92.14,150l22.66,34.22,4.53-3.42,0.74-3.2c-1.2-2.33-7.49-7-10.7-13-3.91-7.29-15.13-16.05-15.13-16.05-0.88-.57-0.07-1.26-0.52-2S90.8,148,90.8,148a1.11,1.11,0,0,0,0,1.5C91.52,150.1,91.69,149.37,92.14,150Z" transform="translate(0 -60.95)"/><path class="cls-80" d="M120.07,177.64c-1.2-2.33-7.49-7-10.7-13-2-3.64-5.72-7.65-9-10.75a20.43,20.43,0,0,0-1.87-1.05,1,1,0,0,0-1-.11,1,1,0,0,0-.23,1.07,12.65,12.65,0,0,0,2.15,4.08c1.32,1.86,1.94,4.06,3.39,5.82a25.12,25.12,0,0,0,2.51,2.72c0.8,0.72,1.68,1.35,2.45,2.11a18.73,18.73,0,0,1,2.59,3.49q3,4.86,5.61,10l0.52,1,2.84-2.15Z" transform="translate(0 -60.95)"/><path class="cls-79" d="M114.32,183.88l1.2,0.86a7.66,7.66,0,0,0,3.84-3c1.73-2.45,1.13-4.16,1.13-4.16l-1-.64a6.58,6.58,0,0,1-1.7,4.2A10.22,10.22,0,0,1,114.32,183.88Z" transform="translate(0 -60.95)"/><path class="cls-79" d="M122.65,178.07a19.92,19.92,0,0,1,4.88,7.18c1.31,3.94,3.3,3.19,3.95,1.64s0.91-3.23.58-6.72l-0.46-.2s0.63,4.77-.51,6.44-2.23.42-2.75-1.2a12.87,12.87,0,0,0-5.16-7.1Z" transform="translate(0 -60.95)"/><polygon class="cls-79" points="122.98 166.05 123.33 167.06 125.68 165.79 126.18 162.96 129.18 163.69 134.31 160.31 133.88 159.51 129.15 162.61 126.08 162 117.75 149.52 116.69 150.14 125.23 162.53 124.97 165.04 122.98 166.05"/><path class="cls-79" d="M123,187.67a6.55,6.55,0,0,0,.55,2.07,1.07,1.07,0,0,0,.92.85,1,1,0,0,0,.68-0.71c0.4-1,1.11-3,.33-4C124.28,184.31,123,186.42,123,187.67Z" transform="translate(0 -60.95)"/><path class="cls-81" d="M130.88,211a0.43,0.43,0,0,0,.15.4,0.3,0.3,0,0,0,.34-0.08,0.87,0.87,0,0,0,.17-0.32c0.12-.32.23-0.64,0.33-1a2.11,2.11,0,0,0-.09-1.93,6.77,6.77,0,0,0,2.49,2.87,0.42,0.42,0,0,0,.48.06,0.36,0.36,0,0,0,.1-0.23,1.94,1.94,0,0,0-.27-1.13c-0.4-.75-1.59-2.08-2.59-1.79S130.88,210.18,130.88,211Z" transform="translate(0 -60.95)"/><path class="cls-82" d="M119.5,188a5.91,5.91,0,0,1-3-1.17,3.89,3.89,0,0,1-1-2.13c-0.32,2.73-1.36,12.62-.63,19.14a61.33,61.33,0,0,0,1.22-6.15A39.81,39.81,0,0,1,119.5,188Z" transform="translate(0 -60.95)"/><path class="cls-83" d="M142.5,268.63a59.66,59.66,0,0,1,6.13-1.16c0.32,0-1-3.42-1.13-3.84a19.06,19.06,0,0,1-1.07-4.91c-0.23-3.73-.75-7.5-1.1-11.16l0-.23-7.92,1.59c0.11,0.52.21,1,.29,1.47a46.11,46.11,0,0,0,2.42,8C141.32,261.74,141.15,264.85,142.5,268.63Z" transform="translate(0 -60.95)"/><path class="cls-84" d="M147.5,263.63a19.06,19.06,0,0,1-1.07-4.91c-0.23-3.73-.75-7.5-1.1-11.16l0-.23-4.78,1c0,2.48,1.2,5,2,7.42,1.21,3.75,1.55,7.71,2.44,11.55q0.09,0.39.19,0.78c1.32-.25,2.73-0.48,3.49-0.58C148.94,267.43,147.62,264,147.5,263.63Z" transform="translate(0 -60.95)"/><path class="cls-85" d="M141.15,265.86a12.93,12.93,0,0,1,1.07,4.19,1,1,0,0,0,1,1,53.77,53.77,0,0,0,12.08-2.77c0.5-.16.9-0.24,0.66-0.8a3.07,3.07,0,0,0-1.5-1.51,5.88,5.88,0,0,0-1.6-.11l-3,.07a1.06,1.06,0,0,1-.06-1,4,4,0,0,0,.08-1.31,1.34,1.34,0,0,0-.68-1.17,0.85,0.85,0,0,0-.92.31,3.15,3.15,0,0,0-.44.95,8.63,8.63,0,0,1-1.35,2.45,1.44,1.44,0,0,1-.57.49,1.57,1.57,0,0,1-.91,0C143.72,266.34,142.35,265.46,141.15,265.86Z" transform="translate(0 -60.95)"/><path class="cls-86" d="M146.95,268.77a5.7,5.7,0,0,0,3.94-1.12,3.69,3.69,0,0,1,.69-0.47c0.37-.16.79-0.16,1.16-0.34a1.33,1.33,0,0,0,.72-1h-0.62l-3,.07a1.06,1.06,0,0,1-.06-1,4,4,0,0,0,.08-1.31,2.34,2.34,0,0,0,0-.25,1.56,1.56,0,0,0-.29.25c-0.64.71-.54,1.92-1.09,2.74S147.07,267.77,146.95,268.77Z" transform="translate(0 -60.95)"/><path class="cls-83" d="M142.55,271.85a1,1,0,0,0,.71,0,82.35,82.35,0,0,0,13-3.33,1.75,1.75,0,0,0-.48-1.37c-0.28-.13-6.11,1.94-9.33,2.25a20.68,20.68,0,0,0-3.7.43c-0.51.15-.66,0-0.67,0.5A2.36,2.36,0,0,0,142.55,271.85Z" transform="translate(0 -60.95)"/><path class="cls-83" d="M115,257.61c-1.38,2.61-2.36,6.07-3.73,8.73,1.33,0.59,3.53.42,5,.6,0.9-1.41,6-8.31,9.41-13L122,250.74c-1-.85-1.93-1.69-2.91-2.49C116.86,251.69,116.08,255.56,115,257.61Z" transform="translate(0 -60.95)"/><path class="cls-87" d="M121.49,255.05q-3.46,5.8-6.57,11.8c0.47,0,.92,0,1.31.09,0.9-1.41,6-8.31,9.41-13L123.46,252A28.13,28.13,0,0,0,121.49,255.05Z" transform="translate(0 -60.95)"/><path class="cls-88" d="M123.43,254.68q-1.54-1.62-3.19-3.13-0.82-.75-1.66-1.48c-0.1-.09-0.22-0.21-0.35-0.34-0.12.23-.23,0.46-0.35,0.69l5.42,5.07c0.23,0.22.46,0.44,0.68,0.67l0.36-.49C124,255.34,123.74,255,123.43,254.68Z" transform="translate(0 -60.95)"/><path class="cls-89" d="M122.5,256.38q-1.54-1.62-3.19-3.13-0.82-.75-1.66-1.48l-0.26-.25c-0.1.24-.21,0.48-0.31,0.72l5.29,5,0.51,0.49,0.36-.49C123,256.92,122.75,256.64,122.5,256.38Z" transform="translate(0 -60.95)"/><path class="cls-88" d="M144.9,249.81l0.64-.14-0.06-.59-1.19.17q-2.21.36-4.39,0.86-1.08.25-2.15,0.53h0c0,0.24.1,0.48,0.15,0.72Z" transform="translate(0 -60.95)"/><path class="cls-89" d="M145.75,251.55l-0.07-.64-0.51.07q-2.21.36-4.39,0.86-1.08.25-2.15,0.53l-0.5.1c0.06,0.24.14,0.48,0.21,0.71Z" transform="translate(0 -60.95)"/><path class="cls-85" d="M111.23,264.9a11.6,11.6,0,0,1-1.08,3.8,0.69,0.69,0,0,0,.37,1.06,55.32,55.32,0,0,0,11.87.67c0.51,0,.91,0,1-0.52a2,2,0,0,0-.58-1.65,4.87,4.87,0,0,0-1.34-.49l-2.63-.68a1.08,1.08,0,0,1,.41-0.83,4.51,4.51,0,0,0,.7-1.09,1,1,0,0,0,0-1.16,0.92,0.92,0,0,0-1,0,4.17,4.17,0,0,0-.84.69,11.59,11.59,0,0,1-2.36,1.74,1.89,1.89,0,0,1-.74.28,1.34,1.34,0,0,1-.78-0.24C113.23,265.93,112.47,264.85,111.23,264.9Z" transform="translate(0 -60.95)"/><path class="cls-90" d="M122.39,270.42c0.51,0,.91,0,1-0.52a2,2,0,0,0-.58-1.65,4.88,4.88,0,0,0-1.34-.49l-2.63-.68a1.08,1.08,0,0,1,.41-0.83,4.51,4.51,0,0,0,.7-1.09,2,2,0,0,0,.15-0.5l0,0L117.27,267a5.76,5.76,0,0,1-1,.78,8.28,8.28,0,0,1-1.54.52,9.46,9.46,0,0,0-1.46.57,0.73,0.73,0,0,0-.32.25,0.52,0.52,0,0,0,.16.63,1.51,1.51,0,0,0,.65.26l1.4,0.31C117.54,270.49,120.08,270.47,122.39,270.42Z" transform="translate(0 -60.95)"/><path class="cls-83" d="M109.5,270.3a0.84,0.84,0,0,0,.6.21,93.11,93.11,0,0,0,13.1.55,1.31,1.31,0,0,0,.24-1.22c-0.19-.17-6.36,0-9.35-0.5a21.12,21.12,0,0,0-3.46-.56c-0.52,0-.56-0.19-0.83.23A1.81,1.81,0,0,0,109.5,270.3Z" transform="translate(0 -60.95)"/><path class="cls-91" d="M118.82,267.09c-0.14.24-.25,0.59-0.35,0.8a1.1,1.1,0,0,0-.13.43,0.28,0.28,0,0,0,0,.16,0.32,0.32,0,0,0,.15.11,1.09,1.09,0,0,0,.43.09,3.2,3.2,0,0,1,.59-1.4Z" transform="translate(0 -60.95)"/><path class="cls-91" d="M149.54,267.73a0.17,0.17,0,0,0,.1,0l0.65,0h0l0,0a12.43,12.43,0,0,0,.5-1.8l-1,0C149.62,266.28,149.29,267.56,149.54,267.73Z" transform="translate(0 -60.95)"/><path class="cls-92" d="M128.52,163.49c-0.91.75-1.35,0.52-1.7,0.09s-0.49-.91.42-1.66,2.51-1.47,2.86-1S129.42,162.74,128.52,163.49Z" transform="translate(0 -60.95)"/><path class="cls-92" d="M132.49,163.62a0.63,0.63,0,0,1-.81.42,0.68,0.68,0,0,1-.44-0.83,0.63,0.63,0,0,1,.81-0.42A0.68,0.68,0,0,1,132.49,163.62Z" transform="translate(0 -60.95)"/><path class="cls-92" d="M129,160.06a0.52,0.52,0,0,1-.67.35,0.57,0.57,0,0,1-.37-0.69,0.52,0.52,0,0,1,.67-0.34A0.57,0.57,0,0,1,129,160.06Z" transform="translate(0 -60.95)"/><path class="cls-92" d="M133.14,162a0.94,0.94,0,0,1,.2.22,1.58,1.58,0,0,1,.24.58,1.56,1.56,0,0,1,0,.63,0.94,0.94,0,0,1-.12.27,2.54,2.54,0,0,1-.09-0.27c0-.16-0.07-0.36-0.12-0.56s-0.06-.41-0.07-0.57A2.74,2.74,0,0,1,133.14,162Z" transform="translate(0 -60.95)"/><path class="cls-92" d="M129.72,158.92l-0.19-.06-0.35-.14a5.37,5.37,0,0,1-.52-0.26,0.51,0.51,0,0,1,.2-0.09,0.81,0.81,0,0,1,.45,0,0.82,0.82,0,0,1,.34.3A0.5,0.5,0,0,1,129.72,158.92Z" transform="translate(0 -60.95)"/><path class="cls-93" d="M124.16,164.61c-0.64,1.79-.07,4.47,2.29,4.9s3.15-1.84,2.09-2.72c-1.69-1.41-2.95-2.36-3.06-3.29S124.59,163.41,124.16,164.61Z" transform="translate(0 -60.95)"/><path class="cls-94" d="M129.32,165.16a0.36,0.36,0,0,0-.09.22,2.69,2.69,0,0,0,.51,1.65,5.81,5.81,0,0,0,1,1.29,2.5,2.5,0,0,0,1.42.7,0.93,0.93,0,0,0,.74-0.19c0.69-.66-0.31-2.15-0.82-2.65S129.86,164.65,129.32,165.16Z" transform="translate(0 -60.95)"/><path class="cls-94" d="M126.71,161.66a0.23,0.23,0,0,0,.05-0.1,0.9,0.9,0,0,0-.09-0.66,1.5,1.5,0,0,0-.32-0.48,0.79,0.79,0,0,0-.59-0.21,0.59,0.59,0,0,0-.36.14,0.83,0.83,0,0,0,.17,1.13A1.12,1.12,0,0,0,126.71,161.66Z" transform="translate(0 -60.95)"/><path class="cls-95" d="M143.61,211.43c-0.18,3.06,2.36,5.22,5.79,4.14s-3.37-5.81-3.37-5.81Z" transform="translate(0 -60.95)"/><path class="cls-96" d="M176.47,241.59a3.23,3.23,0,0,1-1.36-.59,3,3,0,0,1-.57-0.76,29.17,29.17,0,0,1-2.43-5.37,4,4,0,0,1-.28-1.38,4.44,4.44,0,0,1,.61-1.8,73.37,73.37,0,0,0,3.94-9.43c1-3,2-6.29,4.77-7.83a8.85,8.85,0,0,1,3.88-1,7.72,7.72,0,0,1,3.68.53,9.93,9.93,0,0,1,3.17,2.78c3.52,4.13,7.17,8.48,8.33,13.78s0,11.49-2.06,16.32c-0.9,2.14-2.57,1.48-4.35.74-2.66-1.11-5.32-2.2-8-3.15Q181.18,242.83,176.47,241.59Z" transform="translate(0 -60.95)"/><path class="cls-97" d="M159.89,254.58a4.39,4.39,0,0,1-4,3.41c-0.95,0-2-.21-2.79.3a2.9,2.9,0,0,0-.72.72,10.89,10.89,0,0,0-1.14,1.85,2.58,2.58,0,0,0-.31,1.06c0,1,1.25.55,2,.83a0.43,0.43,0,0,0,.59-0.27,4.92,4.92,0,0,1,1-1.24,1.51,1.51,0,0,1,2-.5c1.21,1,2.83.42,4-.76a7.62,7.62,0,0,0,2.1-4.37" transform="translate(0 -60.95)"/><path class="cls-98" d="M165,220.51s-0.86,7.08-.43,10.73-2.16,4.22-2.58,9.62-1.17,11.36-2.89,14.33l3.43,1s2.12,1.3,4.76-7.93,5.16-25.73,5.16-25.73l-0.6-2.05H165Z" transform="translate(0 -60.95)"/><path class="cls-99" d="M171.84,220.51H165s-0.17,1.38-.32,3.22a8.91,8.91,0,0,1,1.53.91c2,1.6,2.12,5.09,2,7.43a5.62,5.62,0,0,1-.75,3,22.19,22.19,0,0,1-2.22,2.1,8.48,8.48,0,0,0-1.6,3.27c-0.82,2.59-2.06,5.5-2.3,8.21a5.51,5.51,0,0,1-.79,2.42,15.86,15.86,0,0,1-1.48,4.08l3.43,1s2.12,1.3,4.76-7.93,5.16-25.73,5.16-25.73Z" transform="translate(0 -60.95)"/><path class="cls-96" d="M165.77,210.93c-0.41,2.91-1.06,8.37-2.36,11,2.81,0.39,4.45.44,7.26,0.83a5.36,5.36,0,0,1,1.41.32,2.58,2.58,0,0,0,1.54.47l0.21-5.36a26.27,26.27,0,0,1,.43-4.41,12.14,12.14,0,0,0,.61-4.15,0.43,0.43,0,0,0-.3.28" transform="translate(0 -60.95)"/><path class="cls-100" d="M174.71,211.84l-0.09-.13a2.21,2.21,0,0,0-1.87-.85,2.58,2.58,0,0,0-1.11.47,9.06,9.06,0,0,0-2.32,2.51,23.3,23.3,0,0,0-2.46,4.73c-0.47,1.22-.87,2.44-1.43,3.6,1.74,0.19,3.17.29,5.24,0.58a5.36,5.36,0,0,1,1.41.32,2.57,2.57,0,0,0,1.54.47l0.21-5.36a26.27,26.27,0,0,1,.43-4.41C174.39,213.14,174.57,212.49,174.71,211.84Z" transform="translate(0 -60.95)"/><path class="cls-101" d="M174.11,264c0,1.23-1,1.8-2.87,2.59s-4.78,2.87-5.91,3.15,2,1,4.9,1,6.59,0.73,8.27,0,2.82-1.49,2.25-3.21-1.18-2.36-1.07-3.32S174.11,264,174.11,264Z" transform="translate(0 -60.95)"/><path class="cls-102" d="M168,268.37c-1.52.09-4.17,0.54-5.07,1.55s-1.35,2,1.18,2H178.5a2.88,2.88,0,0,0,2.95-2c0.38-1-.13-2.81-0.69-2.36s-0.45,1.29-1.86,1.46-9.27.54-10.86,0.39S168,268.37,168,268.37Z" transform="translate(0 -60.95)"/><path class="cls-103" d="M196.57,242c-5.67-3.12-11.93-5-18.14-6.8l-3.22-.95v0.49a25.93,25.93,0,0,1,4.91,13.31,61.84,61.84,0,0,1-.12,7.22c-0.06,1.17.79,9,.81,10.18s-8.1-.41-8.11-0.61c-0.14-4.16-2.67-15.59-3.19-19.73-0.33-2.6-1.51-5-1.83-7.56q-0.28-2.25-.7-4.47a16.61,16.61,0,0,1-.65-3.52,4.65,4.65,0,0,1,.73-2.75c1-1.31,2.49-1.32,4-1.57a29.12,29.12,0,0,1,5.06-.5c2.55,0,12.54.3,15.07,0" transform="translate(0 -60.95)"/><path class="cls-104" d="M178.43,235.21c6.21,1.83,12.47,3.67,18.14,6.8l-5.39-17.26c-2.17.26-9.83,0.1-13.57,0a18.54,18.54,0,0,1-1.91,2.2c-0.87.77-4.1-.05-5.06,0.61a4.75,4.75,0,0,0-2.11,2.68,5.63,5.63,0,0,0,.43,3.06c2.06,5.88,7.43,12.69,8.9,18.74a60.14,60.14,0,0,1,.81,13.79c1.22,0.07,2.15,0,2.14-.39,0-1.17-.87-9-0.81-10.18a61.85,61.85,0,0,0,.12-7.22,25.93,25.93,0,0,0-4.91-13.31v-0.49Z" transform="translate(0 -60.95)"/><path class="cls-96" d="M171,222c4.21,1.83,11.67,2.45,13.48,3.78l-1.08-4.57-8.51-1.91Z" transform="translate(0 -60.95)"/><path class="cls-97" d="M158.66,261.1a2.93,2.93,0,0,1-1.2,1.71,1.53,1.53,0,0,0-.46.57,0.77,0.77,0,0,0,1,1,1.55,1.55,0,0,0,.43-0.34l0.62-.63a16.23,16.23,0,0,0,1.81-1.71,1.69,1.69,0,0,0,.17-1.34,0.18,0.18,0,0,0-.21-0.16" transform="translate(0 -60.95)"/><path class="cls-97" d="M156.14,263.85c0.11-.19.19-0.39,0.3-0.58a4.31,4.31,0,0,1,2-1.77,1.63,1.63,0,0,0,1-.79,0.41,0.41,0,0,0,0-.28,0.58,0.58,0,0,0-.54-0.25,3.82,3.82,0,0,0-1.08,0,3.66,3.66,0,0,0-1,.46,2.77,2.77,0,0,0-.84.65,3.67,3.67,0,0,0-.36.66c-0.12.25-.26,0.49-0.37,0.74a4.67,4.67,0,0,0-.33,1,2.1,2.1,0,0,0-.07,1.06C155.06,265.22,156,264.08,156.14,263.85Z" transform="translate(0 -60.95)"/><path class="cls-105" d="M159.53,261.47a9.83,9.83,0,0,0-1.16-.12,2.47,2.47,0,0,0-2.32,1.2c-0.41,1-.67,2.09-1.21,2.38a0.88,0.88,0,0,1-.53-1,8,8,0,0,1,.22-2.13,2.7,2.7,0,0,1,1.25-1.68,6.71,6.71,0,0,1,1.68-.43c1.78-.4,3.18-1.72,4.57-2.9a2.48,2.48,0,0,1,1.21-.68,1.76,1.76,0,0,1,1.82,1.23,3.9,3.9,0,0,1-1,2.15A5.25,5.25,0,0,1,159.53,261.47Z" transform="translate(0 -60.95)"/><path class="cls-102" d="M182.26,220.51c0,12.2-5.58,19.89-8.26,25.12s-9.12,13.52-9.12,13.52l-2.9-2.92s4-5.18,4.76-10.08S168,236.73,171,231,173,216.8,173,216.8Z" transform="translate(0 -60.95)"/><path class="cls-106" d="M164.88,259.15s6.44-8.28,9.12-13.52c1.57-3.07,4.14-7,6-12.18h-0.06c0.06-.1.11-0.2,0.17-0.3,0.35-1,.66-2,0.94-3.1a7.77,7.77,0,0,0-.22-2.71,1.22,1.22,0,0,0-.69-0.95,1.07,1.07,0,0,0-.88.25c-1.1.81-1.45,2.27-1.86,3.57-1.45,4.54-4.53,8.38-6.41,12.77-1.15,2.68-1.84,5.57-3.4,8-1.38,2.18-3.37,3.95-4.6,6.21Z" transform="translate(0 -60.95)"/><path class="cls-95" d="M185.84,198.3c1.87-4.17-5-4.22-6.5-1a11.92,11.92,0,0,1-6.16,6.28c-3.76,1.67-7.68,7.74-11.61,4.91s-3.69-8.18-3.69-8.18l14.9-9.12h9.48l5.8,1.17,0.42,5.61" transform="translate(0 -60.95)"/><path class="cls-107" d="M152,216.16a29.75,29.75,0,0,1,2.87,2,1.57,1.57,0,0,0,1.32.49,1.48,1.48,0,0,0,.79-1.26" transform="translate(0 -60.95)"/><path class="cls-105" d="M161.3,205.14c-1.32-.28-2.5-1-3.79-1.44a8.78,8.78,0,0,0-5.6.2,12.09,12.09,0,0,0-4.66,3.19c-1.15,1.24-2.13,2.85-1.85,4.52,0.32,1.94,2.21,3.21,4,3.93,1.12,0.45,2.48.51,3.51,1.11,2.46,1.43,6.58,1,7.8-.26a1.83,1.83,0,0,0,.24-1.65,3.59,3.59,0,0,1-.16-1.71c0.33-1.16,1.54-1,2.45-1.07a20,20,0,0,1,6,.2,2.16,2.16,0,0,0,1,0,1.81,1.81,0,0,0,1-1.6c0.23-1.54.1-7-2.24-6.89a19.29,19.29,0,0,0-3.25,1A9.91,9.91,0,0,1,161.3,205.14Z" transform="translate(0 -60.95)"/><path class="cls-108" d="M168.75,203.77c-1,.17-2,0.74-2.89,1a16.88,16.88,0,0,1-2.24.46,0.71,0.71,0,0,0,.22.47c0.12,0.11.26,0.17,0.38,0.28a1.1,1.1,0,0,1-.2,1.57,3.93,3.93,0,0,1-1.66.64,11,11,0,0,0-4.83,2.6,2.65,2.65,0,0,0-.87,1.27c-0.16.69,0.17,1.43,0,2.1a1.79,1.79,0,0,1-1.14,1.09,4.39,4.39,0,0,1-1.61.18,17.7,17.7,0,0,1-6.57-1.53,3.53,3.53,0,0,0-.91-0.3,8.19,8.19,0,0,0,3,2c1.12,0.45,2.48.51,3.51,1.11,2.46,1.43,6.58,1,7.8-.26a1.83,1.83,0,0,0,.24-1.65,3.59,3.59,0,0,1-.16-1.71c0.33-1.16,1.54-1,2.45-1.07a20,20,0,0,1,6,.2,2.16,2.16,0,0,0,1,0,1.81,1.81,0,0,0,1-1.6c0.18-1.21.14-4.89-1-6.31l-1.07-.38Z" transform="translate(0 -60.95)"/><path class="cls-109" d="M142.2,206.46c0.2,3.49,1.68,7.44,3.87,7,0.2-1.77,3-.91,2.75-3.26-0.11-1.31,1.24-.35,1.83-0.08s5.19,1.28,5.53-1.49c0,0-2.25-1.46-1.18-2.85s4.09,0.72,4.09.72,1.91,0.07,2.21-1.32c0.51-2.36,2.31-4.26,4.05-5.84a21.47,21.47,0,0,1,6.46-4,33.16,33.16,0,0,1,3.56-1.15q2.21-.6,4.46-1.07a11.68,11.68,0,0,1,5-.26,4.42,4.42,0,0,1,2.51,2.47,2.35,2.35,0,0,1-1.46,3.05s5.91,1.49,5.13-5.42-7-9.75-10.84-9.84c-8.86-.22-10.58,9.18-16.71,10.35s-9.27.61-14.48,2.94A11.08,11.08,0,0,0,142.2,206.46Z" transform="translate(0 -60.95)"/><path class="cls-110" d="M232.75,263.46a8.72,8.72,0,0,0,3.78-.89c0,1.23,1.22,2.63,1.74,3.74a5.32,5.32,0,0,1,.45,2.93,0.59,0.59,0,0,0,.18.66c0.66,0.28,1.51.66,2,.12a4.17,4.17,0,0,0,.79-2c0.65-3.18,1.13-6.58,0-9.62a3.3,3.3,0,0,0-1.38-1.84,3.82,3.82,0,0,0-2.8,0,42.48,42.48,0,0,0-7.48,2.92,17.56,17.56,0,0,0,1.12,3.11,2.53,2.53,0,0,0,.77,1.06C232.23,264,232.45,263.78,232.75,263.46Z" transform="translate(0 -60.95)"/><path class="cls-102" d="M240.48,268.42a4.3,4.3,0,0,0-1.77.81c-1,.73-2.58.36-2,1.35s1.11,0.85,1.11.85l3.82,0.12c0.65,0,1.59-1.33,1.78-2.47a60.28,60.28,0,0,0,.29-9.39,3.83,3.83,0,0,0-2.26-3.3c-1.28-.66-4.14-0.44-4,0.22s2.71,0.42,3.54,2.64S241.26,266.65,240.48,268.42Z" transform="translate(0 -60.95)"/><path class="cls-103" d="M234.19,264a14.11,14.11,0,0,0-1.83-6.7c-4.24.87-4.08,1.14-8.41,1.14-4.15,0-7.58.21-11.72-.14a13,13,0,0,0-5.14.33,10,10,0,0,1,1.07-5.34,69.81,69.81,0,0,1,4-7.32l-17.49,7.54a5.59,5.59,0,0,0-.65,2.33c-0.48,3.7-.91,7.66.77,11a18.85,18.85,0,0,0,2.39,3.4,2.21,2.21,0,0,0,.87.74,2.19,2.19,0,0,0,1.13,0c4.59-.79,9.1-1.91,13.64-2.94C218.88,266.67,232.24,266.87,234.19,264Z" transform="translate(0 -60.95)"/><path class="cls-111" d="M234.19,264a14.11,14.11,0,0,0-1.83-6.7c-4.24.87-4.08,1.14-8.41,1.14-4.15,0-7.58.21-11.72-.14a13,13,0,0,0-5.14.33,10,10,0,0,1,1.07-5.34,69.81,69.81,0,0,1,4-7.32l-17.49,7.54a5.59,5.59,0,0,0-.65,2.33c-0.1.8-.2,1.62-0.28,2.43,1.38-.18,2.83-0.85,4.14-0.76,1.8,0.13,3.66,1.34,3.89,3.13a3.88,3.88,0,0,0,.25,1.46c0.46,0.82,1.63.78,2.56,0.63l7.6-1.2a17.24,17.24,0,0,1,5.74-.26,5.84,5.84,0,0,1,4.48,3.25,5.13,5.13,0,0,1,.33,2.28C228,266.31,233,265.68,234.19,264Z" transform="translate(0 -60.95)"/><path class="cls-112" d="M167.44,203.6s1.39,6.49.69,8,1.67,2.82,3.63,3.37,14.41-.52,16.61,10.42c2.53,12.57,3,20.78,1.77,26s-1.67,4.36,2.65,3.8,16.79-1,20.42-.28,3.35,2.5,2.93-6.08S215,223.74,200,209.06s-26.8-8.41-28.19-6.87C171.76,202.19,167.16,202.19,167.44,203.6Z" transform="translate(0 -60.95)"/><path class="cls-112" d="M185,209.32c-1,5.89,0,10.53-.55,16.49a27.07,27.07,0,0,0-4.35-2.95c-2.88-1.28-6-1.1-9.13-.83a33,33,0,0,0,.87-13.25c0-.32-0.09-0.65-0.14-1" transform="translate(0 -60.95)"/><path class="cls-113" d="M189.51,220.37c-0.58-3.38-1.26-7.92-3.28-11.07a0.91,0.91,0,0,0-1.66.58c0.07,1.29.28,2.75,0.28,3.32,0,1.88-.08,3.76-0.24,5.63a11.26,11.26,0,0,1,3.76,6.62c2.53,12.57,3,20.78,1.77,26-0.71,2.93-1.15,3.94-.62,4.17l1.33-2.41a11.76,11.76,0,0,0,.92-1.92,11.42,11.42,0,0,0,.38-3.93A185.12,185.12,0,0,0,189.51,220.37Z" transform="translate(0 -60.95)"/><path class="cls-109" d="M176,184.51a3.07,3.07,0,0,1,1.29-1.84,9.37,9.37,0,0,1,2.55-.87,7.2,7.2,0,0,1,4.77,1.25,5.91,5.91,0,0,1,2.12,4.12,7.72,7.72,0,0,0,.12,1.79,4.88,4.88,0,0,0,.09-3.1,7,7,0,0,0-.84-2.26,5.46,5.46,0,0,0-3-2.16,9.32,9.32,0,0,0-5.85.09,9.1,9.1,0,0,0-4.09,3.3,3.46,3.46,0,0,0-.69,1.28" transform="translate(0 -60.95)"/><path class="cls-114" d="M216.14,248.87c-0.42-8.58-1.12-25.12-16.19-39.81a37.33,37.33,0,0,0-10.28-7.35l-0.21,0c2.75,0.93,4.88,3.14,6.62,5.47a37.59,37.59,0,0,1,5.09,9.34c4.34,11.65,2.68,24.66,5.32,36.8,0.09,0.41.19,0.83,0.3,1.24a42.12,42.12,0,0,1,6.41.36C216.84,255.64,216.56,257.44,216.14,248.87Z" transform="translate(0 -60.95)"/><path class="cls-115" d="M181.46,205a2.13,2.13,0,0,0-2.29-.54,2.62,2.62,0,0,0-1.18,1.6,61.44,61.44,0,0,0-2.78,9.73,18.69,18.69,0,0,1-1,3.89,9,9,0,0,0-.87,2.29,16.3,16.3,0,0,1,6.83.89,11,11,0,0,1,1.3.66c0.49,0.28,2-12.93,1-16.45A4.47,4.47,0,0,0,181.46,205Z" transform="translate(0 -60.95)"/><path class="cls-116" d="M212.82,266.64a36.25,36.25,0,0,0-8.75,1.5,13.88,13.88,0,0,1-3.5.62,6.75,6.75,0,0,1-6.73-7.34l-0.21.17a12.27,12.27,0,0,0,1.18,5.24,18.85,18.85,0,0,0,2.39,3.4,2.21,2.21,0,0,0,.87.74,2.19,2.19,0,0,0,1.13,0c4.59-.79,9.1-1.91,13.64-2.94a56.11,56.11,0,0,1,6.37-.88A57.31,57.31,0,0,0,212.82,266.64Z" transform="translate(0 -60.95)"/><circle class="cls-117" cx="151.37" cy="154.52" r="0.38"/><path class="cls-117" d="M157.83,215a1.16,1.16,0,0,1,.54.12,1.38,1.38,0,0,1,.44.35,1.56,1.56,0,0,1,.25.63,1.51,1.51,0,0,1,0,.35,1.18,1.18,0,0,1-.07.33,0.88,0.88,0,0,1-.38.44,0.69,0.69,0,0,1-.52.12l0-.06a0.6,0.6,0,0,0,.36-0.23,0.73,0.73,0,0,0,.16-0.37,0.75,0.75,0,0,0,0-.22,1.08,1.08,0,0,0-.08-0.21,2,2,0,0,0-.28-0.37c-0.09-.12-0.17-0.26-0.25-0.37s-0.25-.44-0.25-0.44Z" transform="translate(0 -60.95)"/><path class="cls-117" d="M150,215.08a1.06,1.06,0,0,1,.12-0.26,1.63,1.63,0,0,1,.94-0.69,1.07,1.07,0,0,1,.28,0,1.6,1.6,0,0,1-.17.22,3.63,3.63,0,0,1-.42.38,3.7,3.7,0,0,1-.49.29A1.67,1.67,0,0,1,150,215.08Z" transform="translate(0 -60.95)"/><path class="cls-118" d="M81,122.54a6.41,6.41,0,0,1,3.9,8c-1.32,4-5.52,5.41-6.5,7.36s-6.16-4.22-3.46-9.82S81,122.54,81,122.54Z" transform="translate(0 -60.95)"/><path class="cls-119" d="M81,122.54a3.9,3.9,0,0,0-1.6.45l-0.19.35a7.13,7.13,0,0,1,5.26,8.21,7.36,7.36,0,0,0,.44-1A6.41,6.41,0,0,0,81,122.54Z" transform="translate(0 -60.95)"/><path class="cls-120" d="M61.47,128.4c-0.15,5.49,1.1,13.11-1.1,16.91s-9.78,7.07-8.2,14.2,11.13,6.3,15.16.44,6.23-12.28,3.22-20.65S61.57,124.52,61.47,128.4Z" transform="translate(0 -60.95)"/><path class="cls-121" d="M70.55,139.3c-0.3-.83-0.63-1.64-1-2.42l-2.34-3a11.38,11.38,0,0,1-5.71,7.43,10.57,10.57,0,0,1-1.14,4,24.23,24.23,0,0,1-4.11,4.42s4.68,7.68,1,14.72a10.47,10.47,0,0,0,10-4.5C71.35,154.09,73.56,147.67,70.55,139.3Z" transform="translate(0 -60.95)"/><path class="cls-122" d="M68.69,145a25.74,25.74,0,0,1-1.3-12.3c-2-2.31-4.64-7.11-.3-8.48s12.53-2.59,13.52-.35,0,10.79-1.86,14.38S74,139.36,74,139.36s-1.12,3.6.87,6.08a65,65,0,0,1,4.84,8.06l-3.22,5-4.22-3.72-2.11-7.07Z" transform="translate(0 -60.95)"/><path class="cls-123" d="M80.6,123.87c-0.49-1.11-2.75-1.36-5.44-1.17a27.29,27.29,0,0,0-6.94,4.54,9.85,9.85,0,0,0-2.15,2.4,2.21,2.21,0,0,0-.27.83L66,130.82a0.55,0.55,0,0,0,.26,0c0.6-.17,1-1,1.69-1.17,1-.35,2.29,0,3.37-0.18a12.25,12.25,0,0,0,3.75-1.31,32.79,32.79,0,0,0,4.77-3.3,26.72,26.72,0,0,1-.55,10.54,6.3,6.3,0,0,1-2.34,4,3.54,3.54,0,0,1-1.8.53l-0.25,0c1,0.44,2.61.67,3.81-1.66C80.6,134.65,81.59,126.1,80.6,123.87Z" transform="translate(0 -60.95)"/><path class="cls-124" d="M68,258.24c-2,2.68-1.85,3.69-2.49,5.36s-2.68,4.43-2.77,5.82-1.94,2-2.31,0a9.94,9.94,0,0,1,0-4.94c0.46-1.89.37-3.37,0.83-4.48s2.64-1.57,2.8-4.89S68,258.24,68,258.24Z" transform="translate(0 -60.95)"/><path class="cls-124" d="M74.92,255.19c0.74,3,1.75,6.74.55,9s-0.74,3.42.09,3.79A26.84,26.84,0,0,1,79,270.7c1,0.83,7.57.74,6.93,0a28.29,28.29,0,0,0-5-3.69,2.43,2.43,0,0,1-1.2-3c0.37-1.48,1.35-6.43.63-9.82S74.92,255.19,74.92,255.19Z" transform="translate(0 -60.95)"/><path class="cls-125" d="M85.78,153.22c3.12,0.58,4.86,6.08,6.59,7.32l-5.49,3.2L85,159.42Z" transform="translate(0 -60.95)"/><path class="cls-124" d="M87.9,150.86C87.71,152.6,86,155.3,85,159.42s3.49,5.87,4.44,3.28S91,152,91,152a8.74,8.74,0,0,0,2.8-2.64c0.69-1.37,1.06-1.11-.42-2.8-0.87-1-.83-1.62-1.89-2.44a0.78,0.78,0,0,0-1.28.06L88.32,146c-0.2-.18-0.51,0-0.69.25l-0.56.66a1.82,1.82,0,0,0-.56,1.08C86.49,149.48,88.08,149.13,87.9,150.86Z" transform="translate(0 -60.95)"/><path class="cls-126" d="M91.12,151.92a3.18,3.18,0,0,1-.29-0.36,0.86,0.86,0,0,1-.14-0.76,1.26,1.26,0,0,1-1.15-.61,0.51,0.51,0,0,0-.18-0.22,2.73,2.73,0,0,0-.31-0.06c-0.32-.12-0.14-0.67-0.41-0.88a1.58,1.58,0,0,0-.49-0.13,0.62,0.62,0,0,1-.37-0.61,1.38,1.38,0,0,1,.28-0.7c0.31-.46,1.12-0.89,1-1.51a1.23,1.23,0,0,0-.28-0.51l-0.44.43c-0.2-.18-0.51,0-0.69.25l-0.56.66a1.82,1.82,0,0,0-.56,1.08c0,1.49,1.57,1.14,1.38,2.87,0,0.07,0,.15,0,0.23a3.26,3.26,0,0,1,.59,1.06,5.3,5.3,0,0,1,0,2.33,59.34,59.34,0,0,1-1.26,6.44,3,3,0,0,0-.14,1.19,2.24,2.24,0,0,0,1,1.36,2.1,2.1,0,0,0,.51.28,1.78,1.78,0,0,0,.93-1C90.43,160.11,91,152,91,152Z" transform="translate(0 -60.95)"/><path class="cls-127" d="M33.48,106a22.29,22.29,0,0,0-4.55-1C28,105,28,104.91,28,104.35s-0.1-.51.41-0.43a2.73,2.73,0,0,0,1,0s-1.49-1-1.1-1.33,0.66-.76,1-0.08a3.15,3.15,0,0,0,2.09,1.14C32,103.69,33.48,106,33.48,106Z" transform="translate(0 -60.95)"/><path class="cls-125" d="M46.75,111.71c-2.79,3.31-3.14,13.06-4,16.49L49,128.89,48.34,118.2Z" transform="translate(0 -60.95)"/><path class="cls-128" d="M39.8,108.56s-3.7-.78-4.49-1.07A19.79,19.79,0,0,1,31,103.72c-0.93-1.14-.85-1.35-0.07-1.57s1.07,0.36,1.85,1.5a4.32,4.32,0,0,0,3.88,1.62,1.66,1.66,0,0,1,.07-0.9,5,5,0,0,1-1.62-1.57c-0.27-.71.73-0.71,1.16-0.36s2,1.78,3.49,1.85,2.35,1.78,3.13,3.63,5.41,7.83,5.41,7.83l-1.64,7.83s-3.06-4.77-3.92-8S41.93,110.55,39.8,108.56Z" transform="translate(0 -60.95)"/><path class="cls-129" d="M66.3,225.83L62,256a0.55,0.55,0,0,0,.26.52l6.25,3.81a0.56,0.56,0,0,0,.78-0.2l1.66-2.83H82.46l0.39-23.62s3.12-5.86,3.9-7.22-2-5.47-2-5.47a108.46,108.46,0,0,0-2.39-49.44s3.08,1.61,5.13,0,4.83-11,4.83-11a13.42,13.42,0,0,1-6.59-7.32L84,158.46s-2.2-6.27-2.93-9.34-5-3.37-5-3.37l-1.21-.31,1.21,5.51s-6.52-5.71-7-6.74S67,143.4,67,143.4L46.75,111.71s-1.61,13-4,16.49c0,0,14.88,16.42,18.39,25.6s3.9,13.67,2.93,16.6-7.93,12.5-5.86,20.89C60.7,201.19,67,215.66,66.3,225.83Z" transform="translate(0 -60.95)"/><path class="cls-119" d="M80.28,120.93c1.78,1.48.51,3.08-1.32,4.39s-8.33,4-9.59,3.29c-1.8-1.08-3.36,2.67-1.12,3.68a15.89,15.89,0,0,0-2.45,3.8c-0.69,2.09-4.92-.67-4.34-7.7S72.08,114.12,80.28,120.93Z" transform="translate(0 -60.95)"/><path class="cls-130" d="M62.49,258.65a1.44,1.44,0,0,0-1.68.23c-0.82.74-3.14,2.88-3.32,3.2s0.27,1,.64.64S60,260.94,60,260.94a7.79,7.79,0,0,1-.32,2.18c-0.34,1.1-1,6.2-.34,7.43s2.17,1.82,2.86,1a2,2,0,0,0,.56-2.19s-1.74.23-2.19-1.09,0.59-4.87.73-6.28S61.66,258.69,62.49,258.65Z" transform="translate(0 -60.95)"/><path class="cls-130" d="M74.75,266.26c-0.62.11-.64,2-0.33,3.19a10.94,10.94,0,0,1,.32,2.49h0.64V269.1a6.3,6.3,0,0,1,2.23,1.6,1.89,1.89,0,0,0,1.59,1.24h7.65c0.87,0,1.31-.34.32-1.24a5.82,5.82,0,0,0-2.21-.78,1.34,1.34,0,0,1-1.39,1c-1.17,0-3.4.18-4.1-.44S74.63,266.92,74.75,266.26Z" transform="translate(0 -60.95)"/><path class="cls-131" d="M68.12,143.45a4,4,0,0,1,.49,0,4.66,4.66,0,0,1,1.27.31,5.1,5.1,0,0,1,1.6,1,10.31,10.31,0,0,1,.69.77c0.18,0.21.41,0.45,0.62,0.66s0.44,0.42.67,0.6a3.75,3.75,0,0,0,.64.43l0.11,0.05s0,0,.08,0a0.09,0.09,0,0,0,.07,0,0.54,0.54,0,0,0,.28-0.34,4,4,0,0,0,.25-1.1,1.94,1.94,0,0,0,0-.47,1.2,1.2,0,0,1,.31.4,2.66,2.66,0,0,1,.34,1.33,1.49,1.49,0,0,1-.44,1.09,1.29,1.29,0,0,1-.75.35,1.46,1.46,0,0,1-.38,0,2,2,0,0,1-.35-0.07,3.75,3.75,0,0,1-1.06-.54,6.17,6.17,0,0,1-.85-0.72,6.88,6.88,0,0,1-.72-0.85l-0.52-.77a7.64,7.64,0,0,0-1.06-1.18c-0.36-.32-0.69-0.58-0.93-0.76Z" transform="translate(0 -60.95)"/><path class="cls-132" d="M87.82,146.5a0.47,0.47,0,0,0-.15.41,0.26,0.26,0,0,0,.17.24,1.29,1.29,0,0,0,.59,0,1.22,1.22,0,0,0,.78-0.43c0.21-.22.53-0.46,0.74-0.68a2.84,2.84,0,0,0,.91-1.06,0.33,0.33,0,0,0,0-.16,0.38,0.38,0,0,0-.07-0.16,1,1,0,0,0-.65-0.57,1.94,1.94,0,0,0-1.47,1.12A7.73,7.73,0,0,1,87.82,146.5Z" transform="translate(0 -60.95)"/><path class="cls-133" d="M79.17,132.92c-0.11,1.06-.23,1.2.31,1.38s1.54,0.32,1.64-.73-0.18-2.73-.72-2.91S79.28,131.86,79.17,132.92Z" transform="translate(0 -60.95)"/><path class="cls-134" d="M72.94,135.13c0.79,2,2.22,3.45,3.84,2.56s2.42-2.79,1.06-3.58c-1.72-1-2.45-1.8-3.79-1.84C73.11,132.25,72.41,133.76,72.94,135.13Z" transform="translate(0 -60.95)"/><path class="cls-131" d="M77.84,134.12c-1.72-1-2.45-1.8-3.79-1.84a1,1,0,0,0-.73.35,8.36,8.36,0,0,0,2.46,1.57,19.43,19.43,0,0,1,2.66,1.63A1.35,1.35,0,0,0,77.84,134.12Z" transform="translate(0 -60.95)"/><path class="cls-129" d="M76.87,128.19a1.37,1.37,0,0,1,.25-0.16,1.07,1.07,0,0,1,.29-0.1,1.49,1.49,0,0,1,.37,0,2.16,2.16,0,0,1,.57.23,1.32,1.32,0,0,1,.24.18,1.28,1.28,0,0,1-.29,0,1.91,1.91,0,0,1-.29,0l-0.31,0a1.13,1.13,0,0,0-.27-0.06l-0.27,0A1.27,1.27,0,0,1,76.87,128.19Z" transform="translate(0 -60.95)"/><path class="cls-129" d="M76,130.38s0.12-.26.34-0.64a2.11,2.11,0,0,1,.53-0.59,1.11,1.11,0,0,1,.53-0.2,1.27,1.27,0,0,1,.55.05,0.86,0.86,0,0,1,.5.45,1.11,1.11,0,0,1,.07.55,4.61,4.61,0,0,1-.14.73c-0.12.41-.19,0.69-0.19,0.69a2.52,2.52,0,0,1-.18-0.71L77.9,130a0.48,0.48,0,0,0-.1-0.23,0.32,0.32,0,0,0-.13-0.06,1,1,0,0,0-.27,0,0.42,0.42,0,0,0-.23,0,4.29,4.29,0,0,0-.56.32A2.88,2.88,0,0,1,76,130.38Z" transform="translate(0 -60.95)"/><path class="cls-135" d="M74.36,144.6a7.77,7.77,0,0,1-.35-5.19l-0.28-.28c-1.06-1.07-3.29-4.33-4.94-4a7,7,0,0,0,1.08,4.42C70.78,141.09,72.46,143.62,74.36,144.6Z" transform="translate(0 -60.95)"/><path class="cls-136" d="M87.27,166c-1.1-.07-2.29.51-3.46,0.46a14.47,14.47,0,0,1-4.15-.9c-2.52-.89-4.95-2.14-7.6-2.47a0.73,0.73,0,0,0-.44,0,0.76,0.76,0,0,0-.29.44c-2.08,5.73-4.17,11.53-4.88,17.59a10,10,0,0,0,.33,4.82c0.64,1.62,2,2.85,3.1,4.17a20.24,20.24,0,0,1,4.3,8.53c0.37,1.62.55,3.29,1.08,4.86A22.51,22.51,0,0,0,77.53,208l6.56,10.74c0.27,0.44.56,0.9,0.87,1.34a108.52,108.52,0,0,0-2.54-48.59s3.07,1.61,5.13,0a11.83,11.83,0,0,0,2.37-4A4.16,4.16,0,0,0,87.27,166Z" transform="translate(0 -60.95)"/><path class="cls-137" d="M85.78,153.22L84,158.46s-2.2-6.27-2.93-9.34c-0.53-2.23-2.9-3-4.17-3.25,0.1,0.88,1.1,2.15,1.45,2.81a108.08,108.08,0,0,1,5.88,13.57c0.62,1.75,1.17,3.77.23,5.37-0.65,1.1-2,1.92-2,3.2a2.07,2.07,0,0,0,.2.84c0.82,0.35,3.16,1.17,4.83-.14,2.05-1.61,4.83-11,4.83-11A13.42,13.42,0,0,1,85.78,153.22Z" transform="translate(0 -60.95)"/><path class="cls-138" d="M46.08,116.26c0.25,0.29.5,0.59,0.75,0.93a46.89,46.89,0,0,1,3,5.31l5.81,10.45c3.42,6.15,6.87,12.38,8.72,19.16,0.9,3.31,1.46,6.83,3.38,9.67,1.69-5.65.43-11.71-.84-17.47l-0.41-1.83L46.75,111.71S46.51,113.67,46.08,116.26Z" transform="translate(0 -60.95)"/><path class="cls-139" d="M70.94,257.28H82.46l0.39-23.62,0.72-1.35c-2.11,1.91-3.41,4.6-4.63,7.2l-7.26,15.55a7.55,7.55,0,0,0-.76,2.25v0Z" transform="translate(0 -60.95)"/><path class="cls-140" d="M76.51,222.31c-1.76-12.07-14.69-20.64-15.14-32.83-0.14-3.74,1-7.52.23-11.19a8.69,8.69,0,0,0-2,1.54c-1.39,3.57-2.32,7.64-1.38,11.47,2.45,9.9,6.88,26.79,6.17,37L62,256.32l0.26,0.16c3.65-3.9,6.41-8.7,8.9-13.48C74.45,236.56,77.56,229.48,76.51,222.31Z" transform="translate(0 -60.95)"/><path class="cls-141" d="M90.38,152.57a3.54,3.54,0,0,0-1-1.35,0.69,0.69,0,0,0-.25-0.16,0.66,0.66,0,0,0-.44.08,3.4,3.4,0,0,0-1.56,1.44,0.81,0.81,0,0,0,.1,1,0.44,0.44,0,0,0,.23.18,0.41,0.41,0,0,0,.39-0.21,1.26,1.26,0,0,1,.48-0.41,2.31,2.31,0,0,1,.66-0.23c0.36,0.88-.71,2.41,0,2.93a10.45,10.45,0,0,0,1.35-1.22A4.2,4.2,0,0,0,90.38,152.57Z" transform="translate(0 -60.95)"/><g id="_Group_" data-name="&lt;Group&gt;"><path id="_Path_" data-name="&lt;Path&gt;" class="cls-142" d="M48.86,83.47L56,88.17l0,0C57.39,89,61.14,85.92,63.72,82s4-8.58,2.6-9.51l0,0-7.13-4.7Z" transform="translate(0 -60.95)"/><path class="cls-143" d="M61.37,77c0.36-1.56.73-3.12,1.15-4.66a14.09,14.09,0,0,1,.67-1.84l-4-2.66L48.86,83.47,56,88.17l0,0c1.07,0.68,3.53-1,5.77-3.57A12.43,12.43,0,0,1,61,82.34,12.23,12.23,0,0,1,61.37,77Z" transform="translate(0 -60.95)"/><polygon id="_Path_2" data-name="&lt;Path&gt;" class="cls-144" points="63.01 0.01 49.91 13.61 44.77 29.52 45.25 29.83 59.3 16.49 63.49 0.32 63.01 0.01"/><polygon id="_Path_3" data-name="&lt;Path&gt;" class="cls-142" points="44.79 29.48 49.92 13.59 63.01 0 58.84 16.16 44.79 29.48"/><ellipse id="_Path_4" data-name="&lt;Path&gt;" class="cls-144" cx="54.1" cy="75.82" rx="2.65" ry="0.74" transform="translate(-38.98 18.25) rotate(-56.57)"/><path id="_Path_5" data-name="&lt;Path&gt;" class="cls-145" d="M54.1,75.82c-2.58,1.86-4,5.16-4.83,8.21a8.23,8.23,0,0,0-.43,4.07,1.21,1.21,0,0,0,.39.73,1.8,1.8,0,0,0,1.34.06c0.74-.11,2.19-0.07,2.41.86a1.36,1.36,0,0,1-.17.95,4,4,0,0,1-.61.77,6.5,6.5,0,0,0-1,1.13c-0.19.35-.36,0.74-0.52,1.11a4.13,4.13,0,0,0-.27,3.13" transform="translate(0 -60.95)"/><g id="_Group_2" data-name="&lt;Group&gt;"><path id="_Path_6" data-name="&lt;Path&gt;" class="cls-146" d="M53,101.31a0.26,0.26,0,0,1-.17.31l-2.21.55a0.26,0.26,0,0,1-.3-0.19l-0.45-5.14a0.25,0.25,0,0,1,.18-0.3l0.63-.16a0.25,0.25,0,0,1,.3.18Z" transform="translate(0 -60.95)"/><path id="_Path_7" data-name="&lt;Path&gt;" class="cls-147" d="M50.71,96a0.12,0.12,0,0,1-.08.14L50,96.35a0.12,0.12,0,0,1-.14-0.08h0a0.12,0.12,0,0,1,.08-0.14L50.57,96a0.12,0.12,0,0,1,.14.08h0Z" transform="translate(0 -60.95)"/><path id="_Path_8" data-name="&lt;Path&gt;" class="cls-147" d="M50.77,96.26a0.12,0.12,0,0,1-.08.14L50,96.57a0.12,0.12,0,0,1-.14-0.08h0A0.12,0.12,0,0,1,50,96.35l0.67-.17a0.12,0.12,0,0,1,.14.08h0Z" transform="translate(0 -60.95)"/><path id="_Path_9" data-name="&lt;Path&gt;" class="cls-147" d="M50.66,95.81a0.12,0.12,0,0,1-.08.14l-0.67.17A0.12,0.12,0,0,1,49.76,96h0a0.12,0.12,0,0,1,.08-0.14l0.67-.17a0.12,0.12,0,0,1,.14.08h0Z" transform="translate(0 -60.95)"/></g></g><path class="cls-148" d="M270.58,244.71c-2.57-1.06-4.55-.26-4.55,1.78s2.9,1.32,4.55-.92" transform="translate(0 -60.95)"/><path class="cls-149" d="M272.51,250.16c-2.55-.76-4-4.16-1.87-8.06s5.52-2.46,6.28-4.07,1.36-3,3.22-1.7,2.12,5.6.85,9.59-4,3.56-3.48,4.84,1.78,3.13,1,6c-0.68,2.57-1.87,3.73-.08,4.41a2.31,2.31,0,0,1,.93,3.53c-0.68.46-.34-1.07-1.61-1.49s-3.14-1.78-3.22-3.22a3.66,3.66,0,0,0,1.44,4.38c2.55,1.9,2.89,4,2.29,5.65a2.28,2.28,0,0,1,1.87.59c0.59,0.75.76,1.33,0,1.33H262.07c-3,0-7-3.88-8.06-10.5s0.68-7.89-1.87-10.78c0,0,1.19,4.24-2.55,5.52s-11.88-.08-10.69-9.84,15.44-13,20.37-5.08-0.25,18.5,1.87,23.63,4.33,4.7,4.33,4.7-3.31-3.65-1.1-10.82A12.42,12.42,0,0,1,272.51,250.16Z" transform="translate(0 -60.95)"/><path class="cls-150" d="M280.15,236.32c-1.43-1-2.11-.4-2.7.64h0a3.08,3.08,0,0,1,1.64,1.81,6.3,6.3,0,0,1,.6,1.53,4.1,4.1,0,0,1-.07,1.67,7.29,7.29,0,0,1-1.73,3.89c-0.73.71-1.7,1.12-2.44,1.83a4.15,4.15,0,0,0-1.22,2.36,0.87,0.87,0,0,0,0,.44,1.08,1.08,0,0,0,.43.44,5.5,5.5,0,0,1,2.12,5.43c-0.14.68-.41,1.32-0.53,2a2.6,2.6,0,0,0,.3,2c0.79,1.1,2.73,1.12,3.17,2.4a3,3,0,0,1,.12.67,2.27,2.27,0,0,0-1.41-2.25c-1.78-.68-0.59-1.84.08-4.41,0.76-2.89-.51-4.75-1-6s2.21-.85,3.48-4.84S282,237.6,280.15,236.32Z" transform="translate(0 -60.95)"/><path class="cls-51" d="M276.92,238c-0.82-1.23-.42-3,1.27-2.89s3.21,1.13,2.71,2S277.6,239,276.92,238Z" transform="translate(0 -60.95)"/><path class="cls-149" d="M271.38,246.36c-2.88-.8-5.84,1.52-5.28,4.24s3.84-.16,5.28-2.88S271.38,246.36,271.38,246.36Z" transform="translate(0 -60.95)"/><path class="cls-151" d="M266.91,250.09c-1-1.36,1.53-3.52,3-3.33C270.2,248.2,268.28,251.9,266.91,250.09Z" transform="translate(0 -60.95)"/><ellipse class="cls-51" cx="274.91" cy="181.22" rx="0.72" ry="0.44"/><path class="cls-152" d="M272.5,265.09c4.24,2.8,2,5.87,2,5.87a23.28,23.28,0,0,1,3.78-.93c0.59-1.69.25-3.74-2.29-5.65a3.66,3.66,0,0,1-1.44-4.38c-1.32-1.33-1.24-4.12-1.24-4.12S268.26,262.29,272.5,265.09Z" transform="translate(0 -60.95)"/><path class="cls-153" d="M256.8,257.77c2.3-8.23-2.46-15.53-9.81-13.29s-4.59,12.11.68,12.08a7.88,7.88,0,0,0,1.93-.37c3.73-1.27,2.55-5.52,2.55-5.52,2.55,2.89.85,4.16,1.87,10.78,0.82,5.36,3.65,8.92,6.27,10.09A14.43,14.43,0,0,1,256.8,257.77Z" transform="translate(0 -60.95)"/><path class="cls-154" d="M264.36,258.77c-2.21,7.17,1.1,10.82,1.1,10.82a23.3,23.3,0,0,1,2.3.68c-6.79-13.54,4.75-20.12,4.75-20.12A12.42,12.42,0,0,0,264.36,258.77Z" transform="translate(0 -60.95)"/><path class="cls-155" d="M252.14,250.67c-3.2-2.92-6.18-1-5.84,1.1s2.91,1.38,2.91,1.38-2.49-.63-1.15-1.58S252.14,250.67,252.14,250.67Z" transform="translate(0 -60.95)"/><path class="cls-156" d="M286.34,258.48c-0.91.91-4.37,3.19-4.53,6.75s1,4.21.89,5.36a2.08,2.08,0,0,1,1.65.57c0.78,0.72,4.11.92,6.55-.36s4.47-4.47,4.47-4.47Z" transform="translate(0 -60.95)"/><path class="cls-157" d="M286.34,258.48c-0.15.15-.38,0.35-0.65,0.58,0.47,1.76,2.51,3.85,3.18,4.82a2.83,2.83,0,0,1,.63,1.43,2.86,2.86,0,0,1-.89,1.83,7.93,7.93,0,0,1-3.09,2.6c-0.68.25-1.41,0.31-2.11,0.52a3.55,3.55,0,0,0-.72.3s0,0,0,0a2.08,2.08,0,0,1,1.65.57c0.78,0.72,4.11.92,6.55-.36s4.47-4.47,4.47-4.47Z" transform="translate(0 -60.95)"/><path class="cls-158" d="M292.27,260.31a4,4,0,0,1,2.84-1.47c0.39,0.07.72,0.85,0.26,1s-2.05.75-2.35,1.5S292.27,260.31,292.27,260.31Z" transform="translate(0 -60.95)"/><path class="cls-159" d="M288.33,256a2.17,2.17,0,0,0-2.51.81c-0.62.68-.52,1.57,0.36,2.38s7.38,7.65,8.32,8.33,1.47,0.6,2.41-.21a1.68,1.68,0,0,0,.13-2.6C296.31,264,289.4,256.46,288.33,256Z" transform="translate(0 -60.95)"/><path class="cls-160" d="M297,264.74c-0.26-.28-1.31-1.43-2.61-2.8a5.41,5.41,0,0,0,0,.76,1.59,1.59,0,0,1-1.77,1.39,4.14,4.14,0,0,1-2.22-1.13,12.94,12.94,0,0,1-3.13-3.39c-0.28-.48-1.1-1.73-1.81-1.26a2.47,2.47,0,0,0,.65.91c0.88,0.82,7.38,7.65,8.32,8.33s1.47,0.6,2.41-.21A1.68,1.68,0,0,0,297,264.74Z" transform="translate(0 -60.95)"/></svg>
\ No newline at end of file
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Generator: Adobe Illustrator 25.3.1, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
+<svg version="1.1" id="Слой_2" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
+	 viewBox="0 0 628.6 667.1" style="enable-background:new 0 0 628.6 667.1;" xml:space="preserve">
+<style type="text/css">
+	.st0{fill:#35363C;}
+	.st1{fill:#222328;}
+	.st2{fill:#FFCBB3;}
+	.st3{fill:#602E1C;}
+	.st4{fill:#FF7749;}
+	.st5{fill:#A2B3DD;}
+	.st6{fill:#CED3F4;}
+	.st7{fill:#4E31B5;}
+	.st8{fill:#2B2B7D;}
+	.st9{fill:#D48975;}
+	.st10{fill:none;stroke:#D48975;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;}
+	.st11{fill:none;stroke:#35363C;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;}
+	.st12{fill:#B76447;}
+	.st13{fill:#FFD57E;}
+	.st14{fill:#E2FCFF;}
+	.st15{fill:#74D8E6;}
+	.st16{fill:#E674E4;}
+	.st17{fill:#F2AE7F;}
+	.st18{fill:#6C9D5C;}
+	.st19{fill:#00C7FF;}
+	.st20{fill:#008AB1;}
+	.st21{fill:#E9C3B5;}
+	.st22{fill:none;stroke:#B76447;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;}
+	.st23{fill:#D3EA79;}
+	.st24{fill:#7FD100;}
+</style>
+<g id="girl">
+	<g id="hair">
+		<path class="st0" d="M337.42,126.26c21.6-2.52,40.37,12.51,42.61,31.1c1.82,15.06-7.42,30.67-23.01,37.49
+			c-0.26,2.35-0.53,6.3,0.03,11.07c3.81,32.59,39.5,47.1,35.33,62.2c-0.83,3.02-3.58,7.21-13.21,10.65
+			c1.94,1.33,13.22,9.34,15.34,24.28c2.73,19.28-12.33,32.09-13.21,32.8c0.11,0.75,1.48,11.66-6.82,18.75
+			c-6.25,5.34-13.66,4.82-15.12,4.69c-0.48,1.36-3.88,10.62-13.85,14.49c-11.68,4.53-21.81-2.43-22.58-2.98
+			c-1.38,1.07-10.85,8.15-23.43,5.54c-10.54-2.19-16.19-9.71-17.47-11.5c-1.67,0.63-8.6,3.02-15.76-0.24
+			c-7.65-3.49-12.45-12.03-11.93-21.49c-4.47-0.98-25.76-6.15-36.21-25.14c-12.03-21.85-4.96-53.39,19.6-73.7
+			c-1.31-3.55-2.77-8.97-2.13-15.34c2.49-24.83,32.93-24.93,46.01-54.53c7.49-16.94,4.21-32.06,18.59-43.02
+			c3.55-2.71,6.99-4.25,9.32-5.12c-2.06-1.09-5.07-3-7.88-6.21c-1.95-2.23-3.22-4.42-4.06-6.15c1.2,0.71,2.83,1.52,4.86,2.12
+			c1.81,0.54,3.44,0.77,4.73,0.86c-0.75-0.65-1.74-1.67-2.55-3.16c-1.51-2.79-1.4-5.48-1.29-6.64c1.32,1.83,3.49,4.39,6.8,6.64
+			c2.32,1.58,4.53,2.56,6.28,3.17c-0.42-1.25-1.06-3.69-0.61-6.72c0.13-0.86,0.59-3.92,2.17-5.65c4.92-5.38,22,0.55,22.62,6.52
+			c0.25,2.43-2.36,3.61-3.26,8.7C336.87,122.43,337.13,124.73,337.42,126.26z"/>
+		<path class="st1" d="M307.13,146.92c1.7-9.61,16.79-16,20.07-12.89c2,1.89-0.35,7.29-1.52,9.43c-4.22,7.71-14.38,11.74-17.56,9.05
+			C306.4,151.05,306.97,147.82,307.13,146.92z"/>
+		<path class="st1" d="M339.23,136.52c7.98-3.18,21.62,3.29,28.14,14.02c6.06,9.95,6.53,24.5-0.59,31.6
+			c-0.95,0.95-3.9,3.89-7.19,3.39c-5.24-0.79-9.4-9.98-9.91-23.62c-2.35,0.3-6.21,0.34-9.64-1.9c-7.17-4.69-8.45-16.77-3.8-21.58
+			C336.48,138.17,337.41,137.24,339.23,136.52z"/>
+	</g>
+	<g id="arm2">
+		<path class="st2" d="M276.47,260.6l-2.02,12.67l-5.46,34.23c-0.73,4.61-4.91,7.86-9.56,7.44l-0.59-0.05
+			c-5.15-0.48-8.81-5.24-7.94-10.34l6.21-36.09l1.85-10.76c0.75-4.32,4.49-7.37,8.73-7.37c0.53,0,1.07,0.05,1.62,0.15
+			C274.05,251.36,277.22,255.85,276.47,260.6z"/>
+		<path class="st2" d="M256.93,369.69c0.86,2.98-1.14,5.84-3.62,6.16c-2.14,0.28-4.48-1.36-5.01-3.94
+			c-0.7-12.3-0.81-25.89,0.11-40.55c0.53-8.44,1.35-16.44,2.36-23.98c1.55-4.49,6.28-6.99,10.6-5.84c3.93,1.04,6.7,4.88,6.45,9.16
+			c-0.46,3.26-1.26,8.33-2.56,14.49c-2.28,10.79-4.03,15.1-5.75,23.42C258.52,353.46,257.33,360.64,256.93,369.69z"/>
+		<path class="st2" d="M263.65,399.58c-0.63,0.72-1.69,1.92-3.08,1.88c-6.52-0.2-11.33-27.45-11.33-27.45l0,0
+			c-1.17-2.54,0.22-5.43,2.5-6.11c2.14-0.64,4.72,0.75,5.37,3.28c2.65,3.9,4.23,7.4,5.18,9.87
+			C264.28,386.17,267.69,395,263.65,399.58z"/>
+		<path class="st3" d="M276.47,260.6l-2.02,12.67c-1.94-1.47-4.22-2.96-6.61-4.07c-3.01-1.4-7.11-1.29-10.73-0.74
+			c0.11-0.85,0.23-1.72,0.36-2.59c0.42-2.84,0.93-5.57,1.49-8.17c0.47-0.97,3.6-7.37,8.73-7.37c0.53,0,1.07,0.05,1.62,0.15
+			C274.05,251.36,277.22,255.85,276.47,260.6z"/>
+	</g>
+	<g id="arm1">
+		<path class="st2" d="M353.06,310.76l-0.55,0.09c-4.34,0.64-8.43-2.41-9.36-6.97l-4.44-21.93l-4.97-24.55
+			c-0.95-4.71,1.8-9.35,6.2-10.45c0.64-0.16,1.28-0.24,1.91-0.24c3.82,0,7.29,2.81,8.17,6.95l4.74,22.1l5.22,24.3
+			C361.06,305.11,357.87,310.05,353.06,310.76z"/>
+		<path class="st2" d="M353.07,365.46c0.37,4.42,3.52,6.94,5.71,6.54c1.51-0.27,2.75-1.97,3.3-3.97c0.23-1.16,5.02-25.63,3.43-40.97
+			c-0.67-6.51-2.14-13.94-2.14-13.94c-0.79-3.97-1.59-7.26-2.2-9.59c-1.45-4.49-5.9-6.99-9.96-5.84c-3.69,1.04-6.29,4.88-6.06,9.16
+			c0.29,5.31,0.67,8.76,2.4,14.49c1.64,5.44,2.44,11.54,4.03,23.75C352.19,349.89,352.9,356.86,353.07,365.46z"/>
+		<path class="st2" d="M353.51,397.53c0.74,0.58,1.96,1.54,3.23,1.22c5.95-1.5,4.55-29.09,4.55-29.09l0,0
+			c0.54-2.72-1.36-5.26-3.6-5.47c-2.1-0.2-4.18,1.68-4.23,4.28c-1.6,4.34-2.31,8.08-2.66,10.68
+			C350.07,384.56,348.83,393.86,353.51,397.53z"/>
+		<path class="st3" d="M354.76,275.76c-1.83,0.46-3.76,1.02-5.75,1.7c-3.92,1.35-7.36,2.92-10.3,4.49l-4.97-24.55
+			c-0.95-4.71,1.8-9.35,6.2-10.45c0.64-0.16,1.28-0.24,1.91-0.24c3.82,0,7.29,2.81,8.17,6.95c1.55,6.53,3,13.19,4.33,19.97
+			C354.49,274.35,354.63,275.06,354.76,275.76z"/>
+	</g>
+	<g id="leg1_2_">
+		<path class="st4" d="M259.7,581.34c0.58,0.79,1.91,2.57,3.74,2.61c2.14,0.04,3.76-2.35,4.44-3.36c4.6-6.79,3.29-31.44,3.05-35.68
+			c0.79-6.02-1.93-10.31-4.25-10.52c-2.11-0.19-5,2.87-6.08,7.57c-1.47,5.37-2.31,9.86-2.8,12.95
+			C254.87,573.1,258.1,579.14,259.7,581.34z"/>
+		<path class="st5" d="M272.71,454.28c-1.41,3.64-3.35,9.07-5.1,15.81c-2.48,9.54-3.54,17.68-4.98,37.38
+			c-0.69,9.41-1.43,21.05-2.04,34.48c0.3,2.65,2.26,4.77,4.73,5.21c2.09,0.37,4.25-0.51,5.6-2.26c1.11-3.79,2.76-9.46,4.76-16.36
+			c7.41-25.55,6.92-24.37,7.75-26.66c4.3-11.83,10.1-23.28,11.93-31.55c0.86-3.9,1.59-7.98,1.59-7.98c0.49-2.78,0.85-5.15,1.1-6.93
+			c-0.85-5.06-4.02-9.31-8.33-10.76C283.57,442.59,275.61,446.41,272.71,454.28z"/>
+		<path class="st6" d="M299,451.46c-0.56,7.12-6.68,12.46-13.46,12.41c-5.73-0.04-11.05-3.92-12.84-9.59
+			c-1.67-21.2-2.35-44.85-1.23-70.52c0.89-20.38,2.8-39.32,5.28-56.66c3.06-7.44,10.27-11.98,16.86-11.35
+			c8.74,0.85,16.61,10.83,13.68,22.06c-2.05,15.2-3.8,31.06-5.17,47.56C300.21,408.51,299.25,430.58,299,451.46z"/>
+	</g>
+	<g id="leg1_1_">
+		<path class="st4" d="M368.92,572.28c-0.64,0.79-2.13,2.57-4.17,2.61c-2.38,0.04-4.19-2.35-4.95-3.36
+			c-5.13-6.79-3.67-31.44-3.4-35.68c-0.89-6.02,2.15-10.31,4.74-10.52c2.35-0.19,5.58,2.87,6.78,7.57
+			c1.63,5.37,2.57,9.86,3.13,12.95C374.31,564.04,370.71,570.09,368.92,572.28z"/>
+		<path class="st5" d="M354.52,534.37c-4.71-12.15-9.5-27.69-12.32-46.11c-2.21-14.39-2.73-27.35-2.48-38.28
+			c-0.47-6.89,4.02-12.49,8.93-13.26c5.81-0.91,12.96,4.85,12.75,13.36c1.53,14.96,2.59,27,3.29,35.32
+			c0.72,8.66,1.36,17.16,2.62,30.58c0.62,6.59,1.16,11.99,1.52,15.54c-0.94,3.31-3.74,5.71-7.01,6.05
+			C357.46,538.01,354.69,534.58,354.52,534.37z"/>
+		<path class="st6" d="M307.92,330.22c-0.18,3.16-0.22,8.21,0.84,14.28c0.83,4.75,2,8.18,2.45,9.5c0.22,0.65,5.98,19.76,17.5,57.98
+			c2.39,7.94,5.81,19.78,9.49,34.52c0.61,1.93,2.22,5.96,6.26,8.61c4.92,3.23,12.49,3.76,15.49,0.29c1.62-1.87,1.53-4.44,1.44-5.32
+			c-2.14-21.39-5.04-38.43-7.17-49.51c-6.89-36.04-17.87-73.8-17.87-73.81c-0.01-0.01-11.55-14.78-18.78-12.5
+			C311.59,316.14,307.27,322.78,307.92,330.22z"/>
+	</g>
+	<g id="waist">
+		<path class="st6" d="M336.62,329.09c0.11,3.43-1.11,6.83-3.6,9.38c-0.58,0.6-1.25,1.17-2.01,1.7c-4.79,3.29-11.75,3.54-18.06,0.65
+			c-3.05-1.4-6.5-1.72-9.78-0.91c-3.78,0.94-9.16,1.47-14.98-0.51c-2.03-0.69-3.79-1.58-5.3-2.54c-4.3-2.72-6.65-7.44-6.31-12.29
+			c0-0.12,0.01-0.23,0.02-0.35c0.53-5.68,1.06-11.36,1.59-17.04c0.36-3.83,0.72-7.65,1.08-11.48c0.31-3.32,1.87-6.43,4.41-8.75
+			c3.99-3.64,10.88-8.19,20.55-8.39c9.6-0.19,16.65,4.02,20.69,7.33c2.44,2,4.06,4.75,4.67,7.75c0.8,3.9,1.59,7.8,2.39,11.69
+			c1.46,7.14,2.91,14.28,4.37,21.42C336.51,327.53,336.6,328.31,336.62,329.09z"/>
+		<path class="st3" d="M337.02,329.07c-6.38-2.16-14.19-4.21-23.21-5.37c-15.07-1.94-27.96-0.67-37.24,1.04
+			c0.01-0.33,0.01-0.65,0.02-0.98c0.16-5.73,0.72-11.26,1.6-16.58l53.79-1.85c1.48,7.02,2.97,14.06,4.47,21.09
+			C336.54,326.82,336.93,328.68,337.02,329.07z"/>
+	</g>
+	<g id="neck">
+		<path class="st2" d="M336.58,220.31c0,0-7.06,8.62-26.47,9.21c-19.4,0.59-26.85-14.7-26.85-14.7l17.49-13.85
+			c0.86-0.68,1.46-1.63,1.71-2.7c0.82-2.99,1.61-6.09,2.37-9.3c0.78-3.3,1.47-6.51,2.08-9.63c1.32-1.02,6.33-4.61,11.35-3.19
+			c6.05,1.71,10.5,9.83,8.1,18.86c-1.11,3.15-2.23,6.31-3.34,9.46c-0.32,0.92-0.22,1.91,0.27,2.72c0.13,0.24,0.31,0.47,0.52,0.67
+			C328.06,212.01,332.32,216.16,336.58,220.31z"/>
+		<path class="st3" d="M323.1,204.48c-0.07,0.21-0.24,0.77-0.17,1.47c0.05,0.52,0.22,0.95,0.37,1.24c-1.48,0.87-4.88,2.57-8.8,1.78
+			c-5.92-1.19-10.7-7.6-10.9-15.77c0.28-1.2,0.57-2.4,0.85-3.6c0.82-3.43,1.64-6.85,2.47-10.26c0.81-0.71,2.11-1.6,3.85-2.38
+			c2.07-0.93,4.75-1.59,7.5-0.81c6.22,1.76,10.75,12.7,8.1,18.86C325.59,196.8,324.76,199.36,323.1,204.48z"/>
+	</g>
+	<g id="bogy">
+		<path class="st7" d="M355.47,308.84l2.02,9.83c-15.2-0.96-32.22-1.24-50.75-0.26c-17.14,0.91-32.86,2.76-46.96,5.05
+			c2.02-19.69,4.04-39.38,6.06-59.07c-2.63-0.34-6.05-1.04-9.84-2.52c-3.84-1.5-6.86-3.33-9.04-4.87
+			c5.27-6.99,9.99-13.15,14.01-18.33c0.54-0.7,1.07-1.38,1.59-2.05c6.18-7.93,9.16-11.62,13.47-16.08
+			c4.31-4.47,8.18-7.88,10.92-10.17c4.92,2.89,14.25,7.49,26.81,8.4c9.18,0.67,16.72-0.87,21.62-2.3c0.78,1.17,1.9,2.91,3.18,5.06
+			c2.41,4.05,6.16,10.91,11.65,25.97c2.12,5.81,4.69,13.37,7.28,22.39c-3.07,1.37-6.13,2.73-9.2,4.1L355.47,308.84z"/>
+		<path class="st8" d="M357.49,318.67c-15.2-0.96-32.22-1.24-50.75-0.26c-17.14,0.91-32.86,2.76-46.96,5.05
+			c2.02-19.69,4.04-39.38,6.06-59.07c-2.63-0.34-6.05-1.04-9.84-2.52c-3.84-1.5-6.86-3.33-9.04-4.87
+			c5.27-6.99,9.99-13.15,14.01-18.33c9.36,19.94,28.77,50.5,64.38,63.87c10.7,4.02,20.98,5.77,30.12,6.3L357.49,318.67z"/>
+	</g>
+	<g id="head_1_">
+		<path class="st2" d="M330.16,143.43c-0.24,0.68-2.87,8.53,2.22,15.51c4.73,6.49,12.21,6.84,13.1,6.86
+			c-0.43,3.81-0.58,8.87,0.41,14.68c0.6,3.5,1.49,6.56,2.41,9.1c-1.74,2.56-5.03,6.67-10.44,9.84c-2.59,1.51-11.74,6.87-20.09,3.8
+			c-8.44-3.1-14.09-14.07-12.79-26.75c-1.16-0.1-2.64-0.42-3.95-1.41c-5.66-4.28-3.45-17.54,0.3-18.57
+			c1.21-0.33,3.17,0.45,6.46,4.95c2.7-0.5,7.12-1.68,11.65-4.8C326.04,152.1,329.02,146.11,330.16,143.43z"/>
+		
+			<ellipse transform="matrix(0.6041 -0.7969 0.7969 0.6041 -18.3509 322.4485)" class="st9" cx="315.35" cy="179.69" rx="4.31" ry="7.15"/>
+		
+			<ellipse transform="matrix(0.6041 -0.7969 0.7969 0.6041 -22.1304 342.3657)" class="st9" cx="333.5" cy="193.46" rx="3.51" ry="5.83"/>
+	</g>
+</g>
+<g id="face1">
+	<path class="st9" d="M322.22,193.34L322.22,193.34c-1.11-0.84-1.33-2.42-0.49-3.53l1.69-2.23c0.84-1.11,2.42-1.33,3.53-0.49l0,0
+		c1.11,0.84,1.33,2.42,0.49,3.53l-1.69,2.23C324.91,193.96,323.33,194.18,322.22,193.34z"/>
+	<path class="st10" d="M317.49,191.22c0,0.34,0.09,3.46,2.75,5.39c2.33,1.69,4.89,1.2,5.31,1.12"/>
+	<circle class="st0" cx="322.47" cy="173.47" r="2.26"/>
+	<circle class="st0" cx="336.08" cy="183.84" r="2.26"/>
+	<path class="st11" d="M317.44,168.25c0.41-0.27,4.34-2.8,8.69-1.12c2.58,1,3.95,2.95,4.44,3.73"/>
+	<path class="st11" d="M337.74,176.06c2.24,0.43,4.07,1.93,4.73,3.95c0.63,1.92-0.02,3.6-0.23,4.09"/>
+</g>
+<g id="coloured_things">
+	<g id="coffee_1_">
+		<g>
+			<path class="st3" d="M509.16,158.85c-0.84-1.66,0.1-4,1.28-5.34c2.78-3.15,7.97-1.95,8.37-1.85c4.42,1.09,7.04,5,8.6,7.32
+				c2.66,3.98,1.95,5.41,3.71,6.38c3.84,2.11,7.98-4.3,14.85-3.84c5.26,0.35,11.57,4.69,11.64,9.97c0.07,5.01-5.51,9-10.09,9.93
+				c-0.47,0.09-5.4,1.03-9.66-1.72c-3.46-2.24-3.85-5.21-6.68-5.51c-2.46-0.26-3.08,1.89-5.56,1.67c-2.9-0.26-4.92-3.46-6.81-6.45
+				c-2.82-4.46-2.15-6.09-4.57-7.81C511.91,159.95,510.02,160.54,509.16,158.85z"/>
+			<path class="st3" d="M531.4,145.01c1.03-0.4,1.57,0.73,4.44,1.08c1.6,0.2,2.2-0.05,3.01,0.51c0.86,0.6,1.55,1.82,1.25,2.88
+				c-0.11,0.37-0.43,1.07-2.28,1.83c-1.83,0.75-5.72,2.35-7.5,0.29C528.67,149.7,529.71,145.67,531.4,145.01z"/>
+			<path class="st3" d="M554.58,146.93c5.46,1.4,4.38,7.23,0.42,5.98C551.03,151.66,549.99,145.75,554.58,146.93z"/>
+		</g>
+		<g>
+			<path class="st3" d="M511.47,181.07c0,0,6.48,5.91,5.69,10.49c-0.79,4.59-5.91,10.5-11.86,9.8c-5.95-0.69-11.07-4.43-11.07-4.43
+				c1.32-1.53,2.64-3.06,3.95-4.59c3.48,4.02,8.14,5.55,11.4,4.02c0.23-0.11,2.84-1.38,3.25-3.88c0.47-2.9-2.18-6.45-6.89-7.88
+				C507.78,183.43,509.63,182.25,511.47,181.07z"/>
+			<path class="st12" d="M516.51,180.69c-3.3,3.54-6.66,7.28-10.05,11.22c-3.47,4.04-6.73,8.01-9.79,11.9
+				c-2.71-0.39-7.07-1.35-11.75-4.05c-5-2.88-8.14-6.44-9.83-8.67c0.19-0.42,0.38-0.83,0.56-1.25c4.77-10.5,9.52-21,14.28-31.5
+				c1.76-0.04,11.76-0.13,19.45,7.71c4.91,4.99,6.45,10.71,6.96,13.63C516.42,180.07,516.47,180.41,516.51,180.69z"/>
+			<path class="st3" d="M516.51,180.69c-6.61,7.7-13.23,15.41-19.84,23.12c-2.71-0.39-7.07-1.35-11.75-4.05
+				c-5-2.88-8.14-6.44-9.83-8.67c0.19-0.42,0.38-0.83,0.56-1.25c3.86,0.98,9.94,1.99,17.22,0.94c12.11-1.75,20.18-8.15,23.47-11.1
+				C516.4,180.02,516.45,180.36,516.51,180.69z"/>
+		</g>
+	</g>
+	<g id="clock_1_">
+		<g>
+			<path class="st13" d="M496.89,342.25c2.48,1.61,7.4,5.34,9.71,11.83c3.74,10.51-0.72,24.45-10.64,28.85
+				c-4.9,2.18-9.79,1.42-12.36,0.8C488.03,369.9,492.46,356.08,496.89,342.25z"/>
+			<path class="st14" d="M497.88,348.34c1.85,1.4,4.12,3.62,5.41,6.87c4.33,10.94-5.3,26.55-12.7,26.45c-1.24-0.02-2.28-0.47-3-0.9
+				C491.02,369.96,494.45,359.15,497.88,348.34z"/>
+		</g>
+		
+			<ellipse transform="matrix(0.1807 -0.9835 0.9835 0.1807 33.8849 754.4935)" class="st13" cx="469.82" cy="356.91" rx="26.3" ry="19.88"/>
+		<path class="st13" d="M475.02,331.13c2.27,0.35,4.78,0.89,7.46,1.74c6.62,2.1,11.68,5.24,15.18,7.9
+			c1.23,3.1,4.65,12.87,1.35,24.76c-3.04,10.96-10.02,17.33-12.67,19.53c-3.11,0.46-7.39,0.73-12.38,0
+			c-3.47-0.51-6.42-1.39-8.76-2.27C468.48,365.57,471.75,348.35,475.02,331.13z"/>
+		<path class="st13" d="M468.9,332.71c-0.34-0.58-1.88-3.32-0.98-6.61c0.72-2.65,3.03-5.68,6.46-5.9c3.8-0.25,7.22,3.04,7.59,6.75
+			c0.38,3.82-2.64,6.44-2.93,6.68C475.66,333.32,472.28,333.02,468.9,332.71z"/>
+		<path class="st13" d="M484.22,335c-0.12-0.75-0.61-4.26,1.68-7.35c1.84-2.49,5.51-4.72,9.22-3.55c4.1,1.3,6.34,6.16,5.21,10.21
+			c-1.17,4.18-5.42,5.68-5.83,5.82C491.08,338.42,487.65,336.71,484.22,335z"/>
+		<path class="st13" d="M461,377.57c-1.17,0.36-3.72,1.33-5.92,3.79c-1.78,2-2.53,4.07-2.85,5.22c3.16,1.55,6.69,3.07,10.59,4.43
+			c9.02,3.15,17.28,4.51,24.03,5.06c0.5-1.37,1.43-4.52,0.63-8.38c-0.59-2.85-1.86-4.9-2.69-6.02
+			C476.87,380.3,468.93,378.94,461,377.57z"/>
+		
+			<ellipse transform="matrix(0.1807 -0.9835 0.9835 0.1807 33.8849 754.4935)" class="st14" cx="469.82" cy="356.91" rx="22.87" ry="17.28"/>
+		
+			<rect x="466.65" y="356" transform="matrix(0.9835 0.1807 -0.1807 0.9835 73.3678 -78.452)" class="st3" width="1.17" height="14.85"/>
+		
+			<rect x="464.35" y="346.61" transform="matrix(0.7071 -0.7071 0.7071 0.7071 -113.0681 432.0005)" class="st3" width="1.17" height="11.75"/>
+		<circle class="st3" cx="468.39" cy="356.6" r="2.35"/>
+		<circle class="st3" cx="472.26" cy="339.17" r="2"/>
+		<circle class="st3" cx="464.36" cy="375.57" r="2"/>
+		<circle class="st3" cx="482.09" cy="359.93" r="2"/>
+		<circle class="st3" cx="456.66" cy="354.25" r="2"/>
+	</g>
+	<g id="pens_1_">
+		<g>
+			<path class="st15" d="M528.94,470.33L528.94,470.33c-2.6-1.79-3.27-5.34-1.48-7.95l19.98-29.15c1.79-2.6,5.34-3.27,7.95-1.48l0,0
+				c2.6,1.79,3.27,5.34,1.48,7.95l-19.98,29.15C535.11,471.45,531.55,472.12,528.94,470.33z"/>
+			<path class="st15" d="M526.58,464.44c-0.07,0.41-4.1,14.02-4.1,14.02l12.82-8.05L526.58,464.44z"/>
+			<polygon class="st7" points="526.78,463.74 525.91,466.82 532.96,471.87 535.3,470.41 			"/>
+		</g>
+		<path class="st16" d="M564.54,474.43c-0.11-0.11-0.24-0.19-0.37-0.26c-0.09-0.15-0.18-0.29-0.31-0.41l-0.88-0.88
+			c-0.09-0.09-0.18-0.16-0.28-0.23l2.81-2.81c0.61-0.61,0.61-1.61,0-2.23l-1.54-1.54c-0.61-0.61-1.61-0.61-2.23,0l-36.47,36.47
+			c-0.3,0.3-0.45,0.69-0.46,1.08l-6.48,9.62l10.16-6.58c0.2-0.08,0.38-0.19,0.54-0.35l30.83-30.83c0.07,0.1,0.14,0.19,0.23,0.28
+			l0.44,0.44l-10.57,10.57c-0.61,0.61-0.61,1.61,0,2.23c0.61,0.61,1.61,0.61,2.23,0l12.33-12.33
+			C565.16,476.04,565.16,475.05,564.54,474.43z"/>
+	</g>
+	<g id="food_1_">
+		<path class="st17" d="M100.16,494.03c0,0,3.44,14.2,8.59,15.92c5.15,1.72,20.96-2.23,27.66-8.94c6.7-6.7,6.36-8.25,9.62-11.17
+			c3.26-2.92,5.15-7.9,3.61-10.14s-18.21-2.23-18.21-2.23L100.16,494.03z"/>
+		<path class="st18" d="M92.6,491.06c2.06,1.37-0.52,13.54,3.61,13.21c4.12-0.33,6.19-4.11,9.11-3.25c2.92,0.86,5.33,7.56,8.94,4.81
+			s2.41-6.19,6.36-6.19c3.95,0,8.08-1.77,10.48-5.61c2.41-3.84,4.12-0.92,7.04-2.98s2.12-4.64,4.58-5.67
+			c2.46-1.03,8.13-2.75,5.21-6.01s-4.81-3.21-3.95-6.59c0.86-3.38,0.69-4.92-3.26-4.92c-3.95,0-0.52-5.5-4.3-5.84
+			c-3.78-0.34-0.69-1.08-8.94,1.44S92.6,491.06,92.6,491.06z"/>
+		<path class="st17" d="M142.71,478.84c0,0-23.73,16.32-28,18.54c-4.26,2.23-16.13,0.56-19.65,0c-1.27-0.2-2.56-1.02-3.66-2.17
+			c-1.96-2.04-3.31-5.11-2.83-7.48c0.74-3.7,10.94-13.53,14.09-17.42c3.15-3.9,17.99-13.46,24.66-13.13
+			c6.68,0.33,7.05,1.26,7.05,1.26s-5.56,4.27-2.41,5.01c3.15,0.74,5.38,1.61,5.38,1.61s-6.16,7.33-3.18,9.35
+			c0.3,0.2,0.63,0.41,0.98,0.62C138.22,476.89,142.71,478.84,142.71,478.84z"/>
+	</g>
+	<g id="toothbrush">
+		<g>
+			<path class="st19" d="M163.12,178.35c-0.82,0.56-3.03,2.5-4.14,2.64c-0.95,0.12-4.23-2.7-5.77-3.43
+				c-0.26-0.14-0.47-0.2-0.61-0.18c-0.97,0.14-3.46,1.11-4.99,0.7c-0.43-0.12-2.04-1.6-4.14-3.7c-0.85-0.84-1.76-1.78-2.71-2.77
+				c-5.16-5.38-11.3-12.29-11.3-13.22c0-1.52,0.13-2.63,0.13-2.63s-2.21,1.66-5.68-1.52c-3.46-3.19-9.56-9.84-9.84-11.37
+				c-0.28-1.52,0-4.3,4.44-6.51c4.43-2.22,18.43-10.81,20.79-10.4c2.35,0.42,3.32,3.19,2.21,4.71c-0.23,0.32-0.45,0.61-0.65,0.89
+				c-0.76,1.05-1.29,1.75-1.29,1.75l0.3,0.57l4.83,9.27c0,0,3.74,0.55,4.44,3.6c0.69,3.05,0,5.41,0,5.41s3.68,4.03,7.25,8.13
+				c0.99,1.13,1.96,2.26,2.84,3.31c2.02,2.41,3.59,4.41,3.77,5.05c0.55,1.94-0.97,4.3-0.97,4.3S163.93,177.8,163.12,178.35z"/>
+			
+				<ellipse transform="matrix(0.8213 -0.5705 0.5705 0.8213 -61.7434 106.9526)" class="st14" cx="139.85" cy="152.03" rx="6.43" ry="8.75"/>
+			<path class="st14" d="M159.23,163.6c-2.33,0.72-5.14,1.88-8.05,3.76c-3.45,2.24-5.96,4.81-7.71,7.02
+				c-0.85-0.84-1.76-1.78-2.71-2.77c1.62-2.24,4.1-5.04,7.72-7.49c2.86-1.93,5.64-3.11,7.91-3.83
+				C157.38,161.42,158.35,162.55,159.23,163.6z"/>
+			<path class="st20" d="M139.57,133.31l0.3,0.57c-2.37,0.87-4.84,1.86-7.38,2.98c-4.8,2.1-9.08,4.34-12.83,6.53v-1.84
+				c3.22-2.24,7.35-4.71,12.37-6.87c3.15-1.36,6.13-2.37,8.83-3.12C140.1,132.61,139.57,133.31,139.57,133.31z"/>
+			<path class="st20" d="M163.12,178.35c-0.82,0.56-3.03,2.5-4.14,2.64c-0.95,0.12-4.23-2.7-5.77-3.43v-0.01
+				c0.32-0.65,1.47-2.74,4.02-3.92c2.11-0.98,4.03-0.8,4.8-0.68C162.03,172.95,163.93,177.8,163.12,178.35z"/>
+		</g>
+		<g>
+			<path class="st19" d="M135.03,190.99l-69.12-23.47c-1.29-0.44-1.97-1.83-1.54-3.12l0,0c0.44-1.29,1.83-1.97,3.12-1.54
+				l69.12,23.47c1.29,0.44,1.97,1.83,1.54,3.12l0,0C137.71,190.74,136.32,191.43,135.03,190.99z"/>
+			<path class="st19" d="M74.26,177.91l-9.52-3.23c-1.9-0.65-2.92-2.71-2.28-4.62l2.07-6.08l16.42,5.58l-2.07,6.08
+				C78.23,177.54,76.16,178.55,74.26,177.91z"/>
+			<path class="st14" d="M73.54,176.44l-7.33-2.49c-1.68-0.57-2.58-2.4-2.01-4.08v0c0.75-2.21,2.95-3.6,5.26-3.3
+				c1.05,0.13,2.2,0.38,3.42,0.83c0.98,0.36,1.85,0.78,2.61,1.23c2,1.17,2.88,3.61,2.13,5.81l0,0
+				C77.05,176.11,75.22,177.01,73.54,176.44z"/>
+		</g>
+	</g>
+	<g id="documents_1_">
+		<g>
+			<path class="st21" d="M199.58,360.1c-0.06,1.37-0.14,2.73-0.23,4.07c-8.58-0.37-17.16-0.74-25.73-1.1l-8.89-57.74
+				c3.13,0.51,6.47,1.16,10,1.99c2.14,0.5,4.35,1.07,6.61,1.71c6.31,1.81,11.94,3.87,16.84,5.95c0.65,5.74,1.16,11.8,1.46,18.17
+				C200.1,342.74,200.01,351.75,199.58,360.1z"/>
+			<path class="st9" d="M199.58,360.1c-0.06,1.37-0.14,2.73-0.23,4.07c-8.58-0.37-17.16-0.74-25.73-1.1l-8.89-57.74
+				c3.13,0.51,6.47,1.16,10,1.99c4.24,12.56,6.94,22.47,8.73,29.84c1.36,5.6,2.87,12.5,8.8,18.09
+				C194.61,357.46,197.16,359.02,199.58,360.1z"/>
+		</g>
+		<g>
+			<path class="st21" d="M154.37,364.17c-2.38-0.29-5.08-0.48-8.05-0.44c-1.94,0.02-3.76,0.13-5.44,0.3
+				c-0.44,0.04-0.88,0.09-1.3,0.14c-6.86-11.43-15.49-24.11-26.32-37.2c-8.15-9.85-16.26-18.39-23.92-25.71
+				c3.64-3.08,8.84-6.82,15.66-9.96c8.09-3.73,15.45-5.23,20.66-5.87c1.21,1.69,2.44,3.49,3.69,5.4
+				c4.36,6.67,8.85,14.66,12.84,23.96C150.44,334.06,153.35,351.59,154.37,364.17z"/>
+			<path class="st9" d="M154.37,364.17c-2.38-0.29-5.08-0.48-8.05-0.44c-1.94,0.02-3.76,0.13-5.44,0.3
+				c-2.29-9.02-5.94-19.93-11.88-31.65c-7.2-14.22-15.44-25.03-22.16-32.62c3.6-1.86,7.68-3.75,12.23-5.5
+				c3.61-1.38,7.05-2.51,10.28-3.43c4.36,6.67,8.85,14.66,12.84,23.96C150.44,334.06,153.35,351.59,154.37,364.17z"/>
+		</g>
+		<g>
+			<path class="st21" d="M58.44,364.17c1.41-7.79,3.72-17.11,7.57-27.28c3.99-10.53,8.63-19.28,12.87-26.19
+				c8.07,4.94,17.82,11.99,27.52,21.9c15.39,15.73,24.13,32,29.03,43.29c-0.56,1.08-1.22,2.23-2.02,3.41
+				c-1.91,2.83-3.98,4.99-5.81,6.6c-12.15-6.89-28.43-14.24-48.48-18.58C71.78,365.73,64.85,364.74,58.44,364.17z"/>
+			<g>
+				<line class="st22" x1="86.96" y1="328.88" x2="76.49" y2="355.34"/>
+				<line class="st22" x1="94.74" y1="334.55" x2="85.21" y2="358.67"/>
+				<line class="st22" x1="100.2" y1="338.85" x2="91.34" y2="361.31"/>
+				<line class="st22" x1="105.56" y1="342.5" x2="97.33" y2="363.37"/>
+				<line class="st22" x1="109.82" y1="346.25" x2="102.13" y2="365.79"/>
+			</g>
+		</g>
+		<g>
+			<path class="st21" d="M111.3,301.26c6.38,7.73,13.24,17.15,19.79,28.33c8.89,15.17,14.76,29.43,18.7,41.32
+				c4.73-1.7,11.34-3.49,19.36-3.91c5.46-0.29,10.26,0.13,14.14,0.75c-1.01-13.59-3.46-30.05-8.92-48.16
+				c-3.19-10.6-6.9-20.04-10.66-28.27c-5.78-0.73-13.22-1.08-21.75,0C128.41,293.03,117.93,297.65,111.3,301.26z"/>
+			<g>
+				<path class="st22" d="M131.12,310.51c4.5-1.79,10.04-3.51,16.52-4.57c5.08-0.83,9.75-1.1,13.84-1.06"/>
+				<path class="st22" d="M135.74,320.9c4.3-1.63,9.59-3.2,15.76-4.18c4.83-0.77,9.26-1.02,13.14-1"/>
+				<path class="st22" d="M141.03,330.23c4.13-1.49,9.19-2.93,15.07-3.84c4.61-0.71,8.82-0.95,12.51-0.94"/>
+				<path class="st22" d="M144.2,338.82c3.96-1.37,8.81-2.7,14.42-3.54c4.4-0.66,8.42-0.89,11.94-0.89"/>
+				<path class="st22" d="M147.4,346.65c3.8-1.27,8.45-2.5,13.83-3.28c4.21-0.61,8.05-0.84,11.41-0.85"/>
+			</g>
+		</g>
+	</g>
+</g>
+<g id="green1">
+	<path class="st23" d="M340.57,57.3L340.57,57.3v-1.96c0-2.64-2.14-4.78-4.78-4.78h-47.74c-2.64,0-4.78,2.14-4.78,4.78v16.4
+		c0,2.64,2.14,4.78,4.78,4.78h47.74c2.64,0,4.78-2.14,4.78-4.78v-1.97l0,0c3.41,0,6.18-2.77,6.18-6.18v-0.11
+		C346.75,60.07,343.99,57.3,340.57,57.3z"/>
+	<path class="st24" d="M295.5,72.63h-3.66c-1.58,0-2.86-1.28-2.86-2.86V57.76c0-1.58,1.28-2.86,2.86-2.86h3.66
+		c1.58,0,2.86,1.28,2.86,2.86v12.01C298.35,71.35,297.08,72.63,295.5,72.63z"/>
+	<path class="st24" d="M331.96,72.63h-3.66c-1.58,0-2.86-1.28-2.86-2.86V57.76c0-1.58,1.28-2.86,2.86-2.86h3.66
+		c1.58,0,2.86,1.28,2.86,2.86v12.01C334.81,71.35,333.53,72.63,331.96,72.63z"/>
+	<path class="st24" d="M319.99,72.63h-3.66c-1.58,0-2.86-1.28-2.86-2.86V57.76c0-1.58,1.28-2.86,2.86-2.86h3.66
+		c1.58,0,2.86,1.28,2.86,2.86v12.01C322.85,71.35,321.57,72.63,319.99,72.63z"/>
+	<path class="st24" d="M307.75,72.63h-3.66c-1.58,0-2.86-1.28-2.86-2.86V57.76c0-1.58,1.28-2.86,2.86-2.86h3.66
+		c1.58,0,2.86,1.28,2.86,2.86v12.01C310.6,71.35,309.32,72.63,307.75,72.63z"/>
+</g>
+</svg>

From e2c9b9c885c486f5b1c54776a21b5a50845f0945 Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Tue, 1 Aug 2023 10:25:03 -0700
Subject: [PATCH 458/749] Rename card file

---
 ...taining-balance-for-open-source-maintainers.png} | Bin
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename assets/images/cards/{maintaining-balance.png => maintaining-balance-for-open-source-maintainers.png} (100%)

diff --git a/assets/images/cards/maintaining-balance.png b/assets/images/cards/maintaining-balance-for-open-source-maintainers.png
similarity index 100%
rename from assets/images/cards/maintaining-balance.png
rename to assets/images/cards/maintaining-balance-for-open-source-maintainers.png

From 10b138e5cbc086aed23efd55807090d30a71d07e Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Tue, 1 Aug 2023 11:37:32 -0700
Subject: [PATCH 459/749] Promote to first article temporarily

---
 _articles/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
index 0f474b15a16..5d319ce6978 100644
--- a/_articles/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -3,7 +3,7 @@ lang: en
 title: Maintaining Balance for Open Source Maintainers
 description: Tips for self-care and avoiding burnout as a maintainer.
 class: balance
-order: 15
+order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 

From 318f51f732c1a0b94165e59fec2235b1a6c31173 Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Tue, 1 Aug 2023 11:53:08 -0700
Subject: [PATCH 460/749] Avoid postrophe catastrophe

---
 ...ing-balance-for-open-source-maintainers.md | 29 ++++++++++---------
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
index 5d319ce6978..3e9f75e1581 100644
--- a/_articles/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -2,7 +2,8 @@
 lang: en
 title: Maintaining Balance for Open Source Maintainers
 description: Tips for self-care and avoiding burnout as a maintainer.
-class: balance
+class: b
+alance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
@@ -32,7 +33,7 @@ Take time to reflect on what parts of open source maintenance energizes you. Und
 
 ### Reflect on what causes you to get out of balance and stressed out
 
-It’s important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
 
 * **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
 
@@ -44,7 +45,7 @@ It’s important to understand what causes us to get burned out. Here are a few
   </p>
 </aside>
 
-* **Not saying ‘no’:** It can be easy to take on more responsibilities than you should on an open source project. Whether it’s from users, contributors, or other maintainers – we can’t always live up to their expectations.
+* **Not saying ‘no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
@@ -58,7 +59,7 @@ It’s important to understand what causes us to get burned out. Here are a few
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
- Especially since COVID and working from home it’s harder to never see anybody or talk to anybody.
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
   </p>
@@ -73,10 +74,10 @@ It’s important to understand what causes us to get burned out. Here are a few
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you’re paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
 
 <aside markdown="1" class="pquote">
-  With paid open source, conflict between employer’s focus and what’s best for the community
+  With paid open source, conflict between employer's focus and what's best for the community
   <p markdown="1" class="pquote-credit">
 — open source maintainer
   </p>
@@ -86,10 +87,10 @@ It’s important to understand what causes us to get burned out. Here are a few
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla’s [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
- I’m a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
   <p markdown="1" class="pquote-credit">
 — open source maintainer
   </p>
@@ -103,7 +104,7 @@ This will look different for each maintainer, and will change depending on your
 
   You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
 
-* **Explore funding:** Whether you’re looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you’re thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
@@ -122,19 +123,19 @@ This will look different for each maintainer, and will change depending on your
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night’s sleep can make a big difference in your ability to sustain your efforts long-term.
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
 
   If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I’m finding more opportunity to sprinkle ‘moments of creativity’ in the middle of the day rather than trying to switch off in evening.
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
   </p>
 </aside>
 
-* **Set boundaries:** You can’t say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
@@ -144,7 +145,7 @@ To meaningfully trust others on these axes, you cannot be someone who says yes t
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It’s okay to not give energy to things you don’t care about.
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
@@ -176,7 +177,7 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
-* Workshop agenda was remixed from [Mozilla’s Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
 
 ## Contributors
 

From 6202688a0dbf5b68c039631929f943bfe744843e Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Tue, 1 Aug 2023 11:54:57 -0700
Subject: [PATCH 461/749] :punch: empty line

---
 _articles/maintaining-balance-for-open-source-maintainers.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
index 3e9f75e1581..82457fb2c0b 100644
--- a/_articles/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -45,7 +45,7 @@ It's important to understand what causes us to get burned out. Here are a few co
   </p>
 </aside>
 
-* **Not saying ‘no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
@@ -155,7 +155,6 @@ My software is gratis, but my time and attention is not.
   </p>
 </aside>
 
-
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
 It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  

From ffc4e3de6a4bb5ac6a18ac6117765d73d5bccd4e Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Tue, 1 Aug 2023 11:59:42 -0700
Subject: [PATCH 462/749] Fix YAML

---
 _articles/maintaining-balance-for-open-source-maintainers.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
index 82457fb2c0b..2144117ed67 100644
--- a/_articles/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -2,8 +2,7 @@
 lang: en
 title: Maintaining Balance for Open Source Maintainers
 description: Tips for self-care and avoiding burnout as a maintainer.
-class: b
-alance
+class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---

From d454eb1e28811ddad516f2c4c64d2001511efee8 Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Tue, 1 Aug 2023 12:00:57 -0700
Subject: [PATCH 463/749] Remove empty line

---
 _articles/maintaining-balance-for-open-source-maintainers.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
index 2144117ed67..fd21f6424ea 100644
--- a/_articles/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -13,7 +13,6 @@ To gain insights into the experiences of maintainers and their strategies for fi
 
 So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
 
-
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
   I was unable to focus or start on a task. I had a lack of empathy for users.

From aa8448ba03dd29708c06ee09312f7b4c45798fd7 Mon Sep 17 00:00:00 2001
From: Abby Cabunoc Mayes <abbycabs@github.com>
Date: Wed, 2 Aug 2023 10:21:57 -0400
Subject: [PATCH 464/749] Update
 _articles/maintaining-balance-for-open-source-maintainers.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Ulises Gascón <UlisesGascon@users.noreply.github.com>
---
 _articles/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
index fd21f6424ea..04bb1902864 100644
--- a/_articles/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -149,7 +149,7 @@ To meaningfully trust others on these axes, you cannot be someone who says yes t
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
 My software is gratis, but my time and attention is not.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, , maintainer of Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
   </p>
 </aside>
 

From 4634fbda4c35f707a0f9d1619e3eb8760a344221 Mon Sep 17 00:00:00 2001
From: Abby Cabunoc Mayes <abbycabs@github.com>
Date: Wed, 2 Aug 2023 10:22:59 -0400
Subject: [PATCH 465/749] Update
 _articles/maintaining-balance-for-open-source-maintainers.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Ulises Gascón <UlisesGascon@users.noreply.github.com>
---
 _articles/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
index 04bb1902864..b85a2d86311 100644
--- a/_articles/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -157,7 +157,7 @@ My software is gratis, but my time and attention is not.
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
 It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, ,maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
 </aside>
 

From f66aa42e319952edb41815f431e02ac147675c5c Mon Sep 17 00:00:00 2001
From: Eshal <eshalali68@gmail.com>
Date: Fri, 4 Aug 2023 16:53:53 +0500
Subject: [PATCH 466/749] Added a scroll to top button

---
 _includes/footer.html  |  1 +
 assets/css/button.scss | 14 ++++++++++++++
 assets/css/index.scss  |  2 +-
 assets/js/button.js    | 14 ++++++++++++++
 assets/js/index.js     |  1 +
 5 files changed, 31 insertions(+), 1 deletion(-)
 create mode 100644 assets/css/button.scss
 create mode 100644 assets/js/button.js

diff --git a/_includes/footer.html b/_includes/footer.html
index 4e7e19b9c67..b1c32580d58 100644
--- a/_includes/footer.html
+++ b/_includes/footer.html
@@ -1,4 +1,5 @@
 {% assign t = site.data.locales[page.lang][page.lang] %}
+<button id="scrollToTopButton" title="Go to top">Top</button>
 <footer class="bg-white border-top text-center pt-5">
   <div class="container-lg p-responsive mx-auto">
 
diff --git a/assets/css/button.scss b/assets/css/button.scss
new file mode 100644
index 00000000000..bbb5785c531
--- /dev/null
+++ b/assets/css/button.scss
@@ -0,0 +1,14 @@
+#scrollToTopButton {
+    display: none;
+    position: fixed;
+    bottom: 20px;
+    right: 20px;
+    z-index: 99;
+    font-size: 16px;
+    background-color: #333;
+    color: #fff;
+    border: none;
+    cursor: pointer;
+    padding: 10px;
+    border-radius: 4px;
+  }
\ No newline at end of file
diff --git a/assets/css/index.scss b/assets/css/index.scss
index d9dce386b70..bdd5da214f7 100644
--- a/assets/css/index.scss
+++ b/assets/css/index.scss
@@ -10,4 +10,4 @@ $marketing-font-path: "/assets/fonts/";
 @import "custom.scss";
 @import "covers.scss";
 @import "anchor.scss";
-
+@import "button.scss";
diff --git a/assets/js/button.js b/assets/js/button.js
new file mode 100644
index 00000000000..9456e097dc7
--- /dev/null
+++ b/assets/js/button.js
@@ -0,0 +1,14 @@
+
+window.addEventListener('scroll', function () {
+    var scrollToTopButton = document.getElementById('scrollToTopButton');
+    if (window.scrollY > 300) {
+        scrollToTopButton.style.display = 'block';
+    } else {
+        scrollToTopButton.style.display = 'none';
+    }
+});
+
+document.getElementById('scrollToTopButton').addEventListener('click', function () {
+    window.scrollTo({ top: 0, behavior: 'smooth' });
+});
+
diff --git a/assets/js/index.js b/assets/js/index.js
index 63fa0fcdddf..0bb3c055fec 100644
--- a/assets/js/index.js
+++ b/assets/js/index.js
@@ -5,6 +5,7 @@
 {% include_relative anchor.min.js %}
 {% include_relative toc.js %}
 {% include_relative locale.js %}
+{% include_relative button.js %}
 
 (function() {
   var selector = '.article-body h2, .article-body h3, .article-body h4, .article-body h5';

From dc563f2cd7080de03c2c6a3ad21f10edd94d465c Mon Sep 17 00:00:00 2001
From: Eshal <eshalali68@gmail.com>
Date: Fri, 4 Aug 2023 17:50:41 +0500
Subject: [PATCH 467/749] Added Scroll to top button

---
 _includes/footer.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_includes/footer.html b/_includes/footer.html
index b1c32580d58..6680765bf2e 100644
--- a/_includes/footer.html
+++ b/_includes/footer.html
@@ -1,5 +1,5 @@
 {% assign t = site.data.locales[page.lang][page.lang] %}
-<button id="scrollToTopButton" title="Go to top">Top</button>
+<button id="scrollToTopButton" title="Go to top">Scroll to Top</button>
 <footer class="bg-white border-top text-center pt-5">
   <div class="container-lg p-responsive mx-auto">
 

From 6fc6f1ab0d1681401c127fd15c1fbc7d9bbfd091 Mon Sep 17 00:00:00 2001
From: Zack Koppert <zkoppert@github.com>
Date: Mon, 7 Aug 2023 13:47:22 -0700
Subject: [PATCH 468/749] Enable Ruby dependabot updates

---
 .github/dependabot.yml | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index 8dc181fec96..7614cdd021b 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -16,4 +16,9 @@ updates:
      interval: daily
     open-pull-requests-limit: 99
     rebase-strategy: disabled
-  
+  - package-ecosystem: bundler
+    directory: "/"
+    schedule:
+      interval: daily
+    versioning-strategy: increase
+    open-pull-requests-limit: 99

From 41e8d3bad0ebf58aa5a14a7f341aa59870d08572 Mon Sep 17 00:00:00 2001
From: Zack Koppert <zkoppert@github.com>
Date: Mon, 7 Aug 2023 21:58:14 +0000
Subject: [PATCH 469/749] update package registry

Signed-off-by: GitHub <noreply@github.com>
---
 package-lock.json | 242 +++++++++++++++++++++-------------------------
 1 file changed, 112 insertions(+), 130 deletions(-)

diff --git a/package-lock.json b/package-lock.json
index fc78d3498f0..9d7c0ad7e94 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -1,73 +1,73 @@
 {
   "name": "open-source-guide",
+  "lockfileVersion": 3,
   "requires": true,
-  "lockfileVersion": 1,
-  "dependencies": {
-    "primer-base": {
+  "packages": {
+    "": {
+      "name": "open-source-guide",
+      "hasInstallScript": true,
+      "dependencies": {
+        "primer-core": "7.0.0",
+        "primer-marketing": "7.0.0"
+      }
+    },
+    "node_modules/primer-base": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/primer-base/-/primer-base-2.0.0.tgz",
       "integrity": "sha512-qqE3MiI1Zr7HgTO7NxguYHw4QrkRGOQjMPck1bFEZhNL36ey5PWJwqB68X7w6frOjA8tRid2joL99GBQhc1NnQ==",
-      "requires": {
-        "primer-support": "5.0.0"
-      },
       "dependencies": {
-        "primer-support": {
-          "version": "5.0.0",
-          "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
-          "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
-        }
+        "primer-support": "5.0.0"
       }
     },
-    "primer-box": {
+    "node_modules/primer-base/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-box": {
       "version": "3.0.0",
       "resolved": "https://registry.npmjs.org/primer-box/-/primer-box-3.0.0.tgz",
       "integrity": "sha512-P6gUxgcC5Se2nPx4erHmj6JhqgBMxJDeJyuz5OS+SArWR0cydxi86Cf7mH4eNC+PebJQ91K+ddcxkU6w3vOEqw==",
-      "requires": {
-        "primer-support": "5.0.0"
-      },
       "dependencies": {
-        "primer-support": {
-          "version": "5.0.0",
-          "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
-          "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
-        }
+        "primer-support": "5.0.0"
       }
     },
-    "primer-breadcrumb": {
+    "node_modules/primer-box/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-breadcrumb": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/primer-breadcrumb/-/primer-breadcrumb-2.0.0.tgz",
       "integrity": "sha512-IhIQZ8HXZNnMh53qzl7JKDrUEAH4jPiqQ4WfxNrFwSoYUrQ7eGN3SJ9LD9oIjtmmO9DUUJhvmR0Cbr9OM1VB8w==",
-      "requires": {
-        "primer-support": "5.0.0"
-      },
       "dependencies": {
-        "primer-support": {
-          "version": "5.0.0",
-          "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
-          "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
-        }
+        "primer-support": "5.0.0"
       }
     },
-    "primer-buttons": {
+    "node_modules/primer-breadcrumb/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-buttons": {
       "version": "3.0.0",
       "resolved": "https://registry.npmjs.org/primer-buttons/-/primer-buttons-3.0.0.tgz",
       "integrity": "sha512-oQX3FOCRrnSrhPFef5AvLkBV9og7W/U0GYPvu1FbXV+CDVauO8pC5hntQqvwa9w/VCptsJl2qpYSIFCQiH+f1g==",
-      "requires": {
-        "primer-support": "5.0.0"
-      },
       "dependencies": {
-        "primer-support": {
-          "version": "5.0.0",
-          "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
-          "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
-        }
+        "primer-support": "5.0.0"
       }
     },
-    "primer-core": {
+    "node_modules/primer-buttons/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-core": {
       "version": "7.0.0",
       "resolved": "https://registry.npmjs.org/primer-core/-/primer-core-7.0.0.tgz",
       "integrity": "sha512-m7E5IddQpzV2Jtrlk9s513zmM7ZMtZUBDJ9Bckrz+67tPSvY74jqwfvwvkty/hLhQFPlM8p+c0fmmRTcO+vVIA==",
-      "requires": {
+      "dependencies": {
         "primer-base": "2.0.0",
         "primer-box": "3.0.0",
         "primer-breadcrumb": "2.0.0",
@@ -81,50 +81,44 @@
         "primer-tooltips": "2.0.0",
         "primer-truncate": "2.0.0",
         "primer-utilities": "5.0.0"
-      },
-      "dependencies": {
-        "primer-support": {
-          "version": "5.0.0",
-          "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
-          "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
-        }
       }
     },
-    "primer-forms": {
+    "node_modules/primer-core/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-forms": {
       "version": "3.0.0",
       "resolved": "https://registry.npmjs.org/primer-forms/-/primer-forms-3.0.0.tgz",
       "integrity": "sha512-buKBHx1skjLmPgYvpFL5Xr3cbE9lxGkWS/h8lsuwL3ZCx5axHFu8MI+fKL6BY1EInRfbfk56d6Dn4QbC/ctInQ==",
-      "requires": {
-        "primer-support": "5.0.0"
-      },
       "dependencies": {
-        "primer-support": {
-          "version": "5.0.0",
-          "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
-          "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
-        }
+        "primer-support": "5.0.0"
       }
     },
-    "primer-layout": {
+    "node_modules/primer-forms/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-layout": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/primer-layout/-/primer-layout-2.0.0.tgz",
       "integrity": "sha512-lwRq5KDaErF4JecHnBr2h6D4Dqbfv28pFBafIOsPvIuMHDHmxNVqao1LRXC86ficL9V0aynlkmH8q6DqKnVPlw==",
-      "requires": {
-        "primer-support": "5.0.0"
-      },
       "dependencies": {
-        "primer-support": {
-          "version": "5.0.0",
-          "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
-          "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
-        }
+        "primer-support": "5.0.0"
       }
     },
-    "primer-marketing": {
+    "node_modules/primer-layout/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-marketing": {
       "version": "7.0.0",
       "resolved": "https://registry.npmjs.org/primer-marketing/-/primer-marketing-7.0.0.tgz",
       "integrity": "sha512-gLIWiE3pW1rXEEnmfz2eekq4LC27QUeMccrG87EU5qyEnu8LMr59c5LRibc5EJaCsa4708Jd2WxxSXEfD0ieug==",
-      "requires": {
+      "dependencies": {
         "primer-marketing-buttons": "2.0.0",
         "primer-marketing-support": "2.0.0",
         "primer-marketing-type": "2.0.0",
@@ -132,135 +126,123 @@
         "primer-support": "5.0.0"
       }
     },
-    "primer-marketing-buttons": {
+    "node_modules/primer-marketing-buttons": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/primer-marketing-buttons/-/primer-marketing-buttons-2.0.0.tgz",
       "integrity": "sha512-R8DvbvI6QjH9/xG2diqReqHhkMgKbiJ7+xg2VTlQon3H5sAxvUqBiqfqY+ZrZ9K5eyrLP+3Z/cgysKd/xe1U2A==",
-      "requires": {
+      "dependencies": {
         "primer-marketing-support": "2.0.0",
         "primer-support": "5.0.0"
       }
     },
-    "primer-marketing-support": {
+    "node_modules/primer-marketing-support": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/primer-marketing-support/-/primer-marketing-support-2.0.0.tgz",
       "integrity": "sha512-HyYxwDVn9aGVN4wyXiIAzHrAgmoyNlXvZpRXh/UZRlA9EfZMxlCji3KhuMFzQFtYi+nXt7f/cTB5AX9YRnlVZg==",
-      "requires": {
+      "dependencies": {
         "primer-support": "5.0.0"
       }
     },
-    "primer-marketing-type": {
+    "node_modules/primer-marketing-type": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/primer-marketing-type/-/primer-marketing-type-2.0.0.tgz",
       "integrity": "sha512-c+bCjKVulTrRhjAHJ7pcaFYDUYiSecVFXMo6DkA9v5JvZ2cK/m4LySo5Eb2qbQmPBwLx6t/V1TnxD2cgKtdIDA==",
-      "requires": {
+      "dependencies": {
         "primer-marketing-support": "2.0.0",
         "primer-support": "5.0.0"
       }
     },
-    "primer-marketing-utilities": {
+    "node_modules/primer-marketing-utilities": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/primer-marketing-utilities/-/primer-marketing-utilities-2.0.0.tgz",
       "integrity": "sha512-R2Y8uaOy44J9NtBNlLJKUrPKxtxv8svss3vP8YS4RRWISUSQGcjxRFPUX5ra8hqaenWO/NBbmeFVJXDwgrKu1A==",
-      "requires": {
+      "dependencies": {
         "primer-marketing-support": "2.0.0",
         "primer-support": "5.0.0"
       }
     },
-    "primer-navigation": {
+    "node_modules/primer-navigation": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/primer-navigation/-/primer-navigation-2.0.0.tgz",
       "integrity": "sha512-yi45wDOuct/Wxp60hG74kfiNKsTluYmhsNelMBOy5WgTmnqtQy0l3d5NAQz/XdvEdiRrpres3LcPxs8GONO3sQ==",
-      "requires": {
-        "primer-support": "5.0.0"
-      },
       "dependencies": {
-        "primer-support": {
-          "version": "5.0.0",
-          "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
-          "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
-        }
+        "primer-support": "5.0.0"
       }
     },
-    "primer-pagination": {
+    "node_modules/primer-navigation/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-pagination": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/primer-pagination/-/primer-pagination-2.0.0.tgz",
       "integrity": "sha512-+1BGHkNJoJtGVkfWi/IUP82MlShSrPJM1my6da1UnfcRBhONfk+7O3DXT7VLscXYk11rYsd/pGKZ8ZPH4DAvsw==",
-      "requires": {
-        "primer-support": "5.0.0"
-      },
       "dependencies": {
-        "primer-support": {
-          "version": "5.0.0",
-          "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
-          "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
-        }
+        "primer-support": "5.0.0"
       }
     },
-    "primer-support": {
+    "node_modules/primer-pagination/node_modules/primer-support": {
       "version": "5.0.0",
       "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
       "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
     },
-    "primer-table-object": {
+    "node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-table-object": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/primer-table-object/-/primer-table-object-2.0.0.tgz",
       "integrity": "sha512-ajCCvy93AwE8g62wS9Frw6kw1JM+gLCwMrr5N3ZXsu4lN1171782lnHcNBFdVzu0iFYiovH7CfQ0glVRNJVAbg==",
-      "requires": {
-        "primer-support": "5.0.0"
-      },
       "dependencies": {
-        "primer-support": {
-          "version": "5.0.0",
-          "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
-          "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
-        }
+        "primer-support": "5.0.0"
       }
     },
-    "primer-tooltips": {
+    "node_modules/primer-table-object/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-tooltips": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/primer-tooltips/-/primer-tooltips-2.0.0.tgz",
       "integrity": "sha512-cNF3r3hG6sXLr71GbYyJw3BXCBhspW4FjzJ0Hx/BO+lP3XCrNAX/wqd57+vvnWSuaLif2O8s3/Prs3VBF50hVQ==",
-      "requires": {
-        "primer-support": "5.0.0"
-      },
       "dependencies": {
-        "primer-support": {
-          "version": "5.0.0",
-          "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
-          "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
-        }
+        "primer-support": "5.0.0"
       }
     },
-    "primer-truncate": {
+    "node_modules/primer-tooltips/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-truncate": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/primer-truncate/-/primer-truncate-2.0.0.tgz",
       "integrity": "sha512-/rmXZCR/wQpOyQsp/vSY8sO/9IczidcFRN0iUg4oCUXgufNuh8IRHetYOGXwnlMiO5c9EkbNFJi/6jkFmRBd4g==",
-      "requires": {
-        "primer-support": "5.0.0"
-      },
       "dependencies": {
-        "primer-support": {
-          "version": "5.0.0",
-          "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
-          "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
-        }
+        "primer-support": "5.0.0"
       }
     },
-    "primer-utilities": {
+    "node_modules/primer-truncate/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-utilities": {
       "version": "5.0.0",
       "resolved": "https://registry.npmjs.org/primer-utilities/-/primer-utilities-5.0.0.tgz",
       "integrity": "sha512-HeMffBQLL2ygyPOUMccN43L9A/3HYsbDhs423Sr3Run1eW1ZvfTgCP3xh9P8Dh/dJt5qHFkekzBc4Y8qsZ3UtA==",
-      "requires": {
-        "primer-support": "5.0.0"
-      },
       "dependencies": {
-        "primer-support": {
-          "version": "5.0.0",
-          "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
-          "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
-        }
+        "primer-support": "5.0.0"
       }
+    },
+    "node_modules/primer-utilities/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
     }
   }
 }

From acda41b934d5e31ba7495133d76a7879f715bed5 Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Mon, 7 Aug 2023 16:16:24 -0700
Subject: [PATCH 470/749] Update quote

---
 _articles/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
index b85a2d86311..f16ed29b635 100644
--- a/_articles/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -37,7 +37,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
-  I was unable to focus or start on a task. I had a lack of empathy for users.
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
   </p>

From 0e9ff52177244f9617d6fbb3e161c13e7c7405b4 Mon Sep 17 00:00:00 2001
From: Lee Reilly <lee@github.com>
Date: Mon, 7 Aug 2023 16:29:54 -0700
Subject: [PATCH 471/749] Flag article as untranslated

---
 _articles/maintaining-balance-for-open-source-maintainers.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
index f16ed29b635..51d312d3499 100644
--- a/_articles/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -1,5 +1,6 @@
 ---
 lang: en
+untranslated: true
 title: Maintaining Balance for Open Source Maintainers
 description: Tips for self-care and avoiding burnout as a maintainer.
 class: balance

From f669ceba1126d82279094316d5d0b580bf5c48db Mon Sep 17 00:00:00 2001
From: Zack Koppert <zkoppert@github.com>
Date: Tue, 8 Aug 2023 09:21:27 -0700
Subject: [PATCH 472/749] ignore urls returning 403 to automation but work in
 real life

---
 script/html-proofer | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/script/html-proofer b/script/html-proofer
index 96eb51b48e0..e7f838ca3a7 100755
--- a/script/html-proofer
+++ b/script/html-proofer
@@ -8,6 +8,13 @@ url_ignores = [
   "https://www.drupal.org/community-initiatives/drupal-core/usability",
   "https://scripts.sil.org/ofl",
   "https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/",
+  "https://pages.18f.gov/open-source-guide/making-readmes-readable/",
+  "https://github.com/sponsors",
+  "https://github.com/sponsors/community",
+  "https://github.com/travis-ci",
+  "https://github.com/webpack",
+  "https://github.com/stuartlynn/puffin_facts",
+  "https://github.com/tryghost/ghost",
   %r{^https?://twitter\.com/},
   %r{^https?://(www\.)?kickstarter\.com/},
   %r{^https://guides\.github\.com/},

From 7bccb67d5da12111f68c091ac6ec7fc17688a1a4 Mon Sep 17 00:00:00 2001
From: Zack Koppert <zkoppert@github.com>
Date: Tue, 8 Aug 2023 09:38:40 -0700
Subject: [PATCH 473/749] Fix shifting github.com 403s

---
 script/html-proofer | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/script/html-proofer b/script/html-proofer
index e7f838ca3a7..8be2ba2dcc7 100755
--- a/script/html-proofer
+++ b/script/html-proofer
@@ -9,16 +9,11 @@ url_ignores = [
   "https://scripts.sil.org/ofl",
   "https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/",
   "https://pages.18f.gov/open-source-guide/making-readmes-readable/",
-  "https://github.com/sponsors",
-  "https://github.com/sponsors/community",
-  "https://github.com/travis-ci",
-  "https://github.com/webpack",
-  "https://github.com/stuartlynn/puffin_facts",
-  "https://github.com/tryghost/ghost",
   %r{^https?://twitter\.com/},
   %r{^https?://(www\.)?kickstarter\.com/},
   %r{^https://guides\.github\.com/},
   %r{^https://help\.github\.com/},
+  %r{^https://\.github\.com/},
 ]
 
 HTMLProofer::Runner.new(

From c0910928dd734729472ca402dea4a0a7a7710a86 Mon Sep 17 00:00:00 2001
From: Zack Koppert <zkoppert@github.com>
Date: Tue, 8 Aug 2023 10:13:36 -0700
Subject: [PATCH 474/749] Update html-proofer

---
 script/html-proofer | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/script/html-proofer b/script/html-proofer
index 8be2ba2dcc7..45a74b85e26 100755
--- a/script/html-proofer
+++ b/script/html-proofer
@@ -13,7 +13,7 @@ url_ignores = [
   %r{^https?://(www\.)?kickstarter\.com/},
   %r{^https://guides\.github\.com/},
   %r{^https://help\.github\.com/},
-  %r{^https://\.github\.com/},
+  %r{^https://github\.com/},
 ]
 
 HTMLProofer::Runner.new(

From 3b84056d38f76c2846ffdf46d541641e2e7ae7bc Mon Sep 17 00:00:00 2001
From: Zack Koppert <zkoppert@github.com>
Date: Wed, 9 Aug 2023 11:07:15 -0700
Subject: [PATCH 475/749] Deploy via action

---
 .github/workflows/jekyll.yml | 63 ++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)
 create mode 100644 .github/workflows/jekyll.yml

diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
new file mode 100644
index 00000000000..88519758b89
--- /dev/null
+++ b/.github/workflows/jekyll.yml
@@ -0,0 +1,63 @@
+# This workflow uses actions that are not certified by GitHub.
+# They are provided by a third-party and are governed by
+# separate terms of service, privacy policy, and support
+# documentation.
+
+# Sample workflow for building and deploying a Jekyll site to GitHub Pages
+name: Deploy Jekyll site to Pages
+
+on:
+  # Runs on pushes targeting the default branch
+  push:
+    branches: ["main"]
+
+  # Allows you to run this workflow manually from the Actions tab
+  workflow_dispatch:
+
+# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
+# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
+concurrency:
+  group: "pages"
+  cancel-in-progress: false
+
+jobs:
+  # Build job
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+      - name: Setup Ruby
+        uses: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf # v1.146.0
+        with:
+          bundler-cache: true # runs 'bundle install' and caches installed gems automatically
+          cache-version: 0 # Increment this number if you need to re-download cached gems
+      - name: Setup Pages
+        id: pages
+        uses: actions/configure-pages@v3
+      - name: Build with Jekyll
+        # Outputs to the './_site' directory by default
+        run: bundle exec jekyll build --baseurl "${{ steps.pages.outputs.base_path }}"
+        env:
+          JEKYLL_ENV: production
+      - name: Upload artifact
+        # Automatically uploads an artifact from the './_site' directory by default
+        uses: actions/upload-pages-artifact@v2
+
+  # Deployment job
+  deploy:
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v2

From aabf9517b7dfb6f6811590935d243bdc21fdd04b Mon Sep 17 00:00:00 2001
From: "James M. Greene" <JamesMGreene@github.com>
Date: Wed, 9 Aug 2023 13:11:34 -0500
Subject: [PATCH 476/749] Deploy using the GitHub Pages internal Jekyll build
 config

---
 .github/workflows/jekyll.yml | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index 88519758b89..ad9142234c3 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -33,19 +33,13 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@v3
-      - name: Setup Ruby
-        uses: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf # v1.146.0
-        with:
-          bundler-cache: true # runs 'bundle install' and caches installed gems automatically
-          cache-version: 0 # Increment this number if you need to re-download cached gems
       - name: Setup Pages
-        id: pages
         uses: actions/configure-pages@v3
       - name: Build with Jekyll
-        # Outputs to the './_site' directory by default
-        run: bundle exec jekyll build --baseurl "${{ steps.pages.outputs.base_path }}"
-        env:
-          JEKYLL_ENV: production
+        uses: actions/jekyll-build-pages@v1
+        with:
+          source: ./
+          destination: ./_site
       - name: Upload artifact
         # Automatically uploads an artifact from the './_site' directory by default
         uses: actions/upload-pages-artifact@v2

From fa0ac888b2f2f9e7ce9e206e27baf9753b5b895a Mon Sep 17 00:00:00 2001
From: "James M. Greene" <JamesMGreene@github.com>
Date: Wed, 9 Aug 2023 13:29:14 -0500
Subject: [PATCH 477/749] Create jekyll-preview.yml

---
 .github/workflows/jekyll-preview.yml | 68 ++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 .github/workflows/jekyll-preview.yml

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
new file mode 100644
index 00000000000..288147b7d67
--- /dev/null
+++ b/.github/workflows/jekyll-preview.yml
@@ -0,0 +1,68 @@
+# This workflow uses actions that are not certified by GitHub.
+# They are provided by a third-party and are governed by
+# separate terms of service, privacy policy, and support
+# documentation.
+
+# Sample workflow for building and deploying a Jekyll site to GitHub Pages
+name: Deploy Jekyll site to Pages preview environment
+
+on:
+  # Runs on pull requests targeting the default branch
+  pull_request_target:
+    branches: ["main"]
+
+# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+# Allow only one concurrent deployment per PR, skipping runs queued between the run in-progress and latest queued.
+# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
+concurrency:
+  group: 'pages-preview @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}'
+  cancel-in-progress: false
+
+jobs:
+  # Build job
+  build:
+    # Limit permissions of the GITHUB_TOKEN for untrusted code
+    permissions:
+      contents: read
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+        with:
+          # For PRs make sure to checkout the PR branch
+          ref: ${{ github.event.pull_request.head.ref }}
+          repository: ${{ github.event.pull_request.head.repo.full_name }}
+      - name: Setup Pages
+        uses: actions/configure-pages@v3
+      - name: Build with Jekyll
+        uses: actions/jekyll-build-pages@v1
+        with:
+          source: ./
+          destination: ./_site
+      - name: Upload artifact
+        # Automatically uploads an artifact from the './_site' directory by default
+        uses: actions/upload-pages-artifact@v2
+
+  # Deployment job
+  deploy:
+    environment:
+      name: 'Pages Preview'
+      url: ${{ steps.deployment.outputs.page_url }}
+    # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
+    permissions:
+      contents: read
+      pages: write
+      id-token: write
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v2
+        with:
+          preview: 'true'

From ebc5efbabe367e1fa086f53f7ce86d275673f1ef Mon Sep 17 00:00:00 2001
From: Zack Koppert <zkoppert@github.com>
Date: Wed, 9 Aug 2023 11:49:42 -0700
Subject: [PATCH 478/749] Add link to github action for measuring maintainer
 response time

---
 _articles/metrics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/metrics.md b/_articles/metrics.md
index 78c094f878a..145dd18119b 100644
--- a/_articles/metrics.md
+++ b/_articles/metrics.md
@@ -112,7 +112,7 @@ Unresponsive maintainers become a bottleneck for open source projects. If someon
 
 [Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
 
-Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+Consider [tracking how long it takes for you (or another maintainer) to respond to contributions](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
 
 You could also measure the time it takes to move between stages in the contribution process, such as:
 

From 88418b61286a3a6de96c4c25b17f3a8114f86c1b Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Wed, 30 Aug 2023 20:42:55 +0530
Subject: [PATCH 479/749] initial commit hindi

---
 _data/locales/hi.yml | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 _data/locales/hi.yml

diff --git a/_data/locales/hi.yml b/_data/locales/hi.yml
new file mode 100644
index 00000000000..84435d4d5fb
--- /dev/null
+++ b/_data/locales/hi.yml
@@ -0,0 +1,32 @@
+hi:
+  locale_name: हिंदी
+  nav:
+    about: बारे में
+    contribute: योगदान करें
+  index:
+    lead: ओपन सोर्स सॉफ़्टवेयर उन लोगों द्वारा बनाया जाता है जैसे कि आप। जानें कि आप कैसे अपने प्रोजेक्ट को शुरू कर सकते हैं और उसे बढ़ा सकते हैं।
+    opensourcefriday: यह शुक्रवार है! कुछ घंटे निवेश करके उन सॉफ़्टवेयर में योगदान करें जिन्हें आप उपयोग करते हैं और पसंद करते हैं
+  article:
+    table_of_contents: सामग्री की सूची
+    back_to_all_guides: सभी मार्गदर्शिकाओं पर वापस जाएं
+    related_guides: संबंधित मार्गदर्शिकाएं
+  footer:
+    contribute:
+      heading: योगदान करें
+      description: क्या आपका कोई सुझाव है? यह सामग्री ओपन सोर्स है। हमें इसे सुधारने में मदद करें।
+      button: योगदान करें
+    subscribe:
+      heading: संपर्क में रहें
+      description: गिटहब की नवीनतम ओपन सोर्स युक्तियों और संसाधनों की पहली जानकारी पाने के लिए पहले ही सुनें।
+      label: ईमेल पता
+      button: सदस्यता लें
+    byline:
+      # [code], [love], and [github] will be replaced by octicons
+      format: "[code] के साथ [love] द्वारा [github] और [friends]"
+      # Label for code octicon
+      code_label: कोड
+      # Label for love octicon
+      love_label: प्रेम
+      # Label for the contributors link
+      friends_label: मित्र
+

From ab3861d499291f08c23084af2d84978f2c11b069 Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Wed, 30 Aug 2023 23:03:25 +0530
Subject: [PATCH 480/749] articles update

---
 _articles/hi/best-practices.md                | 284 ++++++++++
 _articles/hi/building-community.md            | 279 ++++++++++
 _articles/hi/code-of-conduct.md               | 114 ++++
 _articles/hi/finding-users.md                 | 148 +++++
 _articles/hi/getting-paid.md                  | 178 ++++++
 _articles/hi/how-to-contribute.md             | 520 ++++++++++++++++++
 _articles/hi/index.html                       |   5 +
 _articles/hi/leadership-and-governance.md     | 156 ++++++
 _articles/hi/legal.md                         | 158 ++++++
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++
 _articles/hi/metrics.md                       | 128 +++++
 _articles/hi/starting-a-project.md            | 356 ++++++++++++
 12 files changed, 2547 insertions(+)
 create mode 100644 _articles/hi/best-practices.md
 create mode 100644 _articles/hi/building-community.md
 create mode 100644 _articles/hi/code-of-conduct.md
 create mode 100644 _articles/hi/finding-users.md
 create mode 100644 _articles/hi/getting-paid.md
 create mode 100644 _articles/hi/how-to-contribute.md
 create mode 100644 _articles/hi/index.html
 create mode 100644 _articles/hi/leadership-and-governance.md
 create mode 100644 _articles/hi/legal.md
 create mode 100644 _articles/hi/maintaining-balance-for-open-source-maintainers.md
 create mode 100644 _articles/hi/metrics.md
 create mode 100644 _articles/hi/starting-a-project.md

diff --git a/_articles/hi/best-practices.md b/_articles/hi/best-practices.md
new file mode 100644
index 00000000000..52982086e51
--- /dev/null
+++ b/_articles/hi/best-practices.md
@@ -0,0 +1,284 @@
+---
+lang: hi
+title: मेंटेनर्स के लिए सर्वोत्तम प्रैक्टिस
+description: आपके जीवन को आसान बनाने के तरीके, संग्रहणिक प्रक्रियाओं से लेकर आपकी समुदाय का उपयोग करने तक, एक ओपन सोर्स मेंटेनर के रूप में।
+class: best-practices
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+  - metrics
+  - leadership
+---
+
+## मेंटेनर का मतलब क्या है?
+
+अगर आप किसी खुले स्रोत परियोजना का पालन करते हैं जिसका बहुत सारे लोग उपयोग करते हैं, तो आपने देखा होगा कि आप कोडिंग कम और मुद्दों के जवाब देने ज्यादा कर रहे हैं।
+
+परियोजना के प्रारंभिक चरण में, आप नए विचारों की प्रायोगिकता कर रहे होते हैं और निर्णय वही लेते हैं जो आप चाहते हैं। जब आपकी परियोजना लोकप्रिय होने लगती है, तो आप अपने उपयोगकर्ताओं और सहयोगियों के साथ काम करने के बारे में अधिक सोचेंगे।
+
+परियोजना को संभालने के लिए कोड से ज्यादा की आवश्यकता होती है। ये कार्य अक्सर अप्रत्याशित होते हैं, लेकिन एक बढ़ती हुई परियोजना के लिए ये उतने ही महत्वपूर्ण होते हैं। हमने कुछ तरीके जुटाए हैं जो आपके जीवन को आसान बनाने में मदद करेंगे, प्रक्रियाओं की दस्तावेजीकरण से लेकर आपकी समुदाय का उपयोग करने तक।
+
+
+
+## प्रक्रियाओं की दस्तावेजीकरण
+
+चीजों को लिखना मेंटेनर के रूप में आपकी सबसे महत्वपूर्ण चीजों में से एक है।
+
+दस्तावेजीकरण न केवल आपके विचारों को स्पष्ट करता है, बल्कि यह दूसरे लोगों को समझने में मदद करता है कि आपकी क्या आवश्यकताएं हैं या आपकी क्या उम्मीदें हैं, उनसे पहले ही।
+
+चीजें लिखने से, कुछ आपके स्कोप में नहीं आने पर "नहीं" कहना आसान हो जाता है। यह लोगों को साथ में आने और मदद करने के लिए भी आसान बनाता है। आप कभी नहीं जान सकते कि कौन-सा व्यक्ति आपकी परियोजना को पढ़ रहा है या उसका उपयोग कर रहा है।
+
+चाहे आप पूरे पैराग्राफ ना भी उपयोग करें, बुलेट पॉइंट्स को लिखना बिना कुछ लिखे होने से बेहतर है।
+
+याद रखें कि आपकी दस्तावेजीकरण को अपडेट रखने की आवश्यकता है। अगर आप हमेशा इसे अपडेट नहीं कर पा रहे हैं, तो अपने पुराने दस्तावेजीकरण को हटा दें या इसे पुराना बताएं ताकि सहयोगी जानें कि अपडेट्स का स्वागत है।
+
+### अपनी परियोजना की दृष्टि लिखें
+
+परियोजना के लक्ष्यों को लिखने की शुरुआत करें। उन्हें अपने README में जोड़ें, या एक अलग फ़ाइल जिसे VISION के नाम से बुलाया जा सकता है, बनाएं। अगर कोई और आर्टिफैक्ट हो सकते हैं जो मदद कर सकते हैं, जैसे कि परियोजना का रोडमैप, तो उन्हें भी सार्वजनिक बनाएं।
+
+स्पष्ट, दस्तावेजीत दृष्टि आपको ध्यान में रखने में मदद करती है और आपको दूसरों के सहयोग से आने वाले "स्कोप क्रीप" से बचाती है।
+
+उदाहरण के लिए, @lord ने यह जानकर पाया कि परियोजना की दृष्टि रखने से उसने यह तय किया कि किन अनुरोधों पर समय खर्च करना चाहिए। एक नए मेंटेनर के रूप में, उसने खेद किया कि उसने अपनी परियोजना की दिशा को न अपनाकर अपने पहले विशेषता अनुरोध के लिए [Slate](https://github.com/lord/slate) को मान्यता दी।
+
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
+  मैंने इसे गलती से किया। मैंने किसी पूर्ण समाधान को लाने के लिए प्रयास नहीं किया। आधे-पूरे समाधान की जगह, मुझे खेद है कि मैंने यह नहीं कहा "मेरे पास इसके लिए अभी समय नहीं है, लेकिन मैं इसे दीर्घकालिक सूची में जोड़ दूंगा जिसे हमारे लिए अच्छा हो सकता है।"
+  <p markdown="1" class="pquote-credit">
+— @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
+  </p>
+</aside>
+
+### आपकी उम्मीदाएँ संवाद करें
+
+नियम लिखने के लिए हो सकते हैं और समय-समय पर यह घबराने वाला होता है। कभी-कभी आपको ऐसा लग सकता है कि आप दूसरों के व्यवहार की पुलिसी बना रहे हैं या सब मज़ा खत्म कर रहे हैं।
+
+लेकिन यदि नियम स्पष्ट, लिखित और सावधानीपूर्वक पालन किए जाएं, तो यह मेंटेनर्स को सशक्त बनाते हैं। वे आपको उन कामों में नहीं फंसने से बचाते हैं जिन्हें आप करना नहीं चाहते।
+
+आपकी परियोजना के बारे में ज्यादातर लोग आपके बारे में कुछ भी नहीं जानते हैं या आपके परिस्थितियों के बारे में। वे मान सकते हैं कि आप इस पर काम करने के लिए पैसे प्राप्त करते हैं, विशेष रूप से अगर यह कुछ है जिसका वे नियमित रूप से उपयोग करते हैं और उस पर निर्भर करते हैं। शायद किसी समय आपने अपनी परियोजना में काफी समय लगाया था, लेकिन अब आप एक नई नौकरी या परिवार के सदस्य के साथ व्यस्त हैं।
+
+ये सब बिल्कुल ठीक है! बस यह सुनिश्चित करें कि अन्य लोग इसके बारे में जानते हैं।
+
+यदि आपकी परियोजना को पार्ट-टाइम या पूरी तरह से स्वयंसेवा में बनाए रखना है, तो यह स्पष्ट रूप से बताएं कि आपके पास कितना समय है। यह उस समय के समान नहीं है जिसकी परियोजना को आपकी आवश्यकता है, या उस समय के समान नहीं है जिसे दुसरों को आपके खर्च करने के लिए चाहिए।
+
+यहाँ कुछ नियम हैं जो लिखने योग्य हैं:
+
+* किसी योगदान की समीक्षा और स्वीकार कैसे की जाती है (_क्या उन्हें परीक्षण की आवश्यकता है? एक समस्या टेम्पलेट?_)
+* योगदान के प्रकार जिन्हें आप स्वीकार करेंगे (_क्या आप केवल अपने कोड के एक निश्चित भाग के लिए सहायता चाहते हैं?_)
+* जब फॉलो-अप करना उचित हो (_उदाहरण के लिए, "आप 7 दिनों के भीतर अनुरक्षक से प्रतिक्रिया की उम्मीद कर सकते हैं। यदि आपने तब तक कुछ नहीं सुना है, तो बेझिझक थ्रेड को पिंग करें।"_)
+* आप प्रोजेक्ट पर कितना समय बिताते हैं (उदाहरण के लिए, "हम इस प्रोजेक्ट पर प्रति सप्ताह केवल 5 घंटे खर्च करते हैं"_)
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) अनुरक्षकों और योगदानकर्ताओं के लिए बुनियादी नियमों वाली परियोजनाओं के कई उदाहरण हैं।
+
+### संवाद को सार्वजनिक रखें
+
+अपने संवादों को डॉक्युमेंट करना न भूलें। जहां भी संभव हो, अपनी परियोजना के बारे में होने वाले संवाद को सार्वजनिक रूप से रखें। यदि कोई किसी विशेषता अनुरोध या समर्थन की आवश्यकता के लिए आपसे निजी तौर पर संपर्क करने का प्रयास करता है, तो उन्हें सवालों की सार्वजनिक संवाद स्रोत, जैसे कि मेलिंग सूची या समस्या ट्रैकर, की ओर सभीष्ठता से प्रेषित करें।
+
+यदि आप अन्य संरक्षकों से मिलते हैं, या यदि आप निजी तौर पर महत्वपूर्ण निर्णय लेते हैं, तो इन संवादों को सार्वजनिक डॉक्युमेंट करें, चाहे आपके नोट पोस्ट करने के बारे में भी हो।
+
+इस तरह, जो भी आपकी समुदाय में शामिल होता है, वह उसी जानकारी तक पहुँच पाएगा जो सालों से वहाँ हैने वाले किसी के पास है।
+
+## ना कहना सीखना
+
+आपने बातें लिख दी हैं. आदर्श रूप से, हर कोई आपके दस्तावेज़ को पढ़ेगा, लेकिन वास्तव में, आपको दूसरों को याद दिलाना होगा कि यह ज्ञान मौजूद है।
+
+हालाँकि, सब कुछ लिखित होने से उन स्थितियों को वैयक्तिकृत करने में मदद मिलती है जब आपको अपने नियमों को लागू करने की आवश्यकता होती है।
+
+ना कहना मज़ेदार नहीं है, लेकिन _"आपका योगदान इस परियोजना के मानदंडों से मेल नहीं खाता"__"मुझे आपका योगदान पसंद नहीं है"_ की तुलना में कम व्यक्तिगत लगता है।
+
+ना कहना उन कई स्थितियों पर लागू होता है जिनका सामना आप एक अनुरक्षक के रूप में करेंगे: सुविधा अनुरोध जो दायरे में फिट नहीं होते हैं, कोई व्यक्ति चर्चा को पटरी से उतार रहा है, दूसरों के लिए अनावश्यक काम कर रहा है।
+
+### बातचीत मित्रवत रखें
+
+सबसे महत्वपूर्ण स्थानों में से एक जहां आप ना कहने का अभ्यास करेंगे, वह है आपके मुद्दे पर और अनुरोध कतार को खींचना। एक प्रोजेक्ट अनुरक्षक के रूप में, आपको अनिवार्य रूप से ऐसे सुझाव प्राप्त होंगे जिन्हें आप स्वीकार नहीं करना चाहते हैं।
+
+हो सकता है कि योगदान आपके प्रोजेक्ट का दायरा बदल दे या आपके दृष्टिकोण से मेल न खाए। हो सकता है कि विचार अच्छा हो, लेकिन कार्यान्वयन ख़राब हो।
+
+कारण चाहे जो भी हो, उन योगदानों को चतुराई से संभालना संभव है जो आपके प्रोजेक्ट के मानकों को पूरा नहीं करते हैं।
+
+यदि आपको कोई योगदान मिलता है जिसे आप स्वीकार नहीं करना चाहते हैं, तो आपकी पहली प्रतिक्रिया इसे अनदेखा करना या दिखावा करना हो सकता है कि आपने इसे नहीं देखा है। ऐसा करने से दूसरे व्यक्ति की भावनाएं आहत हो सकती हैं और यहां तक ​​कि आपके समुदाय में अन्य संभावित योगदानकर्ता भी हतोत्साहित हो सकते हैं।
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
+  बड़े स्केल के ओपन सोर्स प्रोजेक्ट्स के समर्थन को हैंडल करने की कुंजी है, मुद्दों को आगे बढ़ाने की कोशिश करें। मुद्दों को ठप करने से बचने का प्रयास करें। यदि आप एक iOS डेवलपर हैं, तो आप जानते हैं कि रेडर्स (radars) सबमिट करना कितना खिचड़ हो सकता है। आप 2 साल बाद प्रतिक्रिया प्राप्त कर सकते हैं, और आपको नवीनतम iOS संस्करण के साथ पुनः प्रयास करने की सलाह दी जा सकती है।
+  <p markdown="1" class="pquote-credit">
+— @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
+  </p>
+</aside>
+
+अनचाहे योगदान को खुले छोडने का कारण यह नहीं होना चाहिए कि आपको आपत्ति महसूस हो रही हो या आप अच्छे बनना चाहते हों। समय के साथ, आपके बिना उत्तरित मुद्दे और पुल रिक्वेस्ट (PRs) से आपके प्रोजेक्ट पर काम करने में अधिक तनावपूर्ण और डरावनी भावना उत्पन्न हो सकती है।
+
+जिन योगदानों को आप जानते हैं कि आप स्वीकार नहीं करना चाहते, उन्हें तुरंत बंद कर देना बेहतर है। यदि आपका प्रोजेक्ट पहले से ही बड़े बैकलॉग से ग्रस्त है, @steveklabnik [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) के लिए सुझाव हैं .
+
+योगदान को नज़रअंदाज करना आपके समुदाय को नकारात्मक संकेत भेजता है। किसी प्रोजेक्ट में योगदान देना डराने वाला हो सकता है, खासकर अगर यह किसी के लिए पहली बार हो। भले ही आप उनके योगदान को स्वीकार न करें, इसके पीछे वाले व्यक्ति को स्वीकार करें और उनकी रुचि के लिए उन्हें धन्यवाद दें। यह एक बड़ी प्रशंसा है!
+
+यदि आप कोई योगदान स्वीकार नहीं करना चाहते हैं:
+
+* **उन्हें उनके योगदान के लिए धन्यवाद**
+* **स्पष्ट करें कि यह परियोजना के दायरे में क्यों फिट नहीं बैठता**, और यदि आप सक्षम हैं तो सुधार के लिए स्पष्ट सुझाव दें। दयालु बनें, लेकिन दृढ़ रहें।
+* **प्रासंगिक दस्तावेज का लिंक**, यदि आपके पास है। यदि आप उन चीज़ों के लिए बार-बार अनुरोध देखते हैं जिन्हें आप स्वीकार नहीं करना चाहते हैं, तो उन्हें दोहराने से बचने के लिए उन्हें अपने दस्तावेज़ में जोड़ें।
+* **अनुरोध बंद करें**
+
+You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):
+
+![Celery screenshot](/assets/images/best-practices/celery.png)
+
+यदि ना कहने का विचार आपको भयभीत करता है, तो आप अकेले नहीं हैं। जैसा @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> मैंने कई अलग-अलग ओपन सोर्स प्रोजेक्ट्स, मेसोस, कुबेरनेट्स, क्रोमियम के अनुरक्षकों से बात की है, और वे सभी इस बात से सहमत हैं कि अनुरक्षक होने के सबसे कठिन हिस्सों में से एक उन पैच को "नहीं" कहना है जिन्हें आप नहीं चाहते हैं।
+
+किसी के योगदान को स्वीकार न करने को लेकर दोषी महसूस न करें। ओपन सोर्स का पहला नियम, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"
+नहीं अस्थायी है, हाँ हमेशा के लिए है।"_ जबकि किसी अन्य व्यक्ति के उत्साह के साथ सहानुभूति रखना अच्छी बात है, किसी योगदान को अस्वीकार करना उसके पीछे वाले व्यक्ति को अस्वीकार करने के समान नहीं है।
+
+अंततः, यदि कोई योगदान पर्याप्त नहीं है, तो आप इसे स्वीकार करने के लिए बाध्य नहीं हैं। जब लोग आपके प्रोजेक्ट में योगदान दें तो दयालु और उत्तरदायी बनें, लेकिन केवल उन बदलावों को स्वीकार करें जिनके बारे में आपको वास्तव में विश्वास है कि वे आपके प्रोजेक्ट को बेहतर बनाएंगे। आप जितनी बार ना कहने का अभ्यास करेंगे, यह उतना ही आसान हो जाएगा। वादा करना।
+
+### सक्रिय होना
+
+सबसे पहले अवांछित योगदान की मात्रा को कम करने के लिए, अपने योगदान मार्गदर्शिका में योगदान जमा करने और स्वीकार करने के लिए अपने प्रोजेक्ट की प्रक्रिया की व्याख्या करें।
+
+यदि आपको बहुत अधिक निम्न-गुणवत्ता वाले योगदान प्राप्त हो रहे हैं, तो आवश्यक है कि योगदानकर्ता पहले से ही थोड़ा काम करें, उदाहरण के लिए:
+
+* कोई अंक या पीआर टेम्पलेट/चेकलिस्ट भरें
+* पीआर सबमिट करने से पहले एक मुद्दा खोलें
+
+यदि वे आपके नियमों का पालन नहीं करते हैं, तो समस्या को तुरंत बंद करें और अपने दस्तावेज़ की ओर इंगित करें।
+
+हालाँकि यह दृष्टिकोण पहली बार में निर्दयी लग सकता है, सक्रिय होना वास्तव में दोनों पक्षों के लिए अच्छा है। इससे इस बात की संभावना कम हो जाती है कि कोई व्यक्ति काम के कई घंटे बर्बाद करके ऐसे पुल अनुरोध में लगाएगा जिसे आप स्वीकार नहीं करेंगे। और यह आपके कार्यभार को प्रबंधित करना आसान बनाता है।
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+  आदर्श रूप से, उन्हें CONTRIBUTING.md फ़ाइल में समझाएं कि वे भविष्य में काम शुरू करने से पहले बेहतर संकेत कैसे प्राप्त कर सकते हैं कि क्या स्वीकार किया जाएगा या क्या नहीं।
+  <p markdown="1" class="pquote-credit">
+— @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
+  </p>
+</aside>
+
+कभी-कभी, जब आप ना कहते हैं, तो आपका संभावित योगदानकर्ता परेशान हो सकता है या आपके निर्णय की आलोचना कर सकता है। यदि उनका व्यवहार शत्रुतापूर्ण हो जाए, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) या यदि वे रचनात्मक रूप से सहयोग करने के इच्छुक नहीं हैं, तो उन्हें अपने समुदाय से हटा भी दें।
+
+### मार्गदर्शन को गले लगाओ
+
+हो सकता है कि आपके समुदाय में कोई व्यक्ति नियमित रूप से ऐसे योगदान सबमिट करता हो जो आपके प्रोजेक्ट के मानकों को पूरा नहीं करता हो। बार-बार अस्वीकृतियों से गुजरना दोनों पक्षों के लिए निराशाजनक हो सकता है।
+
+यदि आप देखते हैं कि कोई आपके प्रोजेक्ट को लेकर उत्साहित है, लेकिन उसे थोड़ा निखारने की जरूरत है, तो धैर्य रखें। प्रत्येक स्थिति में स्पष्ट रूप से बताएं कि उनका योगदान परियोजना की अपेक्षाओं को पूरा क्यों नहीं करता है। उन्हें किसी आसान या कम अस्पष्ट कार्य की ओर इंगित करने का प्रयास करें, जैसे उनके पैरों को गीला करने के लिए _"अच्छा पहला अंक,"_ चिह्नित कोई मुद्दा। यदि आपके पास समय है, तो उनके पहले योगदान के माध्यम से उन्हें सलाह देने पर विचार करें, या अपने समुदाय में किसी और को ढूंढें जो उन्हें सलाह देने के लिए तैयार हो सकता है।
+
+## अपने समुदाय का लाभ उठाएं
+
+आपको सब कुछ खुद ही करने की ज़रूरत नहीं है. आपके प्रोजेक्ट का समुदाय किसी कारण से मौजूद है! भले ही आपके पास अभी तक कोई सक्रिय योगदानकर्ता समुदाय नहीं है, यदि आपके पास बहुत सारे उपयोगकर्ता हैं, तो उन्हें काम पर लगाएं।
+
+### कार्यभार साझा करें
+
+यदि आप मदद के लिए दूसरों की तलाश कर रहे हैं, तो आसपास पूछकर शुरुआत करें।
+
+नए योगदानकर्ताओं को प्राप्त करने का एक तरीका स्पष्ट रूप से है [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 इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर प्रदर्शित करेगा, जिससे उनकी दृश्यता बढ़ेगी।
+
+जब आप नए योगदानकर्ताओं को बार-बार योगदान करते हुए देखें, तो अधिक जिम्मेदारी देकर उनके काम को पहचानें। दस्तावेज़ बनाएं कि यदि अन्य लोग चाहें तो नेतृत्व की भूमिका में कैसे विकसित हो सकते हैं।
+
+दूसरों को इसके लिए प्रोत्साहित करना[share ownership of the project](../building-community/#share-ownership-of-your-project) आपके स्वयं के कार्यभार को बहुत कम कर सकता है, जैसा कि @lmccart ने अपने प्रोजेक्ट पर पाया, [p5.js](https://github.com/processing/p5.js).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
+  मैं कह रहा था, "हाँ, कोई भी शामिल हो सकता है, आपके पास बहुत अधिक कोडिंग विशेषज्ञता होनी आवश्यक नहीं है [...]।" हमारे पास लोगों ने [एक कार्यक्रम में] आने के लिए साइन अप किया था और तभी मैं वास्तव में सोच रहा था: क्या यह सच है, जो मैं कह रहा हूं? वहाँ 40 लोग आने वाले हैं, और ऐसा नहीं है कि मैं उनमें से प्रत्येक के साथ बैठ सकता हूँ...लेकिन लोग एक साथ आए, और यह काम कर गया। जैसे ही एक व्यक्ति को यह मिल गया, वे अपने पड़ोसी को सिखा सकते थे।
+  <p markdown="1" class="pquote-credit">
+—  @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+  </p>
+</aside>
+
+यदि आपको अपने प्रोजेक्ट से हटना है, या तो अंतराल पर या स्थायी रूप से, तो किसी और को आपकी जगह लेने के लिए कहने में कोई शर्म की बात नहीं है।
+
+यदि अन्य लोग इसकी दिशा को लेकर उत्साहित हैं, तो उन्हें प्रतिबद्ध पहुंच प्रदान करें या औपचारिक रूप से नियंत्रण किसी और को सौंप दें। यदि किसी ने आपके प्रोजेक्ट को फोर्क किया है और इसे कहीं और सक्रिय रूप से बनाए रख रहा है, तो अपने मूल प्रोजेक्ट से फोर्क को जोड़ने पर विचार करें। यह बहुत अच्छा है कि इतने सारे लोग चाहते हैं कि आपका प्रोजेक्ट चालू रहे!
+
+@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) अपने प्रोजेक्ट, [डोक्कू](https://github.com/dokku/dokku) के लिए विज़न का दस्तावेजीकरण करने से, प्रोजेक्ट से दूर जाने के बाद भी उन लक्ष्यों को जीवित रखने में मदद मिली:
+
+> मैंने एक विकी पेज लिखा जिसमें बताया गया कि मैं क्या चाहता था और मैं यह क्यों चाहता था। किसी कारण से यह मेरे लिए आश्चर्य की बात थी कि अनुरक्षकों ने परियोजना को उस दिशा में आगे बढ़ाना शुरू कर दिया! क्या यह बिल्कुल वैसा ही हुआ जैसा मैंने इसे किया था? हमेशा नहीं। लेकिन फिर भी यह परियोजना को मैंने जो लिखा था उसके करीब ले आया।
+
+### दूसरों को वे समाधान बनाने दें जिनकी उन्हें आवश्यकता है
+
+यदि किसी संभावित योगदानकर्ता की इस बारे में अलग राय है कि आपके प्रोजेक्ट को क्या करना चाहिए, तो आप उन्हें धीरे-धीरे अपने स्वयं के कांटे पर काम करने के लिए प्रोत्साहित करना चाह सकते हैं।
+
+किसी प्रोजेक्ट को फोर्क करना कोई बुरी बात नहीं है। प्रोजेक्टों को कॉपी और संशोधित करने में सक्षम होना ओपन सोर्स के बारे में सबसे अच्छी चीजों में से एक है। अपने समुदाय के सदस्यों को अपने स्वयं के फ़ोर्क पर काम करने के लिए प्रोत्साहित करना, आपके प्रोजेक्ट के दृष्टिकोण के साथ टकराव किए बिना, उन्हें आवश्यक रचनात्मक आउटलेट प्रदान कर सकता है।
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
+  मैं 80% उपयोग के मामले को पूरा करता हूं। यदि आप यूनिकॉर्न में से एक हैं, तो कृपया मेरे काम को छोड़ दें। मैं नाराज नहीं होऊंगा! मेरी सार्वजनिक परियोजनाएँ लगभग हमेशा सबसे आम समस्याओं को हल करने के लिए होती हैं; मैं या तो अपने काम को आगे बढ़ाकर या इसे विस्तारित करके गहराई तक जाना आसान बनाने की कोशिश करता हूं।
+  <p markdown="1" class="pquote-credit">
+— @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+  </p>
+</aside>
+
+यही बात उस उपयोगकर्ता पर लागू होती है जो वास्तव में एक ऐसा समाधान चाहता है जिसे बनाने के लिए आपके पास बैंडविड्थ नहीं है। एपीआई और अनुकूलन हुक की पेशकश दूसरों को स्रोत को सीधे संशोधित किए बिना, अपनी जरूरतों को पूरा करने में मदद कर सकती है। @orta [ने पाया कि](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) कोकोपोड्स के लिए प्लगइन्स को प्रोत्साहित करने से "कुछ सबसे दिलचस्प विचार" सामने आए:
+
+> यह लगभग अपरिहार्य है कि एक बार जब कोई परियोजना बड़ी हो जाती है, तो अनुरक्षकों को इस बारे में अधिक रूढ़िवादी बनना पड़ता है कि वे नए कोड कैसे पेश करते हैं। आप "नहीं" कहने में अच्छे हो जाते हैं, लेकिन बहुत से लोगों की ज़रूरतें वैध होती हैं। तो, इसके बजाय आप अपने टूल को एक प्लेटफ़ॉर्म में परिवर्तित कर देते हैं।
+
+## रोबोट लाओ
+
+जिस प्रकार ऐसे कार्य हैं जिनमें अन्य लोग आपकी सहायता कर सकते हैं, वैसे ही ऐसे कार्य भी हैं जिन्हें किसी भी मनुष्य को कभी नहीं करना चाहिए। रोबोट आपके मित्र हैं. एक अनुरक्षक के रूप में अपने जीवन को आसान बनाने के लिए उनका उपयोग करें।
+
+### आपके कोड की गुणवत्ता में सुधार के लिए परीक्षण और अन्य जांच की आवश्यकता है
+
+परीक्षण जोड़कर अपने प्रोजेक्ट को स्वचालित करने का सबसे महत्वपूर्ण तरीका है।
+
+परीक्षण योगदानकर्ताओं को यह विश्वास दिलाने में मदद करते हैं कि वे कुछ भी नहीं तोड़ेंगे। वे आपके लिए योगदान की शीघ्रता से समीक्षा करना और स्वीकार करना भी आसान बनाते हैं। आप जितने अधिक संवेदनशील होंगे, आपका समुदाय उतना ही अधिक सक्रिय हो सकता है।
+
+स्वचालित परीक्षण सेट करें जो आने वाले सभी योगदानों पर चलेंगे, और सुनिश्चित करें कि आपके परीक्षण योगदानकर्ताओं द्वारा स्थानीय स्तर पर आसानी से चलाए जा सकें। आवश्यक है कि सबमिट किए जाने से पहले सभी कोड योगदान आपके परीक्षणों में उत्तीर्ण हों। आप सभी प्रस्तुतियों के लिए गुणवत्ता का न्यूनतम मानक निर्धारित करने में मदद करेंगे। GitHub पर [आवश्यक स्थिति जांच](https://help.github.com/articles/about-required-status-checks/) यह सुनिश्चित करने में मदद कर सकता है कि आपके परीक्षण पास किए बिना कोई भी परिवर्तन मर्ज नहीं किया जाएगा।
+
+यदि आप परीक्षण जोड़ते हैं, तो यह बताना सुनिश्चित करें कि वे आपकी CONTRIBUTING फ़ाइल में कैसे काम करते हैं।
+
+<aside markdown="1" class="pquote">
+  <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)
+  </p>
+</aside>
+
+### बुनियादी रखरखाव कार्यों को स्वचालित करने के लिए टूल का उपयोग करें
+
+एक लोकप्रिय परियोजना को बनाए रखने के बारे में अच्छी खबर यह है कि अन्य रखरखावकर्ताओं ने संभवतः इसी तरह के मुद्दों का सामना किया है और उनके लिए एक समाधान तैयार किया है।
+
+रखरखाव कार्य के कुछ पहलुओं को स्वचालित करने में मदद के लिए [विभिन्न प्रकार के उपकरण उपलब्ध हैं](https://github.com/showcases/tools-for-open-source) हैं। कुछ उदाहरण:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases
+* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
+* [Danger](https://github.com/danger/danger) helps automate code review
+* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information
+* [dependabot](https://github.com/dependabot) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
+
+बग रिपोर्ट और अन्य सामान्य योगदानों के लिए, GitHub के पास [इश्यू टेम्प्लेट्स और पुल रिक्वेस्ट टेम्प्लेट्स](https://github.com/blog/2111-issue-and-pull-request-templates) हैं, जिन्हें आप संचार को सुव्यवस्थित करने के लिए बना सकते हैं आपको प्राप्त हुया। @TalAter ने आपके मुद्दे और पीआर टेम्प्लेट लिखने में आपकी मदद करने के लिए एक [अपनी खुद की एडवेंचर गाइड चुनें](https://www.talater.com/open-source-templates/#/) बनाई है।
+
+अपनी ईमेल सूचनाओं को प्रबंधित करने के लिए, आप प्राथमिकता के आधार पर व्यवस्थित करने के लिए [ईमेल फ़िल्टर](https://github.com/blog/2203-email-updates-about-your-own-activity) सेट कर सकते हैं।
+
+यदि आप थोड़ा और उन्नत होना चाहते हैं, तो स्टाइल गाइड और लिंटर परियोजना योगदान को मानकीकृत कर सकते हैं और उनकी समीक्षा करना और स्वीकार करना आसान बना सकते हैं।
+
+हालाँकि, यदि आपके मानक बहुत जटिल हैं, तो वे योगदान में बाधाएँ बढ़ा सकते हैं। सुनिश्चित करें कि आप सभी के जीवन को आसान बनाने के लिए केवल पर्याप्त नियम जोड़ रहे हैं।
+
+यदि आप निश्चित नहीं हैं कि कौन से टूल का उपयोग करना है, तो देखें कि अन्य लोकप्रिय प्रोजेक्ट क्या करते हैं, विशेष रूप से आपके पारिस्थितिकी तंत्र में। उदाहरण के लिए, अन्य नोड मॉड्यूल के लिए योगदान प्रक्रिया कैसी दिखती है? समान टूल और दृष्टिकोण का उपयोग करने से आपकी प्रक्रिया आपके लक्षित योगदानकर्ताओं के लिए अधिक परिचित हो जाएगी।
+
+## विराम देना ठीक है
+
+ओपन सोर्स का काम एक बार आपके लिए खुशी लेकर आया। शायद अब यह आपको टालने या दोषी महसूस कराने लगा है।
+
+जब आप अपनी परियोजनाओं के बारे में सोचते हैं तो शायद आप अभिभूत महसूस कर रहे हों या भय की भावना बढ़ रही हो। और इस बीच, मुद्दों और पुल अनुरोधों का ढेर लग जाता है।
+
+ओपन सोर्स कार्य में बर्नआउट एक वास्तविक और व्यापक मुद्दा है, विशेषकर अनुरक्षकों के बीच। एक अनुरक्षक के रूप में, किसी भी ओपन सोर्स प्रोजेक्ट के अस्तित्व के लिए आपकी खुशी एक गैर-परक्राम्य आवश्यकता है।
+
+हालाँकि यह बिना कहे चला जाना चाहिए, एक ब्रेक लें! आपको छुट्टी लेने के लिए तब तक इंतजार नहीं करना चाहिए जब तक आप थका हुआ महसूस न करें। @brettcannon, एक पायथन कोर डेवलपर, ने 14 साल के स्वयंसेवक OSS के बाद [एक महीने की छुट्टी](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) लेने का फैसला किया काम।
+
+किसी भी अन्य प्रकार के काम की तरह, नियमित ब्रेक लेने से आप अपने काम के प्रति तरोताजा, खुश और उत्साहित रहेंगे।
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
+  WP-CLI को बनाए रखने में, मैंने पाया है कि मुझे पहले खुद को खुश करने की ज़रूरत है, और अपनी भागीदारी पर स्पष्ट सीमाएँ निर्धारित करनी होंगी। मेरे सामान्य कार्य शेड्यूल के एक भाग के रूप में, मुझे जो सबसे अच्छा संतुलन मिला है, वह प्रति सप्ताह 2-5 घंटे है। इससे मेरी भागीदारी एक जुनून बनी रहती है, और मुझे काम जैसा महसूस नहीं होता। क्योंकि मैं उन मुद्दों को प्राथमिकता देता हूं जिन पर मैं काम कर रहा हूं, मैं उस पर नियमित प्रगति कर सकता हूं जो मुझे लगता है कि सबसे महत्वपूर्ण है।
+  <p markdown="1" class="pquote-credit">
+— @danielbachhuber, ["मेरी संवेदनाएं, अब आप एक लोकप्रिय ओपन सोर्स प्रोजेक्ट के अनुरक्षक हैं"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+  </p>
+</aside>
+
+कभी-कभी, जब ऐसा महसूस हो कि हर किसी को आपकी ज़रूरत है तो ओपन सोर्स कार्य से ब्रेक लेना कठिन हो सकता है। लोग आपको दूर जाने के लिए दोषी महसूस कराने का प्रयास भी कर सकते हैं।
+
+जब आप किसी प्रोजेक्ट से दूर हों तो अपने उपयोगकर्ताओं और समुदाय के लिए समर्थन पाने की पूरी कोशिश करें। यदि आपको आवश्यक सहायता नहीं मिल पा रही है, तो फिर भी एक ब्रेक ले लें। जब आप उपलब्ध न हों तो संवाद करना सुनिश्चित करें, ताकि लोग आपकी प्रतिक्रियाशीलता की कमी से भ्रमित न हों।
+
+ब्रेक लेना केवल छुट्टियों के अलावा और भी बहुत कुछ पर लागू होता है। यदि आप सप्ताहांत पर या काम के घंटों के दौरान ओपन सोर्स काम नहीं करना चाहते हैं, तो उन अपेक्षाओं को दूसरों को बताएं, ताकि वे जान सकें कि आपको परेशान नहीं करना है।
+
+## पहले अपना ख्याल रखें!
+
+किसी लोकप्रिय प्रोजेक्ट को बनाए रखने के लिए विकास के शुरुआती चरणों की तुलना में अलग कौशल की आवश्यकता होती है, लेकिन यह कम फायदेमंद नहीं है। एक अनुरक्षक के रूप में, आप नेतृत्व और व्यक्तिगत कौशल का उस स्तर पर अभ्यास करेंगे जिसका अनुभव बहुत कम लोगों को होता है। हालाँकि इसे प्रबंधित करना हमेशा आसान नहीं होता है, स्पष्ट सीमाएँ निर्धारित करना और केवल वही लेना जिसमें आप सहज हों, आपको खुश, तरोताज़ा और उत्पादक रहने में मदद करेगा।
diff --git a/_articles/hi/building-community.md b/_articles/hi/building-community.md
new file mode 100644
index 00000000000..25309ad6f28
--- /dev/null
+++ b/_articles/hi/building-community.md
@@ -0,0 +1,279 @@
+---
+lang: hi
+title: स्वागत योग्य समुदायों का निर्माण
+description: एक ऐसे समुदाय का निर्माण करना जो लोगों को आपके प्रोजेक्ट का उपयोग करने, उसमें योगदान करने और उसका प्रचार-प्रसार करने के लिए प्रोत्साहित करे।
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+  - best-practices
+  - coc
+---
+
+## सफलता के लिए अपना प्रोजेक्ट तैयार करना
+
+आपने अपना प्रोजेक्ट लॉन्च कर दिया है, आप इसका प्रचार-प्रसार कर रहे हैं और लोग इसकी जांच कर रहे हैं। बहुत बढ़िया! अब, आप उन्हें अपने साथ कैसे जोड़े रखेंगे?
+
+स्वागत करने वाला समुदाय आपके प्रोजेक्ट के भविष्य और प्रतिष्ठा में एक निवेश है। यदि आपका प्रोजेक्ट अभी अपना पहला योगदान देखना शुरू कर रहा है, तो शुरुआती योगदानकर्ताओं को एक सकारात्मक अनुभव देकर शुरुआत करें, और उनके लिए वापस आना आसान बनाएं।
+
+### लोगों को स्वागत का एहसास कराएं
+
+आपके प्रोजेक्ट के समुदाय के बारे में सोचने का एक तरीका यह है कि @MikeMcQuaid इसे [योगदानकर्ता फ़नल] कहता है(https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+![योगदानकर्ता फ़नल](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+
+जैसे ही आप अपना समुदाय बनाते हैं, इस बात पर विचार करें कि फ़नल के शीर्ष पर कोई व्यक्ति (एक संभावित उपयोगकर्ता) सैद्धांतिक रूप से नीचे (एक सक्रिय अनुरक्षक) तक अपना रास्ता कैसे बना सकता है। आपका लक्ष्य योगदानकर्ता अनुभव के प्रत्येक चरण में घर्षण को कम करना है। जब लोगों को आसानी से जीत मिलती है, तो वे और अधिक करने के लिए प्रोत्साहित महसूस करेंगे।
+
+अपने दस्तावेज़ से प्रारंभ करें:
+
+* **किसी के लिए आपके प्रोजेक्ट का उपयोग करना आसान बनाएं।** [मैत्रीपूर्णREADME](../starting-a-project/#writing-a-readme) 
+और स्पष्ट कोड उदाहरण आपके प्रोजेक्ट पर आने वाले किसी भी व्यक्ति के लिए आरंभ करना आसान बना देंगे।  
+* **स्पष्ट रूप से बताएं कि योगदान कैसे करना है**, आपकी [योगदान CONTRIBUTING फ़ाइल  का उपयोग करके](../starting-a-project/#writing-your-contributing-guidelines) और अपने मुद्दों को अद्यतन रखते हुए।
+* **अच्छे प्रथम अंक**: नए योगदानकर्ताओं को आरंभ करने में मदद करने के लिए, स्पष्ट रूप से विचार करें [उन मुद्दों को लेबल करना जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर सामने लाएगा, उपयोगी योगदान बढ़ाएगा, और उन मुद्दों से निपटने वाले उपयोगकर्ताओं के मनमुटाव को कम करेगा जो उनके स्तर के लिए बहुत कठिन हैं।
+
+[GitHub का 2017 ओपन सोर्स सर्वेक्षण](http://opensourcesurvey.org/2017/) अपूर्ण या भ्रमित करने वाला दस्तावेज़ दिखाना ओपन सोर्स उपयोगकर्ताओं के लिए सबसे बड़ी समस्या है। अच्छा दस्तावेज़ीकरण लोगों को आपके प्रोजेक्ट के साथ बातचीत करने के लिए आमंत्रित करता है। अंततः, कोई व्यक्ति कोई समस्या खोलेगा या अनुरोध खींच लेगा। इन इंटरैक्शन को फ़नल से नीचे ले जाने के अवसर के रूप में उपयोग करें।
+
+* **जब कोई नया व्यक्ति आपके प्रोजेक्ट पर आता है, तो उनकी रुचि के लिए उन्हें धन्यवाद दें!** किसी को वापस आने से रोकने के लिए केवल एक नकारात्मक अनुभव की आवश्यकता होती है।
+* **उत्तरदायी बनें।** यदि आप एक महीने तक उनके मुद्दे पर प्रतिक्रिया नहीं देते हैं, तो संभावना है कि वे पहले ही आपके प्रोजेक्ट के बारे में भूल चुके होंगे।
+* **आप जिस प्रकार के योगदान स्वीकार करेंगे, उसके बारे में खुले दिमाग से काम करें।** कई योगदानकर्ता बग रिपोर्ट या छोटे सुधार के साथ शुरुआत करते हैं। वहाँ हैं[योगदान करने के कई तरीके](../how-to-contribute/#what-it-means-to-contribute) एक परियोजना के लिए. लोग जिस तरह से मदद करना चाहते हैं, उन्हें मदद करने दें।
+* **यदि कोई योगदान है जिससे आप असहमत हैं,** उनके विचार के लिए उन्हें धन्यवाद दें और [समझाइए क्यों](../best-practices/#learning-to-say-no) यह परियोजना के दायरे में फिट नहीं बैठता है, यदि आपके पास प्रासंगिक दस्तावेज हैं तो इसे लिंक करें।
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  कुछ लोगों के लिए ओपन सोर्स में योगदान करना दूसरों की तुलना में आसान है। कुछ सही न करने या उसमें फिट न बैठने के कारण चिल्लाए जाने का बहुत डर है। (...) योगदानकर्ताओं को बहुत कम तकनीकी दक्षता (दस्तावेज़ीकरण, वेब सामग्री मार्कडाउन, आदि) के साथ योगदान करने की जगह देकर आप बहुत कम कर सकते हैं वे चिंताएँ.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["आधुनिक ओपन सोर्स में योगदानकर्ता आधार बढ़ाना"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+  </p>
+</aside>
+
+अधिकांश ओपन सोर्स योगदानकर्ता "आकस्मिक योगदानकर्ता" हैं: वे लोग जो कभी-कभार ही किसी परियोजना में योगदान करते हैं। एक आकस्मिक योगदानकर्ता के पास आपके प्रोजेक्ट को पूरी तरह से गति देने का समय नहीं हो सकता है, इसलिए आपका काम उनके लिए योगदान करना आसान बनाना है।
+
+अन्य योगदानकर्ताओं को प्रोत्साहित करना आपके लिए भी एक निवेश है। जब आप अपने सबसे बड़े प्रशंसकों को उस काम के लिए सशक्त बनाते हैं जिसके लिए वे उत्साहित हैं, तो सब कुछ स्वयं करने का दबाव कम होता है।
+
+### हर चीज़ का दस्तावेजीकरण करें
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  क्या आप कभी किसी (tech) कार्यक्रम में गए हैं जहां आप किसी को नहीं जानते थे, लेकिन बाकी सभी लोग समूहों में खड़े थे और पुराने दोस्तों की तरह बातचीत कर रहे थे? (...) अब कल्पना करें कि आप एक ओपन सोर्स प्रोजेक्ट में योगदान देना चाहते हैं, लेकिन आपको समझ नहीं आ रहा कि ऐसा क्यों या कैसे हो रहा है।
+  <p markdown="1" class="pquote-credit">
+— @janl, ["सतत खुला स्रोत"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+जब आप कोई नया प्रोजेक्ट शुरू करते हैं, तो अपने काम को निजी रखना स्वाभाविक लग सकता है। लेकिन जब आप अपनी प्रक्रिया को सार्वजनिक रूप से दस्तावेज़ित करते हैं तो ओपन सोर्स प्रोजेक्ट फलते-फूलते हैं।
+
+जब आप चीज़ें लिखते हैं, तो हर कदम पर अधिक लोग भाग ले सकते हैं। आपको किसी ऐसी चीज़ पर मदद मिल सकती है जिसके बारे में आपको पता भी नहीं था कि आपको इसकी ज़रूरत है।
+
+चीज़ों को लिखने का अर्थ केवल तकनीकी दस्तावेज़ीकरण से कहीं अधिक है। जब भी आपको कुछ लिखने या अपने प्रोजेक्ट पर निजी तौर पर चर्चा करने की इच्छा महसूस हो, तो अपने आप से पूछें कि क्या आप इसे सार्वजनिक कर सकते हैं।
+
+अपने प्रोजेक्ट के रोडमैप, आप किस प्रकार के योगदान की तलाश कर रहे हैं, योगदान की समीक्षा कैसे की जाती है, या आपने कुछ निर्णय क्यों लिए, इस बारे में पारदर्शी रहें।
+
+यदि आप देखते हैं कि कई उपयोगकर्ता एक ही समस्या से जूझ रहे हैं, तो उत्तरों को README में दर्ज करें।
+
+बैठकों के लिए, किसी प्रासंगिक मुद्दे पर अपने नोट्स या निष्कर्ष प्रकाशित करने पर विचार करें। पारदर्शिता के इस स्तर से आपको जो फीडबैक मिलेगा वह आपको आश्चर्यचकित कर सकता है।
+
+हर चीज़ का दस्तावेज़ीकरण आपके द्वारा किए जाने वाले काम पर भी लागू होता है। यदि आप अपने प्रोजेक्ट में पर्याप्त अपडेट पर काम कर रहे हैं, तो इसे पुल अनुरोध में डालें और इसे कार्य प्रगति पर (डब्ल्यूआईपी) के रूप में चिह्नित करें। इस तरह, अन्य लोग शुरू से ही इस प्रक्रिया में शामिल महसूस कर सकते हैं।
+
+### उत्तरदायी बनें
+
+जैसे ही आप [अपने प्रोजेक्ट का प्रचार करें](../finding-users), लोगों के पास आपके लिए प्रतिक्रिया होगी. उनके मन में यह सवाल हो सकता है कि चीज़ें कैसे काम करती हैं, या उन्हें आरंभ करने में सहायता की आवश्यकता हो सकती है।
+
+जब कोई व्यक्ति कोई समस्या दर्ज करता है, पुल अनुरोध सबमिट करता है, या आपके प्रोजेक्ट के बारे में कोई प्रश्न पूछता है तो प्रतिक्रियाशील बनने का प्रयास करें। जब आप तुरंत प्रतिक्रिया देते हैं, तो लोगों को लगेगा कि वे एक संवाद का हिस्सा हैं, और वे भाग लेने के लिए अधिक उत्साहित होंगे।
+
+भले ही आप तुरंत अनुरोध की समीक्षा नहीं कर सकते, लेकिन इसे जल्दी स्वीकार करने से जुड़ाव बढ़ाने में मदद मिलती है। यहां बताया गया है कि @tdreyno ने [मिडिलमैन] पर पुल अनुरोध का जवाब कैसे दिया(https://github.com/middleman/middleman/pull/1466):
+
+![बिचौलिए का अनुरोध](/assets/images/building-community/middleman_pr.png)
+
+[मोज़िला के एक अध्ययन में यह पाया गया](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) जिन योगदानकर्ताओं को 48 घंटों के भीतर कोड समीक्षाएँ प्राप्त हुईं, उनकी वापसी और दोहराव योगदान की दर बहुत अधिक थी।
+
+आपके प्रोजेक्ट के बारे में बातचीत इंटरनेट पर स्टैक ओवरफ्लो, ट्विटर या रेडिट जैसे अन्य स्थानों पर भी हो सकती है। आप इनमें से कुछ स्थानों पर सूचनाएं सेट कर सकते हैं ताकि जब कोई आपके प्रोजेक्ट का उल्लेख करे तो आप सतर्क हो जाएं।
+
+### अपने समुदाय को एकत्र होने के लिए जगह दें
+
+अपने समुदाय को एकत्रित होने के लिए जगह देने के दो कारण हैं।
+
+पहला कारण उनके लिए है. लोगों को एक-दूसरे को जानने में मदद करें। समान रुचि वाले लोग अनिवार्य रूप से इसके बारे में बात करने के लिए जगह चाहेंगे। और जब संचार सार्वजनिक और सुलभ होता है, तो कोई भी गति प्राप्त करने और भाग लेने के लिए पिछले अभिलेखों को पढ़ सकता है।
+
+दूसरा कारण आपके लिए है. यदि आप लोगों को अपने प्रोजेक्ट के बारे में बात करने के लिए सार्वजनिक स्थान नहीं देते हैं, तो वे संभवतः आपसे सीधे संपर्क करेंगे। शुरुआत में, निजी संदेशों का "सिर्फ एक बार" जवाब देना काफी आसान लग सकता है। लेकिन समय के साथ, खासकर यदि आपका प्रोजेक्ट लोकप्रिय हो जाता है, तो आप थकावट महसूस करेंगे। अपने प्रोजेक्ट के बारे में लोगों से निजी तौर पर संवाद करने के प्रलोभन से बचें। इसके बजाय, उन्हें एक निर्दिष्ट सार्वजनिक चैनल पर निर्देशित करें।
+
+सार्वजनिक संचार उतना ही सरल हो सकता है जितना लोगों को आपको सीधे ईमेल करने या आपके ब्लॉग पर टिप्पणी करने के बजाय किसी मुद्दे को खोलने के लिए निर्देशित करना। आप अपने प्रोजेक्ट के बारे में लोगों से बात करने के लिए एक मेलिंग सूची भी सेट कर सकते हैं, या एक ट्विटर अकाउंट, स्लैक या आईआरसी चैनल बना सकते हैं। या उपरोक्त सभी प्रयास करें!
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) समुदाय के सदस्यों की सहायता के लिए हर दूसरे सप्ताह कार्यालय समय अलग रखें:
+
+> कोप्स के पास समुदाय को सहायता और मार्गदर्शन प्रदान करने के लिए हर दूसरे सप्ताह का समय भी निर्धारित होता है। कोप्स अनुरक्षकों ने नवागंतुकों के साथ काम करने, पीआर के साथ मदद करने और नई सुविधाओं पर चर्चा करने के लिए विशेष रूप से समर्पित समय निर्धारित करने पर सहमति व्यक्त की है।
+
+सार्वजनिक संचार के उल्लेखनीय अपवाद हैं: 1) सुरक्षा मुद्दे और 2) संवेदनशील आचार संहिता का उल्लंघन। आपके पास लोगों के लिए इन मुद्दों की निजी तौर पर रिपोर्ट करने का हमेशा एक तरीका होना चाहिए। यदि आप अपने व्यक्तिगत ईमेल का उपयोग नहीं करना चाहते हैं, तो एक समर्पित ईमेल पता सेट करें।
+
+## अपने समुदाय को बढ़ाना
+
+समुदाय अत्यंत शक्तिशाली हैं. वह शक्ति वरदान या अभिशाप हो सकती है, यह इस बात पर निर्भर करता है कि आप उसका उपयोग कैसे करते हैं। जैसे-जैसे आपके प्रोजेक्ट का समुदाय बढ़ता है, उसे विनाश की नहीं बल्कि निर्माण की शक्ति बनने में मदद करने के कई तरीके हैं।
+
+### बुरे अभिनेताओं को बर्दाश्त न करें
+
+कोई भी लोकप्रिय परियोजना अनिवार्य रूप से ऐसे लोगों को आकर्षित करेगी जो आपके समुदाय को मदद करने के बजाय नुकसान पहुंचाते हैं। वे अनावश्यक बहस शुरू कर सकते हैं, छोटी-छोटी बातों पर विवाद कर सकते हैं, या दूसरों को धमका सकते हैं।
+
+इस प्रकार के लोगों के प्रति शून्य-सहिष्णुता की नीति अपनाने की पूरी कोशिश करें। यदि अनियंत्रित छोड़ दिया जाए, तो नकारात्मक लोग आपके समुदाय के अन्य लोगों को असहज कर देंगे। वे चले भी सकते हैं.
+
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
+  सच तो यह है कि एक सहायक समुदाय का होना महत्वपूर्ण है। मैं अपने सहकर्मियों, मित्रवत इंटरनेट अजनबियों और बातूनी आईआरसी चैनलों की मदद के बिना यह काम कभी नहीं कर पाऊंगा। (...) इससे कम पर समझौता न करें। बेवकूफों के लिए समझौता मत करो.
+  <p markdown="1" class="pquote-credit">
+— @okdistribute, ["FOSS प्रोजेक्ट कैसे चलाएं"](https://okdistribute.xyz/post/okf-de)
+  </p>
+</aside>
+
+आपके प्रोजेक्ट के तुच्छ पहलुओं पर नियमित बहस आपके सहित दूसरों को महत्वपूर्ण कार्यों पर ध्यान केंद्रित करने से विचलित करती है। आपके प्रोजेक्ट में आने वाले नए लोग इन वार्तालापों को देख सकते हैं और भाग नहीं लेना चाहेंगे।
+
+जब आप अपने प्रोजेक्ट पर नकारात्मक व्यवहार होते देखें, तो उसे सार्वजनिक रूप से बताएं। दयालु लेकिन दृढ़ स्वर में बताएं कि उनका व्यवहार स्वीकार्य क्यों नहीं है। यदि समस्या बनी रहती है, तो आपको इसकी आवश्यकता हो सकती है [उन्हें जाने के लिए कहो](../code-of-conduct/#enforcing-your-code-of-conduct). Your [आचार संहिता](../code-of-conduct/) इन वार्तालापों के लिए एक रचनात्मक मार्गदर्शक हो सकता है।
+
+### योगदानकर्ताओं से वहीं मिलें जहां वे हैं
+
+जैसे-जैसे आपका समुदाय बढ़ता है, अच्छा दस्तावेज़ीकरण और अधिक महत्वपूर्ण हो जाता है। आकस्मिक योगदानकर्ता, जो अन्यथा आपके प्रोजेक्ट से परिचित नहीं हो सकते हैं, उन्हें जिस संदर्भ की आवश्यकता है उसे तुरंत प्राप्त करने के लिए आपके दस्तावेज़ को पढ़ें।
+
+अपनी योगदान फ़ाइल में, नए योगदानकर्ताओं को स्पष्ट रूप से बताएं कि शुरुआत कैसे करें। आप इस उद्देश्य के लिए एक समर्पित अनुभाग भी बनाना चाह सकते हैं। उदाहरण के लिए, [Django](https://github.com/django/django) के पास नए योगदानकर्ताओं का स्वागत करने के लिए एक विशेष लैंडिंग पृष्ठ है।
+
+![Django नया योगदानकर्ता पृष्ठ](/assets/images/building-community/django_new_contributors.png)
+
+अपनी समस्या कतार में, ऐसे बग लेबल करें जो विभिन्न प्रकार के योगदानकर्ताओं के लिए उपयुक्त हों: उदाहरण के लिए, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) आपके प्रोजेक्ट में नए व्यक्ति के लिए आपके मुद्दों को तुरंत स्कैन करना और आरंभ करना आसान बनाएं।
+
+अंत में, लोगों को हर कदम पर स्वागत महसूस कराने के लिए अपने दस्तावेज़ का उपयोग करें।
+
+आप उन अधिकांश लोगों के साथ कभी बातचीत नहीं करेंगे जो आपके प्रोजेक्ट पर आते हैं। ऐसे योगदान भी हो सकते हैं जो आपको इसलिए नहीं मिले क्योंकि कोई व्यक्ति डरा हुआ महसूस कर रहा था या नहीं जानता था कि कहां से शुरुआत करें। यहां तक ​​कि कुछ दयालु शब्द भी किसी को हताशा में आपका प्रोजेक्ट छोड़ने से रोक सकते हैं।
+
+उदाहरण के लिए, यहां बताया गया है कि कैसे [Rubinius](https://github.com/rubinius/rubinius/) प्रारंभ होगा [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+> हम रुबिनियस का उपयोग करने के लिए आपको धन्यवाद कहकर शुरुआत करना चाहते हैं। यह परियोजना प्यार का परिश्रम है, और हम उन सभी उपयोगकर्ताओं की सराहना करते हैं जो बग पकड़ते हैं, प्रदर्शन में सुधार करते हैं और दस्तावेज़ीकरण में मदद करते हैं। प्रत्येक योगदान सार्थक है, इसलिए भाग लेने के लिए धन्यवाद। जैसा कि कहा जा रहा है, यहां कुछ दिशानिर्देश दिए गए हैं जिनका पालन करने के लिए हम आपसे कहते हैं ताकि हम आपकी समस्या का सफलतापूर्वक समाधान कर सकें।
+
+### अपने प्रोजेक्ट का स्वामित्व साझा करें
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
+  आपके नेताओं की अलग-अलग राय होगी, जैसा कि सभी स्वस्थ समुदायों को होना चाहिए! हालाँकि, आपको यह सुनिश्चित करने के लिए कदम उठाने की ज़रूरत है कि सबसे ऊँची आवाज़ हमेशा लोगों को थका कर जीत न दिलाए, और कम प्रमुख और अल्पसंख्यक आवाज़ें सुनी जाएँ।
+  <p markdown="1" class="pquote-credit">
+— @sagesharp, ["एक अच्छा समुदाय क्या बनता है?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+  </p>
+</aside>
+
+जब लोग स्वामित्व की भावना महसूस करते हैं तो वे परियोजनाओं में योगदान देने के लिए उत्साहित होते हैं। इसका मतलब यह नहीं है कि आपको अपने प्रोजेक्ट के दृष्टिकोण को बदलना होगा या उन योगदानों को स्वीकार करना होगा जो आप नहीं चाहते हैं। लेकिन जितना अधिक आप दूसरों को श्रेय देंगे, उतना ही अधिक वे आपके साथ बने रहेंगे।
+
+देखें कि क्या आप अपने समुदाय के साथ स्वामित्व को यथासंभव साझा करने के तरीके ढूंढ सकते हैं। यहाँ कुछ विचार हैं:
+
+* **आसान (गैर-महत्वपूर्ण) बग को ठीक करने का विरोध करें।** इसके बजाय, उन्हें नए योगदानकर्ताओं को भर्ती करने के अवसर के रूप में उपयोग करें, या किसी ऐसे व्यक्ति का मार्गदर्शन करें जो योगदान देना चाहता है। यह पहली बार में अस्वाभाविक लग सकता है, लेकिन आपका निवेश समय के साथ फल देगा। उदाहरण के लिए, @michaeljoseph ने एक योगदानकर्ता से इसे स्वयं ठीक करने के बजाय नीचे दिए गए [कुकीकटर](https://github.com/audreyr/cookiecutter) मुद्दे पर एक पुल अनुरोध सबमिट करने के लिए कहा।
+
+![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
+
+* **अपने प्रोजेक्ट में एक योगदानकर्ता या लेखक फ़ाइल प्रारंभ करें** जिसमें आपके प्रोजेक्ट में योगदान देने वाले सभी लोगों की सूची हो, जैसे [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) 
+करता है.
+
+* यदि आपके पास एक बड़ा समुदाय है, तो **एक समाचार पत्र भेजें या एक ब्लॉग पोस्ट लिखें** योगदानकर्ताओं को धन्यवाद दें। जंग का [This Week in Rust](https://this-week-in-rust.org/) और हुडीज़ [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) दो अच्छे उदाहरण हैं.
+
+* **प्रत्येक योगदानकर्ता को पहुंच प्रदान करें** @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/)** और कम से कम एक बैकअप व्यवस्थापक जोड़ें. संगठन बाहरी सहयोगियों के साथ परियोजनाओं पर काम करना आसान बनाते हैं।
+
+हकीकत तो यही है [most projects only have](https://peerj.com/preprints/1233/) एक या दो अनुरक्षक जो अधिकांश कार्य करते हैं। आपका प्रोजेक्ट जितना बड़ा होगा, और आपका समुदाय जितना बड़ा होगा, सहायता पाना उतना ही आसान होगा।
+
+हालाँकि आपको कॉल का उत्तर देने के लिए हमेशा कोई नहीं मिल सकता है, लेकिन वहाँ सिग्नल लगाने से अन्य लोगों के कॉल करने की संभावना बढ़ जाती है। और आप जितनी जल्दी शुरुआत करेंगे, उतनी जल्दी लोग मदद कर सकते हैं।
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
+  \[यह आपके हित में है\] ऐसे योगदानकर्ताओं को भर्ती करना जो आनंद लेते हैं और जो वह काम करने में सक्षम हैं जो आप नहीं कर सकते। क्या आपको कोडिंग में मजा आता है, लेकिन मुद्दों का जवाब देना नहीं? फिर अपने समुदाय में उन व्यक्तियों की पहचान करें जो ऐसा करते हैं और उन्हें ऐसा करने दें।
+  <p markdown="1" class="pquote-credit">
+— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+  </p>
+</aside>
+
+## विवादों का समाधान
+
+आपके प्रोजेक्ट के शुरुआती चरणों में, बड़े निर्णय लेना आसान होता है। जब आप कुछ करना चाहते हैं, तो आप बस उसे करते हैं।
+
+जैसे-जैसे आपका प्रोजेक्ट अधिक लोकप्रिय होगा, अधिक लोग आपके निर्णयों में रुचि लेंगे। भले ही आपके पास योगदानकर्ताओं का एक बड़ा समुदाय न हो, यदि आपके प्रोजेक्ट में बहुत सारे उपयोगकर्ता हैं, तो आप पाएंगे कि लोग निर्णयों पर विचार कर रहे हैं या अपने स्वयं के मुद्दे उठा रहे हैं।
+
+अधिकांश भाग के लिए, यदि आपने एक मैत्रीपूर्ण, सम्मानजनक समुदाय विकसित किया है और अपनी प्रक्रियाओं को खुले तौर पर प्रलेखित किया है, तो आपका समुदाय समाधान खोजने में सक्षम होना चाहिए। लेकिन कभी-कभी आप ऐसे मुद्दे में फंस जाते हैं जिसका समाधान करना थोड़ा कठिन होता है।
+
+### दयालुता का स्तर निर्धारित करें
+
+जब आपका समुदाय किसी कठिन मुद्दे से जूझ रहा हो, तो गुस्सा बढ़ सकता है। लोग क्रोधित या निराश हो सकते हैं और इसे एक-दूसरे पर या आप पर निकाल सकते हैं।
+
+एक अनुरक्षक के रूप में आपका काम इन स्थितियों को बढ़ने से रोकना है। भले ही विषय पर आपकी राय मजबूत हो, लड़ाई में कूदने और अपने विचारों को आगे बढ़ाने के बजाय एक मॉडरेटर या फैसिलिटेटर की स्थिति लेने का प्रयास करें। यदि कोई निर्दयी हो रहा है या बातचीत पर एकाधिकार जमा रहा है, [act immediately](../building-community/#dont-tolerate-bad-actors) 
+चर्चाओं को सभ्य और उत्पादक बनाए रखना।
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
+एक प्रोजेक्ट अनुरक्षक के रूप में, अपने योगदानकर्ताओं के प्रति सम्मानजनक होना बेहद महत्वपूर्ण है। वे अक्सर आप जो कहते हैं उसे बहुत व्यक्तिगत रूप से लेते हैं।
+  <p markdown="1" class="pquote-credit">
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+  </p>
+</aside>
+
+अन्य लोग मार्गदर्शन के लिए आपकी ओर देख रहे हैं। अच्छा उदाहरण स्थापित करो। आप अभी भी निराशा, नाखुशी या चिंता व्यक्त कर सकते हैं, लेकिन ऐसा शांति से करें।
+
+खुद को शांत रखना आसान नहीं है, लेकिन नेतृत्व प्रदर्शित करने से आपके समुदाय के स्वास्थ्य में सुधार होता है। इंटरनेट आपका धन्यवाद करता है.
+
+### अपने README को एक संविधान मानें
+
+आपका README है [more than just a set of instructions](../starting-a-project/#writing-a-readme). यह आपके लक्ष्यों, उत्पाद दृष्टिकोण और रोडमैप के बारे में बात करने का भी स्थान है। यदि लोग किसी विशेष सुविधा की योग्यता पर बहस करने पर अत्यधिक ध्यान केंद्रित कर रहे हैं, तो यह आपके README पर दोबारा गौर करने और आपके प्रोजेक्ट की उच्च दृष्टि के बारे में बात करने में मदद कर सकता है। अपने README पर ध्यान केंद्रित करने से बातचीत भी अवैयक्तिक हो जाती है, जिससे आप रचनात्मक चर्चा कर सकते हैं।
+
+### यात्रा पर ध्यान दें, मंजिल पर नहीं
+
+कुछ परियोजनाएँ प्रमुख निर्णय लेने के लिए मतदान प्रक्रिया का उपयोग करती हैं। पहली नज़र में समझदार होते हुए भी, मतदान एक-दूसरे की चिंताओं को सुनने और संबोधित करने के बजाय "उत्तर" पाने पर जोर देता है।
+
+मतदान राजनीतिक हो सकता है, जहां समुदाय के सदस्य एक-दूसरे का पक्ष लेने या एक निश्चित तरीके से मतदान करने के लिए दबाव महसूस करते हैं। चाहे वह कोई भी हो, हर कोई वोट नहीं देता [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) आपके समुदाय में, या वर्तमान उपयोगकर्ताओं को, जिन्हें नहीं पता था कि वोट हो रहा है।
+
+कभी-कभी, मतदान एक आवश्यक टाईब्रेकर होता है। हालाँकि, जितना आप सक्षम हैं, आम सहमति के बजाय ["आम सहमति की तलाश"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) पर जोर दें।
+
+सर्वसम्मति प्राप्त करने की प्रक्रिया के तहत, समुदाय के सदस्य प्रमुख चिंताओं पर तब तक चर्चा करते हैं जब तक उन्हें नहीं लगता कि उन्हें पर्याप्त रूप से सुना गया है। जब केवल छोटी-मोटी चिंताएँ बची रहती हैं, तो समुदाय आगे बढ़ता है। "आम सहमति की मांग" यह स्वीकार करती है कि एक समुदाय एक सटीक उत्तर तक पहुंचने में सक्षम नहीं हो सकता है। इसके बजाय, यह सुनने और चर्चा को प्राथमिकता देता है।
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
+  एटम मुद्दों के लिए वोटिंग प्रणाली मौजूद न होने का एक कारण यह है कि एटम टीम सभी मामलों में वोटिंग प्रणाली का पालन नहीं करेगी। कभी-कभी हमें वही चुनना पड़ता है जो हमें सही लगता है, भले ही वह अलोकप्रिय हो। (...) मैं जो पेशकश कर सकता हूं और करने की प्रतिज्ञा कर सकता हूं...वह यह है कि समुदाय की बात सुनना मेरा काम है।
+  <p markdown="1" class="pquote-credit">
+— @lee-dohm on Atom's decision making process
+  </p>
+</aside>
+
+भले ही आप वास्तव में सर्वसम्मति प्राप्त करने की प्रक्रिया नहीं अपनाते हों, एक परियोजना अनुरक्षक के रूप में, यह महत्वपूर्ण है कि लोग जानें कि आप सुन रहे हैं। अन्य लोगों को यह महसूस कराना कि उनकी बात सुनी जा रही है, और उनकी चिंताओं को हल करने के लिए प्रतिबद्ध होना, संवेदनशील स्थितियों को दूर करने में काफी मदद करता है। फिर, अपने शब्दों को कार्यों के साथ जारी रखें।
+
+किसी संकल्प के लिए निर्णय लेने में जल्दबाजी न करें। सुनिश्चित करें कि हर कोई यह महसूस करे कि समाधान की ओर बढ़ने से पहले सभी जानकारी सार्वजनिक कर दी गई है।
+
+### बातचीत को कार्रवाई पर केंद्रित रखें
+
+चर्चा महत्वपूर्ण है, लेकिन उत्पादक और अनुत्पादक बातचीत में अंतर है।
+
+चर्चा को तब तक प्रोत्साहित करें जब तक यह सक्रिय रूप से समाधान की ओर बढ़ रही हो। यदि यह स्पष्ट है कि बातचीत धीमी हो रही है या विषय से भटक रही है, तीखी नोकझोंक व्यक्तिगत होती जा रही है, या लोग छोटी-छोटी बातों को लेकर झगड़ रहे हैं, तो इसे बंद करने का समय आ गया है।
+
+इन वार्तालापों को जारी रखने की अनुमति देना न केवल मौजूदा मुद्दे के लिए बुरा है, बल्कि आपके समुदाय के स्वास्थ्य के लिए भी बुरा है। यह एक संदेश भेजता है कि इस प्रकार की बातचीत की अनुमति है या इसे प्रोत्साहित भी किया जाता है, और यह लोगों को भविष्य के मुद्दों को उठाने या हल करने से हतोत्साहित कर सकता है।
+
+आपके द्वारा या दूसरों द्वारा उठाए गए प्रत्येक बिंदु पर, अपने आप से पूछें, _"यह हमें किसी समाधान के करीब कैसे लाता है?"_
+
+यदि बातचीत सुलझने लगी है, तो बातचीत पर फिर से ध्यान केंद्रित करने के लिए समूह से पूछें, _"हमें आगे कौन सा कदम उठाना चाहिए?"_
+
+यदि बातचीत स्पष्ट रूप से कहीं नहीं जा रही है, कोई स्पष्ट कार्रवाई नहीं की जानी है, या उचित कार्रवाई पहले ही की जा चुकी है, तो मुद्दे को बंद करें और बताएं कि आपने इसे क्यों बंद किया।
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  बिना किसी दबाव के किसी धागे को उपयोगिता की ओर ले जाना एक कला है। केवल लोगों को अपना समय बर्बाद करना बंद करने की चेतावनी देना, या उन्हें पोस्ट न करने के लिए कहना, जब तक कि उनके पास कहने के लिए कुछ रचनात्मक न हो, काम नहीं करेगा। (...) इसके बजाय, आपको आगे की प्रगति के लिए शर्तों का सुझाव देना होगा: लोगों को एक मार्ग दें, अनुसरण करने के लिए एक रास्ता जो आपके इच्छित परिणामों की ओर ले जाए, फिर भी ऐसा लगे बिना कि आप आचरण निर्धारित कर रहे हैं।
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+  </p>
+</aside>
+
+### अपनी लड़ाइयाँ बुद्धिमानी से चुनें
+
+प्रसंग महत्वपूर्ण है. विचार करें कि चर्चा में कौन शामिल है और वे शेष समुदाय का प्रतिनिधित्व कैसे करते हैं।
+
+क्या समुदाय में हर कोई इस मुद्दे से परेशान है, या इससे जुड़ा भी है? या एक अकेला उपद्रवी है? केवल सक्रिय आवाज़ों पर ही नहीं, बल्कि अपने मूक समुदाय के सदस्यों पर भी विचार करना न भूलें।
+
+यदि मुद्दा आपके समुदाय की व्यापक आवश्यकताओं का प्रतिनिधित्व नहीं करता है, तो आपको बस कुछ लोगों की चिंताओं को स्वीकार करने की आवश्यकता हो सकती है। यदि यह बिना किसी स्पष्ट समाधान के बार-बार आने वाला मुद्दा है, तो उन्हें विषय पर पिछली चर्चाओं की ओर इंगित करें और थ्रेड बंद कर दें।
+
+### एक सामुदायिक टाईब्रेकर की पहचान करें
+
+अच्छे रवैये और स्पष्ट संचार के साथ, अधिकांश कठिन परिस्थितियाँ हल हो सकती हैं। हालाँकि, एक सार्थक बातचीत में भी, कैसे आगे बढ़ना है, इस पर राय में अंतर हो सकता है। इन मामलों में, ऐसे व्यक्ति या लोगों के समूह की पहचान करें जो टाईब्रेकर के रूप में काम कर सकते हैं।
+
+एक टाईब्रेकर परियोजना का प्राथमिक अनुरक्षक हो सकता है, या यह लोगों का एक छोटा समूह हो सकता है जो मतदान के आधार पर निर्णय लेता है। आदर्श रूप से, आपने गवर्नेंस फ़ाइल का उपयोग करने से पहले उसमें एक टाईब्रेकर और संबंधित प्रक्रिया की पहचान कर ली है।
+
+आपका टाईब्रेकर अंतिम उपाय होना चाहिए। विभाजनकारी मुद्दे आपके समुदाय के लिए बढ़ने और सीखने का एक अवसर हैं। इन अवसरों को स्वीकार करें और जहां भी संभव हो समाधान की ओर बढ़ने के लिए सहयोगात्मक प्रक्रिया का उपयोग करें।
+
+## समुदाय खुले स्रोत का ❤️ है
+
+स्वस्थ, संपन्न समुदाय हर सप्ताह खुले स्रोत में खर्च किए गए हजारों घंटों को ऊर्जा प्रदान करते हैं। कई योगदानकर्ता खुले स्रोत पर काम करने - या काम न करने - का कारण अन्य लोगों को बताते हैं। रचनात्मक रूप से उस शक्ति का उपयोग करना सीखकर, आप किसी को अविस्मरणीय ओपन सोर्स अनुभव प्राप्त करने में मदद करेंगे।
diff --git a/_articles/hi/code-of-conduct.md b/_articles/hi/code-of-conduct.md
new file mode 100644
index 00000000000..3c3d187ae79
--- /dev/null
+++ b/_articles/hi/code-of-conduct.md
@@ -0,0 +1,114 @@
+---
+lang: en
+title: Your Code of Conduct
+description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct.
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+  - building
+  - leadership
+---
+
+## Why do I need a code of conduct?
+
+A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.
+
+Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.
+
+A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with.
+
+## Establishing a code of conduct
+
+Try to establish a code of conduct as early as possible: ideally, when you first create your project.
+
+In addition to communicating your expectations, a code of conduct describes the following:
+
+* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_
+* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_
+* What happens if someone violates the code of conduct
+* How someone can report violations
+
+Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
+
+The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples.
+
+Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
+
+## Deciding how you'll enforce your code of conduct
+
+<aside markdown="1" class="pquote">
+  A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
+  <p markdown="1" class="pquote-credit">
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+  </p>
+</aside>
+
+You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:
+
+* It demonstrates that you are serious about taking action when it's needed.
+
+* Your community will feel more reassured that complaints actually get reviewed.
+
+* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.
+
+You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
+
+Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+
+For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+
+## Enforcing your code of conduct
+
+Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up.
+
+### Gather information about the situation
+
+Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment.
+
+The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context.
+
+Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
+
+<aside markdown="1" class="pquote">
+  Don’t get pulled into an argument. Don’t get sidetracked into dealing with someone else’s behavior before you’ve finished dealing with the matter at hand. Focus on what you need.
+  <p markdown="1" class="pquote-credit">
+— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+  </p>
+</aside>
+
+### Take appropriate action
+
+After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward.
+
+When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise.
+
+There are a few ways you might respond to a code of conduct violation:
+
+* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication.
+
+* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them.
+
+Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example:
+
+* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project
+
+* **Permanently ban** the person from the project
+
+Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached.
+
+## Your responsibilities as a maintainer
+
+A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes.
+
+As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community.
+
+A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable.
+
+In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way.
+
+## Encourage the behavior you want to see in the world 🌎
+
+When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow.
diff --git a/_articles/hi/finding-users.md b/_articles/hi/finding-users.md
new file mode 100644
index 00000000000..61e7b3e98ff
--- /dev/null
+++ b/_articles/hi/finding-users.md
@@ -0,0 +1,148 @@
+---
+lang: en
+title: Finding Users for Your Project
+description: Help your open source project grow by getting it in the hands of happy users.
+class: finding
+order: 3
+image: /assets/images/cards/finding.png
+related:
+  - beginners
+  - building
+---
+
+## Spreading the word
+
+There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work!
+
+## Figure out your message
+
+Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters.
+
+What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance.
+
+Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want.
+
+For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
+
+![Cartography README](/assets/images/finding-users/cartography.jpg)
+
+For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+
+## Help people find and follow your project
+
+<aside markdown="1" class="pquote">
+  You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
+  <p markdown="1" class="pquote-credit">
+— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+  </p>
+</aside>
+
+Help people find and remember your project by pointing them to a single namespace.
+
+**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.
+
+If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
+  A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project.
+  <p markdown="1" class="pquote-credit">
+— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+  </p>
+</aside>
+
+**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_.
+
+If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+
+![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
+
+Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!
+
+## Go where your project's audience is (online)
+
+Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
+
+Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
+  Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project.
+  <p markdown="1" class="pquote-credit">
+— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+  </p>
+</aside>
+
+See if you can find ways to share your project in relevant ways:
+
+* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.
+* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.
+* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work.
+
+Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want.
+
+If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication.
+
+## Go where your project's audience is (offline)
+
+![Public speaking](/assets/images/finding-users/public_speaking.jpg)
+
+Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.
+
+If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
+  I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
+  <p markdown="1" class="pquote-credit">
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+  </p>
+</aside>
+
+If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.
+
+As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.
+
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
+  When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+  <p markdown="1" class="pquote-credit">
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+  </p>
+</aside>
+
+When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.
+
+Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
+  I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?
+  <p markdown="1" class="pquote-credit">
+— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+  </p>
+</aside>
+
+## Build a reputation
+
+In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.
+
+Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
+  The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+  <p markdown="1" class="pquote-credit">
+— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+  </p>
+</aside>
+
+It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others.
+
+There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.
+
+## Keep at it!
+
+It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.
diff --git a/_articles/hi/getting-paid.md b/_articles/hi/getting-paid.md
new file mode 100644
index 00000000000..7fd4a32af4c
--- /dev/null
+++ b/_articles/hi/getting-paid.md
@@ -0,0 +1,178 @@
+---
+lang: en
+title: Getting Paid for Open Source Work
+description: Sustain your work in open source by getting financial support for your time or your project.
+class: getting-paid
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+  - best-practices
+  - leadership
+---
+
+## Why some people seek financial support
+
+Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
+I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+  <p markdown="1" class="pquote-credit">
+— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+  </p>
+</aside>
+
+There are many reasons why a person would not want to be paid for their open source work.
+
+* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
+* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
+* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
+  Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+  <p markdown="1" class="pquote-credit">
+— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+  </p>
+</aside>
+
+For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+
+Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
+  Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+  <p markdown="1" class="pquote-credit">
+— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+  </p>
+</aside>
+
+Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
+   OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+  <p markdown="1" class="pquote-credit">
+— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+  </p>
+</aside>
+
+If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+
+## Funding your own time
+
+Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+
+It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+
+If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+
+Many companies are developing open source programs to build their brand and recruit quality talent.
+
+@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+
+> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+
+If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
+  Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+  <p markdown="1" class="pquote-credit">
+— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+  </p>
+</aside>
+
+If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+
+* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
+* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+
+Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+
+Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
+
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
+* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
+* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+Finally, sometimes open source projects put bounties on issues that you might consider helping with.
+
+* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
+* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+
+## Finding funding for your project
+
+Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+
+Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas.
+
+As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+
+### Raise money for your work through crowdfunding campaigns or sponsorships
+
+Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
+A few examples of sponsored projects include:
+
+* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
+* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+
+### Create a revenue stream
+
+Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
+* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
+* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+
+Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+
+### Apply for grant funding
+
+Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+
+For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+
+## Building a case for financial support
+
+Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+
+Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+
+### Impact
+
+Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+
+### Traction
+
+Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+
+### Value to funder
+
+Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+
+### Use of funds
+
+What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+
+### How you'll receive the funds
+
+Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
+  For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+  <p markdown="1" class="pquote-credit">
+— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+  </p>
+</aside>
+
+## Experiment and don't give up
+
+Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md
new file mode 100644
index 00000000000..17a04ad9821
--- /dev/null
+++ b/_articles/hi/how-to-contribute.md
@@ -0,0 +1,520 @@
+---
+lang: en
+title: How to Contribute to Open Source
+description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans.
+class: contribute
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+  - beginners
+  - building
+---
+
+## Why contribute to open source?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
+  Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+  <p markdown="1" class="pquote-credit">
+— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+  </p>
+</aside>
+
+Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+
+Why do people contribute to open source? Plenty of reasons!
+
+### Improve software you rely on
+
+Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+
+### Improve existing skills
+
+Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+
+### Meet people who are interested in similar things
+
+Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+
+### Find mentors and teach others
+
+Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+
+### Build public artifacts that help you grow a reputation (and a career)
+
+By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+
+### Learn people skills
+
+Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+
+### It's empowering to be able to make changes, even small ones
+
+You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+
+## What it means to contribute
+
+If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+
+Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+
+### You don't have to contribute code
+
+A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
+  I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+  <p markdown="1" class="pquote-credit">
+— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+  </p>
+</aside>
+
+Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+
+### Do you like planning events?
+
+* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Organize the project's conference (if they have one)
+* Help community members find the right conferences and submit proposals for speaking
+
+### Do you like to design?
+
+* Restructure layouts to improve the project's usability
+* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Put together a style guide to help the project have a consistent visual design
+* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+
+### Do you like to write?
+
+* Write and improve the project's documentation
+* Curate a folder of examples showing how the project is used
+* Start a newsletter for the project, or curate highlights from the mailing list
+* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Write a translation for the project's documentation
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
+  Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+  <p markdown="1" class="pquote-credit">
+— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+  </p>
+</aside>
+
+### Do you like organizing?
+
+* Link to duplicate issues, and suggest new issue labels, to keep things organized
+* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
+* Ask clarifying questions on recently opened issues to move the discussion forward
+
+### Do you like to code?
+
+* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Ask if you can help write a new feature
+* Automate project setup
+* Improve tooling and testing
+
+### Do you like helping people?
+
+* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
+* Answer questions for people on open issues
+* Help moderate the discussion boards or conversation channels
+
+### Do you like helping others code?
+
+* Review code on other people's submissions
+* Write tutorials for how a project can be used
+* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### You don't just have to work on software projects!
+
+While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+
+For example:
+
+* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
+* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
+* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+
+Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
+
+## Orienting yourself to a new project
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
+  If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+  <p markdown="1" class="pquote-credit">
+— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+  </p>
+</aside>
+
+For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+
+Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
+
+### Anatomy of an open source project
+
+Every open source community is different.
+
+Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+
+That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+
+A typical open source project has the following types of people:
+
+* **Author:** The person/s or organization that created the project
+* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
+* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
+* **Contributors:** Everyone who has contributed something back to the project
+* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+
+Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+
+A project also has documentation. These files are usually listed in the top level of a repository.
+
+* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
+* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
+* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
+* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
+* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.
+
+Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+
+* **Issue tracker:** Where people discuss issues related to the project.
+* **Pull requests:** Where people discuss and review changes that are in progress.
+* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
+* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
+
+## Finding a project to contribute to
+
+Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+
+If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_
+
+Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+
+Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+
+Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+
+Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+
+You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
+
+> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+
+If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+You can also use one of the following resources to help you discover and contribute to new projects:
+
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+
+### A checklist before you contribute
+
+When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+
+Here's a handy checklist to evaluate whether a project is good for new contributors.
+
+**Meets the definition of open source**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+  </label>
+</div>
+
+**Project actively accepts contributions**
+
+Look at the commit activity on the main branch. On GitHub, you can see this information on a repository's homepage.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+  When was the latest commit?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+  How many contributors does the project have?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  </label>
+</div>
+
+Next, look at the project's issues.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    How many open issues are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to issues when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Are the issues recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+  </label>
+</div>
+
+Now do the same for the project's pull requests.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    How many open pull requests are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox20" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to pull requests when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the pull requests?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    Are the pull requests recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox13" class="overflow-hidden d-block text-normal">
+    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+  </label>
+</div>
+
+**Project is welcoming**
+
+A project that is friendly and welcoming signals that they will be receptive to new contributors.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox14" class="overflow-hidden d-block text-normal">
+    Do the maintainers respond helpfully to questions in issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox15" class="overflow-hidden d-block text-normal">
+    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox16" class="overflow-hidden d-block text-normal">
+    Do pull requests get reviewed?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox17" class="overflow-hidden d-block text-normal">
+    Do maintainers thank people for their contributions?
+  </label>
+</div>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+  </p>
+</aside>
+
+## How to submit a contribution
+
+You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+
+### Communicating effectively
+
+Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
+  \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+  <p markdown="1" class="pquote-credit">
+— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+  </p>
+</aside>
+
+Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+
+**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+
+> 😇 _"X doesn't happen when I do Y"_
+>
+> 😢 _"X is broken! Please fix it."_
+
+**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn.
+
+> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+>
+> 😢 _"How do I X?"_
+
+**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+
+> 😇 _"I'd like to write an API tutorial."_
+>
+> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+
+**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+
+> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+>
+> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+
+**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+
+> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+>
+> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+
+**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+
+> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+>
+> 😢 _"Why won't you support my use case? This is unacceptable!"_
+
+**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+
+### Gathering context
+
+Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+
+If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request:
+
+* **Issues** are like starting a conversation or discussion
+* **Pull requests** are for starting work on a solution
+* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
+  You'll learn <em>a lot</em> from taking a single project you actively use, "watching" it on GitHub and reading every issue and PR.
+<p markdown="1" class="pquote-credit">
+— @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
+  </p>
+</aside>
+
+### Opening an issue
+
+You should usually open an issue in the following situations:
+
+* Report an error you can't solve yourself
+* Discuss a high-level topic or idea (for example, community, vision or policies)
+* Propose a new feature or other project idea
+
+Tips for communicating on issues:
+
+* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
+* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
+* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+
+### Opening a pull request
+
+You should usually open a pull request in the following situations:
+
+* Submit trivial fixes (for example, a typo, a broken link or an obvious error)
+* Start work on a contribution that was already asked for, or that you've already discussed, in an issue
+
+A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
+
+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/).)
+* **[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.
+* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
+* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+
+If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+
+## What happens after you submit a contribution
+
+You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
+
+After you submit a contribution, one of the following will happen:
+
+### 😭 You don't get a response.
+
+Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+
+If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+
+**Don't** reach out to that person privately; remember that public communication is vital to open source projects.
+
+If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+
+### 🚧 Someone requests changes to your contribution.
+
+It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+
+When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it.
+
+If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
+
+### 👎 Your contribution doesn't get accepted.
+
+Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+
+### 🎉 Your contribution gets accepted.
+
+Hooray! You've successfully made an open source contribution!
+
+## You did it!
+
+Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
diff --git a/_articles/hi/index.html b/_articles/hi/index.html
new file mode 100644
index 00000000000..ef7a7cb9a84
--- /dev/null
+++ b/_articles/hi/index.html
@@ -0,0 +1,5 @@
+---
+layout: index
+lang: hi
+permalink: /hi/
+---
diff --git a/_articles/hi/leadership-and-governance.md b/_articles/hi/leadership-and-governance.md
new file mode 100644
index 00000000000..6fd75930d5d
--- /dev/null
+++ b/_articles/hi/leadership-and-governance.md
@@ -0,0 +1,156 @@
+---
+lang: en
+title: Leadership and Governance
+description: Growing open source projects can benefit from formal rules for making decisions.
+class: leadership
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+  - best-practices
+  - metrics
+---
+
+## Understanding governance for your growing project
+
+Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+
+## What are examples of formal roles used in open source projects?
+
+Many projects follow a similar structure for contributor roles and recognition.
+
+What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+
+* **Maintainer**
+* **Contributor**
+* **Committer**
+
+**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+
+A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+
+**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+  </p>
+</aside>
+
+**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+
+While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
+  You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+  <p markdown="1" class="pquote-credit">
+— @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+  </p>
+</aside>
+
+## How do I formalize these leadership roles?
+
+Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+
+For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+
+For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+
+If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+
+<aside markdown="1" class="pquote">
+  \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+  <p markdown="1" class="pquote-credit">
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+  </p>
+</aside>
+
+Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+
+Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+
+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).
+
+## When should I give someone commit access?
+
+Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
+  Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+  <p markdown="1" class="pquote-credit">
+— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+  </p>
+</aside>
+
+## What are some of the common governance structures for open source projects?
+
+There are three common governance structures associated with open source projects.
+
+* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+
+* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+
+* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
+
+Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Do I need governance docs when I launch my project?
+
+There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+
+Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+
+If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
+  We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+  <p markdown="1" class="pquote-credit">
+— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+  </p>
+</aside>
+
+## What happens if corporate employees start submitting contributions?
+
+Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+
+As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+
+It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+
+"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+
+Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+
+## Do I need a legal entity to support my project?
+
+You don't need a legal entity to support your open source project unless you're handling money.
+
+For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+
+If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+
+Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
+  Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+  <p markdown="1" class="pquote-credit">
+— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+  </p>
+</aside>
+
+If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md
new file mode 100644
index 00000000000..8adc3897659
--- /dev/null
+++ b/_articles/hi/legal.md
@@ -0,0 +1,158 @@
+---
+lang: en
+title: The Legal Side of Open Source
+description: Everything you've ever wondered about the legal side of open source, and a few things you didn't.
+class: legal
+order: 10
+image: /assets/images/cards/legal.png
+related:
+  - contribute
+  - leadership
+---
+
+## Understanding the legal implications of open source
+
+Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+
+## Why do people care so much about the legal side of open source?
+
+Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+
+In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+
+If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+
+Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
+
+## 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**.
+
+![Create repository](/assets/images/legal/repo-create-name.png)
+
+**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+
+If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+
+## Just give me the TL;DR on what I need to protect my project.
+
+You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+
+[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 the most popular open source 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/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
+  A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+  <p markdown="1" class="pquote-credit">
+— @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+  </p>
+</aside>
+
+## Which open source license is appropriate for my project?
+
+If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+
+Otherwise, picking the right open source license for your project depends on your objectives.
+
+Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+
+On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+
+You may also want to consider the **communities** you hope will use and contribute to your project:
+
+* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
+* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
+* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+
+Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+
+When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+
+## What if I want to change the license of my project?
+
+Most projects never need to change licenses. But occasionally circumstances change.
+
+For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+
+**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+
+**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+
+**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+
+Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+
+## 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).
+
+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.
+
+Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
+    We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+  <p markdown="1" class="pquote-credit">
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+  </p>
+</aside>
+
+Some situations where you may want to consider an additional contributor agreement for your project include:
+
+* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
+* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
+* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
+* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
+* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
+
+If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+
+## What does my company's legal team need to know?
+
+If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+
+For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+
+**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+
+* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+
+* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+
+* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
+
+* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+
+* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+
+If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+
+Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+
+* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
+  Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+  <p markdown="1" class="pquote-credit">
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+  </p>
+</aside>
+
+* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
+* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+
+<aside markdown="1" class="pquote">
+  Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+  <p markdown="1" class="pquote-credit">
+— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+  </p>
+</aside>
+
+* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
+* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
diff --git a/_articles/hi/maintaining-balance-for-open-source-maintainers.md b/_articles/hi/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..51d312d3499
--- /dev/null
+++ b/_articles/hi/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: en
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/hi/metrics.md b/_articles/hi/metrics.md
new file mode 100644
index 00000000000..145dd18119b
--- /dev/null
+++ b/_articles/hi/metrics.md
@@ -0,0 +1,128 @@
+---
+lang: en
+title: Open Source Metrics
+description: Make informed decisions to help your open source project thrive by measuring and tracking its success.
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+  - finding
+  - best-practices
+---
+
+## Why measure anything?
+
+Data, when used wisely, can help you make better decisions as an open source maintainer.
+
+With more information, you can:
+
+* Understand how users respond to a new feature
+* Figure out where new users come from
+* Identify, and decide whether to support, an outlier use case or functionality
+* Quantify your project's popularity
+* Understand how your project is used
+* Raise money through sponsorships and grants
+
+For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+
+> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+
+Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+
+If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+
+## Discovery
+
+Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+
+![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:
+
+* **Total page views:** Tells you how many times your project was viewed
+
+* **Total unique visitors:** Tells you how many people viewed your project
+
+* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+
+* **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.
+
+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.
+
+## Usage
+
+People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+
+If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+
+Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+
+If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+
+![Clone graph](/assets/images/metrics/clone_graph.png)
+
+If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+
+* Your project isn't successfully converting your audience, or
+* You're attracting the wrong audience
+
+For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+
+Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+
+Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+
+## Retention
+
+People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+
+It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+
+Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+
+Examples of community metrics that you may want to regularly track include:
+
+* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+
+![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+
+* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+
+* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+
+* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+
+* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
+  Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+  <p markdown="1" class="pquote-credit">
+— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+  </p>
+</aside>
+
+## Maintainer activity
+
+Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+
+Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+
+[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+
+Consider [tracking how long it takes for you (or another maintainer) to respond to contributions](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+
+You could also measure the time it takes to move between stages in the contribution process, such as:
+
+* Average time an issue remains open
+* Whether issues get closed by PRs
+* Whether stale issues get closed
+* Average time to merge a pull request
+
+## Use 📊 to learn about people
+
+Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+
+[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health.
diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md
new file mode 100644
index 00000000000..15b01773ef7
--- /dev/null
+++ b/_articles/hi/starting-a-project.md
@@ -0,0 +1,356 @@
+---
+lang: en
+title: Starting an Open Source Project
+description: Learn more about the world of open source and get ready to launch your own project.
+class: beginners
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+  - finding
+  - building
+---
+
+## The "what" and "why" of open source
+
+So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+
+### What does "open source" mean?
+
+When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+
+Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+
+_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+
+### Why do people open source their work?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+  One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+  <p markdown="1" class="pquote-credit">
+— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+  </p>
+</aside>
+
+[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+
+* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+
+* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+
+Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+
+### Does open source mean "free of charge"?
+
+One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+
+Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+
+As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+
+## Should I launch my own open source project?
+
+The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+
+If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+
+Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+
+If you're not yet convinced, take a moment to think about what your goals might be.
+
+### Setting your goals
+
+Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself,  _why am I open sourcing this project?_
+
+There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+
+If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+  At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+  <p markdown="1" class="pquote-credit">
+— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+  </p>
+</aside>
+
+As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+
+While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+
+**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+
+If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+  As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+  <p markdown="1" class="pquote-credit">
+— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+  </p>
+</aside>
+
+### Contributing to other projects
+
+If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+
+If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+
+## Launching your own open source project
+
+There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+
+Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+
+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/)
+* [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.
+
+If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+
+### Choosing a license
+
+An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+
+Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+
+[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 the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+
+When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+
+![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+
+If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+
+### Writing a README
+
+READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+
+In your README, try to answer the following questions:
+
+* What does this project do?
+* Why is this project useful?
+* How do I get started?
+* Where can I get more help, if I need it?
+
+You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+  Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+  <p markdown="1" class="pquote-credit">
+— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+  </p>
+</aside>
+
+Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+
+For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+
+When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+
+### Writing your contributing guidelines
+
+A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+
+* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
+* How to suggest a new feature
+* How to set up your environment and run tests
+
+In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+
+* The types of contributions you're looking for
+* Your roadmap or vision for the project
+* How contributors should (or should not) get in touch with you
+
+Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+
+For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+
+> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+
+In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+
+Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+
+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.
+
+![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+
+### Establishing a code of conduct
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+  We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+  <p markdown="1" class="pquote-credit">
+— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+  </p>
+</aside>
+
+Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+
+For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+
+In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+
+Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+
+Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+
+## Naming and branding your project
+
+Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+
+### Choosing the right name
+
+Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+
+* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
+* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+
+If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+
+Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+
+### Avoiding name conflicts
+
+[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+
+If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+
+Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+
+You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+
+Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+
+### How you write (and code) affects your brand, too!
+
+Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+
+Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+  <p markdown="1" class="pquote-credit">
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+
+Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+
+It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+
+## 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.
+
+**Documentation**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Project has a LICENSE file with an open source license
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    The issue queue is up-to-date, with issues clearly organized and labeled
+  </label>
+</div>
+
+**Code**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Project uses consistent code conventions and clear function/method/variable names
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    The code is clearly commented, documenting intentions and edge cases
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+  </label>
+</div>
+
+**People**
+
+If you're an individual:
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  </label>
+</div>
+
+If you're a company or organization:
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    You've talked to your legal department
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    You have a marketing plan for announcing and promoting the project
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    At least two people have administrative access to the project
+  </label>
+</div>
+
+## You did it!
+
+Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.

From acce4cc6191c5cbde78d3304ad0658e482908cd0 Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Thu, 31 Aug 2023 11:15:21 +0530
Subject: [PATCH 481/749] hindi update

---
 _articles/hi/best-practices.md  |  12 ++--
 _articles/hi/code-of-conduct.md | 106 ++++++++++++++---------------
 _articles/hi/finding-users.md   | 114 ++++++++++++++++----------------
 _articles/hi/index.html         |   1 +
 4 files changed, 117 insertions(+), 116 deletions(-)

diff --git a/_articles/hi/best-practices.md b/_articles/hi/best-practices.md
index 52982086e51..1613e0d2809 100644
--- a/_articles/hi/best-practices.md
+++ b/_articles/hi/best-practices.md
@@ -45,7 +45,7 @@ related:
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
   मैंने इसे गलती से किया। मैंने किसी पूर्ण समाधान को लाने के लिए प्रयास नहीं किया। आधे-पूरे समाधान की जगह, मुझे खेद है कि मैंने यह नहीं कहा "मेरे पास इसके लिए अभी समय नहीं है, लेकिन मैं इसे दीर्घकालिक सूची में जोड़ दूंगा जिसे हमारे लिए अच्छा हो सकता है।"
   <p markdown="1" class="pquote-credit">
-— @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
+— @lord, ["नए ओपन सोर्स अनुरक्षकों के लिए युक्तियाँ"](https://lord.io/blog/2014/oss-tips/)
   </p>
 </aside>
 
@@ -102,7 +102,7 @@ related:
   <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
   बड़े स्केल के ओपन सोर्स प्रोजेक्ट्स के समर्थन को हैंडल करने की कुंजी है, मुद्दों को आगे बढ़ाने की कोशिश करें। मुद्दों को ठप करने से बचने का प्रयास करें। यदि आप एक iOS डेवलपर हैं, तो आप जानते हैं कि रेडर्स (radars) सबमिट करना कितना खिचड़ हो सकता है। आप 2 साल बाद प्रतिक्रिया प्राप्त कर सकते हैं, और आपको नवीनतम iOS संस्करण के साथ पुनः प्रयास करने की सलाह दी जा सकती है।
   <p markdown="1" class="pquote-credit">
-— @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
+— @KrauseFx, ["ओपन सोर्स समुदायों को स्केल करना"](https://krausefx.com/blog/scaling-open-source-communities)
   </p>
 </aside>
 
@@ -149,7 +149,7 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
   आदर्श रूप से, उन्हें CONTRIBUTING.md फ़ाइल में समझाएं कि वे भविष्य में काम शुरू करने से पहले बेहतर संकेत कैसे प्राप्त कर सकते हैं कि क्या स्वीकार किया जाएगा या क्या नहीं।
   <p markdown="1" class="pquote-credit">
-— @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
+— @MikeMcQuaid, ["कृपया पुल अनुरोध बंद करें"](https://github.com/blog/2124-kindly-closing-pull-requests)
   </p>
 </aside>
 
@@ -179,7 +179,7 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
   मैं कह रहा था, "हाँ, कोई भी शामिल हो सकता है, आपके पास बहुत अधिक कोडिंग विशेषज्ञता होनी आवश्यक नहीं है [...]।" हमारे पास लोगों ने [एक कार्यक्रम में] आने के लिए साइन अप किया था और तभी मैं वास्तव में सोच रहा था: क्या यह सच है, जो मैं कह रहा हूं? वहाँ 40 लोग आने वाले हैं, और ऐसा नहीं है कि मैं उनमें से प्रत्येक के साथ बैठ सकता हूँ...लेकिन लोग एक साथ आए, और यह काम कर गया। जैसे ही एक व्यक्ति को यह मिल गया, वे अपने पड़ोसी को सिखा सकते थे।
   <p markdown="1" class="pquote-credit">
-—  @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+—  @lmccart, ["ओपन सोर्स" का क्या मतलब है? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
   </p>
 </aside>
 
@@ -201,7 +201,7 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user
   <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
   मैं 80% उपयोग के मामले को पूरा करता हूं। यदि आप यूनिकॉर्न में से एक हैं, तो कृपया मेरे काम को छोड़ दें। मैं नाराज नहीं होऊंगा! मेरी सार्वजनिक परियोजनाएँ लगभग हमेशा सबसे आम समस्याओं को हल करने के लिए होती हैं; मैं या तो अपने काम को आगे बढ़ाकर या इसे विस्तारित करके गहराई तक जाना आसान बनाने की कोशिश करता हूं।
   <p markdown="1" class="pquote-credit">
-— @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+— @geerlingguy, ["मैं पीआर क्यों बंद करता हूँ?"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
   </p>
 </aside>
 
@@ -227,7 +227,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's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust का सामुदायिक स्वचालन"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/hi/code-of-conduct.md b/_articles/hi/code-of-conduct.md
index 3c3d187ae79..bd1c46ae7a0 100644
--- a/_articles/hi/code-of-conduct.md
+++ b/_articles/hi/code-of-conduct.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Your Code of Conduct
-description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct.
+lang: hi
+title: आपकी आचार संहिता
+description: आचार संहिता को अपनाकर और लागू करके स्वस्थ और रचनात्मक सामुदायिक व्यवहार को सुविधाजनक बनाना।
 class: coc
 order: 8
 image: /assets/images/cards/coc.png
@@ -10,105 +10,105 @@ related:
   - leadership
 ---
 
-## Why do I need a code of conduct?
+## मुझे आचार संहिता की आवश्यकता क्यों है?
 
-A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.
+आचार संहिता एक दस्तावेज है जो आपके प्रोजेक्ट के प्रतिभागियों के लिए व्यवहार की अपेक्षाएं स्थापित करता है। आचार संहिता को अपनाने और लागू करने से आपके समुदाय के लिए एक सकारात्मक सामाजिक माहौल बनाने में मदद मिल सकती है।
 
-Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.
+आचार संहिता न केवल आपके प्रतिभागियों को, बल्कि स्वयं को भी सुरक्षित रखने में मदद करती है। यदि आप किसी प्रोजेक्ट को बनाए रखते हैं, तो आप पा सकते हैं कि अन्य प्रतिभागियों का अनुत्पादक रवैया आपको समय के साथ अपने काम के बारे में थका हुआ या नाखुश महसूस करा सकता है।
 
-A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with.
+आचार संहिता आपको स्वस्थ, रचनात्मक सामुदायिक व्यवहार को सुविधाजनक बनाने के लिए सशक्त बनाती है। सक्रिय रहने से यह संभावना कम हो जाती है कि आप या अन्य लोग अपने प्रोजेक्ट से थक जाएंगे, और जब कोई ऐसा कुछ करता है जिससे आप सहमत नहीं हैं तो आपको कार्रवाई करने में मदद मिलती है।
 
-## Establishing a code of conduct
+## आचार संहिता स्थापित करना
 
-Try to establish a code of conduct as early as possible: ideally, when you first create your project.
+यथाशीघ्र एक आचार संहिता स्थापित करने का प्रयास करें: आदर्श रूप से, जब आप पहली बार अपना प्रोजेक्ट बनाते हैं।
 
-In addition to communicating your expectations, a code of conduct describes the following:
+आपकी अपेक्षाओं को संप्रेषित करने के अलावा, आचार संहिता निम्नलिखित का वर्णन करती है:
 
-* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_
-* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_
-* What happens if someone violates the code of conduct
-* How someone can report violations
+* जहां आचार संहिता प्रभावी होती है _(केवल मुद्दों और पुल अनुरोधों, या घटनाओं जैसी सामुदायिक गतिविधियों पर?)_
+*आचार संहिता किस पर लागू होती है _(समुदाय के सदस्यों और अनुरक्षकों पर, लेकिन प्रायोजकों के बारे में क्या?)_
+*यदि कोई आचार संहिता का उल्लंघन करता है तो क्या होगा
+* कोई कैसे उल्लंघन की रिपोर्ट कर सकता है
 
-Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
+जहां भी आप कर सकें, पूर्व कला का उपयोग करें। [योगदानकर्ता अनुबंध](https://contributor-covenant.org/) एक ड्रॉप-इन आचार संहिता है जिसका उपयोग कुबेरनेट्स, रेल्स और स्विफ्ट सहित 40,000 से अधिक ओपन सोर्स परियोजनाओं द्वारा किया जाता है।
 
-The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples.
+The [Django आचार संहिता](https://www.djangoproject.com/conduct/) और यह [नागरिक आचार संहिता](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) आचार संहिता के दो अच्छे उदाहरण भी हैं।
 
-Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
+एक CODE_OF_CONDUCT फ़ाइल अपने प्रोजेक्ट की रूट डायरेक्टरी में फ़ाइल में रखें, और इसे अपने समुदाय से जोड़कर इसे अपने समुदाय के लिए दृश्यमान बनाएं CONTRIBUTING या README फ़ाइल.
 
-## Deciding how you'll enforce your code of conduct
+## यह निर्णय लेना कि आप अपनी आचार संहिता को कैसे लागू करेंगे
 
 <aside markdown="1" class="pquote">
-  A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
+  एक आचार संहिता जिसे लागू नहीं किया जाता (या नहीं किया जा सकता) वह किसी भी आचार संहिता के न होने से भी बदतर है: यह संदेश भेजती है कि आचार संहिता में मौजूद मूल्य वास्तव में आपके समुदाय में महत्वपूर्ण या सम्मानित नहीं हैं।
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+— [Ada पहल](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
-You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:
+उल्लंघन होने से **_पहले_** आपको स्पष्ट करना चाहिए कि आपकी आचार संहिता कैसे लागू की जाएगी। ऐसा करने के कई कारण हैं:
 
-* It demonstrates that you are serious about taking action when it's needed.
+* यह दर्शाता है कि आप जरूरत पड़ने पर कार्रवाई करने को लेकर गंभीर हैं।
 
-* Your community will feel more reassured that complaints actually get reviewed.
+* आपका समुदाय अधिक आश्वस्त महसूस करेगा कि शिकायतों की वास्तव में समीक्षा की जाती है।
 
-* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.
+* आप अपने समुदाय को आश्वस्त करेंगे कि समीक्षा प्रक्रिया निष्पक्ष और पारदर्शी है, क्या उन्हें कभी भी उल्लंघन के लिए जांच में पाया जाएगा।
 
-You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
+आपको लोगों को आचार संहिता के उल्लंघन की रिपोर्ट करने का एक निजी तरीका (जैसे ईमेल पता) देना चाहिए और यह बताना चाहिए कि वह रिपोर्ट कौन प्राप्त करता है। यह एक अनुरक्षक, अनुरक्षकों का समूह या आचार संहिता कार्य समूह हो सकता है।
 
-Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+यह मत भूलिए कि हो सकता है कि कोई व्यक्ति उस व्यक्ति के बारे में उल्लंघन की रिपोर्ट करना चाहता हो जो उन रिपोर्टों को प्राप्त करता है। इस मामले में, उन्हें किसी अन्य को उल्लंघन की रिपोर्ट करने का विकल्प दें। उदाहरण के लिए,@ctb and @mr-c [उनके प्रोजेक्ट पर स्पष्टीकरण दें](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
-> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+> अपमानजनक, परेशान करने वाले, या अन्यथा अस्वीकार्य व्यवहार के मामलों की रिपोर्ट **khmer-project@idyll.org** पर ईमेल करके की जा सकती है, जो केवल सी. टाइटस ब्राउन और माइकल आर. क्रूसो को जाती है। उनमें से किसी एक से जुड़े मुद्दे की रिपोर्ट करने के लिए कृपया विज्ञान और प्रौद्योगिकी के लिए एक एनएसएफ केंद्र, बीकॉन सेंटर फॉर द स्टडी ऑफ इवोल्यूशन इन एक्शन में विविधता निदेशक **जूडी ब्राउन क्लार्क, पीएच.डी.** को ईमेल करें।*
 
-For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+प्रेरणा के लिए, Django का [प्रवर्तन मैनुअल](https://www.djangoproject.com/conduct/enforcement-manual/) देखें (हालाँकि, आपके प्रोजेक्ट के आकार के आधार पर, आपको इतनी व्यापक चीज़ की आवश्यकता नहीं हो सकती है).
 
-## Enforcing your code of conduct
+## अपनी आचार संहिता लागू करना
 
-Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up.
+कभी-कभी, आपके सर्वोत्तम प्रयासों के बावजूद, कोई ऐसा कार्य करेगा जो इस संहिता का उल्लंघन करता है। नकारात्मक या हानिकारक व्यवहार सामने आने पर उससे निपटने के कई तरीके हैं।
 
-### Gather information about the situation
+### स्थिति के बारे में जानकारी इकट्ठा करें
 
-Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment.
+समुदाय के प्रत्येक सदस्य की आवाज़ को अपनी आवाज़ के समान महत्वपूर्ण मानें। यदि आपको कोई रिपोर्ट मिलती है कि किसी ने आचार संहिता का उल्लंघन किया है, तो इसे गंभीरता से लें और मामले की जांच करें, भले ही वह उस व्यक्ति के साथ आपके अपने अनुभव से मेल न खाता हो। ऐसा करना आपके समुदाय को संकेत देता है कि आप उनके दृष्टिकोण को महत्व देते हैं और उनके निर्णय पर भरोसा करते हैं।
 
-The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context.
+विचाराधीन समुदाय का सदस्य बार-बार अपराधी हो सकता है जो लगातार दूसरों को असहज महसूस कराता है, या हो सकता है कि उसने केवल एक बार ही कुछ कहा या किया हो। संदर्भ के आधार पर दोनों ही कार्रवाई करने के आधार हो सकते हैं।
 
-Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
+प्रतिक्रिया देने से पहले, स्वयं को यह समझने का समय दें कि क्या हुआ था। यह बेहतर ढंग से समझने के लिए कि वे कौन हैं और उन्होंने ऐसा व्यवहार क्यों किया होगा, उस व्यक्ति की पिछली टिप्पणियों और बातचीत को पढ़ें। इस व्यक्ति और उनके व्यवहार के बारे में अपने अलावा अन्य दृष्टिकोण इकट्ठा करने का प्रयास करें।
 
 <aside markdown="1" class="pquote">
-  Don’t get pulled into an argument. Don’t get sidetracked into dealing with someone else’s behavior before you’ve finished dealing with the matter at hand. Focus on what you need.
+  किसी बहस में न पड़ें. इससे पहले कि आप मौजूदा मामले से निपट लें, किसी और के व्यवहार से निपटने में पीछे न हटें। आपको जो चाहिए उस पर ध्यान दें.
   <p markdown="1" class="pquote-credit">
-— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+— Stephanie Zvan, ["तो आपके पास अपने लिए एक पॉलिसी है। अब क्या?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
   </p>
 </aside>
 
-### Take appropriate action
+### उचित कार्रवाई करें
 
-After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward.
+पर्याप्त जानकारी एकत्र करने और संसाधित करने के बाद, आपको यह निर्णय लेना होगा कि क्या करना है। जब आप अपने अगले कदमों पर विचार करें, तो याद रखें कि एक मॉडरेटर के रूप में आपका लक्ष्य एक सुरक्षित, सम्मानजनक और सहयोगात्मक वातावरण को बढ़ावा देना है। न केवल इस बात पर विचार करें कि संबंधित स्थिति से कैसे निपटा जाए, बल्कि यह भी कि आपकी प्रतिक्रिया आपके समुदाय के बाकी व्यवहार और अपेक्षाओं को कैसे प्रभावित करेगी।
 
-When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise.
+जब कोई आचार संहिता के उल्लंघन की रिपोर्ट करता है, तो इसे संभालना उनका नहीं, आपका काम है। कभी-कभी, रिपोर्टर अपने करियर, प्रतिष्ठा या शारीरिक सुरक्षा को बहुत जोखिम में डालकर जानकारी का खुलासा कर रहा है। उन्हें अपने उत्पीड़क का सामना करने के लिए मजबूर करना रिपोर्टर को समझौतावादी स्थिति में डाल सकता है। आपको संबंधित व्यक्ति के साथ सीधा संवाद संभालना चाहिए, जब तक कि रिपोर्टर स्पष्ट रूप से अन्यथा अनुरोध न करे।
 
-There are a few ways you might respond to a code of conduct violation:
+ऐसे कुछ तरीके हैं जिनसे आप आचार संहिता के उल्लंघन पर प्रतिक्रिया दे सकते हैं:
 
-* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication.
+* **संबंधित व्यक्ति को सार्वजनिक चेतावनी दें** और बताएं कि उनके व्यवहार ने दूसरों पर कैसे नकारात्मक प्रभाव डाला, अधिमानतः उस चैनल में जहां यह हुआ। जहां संभव हो, सार्वजनिक संचार शेष समुदाय को बताता है कि आप आचार संहिता को गंभीरता से लेते हैं। दयालु बनें, लेकिन अपने संचार में दृढ़ रहें।
 
-* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them.
+* **व्यक्तिगत रूप से उस व्यक्ति तक पहुंचें**यह समझाने के लिए कि उनके व्यवहार ने दूसरों पर कैसे नकारात्मक प्रभाव डाला। यदि स्थिति में संवेदनशील व्यक्तिगत जानकारी शामिल है तो आप निजी संचार चैनल का उपयोग करना चाह सकते हैं। यदि आप किसी के साथ निजी तौर पर संवाद करते हैं, तो उन लोगों को सीसी देना एक अच्छा विचार है जिन्होंने सबसे पहले स्थिति की सूचना दी थी, ताकि वे जान सकें कि आपने कार्रवाई की है। सीसी देने से पहले रिपोर्टिंग व्यक्ति से सहमति मांगें।
 
-Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example:
+कभी-कभी, किसी समाधान तक नहीं पहुंचा जा सकता. सामना किए जाने पर संबंधित व्यक्ति आक्रामक या शत्रुतापूर्ण हो सकता है या अपना व्यवहार नहीं बदलता है। इस स्थिति में, आप कड़ी कार्रवाई करने पर विचार कर सकते हैं। उदाहरण के लिए:
 
-* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project
+* **परियोजना के किसी भी पहलू में भाग लेने पर अस्थायी प्रतिबंध के माध्यम से लागू, परियोजना से संबंधित व्यक्ति को निलंबित करें**
 
-* **Permanently ban** the person from the project
+* **प्रोजेक्ट से व्यक्ति को स्थायी रूप से प्रतिबंधित** करें
 
-Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached.
+सदस्यों पर प्रतिबंध लगाना हल्के में नहीं लिया जाना चाहिए और यह दृष्टिकोण में स्थायी और अपूरणीय अंतर का प्रतिनिधित्व करता है। आपको ये उपाय केवल तभी करना चाहिए जब यह स्पष्ट हो कि किसी समाधान पर नहीं पहुंचा जा सकता।
 
-## Your responsibilities as a maintainer
+## एक अनुरक्षक के रूप में आपकी जिम्मेदारियाँ
 
-A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes.
+आचार संहिता कोई ऐसा कानून नहीं है जिसे मनमाने ढंग से लागू किया जाए। आप आचार संहिता के प्रवर्तक हैं और आचार संहिता द्वारा स्थापित नियमों का पालन करना आपकी जिम्मेदारी है।
 
-As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community.
+एक अनुरक्षक के रूप में आप अपने समुदाय के लिए दिशानिर्देश स्थापित करते हैं और उन दिशानिर्देशों को अपनी आचार संहिता में निर्धारित नियमों के अनुसार लागू करते हैं। इसका अर्थ है आचार संहिता उल्लंघन की किसी भी रिपोर्ट को गंभीरता से लेना। रिपोर्टर को उनकी शिकायत की गहन और निष्पक्ष समीक्षा करनी चाहिए। यदि आप यह निर्धारित करते हैं कि जिस व्यवहार की उन्होंने रिपोर्ट की है वह उल्लंघन नहीं है, तो उन्हें स्पष्ट रूप से बताएं और बताएं कि आप इस पर कार्रवाई क्यों नहीं करने जा रहे हैं। वे इसके साथ क्या करते हैं यह उन पर निर्भर है: उस व्यवहार को सहन करें जिससे उन्हें कोई समस्या थी, या समुदाय में भाग लेना बंद कर दें।
 
-A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable.
+व्यवहार की एक रिपोर्ट जो तकनीकी रूप से आचार संहिता का उल्लंघन नहीं करती है, फिर भी यह संकेत दे सकती है कि आपके समुदाय में कोई समस्या है, और आपको इस संभावित समस्या की जांच करनी चाहिए और तदनुसार कार्य करना चाहिए। इसमें स्वीकार्य व्यवहार को स्पष्ट करने के लिए अपनी आचार संहिता को संशोधित करना और/या उस व्यक्ति से बात करना शामिल हो सकता है जिसके व्यवहार की रिपोर्ट की गई थी और उन्हें यह बताना कि हालांकि उन्होंने आचार संहिता का उल्लंघन नहीं किया है, वे जो अपेक्षित है उससे किनारा कर रहे हैं और निश्चित कर रहे हैं। प्रतिभागी असहज महसूस करते हैं।
 
-In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way.
+अंत में, एक अनुरक्षक के रूप में, आप स्वीकार्य व्यवहार के लिए मानक निर्धारित और लागू करते हैं। आपके पास परियोजना के सामुदायिक मूल्यों को आकार देने की क्षमता है, और प्रतिभागी आपसे उन मूल्यों को निष्पक्ष और समान तरीके से लागू करने की उम्मीद करते हैं।
 
-## Encourage the behavior you want to see in the world 🌎
+## उस व्यवहार को प्रोत्साहित करें जो आप दुनिया में देखना चाहते हैं 🌎
 
-When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow.
+जब कोई परियोजना शत्रुतापूर्ण या अप्रिय लगती है, भले ही वह सिर्फ एक व्यक्ति हो जिसका व्यवहार दूसरों द्वारा सहन किया जाता है, तो आप कई और योगदानकर्ताओं को खोने का जोखिम उठाते हैं, जिनमें से कुछ से आप कभी भी नहीं मिल सकते हैं। आचार संहिता को अपनाना या लागू करना हमेशा आसान नहीं होता है, लेकिन स्वागत योग्य माहौल को बढ़ावा देने से आपके समुदाय को बढ़ने में मदद मिलेगी।
diff --git a/_articles/hi/finding-users.md b/_articles/hi/finding-users.md
index 61e7b3e98ff..94d36a15e3f 100644
--- a/_articles/hi/finding-users.md
+++ b/_articles/hi/finding-users.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Finding Users for Your Project
-description: Help your open source project grow by getting it in the hands of happy users.
+lang: hi
+title: अपने प्रोजेक्ट के लिए उपयोगकर्ता ढूँढना
+description: अपने ओपन सोर्स प्रोजेक्ट को खुश उपयोगकर्ताओं के हाथों में पहुंचाकर उसे बढ़ने में मदद करें।
 class: finding
 order: 3
 image: /assets/images/cards/finding.png
@@ -10,139 +10,139 @@ related:
   - building
 ---
 
-## Spreading the word
+## बातों का प्रसार
 
-There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work!
+ऐसा कोई नियम नहीं है जो कहता हो कि लॉन्च करते समय आपको एक ओपन सोर्स प्रोजेक्ट का प्रचार करना होगा। ओपन सोर्स में काम करने के कई संतोषजनक कारण हैं जिनका लोकप्रियता से कोई लेना-देना नहीं है। यह आशा करने के बजाय कि अन्य लोग आपके ओपन सोर्स प्रोजेक्ट को ढूंढेंगे और उसका उपयोग करेंगे, आपको अपनी कड़ी मेहनत के बारे में प्रचार करना होगा!
 
-## Figure out your message
+## अपने संदेश का पता लगाएं
 
-Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters.
+इससे पहले कि आप अपने प्रोजेक्ट को बढ़ावा देने का वास्तविक काम शुरू करें, आपको यह समझाने में सक्षम होना चाहिए कि यह क्या करता है और यह क्यों मायने रखता है।
 
-What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance.
+आपके प्रोजेक्ट को क्या अलग या दिलचस्प बनाता है? आपने इसे क्यों बनाया? इन प्रश्नों का स्वयं उत्तर देने से आपको अपने प्रोजेक्ट के महत्व के बारे में बताने में मदद मिलेगी।
 
-Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want.
+याद रखें कि लोग उपयोगकर्ता के रूप में शामिल होते हैं, और अंततः योगदानकर्ता बन जाते हैं, क्योंकि आपका प्रोजेक्ट उनके लिए एक समस्या का समाधान करता है। जब आप अपने प्रोजेक्ट के संदेश और मूल्य के बारे में सोचते हैं, तो उन्हें इस नजरिए से देखने का प्रयास करें कि उपयोगकर्ता और योगदानकर्ता क्या चाहते हैं।
 
-For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
+उदाहरण के लिए, @robb अपने प्रोजेक्ट को स्पष्ट रूप से बताने के लिए कोड उदाहरणों का उपयोग करता है, [Cartography](https://github.com/robb/Cartography), उपयोगी है:
 
 ![Cartography README](/assets/images/finding-users/cartography.jpg)
 
-For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+मैसेजिंग के बारे में गहराई से जानने के लिए मोज़िला देखें ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) उपयोगकर्ता व्यक्तित्व विकसित करने के लिए व्यायाम।
 
-## Help people find and follow your project
+## अपने प्रोजेक्ट को ढूंढने और उसका अनुसरण करने में लोगों की सहायता करें
 
 <aside markdown="1" class="pquote">
-  You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
+  आपको आदर्श रूप से एक एकल "होम" यूआरएल की आवश्यकता है जिसे आप प्रचारित कर सकें और अपने प्रोजेक्ट के संबंध में लोगों को इंगित कर सकें। आपको किसी फैंसी टेम्पलेट या यहां तक ​​कि एक डोमेन नाम पर छपने की ज़रूरत नहीं है, लेकिन आपके प्रोजेक्ट को एक केंद्र बिंदु की आवश्यकता है।
   <p markdown="1" class="pquote-credit">
-— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+— Peter Cooper & Robert Nyman, ["अपने कोड के बारे में प्रचार कैसे करें"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
   </p>
 </aside>
 
-Help people find and remember your project by pointing them to a single namespace.
+लोगों को एक ही नामस्थान की ओर इंगित करके अपना प्रोजेक्ट ढूंढने और याद रखने में सहायता करें।
 
-**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.
+**अपने काम को बढ़ावा देने के लिए एक स्पष्ट हैंडल रखें।** एक ट्विटर हैंडल, GitHub URL, या IRC चैनल लोगों को आपके प्रोजेक्ट की ओर इंगित करने का एक आसान तरीका है। ये आउटलेट आपके प्रोजेक्ट के बढ़ते समुदाय को एकत्रित होने की जगह भी देते हैं।
 
-If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides.
+यदि आप अभी तक अपने प्रोजेक्ट के लिए आउटलेट स्थापित नहीं करना चाहते हैं, तो अपने हर काम में अपने स्वयं के ट्विटर या GitHub हैंडल को बढ़ावा दें। आपके ट्विटर या GitHub हैंडल को बढ़ावा देने से लोगों को पता चलेगा कि आपसे कैसे संपर्क किया जाए या आपके काम का अनुसरण किया जाए। यदि आप किसी बैठक या कार्यक्रम में बोलते हैं, तो सुनिश्चित करें कि आपकी संपर्क जानकारी आपके बायो या स्लाइड में शामिल है।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
-  A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project.
+ उन शुरुआती दिनों में मैंने जो गलती की थी (...) वह थी प्रोजेक्ट के लिए ट्विटर अकाउंट शुरू न करना। ट्विटर लोगों को किसी प्रोजेक्ट के बारे में अपडेट रखने के साथ-साथ लोगों को प्रोजेक्ट के बारे में लगातार अवगत कराने का एक शानदार तरीका है।
   <p markdown="1" class="pquote-credit">
-— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+— @nathanmarz, ["अपाचे तूफान का इतिहास और इससे सीखे गए सबक"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
   </p>
 </aside>
 
-**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project.
+**अपने प्रोजेक्ट के लिए एक वेबसाइट बनाने पर विचार करें।** एक वेबसाइट आपके प्रोजेक्ट को मित्रवत और नेविगेट करने में आसान बनाती है, खासकर जब इसे स्पष्ट दस्तावेज़ीकरण और ट्यूटोरियल के साथ जोड़ा जाता है। एक वेबसाइट होने से यह भी पता चलता है कि आपका प्रोजेक्ट सक्रिय है जिससे आपके दर्शकों को इसका उपयोग करने में अधिक सहजता महसूस होगी। लोगों को अपने प्रोजेक्ट का उपयोग करने के तरीके के बारे में विचार देने के लिए उदाहरण प्रदान करें।
 
-[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_.
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django के सह-निर्माता ने कहा कि एक वेबसाइट _"प्रारंभिक दिनों में Django के साथ हमने जो किया वह अब तक का सबसे अच्छा काम था"_.
 
-If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+यदि आपका प्रोजेक्ट GitHub पर होस्ट किया गया है, तो आप इसका उपयोग कर सकते हैं [GitHub Pages](https://pages.github.com/) आसानी से एक वेबसाइट बनाने के लिए. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), और [Middleman](https://middlemanapp.com/) हैं [a few examples](https://github.com/showcases/github-pages-examples) उत्कृष्ट, व्यापक वेबसाइटें।
 
 ![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
 
-Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!
+अब जब भी आपके पास अपने प्रोजेक्ट के लिए एक संदेश है, और लोगों के लिए आपके प्रोजेक्ट को आकर्षित करने का एक आसान तरीका है, तो वहां आएं और अपने दर्शकों से बात करें!
 
-## Go where your project's audience is (online)
+## वहां जाएं जहां आपके प्रोजेक्ट के दर्शक हैं (ऑनलाइन)
 
-Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
+ऑनलाइन आउटरीच बात को तेजी से साझा करने और फैलाने का एक शानदार तरीका है। ऑनलाइन चैनलों का उपयोग करके, आपके पास बहुत व्यापक दर्शकों तक पहुंचने की क्षमता है।
 
-Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+अपने दर्शकों तक पहुंचने के लिए मौजूदा ऑनलाइन समुदायों और प्लेटफार्मों का लाभ उठाएं। यदि आपका ओपन सोर्स प्रोजेक्ट एक सॉफ्टवेयर प्रोजेक्ट है, तो आप संभवतः अपने दर्शकों को ढूंढ सकते हैं [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), या [Quora](https://www.quora.com/). वे चैनल ढूंढें जहां आपको लगता है कि लोगों को आपके काम से सबसे अधिक लाभ होगा या वे आपके काम के बारे में उत्साहित होंगे।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
-  Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project.
+  प्रत्येक प्रोग्राम में बहुत विशिष्ट कार्य होते हैं जो केवल कुछ ही उपयोगकर्ताओं को उपयोगी लगेंगे। जितना संभव हो उतने लोगों को स्पैम न करें। इसके बजाय, अपने प्रयासों को उन समुदायों पर लक्षित करें जिन्हें आपके प्रोजेक्ट के बारे में जानने से लाभ होगा।
   <p markdown="1" class="pquote-credit">
-— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+— @pazdera, ["ओपन सोर्स प्रोजेक्ट्स के लिए मार्केटिंग"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
   </p>
 </aside>
 
-See if you can find ways to share your project in relevant ways:
+देखें कि क्या आप अपने प्रोजेक्ट को प्रासंगिक तरीकों से साझा करने के तरीके ढूंढ सकते हैं:
 
-* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.
-* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.
-* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work.
+* **प्रासंगिक ओपन सोर्स प्रोजेक्ट्स और समुदायों को जानें।** कभी-कभी, आपको सीधे अपने प्रोजेक्ट का प्रचार करने की ज़रूरत नहीं होती है। यदि आपका प्रोजेक्ट पायथन का उपयोग करने वाले डेटा वैज्ञानिकों के लिए एकदम सही है, तो पायथन डेटा विज्ञान समुदाय को जानें। जैसे-जैसे लोग आपको जानने लगेंगे, आपके काम के बारे में बात करने और साझा करने के स्वाभाविक अवसर पैदा होंगे।
+* **उन लोगों को ढूंढें जो उस समस्या का अनुभव कर रहे हैं जिसे आपका प्रोजेक्ट हल करता है।** उन लोगों के लिए संबंधित मंचों के माध्यम से खोजें जो आपके प्रोजेक्ट के लक्षित दर्शकों में आते हैं। उनके प्रश्न का उत्तर दें और समाधान के रूप में अपनी परियोजना का सुझाव देने के लिए, जब उचित हो, एक चतुराईपूर्ण तरीका खोजें।
+* **प्रतिक्रिया के लिए पूछें।** ऐसे दर्शकों के सामने अपना और अपने काम का परिचय दें जिन्हें यह प्रासंगिक और दिलचस्प लगे। इस बारे में स्पष्ट रहें कि आपको क्या लगता है कि आपके प्रोजेक्ट से किसे लाभ होगा। वाक्य को पूरा करने का प्रयास करें: _"मुझे लगता है कि मेरा प्रोजेक्ट वास्तव में एक्स की मदद करेगा, जो Y_ करने की कोशिश कर रहे हैं"। केवल अपने काम का प्रचार करने के बजाय दूसरों की प्रतिक्रिया सुनें और उसका जवाब दें।
 
-Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want.
+सामान्यतया, बदले में चीज़ें मांगने से पहले दूसरों की मदद करने पर ध्यान केंद्रित करें। क्योंकि कोई भी किसी प्रोजेक्ट को आसानी से ऑनलाइन प्रमोट कर सकता है, इसलिए बहुत शोर होगा। भीड़ से अलग दिखने के लिए, लोगों को यह संदर्भ दें कि आप कौन हैं, न कि केवल वह जो आप चाहते हैं।
 
-If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication.
+यदि कोई आपकी आरंभिक पहुंच पर ध्यान नहीं देता है या प्रतिक्रिया नहीं देता है, तो निराश न हों! अधिकांश प्रोजेक्ट लॉन्च एक पुनरावृत्तीय प्रक्रिया है जिसमें महीनों या वर्षों का समय लग सकता है। यदि आपको पहली बार कोई प्रतिक्रिया नहीं मिलती है, तो एक अलग रणनीति आज़माएं, या पहले दूसरों के काम में मूल्य जोड़ने के तरीकों की तलाश करें। अपने प्रोजेक्ट को प्रचारित करने और लॉन्च करने में समय और समर्पण लगता है।
 
-## Go where your project's audience is (offline)
+## वहां जाएं जहां आपके प्रोजेक्ट के दर्शक हैं (ऑफ़लाइन)
 
-![Public speaking](/assets/images/finding-users/public_speaking.jpg)
+![सार्वजनिक रूप से बोलना](/assets/images/finding-users/public_speaking.jpg)
 
-Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.
+ऑफ़लाइन कार्यक्रम दर्शकों के बीच नई परियोजनाओं को बढ़ावा देने का एक लोकप्रिय तरीका है। वे व्यस्त दर्शकों तक पहुंचने और गहरे मानवीय संबंध बनाने का एक शानदार तरीका हैं, खासकर यदि आप डेवलपर्स तक पहुंचने में रुचि रखते हैं।
 
-If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.
+यदि आप [सार्वजनिक भाषण में नए](https://peaking.io/) हैं, तो एक स्थानीय बैठक ढूंढ़कर शुरुआत करें जो आपके प्रोजेक्ट की भाषा या पारिस्थितिकी तंत्र से संबंधित हो।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
-  I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
+  मैं PyCon जाने को लेकर काफी घबराया हुआ था। मैं एक भाषण दे रहा था, मैं वहां केवल कुछ लोगों को जानने वाला था, मैं पूरे एक सप्ताह के लिए जा रहा था। (...) हालाँकि, मुझे चिंतित नहीं होना चाहिए था। PyCon असाधारण रूप से अद्भुत था! (...) हर कोई अविश्वसनीय रूप से मिलनसार और मिलनसार था, इतना कि मुझे लोगों से बात न करने का समय ही नहीं मिल पाता था!
   <p markdown="1" class="pquote-credit">
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["मैंने चिंता करना बंद करना और पाइकॉन से प्यार करना कैसे सीखा"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
   </p>
 </aside>
 
-If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.
+यदि आपने पहले कभी किसी कार्यक्रम में बात नहीं की है, तो घबराहट महसूस होना बिल्कुल सामान्य है! याद रखें कि आपके दर्शक वहां हैं क्योंकि वे वास्तव में आपके काम के बारे में सुनना चाहते हैं।
 
-As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.
+जब आप अपनी बात लिखते हैं, तो इस बात पर ध्यान केंद्रित करें कि आपके दर्शकों को क्या दिलचस्प लगेगा और उन्हें क्या लाभ मिलेगा। अपनी भाषा मित्रतापूर्ण एवं सुगम्य रखें। मुस्कुराएं, सांस लें और आनंद लें।
 
 <aside markdown="1" class="pquote">
   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
-  When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+  जब आप अपनी बातचीत लिखना शुरू करते हैं, तो इससे कोई फर्क नहीं पड़ता कि आपका विषय क्या है, अगर आप अपनी बातचीत को एक कहानी के रूप में देखते हैं जो आप लोगों को बताते हैं तो इससे मदद मिल सकती है।
   <p markdown="1" class="pquote-credit">
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— लीना रेनहार्ड, ["टेक कॉन्फ्रेंस टॉक की तैयारी और लेखन कैसे करें"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
   </p>
 </aside>
 
-When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.
+जब आप तैयार महसूस करें, तो अपने प्रोजेक्ट को बढ़ावा देने के लिए एक सम्मेलन में बोलने पर विचार करें। सम्मेलन आपको अधिक लोगों तक पहुँचने में मदद कर सकते हैं, कभी-कभी दुनिया भर से।
 
-Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers.
+ऐसे सम्मेलनों की तलाश करें जो आपकी भाषा या पारिस्थितिकी तंत्र के लिए विशिष्ट हों। अपना भाषण प्रस्तुत करने से पहले, उपस्थित लोगों के लिए अपनी बात तैयार करने के लिए सम्मेलन पर शोध करें और सम्मेलन में बोलने के लिए स्वीकार किए जाने की संभावना बढ़ाएं। आप अक्सर सम्मेलन के वक्ताओं को देखकर अपने दर्शकों के बारे में अंदाजा लगा सकते हैं।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
-  I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?
+  मैंने JSConf के लोगों को बहुत अच्छा लिखा और उनसे विनती की कि वे मुझे एक स्लॉट दें जहां मैं इसे JSConf EU में प्रस्तुत कर सकूं। (...) जिस चीज़ पर मैं छह महीने से काम कर रहा था, उसे पेश करते हुए मैं बेहद डरा हुआ था। (...) पूरे समय मैं बस यही सोच रहा था, हे भगवान। मैं यहां क्या कर रहा हूं?
   <p markdown="1" class="pquote-credit">
-— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+— @ry, ["Node.js का इतिहास" (वीडियो)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
   </p>
 </aside>
 
-## Build a reputation
+## प्रतिष्ठा बनायें
 
-In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.
+ऊपर उल्लिखित रणनीतियों के अलावा, लोगों को अपने प्रोजेक्ट में साझा करने और योगदान करने के लिए आमंत्रित करने का सबसे अच्छा तरीका उनकी परियोजनाओं को साझा करना और योगदान देना है।
 
-Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships.
+नए लोगों की मदद करना, संसाधन साझा करना और दूसरों की परियोजनाओं में विचारशील योगदान देना आपको सकारात्मक प्रतिष्ठा बनाने में मदद करेगा। ओपन सोर्स समुदाय में एक सक्रिय सदस्य होने से लोगों को आपके काम के संदर्भ में मदद मिलेगी और आपके प्रोजेक्ट पर ध्यान देने और साझा करने की अधिक संभावना होगी। अन्य ओपन सोर्स परियोजनाओं के साथ संबंध विकसित करने से आधिकारिक साझेदारी भी हो सकती है।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
-  The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+  आज urllib3 सबसे लोकप्रिय तृतीय-पक्ष पायथन लाइब्रेरी है, इसका एकमात्र कारण यह है कि यह अनुरोधों का हिस्सा है।
   <p markdown="1" class="pquote-credit">
-— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+— @shazow, ["अपने ओपन सोर्स प्रोजेक्ट को कैसे सफल बनाएं"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
   </p>
 </aside>
 
-It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others.
+अपनी प्रतिष्ठा बनाना शुरू करने के लिए कभी भी बहुत जल्दी या बहुत देर नहीं होती है। भले ही आपने अपना खुद का प्रोजेक्ट पहले ही लॉन्च कर दिया हो, दूसरों की मदद करने के तरीकों की तलाश जारी रखें।
 
-There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.
+दर्शक वर्ग बनाने का कोई रातोरात समाधान नहीं है। दूसरों का विश्वास और सम्मान हासिल करने में समय लगता है, और आपकी प्रतिष्ठा बनाना कभी ख़त्म नहीं होता।
 
-## Keep at it!
+## बने रहिए!
 
-It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.
+लोगों को आपके ओपन सोर्स प्रोजेक्ट पर ध्यान देने में काफी समय लग सकता है। वह ठीक है! आज की कुछ सबसे लोकप्रिय परियोजनाओं को गतिविधि के उच्च स्तर तक पहुंचने में वर्षों लग गए। यह आशा करने के बजाय कि आपका प्रोजेक्ट अनायास लोकप्रियता हासिल कर लेगा, संबंध बनाने पर ध्यान केंद्रित करें। धैर्य रखें और अपना काम उन लोगों के साथ साझा करते रहें जो इसकी सराहना करते हैं।
diff --git a/_articles/hi/index.html b/_articles/hi/index.html
index ef7a7cb9a84..454d05a6705 100644
--- a/_articles/hi/index.html
+++ b/_articles/hi/index.html
@@ -1,5 +1,6 @@
 ---
 layout: index
+title: ओपन सोर्स गाइड
 lang: hi
 permalink: /hi/
 ---

From bd78cd3a6a9c6c107477915a0310cacc182d92cf Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Thu, 31 Aug 2023 22:20:33 +0530
Subject: [PATCH 482/749] hindi --articles update

---
 _articles/hi/getting-paid.md                  | 162 +++++++++---------
 _articles/hi/leadership-and-governance.md     | 117 ++++++-------
 _articles/hi/legal.md                         | 144 ++++++++--------
 ...ing-balance-for-open-source-maintainers.md | 142 +++++++--------
 _articles/hi/metrics.md                       | 126 +++++++-------
 _data/locales/hi.yml                          |   2 +-
 6 files changed, 350 insertions(+), 343 deletions(-)

diff --git a/_articles/hi/getting-paid.md b/_articles/hi/getting-paid.md
index 7fd4a32af4c..c0aaf21f9d4 100644
--- a/_articles/hi/getting-paid.md
+++ b/_articles/hi/getting-paid.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Getting Paid for Open Source Work
-description: Sustain your work in open source by getting financial support for your time or your project.
+lang: hi
+title: ओपन सोर्स कार्य के लिए भुगतान प्राप्त करना
+description: अपने समय या अपने प्रोजेक्ट के लिए वित्तीय सहायता प्राप्त करके अपने काम को खुले स्रोत में बनाए रखें।
 class: getting-paid
 order: 7
 image: /assets/images/cards/getting-paid.png
@@ -10,169 +10,171 @@ related:
   - leadership
 ---
 
-## Why some people seek financial support
+## कुछ लोग वित्तीय सहायता क्यों चाहते हैं?
 
-Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+ओपन सोर्स का अधिकांश कार्य स्वैच्छिक है। उदाहरण के लिए, हो सकता है कि किसी को अपने द्वारा उपयोग किए जा रहे किसी प्रोजेक्ट में बग का सामना करना पड़े और वह त्वरित समाधान सबमिट कर दे, या हो सकता है कि वे अपने खाली समय में किसी ओपन सोर्स प्रोजेक्ट के साथ छेड़छाड़ करने का आनंद लें।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
-I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+मैं एक "शौक" प्रोग्रामिंग प्रोजेक्ट की तलाश में था जो क्रिसमस के आसपास के सप्ताह के दौरान मुझे व्यस्त रखे। (...) मेरे पास एक घरेलू कंप्यूटर था, और मेरे हाथ में और कुछ नहीं था। मैंने उस नई स्क्रिप्टिंग भाषा के लिए एक दुभाषिया लिखने का निर्णय लिया जिसके बारे में मैं हाल ही में सोच रहा था। (...) मैंने कार्यकारी शीर्षक के रूप में पायथन को चुना।
   <p markdown="1" class="pquote-credit">
-— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+— @gvanrossum, ["प्रोग्रामिंग Python"](https://www.python.org/doc/essays/foreword/)
   </p>
 </aside>
 
-There are many reasons why a person would not want to be paid for their open source work.
+ऐसे कई कारण हैं जिनकी वजह से कोई व्यक्ति अपने ओपन सोर्स कार्य के लिए भुगतान नहीं करना चाहेगा।
 
-* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
-* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
-* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+* **उनके पास पहले से ही एक पूर्णकालिक नौकरी हो सकती है जो उन्हें पसंद है,** जो उन्हें अपने खाली समय में ओपन सोर्स में योगदान करने में सक्षम बनाती है।
+* **वे ओपन सोर्स को एक शौक** या रचनात्मक पलायन के रूप में सोचने का आनंद लेते हैं और अपनी परियोजनाओं पर काम करने के लिए वित्तीय रूप से बाध्य महसूस नहीं करना चाहते हैं।
+* **उन्हें ओपन सोर्स में योगदान करने से अन्य लाभ मिलते हैं,** जैसे कि उनकी प्रतिष्ठा या पोर्टफोलियो बनाना, एक नया कौशल सीखना, या किसी समुदाय के करीब महसूस करना।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
-  Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+  वित्तीय दान कुछ लोगों के लिए ज़िम्मेदारी की भावना जोड़ता है। (...) यह हमारे लिए महत्वपूर्ण है, विश्व स्तर पर जुड़ी हुई, तेज़ गति वाली दुनिया में जिसमें हम रहते हैं, यह कहने में सक्षम होना कि "अभी नहीं, मुझे कुछ पूरी तरह से अलग करने का मन है"।
   <p markdown="1" class="pquote-credit">
-— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+— @alloy, ["हम दान स्वीकार क्यों नहीं करते?"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
   </p>
 </aside>
 
-For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+दूसरों के लिए, विशेष रूप से जब योगदान जारी है या महत्वपूर्ण समय की आवश्यकता है, तो ओपन सोर्स में योगदान करने के लिए भुगतान प्राप्त करना ही एकमात्र तरीका है जिससे वे भाग ले सकते हैं, या तो क्योंकि परियोजना को इसकी आवश्यकता है, या व्यक्तिगत कारणों से।
 
-Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
+लोकप्रिय परियोजनाओं को बनाए रखना एक महत्वपूर्ण जिम्मेदारी हो सकती है, जिसमें प्रति माह कुछ घंटों के बजाय प्रति सप्ताह 10 या 20 घंटे लगते हैं।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
-  Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+  किसी भी ओपन सोर्स प्रोजेक्ट अनुरक्षक से पूछें, और वे आपको किसी प्रोजेक्ट को प्रबंधित करने में लगने वाले काम की मात्रा की वास्तविकता के बारे में बताएंगे। आपके पास ग्राहक हैं. आप उनके लिए समस्याएं ठीक कर रहे हैं. आप नई सुविधाएँ बना रहे हैं. यह आपके समय की वास्तविक मांग बन जाती है।
   <p markdown="1" class="pquote-credit">
-— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+— @ashedryden, ["अवैतनिक श्रम की नैतिकता और ओएसएस समुदाय"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
   </p>
 </aside>
 
-Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+भुगतान किया गया कार्य जीवन के विभिन्न क्षेत्रों के लोगों को सार्थक योगदान देने में भी सक्षम बनाता है। कुछ लोग अपनी वर्तमान वित्तीय स्थिति, ऋण, या परिवार या अन्य देखभाल संबंधी दायित्वों के आधार पर, ओपन सोर्स परियोजनाओं पर अवैतनिक समय बिताने का जोखिम नहीं उठा सकते हैं। इसका मतलब है कि दुनिया कभी भी उन प्रतिभाशाली लोगों के योगदान को नहीं देखती है जो स्वेच्छा से अपना समय नहीं दे सकते। इसके नैतिक निहितार्थ हैं, जैसा कि @ashedryden [ने वर्णन किया है](https://www.ashedryden.com/blog/the-ethics-of-unread-labor-and-the-oss-community), क्योंकि जो काम किया गया है वह है उन लोगों के पक्ष में पक्षपातपूर्ण जिनके पास पहले से ही जीवन में लाभ हैं, जो बाद में अपने स्वैच्छिक योगदान के आधार पर अतिरिक्त लाभ प्राप्त करते हैं, जबकि अन्य जो स्वयंसेवा करने में सक्षम नहीं होते हैं उन्हें बाद में अवसर नहीं मिलते हैं, जो खुले स्रोत में विविधता की वर्तमान कमी को मजबूत करता है समुदाय।
 
 <aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
-   OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+  <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar"> 
+OSS प्रौद्योगिकी उद्योग को बड़े पैमाने पर लाभ पहुंचाता है, जिसका अर्थ है सभी उद्योगों को लाभ। (...) हालाँकि, यदि केवल वे लोग ही भाग्यशाली और जुनूनी हैं जो इस पर ध्यान केंद्रित कर सकते हैं, तो इसमें एक बड़ी अप्रयुक्त क्षमता है।
   <p markdown="1" class="pquote-credit">
-— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+— @isaacs, ["पैसा और ओपन सोर्स"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
   </p>
 </aside>
 
-If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+यदि आप वित्तीय सहायता की तलाश में हैं, तो विचार करने के लिए दो रास्ते हैं। आप एक योगदानकर्ता के रूप में अपने समय का वित्तपोषण कर सकते हैं, या आप परियोजना के लिए संगठनात्मक वित्तपोषण पा सकते हैं।
 
-## Funding your own time
+## अपने समय का वित्तपोषण करना
 
-Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+आज, कई लोगों को ओपन सोर्स पर अंशकालिक या पूर्णकालिक काम करने के लिए भुगतान मिलता है। अपने समय के लिए भुगतान पाने का सबसे आम तरीका अपने नियोक्ता से बात करना है।
 
-It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+यदि आपका नियोक्ता वास्तव में परियोजना का उपयोग करता है, तो ओपन सोर्स कार्य के लिए मामला बनाना आसान है, लेकिन अपनी पिच के साथ रचनात्मक बनें। हो सकता है कि आपका नियोक्ता प्रोजेक्ट का उपयोग नहीं करता हो, लेकिन वे पायथन का उपयोग करते हैं, और एक लोकप्रिय पायथन प्रोजेक्ट को बनाए रखने से नए पायथन डेवलपर्स को आकर्षित करने में मदद मिलती है। शायद यह आपके नियोक्ता को सामान्य रूप से अधिक डेवलपर-अनुकूल बनाता है।
 
-If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+यदि आपके पास कोई मौजूदा ओपन सोर्स प्रोजेक्ट नहीं है जिस पर आप काम करना चाहेंगे, बल्कि चाहेंगे कि आपका वर्तमान कार्य आउटपुट ओपन सोर्स हो, तो अपने नियोक्ता के लिए उनके कुछ आंतरिक सॉफ़्टवेयर को ओपन सोर्स करने का मामला बनाएं।
 
-Many companies are developing open source programs to build their brand and recruit quality talent.
+कई कंपनियां अपना ब्रांड बनाने और गुणवत्तापूर्ण प्रतिभाओं की भर्ती के लिए ओपन सोर्स प्रोग्राम विकसित कर रही हैं।
 
-@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+उदाहरण के लिए, @hueniverse ने पाया कि औचित्य सिद्ध करने के लिए वित्तीय कारण थे [ओपन सोर्स में वॉलमार्ट का निवेश](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). और @jamesgpearce ने पाया वह फेसबुक का ओपन सोर्स प्रोग्राम है [make a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) 
+भर्ती में:
 
-> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+> यह हमारी हैकर संस्कृति और हमारे संगठन को कैसे समझा जाता है, के साथ निकटता से जुड़ा हुआ है। हमने अपने कर्मचारियों से पूछा, "क्या आप फेसबुक के ओपन सोर्स सॉफ़्टवेयर प्रोग्राम के बारे में जानते थे?" दो-तिहाई ने कहा "हाँ"। एक-आधे ने कहा कि कार्यक्रम ने हमारे लिए काम करने के उनके निर्णय में सकारात्मक योगदान दिया। ये सीमांत संख्याएं नहीं हैं, और मुझे आशा है कि यह प्रवृत्ति जारी रहेगी।
 
-If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+यदि आपकी कंपनी इस मार्ग पर चलती है, तो समुदाय और कॉर्पोरेट गतिविधि के बीच की सीमाओं को स्पष्ट रखना महत्वपूर्ण है। अंततः, ओपन सोर्स दुनिया भर के लोगों के योगदान के माध्यम से खुद को कायम रखता है, और यह किसी एक कंपनी या स्थान से बड़ा है।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
-  Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+  ओपन सोर्स पर काम करने के लिए भुगतान प्राप्त करना एक दुर्लभ और अद्भुत अवसर है, लेकिन आपको इस प्रक्रिया में अपना जुनून नहीं छोड़ना चाहिए। आपका जुनून यह होना चाहिए कि कंपनियां आपको भुगतान क्यों करना चाहती हैं।
   <p markdown="1" class="pquote-credit">
 — @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
   </p>
 </aside>
 
-If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+यदि आप अपने वर्तमान नियोक्ता को ओपन सोर्स कार्य को प्राथमिकता देने के लिए मना नहीं सकते हैं, तो एक नया नियोक्ता ढूंढने पर विचार करें जो ओपन सोर्स में कर्मचारी योगदान को प्रोत्साहित करता हो। ऐसी कंपनियों की तलाश करें जो ओपन सोर्स कार्य के प्रति अपना समर्पण स्पष्ट करती हों। उदाहरण के लिए:
 
-* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
-* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+*कुछ कंपनियाँ, जैसे [Netflix](https://netflix.github.io/) या [PayPal](https://paypal.github.io/), के पास ऐसी वेबसाइटें हैं जो ओपन सोर्स में उनकी भागीदारी को उजागर करती हैं
+* [Zalando](https://opensource.zalando.com) [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) कर्मचारियों के लिए इसका प्रकाशन किया।
 
-Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+ऐसी परियोजनाएँ जो किसी बड़ी कंपनी में उत्पन्न हुईं, जैसे [Go](https://github.com/golang) या [React](https://github.com/facebook/react), ओपन सोर्स पर काम करने के लिए लोगों को नियोजित करने की भी संभावना है।
 
-Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
+अपनी व्यक्तिगत परिस्थितियों के आधार पर, आप अपने ओपन सोर्स कार्य के वित्तपोषण के लिए स्वतंत्र रूप से धन जुटाने का प्रयास कर सकते हैं। उदाहरण के लिए:
 
-* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
-* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
-* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+* @Homebrew (और [many other maintainers and organizations](https://github.com/sponsors/community)) [GitHub Sponsors](https://github.com/sponsors) के माध्यम से उनके काम को वित्तपोषित करें
+* @gaearon उसके काम को वित्त पोषित किया [Redux](https://github.com/reactjs/redux) पर, और [Patreon crowdfunding campaign](https://redux.js.org/) के जरिए
+* @andrewgodwin स्कीमा माइग्रेशन पर वित्त पोषित कार्य [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
-Finally, sometimes open source projects put bounties on issues that you might consider helping with.
+अंत में, कभी-कभी ओपन सोर्स प्रोजेक्ट उन मुद्दों पर इनाम देते हैं जिनमें आप मदद करने पर विचार कर सकते हैं।
 
-* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
-* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+* @ConnorChristie भुगतान पाने में सक्षम था [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
+* @mamiM ने इसके बाद @MetaMask का जापानी अनुवाद किया [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
 
-## Finding funding for your project
+## अपने प्रोजेक्ट के लिए फंडिंग ढूँढना
 
-Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+व्यक्तिगत योगदानकर्ताओं के लिए व्यवस्था से परे, कभी-कभी परियोजनाएं चल रहे काम को निधि देने के लिए कंपनियों, व्यक्तियों या अन्य लोगों से धन जुटाती हैं।
 
-Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas.
+संगठनात्मक फंडिंग वर्तमान योगदानकर्ताओं को भुगतान करने, परियोजना चलाने की लागत (जैसे होस्टिंग शुल्क) को कवर करने, या नई सुविधाओं या विचारों में निवेश करने में जा सकती है।
 
-As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+जैसे-जैसे ओपन सोर्स की लोकप्रियता बढ़ती है, परियोजनाओं के लिए फंडिंग ढूंढना अभी भी प्रयोगात्मक है, लेकिन कुछ सामान्य विकल्प उपलब्ध हैं।
 
-### Raise money for your work through crowdfunding campaigns or sponsorships
+### क्राउडफंडिंग अभियानों या प्रायोजन के माध्यम से अपने काम के लिए धन जुटाएं
 
-Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
-A few examples of sponsored projects include:
+यदि आपके पास पहले से ही एक मजबूत दर्शक वर्ग या प्रतिष्ठा है, या आपका प्रोजेक्ट बहुत लोकप्रिय है, तो प्रायोजन ढूँढना अच्छा काम करता है।
+प्रायोजित परियोजनाओं के कुछ उदाहरणों में शामिल हैं:
 
-* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+* **[webpack](https://github.com/webpack)** कंपनियों और व्यक्तियों से धन जुटाता है [through OpenCollective](https://opencollective.com/webpack)
+* **[Ruby Together](https://rubytogether.org/),** एक गैर-लाभकारी संगठन जो काम के लिए भुगतान करता है [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
 
-### Create a revenue stream
+### एक राजस्व धारा बनाएँ
 
-Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+आपके प्रोजेक्ट के आधार पर, आप व्यावसायिक सहायता, होस्ट किए गए विकल्पों या अतिरिक्त सुविधाओं के लिए शुल्क लेने में सक्षम हो सकते हैं। कुछ उदाहरणों में शामिल हैं:
 
-* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
-* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
-* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+* **[Sidekiq](https://github.com/mperham/sidekiq)** अतिरिक्त सहायता के लिए सशुल्क संस्करण प्रदान करता है
+* **[Travis CI](https://github.com/travis-ci)** अपने उत्पाद के सशुल्क संस्करण प्रदान करता है
+* **[Ghost](https://github.com/TryGhost/Ghost)** सशुल्क प्रबंधित सेवा वाला एक गैर-लाभकारी संगठन है
 
-Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+कुछ लोकप्रिय परियोजनाएँ, जैसे [npm](https://github.com/npm/cli) और [Docker](https://github.com/docker/docker), यहां तक ​​कि अपने व्यवसाय के विकास को समर्थन देने के लिए उद्यम पूंजी भी जुटाते हैं।
 
-### Apply for grant funding
+### अनुदान निधि के लिए आवेदन करें
 
-Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+कुछ सॉफ़्टवेयर फ़ाउंडेशन और कंपनियाँ ओपन सोर्स कार्य के लिए अनुदान प्रदान करती हैं। कभी-कभी, परियोजना के लिए कानूनी इकाई स्थापित किए बिना व्यक्तियों को अनुदान का भुगतान किया जा सकता है।
 
-* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
-* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
-* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
-* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** को [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) से अनुदान प्राप्त हुआ।
+* **[OpenMRS](https://github.com/openmrs)** कार्य द्वारा वित्त पोषित किया गया था [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** को [Sloan Foundation](https://sloan.org/programs/digital-technology) से अनुदान प्राप्त हुआ।
+* **[Python Software Foundation](https://www.python.org/psf/grants/)** पायथन से संबंधित कार्यों के लिए अनुदान प्रदान करता है।
 
-For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+अधिक विस्तृत विकल्पों और केस अध्ययन के लिए, @nayafia  [एक गाइड लिखा](https://github.com/nayafia/lemonade-stand) 
+ओपन सोर्स कार्य के लिए भुगतान प्राप्त करना। विभिन्न प्रकार की फंडिंग के लिए अलग-अलग कौशल की आवश्यकता होती है, इसलिए यह पता लगाने के लिए अपनी ताकत पर विचार करें कि कौन सा विकल्प आपके लिए सबसे अच्छा काम करता है।
 
-## Building a case for financial support
+## वित्तीय सहायता के लिए मामला बनाना
 
-Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+चाहे आपका प्रोजेक्ट एक नया विचार हो, या वर्षों से चला आ रहा हो, आपको अपने लक्षित फंडर की पहचान करने और एक सम्मोहक मामला बनाने में महत्वपूर्ण विचार करने की उम्मीद करनी चाहिए।
 
-Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+चाहे आप अपने समय के लिए भुगतान करना चाह रहे हों, या किसी परियोजना के लिए धन जुटाना चाह रहे हों, आपको निम्नलिखित प्रश्नों का उत्तर देने में सक्षम होना चाहिए।
 
-### Impact
+### प्रभाव
 
-Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+यह प्रोजेक्ट उपयोगी क्यों है? आपके उपयोगकर्ता, या संभावित उपयोगकर्ता, इसे इतना पसंद क्यों करते हैं? पांच साल में यह कहां होगा?
 
-### Traction
+### संकर्षण
 
-Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+सबूत इकट्ठा करने की कोशिश करें कि आपका प्रोजेक्ट मायने रखता है, चाहे वह मेट्रिक्स, उपाख्यान या प्रशंसापत्र हो। क्या अभी कोई कंपनी या उल्लेखनीय लोग आपके प्रोजेक्ट का उपयोग कर रहे हैं? यदि नहीं, तो क्या किसी प्रमुख व्यक्ति ने इसका समर्थन किया है?
 
-### Value to funder
+### फंड देने वाले के लिए मूल्य
 
-Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+फंडर्स, चाहे आपका नियोक्ता हो या अनुदान देने वाला फाउंडेशन, अक्सर अवसरों के साथ संपर्क किया जाता है। उन्हें किसी अन्य अवसर की अपेक्षा आपके प्रोजेक्ट का समर्थन क्यों करना चाहिए? वे व्यक्तिगत रूप से कैसे लाभान्वित होते हैं?
 
-### Use of funds
+### धन का उपयोग
 
-What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+प्रस्तावित फंडिंग से आप वास्तव में क्या हासिल करेंगे? वेतन देने के बजाय परियोजना की उपलब्धियों या परिणामों पर ध्यान दें।
 
-### How you'll receive the funds
+### आपको धनराशि कैसे प्राप्त होगी
 
-Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+क्या फंडर को संवितरण से संबंधित कोई आवश्यकता है? उदाहरण के लिए, आपको एक गैर-लाभकारी संस्था होने या एक गैर-लाभकारी वित्तीय प्रायोजक होने की आवश्यकता हो सकती है। या शायद धनराशि किसी संगठन के बजाय किसी व्यक्तिगत ठेकेदार को दी जानी चाहिए। ये आवश्यकताएं फंडर्स के बीच अलग-अलग होती हैं, इसलिए पहले से ही अपना शोध करना सुनिश्चित करें।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
-  For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+  वर्षों से, हम 20 मिलियन से अधिक लोगों के समुदाय के साथ वेबसाइट फ्रेंडली आइकन के अग्रणी संसाधन रहे हैं और Whitehouse.gov सहित 70 मिलियन से अधिक वेबसाइटों पर प्रदर्शित हुए हैं। (...) संस्करण 4 तीन साल पहले था। तब से वेब तकनीक बहुत बदल गई है, और स्पष्ट रूप से, फ़ॉन्ट विस्मयकारी थोड़ा पुराना हो गया है। (...) इसीलिए हम फ़ॉन्ट विस्मयकारी 5 पेश कर रहे हैं। हम सीएसएस का आधुनिकीकरण और पुनर्लेखन कर रहे हैं और ऊपर से नीचे तक हर आइकन को फिर से डिज़ाइन कर रहे हैं। हम बेहतर डिज़ाइन, बेहतर स्थिरता और बेहतर पठनीयता की बात कर रहे हैं।
   <p markdown="1" class="pquote-credit">
 — @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
   </p>
 </aside>
 
-## Experiment and don't give up
+## प्रयोग करो और हार मत मानो
 
-Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
+पैसा जुटाना आसान नहीं है, चाहे आप एक ओपन सोर्स प्रोजेक्ट हों, एक गैर-लाभकारी संस्था हों, या एक सॉफ्टवेयर स्टार्टअप हों, और ज्यादातर मामलों में आपको रचनात्मक होने की आवश्यकता होती है। यह पहचानना कि आप भुगतान कैसे प्राप्त करना चाहते हैं, अपना शोध करना, और अपने आप को अपने फंडर के स्थान पर रखना आपको फंडिंग के लिए एक ठोस मामला बनाने में मदद करेगा।
diff --git a/_articles/hi/leadership-and-governance.md b/_articles/hi/leadership-and-governance.md
index 6fd75930d5d..579273895c1 100644
--- a/_articles/hi/leadership-and-governance.md
+++ b/_articles/hi/leadership-and-governance.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Leadership and Governance
-description: Growing open source projects can benefit from formal rules for making decisions.
+lang: hi
+title: नेतृत्व और शासन
+description: निर्णय लेने के लिए औपचारिक नियमों से बढ़ते ओपन सोर्स प्रोजेक्ट्स को फायदा हो सकता है।
 class: leadership
 order: 6
 image: /assets/images/cards/leadership.png
@@ -10,147 +10,148 @@ related:
   - metrics
 ---
 
-## Understanding governance for your growing project
+## अपने बढ़ते प्रोजेक्ट के लिए प्रशासन को समझना
 
-Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+आपका प्रोजेक्ट बढ़ रहा है, लोग इसमें लगे हुए हैं और आप इस चीज़ को जारी रखने के लिए प्रतिबद्ध हैं। इस स्तर पर, आप सोच रहे होंगे कि नियमित परियोजना योगदानकर्ताओं को अपने वर्कफ़्लो में कैसे शामिल किया जाए, चाहे वह किसी को प्रतिबद्ध पहुंच प्रदान करना हो या सामुदायिक बहस को हल करना हो। यदि आपके कोई प्रश्न हैं, तो हमें उत्तर मिल गए हैं।
 
-## What are examples of formal roles used in open source projects?
+## ओपन सोर्स प्रोजेक्ट्स में उपयोग की जाने वाली औपचारिक भूमिकाओं के उदाहरण क्या हैं?
 
-Many projects follow a similar structure for contributor roles and recognition.
+कई परियोजनाएँ योगदानकर्ता भूमिकाओं और मान्यता के लिए समान संरचना का पालन करती हैं।
 
-What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+हालाँकि, इन भूमिकाओं का वास्तव में क्या मतलब है, यह पूरी तरह आप पर निर्भर है। यहां कुछ प्रकार की भूमिकाएं दी गई हैं जिन्हें आप पहचान सकते हैं:
 
-* **Maintainer**
-* **Contributor**
-* **Committer**
+* **रखरखाव**
+* **योगदान देने वाला**
+* **कमिटर**
 
-**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+**कुछ परियोजनाओं के लिए, "रखरखावकर्ता"** किसी परियोजना में प्रतिबद्ध पहुंच वाले एकमात्र लोग होते हैं। अन्य परियोजनाओं में, वे केवल वे लोग हैं जो रीडमी में अनुरक्षक के रूप में सूचीबद्ध हैं।
 
-A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+एक अनुरक्षक आवश्यक रूप से ऐसा व्यक्ति नहीं है जो आपके प्रोजेक्ट के लिए कोड लिखता हो। यह कोई ऐसा व्यक्ति हो सकता है जिसने आपके प्रोजेक्ट को प्रचारित करने के लिए बहुत काम किया हो, या लिखित दस्तावेज़ीकरण किया हो जिसने प्रोजेक्ट को दूसरों के लिए अधिक सुलभ बना दिया हो। चाहे वे दिन-प्रतिदिन कुछ भी करें, एक अनुरक्षक संभवतः वह व्यक्ति होता है जो परियोजना की दिशा में ज़िम्मेदारी महसूस करता है और इसे सुधारने के लिए प्रतिबद्ध है।
 
-**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+**एक "योगदानकर्ता" कोई भी हो सकता है** जो किसी मुद्दे या पुल अनुरोध पर टिप्पणी करता है, जो लोग परियोजना में मूल्य जोड़ते हैं (चाहे वह मुद्दों का परीक्षण करना हो, कोड लिखना हो, या घटनाओं का आयोजन करना हो), या मर्ज किए गए पुल अनुरोध वाला कोई भी व्यक्ति (शायद योगदानकर्ता की सबसे संकीर्ण परिभाषा।)
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+  \[ Node.js के लिया,\] प्रत्येक व्यक्ति जो किसी मुद्दे पर टिप्पणी करने या कोड सबमिट करने के लिए आता है, वह प्रोजेक्ट समुदाय का सदस्य होता है। बस उन्हें देखने में सक्षम होने का मतलब है कि उन्होंने उपयोगकर्ता से योगदानकर्ता बनने की सीमा पार कर ली है।
   <p markdown="1" class="pquote-credit">
 — @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
   </p>
 </aside>
 
-**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+**शब्द "कमिटर"** का उपयोग कमिट एक्सेस, जो एक विशिष्ट प्रकार की जिम्मेदारी है, को योगदान के अन्य रूपों से अलग करने के लिए किया जा सकता है।
 
-While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+हालाँकि आप अपनी परियोजना भूमिकाओं को अपनी इच्छानुसार किसी भी तरह परिभाषित कर सकते हैं, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) योगदान के और अधिक रूपों को प्रोत्साहित करना। आप उन लोगों को औपचारिक रूप से पहचानने के लिए नेतृत्व की भूमिकाओं का उपयोग कर सकते हैं जिन्होंने आपके प्रोजेक्ट में उत्कृष्ट योगदान दिया है, भले ही उनके तकनीकी कौशल कुछ भी हों।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
-  You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+  आप शायद मुझे Django के "आविष्कारक" के रूप में जानते होंगे...लेकिन वास्तव में मैं वह व्यक्ति हूं जिसे किसी चीज़ के बनने के एक साल बाद उस पर काम करने के लिए नियुक्त किया गया था। (...) लोगों को संदेह है कि मैं अपने प्रोग्रामिंग कौशल के कारण सफल हूं...लेकिन मैं अधिक से अधिक एक औसत प्रोग्रामर हूं।
   <p markdown="1" class="pquote-credit">
 — @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
   </p>
 </aside>
 
-## How do I formalize these leadership roles?
+## मैं इन नेतृत्व भूमिकाओं को कैसे औपचारिक बनाऊं?
 
-Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+अपनी नेतृत्व भूमिकाओं को औपचारिक बनाने से लोगों को स्वामित्व महसूस करने में मदद मिलती है और समुदाय के अन्य सदस्यों को पता चलता है कि मदद के लिए किससे संपर्क करना चाहिए।
 
-For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+एक छोटी परियोजना के लिए, नेताओं को नामित करना आपके README या CONTRIBUTORS टेक्स्ट फ़ाइल में उनके नाम जोड़ने जितना आसान हो सकता है।
 
-For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+किसी बड़े प्रोजेक्ट के लिए, यदि आपके पास कोई वेबसाइट है, तो एक टीम पेज बनाएं या वहां अपने प्रोजेक्ट लीडरों की सूची बनाएं। उदाहरण के लिए, [Postgres](https://github.com/postgres/postgres/) के पास एक [comprehensive team page](https://www.postgresql.org/community/contributors/) प्रत्येक योगदानकर्ता के लिए संक्षिप्त प्रोफ़ाइल के साथ।
 
-If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+यदि आपके प्रोजेक्ट में बहुत सक्रिय योगदानकर्ता समुदाय है, तो आप अनुरक्षकों की एक "कोर टीम" बना सकते हैं, या ऐसे लोगों की उपसमितियां भी बना सकते हैं जो विभिन्न मुद्दे क्षेत्रों (उदाहरण के लिए, सुरक्षा, समस्या निवारण, या सामुदायिक आचरण) का स्वामित्व लेते हैं। लोगों को वे भूमिकाएँ सौंपने के बजाय स्वयं संगठित होने दें और उनके लिए स्वेच्छा से काम करने दें जिनके बारे में वे सबसे अधिक उत्साहित हैं।
 
 <aside markdown="1" class="pquote">
-  \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+  \[हम\] कई "उपटीमों" के साथ कोर टीम को पूरक करें। प्रत्येक उपटीम एक विशिष्ट क्षेत्र पर केंद्रित है, जैसे, भाषा डिज़ाइन या पुस्तकालय। (...) समग्र रूप से परियोजना के लिए वैश्विक समन्वय और एक मजबूत, सुसंगत दृष्टिकोण सुनिश्चित करने के लिए, प्रत्येक उपटीम का नेतृत्व कोर टीम के एक सदस्य द्वारा किया जाता है।
   <p markdown="1" class="pquote-credit">
 — ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+नेतृत्व दल एक निर्दिष्ट चैनल बनाना चाह सकते हैं (जैसे आईआरसी पर) या परियोजना पर चर्चा करने के लिए नियमित रूप से मिलना चाहते हैं (जैसे गिटर या गूगल हैंगआउट पर)। आप उन बैठकों को सार्वजनिक भी कर सकते हैं ताकि अन्य लोग सुन सकें। [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), उदाहरण के लिए, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
-Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+एक बार जब आप नेतृत्व की भूमिकाएँ स्थापित कर लें, तो यह दस्तावेज करना न भूलें कि लोग उन्हें कैसे प्राप्त कर सकते हैं! कोई आपके प्रोजेक्ट में अनुरक्षक कैसे बन सकता है या उपसमिति में कैसे शामिल हो सकता है, इसके लिए एक स्पष्ट प्रक्रिया स्थापित करें और इसे अपने में लिखें GOVERNANCE.md.
 
-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.
+उपकरण जैसे [Vossibility](https://github.com/icecrime/vossibility-stack) आपको सार्वजनिक रूप से ट्रैक करने में मदद मिल सकती है कि प्रोजेक्ट में कौन योगदान दे रहा है (या नहीं दे रहा है)। इस जानकारी का दस्तावेजीकरण करने से समुदाय की इस धारणा से बचा जा सकता है कि रखरखाव करने वाले एक समूह हैं जो निजी तौर पर अपने निर्णय लेते हैं।
 
-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).
+अंत में, यदि आपका प्रोजेक्ट GitHub पर है, तो अपने प्रोजेक्ट को अपने व्यक्तिगत खाते से किसी संगठन में ले जाने और कम से कम एक बैकअप व्यवस्थापक जोड़ने पर विचार करें। [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) अनुमतियों और एकाधिक रिपॉजिटरी को प्रबंधित करना और अपने प्रोजेक्ट की विरासत को सुरक्षित रखना आसान बनाएं [shared ownership](../building-community/#share-ownership-of-your-project).
 
-## When should I give someone commit access?
+## मुझे किसी को प्रतिबद्ध पहुंच कब देनी चाहिए?
 
-Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+कुछ लोग सोचते हैं कि आपको योगदान देने वाले हर व्यक्ति को प्रतिबद्ध पहुंच देनी चाहिए। ऐसा करने से अधिक लोग आपके प्रोजेक्ट पर स्वामित्व महसूस करने के लिए प्रोत्साहित हो सकते हैं।
 
-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.
+यदि आपका प्रोजेक्ट GitHub पर है, तो आप इसका उपयोग कर सकते हैं [protected branches](https://help.github.com/articles/about-protected-branches/) यह प्रबंधित करना कि कौन किसी विशेष शाखा में जा सकता है, और किन परिस्थितियों में।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
-  Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+  जब भी कोई आपको पुल अनुरोध भेजता है, तो उन्हें अपने प्रोजेक्ट तक पहुंच प्रदान करें। हालाँकि यह पहली बार में अविश्वसनीय रूप से बेवकूफी भरा लग सकता है, इस रणनीति का उपयोग करने से आप GitHub की वास्तविक शक्ति को उजागर कर सकेंगे। (...) एक बार लोगों के पास प्रतिबद्ध पहुंच हो जाने के बाद, उन्हें चिंता नहीं रहती कि उनका पैच अलग हो सकता है...जिससे उन्हें इसमें और अधिक काम करना पड़ेगा।
   <p markdown="1" class="pquote-credit">
 — @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
   </p>
 </aside>
 
-## What are some of the common governance structures for open source projects?
+## ओपन सोर्स परियोजनाओं के लिए कुछ सामान्य शासन संरचनाएँ क्या हैं?
 
-There are three common governance structures associated with open source projects.
+ओपन सोर्स परियोजनाओं से जुड़ी तीन सामान्य शासन संरचनाएँ हैं।
 
-* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+* **बीडीएफएल:** बीडीएफएल का अर्थ है "जीवन के लिए परोपकारी तानाशाह"। इस संरचना के तहत, सभी प्रमुख परियोजना निर्णयों पर एक व्यक्ति (आमतौर पर परियोजना का प्रारंभिक लेखक) का अंतिम अधिकार होता है। [Python](https://github.com/python) एक उत्कृष्ट उदाहरण है. छोटी परियोजनाएँ संभवतः डिफ़ॉल्ट रूप से बीडीएफएल हैं, क्योंकि केवल एक या दो अनुरक्षक होते हैं। किसी कंपनी में शुरू हुआ प्रोजेक्ट भी बीडीएफएल श्रेणी में आ सकता है।
 
-* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+* **मेरिटोक्रेसी:** **(नोट: शब्द "मेरिटोक्रेसी" कुछ समुदायों के लिए नकारात्मक अर्थ रखता है और इसका एक नकारात्मक प्रभाव है[complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** योग्यतातंत्र के तहत, सक्रिय परियोजना योगदानकर्ताओं (जो "योग्यता" प्रदर्शित करते हैं) को औपचारिक निर्णय लेने की भूमिका दी जाती है। निर्णय आम तौर पर शुद्ध मतदान सर्वसम्मति के आधार पर किए जाते हैं। योग्यतातंत्र की अवधारणा का सूत्रपात किसके द्वारा किया गया था? [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) 
+योग्यतातंत्र हैं. योगदान केवल अपना प्रतिनिधित्व करने वाले व्यक्तियों द्वारा ही किया जा सकता है, किसी कंपनी द्वारा नहीं।
 
-* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
+* **उदार योगदान:** उदार योगदान मॉडल के तहत, जो लोग सबसे अधिक काम करते हैं उन्हें सबसे प्रभावशाली माना जाता है, लेकिन यह वर्तमान कार्य पर आधारित है न कि ऐतिहासिक योगदान पर। प्रमुख परियोजना निर्णय शुद्ध वोट के बजाय सर्वसम्मति प्राप्त करने की प्रक्रिया (प्रमुख शिकायतों पर चर्चा) के आधार पर किए जाते हैं, और यथासंभव अधिक से अधिक सामुदायिक दृष्टिकोणों को शामिल करने का प्रयास किया जाता है। उदार योगदान मॉडल का उपयोग करने वाली परियोजनाओं के लोकप्रिय उदाहरणों में शामिल हैं [Node.js](https://foundation.nodejs.org/) और [Rust](https://www.rust-lang.org/).
 
-Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+आपको किसका उपयोग करना चाहिए? यह आप पर निर्भर करता है! हर मॉडल के फायदे और फायदे हैं। और यद्यपि वे पहली बार में काफी भिन्न लग सकते हैं, तीनों मॉडलों में जितना वे दिखते हैं उससे कहीं अधिक समानता है। यदि आप इनमें से किसी एक मॉडल को अपनाने में रुचि रखते हैं, तो इन टेम्पलेट्स को देखें:
 
 * [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
 * [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
 * [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
 
-## Do I need governance docs when I launch my project?
+## क्या मुझे अपना प्रोजेक्ट लॉन्च करते समय शासन दस्तावेज़ों की आवश्यकता होगी?
 
-There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+आपके प्रोजेक्ट के प्रशासन को लिखने का कोई सही समय नहीं है, लेकिन एक बार जब आप अपने समुदाय की गतिशीलता को देख लेंगे तो इसे परिभाषित करना बहुत आसान हो जाएगा। ओपन सोर्स गवर्नेंस के बारे में सबसे अच्छी (और सबसे कठिन) बात यह है कि इसे समुदाय द्वारा आकार दिया जाता है!
 
-Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+हालाँकि, कुछ शुरुआती दस्तावेज़ अनिवार्य रूप से आपके प्रोजेक्ट के प्रशासन में योगदान देंगे, इसलिए आप जो कर सकते हैं उसे लिखना शुरू कर दें। उदाहरण के लिए, आप व्यवहार के लिए स्पष्ट अपेक्षाओं को परिभाषित कर सकते हैं, या आपके प्रोजेक्ट के लॉन्च पर भी आपकी योगदानकर्ता प्रक्रिया कैसे काम करती है।
 
-If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
+यदि आप एक ओपन सोर्स प्रोजेक्ट लॉन्च करने वाली कंपनी का हिस्सा हैं, तो लॉन्च से पहले इस बारे में आंतरिक चर्चा करना उचित है कि आपकी कंपनी प्रोजेक्ट को आगे बढ़ाने के बारे में कैसे बनाए रखने और निर्णय लेने की उम्मीद करती है। हो सकता है कि आप सार्वजनिक रूप से यह स्पष्ट करना चाहें कि आपकी कंपनी इस परियोजना में कैसे शामिल होगी (या नहीं करेगी!)।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
-  We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+  हम GitHub पर प्रोजेक्ट प्रबंधित करने के लिए छोटी टीमें नियुक्त करते हैं जो वास्तव में Facebook पर इन पर काम कर रही हैं। उदाहरण के लिए, रिएक्ट एक रिएक्ट इंजीनियर द्वारा चलाया जाता है।
   <p markdown="1" class="pquote-credit">
 — @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
   </p>
 </aside>
 
-## What happens if corporate employees start submitting contributions?
+## यदि कॉर्पोरेट कर्मचारी अंशदान जमा करना शुरू कर दें तो क्या होगा?
 
-Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+सफल ओपन सोर्स परियोजनाओं का उपयोग कई लोगों और कंपनियों द्वारा किया जाता है, और कुछ कंपनियों के पास अंततः राजस्व धाराएं परियोजना से जुड़ी हो सकती हैं। उदाहरण के लिए, कोई कंपनी किसी वाणिज्यिक सेवा पेशकश में परियोजना के कोड को एक घटक के रूप में उपयोग कर सकती है।
 
-As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+जैसे-जैसे परियोजना अधिक व्यापक रूप से उपयोग की जाती है, इसमें विशेषज्ञता रखने वाले लोगों की मांग अधिक हो जाती है - आप उनमें से एक हो सकते हैं! - और कभी-कभी उन्हें प्रोजेक्ट में किए गए काम के लिए भुगतान मिलेगा।
 
-It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+व्यावसायिक गतिविधि को सामान्य और विकास ऊर्जा के एक अन्य स्रोत के रूप में मानना ​​महत्वपूर्ण है। निःसंदेह, भुगतान किए गए डेवलपर्स को अवैतनिक डेवलपर्स की तुलना में विशेष व्यवहार नहीं मिलना चाहिए; प्रत्येक योगदान का मूल्यांकन उसकी तकनीकी खूबियों के आधार पर किया जाना चाहिए। हालाँकि, लोगों को व्यावसायिक गतिविधि में शामिल होने में सहज महसूस करना चाहिए, और किसी विशेष वृद्धि या सुविधा के पक्ष में बहस करते समय अपने उपयोग के मामलों को बताने में सहज महसूस करना चाहिए।
 
-"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+"वाणिज्यिक" "ओपन सोर्स" के साथ पूरी तरह से संगत है। "वाणिज्यिक" का सीधा सा मतलब है कि इसमें कहीं न कहीं पैसा शामिल है - कि सॉफ्टवेयर का उपयोग वाणिज्य में किया जाता है, जो कि एक परियोजना के अपनाने के रूप में तेजी से संभव है। (जब ओपन सोर्स सॉफ़्टवेयर का उपयोग गैर-ओपन-सोर्स उत्पाद के हिस्से के रूप में किया जाता है, तो समग्र उत्पाद अभी भी "मालिकाना" सॉफ़्टवेयर होता है, हालांकि, ओपन सोर्स की तरह, इसका उपयोग वाणिज्यिक या गैर-व्यावसायिक उद्देश्यों के लिए किया जा सकता है।)
 
-Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+किसी भी अन्य की तरह, व्यावसायिक रूप से प्रेरित डेवलपर्स अपने योगदान की गुणवत्ता और मात्रा के माध्यम से परियोजना में प्रभाव प्राप्त करते हैं। जाहिर है, एक डेवलपर जिसे उसके समय के लिए भुगतान किया जाता है, वह उस व्यक्ति से अधिक काम करने में सक्षम हो सकता है जिसे भुगतान नहीं किया जाता है, लेकिन यह ठीक है: भुगतान कई संभावित कारकों में से एक है जो किसी के काम को प्रभावित कर सकता है। अपनी परियोजना चर्चाओं को योगदानों पर केंद्रित रखें, न कि उन बाहरी कारकों पर जो लोगों को योगदान देने में सक्षम बनाते हैं।
 
-## Do I need a legal entity to support my project?
+## क्या मुझे अपने प्रोजेक्ट का समर्थन करने के लिए एक कानूनी इकाई की आवश्यकता है?
 
-You don't need a legal entity to support your open source project unless you're handling money.
+जब तक आप पैसे का प्रबंधन नहीं कर रहे हों, आपको अपने ओपन सोर्स प्रोजेक्ट का समर्थन करने के लिए किसी कानूनी इकाई की आवश्यकता नहीं है।
 
-For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+उदाहरण के लिए, यदि आप एक वाणिज्यिक व्यवसाय बनाना चाहते हैं, तो आप एक सी कॉर्प या एलएलसी स्थापित करना चाहेंगे (यदि आप अमेरिका में स्थित हैं)। यदि आप केवल अपने ओपन सोर्स प्रोजेक्ट से संबंधित अनुबंध कार्य कर रहे हैं, तो आप एकमात्र मालिक के रूप में धन स्वीकार कर सकते हैं, या एलएलसी स्थापित कर सकते हैं (यदि आप अमेरिका में स्थित हैं)।
 
-If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+यदि आप अपने ओपन सोर्स प्रोजेक्ट के लिए दान स्वीकार करना चाहते हैं, तो आप एक दान बटन सेट कर सकते हैं (उदाहरण के लिए पेपैल या स्ट्राइप का उपयोग करके), लेकिन पैसा तब तक कर-कटौती योग्य नहीं होगा जब तक कि आप एक योग्य गैर-लाभकारी संस्था (501c3, यदि आप अमेरिका में हैं)।
 
-Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+कई परियोजनाएँ एक गैर-लाभकारी संस्था स्थापित करने की परेशानी से गुज़रना नहीं चाहती हैं, इसलिए वे इसके बजाय एक गैर-लाभकारी राजकोषीय प्रायोजक ढूंढती हैं। एक राजकोषीय प्रायोजक आपकी ओर से दान स्वीकार करता है, आमतौर पर दान के एक प्रतिशत के बदले में। [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) ओर [Open Collective](https://opencollective.com/opensource) ऐसे संगठनों के उदाहरण हैं जो ओपन सोर्स परियोजनाओं के लिए वित्तीय प्रायोजक के रूप में काम करते हैं।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
-  Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+  हमारा लक्ष्य एक ऐसा बुनियादी ढाँचा प्रदान करना है जिसका उपयोग समुदाय स्वयं टिकाऊ होने के लिए कर सकें, इस प्रकार एक ऐसा वातावरण तैयार करना है जहाँ सभी — योगदानकर्ताओं, समर्थकों, प्रायोजकों — को इससे ठोस लाभ मिले।
   <p markdown="1" class="pquote-credit">
-— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+— @piamancini, ["दान ढांचे से आगे बढ़ना"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
   </p>
 </aside>
 
-If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
+यदि आपका प्रोजेक्ट किसी निश्चित भाषा या पारिस्थितिकी तंत्र से निकटता से जुड़ा हुआ है, तो एक संबंधित सॉफ़्टवेयर फ़ाउंडेशन भी हो सकता है जिसके साथ आप काम कर सकते हैं। उदाहरण के लिए, [Python Software Foundation](https://www.python.org/psf/) मदद करता है [PyPI](https://pypi.org/), पायथन पैकेज मैनेजर का, और [Node.js Foundation](https://foundation.nodejs.org/) मदद करता है [Express.js](https://expressjs.com/) का, एक नोड-आधारित ढांचा।
diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md
index 8adc3897659..a1ebf7d8a6c 100644
--- a/_articles/hi/legal.md
+++ b/_articles/hi/legal.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: The Legal Side of Open Source
-description: Everything you've ever wondered about the legal side of open source, and a few things you didn't.
+lang: hi
+title: ओपन सोर्स का कानूनी पक्ष
+description: ओपन सोर्स के कानूनी पक्ष के बारे में आपने जो कुछ भी सोचा है, और कुछ चीजें जो आपने नहीं सोची हैं।
 class: legal
 order: 10
 image: /assets/images/cards/legal.png
@@ -10,149 +10,153 @@ related:
   - leadership
 ---
 
-## Understanding the legal implications of open source
+## ओपन सोर्स के कानूनी निहितार्थ को समझना
 
-Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+अपने रचनात्मक कार्य को दुनिया के साथ साझा करना एक रोमांचक और पुरस्कृत अनुभव हो सकता है। इसका मतलब यह भी हो सकता है कि कई कानूनी चीजें जिनके बारे में आप नहीं जानते कि आपको चिंता करने की ज़रूरत है। शुक्र है, आपको शून्य से शुरुआत करने की ज़रूरत नहीं है। हमने आपकी कानूनी ज़रूरतें पूरी कर ली हैं। (इससे पहले कि आप गहराई से जानें, हमारा पढ़ना सुनिश्चित करें [disclaimer](/notices/).)
 
-## Why do people care so much about the legal side of open source?
+## लोग ओपन सोर्स के कानूनी पक्ष की इतनी परवाह क्यों करते हैं?
 
-Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+ख़ुशी है कि आपने पूछा! जब आप कोई रचनात्मक कार्य (जैसे लेखन, ग्राफ़िक्स, या कोड) करते हैं, तो वह कार्य डिफ़ॉल्ट रूप से विशेष कॉपीराइट के अंतर्गत होता है। यानी, कानून मानता है कि आपके काम के लेखक के रूप में, आपको यह कहने का अधिकार है कि दूसरे इसके साथ क्या कर सकते हैं।
 
-In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+सामान्य तौर पर, इसका मतलब यह है कि कोई भी अन्य व्यक्ति टेक-डाउन, शेक-डाउन या मुकदमेबाजी के जोखिम के बिना आपके काम का उपयोग, प्रतिलिपि, वितरण या संशोधन नहीं कर सकता है।
 
-Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+हालाँकि, ओपन सोर्स एक असामान्य परिस्थिति है, क्योंकि लेखक को उम्मीद है कि अन्य लोग काम का उपयोग, संशोधन और साझा करेंगे। लेकिन चूँकि कानूनी डिफ़ॉल्ट अभी भी अनन्य कॉपीराइट है, इसलिए आपको एक ऐसे लाइसेंस की आवश्यकता है जो इन अनुमतियों को स्पष्ट रूप से बताता हो।
 
-If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+यदि आप ओपन सोर्स लाइसेंस लागू नहीं करते हैं, तो आपके प्रोजेक्ट में योगदान देने वाला प्रत्येक व्यक्ति भी अपने काम का विशेष कॉपीराइट धारक बन जाता है। इसका मतलब है कि कोई भी उनके योगदान का उपयोग, प्रतिलिपि, वितरण या संशोधन नहीं कर सकता है - और उस "कोई भी" में आप शामिल नहीं हैं।
 
-Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
+अंततः, आपके प्रोजेक्ट में लाइसेंस आवश्यकताओं वाली निर्भरताएँ हो सकती हैं जिनके बारे में आपको जानकारी नहीं थी। आपके प्रोजेक्ट के समुदाय, या आपके नियोक्ता की नीतियों के लिए, आपके प्रोजेक्ट को विशिष्ट ओपन सोर्स लाइसेंस का उपयोग करने की भी आवश्यकता हो सकती है। हम नीचे इन स्थितियों को कवर करेंगे।
 
-## Are public GitHub projects open source?
+## क्या सार्वजनिक GitHub परियोजनाएँ खुला स्रोत हैं?
 
-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**.
+जब आप GitHub पर [एक नया प्रोजेक्ट बनाते हैं](https://help.github.com/articles/creating-a-new-repository/), तो आपके पास रिपॉजिटरी को **private** या **public** बनाने का विकल्प होता है।
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+**अपने GitHub प्रोजेक्ट को सार्वजनिक बनाना आपके प्रोजेक्ट को लाइसेंस देने के समान नहीं है।** सार्वजनिक परियोजनाएँ इसके अंतर्गत आती हैं [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), जो दूसरों को आपके प्रोजेक्ट को देखने और फोर्क करने की अनुमति देता है, लेकिन अन्यथा आपका काम बिना किसी अनुमति के आता है।
 
-If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+यदि आप चाहते हैं कि अन्य लोग आपके प्रोजेक्ट का उपयोग, वितरण, संशोधन या योगदान करें, तो आपको एक ओपन सोर्स लाइसेंस शामिल करना होगा। उदाहरण के लिए, कोई व्यक्ति आपके GitHub प्रोजेक्ट के किसी भी हिस्से को अपने कोड में कानूनी रूप से उपयोग नहीं कर सकता, भले ही वह सार्वजनिक हो, जब तक कि आप स्पष्ट रूप से उन्हें ऐसा करने का अधिकार नहीं देते।
 
-## Just give me the TL;DR on what I need to protect my project.
+## बस मुझे टीएल;डीआर दें कि मुझे अपने प्रोजेक्ट की सुरक्षा के लिए क्या चाहिए।
 
-You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+आप भाग्यशाली हैं, क्योंकि आज, ओपन सोर्स लाइसेंस मानकीकृत और उपयोग में आसान हैं। आप किसी मौजूदा लाइसेंस को सीधे अपने प्रोजेक्ट में कॉपी-पेस्ट कर सकते हैं।
 
-[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 the most popular open source 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/).
+[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/).
 
-When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/).
+जब आप GitHub पर एक नया प्रोजेक्ट बनाएंगे, तो आप होंगे [लाइसेंस जोड़ने के लिए कहा गया](https://help.github.com/articles/open-source-licensing/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
-  A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+  एक मानकीकृत लाइसेंस कानूनी प्रशिक्षण के बिना उन लोगों के लिए एक प्रॉक्सी के रूप में कार्य करता है ताकि वे जान सकें कि वे सॉफ़्टवेयर के साथ क्या कर सकते हैं और क्या नहीं। जब तक बिल्कुल आवश्यक न हो, कस्टम, संशोधित या गैर-मानक शब्दों से बचें, जो एजेंसी कोड के डाउनस्ट्रीम उपयोग में बाधा के रूप में काम करेंगे।
   <p markdown="1" class="pquote-credit">
 — @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
   </p>
 </aside>
 
-## Which open source license is appropriate for my project?
+## मेरे प्रोजेक्ट के लिए कौन सा ओपन सोर्स लाइसेंस उपयुक्त है?
 
-If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+यदि आप कोरी स्लेट से शुरुआत कर रहे हैं, तो इसमें गलत होना कठिन है [MIT License](https://choosealicense.com/licenses/mit/). यह संक्षिप्त है, समझने में बहुत आसान है, और किसी को भी कुछ भी करने की अनुमति देता है जब तक कि वे आपके कॉपीराइट नोटिस सहित लाइसेंस की एक प्रति अपने पास रखते हैं। यदि आपको कभी आवश्यकता होगी तो आप प्रोजेक्ट को एक अलग लाइसेंस के तहत जारी करने में सक्षम होंगे।
 
-Otherwise, picking the right open source license for your project depends on your objectives.
+अन्यथा, आपके प्रोजेक्ट के लिए सही ओपन सोर्स लाइसेंस चुनना आपके उद्देश्यों पर निर्भर करता है।
 
-Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+आपके प्रोजेक्ट की बहुत संभावना है (या होगी) **dependencies**. उदाहरण के लिए, यदि आप Node.js प्रोजेक्ट की ओपन सोर्सिंग कर रहे हैं, तो आप संभवतः नोड पैकेज मैनेजर (npm) से लाइब्रेरी का उपयोग करेंगे। आप जिन पुस्तकालयों पर निर्भर हैं उनमें से प्रत्येक के पास अपना स्वयं का ओपन सोर्स लाइसेंस होगा। यदि उनका प्रत्येक लाइसेंस "अनुमोदनात्मक" है (डाउनस्ट्रीम लाइसेंसिंग के लिए बिना किसी शर्त के जनता को उपयोग, संशोधन और साझा करने की अनुमति देता है), तो आप अपने इच्छित किसी भी लाइसेंस का उपयोग कर सकते हैं। सामान्य अनुमेय लाइसेंस में एमआईटी, अपाचे 2.0, आईएससी और बीएसडी शामिल हैं।
 
-On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+दूसरी ओर, यदि आपकी किसी निर्भरता का लाइसेंस "मजबूत कॉपीलेफ्ट" है (सार्वजनिक रूप से समान अनुमतियाँ देता है, समान लाइसेंस डाउनस्ट्रीम का उपयोग करने की शर्त के अधीन), तो आपके प्रोजेक्ट को उसी लाइसेंस का उपयोग करना होगा। सामान्य मजबूत कॉपीलेफ़्ट लाइसेंस में GPLv2, GPLv3, और AGPLv3 शामिल हैं।
 
-You may also want to consider the **communities** you hope will use and contribute to your project:
+आप शायद उन **communities** पर भी विचार करना चाहेंगे जिनका आप उपयोग करेंगे और आपके प्रोजेक्ट में योगदान देंगे:
 
-* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
-* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
-* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+* **क्या आप चाहते हैं कि आपकी परियोजना का उपयोग अन्य परियोजनाओं द्वारा निर्भरता के रूप में किया जाए?** संभवतः आपके प्रासंगिक समुदाय में सबसे लोकप्रिय लाइसेंस का उपयोग करना सबसे अच्छा है। उदाहरण के लिए, [MIT](https://choosealicense.com/licenses/mit/) 
+के लिए सबसे लोकप्रिय लाइसेंस है [npm libraries](https://libraries.io/search?platforms=NPM).
+* **क्या आप चाहते हैं कि आपका प्रोजेक्ट बड़े व्यवसायों को पसंद आए?** एक बड़ा व्यवसाय संभवतः सभी योगदानकर्ताओं से एक एक्सप्रेस पेटेंट लाइसेंस चाहेगा। इस मामले में, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
+* **क्या आप चाहते हैं कि आपका प्रोजेक्ट उन योगदानकर्ताओं को आकर्षित करे जो नहीं चाहते कि उनके योगदान का उपयोग बंद स्रोत सॉफ़्टवेयर में किया जाए?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) या (यदि वे भी बंद स्रोत सेवाओं में योगदान नहीं करना चाहते हैं) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) 
+अच्छा चलेगा।
 
-Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+आपकी **कंपनी** को अपने ओपन सोर्स प्रोजेक्ट्स के लिए विशिष्ट लाइसेंसिंग आवश्यकताएं हो सकती हैं। उदाहरण के लिए, इसके लिए एक अनुमेय लाइसेंस की आवश्यकता हो सकती है ताकि कंपनी आपके प्रोजेक्ट का उपयोग कंपनी के बंद स्रोत उत्पाद में कर सके। या आपकी कंपनी को एक मजबूत कॉपीलेफ्ट लाइसेंस और एक अतिरिक्त योगदानकर्ता समझौते (नीचे देखें) की आवश्यकता हो सकती है ताकि केवल आपकी कंपनी, और कोई नहीं, बंद स्रोत सॉफ़्टवेयर में आपके प्रोजेक्ट का उपयोग कर सके। या आपकी कंपनी को मानकों, सामाजिक जिम्मेदारी, या पारदर्शिता से संबंधित कुछ ज़रूरतें हो सकती हैं, जिनमें से किसी के लिए एक विशेष लाइसेंसिंग रणनीति की आवश्यकता हो सकती है। आप अपने [कंपनी का कानूनी विभाग](#what-does-my-companys-legal-team-need-to-know) से बातें करें।
 
-When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+जब आप GitHub पर एक नया प्रोजेक्ट बनाते हैं, तो आपको लाइसेंस चुनने का विकल्प दिया जाता है। ऊपर उल्लिखित लाइसेंसों में से एक को शामिल करने से आपका GitHub प्रोजेक्ट खुला स्रोत बन जाएगा। यदि आप अन्य विकल्प देखना चाहते हैं, तो देखें [choosealicense.com](https://choosealicense.com) अपने प्रोजेक्ट के लिए सही लाइसेंस ढूँढ़ने के लिए, भले ही वह हो [isn't software](https://choosealicense.com/non-software/).
 
-## What if I want to change the license of my project?
+## यदि मैं अपने प्रोजेक्ट का लाइसेंस बदलना चाहूँ तो क्या होगा?
 
-Most projects never need to change licenses. But occasionally circumstances change.
+अधिकांश परियोजनाओं को कभी भी लाइसेंस बदलने की आवश्यकता नहीं होती है। लेकिन कभी-कभी हालात बदल जाते हैं.
 
-For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+उदाहरण के लिए, जैसे-जैसे आपका प्रोजेक्ट बढ़ता है, इसमें निर्भरताएँ या उपयोगकर्ता जुड़ते हैं, या आपकी कंपनी रणनीतियाँ बदलती है, जिनमें से किसी को भी अलग लाइसेंस की आवश्यकता हो सकती है या चाहिए। साथ ही, यदि आपने शुरू से ही अपने प्रोजेक्ट को लाइसेंस देने की उपेक्षा की है, तो लाइसेंस जोड़ना प्रभावी रूप से लाइसेंस बदलने के समान है। अपने प्रोजेक्ट का लाइसेंस जोड़ते या बदलते समय विचार करने योग्य तीन मूलभूत बातें हैं:
 
-**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+**यह जटिल है।** लाइसेंस अनुकूलता और अनुपालन का निर्धारण करना और कॉपीराइट किसके पास है, यह बहुत जल्दी जटिल और भ्रमित करने वाला हो सकता है। नई रिलीज़ और योगदान के लिए नए लेकिन संगत लाइसेंस पर स्विच करना सभी मौजूदा योगदानों को दोबारा लाइसेंस देने से अलग है। लाइसेंस बदलने की इच्छा के पहले संकेत पर अपनी कानूनी टीम को शामिल करें। भले ही आपके पास लाइसेंस परिवर्तन के लिए अपने प्रोजेक्ट के कॉपीराइट धारकों से अनुमति है या आप प्राप्त कर सकते हैं, फिर भी अपने प्रोजेक्ट के अन्य उपयोगकर्ताओं और योगदानकर्ताओं पर परिवर्तन के प्रभाव पर विचार करें। अपने प्रोजेक्ट के लिए लाइसेंस परिवर्तन को एक "गवर्नेंस इवेंट" के रूप में सोचें, जो आपके प्रोजेक्ट के हितधारकों के साथ स्पष्ट संचार और परामर्श के साथ आसानी से चलेगा। शुरुआत से ही अपने प्रोजेक्ट के लिए उपयुक्त लाइसेंस चुनने और उसका उपयोग करने का और भी अधिक कारण!
 
-**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+**आपके प्रोजेक्ट का मौजूदा लाइसेंस।** यदि आपके प्रोजेक्ट का मौजूदा लाइसेंस उस लाइसेंस के अनुकूल है जिसे आप बदलना चाहते हैं, तो आप नए लाइसेंस का उपयोग शुरू कर सकते हैं। ऐसा इसलिए है क्योंकि यदि लाइसेंस ए लाइसेंस बी के साथ संगत है, तो आप बी की शर्तों का अनुपालन करते समय ए की शर्तों का अनुपालन करेंगे (लेकिन जरूरी नहीं कि इसका विपरीत भी हो)। इसलिए यदि आप वर्तमान में एक अनुमेय लाइसेंस (उदाहरण के लिए, एमआईटी) का उपयोग कर रहे हैं, तो आप अधिक शर्तों वाले लाइसेंस में बदल सकते हैं, जब तक कि आप एमआईटी लाइसेंस और किसी भी संबंधित कॉपीराइट नोटिस की एक प्रति अपने पास रखते हैं (यानी, इसका अनुपालन करना जारी रखते हैं। एमआईटी लाइसेंस की न्यूनतम शर्तें)। लेकिन यदि आपका वर्तमान लाइसेंस अनुमेय नहीं है (उदाहरण के लिए, कॉपीलेफ्ट, या आपके पास लाइसेंस नहीं है) और आप एकमात्र कॉपीराइट धारक नहीं हैं, तो आप अपने प्रोजेक्ट के लाइसेंस को एमआईटी में नहीं बदल सकते। मूलतः, अनुमेय लाइसेंस के साथ परियोजना के कॉपीराइट धारकों ने लाइसेंस बदलने की अग्रिम अनुमति दे दी है।
 
-**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+**आपके प्रोजेक्ट के मौजूदा कॉपीराइट धारक।** यदि आप अपने प्रोजेक्ट में एकमात्र योगदानकर्ता हैं तो या तो आप या आपकी कंपनी प्रोजेक्ट के एकमात्र कॉपीराइट धारक हैं। आप या आपकी कंपनी जो भी लाइसेंस जोड़ना या बदलना चाहती है, आप उसे जोड़ या बदल सकते हैं। अन्यथा ऐसे अन्य कॉपीराइट धारक भी हो सकते हैं जिनसे लाइसेंस बदलने के लिए आपको सहमति की आवश्यकता होगी। कौन हैं वे? जिन लोगों की आपके प्रोजेक्ट में प्रतिबद्धता है, वे शुरुआत करने के लिए एक अच्छी जगह हैं। लेकिन कुछ मामलों में कॉपीराइट उन लोगों के नियोक्ताओं के पास होगा। कुछ मामलों में लोगों ने केवल न्यूनतम योगदान दिया होगा, लेकिन ऐसा कोई सख्त नियम नहीं है कि कोड की कुछ पंक्तियों के तहत योगदान कॉपीराइट के अधीन नहीं है। क्या करें? निर्भर करता है। अपेक्षाकृत छोटी और युवा परियोजना के लिए, सभी मौजूदा योगदानकर्ताओं को किसी मुद्दे या पुल अनुरोध में लाइसेंस परिवर्तन के लिए सहमत करना संभव हो सकता है। बड़ी और लंबे समय तक चलने वाली परियोजनाओं के लिए, आपको कई योगदानकर्ताओं और यहां तक ​​कि उनके उत्तराधिकारियों की तलाश करनी पड़ सकती है। मोज़िला को फ़ायरफ़ॉक्स, थंडरबर्ड और संबंधित सॉफ़्टवेयर को पुनः लाइसेंस देने में वर्षों (2001-2006) लग गए।
 
-Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+वैकल्पिक रूप से, आप अपने मौजूदा ओपन सोर्स लाइसेंस द्वारा अनुमत शर्तों से परे, कुछ शर्तों के तहत कुछ लाइसेंस परिवर्तनों के लिए योगदानकर्ताओं को पहले से सहमत कर सकते हैं (एक अतिरिक्त योगदानकर्ता समझौते के माध्यम से - नीचे देखें)। इससे लाइसेंस बदलने की जटिलता कुछ हद तक बदल जाती है। आपको पहले से ही अपने वकीलों से अधिक सहायता की आवश्यकता होगी, और लाइसेंस परिवर्तन निष्पादित करते समय आप अभी भी अपने प्रोजेक्ट के हितधारकों के साथ स्पष्ट रूप से संवाद करना चाहेंगे।
 
-## 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).
+शायद नहीं। अधिकांश ओपन सोर्स परियोजनाओं के लिए, एक ओपन सोर्स लाइसेंस अंतर्निहित रूप से इनबाउंड (योगदानकर्ताओं से) और आउटबाउंड (अन्य योगदानकर्ताओं और उपयोगकर्ताओं के लिए) लाइसेंस दोनों के रूप में कार्य करता है।यदि आपका प्रोजेक्ट GitHub पर है, तो GitHub सेवा की शर्तें "इनबाउंड = आउटबाउंड" बनाती हैं [explicit default](https://help.github.com/en/github/site-policy/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.
+एक अतिरिक्त योगदानकर्ता समझौता - जिसे अक्सर Contributor License Agreement (CLA) कहा जाता है - परियोजना अनुरक्षकों के लिए प्रशासनिक कार्य बना सकता है। एक समझौता कितना काम जोड़ता है यह परियोजना और कार्यान्वयन पर निर्भर करता है। एक साधारण समझौते के लिए आवश्यक हो सकता है कि योगदानकर्ता एक क्लिक के साथ पुष्टि करें कि उनके पास प्रोजेक्ट ओपन सोर्स लाइसेंस के तहत योगदान करने के लिए आवश्यक अधिकार हैं। अधिक जटिल समझौते के लिए कानूनी समीक्षा और योगदानकर्ताओं के नियोक्ताओं से हस्ताक्षर की आवश्यकता हो सकती है।
 
-Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
+साथ ही, "कागजी कार्रवाई" जोड़कर, जो कुछ लोगों का मानना ​​है कि अनावश्यक, समझने में कठिन या अनुचित है (जब समझौते के प्राप्तकर्ता को परियोजना के ओपन सोर्स लाइसेंस के माध्यम से योगदानकर्ताओं या जनता की तुलना में अधिक अधिकार मिलते हैं), एक अतिरिक्त योगदानकर्ता समझौते को अमित्र माना जा सकता है परियोजना के समुदाय के लिए।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
-    We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+    हमने Node.js के लिए CLA को हटा दिया है। ऐसा करने से Node.js योगदानकर्ताओं के लिए प्रवेश की बाधा कम हो जाती है जिससे योगदानकर्ता आधार का विस्तार होता है।
   <p markdown="1" class="pquote-credit">
 — @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
-Some situations where you may want to consider an additional contributor agreement for your project include:
+कुछ स्थितियाँ जहाँ आप अपने प्रोजेक्ट के लिए अतिरिक्त योगदानकर्ता समझौते पर विचार करना चाह सकते हैं उनमें शामिल हैं:
 
-* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
-* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
-* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
-* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
-* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
+* आपके वकील चाहते हैं कि सभी योगदानकर्ता स्पष्ट रूप से (_साइन_, ऑनलाइन या ऑफलाइन) योगदान शर्तों को स्वीकार करें, शायद इसलिए क्योंकि उन्हें लगता है कि ओपन सोर्स लाइसेंस ही पर्याप्त नहीं है (भले ही यह है!)। यदि यह एकमात्र चिंता का विषय है, तो एक योगदानकर्ता समझौता जो परियोजना के ओपन सोर्स लाइसेंस की पुष्टि करता है, पर्याप्त होना चाहिए। [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) हल्के अतिरिक्त योगदानकर्ता समझौते का एक अच्छा उदाहरण है।
+* आप या आपके वकील चाहते हैं कि डेवलपर्स यह प्रतिनिधित्व करें कि उनकी प्रत्येक प्रतिबद्धता अधिकृत है. [Developer Certificate of Origin](https://developercertificate.org/) आवश्यकता यह है कि कितनी परियोजनाएँ इसे प्राप्त करती हैं। उदाहरण के लिए, Node.js समुदाय [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) उनके पूर्व CLI का। आपके भंडार पर डीसीओ के प्रवर्तन को स्वचालित करने का एक सरल विकल्प है [DCO Probot](https://github.com/probot/dco).
+*आपका प्रोजेक्ट एक ओपन सोर्स लाइसेंस का उपयोग करता है जिसमें एक्सप्रेस पेटेंट अनुदान (जैसे एमआईटी) शामिल नहीं है, और आपको सभी योगदानकर्ताओं से पेटेंट अनुदान की आवश्यकता है, जिनमें से कुछ बड़े पेटेंट पोर्टफोलियो वाली कंपनियों के लिए काम कर सकते हैं जिनका उपयोग आपको लक्षित करने के लिए किया जा सकता है या परियोजना के अन्य योगदानकर्ता और उपयोगकर्ता। The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) आमतौर पर इस्तेमाल किया जाने वाला अतिरिक्त योगदानकर्ता समझौता है जिसमें अपाचे लाइसेंस 2.0 में पाए गए पेटेंट अनुदान को प्रतिबिंबित किया गया है।
+* आपका प्रोजेक्ट कॉपीलेफ्ट लाइसेंस के अंतर्गत है, लेकिन आपको प्रोजेक्ट का मालिकाना संस्करण भी वितरित करने की आवश्यकता है। आपको प्रत्येक योगदानकर्ता से आपको कॉपीराइट सौंपने या आपको (लेकिन जनता को नहीं) अनुमेय लाइसेंस देने की आवश्यकता होगी। [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) इस प्रकार के समझौते का एक उदाहरण है.
+* आपको लगता है कि आपके प्रोजेक्ट को अपने जीवनकाल में लाइसेंस बदलने की आवश्यकता हो सकती है और आप चाहते हैं कि योगदानकर्ता ऐसे परिवर्तनों के लिए पहले से सहमत हों।
 
-If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+यदि आपको अपने प्रोजेक्ट के साथ एक अतिरिक्त योगदानकर्ता समझौते का उपयोग करने की आवश्यकता है, तो एक एकीकरण का उपयोग करने पर विचार करें [CLA assistant](https://github.com/cla-assistant/cla-assistant) योगदानकर्ता व्याकुलता को कम करने के लिए।
 
-## What does my company's legal team need to know?
+## मेरी कंपनी की कानूनी टीम को क्या जानना आवश्यक है?
 
-If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+यदि आप एक कंपनी कर्मचारी के रूप में एक ओपन सोर्स प्रोजेक्ट जारी कर रहे हैं, तो सबसे पहले, आपकी कानूनी टीम को पता होना चाहिए कि आप एक प्रोजेक्ट को ओपन सोर्स कर रहे हैं।
 
-For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+बेहतर या बदतर के लिए, उन्हें बताने पर विचार करें, भले ही यह एक व्यक्तिगत परियोजना हो। संभवत: आपके पास अपनी कंपनी के साथ एक "कर्मचारी आईपी समझौता" है जो उन्हें आपकी परियोजनाओं पर कुछ नियंत्रण देता है, खासकर यदि वे कंपनी के व्यवसाय से संबंधित हैं या आप परियोजना को विकसित करने के लिए किसी कंपनी के संसाधनों का उपयोग करते हैं। आपकी कंपनी को आपको आसानी से अनुमति देनी चाहिए, और शायद पहले से ही एक कर्मचारी-अनुकूल आईपी समझौते या कंपनी नीति के माध्यम से अनुमति दे दी है। यदि नहीं, तो आप बातचीत कर सकते हैं (उदाहरण के लिए, समझाएं कि आपका प्रोजेक्ट आपके लिए कंपनी के पेशेवर शिक्षण और विकास उद्देश्यों को पूरा करता है), या जब तक आपको एक बेहतर कंपनी नहीं मिल जाती, तब तक अपने प्रोजेक्ट पर काम करने से बचें।
 
-**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+**यदि आप अपनी कंपनी के लिए किसी प्रोजेक्ट की ओपन सोर्सिंग कर रहे हैं,** तो उन्हें अवश्य बताएं। आपकी कानूनी टीम के पास संभवतः पहले से ही नीतियां हैं कि कंपनी की व्यावसायिक आवश्यकताओं और विशेषज्ञता के आधार पर किस ओपन सोर्स लाइसेंस (और शायद अतिरिक्त योगदानकर्ता समझौते) का उपयोग किया जाए ताकि यह सुनिश्चित हो सके कि आपका प्रोजेक्ट उसकी निर्भरता के लाइसेंस का अनुपालन करता है। यदि नहीं, तो आप और वे भाग्यशाली हैं! आपकी कानूनी टीम को इस चीज़ का पता लगाने के लिए आपके साथ काम करने के लिए उत्सुक होना चाहिए। सोचने लायक कुछ बातें:
 
-* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+* **तृतीय पक्ष सामग्री:** क्या आपके प्रोजेक्ट में दूसरों द्वारा बनाई गई निर्भरताएँ हैं या अन्यथा दूसरों के कोड को शामिल या उपयोग करते हैं? यदि ये ओपन सोर्स हैं, तो आपको सामग्रियों के ओपन सोर्स लाइसेंस का अनुपालन करना होगा। इसकी शुरुआत एक ऐसे लाइसेंस को चुनने से होती है जो तीसरे पक्ष के ओपन सोर्स लाइसेंस के साथ काम करता है (ऊपर देखें)। यदि आपका प्रोजेक्ट तृतीय पक्ष ओपन सोर्स सामग्री को संशोधित या वितरित करता है, तो आपकी कानूनी टीम यह भी जानना चाहेगी कि आप तृतीय पक्ष ओपन सोर्स लाइसेंस की अन्य शर्तों को पूरा कर रहे हैं जैसे कि कॉपीराइट नोटिस बनाए रखना। यदि आपका प्रोजेक्ट दूसरों के कोड का उपयोग करता है जिसके पास ओपन सोर्स लाइसेंस नहीं है, तो आपको संभवतः तीसरे पक्ष के अनुरक्षकों से पूछना होगा [एक ओपन सोर्स लाइसेंस जोड़ें](https://choosealicense.com/no-license/#for-users), और यदि आपको कोई नहीं मिल सकता है, तो अपने प्रोजेक्ट में उनके कोड का उपयोग करना बंद कर दें।
 
-* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+* **व्यापार रहस्य:** विचार करें कि क्या परियोजना में ऐसा कुछ है जिसे कंपनी आम जनता के लिए उपलब्ध नहीं कराना चाहती है। यदि ऐसा है, तो जिस सामग्री को आप निजी रखना चाहते हैं, उसे निकालने के बाद आप अपने प्रोजेक्ट के बाकी हिस्से को ओपन सोर्स कर सकते हैं।
 
-* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
+* **पेटेंट:** क्या आपकी कंपनी किसी ऐसे पेटेंट के लिए आवेदन कर रही है जिसके ओपन सोर्सिंग से आपका प्रोजेक्ट [सार्वजनिक प्रकटीकरण](https://en.wikipedia.org/wiki/Public_disclosure) बनेगा? अफसोस की बात है, आपको प्रतीक्षा करने के लिए कहा जा सकता है (या हो सकता है कि कंपनी आवेदन की समझदारी पर पुनर्विचार करेगी)। यदि आप बड़े पेटेंट पोर्टफोलियो वाली कंपनियों के कर्मचारियों से अपने प्रोजेक्ट में योगदान की उम्मीद कर रहे हैं, तो आपकी कानूनी टीम चाहती है कि आप योगदानकर्ताओं (जैसे अपाचे 2.0 या जीपीएलवी 3) से एक्सप्रेस पेटेंट अनुदान के साथ लाइसेंस का उपयोग करें, या एक अतिरिक्त योगदानकर्ता अनुबंध ( ऊपर देखें)।
 
-* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+* **ट्रेडमार्क:** दोबारा जांचें कि आपके प्रोजेक्ट का नाम [किसी भी मौजूदा ट्रेडमार्क के साथ टकराव नहीं करता है](../starting-a-project/#avoiding-name-conflicts)। यदि आप प्रोजेक्ट में अपनी कंपनी के ट्रेडमार्क का उपयोग करते हैं, तो जांच लें कि इससे कोई टकराव न हो। [FOSSmarks](http://fossmarks.org/) मुक्त और मुक्त स्रोत परियोजनाओं के संदर्भ में ट्रेडमार्क को समझने के लिए एक व्यावहारिक मार्गदर्शिका है।
 
-* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+* **गोपनीयता:** क्या आपका प्रोजेक्ट उपयोगकर्ताओं पर डेटा एकत्र करता है? कंपनी सर्वर के लिए "फ़ोन होम"? आपकी कानूनी टीम कंपनी की नीतियों और बाहरी नियमों का अनुपालन करने में आपकी सहायता कर सकती है।
 
-If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+यदि आप अपनी कंपनी का पहला ओपन सोर्स प्रोजेक्ट जारी कर रहे हैं, तो उपरोक्त पूरा करने के लिए पर्याप्त से अधिक है (लेकिन चिंता न करें, अधिकांश परियोजनाओं को कोई बड़ी चिंता नहीं उठानी चाहिए)।
 
-Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+लंबी अवधि में, आपकी कानूनी टीम कंपनी को ओपन सोर्स में अपनी भागीदारी से अधिक लाभ प्राप्त करने और सुरक्षित रहने में मदद करने के लिए और अधिक प्रयास कर सकती है:
 
-* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+* **कर्मचारी योगदान नीतियां:** एक कॉर्पोरेट नीति विकसित करने पर विचार करें जो निर्दिष्ट करती है कि आपके कर्मचारी ओपन सोर्स परियोजनाओं में कैसे योगदान करते हैं। एक स्पष्ट नीति आपके कर्मचारियों के बीच भ्रम को कम करेगी और उन्हें कंपनी के सर्वोत्तम हित में ओपन सोर्स परियोजनाओं में योगदान करने में मदद करेगी, चाहे वह उनकी नौकरी के हिस्से के रूप में हो या उनके खाली समय में। एक अच्छा उदाहरण रैकस्पेस की [मॉडल आईपी और ओपन सोर्स योगदान नीति](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) है।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
-  Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+पैच से जुड़े आईपी को देने से कर्मचारी के ज्ञान का आधार और प्रतिष्ठा बनती है। यह दर्शाता है कि कंपनी ने उस कर्मचारी के विकास में निवेश किया है और सशक्तिकरण और स्वायत्तता की भावना पैदा की है। इन सभी लाभों से उच्च मनोबल और बेहतर कर्मचारी प्रतिधारण भी होता है।
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["एक मॉडल आईपी और ओपन सोर्स योगदान नीति"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
-* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
-* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+* **क्या जारी करें:** [(लगभग) सब कुछ?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) यदि आपकी कानूनी टीम समझती है और है यदि आपने अपनी कंपनी की ओपन सोर्स रणनीति में निवेश किया है, तो वे आपके प्रयासों में बाधा डालने के बजाय मदद करने में सर्वोत्तम रूप से सक्षम होंगे।
+* **अनुपालन:** भले ही आपकी कंपनी कोई ओपन सोर्स प्रोजेक्ट जारी नहीं करती है, यह दूसरों के ओपन सोर्स सॉफ़्टवेयर का उपयोग करती है। [जागरूकता और प्रक्रिया](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) सिरदर्द, उत्पाद में देरी और मुकदमों को रोक सकती है .
 
 <aside markdown="1" class="pquote">
-  Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+  संगठनों के पास एक लाइसेंस और अनुपालन रणनीति होनी चाहिए जो \["अनुमोदनात्मक" और "कॉपीलेफ्ट"\] दोनों श्रेणियों में फिट हो। इसकी शुरुआत उन लाइसेंसिंग शर्तों का रिकॉर्ड रखने से होती है जो आपके द्वारा उपयोग किए जा रहे ओपन सोर्स सॉफ़्टवेयर पर लागू होती हैं - जिसमें उप-घटक और निर्भरताएं शामिल हैं।
   <p markdown="1" class="pquote-credit">
-— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+— Heather Meeker, ["ओपन सोर्स सॉफ्टवेयर: अनुपालन की मूल बातें और सर्वोत्तम प्रथाएं"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
   </p>
 </aside>
 
-* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
-* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
+* **पेटेंट:** आपकी कंपनी प्रमुख ओपन सोर्स परियोजनाओं के सदस्यों के उपयोग की सुरक्षा के लिए एक साझा रक्षात्मक पेटेंट पूल [ओपन इन्वेंशन नेटवर्क](https://www.openinventionnetwork.com/) में शामिल होना चाह सकती है, या अन्वेषण कर सकती है अन्य [वैकल्पिक पेटेंट लाइसेंसिंग](https://www.eff.org/document/hacking-patent-system-2016).
+
+* **शासन:** विशेष रूप से यदि और जब किसी प्रोजेक्ट को स्थानांतरित करना उचित हो [कंपनी के बाहर कानूनी इकाई](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
diff --git a/_articles/hi/maintaining-balance-for-open-source-maintainers.md b/_articles/hi/maintaining-balance-for-open-source-maintainers.md
index 51d312d3499..4282247015b 100644
--- a/_articles/hi/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/hi/maintaining-balance-for-open-source-maintainers.md
@@ -1,187 +1,187 @@
 ---
-lang: en
+lang: hi
 untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+title: ओपन सोर्स अनुरक्षकों के लिए संतुलन बनाए रखना
+description: एक अनुचर के रूप में स्वयं की देखभाल और बर्नआउट से बचने के लिए युक्तियाँ।
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+जैसे-जैसे एक ओपन सोर्स प्रोजेक्ट की लोकप्रियता बढ़ती है, आपको लंबे समय तक तरोताजा और उत्पादक बने रहने के लिए संतुलन बनाए रखने में मदद करने के लिए स्पष्ट सीमाएँ निर्धारित करना महत्वपूर्ण हो जाता है।
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+संतुलन खोजने के लिए अनुरक्षकों के अनुभवों और उनकी रणनीतियों के बारे में जानकारी प्राप्त करने के लिए, हमने <a href="http://maintainers.github.com/">मेंटेनर समुदाय</a> के 40 सदस्यों के साथ एक कार्यशाला चलाई, जिससे हमें अनुमति मिली खुले स्रोत में बर्नआउट के साथ उनके प्रत्यक्ष अनुभवों और उन प्रथाओं से सीखना जिन्होंने उन्हें अपने काम में संतुलन बनाए रखने में मदद की है। यहीं पर व्यक्तिगत पारिस्थितिकी की अवधारणा काम आती है।
 
-So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+तो, व्यक्तिगत पारिस्थितिकी क्या है? जैसा <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance% 2सी%20पेसिंग%20और%20दक्षता%20टू%20सस्टेन%20योर%20एनर्जी%20ओवर%20ए%20लाइफटाइम%20ऑफ%20एक्टिविज्म">रॉकवुड लीडरशिप इंस्टीट्यूट द्वारा वर्णित</a>, इसमें "<strong>संतुलन बनाए रखना, गति बनाए रखना और शामिल है जीवन भर हमारी ऊर्जा को बनाए रखने की दक्षता</strong>।" इसने हमारी बातचीत को तैयार किया, जिससे अनुरक्षकों को समय के साथ विकसित होने वाले एक बड़े पारिस्थितिकी तंत्र के हिस्से के रूप में अपने कार्यों और योगदान को पहचानने में मदद मिली। बर्नआउट, क्रोनिक कार्यस्थल तनाव से उत्पन्न एक सिंड्रोम जैसा कि [डब्ल्यूएचओ द्वारा परिभाषित](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), अनुरक्षकों के बीच असामान्य नहीं है। इससे अक्सर प्रेरणा की हानि, ध्यान केंद्रित करने में असमर्थता और उन योगदानकर्ताओं और समुदाय के लिए सहानुभूति की कमी हो जाती है जिनके साथ आप काम करते हैं।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
-  I was unable to focus or start on a task. I had a lack of empathy for users.
+  मैं किसी कार्य पर ध्यान केंद्रित करने या शुरू करने में असमर्थ था। मेरे अंदर उपयोगकर्ताओं के प्रति सहानुभूति की कमी थी।
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href='https://github.com/gabek'>@gabek</a>, ओनकास्ट लाइव स्ट्रीमिंग सर्वर के अनुरक्षक, अपने ओपन सोर्स कार्य पर बर्नआउट के प्रभाव पर
   </p>
 </aside>
 
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+व्यक्तिगत पारिस्थितिकी की अवधारणा को अपनाकर, अनुरक्षक सक्रिय रूप से बर्नआउट से बच सकते हैं, आत्म-देखभाल को प्राथमिकता दे सकते हैं और अपना सर्वश्रेष्ठ कार्य करने के लिए संतुलन की भावना बनाए रख सकते हैं।
 
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+## एक अनुरक्षक के रूप में स्वयं की देखभाल और बर्नआउट से बचने के लिए युक्तियाँ:
 
-### Identify your motivations for working in open source
+### ओपन सोर्स में काम करने के लिए अपनी प्रेरणाओं को पहचानें
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+इस बात पर विचार करने के लिए समय निकालें कि ओपन सोर्स रखरखाव के कौन से हिस्से आपको ऊर्जावान बनाते हैं। अपनी प्रेरणाओं को समझने से आपको काम को इस तरह से प्राथमिकता देने में मदद मिल सकती है जिससे आप व्यस्त रहेंगे और नई चुनौतियों के लिए तैयार रहेंगे। चाहे वह उपयोगकर्ताओं से सकारात्मक प्रतिक्रिया हो, समुदाय के साथ सहयोग और मेलजोल की खुशी हो, या कोड में गोता लगाने की संतुष्टि हो, अपनी प्रेरणाओं को पहचानने से आपका ध्यान केंद्रित करने में मदद मिल सकती है।
 
-### Reflect on what causes you to get out of balance and stressed out
+### इस बात पर विचार करें कि किन कारणों से आप असंतुलित हो जाते हैं और तनावग्रस्त हो जाते हैं
 
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+यह समझना महत्वपूर्ण है कि किन कारणों से हम थक जाते हैं। यहां कुछ सामान्य विषय हैं जो हमने ओपन सोर्स अनुरक्षकों के बीच देखे हैं:
 
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+* **सकारात्मक प्रतिक्रिया का अभाव:** उपयोगकर्ताओं के पास शिकायत होने पर संपर्क करने की बहुत अधिक संभावना होती है। यदि सब कुछ बढ़िया चलता है, तो वे चुप रहना पसंद करते हैं। सकारात्मक प्रतिक्रिया के बिना मुद्दों की बढ़ती सूची को देखना हतोत्साहित करने वाला हो सकता है, जिसमें दिखाया गया हो कि आपके योगदान से कैसे फर्क पड़ रहा है।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
-  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  कभी-कभी ऐसा महसूस होता है जैसे शून्य में चिल्लाना और मुझे लगता है कि प्रतिक्रिया वास्तव में मुझे ऊर्जावान बनाती है। हमारे पास बहुत सारे खुश लेकिन शांत उपयोगकर्ता हैं।
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+— <a href="https://github.com/thisisnic">@thisisnic</a>, अपाचे एरो का अनुरक्षक
   </p>
 </aside>
 
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **'नहीं' नहीं कहना:** किसी ओपन सोर्स प्रोजेक्ट पर अपनी अपेक्षा से अधिक ज़िम्मेदारियाँ लेना आसान हो सकता है। चाहे यह उपयोगकर्ताओं, योगदानकर्ताओं, या अन्य अनुरक्षकों से हो - हम हमेशा उनकी अपेक्षाओं पर खरे नहीं उतर सकते।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
-  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  मैंने पाया कि मैं एक से अधिक काम ले रहा था और मुझे कई लोगों का काम करना पड़ रहा था, जैसा कि आम तौर पर FOSS में किया जाता है।
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, टर्मक्स के अनुरक्षक, उनके काम में बर्नआउट का कारण क्या है
   </p>
 </aside>
 
-* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+* **अकेले काम करना:** एक अनुरक्षक बनना अविश्वसनीय रूप से अकेला हो सकता है। भले ही आप अनुरक्षकों के एक समूह के साथ काम करते हैं, पिछले कुछ वर्षों में वितरित टीमों को व्यक्तिगत रूप से बुलाना कठिन रहा है।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
- Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+विशेष रूप से चूंकि कोविड और घर से काम करने के कारण कभी किसी को नहीं देखना या किसी से बात करना कठिन हो गया है।
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, ओनकास्ट लाइव स्ट्रीमिंग सर्वर के अनुरक्षक, अपने ओपन सोर्स कार्य पर बर्नआउट के प्रभाव पर
   </p>
 </aside>
 
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **पर्याप्त समय या संसाधन नहीं:** यह स्वयंसेवक अनुरक्षकों के लिए विशेष रूप से सच है, जिन्हें किसी परियोजना पर काम करने के लिए अपने खाली समय का त्याग करना पड़ता है।
 
 <aside markdown="1" class="pquote">
-  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  [मैं चाहूंगा] अधिक वित्तीय सहायता, ताकि मैं अपनी बचत खर्च किए बिना ओपन सोर्स कार्य पर ध्यान केंद्रित कर सकूं और यह जान सकूं कि बाद में इसकी भरपाई के लिए मुझे बहुत सारे अनुबंध करने होंगे।
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— ओपन सोर्स अनुरक्षक
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **परस्पर विरोधी मांगें:** खुला स्रोत विभिन्न प्रेरणाओं वाले समूहों से भरा है, जिन्हें नेविगेट करना मुश्किल हो सकता है। यदि आपको ओपन सोर्स करने के लिए भुगतान किया जाता है, तो आपके नियोक्ता के हित कभी-कभी समुदाय के विपरीत हो सकते हैं।
 
 <aside markdown="1" class="pquote">
-  With paid open source, conflict between employer's focus and what's best for the community
+  सशुल्क ओपन सोर्स के साथ, नियोक्ता के फोकस और समुदाय के लिए सबसे अच्छा क्या है के बीच संघर्ष होता है
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— ओपन सोर्स अनुरक्षक
   </p>
 </aside>
 
-### Watch out for signs of burnout
+### बर्नआउट के लक्षणों से सावधान रहें
 
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+क्या आप 10 सप्ताह तक अपनी गति बनाए रख सकते हैं? दस महीने? 10 वर्ष?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+उपकरण जैसे [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) [@shaunagm](https://github.com/shaunagm) से और मोज़िला का [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) इससे आपको अपनी वर्तमान गति पर विचार करने और यह देखने में मदद मिल सकती है कि क्या आप कोई समायोजन कर सकते हैं। कुछ अनुरक्षक नींद की गुणवत्ता और हृदय गति परिवर्तनशीलता (दोनों तनाव से जुड़े हुए हैं) जैसे मेट्रिक्स को ट्रैक करने के लिए पहनने योग्य तकनीक का भी उपयोग करते हैं।
 
 <aside markdown="1" class="pquote">
- I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+ मैं अच्छे पहनने योग्य वस्तुओं में बड़ा विश्वास रखता हूँ। इसके पीछे के विज्ञान से, आप समझ सकते हैं कि आप कैसे बेहतर कर सकते थे और आप जो करना चाहते हैं उसकी इष्टतम स्थिति कैसे प्राप्त करें।
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— ओपन सोर्स अनुरक्षक
   </p>
 </aside>
 
-### What would you need to continue sustaining yourself and your community?
+### आपको अपना और अपने समुदाय का भरण-पोषण जारी रखने के लिए क्या चाहिए होगा?
 
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+यह प्रत्येक अनुरक्षक के लिए अलग दिखेगा, और आपके जीवन के चरण और अन्य बाहरी कारकों के आधार पर बदल जाएगा। लेकिन यहां कुछ विषय हैं जो हमने सुने हैं:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **समुदाय पर निर्भर रहें:** प्रतिनिधिमंडल और योगदानकर्ताओं को ढूंढने से काम का बोझ कम हो सकता है। किसी प्रोजेक्ट के लिए संपर्क के कई बिंदु होने से आपको बिना किसी चिंता के ब्रेक लेने में मदद मिल सकती है। [मेंटेनर कम्युनिटी](http://maintainers.github.com/) जैसे समूहों में अन्य अनुरक्षकों और व्यापक समुदाय से जुड़ें। साथियों के समर्थन और सीखने के लिए यह एक बेहतरीन संसाधन हो सकता है।
 
-  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+  आप उपयोगकर्ता समुदाय के साथ जुड़ने के तरीकों की भी तलाश कर सकते हैं, ताकि आप नियमित रूप से फीडबैक सुन सकें और अपने ओपन सोर्स कार्य के प्रभाव को समझ सकें।
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **फंडिंग का अन्वेषण करें:** चाहे आप कुछ पिज़्ज़ा मनी की तलाश में हों, या पूर्णकालिक ओपन सोर्स पर जाने की कोशिश कर रहे हों, मदद के लिए कई संसाधन मौजूद हैं! पहले कदम के रूप में, दूसरों को आपके ओपन सोर्स कार्य को प्रायोजित करने की अनुमति देने के लिए [GitHub प्रायोजक](https://github.com/sponsors) को चालू करने पर विचार करें। यदि आप पूर्णकालिक बनने के बारे में सोच रहे हैं, तो [GitHub Accelerator](http://accelerator.github.com/) के अगले दौर के लिए आवेदन करें।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
- I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+मैं कुछ समय पहले पॉडकास्ट पर था और हम ओपन सोर्स रखरखाव और स्थिरता के बारे में बातचीत कर रहे थे। मैंने पाया कि GitHub पर मेरे काम का समर्थन करने वाले बहुत कम लोगों ने भी मुझे गेम के सामने नहीं बैठने, बल्कि ओपन सोर्स के साथ एक छोटा सा काम करने का त्वरित निर्णय लेने में मदद की।
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+— <a href="https://github.com/mansona">@mansona</a>, EmberJS के अनुरक्षक
   </p>
 </aside>
 
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+* **टूल्स का उपयोग करें:** सांसारिक कार्यों को स्वचालित करने के लिए [GitHub Copilot](https://github.com/features/copilot/) और [GitHub Actions](https://github.com/features/actions) जैसे टूल खोजें कार्य करें और अधिक सार्थक योगदान के लिए अपना समय खाली करें।
 
 <aside markdown="1" class="pquote">
- Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+ उबाऊ चीज़ों के लिए [कोपायलट](https://github.com/features/copilot/) का उपयोग करें - मज़ेदार चीज़ें करें
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— ओपन सोर्स अनुरक्षक
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+* **आराम करें और रिचार्ज करें:** ओपन सोर्स के बाहर अपने शौक और रुचियों के लिए समय निकालें। आराम करने और तरोताजा होने के लिए सप्ताहांत की छुट्टी लें-और अपना काम शुरू करें [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) आपकी उपलब्धता दर्शाने के लिए! एक अच्छी रात की नींद आपके प्रयासों को लंबे समय तक जारी रखने की आपकी क्षमता में बड़ा अंतर ला सकती है।
 
-  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+  यदि आपको अपने प्रोजेक्ट के कुछ पहलू विशेष रूप से आनंददायक लगते हैं, तो अपने काम को इस प्रकार व्यवस्थित करने का प्रयास करें ताकि आप इसे पूरे दिन अनुभव कर सकें।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+मुझे शाम को स्विच ऑफ करने की बजाय दिन के मध्य में 'रचनात्मकता के क्षण' बिखेरने का अधिक अवसर मिल रहा है।
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+— <a href="https://github.com/danielroe">@danielroe</a>, Nuxt का अनुरक्षक
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **सीमाएँ निर्धारित करें:** आप हर अनुरोध के लिए हाँ नहीं कह सकते। यह कहने जितना सरल हो सकता है, "मैं अभी उस तक नहीं पहुंच सकता और भविष्य में मेरी कोई योजना नहीं है," या README में यह सूचीबद्ध करना कि आप क्या करने में रुचि रखते हैं और क्या नहीं करने में। उदाहरण के लिए, आप कह सकते हैं: "मैं केवल उन पीआर का विलय करता हूं जिनमें स्पष्ट रूप से उन कारणों को सूचीबद्ध किया गया है कि उन्हें क्यों बनाया गया है," या, "मैं केवल वैकल्पिक गुरुवार को शाम 6 से 7 बजे तक मुद्दों की समीक्षा करता हूं।" यह दूसरों के लिए अपेक्षाएं निर्धारित करता है, और आपको कुछ देता है अपने समय पर योगदानकर्ताओं या उपयोगकर्ताओं की मांगों को कम करने में मदद करने के लिए अन्य समय पर इंगित करना।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+इन अक्षों पर दूसरों पर सार्थक रूप से भरोसा करने के लिए, आप ऐसा व्यक्ति नहीं बन सकते जो हर अनुरोध के लिए हाँ कहता है। ऐसा करने पर, आप पेशेवर या व्यक्तिगत रूप से कोई सीमा नहीं बनाए रखते हैं, और एक विश्वसनीय सहकर्मी नहीं होंगे।
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, होमब्रू के अनुरक्षक [इंकार करना](https://mikemcquaid.com/saying-no/)
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+  विषाक्त व्यवहार और नकारात्मक बातचीत को बंद करने में दृढ़ रहना सीखें। उन चीज़ों को ऊर्जा न देना ठीक है जिनकी आपको परवाह नहीं है।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-My software is gratis, but my time and attention is not.
+मेरा सॉफ्टवेयर मुफ़्त है, लेकिन मेरा समय और ध्यान मुफ़्त नहीं है।
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, पत्रक का अनुरक्षक
   </p>
 </aside>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+यह कोई रहस्य नहीं है कि ओपन सोर्स रखरखाव के अपने अंधेरे पक्ष हैं, और इनमें से एक कभी-कभी काफी कृतघ्न, हकदार या पूरी तरह से विषाक्त लोगों के साथ बातचीत करना है। जैसे-जैसे किसी प्रोजेक्ट की लोकप्रियता बढ़ती है, वैसे-वैसे इस तरह की बातचीत की आवृत्ति भी बढ़ती है, जिससे अनुरक्षकों पर बोझ बढ़ जाता है और संभवतः अनुरक्षक बर्नआउट के लिए एक महत्वपूर्ण जोखिम कारक बन जाता है। 
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>, ऑक्टोप्रिंट का अनुरक्षक [जहरीले लोगों से कैसे निपटें](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
 </aside>
 
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+याद रखें, व्यक्तिगत पारिस्थितिकी एक सतत अभ्यास है जो आपकी ओपन सोर्स यात्रा में प्रगति के साथ विकसित होगी। आत्म-देखभाल को प्राथमिकता देकर और संतुलन की भावना बनाए रखकर, आप प्रभावी ढंग से और स्थायी रूप से ओपन सोर्स समुदाय में योगदान कर सकते हैं, जिससे आपकी भलाई और लंबे समय तक आपकी परियोजनाओं की सफलता दोनों सुनिश्चित हो सकती है।
 
-## Additional Resources
+## अतिरिक्त संसाधन
 
-* [Maintainer Community](http://maintainers.github.com/)
-* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
-* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
-* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
-* [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
-* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
-* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
-* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+* [मेंटेनर समुदाय](http://maintainers.github.com/)
+* [ओपन सोर्स का सामाजिक अनुबंध](https://snarky.ca/the-social-contract-of-open-source/), ब्रेट कैनन
+* [अनकर्लड](https://daniel.haxx.se/uncurled/), डेनियल स्टेनबर्ग
+* [जहरीले लोगों से कैसे निपटें](https://www.youtube.com/watch?v=7lIpP3GEyXs), जीना हाउजगे
+* [सस्टेनओएसएस](https://sustainoss.org/)
+* [व्यक्तिगत पारिस्थितिकी स्व-मूल्यांकन किट](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), मोज़िला
+* [नेतृत्व की रॉकवुड कला](https://rockwoodleadership.org/art-of-leadership/)
+* [नहीं कहना](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), माइक मैकक्यूएड
+* [गवर्निंग ओपन](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* कार्यशाला के एजेंडे को रीमिक्स किया गया था [घर से मोज़िला की मूवमेंट बिल्डिंग](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) शृंखला
 
-## Contributors
+## योगदानकर्ताओं
 
-Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+इस गाइड के लिए अपने अनुभव और सुझाव हमारे साथ साझा करने वाले सभी अनुरक्षकों को बहुत धन्यवाद!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+यह मार्गदर्शिका [@abbycabs](https://github.com/abbycabs) द्वारा इनके योगदान के साथ लिखी गई थी:
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
diff --git a/_articles/hi/metrics.md b/_articles/hi/metrics.md
index 145dd18119b..5f4de85f9ba 100644
--- a/_articles/hi/metrics.md
+++ b/_articles/hi/metrics.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Open Source Metrics
-description: Make informed decisions to help your open source project thrive by measuring and tracking its success.
+lang: hi
+title: ओपन सोर्स मेट्रिक्स
+description: अपने ओपन सोर्स प्रोजेक्ट की सफलता को मापने और ट्रैक करके उसे फलने-फूलने में मदद करने के लिए सोच-समझकर निर्णय लें।
 class: metrics
 order: 9
 image: /assets/images/cards/metrics.png
@@ -10,119 +10,119 @@ related:
   - best-practices
 ---
 
-## Why measure anything?
+## किसी भी चीज़ को क्यों मापें?
 
-Data, when used wisely, can help you make better decisions as an open source maintainer.
+डेटा, जब बुद्धिमानी से उपयोग किया जाता है, तो आपको ओपन सोर्स अनुरक्षक के रूप में बेहतर निर्णय लेने में मदद मिल सकती है।
 
-With more information, you can:
+अधिक जानकारी के साथ, आप यह कर सकते हैं:
 
-* Understand how users respond to a new feature
-* Figure out where new users come from
-* Identify, and decide whether to support, an outlier use case or functionality
-* Quantify your project's popularity
-* Understand how your project is used
-* Raise money through sponsorships and grants
+* समझें कि उपयोगकर्ता किसी नई सुविधा पर कैसे प्रतिक्रिया देते हैं
+* पता लगाएं कि नए उपयोगकर्ता कहां से आते हैं
+* बाहरी उपयोग के मामले या कार्यक्षमता को पहचानें और निर्णय लें कि इसका समर्थन करना है या नहीं
+* अपने प्रोजेक्ट की लोकप्रियता का आकलन करें
+* समझें कि आपके प्रोजेक्ट का उपयोग कैसे किया जाता है
+* प्रायोजन और अनुदान के माध्यम से धन जुटाएं
 
-For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+उदाहरण के लिए, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) ने पाया कि Google Analytics उन्हें काम को प्राथमिकता देने में मदद करता है:
 
-> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+> होमब्रू निःशुल्क प्रदान किया जाता है और इसे पूरी तरह से स्वयंसेवकों द्वारा अपने खाली समय में चलाया जाता है। परिणामस्वरूप, हमारे पास भविष्य की सुविधाओं को सर्वोत्तम तरीके से डिज़ाइन करने और वर्तमान कार्य को प्राथमिकता देने के तरीके पर निर्णय लेने के लिए होमब्रू उपयोगकर्ताओं का विस्तृत उपयोगकर्ता अध्ययन करने के लिए संसाधन नहीं हैं। अनाम समग्र उपयोगकर्ता विश्लेषण हमें लोग होमब्रू का उपयोग कैसे, कहां और कब करते हैं, इसके आधार पर सुधारों और सुविधाओं को प्राथमिकता देने की अनुमति देते हैं।
 
-Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+लोकप्रियता ही सब कुछ नहीं है. हर कोई अलग-अलग कारणों से खुले स्रोत में आ जाता है। यदि एक ओपन सोर्स अनुरक्षक के रूप में आपका लक्ष्य अपना काम दिखाना है, अपने कोड के बारे में पारदर्शी होना है, या सिर्फ मनोरंजन करना है, तो मेट्रिक्स आपके लिए महत्वपूर्ण नहीं हो सकते हैं।
 
-If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+यदि आप अपने प्रोजेक्ट को गहराई से समझने में रुचि रखते हैं, तो अपने प्रोजेक्ट की गतिविधि का विश्लेषण करने के तरीकों के लिए आगे पढ़ें।
 
-## Discovery
+## खोज
 
-Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+इससे पहले कि कोई भी आपके प्रोजेक्ट का उपयोग कर सके या उसमें योगदान कर सके, उन्हें यह जानना होगा कि यह मौजूद है। अपने आप से पूछें: _क्या लोगों को यह प्रोजेक्ट मिल रहा है?_
 
 ![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:
+यदि आपका प्रोजेक्ट GitHub पर होस्ट किया गया है, [आप देख सकते हैं](https://help.github.com/articles/about-repository-graphs/#traffic) आपके प्रोजेक्ट पर कितने लोग आते हैं और वे कहाँ से आते हैं। अपने प्रोजेक्ट के पेज से, "इनसाइट्स" पर क्लिक करें, फिर "ट्रैफ़िक" पर क्लिक करें। इस पृष्ठ पर, आप देख सकते हैं:
 
-* **Total page views:** Tells you how many times your project was viewed
+* **कुल पृष्ठ दृश्य:** आपको बताता है कि आपका प्रोजेक्ट कितनी बार देखा गया
 
-* **Total unique visitors:** Tells you how many people viewed your project
+* **कुल अद्वितीय विज़िटर:** आपको बताता है कि कितने लोगों ने आपका प्रोजेक्ट देखा
 
-* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+* **रेफ़रिंग साइटें:** आपको बताती हैं कि विज़िटर कहाँ से आए। यह मीट्रिक आपको यह पता लगाने में मदद कर सकता है कि आपको अपने दर्शकों तक कहां पहुंचना है और क्या आपके प्रचार प्रयास काम कर रहे हैं।
 
-* **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.
+[गिटहब सितारे](https://help.github.com/articles/about-stars/) लोकप्रियता का आधारभूत माप प्रदान करने में भी मदद मिल सकती है। हालाँकि GitHub सितारे आवश्यक रूप से डाउनलोड और उपयोग से संबंधित नहीं हैं, वे आपको बता सकते हैं कि कितने लोग आपके काम पर ध्यान दे रहे हैं।
 
-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.
+आप भी चाहते होंगे [tविशिष्ट स्थानों में रैक खोज योग्यता](https://opensource.com/business/16/6/pirate-metrics): उदाहरण के लिए, Google पेजरैंक, आपके प्रोजेक्ट की वेबसाइट से रेफरल ट्रैफ़िक, या अन्य ओपन सोर्स प्रोजेक्ट या वेबसाइट से रेफरल।
 
-## Usage
+## उपयोग
 
-People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+लोग आपके प्रोजेक्ट को इस जंगली और पागलपन वाली चीज़ पर ढूंढ रहे हैं जिसे हम इंटरनेट कहते हैं। आदर्श रूप से, जब वे आपका प्रोजेक्ट देखेंगे, तो वे कुछ करने के लिए मजबूर महसूस करेंगे। दूसरा प्रश्न जो आप पूछना चाहेंगे वह है: _क्या लोग इस परियोजना का उपयोग कर रहे हैं?_
 
-If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+यदि आप अपने प्रोजेक्ट को वितरित करने के लिए npm या RubyGems.org जैसे पैकेज मैनेजर का उपयोग करते हैं, तो आप अपने प्रोजेक्ट के डाउनलोड को ट्रैक करने में सक्षम हो सकते हैं।
 
-Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+प्रत्येक पैकेज प्रबंधक "डाउनलोड" की थोड़ी अलग परिभाषा का उपयोग कर सकता है, और डाउनलोड आवश्यक रूप से इंस्टॉल या उपयोग से संबंधित नहीं है, लेकिन यह तुलना के लिए कुछ आधार रेखा प्रदान करता है। कई लोकप्रिय पैकेज प्रबंधकों में उपयोग के आंकड़ों को ट्रैक करने के लिए [Libraries.io](https://libraries.io/) का उपयोग करने का प्रयास करें।
 
-If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+यदि आपका प्रोजेक्ट GitHub पर है, तो "ट्रैफ़िक" पृष्ठ पर फिर से नेविगेट करें। आप यह देखने के लिए [क्लोन ग्राफ](https://github.com/blog/1873-clone-graphs) का उपयोग कर सकते हैं कि आपके प्रोजेक्ट को किसी दिए गए दिन में कितनी बार क्लोन किया गया है, कुल क्लोन और अद्वितीय क्लोनर्स द्वारा विभाजित किया गया है।
 
-![Clone graph](/assets/images/metrics/clone_graph.png)
+![क्लोन ग्राफ़](/assets/images/metrics/clone_graph.png)
 
-If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+यदि आपके प्रोजेक्ट को खोजने वाले लोगों की संख्या की तुलना में उपयोग कम है, तो विचार करने के लिए दो मुद्दे हैं। दोनों में से एक:
 
-* Your project isn't successfully converting your audience, or
-* You're attracting the wrong audience
+* आपका प्रोजेक्ट आपके दर्शकों को सफलतापूर्वक परिवर्तित नहीं कर रहा है, या
+* आप गलत दर्शकों को आकर्षित कर रहे हैं
 
-For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+उदाहरण के लिए, यदि आपका प्रोजेक्ट हैकर न्यूज़ के पहले पन्ने पर आता है, तो आपको संभवतः खोज (ट्रैफ़िक) में वृद्धि दिखाई देगी, लेकिन रूपांतरण दर कम होगी, क्योंकि आप हैकर न्यूज़ पर सभी तक पहुंच रहे हैं। हालाँकि, यदि आपका रूबी प्रोजेक्ट रूबी सम्मेलन में प्रदर्शित किया गया है, तो आपको लक्षित दर्शकों से उच्च रूपांतरण दर देखने की अधिक संभावना है।
 
-Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+यह पता लगाने का प्रयास करें कि आपके दर्शक कहां से आ रहे हैं और अपने प्रोजेक्ट पेज पर दूसरों से फीडबैक मांगें ताकि यह पता चल सके कि आप इन दोनों में से किस समस्या का सामना कर रहे हैं।
 
-Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+एक बार जब आप जान जाते हैं कि लोग आपके प्रोजेक्ट का उपयोग कर रहे हैं, तो आप यह पता लगाने की कोशिश करना चाहेंगे कि वे इसके साथ क्या कर रहे हैं। क्या वे आपके कोड को फोर्क करके और सुविधाएँ जोड़कर इस पर निर्माण कर रहे हैं? क्या वे इसका उपयोग विज्ञान या व्यवसाय के लिए कर रहे हैं?
 
-## Retention
+## अवधारण
 
-People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+लोगों को आपका प्रोजेक्ट मिल रहा है और वे इसका उपयोग कर रहे हैं। अगला प्रश्न जो आप स्वयं से पूछना चाहेंगे वह है: _क्या लोग इस परियोजना में योगदान दे रहे हैं?_
 
-It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+योगदानकर्ताओं के बारे में सोचना शुरू करना कभी भी जल्दी नहीं है। अन्य लोगों के हस्तक्षेप के बिना, आप अपने आप को एक अस्वस्थ स्थिति में डालने का जोखिम उठाते हैं जहां आपका प्रोजेक्ट लोकप्रिय है (कई लोग इसका उपयोग करते हैं) लेकिन समर्थित नहीं है (मांग को पूरा करने के लिए रखरखाव के लिए पर्याप्त समय नहीं है)।
 
-Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+प्रतिधारण के लिए [नए योगदानकर्ताओं की आमद](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), की भी आवश्यकता होती है, चूँकि पहले सक्रिय योगदानकर्ता अंततः अन्य चीज़ों की ओर बढ़ेंगे।
 
-Examples of community metrics that you may want to regularly track include:
+सामुदायिक मेट्रिक्स के उदाहरण जिन्हें आप नियमित रूप से ट्रैक करना चाहते हैं उनमें शामिल हैं:
 
-* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+* **कुल योगदानकर्ता संख्या और प्रति योगदानकर्ता प्रतिबद्धताओं की संख्या:** आपको बताता है कि आपके पास कितने योगदानकर्ता हैं, और कौन कम या ज्यादा सक्रिय है। GitHub पर, आप इसे "अंतर्दृष्टि" -> "योगदानकर्ता" के अंतर्गत देख सकते हैं। अभी, यह ग्राफ़ केवल उन योगदानकर्ताओं की गणना करता है जिन्होंने रिपॉजिटरी की डिफ़ॉल्ट शाखा के लिए प्रतिबद्ध किया है।
 
-![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+![योगदानकर्ता ग्राफ](/assets/images/metrics/repo_contributors_specific_graph.png)
 
-* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+* **पहली बार, आकस्मिक और बार-बार योगदान देने वाले:** आपको यह ट्रैक करने में मदद करता है कि क्या आपको नए योगदानकर्ता मिल रहे हैं, और क्या वे वापस आते हैं। (आकस्मिक योगदानकर्ता कम संख्या में कमिट वाले योगदानकर्ता होते हैं। चाहे वह एक कमिट हो, पांच से कम कमिट हो, या कुछ और यह आप पर निर्भर है।) नए योगदानकर्ताओं के बिना, आपके प्रोजेक्ट का समुदाय स्थिर हो सकता है।
 
-* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+* **खुले मुद्दों और खुले पुल अनुरोधों की संख्या:** यदि ये संख्या बहुत अधिक हो जाती है, तो आपको समस्या परीक्षण और कोड समीक्षा में मदद की आवश्यकता हो सकती है।
 
-* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+* **_खुले हुए_ मुद्दों और _खुले_पुल अनुरोधों की संख्या:** खुले हुए मुद्दों का मतलब है कि किसी को आपके प्रोजेक्ट की इतनी परवाह है कि वह किसी मुद्दे को खोल सके। यदि वह संख्या समय के साथ बढ़ती है, तो यह दर्शाता है कि लोग आपके प्रोजेक्ट में रुचि रखते हैं।
 
-* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+* **योगदान के प्रकार:** उदाहरण के लिए, कमिट करना, टाइपो या बग को ठीक करना, या किसी मुद्दे पर टिप्पणी करना।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
-  Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+  ओपन सोर्स सिर्फ कोड से कहीं अधिक है। सफल ओपन सोर्स परियोजनाओं में इन परिवर्तनों के बारे में बातचीत के साथ-साथ कोड और दस्तावेज़ीकरण योगदान भी शामिल हैं।
   <p markdown="1" class="pquote-credit">
-— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+— @arfon, ["ओपन सोर्स का आकार"](https://github.com/blog/2195-the-shape-of-open-source)
   </p>
 </aside>
 
-## Maintainer activity
+## अनुरक्षक गतिविधि
 
-Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+अंत में, आप यह सुनिश्चित करके लूप को बंद करना चाहेंगे कि आपके प्रोजेक्ट के अनुरक्षक प्राप्त योगदान की मात्रा को संभालने में सक्षम हैं। आखिरी सवाल जो आप खुद से पूछना चाहेंगे वह है: _क्या मैं (या हम) अपने समुदाय को जवाब दे रहे हैं?_
 
-Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+अनुत्तरदायी अनुरक्षक खुले स्रोत परियोजनाओं के लिए एक बाधा बन जाते हैं। यदि कोई योगदान जमा करता है लेकिन रखरखावकर्ता से कभी जवाब नहीं मिलता है, तो वे निराश महसूस कर सकते हैं और छोड़ सकते हैं।
 
-[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+[मोज़िला से अनुसंधान](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) सुझाव देता है कि बार-बार योगदान को प्रोत्साहित करने में अनुरक्षक प्रतिक्रिया एक महत्वपूर्ण कारक है।
 
-Consider [tracking how long it takes for you (or another maintainer) to respond to contributions](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+विचार करना [यह ट्रैक करना कि आपको (या किसी अन्य अनुरक्षक को) योगदान का जवाब देने में कितना समय लगता है](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), चाहे कोई समस्या हो या पुल अनुरोध। प्रतिक्रिया देने के लिए कार्रवाई की आवश्यकता नहीं है. यह कहने जितना सरल हो सकता है: _"आपके सबमिशन के लिए धन्यवाद! मैं अगले सप्ताह के भीतर इसकी समीक्षा करूंगा।"_
 
-You could also measure the time it takes to move between stages in the contribution process, such as:
+आप योगदान प्रक्रिया के चरणों के बीच लगने वाले समय को भी माप सकते हैं, जैसे:
 
-* Average time an issue remains open
-* Whether issues get closed by PRs
-* Whether stale issues get closed
-* Average time to merge a pull request
+* किसी अंक के खुले रहने का औसत समय
+* क्या मुद्दे पीआर द्वारा बंद कर दिए जाते हैं
+* क्या बासी मुद्दे बंद हो जाते हैं
+* पुल अनुरोध को मर्ज करने का औसत समय
 
-## Use 📊 to learn about people
+## लोगों के बारे में जानने के लिए 📊 का प्रयोग करें
 
-Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+मेट्रिक्स को समझने से आपको एक सक्रिय, बढ़ता हुआ ओपन सोर्स प्रोजेक्ट बनाने में मदद मिलेगी। भले ही आप डैशबोर्ड पर प्रत्येक मीट्रिक को ट्रैक नहीं करते हैं, फिर भी अपना ध्यान उस प्रकार के व्यवहार पर केंद्रित करने के लिए उपरोक्त ढांचे का उपयोग करें जो आपके प्रोजेक्ट को आगे बढ़ाने में मदद करेगा।
 
-[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health.
+[CHAOSS](https://chaoss.community/) एक स्वागतयोग्य, खुला स्रोत समुदाय है जो सामुदायिक स्वास्थ्य के लिए एनालिटिक्स, मेट्रिक्स और सॉफ्टवेयर पर केंद्रित है।
diff --git a/_data/locales/hi.yml b/_data/locales/hi.yml
index 84435d4d5fb..076cf4e9203 100644
--- a/_data/locales/hi.yml
+++ b/_data/locales/hi.yml
@@ -1,5 +1,5 @@
 hi:
-  locale_name: हिंदी
+  locale_name: Hindi
   nav:
     about: बारे में
     contribute: योगदान करें

From 6773bdf935c8ecbb3073b9a72522c231d02132b7 Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Fri, 1 Sep 2023 11:17:07 +0530
Subject: [PATCH 483/749] article update --hindi

---
 _articles/hi/starting-a-project.md | 269 ++++++++++++++---------------
 1 file changed, 134 insertions(+), 135 deletions(-)

diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md
index 15b01773ef7..671117cc326 100644
--- a/_articles/hi/starting-a-project.md
+++ b/_articles/hi/starting-a-project.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Starting an Open Source Project
-description: Learn more about the world of open source and get ready to launch your own project.
+lang: hi
+title: एक ओपन सोर्स प्रोजेक्ट शुरू करना
+description: ओपन सोर्स की दुनिया के बारे में और जानें और अपना खुद का प्रोजेक्ट लॉन्च करने के लिए तैयार हो जाएं।
 class: beginners
 order: 2
 image: /assets/images/cards/beginner.png
@@ -10,280 +10,279 @@ related:
   - building
 ---
 
-## The "what" and "why" of open source
+## खुले स्रोत का "क्या" और "क्यों"।
 
-So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+तो क्या आप ओपन सोर्स के साथ शुरुआत करने के बारे में सोच रहे हैं? बधाई हो! दुनिया आपके योगदान की सराहना करती है. आइए बात करें कि ओपन सोर्स क्या है और लोग ऐसा क्यों करते हैं।
 
-### What does "open source" mean?
+### "ओपन सोर्स" का क्या मतलब है?
 
-When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+जब कोई प्रोजेक्ट ओपन सोर्स होता है, तो इसका मतलब है कि **कोई भी किसी भी उद्देश्य के लिए आपके प्रोजेक्ट का उपयोग, अध्ययन, संशोधन और वितरण करने के लिए स्वतंत्र है।** ये अनुमतियाँ [एक ओपन सोर्स लाइसेंस](https://opensource.org/licenses)  के माध्यम से लागू की जाती हैं।
 
-Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+खुला स्रोत शक्तिशाली है क्योंकि यह अपनाने और सहयोग की बाधाओं को कम करता है, जिससे लोगों को परियोजनाओं को तेजी से फैलाने और सुधारने की अनुमति मिलती है। इसके अलावा, क्योंकि यह उपयोगकर्ताओं को बंद स्रोत के सापेक्ष, अपने स्वयं के कंप्यूटिंग को नियंत्रित करने की क्षमता देता है। उदाहरण के लिए, ओपन सोर्स सॉफ़्टवेयर का उपयोग करने वाले व्यवसाय के पास किसी बंद स्रोत विक्रेता के उत्पाद निर्णयों पर विशेष रूप से निर्भर रहने के बजाय सॉफ़्टवेयर में कस्टम सुधार करने के लिए किसी को नियुक्त करने का विकल्प होता है।
 
-_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+_मुफ़्त सॉफ़्टवेयर_ परियोजनाओं के उसी सेट को संदर्भित करता है जो _ओपन सोर्स_ है। कभी-कभी आप [इन शर्तों](https://en.wikipedia.org/wiki/Free_and_open-source_software) को "फ्री और ओपन सोर्स सॉफ्टवेयर" (FOSS) या "फ्री, लिब्रे और ओपन सोर्स सॉफ्टवेयर" के रूप में भी देखेंगे। (दाँत साफ करने का धागा)। _मुक्त_ और _मुक्ति_ का तात्पर्य स्वतंत्रता से है, [कीमत से नहीं](#does-open-source-mean-free-of-charge)।
 
-### Why do people open source their work?
+### लोग अपना काम ओपन सोर्स क्यों करते हैं?
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
-  One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+ ओपन सोर्स का उपयोग करने और सहयोग करने से मुझे जो सबसे फायदेमंद अनुभव मिलता है, वह उन रिश्तों से आता है जो मैं उन अन्य डेवलपर्स के साथ बनाता हूं जो मेरे जैसी ही कई समस्याओं का सामना कर रहे हैं।
   <p markdown="1" class="pquote-credit">
-— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+— @kentcdodds, ["ओपन सोर्स में आना मेरे लिए कितना अद्भुत रहा है"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
   </p>
 </aside>
 
-[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+[इसके कई कारण हैं](https://ben.balter.com/2015/11/23/why-open-source/) कोई व्यक्ति या संगठन किसी प्रोजेक्ट को ओपन सोर्स क्यों करना चाहेगा। कुछ उदाहरणों में शामिल हैं:
 
-* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+* **सहयोग:** ओपन सोर्स प्रोजेक्ट दुनिया में किसी से भी बदलाव स्वीकार कर सकते हैं। [व्यायाम](https://github.com/exercism/), उदाहरण के लिए, 350 से अधिक योगदानकर्ताओं वाला एक प्रोग्रामिंग अभ्यास मंच है।
 
-* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **अडॉप्टेशन और रीमिक्सिंग:** ओपन सोर्स प्रोजेक्ट्स का उपयोग कोई भी लगभग किसी भी उद्देश्य के लिए कर सकता है। लोग इसका उपयोग अन्य चीजें बनाने में भी कर सकते हैं। [WordPress](https://github.com/WordPress), उदाहरण के लिए, किसी मौजूदा प्रोजेक्ट के फोर्क के रूप में शुरू किया गया, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparency:** Anyone can inspect an open source project for errors or असंगतियाँ जैसी सरकारों के लिए पारदर्शिता मायने रखती है [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) या[United States](https://sourcecode.cio.gov/), बैंकिंग या स्वास्थ्य देखभाल जैसे विनियमित उद्योग और सुरक्षा सॉफ्टवेयर जैसे [Let's Encrypt](https://github.com/letsencrypt).
 
-Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+ओपन सोर्स सिर्फ सॉफ्टवेयर के लिए ही नहीं है। आप डेटा सेट से लेकर किताबों तक सब कुछ ओपन सोर्स कर सकते हैं। आप और क्या स्रोत खोल सकते हैं, इस बारे में विचारों के लिए [गिटहब एक्सप्लोर](https://github.com/explore) देखें।
 
-### Does open source mean "free of charge"?
+### क्या ओपन सोर्स का मतलब "निःशुल्क" है?
+ओपन सोर्स का सबसे बड़ा आकर्षण यह है कि इसमें पैसा खर्च नहीं होता है। हालाँकि, "निःशुल्क", खुले स्रोत के समग्र मूल्य का एक उपोत्पाद है।
 
-One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+क्योंकि [एक ओपन सोर्स लाइसेंस के लिए आवश्यक है](https://opensource.org/osd-annotated) कि कोई भी आपके प्रोजेक्ट को लगभग किसी भी उद्देश्य के लिए उपयोग, संशोधित और साझा कर सकता है, प्रोजेक्ट स्वयं निःशुल्क होते हैं। यदि प्रोजेक्ट के उपयोग में पैसे खर्च होते हैं, तो कोई भी कानूनी तौर पर इसकी प्रतिलिपि बना सकता है और इसके बजाय मुफ़्त संस्करण का उपयोग कर सकता है।
 
-Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+परिणामस्वरूप, अधिकांश ओपन सोर्स प्रोजेक्ट मुफ़्त हैं, लेकिन "निःशुल्क" ओपन सोर्स परिभाषा का हिस्सा नहीं है। ओपन सोर्स की आधिकारिक परिभाषा का अनुपालन करते हुए, दोहरे लाइसेंसिंग या सीमित सुविधाओं के माध्यम से अप्रत्यक्ष रूप से ओपन सोर्स परियोजनाओं के लिए शुल्क लेने के कई तरीके हैं।
 
-As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+## क्या मुझे अपना स्वयं का ओपन सोर्स प्रोजेक्ट लॉन्च करना चाहिए?
 
-## Should I launch my own open source project?
+संक्षिप्त उत्तर हां है, क्योंकि परिणाम चाहे जो भी हो, अपना खुद का प्रोजेक्ट लॉन्च करना यह सीखने का एक शानदार तरीका है कि ओपन सोर्स कैसे काम करता है।
 
-The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+यदि आपने पहले कभी कोई प्रोजेक्ट ओपन सोर्स नहीं किया है, तो आप इस बात से घबरा सकते हैं कि लोग क्या कहेंगे, या कोई नोटिस करेगा या नहीं। यदि यह आपके जैसा लगता है, तो आप अकेले नहीं हैं!
 
-If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+ओपन सोर्स कार्य किसी भी अन्य रचनात्मक गतिविधि की तरह है, चाहे वह लेखन हो या पेंटिंग। अपने काम को दुनिया के साथ साझा करना डरावना लग सकता है, लेकिन बेहतर होने का एकमात्र तरीका अभ्यास करना है - भले ही आपके पास दर्शक न हों।
 
-Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+यदि आप अभी तक आश्वस्त नहीं हैं, तो एक क्षण रुककर सोचें कि आपके लक्ष्य क्या हो सकते हैं।
 
-If you're not yet convinced, take a moment to think about what your goals might be.
+### अपने लक्ष्य निर्धारित करना
 
-### Setting your goals
+लक्ष्य आपको यह पता लगाने में मदद कर सकते हैं कि किस पर काम करना है, किस चीज़ को ना कहना है और आपको कहाँ दूसरों से मदद की ज़रूरत है। अपने आप से यह पूछकर शुरुआत करें, _मैं इस प्रोजेक्ट का ओपन सोर्सिंग क्यों कर रहा हूँ?_
 
-Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself,  _why am I open sourcing this project?_
+इस प्रश्न का कोई भी सही उत्तर नहीं है। आपके पास एक ही प्रोजेक्ट के लिए कई लक्ष्य हो सकते हैं, या अलग-अलग लक्ष्यों वाली अलग-अलग परियोजनाएँ हो सकती हैं।
 
-There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
-
-If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+यदि आपका एकमात्र लक्ष्य अपना काम दिखाना है, तो हो सकता है कि आप योगदान भी न चाहें, और अपने README में ऐसा कहें भी नहीं। दूसरी ओर, यदि आप योगदानकर्ता चाहते हैं, तो आप स्पष्ट दस्तावेज़ीकरण और नए लोगों का स्वागत महसूस कराने में समय लगाएंगे।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
-  At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+  किसी बिंदु पर मैंने एक कस्टम UIAlertView बनाया जिसका मैं उपयोग कर रहा था...और मैंने इसे खुला स्रोत बनाने का निर्णय लिया। इसलिए मैंने इसे अधिक गतिशील बनाने के लिए संशोधित किया और GitHub पर अपलोड किया। मैंने अपना पहला दस्तावेज़ अन्य डेवलपर्स को यह समझाते हुए लिखा कि इसे अपनी परियोजनाओं पर कैसे उपयोग किया जाए। संभवतः किसी ने कभी इसका उपयोग नहीं किया क्योंकि यह एक साधारण परियोजना थी लेकिन मैं अपने योगदान के बारे में अच्छा महसूस कर रहा था।
   <p markdown="1" class="pquote-credit">
-— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+— @mavris, ["स्व-सिखाया गया सॉफ़्टवेयर डेवलपर्स: ओपन सोर्स हमारे लिए क्यों महत्वपूर्ण है"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
   </p>
 </aside>
 
-As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+जैसे-जैसे आपका प्रोजेक्ट बढ़ता है, आपके समुदाय को आपसे कोड के अलावा और भी बहुत कुछ की आवश्यकता हो सकती है। मुद्दों पर प्रतिक्रिया देना, कोड की समीक्षा करना और अपने प्रोजेक्ट का प्रचार-प्रसार करना एक ओपन सोर्स प्रोजेक्ट में सभी महत्वपूर्ण कार्य हैं।
 
-While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+जबकि आप गैर-कोडिंग कार्यों पर कितना समय बिताएंगे, यह आपके प्रोजेक्ट के आकार और दायरे पर निर्भर करेगा, आपको उन्हें स्वयं संबोधित करने या आपकी सहायता के लिए किसी को ढूंढने के लिए एक अनुरक्षक के रूप में तैयार रहना चाहिए।
 
-**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+**यदि आप किसी प्रोजेक्ट की ओपन सोर्सिंग करने वाली कंपनी का हिस्सा हैं,**सुनिश्चित करें कि आपके प्रोजेक्ट के पास आंतरिक संसाधन हैं जो उसे आगे बढ़ाने के लिए आवश्यक हैं। आप यह पहचानना चाहेंगे कि लॉन्च के बाद प्रोजेक्ट को बनाए रखने के लिए कौन ज़िम्मेदार है, और आप उन कार्यों को अपने समुदाय के साथ कैसे साझा करेंगे।
 
-If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+यदि आपको परियोजना के प्रचार, संचालन और रखरखाव के लिए समर्पित बजट या स्टाफिंग की आवश्यकता है, तो बातचीत जल्दी शुरू करें।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-  As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+ जैसे ही आप प्रोजेक्ट को ओपन सोर्स करना शुरू करते हैं, यह सुनिश्चित करना महत्वपूर्ण है कि आपकी प्रबंधन प्रक्रियाएं आपके प्रोजेक्ट के आसपास के समुदाय के योगदान और क्षमताओं को ध्यान में रखती हैं। परियोजना के प्रमुख पहलुओं में उन योगदानकर्ताओं को शामिल करने से न डरें जो आपके व्यवसाय में कार्यरत नहीं हैं - खासकर यदि वे लगातार योगदानकर्ता हैं।
   <p markdown="1" class="pquote-credit">
-— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+— @captainsafia, ["तो आप एक प्रोजेक्ट को ओपन सोर्स करना चाहते हैं, है ना?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
   </p>
 </aside>
 
-### Contributing to other projects
+### अन्य परियोजनाओं में योगदान देना
 
-If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+यदि आपका लक्ष्य यह सीखना है कि दूसरों के साथ कैसे सहयोग करें या यह समझें कि ओपन सोर्स कैसे काम करता है, तो किसी मौजूदा प्रोजेक्ट में योगदान देने पर विचार करें। उस प्रोजेक्ट से शुरुआत करें जिसे आप पहले से ही उपयोग करते हैं और पसंद करते हैं। किसी प्रोजेक्ट में योगदान देना टाइप की त्रुटियों को ठीक करने या दस्तावेज़ीकरण को अपडेट करने जितना आसान हो सकता है।
 
-If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+यदि आप निश्चित नहीं हैं कि योगदानकर्ता के रूप में शुरुआत कैसे करें, तो हमारी जाँच करें [ओपन सोर्स गाइड में योगदान कैसे करें](../how-to-contribute/).
 
-## Launching your own open source project
+## अपना स्वयं का ओपन सोर्स प्रोजेक्ट लॉन्च करना
 
-There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+अपने काम का स्रोत खोलने का कोई सही समय नहीं है। आप किसी विचार का स्रोत खोल सकते हैं, कोई कार्य प्रगति पर है, या वर्षों तक बंद स्रोत रहने के बाद।
 
-Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+आम तौर पर कहें तो, आपको अपने प्रोजेक्ट को तब ओपन सोर्स करना चाहिए जब आप दूसरों को अपने काम को देखने और उस पर फीडबैक देने में सहज महसूस करें।
 
-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/)
 * [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.
+एक अनुरक्षक के रूप में, ये घटक आपको अपेक्षाओं को संप्रेषित करने, योगदान प्रबंधित करने और सभी के कानूनी अधिकारों (आपके अपने अधिकारों सहित) की रक्षा करने में मदद करेंगे। वे आपके सकारात्मक अनुभव प्राप्त करने की संभावनाओं को उल्लेखनीय रूप से बढ़ा देते हैं।
 
-If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+यदि आपका प्रोजेक्ट GitHub पर है, तो इन फ़ाइलों को अनुशंसित फ़ाइल नामों के साथ अपनी रूट निर्देशिका में डालने से GitHub को उन्हें पहचानने और स्वचालित रूप से आपके पाठकों के सामने लाने में मदद मिलेगी।
 
-### Choosing a license
+### लाइसेंस चुनना
 
-An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+एक ओपन सोर्स लाइसेंस यह गारंटी देता है कि अन्य लोग बिना किसी प्रभाव के आपके प्रोजेक्ट का उपयोग, प्रतिलिपि, संशोधन और योगदान कर सकते हैं। यह आपको जटिल कानूनी स्थितियों से भी बचाता है। **ओपन सोर्स प्रोजेक्ट लॉन्च करते समय आपको एक लाइसेंस शामिल करना होगा।**
 
-Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+क़ानूनी काम कोई मज़ेदार नहीं है. अच्छी खबर यह है कि आप मौजूदा लाइसेंस को कॉपी करके अपने रिपॉजिटरी में पेस्ट कर सकते हैं। आपकी मेहनत की रक्षा करने में केवल एक मिनट लगेगा।
 
-[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 the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), और [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) सबसे लोकप्रिय ओपन सोर्स लाइसेंस हैं, लेकिन [अन्य विकल्प भी हैं](https://choosealicense.com).
 
-When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+जब आप GitHub पर एक नया प्रोजेक्ट बनाते हैं, तो आपको लाइसेंस चुनने का विकल्प दिया जाता है। ओपन सोर्स लाइसेंस शामिल करने से आपका GitHub प्रोजेक्ट ओपन सोर्स बन जाएगा।
 
-![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+![एक लाइसेंस चुनें](/assets/images/starting-a-project/repository-license-picker.png)
 
-If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+यदि आपके पास ओपन सोर्स प्रोजेक्ट के प्रबंधन के कानूनी पहलुओं के बारे में अन्य प्रश्न या चिंताएं हैं, [हमने आपका ध्यान रखा है](../legal/).
 
-### Writing a README
+### एक README लिखना
 
-READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+READMEs आपके प्रोजेक्ट का उपयोग कैसे करें यह समझाने के अलावा और भी बहुत कुछ करते हैं। वे यह भी बताते हैं कि आपका प्रोजेक्ट क्यों मायने रखता है, और आपके उपयोगकर्ता इसके साथ क्या कर सकते हैं।
 
-In your README, try to answer the following questions:
+अपने README में निम्नलिखित प्रश्नों के उत्तर देने का प्रयास करें:
 
-* What does this project do?
-* Why is this project useful?
-* How do I get started?
-* Where can I get more help, if I need it?
+* यह प्रोजेक्ट क्या करता है?
+* यह प्रोजेक्ट उपयोगी क्यों है?
+* मैं कैसे शुरू करूँ?
+* यदि मुझे आवश्यकता हो तो मुझे और सहायता कहां से मिल सकती है?
 
-You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+आप अपने README का उपयोग अन्य प्रश्नों के उत्तर देने के लिए कर सकते हैं, जैसे कि आप योगदान कैसे संभालते हैं, परियोजना के लक्ष्य क्या हैं, और लाइसेंस और एट्रिब्यूशन के बारे में जानकारी। यदि आप योगदान स्वीकार नहीं करना चाहते हैं, या आपका प्रोजेक्ट अभी तक उत्पादन के लिए तैयार नहीं है, तो इस जानकारी को लिख लें।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
-  Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+  बेहतर दस्तावेज़ीकरण का अर्थ है अधिक उपयोगकर्ता, कम समर्थन अनुरोध और अधिक योगदानकर्ता। (...) याद रखें कि आपके पाठक आप नहीं हैं। ऐसे लोग भी हो सकते हैं जो किसी प्रोजेक्ट में आ सकते हैं जिनके पास पूरी तरह से अलग अनुभव हों।
   <p markdown="1" class="pquote-credit">
-— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+— @tracymakes, ["लिखें ताकि आपके शब्द पढ़े जा सकें (वीडियो)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
   </p>
 </aside>
 
-Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+कभी-कभी, लोग README लिखने से बचते हैं क्योंकि उन्हें लगता है कि परियोजना अधूरी है, या वे योगदान नहीं चाहते हैं। इसे लिखने के ये सभी बहुत अच्छे कारण हैं।
 
-For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+अधिक प्रेरणा के लिए, @dguo's का ["एक README बनाएं" मार्गदर्शिका](https://www.makeareadme.com/) उपयोग करने का प्रयास करें या @PurpleBooth's [README टेम्पलेट](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) संपूर्ण README लिखने के लिए।
 
-When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+जब आप रूट डायरेक्टरी में एक README फ़ाइल शामिल करते हैं, तो GitHub स्वचालित रूप से इसे रिपॉजिटरी होमपेज पर प्रदर्शित करेगा।
 
-### Writing your contributing guidelines
+### अपने योगदान संबंधी दिशानिर्देश लिखना
 
-A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+एक योगदान फ़ाइल आपके दर्शकों को बताती है कि आपके प्रोजेक्ट में कैसे भाग लेना है। उदाहरण के लिए, आप निम्न पर जानकारी शामिल कर सकते हैं:
 
-* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
-* How to suggest a new feature
-* How to set up your environment and run tests
+* बग रिपोर्ट कैसे दर्ज करें ([इश्यू और पुल रिक्वेस्ट टेम्प्लेट्स का उपयोग](https://github.com/blog/2111-issue-and-pull-request-templates)) करने का प्रयास करें।
+* नई सुविधा का सुझाव कैसे दें
+* अपना वातावरण कैसे स्थापित करें और परीक्षण कैसे चलाएं
 
-In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+तकनीकी विवरण के अलावा, योगदान फ़ाइल योगदान के लिए आपकी अपेक्षाओं को संप्रेषित करने का एक अवसर है, जैसे:
 
-* The types of contributions you're looking for
-* Your roadmap or vision for the project
-* How contributors should (or should not) get in touch with you
+* आप जिस प्रकार के योगदान की तलाश कर रहे हैं
+* परियोजना के लिए आपका रोडमैप या विज़न
+* योगदानकर्ताओं को आपसे कैसे संपर्क करना चाहिए (या नहीं करना चाहिए)।
 
-Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+गर्मजोशीपूर्ण, मैत्रीपूर्ण लहजे का उपयोग करना और योगदान के लिए विशिष्ट सुझाव देना (जैसे दस्तावेज़ लिखना, या वेबसाइट बनाना) नवागंतुकों को भाग लेने के लिए स्वागत और उत्साहित महसूस कराने में काफी मदद कर सकता है।
 
-For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+उदाहरण के लिए, [सक्रिय व्यवस्थापक](https://github.com/activeadmin/activeadmin/) प्रारंभ होता है [इसकी योगदान मार्गदर्शिका](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) के साथ:
 
-> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+>सबसे पहले, सक्रिय व्यवस्थापक में योगदान देने पर विचार करने के लिए धन्यवाद। यह आप जैसे लोग ही हैं जो एक्टिव एडमिन को इतना बढ़िया टूल बनाते हैं।
 
-In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+आपके प्रोजेक्ट के शुरुआती चरणों में, आपकी CONTRIBUTING फ़ाइल सरल हो सकती है। योगदान देने के लिए आपको हमेशा यह समझाना चाहिए कि बग या फ़ाइल समस्याओं की रिपोर्ट कैसे करें, और कोई तकनीकी आवश्यकताएं (जैसे परीक्षण) कैसे करें।
 
-Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+समय के साथ, आप अपनी योगदान फ़ाइल में अन्य अक्सर पूछे जाने वाले प्रश्न जोड़ सकते हैं। इस जानकारी को लिखने का मतलब है कि कम लोग आपसे वही प्रश्न बार-बार पूछेंगे।
 
-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/).
+अपनी 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/).
 
-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.
+अपनी CONTRIBUTING फ़ाइल को अपने README से लिंक करें, ताकि अधिक लोग इसे देख सकें। यदि आप [CONTRIBUTING फ़ाइल को अपने प्रोजेक्ट के भंडार में रखते हैं](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), जब कोई योगदानकर्ता कोई समस्या उत्पन्न करता है या पुल अनुरोध खोलता है तो GitHub स्वचालित रूप से आपकी फ़ाइल से लिंक हो जाएगा।
 
-![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+![योगदान दिशानिर्देश](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
-### Establishing a code of conduct
+### आचार संहिता की स्थापना
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
-  We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+ हम सभी के पास ऐसे अनुभव हैं जहां हमें संभवतः दुरुपयोग का सामना करना पड़ा है या तो एक अनुरक्षक के रूप में यह समझाने की कोशिश कर रहा है कि कुछ को एक निश्चित तरीके से क्यों होना चाहिए, या एक उपयोगकर्ता के रूप में... एक साधारण प्रश्न पूछना। (...) आचार संहिता एक आसानी से संदर्भित और लिंक करने योग्य दस्तावेज़ बन जाती है जो इंगित करती है कि आपकी टीम रचनात्मक चर्चा को बहुत गंभीरता से लेती है।
   <p markdown="1" class="pquote-credit">
-— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+— @mlynch, ["ओपन सोर्स को एक खुशहाल जगह बनाना"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
   </p>
 </aside>
 
-Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+अंत में, एक आचार संहिता आपके प्रोजेक्ट के प्रतिभागियों के लिए व्यवहार के लिए बुनियादी नियम निर्धारित करने में मदद करती है। यह विशेष रूप से मूल्यवान है यदि आप किसी समुदाय या कंपनी के लिए एक ओपन सोर्स प्रोजेक्ट लॉन्च कर रहे हैं। आचार संहिता आपको स्वस्थ, रचनात्मक सामुदायिक व्यवहार की सुविधा प्रदान करने का अधिकार देती है, जो एक अनुरक्षक के रूप में आपके तनाव को कम करेगा।
 
-For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+अधिक जानकारी के लिए, हमारी जाँच करें [आचार संहिता मार्गदर्शिका](../code-of-conduct/).
 
-In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+यह बताने के अलावा कि आप प्रतिभागियों से कैसे व्यवहार करने की अपेक्षा करते हैं, आचार संहिता यह भी बताती है कि ये अपेक्षाएं किस पर लागू होती हैं, कब लागू होती हैं और उल्लंघन होने पर क्या करना चाहिए।
 
-Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+ओपन सोर्स लाइसेंस की तरह, आचार संहिता के लिए भी उभरते मानक हैं, इसलिए आपको अपना खुद का लिखने की ज़रूरत नहीं है। [योगदानकर्ता वाचा](https://contributor-covenant.org/) एक ड्रॉप-इन आचार संहिता है जिसका उपयोग [40,000 से अधिक ओपन सोर्स प्रोजेक्ट्स](https://www.contributor-covenant.org/adopters) द्वारा किया जाता है। कुबेरनेट्स, रेल्स और स्विफ्ट सहित। इससे कोई फर्क नहीं पड़ता कि आप किस पाठ का उपयोग करते हैं, आपको आवश्यकता पड़ने पर अपनी आचार संहिता लागू करने के लिए तैयार रहना चाहिए।
 
-Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+टेक्स्ट को सीधे अपने रिपॉजिटरी में एक Code_OF_CONDUCT फ़ाइल में पेस्ट करें। फ़ाइल को अपने प्रोजेक्ट की रूट डायरेक्टरी में रखें ताकि इसे ढूंढना आसान हो, और इसे अपने README से लिंक करें।
 
-## Naming and branding your project
+## अपने प्रोजेक्ट का नामकरण और ब्रांडिंग करना
 
-Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+ब्रांडिंग एक आकर्षक लोगो या आकर्षक प्रोजेक्ट नाम से कहीं अधिक है। यह इस बारे में है कि आप अपने प्रोजेक्ट के बारे में कैसे बात करते हैं, और आप अपना संदेश किस तक पहुंचाते हैं।
 
-### Choosing the right name
+### सही नाम चुनना
 
-Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+ऐसा नाम चुनें जो याद रखने में आसान हो और, आदर्श रूप से, प्रोजेक्ट क्या करता है, इसका कुछ अंदाज़ा देता हो। उदाहरण के लिए:
 
-* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
-* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+* [Sentry](https://github.com/getsentry/sentry) क्रैश रिपोर्टिंग के लिए ऐप्स पर नज़र रखता है
+* [Thin](https://github.com/macournoyer/thin) एक तेज़ और सरल रूबी वेब सर्वर है
 
-If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+यदि आप किसी मौजूदा प्रोजेक्ट पर निर्माण कर रहे हैं, तो उपसर्ग के रूप में उनके नाम का उपयोग करने से यह स्पष्ट करने में मदद मिल सकती है कि आपका प्रोजेक्ट क्या करता है (उदाहरण के लिए, [node-fetch](https://github.com/bitinn/node-fetch) window.fetch` को Node.js पर लाता है)।
 
-Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+स्पष्टता को सर्वोपरि मानें। चुटकुले मजेदार हैं, लेकिन याद रखें कि कुछ चुटकुले अन्य संस्कृतियों या आपसे अलग अनुभव वाले लोगों पर लागू नहीं हो सकते हैं। आपके कुछ संभावित उपयोगकर्ता कंपनी के कर्मचारी हो सकते हैं: जब उन्हें कार्यस्थल पर आपके प्रोजेक्ट के बारे में बताना हो तो आप उन्हें असहज नहीं करना चाहेंगे!
 
-### Avoiding name conflicts
+### नाम के झगड़ों से बचना
 
-[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+[समान नाम वाले ओपन सोर्स प्रोजेक्ट की जांच करें](http://ivantomic.com/projects/ospnc/), खासकर यदि आप एक ही भाषा या पारिस्थितिकी तंत्र साझा करते हैं। यदि आपका नाम किसी लोकप्रिय मौजूदा प्रोजेक्ट से मेल खाता है, तो आप अपने दर्शकों को भ्रमित कर सकते हैं।
 
-If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+यदि आप अपने प्रोजेक्ट का प्रतिनिधित्व करने के लिए एक वेबसाइट, ट्विटर हैंडल या अन्य संपत्तियां चाहते हैं, तो सुनिश्चित करें कि आपको अपने इच्छित नाम मिल सकें। आदर्श रूप से, मन की शांति के लिए [अभी उन नामों को आरक्षित करें](https://instantdomainsearch.com/), भले ही आप अभी उनका उपयोग करने का इरादा नहीं रखते हों।
 
-Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+सुनिश्चित करें कि आपके प्रोजेक्ट का नाम किसी भी ट्रेडमार्क का उल्लंघन नहीं करता है। कोई कंपनी बाद में आपसे अपना प्रोजेक्ट वापस लेने के लिए कह सकती है, या आपके खिलाफ कानूनी कार्रवाई भी कर सकती है। यह जोखिम के लायक ही नहीं है।
 
-You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+आप ट्रेडमार्क विवादों के लिए [WIPO ग्लोबल ब्रांड डेटाबेस](http://www.wipo.int/branddb/en/) की जांच कर सकते हैं। यदि आप किसी कंपनी में हैं, तो यह उन चीजों में से एक है जिसमें आपकी [कानूनी टीम आपकी मदद कर सकती है।](../legal/)
 
-Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+अंत में, अपने प्रोजेक्ट के नाम के लिए त्वरित Google खोज करें। क्या लोग आपका प्रोजेक्ट आसानी से ढूंढ पाएंगे? क्या खोज परिणामों में कुछ और दिखाई देता है जो आप नहीं चाहेंगे कि वे देखें?
 
-### How you write (and code) affects your brand, too!
+### आप कैसे लिखते हैं (और कोड) आपके ब्रांड को भी प्रभावित करता है!
 
-Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+अपने प्रोजेक्ट के पूरे जीवनकाल में, आप बहुत सारा लेखन करेंगे: रीडमी, ट्यूटोरियल, सामुदायिक दस्तावेज़, मुद्दों पर प्रतिक्रिया देना, शायद न्यूज़लेटर और मेलिंग सूचियाँ भी।
 
-Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+चाहे वह आधिकारिक दस्तावेज हो या कोई आकस्मिक ईमेल, आपकी लेखन शैली आपके प्रोजेक्ट के ब्रांड का हिस्सा है। इस बात पर विचार करें कि आप अपने दर्शकों के सामने कैसे आ सकते हैं और क्या आप यही लहजा बताना चाहते हैं।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+  मैंने मेलिंग सूची के हर सूत्र में शामिल होने और अनुकरणीय व्यवहार दिखाने, लोगों के साथ अच्छा व्यवहार करने, उनके मुद्दों को गंभीरता से लेने और समग्र रूप से मददगार बनने की कोशिश की। थोड़ी देर के बाद, लोग न केवल प्रश्न पूछने के लिए, बल्कि उत्तर देने में भी मदद करने के लिए इधर-उधर रुके और मुझे पूरी खुशी हुई, उन्होंने मेरी शैली की नकल की।
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl [CouchDB](https://github.com/apache/couchdb), ["सतत खुला स्रोत"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html) पर।
   </p>
 </aside>
 
-Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+गर्मजोशीपूर्ण, समावेशी भाषा (जैसे कि "उन्हें", यहां तक ​​कि जब एक व्यक्ति का जिक्र हो) का उपयोग करना आपके प्रोजेक्ट को नए योगदानकर्ताओं का स्वागत करने में काफी मदद कर सकता है। सरल भाषा पर कायम रहें, क्योंकि हो सकता है कि आपके कई पाठक मूल अंग्रेजी बोलने वाले न हों।
 
-Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+शब्दों को लिखने के तरीके के अलावा, आपकी कोडिंग शैली भी आपके प्रोजेक्ट के ब्रांड का हिस्सा बन सकती है। [Angular](https://angular.io/guide/styleguide) और [jQuery](https://contribute.jquery.org/style-guide/js/) कठोर कोडिंग शैलियों और दिशानिर्देशों वाली परियोजनाओं के दो उदाहरण हैं।
 
-It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+जब आप अभी शुरुआत कर रहे हों तो अपने प्रोजेक्ट के लिए स्टाइल गाइड लिखना आवश्यक नहीं है, और आप पाएंगे कि आप वैसे भी अपने प्रोजेक्ट में विभिन्न कोडिंग शैलियों को शामिल करने का आनंद लेते हैं। लेकिन आपको यह अनुमान लगाना चाहिए कि आपकी लेखन और कोडिंग शैली विभिन्न प्रकार के लोगों को कैसे आकर्षित या हतोत्साहित कर सकती है। आपके प्रोजेक्ट के शुरुआती चरण आपके लिए वह मिसाल कायम करने का अवसर हैं जो आप देखना चाहते हैं।
 
-## 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.
+क्या आप अपना प्रोजेक्ट ओपन सोर्स करने के लिए तैयार हैं? मदद के लिए यहां एक चेकलिस्ट दी गई है। सभी बक्सों की जाँच करें? आप जाने के लिए तैयार हैं! ["प्रकाशित करें" पर क्लिक करें](https://help.github.com/articles/making-a-private-repository-public/) और अपनी पीठ थपथपाएं।
 
-**Documentation**
+**दस्तावेज़ीकरण**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-    Project has a LICENSE file with an open source license
+    प्रोजेक्ट में ओपन सोर्स लाइसेंस के साथ LICENSE फ़ाइल है।
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+    प्रोजेक्ट में बुनियादी दस्तावेज़ हैं (README, CONTRIBUTING, Code_OF_CONDUCT)।
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+    नाम याद रखना आसान है, प्रोजेक्ट क्या करता है इसका कुछ अंदाजा देता है, और किसी मौजूदा प्रोजेक्ट के साथ टकराव नहीं करता है या ट्रेडमार्क का उल्लंघन नहीं करता है।
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-    The issue queue is up-to-date, with issues clearly organized and labeled
+    समस्या कतार अद्यतन है, जिसमें मुद्दे स्पष्ट रूप से व्यवस्थित और लेबल किए गए हैं।
   </label>
 </div>
 
@@ -292,65 +291,65 @@ Ready to open source your project? Here's a checklist to help. Check all the box
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    Project uses consistent code conventions and clear function/method/variable names
+    प्रोजेक्ट सुसंगत कोड सम्मेलनों और स्पष्ट फ़ंक्शन/विधि/चर नामों का उपयोग करता है।
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    The code is clearly commented, documenting intentions and edge cases
+    इरादों और किनारे के मामलों का दस्तावेजीकरण करते हुए कोड पर स्पष्ट रूप से टिप्पणी की गई है।
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+    पुनरीक्षण इतिहास, मुद्दों या पुल अनुरोधों में कोई संवेदनशील सामग्री नहीं है (उदाहरण के लिए, पासवर्ड या अन्य गैर-सार्वजनिक जानकारी)।
   </label>
 </div>
 
-**People**
+**लोग**
 
-If you're an individual:
+यदि आप एक व्यक्ति हैं:
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  आपने कानूनी विभाग से बात की है और/या अपनी कंपनी की आईपी और ओपन सोर्स नीतियों को समझा है (यदि आप कहीं कर्मचारी हैं)।
   </label>
 </div>
 
-If you're a company or organization:
+यदि आप एक कंपनी या संगठन हैं:
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    You've talked to your legal department
+    आपने अपने कानूनी विभाग से बात की है।
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    You have a marketing plan for announcing and promoting the project
+    आपके पास परियोजना की घोषणा और प्रचार के लिए एक मार्केटिंग योजना है।
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+    कोई व्यक्ति सामुदायिक अंतःक्रियाओं के प्रबंधन के लिए प्रतिबद्ध है (issues का जवाब देना, reviewing और merging pull requests)
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    At least two people have administrative access to the project
+    कम से कम दो लोगों के पास परियोजना तक प्रशासनिक पहुंच है।
   </label>
 </div>
 
-## You did it!
+## तुमने यह किया!
 
-Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.
+आपके पहले प्रोजेक्ट की ओपन सोर्सिंग के लिए बधाई। परिणाम चाहे जो भी हो, सार्वजनिक रूप से काम करना समुदाय के लिए एक उपहार है। प्रत्येक प्रतिबद्धता, टिप्पणी और अनुरोध के साथ, आप अपने लिए और दूसरों के लिए सीखने और बढ़ने के अवसर पैदा कर रहे हैं।

From 9c0f9903fdfb783ccf876f824e717e64d39d6e7a Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Fri, 1 Sep 2023 14:15:30 +0530
Subject: [PATCH 484/749] hindi articles update

---
 _articles/hi/how-to-contribute.md | 431 +++++++++++++++---------------
 1 file changed, 214 insertions(+), 217 deletions(-)

diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md
index 17a04ad9821..72795bed162 100644
--- a/_articles/hi/how-to-contribute.md
+++ b/_articles/hi/how-to-contribute.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: How to Contribute to Open Source
-description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans.
+lang: hi
+title: ओपन सोर्स में कैसे योगदान करें
+description: क्या आप ओपन सोर्स में योगदान देना चाहते हैं? पहली बार और अनुभवी लोगों के लिए ओपन सोर्स योगदान करने के लिए एक मार्गदर्शिका।
 class: contribute
 order: 1
 image: /assets/images/cards/contribute.png
@@ -14,198 +14,195 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
-  Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+  \[Freenode\] पर काम करने से मुझे कई कौशल अर्जित करने में मदद मिली जिनका उपयोग मैंने बाद में विश्वविद्यालय में अपनी पढ़ाई और अपनी वास्तविक नौकरी के लिए किया। मुझे लगता है कि ओपन सोर्स प्रोजेक्ट्स पर काम करने से मुझे उतना ही फायदा होता है जितना प्रोजेक्ट को मदद मिलती है!
   <p markdown="1" class="pquote-credit">
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["मुझे ओपन सोर्स सॉफ़्टवेयर में योगदान देना क्यों पसंद है?"](https://www.errietta.me/blog/open-source/)
   </p>
 </aside>
 
-Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+ओपन सोर्स में योगदान करना किसी भी ऐसे कौशल में सीखने, सिखाने और अनुभव बनाने का एक फायदेमंद तरीका हो सकता है जिसकी आप कल्पना कर सकते हैं।
 
-Why do people contribute to open source? Plenty of reasons!
+लोग ओपन सोर्स में योगदान क्यों देते हैं? बहुत सारे कारण!
 
-### Improve software you rely on
+### जिस सॉफ़्टवेयर पर आप भरोसा करते हैं उसे सुधारें
 
-Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+बहुत से ओपन सोर्स योगदानकर्ता उस सॉफ़्टवेयर के उपयोगकर्ता बनकर शुरुआत करते हैं जिसमें वे योगदान करते हैं। जब आप अपने द्वारा उपयोग किए जाने वाले ओपन सोर्स सॉफ़्टवेयर में कोई बग पाते हैं, तो आप यह देखने के लिए स्रोत को देखना चाहेंगे कि क्या आप इसे स्वयं ठीक कर सकते हैं। यदि ऐसा मामला है, तो पैच बैक में योगदान करना यह सुनिश्चित करने का सबसे अच्छा तरीका है कि आपके मित्र (और जब आप अगली रिलीज़ के लिए अपडेट करते हैं तो आप स्वयं) इससे लाभ उठा सकेंगे।
 
-### Improve existing skills
+### मौजूदा कौशल में सुधार करें
 
-Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+चाहे वह कोडिंग हो, यूजर इंटरफ़ेस डिज़ाइन हो, ग्राफ़िक डिज़ाइन हो, लेखन हो, या आयोजन हो, यदि आप अभ्यास की तलाश में हैं, तो ओपन सोर्स प्रोजेक्ट पर आपके लिए एक कार्य है।
 
-### Meet people who are interested in similar things
+### ऐसे लोगों से मिलें जो समान चीज़ों में रुचि रखते हैं
 
-Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+गर्मजोशी से स्वागत करने वाले समुदायों के साथ ओपन सोर्स परियोजनाएं लोगों को वर्षों तक वापस लाती हैं। बहुत से लोग खुले स्रोत में अपनी भागीदारी के माध्यम से आजीवन मित्रता बनाते हैं, चाहे वह सम्मेलनों में एक-दूसरे से मिलना हो या बरिटो के बारे में देर रात तक ऑनलाइन चैट करना हो।
 
-### Find mentors and teach others
+### मार्गदर्शक खोजें और दूसरों को सिखाएं
 
-Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+किसी साझा प्रोजेक्ट पर दूसरों के साथ काम करने का मतलब है कि आपको यह बताना होगा कि आप काम कैसे करते हैं, साथ ही अन्य लोगों से मदद भी मांगनी होगी। सीखने और सिखाने के कार्य इसमें शामिल सभी लोगों के लिए एक संतुष्टिदायक गतिविधि हो सकते हैं।
 
-### Build public artifacts that help you grow a reputation (and a career)
+### सार्वजनिक कलाकृतियों का निर्माण करें जो आपको प्रतिष्ठा (और करियर) बढ़ाने में मदद करें
 
-By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+परिभाषा के अनुसार, आपके सभी ओपन सोर्स कार्य सार्वजनिक हैं, जिसका अर्थ है कि आप जो भी कर सकते हैं उसे प्रदर्शित करने के लिए आपको कहीं भी ले जाने के लिए निःशुल्क उदाहरण मिलते हैं।
 
-### Learn people skills
+### लोगों के कौशल सीखें
 
-Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+ओपन सोर्स नेतृत्व और प्रबंधन कौशल का अभ्यास करने के अवसर प्रदान करता है, जैसे संघर्षों को हल करना, लोगों की टीमों को संगठित करना और काम को प्राथमिकता देना।
 
-### It's empowering to be able to make changes, even small ones
+### परिवर्तन करने में सक्षम होना सशक्त है, यहां तक कि छोटे परिवर्तन भी
 
-You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+ओपन सोर्स में भाग लेने का आनंद लेने के लिए आपको आजीवन योगदानकर्ता बनने की आवश्यकता नहीं है। क्या आपने कभी किसी वेबसाइट पर कोई टाइपो त्रुटि देखी है और सोचा है कि कोई इसे ठीक कर देगा? किसी ओपन सोर्स प्रोजेक्ट पर, आप बस यही कर सकते हैं। ओपन सोर्स लोगों को उनके जीवन और वे दुनिया का अनुभव कैसे करते हैं, इस पर एजेंसी महसूस करने में मदद करता है, और यह अपने आप में संतुष्टिदायक है।
 
-## What it means to contribute
+## योगदान देने का क्या मतलब है
 
-If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+यदि आप एक नए ओपन सोर्स योगदानकर्ता हैं, तो प्रक्रिया डराने वाली हो सकती है। आपको सही प्रोजेक्ट कैसे मिलता है? यदि आप नहीं जानते कि कोडिंग कैसे की जाती है तो क्या होगा? क्या हो यदि कुछ गलत हो जाए?
 
-Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+कोइ चिंता नहीं! किसी ओपन सोर्स प्रोजेक्ट में शामिल होने के सभी प्रकार के तरीके हैं, और कुछ युक्तियाँ आपको अपने अनुभव से अधिकतम लाभ उठाने में मदद करेंगी।
 
-### You don't have to contribute code
+### आपको कोड योगदान करने की आवश्यकता नहीं है
 
-A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+ओपन सोर्स में योगदान देने के बारे में एक आम ग़लतफ़हमी यह है कि आपको कोड का योगदान करने की आवश्यकता है। वास्तव में, यह अक्सर किसी परियोजना के अन्य भाग होते हैं जिन्हें [सबसे अधिक उपेक्षित या अनदेखा](https://github.com/blog/2195-the-shape-of-open-source) किया जाता है। आप इस प्रकार के योगदान की पेशकश करके परियोजना पर बहुत बड़ा उपकार करेंगे!
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
-  I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+  मैं कोकोपोड्स पर अपने काम के लिए प्रसिद्ध रहा हूं, लेकिन ज्यादातर लोग नहीं जानते कि मैं वास्तव में कोकोपोड्स टूल पर कोई वास्तविक काम नहीं करता हूं। प्रोजेक्ट पर मेरा अधिकांश समय दस्तावेज़ीकरण और ब्रांडिंग पर काम करने में व्यतीत होता है।
   <p markdown="1" class="pquote-credit">
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["डिफ़ॉल्ट रूप से OSS पर जा रहा है"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
   </p>
 </aside>
 
-Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+भले ही आपको कोड लिखना पसंद हो, अन्य प्रकार के योगदान किसी प्रोजेक्ट में शामिल होने और समुदाय के अन्य सदस्यों से मिलने का एक शानदार तरीका है। उन संबंधों के निर्माण से आपको परियोजना के अन्य हिस्सों पर काम करने का अवसर मिलेगा।
 
-### Do you like planning events?
+### क्या आपको आयोजनों की योजना बनाना पसंद है?
 
-* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
-* Organize the project's conference (if they have one)
-* Help community members find the right conferences and submit proposals for speaking
+* परियोजना के बारे में कार्यशालाएँ या बैठकें आयोजित करें, [जैसे @fzamperin ने NodeSchool के लिए किया](https://github.com/nodeschool/organizers/issues/406)
+* परियोजना का सम्मेलन आयोजित करें (यदि उनके पास एक है)
+* समुदाय के सदस्यों को सही सम्मेलन ढूंढने और बोलने के लिए प्रस्ताव प्रस्तुत करने में सहायता करें
 
-### Do you like to design?
+### क्या आपको डिज़ाइन करना पसंद है?
 
-* Restructure layouts to improve the project's usability
-* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
-* Put together a style guide to help the project have a consistent visual design
-* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+* परियोजना की उपयोगिता में सुधार के लिए लेआउट का पुनर्गठन करें
+* प्रोजेक्ट के नेविगेशन या मेनू को पुनर्गठित और परिष्कृत करने के लिए उपयोगकर्ता अनुसंधान करें, [जैसा कि Drupal सुझाव देता है](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* प्रोजेक्ट को एक सुसंगत विज़ुअल डिज़ाइन बनाने में मदद करने के लिए एक स्टाइल गाइड साथ रखें
+* टी-शर्ट या नए लोगो के लिए कला बनाएं, [जैसे hapi.js के योगदानकर्ताओं ने किया](https://github.com/hapijs/contrib/issues/68)
 
-### Do you like to write?
+### क्या आप लिखना पसंद करते हैं?
 
-* Write and improve the project's documentation
-* Curate a folder of examples showing how the project is used
-* Start a newsletter for the project, or curate highlights from the mailing list
-* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
-* Write a translation for the project's documentation
+* प्रोजेक्ट के दस्तावेज़ीकरण को लिखें और सुधारें
+* प्रोजेक्ट का उपयोग कैसे किया जाता है, यह दर्शाने वाले उदाहरणों का एक फ़ोल्डर बनाएं
+* प्रोजेक्ट के लिए एक न्यूज़लेटर शुरू करें, या मेलिंग सूची से हाइलाइट्स क्यूरेट करें
+* प्रोजेक्ट के लिए ट्यूटोरियल लिखें, [जैसे PyPA के योगदानकर्ताओं ने किया](https://github.com/pypa/python-package-user-guide/issues/194)
+* परियोजना के दस्तावेज़ीकरण के लिए एक अनुवाद लिखें
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
-  Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+  सचमुच, \[दस्तावेज़ीकरण\] अत्यंत महत्वपूर्ण है। अब तक का दस्तावेज़ीकरण बढ़िया रहा है और बैबेल की एक शानदार विशेषता रही है। ऐसे अनुभाग हैं जो निश्चित रूप से कुछ काम का उपयोग कर सकते हैं और यहां तक कि यहां या वहां एक पैराग्राफ जोड़ना भी बेहद सराहनीय है।
   <p markdown="1" class="pquote-credit">
-— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+— @kittens, ["योगदानकर्ताओं के लिए कॉल करें"](https://github.com/babel/babel/issues/1347)
   </p>
 </aside>
 
-### Do you like organizing?
+### क्या आपको आयोजन करना पसंद है?
 
-* Link to duplicate issues, and suggest new issue labels, to keep things organized
-* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
-* Ask clarifying questions on recently opened issues to move the discussion forward
+* चीजों को व्यवस्थित रखने के लिए डुप्लिकेट मुद्दों से लिंक करें, और नए अंक लेबल का सुझाव दें
+* खुले मुद्दों पर गौर करें और पुराने मुद्दों को बंद करने का सुझाव दें, [जैसे @nzakas ने ESLint के लिए किया](https://github.com/eslint/eslint/issues/6765)
+* चर्चा को आगे बढ़ाने के लिए हाल ही में खुले मुद्दों पर स्पष्ट प्रश्न पूछें
 
-### Do you like to code?
+### क्या आपको कोड करना पसंद है?
 
-* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
-* Ask if you can help write a new feature
-* Automate project setup
-* Improve tooling and testing
+* निपटने के लिए एक खुला मुद्दा खोजें, [जैसे @dianjin ने कैटलॉग के लिए किया](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* पूछें कि क्या आप एक नई सुविधा लिखने में मदद कर सकते हैं
+* स्वचालित प्रोजेक्ट सेटअप
+* टूलींग और परीक्षण में सुधार करें
 
-### Do you like helping people?
+### क्या आपको लोगों की मदद करना पसंद है?
 
-* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
-* Answer questions for people on open issues
-* Help moderate the discussion boards or conversation channels
+* प्रोजेक्ट के बारे में प्रश्नों के उत्तर दें, उदाहरण के लिए, स्टैक ओवरफ्लो ([इस पोस्टग्रेज उदाहरण की तरह](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) या रेडिट
+* खुले मुद्दों पर लोगों के सवालों के जवाब दें
+* चर्चा बोर्डों या वार्तालाप चैनलों को मॉडरेट करने में सहायता करें
 
-### Do you like helping others code?
+### क्या आपको दूसरों की कोड में मदद करना पसंद है?
 
-* Review code on other people's submissions
-* Write tutorials for how a project can be used
-* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+* अन्य लोगों के सबमिशन पर कोड की समीक्षा करें
+* किसी प्रोजेक्ट का उपयोग कैसे किया जा सकता है, इसके लिए ट्यूटोरियल लिखें
+* किसी अन्य योगदानकर्ता को सलाह देने की पेशकश, [जैसे @ereichert ने Rust पर @bronzdoc के लिए किया](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
 
-### You don't just have to work on software projects!
+### आपको सिर्फ सॉफ्टवेयर प्रोजेक्ट पर काम नहीं करना है!
 
-While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+जबकि "ओपन सोर्स" अक्सर सॉफ़्टवेयर को संदर्भित करता है, आप किसी भी चीज़ पर सहयोग कर सकते हैं। ऐसी किताबें, रेसिपी, सूचियाँ और कक्षाएं हैं जिन्हें ओपन सोर्स प्रोजेक्ट के रूप में विकसित किया जाता है।
 
-For example:
+उदाहरण के लिए:
 
-* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
-* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
-* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+* @sindresorhas एक ["भयानक" सूचियों की सूची तैयार करता है](https://github.com/sindresorhas/awesome)
+* @h5bp फ्रंट-एंड डेवलपर उम्मीदवारों के लिए [संभावित साक्षात्कार प्रश्नों की सूची] (https://github.com/h5bp/Front-end-Developer-Interview-Questions) रखता है
+* @stuartlynn और @nicole-a-tesla ने [पफिन्स के बारे में मजेदार तथ्यों का संग्रह](https://github.com/stuartlynn/puffin_facts) बनाया।
 
-Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
+भले ही आप एक सॉफ़्टवेयर डेवलपर हों, दस्तावेज़ीकरण प्रोजेक्ट पर काम करने से आपको ओपन सोर्स में शुरुआत करने में मदद मिल सकती है। उन परियोजनाओं पर काम करना अक्सर कम डराने वाला होता है जिनमें कोड शामिल नहीं होता है, और सहयोग की प्रक्रिया आपके आत्मविश्वास और अनुभव का निर्माण करेगी।
 
-## Orienting yourself to a new project
+## अपने आप को एक नई परियोजना की ओर उन्मुख करना
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
-  If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+  यदि आप किसी समस्या ट्रैकर पर जाते हैं और चीजें भ्रमित करने वाली लगती हैं, तो यह सिर्फ आप ही नहीं हैं। इन उपकरणों के लिए बहुत अधिक अंतर्निहित ज्ञान की आवश्यकता होती है, लेकिन लोग इसे नेविगेट करने में आपकी सहायता कर सकते हैं और आप उनसे प्रश्न पूछ सकते हैं।
   <p markdown="1" class="pquote-credit">
-— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+— @shaunagm, ["ओपन सोर्स में कैसे योगदान करें"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
   </p>
 </aside>
 
-For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+टाइपो फिक्स से अधिक किसी भी चीज़ के लिए, ओपन सोर्स में योगदान करना किसी पार्टी में अजनबियों के समूह के पास जाने जैसा है। यदि आप लामाओं के बारे में बात करना शुरू करते हैं, जबकि वे सुनहरी मछली के बारे में गहन चर्चा में थे, तो वे शायद आपको थोड़ा अजीब तरीके से देखेंगे।
 
-Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
+अपने स्वयं के सुझावों पर आँख मूँद कर कूदने से पहले, कमरे को पढ़ना सीखना शुरू करें। ऐसा करने से संभावना बढ़ जाती है कि आपके विचारों पर ध्यान दिया जाएगा और सुना जाएगा।
 
-### Anatomy of an open source project
+### एक ओपन सोर्स प्रोजेक्ट का एनाटॉमी
 
-Every open source community is different.
+प्रत्येक खुला स्रोत समुदाय अलग है।
 
-Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+एक ओपन सोर्स प्रोजेक्ट पर वर्षों बिताने का मतलब है कि आपको एक ओपन सोर्स प्रोजेक्ट के बारे में पता चल गया है। एक अलग प्रोजेक्ट पर जाएँ, और आप पाएंगे कि शब्दावली, मानदंड और संचार शैलियाँ पूरी तरह से अलग हैं।
 
-That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+जैसा कि कहा गया है, कई ओपन सोर्स प्रोजेक्ट समान संगठनात्मक संरचना का पालन करते हैं। विभिन्न सामुदायिक भूमिकाओं और समग्र प्रक्रिया को समझने से आपको किसी भी नई परियोजना के प्रति शीघ्रता से उन्मुख होने में मदद मिलेगी।
 
-A typical open source project has the following types of people:
+एक विशिष्ट ओपन सोर्स प्रोजेक्ट में निम्नलिखित प्रकार के लोग होते हैं:
 
-* **Author:** The person/s or organization that created the project
-* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
-* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
-* **Contributors:** Everyone who has contributed something back to the project
-* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+* **लेखक:** वह व्यक्ति/संगठन जिसने प्रोजेक्ट बनाया है
+* **स्वामी:** वह व्यक्ति/व्यक्ति जिनके पास संगठन या भंडार पर प्रशासनिक स्वामित्व है (हमेशा मूल लेखक के समान नहीं)
+* **रखरखावकर्ता:** योगदानकर्ता जो परियोजना के दृष्टिकोण को आगे बढ़ाने और संगठनात्मक पहलुओं को प्रबंधित करने के लिए जिम्मेदार हैं (वे परियोजना के लेखक या मालिक भी हो सकते हैं।)
+* **योगदानकर्ता:** हर कोई जिसने परियोजना में कुछ न कुछ योगदान दिया है
+* **समुदाय सदस्य:** वे लोग जो परियोजना का उपयोग करते हैं। वे बातचीत में सक्रिय हो सकते हैं या परियोजना की दिशा पर अपनी राय व्यक्त कर सकते हैं
 
-Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+बड़ी परियोजनाओं में उपसमितियां या कार्य समूह भी हो सकते हैं जो टूलींग, ट्राइएज, सामुदायिक मॉडरेशन और इवेंट आयोजन जैसे विभिन्न कार्यों पर केंद्रित हो सकते हैं। इस जानकारी को पाने के लिए किसी प्रोजेक्ट की वेबसाइट पर "टीम" पृष्ठ, या शासन दस्तावेज़ के भंडार में देखें।
 
-A project also has documentation. These files are usually listed in the top level of a repository.
+एक प्रोजेक्ट में दस्तावेज़ीकरण भी होता है. ये फ़ाइलें आमतौर पर रिपॉजिटरी के शीर्ष स्तर पर सूचीबद्ध होती हैं।
 
-* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
-* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
-* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
-* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
-* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.
+* **लाइसेंस:** परिभाषा के अनुसार, प्रत्येक ओपन सोर्स प्रोजेक्ट के पास एक [ओपन सोर्स लाइसेंस](https://choosealicense.com) होना चाहिए। यदि प्रोजेक्ट के पास लाइसेंस नहीं है, तो यह खुला स्रोत नहीं है।
+* **रीडमी:** रीडमी एक निर्देश पुस्तिका है जो परियोजना में नए समुदाय के सदस्यों का स्वागत करती है। यह बताता है कि परियोजना क्यों उपयोगी है और इसे कैसे शुरू किया जाए।
+* **योगदान:** जबकि READMEs लोगों को परियोजना का उपयोग करने में मदद करते हैं, योगदान करने वाले दस्तावेज़ लोगों को परियोजना में योगदान देने में मदद करते हैं। यह बताता है कि किस प्रकार के योगदान की आवश्यकता है और प्रक्रिया कैसे काम करती है। हालाँकि हर परियोजना में योगदान फ़ाइल नहीं होती है, इसकी उपस्थिति संकेत देती है कि यह योगदान करने के लिए एक स्वागत योग्य परियोजना है।
+* **आचार संहिता:** आचार संहिता प्रतिभागियों के व्यवहार से संबंधित बुनियादी नियम निर्धारित करती है और एक मैत्रीपूर्ण, स्वागत योग्य वातावरण बनाने में मदद करती है। हालाँकि हर परियोजना में एक Code_OF_CONDUCT फ़ाइल नहीं होती है, लेकिन इसकी उपस्थिति संकेत देती है कि यह योगदान देने के लिए एक स्वागत योग्य परियोजना है।
+* **अन्य दस्तावेज़:** अतिरिक्त दस्तावेज़ हो सकते हैं, जैसे ट्यूटोरियल, वॉकथ्रू, या शासन नीतियां, विशेष रूप से बड़ी परियोजनाओं पर।
 
-Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+अंत में, ओपन सोर्स प्रोजेक्ट चर्चा को व्यवस्थित करने के लिए निम्नलिखित टूल का उपयोग करते हैं। अभिलेखों को पढ़ने से आपको एक अच्छी तस्वीर मिलेगी कि समुदाय कैसे सोचता है और कैसे काम करता है।
 
-* **Issue tracker:** Where people discuss issues related to the project.
-* **Pull requests:** Where people discuss and review changes that are in progress.
-* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
-* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
+* **समस्या ट्रैकर:** जहां लोग परियोजना से संबंधित मुद्दों पर चर्चा करते हैं।
+* **पुल अनुरोध:** जहां लोग प्रगति पर चल रहे परिवर्तनों पर चर्चा और समीक्षा करते हैं।
+* **चर्चा फ़ोरम या मेलिंग सूचियाँ:** कुछ परियोजनाएँ इन चैनलों का उपयोग वार्तालाप विषयों के लिए कर सकती हैं (उदाहरण के लिए, _"मैं कैसे करूँ..."_ या _"आप किस बारे में सोचते हैं..."_ बग के बजाय रिपोर्ट या सुविधा अनुरोध)। अन्य सभी वार्तालापों के लिए समस्या ट्रैकर का उपयोग करते हैं।
+* **सिंक्रोनस चैट चैनल:** कुछ प्रोजेक्ट आकस्मिक बातचीत, सहयोग और त्वरित आदान-प्रदान के लिए चैट चैनल (जैसे स्लैक या आईआरसी) का उपयोग करते हैं।
 
-## Finding a project to contribute to
+## योगदान देने के लिए एक परियोजना ढूँढना
 
-Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+अंत में, ओपन सोर्स प्रोजेक्ट चर्चा को व्यवस्थित करने के लिए निम्नलिखित टूल का उपयोग करते हैं। अभिलेखों को पढ़ने से आपको एक अच्छी तस्वीर मिलेगी कि समुदाय कैसे सोचता है और कैसे काम करता है।
 
-If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_
+* **समस्या ट्रैकर:** जहां लोग परियोजना से संबंधित मुद्दों पर चर्चा करते हैं।
+* **पुल अनुरोध:** जहां लोग प्रगति पर चल रहे परिवर्तनों पर चर्चा और समीक्षा करते हैं।
+* **चर्चा फ़ोरम या मेलिंग सूचियाँ:** कुछ परियोजनाएँ इन चैनलों का उपयोग वार्तालाप विषयों के लिए कर सकती हैं (उदाहरण के लिए, _"मैं कैसे करूँ..."_ या _"आप किस बारे में सोचते हैं..."_ बग के बजाय रिपोर्ट या सुविधा अनुरोध)। अन्य सभी वार्तालापों के लिए समस्या ट्रैकर का उपयोग करते हैं।
+* **सिंक्रोनस चैट चैनल:** कुछ प्रोजेक्ट आकस्मिक बातचीत, सहयोग और त्वरित आदान-प्रदान के लिए चैट चैनल (जैसे स्लैक या आईआरसी) का उपयोग करते हैं।
 
-Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+## योगदान देने के लिए एक परियोजना ढूँढना
 
-Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+आप README को स्कैन कर सकते हैं और एक टूटा हुआ लिंक या कोई टाइपो पा सकते हैं। या आप एक नए उपयोगकर्ता हैं और आपने देखा कि कुछ टूटा हुआ है, या कोई समस्या है जो आपको लगता है कि वास्तव में दस्तावेज़ में होनी चाहिए। इसे नज़रअंदाज़ करने और आगे बढ़ने, या किसी और से इसे ठीक करने के लिए कहने के बजाय, देखें कि क्या आप इसमें योगदान देकर मदद कर सकते हैं। खुले स्रोत का यही मतलब है!
 
-Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+> [28% आकस्मिक योगदान](https://www.igor.pro.br/publica/papers/saner2016.pdf) ओपन सोर्स के लिए दस्तावेज हैं, जैसे टाइपो फिक्स, रिफॉर्मेटिंग, या अनुवाद लिखना।
 
-Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+यदि आप मौजूदा मुद्दों की तलाश कर रहे हैं जिन्हें आप ठीक कर सकते हैं, तो प्रत्येक ओपन सोर्स प्रोजेक्ट में एक `/contribute` पेज होता है जो शुरुआती-अनुकूल मुद्दों पर प्रकाश डालता है जिनके साथ आप शुरुआत कर सकते हैं। GitHub पर रिपॉजिटरी के मुख्य पृष्ठ पर जाएँ, और URL के अंत में `/contribute` जोड़ें (उदाहरण के लिए [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
 
-You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
-
-> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
-
-If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
-
-You can also use one of the following resources to help you discover and contribute to new projects:
+नई परियोजनाओं को खोजने और उनमें योगदान देने में सहायता के लिए आप निम्नलिखित संसाधनों में से किसी एक का भी उपयोग कर सकते हैं:
 
 * [GitHub Explore](https://github.com/explore/)
 * [Open Source Friday](https://opensourcefriday.com)
@@ -217,304 +214,304 @@ You can also use one of the following resources to help you discover and contrib
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
-### A checklist before you contribute
+### योगदान देने से पहले एक चेकलिस्ट
 
-When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+जब आपको कोई ऐसा प्रोजेक्ट मिल जाए जिसमें आप योगदान करना चाहते हैं, तो यह सुनिश्चित करने के लिए त्वरित स्कैन करें कि प्रोजेक्ट योगदान स्वीकार करने के लिए उपयुक्त है। वरना आपकी मेहनत को कभी जवाब नहीं मिल पाएगा.
 
-Here's a handy checklist to evaluate whether a project is good for new contributors.
+यह मूल्यांकन करने के लिए एक आसान चेकलिस्ट है कि कोई प्रोजेक्ट नए योगदानकर्ताओं के लिए अच्छा है या नहीं।
 
-**Meets the definition of open source**
+**ओपन सोर्स की परिभाषा को पूरा करता है**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
-  </label>
+  क्या इसके पास लाइसेंस है? आमतौर पर, रिपॉजिटरी के रूट में LICENSE नामक एक फ़ाइल होती है।
+   </label>
 </div>
 
-**Project actively accepts contributions**
+**परियोजना सक्रिय रूप से योगदान स्वीकार करती है**
 
-Look at the commit activity on the main branch. On GitHub, you can see this information on a repository's homepage.
+Main branch पर commit प्रतिबद्ध को देखें। GitHub पर, आप इस जानकारी को रिपॉजिटरी के होमपेज पर देख सकते हैं।
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-  When was the latest commit?
+  नवीनतम प्रतिबद्धता कब थी?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-  How many contributors does the project have?
+  परियोजना में कितने योगदानकर्ता हैं?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  लोग कितनी बार प्रतिबद्ध होते हैं? (GitHub पर, आप इसे शीर्ष बार में "कमिट्स" पर क्लिक करके पा सकते हैं।)
   </label>
 </div>
 
-Next, look at the project's issues.
+इसके बाद, परियोजना के मुद्दों को देखें।
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    How many open issues are there?
+    कितने खुले मुद्दे हैं?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to issues when they are opened?
+    क्या रखरखावकर्ता मुद्दों को खोले जाने पर तुरंत उन पर प्रतिक्रिया देते हैं?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the issues?
+    क्या मुद्दों पर सक्रिय चर्चा होती है?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-    Are the issues recent?
+    क्या मुद्दे ताज़ा हैं?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+    क्या मुद्दे बंद हो रहे हैं? (GitHub पर, बंद मुद्दों को देखने के लिए मुद्दे पृष्ठ पर "closed" टैब पर क्लिक करें।)
   </label>
 </div>
 
-Now do the same for the project's pull requests.
+अब प्रोजेक्ट के पुल रीकवेस्ट के लिए भी ऐसा ही करें।
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    How many open pull requests are there?
+    कितने खुले पुल रीकवेस्ट हैं?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox20" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to pull requests when they are opened?
+    क्या अनुरक्षक खुले पुल रीकवेस्ट जाने पर तुरंत प्रतिक्रिया देते हैं?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the pull requests?
+    क्या पुल रीकवेस्ट पर सक्रिय चर्चा है?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    Are the pull requests recent?
+    क्या पुल रीकवेस्ट हाल ही में हुए हैं?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox13" class="overflow-hidden d-block text-normal">
-    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+    हाल ही में किसी पुल रीकवेस्ट का मर्ज किया गया था? (GitHub पर, बंद पीआर देखने के लिए पुल रीकवेस्ट पृष्ठ पर "closed" टैब पर क्लिक करें।)
   </label>
 </div>
 
-**Project is welcoming**
+**परियोजना स्वागतयोग्य है**
 
-A project that is friendly and welcoming signals that they will be receptive to new contributors.
+एक परियोजना जो मैत्रीपूर्ण और स्वागत योग्य है, यह संकेत देती है कि वे नए योगदानकर्ताओं के प्रति ग्रहणशील होंगे।
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox14" class="overflow-hidden d-block text-normal">
-    Do the maintainers respond helpfully to questions in issues?
+    क्या अनुरक्षक मुद्दों में सवालों का मददगार ढंग से जवाब देते हैं?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox15" class="overflow-hidden d-block text-normal">
-    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+    क्या लोग मुद्दों, चर्चा मंच और चैट में मित्रवत हैं (उदाहरण के लिए, IRS या Slack)?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox16" class="overflow-hidden d-block text-normal">
-    Do pull requests get reviewed?
+    क्या पुल रीकवेस्ट की समीक्षा की जाती है?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox17" class="overflow-hidden d-block text-normal">
-    Do maintainers thank people for their contributions?
+    क्या अनुरक्षक लोगों को उनके योगदान के लिए धन्यवाद देते हैं?
   </label>
 </div>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-  Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+  जब भी आप कोई लंबा थ्रेड देखें, तो थ्रेड में देर से आने वाले मुख्य डेवलपर्स की प्रतिक्रियाओं की जांच करें। क्या वे रचनात्मक रूप से सारांश प्रस्तुत कर रहे हैं, और विनम्र रहते हुए सूत्र को निर्णय तक लाने के लिए कदम उठा रहे हैं? यदि आप देखते हैं कि बहुत सारे ज्वलंत युद्ध चल रहे हैं, तो यह अक्सर एक संकेत है कि ऊर्जा विकास के बजाय तर्क-वितर्क में जा रही है।
   <p markdown="1" class="pquote-credit">
 — @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
   </p>
 </aside>
 
-## How to submit a contribution
+## योगदान कैसे जमा करें
 
-You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+आपको अपनी पसंद का एक प्रोजेक्ट मिल गया है और आप योगदान देने के लिए तैयार हैं। अंत में! यहां बताया गया है कि अपना योगदान सही तरीके से कैसे प्राप्त करें।
 
-### Communicating effectively
+### प्रभावी ढंग से संचार करना
 
-Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+चाहे आप एक बार के योगदानकर्ता हों या किसी समुदाय में शामिल होने का प्रयास कर रहे हों, दूसरों के साथ काम करना सबसे महत्वपूर्ण कौशलों में से एक है जिसे आप ओपन सोर्स में विकसित करेंगे।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
-  \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+ \[एक नए योगदानकर्ता के रूप में,\] मुझे तुरंत एहसास हुआ कि अगर मैं इस मुद्दे को बंद करने में सक्षम होना चाहता हूं तो मुझे प्रश्न पूछना होगा। मैंने कोड बेस को सरसरी तौर पर देखा। एक बार जब मुझे कुछ समझ आ गया कि क्या हो रहा है, तो मैंने और दिशा-निर्देश मांगे। और वोइला! मुझे आवश्यक सभी प्रासंगिक विवरण प्राप्त करने के बाद मैं समस्या को हल करने में सक्षम था।
   <p markdown="1" class="pquote-credit">
-— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+— @shubheksha, [ओपन सोर्स की दुनिया के माध्यम से एक शुरुआती की बहुत ऊबड़-खाबड़ यात्रा](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
   </p>
 </aside>
 
-Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+इससे पहले कि आप कोई मुद्दा खोलें या अनुरोध खींचें, या चैट में कोई प्रश्न पूछें, अपने विचारों को प्रभावी ढंग से सामने लाने में मदद के लिए इन बिंदुओं को ध्यान में रखें।
 
-**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+**संदर्भ दें।** दूसरों को तेजी से आगे बढ़ने में मदद करें। यदि आप किसी त्रुटि का सामना कर रहे हैं, तो बताएं कि आप क्या करने का प्रयास कर रहे हैं और इसे कैसे पुन: उत्पन्न करना है। यदि आप कोई नया विचार सुझा रहे हैं, तो स्पष्ट करें कि आप क्यों सोचते हैं कि यह परियोजना के लिए उपयोगी होगा (केवल आपके लिए नहीं!)।
 
-> 😇 _"X doesn't happen when I do Y"_
+> 😇 _"जब मैं यह करता हूं तो वह नहीं होता"_
 >
-> 😢 _"X is broken! Please fix it."_
+> 😢 _"यह टूट गया है! कृपया इसे ठीक करें।"_
 
-**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn.
+**कृपया अपना होमवर्क पहले से कर लें।** चीजों को न जानना ठीक है, लेकिन दिखाएं कि आपने प्रयास किया। मदद मांगने से पहले, किसी प्रोजेक्ट की रीडमी, दस्तावेज़ीकरण, मुद्दे (खुले या बंद), मेलिंग सूची की जांच करना और उत्तर के लिए इंटरनेट पर खोजना सुनिश्चित करें। जब आप प्रदर्शित करेंगे कि आप सीखने का प्रयास कर रहे हैं तो लोग इसकी सराहना करेंगे।
 
-> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+> 😇 _"मुझे नहीं पता कि ईस को कैसे लागू किया जाए। मैंने सहायता दस्तावेजों की जांच की और कोई उल्लेख नहीं मिला।"_
 >
-> 😢 _"How do I X?"_
+> 😢 _"मैं कैसे यह करूं?"_
 
-**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+**अनुरोधों को संक्षिप्त और सीधा रखें।** ईमेल भेजने की तरह, हर योगदान, चाहे कितना भी सरल या उपयोगी क्यों न हो, किसी और की समीक्षा की आवश्यकता होती है। कई परियोजनाओं में मदद के लिए उपलब्ध लोगों की तुलना में अधिक अनुरोध आ रहे हैं। संक्षिप्त रखें। आपको इस बात की संभावना बढ़ जाएगी कि कोई आपकी मदद कर पाएगा।
 
-> 😇 _"I'd like to write an API tutorial."_
+> 😇 _"मैं एक एपीआई ट्यूटोरियल लिखना चाहूंगा।"_
 >
-> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+> 😢 _"मैं पिछले दिन राजमार्ग पर गाड़ी चला रहा था और गैस के लिए रुका, और तभी मेरे मन में यह अद्भुत विचार आया कि हमें क्या करना चाहिए, लेकिन इससे पहले कि मैं यह समझाऊं, मैं आपको दिखाता हूं..."_
 
-**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+**सभी संचार सार्वजनिक रखें।** हालांकि यह आकर्षक है, जब तक आपको संवेदनशील जानकारी (जैसे कोई सुरक्षा मुद्दा या गंभीर आचरण उल्लंघन) साझा करने की आवश्यकता न हो, निजी तौर पर अनुरक्षकों तक न पहुंचें। जब आप बातचीत को सार्वजनिक रखते हैं, तो अधिक लोग आपके आदान-प्रदान से सीख सकते हैं और लाभ उठा सकते हैं। चर्चाएँ, अपने आप में, योगदान हो सकती हैं।
 
-> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+> 😇 _(एक टिप्पणी के रूप में) "@-maintainer नमस्ते! हमें इस PR पर कैसे आगे बढ़ना चाहिए?"_
 >
-> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+> 😢_(एक ईमेल के रूप में) "अरे, ईमेल पर आपको परेशान करने के लिए खेद है, लेकिन मैं सोच रहा था कि क्या आपको मेरे PR की समीक्षा करने का मौका मिला है"_
 
-**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+**प्रश्न पूछना ठीक है (लेकिन धैर्य रखें!)** हर कोई किसी न किसी समय परियोजना में नया था, और यहां तक ​​कि अनुभवी योगदानकर्ताओं को भी जब वे किसी नई परियोजना को देखते हैं तो उन्हें तेजी लाने की जरूरत होती है। इसी तरह, लंबे समय तक अनुरक्षक भी हमेशा परियोजना के हर हिस्से से परिचित नहीं होते हैं। उन्हें वही धैर्य दिखाएं जो आप चाहते हैं कि वे आपके प्रति दिखाएं।
 
-> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+> 😇 _"इस त्रुटि पर ध्यान देने के लिए धन्यवाद। मैंने आपके सुझावों का पालन किया। यहां आउटपुट है।"_
 >
-> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+> 😢 _"आप मेरी समस्या का समाधान क्यों नहीं कर सकते? क्या यह आपका प्रोजेक्ट नहीं है?"_
 
-**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+**सामुदायिक निर्णयों का सम्मान करें।** आपके विचार समुदाय की प्राथमिकताओं या दृष्टिकोण से भिन्न हो सकते हैं। वे प्रतिक्रिया दे सकते हैं या आपके विचार को आगे न बढ़ाने का निर्णय ले सकते हैं। जबकि आपको चर्चा करनी चाहिए और समझौते की तलाश करनी चाहिए, लेकिन अनुरक्षकों को आपके निर्णय के साथ आपकी इच्छा से अधिक समय तक रहना होगा। यदि आप उनकी दिशा से असहमत हैं, तो आप हमेशा अपने स्वयं के कांटे पर काम कर सकते हैं या अपना स्वयं का प्रोजेक्ट शुरू कर सकते हैं।
 
-> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+> 😇 _"मुझे निराशा है कि आप मेरे उपयोग के मामले का समर्थन नहीं कर सकते, लेकिन जैसा कि आपने समझाया है कि यह केवल उपयोगकर्ताओं के एक छोटे हिस्से को प्रभावित करता है, मैं समझता हूं क्यों। सुनने के लिए धन्यवाद।"_
 >
-> 😢 _"Why won't you support my use case? This is unacceptable!"_
+> 😢 _"आप मेरे उपयोग के मामले का समर्थन क्यों नहीं करेंगे? यह अस्वीकार्य है!"_
 
-**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+**सबसे बढ़कर, इसे उत्तम दर्जे का रखें।** ओपन सोर्स दुनिया भर के सहयोगियों से बना है। भाषाओं, संस्कृतियों, भूगोलों और समय क्षेत्रों में संदर्भ खो जाता है। इसके अलावा, लिखित संचार से स्वर या मनोदशा को व्यक्त करना कठिन हो जाता है। इन वार्तालापों में अच्छे इरादे मानें। किसी विचार पर विनम्रतापूर्वक ज़ोर देना, अधिक संदर्भ मांगना, या अपनी स्थिति को और स्पष्ट करना ठीक है। बस इंटरनेट को उस समय से बेहतर जगह छोड़ने का प्रयास करें जब यह आपको मिला था।
 
-### Gathering context
+### संदर्भ एकत्रित करना
 
-Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+कुछ भी करने से पहले, यह सुनिश्चित करने के लिए त्वरित जांच करें कि आपके विचार की चर्चा कहीं और नहीं की गई है। प्रोजेक्ट के README, मुद्दे (खुले और बंद), मेलिंग सूची और स्टैक ओवरफ़्लो को स्किम करें। आपको हर चीज़ को पढ़ने में घंटों खर्च करने की ज़रूरत नहीं है, लेकिन कुछ प्रमुख शब्दों की त्वरित खोज बहुत काम आती है।
 
-If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request:
+यदि आपको अपना विचार कहीं और नहीं मिल रहा है, तो आप एक कदम उठाने के लिए तैयार हैं। यदि प्रोजेक्ट GitHub पर है, तो आप संभवतः कोई समस्या खोलकर या अनुरोध खींचकर संवाद करेंगे:
 
-* **Issues** are like starting a conversation or discussion
-* **Pull requests** are for starting work on a solution
-* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one
+* **ईशूस** बातचीत या चर्चा शुरू करने जैसा है
+* **पुल रीकवेस्ट** समाधान पर काम शुरू करने के लिए हैं
+* **हल्के संचार के लिए,** जैसे कि स्पष्टीकरण या कैसे-कैसे प्रश्न करें, स्टैक ओवरफ़्लो, IRS, स्लैक, या अन्य चैट चैनलों पर पूछने का प्रयास करें, यदि प्रोजेक्ट में कोई है
 
-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.
+किसी मुद्दे को खोलने या अनुरोध खींचने से पहले, यह देखने के लिए कि क्या आपको कुछ विशिष्ट शामिल करने की आवश्यकता है, प्रोजेक्ट के योगदान दस्तावेज़ (आमतौर पर CONTRIBUTING या README में एक फ़ाइल) की जाँच करें। उदाहरण के लिए, वे आपसे एक टेम्पलेट का पालन करने के लिए कह सकते हैं, या आपसे परीक्षण का उपयोग करने के लिए कह सकते हैं।
 
-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.
+यदि आप कोई महत्वपूर्ण योगदान देना चाहते हैं, तो उस पर काम करने से पहले पूछने के लिए एक मुद्दा खोलें। प्रोजेक्ट को कुछ समय के लिए देखना उपयोगी है (GitHub पर, [आप "watch" पर क्लिक कर सकते हैं)](https://help.github.com/articles/watching-repositories/) सभी वार्तालापों की सूचना प्राप्त करने के लिए), और वह काम करने से पहले समुदाय के सदस्यों को जानें जिन्हें स्वीकार नहीं किया जा सकता है।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
-  You'll learn <em>a lot</em> from taking a single project you actively use, "watching" it on GitHub and reading every issue and PR.
+  आप सक्रिय रूप से उपयोग किए जाने वाले किसी एक प्रोजेक्ट को लेने, उसे GitHub पर "देखने" और हर अंक और पीआर को पढ़ने से <em>बहुत कुछ</em> सीखेंगे।
 <p markdown="1" class="pquote-credit">
-— @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
+— @gaearon [परियोजनाओं में शामिल होने पर](https://twitter.com/dan_abramov/status/819555257055322112)
   </p>
 </aside>
 
-### Opening an issue
+### एक मुद्दा खुल रहा है
 
-You should usually open an issue in the following situations:
+आपको आमतौर पर निम्नलिखित स्थितियों में कोई मुद्दा खोलना चाहिए:
 
-* Report an error you can't solve yourself
-* Discuss a high-level topic or idea (for example, community, vision or policies)
-* Propose a new feature or other project idea
+* उस त्रुटि की रिपोर्ट करें जिसे आप स्वयं हल नहीं कर सकते
+* किसी उच्च-स्तरीय विषय या विचार पर चर्चा करें (उदाहरण के लिए, समुदाय, दृष्टिकोण या नीतियां)
+* एक नई सुविधा या अन्य परियोजना विचार का प्रस्ताव रखें
 
-Tips for communicating on issues:
+मुद्दों पर संवाद करने के लिए युक्तियाँ:
 
-* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
-* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
-* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+* **यदि आप कोई खुला मुद्दा देखते हैं जिससे आप निपटना चाहते हैं,** लोगों को यह बताने के लिए कि आप इस मुद्दे पर हैं, उस मुद्दे पर टिप्पणी करें। इस तरह, लोगों द्वारा आपके काम की नकल करने की संभावना कम होगी।
+* **यदि कोई मुद्दा कुछ समय पहले खोला गया था,** यह संभव है कि इसे कहीं और संबोधित किया जा रहा है, या पहले ही हल किया जा चुका है, इसलिए काम शुरू करने से पहले पुष्टि के लिए टिप्पणी करें।
+* **यदि आपने कोई मुद्दा खोला है, लेकिन बाद में आपको स्वयं उत्तर मिल गया है,** लोगों को बताने के लिए मुद्दे पर टिप्पणी करें, फिर मुद्दे को बंद कर दें। यहां तक कि उस परिणाम का दस्तावेज़ीकरण भी परियोजना में एक योगदान है।
 
-### Opening a pull request
+### पुल रीकवेस्ट खोलना
 
-You should usually open a pull request in the following situations:
+आपको आमतौर पर निम्नलिखित स्थितियों में पुल अनुरोध खोलना चाहिए:
 
-* Submit trivial fixes (for example, a typo, a broken link or an obvious error)
-* Start work on a contribution that was already asked for, or that you've already discussed, in an issue
+* मामूली सुधार सबमिट करें (उदाहरण के लिए, एक टाइपो, एक टूटा हुआ लिंक या एक स्पष्ट त्रुटि)
+* उस योगदान पर काम शुरू करें जो पहले से ही मांगा गया था, या जिस पर आप पहले ही किसी मुद्दे पर चर्चा कर चुके हैंn
 
-A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
+पुल अनुरोध को समाप्त कार्य का प्रतिनिधित्व करने की आवश्यकता नहीं है। आमतौर पर पुल अनुरोध को जल्दी खोलना बेहतर होता है, ताकि अन्य लोग आपकी प्रगति को देख सकें या उस पर प्रतिक्रिया दे सकें। बस इसे "ड्राफ्ट" के रूप में खोलें या विषय पंक्ति में "डब्ल्यूआईपी" (कार्य प्रगति पर) के रूप में चिह्नित करें। आप बाद में कभी भी और कमिट जोड़ सकते हैं।
 
-If the project is on GitHub, here's how to submit a pull request:
+यदि प्रोजेक्ट GitHub पर है, तो पुल अनुरोध सबमिट करने का तरीका यहां दिया गया है:
 
-* **[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/).)
-* **[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.
-* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
-* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+* **[रेपासटरी को फोर्क करें](https://guides.github.com/activities/forking/)** और इसे स्थानीय रूप से क्लोन करें। अपने लोकल को रिमोट के रूप में जोड़कर मूल "अपस्ट्रीम" रिपॉजिटरी से कनेक्ट करें। "अपस्ट्रीम" से परिवर्तन अक्सर खींचें ताकि आप अद्यतित रहें ताकि जब आप अपना पुल अनुरोध सबमिट करें, तो मर्ज विवादों की संभावना कम हो जाएगी। (अधिक विस्तृत निर्देश देखें [यहाँ](https://help.github.com/articles/syncing-a-fork/).)
+* **[एक ब्रेनच बनाएँ](https://guides.github.com/introduction/flow/)** आपके संपादनों के लिए.
+* **अपने पीआर में किसी भी प्रासंगिक मुद्दे** या सहायक दस्तावेज़ का संदर्भ लें (उदाहरण के लिए, " #37 बंद होता है।")
+* **यदि आपके परिवर्तनों में HTML/CSS में अंतर शामिल है तो पहले और बाद के स्क्रीनशॉट शामिल करें**। छवियों को अपने पुल अनुरोध के मुख्य भाग में खींचें और छोड़ें।
+* **अपने परिवर्तनों का परीक्षण करें!** यदि कोई मौजूदा परीक्षण मौजूद है तो उसके विरुद्ध अपने परिवर्तन चलाएँ और आवश्यकता पड़ने पर नए बनाएँ। परीक्षण मौजूद हैं या नहीं, सुनिश्चित करें कि आपके परिवर्तन मौजूदा प्रोजेक्ट को बाधित नहीं करते हैं।
+* **परियोजना की शैली में अपनी सर्वोत्तम क्षमता से योगदान दें**। इसका मतलब यह हो सकता है कि इंडेंट, सेमी-कोलन या टिप्पणियों का उपयोग आप अपने स्वयं के भंडार से अलग तरीके से करेंगे, लेकिन इससे अनुरक्षक के लिए विलय करना, दूसरों के लिए समझना और भविष्य में बनाए रखना आसान हो जाता है।
 
-If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+यदि यह आपका पहला पुल अनुरोध है, तो [मेक अ पुल रिक्वेस्ट](http://makeapullrequest.com/) देखें, जिसे @kentcdodds ने वॉकथ्रू वीडियो ट्यूटोरियल के रूप में बनाया है। आप @Roshanjossey द्वारा बनाए गए [प्रथम योगदान](https://github.com/Roshanjossey/first-contributions) रिपॉजिटरी में पुल अनुरोध करने का अभ्यास भी कर सकते हैं।
 
-## What happens after you submit a contribution
+## आपके योगदान जमा करने के बाद क्या होता है
 
-You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
+तुमने यह किया! ओपन सोर्स योगदानकर्ता बनने पर बधाई। हमें उम्मीद है कि यह कई में से पहला है।
 
-After you submit a contribution, one of the following will happen:
+आपके द्वारा योगदान जमा करने के बाद, निम्नलिखित में से एक होगा:
 
-### 😭 You don't get a response.
+### 😭 आपको कोई प्रतिक्रिया नहीं मिलती।
 
-Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+उम्मीद है कि आपने [गतिविधि के संकेतों के लिए परियोजना की जाँच की](#a-checklist-before-you-contribute) योगदान देने से पहले. हालाँकि, किसी सक्रिय प्रोजेक्ट पर भी, यह संभव है कि आपके योगदान को प्रतिक्रिया नहीं मिलेगी।
 
-If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+यदि आपको एक सप्ताह से अधिक समय में कोई प्रतिक्रिया नहीं मिली है, तो किसी से समीक्षा के लिए पूछते हुए, उसी थ्रेड में विनम्रतापूर्वक प्रतिक्रिया देना उचित है। यदि आप अपने योगदान की समीक्षा करने के लिए सही व्यक्ति का नाम जानते हैं, तो आप उस थ्रेड में उनका @-mention कर सकते हैं।
 
-**Don't** reach out to that person privately; remember that public communication is vital to open source projects.
+**उस व्यक्ति तक निजी तौर पर संपर्क न करें; याद रखें कि ओपन सोर्स परियोजनाओं के लिए सार्वजनिक संचार महत्वपूर्ण है।
 
-If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+यदि आप विनम्रतापूर्वक बात करते हैं और फिर भी कोई प्रतिक्रिया नहीं देता है, तो यह संभव है कि कोई भी कभी भी प्रतिक्रिया नहीं देगा। यह कोई बढ़िया एहसास नहीं है, लेकिन इससे आपको हतोत्साहित न होने दें। यह हर किसी के साथ हुआ है! आपको प्रतिक्रिया न मिलने के कई संभावित कारण हो सकते हैं, जिनमें व्यक्तिगत परिस्थितियाँ भी शामिल हैं जो आपके नियंत्रण से बाहर हो सकती हैं। योगदान देने के लिए कोई अन्य प्रोजेक्ट या तरीका खोजने का प्रयास करें। यदि कुछ भी हो, तो यह एक अच्छा कारण है कि समुदाय के अन्य सदस्यों के शामिल होने और प्रतिक्रिया देने से पहले योगदान देने में बहुत अधिक समय न लगाया जाए।
 
-### 🚧 Someone requests changes to your contribution.
+### 🚧 कोई आपके योगदान में परिवर्तन का अनुरोध करता है।
 
-It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+यह सामान्य बात है कि आपसे आपके योगदान में परिवर्तन करने के लिए कहा जाएगा, चाहे वह आपके विचार के दायरे पर प्रतिक्रिया हो, या आपके कोड में परिवर्तन हो।
 
-When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it.
+जब कोई परिवर्तन का अनुरोध करता है, तो उत्तरदायी बनें। उन्होंने आपके योगदान की समीक्षा करने के लिए समय लिया है। पीआर खोलना और चले जाना बुरी आदत है। यदि आप नहीं जानते कि परिवर्तन कैसे करें, तो समस्या पर शोध करें और यदि आपको सहायता की आवश्यकता हो तो सहायता माँगें।
 
-If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
+यदि आपके पास अब इस मुद्दे पर काम करने का समय नहीं है (उदाहरण के लिए, यदि बातचीत महीनों से चल रही है, और आपकी परिस्थितियाँ बदल गई हैं), तो अनुरक्षक को बताएं ताकि वे प्रतिक्रिया की उम्मीद न करें। कोई अन्य व्यक्ति कार्यभार संभालने में प्रसन्न हो सकता है।
 
-### 👎 Your contribution doesn't get accepted.
+### 👎 आपका योगदान स्वीकार नहीं किया जाता।
 
-Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+आपका योगदान अंततः स्वीकार किया भी जा सकता है और नहीं भी। उम्मीद है कि आपने पहले से ही इसमें बहुत अधिक काम नहीं किया होगा। यदि आप निश्चित नहीं हैं कि इसे क्यों स्वीकार नहीं किया गया, तो अनुरक्षक से फीडबैक और स्पष्टीकरण मांगना बिल्कुल उचित है। हालाँकि, अंततः, आपको इसका सम्मान करना होगा कि यह उनका निर्णय है। बहस न करें या शत्रुतापूर्ण न बनें। यदि आप असहमत हैं तो फोर्क और अपने संस्करण पर काम करने के लिए आपका हमेशा स्वागत है!
 
-### 🎉 Your contribution gets accepted.
+### 🎉 आपका योगदान स्वीकार किया जाता है।
 
-Hooray! You've successfully made an open source contribution!
+हुर्रे! आपने सफलतापूर्वक ओपन सोर्स योगदान दे दिया है!
 
-## You did it!
+## तुमने यह किया!
 
-Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
+चाहे आपने अभी अपना पहला ओपन सोर्स योगदान दिया हो, या आप योगदान करने के नए तरीकों की तलाश कर रहे हों, हमें उम्मीद है कि आप कार्रवाई करने के लिए प्रेरित होंगे। भले ही आपका योगदान स्वीकार नहीं किया गया हो, जब कोई अनुरक्षक आपकी मदद करने का प्रयास करे तो धन्यवाद कहना न भूलें। ओपन सोर्स आपके जैसे लोगों द्वारा बनाया गया है: एक समय में एक मुद्दा, पुल अनुरोध, टिप्पणी, या हाई-फाइव।

From d0bf0bdb8e4e6e56dea5af56a1b62608c76523d5 Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Fri, 1 Sep 2023 14:40:10 +0530
Subject: [PATCH 485/749] Hindi translation commit

---
 _articles/hi/best-practices.md     |  3 ---
 _articles/hi/building-community.md |  7 +++----
 _articles/hi/getting-paid.md       |  4 ++--
 _articles/hi/how-to-contribute.md  | 18 +++++++++++++++---
 _articles/hi/starting-a-project.md |  1 +
 5 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/_articles/hi/best-practices.md b/_articles/hi/best-practices.md
index 1613e0d2809..ea8c4047765 100644
--- a/_articles/hi/best-practices.md
+++ b/_articles/hi/best-practices.md
@@ -18,8 +18,6 @@ related:
 
 परियोजना को संभालने के लिए कोड से ज्यादा की आवश्यकता होती है। ये कार्य अक्सर अप्रत्याशित होते हैं, लेकिन एक बढ़ती हुई परियोजना के लिए ये उतने ही महत्वपूर्ण होते हैं। हमने कुछ तरीके जुटाए हैं जो आपके जीवन को आसान बनाने में मदद करेंगे, प्रक्रियाओं की दस्तावेजीकरण से लेकर आपकी समुदाय का उपयोग करने तक।
 
-
-
 ## प्रक्रियाओं की दस्तावेजीकरण
 
 चीजों को लिखना मेंटेनर के रूप में आपकी सबसे महत्वपूर्ण चीजों में से एक है।
@@ -40,7 +38,6 @@ related:
 
 उदाहरण के लिए, @lord ने यह जानकर पाया कि परियोजना की दृष्टि रखने से उसने यह तय किया कि किन अनुरोधों पर समय खर्च करना चाहिए। एक नए मेंटेनर के रूप में, उसने खेद किया कि उसने अपनी परियोजना की दिशा को न अपनाकर अपने पहले विशेषता अनुरोध के लिए [Slate](https://github.com/lord/slate) को मान्यता दी।
 
-
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
   मैंने इसे गलती से किया। मैंने किसी पूर्ण समाधान को लाने के लिए प्रयास नहीं किया। आधे-पूरे समाधान की जगह, मुझे खेद है कि मैंने यह नहीं कहा "मेरे पास इसके लिए अभी समय नहीं है, लेकिन मैं इसे दीर्घकालिक सूची में जोड़ दूंगा जिसे हमारे लिए अच्छा हो सकता है।"
diff --git a/_articles/hi/building-community.md b/_articles/hi/building-community.md
index 25309ad6f28..b26d807f300 100644
--- a/_articles/hi/building-community.md
+++ b/_articles/hi/building-community.md
@@ -18,7 +18,7 @@ related:
 
 ### लोगों को स्वागत का एहसास कराएं
 
-आपके प्रोजेक्ट के समुदाय के बारे में सोचने का एक तरीका यह है कि @MikeMcQuaid इसे [योगदानकर्ता फ़नल] कहता है(https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+आपके प्रोजेक्ट के समुदाय के बारे में सोचने का एक तरीका यह है कि @MikeMcQuaid इसे [योगदानकर्ता फ़नल](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) कहता है:
 
 ![योगदानकर्ता फ़नल](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
 
@@ -80,7 +80,7 @@ related:
 
 जब कोई व्यक्ति कोई समस्या दर्ज करता है, पुल अनुरोध सबमिट करता है, या आपके प्रोजेक्ट के बारे में कोई प्रश्न पूछता है तो प्रतिक्रियाशील बनने का प्रयास करें। जब आप तुरंत प्रतिक्रिया देते हैं, तो लोगों को लगेगा कि वे एक संवाद का हिस्सा हैं, और वे भाग लेने के लिए अधिक उत्साहित होंगे।
 
-भले ही आप तुरंत अनुरोध की समीक्षा नहीं कर सकते, लेकिन इसे जल्दी स्वीकार करने से जुड़ाव बढ़ाने में मदद मिलती है। यहां बताया गया है कि @tdreyno ने [मिडिलमैन] पर पुल अनुरोध का जवाब कैसे दिया(https://github.com/middleman/middleman/pull/1466):
+भले ही आप तुरंत अनुरोध की समीक्षा नहीं कर सकते, लेकिन इसे जल्दी स्वीकार करने से जुड़ाव बढ़ाने में मदद मिलती है। यहां बताया गया है कि @tdreyno ने [मिडिलमैन](https://github.com/middleman/middleman/pull/1466) पर पुल अनुरोध का जवाब कैसे दिया:
 
 ![बिचौलिए का अनुरोध](/assets/images/building-community/middleman_pr.png)
 
@@ -101,7 +101,7 @@ related:
 
 > कोप्स के पास समुदाय को सहायता और मार्गदर्शन प्रदान करने के लिए हर दूसरे सप्ताह का समय भी निर्धारित होता है। कोप्स अनुरक्षकों ने नवागंतुकों के साथ काम करने, पीआर के साथ मदद करने और नई सुविधाओं पर चर्चा करने के लिए विशेष रूप से समर्पित समय निर्धारित करने पर सहमति व्यक्त की है।
 
-सार्वजनिक संचार के उल्लेखनीय अपवाद हैं: 1) सुरक्षा मुद्दे और 2) संवेदनशील आचार संहिता का उल्लंघन। आपके पास लोगों के लिए इन मुद्दों की निजी तौर पर रिपोर्ट करने का हमेशा एक तरीका होना चाहिए। यदि आप अपने व्यक्तिगत ईमेल का उपयोग नहीं करना चाहते हैं, तो एक समर्पित ईमेल पता सेट करें।
+सार्वजनिक संचार के उल्लेखनीय अपवाद हैं: 1. सुरक्षा मुद्दे और 2. संवेदनशील आचार संहिता का उल्लंघन। आपके पास लोगों के लिए इन मुद्दों की निजी तौर पर रिपोर्ट करने का हमेशा एक तरीका होना चाहिए। यदि आप अपने व्यक्तिगत ईमेल का उपयोग नहीं करना चाहते हैं, तो एक समर्पित ईमेल पता सेट करें।
 
 ## अपने समुदाय को बढ़ाना
 
@@ -113,7 +113,6 @@ related:
 
 इस प्रकार के लोगों के प्रति शून्य-सहिष्णुता की नीति अपनाने की पूरी कोशिश करें। यदि अनियंत्रित छोड़ दिया जाए, तो नकारात्मक लोग आपके समुदाय के अन्य लोगों को असहज कर देंगे। वे चले भी सकते हैं.
 
-
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
   सच तो यह है कि एक सहायक समुदाय का होना महत्वपूर्ण है। मैं अपने सहकर्मियों, मित्रवत इंटरनेट अजनबियों और बातूनी आईआरसी चैनलों की मदद के बिना यह काम कभी नहीं कर पाऊंगा। (...) इससे कम पर समझौता न करें। बेवकूफों के लिए समझौता मत करो.
diff --git a/_articles/hi/getting-paid.md b/_articles/hi/getting-paid.md
index c0aaf21f9d4..357b3497603 100644
--- a/_articles/hi/getting-paid.md
+++ b/_articles/hi/getting-paid.md
@@ -87,8 +87,8 @@ OSS प्रौद्योगिकी उद्योग को बड़े
 
 यदि आप अपने वर्तमान नियोक्ता को ओपन सोर्स कार्य को प्राथमिकता देने के लिए मना नहीं सकते हैं, तो एक नया नियोक्ता ढूंढने पर विचार करें जो ओपन सोर्स में कर्मचारी योगदान को प्रोत्साहित करता हो। ऐसी कंपनियों की तलाश करें जो ओपन सोर्स कार्य के प्रति अपना समर्पण स्पष्ट करती हों। उदाहरण के लिए:
 
-*कुछ कंपनियाँ, जैसे [Netflix](https://netflix.github.io/) या [PayPal](https://paypal.github.io/), के पास ऐसी वेबसाइटें हैं जो ओपन सोर्स में उनकी भागीदारी को उजागर करती हैं
-* [Zalando](https://opensource.zalando.com) [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) कर्मचारियों के लिए इसका प्रकाशन किया।
+*कुछ कंपनियाँ, जैसे [Netflix](https://netflix.github.io/) या [PayPal](https://paypal.github.io/), के पास ऐसी वेबसाइटें हैं जो ओपन सोर्स में उनकी भागीदारी को उजागर करती हैं।
+* [Zalando](https://opensource.zalando.com) ने [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) उनके कर्मचारियों के लिए प्रकाशन किया।
 
 ऐसी परियोजनाएँ जो किसी बड़ी कंपनी में उत्पन्न हुईं, जैसे [Go](https://github.com/golang) या [React](https://github.com/facebook/react), ओपन सोर्स पर काम करने के लिए लोगों को नियोजित करने की भी संभावना है।
 
diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md
index 72795bed162..9f39991dd68 100644
--- a/_articles/hi/how-to-contribute.md
+++ b/_articles/hi/how-to-contribute.md
@@ -181,21 +181,33 @@ related:
 अंत में, ओपन सोर्स प्रोजेक्ट चर्चा को व्यवस्थित करने के लिए निम्नलिखित टूल का उपयोग करते हैं। अभिलेखों को पढ़ने से आपको एक अच्छी तस्वीर मिलेगी कि समुदाय कैसे सोचता है और कैसे काम करता है।
 
 * **समस्या ट्रैकर:** जहां लोग परियोजना से संबंधित मुद्दों पर चर्चा करते हैं।
-* **पुल अनुरोध:** जहां लोग प्रगति पर चल रहे परिवर्तनों पर चर्चा और समीक्षा करते हैं।
+* **पुल रीकवेस्ट:** जहां लोग प्रगति पर चल रहे परिवर्तनों पर चर्चा और समीक्षा करते हैं।
 * **चर्चा फ़ोरम या मेलिंग सूचियाँ:** कुछ परियोजनाएँ इन चैनलों का उपयोग वार्तालाप विषयों के लिए कर सकती हैं (उदाहरण के लिए, _"मैं कैसे करूँ..."_ या _"आप किस बारे में सोचते हैं..."_ बग के बजाय रिपोर्ट या सुविधा अनुरोध)। अन्य सभी वार्तालापों के लिए समस्या ट्रैकर का उपयोग करते हैं।
 * **सिंक्रोनस चैट चैनल:** कुछ प्रोजेक्ट आकस्मिक बातचीत, सहयोग और त्वरित आदान-प्रदान के लिए चैट चैनल (जैसे स्लैक या आईआरसी) का उपयोग करते हैं।
 
 ## योगदान देने के लिए एक परियोजना ढूँढना
 
-अंत में, ओपन सोर्स प्रोजेक्ट चर्चा को व्यवस्थित करने के लिए निम्नलिखित टूल का उपयोग करते हैं। अभिलेखों को पढ़ने से आपको एक अच्छी तस्वीर मिलेगी कि समुदाय कैसे सोचता है और कैसे काम करता है।
+अंत में, ओपन सोर्स प्रोजेक्ट चर्चा को व्यवस्थित करने के लिए निम्नलिखित टूल का उपयोग करते हैं। अभिलेखों को पढ़ने से आपको एक अच्छी तस्वीर मिलेगी कि समुदाय कैसे सोरीकवेस्टचता है और कैसे काम करता है।
 
 * **समस्या ट्रैकर:** जहां लोग परियोजना से संबंधित मुद्दों पर चर्चा करते हैं।
-* **पुल अनुरोध:** जहां लोग प्रगति पर चल रहे परिवर्तनों पर चर्चा और समीक्षा करते हैं।
+* **पुल रीकवेस्ट:** जहां लोग प्रगति पर चल रहे परिवर्तनों पर चर्चा और समीक्षा करते हैं।
 * **चर्चा फ़ोरम या मेलिंग सूचियाँ:** कुछ परियोजनाएँ इन चैनलों का उपयोग वार्तालाप विषयों के लिए कर सकती हैं (उदाहरण के लिए, _"मैं कैसे करूँ..."_ या _"आप किस बारे में सोचते हैं..."_ बग के बजाय रिपोर्ट या सुविधा अनुरोध)। अन्य सभी वार्तालापों के लिए समस्या ट्रैकर का उपयोग करते हैं।
 * **सिंक्रोनस चैट चैनल:** कुछ प्रोजेक्ट आकस्मिक बातचीत, सहयोग और त्वरित आदान-प्रदान के लिए चैट चैनल (जैसे स्लैक या आईआरसी) का उपयोग करते हैं।
 
 ## योगदान देने के लिए एक परियोजना ढूँढना
 
+अब जब आपको पता चल गया है कि ओपन सोर्स प्रोजेक्ट कैसे काम करते हैं, तो योगदान देने के लिए एक प्रोजेक्ट ढूंढने का समय आ गया है!
+
+यदि आपने पहले कभी भी ओपन सोर्स में योगदान नहीं दिया है, तो अमेरिकी राष्ट्रपति जॉन एफ कैनेडी से कुछ सलाह लें, जिन्होंने एक बार कहा था, _"यह मत पूछो कि आपका देश आपके लिए क्या कर सकता है - यह पूछें कि आप अपने देश के लिए क्या कर सकते हैं।"_
+
+ओपन सोर्स में योगदान सभी स्तरों पर, सभी परियोजनाओं में होता है। आपको यह ज़्यादा सोचने की ज़रूरत नहीं है कि वास्तव में आपका पहला योगदान क्या होगा, या यह कैसा दिखेगा।
+
+इसके बजाय, उन परियोजनाओं के बारे में सोचकर शुरुआत करें जिनका आप पहले से उपयोग कर रहे हैं, या जिनका उपयोग करना चाहते हैं। जिन परियोजनाओं में आप सक्रिय रूप से योगदान देंगे, उन्हीं परियोजनाओं में आप स्वयं को वापस आते हुए पाएंगे।
+
+उन परियोजनाओं के भीतर, जब भी आप खुद को यह सोचते हुए पाते हैं कि कुछ बेहतर या अलग हो सकता है, तो अपनी प्रवृत्ति पर कार्य करें।
+
+ओपन सोर्स कोई विशेष क्लब नहीं है; यह आप जैसे ही लोगों द्वारा बनाया गया है। "ओपन सोर्स" दुनिया की समस्याओं को ठीक करने योग्य मानने के लिए सिर्फ एक फैंसी शब्द है।
+
 आप README को स्कैन कर सकते हैं और एक टूटा हुआ लिंक या कोई टाइपो पा सकते हैं। या आप एक नए उपयोगकर्ता हैं और आपने देखा कि कुछ टूटा हुआ है, या कोई समस्या है जो आपको लगता है कि वास्तव में दस्तावेज़ में होनी चाहिए। इसे नज़रअंदाज़ करने और आगे बढ़ने, या किसी और से इसे ठीक करने के लिए कहने के बजाय, देखें कि क्या आप इसमें योगदान देकर मदद कर सकते हैं। खुले स्रोत का यही मतलब है!
 
 > [28% आकस्मिक योगदान](https://www.igor.pro.br/publica/papers/saner2016.pdf) ओपन सोर्स के लिए दस्तावेज हैं, जैसे टाइपो फिक्स, रिफॉर्मेटिंग, या अनुवाद लिखना।
diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md
index 671117cc326..f3dfe0c02b7 100644
--- a/_articles/hi/starting-a-project.md
+++ b/_articles/hi/starting-a-project.md
@@ -43,6 +43,7 @@ _मुफ़्त सॉफ़्टवेयर_ परियोजनाओ
 ओपन सोर्स सिर्फ सॉफ्टवेयर के लिए ही नहीं है। आप डेटा सेट से लेकर किताबों तक सब कुछ ओपन सोर्स कर सकते हैं। आप और क्या स्रोत खोल सकते हैं, इस बारे में विचारों के लिए [गिटहब एक्सप्लोर](https://github.com/explore) देखें।
 
 ### क्या ओपन सोर्स का मतलब "निःशुल्क" है?
+
 ओपन सोर्स का सबसे बड़ा आकर्षण यह है कि इसमें पैसा खर्च नहीं होता है। हालाँकि, "निःशुल्क", खुले स्रोत के समग्र मूल्य का एक उपोत्पाद है।
 
 क्योंकि [एक ओपन सोर्स लाइसेंस के लिए आवश्यक है](https://opensource.org/osd-annotated) कि कोई भी आपके प्रोजेक्ट को लगभग किसी भी उद्देश्य के लिए उपयोग, संशोधित और साझा कर सकता है, प्रोजेक्ट स्वयं निःशुल्क होते हैं। यदि प्रोजेक्ट के उपयोग में पैसे खर्च होते हैं, तो कोई भी कानूनी तौर पर इसकी प्रतिलिपि बना सकता है और इसके बजाय मुफ़्त संस्करण का उपयोग कर सकता है।

From 98c00269d087449bf23175758a7e96afe594ca42 Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Fri, 1 Sep 2023 14:54:09 +0530
Subject: [PATCH 486/749] Hindi updated commit

---
 _articles/hi/how-to-contribute.md  | 9 ---------
 _articles/hi/starting-a-project.md | 2 +-
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md
index 9f39991dd68..d345f07f8c9 100644
--- a/_articles/hi/how-to-contribute.md
+++ b/_articles/hi/how-to-contribute.md
@@ -187,15 +187,6 @@ related:
 
 ## योगदान देने के लिए एक परियोजना ढूँढना
 
-अंत में, ओपन सोर्स प्रोजेक्ट चर्चा को व्यवस्थित करने के लिए निम्नलिखित टूल का उपयोग करते हैं। अभिलेखों को पढ़ने से आपको एक अच्छी तस्वीर मिलेगी कि समुदाय कैसे सोरीकवेस्टचता है और कैसे काम करता है।
-
-* **समस्या ट्रैकर:** जहां लोग परियोजना से संबंधित मुद्दों पर चर्चा करते हैं।
-* **पुल रीकवेस्ट:** जहां लोग प्रगति पर चल रहे परिवर्तनों पर चर्चा और समीक्षा करते हैं।
-* **चर्चा फ़ोरम या मेलिंग सूचियाँ:** कुछ परियोजनाएँ इन चैनलों का उपयोग वार्तालाप विषयों के लिए कर सकती हैं (उदाहरण के लिए, _"मैं कैसे करूँ..."_ या _"आप किस बारे में सोचते हैं..."_ बग के बजाय रिपोर्ट या सुविधा अनुरोध)। अन्य सभी वार्तालापों के लिए समस्या ट्रैकर का उपयोग करते हैं।
-* **सिंक्रोनस चैट चैनल:** कुछ प्रोजेक्ट आकस्मिक बातचीत, सहयोग और त्वरित आदान-प्रदान के लिए चैट चैनल (जैसे स्लैक या आईआरसी) का उपयोग करते हैं।
-
-## योगदान देने के लिए एक परियोजना ढूँढना
-
 अब जब आपको पता चल गया है कि ओपन सोर्स प्रोजेक्ट कैसे काम करते हैं, तो योगदान देने के लिए एक प्रोजेक्ट ढूंढने का समय आ गया है!
 
 यदि आपने पहले कभी भी ओपन सोर्स में योगदान नहीं दिया है, तो अमेरिकी राष्ट्रपति जॉन एफ कैनेडी से कुछ सलाह लें, जिन्होंने एक बार कहा था, _"यह मत पूछो कि आपका देश आपके लिए क्या कर सकता है - यह पूछें कि आप अपने देश के लिए क्या कर सकते हैं।"_
diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md
index f3dfe0c02b7..df1890cf721 100644
--- a/_articles/hi/starting-a-project.md
+++ b/_articles/hi/starting-a-project.md
@@ -174,7 +174,7 @@ READMEs आपके प्रोजेक्ट का उपयोग कै
 
 उदाहरण के लिए, [सक्रिय व्यवस्थापक](https://github.com/activeadmin/activeadmin/) प्रारंभ होता है [इसकी योगदान मार्गदर्शिका](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) के साथ:
 
->सबसे पहले, सक्रिय व्यवस्थापक में योगदान देने पर विचार करने के लिए धन्यवाद। यह आप जैसे लोग ही हैं जो एक्टिव एडमिन को इतना बढ़िया टूल बनाते हैं।
+> सबसे पहले, सक्रिय व्यवस्थापक में योगदान देने पर विचार करने के लिए धन्यवाद। यह आप जैसे लोग ही हैं जो एक्टिव एडमिन को इतना बढ़िया टूल बनाते हैं।
 
 आपके प्रोजेक्ट के शुरुआती चरणों में, आपकी CONTRIBUTING फ़ाइल सरल हो सकती है। योगदान देने के लिए आपको हमेशा यह समझाना चाहिए कि बग या फ़ाइल समस्याओं की रिपोर्ट कैसे करें, और कोई तकनीकी आवश्यकताएं (जैसे परीक्षण) कैसे करें।
 

From a9161b2d25ce0b82fec66ff111958e62c0804503 Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Fri, 1 Sep 2023 15:02:11 +0530
Subject: [PATCH 487/749] Hindi updated commit

---
 _articles/hi/code-of-conduct.md | 4 ++--
 _articles/hi/getting-paid.md    | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/hi/code-of-conduct.md b/_articles/hi/code-of-conduct.md
index bd1c46ae7a0..53f610b2b2a 100644
--- a/_articles/hi/code-of-conduct.md
+++ b/_articles/hi/code-of-conduct.md
@@ -24,8 +24,8 @@ related:
 
 आपकी अपेक्षाओं को संप्रेषित करने के अलावा, आचार संहिता निम्नलिखित का वर्णन करती है:
 
-* जहां आचार संहिता प्रभावी होती है _(केवल मुद्दों और पुल अनुरोधों, या घटनाओं जैसी सामुदायिक गतिविधियों पर?)_
-*आचार संहिता किस पर लागू होती है _(समुदाय के सदस्यों और अनुरक्षकों पर, लेकिन प्रायोजकों के बारे में क्या?)_
+* जहां आचार संहिता प्रभावी होती है `_`(केवल मुद्दों और पुल अनुरोधों, या घटनाओं जैसी सामुदायिक गतिविधियों पर?)`_`
+*आचार संहिता किस पर लागू होती है `_`(समुदाय के सदस्यों और अनुरक्षकों पर, लेकिन प्रायोजकों के बारे में क्या?)`_`
 *यदि कोई आचार संहिता का उल्लंघन करता है तो क्या होगा
 * कोई कैसे उल्लंघन की रिपोर्ट कर सकता है
 
diff --git a/_articles/hi/getting-paid.md b/_articles/hi/getting-paid.md
index 357b3497603..6f17b5c6015 100644
--- a/_articles/hi/getting-paid.md
+++ b/_articles/hi/getting-paid.md
@@ -88,7 +88,7 @@ OSS प्रौद्योगिकी उद्योग को बड़े
 यदि आप अपने वर्तमान नियोक्ता को ओपन सोर्स कार्य को प्राथमिकता देने के लिए मना नहीं सकते हैं, तो एक नया नियोक्ता ढूंढने पर विचार करें जो ओपन सोर्स में कर्मचारी योगदान को प्रोत्साहित करता हो। ऐसी कंपनियों की तलाश करें जो ओपन सोर्स कार्य के प्रति अपना समर्पण स्पष्ट करती हों। उदाहरण के लिए:
 
 *कुछ कंपनियाँ, जैसे [Netflix](https://netflix.github.io/) या [PayPal](https://paypal.github.io/), के पास ऐसी वेबसाइटें हैं जो ओपन सोर्स में उनकी भागीदारी को उजागर करती हैं।
-* [Zalando](https://opensource.zalando.com) ने [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) उनके कर्मचारियों के लिए प्रकाशन किया।
+*[Zalando](https://opensource.zalando.com) ने [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) उनके कर्मचारियों के लिए प्रकाशन किया।
 
 ऐसी परियोजनाएँ जो किसी बड़ी कंपनी में उत्पन्न हुईं, जैसे [Go](https://github.com/golang) या [React](https://github.com/facebook/react), ओपन सोर्स पर काम करने के लिए लोगों को नियोजित करने की भी संभावना है।
 

From ad1c2de3947863367ec50feb02ecf80edb83f205 Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Sat, 2 Sep 2023 09:43:15 +0530
Subject: [PATCH 488/749] Hindi internal links update

---
 _articles/hi/best-practices.md            |   8 +-
 _articles/hi/building-community.md        |  14 +-
 _articles/hi/code-of-conduct.md           |   4 +-
 _articles/hi/getting-paid.md              |   4 +-
 _articles/hi/leadership-and-governance.md |   4 +-
 _articles/hi/legal.md                     |   4 +-
 _articles/hi/starting-a-project.md        |   2 +-
 node_modules/.package-lock.json           | 240 ++++++++++++++++++++++
 8 files changed, 260 insertions(+), 20 deletions(-)
 create mode 100644 node_modules/.package-lock.json

diff --git a/_articles/hi/best-practices.md b/_articles/hi/best-practices.md
index ea8c4047765..db31c75bfe7 100644
--- a/_articles/hi/best-practices.md
+++ b/_articles/hi/best-practices.md
@@ -150,7 +150,7 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user
   </p>
 </aside>
 
-कभी-कभी, जब आप ना कहते हैं, तो आपका संभावित योगदानकर्ता परेशान हो सकता है या आपके निर्णय की आलोचना कर सकता है। यदि उनका व्यवहार शत्रुतापूर्ण हो जाए, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) या यदि वे रचनात्मक रूप से सहयोग करने के इच्छुक नहीं हैं, तो उन्हें अपने समुदाय से हटा भी दें।
+कभी-कभी, जब आप ना कहते हैं, तो आपका संभावित योगदानकर्ता परेशान हो सकता है या आपके निर्णय की आलोचना कर सकता है। यदि उनका व्यवहार शत्रुतापूर्ण हो जाए, [स्थिति को शांत करने के लिए कदम उठाएं](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) या यदि वे रचनात्मक रूप से सहयोग करने के इच्छुक नहीं हैं, तो उन्हें अपने समुदाय से हटा भी दें।
 
 ### मार्गदर्शन को गले लगाओ
 
@@ -166,11 +166,11 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user
 
 यदि आप मदद के लिए दूसरों की तलाश कर रहे हैं, तो आसपास पूछकर शुरुआत करें।
 
-नए योगदानकर्ताओं को प्राप्त करने का एक तरीका स्पष्ट रूप से है [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 इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर प्रदर्शित करेगा, जिससे उनकी दृश्यता बढ़ेगी।
+नए योगदानकर्ताओं को प्राप्त करने का एक तरीका स्पष्ट रूप से है [ऐसे लेबल मुद्दे जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर प्रदर्शित करेगा, जिससे उनकी दृश्यता बढ़ेगी।
 
 जब आप नए योगदानकर्ताओं को बार-बार योगदान करते हुए देखें, तो अधिक जिम्मेदारी देकर उनके काम को पहचानें। दस्तावेज़ बनाएं कि यदि अन्य लोग चाहें तो नेतृत्व की भूमिका में कैसे विकसित हो सकते हैं।
 
-दूसरों को इसके लिए प्रोत्साहित करना[share ownership of the project](../building-community/#share-ownership-of-your-project) आपके स्वयं के कार्यभार को बहुत कम कर सकता है, जैसा कि @lmccart ने अपने प्रोजेक्ट पर पाया, [p5.js](https://github.com/processing/p5.js).
+दूसरों को इसके लिए प्रोत्साहित करना [अपने प्रोजेक्ट का स्वामित्व साझा करें](../building-community/#अपने-प्रोजेक्ट-का-स्वामित्व-साझा-करें) आपके स्वयं के कार्यभार को बहुत कम कर सकता है, जैसा कि @lmccart ने अपने प्रोजेक्ट पर पाया, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
@@ -184,7 +184,7 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user
 
 यदि अन्य लोग इसकी दिशा को लेकर उत्साहित हैं, तो उन्हें प्रतिबद्ध पहुंच प्रदान करें या औपचारिक रूप से नियंत्रण किसी और को सौंप दें। यदि किसी ने आपके प्रोजेक्ट को फोर्क किया है और इसे कहीं और सक्रिय रूप से बनाए रख रहा है, तो अपने मूल प्रोजेक्ट से फोर्क को जोड़ने पर विचार करें। यह बहुत अच्छा है कि इतने सारे लोग चाहते हैं कि आपका प्रोजेक्ट चालू रहे!
 
-@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) अपने प्रोजेक्ट, [डोक्कू](https://github.com/dokku/dokku) के लिए विज़न का दस्तावेजीकरण करने से, प्रोजेक्ट से दूर जाने के बाद भी उन लक्ष्यों को जीवित रखने में मदद मिली:
+@progrium [ने पाया कि](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) अपने प्रोजेक्ट, [Dokku](https://github.com/dokku/dokku) के लिए विज़न का दस्तावेजीकरण करने से, प्रोजेक्ट से जाने के बाद भी उन लक्ष्यों को जीवित रखने में मदद मिली:
 
 > मैंने एक विकी पेज लिखा जिसमें बताया गया कि मैं क्या चाहता था और मैं यह क्यों चाहता था। किसी कारण से यह मेरे लिए आश्चर्य की बात थी कि अनुरक्षकों ने परियोजना को उस दिशा में आगे बढ़ाना शुरू कर दिया! क्या यह बिल्कुल वैसा ही हुआ जैसा मैंने इसे किया था? हमेशा नहीं। लेकिन फिर भी यह परियोजना को मैंने जो लिखा था उसके करीब ले आया।
 
diff --git a/_articles/hi/building-community.md b/_articles/hi/building-community.md
index b26d807f300..1e271fca4c1 100644
--- a/_articles/hi/building-community.md
+++ b/_articles/hi/building-community.md
@@ -26,17 +26,17 @@ related:
 
 अपने दस्तावेज़ से प्रारंभ करें:
 
-* **किसी के लिए आपके प्रोजेक्ट का उपयोग करना आसान बनाएं।** [मैत्रीपूर्णREADME](../starting-a-project/#writing-a-readme) 
+* **किसी के लिए आपके प्रोजेक्ट का उपयोग करना आसान बनाएं।** [एक मैत्रीपूर्ण README लिखना](../starting-a-project/#एक-README-लिखना) 
 और स्पष्ट कोड उदाहरण आपके प्रोजेक्ट पर आने वाले किसी भी व्यक्ति के लिए आरंभ करना आसान बना देंगे।  
-* **स्पष्ट रूप से बताएं कि योगदान कैसे करना है**, आपकी [योगदान CONTRIBUTING फ़ाइल  का उपयोग करके](../starting-a-project/#writing-your-contributing-guidelines) और अपने मुद्दों को अद्यतन रखते हुए।
+* **स्पष्ट रूप से बताएं कि योगदान कैसे करना है**, आपकी [योगदान CONTRIBUTING फ़ाइल का उपयोग करके](../starting-a-project/#अपने-योगदान-संबंधी-दिशानिर्देश-लिखना) और अपने मुद्दों को अद्यतन रखते हुए।
 * **अच्छे प्रथम अंक**: नए योगदानकर्ताओं को आरंभ करने में मदद करने के लिए, स्पष्ट रूप से विचार करें [उन मुद्दों को लेबल करना जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर सामने लाएगा, उपयोगी योगदान बढ़ाएगा, और उन मुद्दों से निपटने वाले उपयोगकर्ताओं के मनमुटाव को कम करेगा जो उनके स्तर के लिए बहुत कठिन हैं।
 
 [GitHub का 2017 ओपन सोर्स सर्वेक्षण](http://opensourcesurvey.org/2017/) अपूर्ण या भ्रमित करने वाला दस्तावेज़ दिखाना ओपन सोर्स उपयोगकर्ताओं के लिए सबसे बड़ी समस्या है। अच्छा दस्तावेज़ीकरण लोगों को आपके प्रोजेक्ट के साथ बातचीत करने के लिए आमंत्रित करता है। अंततः, कोई व्यक्ति कोई समस्या खोलेगा या अनुरोध खींच लेगा। इन इंटरैक्शन को फ़नल से नीचे ले जाने के अवसर के रूप में उपयोग करें।
 
 * **जब कोई नया व्यक्ति आपके प्रोजेक्ट पर आता है, तो उनकी रुचि के लिए उन्हें धन्यवाद दें!** किसी को वापस आने से रोकने के लिए केवल एक नकारात्मक अनुभव की आवश्यकता होती है।
 * **उत्तरदायी बनें।** यदि आप एक महीने तक उनके मुद्दे पर प्रतिक्रिया नहीं देते हैं, तो संभावना है कि वे पहले ही आपके प्रोजेक्ट के बारे में भूल चुके होंगे।
-* **आप जिस प्रकार के योगदान स्वीकार करेंगे, उसके बारे में खुले दिमाग से काम करें।** कई योगदानकर्ता बग रिपोर्ट या छोटे सुधार के साथ शुरुआत करते हैं। वहाँ हैं[योगदान करने के कई तरीके](../how-to-contribute/#what-it-means-to-contribute) एक परियोजना के लिए. लोग जिस तरह से मदद करना चाहते हैं, उन्हें मदद करने दें।
-* **यदि कोई योगदान है जिससे आप असहमत हैं,** उनके विचार के लिए उन्हें धन्यवाद दें और [समझाइए क्यों](../best-practices/#learning-to-say-no) यह परियोजना के दायरे में फिट नहीं बैठता है, यदि आपके पास प्रासंगिक दस्तावेज हैं तो इसे लिंक करें।
+* **आप जिस प्रकार के योगदान स्वीकार करेंगे, उसके बारे में खुले दिमाग से काम करें।** कई योगदानकर्ता बग रिपोर्ट या छोटे सुधार के साथ शुरुआत करते हैं। [योगदान करने के कई तरीके](../how-to-contribute/#योगदान-देने-का-क्या-मतलब-है) हैं। लोग जिस तरह से मदद करना चाहते हैं, उन्हें मदद करने दें।
+* **यदि कोई योगदान है जिससे आप असहमत हैं,** उनके विचार के लिए उन्हें धन्यवाद दें और [समझाइए क्यों](../best-practices/#ना-कहना-सीखना) यह परियोजना के दायरे में फिट नहीं बैठता है, यदि आपके पास प्रासंगिक दस्तावेज हैं तो इसे लिंक करें।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -123,7 +123,7 @@ related:
 
 आपके प्रोजेक्ट के तुच्छ पहलुओं पर नियमित बहस आपके सहित दूसरों को महत्वपूर्ण कार्यों पर ध्यान केंद्रित करने से विचलित करती है। आपके प्रोजेक्ट में आने वाले नए लोग इन वार्तालापों को देख सकते हैं और भाग नहीं लेना चाहेंगे।
 
-जब आप अपने प्रोजेक्ट पर नकारात्मक व्यवहार होते देखें, तो उसे सार्वजनिक रूप से बताएं। दयालु लेकिन दृढ़ स्वर में बताएं कि उनका व्यवहार स्वीकार्य क्यों नहीं है। यदि समस्या बनी रहती है, तो आपको इसकी आवश्यकता हो सकती है [उन्हें जाने के लिए कहो](../code-of-conduct/#enforcing-your-code-of-conduct). Your [आचार संहिता](../code-of-conduct/) इन वार्तालापों के लिए एक रचनात्मक मार्गदर्शक हो सकता है।
+जब आप अपने प्रोजेक्ट पर नकारात्मक व्यवहार होते देखें, तो उसे सार्वजनिक रूप से बताएं। दयालु लेकिन दृढ़ स्वर में बताएं कि उनका व्यवहार स्वीकार्य क्यों नहीं है। यदि समस्या बनी रहती है, तो आपको इसकी आवश्यकता हो सकती है [उन्हें जाने के लिए कहो](../code-of-conduct/#अपनी-आचार-संहिता-लागू-करना). आपके [आचार संहिता](../code-of-conduct/) इन वार्तालापों के लिए एक रचनात्मक मार्गदर्शक हो सकता है।
 
 ### योगदानकर्ताओं से वहीं मिलें जहां वे हैं
 
@@ -194,7 +194,7 @@ related:
 
 जब आपका समुदाय किसी कठिन मुद्दे से जूझ रहा हो, तो गुस्सा बढ़ सकता है। लोग क्रोधित या निराश हो सकते हैं और इसे एक-दूसरे पर या आप पर निकाल सकते हैं।
 
-एक अनुरक्षक के रूप में आपका काम इन स्थितियों को बढ़ने से रोकना है। भले ही विषय पर आपकी राय मजबूत हो, लड़ाई में कूदने और अपने विचारों को आगे बढ़ाने के बजाय एक मॉडरेटर या फैसिलिटेटर की स्थिति लेने का प्रयास करें। यदि कोई निर्दयी हो रहा है या बातचीत पर एकाधिकार जमा रहा है, [act immediately](../building-community/#dont-tolerate-bad-actors) 
+एक अनुरक्षक के रूप में आपका काम इन स्थितियों को बढ़ने से रोकना है। भले ही विषय पर आपकी राय मजबूत हो, लड़ाई में कूदने और अपने विचारों को आगे बढ़ाने के बजाय एक मॉडरेटर या फैसिलिटेटर की स्थिति लेने का प्रयास करें। यदि कोई निर्दयी हो रहा है या बातचीत पर एकाधिकार जमा रहा है, [तुरंत कार्रवाई करें](../building-community/#बुरे-अभिनेताओं-को-बर्दाश्त-न-करें) 
 चर्चाओं को सभ्य और उत्पादक बनाए रखना।
 
 <aside markdown="1" class="pquote">
@@ -211,7 +211,7 @@ related:
 
 ### अपने README को एक संविधान मानें
 
-आपका README है [more than just a set of instructions](../starting-a-project/#writing-a-readme). यह आपके लक्ष्यों, उत्पाद दृष्टिकोण और रोडमैप के बारे में बात करने का भी स्थान है। यदि लोग किसी विशेष सुविधा की योग्यता पर बहस करने पर अत्यधिक ध्यान केंद्रित कर रहे हैं, तो यह आपके README पर दोबारा गौर करने और आपके प्रोजेक्ट की उच्च दृष्टि के बारे में बात करने में मदद कर सकता है। अपने README पर ध्यान केंद्रित करने से बातचीत भी अवैयक्तिक हो जाती है, जिससे आप रचनात्मक चर्चा कर सकते हैं।
+आपका README है [more than just a set of instructions](../starting-a-project/#एक-README-लिखना). यह आपके लक्ष्यों, उत्पाद दृष्टिकोण और रोडमैप के बारे में बात करने का भी स्थान है। यदि लोग किसी विशेष सुविधा की योग्यता पर बहस करने पर अत्यधिक ध्यान केंद्रित कर रहे हैं, तो यह आपके README पर दोबारा गौर करने और आपके प्रोजेक्ट की उच्च दृष्टि के बारे में बात करने में मदद कर सकता है। अपने README पर ध्यान केंद्रित करने से बातचीत भी अवैयक्तिक हो जाती है, जिससे आप रचनात्मक चर्चा कर सकते हैं।
 
 ### यात्रा पर ध्यान दें, मंजिल पर नहीं
 
diff --git a/_articles/hi/code-of-conduct.md b/_articles/hi/code-of-conduct.md
index 53f610b2b2a..d39309320ae 100644
--- a/_articles/hi/code-of-conduct.md
+++ b/_articles/hi/code-of-conduct.md
@@ -24,8 +24,8 @@ related:
 
 आपकी अपेक्षाओं को संप्रेषित करने के अलावा, आचार संहिता निम्नलिखित का वर्णन करती है:
 
-* जहां आचार संहिता प्रभावी होती है `_`(केवल मुद्दों और पुल अनुरोधों, या घटनाओं जैसी सामुदायिक गतिविधियों पर?)`_`
-*आचार संहिता किस पर लागू होती है `_`(समुदाय के सदस्यों और अनुरक्षकों पर, लेकिन प्रायोजकों के बारे में क्या?)`_`
+* जहां आचार संहिता प्रभावी होती है (केवल मुद्दों और पुल अनुरोधों, या घटनाओं जैसी सामुदायिक गतिविधियों पर?)
+*आचार संहिता किस पर लागू होती है (समुदाय के सदस्यों और अनुरक्षकों पर, लेकिन प्रायोजकों के बारे में क्या?)
 *यदि कोई आचार संहिता का उल्लंघन करता है तो क्या होगा
 * कोई कैसे उल्लंघन की रिपोर्ट कर सकता है
 
diff --git a/_articles/hi/getting-paid.md b/_articles/hi/getting-paid.md
index 6f17b5c6015..9e56bccf3ae 100644
--- a/_articles/hi/getting-paid.md
+++ b/_articles/hi/getting-paid.md
@@ -87,8 +87,8 @@ OSS प्रौद्योगिकी उद्योग को बड़े
 
 यदि आप अपने वर्तमान नियोक्ता को ओपन सोर्स कार्य को प्राथमिकता देने के लिए मना नहीं सकते हैं, तो एक नया नियोक्ता ढूंढने पर विचार करें जो ओपन सोर्स में कर्मचारी योगदान को प्रोत्साहित करता हो। ऐसी कंपनियों की तलाश करें जो ओपन सोर्स कार्य के प्रति अपना समर्पण स्पष्ट करती हों। उदाहरण के लिए:
 
-*कुछ कंपनियाँ, जैसे [Netflix](https://netflix.github.io/) या [PayPal](https://paypal.github.io/), के पास ऐसी वेबसाइटें हैं जो ओपन सोर्स में उनकी भागीदारी को उजागर करती हैं।
-*[Zalando](https://opensource.zalando.com) ने [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) उनके कर्मचारियों के लिए प्रकाशन किया।
+* कुछ कंपनियाँ, जैसे [Netflix](https://netflix.github.io/) या [PayPal](https://paypal.github.io/), के पास ऐसी वेबसाइटें हैं जो ओपन सोर्स में उनकी भागीदारी को उजागर करती हैं।
+* [Zalando](https://opensource.zalando.com) ने [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) उनके कर्मचारियों के लिए प्रकाशन किया।
 
 ऐसी परियोजनाएँ जो किसी बड़ी कंपनी में उत्पन्न हुईं, जैसे [Go](https://github.com/golang) या [React](https://github.com/facebook/react), ओपन सोर्स पर काम करने के लिए लोगों को नियोजित करने की भी संभावना है।
 
diff --git a/_articles/hi/leadership-and-governance.md b/_articles/hi/leadership-and-governance.md
index 579273895c1..e680ef79544 100644
--- a/_articles/hi/leadership-and-governance.md
+++ b/_articles/hi/leadership-and-governance.md
@@ -40,7 +40,7 @@ related:
 
 **शब्द "कमिटर"** का उपयोग कमिट एक्सेस, जो एक विशिष्ट प्रकार की जिम्मेदारी है, को योगदान के अन्य रूपों से अलग करने के लिए किया जा सकता है।
 
-हालाँकि आप अपनी परियोजना भूमिकाओं को अपनी इच्छानुसार किसी भी तरह परिभाषित कर सकते हैं, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) योगदान के और अधिक रूपों को प्रोत्साहित करना। आप उन लोगों को औपचारिक रूप से पहचानने के लिए नेतृत्व की भूमिकाओं का उपयोग कर सकते हैं जिन्होंने आपके प्रोजेक्ट में उत्कृष्ट योगदान दिया है, भले ही उनके तकनीकी कौशल कुछ भी हों।
+हालाँकि आप अपनी परियोजना भूमिकाओं को अपनी इच्छानुसार किसी भी तरह परिभाषित कर सकते हैं, [व्यापक परिभाषाओं का उपयोग करने पर विचार करें](../how-to-contribute/#योगदान-देने-का-क्या-मतलब-है) योगदान के और अधिक रूपों को प्रोत्साहित करना। आप उन लोगों को औपचारिक रूप से पहचानने के लिए नेतृत्व की भूमिकाओं का उपयोग कर सकते हैं जिन्होंने आपके प्रोजेक्ट में उत्कृष्ट योगदान दिया है, भले ही उनके तकनीकी कौशल कुछ भी हों।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
@@ -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/#share-ownership-of-your-project).
+अंत में, यदि आपका प्रोजेक्ट GitHub पर है, तो अपने प्रोजेक्ट को अपने व्यक्तिगत खाते से किसी संगठन में ले जाने और कम से कम एक बैकअप व्यवस्थापक जोड़ने पर विचार करें। [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) अनुमतियों और एकाधिक रिपॉजिटरी को प्रबंधित करना और अपने प्रोजेक्ट की विरासत को सुरक्षित रखना आसान बनाएं [shared ownership](../building-community/#अपने-प्रोजेक्ट-का-स्वामित्व-साझा-करें).
 
 ## मुझे किसी को प्रतिबद्ध पहुंच कब देनी चाहिए?
 
diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md
index a1ebf7d8a6c..01219342e80 100644
--- a/_articles/hi/legal.md
+++ b/_articles/hi/legal.md
@@ -129,7 +129,7 @@ related:
 
 * **पेटेंट:** क्या आपकी कंपनी किसी ऐसे पेटेंट के लिए आवेदन कर रही है जिसके ओपन सोर्सिंग से आपका प्रोजेक्ट [सार्वजनिक प्रकटीकरण](https://en.wikipedia.org/wiki/Public_disclosure) बनेगा? अफसोस की बात है, आपको प्रतीक्षा करने के लिए कहा जा सकता है (या हो सकता है कि कंपनी आवेदन की समझदारी पर पुनर्विचार करेगी)। यदि आप बड़े पेटेंट पोर्टफोलियो वाली कंपनियों के कर्मचारियों से अपने प्रोजेक्ट में योगदान की उम्मीद कर रहे हैं, तो आपकी कानूनी टीम चाहती है कि आप योगदानकर्ताओं (जैसे अपाचे 2.0 या जीपीएलवी 3) से एक्सप्रेस पेटेंट अनुदान के साथ लाइसेंस का उपयोग करें, या एक अतिरिक्त योगदानकर्ता अनुबंध ( ऊपर देखें)।
 
-* **ट्रेडमार्क:** दोबारा जांचें कि आपके प्रोजेक्ट का नाम [किसी भी मौजूदा ट्रेडमार्क के साथ टकराव नहीं करता है](../starting-a-project/#avoiding-name-conflicts)। यदि आप प्रोजेक्ट में अपनी कंपनी के ट्रेडमार्क का उपयोग करते हैं, तो जांच लें कि इससे कोई टकराव न हो। [FOSSmarks](http://fossmarks.org/) मुक्त और मुक्त स्रोत परियोजनाओं के संदर्भ में ट्रेडमार्क को समझने के लिए एक व्यावहारिक मार्गदर्शिका है।
+* **ट्रेडमार्क:** दोबारा जांचें कि आपके प्रोजेक्ट का नाम [किसी भी मौजूदा ट्रेडमार्क के साथ टकराव नहीं करता है](../starting-a-project/#नाम-टकराव-से-बचना)। यदि आप प्रोजेक्ट में अपनी कंपनी के ट्रेडमार्क का उपयोग करते हैं, तो जांच लें कि इससे कोई टकराव न हो। [FOSSmarks](http://fossmarks.org/) मुक्त और मुक्त स्रोत परियोजनाओं के संदर्भ में ट्रेडमार्क को समझने के लिए एक व्यावहारिक मार्गदर्शिका है।
 
 * **गोपनीयता:** क्या आपका प्रोजेक्ट उपयोगकर्ताओं पर डेटा एकत्र करता है? कंपनी सर्वर के लिए "फ़ोन होम"? आपकी कानूनी टीम कंपनी की नीतियों और बाहरी नियमों का अनुपालन करने में आपकी सहायता कर सकती है।
 
@@ -159,4 +159,4 @@ related:
 
 * **पेटेंट:** आपकी कंपनी प्रमुख ओपन सोर्स परियोजनाओं के सदस्यों के उपयोग की सुरक्षा के लिए एक साझा रक्षात्मक पेटेंट पूल [ओपन इन्वेंशन नेटवर्क](https://www.openinventionnetwork.com/) में शामिल होना चाह सकती है, या अन्वेषण कर सकती है अन्य [वैकल्पिक पेटेंट लाइसेंसिंग](https://www.eff.org/document/hacking-patent-system-2016).
 
-* **शासन:** विशेष रूप से यदि और जब किसी प्रोजेक्ट को स्थानांतरित करना उचित हो [कंपनी के बाहर कानूनी इकाई](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
+* **शासन:** विशेष रूप से यदि और जब किसी प्रोजेक्ट को स्थानांतरित करना उचित हो [कंपनी के बाहर कानूनी इकाई](../leadership-and-governance/#क्या-मुझे-अपना-प्रोजेक्ट-लॉन्च-करते-समय-शासन-दस्तावेज़ों-की-आवश्यकता-होगी?).
diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md
index df1890cf721..7a9933f2a5c 100644
--- a/_articles/hi/starting-a-project.md
+++ b/_articles/hi/starting-a-project.md
@@ -221,7 +221,7 @@ READMEs आपके प्रोजेक्ट का उपयोग कै
 
 स्पष्टता को सर्वोपरि मानें। चुटकुले मजेदार हैं, लेकिन याद रखें कि कुछ चुटकुले अन्य संस्कृतियों या आपसे अलग अनुभव वाले लोगों पर लागू नहीं हो सकते हैं। आपके कुछ संभावित उपयोगकर्ता कंपनी के कर्मचारी हो सकते हैं: जब उन्हें कार्यस्थल पर आपके प्रोजेक्ट के बारे में बताना हो तो आप उन्हें असहज नहीं करना चाहेंगे!
 
-### नाम के झगड़ों से बचना
+### नाम टकराव से बचना
 
 [समान नाम वाले ओपन सोर्स प्रोजेक्ट की जांच करें](http://ivantomic.com/projects/ospnc/), खासकर यदि आप एक ही भाषा या पारिस्थितिकी तंत्र साझा करते हैं। यदि आपका नाम किसी लोकप्रिय मौजूदा प्रोजेक्ट से मेल खाता है, तो आप अपने दर्शकों को भ्रमित कर सकते हैं।
 
diff --git a/node_modules/.package-lock.json b/node_modules/.package-lock.json
new file mode 100644
index 00000000000..0cf4030726e
--- /dev/null
+++ b/node_modules/.package-lock.json
@@ -0,0 +1,240 @@
+{
+  "name": "open-source-guide",
+  "lockfileVersion": 3,
+  "requires": true,
+  "packages": {
+    "node_modules/primer-base": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/primer-base/-/primer-base-2.0.0.tgz",
+      "integrity": "sha512-qqE3MiI1Zr7HgTO7NxguYHw4QrkRGOQjMPck1bFEZhNL36ey5PWJwqB68X7w6frOjA8tRid2joL99GBQhc1NnQ==",
+      "dependencies": {
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-base/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-box": {
+      "version": "3.0.0",
+      "resolved": "https://registry.npmjs.org/primer-box/-/primer-box-3.0.0.tgz",
+      "integrity": "sha512-P6gUxgcC5Se2nPx4erHmj6JhqgBMxJDeJyuz5OS+SArWR0cydxi86Cf7mH4eNC+PebJQ91K+ddcxkU6w3vOEqw==",
+      "dependencies": {
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-box/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-breadcrumb": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/primer-breadcrumb/-/primer-breadcrumb-2.0.0.tgz",
+      "integrity": "sha512-IhIQZ8HXZNnMh53qzl7JKDrUEAH4jPiqQ4WfxNrFwSoYUrQ7eGN3SJ9LD9oIjtmmO9DUUJhvmR0Cbr9OM1VB8w==",
+      "dependencies": {
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-breadcrumb/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-buttons": {
+      "version": "3.0.0",
+      "resolved": "https://registry.npmjs.org/primer-buttons/-/primer-buttons-3.0.0.tgz",
+      "integrity": "sha512-oQX3FOCRrnSrhPFef5AvLkBV9og7W/U0GYPvu1FbXV+CDVauO8pC5hntQqvwa9w/VCptsJl2qpYSIFCQiH+f1g==",
+      "dependencies": {
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-buttons/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-core": {
+      "version": "7.0.0",
+      "resolved": "https://registry.npmjs.org/primer-core/-/primer-core-7.0.0.tgz",
+      "integrity": "sha512-m7E5IddQpzV2Jtrlk9s513zmM7ZMtZUBDJ9Bckrz+67tPSvY74jqwfvwvkty/hLhQFPlM8p+c0fmmRTcO+vVIA==",
+      "dependencies": {
+        "primer-base": "2.0.0",
+        "primer-box": "3.0.0",
+        "primer-breadcrumb": "2.0.0",
+        "primer-buttons": "3.0.0",
+        "primer-forms": "3.0.0",
+        "primer-layout": "2.0.0",
+        "primer-navigation": "2.0.0",
+        "primer-pagination": "2.0.0",
+        "primer-support": "5.0.0",
+        "primer-table-object": "2.0.0",
+        "primer-tooltips": "2.0.0",
+        "primer-truncate": "2.0.0",
+        "primer-utilities": "5.0.0"
+      }
+    },
+    "node_modules/primer-core/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-forms": {
+      "version": "3.0.0",
+      "resolved": "https://registry.npmjs.org/primer-forms/-/primer-forms-3.0.0.tgz",
+      "integrity": "sha512-buKBHx1skjLmPgYvpFL5Xr3cbE9lxGkWS/h8lsuwL3ZCx5axHFu8MI+fKL6BY1EInRfbfk56d6Dn4QbC/ctInQ==",
+      "dependencies": {
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-forms/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-layout": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/primer-layout/-/primer-layout-2.0.0.tgz",
+      "integrity": "sha512-lwRq5KDaErF4JecHnBr2h6D4Dqbfv28pFBafIOsPvIuMHDHmxNVqao1LRXC86ficL9V0aynlkmH8q6DqKnVPlw==",
+      "dependencies": {
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-layout/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-marketing": {
+      "version": "7.0.0",
+      "resolved": "https://registry.npmjs.org/primer-marketing/-/primer-marketing-7.0.0.tgz",
+      "integrity": "sha512-gLIWiE3pW1rXEEnmfz2eekq4LC27QUeMccrG87EU5qyEnu8LMr59c5LRibc5EJaCsa4708Jd2WxxSXEfD0ieug==",
+      "dependencies": {
+        "primer-marketing-buttons": "2.0.0",
+        "primer-marketing-support": "2.0.0",
+        "primer-marketing-type": "2.0.0",
+        "primer-marketing-utilities": "2.0.0",
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-marketing-buttons": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/primer-marketing-buttons/-/primer-marketing-buttons-2.0.0.tgz",
+      "integrity": "sha512-R8DvbvI6QjH9/xG2diqReqHhkMgKbiJ7+xg2VTlQon3H5sAxvUqBiqfqY+ZrZ9K5eyrLP+3Z/cgysKd/xe1U2A==",
+      "dependencies": {
+        "primer-marketing-support": "2.0.0",
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-marketing-support": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/primer-marketing-support/-/primer-marketing-support-2.0.0.tgz",
+      "integrity": "sha512-HyYxwDVn9aGVN4wyXiIAzHrAgmoyNlXvZpRXh/UZRlA9EfZMxlCji3KhuMFzQFtYi+nXt7f/cTB5AX9YRnlVZg==",
+      "dependencies": {
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-marketing-type": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/primer-marketing-type/-/primer-marketing-type-2.0.0.tgz",
+      "integrity": "sha512-c+bCjKVulTrRhjAHJ7pcaFYDUYiSecVFXMo6DkA9v5JvZ2cK/m4LySo5Eb2qbQmPBwLx6t/V1TnxD2cgKtdIDA==",
+      "dependencies": {
+        "primer-marketing-support": "2.0.0",
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-marketing-utilities": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/primer-marketing-utilities/-/primer-marketing-utilities-2.0.0.tgz",
+      "integrity": "sha512-R2Y8uaOy44J9NtBNlLJKUrPKxtxv8svss3vP8YS4RRWISUSQGcjxRFPUX5ra8hqaenWO/NBbmeFVJXDwgrKu1A==",
+      "dependencies": {
+        "primer-marketing-support": "2.0.0",
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-navigation": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/primer-navigation/-/primer-navigation-2.0.0.tgz",
+      "integrity": "sha512-yi45wDOuct/Wxp60hG74kfiNKsTluYmhsNelMBOy5WgTmnqtQy0l3d5NAQz/XdvEdiRrpres3LcPxs8GONO3sQ==",
+      "dependencies": {
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-navigation/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-pagination": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/primer-pagination/-/primer-pagination-2.0.0.tgz",
+      "integrity": "sha512-+1BGHkNJoJtGVkfWi/IUP82MlShSrPJM1my6da1UnfcRBhONfk+7O3DXT7VLscXYk11rYsd/pGKZ8ZPH4DAvsw==",
+      "dependencies": {
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-pagination/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-table-object": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/primer-table-object/-/primer-table-object-2.0.0.tgz",
+      "integrity": "sha512-ajCCvy93AwE8g62wS9Frw6kw1JM+gLCwMrr5N3ZXsu4lN1171782lnHcNBFdVzu0iFYiovH7CfQ0glVRNJVAbg==",
+      "dependencies": {
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-table-object/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-tooltips": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/primer-tooltips/-/primer-tooltips-2.0.0.tgz",
+      "integrity": "sha512-cNF3r3hG6sXLr71GbYyJw3BXCBhspW4FjzJ0Hx/BO+lP3XCrNAX/wqd57+vvnWSuaLif2O8s3/Prs3VBF50hVQ==",
+      "dependencies": {
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-tooltips/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-truncate": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/primer-truncate/-/primer-truncate-2.0.0.tgz",
+      "integrity": "sha512-/rmXZCR/wQpOyQsp/vSY8sO/9IczidcFRN0iUg4oCUXgufNuh8IRHetYOGXwnlMiO5c9EkbNFJi/6jkFmRBd4g==",
+      "dependencies": {
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-truncate/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    },
+    "node_modules/primer-utilities": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-utilities/-/primer-utilities-5.0.0.tgz",
+      "integrity": "sha512-HeMffBQLL2ygyPOUMccN43L9A/3HYsbDhs423Sr3Run1eW1ZvfTgCP3xh9P8Dh/dJt5qHFkekzBc4Y8qsZ3UtA==",
+      "dependencies": {
+        "primer-support": "5.0.0"
+      }
+    },
+    "node_modules/primer-utilities/node_modules/primer-support": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz",
+      "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g=="
+    }
+  }
+}

From c9a1ce3d16678a71603e121704683de33b60ec9e Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Sat, 2 Sep 2023 10:02:16 +0530
Subject: [PATCH 489/749] hindi update

---
 _articles/hi/building-community.md | 4 ++--
 _articles/hi/legal.md              | 2 +-
 _articles/hi/starting-a-project.md | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/hi/building-community.md b/_articles/hi/building-community.md
index 1e271fca4c1..642194d3c0b 100644
--- a/_articles/hi/building-community.md
+++ b/_articles/hi/building-community.md
@@ -26,7 +26,7 @@ related:
 
 अपने दस्तावेज़ से प्रारंभ करें:
 
-* **किसी के लिए आपके प्रोजेक्ट का उपयोग करना आसान बनाएं।** [एक मैत्रीपूर्ण README लिखना](../starting-a-project/#एक-README-लिखना) 
+* **किसी के लिए आपके प्रोजेक्ट का उपयोग करना आसान बनाएं।** [एक मैत्रीपूर्ण README लिखना](../starting-a-project/#एक-रीडमी-लिखना) 
 और स्पष्ट कोड उदाहरण आपके प्रोजेक्ट पर आने वाले किसी भी व्यक्ति के लिए आरंभ करना आसान बना देंगे।  
 * **स्पष्ट रूप से बताएं कि योगदान कैसे करना है**, आपकी [योगदान CONTRIBUTING फ़ाइल का उपयोग करके](../starting-a-project/#अपने-योगदान-संबंधी-दिशानिर्देश-लिखना) और अपने मुद्दों को अद्यतन रखते हुए।
 * **अच्छे प्रथम अंक**: नए योगदानकर्ताओं को आरंभ करने में मदद करने के लिए, स्पष्ट रूप से विचार करें [उन मुद्दों को लेबल करना जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर सामने लाएगा, उपयोगी योगदान बढ़ाएगा, और उन मुद्दों से निपटने वाले उपयोगकर्ताओं के मनमुटाव को कम करेगा जो उनके स्तर के लिए बहुत कठिन हैं।
@@ -211,7 +211,7 @@ related:
 
 ### अपने README को एक संविधान मानें
 
-आपका README है [more than just a set of instructions](../starting-a-project/#एक-README-लिखना). यह आपके लक्ष्यों, उत्पाद दृष्टिकोण और रोडमैप के बारे में बात करने का भी स्थान है। यदि लोग किसी विशेष सुविधा की योग्यता पर बहस करने पर अत्यधिक ध्यान केंद्रित कर रहे हैं, तो यह आपके README पर दोबारा गौर करने और आपके प्रोजेक्ट की उच्च दृष्टि के बारे में बात करने में मदद कर सकता है। अपने README पर ध्यान केंद्रित करने से बातचीत भी अवैयक्तिक हो जाती है, जिससे आप रचनात्मक चर्चा कर सकते हैं।
+आपका README है [निर्देशों के एक संग्रह से कहीं अधिक](../starting-a-project/#एक-रीडमी-लिखना). यह आपके लक्ष्यों, उत्पाद दृष्टिकोण और रोडमैप के बारे में बात करने का भी स्थान है। यदि लोग किसी विशेष सुविधा की योग्यता पर बहस करने पर अत्यधिक ध्यान केंद्रित कर रहे हैं, तो यह आपके README पर दोबारा गौर करने और आपके प्रोजेक्ट की उच्च दृष्टि के बारे में बात करने में मदद कर सकता है। अपने README पर ध्यान केंद्रित करने से बातचीत भी अवैयक्तिक हो जाती है, जिससे आप रचनात्मक चर्चा कर सकते हैं।
 
 ### यात्रा पर ध्यान दें, मंजिल पर नहीं
 
diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md
index 01219342e80..aae22fa1d16 100644
--- a/_articles/hi/legal.md
+++ b/_articles/hi/legal.md
@@ -159,4 +159,4 @@ related:
 
 * **पेटेंट:** आपकी कंपनी प्रमुख ओपन सोर्स परियोजनाओं के सदस्यों के उपयोग की सुरक्षा के लिए एक साझा रक्षात्मक पेटेंट पूल [ओपन इन्वेंशन नेटवर्क](https://www.openinventionnetwork.com/) में शामिल होना चाह सकती है, या अन्वेषण कर सकती है अन्य [वैकल्पिक पेटेंट लाइसेंसिंग](https://www.eff.org/document/hacking-patent-system-2016).
 
-* **शासन:** विशेष रूप से यदि और जब किसी प्रोजेक्ट को स्थानांतरित करना उचित हो [कंपनी के बाहर कानूनी इकाई](../leadership-and-governance/#क्या-मुझे-अपना-प्रोजेक्ट-लॉन्च-करते-समय-शासन-दस्तावेज़ों-की-आवश्यकता-होगी?).
+* **शासन:** विशेष रूप से यदि और जब किसी प्रोजेक्ट को स्थानांतरित करना उचित हो [कंपनी के बाहर कानूनी इकाई](../leadership-and-governance/#क्या-मुझे-अपने-प्रोजेक्ट-का-समर्थन-करने-के-लिए-एक-कानूनी-इकाई-की-आवश्यकता-है).
diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md
index 7a9933f2a5c..e1eb3ed63c0 100644
--- a/_articles/hi/starting-a-project.md
+++ b/_articles/hi/starting-a-project.md
@@ -129,7 +129,7 @@ _मुफ़्त सॉफ़्टवेयर_ परियोजनाओ
 
 यदि आपके पास ओपन सोर्स प्रोजेक्ट के प्रबंधन के कानूनी पहलुओं के बारे में अन्य प्रश्न या चिंताएं हैं, [हमने आपका ध्यान रखा है](../legal/).
 
-### एक README लिखना
+### एक रीडमी लिखना
 
 READMEs आपके प्रोजेक्ट का उपयोग कैसे करें यह समझाने के अलावा और भी बहुत कुछ करते हैं। वे यह भी बताते हैं कि आपका प्रोजेक्ट क्यों मायने रखता है, और आपके उपयोगकर्ता इसके साथ क्या कर सकते हैं।
 

From e069f1cba00d9658d238454dbecf606f17d827ac Mon Sep 17 00:00:00 2001
From: omahs <73983677+omahs@users.noreply.github.com>
Date: Sat, 2 Sep 2023 08:42:42 +0200
Subject: [PATCH 490/749] fix typo

---
 _articles/best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/best-practices.md b/_articles/best-practices.md
index 01895803615..5fff30d2f11 100644
--- a/_articles/best-practices.md
+++ b/_articles/best-practices.md
@@ -134,7 +134,7 @@ To reduce the volume of unwanted contributions in the first place, explain your
 
 If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example:
 
-* Fill out a issue or PR template/checklist
+* Fill out an issue or PR template/checklist
 * Open an issue before submitting a PR
 
 If they don't follow your rules, close the issue immediately and point to your documentation.

From fa860e6f42cb2828843b438ef9f3deb37c2c2645 Mon Sep 17 00:00:00 2001
From: omahs <73983677+omahs@users.noreply.github.com>
Date: Sat, 2 Sep 2023 08:54:12 +0200
Subject: [PATCH 491/749] fix typos

---
 _articles/fr/best-practices.md | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/_articles/fr/best-practices.md b/_articles/fr/best-practices.md
index a2c213ed820..e3252b7f877 100644
--- a/_articles/fr/best-practices.md
+++ b/_articles/fr/best-practices.md
@@ -28,7 +28,7 @@ Rédaction des choses rend plus facile de dire non quand quelque chose ne rentre
 
 Même si vous n'utilisez pas de paragraphes entiers, des listes de point sont mieux que de ne pas écrire du tout.
 
-N'oubliez pas de garder votre documentation à jour. Si vous n'êtes pas toujours en mesure le faire, supprimez votre documentation obsolète ou indiquez qu'elle est obsolète afin que les contributeurs sachent que les mises à jour sont les bienvenues.
+N'oubliez pas de garder votre documentation à jour. Si vous n'êtes pas toujours en mesure de le faire, supprimez votre documentation obsolète ou indiquez qu'elle est obsolète afin que les contributeurs sachent que les mises à jour sont les bienvenues.
 
 ### Décrivez la vision de votre projet
 
@@ -87,7 +87,7 @@ Dire non s'applique à de nombreuses situations que vous rencontrerez en tant qu
 
 ### Gardez la conversation amicale
 
-L'un des endroits les plus importants que vous pratiquez en disant non est sur votre isue et la file d'attente des pull requests. En tant que responsable du projet, vous recevrez inévitablement des suggestions que vous ne souhaitez pas accepter.
+Les endroits les plus importants où pratiquer l'art du refus sont vos issues et la file d'attente des pull requests. En tant que responsable du projet, vous recevrez inévitablement des suggestions que vous ne souhaitez pas accepter.
 
 Peut-être que la contribution modifie la portée de votre projet ou ne correspond pas à votre vision. Peut-être que l'idée est bonne, mais la mise en œuvre est mauvaise.
 
@@ -128,7 +128,7 @@ Ne vous sentez pas coupable de ne pas vouloir accepter la contribution de quelqu
 
 En fin de compte, si une contribution n'est pas suffisante, vous n'êtes pas obligé de l'accepter. Soyez gentil et réactif lorsque les gens contribuent à votre projet, mais n'acceptez que les changements qui, selon vous, amélioreront votre projet. Le plus souvent vous pratiquez en disant non, plus cela devient facile. Promis.
 
-### Soyez pro-actif
+### Soyez proactif
 
 Pour réduire le volume des contributions non désirées, expliquez le processus de soumission et d'acceptation des contributions de votre projet dans votre guide.
 
@@ -137,7 +137,7 @@ Si vous recevez trop de contributions de faible qualité, demandez aux contribut
 * Remplir une issue ou un modèle de PR / checklist
 * Ouvrir une issue avant de soumettre une PR
 
-S'ils ne respectent pas vos règles, fermez immédiatement l'issue et référez a votre documentation.
+S'ils ne respectent pas vos règles, fermez immédiatement l'issue et référez à votre documentation.
 
 Bien que cette approche puisse sembler méchante au début, être proactif est réellement bon pour les deux parties. Cela réduit le risque que quelqu'un consacre beaucoup d'heures de travail perdues à une pull request que vous n'allez pas accepter. Et cela rend votre charge de travail plus facile à gérer.
 
@@ -155,7 +155,7 @@ Parfois, quand vous dites non, votre contributeur potentiel peut se fâcher ou c
 
 Peut-être que quelqu'un dans votre communauté soumet régulièrement des contributions qui ne répondent pas aux normes de votre projet. Il peut être frustrant pour les deux parties de passer à plusieurs reprises par des rejets.
 
-Si vous voyez que quelqu'un est enthousiaste à propos de votre projet, mais qu'il a besoin d'un peu de polish, soyez patient. Expliquer clairement dans chaque situation pourquoi les contributions ne répondent pas aux attentes du projet. Essayez de le diriger vers une tâche plus facile ou moins ambiguë, comme une question marquée _"bonne premiere issue"_, pour se faire les pieds. Si vous avez le temps, envisagez de l'encadrer à travers sa première contribution, ou de trouver quelqu'un d'autre dans votre communauté qui pourrait être disposé à le faire.
+Si vous voyez que quelqu'un est enthousiaste à propos de votre projet, mais qu'il a besoin d'un peu de polish, soyez patient. Expliquer clairement dans chaque situation pourquoi les contributions ne répondent pas aux attentes du projet. Essayez de le diriger vers une tâche plus facile ou moins ambiguë, comme une question marquée _"bonne première issue"_, pour se faire les pieds. Si vous avez le temps, envisagez de l'encadrer à travers sa première contribution, ou de trouver quelqu'un d'autre dans votre communauté qui pourrait être disposé à le faire.
 
 ## Tirez parti de votre communauté
 
@@ -193,7 +193,7 @@ Forker un projet ne doit pas être une mauvaise chose. Etre capable de copier et
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
-  Je réponds a 80% des cas d'utilisation. Si vous êtes l'une des licornes, s'il vous plaît forker mon travail. Je ne serai pas offensé ! Mes projets publics sont presque toujours destinés à résoudre les problèmes les plus courants. J'essaie de faire en sorte qu'il soit plus facile d'approfondir mon travail ou de le prolonger.
+  Je réponds à 80% des cas d'utilisation. Si vous êtes l'une des licornes, s'il vous plaît forker mon travail. Je ne serai pas offensé ! Mes projets publics sont presque toujours destinés à résoudre les problèmes les plus courants. J'essaie de faire en sorte qu'il soit plus facile d'approfondir mon travail ou de le prolonger.
   <p markdown="1" class="pquote-credit">
 — @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
   </p>
@@ -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érifications 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://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.
 
 Si vous ajoutez des tests, assurez-vous d'expliquer comment ils fonctionnent dans votre fichier CONTRIBUTING.
 
@@ -227,7 +227,7 @@ Si vous ajoutez des tests, assurez-vous d'expliquer comment ils fonctionnent dan
 
 ### Utiliser des outils pour automatiser les tâches de maintenance de base
 
-Les bonnes nouvelles à propos du maintien d'un projet populaire sont que d'autres responsables ont probablement deja fait face à des problèmes similaires et ont construit une solution pour cela.
+Les bonnes nouvelles à propos du maintien d'un projet populaire sont que d'autres responsables ont probablement déjà fait face à des problèmes similaires et ont construit une solution pour cela.
 
 Il y a une [variété d'outils disponibles](https://github.com/showcases/tools-for-open-source) pour aider à automatiser certains aspects du travail de maintenance. Quelques exemples:
 
@@ -271,6 +271,6 @@ Faites de votre mieux pour trouver du support pour vos utilisateurs et votre com
 
 Prendre des pauses s'applique à plus que de simples vacances, aussi. Si vous ne voulez pas faire du travail open source le week-end, ou pendant les heures de travail, communiquez ces attentes aux autres, afin qu'ils sachent ne pas vous déranger.
 
-## Prennez soin de vous d'abord !
+## Prenez soin de vous d'abord !
 
 Maintenir un projet populaire nécessite des compétences différentes des étapes précédentes de la croissance, mais ce n'est pas moins gratifiant. En tant que responsable, vous pratiquerez le leadership et les compétences personnelles à un niveau que peu de gens connaissent. Bien que ce ne soit pas toujours facile à gérer, définir des limites claires et ne prendre que ce que vous êtes à l'aise vous aidera à rester heureux, frais et productif.

From c32726ee759cef05ee91e0dd88d88133bbcbaa41 Mon Sep 17 00:00:00 2001
From: omahs <73983677+omahs@users.noreply.github.com>
Date: Sat, 2 Sep 2023 08:59:29 +0200
Subject: [PATCH 492/749] fix typos

---
 _articles/fr/building-community.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/_articles/fr/building-community.md b/_articles/fr/building-community.md
index 557ae48e8db..95c2531f6b4 100644
--- a/_articles/fr/building-community.md
+++ b/_articles/fr/building-community.md
@@ -29,10 +29,10 @@ Commencez avec votre documentation:
 * **Facilitez l'utilisation de votre projet par quelqu'un.** [Un fichier README amical](../starting-a-project/#ecrire-un-fichier-readme) et des exemples de code clair faciliteront la tâche à tous ceux qui atterriront votre projet pour commencer.
 * **Expliquez clairement comment contribuer**, en utilisant [votre fichier CONTRIBUTING](../starting-a-project/#r&eacute;daction-de-vos-directives-de-contribution) et en gardant vos issues à jour.
 
-[L'enquête open source 2017 de GitHub](http://opensourcesurvey.org/2017/) a montrée que la documentation incomplète ou confuse est le plus gros problème pour les utilisateurs open source. Une bonne documentation invite les gens à interagir avec votre projet. Finalement, quelqu'un va ouvrir une issue ou faire une pull request. Utilisez ces interactions comme des opportunités pour les déplacer dans l'entonnoir.
+[L'enquête open source 2017 de GitHub](http://opensourcesurvey.org/2017/) a montré que la documentation incomplète ou confuse est le plus gros problème pour les utilisateurs open source. Une bonne documentation invite les gens à interagir avec votre projet. Finalement, quelqu'un va ouvrir une issue ou faire une pull request. Utilisez ces interactions comme des opportunités pour les déplacer dans l'entonnoir.
 
 * **Quand quelqu'un arrive sur votre projet, remerciez-le de son intérêt !** Il suffit d'une expérience négative pour que quelqu'un ne veuille pas revenir.
-* **Soyez réactif.** Si vous ne répondez pas à leur problème pendant un mois, les chances sont, ils ont déjà oublié votre projet.
+* **Soyez réactif.** Si vous ne répondez pas à leur problème pendant un mois, il est probable qu'ils aient déjà oublié votre projet.
 * **Soyez ouvert sur les types de contributions que vous accepterez.** De nombreux contributeurs commencent par un rapport de bug ou une petite correction. Il y a [plusieurs façons de contribuer](../how-to-contribute/#que-signifie-contribuer) à un projet. Laissez les gens aider comment ils veulent aider.
 * **S'il y a une contribution avec laquelle vous n'êtes pas d'accord,** remerciez-les pour leur idée et [expliquez pourquoi](../best-practices/#apprendre-&agrave;-dire-non) cela ne rentre pas dans le cadre de la projet, en reliant à la documentation pertinente si vous l'avez.
 
@@ -70,7 +70,7 @@ Si vous remarquez que plusieurs utilisateurs rencontrent le même problème, doc
 
 Pour les réunions, pensez à publier vos notes ou vos plats à emporter dans un numéro pertinent. Les commentaires que vous obtiendrez de ce niveau de transparence pourraient vous surprendre.
 
-Documenter tout s'applique au travail que vous faites aussi. Si vous travaillez sur une mise à jour substantielle de votre projet, placez-la dans une pull request et marquez-la comme un travail en cours (WIP). De cette façon, d'autres personnes peuvent se sentir impliqués dans le processus dès le début.
+Documenter tout s'applique au travail que vous faites aussi. Si vous travaillez sur une mise à jour substantielle de votre projet, placez-la dans une pull request et marquez-la comme un travail en cours (WIP). De cette façon, d'autres personnes peuvent se sentir impliquées dans le processus dès le début.
 
 ### Soyez réactif
 
@@ -82,7 +82,7 @@ Même si vous ne pouvez pas examiner la demande immédiatement, le reconnaître
 
 ![la pull request Middleman](/assets/images/building-community/middleman_pr.png)
 
-[Une étude de Mozilla a trouvé que](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) les contributeurs qui ont reçu des avis de code dans les 48 heures avaient un taux de rendement beaucoup plus élevé et recommencaient a contriber.
+[Une étude de Mozilla a trouvé que](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) les contributeurs qui ont reçu des avis de code dans les 48 heures avaient un taux de rendement beaucoup plus élevé et recommençaient a contribuer.
 
 Des conversations sur votre projet pourraient également avoir lieu dans d'autres endroits sur Internet, tels que Stack Overflow, Twitter ou Reddit. Vous pouvez configurer des notifications dans certains de ces endroits afin d'être averti lorsque quelqu'un mentionne votre projet.
 
@@ -106,7 +106,7 @@ Les exceptions notables à la communication publique sont: 1) les problèmes de
 
 Les communautés sont extrêmement puissantes. Ce pouvoir peut être une bénédiction ou une malédiction, selon la façon dont vous l'utilisez. Au fur et à mesure que la communauté de votre projet grandit, il existe des moyens de l'aider à devenir une force de construction, pas de destruction.
 
-### Ne tol&egrave;rez pas les mauvais acteurs
+### Ne tolérez pas les mauvais acteurs
 
 Tout projet populaire attirera inévitablement des gens qui nuisent à votre communauté plutôt que de l'aider. Ils peuvent lancer des débats inutiles, ergoter sur des fonctionnalités triviales, ou intimider les autres.
 
@@ -114,7 +114,7 @@ Faites de votre mieux pour adopter une politique de tolérance zéro envers ces
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
-  La vérité est qu'ayant une communauté de soutien est la clé. Je ne serais jamais capable de faire ce travail sans l'aide de mes collègues, des étrangers sympathiques sur Internet, et des canaux IRC bavards. (...) Ne vous contentez pas de moins. Ne vous contentez pas de connards.
+  La vérité est qu'avoir une communauté de soutien est la clé. Je ne serais jamais capable de faire ce travail sans l'aide de mes collègues, des étrangers sympathiques sur Internet, et des canaux IRC bavards. (...) Ne vous contentez pas de moins. Ne vous contentez pas de connards.
   <p markdown="1" class="pquote-credit">
 — @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
   </p>
@@ -230,7 +230,7 @@ Dans le cadre d'un processus de recherche de consensus, les membres de la commun
 
 Même si vous n'adoptez pas un processus de recherche de consensus, en tant que responsable de projet, il est important que les gens sachent que vous écoutez. Faire en sorte que les autres se sentent entendus, et s'engager à résoudre leurs problèmes, contribue grandement à la diffusion des situations sensibles. Ensuite, suivez vos mots avec des actions.
 
-Ne vous précipitez pas dans une décision pour avoir une résolution. Assurez-vous que tout le monde se sent entendu et que toutes les informations ont été rendues publiques avant de passer à une résolution.
+Ne vous précipitez pas dans une décision pour avoir une résolution. Assurez-vous que tout le monde se sente entendu et que toutes les informations ont été rendues publiques avant de passer à une résolution.
 
 ### Maintenir la conversation centrée sur l'action
 

From f8cc57ad3e61dc7c2b9528b7030e14820d545180 Mon Sep 17 00:00:00 2001
From: omahs <73983677+omahs@users.noreply.github.com>
Date: Sat, 2 Sep 2023 09:01:51 +0200
Subject: [PATCH 493/749] fix typos

---
 _articles/fr/code-of-conduct.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/_articles/fr/code-of-conduct.md b/_articles/fr/code-of-conduct.md
index cc3b654023f..aeea86586fb 100644
--- a/_articles/fr/code-of-conduct.md
+++ b/_articles/fr/code-of-conduct.md
@@ -44,9 +44,9 @@ Placez un fichier CODE_OF_CONDUCT dans le répertoire racine de votre projet et
   </p>
 </aside>
 
-Vous devrez expliquer comment votre code de conduite sera appliqué **_avant_** une qu'une violation se produise. Il y a plusieurs raisons de le faire:
+Vous devrez expliquer comment votre code de conduite sera appliqué **_avant_** qu'une violation se produise. Il y a plusieurs raisons de le faire:
 
-* Cela montre que vous êtes capable de prendre les mesures nécessaire quand il y a besoin.
+* Cela montre que vous êtes capable de prendre les mesures nécessaires quand il y a besoin.
 
 * Votre communauté se sentira plus rassurée que les plaintes soient réellement examinées.
 
@@ -70,7 +70,7 @@ Traitez la voix de chaque membre de la communauté comme étant aussi importante
 
 Le membre de la communauté en question peut être un récidiviste qui incite constamment les autres à se sentir mal à l'aise, ou il se peut qu'ils aient seulement dit ou fait quelque chose une fois. Les deux peuvent être des motifs d'action, selon le contexte.
 
-Avant de répondre, donnez-vous le temps de comprendre ce qui s'est passé. Lisez les commentaires et les conversations passés de la personne pour mieux comprendre qui ils sont et pourquoi ils ont agis de cette façon. Essayez de recueillir des points de vues autres que le vôtre au sujet de cette personne et de son comportement.
+Avant de répondre, donnez-vous le temps de comprendre ce qui s'est passé. Lisez les commentaires et les conversations passés de la personne pour mieux comprendre qui ils sont et pourquoi ils ont agi de cette façon. Essayez de recueillir des points de vues autres que le vôtre au sujet de cette personne et de son comportement.
 
 <aside markdown="1" class="pquote">
   Ne vous laissez pas entraîner dans une dispute. Ne vous laissez pas distraire par le comportement de quelqu'un d'autre avant d'avoir réglé le problème. Concentrez-vous sur ce dont vous avez besoin.
@@ -89,7 +89,7 @@ Il existe plusieurs façons de répondre à une violation du code de conduite:
 
 * **Donnez à la personne en question un avertissement public** et expliquez comment son comportement a eu un impact négatif sur les autres, de préférence dans le canal où il s'est produit. Dans la mesure du possible, la communication publique indique au reste de la communauté que vous prenez le code de conduite au sérieux. Soyez gentil, mais ferme dans votre communication.
 
-* **Communiquer en privé avec la personne** en question pour lui expliquer comment son comportement a eu un impact négatif sur les autres. Vous pouvez utiliser un canal de communication privé si la situation implique des informations personnelles sensibles. Si vous communiquez avec quelqu'un en privé, c'est une bonne idée de metre en copie ceux qui ont d'abord signalé la situation, alors ils savent que vous avez pris des mesures. Dans ce cas, demandez le consentement du déclarant avant.
+* **Communiquer en privé avec la personne** en question pour lui expliquer comment son comportement a eu un impact négatif sur les autres. Vous pouvez utiliser un canal de communication privé si la situation implique des informations personnelles sensibles. Si vous communiquez avec quelqu'un en privé, c'est une bonne idée de mettre en copie ceux qui ont d'abord signalé la situation, alors ils savent que vous avez pris des mesures. Dans ce cas, demandez le consentement du déclarant avant.
 
 Parfois, une résolution ne peut pas être atteinte. La personne en question peut devenir agressive ou hostile lorsqu'elle est confrontée ou ne change pas son comportement. Dans cette situation, vous pouvez envisager de prendre des mesures plus énergiques. Par exemple:
 
@@ -103,7 +103,7 @@ Interdire les membres ne devrait pas être pris à la légère et représente un
 
 Un code de conduite n'est pas une loi imposée arbitrairement. Vous êtes l'exécutant du code de conduite et il est de votre responsabilité de suivre les règles établies par le code de conduite.
 
-En tant que responsable, vous établissez les lignes directrices pour votre communauté et appliquez ces directives conformément aux règles énoncées dans votre code de conduite. Cela signifie prendre au sérieux tout rapport d'une violation du code de conduite. Les déclarants ont a droit a un examen approfondi et équitable de leur plaintes. Si vous déterminez que le comportement signalé n'est pas une violation, communiquez-le clairement et expliquez pourquoi vous n'allez pas agir. Ce qu'ils feront avec cela leur appartient: tolérer le comportement avec lequel ils ont un problème ou cesser de participer à la communauté.
+En tant que responsable, vous établissez les lignes directrices pour votre communauté et appliquez ces directives conformément aux règles énoncées dans votre code de conduite. Cela signifie prendre au sérieux tout rapport d'une violation du code de conduite. Les déclarants ont droit à un examen approfondi et équitable de leurs plaintes. Si vous déterminez que le comportement signalé n'est pas une violation, communiquez-le clairement et expliquez pourquoi vous n'allez pas agir. Ce qu'ils feront avec cela leur appartient: tolérer le comportement avec lequel ils ont un problème ou cesser de participer à la communauté.
 
 Un rapport de comportement qui ne viole pas _théoriquement_ le code de conduite peut toujours indiquer qu'il y a un problème dans votre communauté, et vous devriez étudier ce problème potentiel et agir en conséquence. Cela peut inclure la révision de votre code de conduite pour clarifier un comportement acceptable et/ou parler à la personne dont le comportement a été signalé et lui signaler que bien qu'il n'ai pas enfreint le code de conduite, il est en train de contourner ce qui en est attendu et que certain participants en sont mal à l'aise.
 

From 7442515c20bd823464ca4c66806c0d6bd7fffcb4 Mon Sep 17 00:00:00 2001
From: omahs <73983677+omahs@users.noreply.github.com>
Date: Sat, 2 Sep 2023 09:03:43 +0200
Subject: [PATCH 494/749] fix typos

---
 _articles/fr/finding-users.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/fr/finding-users.md b/_articles/fr/finding-users.md
index 86838dbab02..5c8f3179ac1 100644
--- a/_articles/fr/finding-users.md
+++ b/_articles/fr/finding-users.md
@@ -31,7 +31,7 @@ Pour plus d'information concernant la messagerie, consultez l'exercice de Mozill
 ## Aidez les gens à trouver et à suivre votre projet
 
 <aside markdown="1" class="pquote">
-  Dans l'idéal, vous avez besoin d'une seule URL "d'accueil" que vous pouvez promouvoir et diriger vers des personnes en relation avec votre projet. Vous n'avez pas besoin de vous depenser sur un modèle fantaisie ou même un nom de domaine, mais votre projet a besoin d'un point focal.
+  Dans l'idéal, vous avez besoin d'une seule URL "d'accueil" que vous pouvez promouvoir et diriger vers des personnes en relation avec votre projet. Vous n'avez pas besoin de vous dépenser sur un modèle fantaisie ou même un nom de domaine, mais votre projet a besoin d'un point focal.
   <p markdown="1" class="pquote-credit">
 — Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
   </p>
@@ -69,7 +69,7 @@ Tirez parti des communautés et des plateformes en ligne existantes pour atteind
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
-  Chaque programme a des fonctions très spécifiques que seule une fraction des utilisateurs trouveront utiles. Ne spammez pas toute les personnes possible. Ciblez plutôt vos efforts sur les communautés qui trouveront un bénéfice a connaître votre projet.
+  Chaque programme a des fonctions très spécifiques que seule une fraction des utilisateurs trouveront utiles. Ne spammez pas toutes les personnes possible. Ciblez plutôt vos efforts sur les communautés qui trouveront un bénéfice à connaître votre projet.
   <p markdown="1" class="pquote-credit">
 — @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
   </p>
@@ -103,7 +103,7 @@ Si vous êtes [nouveau sur la prise de parole en public](https://speaking.io/),
 
 Si vous n'avez jamais parlé à un événement auparavant, il est tout à fait normal de vous sentir nerveux ! Rappelez-vous que votre auditoire est là parce qu'il veut vraiment entendre parler de votre travail.
 
-Au fur et à mesure que vous écrivez votre exposé, concentrez-vous sur ce que votre auditoire trouvera intéressant et dont vous tirerez profit. Gardez votre ton amicale et accessible. Souriez, respirez et amusez-vous.
+Au fur et à mesure que vous écrivez votre exposé, concentrez-vous sur ce que votre auditoire trouvera intéressant et dont vous tirerez profit. Gardez votre ton amical et accessible. Souriez, respirez et amusez-vous.
 
 <aside markdown="1" class="pquote">
   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
@@ -143,6 +143,6 @@ Il n'est jamais trop tôt ou trop tard pour commencer à bâtir votre réputatio
 
 Il n'y a pas de solution du jour au lendemain pour créer un public. Gagner la confiance et le respect des autres prend du temps, et bâtir votre réputation ne s'arrête jamais.
 
-## Persévèrez !
+## Persévérez !
 
 Cela peut prendre beaucoup de temps avant que les gens remarquent votre projet open source. C'est bon ! Certains des projets les plus populaires aujourd'hui ont pris des années pour atteindre des niveaux d'activité élevés. Concentrez-vous sur l'établissement de relations au lieu d'espérer que votre projet gagnera spontanément en popularité. Soyez patient et continuez à partager votre travail avec ceux qui l'apprécient.

From f972cf1442212d889f82fd2436cc5d5703b6cb4b Mon Sep 17 00:00:00 2001
From: omahs <73983677+omahs@users.noreply.github.com>
Date: Sat, 2 Sep 2023 09:04:16 +0200
Subject: [PATCH 495/749] fix typo

---
 _articles/fr/getting-paid.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fr/getting-paid.md b/_articles/fr/getting-paid.md
index 1f70efd7f01..f04a67d2b12 100644
--- a/_articles/fr/getting-paid.md
+++ b/_articles/fr/getting-paid.md
@@ -16,7 +16,7 @@ Une grande partie du travail open source est volontaire. Par exemple, une person
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
-  Je cherchais un projet de programmation comme "hobby" qui me garderait occupé pendant la semaine autour de Noël. (...) J'avais un ordinateur à la maison, et pas grand-chose d'autre dans les mains. J'ai décidé d'écrire un interprèteur pour le nouveau langage de script auquel j'avais pensé récemment. (...) J'ai choisi Python comme titre de travail.
+  Je cherchais un projet de programmation comme "hobby" qui me garderait occupé pendant la semaine autour de Noël. (...) J'avais un ordinateur à la maison, et pas grand-chose d'autre dans les mains. J'ai décidé d'écrire un interpréteur pour le nouveau langage de script auquel j'avais pensé récemment. (...) J'ai choisi Python comme titre de travail.
   <p markdown="1" class="pquote-credit">
 — @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
   </p>

From 52057f375dd5a54022a1a9b515f08b180501923f Mon Sep 17 00:00:00 2001
From: omahs <73983677+omahs@users.noreply.github.com>
Date: Sat, 2 Sep 2023 09:06:36 +0200
Subject: [PATCH 496/749] fix typos

---
 _articles/fr/how-to-contribute.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md
index 79d9c25edf3..17a846fc4c6 100644
--- a/_articles/fr/how-to-contribute.md
+++ b/_articles/fr/how-to-contribute.md
@@ -247,7 +247,7 @@ Regardez l'activité des commits sur la branche principale. Sur GitHub, vous pou
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-  À quelle fréquence les gens commmits ? (Sur GitHub, vous pouvez le trouver en cliquant sur "Commits" dans la barre du haut.)
+  À quelle fréquence les gens commits ? (Sur GitHub, vous pouvez le trouver en cliquant sur "Commits" dans la barre du haut.)
   </label>
 </div>
 
@@ -497,7 +497,7 @@ Si vous faites une contribution et que personne ne répond, il est possible que
 
 Il est courant que l'on vous demande d'apporter des modifications à votre contribution, qu'il s'agisse de commentaires sur la portée de votre idée ou de modifications apportées à votre code.
 
-Quand quelqu'un demande des changements, soyez flexible. Ils ont pris le temps d'examiner votre contribution. Ouvrir une PR et passer a autre chose est une mauvaise idée. Si vous ne savez pas comment faire des changements, recherchez le problème, puis demandez de l'aide si vous en avez besoin.
+Quand quelqu'un demande des changements, soyez flexible. Ils ont pris le temps d'examiner votre contribution. Ouvrir une PR et passer à autre chose est une mauvaise idée. Si vous ne savez pas comment faire des changements, recherchez le problème, puis demandez de l'aide si vous en avez besoin.
 
 Si vous n'avez plus le temps de travailler sur le problème (par exemple, si la conversation dure depuis des mois et que votre situation a changé), informez le responsable pour qu'il n'attende pas de réponse. Quelqu'un d'autre peut être heureux de prendre le relais.
 

From 212dda9d473336c5b91b1431b496c1a70070c948 Mon Sep 17 00:00:00 2001
From: omahs <73983677+omahs@users.noreply.github.com>
Date: Sat, 2 Sep 2023 09:10:32 +0200
Subject: [PATCH 497/749] fix typos

---
 _articles/fr/legal.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index 4eae765f715..bda5d240cc2 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ée** ou **public**.
+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**.
 
 ![Créer un référentiel](/assets/images/legal/repo-create-name.png)
 
@@ -117,7 +117,7 @@ Si vous publiez un projet open source en tant qu'employé de l'entreprise, votre
 
 Pour le meilleur ou pour le pire, envisagez de les informer même s'il s'agit d'un projet personnel. Vous avez probablement avec votre entreprise un "accord IP d'employé" qui lui donne un certain contrôle sur vos projets, surtout s'ils sont liés à l'activité de l'entreprise ou si vous utilisez les ressources de l'entreprise pour développer le projet. Votre entreprise _devrait_ vous donner facilement la permission, et peut-être déjà à travers un accord de propriété intellectuelle favorable aux employés ou une politique d'entreprise. Sinon, vous pouvez négocier (par exemple, expliquer que votre projet répond aux objectifs d'apprentissage et de développement professionnel de l'entreprise pour vous), ou éviter de travailler sur votre projet jusqu'à ce que vous trouviez une meilleure entreprise.
 
-**Si vous êtes ouvrez la source d'un projet pour votre entreprise**, alors faites-le savoir. Votre équipe juridique a sans doute déjà des politiques de quelle licence open source (et peut-être un accord de contribution supplémentaire) à utiliser en fonction des besoins d'affaires de l'entreprise et de l'expertise assurant autour de votre projet est conforme aux licences de ses dépendances. Sinon, vous et ils ont de la chance! Votre équipe juridique devrait être impatiente de travailler avec vous pour comprendre ces choses. Quelques points à penser:
+**Si vous ouvrez la source d'un projet pour votre entreprise**, alors faites-le savoir. Votre équipe juridique a sans doute déjà des politiques de quelle licence open source (et peut-être un accord de contribution supplémentaire) à utiliser en fonction des besoins d'affaires de l'entreprise et de l'expertise assurant autour de votre projet est conforme aux licences de ses dépendances. Sinon, vous et ils ont de la chance! Votre équipe juridique devrait être impatiente de travailler avec vous pour comprendre ces choses. Quelques points à penser:
 
 * **Matériel de tiers :** Votre projet a-t-il des dépendances créées par d'autres ou inclut ou utilise le code d'autres personnes ? Si ceux-ci sont open source, vous devrez vous conformer aux licences open source des matériaux. Cela commence par choisir une licence qui fonctionne avec les licences open source tierces (voir ci-dessus). Si votre projet modifie ou distribue du matériel Open Source tiers, votre équipe juridique voudra également savoir que vous remplissez d'autres conditions des licences Open Source tierces, telles que la conservation des avis de copyright. Si votre projet utilise le code d'autres personnes n'ayant pas de licence Open Source, vous devrez probablement demander aux responsables de la maintenance tiers d'[ajouter une licence Open Source](https://choosealicense.com/no-license/#for-users), et si vous ne pouvez pas en obtenir un, arrêtez d'utiliser leur code dans votre projet.
 
@@ -143,7 +143,7 @@ Si vous publiez le premier projet open source de votre entreprise, ce qui préc
   </p>
 </aside>
 
-* **Que publier :** [(Presque) tout ?](Http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Si votre équipe juridique comprend et est investis dans la stratégie open source de votre entreprise, ils seront les mieux placés pour vous aider plutôt que d'entraver vos efforts.
+* **Que publier :** [(Presque) tout ?](Http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Si votre équipe juridique comprend et est investie dans la stratégie open source de votre entreprise, ils seront les mieux placés pour vous aider plutôt que d'entraver vos efforts.
 * **Conformité :** Même si votre entreprise ne diffuse aucun projet open source, elle utilise le logiciel open source des autres. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) peut prévenir les maux de tête, les retards de produit et les poursuites judiciaires.
 
 <aside markdown="1" class="pquote">
@@ -153,5 +153,5 @@ Si vous publiez le premier projet open source de votre entreprise, ce qui préc
   </p>
 </aside>
 
-* **Brevets :** Votre entreprise voudra peut-être rejoindre le [Open Invention Network](https://www.openinventionnetwork.com/), un pool de brevets défensif partagé pour protéger l'utilisation de projets open source majeurs par les membres, ou explorer autre [licence alternative de brevet](https://www.eff.org/document/hacking-patent-system-2016).
+* **Brevets :** Votre entreprise voudra peut-être rejoindre le [Open Invention Network](https://www.openinventionnetwork.com/), un pool de brevets défensif partagé pour protéger l'utilisation de projets open source majeurs par les membres, ou explorer une autre [licence alternative de brevet](https://www.eff.org/document/hacking-patent-system-2016).
 * **Gouvernance :** Surtout si et quand il est logique de transférer un projet à une [entité juridique extérieure à l'entreprise](../leadership-and-governance/#ai-je-besoin-dune-entit&eacute;-l&eacute;gale-pour-soutenir-mon-projet).

From 8f6c43c796fcb04fe8aca40242dcc7e12e36c01f Mon Sep 17 00:00:00 2001
From: omahs <73983677+omahs@users.noreply.github.com>
Date: Sat, 2 Sep 2023 09:12:24 +0200
Subject: [PATCH 498/749] fix typo

---
 _articles/fr/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fr/starting-a-project.md b/_articles/fr/starting-a-project.md
index dd62eb8b68b..f4b297c65f1 100644
--- a/_articles/fr/starting-a-project.md
+++ b/_articles/fr/starting-a-project.md
@@ -290,7 +290,7 @@ Prêt à lancer votre projet open source ? Voici une checklist pour vous aider.
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-    La liste des problèmes est à jour, avec des problèmes clairement organisés et labelisés
+    La liste des problèmes est à jour, avec des problèmes clairement organisés et labellisés
   </label>
 </div>
 

From f6e86e12e48f61c795f60c6ae6cd5ec872925e51 Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Sat, 2 Sep 2023 15:55:55 +0530
Subject: [PATCH 499/749] Hindi -- link updated

---
 _articles/hi/getting-paid.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/hi/getting-paid.md b/_articles/hi/getting-paid.md
index 9e56bccf3ae..7cada6b50b1 100644
--- a/_articles/hi/getting-paid.md
+++ b/_articles/hi/getting-paid.md
@@ -48,7 +48,7 @@ related:
   </p>
 </aside>
 
-भुगतान किया गया कार्य जीवन के विभिन्न क्षेत्रों के लोगों को सार्थक योगदान देने में भी सक्षम बनाता है। कुछ लोग अपनी वर्तमान वित्तीय स्थिति, ऋण, या परिवार या अन्य देखभाल संबंधी दायित्वों के आधार पर, ओपन सोर्स परियोजनाओं पर अवैतनिक समय बिताने का जोखिम नहीं उठा सकते हैं। इसका मतलब है कि दुनिया कभी भी उन प्रतिभाशाली लोगों के योगदान को नहीं देखती है जो स्वेच्छा से अपना समय नहीं दे सकते। इसके नैतिक निहितार्थ हैं, जैसा कि @ashedryden [ने वर्णन किया है](https://www.ashedryden.com/blog/the-ethics-of-unread-labor-and-the-oss-community), क्योंकि जो काम किया गया है वह है उन लोगों के पक्ष में पक्षपातपूर्ण जिनके पास पहले से ही जीवन में लाभ हैं, जो बाद में अपने स्वैच्छिक योगदान के आधार पर अतिरिक्त लाभ प्राप्त करते हैं, जबकि अन्य जो स्वयंसेवा करने में सक्षम नहीं होते हैं उन्हें बाद में अवसर नहीं मिलते हैं, जो खुले स्रोत में विविधता की वर्तमान कमी को मजबूत करता है समुदाय।
+भुगतान किया गया कार्य जीवन के विभिन्न क्षेत्रों के लोगों को सार्थक योगदान देने में भी सक्षम बनाता है। कुछ लोग अपनी वर्तमान वित्तीय स्थिति, ऋण, या परिवार या अन्य देखभाल संबंधी दायित्वों के आधार पर, ओपन सोर्स परियोजनाओं पर अवैतनिक समय बिताने का जोखिम नहीं उठा सकते हैं। इसका मतलब है कि दुनिया कभी भी उन प्रतिभाशाली लोगों के योगदान को नहीं देखती है जो स्वेच्छा से अपना समय नहीं दे सकते। इसके नैतिक निहितार्थ हैं, जैसा कि @ashedryden [ने वर्णन किया है](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), क्योंकि जो काम किया गया है वह है उन लोगों के पक्ष में पक्षपातपूर्ण जिनके पास पहले से ही जीवन में लाभ हैं, जो बाद में अपने स्वैच्छिक योगदान के आधार पर अतिरिक्त लाभ प्राप्त करते हैं, जबकि अन्य जो स्वयंसेवा करने में सक्षम नहीं होते हैं उन्हें बाद में अवसर नहीं मिलते हैं, जो खुले स्रोत में विविधता की वर्तमान कमी को मजबूत करता है समुदाय।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar"> 

From 1618dcc82dcbed019d324cde456a5801819622c1 Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Sat, 2 Sep 2023 16:05:10 +0530
Subject: [PATCH 500/749] hindi update

---
 _articles/hi/code-of-conduct.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/hi/code-of-conduct.md b/_articles/hi/code-of-conduct.md
index d39309320ae..bd1c46ae7a0 100644
--- a/_articles/hi/code-of-conduct.md
+++ b/_articles/hi/code-of-conduct.md
@@ -24,8 +24,8 @@ related:
 
 आपकी अपेक्षाओं को संप्रेषित करने के अलावा, आचार संहिता निम्नलिखित का वर्णन करती है:
 
-* जहां आचार संहिता प्रभावी होती है (केवल मुद्दों और पुल अनुरोधों, या घटनाओं जैसी सामुदायिक गतिविधियों पर?)
-*आचार संहिता किस पर लागू होती है (समुदाय के सदस्यों और अनुरक्षकों पर, लेकिन प्रायोजकों के बारे में क्या?)
+* जहां आचार संहिता प्रभावी होती है _(केवल मुद्दों और पुल अनुरोधों, या घटनाओं जैसी सामुदायिक गतिविधियों पर?)_
+*आचार संहिता किस पर लागू होती है _(समुदाय के सदस्यों और अनुरक्षकों पर, लेकिन प्रायोजकों के बारे में क्या?)_
 *यदि कोई आचार संहिता का उल्लंघन करता है तो क्या होगा
 * कोई कैसे उल्लंघन की रिपोर्ट कर सकता है
 

From 1b4f5fcbb81a86b81bff4c11ca2841ce72df31cc Mon Sep 17 00:00:00 2001
From: Joseph Hale <me@jhale.dev>
Date: Sat, 2 Sep 2023 16:08:20 -0700
Subject: [PATCH 501/749] Update legal.md

- Simplify the legalese in a few places
- Add more links to licenses and data behind various claims
- Add more descriptions for different classes of licenses.
- Improve internal linking within the article.
---
 _articles/legal.md | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/_articles/legal.md b/_articles/legal.md
index 8adc3897659..a64a77cd167 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -12,7 +12,7 @@ related:
 
 ## Understanding the legal implications of open source
 
-Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this legal crash course you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).)
 
 ## Why do people care so much about the legal side of open source?
 
@@ -20,9 +20,9 @@ Glad you asked! When you make a creative work (such as writing, graphics, or cod
 
 In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
 
-Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly state these permissions in a document called a license.
 
-If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions.
 
 Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
 
@@ -40,7 +40,7 @@ If you want others to use, distribute, modify, or contribute back to your projec
 
 You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
 
-[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 the most popular open source 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/).
+[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 the [most popular open source licenses](https://libraries.io/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/).
 
@@ -54,21 +54,23 @@ When you create a new project on GitHub, you'll be [asked to add a license](http
 
 ## Which open source license is appropriate for my project?
 
-If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+It's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/) if you're starting with a blank slate. It's short, easily understood, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
 
 Otherwise, picking the right open source license for your project depends on your objectives.
 
-Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+Your project very likely has (or will have) **dependencies**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm).
 
-On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+* **"Permissive" licenses** give you permission to use, modify, and share the library without any conditions on how you license your project. Common permissive licenses include [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause).
+* **"Limited copyleft" licenses** (sometimes called "weak copyleft") are similar to permissive licenses -- generally your project can use whatever license you want -- but modifications to the library itself must be shared under an identical/compatible license. Common limited copyleft licenses include the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and the [LGPL](https://choosealicense.com/licenses/lgpl-3.0/).
+* **"Strong copyleft" licenses** also give you permission to use, modify, and share the library, but only if your project uses an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses). Common strong copyleft licenses include [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), and [AGPLv3](https://choosealicense.com/licenses/agpl-3.0).
 
 You may also want to consider the **communities** you hope will use and contribute to your project:
 
 * **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
-* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
+* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors and the ability to use the project in proprietary software. In this case, the permissive [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) or the limited copyleft [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) has you (and them) covered.
 * **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
 
-Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive or limited copyleft license so your project can be used in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
 
 When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
 
@@ -84,7 +86,7 @@ For example, as your project grows it adds dependencies or users, or your compan
 
 **Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
 
-Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- [see below](#does-my-project-need-an-additional-contributor-agreement)) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
 
 ## Does my project need an additional contributor agreement?
 
@@ -120,11 +122,11 @@ For better or worse, consider letting them know even if it's a personal project.
 
 **If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
 
-* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses ([see above](#which-open-source-license-is-appropriate-for-my-project)). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
 
 * **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
 
-* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
+* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement ([see above](#which-open-source-license-is-appropriate-for-my-project)).
 
 * **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
 

From 51412a9c4c36bcd73d0e2030841204fc01962944 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 5 Sep 2023 04:50:05 +0000
Subject: [PATCH 502/749] Bump actions/checkout from 3 to 4

Bumps [actions/checkout](https://github.com/actions/checkout) from 3 to 4.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v3...v4)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/jekyll-preview.yml | 2 +-
 .github/workflows/jekyll.yml         | 2 +-
 .github/workflows/tests.yml          | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index 288147b7d67..57cef2b5854 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -32,7 +32,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
         with:
           # For PRs make sure to checkout the PR branch
           ref: ${{ github.event.pull_request.head.ref }}
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index ad9142234c3..2d280c8de2e 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -32,7 +32,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
       - name: Setup Pages
         uses: actions/configure-pages@v3
       - name: Build with Jekyll
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index d1e7bd1955e..7c2c57a47ec 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -9,7 +9,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
     - name: Set up Git repository
-      uses: actions/checkout@v3
+      uses: actions/checkout@v4
 
     - name: Set up Ruby
       uses: ruby/setup-ruby@v1

From 788c5d0f6385cb0040a868b0f7999eb01d7e1402 Mon Sep 17 00:00:00 2001
From: Zack Koppert <zkoppert@github.com>
Date: Thu, 7 Sep 2023 14:34:19 -0700
Subject: [PATCH 503/749] Update jquery.min.js to v3.7.1

---
 assets/js/jquery.min.js | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/assets/js/jquery.min.js b/assets/js/jquery.min.js
index 4c5be4c0fbe..7f37b5d9912 100644
--- a/assets/js/jquery.min.js
+++ b/assets/js/jquery.min.js
@@ -1,4 +1,2 @@
-/*! jQuery v3.1.1 | (c) jQuery Foundation | jquery.org/license */
-!function(a,b){"use strict";"object"==typeof module&&"object"==typeof module.exports?module.exports=a.document?b(a,!0):function(a){if(!a.document)throw new Error("jQuery requires a window with a document");return b(a)}:b(a)}("undefined"!=typeof window?window:this,function(a,b){"use strict";var c=[],d=a.document,e=Object.getPrototypeOf,f=c.slice,g=c.concat,h=c.push,i=c.indexOf,j={},k=j.toString,l=j.hasOwnProperty,m=l.toString,n=m.call(Object),o={};function p(a,b){b=b||d;var c=b.createElement("script");c.text=a,b.head.appendChild(c).parentNode.removeChild(c)}var q="3.1.1",r=function(a,b){return new r.fn.init(a,b)},s=/^[\s\uFEFF\xA0]+|[\s\uFEFF\xA0]+$/g,t=/^-ms-/,u=/-([a-z])/g,v=function(a,b){return b.toUpperCase()};r.fn=r.prototype={jquery:q,constructor:r,length:0,toArray:function(){return f.call(this)},get:function(a){return null==a?f.call(this):a<0?this[a+this.length]:this[a]},pushStack:function(a){var b=r.merge(this.constructor(),a);return b.prevObject=this,b},each:function(a){return r.each(this,a)},map:function(a){return this.pushStack(r.map(this,function(b,c){return a.call(b,c,b)}))},slice:function(){return this.pushStack(f.apply(this,arguments))},first:function(){return this.eq(0)},last:function(){return this.eq(-1)},eq:function(a){var b=this.length,c=+a+(a<0?b:0);return this.pushStack(c>=0&&c<b?[this[c]]:[])},end:function(){return this.prevObject||this.constructor()},push:h,sort:c.sort,splice:c.splice},r.extend=r.fn.extend=function(){var a,b,c,d,e,f,g=arguments[0]||{},h=1,i=arguments.length,j=!1;for("boolean"==typeof g&&(j=g,g=arguments[h]||{},h++),"object"==typeof g||r.isFunction(g)||(g={}),h===i&&(g=this,h--);h<i;h++)if(null!=(a=arguments[h]))for(b in a)c=g[b],d=a[b],g!==d&&(j&&d&&(r.isPlainObject(d)||(e=r.isArray(d)))?(e?(e=!1,f=c&&r.isArray(c)?c:[]):f=c&&r.isPlainObject(c)?c:{},g[b]=r.extend(j,f,d)):void 0!==d&&(g[b]=d));return g},r.extend({expando:"jQuery"+(q+Math.random()).replace(/\D/g,""),isReady:!0,error:function(a){throw new Error(a)},noop:function(){},isFunction:function(a){return"function"===r.type(a)},isArray:Array.isArray,isWindow:function(a){return null!=a&&a===a.window},isNumeric:function(a){var b=r.type(a);return("number"===b||"string"===b)&&!isNaN(a-parseFloat(a))},isPlainObject:function(a){var b,c;return!(!a||"[object Object]"!==k.call(a))&&(!(b=e(a))||(c=l.call(b,"constructor")&&b.constructor,"function"==typeof c&&m.call(c)===n))},isEmptyObject:function(a){var b;for(b in a)return!1;return!0},type:function(a){return null==a?a+"":"object"==typeof a||"function"==typeof a?j[k.call(a)]||"object":typeof a},globalEval:function(a){p(a)},camelCase:function(a){return a.replace(t,"ms-").replace(u,v)},nodeName:function(a,b){return a.nodeName&&a.nodeName.toLowerCase()===b.toLowerCase()},each:function(a,b){var c,d=0;if(w(a)){for(c=a.length;d<c;d++)if(b.call(a[d],d,a[d])===!1)break}else for(d in a)if(b.call(a[d],d,a[d])===!1)break;return a},trim:function(a){return null==a?"":(a+"").replace(s,"")},makeArray:function(a,b){var c=b||[];return null!=a&&(w(Object(a))?r.merge(c,"string"==typeof a?[a]:a):h.call(c,a)),c},inArray:function(a,b,c){return null==b?-1:i.call(b,a,c)},merge:function(a,b){for(var c=+b.length,d=0,e=a.length;d<c;d++)a[e++]=b[d];return a.length=e,a},grep:function(a,b,c){for(var d,e=[],f=0,g=a.length,h=!c;f<g;f++)d=!b(a[f],f),d!==h&&e.push(a[f]);return e},map:function(a,b,c){var d,e,f=0,h=[];if(w(a))for(d=a.length;f<d;f++)e=b(a[f],f,c),null!=e&&h.push(e);else for(f in a)e=b(a[f],f,c),null!=e&&h.push(e);return g.apply([],h)},guid:1,proxy:function(a,b){var c,d,e;if("string"==typeof b&&(c=a[b],b=a,a=c),r.isFunction(a))return d=f.call(arguments,2),e=function(){return a.apply(b||this,d.concat(f.call(arguments)))},e.guid=a.guid=a.guid||r.guid++,e},now:Date.now,support:o}),"function"==typeof Symbol&&(r.fn[Symbol.iterator]=c[Symbol.iterator]),r.each("Boolean Number String Function Array Date RegExp Object Error Symbol".split(" "),function(a,b){j["[object "+b+"]"]=b.toLowerCase()});function w(a){var b=!!a&&"length"in a&&a.length,c=r.type(a);return"function"!==c&&!r.isWindow(a)&&("array"===c||0===b||"number"==typeof b&&b>0&&b-1 in a)}var x=function(a){var b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u="sizzle"+1*new Date,v=a.document,w=0,x=0,y=ha(),z=ha(),A=ha(),B=function(a,b){return a===b&&(l=!0),0},C={}.hasOwnProperty,D=[],E=D.pop,F=D.push,G=D.push,H=D.slice,I=function(a,b){for(var c=0,d=a.length;c<d;c++)if(a[c]===b)return c;return-1},J="checked|selected|async|autofocus|autoplay|controls|defer|disabled|hidden|ismap|loop|multiple|open|readonly|required|scoped",K="[\\x20\\t\\r\\n\\f]",L="(?:\\\\.|[\\w-]|[^\0-\\xa0])+",M="\\["+K+"*("+L+")(?:"+K+"*([*^$|!~]?=)"+K+"*(?:'((?:\\\\.|[^\\\\'])*)'|\"((?:\\\\.|[^\\\\\"])*)\"|("+L+"))|)"+K+"*\\]",N=":("+L+")(?:\\((('((?:\\\\.|[^\\\\'])*)'|\"((?:\\\\.|[^\\\\\"])*)\")|((?:\\\\.|[^\\\\()[\\]]|"+M+")*)|.*)\\)|)",O=new RegExp(K+"+","g"),P=new RegExp("^"+K+"+|((?:^|[^\\\\])(?:\\\\.)*)"+K+"+$","g"),Q=new RegExp("^"+K+"*,"+K+"*"),R=new RegExp("^"+K+"*([>+~]|"+K+")"+K+"*"),S=new RegExp("="+K+"*([^\\]'\"]*?)"+K+"*\\]","g"),T=new RegExp(N),U=new RegExp("^"+L+"$"),V={ID:new RegExp("^#("+L+")"),CLASS:new RegExp("^\\.("+L+")"),TAG:new RegExp("^("+L+"|[*])"),ATTR:new RegExp("^"+M),PSEUDO:new RegExp("^"+N),CHILD:new RegExp("^:(only|first|last|nth|nth-last)-(child|of-type)(?:\\("+K+"*(even|odd|(([+-]|)(\\d*)n|)"+K+"*(?:([+-]|)"+K+"*(\\d+)|))"+K+"*\\)|)","i"),bool:new RegExp("^(?:"+J+")$","i"),needsContext:new RegExp("^"+K+"*[>+~]|:(even|odd|eq|gt|lt|nth|first|last)(?:\\("+K+"*((?:-\\d)?\\d*)"+K+"*\\)|)(?=[^-]|$)","i")},W=/^(?:input|select|textarea|button)$/i,X=/^h\d$/i,Y=/^[^{]+\{\s*\[native \w/,Z=/^(?:#([\w-]+)|(\w+)|\.([\w-]+))$/,$=/[+~]/,_=new RegExp("\\\\([\\da-f]{1,6}"+K+"?|("+K+")|.)","ig"),aa=function(a,b,c){var d="0x"+b-65536;return d!==d||c?b:d<0?String.fromCharCode(d+65536):String.fromCharCode(d>>10|55296,1023&d|56320)},ba=/([\0-\x1f\x7f]|^-?\d)|^-$|[^\0-\x1f\x7f-\uFFFF\w-]/g,ca=function(a,b){return b?"\0"===a?"\ufffd":a.slice(0,-1)+"\\"+a.charCodeAt(a.length-1).toString(16)+" ":"\\"+a},da=function(){m()},ea=ta(function(a){return a.disabled===!0&&("form"in a||"label"in a)},{dir:"parentNode",next:"legend"});try{G.apply(D=H.call(v.childNodes),v.childNodes),D[v.childNodes.length].nodeType}catch(fa){G={apply:D.length?function(a,b){F.apply(a,H.call(b))}:function(a,b){var c=a.length,d=0;while(a[c++]=b[d++]);a.length=c-1}}}function ga(a,b,d,e){var f,h,j,k,l,o,r,s=b&&b.ownerDocument,w=b?b.nodeType:9;if(d=d||[],"string"!=typeof a||!a||1!==w&&9!==w&&11!==w)return d;if(!e&&((b?b.ownerDocument||b:v)!==n&&m(b),b=b||n,p)){if(11!==w&&(l=Z.exec(a)))if(f=l[1]){if(9===w){if(!(j=b.getElementById(f)))return d;if(j.id===f)return d.push(j),d}else if(s&&(j=s.getElementById(f))&&t(b,j)&&j.id===f)return d.push(j),d}else{if(l[2])return G.apply(d,b.getElementsByTagName(a)),d;if((f=l[3])&&c.getElementsByClassName&&b.getElementsByClassName)return G.apply(d,b.getElementsByClassName(f)),d}if(c.qsa&&!A[a+" "]&&(!q||!q.test(a))){if(1!==w)s=b,r=a;else if("object"!==b.nodeName.toLowerCase()){(k=b.getAttribute("id"))?k=k.replace(ba,ca):b.setAttribute("id",k=u),o=g(a),h=o.length;while(h--)o[h]="#"+k+" "+sa(o[h]);r=o.join(","),s=$.test(a)&&qa(b.parentNode)||b}if(r)try{return G.apply(d,s.querySelectorAll(r)),d}catch(x){}finally{k===u&&b.removeAttribute("id")}}}return i(a.replace(P,"$1"),b,d,e)}function ha(){var a=[];function b(c,e){return a.push(c+" ")>d.cacheLength&&delete b[a.shift()],b[c+" "]=e}return b}function ia(a){return a[u]=!0,a}function ja(a){var b=n.createElement("fieldset");try{return!!a(b)}catch(c){return!1}finally{b.parentNode&&b.parentNode.removeChild(b),b=null}}function ka(a,b){var c=a.split("|"),e=c.length;while(e--)d.attrHandle[c[e]]=b}function la(a,b){var c=b&&a,d=c&&1===a.nodeType&&1===b.nodeType&&a.sourceIndex-b.sourceIndex;if(d)return d;if(c)while(c=c.nextSibling)if(c===b)return-1;return a?1:-1}function ma(a){return function(b){var c=b.nodeName.toLowerCase();return"input"===c&&b.type===a}}function na(a){return function(b){var c=b.nodeName.toLowerCase();return("input"===c||"button"===c)&&b.type===a}}function oa(a){return function(b){return"form"in b?b.parentNode&&b.disabled===!1?"label"in b?"label"in b.parentNode?b.parentNode.disabled===a:b.disabled===a:b.isDisabled===a||b.isDisabled!==!a&&ea(b)===a:b.disabled===a:"label"in b&&b.disabled===a}}function pa(a){return ia(function(b){return b=+b,ia(function(c,d){var e,f=a([],c.length,b),g=f.length;while(g--)c[e=f[g]]&&(c[e]=!(d[e]=c[e]))})})}function qa(a){return a&&"undefined"!=typeof a.getElementsByTagName&&a}c=ga.support={},f=ga.isXML=function(a){var b=a&&(a.ownerDocument||a).documentElement;return!!b&&"HTML"!==b.nodeName},m=ga.setDocument=function(a){var b,e,g=a?a.ownerDocument||a:v;return g!==n&&9===g.nodeType&&g.documentElement?(n=g,o=n.documentElement,p=!f(n),v!==n&&(e=n.defaultView)&&e.top!==e&&(e.addEventListener?e.addEventListener("unload",da,!1):e.attachEvent&&e.attachEvent("onunload",da)),c.attributes=ja(function(a){return a.className="i",!a.getAttribute("className")}),c.getElementsByTagName=ja(function(a){return a.appendChild(n.createComment("")),!a.getElementsByTagName("*").length}),c.getElementsByClassName=Y.test(n.getElementsByClassName),c.getById=ja(function(a){return o.appendChild(a).id=u,!n.getElementsByName||!n.getElementsByName(u).length}),c.getById?(d.filter.ID=function(a){var b=a.replace(_,aa);return function(a){return a.getAttribute("id")===b}},d.find.ID=function(a,b){if("undefined"!=typeof b.getElementById&&p){var c=b.getElementById(a);return c?[c]:[]}}):(d.filter.ID=function(a){var b=a.replace(_,aa);return function(a){var c="undefined"!=typeof a.getAttributeNode&&a.getAttributeNode("id");return c&&c.value===b}},d.find.ID=function(a,b){if("undefined"!=typeof b.getElementById&&p){var c,d,e,f=b.getElementById(a);if(f){if(c=f.getAttributeNode("id"),c&&c.value===a)return[f];e=b.getElementsByName(a),d=0;while(f=e[d++])if(c=f.getAttributeNode("id"),c&&c.value===a)return[f]}return[]}}),d.find.TAG=c.getElementsByTagName?function(a,b){return"undefined"!=typeof b.getElementsByTagName?b.getElementsByTagName(a):c.qsa?b.querySelectorAll(a):void 0}:function(a,b){var c,d=[],e=0,f=b.getElementsByTagName(a);if("*"===a){while(c=f[e++])1===c.nodeType&&d.push(c);return d}return f},d.find.CLASS=c.getElementsByClassName&&function(a,b){if("undefined"!=typeof b.getElementsByClassName&&p)return b.getElementsByClassName(a)},r=[],q=[],(c.qsa=Y.test(n.querySelectorAll))&&(ja(function(a){o.appendChild(a).innerHTML="<a id='"+u+"'></a><select id='"+u+"-\r\\' msallowcapture=''><option selected=''></option></select>",a.querySelectorAll("[msallowcapture^='']").length&&q.push("[*^$]="+K+"*(?:''|\"\")"),a.querySelectorAll("[selected]").length||q.push("\\["+K+"*(?:value|"+J+")"),a.querySelectorAll("[id~="+u+"-]").length||q.push("~="),a.querySelectorAll(":checked").length||q.push(":checked"),a.querySelectorAll("a#"+u+"+*").length||q.push(".#.+[+~]")}),ja(function(a){a.innerHTML="<a href='' disabled='disabled'></a><select disabled='disabled'><option/></select>";var b=n.createElement("input");b.setAttribute("type","hidden"),a.appendChild(b).setAttribute("name","D"),a.querySelectorAll("[name=d]").length&&q.push("name"+K+"*[*^$|!~]?="),2!==a.querySelectorAll(":enabled").length&&q.push(":enabled",":disabled"),o.appendChild(a).disabled=!0,2!==a.querySelectorAll(":disabled").length&&q.push(":enabled",":disabled"),a.querySelectorAll("*,:x"),q.push(",.*:")})),(c.matchesSelector=Y.test(s=o.matches||o.webkitMatchesSelector||o.mozMatchesSelector||o.oMatchesSelector||o.msMatchesSelector))&&ja(function(a){c.disconnectedMatch=s.call(a,"*"),s.call(a,"[s!='']:x"),r.push("!=",N)}),q=q.length&&new RegExp(q.join("|")),r=r.length&&new RegExp(r.join("|")),b=Y.test(o.compareDocumentPosition),t=b||Y.test(o.contains)?function(a,b){var c=9===a.nodeType?a.documentElement:a,d=b&&b.parentNode;return a===d||!(!d||1!==d.nodeType||!(c.contains?c.contains(d):a.compareDocumentPosition&&16&a.compareDocumentPosition(d)))}:function(a,b){if(b)while(b=b.parentNode)if(b===a)return!0;return!1},B=b?function(a,b){if(a===b)return l=!0,0;var d=!a.compareDocumentPosition-!b.compareDocumentPosition;return d?d:(d=(a.ownerDocument||a)===(b.ownerDocument||b)?a.compareDocumentPosition(b):1,1&d||!c.sortDetached&&b.compareDocumentPosition(a)===d?a===n||a.ownerDocument===v&&t(v,a)?-1:b===n||b.ownerDocument===v&&t(v,b)?1:k?I(k,a)-I(k,b):0:4&d?-1:1)}:function(a,b){if(a===b)return l=!0,0;var c,d=0,e=a.parentNode,f=b.parentNode,g=[a],h=[b];if(!e||!f)return a===n?-1:b===n?1:e?-1:f?1:k?I(k,a)-I(k,b):0;if(e===f)return la(a,b);c=a;while(c=c.parentNode)g.unshift(c);c=b;while(c=c.parentNode)h.unshift(c);while(g[d]===h[d])d++;return d?la(g[d],h[d]):g[d]===v?-1:h[d]===v?1:0},n):n},ga.matches=function(a,b){return ga(a,null,null,b)},ga.matchesSelector=function(a,b){if((a.ownerDocument||a)!==n&&m(a),b=b.replace(S,"='$1']"),c.matchesSelector&&p&&!A[b+" "]&&(!r||!r.test(b))&&(!q||!q.test(b)))try{var d=s.call(a,b);if(d||c.disconnectedMatch||a.document&&11!==a.document.nodeType)return d}catch(e){}return ga(b,n,null,[a]).length>0},ga.contains=function(a,b){return(a.ownerDocument||a)!==n&&m(a),t(a,b)},ga.attr=function(a,b){(a.ownerDocument||a)!==n&&m(a);var e=d.attrHandle[b.toLowerCase()],f=e&&C.call(d.attrHandle,b.toLowerCase())?e(a,b,!p):void 0;return void 0!==f?f:c.attributes||!p?a.getAttribute(b):(f=a.getAttributeNode(b))&&f.specified?f.value:null},ga.escape=function(a){return(a+"").replace(ba,ca)},ga.error=function(a){throw new Error("Syntax error, unrecognized expression: "+a)},ga.uniqueSort=function(a){var b,d=[],e=0,f=0;if(l=!c.detectDuplicates,k=!c.sortStable&&a.slice(0),a.sort(B),l){while(b=a[f++])b===a[f]&&(e=d.push(f));while(e--)a.splice(d[e],1)}return k=null,a},e=ga.getText=function(a){var b,c="",d=0,f=a.nodeType;if(f){if(1===f||9===f||11===f){if("string"==typeof a.textContent)return a.textContent;for(a=a.firstChild;a;a=a.nextSibling)c+=e(a)}else if(3===f||4===f)return a.nodeValue}else while(b=a[d++])c+=e(b);return c},d=ga.selectors={cacheLength:50,createPseudo:ia,match:V,attrHandle:{},find:{},relative:{">":{dir:"parentNode",first:!0}," ":{dir:"parentNode"},"+":{dir:"previousSibling",first:!0},"~":{dir:"previousSibling"}},preFilter:{ATTR:function(a){return a[1]=a[1].replace(_,aa),a[3]=(a[3]||a[4]||a[5]||"").replace(_,aa),"~="===a[2]&&(a[3]=" "+a[3]+" "),a.slice(0,4)},CHILD:function(a){return a[1]=a[1].toLowerCase(),"nth"===a[1].slice(0,3)?(a[3]||ga.error(a[0]),a[4]=+(a[4]?a[5]+(a[6]||1):2*("even"===a[3]||"odd"===a[3])),a[5]=+(a[7]+a[8]||"odd"===a[3])):a[3]&&ga.error(a[0]),a},PSEUDO:function(a){var b,c=!a[6]&&a[2];return V.CHILD.test(a[0])?null:(a[3]?a[2]=a[4]||a[5]||"":c&&T.test(c)&&(b=g(c,!0))&&(b=c.indexOf(")",c.length-b)-c.length)&&(a[0]=a[0].slice(0,b),a[2]=c.slice(0,b)),a.slice(0,3))}},filter:{TAG:function(a){var b=a.replace(_,aa).toLowerCase();return"*"===a?function(){return!0}:function(a){return a.nodeName&&a.nodeName.toLowerCase()===b}},CLASS:function(a){var b=y[a+" "];return b||(b=new RegExp("(^|"+K+")"+a+"("+K+"|$)"))&&y(a,function(a){return b.test("string"==typeof a.className&&a.className||"undefined"!=typeof a.getAttribute&&a.getAttribute("class")||"")})},ATTR:function(a,b,c){return function(d){var e=ga.attr(d,a);return null==e?"!="===b:!b||(e+="","="===b?e===c:"!="===b?e!==c:"^="===b?c&&0===e.indexOf(c):"*="===b?c&&e.indexOf(c)>-1:"$="===b?c&&e.slice(-c.length)===c:"~="===b?(" "+e.replace(O," ")+" ").indexOf(c)>-1:"|="===b&&(e===c||e.slice(0,c.length+1)===c+"-"))}},CHILD:function(a,b,c,d,e){var f="nth"!==a.slice(0,3),g="last"!==a.slice(-4),h="of-type"===b;return 1===d&&0===e?function(a){return!!a.parentNode}:function(b,c,i){var j,k,l,m,n,o,p=f!==g?"nextSibling":"previousSibling",q=b.parentNode,r=h&&b.nodeName.toLowerCase(),s=!i&&!h,t=!1;if(q){if(f){while(p){m=b;while(m=m[p])if(h?m.nodeName.toLowerCase()===r:1===m.nodeType)return!1;o=p="only"===a&&!o&&"nextSibling"}return!0}if(o=[g?q.firstChild:q.lastChild],g&&s){m=q,l=m[u]||(m[u]={}),k=l[m.uniqueID]||(l[m.uniqueID]={}),j=k[a]||[],n=j[0]===w&&j[1],t=n&&j[2],m=n&&q.childNodes[n];while(m=++n&&m&&m[p]||(t=n=0)||o.pop())if(1===m.nodeType&&++t&&m===b){k[a]=[w,n,t];break}}else if(s&&(m=b,l=m[u]||(m[u]={}),k=l[m.uniqueID]||(l[m.uniqueID]={}),j=k[a]||[],n=j[0]===w&&j[1],t=n),t===!1)while(m=++n&&m&&m[p]||(t=n=0)||o.pop())if((h?m.nodeName.toLowerCase()===r:1===m.nodeType)&&++t&&(s&&(l=m[u]||(m[u]={}),k=l[m.uniqueID]||(l[m.uniqueID]={}),k[a]=[w,t]),m===b))break;return t-=e,t===d||t%d===0&&t/d>=0}}},PSEUDO:function(a,b){var c,e=d.pseudos[a]||d.setFilters[a.toLowerCase()]||ga.error("unsupported pseudo: "+a);return e[u]?e(b):e.length>1?(c=[a,a,"",b],d.setFilters.hasOwnProperty(a.toLowerCase())?ia(function(a,c){var d,f=e(a,b),g=f.length;while(g--)d=I(a,f[g]),a[d]=!(c[d]=f[g])}):function(a){return e(a,0,c)}):e}},pseudos:{not:ia(function(a){var b=[],c=[],d=h(a.replace(P,"$1"));return d[u]?ia(function(a,b,c,e){var f,g=d(a,null,e,[]),h=a.length;while(h--)(f=g[h])&&(a[h]=!(b[h]=f))}):function(a,e,f){return b[0]=a,d(b,null,f,c),b[0]=null,!c.pop()}}),has:ia(function(a){return function(b){return ga(a,b).length>0}}),contains:ia(function(a){return a=a.replace(_,aa),function(b){return(b.textContent||b.innerText||e(b)).indexOf(a)>-1}}),lang:ia(function(a){return U.test(a||"")||ga.error("unsupported lang: "+a),a=a.replace(_,aa).toLowerCase(),function(b){var c;do if(c=p?b.lang:b.getAttribute("xml:lang")||b.getAttribute("lang"))return c=c.toLowerCase(),c===a||0===c.indexOf(a+"-");while((b=b.parentNode)&&1===b.nodeType);return!1}}),target:function(b){var c=a.location&&a.location.hash;return c&&c.slice(1)===b.id},root:function(a){return a===o},focus:function(a){return a===n.activeElement&&(!n.hasFocus||n.hasFocus())&&!!(a.type||a.href||~a.tabIndex)},enabled:oa(!1),disabled:oa(!0),checked:function(a){var b=a.nodeName.toLowerCase();return"input"===b&&!!a.checked||"option"===b&&!!a.selected},selected:function(a){return a.parentNode&&a.parentNode.selectedIndex,a.selected===!0},empty:function(a){for(a=a.firstChild;a;a=a.nextSibling)if(a.nodeType<6)return!1;return!0},parent:function(a){return!d.pseudos.empty(a)},header:function(a){return X.test(a.nodeName)},input:function(a){return W.test(a.nodeName)},button:function(a){var b=a.nodeName.toLowerCase();return"input"===b&&"button"===a.type||"button"===b},text:function(a){var b;return"input"===a.nodeName.toLowerCase()&&"text"===a.type&&(null==(b=a.getAttribute("type"))||"text"===b.toLowerCase())},first:pa(function(){return[0]}),last:pa(function(a,b){return[b-1]}),eq:pa(function(a,b,c){return[c<0?c+b:c]}),even:pa(function(a,b){for(var c=0;c<b;c+=2)a.push(c);return a}),odd:pa(function(a,b){for(var c=1;c<b;c+=2)a.push(c);return a}),lt:pa(function(a,b,c){for(var d=c<0?c+b:c;--d>=0;)a.push(d);return a}),gt:pa(function(a,b,c){for(var d=c<0?c+b:c;++d<b;)a.push(d);return a})}},d.pseudos.nth=d.pseudos.eq;for(b in{radio:!0,checkbox:!0,file:!0,password:!0,image:!0})d.pseudos[b]=ma(b);for(b in{submit:!0,reset:!0})d.pseudos[b]=na(b);function ra(){}ra.prototype=d.filters=d.pseudos,d.setFilters=new ra,g=ga.tokenize=function(a,b){var c,e,f,g,h,i,j,k=z[a+" "];if(k)return b?0:k.slice(0);h=a,i=[],j=d.preFilter;while(h){c&&!(e=Q.exec(h))||(e&&(h=h.slice(e[0].length)||h),i.push(f=[])),c=!1,(e=R.exec(h))&&(c=e.shift(),f.push({value:c,type:e[0].replace(P," ")}),h=h.slice(c.length));for(g in d.filter)!(e=V[g].exec(h))||j[g]&&!(e=j[g](e))||(c=e.shift(),f.push({value:c,type:g,matches:e}),h=h.slice(c.length));if(!c)break}return b?h.length:h?ga.error(a):z(a,i).slice(0)};function sa(a){for(var b=0,c=a.length,d="";b<c;b++)d+=a[b].value;return d}function ta(a,b,c){var d=b.dir,e=b.next,f=e||d,g=c&&"parentNode"===f,h=x++;return b.first?function(b,c,e){while(b=b[d])if(1===b.nodeType||g)return a(b,c,e);return!1}:function(b,c,i){var j,k,l,m=[w,h];if(i){while(b=b[d])if((1===b.nodeType||g)&&a(b,c,i))return!0}else while(b=b[d])if(1===b.nodeType||g)if(l=b[u]||(b[u]={}),k=l[b.uniqueID]||(l[b.uniqueID]={}),e&&e===b.nodeName.toLowerCase())b=b[d]||b;else{if((j=k[f])&&j[0]===w&&j[1]===h)return m[2]=j[2];if(k[f]=m,m[2]=a(b,c,i))return!0}return!1}}function ua(a){return a.length>1?function(b,c,d){var e=a.length;while(e--)if(!a[e](b,c,d))return!1;return!0}:a[0]}function va(a,b,c){for(var d=0,e=b.length;d<e;d++)ga(a,b[d],c);return c}function wa(a,b,c,d,e){for(var f,g=[],h=0,i=a.length,j=null!=b;h<i;h++)(f=a[h])&&(c&&!c(f,d,e)||(g.push(f),j&&b.push(h)));return g}function xa(a,b,c,d,e,f){return d&&!d[u]&&(d=xa(d)),e&&!e[u]&&(e=xa(e,f)),ia(function(f,g,h,i){var j,k,l,m=[],n=[],o=g.length,p=f||va(b||"*",h.nodeType?[h]:h,[]),q=!a||!f&&b?p:wa(p,m,a,h,i),r=c?e||(f?a:o||d)?[]:g:q;if(c&&c(q,r,h,i),d){j=wa(r,n),d(j,[],h,i),k=j.length;while(k--)(l=j[k])&&(r[n[k]]=!(q[n[k]]=l))}if(f){if(e||a){if(e){j=[],k=r.length;while(k--)(l=r[k])&&j.push(q[k]=l);e(null,r=[],j,i)}k=r.length;while(k--)(l=r[k])&&(j=e?I(f,l):m[k])>-1&&(f[j]=!(g[j]=l))}}else r=wa(r===g?r.splice(o,r.length):r),e?e(null,g,r,i):G.apply(g,r)})}function ya(a){for(var b,c,e,f=a.length,g=d.relative[a[0].type],h=g||d.relative[" "],i=g?1:0,k=ta(function(a){return a===b},h,!0),l=ta(function(a){return I(b,a)>-1},h,!0),m=[function(a,c,d){var e=!g&&(d||c!==j)||((b=c).nodeType?k(a,c,d):l(a,c,d));return b=null,e}];i<f;i++)if(c=d.relative[a[i].type])m=[ta(ua(m),c)];else{if(c=d.filter[a[i].type].apply(null,a[i].matches),c[u]){for(e=++i;e<f;e++)if(d.relative[a[e].type])break;return xa(i>1&&ua(m),i>1&&sa(a.slice(0,i-1).concat({value:" "===a[i-2].type?"*":""})).replace(P,"$1"),c,i<e&&ya(a.slice(i,e)),e<f&&ya(a=a.slice(e)),e<f&&sa(a))}m.push(c)}return ua(m)}function za(a,b){var c=b.length>0,e=a.length>0,f=function(f,g,h,i,k){var l,o,q,r=0,s="0",t=f&&[],u=[],v=j,x=f||e&&d.find.TAG("*",k),y=w+=null==v?1:Math.random()||.1,z=x.length;for(k&&(j=g===n||g||k);s!==z&&null!=(l=x[s]);s++){if(e&&l){o=0,g||l.ownerDocument===n||(m(l),h=!p);while(q=a[o++])if(q(l,g||n,h)){i.push(l);break}k&&(w=y)}c&&((l=!q&&l)&&r--,f&&t.push(l))}if(r+=s,c&&s!==r){o=0;while(q=b[o++])q(t,u,g,h);if(f){if(r>0)while(s--)t[s]||u[s]||(u[s]=E.call(i));u=wa(u)}G.apply(i,u),k&&!f&&u.length>0&&r+b.length>1&&ga.uniqueSort(i)}return k&&(w=y,j=v),t};return c?ia(f):f}return h=ga.compile=function(a,b){var c,d=[],e=[],f=A[a+" "];if(!f){b||(b=g(a)),c=b.length;while(c--)f=ya(b[c]),f[u]?d.push(f):e.push(f);f=A(a,za(e,d)),f.selector=a}return f},i=ga.select=function(a,b,c,e){var f,i,j,k,l,m="function"==typeof a&&a,n=!e&&g(a=m.selector||a);if(c=c||[],1===n.length){if(i=n[0]=n[0].slice(0),i.length>2&&"ID"===(j=i[0]).type&&9===b.nodeType&&p&&d.relative[i[1].type]){if(b=(d.find.ID(j.matches[0].replace(_,aa),b)||[])[0],!b)return c;m&&(b=b.parentNode),a=a.slice(i.shift().value.length)}f=V.needsContext.test(a)?0:i.length;while(f--){if(j=i[f],d.relative[k=j.type])break;if((l=d.find[k])&&(e=l(j.matches[0].replace(_,aa),$.test(i[0].type)&&qa(b.parentNode)||b))){if(i.splice(f,1),a=e.length&&sa(i),!a)return G.apply(c,e),c;break}}}return(m||h(a,n))(e,b,!p,c,!b||$.test(a)&&qa(b.parentNode)||b),c},c.sortStable=u.split("").sort(B).join("")===u,c.detectDuplicates=!!l,m(),c.sortDetached=ja(function(a){return 1&a.compareDocumentPosition(n.createElement("fieldset"))}),ja(function(a){return a.innerHTML="<a href='#'></a>","#"===a.firstChild.getAttribute("href")})||ka("type|href|height|width",function(a,b,c){if(!c)return a.getAttribute(b,"type"===b.toLowerCase()?1:2)}),c.attributes&&ja(function(a){return a.innerHTML="<input/>",a.firstChild.setAttribute("value",""),""===a.firstChild.getAttribute("value")})||ka("value",function(a,b,c){if(!c&&"input"===a.nodeName.toLowerCase())return a.defaultValue}),ja(function(a){return null==a.getAttribute("disabled")})||ka(J,function(a,b,c){var d;if(!c)return a[b]===!0?b.toLowerCase():(d=a.getAttributeNode(b))&&d.specified?d.value:null}),ga}(a);r.find=x,r.expr=x.selectors,r.expr[":"]=r.expr.pseudos,r.uniqueSort=r.unique=x.uniqueSort,r.text=x.getText,r.isXMLDoc=x.isXML,r.contains=x.contains,r.escapeSelector=x.escape;var y=function(a,b,c){var d=[],e=void 0!==c;while((a=a[b])&&9!==a.nodeType)if(1===a.nodeType){if(e&&r(a).is(c))break;d.push(a)}return d},z=function(a,b){for(var c=[];a;a=a.nextSibling)1===a.nodeType&&a!==b&&c.push(a);return c},A=r.expr.match.needsContext,B=/^<([a-z][^\/\0>:\x20\t\r\n\f]*)[\x20\t\r\n\f]*\/?>(?:<\/\1>|)$/i,C=/^.[^:#\[\.,]*$/;function D(a,b,c){return r.isFunction(b)?r.grep(a,function(a,d){return!!b.call(a,d,a)!==c}):b.nodeType?r.grep(a,function(a){return a===b!==c}):"string"!=typeof b?r.grep(a,function(a){return i.call(b,a)>-1!==c}):C.test(b)?r.filter(b,a,c):(b=r.filter(b,a),r.grep(a,function(a){return i.call(b,a)>-1!==c&&1===a.nodeType}))}r.filter=function(a,b,c){var d=b[0];return c&&(a=":not("+a+")"),1===b.length&&1===d.nodeType?r.find.matchesSelector(d,a)?[d]:[]:r.find.matches(a,r.grep(b,function(a){return 1===a.nodeType}))},r.fn.extend({find:function(a){var b,c,d=this.length,e=this;if("string"!=typeof a)return this.pushStack(r(a).filter(function(){for(b=0;b<d;b++)if(r.contains(e[b],this))return!0}));for(c=this.pushStack([]),b=0;b<d;b++)r.find(a,e[b],c);return d>1?r.uniqueSort(c):c},filter:function(a){return this.pushStack(D(this,a||[],!1))},not:function(a){return this.pushStack(D(this,a||[],!0))},is:function(a){return!!D(this,"string"==typeof a&&A.test(a)?r(a):a||[],!1).length}});var E,F=/^(?:\s*(<[\w\W]+>)[^>]*|#([\w-]+))$/,G=r.fn.init=function(a,b,c){var e,f;if(!a)return this;if(c=c||E,"string"==typeof a){if(e="<"===a[0]&&">"===a[a.length-1]&&a.length>=3?[null,a,null]:F.exec(a),!e||!e[1]&&b)return!b||b.jquery?(b||c).find(a):this.constructor(b).find(a);if(e[1]){if(b=b instanceof r?b[0]:b,r.merge(this,r.parseHTML(e[1],b&&b.nodeType?b.ownerDocument||b:d,!0)),B.test(e[1])&&r.isPlainObject(b))for(e in b)r.isFunction(this[e])?this[e](b[e]):this.attr(e,b[e]);return this}return f=d.getElementById(e[2]),f&&(this[0]=f,this.length=1),this}return a.nodeType?(this[0]=a,this.length=1,this):r.isFunction(a)?void 0!==c.ready?c.ready(a):a(r):r.makeArray(a,this)};G.prototype=r.fn,E=r(d);var H=/^(?:parents|prev(?:Until|All))/,I={children:!0,contents:!0,next:!0,prev:!0};r.fn.extend({has:function(a){var b=r(a,this),c=b.length;return this.filter(function(){for(var a=0;a<c;a++)if(r.contains(this,b[a]))return!0})},closest:function(a,b){var c,d=0,e=this.length,f=[],g="string"!=typeof a&&r(a);if(!A.test(a))for(;d<e;d++)for(c=this[d];c&&c!==b;c=c.parentNode)if(c.nodeType<11&&(g?g.index(c)>-1:1===c.nodeType&&r.find.matchesSelector(c,a))){f.push(c);break}return this.pushStack(f.length>1?r.uniqueSort(f):f)},index:function(a){return a?"string"==typeof a?i.call(r(a),this[0]):i.call(this,a.jquery?a[0]:a):this[0]&&this[0].parentNode?this.first().prevAll().length:-1},add:function(a,b){return this.pushStack(r.uniqueSort(r.merge(this.get(),r(a,b))))},addBack:function(a){return this.add(null==a?this.prevObject:this.prevObject.filter(a))}});function J(a,b){while((a=a[b])&&1!==a.nodeType);return a}r.each({parent:function(a){var b=a.parentNode;return b&&11!==b.nodeType?b:null},parents:function(a){return y(a,"parentNode")},parentsUntil:function(a,b,c){return y(a,"parentNode",c)},next:function(a){return J(a,"nextSibling")},prev:function(a){return J(a,"previousSibling")},nextAll:function(a){return y(a,"nextSibling")},prevAll:function(a){return y(a,"previousSibling")},nextUntil:function(a,b,c){return y(a,"nextSibling",c)},prevUntil:function(a,b,c){return y(a,"previousSibling",c)},siblings:function(a){return z((a.parentNode||{}).firstChild,a)},children:function(a){return z(a.firstChild)},contents:function(a){return a.contentDocument||r.merge([],a.childNodes)}},function(a,b){r.fn[a]=function(c,d){var e=r.map(this,b,c);return"Until"!==a.slice(-5)&&(d=c),d&&"string"==typeof d&&(e=r.filter(d,e)),this.length>1&&(I[a]||r.uniqueSort(e),H.test(a)&&e.reverse()),this.pushStack(e)}});var K=/[^\x20\t\r\n\f]+/g;function L(a){var b={};return r.each(a.match(K)||[],function(a,c){b[c]=!0}),b}r.Callbacks=function(a){a="string"==typeof a?L(a):r.extend({},a);var b,c,d,e,f=[],g=[],h=-1,i=function(){for(e=a.once,d=b=!0;g.length;h=-1){c=g.shift();while(++h<f.length)f[h].apply(c[0],c[1])===!1&&a.stopOnFalse&&(h=f.length,c=!1)}a.memory||(c=!1),b=!1,e&&(f=c?[]:"")},j={add:function(){return f&&(c&&!b&&(h=f.length-1,g.push(c)),function d(b){r.each(b,function(b,c){r.isFunction(c)?a.unique&&j.has(c)||f.push(c):c&&c.length&&"string"!==r.type(c)&&d(c)})}(arguments),c&&!b&&i()),this},remove:function(){return r.each(arguments,function(a,b){var c;while((c=r.inArray(b,f,c))>-1)f.splice(c,1),c<=h&&h--}),this},has:function(a){return a?r.inArray(a,f)>-1:f.length>0},empty:function(){return f&&(f=[]),this},disable:function(){return e=g=[],f=c="",this},disabled:function(){return!f},lock:function(){return e=g=[],c||b||(f=c=""),this},locked:function(){return!!e},fireWith:function(a,c){return e||(c=c||[],c=[a,c.slice?c.slice():c],g.push(c),b||i()),this},fire:function(){return j.fireWith(this,arguments),this},fired:function(){return!!d}};return j};function M(a){return a}function N(a){throw a}function O(a,b,c){var d;try{a&&r.isFunction(d=a.promise)?d.call(a).done(b).fail(c):a&&r.isFunction(d=a.then)?d.call(a,b,c):b.call(void 0,a)}catch(a){c.call(void 0,a)}}r.extend({Deferred:function(b){var c=[["notify","progress",r.Callbacks("memory"),r.Callbacks("memory"),2],["resolve","done",r.Callbacks("once memory"),r.Callbacks("once memory"),0,"resolved"],["reject","fail",r.Callbacks("once memory"),r.Callbacks("once memory"),1,"rejected"]],d="pending",e={state:function(){return d},always:function(){return f.done(arguments).fail(arguments),this},"catch":function(a){return e.then(null,a)},pipe:function(){var a=arguments;return r.Deferred(function(b){r.each(c,function(c,d){var e=r.isFunction(a[d[4]])&&a[d[4]];f[d[1]](function(){var a=e&&e.apply(this,arguments);a&&r.isFunction(a.promise)?a.promise().progress(b.notify).done(b.resolve).fail(b.reject):b[d[0]+"With"](this,e?[a]:arguments)})}),a=null}).promise()},then:function(b,d,e){var f=0;function g(b,c,d,e){return function(){var h=this,i=arguments,j=function(){var a,j;if(!(b<f)){if(a=d.apply(h,i),a===c.promise())throw new TypeError("Thenable self-resolution");j=a&&("object"==typeof a||"function"==typeof a)&&a.then,r.isFunction(j)?e?j.call(a,g(f,c,M,e),g(f,c,N,e)):(f++,j.call(a,g(f,c,M,e),g(f,c,N,e),g(f,c,M,c.notifyWith))):(d!==M&&(h=void 0,i=[a]),(e||c.resolveWith)(h,i))}},k=e?j:function(){try{j()}catch(a){r.Deferred.exceptionHook&&r.Deferred.exceptionHook(a,k.stackTrace),b+1>=f&&(d!==N&&(h=void 0,i=[a]),c.rejectWith(h,i))}};b?k():(r.Deferred.getStackHook&&(k.stackTrace=r.Deferred.getStackHook()),a.setTimeout(k))}}return r.Deferred(function(a){c[0][3].add(g(0,a,r.isFunction(e)?e:M,a.notifyWith)),c[1][3].add(g(0,a,r.isFunction(b)?b:M)),c[2][3].add(g(0,a,r.isFunction(d)?d:N))}).promise()},promise:function(a){return null!=a?r.extend(a,e):e}},f={};return r.each(c,function(a,b){var g=b[2],h=b[5];e[b[1]]=g.add,h&&g.add(function(){d=h},c[3-a][2].disable,c[0][2].lock),g.add(b[3].fire),f[b[0]]=function(){return f[b[0]+"With"](this===f?void 0:this,arguments),this},f[b[0]+"With"]=g.fireWith}),e.promise(f),b&&b.call(f,f),f},when:function(a){var b=arguments.length,c=b,d=Array(c),e=f.call(arguments),g=r.Deferred(),h=function(a){return function(c){d[a]=this,e[a]=arguments.length>1?f.call(arguments):c,--b||g.resolveWith(d,e)}};if(b<=1&&(O(a,g.done(h(c)).resolve,g.reject),"pending"===g.state()||r.isFunction(e[c]&&e[c].then)))return g.then();while(c--)O(e[c],h(c),g.reject);return g.promise()}});var P=/^(Eval|Internal|Range|Reference|Syntax|Type|URI)Error$/;r.Deferred.exceptionHook=function(b,c){a.console&&a.console.warn&&b&&P.test(b.name)&&a.console.warn("jQuery.Deferred exception: "+b.message,b.stack,c)},r.readyException=function(b){a.setTimeout(function(){throw b})};var Q=r.Deferred();r.fn.ready=function(a){return Q.then(a)["catch"](function(a){r.readyException(a)}),this},r.extend({isReady:!1,readyWait:1,holdReady:function(a){a?r.readyWait++:r.ready(!0)},ready:function(a){(a===!0?--r.readyWait:r.isReady)||(r.isReady=!0,a!==!0&&--r.readyWait>0||Q.resolveWith(d,[r]))}}),r.ready.then=Q.then;function R(){d.removeEventListener("DOMContentLoaded",R),
-a.removeEventListener("load",R),r.ready()}"complete"===d.readyState||"loading"!==d.readyState&&!d.documentElement.doScroll?a.setTimeout(r.ready):(d.addEventListener("DOMContentLoaded",R),a.addEventListener("load",R));var S=function(a,b,c,d,e,f,g){var h=0,i=a.length,j=null==c;if("object"===r.type(c)){e=!0;for(h in c)S(a,b,h,c[h],!0,f,g)}else if(void 0!==d&&(e=!0,r.isFunction(d)||(g=!0),j&&(g?(b.call(a,d),b=null):(j=b,b=function(a,b,c){return j.call(r(a),c)})),b))for(;h<i;h++)b(a[h],c,g?d:d.call(a[h],h,b(a[h],c)));return e?a:j?b.call(a):i?b(a[0],c):f},T=function(a){return 1===a.nodeType||9===a.nodeType||!+a.nodeType};function U(){this.expando=r.expando+U.uid++}U.uid=1,U.prototype={cache:function(a){var b=a[this.expando];return b||(b={},T(a)&&(a.nodeType?a[this.expando]=b:Object.defineProperty(a,this.expando,{value:b,configurable:!0}))),b},set:function(a,b,c){var d,e=this.cache(a);if("string"==typeof b)e[r.camelCase(b)]=c;else for(d in b)e[r.camelCase(d)]=b[d];return e},get:function(a,b){return void 0===b?this.cache(a):a[this.expando]&&a[this.expando][r.camelCase(b)]},access:function(a,b,c){return void 0===b||b&&"string"==typeof b&&void 0===c?this.get(a,b):(this.set(a,b,c),void 0!==c?c:b)},remove:function(a,b){var c,d=a[this.expando];if(void 0!==d){if(void 0!==b){r.isArray(b)?b=b.map(r.camelCase):(b=r.camelCase(b),b=b in d?[b]:b.match(K)||[]),c=b.length;while(c--)delete d[b[c]]}(void 0===b||r.isEmptyObject(d))&&(a.nodeType?a[this.expando]=void 0:delete a[this.expando])}},hasData:function(a){var b=a[this.expando];return void 0!==b&&!r.isEmptyObject(b)}};var V=new U,W=new U,X=/^(?:\{[\w\W]*\}|\[[\w\W]*\])$/,Y=/[A-Z]/g;function Z(a){return"true"===a||"false"!==a&&("null"===a?null:a===+a+""?+a:X.test(a)?JSON.parse(a):a)}function $(a,b,c){var d;if(void 0===c&&1===a.nodeType)if(d="data-"+b.replace(Y,"-$&").toLowerCase(),c=a.getAttribute(d),"string"==typeof c){try{c=Z(c)}catch(e){}W.set(a,b,c)}else c=void 0;return c}r.extend({hasData:function(a){return W.hasData(a)||V.hasData(a)},data:function(a,b,c){return W.access(a,b,c)},removeData:function(a,b){W.remove(a,b)},_data:function(a,b,c){return V.access(a,b,c)},_removeData:function(a,b){V.remove(a,b)}}),r.fn.extend({data:function(a,b){var c,d,e,f=this[0],g=f&&f.attributes;if(void 0===a){if(this.length&&(e=W.get(f),1===f.nodeType&&!V.get(f,"hasDataAttrs"))){c=g.length;while(c--)g[c]&&(d=g[c].name,0===d.indexOf("data-")&&(d=r.camelCase(d.slice(5)),$(f,d,e[d])));V.set(f,"hasDataAttrs",!0)}return e}return"object"==typeof a?this.each(function(){W.set(this,a)}):S(this,function(b){var c;if(f&&void 0===b){if(c=W.get(f,a),void 0!==c)return c;if(c=$(f,a),void 0!==c)return c}else this.each(function(){W.set(this,a,b)})},null,b,arguments.length>1,null,!0)},removeData:function(a){return this.each(function(){W.remove(this,a)})}}),r.extend({queue:function(a,b,c){var d;if(a)return b=(b||"fx")+"queue",d=V.get(a,b),c&&(!d||r.isArray(c)?d=V.access(a,b,r.makeArray(c)):d.push(c)),d||[]},dequeue:function(a,b){b=b||"fx";var c=r.queue(a,b),d=c.length,e=c.shift(),f=r._queueHooks(a,b),g=function(){r.dequeue(a,b)};"inprogress"===e&&(e=c.shift(),d--),e&&("fx"===b&&c.unshift("inprogress"),delete f.stop,e.call(a,g,f)),!d&&f&&f.empty.fire()},_queueHooks:function(a,b){var c=b+"queueHooks";return V.get(a,c)||V.access(a,c,{empty:r.Callbacks("once memory").add(function(){V.remove(a,[b+"queue",c])})})}}),r.fn.extend({queue:function(a,b){var c=2;return"string"!=typeof a&&(b=a,a="fx",c--),arguments.length<c?r.queue(this[0],a):void 0===b?this:this.each(function(){var c=r.queue(this,a,b);r._queueHooks(this,a),"fx"===a&&"inprogress"!==c[0]&&r.dequeue(this,a)})},dequeue:function(a){return this.each(function(){r.dequeue(this,a)})},clearQueue:function(a){return this.queue(a||"fx",[])},promise:function(a,b){var c,d=1,e=r.Deferred(),f=this,g=this.length,h=function(){--d||e.resolveWith(f,[f])};"string"!=typeof a&&(b=a,a=void 0),a=a||"fx";while(g--)c=V.get(f[g],a+"queueHooks"),c&&c.empty&&(d++,c.empty.add(h));return h(),e.promise(b)}});var _=/[+-]?(?:\d*\.|)\d+(?:[eE][+-]?\d+|)/.source,aa=new RegExp("^(?:([+-])=|)("+_+")([a-z%]*)$","i"),ba=["Top","Right","Bottom","Left"],ca=function(a,b){return a=b||a,"none"===a.style.display||""===a.style.display&&r.contains(a.ownerDocument,a)&&"none"===r.css(a,"display")},da=function(a,b,c,d){var e,f,g={};for(f in b)g[f]=a.style[f],a.style[f]=b[f];e=c.apply(a,d||[]);for(f in b)a.style[f]=g[f];return e};function ea(a,b,c,d){var e,f=1,g=20,h=d?function(){return d.cur()}:function(){return r.css(a,b,"")},i=h(),j=c&&c[3]||(r.cssNumber[b]?"":"px"),k=(r.cssNumber[b]||"px"!==j&&+i)&&aa.exec(r.css(a,b));if(k&&k[3]!==j){j=j||k[3],c=c||[],k=+i||1;do f=f||".5",k/=f,r.style(a,b,k+j);while(f!==(f=h()/i)&&1!==f&&--g)}return c&&(k=+k||+i||0,e=c[1]?k+(c[1]+1)*c[2]:+c[2],d&&(d.unit=j,d.start=k,d.end=e)),e}var fa={};function ga(a){var b,c=a.ownerDocument,d=a.nodeName,e=fa[d];return e?e:(b=c.body.appendChild(c.createElement(d)),e=r.css(b,"display"),b.parentNode.removeChild(b),"none"===e&&(e="block"),fa[d]=e,e)}function ha(a,b){for(var c,d,e=[],f=0,g=a.length;f<g;f++)d=a[f],d.style&&(c=d.style.display,b?("none"===c&&(e[f]=V.get(d,"display")||null,e[f]||(d.style.display="")),""===d.style.display&&ca(d)&&(e[f]=ga(d))):"none"!==c&&(e[f]="none",V.set(d,"display",c)));for(f=0;f<g;f++)null!=e[f]&&(a[f].style.display=e[f]);return a}r.fn.extend({show:function(){return ha(this,!0)},hide:function(){return ha(this)},toggle:function(a){return"boolean"==typeof a?a?this.show():this.hide():this.each(function(){ca(this)?r(this).show():r(this).hide()})}});var ia=/^(?:checkbox|radio)$/i,ja=/<([a-z][^\/\0>\x20\t\r\n\f]+)/i,ka=/^$|\/(?:java|ecma)script/i,la={option:[1,"<select multiple='multiple'>","</select>"],thead:[1,"<table>","</table>"],col:[2,"<table><colgroup>","</colgroup></table>"],tr:[2,"<table><tbody>","</tbody></table>"],td:[3,"<table><tbody><tr>","</tr></tbody></table>"],_default:[0,"",""]};la.optgroup=la.option,la.tbody=la.tfoot=la.colgroup=la.caption=la.thead,la.th=la.td;function ma(a,b){var c;return c="undefined"!=typeof a.getElementsByTagName?a.getElementsByTagName(b||"*"):"undefined"!=typeof a.querySelectorAll?a.querySelectorAll(b||"*"):[],void 0===b||b&&r.nodeName(a,b)?r.merge([a],c):c}function na(a,b){for(var c=0,d=a.length;c<d;c++)V.set(a[c],"globalEval",!b||V.get(b[c],"globalEval"))}var oa=/<|&#?\w+;/;function pa(a,b,c,d,e){for(var f,g,h,i,j,k,l=b.createDocumentFragment(),m=[],n=0,o=a.length;n<o;n++)if(f=a[n],f||0===f)if("object"===r.type(f))r.merge(m,f.nodeType?[f]:f);else if(oa.test(f)){g=g||l.appendChild(b.createElement("div")),h=(ja.exec(f)||["",""])[1].toLowerCase(),i=la[h]||la._default,g.innerHTML=i[1]+r.htmlPrefilter(f)+i[2],k=i[0];while(k--)g=g.lastChild;r.merge(m,g.childNodes),g=l.firstChild,g.textContent=""}else m.push(b.createTextNode(f));l.textContent="",n=0;while(f=m[n++])if(d&&r.inArray(f,d)>-1)e&&e.push(f);else if(j=r.contains(f.ownerDocument,f),g=ma(l.appendChild(f),"script"),j&&na(g),c){k=0;while(f=g[k++])ka.test(f.type||"")&&c.push(f)}return l}!function(){var a=d.createDocumentFragment(),b=a.appendChild(d.createElement("div")),c=d.createElement("input");c.setAttribute("type","radio"),c.setAttribute("checked","checked"),c.setAttribute("name","t"),b.appendChild(c),o.checkClone=b.cloneNode(!0).cloneNode(!0).lastChild.checked,b.innerHTML="<textarea>x</textarea>",o.noCloneChecked=!!b.cloneNode(!0).lastChild.defaultValue}();var qa=d.documentElement,ra=/^key/,sa=/^(?:mouse|pointer|contextmenu|drag|drop)|click/,ta=/^([^.]*)(?:\.(.+)|)/;function ua(){return!0}function va(){return!1}function wa(){try{return d.activeElement}catch(a){}}function xa(a,b,c,d,e,f){var g,h;if("object"==typeof b){"string"!=typeof c&&(d=d||c,c=void 0);for(h in b)xa(a,h,c,d,b[h],f);return a}if(null==d&&null==e?(e=c,d=c=void 0):null==e&&("string"==typeof c?(e=d,d=void 0):(e=d,d=c,c=void 0)),e===!1)e=va;else if(!e)return a;return 1===f&&(g=e,e=function(a){return r().off(a),g.apply(this,arguments)},e.guid=g.guid||(g.guid=r.guid++)),a.each(function(){r.event.add(this,b,e,d,c)})}r.event={global:{},add:function(a,b,c,d,e){var f,g,h,i,j,k,l,m,n,o,p,q=V.get(a);if(q){c.handler&&(f=c,c=f.handler,e=f.selector),e&&r.find.matchesSelector(qa,e),c.guid||(c.guid=r.guid++),(i=q.events)||(i=q.events={}),(g=q.handle)||(g=q.handle=function(b){return"undefined"!=typeof r&&r.event.triggered!==b.type?r.event.dispatch.apply(a,arguments):void 0}),b=(b||"").match(K)||[""],j=b.length;while(j--)h=ta.exec(b[j])||[],n=p=h[1],o=(h[2]||"").split(".").sort(),n&&(l=r.event.special[n]||{},n=(e?l.delegateType:l.bindType)||n,l=r.event.special[n]||{},k=r.extend({type:n,origType:p,data:d,handler:c,guid:c.guid,selector:e,needsContext:e&&r.expr.match.needsContext.test(e),namespace:o.join(".")},f),(m=i[n])||(m=i[n]=[],m.delegateCount=0,l.setup&&l.setup.call(a,d,o,g)!==!1||a.addEventListener&&a.addEventListener(n,g)),l.add&&(l.add.call(a,k),k.handler.guid||(k.handler.guid=c.guid)),e?m.splice(m.delegateCount++,0,k):m.push(k),r.event.global[n]=!0)}},remove:function(a,b,c,d,e){var f,g,h,i,j,k,l,m,n,o,p,q=V.hasData(a)&&V.get(a);if(q&&(i=q.events)){b=(b||"").match(K)||[""],j=b.length;while(j--)if(h=ta.exec(b[j])||[],n=p=h[1],o=(h[2]||"").split(".").sort(),n){l=r.event.special[n]||{},n=(d?l.delegateType:l.bindType)||n,m=i[n]||[],h=h[2]&&new RegExp("(^|\\.)"+o.join("\\.(?:.*\\.|)")+"(\\.|$)"),g=f=m.length;while(f--)k=m[f],!e&&p!==k.origType||c&&c.guid!==k.guid||h&&!h.test(k.namespace)||d&&d!==k.selector&&("**"!==d||!k.selector)||(m.splice(f,1),k.selector&&m.delegateCount--,l.remove&&l.remove.call(a,k));g&&!m.length&&(l.teardown&&l.teardown.call(a,o,q.handle)!==!1||r.removeEvent(a,n,q.handle),delete i[n])}else for(n in i)r.event.remove(a,n+b[j],c,d,!0);r.isEmptyObject(i)&&V.remove(a,"handle events")}},dispatch:function(a){var b=r.event.fix(a),c,d,e,f,g,h,i=new Array(arguments.length),j=(V.get(this,"events")||{})[b.type]||[],k=r.event.special[b.type]||{};for(i[0]=b,c=1;c<arguments.length;c++)i[c]=arguments[c];if(b.delegateTarget=this,!k.preDispatch||k.preDispatch.call(this,b)!==!1){h=r.event.handlers.call(this,b,j),c=0;while((f=h[c++])&&!b.isPropagationStopped()){b.currentTarget=f.elem,d=0;while((g=f.handlers[d++])&&!b.isImmediatePropagationStopped())b.rnamespace&&!b.rnamespace.test(g.namespace)||(b.handleObj=g,b.data=g.data,e=((r.event.special[g.origType]||{}).handle||g.handler).apply(f.elem,i),void 0!==e&&(b.result=e)===!1&&(b.preventDefault(),b.stopPropagation()))}return k.postDispatch&&k.postDispatch.call(this,b),b.result}},handlers:function(a,b){var c,d,e,f,g,h=[],i=b.delegateCount,j=a.target;if(i&&j.nodeType&&!("click"===a.type&&a.button>=1))for(;j!==this;j=j.parentNode||this)if(1===j.nodeType&&("click"!==a.type||j.disabled!==!0)){for(f=[],g={},c=0;c<i;c++)d=b[c],e=d.selector+" ",void 0===g[e]&&(g[e]=d.needsContext?r(e,this).index(j)>-1:r.find(e,this,null,[j]).length),g[e]&&f.push(d);f.length&&h.push({elem:j,handlers:f})}return j=this,i<b.length&&h.push({elem:j,handlers:b.slice(i)}),h},addProp:function(a,b){Object.defineProperty(r.Event.prototype,a,{enumerable:!0,configurable:!0,get:r.isFunction(b)?function(){if(this.originalEvent)return b(this.originalEvent)}:function(){if(this.originalEvent)return this.originalEvent[a]},set:function(b){Object.defineProperty(this,a,{enumerable:!0,configurable:!0,writable:!0,value:b})}})},fix:function(a){return a[r.expando]?a:new r.Event(a)},special:{load:{noBubble:!0},focus:{trigger:function(){if(this!==wa()&&this.focus)return this.focus(),!1},delegateType:"focusin"},blur:{trigger:function(){if(this===wa()&&this.blur)return this.blur(),!1},delegateType:"focusout"},click:{trigger:function(){if("checkbox"===this.type&&this.click&&r.nodeName(this,"input"))return this.click(),!1},_default:function(a){return r.nodeName(a.target,"a")}},beforeunload:{postDispatch:function(a){void 0!==a.result&&a.originalEvent&&(a.originalEvent.returnValue=a.result)}}}},r.removeEvent=function(a,b,c){a.removeEventListener&&a.removeEventListener(b,c)},r.Event=function(a,b){return this instanceof r.Event?(a&&a.type?(this.originalEvent=a,this.type=a.type,this.isDefaultPrevented=a.defaultPrevented||void 0===a.defaultPrevented&&a.returnValue===!1?ua:va,this.target=a.target&&3===a.target.nodeType?a.target.parentNode:a.target,this.currentTarget=a.currentTarget,this.relatedTarget=a.relatedTarget):this.type=a,b&&r.extend(this,b),this.timeStamp=a&&a.timeStamp||r.now(),void(this[r.expando]=!0)):new r.Event(a,b)},r.Event.prototype={constructor:r.Event,isDefaultPrevented:va,isPropagationStopped:va,isImmediatePropagationStopped:va,isSimulated:!1,preventDefault:function(){var a=this.originalEvent;this.isDefaultPrevented=ua,a&&!this.isSimulated&&a.preventDefault()},stopPropagation:function(){var a=this.originalEvent;this.isPropagationStopped=ua,a&&!this.isSimulated&&a.stopPropagation()},stopImmediatePropagation:function(){var a=this.originalEvent;this.isImmediatePropagationStopped=ua,a&&!this.isSimulated&&a.stopImmediatePropagation(),this.stopPropagation()}},r.each({altKey:!0,bubbles:!0,cancelable:!0,changedTouches:!0,ctrlKey:!0,detail:!0,eventPhase:!0,metaKey:!0,pageX:!0,pageY:!0,shiftKey:!0,view:!0,"char":!0,charCode:!0,key:!0,keyCode:!0,button:!0,buttons:!0,clientX:!0,clientY:!0,offsetX:!0,offsetY:!0,pointerId:!0,pointerType:!0,screenX:!0,screenY:!0,targetTouches:!0,toElement:!0,touches:!0,which:function(a){var b=a.button;return null==a.which&&ra.test(a.type)?null!=a.charCode?a.charCode:a.keyCode:!a.which&&void 0!==b&&sa.test(a.type)?1&b?1:2&b?3:4&b?2:0:a.which}},r.event.addProp),r.each({mouseenter:"mouseover",mouseleave:"mouseout",pointerenter:"pointerover",pointerleave:"pointerout"},function(a,b){r.event.special[a]={delegateType:b,bindType:b,handle:function(a){var c,d=this,e=a.relatedTarget,f=a.handleObj;return e&&(e===d||r.contains(d,e))||(a.type=f.origType,c=f.handler.apply(this,arguments),a.type=b),c}}}),r.fn.extend({on:function(a,b,c,d){return xa(this,a,b,c,d)},one:function(a,b,c,d){return xa(this,a,b,c,d,1)},off:function(a,b,c){var d,e;if(a&&a.preventDefault&&a.handleObj)return d=a.handleObj,r(a.delegateTarget).off(d.namespace?d.origType+"."+d.namespace:d.origType,d.selector,d.handler),this;if("object"==typeof a){for(e in a)this.off(e,b,a[e]);return this}return b!==!1&&"function"!=typeof b||(c=b,b=void 0),c===!1&&(c=va),this.each(function(){r.event.remove(this,a,c,b)})}});var ya=/<(?!area|br|col|embed|hr|img|input|link|meta|param)(([a-z][^\/\0>\x20\t\r\n\f]*)[^>]*)\/>/gi,za=/<script|<style|<link/i,Aa=/checked\s*(?:[^=]|=\s*.checked.)/i,Ba=/^true\/(.*)/,Ca=/^\s*<!(?:\[CDATA\[|--)|(?:\]\]|--)>\s*$/g;function Da(a,b){return r.nodeName(a,"table")&&r.nodeName(11!==b.nodeType?b:b.firstChild,"tr")?a.getElementsByTagName("tbody")[0]||a:a}function Ea(a){return a.type=(null!==a.getAttribute("type"))+"/"+a.type,a}function Fa(a){var b=Ba.exec(a.type);return b?a.type=b[1]:a.removeAttribute("type"),a}function Ga(a,b){var c,d,e,f,g,h,i,j;if(1===b.nodeType){if(V.hasData(a)&&(f=V.access(a),g=V.set(b,f),j=f.events)){delete g.handle,g.events={};for(e in j)for(c=0,d=j[e].length;c<d;c++)r.event.add(b,e,j[e][c])}W.hasData(a)&&(h=W.access(a),i=r.extend({},h),W.set(b,i))}}function Ha(a,b){var c=b.nodeName.toLowerCase();"input"===c&&ia.test(a.type)?b.checked=a.checked:"input"!==c&&"textarea"!==c||(b.defaultValue=a.defaultValue)}function Ia(a,b,c,d){b=g.apply([],b);var e,f,h,i,j,k,l=0,m=a.length,n=m-1,q=b[0],s=r.isFunction(q);if(s||m>1&&"string"==typeof q&&!o.checkClone&&Aa.test(q))return a.each(function(e){var f=a.eq(e);s&&(b[0]=q.call(this,e,f.html())),Ia(f,b,c,d)});if(m&&(e=pa(b,a[0].ownerDocument,!1,a,d),f=e.firstChild,1===e.childNodes.length&&(e=f),f||d)){for(h=r.map(ma(e,"script"),Ea),i=h.length;l<m;l++)j=e,l!==n&&(j=r.clone(j,!0,!0),i&&r.merge(h,ma(j,"script"))),c.call(a[l],j,l);if(i)for(k=h[h.length-1].ownerDocument,r.map(h,Fa),l=0;l<i;l++)j=h[l],ka.test(j.type||"")&&!V.access(j,"globalEval")&&r.contains(k,j)&&(j.src?r._evalUrl&&r._evalUrl(j.src):p(j.textContent.replace(Ca,""),k))}return a}function Ja(a,b,c){for(var d,e=b?r.filter(b,a):a,f=0;null!=(d=e[f]);f++)c||1!==d.nodeType||r.cleanData(ma(d)),d.parentNode&&(c&&r.contains(d.ownerDocument,d)&&na(ma(d,"script")),d.parentNode.removeChild(d));return a}r.extend({htmlPrefilter:function(a){return a.replace(ya,"<$1></$2>")},clone:function(a,b,c){var d,e,f,g,h=a.cloneNode(!0),i=r.contains(a.ownerDocument,a);if(!(o.noCloneChecked||1!==a.nodeType&&11!==a.nodeType||r.isXMLDoc(a)))for(g=ma(h),f=ma(a),d=0,e=f.length;d<e;d++)Ha(f[d],g[d]);if(b)if(c)for(f=f||ma(a),g=g||ma(h),d=0,e=f.length;d<e;d++)Ga(f[d],g[d]);else Ga(a,h);return g=ma(h,"script"),g.length>0&&na(g,!i&&ma(a,"script")),h},cleanData:function(a){for(var b,c,d,e=r.event.special,f=0;void 0!==(c=a[f]);f++)if(T(c)){if(b=c[V.expando]){if(b.events)for(d in b.events)e[d]?r.event.remove(c,d):r.removeEvent(c,d,b.handle);c[V.expando]=void 0}c[W.expando]&&(c[W.expando]=void 0)}}}),r.fn.extend({detach:function(a){return Ja(this,a,!0)},remove:function(a){return Ja(this,a)},text:function(a){return S(this,function(a){return void 0===a?r.text(this):this.empty().each(function(){1!==this.nodeType&&11!==this.nodeType&&9!==this.nodeType||(this.textContent=a)})},null,a,arguments.length)},append:function(){return Ia(this,arguments,function(a){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){var b=Da(this,a);b.appendChild(a)}})},prepend:function(){return Ia(this,arguments,function(a){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){var b=Da(this,a);b.insertBefore(a,b.firstChild)}})},before:function(){return Ia(this,arguments,function(a){this.parentNode&&this.parentNode.insertBefore(a,this)})},after:function(){return Ia(this,arguments,function(a){this.parentNode&&this.parentNode.insertBefore(a,this.nextSibling)})},empty:function(){for(var a,b=0;null!=(a=this[b]);b++)1===a.nodeType&&(r.cleanData(ma(a,!1)),a.textContent="");return this},clone:function(a,b){return a=null!=a&&a,b=null==b?a:b,this.map(function(){return r.clone(this,a,b)})},html:function(a){return S(this,function(a){var b=this[0]||{},c=0,d=this.length;if(void 0===a&&1===b.nodeType)return b.innerHTML;if("string"==typeof a&&!za.test(a)&&!la[(ja.exec(a)||["",""])[1].toLowerCase()]){a=r.htmlPrefilter(a);try{for(;c<d;c++)b=this[c]||{},1===b.nodeType&&(r.cleanData(ma(b,!1)),b.innerHTML=a);b=0}catch(e){}}b&&this.empty().append(a)},null,a,arguments.length)},replaceWith:function(){var a=[];return Ia(this,arguments,function(b){var c=this.parentNode;r.inArray(this,a)<0&&(r.cleanData(ma(this)),c&&c.replaceChild(b,this))},a)}}),r.each({appendTo:"append",prependTo:"prepend",insertBefore:"before",insertAfter:"after",replaceAll:"replaceWith"},function(a,b){r.fn[a]=function(a){for(var c,d=[],e=r(a),f=e.length-1,g=0;g<=f;g++)c=g===f?this:this.clone(!0),r(e[g])[b](c),h.apply(d,c.get());return this.pushStack(d)}});var Ka=/^margin/,La=new RegExp("^("+_+")(?!px)[a-z%]+$","i"),Ma=function(b){var c=b.ownerDocument.defaultView;return c&&c.opener||(c=a),c.getComputedStyle(b)};!function(){function b(){if(i){i.style.cssText="box-sizing:border-box;position:relative;display:block;margin:auto;border:1px;padding:1px;top:1%;width:50%",i.innerHTML="",qa.appendChild(h);var b=a.getComputedStyle(i);c="1%"!==b.top,g="2px"===b.marginLeft,e="4px"===b.width,i.style.marginRight="50%",f="4px"===b.marginRight,qa.removeChild(h),i=null}}var c,e,f,g,h=d.createElement("div"),i=d.createElement("div");i.style&&(i.style.backgroundClip="content-box",i.cloneNode(!0).style.backgroundClip="",o.clearCloneStyle="content-box"===i.style.backgroundClip,h.style.cssText="border:0;width:8px;height:0;top:0;left:-9999px;padding:0;margin-top:1px;position:absolute",h.appendChild(i),r.extend(o,{pixelPosition:function(){return b(),c},boxSizingReliable:function(){return b(),e},pixelMarginRight:function(){return b(),f},reliableMarginLeft:function(){return b(),g}}))}();function Na(a,b,c){var d,e,f,g,h=a.style;return c=c||Ma(a),c&&(g=c.getPropertyValue(b)||c[b],""!==g||r.contains(a.ownerDocument,a)||(g=r.style(a,b)),!o.pixelMarginRight()&&La.test(g)&&Ka.test(b)&&(d=h.width,e=h.minWidth,f=h.maxWidth,h.minWidth=h.maxWidth=h.width=g,g=c.width,h.width=d,h.minWidth=e,h.maxWidth=f)),void 0!==g?g+"":g}function Oa(a,b){return{get:function(){return a()?void delete this.get:(this.get=b).apply(this,arguments)}}}var Pa=/^(none|table(?!-c[ea]).+)/,Qa={position:"absolute",visibility:"hidden",display:"block"},Ra={letterSpacing:"0",fontWeight:"400"},Sa=["Webkit","Moz","ms"],Ta=d.createElement("div").style;function Ua(a){if(a in Ta)return a;var b=a[0].toUpperCase()+a.slice(1),c=Sa.length;while(c--)if(a=Sa[c]+b,a in Ta)return a}function Va(a,b,c){var d=aa.exec(b);return d?Math.max(0,d[2]-(c||0))+(d[3]||"px"):b}function Wa(a,b,c,d,e){var f,g=0;for(f=c===(d?"border":"content")?4:"width"===b?1:0;f<4;f+=2)"margin"===c&&(g+=r.css(a,c+ba[f],!0,e)),d?("content"===c&&(g-=r.css(a,"padding"+ba[f],!0,e)),"margin"!==c&&(g-=r.css(a,"border"+ba[f]+"Width",!0,e))):(g+=r.css(a,"padding"+ba[f],!0,e),"padding"!==c&&(g+=r.css(a,"border"+ba[f]+"Width",!0,e)));return g}function Xa(a,b,c){var d,e=!0,f=Ma(a),g="border-box"===r.css(a,"boxSizing",!1,f);if(a.getClientRects().length&&(d=a.getBoundingClientRect()[b]),d<=0||null==d){if(d=Na(a,b,f),(d<0||null==d)&&(d=a.style[b]),La.test(d))return d;e=g&&(o.boxSizingReliable()||d===a.style[b]),d=parseFloat(d)||0}return d+Wa(a,b,c||(g?"border":"content"),e,f)+"px"}r.extend({cssHooks:{opacity:{get:function(a,b){if(b){var c=Na(a,"opacity");return""===c?"1":c}}}},cssNumber:{animationIterationCount:!0,columnCount:!0,fillOpacity:!0,flexGrow:!0,flexShrink:!0,fontWeight:!0,lineHeight:!0,opacity:!0,order:!0,orphans:!0,widows:!0,zIndex:!0,zoom:!0},cssProps:{"float":"cssFloat"},style:function(a,b,c,d){if(a&&3!==a.nodeType&&8!==a.nodeType&&a.style){var e,f,g,h=r.camelCase(b),i=a.style;return b=r.cssProps[h]||(r.cssProps[h]=Ua(h)||h),g=r.cssHooks[b]||r.cssHooks[h],void 0===c?g&&"get"in g&&void 0!==(e=g.get(a,!1,d))?e:i[b]:(f=typeof c,"string"===f&&(e=aa.exec(c))&&e[1]&&(c=ea(a,b,e),f="number"),null!=c&&c===c&&("number"===f&&(c+=e&&e[3]||(r.cssNumber[h]?"":"px")),o.clearCloneStyle||""!==c||0!==b.indexOf("background")||(i[b]="inherit"),g&&"set"in g&&void 0===(c=g.set(a,c,d))||(i[b]=c)),void 0)}},css:function(a,b,c,d){var e,f,g,h=r.camelCase(b);return b=r.cssProps[h]||(r.cssProps[h]=Ua(h)||h),g=r.cssHooks[b]||r.cssHooks[h],g&&"get"in g&&(e=g.get(a,!0,c)),void 0===e&&(e=Na(a,b,d)),"normal"===e&&b in Ra&&(e=Ra[b]),""===c||c?(f=parseFloat(e),c===!0||isFinite(f)?f||0:e):e}}),r.each(["height","width"],function(a,b){r.cssHooks[b]={get:function(a,c,d){if(c)return!Pa.test(r.css(a,"display"))||a.getClientRects().length&&a.getBoundingClientRect().width?Xa(a,b,d):da(a,Qa,function(){return Xa(a,b,d)})},set:function(a,c,d){var e,f=d&&Ma(a),g=d&&Wa(a,b,d,"border-box"===r.css(a,"boxSizing",!1,f),f);return g&&(e=aa.exec(c))&&"px"!==(e[3]||"px")&&(a.style[b]=c,c=r.css(a,b)),Va(a,c,g)}}}),r.cssHooks.marginLeft=Oa(o.reliableMarginLeft,function(a,b){if(b)return(parseFloat(Na(a,"marginLeft"))||a.getBoundingClientRect().left-da(a,{marginLeft:0},function(){return a.getBoundingClientRect().left}))+"px"}),r.each({margin:"",padding:"",border:"Width"},function(a,b){r.cssHooks[a+b]={expand:function(c){for(var d=0,e={},f="string"==typeof c?c.split(" "):[c];d<4;d++)e[a+ba[d]+b]=f[d]||f[d-2]||f[0];return e}},Ka.test(a)||(r.cssHooks[a+b].set=Va)}),r.fn.extend({css:function(a,b){return S(this,function(a,b,c){var d,e,f={},g=0;if(r.isArray(b)){for(d=Ma(a),e=b.length;g<e;g++)f[b[g]]=r.css(a,b[g],!1,d);return f}return void 0!==c?r.style(a,b,c):r.css(a,b)},a,b,arguments.length>1)}});function Ya(a,b,c,d,e){return new Ya.prototype.init(a,b,c,d,e)}r.Tween=Ya,Ya.prototype={constructor:Ya,init:function(a,b,c,d,e,f){this.elem=a,this.prop=c,this.easing=e||r.easing._default,this.options=b,this.start=this.now=this.cur(),this.end=d,this.unit=f||(r.cssNumber[c]?"":"px")},cur:function(){var a=Ya.propHooks[this.prop];return a&&a.get?a.get(this):Ya.propHooks._default.get(this)},run:function(a){var b,c=Ya.propHooks[this.prop];return this.options.duration?this.pos=b=r.easing[this.easing](a,this.options.duration*a,0,1,this.options.duration):this.pos=b=a,this.now=(this.end-this.start)*b+this.start,this.options.step&&this.options.step.call(this.elem,this.now,this),c&&c.set?c.set(this):Ya.propHooks._default.set(this),this}},Ya.prototype.init.prototype=Ya.prototype,Ya.propHooks={_default:{get:function(a){var b;return 1!==a.elem.nodeType||null!=a.elem[a.prop]&&null==a.elem.style[a.prop]?a.elem[a.prop]:(b=r.css(a.elem,a.prop,""),b&&"auto"!==b?b:0)},set:function(a){r.fx.step[a.prop]?r.fx.step[a.prop](a):1!==a.elem.nodeType||null==a.elem.style[r.cssProps[a.prop]]&&!r.cssHooks[a.prop]?a.elem[a.prop]=a.now:r.style(a.elem,a.prop,a.now+a.unit)}}},Ya.propHooks.scrollTop=Ya.propHooks.scrollLeft={set:function(a){a.elem.nodeType&&a.elem.parentNode&&(a.elem[a.prop]=a.now)}},r.easing={linear:function(a){return a},swing:function(a){return.5-Math.cos(a*Math.PI)/2},_default:"swing"},r.fx=Ya.prototype.init,r.fx.step={};var Za,$a,_a=/^(?:toggle|show|hide)$/,ab=/queueHooks$/;function bb(){$a&&(a.requestAnimationFrame(bb),r.fx.tick())}function cb(){return a.setTimeout(function(){Za=void 0}),Za=r.now()}function db(a,b){var c,d=0,e={height:a};for(b=b?1:0;d<4;d+=2-b)c=ba[d],e["margin"+c]=e["padding"+c]=a;return b&&(e.opacity=e.width=a),e}function eb(a,b,c){for(var d,e=(hb.tweeners[b]||[]).concat(hb.tweeners["*"]),f=0,g=e.length;f<g;f++)if(d=e[f].call(c,b,a))return d}function fb(a,b,c){var d,e,f,g,h,i,j,k,l="width"in b||"height"in b,m=this,n={},o=a.style,p=a.nodeType&&ca(a),q=V.get(a,"fxshow");c.queue||(g=r._queueHooks(a,"fx"),null==g.unqueued&&(g.unqueued=0,h=g.empty.fire,g.empty.fire=function(){g.unqueued||h()}),g.unqueued++,m.always(function(){m.always(function(){g.unqueued--,r.queue(a,"fx").length||g.empty.fire()})}));for(d in b)if(e=b[d],_a.test(e)){if(delete b[d],f=f||"toggle"===e,e===(p?"hide":"show")){if("show"!==e||!q||void 0===q[d])continue;p=!0}n[d]=q&&q[d]||r.style(a,d)}if(i=!r.isEmptyObject(b),i||!r.isEmptyObject(n)){l&&1===a.nodeType&&(c.overflow=[o.overflow,o.overflowX,o.overflowY],j=q&&q.display,null==j&&(j=V.get(a,"display")),k=r.css(a,"display"),"none"===k&&(j?k=j:(ha([a],!0),j=a.style.display||j,k=r.css(a,"display"),ha([a]))),("inline"===k||"inline-block"===k&&null!=j)&&"none"===r.css(a,"float")&&(i||(m.done(function(){o.display=j}),null==j&&(k=o.display,j="none"===k?"":k)),o.display="inline-block")),c.overflow&&(o.overflow="hidden",m.always(function(){o.overflow=c.overflow[0],o.overflowX=c.overflow[1],o.overflowY=c.overflow[2]})),i=!1;for(d in n)i||(q?"hidden"in q&&(p=q.hidden):q=V.access(a,"fxshow",{display:j}),f&&(q.hidden=!p),p&&ha([a],!0),m.done(function(){p||ha([a]),V.remove(a,"fxshow");for(d in n)r.style(a,d,n[d])})),i=eb(p?q[d]:0,d,m),d in q||(q[d]=i.start,p&&(i.end=i.start,i.start=0))}}function gb(a,b){var c,d,e,f,g;for(c in a)if(d=r.camelCase(c),e=b[d],f=a[c],r.isArray(f)&&(e=f[1],f=a[c]=f[0]),c!==d&&(a[d]=f,delete a[c]),g=r.cssHooks[d],g&&"expand"in g){f=g.expand(f),delete a[d];for(c in f)c in a||(a[c]=f[c],b[c]=e)}else b[d]=e}function hb(a,b,c){var d,e,f=0,g=hb.prefilters.length,h=r.Deferred().always(function(){delete i.elem}),i=function(){if(e)return!1;for(var b=Za||cb(),c=Math.max(0,j.startTime+j.duration-b),d=c/j.duration||0,f=1-d,g=0,i=j.tweens.length;g<i;g++)j.tweens[g].run(f);return h.notifyWith(a,[j,f,c]),f<1&&i?c:(h.resolveWith(a,[j]),!1)},j=h.promise({elem:a,props:r.extend({},b),opts:r.extend(!0,{specialEasing:{},easing:r.easing._default},c),originalProperties:b,originalOptions:c,startTime:Za||cb(),duration:c.duration,tweens:[],createTween:function(b,c){var d=r.Tween(a,j.opts,b,c,j.opts.specialEasing[b]||j.opts.easing);return j.tweens.push(d),d},stop:function(b){var c=0,d=b?j.tweens.length:0;if(e)return this;for(e=!0;c<d;c++)j.tweens[c].run(1);return b?(h.notifyWith(a,[j,1,0]),h.resolveWith(a,[j,b])):h.rejectWith(a,[j,b]),this}}),k=j.props;for(gb(k,j.opts.specialEasing);f<g;f++)if(d=hb.prefilters[f].call(j,a,k,j.opts))return r.isFunction(d.stop)&&(r._queueHooks(j.elem,j.opts.queue).stop=r.proxy(d.stop,d)),d;return r.map(k,eb,j),r.isFunction(j.opts.start)&&j.opts.start.call(a,j),r.fx.timer(r.extend(i,{elem:a,anim:j,queue:j.opts.queue})),j.progress(j.opts.progress).done(j.opts.done,j.opts.complete).fail(j.opts.fail).always(j.opts.always)}r.Animation=r.extend(hb,{tweeners:{"*":[function(a,b){var c=this.createTween(a,b);return ea(c.elem,a,aa.exec(b),c),c}]},tweener:function(a,b){r.isFunction(a)?(b=a,a=["*"]):a=a.match(K);for(var c,d=0,e=a.length;d<e;d++)c=a[d],hb.tweeners[c]=hb.tweeners[c]||[],hb.tweeners[c].unshift(b)},prefilters:[fb],prefilter:function(a,b){b?hb.prefilters.unshift(a):hb.prefilters.push(a)}}),r.speed=function(a,b,c){var e=a&&"object"==typeof a?r.extend({},a):{complete:c||!c&&b||r.isFunction(a)&&a,duration:a,easing:c&&b||b&&!r.isFunction(b)&&b};return r.fx.off||d.hidden?e.duration=0:"number"!=typeof e.duration&&(e.duration in r.fx.speeds?e.duration=r.fx.speeds[e.duration]:e.duration=r.fx.speeds._default),null!=e.queue&&e.queue!==!0||(e.queue="fx"),e.old=e.complete,e.complete=function(){r.isFunction(e.old)&&e.old.call(this),e.queue&&r.dequeue(this,e.queue)},e},r.fn.extend({fadeTo:function(a,b,c,d){return this.filter(ca).css("opacity",0).show().end().animate({opacity:b},a,c,d)},animate:function(a,b,c,d){var e=r.isEmptyObject(a),f=r.speed(b,c,d),g=function(){var b=hb(this,r.extend({},a),f);(e||V.get(this,"finish"))&&b.stop(!0)};return g.finish=g,e||f.queue===!1?this.each(g):this.queue(f.queue,g)},stop:function(a,b,c){var d=function(a){var b=a.stop;delete a.stop,b(c)};return"string"!=typeof a&&(c=b,b=a,a=void 0),b&&a!==!1&&this.queue(a||"fx",[]),this.each(function(){var b=!0,e=null!=a&&a+"queueHooks",f=r.timers,g=V.get(this);if(e)g[e]&&g[e].stop&&d(g[e]);else for(e in g)g[e]&&g[e].stop&&ab.test(e)&&d(g[e]);for(e=f.length;e--;)f[e].elem!==this||null!=a&&f[e].queue!==a||(f[e].anim.stop(c),b=!1,f.splice(e,1));!b&&c||r.dequeue(this,a)})},finish:function(a){return a!==!1&&(a=a||"fx"),this.each(function(){var b,c=V.get(this),d=c[a+"queue"],e=c[a+"queueHooks"],f=r.timers,g=d?d.length:0;for(c.finish=!0,r.queue(this,a,[]),e&&e.stop&&e.stop.call(this,!0),b=f.length;b--;)f[b].elem===this&&f[b].queue===a&&(f[b].anim.stop(!0),f.splice(b,1));for(b=0;b<g;b++)d[b]&&d[b].finish&&d[b].finish.call(this);delete c.finish})}}),r.each(["toggle","show","hide"],function(a,b){var c=r.fn[b];r.fn[b]=function(a,d,e){return null==a||"boolean"==typeof a?c.apply(this,arguments):this.animate(db(b,!0),a,d,e)}}),r.each({slideDown:db("show"),slideUp:db("hide"),slideToggle:db("toggle"),fadeIn:{opacity:"show"},fadeOut:{opacity:"hide"},fadeToggle:{opacity:"toggle"}},function(a,b){r.fn[a]=function(a,c,d){return this.animate(b,a,c,d)}}),r.timers=[],r.fx.tick=function(){var a,b=0,c=r.timers;for(Za=r.now();b<c.length;b++)a=c[b],a()||c[b]!==a||c.splice(b--,1);c.length||r.fx.stop(),Za=void 0},r.fx.timer=function(a){r.timers.push(a),a()?r.fx.start():r.timers.pop()},r.fx.interval=13,r.fx.start=function(){$a||($a=a.requestAnimationFrame?a.requestAnimationFrame(bb):a.setInterval(r.fx.tick,r.fx.interval))},r.fx.stop=function(){a.cancelAnimationFrame?a.cancelAnimationFrame($a):a.clearInterval($a),$a=null},r.fx.speeds={slow:600,fast:200,_default:400},r.fn.delay=function(b,c){return b=r.fx?r.fx.speeds[b]||b:b,c=c||"fx",this.queue(c,function(c,d){var e=a.setTimeout(c,b);d.stop=function(){a.clearTimeout(e)}})},function(){var a=d.createElement("input"),b=d.createElement("select"),c=b.appendChild(d.createElement("option"));a.type="checkbox",o.checkOn=""!==a.value,o.optSelected=c.selected,a=d.createElement("input"),a.value="t",a.type="radio",o.radioValue="t"===a.value}();var ib,jb=r.expr.attrHandle;r.fn.extend({attr:function(a,b){return S(this,r.attr,a,b,arguments.length>1)},removeAttr:function(a){return this.each(function(){r.removeAttr(this,a)})}}),r.extend({attr:function(a,b,c){var d,e,f=a.nodeType;if(3!==f&&8!==f&&2!==f)return"undefined"==typeof a.getAttribute?r.prop(a,b,c):(1===f&&r.isXMLDoc(a)||(e=r.attrHooks[b.toLowerCase()]||(r.expr.match.bool.test(b)?ib:void 0)),
-void 0!==c?null===c?void r.removeAttr(a,b):e&&"set"in e&&void 0!==(d=e.set(a,c,b))?d:(a.setAttribute(b,c+""),c):e&&"get"in e&&null!==(d=e.get(a,b))?d:(d=r.find.attr(a,b),null==d?void 0:d))},attrHooks:{type:{set:function(a,b){if(!o.radioValue&&"radio"===b&&r.nodeName(a,"input")){var c=a.value;return a.setAttribute("type",b),c&&(a.value=c),b}}}},removeAttr:function(a,b){var c,d=0,e=b&&b.match(K);if(e&&1===a.nodeType)while(c=e[d++])a.removeAttribute(c)}}),ib={set:function(a,b,c){return b===!1?r.removeAttr(a,c):a.setAttribute(c,c),c}},r.each(r.expr.match.bool.source.match(/\w+/g),function(a,b){var c=jb[b]||r.find.attr;jb[b]=function(a,b,d){var e,f,g=b.toLowerCase();return d||(f=jb[g],jb[g]=e,e=null!=c(a,b,d)?g:null,jb[g]=f),e}});var kb=/^(?:input|select|textarea|button)$/i,lb=/^(?:a|area)$/i;r.fn.extend({prop:function(a,b){return S(this,r.prop,a,b,arguments.length>1)},removeProp:function(a){return this.each(function(){delete this[r.propFix[a]||a]})}}),r.extend({prop:function(a,b,c){var d,e,f=a.nodeType;if(3!==f&&8!==f&&2!==f)return 1===f&&r.isXMLDoc(a)||(b=r.propFix[b]||b,e=r.propHooks[b]),void 0!==c?e&&"set"in e&&void 0!==(d=e.set(a,c,b))?d:a[b]=c:e&&"get"in e&&null!==(d=e.get(a,b))?d:a[b]},propHooks:{tabIndex:{get:function(a){var b=r.find.attr(a,"tabindex");return b?parseInt(b,10):kb.test(a.nodeName)||lb.test(a.nodeName)&&a.href?0:-1}}},propFix:{"for":"htmlFor","class":"className"}}),o.optSelected||(r.propHooks.selected={get:function(a){var b=a.parentNode;return b&&b.parentNode&&b.parentNode.selectedIndex,null},set:function(a){var b=a.parentNode;b&&(b.selectedIndex,b.parentNode&&b.parentNode.selectedIndex)}}),r.each(["tabIndex","readOnly","maxLength","cellSpacing","cellPadding","rowSpan","colSpan","useMap","frameBorder","contentEditable"],function(){r.propFix[this.toLowerCase()]=this});function mb(a){var b=a.match(K)||[];return b.join(" ")}function nb(a){return a.getAttribute&&a.getAttribute("class")||""}r.fn.extend({addClass:function(a){var b,c,d,e,f,g,h,i=0;if(r.isFunction(a))return this.each(function(b){r(this).addClass(a.call(this,b,nb(this)))});if("string"==typeof a&&a){b=a.match(K)||[];while(c=this[i++])if(e=nb(c),d=1===c.nodeType&&" "+mb(e)+" "){g=0;while(f=b[g++])d.indexOf(" "+f+" ")<0&&(d+=f+" ");h=mb(d),e!==h&&c.setAttribute("class",h)}}return this},removeClass:function(a){var b,c,d,e,f,g,h,i=0;if(r.isFunction(a))return this.each(function(b){r(this).removeClass(a.call(this,b,nb(this)))});if(!arguments.length)return this.attr("class","");if("string"==typeof a&&a){b=a.match(K)||[];while(c=this[i++])if(e=nb(c),d=1===c.nodeType&&" "+mb(e)+" "){g=0;while(f=b[g++])while(d.indexOf(" "+f+" ")>-1)d=d.replace(" "+f+" "," ");h=mb(d),e!==h&&c.setAttribute("class",h)}}return this},toggleClass:function(a,b){var c=typeof a;return"boolean"==typeof b&&"string"===c?b?this.addClass(a):this.removeClass(a):r.isFunction(a)?this.each(function(c){r(this).toggleClass(a.call(this,c,nb(this),b),b)}):this.each(function(){var b,d,e,f;if("string"===c){d=0,e=r(this),f=a.match(K)||[];while(b=f[d++])e.hasClass(b)?e.removeClass(b):e.addClass(b)}else void 0!==a&&"boolean"!==c||(b=nb(this),b&&V.set(this,"__className__",b),this.setAttribute&&this.setAttribute("class",b||a===!1?"":V.get(this,"__className__")||""))})},hasClass:function(a){var b,c,d=0;b=" "+a+" ";while(c=this[d++])if(1===c.nodeType&&(" "+mb(nb(c))+" ").indexOf(b)>-1)return!0;return!1}});var ob=/\r/g;r.fn.extend({val:function(a){var b,c,d,e=this[0];{if(arguments.length)return d=r.isFunction(a),this.each(function(c){var e;1===this.nodeType&&(e=d?a.call(this,c,r(this).val()):a,null==e?e="":"number"==typeof e?e+="":r.isArray(e)&&(e=r.map(e,function(a){return null==a?"":a+""})),b=r.valHooks[this.type]||r.valHooks[this.nodeName.toLowerCase()],b&&"set"in b&&void 0!==b.set(this,e,"value")||(this.value=e))});if(e)return b=r.valHooks[e.type]||r.valHooks[e.nodeName.toLowerCase()],b&&"get"in b&&void 0!==(c=b.get(e,"value"))?c:(c=e.value,"string"==typeof c?c.replace(ob,""):null==c?"":c)}}}),r.extend({valHooks:{option:{get:function(a){var b=r.find.attr(a,"value");return null!=b?b:mb(r.text(a))}},select:{get:function(a){var b,c,d,e=a.options,f=a.selectedIndex,g="select-one"===a.type,h=g?null:[],i=g?f+1:e.length;for(d=f<0?i:g?f:0;d<i;d++)if(c=e[d],(c.selected||d===f)&&!c.disabled&&(!c.parentNode.disabled||!r.nodeName(c.parentNode,"optgroup"))){if(b=r(c).val(),g)return b;h.push(b)}return h},set:function(a,b){var c,d,e=a.options,f=r.makeArray(b),g=e.length;while(g--)d=e[g],(d.selected=r.inArray(r.valHooks.option.get(d),f)>-1)&&(c=!0);return c||(a.selectedIndex=-1),f}}}}),r.each(["radio","checkbox"],function(){r.valHooks[this]={set:function(a,b){if(r.isArray(b))return a.checked=r.inArray(r(a).val(),b)>-1}},o.checkOn||(r.valHooks[this].get=function(a){return null===a.getAttribute("value")?"on":a.value})});var pb=/^(?:focusinfocus|focusoutblur)$/;r.extend(r.event,{trigger:function(b,c,e,f){var g,h,i,j,k,m,n,o=[e||d],p=l.call(b,"type")?b.type:b,q=l.call(b,"namespace")?b.namespace.split("."):[];if(h=i=e=e||d,3!==e.nodeType&&8!==e.nodeType&&!pb.test(p+r.event.triggered)&&(p.indexOf(".")>-1&&(q=p.split("."),p=q.shift(),q.sort()),k=p.indexOf(":")<0&&"on"+p,b=b[r.expando]?b:new r.Event(p,"object"==typeof b&&b),b.isTrigger=f?2:3,b.namespace=q.join("."),b.rnamespace=b.namespace?new RegExp("(^|\\.)"+q.join("\\.(?:.*\\.|)")+"(\\.|$)"):null,b.result=void 0,b.target||(b.target=e),c=null==c?[b]:r.makeArray(c,[b]),n=r.event.special[p]||{},f||!n.trigger||n.trigger.apply(e,c)!==!1)){if(!f&&!n.noBubble&&!r.isWindow(e)){for(j=n.delegateType||p,pb.test(j+p)||(h=h.parentNode);h;h=h.parentNode)o.push(h),i=h;i===(e.ownerDocument||d)&&o.push(i.defaultView||i.parentWindow||a)}g=0;while((h=o[g++])&&!b.isPropagationStopped())b.type=g>1?j:n.bindType||p,m=(V.get(h,"events")||{})[b.type]&&V.get(h,"handle"),m&&m.apply(h,c),m=k&&h[k],m&&m.apply&&T(h)&&(b.result=m.apply(h,c),b.result===!1&&b.preventDefault());return b.type=p,f||b.isDefaultPrevented()||n._default&&n._default.apply(o.pop(),c)!==!1||!T(e)||k&&r.isFunction(e[p])&&!r.isWindow(e)&&(i=e[k],i&&(e[k]=null),r.event.triggered=p,e[p](),r.event.triggered=void 0,i&&(e[k]=i)),b.result}},simulate:function(a,b,c){var d=r.extend(new r.Event,c,{type:a,isSimulated:!0});r.event.trigger(d,null,b)}}),r.fn.extend({trigger:function(a,b){return this.each(function(){r.event.trigger(a,b,this)})},triggerHandler:function(a,b){var c=this[0];if(c)return r.event.trigger(a,b,c,!0)}}),r.each("blur focus focusin focusout resize scroll click dblclick mousedown mouseup mousemove mouseover mouseout mouseenter mouseleave change select submit keydown keypress keyup contextmenu".split(" "),function(a,b){r.fn[b]=function(a,c){return arguments.length>0?this.on(b,null,a,c):this.trigger(b)}}),r.fn.extend({hover:function(a,b){return this.mouseenter(a).mouseleave(b||a)}}),o.focusin="onfocusin"in a,o.focusin||r.each({focus:"focusin",blur:"focusout"},function(a,b){var c=function(a){r.event.simulate(b,a.target,r.event.fix(a))};r.event.special[b]={setup:function(){var d=this.ownerDocument||this,e=V.access(d,b);e||d.addEventListener(a,c,!0),V.access(d,b,(e||0)+1)},teardown:function(){var d=this.ownerDocument||this,e=V.access(d,b)-1;e?V.access(d,b,e):(d.removeEventListener(a,c,!0),V.remove(d,b))}}});var qb=a.location,rb=r.now(),sb=/\?/;r.parseXML=function(b){var c;if(!b||"string"!=typeof b)return null;try{c=(new a.DOMParser).parseFromString(b,"text/xml")}catch(d){c=void 0}return c&&!c.getElementsByTagName("parsererror").length||r.error("Invalid XML: "+b),c};var tb=/\[\]$/,ub=/\r?\n/g,vb=/^(?:submit|button|image|reset|file)$/i,wb=/^(?:input|select|textarea|keygen)/i;function xb(a,b,c,d){var e;if(r.isArray(b))r.each(b,function(b,e){c||tb.test(a)?d(a,e):xb(a+"["+("object"==typeof e&&null!=e?b:"")+"]",e,c,d)});else if(c||"object"!==r.type(b))d(a,b);else for(e in b)xb(a+"["+e+"]",b[e],c,d)}r.param=function(a,b){var c,d=[],e=function(a,b){var c=r.isFunction(b)?b():b;d[d.length]=encodeURIComponent(a)+"="+encodeURIComponent(null==c?"":c)};if(r.isArray(a)||a.jquery&&!r.isPlainObject(a))r.each(a,function(){e(this.name,this.value)});else for(c in a)xb(c,a[c],b,e);return d.join("&")},r.fn.extend({serialize:function(){return r.param(this.serializeArray())},serializeArray:function(){return this.map(function(){var a=r.prop(this,"elements");return a?r.makeArray(a):this}).filter(function(){var a=this.type;return this.name&&!r(this).is(":disabled")&&wb.test(this.nodeName)&&!vb.test(a)&&(this.checked||!ia.test(a))}).map(function(a,b){var c=r(this).val();return null==c?null:r.isArray(c)?r.map(c,function(a){return{name:b.name,value:a.replace(ub,"\r\n")}}):{name:b.name,value:c.replace(ub,"\r\n")}}).get()}});var yb=/%20/g,zb=/#.*$/,Ab=/([?&])_=[^&]*/,Bb=/^(.*?):[ \t]*([^\r\n]*)$/gm,Cb=/^(?:about|app|app-storage|.+-extension|file|res|widget):$/,Db=/^(?:GET|HEAD)$/,Eb=/^\/\//,Fb={},Gb={},Hb="*/".concat("*"),Ib=d.createElement("a");Ib.href=qb.href;function Jb(a){return function(b,c){"string"!=typeof b&&(c=b,b="*");var d,e=0,f=b.toLowerCase().match(K)||[];if(r.isFunction(c))while(d=f[e++])"+"===d[0]?(d=d.slice(1)||"*",(a[d]=a[d]||[]).unshift(c)):(a[d]=a[d]||[]).push(c)}}function Kb(a,b,c,d){var e={},f=a===Gb;function g(h){var i;return e[h]=!0,r.each(a[h]||[],function(a,h){var j=h(b,c,d);return"string"!=typeof j||f||e[j]?f?!(i=j):void 0:(b.dataTypes.unshift(j),g(j),!1)}),i}return g(b.dataTypes[0])||!e["*"]&&g("*")}function Lb(a,b){var c,d,e=r.ajaxSettings.flatOptions||{};for(c in b)void 0!==b[c]&&((e[c]?a:d||(d={}))[c]=b[c]);return d&&r.extend(!0,a,d),a}function Mb(a,b,c){var d,e,f,g,h=a.contents,i=a.dataTypes;while("*"===i[0])i.shift(),void 0===d&&(d=a.mimeType||b.getResponseHeader("Content-Type"));if(d)for(e in h)if(h[e]&&h[e].test(d)){i.unshift(e);break}if(i[0]in c)f=i[0];else{for(e in c){if(!i[0]||a.converters[e+" "+i[0]]){f=e;break}g||(g=e)}f=f||g}if(f)return f!==i[0]&&i.unshift(f),c[f]}function Nb(a,b,c,d){var e,f,g,h,i,j={},k=a.dataTypes.slice();if(k[1])for(g in a.converters)j[g.toLowerCase()]=a.converters[g];f=k.shift();while(f)if(a.responseFields[f]&&(c[a.responseFields[f]]=b),!i&&d&&a.dataFilter&&(b=a.dataFilter(b,a.dataType)),i=f,f=k.shift())if("*"===f)f=i;else if("*"!==i&&i!==f){if(g=j[i+" "+f]||j["* "+f],!g)for(e in j)if(h=e.split(" "),h[1]===f&&(g=j[i+" "+h[0]]||j["* "+h[0]])){g===!0?g=j[e]:j[e]!==!0&&(f=h[0],k.unshift(h[1]));break}if(g!==!0)if(g&&a["throws"])b=g(b);else try{b=g(b)}catch(l){return{state:"parsererror",error:g?l:"No conversion from "+i+" to "+f}}}return{state:"success",data:b}}r.extend({active:0,lastModified:{},etag:{},ajaxSettings:{url:qb.href,type:"GET",isLocal:Cb.test(qb.protocol),global:!0,processData:!0,async:!0,contentType:"application/x-www-form-urlencoded; charset=UTF-8",accepts:{"*":Hb,text:"text/plain",html:"text/html",xml:"application/xml, text/xml",json:"application/json, text/javascript"},contents:{xml:/\bxml\b/,html:/\bhtml/,json:/\bjson\b/},responseFields:{xml:"responseXML",text:"responseText",json:"responseJSON"},converters:{"* text":String,"text html":!0,"text json":JSON.parse,"text xml":r.parseXML},flatOptions:{url:!0,context:!0}},ajaxSetup:function(a,b){return b?Lb(Lb(a,r.ajaxSettings),b):Lb(r.ajaxSettings,a)},ajaxPrefilter:Jb(Fb),ajaxTransport:Jb(Gb),ajax:function(b,c){"object"==typeof b&&(c=b,b=void 0),c=c||{};var e,f,g,h,i,j,k,l,m,n,o=r.ajaxSetup({},c),p=o.context||o,q=o.context&&(p.nodeType||p.jquery)?r(p):r.event,s=r.Deferred(),t=r.Callbacks("once memory"),u=o.statusCode||{},v={},w={},x="canceled",y={readyState:0,getResponseHeader:function(a){var b;if(k){if(!h){h={};while(b=Bb.exec(g))h[b[1].toLowerCase()]=b[2]}b=h[a.toLowerCase()]}return null==b?null:b},getAllResponseHeaders:function(){return k?g:null},setRequestHeader:function(a,b){return null==k&&(a=w[a.toLowerCase()]=w[a.toLowerCase()]||a,v[a]=b),this},overrideMimeType:function(a){return null==k&&(o.mimeType=a),this},statusCode:function(a){var b;if(a)if(k)y.always(a[y.status]);else for(b in a)u[b]=[u[b],a[b]];return this},abort:function(a){var b=a||x;return e&&e.abort(b),A(0,b),this}};if(s.promise(y),o.url=((b||o.url||qb.href)+"").replace(Eb,qb.protocol+"//"),o.type=c.method||c.type||o.method||o.type,o.dataTypes=(o.dataType||"*").toLowerCase().match(K)||[""],null==o.crossDomain){j=d.createElement("a");try{j.href=o.url,j.href=j.href,o.crossDomain=Ib.protocol+"//"+Ib.host!=j.protocol+"//"+j.host}catch(z){o.crossDomain=!0}}if(o.data&&o.processData&&"string"!=typeof o.data&&(o.data=r.param(o.data,o.traditional)),Kb(Fb,o,c,y),k)return y;l=r.event&&o.global,l&&0===r.active++&&r.event.trigger("ajaxStart"),o.type=o.type.toUpperCase(),o.hasContent=!Db.test(o.type),f=o.url.replace(zb,""),o.hasContent?o.data&&o.processData&&0===(o.contentType||"").indexOf("application/x-www-form-urlencoded")&&(o.data=o.data.replace(yb,"+")):(n=o.url.slice(f.length),o.data&&(f+=(sb.test(f)?"&":"?")+o.data,delete o.data),o.cache===!1&&(f=f.replace(Ab,"$1"),n=(sb.test(f)?"&":"?")+"_="+rb++ +n),o.url=f+n),o.ifModified&&(r.lastModified[f]&&y.setRequestHeader("If-Modified-Since",r.lastModified[f]),r.etag[f]&&y.setRequestHeader("If-None-Match",r.etag[f])),(o.data&&o.hasContent&&o.contentType!==!1||c.contentType)&&y.setRequestHeader("Content-Type",o.contentType),y.setRequestHeader("Accept",o.dataTypes[0]&&o.accepts[o.dataTypes[0]]?o.accepts[o.dataTypes[0]]+("*"!==o.dataTypes[0]?", "+Hb+"; q=0.01":""):o.accepts["*"]);for(m in o.headers)y.setRequestHeader(m,o.headers[m]);if(o.beforeSend&&(o.beforeSend.call(p,y,o)===!1||k))return y.abort();if(x="abort",t.add(o.complete),y.done(o.success),y.fail(o.error),e=Kb(Gb,o,c,y)){if(y.readyState=1,l&&q.trigger("ajaxSend",[y,o]),k)return y;o.async&&o.timeout>0&&(i=a.setTimeout(function(){y.abort("timeout")},o.timeout));try{k=!1,e.send(v,A)}catch(z){if(k)throw z;A(-1,z)}}else A(-1,"No Transport");function A(b,c,d,h){var j,m,n,v,w,x=c;k||(k=!0,i&&a.clearTimeout(i),e=void 0,g=h||"",y.readyState=b>0?4:0,j=b>=200&&b<300||304===b,d&&(v=Mb(o,y,d)),v=Nb(o,v,y,j),j?(o.ifModified&&(w=y.getResponseHeader("Last-Modified"),w&&(r.lastModified[f]=w),w=y.getResponseHeader("etag"),w&&(r.etag[f]=w)),204===b||"HEAD"===o.type?x="nocontent":304===b?x="notmodified":(x=v.state,m=v.data,n=v.error,j=!n)):(n=x,!b&&x||(x="error",b<0&&(b=0))),y.status=b,y.statusText=(c||x)+"",j?s.resolveWith(p,[m,x,y]):s.rejectWith(p,[y,x,n]),y.statusCode(u),u=void 0,l&&q.trigger(j?"ajaxSuccess":"ajaxError",[y,o,j?m:n]),t.fireWith(p,[y,x]),l&&(q.trigger("ajaxComplete",[y,o]),--r.active||r.event.trigger("ajaxStop")))}return y},getJSON:function(a,b,c){return r.get(a,b,c,"json")},getScript:function(a,b){return r.get(a,void 0,b,"script")}}),r.each(["get","post"],function(a,b){r[b]=function(a,c,d,e){return r.isFunction(c)&&(e=e||d,d=c,c=void 0),r.ajax(r.extend({url:a,type:b,dataType:e,data:c,success:d},r.isPlainObject(a)&&a))}}),r._evalUrl=function(a){return r.ajax({url:a,type:"GET",dataType:"script",cache:!0,async:!1,global:!1,"throws":!0})},r.fn.extend({wrapAll:function(a){var b;return this[0]&&(r.isFunction(a)&&(a=a.call(this[0])),b=r(a,this[0].ownerDocument).eq(0).clone(!0),this[0].parentNode&&b.insertBefore(this[0]),b.map(function(){var a=this;while(a.firstElementChild)a=a.firstElementChild;return a}).append(this)),this},wrapInner:function(a){return r.isFunction(a)?this.each(function(b){r(this).wrapInner(a.call(this,b))}):this.each(function(){var b=r(this),c=b.contents();c.length?c.wrapAll(a):b.append(a)})},wrap:function(a){var b=r.isFunction(a);return this.each(function(c){r(this).wrapAll(b?a.call(this,c):a)})},unwrap:function(a){return this.parent(a).not("body").each(function(){r(this).replaceWith(this.childNodes)}),this}}),r.expr.pseudos.hidden=function(a){return!r.expr.pseudos.visible(a)},r.expr.pseudos.visible=function(a){return!!(a.offsetWidth||a.offsetHeight||a.getClientRects().length)},r.ajaxSettings.xhr=function(){try{return new a.XMLHttpRequest}catch(b){}};var Ob={0:200,1223:204},Pb=r.ajaxSettings.xhr();o.cors=!!Pb&&"withCredentials"in Pb,o.ajax=Pb=!!Pb,r.ajaxTransport(function(b){var c,d;if(o.cors||Pb&&!b.crossDomain)return{send:function(e,f){var g,h=b.xhr();if(h.open(b.type,b.url,b.async,b.username,b.password),b.xhrFields)for(g in b.xhrFields)h[g]=b.xhrFields[g];b.mimeType&&h.overrideMimeType&&h.overrideMimeType(b.mimeType),b.crossDomain||e["X-Requested-With"]||(e["X-Requested-With"]="XMLHttpRequest");for(g in e)h.setRequestHeader(g,e[g]);c=function(a){return function(){c&&(c=d=h.onload=h.onerror=h.onabort=h.onreadystatechange=null,"abort"===a?h.abort():"error"===a?"number"!=typeof h.status?f(0,"error"):f(h.status,h.statusText):f(Ob[h.status]||h.status,h.statusText,"text"!==(h.responseType||"text")||"string"!=typeof h.responseText?{binary:h.response}:{text:h.responseText},h.getAllResponseHeaders()))}},h.onload=c(),d=h.onerror=c("error"),void 0!==h.onabort?h.onabort=d:h.onreadystatechange=function(){4===h.readyState&&a.setTimeout(function(){c&&d()})},c=c("abort");try{h.send(b.hasContent&&b.data||null)}catch(i){if(c)throw i}},abort:function(){c&&c()}}}),r.ajaxPrefilter(function(a){a.crossDomain&&(a.contents.script=!1)}),r.ajaxSetup({accepts:{script:"text/javascript, application/javascript, application/ecmascript, application/x-ecmascript"},contents:{script:/\b(?:java|ecma)script\b/},converters:{"text script":function(a){return r.globalEval(a),a}}}),r.ajaxPrefilter("script",function(a){void 0===a.cache&&(a.cache=!1),a.crossDomain&&(a.type="GET")}),r.ajaxTransport("script",function(a){if(a.crossDomain){var b,c;return{send:function(e,f){b=r("<script>").prop({charset:a.scriptCharset,src:a.url}).on("load error",c=function(a){b.remove(),c=null,a&&f("error"===a.type?404:200,a.type)}),d.head.appendChild(b[0])},abort:function(){c&&c()}}}});var Qb=[],Rb=/(=)\?(?=&|$)|\?\?/;r.ajaxSetup({jsonp:"callback",jsonpCallback:function(){var a=Qb.pop()||r.expando+"_"+rb++;return this[a]=!0,a}}),r.ajaxPrefilter("json jsonp",function(b,c,d){var e,f,g,h=b.jsonp!==!1&&(Rb.test(b.url)?"url":"string"==typeof b.data&&0===(b.contentType||"").indexOf("application/x-www-form-urlencoded")&&Rb.test(b.data)&&"data");if(h||"jsonp"===b.dataTypes[0])return e=b.jsonpCallback=r.isFunction(b.jsonpCallback)?b.jsonpCallback():b.jsonpCallback,h?b[h]=b[h].replace(Rb,"$1"+e):b.jsonp!==!1&&(b.url+=(sb.test(b.url)?"&":"?")+b.jsonp+"="+e),b.converters["script json"]=function(){return g||r.error(e+" was not called"),g[0]},b.dataTypes[0]="json",f=a[e],a[e]=function(){g=arguments},d.always(function(){void 0===f?r(a).removeProp(e):a[e]=f,b[e]&&(b.jsonpCallback=c.jsonpCallback,Qb.push(e)),g&&r.isFunction(f)&&f(g[0]),g=f=void 0}),"script"}),o.createHTMLDocument=function(){var a=d.implementation.createHTMLDocument("").body;return a.innerHTML="<form></form><form></form>",2===a.childNodes.length}(),r.parseHTML=function(a,b,c){if("string"!=typeof a)return[];"boolean"==typeof b&&(c=b,b=!1);var e,f,g;return b||(o.createHTMLDocument?(b=d.implementation.createHTMLDocument(""),e=b.createElement("base"),e.href=d.location.href,b.head.appendChild(e)):b=d),f=B.exec(a),g=!c&&[],f?[b.createElement(f[1])]:(f=pa([a],b,g),g&&g.length&&r(g).remove(),r.merge([],f.childNodes))},r.fn.load=function(a,b,c){var d,e,f,g=this,h=a.indexOf(" ");return h>-1&&(d=mb(a.slice(h)),a=a.slice(0,h)),r.isFunction(b)?(c=b,b=void 0):b&&"object"==typeof b&&(e="POST"),g.length>0&&r.ajax({url:a,type:e||"GET",dataType:"html",data:b}).done(function(a){f=arguments,g.html(d?r("<div>").append(r.parseHTML(a)).find(d):a)}).always(c&&function(a,b){g.each(function(){c.apply(this,f||[a.responseText,b,a])})}),this},r.each(["ajaxStart","ajaxStop","ajaxComplete","ajaxError","ajaxSuccess","ajaxSend"],function(a,b){r.fn[b]=function(a){return this.on(b,a)}}),r.expr.pseudos.animated=function(a){return r.grep(r.timers,function(b){return a===b.elem}).length};function Sb(a){return r.isWindow(a)?a:9===a.nodeType&&a.defaultView}r.offset={setOffset:function(a,b,c){var d,e,f,g,h,i,j,k=r.css(a,"position"),l=r(a),m={};"static"===k&&(a.style.position="relative"),h=l.offset(),f=r.css(a,"top"),i=r.css(a,"left"),j=("absolute"===k||"fixed"===k)&&(f+i).indexOf("auto")>-1,j?(d=l.position(),g=d.top,e=d.left):(g=parseFloat(f)||0,e=parseFloat(i)||0),r.isFunction(b)&&(b=b.call(a,c,r.extend({},h))),null!=b.top&&(m.top=b.top-h.top+g),null!=b.left&&(m.left=b.left-h.left+e),"using"in b?b.using.call(a,m):l.css(m)}},r.fn.extend({offset:function(a){if(arguments.length)return void 0===a?this:this.each(function(b){r.offset.setOffset(this,a,b)});var b,c,d,e,f=this[0];if(f)return f.getClientRects().length?(d=f.getBoundingClientRect(),d.width||d.height?(e=f.ownerDocument,c=Sb(e),b=e.documentElement,{top:d.top+c.pageYOffset-b.clientTop,left:d.left+c.pageXOffset-b.clientLeft}):d):{top:0,left:0}},position:function(){if(this[0]){var a,b,c=this[0],d={top:0,left:0};return"fixed"===r.css(c,"position")?b=c.getBoundingClientRect():(a=this.offsetParent(),b=this.offset(),r.nodeName(a[0],"html")||(d=a.offset()),d={top:d.top+r.css(a[0],"borderTopWidth",!0),left:d.left+r.css(a[0],"borderLeftWidth",!0)}),{top:b.top-d.top-r.css(c,"marginTop",!0),left:b.left-d.left-r.css(c,"marginLeft",!0)}}},offsetParent:function(){return this.map(function(){var a=this.offsetParent;while(a&&"static"===r.css(a,"position"))a=a.offsetParent;return a||qa})}}),r.each({scrollLeft:"pageXOffset",scrollTop:"pageYOffset"},function(a,b){var c="pageYOffset"===b;r.fn[a]=function(d){return S(this,function(a,d,e){var f=Sb(a);return void 0===e?f?f[b]:a[d]:void(f?f.scrollTo(c?f.pageXOffset:e,c?e:f.pageYOffset):a[d]=e)},a,d,arguments.length)}}),r.each(["top","left"],function(a,b){r.cssHooks[b]=Oa(o.pixelPosition,function(a,c){if(c)return c=Na(a,b),La.test(c)?r(a).position()[b]+"px":c})}),r.each({Height:"height",Width:"width"},function(a,b){r.each({padding:"inner"+a,content:b,"":"outer"+a},function(c,d){r.fn[d]=function(e,f){var g=arguments.length&&(c||"boolean"!=typeof e),h=c||(e===!0||f===!0?"margin":"border");return S(this,function(b,c,e){var f;return r.isWindow(b)?0===d.indexOf("outer")?b["inner"+a]:b.document.documentElement["client"+a]:9===b.nodeType?(f=b.documentElement,Math.max(b.body["scroll"+a],f["scroll"+a],b.body["offset"+a],f["offset"+a],f["client"+a])):void 0===e?r.css(b,c,h):r.style(b,c,e,h)},b,g?e:void 0,g)}})}),r.fn.extend({bind:function(a,b,c){return this.on(a,null,b,c)},unbind:function(a,b){return this.off(a,null,b)},delegate:function(a,b,c,d){return this.on(b,a,c,d)},undelegate:function(a,b,c){return 1===arguments.length?this.off(a,"**"):this.off(b,a||"**",c)}}),r.parseJSON=JSON.parse,"function"==typeof define&&define.amd&&define("jquery",[],function(){return r});var Tb=a.jQuery,Ub=a.$;return r.noConflict=function(b){return a.$===r&&(a.$=Ub),b&&a.jQuery===r&&(a.jQuery=Tb),r},b||(a.jQuery=a.$=r),r});
+/*! jQuery v3.7.1 | (c) OpenJS Foundation and other contributors | jquery.org/license */
+!function(e,t){"use strict";"object"==typeof module&&"object"==typeof module.exports?module.exports=e.document?t(e,!0):function(e){if(!e.document)throw new Error("jQuery requires a window with a document");return t(e)}:t(e)}("undefined"!=typeof window?window:this,function(ie,e){"use strict";var oe=[],r=Object.getPrototypeOf,ae=oe.slice,g=oe.flat?function(e){return oe.flat.call(e)}:function(e){return oe.concat.apply([],e)},s=oe.push,se=oe.indexOf,n={},i=n.toString,ue=n.hasOwnProperty,o=ue.toString,a=o.call(Object),le={},v=function(e){return"function"==typeof e&&"number"!=typeof e.nodeType&&"function"!=typeof e.item},y=function(e){return null!=e&&e===e.window},C=ie.document,u={type:!0,src:!0,nonce:!0,noModule:!0};function m(e,t,n){var r,i,o=(n=n||C).createElement("script");if(o.text=e,t)for(r in u)(i=t[r]||t.getAttribute&&t.getAttribute(r))&&o.setAttribute(r,i);n.head.appendChild(o).parentNode.removeChild(o)}function x(e){return null==e?e+"":"object"==typeof e||"function"==typeof e?n[i.call(e)]||"object":typeof e}var t="3.7.1",l=/HTML$/i,ce=function(e,t){return new ce.fn.init(e,t)};function c(e){var t=!!e&&"length"in e&&e.length,n=x(e);return!v(e)&&!y(e)&&("array"===n||0===t||"number"==typeof t&&0<t&&t-1 in e)}function fe(e,t){return e.nodeName&&e.nodeName.toLowerCase()===t.toLowerCase()}ce.fn=ce.prototype={jquery:t,constructor:ce,length:0,toArray:function(){return ae.call(this)},get:function(e){return null==e?ae.call(this):e<0?this[e+this.length]:this[e]},pushStack:function(e){var t=ce.merge(this.constructor(),e);return t.prevObject=this,t},each:function(e){return ce.each(this,e)},map:function(n){return this.pushStack(ce.map(this,function(e,t){return n.call(e,t,e)}))},slice:function(){return this.pushStack(ae.apply(this,arguments))},first:function(){return this.eq(0)},last:function(){return this.eq(-1)},even:function(){return this.pushStack(ce.grep(this,function(e,t){return(t+1)%2}))},odd:function(){return this.pushStack(ce.grep(this,function(e,t){return t%2}))},eq:function(e){var t=this.length,n=+e+(e<0?t:0);return this.pushStack(0<=n&&n<t?[this[n]]:[])},end:function(){return this.prevObject||this.constructor()},push:s,sort:oe.sort,splice:oe.splice},ce.extend=ce.fn.extend=function(){var e,t,n,r,i,o,a=arguments[0]||{},s=1,u=arguments.length,l=!1;for("boolean"==typeof a&&(l=a,a=arguments[s]||{},s++),"object"==typeof a||v(a)||(a={}),s===u&&(a=this,s--);s<u;s++)if(null!=(e=arguments[s]))for(t in e)r=e[t],"__proto__"!==t&&a!==r&&(l&&r&&(ce.isPlainObject(r)||(i=Array.isArray(r)))?(n=a[t],o=i&&!Array.isArray(n)?[]:i||ce.isPlainObject(n)?n:{},i=!1,a[t]=ce.extend(l,o,r)):void 0!==r&&(a[t]=r));return a},ce.extend({expando:"jQuery"+(t+Math.random()).replace(/\D/g,""),isReady:!0,error:function(e){throw new Error(e)},noop:function(){},isPlainObject:function(e){var t,n;return!(!e||"[object Object]"!==i.call(e))&&(!(t=r(e))||"function"==typeof(n=ue.call(t,"constructor")&&t.constructor)&&o.call(n)===a)},isEmptyObject:function(e){var t;for(t in e)return!1;return!0},globalEval:function(e,t,n){m(e,{nonce:t&&t.nonce},n)},each:function(e,t){var n,r=0;if(c(e)){for(n=e.length;r<n;r++)if(!1===t.call(e[r],r,e[r]))break}else for(r in e)if(!1===t.call(e[r],r,e[r]))break;return e},text:function(e){var t,n="",r=0,i=e.nodeType;if(!i)while(t=e[r++])n+=ce.text(t);return 1===i||11===i?e.textContent:9===i?e.documentElement.textContent:3===i||4===i?e.nodeValue:n},makeArray:function(e,t){var n=t||[];return null!=e&&(c(Object(e))?ce.merge(n,"string"==typeof e?[e]:e):s.call(n,e)),n},inArray:function(e,t,n){return null==t?-1:se.call(t,e,n)},isXMLDoc:function(e){var t=e&&e.namespaceURI,n=e&&(e.ownerDocument||e).documentElement;return!l.test(t||n&&n.nodeName||"HTML")},merge:function(e,t){for(var n=+t.length,r=0,i=e.length;r<n;r++)e[i++]=t[r];return e.length=i,e},grep:function(e,t,n){for(var r=[],i=0,o=e.length,a=!n;i<o;i++)!t(e[i],i)!==a&&r.push(e[i]);return r},map:function(e,t,n){var r,i,o=0,a=[];if(c(e))for(r=e.length;o<r;o++)null!=(i=t(e[o],o,n))&&a.push(i);else for(o in e)null!=(i=t(e[o],o,n))&&a.push(i);return g(a)},guid:1,support:le}),"function"==typeof Symbol&&(ce.fn[Symbol.iterator]=oe[Symbol.iterator]),ce.each("Boolean Number String Function Array Date RegExp Object Error Symbol".split(" "),function(e,t){n["[object "+t+"]"]=t.toLowerCase()});var pe=oe.pop,de=oe.sort,he=oe.splice,ge="[\\x20\\t\\r\\n\\f]",ve=new RegExp("^"+ge+"+|((?:^|[^\\\\])(?:\\\\.)*)"+ge+"+$","g");ce.contains=function(e,t){var n=t&&t.parentNode;return e===n||!(!n||1!==n.nodeType||!(e.contains?e.contains(n):e.compareDocumentPosition&&16&e.compareDocumentPosition(n)))};var f=/([\0-\x1f\x7f]|^-?\d)|^-$|[^\x80-\uFFFF\w-]/g;function p(e,t){return t?"\0"===e?"\ufffd":e.slice(0,-1)+"\\"+e.charCodeAt(e.length-1).toString(16)+" ":"\\"+e}ce.escapeSelector=function(e){return(e+"").replace(f,p)};var ye=C,me=s;!function(){var e,b,w,o,a,T,r,C,d,i,k=me,S=ce.expando,E=0,n=0,s=W(),c=W(),u=W(),h=W(),l=function(e,t){return e===t&&(a=!0),0},f="checked|selected|async|autofocus|autoplay|controls|defer|disabled|hidden|ismap|loop|multiple|open|readonly|required|scoped",t="(?:\\\\[\\da-fA-F]{1,6}"+ge+"?|\\\\[^\\r\\n\\f]|[\\w-]|[^\0-\\x7f])+",p="\\["+ge+"*("+t+")(?:"+ge+"*([*^$|!~]?=)"+ge+"*(?:'((?:\\\\.|[^\\\\'])*)'|\"((?:\\\\.|[^\\\\\"])*)\"|("+t+"))|)"+ge+"*\\]",g=":("+t+")(?:\\((('((?:\\\\.|[^\\\\'])*)'|\"((?:\\\\.|[^\\\\\"])*)\")|((?:\\\\.|[^\\\\()[\\]]|"+p+")*)|.*)\\)|)",v=new RegExp(ge+"+","g"),y=new RegExp("^"+ge+"*,"+ge+"*"),m=new RegExp("^"+ge+"*([>+~]|"+ge+")"+ge+"*"),x=new RegExp(ge+"|>"),j=new RegExp(g),A=new RegExp("^"+t+"$"),D={ID:new RegExp("^#("+t+")"),CLASS:new RegExp("^\\.("+t+")"),TAG:new RegExp("^("+t+"|[*])"),ATTR:new RegExp("^"+p),PSEUDO:new RegExp("^"+g),CHILD:new RegExp("^:(only|first|last|nth|nth-last)-(child|of-type)(?:\\("+ge+"*(even|odd|(([+-]|)(\\d*)n|)"+ge+"*(?:([+-]|)"+ge+"*(\\d+)|))"+ge+"*\\)|)","i"),bool:new RegExp("^(?:"+f+")$","i"),needsContext:new RegExp("^"+ge+"*[>+~]|:(even|odd|eq|gt|lt|nth|first|last)(?:\\("+ge+"*((?:-\\d)?\\d*)"+ge+"*\\)|)(?=[^-]|$)","i")},N=/^(?:input|select|textarea|button)$/i,q=/^h\d$/i,L=/^(?:#([\w-]+)|(\w+)|\.([\w-]+))$/,H=/[+~]/,O=new RegExp("\\\\[\\da-fA-F]{1,6}"+ge+"?|\\\\([^\\r\\n\\f])","g"),P=function(e,t){var n="0x"+e.slice(1)-65536;return t||(n<0?String.fromCharCode(n+65536):String.fromCharCode(n>>10|55296,1023&n|56320))},M=function(){V()},R=J(function(e){return!0===e.disabled&&fe(e,"fieldset")},{dir:"parentNode",next:"legend"});try{k.apply(oe=ae.call(ye.childNodes),ye.childNodes),oe[ye.childNodes.length].nodeType}catch(e){k={apply:function(e,t){me.apply(e,ae.call(t))},call:function(e){me.apply(e,ae.call(arguments,1))}}}function I(t,e,n,r){var i,o,a,s,u,l,c,f=e&&e.ownerDocument,p=e?e.nodeType:9;if(n=n||[],"string"!=typeof t||!t||1!==p&&9!==p&&11!==p)return n;if(!r&&(V(e),e=e||T,C)){if(11!==p&&(u=L.exec(t)))if(i=u[1]){if(9===p){if(!(a=e.getElementById(i)))return n;if(a.id===i)return k.call(n,a),n}else if(f&&(a=f.getElementById(i))&&I.contains(e,a)&&a.id===i)return k.call(n,a),n}else{if(u[2])return k.apply(n,e.getElementsByTagName(t)),n;if((i=u[3])&&e.getElementsByClassName)return k.apply(n,e.getElementsByClassName(i)),n}if(!(h[t+" "]||d&&d.test(t))){if(c=t,f=e,1===p&&(x.test(t)||m.test(t))){(f=H.test(t)&&U(e.parentNode)||e)==e&&le.scope||((s=e.getAttribute("id"))?s=ce.escapeSelector(s):e.setAttribute("id",s=S)),o=(l=Y(t)).length;while(o--)l[o]=(s?"#"+s:":scope")+" "+Q(l[o]);c=l.join(",")}try{return k.apply(n,f.querySelectorAll(c)),n}catch(e){h(t,!0)}finally{s===S&&e.removeAttribute("id")}}}return re(t.replace(ve,"$1"),e,n,r)}function W(){var r=[];return function e(t,n){return r.push(t+" ")>b.cacheLength&&delete e[r.shift()],e[t+" "]=n}}function F(e){return e[S]=!0,e}function $(e){var t=T.createElement("fieldset");try{return!!e(t)}catch(e){return!1}finally{t.parentNode&&t.parentNode.removeChild(t),t=null}}function B(t){return function(e){return fe(e,"input")&&e.type===t}}function _(t){return function(e){return(fe(e,"input")||fe(e,"button"))&&e.type===t}}function z(t){return function(e){return"form"in e?e.parentNode&&!1===e.disabled?"label"in e?"label"in e.parentNode?e.parentNode.disabled===t:e.disabled===t:e.isDisabled===t||e.isDisabled!==!t&&R(e)===t:e.disabled===t:"label"in e&&e.disabled===t}}function X(a){return F(function(o){return o=+o,F(function(e,t){var n,r=a([],e.length,o),i=r.length;while(i--)e[n=r[i]]&&(e[n]=!(t[n]=e[n]))})})}function U(e){return e&&"undefined"!=typeof e.getElementsByTagName&&e}function V(e){var t,n=e?e.ownerDocument||e:ye;return n!=T&&9===n.nodeType&&n.documentElement&&(r=(T=n).documentElement,C=!ce.isXMLDoc(T),i=r.matches||r.webkitMatchesSelector||r.msMatchesSelector,r.msMatchesSelector&&ye!=T&&(t=T.defaultView)&&t.top!==t&&t.addEventListener("unload",M),le.getById=$(function(e){return r.appendChild(e).id=ce.expando,!T.getElementsByName||!T.getElementsByName(ce.expando).length}),le.disconnectedMatch=$(function(e){return i.call(e,"*")}),le.scope=$(function(){return T.querySelectorAll(":scope")}),le.cssHas=$(function(){try{return T.querySelector(":has(*,:jqfake)"),!1}catch(e){return!0}}),le.getById?(b.filter.ID=function(e){var t=e.replace(O,P);return function(e){return e.getAttribute("id")===t}},b.find.ID=function(e,t){if("undefined"!=typeof t.getElementById&&C){var n=t.getElementById(e);return n?[n]:[]}}):(b.filter.ID=function(e){var n=e.replace(O,P);return function(e){var t="undefined"!=typeof e.getAttributeNode&&e.getAttributeNode("id");return t&&t.value===n}},b.find.ID=function(e,t){if("undefined"!=typeof t.getElementById&&C){var n,r,i,o=t.getElementById(e);if(o){if((n=o.getAttributeNode("id"))&&n.value===e)return[o];i=t.getElementsByName(e),r=0;while(o=i[r++])if((n=o.getAttributeNode("id"))&&n.value===e)return[o]}return[]}}),b.find.TAG=function(e,t){return"undefined"!=typeof t.getElementsByTagName?t.getElementsByTagName(e):t.querySelectorAll(e)},b.find.CLASS=function(e,t){if("undefined"!=typeof t.getElementsByClassName&&C)return t.getElementsByClassName(e)},d=[],$(function(e){var t;r.appendChild(e).innerHTML="<a id='"+S+"' href='' disabled='disabled'></a><select id='"+S+"-\r\\' disabled='disabled'><option selected=''></option></select>",e.querySelectorAll("[selected]").length||d.push("\\["+ge+"*(?:value|"+f+")"),e.querySelectorAll("[id~="+S+"-]").length||d.push("~="),e.querySelectorAll("a#"+S+"+*").length||d.push(".#.+[+~]"),e.querySelectorAll(":checked").length||d.push(":checked"),(t=T.createElement("input")).setAttribute("type","hidden"),e.appendChild(t).setAttribute("name","D"),r.appendChild(e).disabled=!0,2!==e.querySelectorAll(":disabled").length&&d.push(":enabled",":disabled"),(t=T.createElement("input")).setAttribute("name",""),e.appendChild(t),e.querySelectorAll("[name='']").length||d.push("\\["+ge+"*name"+ge+"*="+ge+"*(?:''|\"\")")}),le.cssHas||d.push(":has"),d=d.length&&new RegExp(d.join("|")),l=function(e,t){if(e===t)return a=!0,0;var n=!e.compareDocumentPosition-!t.compareDocumentPosition;return n||(1&(n=(e.ownerDocument||e)==(t.ownerDocument||t)?e.compareDocumentPosition(t):1)||!le.sortDetached&&t.compareDocumentPosition(e)===n?e===T||e.ownerDocument==ye&&I.contains(ye,e)?-1:t===T||t.ownerDocument==ye&&I.contains(ye,t)?1:o?se.call(o,e)-se.call(o,t):0:4&n?-1:1)}),T}for(e in I.matches=function(e,t){return I(e,null,null,t)},I.matchesSelector=function(e,t){if(V(e),C&&!h[t+" "]&&(!d||!d.test(t)))try{var n=i.call(e,t);if(n||le.disconnectedMatch||e.document&&11!==e.document.nodeType)return n}catch(e){h(t,!0)}return 0<I(t,T,null,[e]).length},I.contains=function(e,t){return(e.ownerDocument||e)!=T&&V(e),ce.contains(e,t)},I.attr=function(e,t){(e.ownerDocument||e)!=T&&V(e);var n=b.attrHandle[t.toLowerCase()],r=n&&ue.call(b.attrHandle,t.toLowerCase())?n(e,t,!C):void 0;return void 0!==r?r:e.getAttribute(t)},I.error=function(e){throw new Error("Syntax error, unrecognized expression: "+e)},ce.uniqueSort=function(e){var t,n=[],r=0,i=0;if(a=!le.sortStable,o=!le.sortStable&&ae.call(e,0),de.call(e,l),a){while(t=e[i++])t===e[i]&&(r=n.push(i));while(r--)he.call(e,n[r],1)}return o=null,e},ce.fn.uniqueSort=function(){return this.pushStack(ce.uniqueSort(ae.apply(this)))},(b=ce.expr={cacheLength:50,createPseudo:F,match:D,attrHandle:{},find:{},relative:{">":{dir:"parentNode",first:!0}," ":{dir:"parentNode"},"+":{dir:"previousSibling",first:!0},"~":{dir:"previousSibling"}},preFilter:{ATTR:function(e){return e[1]=e[1].replace(O,P),e[3]=(e[3]||e[4]||e[5]||"").replace(O,P),"~="===e[2]&&(e[3]=" "+e[3]+" "),e.slice(0,4)},CHILD:function(e){return e[1]=e[1].toLowerCase(),"nth"===e[1].slice(0,3)?(e[3]||I.error(e[0]),e[4]=+(e[4]?e[5]+(e[6]||1):2*("even"===e[3]||"odd"===e[3])),e[5]=+(e[7]+e[8]||"odd"===e[3])):e[3]&&I.error(e[0]),e},PSEUDO:function(e){var t,n=!e[6]&&e[2];return D.CHILD.test(e[0])?null:(e[3]?e[2]=e[4]||e[5]||"":n&&j.test(n)&&(t=Y(n,!0))&&(t=n.indexOf(")",n.length-t)-n.length)&&(e[0]=e[0].slice(0,t),e[2]=n.slice(0,t)),e.slice(0,3))}},filter:{TAG:function(e){var t=e.replace(O,P).toLowerCase();return"*"===e?function(){return!0}:function(e){return fe(e,t)}},CLASS:function(e){var t=s[e+" "];return t||(t=new RegExp("(^|"+ge+")"+e+"("+ge+"|$)"))&&s(e,function(e){return t.test("string"==typeof e.className&&e.className||"undefined"!=typeof e.getAttribute&&e.getAttribute("class")||"")})},ATTR:function(n,r,i){return function(e){var t=I.attr(e,n);return null==t?"!="===r:!r||(t+="","="===r?t===i:"!="===r?t!==i:"^="===r?i&&0===t.indexOf(i):"*="===r?i&&-1<t.indexOf(i):"$="===r?i&&t.slice(-i.length)===i:"~="===r?-1<(" "+t.replace(v," ")+" ").indexOf(i):"|="===r&&(t===i||t.slice(0,i.length+1)===i+"-"))}},CHILD:function(d,e,t,h,g){var v="nth"!==d.slice(0,3),y="last"!==d.slice(-4),m="of-type"===e;return 1===h&&0===g?function(e){return!!e.parentNode}:function(e,t,n){var r,i,o,a,s,u=v!==y?"nextSibling":"previousSibling",l=e.parentNode,c=m&&e.nodeName.toLowerCase(),f=!n&&!m,p=!1;if(l){if(v){while(u){o=e;while(o=o[u])if(m?fe(o,c):1===o.nodeType)return!1;s=u="only"===d&&!s&&"nextSibling"}return!0}if(s=[y?l.firstChild:l.lastChild],y&&f){p=(a=(r=(i=l[S]||(l[S]={}))[d]||[])[0]===E&&r[1])&&r[2],o=a&&l.childNodes[a];while(o=++a&&o&&o[u]||(p=a=0)||s.pop())if(1===o.nodeType&&++p&&o===e){i[d]=[E,a,p];break}}else if(f&&(p=a=(r=(i=e[S]||(e[S]={}))[d]||[])[0]===E&&r[1]),!1===p)while(o=++a&&o&&o[u]||(p=a=0)||s.pop())if((m?fe(o,c):1===o.nodeType)&&++p&&(f&&((i=o[S]||(o[S]={}))[d]=[E,p]),o===e))break;return(p-=g)===h||p%h==0&&0<=p/h}}},PSEUDO:function(e,o){var t,a=b.pseudos[e]||b.setFilters[e.toLowerCase()]||I.error("unsupported pseudo: "+e);return a[S]?a(o):1<a.length?(t=[e,e,"",o],b.setFilters.hasOwnProperty(e.toLowerCase())?F(function(e,t){var n,r=a(e,o),i=r.length;while(i--)e[n=se.call(e,r[i])]=!(t[n]=r[i])}):function(e){return a(e,0,t)}):a}},pseudos:{not:F(function(e){var r=[],i=[],s=ne(e.replace(ve,"$1"));return s[S]?F(function(e,t,n,r){var i,o=s(e,null,r,[]),a=e.length;while(a--)(i=o[a])&&(e[a]=!(t[a]=i))}):function(e,t,n){return r[0]=e,s(r,null,n,i),r[0]=null,!i.pop()}}),has:F(function(t){return function(e){return 0<I(t,e).length}}),contains:F(function(t){return t=t.replace(O,P),function(e){return-1<(e.textContent||ce.text(e)).indexOf(t)}}),lang:F(function(n){return A.test(n||"")||I.error("unsupported lang: "+n),n=n.replace(O,P).toLowerCase(),function(e){var t;do{if(t=C?e.lang:e.getAttribute("xml:lang")||e.getAttribute("lang"))return(t=t.toLowerCase())===n||0===t.indexOf(n+"-")}while((e=e.parentNode)&&1===e.nodeType);return!1}}),target:function(e){var t=ie.location&&ie.location.hash;return t&&t.slice(1)===e.id},root:function(e){return e===r},focus:function(e){return e===function(){try{return T.activeElement}catch(e){}}()&&T.hasFocus()&&!!(e.type||e.href||~e.tabIndex)},enabled:z(!1),disabled:z(!0),checked:function(e){return fe(e,"input")&&!!e.checked||fe(e,"option")&&!!e.selected},selected:function(e){return e.parentNode&&e.parentNode.selectedIndex,!0===e.selected},empty:function(e){for(e=e.firstChild;e;e=e.nextSibling)if(e.nodeType<6)return!1;return!0},parent:function(e){return!b.pseudos.empty(e)},header:function(e){return q.test(e.nodeName)},input:function(e){return N.test(e.nodeName)},button:function(e){return fe(e,"input")&&"button"===e.type||fe(e,"button")},text:function(e){var t;return fe(e,"input")&&"text"===e.type&&(null==(t=e.getAttribute("type"))||"text"===t.toLowerCase())},first:X(function(){return[0]}),last:X(function(e,t){return[t-1]}),eq:X(function(e,t,n){return[n<0?n+t:n]}),even:X(function(e,t){for(var n=0;n<t;n+=2)e.push(n);return e}),odd:X(function(e,t){for(var n=1;n<t;n+=2)e.push(n);return e}),lt:X(function(e,t,n){var r;for(r=n<0?n+t:t<n?t:n;0<=--r;)e.push(r);return e}),gt:X(function(e,t,n){for(var r=n<0?n+t:n;++r<t;)e.push(r);return e})}}).pseudos.nth=b.pseudos.eq,{radio:!0,checkbox:!0,file:!0,password:!0,image:!0})b.pseudos[e]=B(e);for(e in{submit:!0,reset:!0})b.pseudos[e]=_(e);function G(){}function Y(e,t){var n,r,i,o,a,s,u,l=c[e+" "];if(l)return t?0:l.slice(0);a=e,s=[],u=b.preFilter;while(a){for(o in n&&!(r=y.exec(a))||(r&&(a=a.slice(r[0].length)||a),s.push(i=[])),n=!1,(r=m.exec(a))&&(n=r.shift(),i.push({value:n,type:r[0].replace(ve," ")}),a=a.slice(n.length)),b.filter)!(r=D[o].exec(a))||u[o]&&!(r=u[o](r))||(n=r.shift(),i.push({value:n,type:o,matches:r}),a=a.slice(n.length));if(!n)break}return t?a.length:a?I.error(e):c(e,s).slice(0)}function Q(e){for(var t=0,n=e.length,r="";t<n;t++)r+=e[t].value;return r}function J(a,e,t){var s=e.dir,u=e.next,l=u||s,c=t&&"parentNode"===l,f=n++;return e.first?function(e,t,n){while(e=e[s])if(1===e.nodeType||c)return a(e,t,n);return!1}:function(e,t,n){var r,i,o=[E,f];if(n){while(e=e[s])if((1===e.nodeType||c)&&a(e,t,n))return!0}else while(e=e[s])if(1===e.nodeType||c)if(i=e[S]||(e[S]={}),u&&fe(e,u))e=e[s]||e;else{if((r=i[l])&&r[0]===E&&r[1]===f)return o[2]=r[2];if((i[l]=o)[2]=a(e,t,n))return!0}return!1}}function K(i){return 1<i.length?function(e,t,n){var r=i.length;while(r--)if(!i[r](e,t,n))return!1;return!0}:i[0]}function Z(e,t,n,r,i){for(var o,a=[],s=0,u=e.length,l=null!=t;s<u;s++)(o=e[s])&&(n&&!n(o,r,i)||(a.push(o),l&&t.push(s)));return a}function ee(d,h,g,v,y,e){return v&&!v[S]&&(v=ee(v)),y&&!y[S]&&(y=ee(y,e)),F(function(e,t,n,r){var i,o,a,s,u=[],l=[],c=t.length,f=e||function(e,t,n){for(var r=0,i=t.length;r<i;r++)I(e,t[r],n);return n}(h||"*",n.nodeType?[n]:n,[]),p=!d||!e&&h?f:Z(f,u,d,n,r);if(g?g(p,s=y||(e?d:c||v)?[]:t,n,r):s=p,v){i=Z(s,l),v(i,[],n,r),o=i.length;while(o--)(a=i[o])&&(s[l[o]]=!(p[l[o]]=a))}if(e){if(y||d){if(y){i=[],o=s.length;while(o--)(a=s[o])&&i.push(p[o]=a);y(null,s=[],i,r)}o=s.length;while(o--)(a=s[o])&&-1<(i=y?se.call(e,a):u[o])&&(e[i]=!(t[i]=a))}}else s=Z(s===t?s.splice(c,s.length):s),y?y(null,t,s,r):k.apply(t,s)})}function te(e){for(var i,t,n,r=e.length,o=b.relative[e[0].type],a=o||b.relative[" "],s=o?1:0,u=J(function(e){return e===i},a,!0),l=J(function(e){return-1<se.call(i,e)},a,!0),c=[function(e,t,n){var r=!o&&(n||t!=w)||((i=t).nodeType?u(e,t,n):l(e,t,n));return i=null,r}];s<r;s++)if(t=b.relative[e[s].type])c=[J(K(c),t)];else{if((t=b.filter[e[s].type].apply(null,e[s].matches))[S]){for(n=++s;n<r;n++)if(b.relative[e[n].type])break;return ee(1<s&&K(c),1<s&&Q(e.slice(0,s-1).concat({value:" "===e[s-2].type?"*":""})).replace(ve,"$1"),t,s<n&&te(e.slice(s,n)),n<r&&te(e=e.slice(n)),n<r&&Q(e))}c.push(t)}return K(c)}function ne(e,t){var n,v,y,m,x,r,i=[],o=[],a=u[e+" "];if(!a){t||(t=Y(e)),n=t.length;while(n--)(a=te(t[n]))[S]?i.push(a):o.push(a);(a=u(e,(v=o,m=0<(y=i).length,x=0<v.length,r=function(e,t,n,r,i){var o,a,s,u=0,l="0",c=e&&[],f=[],p=w,d=e||x&&b.find.TAG("*",i),h=E+=null==p?1:Math.random()||.1,g=d.length;for(i&&(w=t==T||t||i);l!==g&&null!=(o=d[l]);l++){if(x&&o){a=0,t||o.ownerDocument==T||(V(o),n=!C);while(s=v[a++])if(s(o,t||T,n)){k.call(r,o);break}i&&(E=h)}m&&((o=!s&&o)&&u--,e&&c.push(o))}if(u+=l,m&&l!==u){a=0;while(s=y[a++])s(c,f,t,n);if(e){if(0<u)while(l--)c[l]||f[l]||(f[l]=pe.call(r));f=Z(f)}k.apply(r,f),i&&!e&&0<f.length&&1<u+y.length&&ce.uniqueSort(r)}return i&&(E=h,w=p),c},m?F(r):r))).selector=e}return a}function re(e,t,n,r){var i,o,a,s,u,l="function"==typeof e&&e,c=!r&&Y(e=l.selector||e);if(n=n||[],1===c.length){if(2<(o=c[0]=c[0].slice(0)).length&&"ID"===(a=o[0]).type&&9===t.nodeType&&C&&b.relative[o[1].type]){if(!(t=(b.find.ID(a.matches[0].replace(O,P),t)||[])[0]))return n;l&&(t=t.parentNode),e=e.slice(o.shift().value.length)}i=D.needsContext.test(e)?0:o.length;while(i--){if(a=o[i],b.relative[s=a.type])break;if((u=b.find[s])&&(r=u(a.matches[0].replace(O,P),H.test(o[0].type)&&U(t.parentNode)||t))){if(o.splice(i,1),!(e=r.length&&Q(o)))return k.apply(n,r),n;break}}}return(l||ne(e,c))(r,t,!C,n,!t||H.test(e)&&U(t.parentNode)||t),n}G.prototype=b.filters=b.pseudos,b.setFilters=new G,le.sortStable=S.split("").sort(l).join("")===S,V(),le.sortDetached=$(function(e){return 1&e.compareDocumentPosition(T.createElement("fieldset"))}),ce.find=I,ce.expr[":"]=ce.expr.pseudos,ce.unique=ce.uniqueSort,I.compile=ne,I.select=re,I.setDocument=V,I.tokenize=Y,I.escape=ce.escapeSelector,I.getText=ce.text,I.isXML=ce.isXMLDoc,I.selectors=ce.expr,I.support=ce.support,I.uniqueSort=ce.uniqueSort}();var d=function(e,t,n){var r=[],i=void 0!==n;while((e=e[t])&&9!==e.nodeType)if(1===e.nodeType){if(i&&ce(e).is(n))break;r.push(e)}return r},h=function(e,t){for(var n=[];e;e=e.nextSibling)1===e.nodeType&&e!==t&&n.push(e);return n},b=ce.expr.match.needsContext,w=/^<([a-z][^\/\0>:\x20\t\r\n\f]*)[\x20\t\r\n\f]*\/?>(?:<\/\1>|)$/i;function T(e,n,r){return v(n)?ce.grep(e,function(e,t){return!!n.call(e,t,e)!==r}):n.nodeType?ce.grep(e,function(e){return e===n!==r}):"string"!=typeof n?ce.grep(e,function(e){return-1<se.call(n,e)!==r}):ce.filter(n,e,r)}ce.filter=function(e,t,n){var r=t[0];return n&&(e=":not("+e+")"),1===t.length&&1===r.nodeType?ce.find.matchesSelector(r,e)?[r]:[]:ce.find.matches(e,ce.grep(t,function(e){return 1===e.nodeType}))},ce.fn.extend({find:function(e){var t,n,r=this.length,i=this;if("string"!=typeof e)return this.pushStack(ce(e).filter(function(){for(t=0;t<r;t++)if(ce.contains(i[t],this))return!0}));for(n=this.pushStack([]),t=0;t<r;t++)ce.find(e,i[t],n);return 1<r?ce.uniqueSort(n):n},filter:function(e){return this.pushStack(T(this,e||[],!1))},not:function(e){return this.pushStack(T(this,e||[],!0))},is:function(e){return!!T(this,"string"==typeof e&&b.test(e)?ce(e):e||[],!1).length}});var k,S=/^(?:\s*(<[\w\W]+>)[^>]*|#([\w-]+))$/;(ce.fn.init=function(e,t,n){var r,i;if(!e)return this;if(n=n||k,"string"==typeof e){if(!(r="<"===e[0]&&">"===e[e.length-1]&&3<=e.length?[null,e,null]:S.exec(e))||!r[1]&&t)return!t||t.jquery?(t||n).find(e):this.constructor(t).find(e);if(r[1]){if(t=t instanceof ce?t[0]:t,ce.merge(this,ce.parseHTML(r[1],t&&t.nodeType?t.ownerDocument||t:C,!0)),w.test(r[1])&&ce.isPlainObject(t))for(r in t)v(this[r])?this[r](t[r]):this.attr(r,t[r]);return this}return(i=C.getElementById(r[2]))&&(this[0]=i,this.length=1),this}return e.nodeType?(this[0]=e,this.length=1,this):v(e)?void 0!==n.ready?n.ready(e):e(ce):ce.makeArray(e,this)}).prototype=ce.fn,k=ce(C);var E=/^(?:parents|prev(?:Until|All))/,j={children:!0,contents:!0,next:!0,prev:!0};function A(e,t){while((e=e[t])&&1!==e.nodeType);return e}ce.fn.extend({has:function(e){var t=ce(e,this),n=t.length;return this.filter(function(){for(var e=0;e<n;e++)if(ce.contains(this,t[e]))return!0})},closest:function(e,t){var n,r=0,i=this.length,o=[],a="string"!=typeof e&&ce(e);if(!b.test(e))for(;r<i;r++)for(n=this[r];n&&n!==t;n=n.parentNode)if(n.nodeType<11&&(a?-1<a.index(n):1===n.nodeType&&ce.find.matchesSelector(n,e))){o.push(n);break}return this.pushStack(1<o.length?ce.uniqueSort(o):o)},index:function(e){return e?"string"==typeof e?se.call(ce(e),this[0]):se.call(this,e.jquery?e[0]:e):this[0]&&this[0].parentNode?this.first().prevAll().length:-1},add:function(e,t){return this.pushStack(ce.uniqueSort(ce.merge(this.get(),ce(e,t))))},addBack:function(e){return this.add(null==e?this.prevObject:this.prevObject.filter(e))}}),ce.each({parent:function(e){var t=e.parentNode;return t&&11!==t.nodeType?t:null},parents:function(e){return d(e,"parentNode")},parentsUntil:function(e,t,n){return d(e,"parentNode",n)},next:function(e){return A(e,"nextSibling")},prev:function(e){return A(e,"previousSibling")},nextAll:function(e){return d(e,"nextSibling")},prevAll:function(e){return d(e,"previousSibling")},nextUntil:function(e,t,n){return d(e,"nextSibling",n)},prevUntil:function(e,t,n){return d(e,"previousSibling",n)},siblings:function(e){return h((e.parentNode||{}).firstChild,e)},children:function(e){return h(e.firstChild)},contents:function(e){return null!=e.contentDocument&&r(e.contentDocument)?e.contentDocument:(fe(e,"template")&&(e=e.content||e),ce.merge([],e.childNodes))}},function(r,i){ce.fn[r]=function(e,t){var n=ce.map(this,i,e);return"Until"!==r.slice(-5)&&(t=e),t&&"string"==typeof t&&(n=ce.filter(t,n)),1<this.length&&(j[r]||ce.uniqueSort(n),E.test(r)&&n.reverse()),this.pushStack(n)}});var D=/[^\x20\t\r\n\f]+/g;function N(e){return e}function q(e){throw e}function L(e,t,n,r){var i;try{e&&v(i=e.promise)?i.call(e).done(t).fail(n):e&&v(i=e.then)?i.call(e,t,n):t.apply(void 0,[e].slice(r))}catch(e){n.apply(void 0,[e])}}ce.Callbacks=function(r){var e,n;r="string"==typeof r?(e=r,n={},ce.each(e.match(D)||[],function(e,t){n[t]=!0}),n):ce.extend({},r);var i,t,o,a,s=[],u=[],l=-1,c=function(){for(a=a||r.once,o=i=!0;u.length;l=-1){t=u.shift();while(++l<s.length)!1===s[l].apply(t[0],t[1])&&r.stopOnFalse&&(l=s.length,t=!1)}r.memory||(t=!1),i=!1,a&&(s=t?[]:"")},f={add:function(){return s&&(t&&!i&&(l=s.length-1,u.push(t)),function n(e){ce.each(e,function(e,t){v(t)?r.unique&&f.has(t)||s.push(t):t&&t.length&&"string"!==x(t)&&n(t)})}(arguments),t&&!i&&c()),this},remove:function(){return ce.each(arguments,function(e,t){var n;while(-1<(n=ce.inArray(t,s,n)))s.splice(n,1),n<=l&&l--}),this},has:function(e){return e?-1<ce.inArray(e,s):0<s.length},empty:function(){return s&&(s=[]),this},disable:function(){return a=u=[],s=t="",this},disabled:function(){return!s},lock:function(){return a=u=[],t||i||(s=t=""),this},locked:function(){return!!a},fireWith:function(e,t){return a||(t=[e,(t=t||[]).slice?t.slice():t],u.push(t),i||c()),this},fire:function(){return f.fireWith(this,arguments),this},fired:function(){return!!o}};return f},ce.extend({Deferred:function(e){var o=[["notify","progress",ce.Callbacks("memory"),ce.Callbacks("memory"),2],["resolve","done",ce.Callbacks("once memory"),ce.Callbacks("once memory"),0,"resolved"],["reject","fail",ce.Callbacks("once memory"),ce.Callbacks("once memory"),1,"rejected"]],i="pending",a={state:function(){return i},always:function(){return s.done(arguments).fail(arguments),this},"catch":function(e){return a.then(null,e)},pipe:function(){var i=arguments;return ce.Deferred(function(r){ce.each(o,function(e,t){var n=v(i[t[4]])&&i[t[4]];s[t[1]](function(){var e=n&&n.apply(this,arguments);e&&v(e.promise)?e.promise().progress(r.notify).done(r.resolve).fail(r.reject):r[t[0]+"With"](this,n?[e]:arguments)})}),i=null}).promise()},then:function(t,n,r){var u=0;function l(i,o,a,s){return function(){var n=this,r=arguments,e=function(){var e,t;if(!(i<u)){if((e=a.apply(n,r))===o.promise())throw new TypeError("Thenable self-resolution");t=e&&("object"==typeof e||"function"==typeof e)&&e.then,v(t)?s?t.call(e,l(u,o,N,s),l(u,o,q,s)):(u++,t.call(e,l(u,o,N,s),l(u,o,q,s),l(u,o,N,o.notifyWith))):(a!==N&&(n=void 0,r=[e]),(s||o.resolveWith)(n,r))}},t=s?e:function(){try{e()}catch(e){ce.Deferred.exceptionHook&&ce.Deferred.exceptionHook(e,t.error),u<=i+1&&(a!==q&&(n=void 0,r=[e]),o.rejectWith(n,r))}};i?t():(ce.Deferred.getErrorHook?t.error=ce.Deferred.getErrorHook():ce.Deferred.getStackHook&&(t.error=ce.Deferred.getStackHook()),ie.setTimeout(t))}}return ce.Deferred(function(e){o[0][3].add(l(0,e,v(r)?r:N,e.notifyWith)),o[1][3].add(l(0,e,v(t)?t:N)),o[2][3].add(l(0,e,v(n)?n:q))}).promise()},promise:function(e){return null!=e?ce.extend(e,a):a}},s={};return ce.each(o,function(e,t){var n=t[2],r=t[5];a[t[1]]=n.add,r&&n.add(function(){i=r},o[3-e][2].disable,o[3-e][3].disable,o[0][2].lock,o[0][3].lock),n.add(t[3].fire),s[t[0]]=function(){return s[t[0]+"With"](this===s?void 0:this,arguments),this},s[t[0]+"With"]=n.fireWith}),a.promise(s),e&&e.call(s,s),s},when:function(e){var n=arguments.length,t=n,r=Array(t),i=ae.call(arguments),o=ce.Deferred(),a=function(t){return function(e){r[t]=this,i[t]=1<arguments.length?ae.call(arguments):e,--n||o.resolveWith(r,i)}};if(n<=1&&(L(e,o.done(a(t)).resolve,o.reject,!n),"pending"===o.state()||v(i[t]&&i[t].then)))return o.then();while(t--)L(i[t],a(t),o.reject);return o.promise()}});var H=/^(Eval|Internal|Range|Reference|Syntax|Type|URI)Error$/;ce.Deferred.exceptionHook=function(e,t){ie.console&&ie.console.warn&&e&&H.test(e.name)&&ie.console.warn("jQuery.Deferred exception: "+e.message,e.stack,t)},ce.readyException=function(e){ie.setTimeout(function(){throw e})};var O=ce.Deferred();function P(){C.removeEventListener("DOMContentLoaded",P),ie.removeEventListener("load",P),ce.ready()}ce.fn.ready=function(e){return O.then(e)["catch"](function(e){ce.readyException(e)}),this},ce.extend({isReady:!1,readyWait:1,ready:function(e){(!0===e?--ce.readyWait:ce.isReady)||(ce.isReady=!0)!==e&&0<--ce.readyWait||O.resolveWith(C,[ce])}}),ce.ready.then=O.then,"complete"===C.readyState||"loading"!==C.readyState&&!C.documentElement.doScroll?ie.setTimeout(ce.ready):(C.addEventListener("DOMContentLoaded",P),ie.addEventListener("load",P));var M=function(e,t,n,r,i,o,a){var s=0,u=e.length,l=null==n;if("object"===x(n))for(s in i=!0,n)M(e,t,s,n[s],!0,o,a);else if(void 0!==r&&(i=!0,v(r)||(a=!0),l&&(a?(t.call(e,r),t=null):(l=t,t=function(e,t,n){return l.call(ce(e),n)})),t))for(;s<u;s++)t(e[s],n,a?r:r.call(e[s],s,t(e[s],n)));return i?e:l?t.call(e):u?t(e[0],n):o},R=/^-ms-/,I=/-([a-z])/g;function W(e,t){return t.toUpperCase()}function F(e){return e.replace(R,"ms-").replace(I,W)}var $=function(e){return 1===e.nodeType||9===e.nodeType||!+e.nodeType};function B(){this.expando=ce.expando+B.uid++}B.uid=1,B.prototype={cache:function(e){var t=e[this.expando];return t||(t={},$(e)&&(e.nodeType?e[this.expando]=t:Object.defineProperty(e,this.expando,{value:t,configurable:!0}))),t},set:function(e,t,n){var r,i=this.cache(e);if("string"==typeof t)i[F(t)]=n;else for(r in t)i[F(r)]=t[r];return i},get:function(e,t){return void 0===t?this.cache(e):e[this.expando]&&e[this.expando][F(t)]},access:function(e,t,n){return void 0===t||t&&"string"==typeof t&&void 0===n?this.get(e,t):(this.set(e,t,n),void 0!==n?n:t)},remove:function(e,t){var n,r=e[this.expando];if(void 0!==r){if(void 0!==t){n=(t=Array.isArray(t)?t.map(F):(t=F(t))in r?[t]:t.match(D)||[]).length;while(n--)delete r[t[n]]}(void 0===t||ce.isEmptyObject(r))&&(e.nodeType?e[this.expando]=void 0:delete e[this.expando])}},hasData:function(e){var t=e[this.expando];return void 0!==t&&!ce.isEmptyObject(t)}};var _=new B,z=new B,X=/^(?:\{[\w\W]*\}|\[[\w\W]*\])$/,U=/[A-Z]/g;function V(e,t,n){var r,i;if(void 0===n&&1===e.nodeType)if(r="data-"+t.replace(U,"-$&").toLowerCase(),"string"==typeof(n=e.getAttribute(r))){try{n="true"===(i=n)||"false"!==i&&("null"===i?null:i===+i+""?+i:X.test(i)?JSON.parse(i):i)}catch(e){}z.set(e,t,n)}else n=void 0;return n}ce.extend({hasData:function(e){return z.hasData(e)||_.hasData(e)},data:function(e,t,n){return z.access(e,t,n)},removeData:function(e,t){z.remove(e,t)},_data:function(e,t,n){return _.access(e,t,n)},_removeData:function(e,t){_.remove(e,t)}}),ce.fn.extend({data:function(n,e){var t,r,i,o=this[0],a=o&&o.attributes;if(void 0===n){if(this.length&&(i=z.get(o),1===o.nodeType&&!_.get(o,"hasDataAttrs"))){t=a.length;while(t--)a[t]&&0===(r=a[t].name).indexOf("data-")&&(r=F(r.slice(5)),V(o,r,i[r]));_.set(o,"hasDataAttrs",!0)}return i}return"object"==typeof n?this.each(function(){z.set(this,n)}):M(this,function(e){var t;if(o&&void 0===e)return void 0!==(t=z.get(o,n))?t:void 0!==(t=V(o,n))?t:void 0;this.each(function(){z.set(this,n,e)})},null,e,1<arguments.length,null,!0)},removeData:function(e){return this.each(function(){z.remove(this,e)})}}),ce.extend({queue:function(e,t,n){var r;if(e)return t=(t||"fx")+"queue",r=_.get(e,t),n&&(!r||Array.isArray(n)?r=_.access(e,t,ce.makeArray(n)):r.push(n)),r||[]},dequeue:function(e,t){t=t||"fx";var n=ce.queue(e,t),r=n.length,i=n.shift(),o=ce._queueHooks(e,t);"inprogress"===i&&(i=n.shift(),r--),i&&("fx"===t&&n.unshift("inprogress"),delete o.stop,i.call(e,function(){ce.dequeue(e,t)},o)),!r&&o&&o.empty.fire()},_queueHooks:function(e,t){var n=t+"queueHooks";return _.get(e,n)||_.access(e,n,{empty:ce.Callbacks("once memory").add(function(){_.remove(e,[t+"queue",n])})})}}),ce.fn.extend({queue:function(t,n){var e=2;return"string"!=typeof t&&(n=t,t="fx",e--),arguments.length<e?ce.queue(this[0],t):void 0===n?this:this.each(function(){var e=ce.queue(this,t,n);ce._queueHooks(this,t),"fx"===t&&"inprogress"!==e[0]&&ce.dequeue(this,t)})},dequeue:function(e){return this.each(function(){ce.dequeue(this,e)})},clearQueue:function(e){return this.queue(e||"fx",[])},promise:function(e,t){var n,r=1,i=ce.Deferred(),o=this,a=this.length,s=function(){--r||i.resolveWith(o,[o])};"string"!=typeof e&&(t=e,e=void 0),e=e||"fx";while(a--)(n=_.get(o[a],e+"queueHooks"))&&n.empty&&(r++,n.empty.add(s));return s(),i.promise(t)}});var G=/[+-]?(?:\d*\.|)\d+(?:[eE][+-]?\d+|)/.source,Y=new RegExp("^(?:([+-])=|)("+G+")([a-z%]*)$","i"),Q=["Top","Right","Bottom","Left"],J=C.documentElement,K=function(e){return ce.contains(e.ownerDocument,e)},Z={composed:!0};J.getRootNode&&(K=function(e){return ce.contains(e.ownerDocument,e)||e.getRootNode(Z)===e.ownerDocument});var ee=function(e,t){return"none"===(e=t||e).style.display||""===e.style.display&&K(e)&&"none"===ce.css(e,"display")};function te(e,t,n,r){var i,o,a=20,s=r?function(){return r.cur()}:function(){return ce.css(e,t,"")},u=s(),l=n&&n[3]||(ce.cssNumber[t]?"":"px"),c=e.nodeType&&(ce.cssNumber[t]||"px"!==l&&+u)&&Y.exec(ce.css(e,t));if(c&&c[3]!==l){u/=2,l=l||c[3],c=+u||1;while(a--)ce.style(e,t,c+l),(1-o)*(1-(o=s()/u||.5))<=0&&(a=0),c/=o;c*=2,ce.style(e,t,c+l),n=n||[]}return n&&(c=+c||+u||0,i=n[1]?c+(n[1]+1)*n[2]:+n[2],r&&(r.unit=l,r.start=c,r.end=i)),i}var ne={};function re(e,t){for(var n,r,i,o,a,s,u,l=[],c=0,f=e.length;c<f;c++)(r=e[c]).style&&(n=r.style.display,t?("none"===n&&(l[c]=_.get(r,"display")||null,l[c]||(r.style.display="")),""===r.style.display&&ee(r)&&(l[c]=(u=a=o=void 0,a=(i=r).ownerDocument,s=i.nodeName,(u=ne[s])||(o=a.body.appendChild(a.createElement(s)),u=ce.css(o,"display"),o.parentNode.removeChild(o),"none"===u&&(u="block"),ne[s]=u)))):"none"!==n&&(l[c]="none",_.set(r,"display",n)));for(c=0;c<f;c++)null!=l[c]&&(e[c].style.display=l[c]);return e}ce.fn.extend({show:function(){return re(this,!0)},hide:function(){return re(this)},toggle:function(e){return"boolean"==typeof e?e?this.show():this.hide():this.each(function(){ee(this)?ce(this).show():ce(this).hide()})}});var xe,be,we=/^(?:checkbox|radio)$/i,Te=/<([a-z][^\/\0>\x20\t\r\n\f]*)/i,Ce=/^$|^module$|\/(?:java|ecma)script/i;xe=C.createDocumentFragment().appendChild(C.createElement("div")),(be=C.createElement("input")).setAttribute("type","radio"),be.setAttribute("checked","checked"),be.setAttribute("name","t"),xe.appendChild(be),le.checkClone=xe.cloneNode(!0).cloneNode(!0).lastChild.checked,xe.innerHTML="<textarea>x</textarea>",le.noCloneChecked=!!xe.cloneNode(!0).lastChild.defaultValue,xe.innerHTML="<option></option>",le.option=!!xe.lastChild;var ke={thead:[1,"<table>","</table>"],col:[2,"<table><colgroup>","</colgroup></table>"],tr:[2,"<table><tbody>","</tbody></table>"],td:[3,"<table><tbody><tr>","</tr></tbody></table>"],_default:[0,"",""]};function Se(e,t){var n;return n="undefined"!=typeof e.getElementsByTagName?e.getElementsByTagName(t||"*"):"undefined"!=typeof e.querySelectorAll?e.querySelectorAll(t||"*"):[],void 0===t||t&&fe(e,t)?ce.merge([e],n):n}function Ee(e,t){for(var n=0,r=e.length;n<r;n++)_.set(e[n],"globalEval",!t||_.get(t[n],"globalEval"))}ke.tbody=ke.tfoot=ke.colgroup=ke.caption=ke.thead,ke.th=ke.td,le.option||(ke.optgroup=ke.option=[1,"<select multiple='multiple'>","</select>"]);var je=/<|&#?\w+;/;function Ae(e,t,n,r,i){for(var o,a,s,u,l,c,f=t.createDocumentFragment(),p=[],d=0,h=e.length;d<h;d++)if((o=e[d])||0===o)if("object"===x(o))ce.merge(p,o.nodeType?[o]:o);else if(je.test(o)){a=a||f.appendChild(t.createElement("div")),s=(Te.exec(o)||["",""])[1].toLowerCase(),u=ke[s]||ke._default,a.innerHTML=u[1]+ce.htmlPrefilter(o)+u[2],c=u[0];while(c--)a=a.lastChild;ce.merge(p,a.childNodes),(a=f.firstChild).textContent=""}else p.push(t.createTextNode(o));f.textContent="",d=0;while(o=p[d++])if(r&&-1<ce.inArray(o,r))i&&i.push(o);else if(l=K(o),a=Se(f.appendChild(o),"script"),l&&Ee(a),n){c=0;while(o=a[c++])Ce.test(o.type||"")&&n.push(o)}return f}var De=/^([^.]*)(?:\.(.+)|)/;function Ne(){return!0}function qe(){return!1}function Le(e,t,n,r,i,o){var a,s;if("object"==typeof t){for(s in"string"!=typeof n&&(r=r||n,n=void 0),t)Le(e,s,n,r,t[s],o);return e}if(null==r&&null==i?(i=n,r=n=void 0):null==i&&("string"==typeof n?(i=r,r=void 0):(i=r,r=n,n=void 0)),!1===i)i=qe;else if(!i)return e;return 1===o&&(a=i,(i=function(e){return ce().off(e),a.apply(this,arguments)}).guid=a.guid||(a.guid=ce.guid++)),e.each(function(){ce.event.add(this,t,i,r,n)})}function He(e,r,t){t?(_.set(e,r,!1),ce.event.add(e,r,{namespace:!1,handler:function(e){var t,n=_.get(this,r);if(1&e.isTrigger&&this[r]){if(n)(ce.event.special[r]||{}).delegateType&&e.stopPropagation();else if(n=ae.call(arguments),_.set(this,r,n),this[r](),t=_.get(this,r),_.set(this,r,!1),n!==t)return e.stopImmediatePropagation(),e.preventDefault(),t}else n&&(_.set(this,r,ce.event.trigger(n[0],n.slice(1),this)),e.stopPropagation(),e.isImmediatePropagationStopped=Ne)}})):void 0===_.get(e,r)&&ce.event.add(e,r,Ne)}ce.event={global:{},add:function(t,e,n,r,i){var o,a,s,u,l,c,f,p,d,h,g,v=_.get(t);if($(t)){n.handler&&(n=(o=n).handler,i=o.selector),i&&ce.find.matchesSelector(J,i),n.guid||(n.guid=ce.guid++),(u=v.events)||(u=v.events=Object.create(null)),(a=v.handle)||(a=v.handle=function(e){return"undefined"!=typeof ce&&ce.event.triggered!==e.type?ce.event.dispatch.apply(t,arguments):void 0}),l=(e=(e||"").match(D)||[""]).length;while(l--)d=g=(s=De.exec(e[l])||[])[1],h=(s[2]||"").split(".").sort(),d&&(f=ce.event.special[d]||{},d=(i?f.delegateType:f.bindType)||d,f=ce.event.special[d]||{},c=ce.extend({type:d,origType:g,data:r,handler:n,guid:n.guid,selector:i,needsContext:i&&ce.expr.match.needsContext.test(i),namespace:h.join(".")},o),(p=u[d])||((p=u[d]=[]).delegateCount=0,f.setup&&!1!==f.setup.call(t,r,h,a)||t.addEventListener&&t.addEventListener(d,a)),f.add&&(f.add.call(t,c),c.handler.guid||(c.handler.guid=n.guid)),i?p.splice(p.delegateCount++,0,c):p.push(c),ce.event.global[d]=!0)}},remove:function(e,t,n,r,i){var o,a,s,u,l,c,f,p,d,h,g,v=_.hasData(e)&&_.get(e);if(v&&(u=v.events)){l=(t=(t||"").match(D)||[""]).length;while(l--)if(d=g=(s=De.exec(t[l])||[])[1],h=(s[2]||"").split(".").sort(),d){f=ce.event.special[d]||{},p=u[d=(r?f.delegateType:f.bindType)||d]||[],s=s[2]&&new RegExp("(^|\\.)"+h.join("\\.(?:.*\\.|)")+"(\\.|$)"),a=o=p.length;while(o--)c=p[o],!i&&g!==c.origType||n&&n.guid!==c.guid||s&&!s.test(c.namespace)||r&&r!==c.selector&&("**"!==r||!c.selector)||(p.splice(o,1),c.selector&&p.delegateCount--,f.remove&&f.remove.call(e,c));a&&!p.length&&(f.teardown&&!1!==f.teardown.call(e,h,v.handle)||ce.removeEvent(e,d,v.handle),delete u[d])}else for(d in u)ce.event.remove(e,d+t[l],n,r,!0);ce.isEmptyObject(u)&&_.remove(e,"handle events")}},dispatch:function(e){var t,n,r,i,o,a,s=new Array(arguments.length),u=ce.event.fix(e),l=(_.get(this,"events")||Object.create(null))[u.type]||[],c=ce.event.special[u.type]||{};for(s[0]=u,t=1;t<arguments.length;t++)s[t]=arguments[t];if(u.delegateTarget=this,!c.preDispatch||!1!==c.preDispatch.call(this,u)){a=ce.event.handlers.call(this,u,l),t=0;while((i=a[t++])&&!u.isPropagationStopped()){u.currentTarget=i.elem,n=0;while((o=i.handlers[n++])&&!u.isImmediatePropagationStopped())u.rnamespace&&!1!==o.namespace&&!u.rnamespace.test(o.namespace)||(u.handleObj=o,u.data=o.data,void 0!==(r=((ce.event.special[o.origType]||{}).handle||o.handler).apply(i.elem,s))&&!1===(u.result=r)&&(u.preventDefault(),u.stopPropagation()))}return c.postDispatch&&c.postDispatch.call(this,u),u.result}},handlers:function(e,t){var n,r,i,o,a,s=[],u=t.delegateCount,l=e.target;if(u&&l.nodeType&&!("click"===e.type&&1<=e.button))for(;l!==this;l=l.parentNode||this)if(1===l.nodeType&&("click"!==e.type||!0!==l.disabled)){for(o=[],a={},n=0;n<u;n++)void 0===a[i=(r=t[n]).selector+" "]&&(a[i]=r.needsContext?-1<ce(i,this).index(l):ce.find(i,this,null,[l]).length),a[i]&&o.push(r);o.length&&s.push({elem:l,handlers:o})}return l=this,u<t.length&&s.push({elem:l,handlers:t.slice(u)}),s},addProp:function(t,e){Object.defineProperty(ce.Event.prototype,t,{enumerable:!0,configurable:!0,get:v(e)?function(){if(this.originalEvent)return e(this.originalEvent)}:function(){if(this.originalEvent)return this.originalEvent[t]},set:function(e){Object.defineProperty(this,t,{enumerable:!0,configurable:!0,writable:!0,value:e})}})},fix:function(e){return e[ce.expando]?e:new ce.Event(e)},special:{load:{noBubble:!0},click:{setup:function(e){var t=this||e;return we.test(t.type)&&t.click&&fe(t,"input")&&He(t,"click",!0),!1},trigger:function(e){var t=this||e;return we.test(t.type)&&t.click&&fe(t,"input")&&He(t,"click"),!0},_default:function(e){var t=e.target;return we.test(t.type)&&t.click&&fe(t,"input")&&_.get(t,"click")||fe(t,"a")}},beforeunload:{postDispatch:function(e){void 0!==e.result&&e.originalEvent&&(e.originalEvent.returnValue=e.result)}}}},ce.removeEvent=function(e,t,n){e.removeEventListener&&e.removeEventListener(t,n)},ce.Event=function(e,t){if(!(this instanceof ce.Event))return new ce.Event(e,t);e&&e.type?(this.originalEvent=e,this.type=e.type,this.isDefaultPrevented=e.defaultPrevented||void 0===e.defaultPrevented&&!1===e.returnValue?Ne:qe,this.target=e.target&&3===e.target.nodeType?e.target.parentNode:e.target,this.currentTarget=e.currentTarget,this.relatedTarget=e.relatedTarget):this.type=e,t&&ce.extend(this,t),this.timeStamp=e&&e.timeStamp||Date.now(),this[ce.expando]=!0},ce.Event.prototype={constructor:ce.Event,isDefaultPrevented:qe,isPropagationStopped:qe,isImmediatePropagationStopped:qe,isSimulated:!1,preventDefault:function(){var e=this.originalEvent;this.isDefaultPrevented=Ne,e&&!this.isSimulated&&e.preventDefault()},stopPropagation:function(){var e=this.originalEvent;this.isPropagationStopped=Ne,e&&!this.isSimulated&&e.stopPropagation()},stopImmediatePropagation:function(){var e=this.originalEvent;this.isImmediatePropagationStopped=Ne,e&&!this.isSimulated&&e.stopImmediatePropagation(),this.stopPropagation()}},ce.each({altKey:!0,bubbles:!0,cancelable:!0,changedTouches:!0,ctrlKey:!0,detail:!0,eventPhase:!0,metaKey:!0,pageX:!0,pageY:!0,shiftKey:!0,view:!0,"char":!0,code:!0,charCode:!0,key:!0,keyCode:!0,button:!0,buttons:!0,clientX:!0,clientY:!0,offsetX:!0,offsetY:!0,pointerId:!0,pointerType:!0,screenX:!0,screenY:!0,targetTouches:!0,toElement:!0,touches:!0,which:!0},ce.event.addProp),ce.each({focus:"focusin",blur:"focusout"},function(r,i){function o(e){if(C.documentMode){var t=_.get(this,"handle"),n=ce.event.fix(e);n.type="focusin"===e.type?"focus":"blur",n.isSimulated=!0,t(e),n.target===n.currentTarget&&t(n)}else ce.event.simulate(i,e.target,ce.event.fix(e))}ce.event.special[r]={setup:function(){var e;if(He(this,r,!0),!C.documentMode)return!1;(e=_.get(this,i))||this.addEventListener(i,o),_.set(this,i,(e||0)+1)},trigger:function(){return He(this,r),!0},teardown:function(){var e;if(!C.documentMode)return!1;(e=_.get(this,i)-1)?_.set(this,i,e):(this.removeEventListener(i,o),_.remove(this,i))},_default:function(e){return _.get(e.target,r)},delegateType:i},ce.event.special[i]={setup:function(){var e=this.ownerDocument||this.document||this,t=C.documentMode?this:e,n=_.get(t,i);n||(C.documentMode?this.addEventListener(i,o):e.addEventListener(r,o,!0)),_.set(t,i,(n||0)+1)},teardown:function(){var e=this.ownerDocument||this.document||this,t=C.documentMode?this:e,n=_.get(t,i)-1;n?_.set(t,i,n):(C.documentMode?this.removeEventListener(i,o):e.removeEventListener(r,o,!0),_.remove(t,i))}}}),ce.each({mouseenter:"mouseover",mouseleave:"mouseout",pointerenter:"pointerover",pointerleave:"pointerout"},function(e,i){ce.event.special[e]={delegateType:i,bindType:i,handle:function(e){var t,n=e.relatedTarget,r=e.handleObj;return n&&(n===this||ce.contains(this,n))||(e.type=r.origType,t=r.handler.apply(this,arguments),e.type=i),t}}}),ce.fn.extend({on:function(e,t,n,r){return Le(this,e,t,n,r)},one:function(e,t,n,r){return Le(this,e,t,n,r,1)},off:function(e,t,n){var r,i;if(e&&e.preventDefault&&e.handleObj)return r=e.handleObj,ce(e.delegateTarget).off(r.namespace?r.origType+"."+r.namespace:r.origType,r.selector,r.handler),this;if("object"==typeof e){for(i in e)this.off(i,t,e[i]);return this}return!1!==t&&"function"!=typeof t||(n=t,t=void 0),!1===n&&(n=qe),this.each(function(){ce.event.remove(this,e,n,t)})}});var Oe=/<script|<style|<link/i,Pe=/checked\s*(?:[^=]|=\s*.checked.)/i,Me=/^\s*<!\[CDATA\[|\]\]>\s*$/g;function Re(e,t){return fe(e,"table")&&fe(11!==t.nodeType?t:t.firstChild,"tr")&&ce(e).children("tbody")[0]||e}function Ie(e){return e.type=(null!==e.getAttribute("type"))+"/"+e.type,e}function We(e){return"true/"===(e.type||"").slice(0,5)?e.type=e.type.slice(5):e.removeAttribute("type"),e}function Fe(e,t){var n,r,i,o,a,s;if(1===t.nodeType){if(_.hasData(e)&&(s=_.get(e).events))for(i in _.remove(t,"handle events"),s)for(n=0,r=s[i].length;n<r;n++)ce.event.add(t,i,s[i][n]);z.hasData(e)&&(o=z.access(e),a=ce.extend({},o),z.set(t,a))}}function $e(n,r,i,o){r=g(r);var e,t,a,s,u,l,c=0,f=n.length,p=f-1,d=r[0],h=v(d);if(h||1<f&&"string"==typeof d&&!le.checkClone&&Pe.test(d))return n.each(function(e){var t=n.eq(e);h&&(r[0]=d.call(this,e,t.html())),$e(t,r,i,o)});if(f&&(t=(e=Ae(r,n[0].ownerDocument,!1,n,o)).firstChild,1===e.childNodes.length&&(e=t),t||o)){for(s=(a=ce.map(Se(e,"script"),Ie)).length;c<f;c++)u=e,c!==p&&(u=ce.clone(u,!0,!0),s&&ce.merge(a,Se(u,"script"))),i.call(n[c],u,c);if(s)for(l=a[a.length-1].ownerDocument,ce.map(a,We),c=0;c<s;c++)u=a[c],Ce.test(u.type||"")&&!_.access(u,"globalEval")&&ce.contains(l,u)&&(u.src&&"module"!==(u.type||"").toLowerCase()?ce._evalUrl&&!u.noModule&&ce._evalUrl(u.src,{nonce:u.nonce||u.getAttribute("nonce")},l):m(u.textContent.replace(Me,""),u,l))}return n}function Be(e,t,n){for(var r,i=t?ce.filter(t,e):e,o=0;null!=(r=i[o]);o++)n||1!==r.nodeType||ce.cleanData(Se(r)),r.parentNode&&(n&&K(r)&&Ee(Se(r,"script")),r.parentNode.removeChild(r));return e}ce.extend({htmlPrefilter:function(e){return e},clone:function(e,t,n){var r,i,o,a,s,u,l,c=e.cloneNode(!0),f=K(e);if(!(le.noCloneChecked||1!==e.nodeType&&11!==e.nodeType||ce.isXMLDoc(e)))for(a=Se(c),r=0,i=(o=Se(e)).length;r<i;r++)s=o[r],u=a[r],void 0,"input"===(l=u.nodeName.toLowerCase())&&we.test(s.type)?u.checked=s.checked:"input"!==l&&"textarea"!==l||(u.defaultValue=s.defaultValue);if(t)if(n)for(o=o||Se(e),a=a||Se(c),r=0,i=o.length;r<i;r++)Fe(o[r],a[r]);else Fe(e,c);return 0<(a=Se(c,"script")).length&&Ee(a,!f&&Se(e,"script")),c},cleanData:function(e){for(var t,n,r,i=ce.event.special,o=0;void 0!==(n=e[o]);o++)if($(n)){if(t=n[_.expando]){if(t.events)for(r in t.events)i[r]?ce.event.remove(n,r):ce.removeEvent(n,r,t.handle);n[_.expando]=void 0}n[z.expando]&&(n[z.expando]=void 0)}}}),ce.fn.extend({detach:function(e){return Be(this,e,!0)},remove:function(e){return Be(this,e)},text:function(e){return M(this,function(e){return void 0===e?ce.text(this):this.empty().each(function(){1!==this.nodeType&&11!==this.nodeType&&9!==this.nodeType||(this.textContent=e)})},null,e,arguments.length)},append:function(){return $e(this,arguments,function(e){1!==this.nodeType&&11!==this.nodeType&&9!==this.nodeType||Re(this,e).appendChild(e)})},prepend:function(){return $e(this,arguments,function(e){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){var t=Re(this,e);t.insertBefore(e,t.firstChild)}})},before:function(){return $e(this,arguments,function(e){this.parentNode&&this.parentNode.insertBefore(e,this)})},after:function(){return $e(this,arguments,function(e){this.parentNode&&this.parentNode.insertBefore(e,this.nextSibling)})},empty:function(){for(var e,t=0;null!=(e=this[t]);t++)1===e.nodeType&&(ce.cleanData(Se(e,!1)),e.textContent="");return this},clone:function(e,t){return e=null!=e&&e,t=null==t?e:t,this.map(function(){return ce.clone(this,e,t)})},html:function(e){return M(this,function(e){var t=this[0]||{},n=0,r=this.length;if(void 0===e&&1===t.nodeType)return t.innerHTML;if("string"==typeof e&&!Oe.test(e)&&!ke[(Te.exec(e)||["",""])[1].toLowerCase()]){e=ce.htmlPrefilter(e);try{for(;n<r;n++)1===(t=this[n]||{}).nodeType&&(ce.cleanData(Se(t,!1)),t.innerHTML=e);t=0}catch(e){}}t&&this.empty().append(e)},null,e,arguments.length)},replaceWith:function(){var n=[];return $e(this,arguments,function(e){var t=this.parentNode;ce.inArray(this,n)<0&&(ce.cleanData(Se(this)),t&&t.replaceChild(e,this))},n)}}),ce.each({appendTo:"append",prependTo:"prepend",insertBefore:"before",insertAfter:"after",replaceAll:"replaceWith"},function(e,a){ce.fn[e]=function(e){for(var t,n=[],r=ce(e),i=r.length-1,o=0;o<=i;o++)t=o===i?this:this.clone(!0),ce(r[o])[a](t),s.apply(n,t.get());return this.pushStack(n)}});var _e=new RegExp("^("+G+")(?!px)[a-z%]+$","i"),ze=/^--/,Xe=function(e){var t=e.ownerDocument.defaultView;return t&&t.opener||(t=ie),t.getComputedStyle(e)},Ue=function(e,t,n){var r,i,o={};for(i in t)o[i]=e.style[i],e.style[i]=t[i];for(i in r=n.call(e),t)e.style[i]=o[i];return r},Ve=new RegExp(Q.join("|"),"i");function Ge(e,t,n){var r,i,o,a,s=ze.test(t),u=e.style;return(n=n||Xe(e))&&(a=n.getPropertyValue(t)||n[t],s&&a&&(a=a.replace(ve,"$1")||void 0),""!==a||K(e)||(a=ce.style(e,t)),!le.pixelBoxStyles()&&_e.test(a)&&Ve.test(t)&&(r=u.width,i=u.minWidth,o=u.maxWidth,u.minWidth=u.maxWidth=u.width=a,a=n.width,u.width=r,u.minWidth=i,u.maxWidth=o)),void 0!==a?a+"":a}function Ye(e,t){return{get:function(){if(!e())return(this.get=t).apply(this,arguments);delete this.get}}}!function(){function e(){if(l){u.style.cssText="position:absolute;left:-11111px;width:60px;margin-top:1px;padding:0;border:0",l.style.cssText="position:relative;display:block;box-sizing:border-box;overflow:scroll;margin:auto;border:1px;padding:1px;width:60%;top:1%",J.appendChild(u).appendChild(l);var e=ie.getComputedStyle(l);n="1%"!==e.top,s=12===t(e.marginLeft),l.style.right="60%",o=36===t(e.right),r=36===t(e.width),l.style.position="absolute",i=12===t(l.offsetWidth/3),J.removeChild(u),l=null}}function t(e){return Math.round(parseFloat(e))}var n,r,i,o,a,s,u=C.createElement("div"),l=C.createElement("div");l.style&&(l.style.backgroundClip="content-box",l.cloneNode(!0).style.backgroundClip="",le.clearCloneStyle="content-box"===l.style.backgroundClip,ce.extend(le,{boxSizingReliable:function(){return e(),r},pixelBoxStyles:function(){return e(),o},pixelPosition:function(){return e(),n},reliableMarginLeft:function(){return e(),s},scrollboxSize:function(){return e(),i},reliableTrDimensions:function(){var e,t,n,r;return null==a&&(e=C.createElement("table"),t=C.createElement("tr"),n=C.createElement("div"),e.style.cssText="position:absolute;left:-11111px;border-collapse:separate",t.style.cssText="box-sizing:content-box;border:1px solid",t.style.height="1px",n.style.height="9px",n.style.display="block",J.appendChild(e).appendChild(t).appendChild(n),r=ie.getComputedStyle(t),a=parseInt(r.height,10)+parseInt(r.borderTopWidth,10)+parseInt(r.borderBottomWidth,10)===t.offsetHeight,J.removeChild(e)),a}}))}();var Qe=["Webkit","Moz","ms"],Je=C.createElement("div").style,Ke={};function Ze(e){var t=ce.cssProps[e]||Ke[e];return t||(e in Je?e:Ke[e]=function(e){var t=e[0].toUpperCase()+e.slice(1),n=Qe.length;while(n--)if((e=Qe[n]+t)in Je)return e}(e)||e)}var et=/^(none|table(?!-c[ea]).+)/,tt={position:"absolute",visibility:"hidden",display:"block"},nt={letterSpacing:"0",fontWeight:"400"};function rt(e,t,n){var r=Y.exec(t);return r?Math.max(0,r[2]-(n||0))+(r[3]||"px"):t}function it(e,t,n,r,i,o){var a="width"===t?1:0,s=0,u=0,l=0;if(n===(r?"border":"content"))return 0;for(;a<4;a+=2)"margin"===n&&(l+=ce.css(e,n+Q[a],!0,i)),r?("content"===n&&(u-=ce.css(e,"padding"+Q[a],!0,i)),"margin"!==n&&(u-=ce.css(e,"border"+Q[a]+"Width",!0,i))):(u+=ce.css(e,"padding"+Q[a],!0,i),"padding"!==n?u+=ce.css(e,"border"+Q[a]+"Width",!0,i):s+=ce.css(e,"border"+Q[a]+"Width",!0,i));return!r&&0<=o&&(u+=Math.max(0,Math.ceil(e["offset"+t[0].toUpperCase()+t.slice(1)]-o-u-s-.5))||0),u+l}function ot(e,t,n){var r=Xe(e),i=(!le.boxSizingReliable()||n)&&"border-box"===ce.css(e,"boxSizing",!1,r),o=i,a=Ge(e,t,r),s="offset"+t[0].toUpperCase()+t.slice(1);if(_e.test(a)){if(!n)return a;a="auto"}return(!le.boxSizingReliable()&&i||!le.reliableTrDimensions()&&fe(e,"tr")||"auto"===a||!parseFloat(a)&&"inline"===ce.css(e,"display",!1,r))&&e.getClientRects().length&&(i="border-box"===ce.css(e,"boxSizing",!1,r),(o=s in e)&&(a=e[s])),(a=parseFloat(a)||0)+it(e,t,n||(i?"border":"content"),o,r,a)+"px"}function at(e,t,n,r,i){return new at.prototype.init(e,t,n,r,i)}ce.extend({cssHooks:{opacity:{get:function(e,t){if(t){var n=Ge(e,"opacity");return""===n?"1":n}}}},cssNumber:{animationIterationCount:!0,aspectRatio:!0,borderImageSlice:!0,columnCount:!0,flexGrow:!0,flexShrink:!0,fontWeight:!0,gridArea:!0,gridColumn:!0,gridColumnEnd:!0,gridColumnStart:!0,gridRow:!0,gridRowEnd:!0,gridRowStart:!0,lineHeight:!0,opacity:!0,order:!0,orphans:!0,scale:!0,widows:!0,zIndex:!0,zoom:!0,fillOpacity:!0,floodOpacity:!0,stopOpacity:!0,strokeMiterlimit:!0,strokeOpacity:!0},cssProps:{},style:function(e,t,n,r){if(e&&3!==e.nodeType&&8!==e.nodeType&&e.style){var i,o,a,s=F(t),u=ze.test(t),l=e.style;if(u||(t=Ze(s)),a=ce.cssHooks[t]||ce.cssHooks[s],void 0===n)return a&&"get"in a&&void 0!==(i=a.get(e,!1,r))?i:l[t];"string"===(o=typeof n)&&(i=Y.exec(n))&&i[1]&&(n=te(e,t,i),o="number"),null!=n&&n==n&&("number"!==o||u||(n+=i&&i[3]||(ce.cssNumber[s]?"":"px")),le.clearCloneStyle||""!==n||0!==t.indexOf("background")||(l[t]="inherit"),a&&"set"in a&&void 0===(n=a.set(e,n,r))||(u?l.setProperty(t,n):l[t]=n))}},css:function(e,t,n,r){var i,o,a,s=F(t);return ze.test(t)||(t=Ze(s)),(a=ce.cssHooks[t]||ce.cssHooks[s])&&"get"in a&&(i=a.get(e,!0,n)),void 0===i&&(i=Ge(e,t,r)),"normal"===i&&t in nt&&(i=nt[t]),""===n||n?(o=parseFloat(i),!0===n||isFinite(o)?o||0:i):i}}),ce.each(["height","width"],function(e,u){ce.cssHooks[u]={get:function(e,t,n){if(t)return!et.test(ce.css(e,"display"))||e.getClientRects().length&&e.getBoundingClientRect().width?ot(e,u,n):Ue(e,tt,function(){return ot(e,u,n)})},set:function(e,t,n){var r,i=Xe(e),o=!le.scrollboxSize()&&"absolute"===i.position,a=(o||n)&&"border-box"===ce.css(e,"boxSizing",!1,i),s=n?it(e,u,n,a,i):0;return a&&o&&(s-=Math.ceil(e["offset"+u[0].toUpperCase()+u.slice(1)]-parseFloat(i[u])-it(e,u,"border",!1,i)-.5)),s&&(r=Y.exec(t))&&"px"!==(r[3]||"px")&&(e.style[u]=t,t=ce.css(e,u)),rt(0,t,s)}}}),ce.cssHooks.marginLeft=Ye(le.reliableMarginLeft,function(e,t){if(t)return(parseFloat(Ge(e,"marginLeft"))||e.getBoundingClientRect().left-Ue(e,{marginLeft:0},function(){return e.getBoundingClientRect().left}))+"px"}),ce.each({margin:"",padding:"",border:"Width"},function(i,o){ce.cssHooks[i+o]={expand:function(e){for(var t=0,n={},r="string"==typeof e?e.split(" "):[e];t<4;t++)n[i+Q[t]+o]=r[t]||r[t-2]||r[0];return n}},"margin"!==i&&(ce.cssHooks[i+o].set=rt)}),ce.fn.extend({css:function(e,t){return M(this,function(e,t,n){var r,i,o={},a=0;if(Array.isArray(t)){for(r=Xe(e),i=t.length;a<i;a++)o[t[a]]=ce.css(e,t[a],!1,r);return o}return void 0!==n?ce.style(e,t,n):ce.css(e,t)},e,t,1<arguments.length)}}),((ce.Tween=at).prototype={constructor:at,init:function(e,t,n,r,i,o){this.elem=e,this.prop=n,this.easing=i||ce.easing._default,this.options=t,this.start=this.now=this.cur(),this.end=r,this.unit=o||(ce.cssNumber[n]?"":"px")},cur:function(){var e=at.propHooks[this.prop];return e&&e.get?e.get(this):at.propHooks._default.get(this)},run:function(e){var t,n=at.propHooks[this.prop];return this.options.duration?this.pos=t=ce.easing[this.easing](e,this.options.duration*e,0,1,this.options.duration):this.pos=t=e,this.now=(this.end-this.start)*t+this.start,this.options.step&&this.options.step.call(this.elem,this.now,this),n&&n.set?n.set(this):at.propHooks._default.set(this),this}}).init.prototype=at.prototype,(at.propHooks={_default:{get:function(e){var t;return 1!==e.elem.nodeType||null!=e.elem[e.prop]&&null==e.elem.style[e.prop]?e.elem[e.prop]:(t=ce.css(e.elem,e.prop,""))&&"auto"!==t?t:0},set:function(e){ce.fx.step[e.prop]?ce.fx.step[e.prop](e):1!==e.elem.nodeType||!ce.cssHooks[e.prop]&&null==e.elem.style[Ze(e.prop)]?e.elem[e.prop]=e.now:ce.style(e.elem,e.prop,e.now+e.unit)}}}).scrollTop=at.propHooks.scrollLeft={set:function(e){e.elem.nodeType&&e.elem.parentNode&&(e.elem[e.prop]=e.now)}},ce.easing={linear:function(e){return e},swing:function(e){return.5-Math.cos(e*Math.PI)/2},_default:"swing"},ce.fx=at.prototype.init,ce.fx.step={};var st,ut,lt,ct,ft=/^(?:toggle|show|hide)$/,pt=/queueHooks$/;function dt(){ut&&(!1===C.hidden&&ie.requestAnimationFrame?ie.requestAnimationFrame(dt):ie.setTimeout(dt,ce.fx.interval),ce.fx.tick())}function ht(){return ie.setTimeout(function(){st=void 0}),st=Date.now()}function gt(e,t){var n,r=0,i={height:e};for(t=t?1:0;r<4;r+=2-t)i["margin"+(n=Q[r])]=i["padding"+n]=e;return t&&(i.opacity=i.width=e),i}function vt(e,t,n){for(var r,i=(yt.tweeners[t]||[]).concat(yt.tweeners["*"]),o=0,a=i.length;o<a;o++)if(r=i[o].call(n,t,e))return r}function yt(o,e,t){var n,a,r=0,i=yt.prefilters.length,s=ce.Deferred().always(function(){delete u.elem}),u=function(){if(a)return!1;for(var e=st||ht(),t=Math.max(0,l.startTime+l.duration-e),n=1-(t/l.duration||0),r=0,i=l.tweens.length;r<i;r++)l.tweens[r].run(n);return s.notifyWith(o,[l,n,t]),n<1&&i?t:(i||s.notifyWith(o,[l,1,0]),s.resolveWith(o,[l]),!1)},l=s.promise({elem:o,props:ce.extend({},e),opts:ce.extend(!0,{specialEasing:{},easing:ce.easing._default},t),originalProperties:e,originalOptions:t,startTime:st||ht(),duration:t.duration,tweens:[],createTween:function(e,t){var n=ce.Tween(o,l.opts,e,t,l.opts.specialEasing[e]||l.opts.easing);return l.tweens.push(n),n},stop:function(e){var t=0,n=e?l.tweens.length:0;if(a)return this;for(a=!0;t<n;t++)l.tweens[t].run(1);return e?(s.notifyWith(o,[l,1,0]),s.resolveWith(o,[l,e])):s.rejectWith(o,[l,e]),this}}),c=l.props;for(!function(e,t){var n,r,i,o,a;for(n in e)if(i=t[r=F(n)],o=e[n],Array.isArray(o)&&(i=o[1],o=e[n]=o[0]),n!==r&&(e[r]=o,delete e[n]),(a=ce.cssHooks[r])&&"expand"in a)for(n in o=a.expand(o),delete e[r],o)n in e||(e[n]=o[n],t[n]=i);else t[r]=i}(c,l.opts.specialEasing);r<i;r++)if(n=yt.prefilters[r].call(l,o,c,l.opts))return v(n.stop)&&(ce._queueHooks(l.elem,l.opts.queue).stop=n.stop.bind(n)),n;return ce.map(c,vt,l),v(l.opts.start)&&l.opts.start.call(o,l),l.progress(l.opts.progress).done(l.opts.done,l.opts.complete).fail(l.opts.fail).always(l.opts.always),ce.fx.timer(ce.extend(u,{elem:o,anim:l,queue:l.opts.queue})),l}ce.Animation=ce.extend(yt,{tweeners:{"*":[function(e,t){var n=this.createTween(e,t);return te(n.elem,e,Y.exec(t),n),n}]},tweener:function(e,t){v(e)?(t=e,e=["*"]):e=e.match(D);for(var n,r=0,i=e.length;r<i;r++)n=e[r],yt.tweeners[n]=yt.tweeners[n]||[],yt.tweeners[n].unshift(t)},prefilters:[function(e,t,n){var r,i,o,a,s,u,l,c,f="width"in t||"height"in t,p=this,d={},h=e.style,g=e.nodeType&&ee(e),v=_.get(e,"fxshow");for(r in n.queue||(null==(a=ce._queueHooks(e,"fx")).unqueued&&(a.unqueued=0,s=a.empty.fire,a.empty.fire=function(){a.unqueued||s()}),a.unqueued++,p.always(function(){p.always(function(){a.unqueued--,ce.queue(e,"fx").length||a.empty.fire()})})),t)if(i=t[r],ft.test(i)){if(delete t[r],o=o||"toggle"===i,i===(g?"hide":"show")){if("show"!==i||!v||void 0===v[r])continue;g=!0}d[r]=v&&v[r]||ce.style(e,r)}if((u=!ce.isEmptyObject(t))||!ce.isEmptyObject(d))for(r in f&&1===e.nodeType&&(n.overflow=[h.overflow,h.overflowX,h.overflowY],null==(l=v&&v.display)&&(l=_.get(e,"display")),"none"===(c=ce.css(e,"display"))&&(l?c=l:(re([e],!0),l=e.style.display||l,c=ce.css(e,"display"),re([e]))),("inline"===c||"inline-block"===c&&null!=l)&&"none"===ce.css(e,"float")&&(u||(p.done(function(){h.display=l}),null==l&&(c=h.display,l="none"===c?"":c)),h.display="inline-block")),n.overflow&&(h.overflow="hidden",p.always(function(){h.overflow=n.overflow[0],h.overflowX=n.overflow[1],h.overflowY=n.overflow[2]})),u=!1,d)u||(v?"hidden"in v&&(g=v.hidden):v=_.access(e,"fxshow",{display:l}),o&&(v.hidden=!g),g&&re([e],!0),p.done(function(){for(r in g||re([e]),_.remove(e,"fxshow"),d)ce.style(e,r,d[r])})),u=vt(g?v[r]:0,r,p),r in v||(v[r]=u.start,g&&(u.end=u.start,u.start=0))}],prefilter:function(e,t){t?yt.prefilters.unshift(e):yt.prefilters.push(e)}}),ce.speed=function(e,t,n){var r=e&&"object"==typeof e?ce.extend({},e):{complete:n||!n&&t||v(e)&&e,duration:e,easing:n&&t||t&&!v(t)&&t};return ce.fx.off?r.duration=0:"number"!=typeof r.duration&&(r.duration in ce.fx.speeds?r.duration=ce.fx.speeds[r.duration]:r.duration=ce.fx.speeds._default),null!=r.queue&&!0!==r.queue||(r.queue="fx"),r.old=r.complete,r.complete=function(){v(r.old)&&r.old.call(this),r.queue&&ce.dequeue(this,r.queue)},r},ce.fn.extend({fadeTo:function(e,t,n,r){return this.filter(ee).css("opacity",0).show().end().animate({opacity:t},e,n,r)},animate:function(t,e,n,r){var i=ce.isEmptyObject(t),o=ce.speed(e,n,r),a=function(){var e=yt(this,ce.extend({},t),o);(i||_.get(this,"finish"))&&e.stop(!0)};return a.finish=a,i||!1===o.queue?this.each(a):this.queue(o.queue,a)},stop:function(i,e,o){var a=function(e){var t=e.stop;delete e.stop,t(o)};return"string"!=typeof i&&(o=e,e=i,i=void 0),e&&this.queue(i||"fx",[]),this.each(function(){var e=!0,t=null!=i&&i+"queueHooks",n=ce.timers,r=_.get(this);if(t)r[t]&&r[t].stop&&a(r[t]);else for(t in r)r[t]&&r[t].stop&&pt.test(t)&&a(r[t]);for(t=n.length;t--;)n[t].elem!==this||null!=i&&n[t].queue!==i||(n[t].anim.stop(o),e=!1,n.splice(t,1));!e&&o||ce.dequeue(this,i)})},finish:function(a){return!1!==a&&(a=a||"fx"),this.each(function(){var e,t=_.get(this),n=t[a+"queue"],r=t[a+"queueHooks"],i=ce.timers,o=n?n.length:0;for(t.finish=!0,ce.queue(this,a,[]),r&&r.stop&&r.stop.call(this,!0),e=i.length;e--;)i[e].elem===this&&i[e].queue===a&&(i[e].anim.stop(!0),i.splice(e,1));for(e=0;e<o;e++)n[e]&&n[e].finish&&n[e].finish.call(this);delete t.finish})}}),ce.each(["toggle","show","hide"],function(e,r){var i=ce.fn[r];ce.fn[r]=function(e,t,n){return null==e||"boolean"==typeof e?i.apply(this,arguments):this.animate(gt(r,!0),e,t,n)}}),ce.each({slideDown:gt("show"),slideUp:gt("hide"),slideToggle:gt("toggle"),fadeIn:{opacity:"show"},fadeOut:{opacity:"hide"},fadeToggle:{opacity:"toggle"}},function(e,r){ce.fn[e]=function(e,t,n){return this.animate(r,e,t,n)}}),ce.timers=[],ce.fx.tick=function(){var e,t=0,n=ce.timers;for(st=Date.now();t<n.length;t++)(e=n[t])()||n[t]!==e||n.splice(t--,1);n.length||ce.fx.stop(),st=void 0},ce.fx.timer=function(e){ce.timers.push(e),ce.fx.start()},ce.fx.interval=13,ce.fx.start=function(){ut||(ut=!0,dt())},ce.fx.stop=function(){ut=null},ce.fx.speeds={slow:600,fast:200,_default:400},ce.fn.delay=function(r,e){return r=ce.fx&&ce.fx.speeds[r]||r,e=e||"fx",this.queue(e,function(e,t){var n=ie.setTimeout(e,r);t.stop=function(){ie.clearTimeout(n)}})},lt=C.createElement("input"),ct=C.createElement("select").appendChild(C.createElement("option")),lt.type="checkbox",le.checkOn=""!==lt.value,le.optSelected=ct.selected,(lt=C.createElement("input")).value="t",lt.type="radio",le.radioValue="t"===lt.value;var mt,xt=ce.expr.attrHandle;ce.fn.extend({attr:function(e,t){return M(this,ce.attr,e,t,1<arguments.length)},removeAttr:function(e){return this.each(function(){ce.removeAttr(this,e)})}}),ce.extend({attr:function(e,t,n){var r,i,o=e.nodeType;if(3!==o&&8!==o&&2!==o)return"undefined"==typeof e.getAttribute?ce.prop(e,t,n):(1===o&&ce.isXMLDoc(e)||(i=ce.attrHooks[t.toLowerCase()]||(ce.expr.match.bool.test(t)?mt:void 0)),void 0!==n?null===n?void ce.removeAttr(e,t):i&&"set"in i&&void 0!==(r=i.set(e,n,t))?r:(e.setAttribute(t,n+""),n):i&&"get"in i&&null!==(r=i.get(e,t))?r:null==(r=ce.find.attr(e,t))?void 0:r)},attrHooks:{type:{set:function(e,t){if(!le.radioValue&&"radio"===t&&fe(e,"input")){var n=e.value;return e.setAttribute("type",t),n&&(e.value=n),t}}}},removeAttr:function(e,t){var n,r=0,i=t&&t.match(D);if(i&&1===e.nodeType)while(n=i[r++])e.removeAttribute(n)}}),mt={set:function(e,t,n){return!1===t?ce.removeAttr(e,n):e.setAttribute(n,n),n}},ce.each(ce.expr.match.bool.source.match(/\w+/g),function(e,t){var a=xt[t]||ce.find.attr;xt[t]=function(e,t,n){var r,i,o=t.toLowerCase();return n||(i=xt[o],xt[o]=r,r=null!=a(e,t,n)?o:null,xt[o]=i),r}});var bt=/^(?:input|select|textarea|button)$/i,wt=/^(?:a|area)$/i;function Tt(e){return(e.match(D)||[]).join(" ")}function Ct(e){return e.getAttribute&&e.getAttribute("class")||""}function kt(e){return Array.isArray(e)?e:"string"==typeof e&&e.match(D)||[]}ce.fn.extend({prop:function(e,t){return M(this,ce.prop,e,t,1<arguments.length)},removeProp:function(e){return this.each(function(){delete this[ce.propFix[e]||e]})}}),ce.extend({prop:function(e,t,n){var r,i,o=e.nodeType;if(3!==o&&8!==o&&2!==o)return 1===o&&ce.isXMLDoc(e)||(t=ce.propFix[t]||t,i=ce.propHooks[t]),void 0!==n?i&&"set"in i&&void 0!==(r=i.set(e,n,t))?r:e[t]=n:i&&"get"in i&&null!==(r=i.get(e,t))?r:e[t]},propHooks:{tabIndex:{get:function(e){var t=ce.find.attr(e,"tabindex");return t?parseInt(t,10):bt.test(e.nodeName)||wt.test(e.nodeName)&&e.href?0:-1}}},propFix:{"for":"htmlFor","class":"className"}}),le.optSelected||(ce.propHooks.selected={get:function(e){var t=e.parentNode;return t&&t.parentNode&&t.parentNode.selectedIndex,null},set:function(e){var t=e.parentNode;t&&(t.selectedIndex,t.parentNode&&t.parentNode.selectedIndex)}}),ce.each(["tabIndex","readOnly","maxLength","cellSpacing","cellPadding","rowSpan","colSpan","useMap","frameBorder","contentEditable"],function(){ce.propFix[this.toLowerCase()]=this}),ce.fn.extend({addClass:function(t){var e,n,r,i,o,a;return v(t)?this.each(function(e){ce(this).addClass(t.call(this,e,Ct(this)))}):(e=kt(t)).length?this.each(function(){if(r=Ct(this),n=1===this.nodeType&&" "+Tt(r)+" "){for(o=0;o<e.length;o++)i=e[o],n.indexOf(" "+i+" ")<0&&(n+=i+" ");a=Tt(n),r!==a&&this.setAttribute("class",a)}}):this},removeClass:function(t){var e,n,r,i,o,a;return v(t)?this.each(function(e){ce(this).removeClass(t.call(this,e,Ct(this)))}):arguments.length?(e=kt(t)).length?this.each(function(){if(r=Ct(this),n=1===this.nodeType&&" "+Tt(r)+" "){for(o=0;o<e.length;o++){i=e[o];while(-1<n.indexOf(" "+i+" "))n=n.replace(" "+i+" "," ")}a=Tt(n),r!==a&&this.setAttribute("class",a)}}):this:this.attr("class","")},toggleClass:function(t,n){var e,r,i,o,a=typeof t,s="string"===a||Array.isArray(t);return v(t)?this.each(function(e){ce(this).toggleClass(t.call(this,e,Ct(this),n),n)}):"boolean"==typeof n&&s?n?this.addClass(t):this.removeClass(t):(e=kt(t),this.each(function(){if(s)for(o=ce(this),i=0;i<e.length;i++)r=e[i],o.hasClass(r)?o.removeClass(r):o.addClass(r);else void 0!==t&&"boolean"!==a||((r=Ct(this))&&_.set(this,"__className__",r),this.setAttribute&&this.setAttribute("class",r||!1===t?"":_.get(this,"__className__")||""))}))},hasClass:function(e){var t,n,r=0;t=" "+e+" ";while(n=this[r++])if(1===n.nodeType&&-1<(" "+Tt(Ct(n))+" ").indexOf(t))return!0;return!1}});var St=/\r/g;ce.fn.extend({val:function(n){var r,e,i,t=this[0];return arguments.length?(i=v(n),this.each(function(e){var t;1===this.nodeType&&(null==(t=i?n.call(this,e,ce(this).val()):n)?t="":"number"==typeof t?t+="":Array.isArray(t)&&(t=ce.map(t,function(e){return null==e?"":e+""})),(r=ce.valHooks[this.type]||ce.valHooks[this.nodeName.toLowerCase()])&&"set"in r&&void 0!==r.set(this,t,"value")||(this.value=t))})):t?(r=ce.valHooks[t.type]||ce.valHooks[t.nodeName.toLowerCase()])&&"get"in r&&void 0!==(e=r.get(t,"value"))?e:"string"==typeof(e=t.value)?e.replace(St,""):null==e?"":e:void 0}}),ce.extend({valHooks:{option:{get:function(e){var t=ce.find.attr(e,"value");return null!=t?t:Tt(ce.text(e))}},select:{get:function(e){var t,n,r,i=e.options,o=e.selectedIndex,a="select-one"===e.type,s=a?null:[],u=a?o+1:i.length;for(r=o<0?u:a?o:0;r<u;r++)if(((n=i[r]).selected||r===o)&&!n.disabled&&(!n.parentNode.disabled||!fe(n.parentNode,"optgroup"))){if(t=ce(n).val(),a)return t;s.push(t)}return s},set:function(e,t){var n,r,i=e.options,o=ce.makeArray(t),a=i.length;while(a--)((r=i[a]).selected=-1<ce.inArray(ce.valHooks.option.get(r),o))&&(n=!0);return n||(e.selectedIndex=-1),o}}}}),ce.each(["radio","checkbox"],function(){ce.valHooks[this]={set:function(e,t){if(Array.isArray(t))return e.checked=-1<ce.inArray(ce(e).val(),t)}},le.checkOn||(ce.valHooks[this].get=function(e){return null===e.getAttribute("value")?"on":e.value})});var Et=ie.location,jt={guid:Date.now()},At=/\?/;ce.parseXML=function(e){var t,n;if(!e||"string"!=typeof e)return null;try{t=(new ie.DOMParser).parseFromString(e,"text/xml")}catch(e){}return n=t&&t.getElementsByTagName("parsererror")[0],t&&!n||ce.error("Invalid XML: "+(n?ce.map(n.childNodes,function(e){return e.textContent}).join("\n"):e)),t};var Dt=/^(?:focusinfocus|focusoutblur)$/,Nt=function(e){e.stopPropagation()};ce.extend(ce.event,{trigger:function(e,t,n,r){var i,o,a,s,u,l,c,f,p=[n||C],d=ue.call(e,"type")?e.type:e,h=ue.call(e,"namespace")?e.namespace.split("."):[];if(o=f=a=n=n||C,3!==n.nodeType&&8!==n.nodeType&&!Dt.test(d+ce.event.triggered)&&(-1<d.indexOf(".")&&(d=(h=d.split(".")).shift(),h.sort()),u=d.indexOf(":")<0&&"on"+d,(e=e[ce.expando]?e:new ce.Event(d,"object"==typeof e&&e)).isTrigger=r?2:3,e.namespace=h.join("."),e.rnamespace=e.namespace?new RegExp("(^|\\.)"+h.join("\\.(?:.*\\.|)")+"(\\.|$)"):null,e.result=void 0,e.target||(e.target=n),t=null==t?[e]:ce.makeArray(t,[e]),c=ce.event.special[d]||{},r||!c.trigger||!1!==c.trigger.apply(n,t))){if(!r&&!c.noBubble&&!y(n)){for(s=c.delegateType||d,Dt.test(s+d)||(o=o.parentNode);o;o=o.parentNode)p.push(o),a=o;a===(n.ownerDocument||C)&&p.push(a.defaultView||a.parentWindow||ie)}i=0;while((o=p[i++])&&!e.isPropagationStopped())f=o,e.type=1<i?s:c.bindType||d,(l=(_.get(o,"events")||Object.create(null))[e.type]&&_.get(o,"handle"))&&l.apply(o,t),(l=u&&o[u])&&l.apply&&$(o)&&(e.result=l.apply(o,t),!1===e.result&&e.preventDefault());return e.type=d,r||e.isDefaultPrevented()||c._default&&!1!==c._default.apply(p.pop(),t)||!$(n)||u&&v(n[d])&&!y(n)&&((a=n[u])&&(n[u]=null),ce.event.triggered=d,e.isPropagationStopped()&&f.addEventListener(d,Nt),n[d](),e.isPropagationStopped()&&f.removeEventListener(d,Nt),ce.event.triggered=void 0,a&&(n[u]=a)),e.result}},simulate:function(e,t,n){var r=ce.extend(new ce.Event,n,{type:e,isSimulated:!0});ce.event.trigger(r,null,t)}}),ce.fn.extend({trigger:function(e,t){return this.each(function(){ce.event.trigger(e,t,this)})},triggerHandler:function(e,t){var n=this[0];if(n)return ce.event.trigger(e,t,n,!0)}});var qt=/\[\]$/,Lt=/\r?\n/g,Ht=/^(?:submit|button|image|reset|file)$/i,Ot=/^(?:input|select|textarea|keygen)/i;function Pt(n,e,r,i){var t;if(Array.isArray(e))ce.each(e,function(e,t){r||qt.test(n)?i(n,t):Pt(n+"["+("object"==typeof t&&null!=t?e:"")+"]",t,r,i)});else if(r||"object"!==x(e))i(n,e);else for(t in e)Pt(n+"["+t+"]",e[t],r,i)}ce.param=function(e,t){var n,r=[],i=function(e,t){var n=v(t)?t():t;r[r.length]=encodeURIComponent(e)+"="+encodeURIComponent(null==n?"":n)};if(null==e)return"";if(Array.isArray(e)||e.jquery&&!ce.isPlainObject(e))ce.each(e,function(){i(this.name,this.value)});else for(n in e)Pt(n,e[n],t,i);return r.join("&")},ce.fn.extend({serialize:function(){return ce.param(this.serializeArray())},serializeArray:function(){return this.map(function(){var e=ce.prop(this,"elements");return e?ce.makeArray(e):this}).filter(function(){var e=this.type;return this.name&&!ce(this).is(":disabled")&&Ot.test(this.nodeName)&&!Ht.test(e)&&(this.checked||!we.test(e))}).map(function(e,t){var n=ce(this).val();return null==n?null:Array.isArray(n)?ce.map(n,function(e){return{name:t.name,value:e.replace(Lt,"\r\n")}}):{name:t.name,value:n.replace(Lt,"\r\n")}}).get()}});var Mt=/%20/g,Rt=/#.*$/,It=/([?&])_=[^&]*/,Wt=/^(.*?):[ \t]*([^\r\n]*)$/gm,Ft=/^(?:GET|HEAD)$/,$t=/^\/\//,Bt={},_t={},zt="*/".concat("*"),Xt=C.createElement("a");function Ut(o){return function(e,t){"string"!=typeof e&&(t=e,e="*");var n,r=0,i=e.toLowerCase().match(D)||[];if(v(t))while(n=i[r++])"+"===n[0]?(n=n.slice(1)||"*",(o[n]=o[n]||[]).unshift(t)):(o[n]=o[n]||[]).push(t)}}function Vt(t,i,o,a){var s={},u=t===_t;function l(e){var r;return s[e]=!0,ce.each(t[e]||[],function(e,t){var n=t(i,o,a);return"string"!=typeof n||u||s[n]?u?!(r=n):void 0:(i.dataTypes.unshift(n),l(n),!1)}),r}return l(i.dataTypes[0])||!s["*"]&&l("*")}function Gt(e,t){var n,r,i=ce.ajaxSettings.flatOptions||{};for(n in t)void 0!==t[n]&&((i[n]?e:r||(r={}))[n]=t[n]);return r&&ce.extend(!0,e,r),e}Xt.href=Et.href,ce.extend({active:0,lastModified:{},etag:{},ajaxSettings:{url:Et.href,type:"GET",isLocal:/^(?:about|app|app-storage|.+-extension|file|res|widget):$/.test(Et.protocol),global:!0,processData:!0,async:!0,contentType:"application/x-www-form-urlencoded; charset=UTF-8",accepts:{"*":zt,text:"text/plain",html:"text/html",xml:"application/xml, text/xml",json:"application/json, text/javascript"},contents:{xml:/\bxml\b/,html:/\bhtml/,json:/\bjson\b/},responseFields:{xml:"responseXML",text:"responseText",json:"responseJSON"},converters:{"* text":String,"text html":!0,"text json":JSON.parse,"text xml":ce.parseXML},flatOptions:{url:!0,context:!0}},ajaxSetup:function(e,t){return t?Gt(Gt(e,ce.ajaxSettings),t):Gt(ce.ajaxSettings,e)},ajaxPrefilter:Ut(Bt),ajaxTransport:Ut(_t),ajax:function(e,t){"object"==typeof e&&(t=e,e=void 0),t=t||{};var c,f,p,n,d,r,h,g,i,o,v=ce.ajaxSetup({},t),y=v.context||v,m=v.context&&(y.nodeType||y.jquery)?ce(y):ce.event,x=ce.Deferred(),b=ce.Callbacks("once memory"),w=v.statusCode||{},a={},s={},u="canceled",T={readyState:0,getResponseHeader:function(e){var t;if(h){if(!n){n={};while(t=Wt.exec(p))n[t[1].toLowerCase()+" "]=(n[t[1].toLowerCase()+" "]||[]).concat(t[2])}t=n[e.toLowerCase()+" "]}return null==t?null:t.join(", ")},getAllResponseHeaders:function(){return h?p:null},setRequestHeader:function(e,t){return null==h&&(e=s[e.toLowerCase()]=s[e.toLowerCase()]||e,a[e]=t),this},overrideMimeType:function(e){return null==h&&(v.mimeType=e),this},statusCode:function(e){var t;if(e)if(h)T.always(e[T.status]);else for(t in e)w[t]=[w[t],e[t]];return this},abort:function(e){var t=e||u;return c&&c.abort(t),l(0,t),this}};if(x.promise(T),v.url=((e||v.url||Et.href)+"").replace($t,Et.protocol+"//"),v.type=t.method||t.type||v.method||v.type,v.dataTypes=(v.dataType||"*").toLowerCase().match(D)||[""],null==v.crossDomain){r=C.createElement("a");try{r.href=v.url,r.href=r.href,v.crossDomain=Xt.protocol+"//"+Xt.host!=r.protocol+"//"+r.host}catch(e){v.crossDomain=!0}}if(v.data&&v.processData&&"string"!=typeof v.data&&(v.data=ce.param(v.data,v.traditional)),Vt(Bt,v,t,T),h)return T;for(i in(g=ce.event&&v.global)&&0==ce.active++&&ce.event.trigger("ajaxStart"),v.type=v.type.toUpperCase(),v.hasContent=!Ft.test(v.type),f=v.url.replace(Rt,""),v.hasContent?v.data&&v.processData&&0===(v.contentType||"").indexOf("application/x-www-form-urlencoded")&&(v.data=v.data.replace(Mt,"+")):(o=v.url.slice(f.length),v.data&&(v.processData||"string"==typeof v.data)&&(f+=(At.test(f)?"&":"?")+v.data,delete v.data),!1===v.cache&&(f=f.replace(It,"$1"),o=(At.test(f)?"&":"?")+"_="+jt.guid+++o),v.url=f+o),v.ifModified&&(ce.lastModified[f]&&T.setRequestHeader("If-Modified-Since",ce.lastModified[f]),ce.etag[f]&&T.setRequestHeader("If-None-Match",ce.etag[f])),(v.data&&v.hasContent&&!1!==v.contentType||t.contentType)&&T.setRequestHeader("Content-Type",v.contentType),T.setRequestHeader("Accept",v.dataTypes[0]&&v.accepts[v.dataTypes[0]]?v.accepts[v.dataTypes[0]]+("*"!==v.dataTypes[0]?", "+zt+"; q=0.01":""):v.accepts["*"]),v.headers)T.setRequestHeader(i,v.headers[i]);if(v.beforeSend&&(!1===v.beforeSend.call(y,T,v)||h))return T.abort();if(u="abort",b.add(v.complete),T.done(v.success),T.fail(v.error),c=Vt(_t,v,t,T)){if(T.readyState=1,g&&m.trigger("ajaxSend",[T,v]),h)return T;v.async&&0<v.timeout&&(d=ie.setTimeout(function(){T.abort("timeout")},v.timeout));try{h=!1,c.send(a,l)}catch(e){if(h)throw e;l(-1,e)}}else l(-1,"No Transport");function l(e,t,n,r){var i,o,a,s,u,l=t;h||(h=!0,d&&ie.clearTimeout(d),c=void 0,p=r||"",T.readyState=0<e?4:0,i=200<=e&&e<300||304===e,n&&(s=function(e,t,n){var r,i,o,a,s=e.contents,u=e.dataTypes;while("*"===u[0])u.shift(),void 0===r&&(r=e.mimeType||t.getResponseHeader("Content-Type"));if(r)for(i in s)if(s[i]&&s[i].test(r)){u.unshift(i);break}if(u[0]in n)o=u[0];else{for(i in n){if(!u[0]||e.converters[i+" "+u[0]]){o=i;break}a||(a=i)}o=o||a}if(o)return o!==u[0]&&u.unshift(o),n[o]}(v,T,n)),!i&&-1<ce.inArray("script",v.dataTypes)&&ce.inArray("json",v.dataTypes)<0&&(v.converters["text script"]=function(){}),s=function(e,t,n,r){var i,o,a,s,u,l={},c=e.dataTypes.slice();if(c[1])for(a in e.converters)l[a.toLowerCase()]=e.converters[a];o=c.shift();while(o)if(e.responseFields[o]&&(n[e.responseFields[o]]=t),!u&&r&&e.dataFilter&&(t=e.dataFilter(t,e.dataType)),u=o,o=c.shift())if("*"===o)o=u;else if("*"!==u&&u!==o){if(!(a=l[u+" "+o]||l["* "+o]))for(i in l)if((s=i.split(" "))[1]===o&&(a=l[u+" "+s[0]]||l["* "+s[0]])){!0===a?a=l[i]:!0!==l[i]&&(o=s[0],c.unshift(s[1]));break}if(!0!==a)if(a&&e["throws"])t=a(t);else try{t=a(t)}catch(e){return{state:"parsererror",error:a?e:"No conversion from "+u+" to "+o}}}return{state:"success",data:t}}(v,s,T,i),i?(v.ifModified&&((u=T.getResponseHeader("Last-Modified"))&&(ce.lastModified[f]=u),(u=T.getResponseHeader("etag"))&&(ce.etag[f]=u)),204===e||"HEAD"===v.type?l="nocontent":304===e?l="notmodified":(l=s.state,o=s.data,i=!(a=s.error))):(a=l,!e&&l||(l="error",e<0&&(e=0))),T.status=e,T.statusText=(t||l)+"",i?x.resolveWith(y,[o,l,T]):x.rejectWith(y,[T,l,a]),T.statusCode(w),w=void 0,g&&m.trigger(i?"ajaxSuccess":"ajaxError",[T,v,i?o:a]),b.fireWith(y,[T,l]),g&&(m.trigger("ajaxComplete",[T,v]),--ce.active||ce.event.trigger("ajaxStop")))}return T},getJSON:function(e,t,n){return ce.get(e,t,n,"json")},getScript:function(e,t){return ce.get(e,void 0,t,"script")}}),ce.each(["get","post"],function(e,i){ce[i]=function(e,t,n,r){return v(t)&&(r=r||n,n=t,t=void 0),ce.ajax(ce.extend({url:e,type:i,dataType:r,data:t,success:n},ce.isPlainObject(e)&&e))}}),ce.ajaxPrefilter(function(e){var t;for(t in e.headers)"content-type"===t.toLowerCase()&&(e.contentType=e.headers[t]||"")}),ce._evalUrl=function(e,t,n){return ce.ajax({url:e,type:"GET",dataType:"script",cache:!0,async:!1,global:!1,converters:{"text script":function(){}},dataFilter:function(e){ce.globalEval(e,t,n)}})},ce.fn.extend({wrapAll:function(e){var t;return this[0]&&(v(e)&&(e=e.call(this[0])),t=ce(e,this[0].ownerDocument).eq(0).clone(!0),this[0].parentNode&&t.insertBefore(this[0]),t.map(function(){var e=this;while(e.firstElementChild)e=e.firstElementChild;return e}).append(this)),this},wrapInner:function(n){return v(n)?this.each(function(e){ce(this).wrapInner(n.call(this,e))}):this.each(function(){var e=ce(this),t=e.contents();t.length?t.wrapAll(n):e.append(n)})},wrap:function(t){var n=v(t);return this.each(function(e){ce(this).wrapAll(n?t.call(this,e):t)})},unwrap:function(e){return this.parent(e).not("body").each(function(){ce(this).replaceWith(this.childNodes)}),this}}),ce.expr.pseudos.hidden=function(e){return!ce.expr.pseudos.visible(e)},ce.expr.pseudos.visible=function(e){return!!(e.offsetWidth||e.offsetHeight||e.getClientRects().length)},ce.ajaxSettings.xhr=function(){try{return new ie.XMLHttpRequest}catch(e){}};var Yt={0:200,1223:204},Qt=ce.ajaxSettings.xhr();le.cors=!!Qt&&"withCredentials"in Qt,le.ajax=Qt=!!Qt,ce.ajaxTransport(function(i){var o,a;if(le.cors||Qt&&!i.crossDomain)return{send:function(e,t){var n,r=i.xhr();if(r.open(i.type,i.url,i.async,i.username,i.password),i.xhrFields)for(n in i.xhrFields)r[n]=i.xhrFields[n];for(n in i.mimeType&&r.overrideMimeType&&r.overrideMimeType(i.mimeType),i.crossDomain||e["X-Requested-With"]||(e["X-Requested-With"]="XMLHttpRequest"),e)r.setRequestHeader(n,e[n]);o=function(e){return function(){o&&(o=a=r.onload=r.onerror=r.onabort=r.ontimeout=r.onreadystatechange=null,"abort"===e?r.abort():"error"===e?"number"!=typeof r.status?t(0,"error"):t(r.status,r.statusText):t(Yt[r.status]||r.status,r.statusText,"text"!==(r.responseType||"text")||"string"!=typeof r.responseText?{binary:r.response}:{text:r.responseText},r.getAllResponseHeaders()))}},r.onload=o(),a=r.onerror=r.ontimeout=o("error"),void 0!==r.onabort?r.onabort=a:r.onreadystatechange=function(){4===r.readyState&&ie.setTimeout(function(){o&&a()})},o=o("abort");try{r.send(i.hasContent&&i.data||null)}catch(e){if(o)throw e}},abort:function(){o&&o()}}}),ce.ajaxPrefilter(function(e){e.crossDomain&&(e.contents.script=!1)}),ce.ajaxSetup({accepts:{script:"text/javascript, application/javascript, application/ecmascript, application/x-ecmascript"},contents:{script:/\b(?:java|ecma)script\b/},converters:{"text script":function(e){return ce.globalEval(e),e}}}),ce.ajaxPrefilter("script",function(e){void 0===e.cache&&(e.cache=!1),e.crossDomain&&(e.type="GET")}),ce.ajaxTransport("script",function(n){var r,i;if(n.crossDomain||n.scriptAttrs)return{send:function(e,t){r=ce("<script>").attr(n.scriptAttrs||{}).prop({charset:n.scriptCharset,src:n.url}).on("load error",i=function(e){r.remove(),i=null,e&&t("error"===e.type?404:200,e.type)}),C.head.appendChild(r[0])},abort:function(){i&&i()}}});var Jt,Kt=[],Zt=/(=)\?(?=&|$)|\?\?/;ce.ajaxSetup({jsonp:"callback",jsonpCallback:function(){var e=Kt.pop()||ce.expando+"_"+jt.guid++;return this[e]=!0,e}}),ce.ajaxPrefilter("json jsonp",function(e,t,n){var r,i,o,a=!1!==e.jsonp&&(Zt.test(e.url)?"url":"string"==typeof e.data&&0===(e.contentType||"").indexOf("application/x-www-form-urlencoded")&&Zt.test(e.data)&&"data");if(a||"jsonp"===e.dataTypes[0])return r=e.jsonpCallback=v(e.jsonpCallback)?e.jsonpCallback():e.jsonpCallback,a?e[a]=e[a].replace(Zt,"$1"+r):!1!==e.jsonp&&(e.url+=(At.test(e.url)?"&":"?")+e.jsonp+"="+r),e.converters["script json"]=function(){return o||ce.error(r+" was not called"),o[0]},e.dataTypes[0]="json",i=ie[r],ie[r]=function(){o=arguments},n.always(function(){void 0===i?ce(ie).removeProp(r):ie[r]=i,e[r]&&(e.jsonpCallback=t.jsonpCallback,Kt.push(r)),o&&v(i)&&i(o[0]),o=i=void 0}),"script"}),le.createHTMLDocument=((Jt=C.implementation.createHTMLDocument("").body).innerHTML="<form></form><form></form>",2===Jt.childNodes.length),ce.parseHTML=function(e,t,n){return"string"!=typeof e?[]:("boolean"==typeof t&&(n=t,t=!1),t||(le.createHTMLDocument?((r=(t=C.implementation.createHTMLDocument("")).createElement("base")).href=C.location.href,t.head.appendChild(r)):t=C),o=!n&&[],(i=w.exec(e))?[t.createElement(i[1])]:(i=Ae([e],t,o),o&&o.length&&ce(o).remove(),ce.merge([],i.childNodes)));var r,i,o},ce.fn.load=function(e,t,n){var r,i,o,a=this,s=e.indexOf(" ");return-1<s&&(r=Tt(e.slice(s)),e=e.slice(0,s)),v(t)?(n=t,t=void 0):t&&"object"==typeof t&&(i="POST"),0<a.length&&ce.ajax({url:e,type:i||"GET",dataType:"html",data:t}).done(function(e){o=arguments,a.html(r?ce("<div>").append(ce.parseHTML(e)).find(r):e)}).always(n&&function(e,t){a.each(function(){n.apply(this,o||[e.responseText,t,e])})}),this},ce.expr.pseudos.animated=function(t){return ce.grep(ce.timers,function(e){return t===e.elem}).length},ce.offset={setOffset:function(e,t,n){var r,i,o,a,s,u,l=ce.css(e,"position"),c=ce(e),f={};"static"===l&&(e.style.position="relative"),s=c.offset(),o=ce.css(e,"top"),u=ce.css(e,"left"),("absolute"===l||"fixed"===l)&&-1<(o+u).indexOf("auto")?(a=(r=c.position()).top,i=r.left):(a=parseFloat(o)||0,i=parseFloat(u)||0),v(t)&&(t=t.call(e,n,ce.extend({},s))),null!=t.top&&(f.top=t.top-s.top+a),null!=t.left&&(f.left=t.left-s.left+i),"using"in t?t.using.call(e,f):c.css(f)}},ce.fn.extend({offset:function(t){if(arguments.length)return void 0===t?this:this.each(function(e){ce.offset.setOffset(this,t,e)});var e,n,r=this[0];return r?r.getClientRects().length?(e=r.getBoundingClientRect(),n=r.ownerDocument.defaultView,{top:e.top+n.pageYOffset,left:e.left+n.pageXOffset}):{top:0,left:0}:void 0},position:function(){if(this[0]){var e,t,n,r=this[0],i={top:0,left:0};if("fixed"===ce.css(r,"position"))t=r.getBoundingClientRect();else{t=this.offset(),n=r.ownerDocument,e=r.offsetParent||n.documentElement;while(e&&(e===n.body||e===n.documentElement)&&"static"===ce.css(e,"position"))e=e.parentNode;e&&e!==r&&1===e.nodeType&&((i=ce(e).offset()).top+=ce.css(e,"borderTopWidth",!0),i.left+=ce.css(e,"borderLeftWidth",!0))}return{top:t.top-i.top-ce.css(r,"marginTop",!0),left:t.left-i.left-ce.css(r,"marginLeft",!0)}}},offsetParent:function(){return this.map(function(){var e=this.offsetParent;while(e&&"static"===ce.css(e,"position"))e=e.offsetParent;return e||J})}}),ce.each({scrollLeft:"pageXOffset",scrollTop:"pageYOffset"},function(t,i){var o="pageYOffset"===i;ce.fn[t]=function(e){return M(this,function(e,t,n){var r;if(y(e)?r=e:9===e.nodeType&&(r=e.defaultView),void 0===n)return r?r[i]:e[t];r?r.scrollTo(o?r.pageXOffset:n,o?n:r.pageYOffset):e[t]=n},t,e,arguments.length)}}),ce.each(["top","left"],function(e,n){ce.cssHooks[n]=Ye(le.pixelPosition,function(e,t){if(t)return t=Ge(e,n),_e.test(t)?ce(e).position()[n]+"px":t})}),ce.each({Height:"height",Width:"width"},function(a,s){ce.each({padding:"inner"+a,content:s,"":"outer"+a},function(r,o){ce.fn[o]=function(e,t){var n=arguments.length&&(r||"boolean"!=typeof e),i=r||(!0===e||!0===t?"margin":"border");return M(this,function(e,t,n){var r;return y(e)?0===o.indexOf("outer")?e["inner"+a]:e.document.documentElement["client"+a]:9===e.nodeType?(r=e.documentElement,Math.max(e.body["scroll"+a],r["scroll"+a],e.body["offset"+a],r["offset"+a],r["client"+a])):void 0===n?ce.css(e,t,i):ce.style(e,t,n,i)},s,n?e:void 0,n)}})}),ce.each(["ajaxStart","ajaxStop","ajaxComplete","ajaxError","ajaxSuccess","ajaxSend"],function(e,t){ce.fn[t]=function(e){return this.on(t,e)}}),ce.fn.extend({bind:function(e,t,n){return this.on(e,null,t,n)},unbind:function(e,t){return this.off(e,null,t)},delegate:function(e,t,n,r){return this.on(t,e,n,r)},undelegate:function(e,t,n){return 1===arguments.length?this.off(e,"**"):this.off(t,e||"**",n)},hover:function(e,t){return this.on("mouseenter",e).on("mouseleave",t||e)}}),ce.each("blur focus focusin focusout resize scroll click dblclick mousedown mouseup mousemove mouseover mouseout mouseenter mouseleave change select submit keydown keypress keyup contextmenu".split(" "),function(e,n){ce.fn[n]=function(e,t){return 0<arguments.length?this.on(n,null,e,t):this.trigger(n)}});var en=/^[\s\uFEFF\xA0]+|([^\s\uFEFF\xA0])[\s\uFEFF\xA0]+$/g;ce.proxy=function(e,t){var n,r,i;if("string"==typeof t&&(n=e[t],t=e,e=n),v(e))return r=ae.call(arguments,2),(i=function(){return e.apply(t||this,r.concat(ae.call(arguments)))}).guid=e.guid=e.guid||ce.guid++,i},ce.holdReady=function(e){e?ce.readyWait++:ce.ready(!0)},ce.isArray=Array.isArray,ce.parseJSON=JSON.parse,ce.nodeName=fe,ce.isFunction=v,ce.isWindow=y,ce.camelCase=F,ce.type=x,ce.now=Date.now,ce.isNumeric=function(e){var t=ce.type(e);return("number"===t||"string"===t)&&!isNaN(e-parseFloat(e))},ce.trim=function(e){return null==e?"":(e+"").replace(en,"$1")},"function"==typeof define&&define.amd&&define("jquery",[],function(){return ce});var tn=ie.jQuery,nn=ie.$;return ce.noConflict=function(e){return ie.$===ce&&(ie.$=nn),e&&ie.jQuery===ce&&(ie.jQuery=tn),ce},"undefined"==typeof e&&(ie.jQuery=ie.$=ce),ce});

From ad3c1308a7c1310e34416cfd0438f00666639744 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:34:14 +0200
Subject: [PATCH 504/749] add maintaining balance

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/pl/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..51d312d3499
--- /dev/null
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: en
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From 2cd20ad8d9d490f6c943da73199c33a517a8dd9a Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:37:41 +0200
Subject: [PATCH 505/749] add translate for meta maintaining balance

---
 .../pl/maintaining-balance-for-open-source-maintainers.md   | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 51d312d3499..a195bde87f9 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -1,8 +1,8 @@
 ---
-lang: en
+lang: pl
 untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+title: Utrzymanie równowagi dla opiekunów Open Source
+description: Wskazówki dotyczące dbania o siebie i unikania wypalenia jako opiekun.
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png

From 12793dd619aa9f74556a13371cff04be4ab9affb Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:52:24 +0200
Subject: [PATCH 506/749] add maintaining balance file for DE

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/de/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..29808f19840
--- /dev/null
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: de
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From 67687143679108811cf85cf98c631ea3bc3b63c7 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:53:15 +0200
Subject: [PATCH 507/749] add maintaining balance file for EL

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/el/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/el/maintaining-balance-for-open-source-maintainers.md b/_articles/el/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..ce653c289f3
--- /dev/null
+++ b/_articles/el/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: el
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From 3ae2d9f111797448c83a51a3d1566fad652739af Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:53:32 +0200
Subject: [PATCH 508/749] add maintaining balance file for ES

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/es/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/es/maintaining-balance-for-open-source-maintainers.md b/_articles/es/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..776f4487381
--- /dev/null
+++ b/_articles/es/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: es
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From 30020ec878ffb3bf50fb9411d38928da50b922d7 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:53:49 +0200
Subject: [PATCH 509/749] add maintaining balance file for FA

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/fa/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/fa/maintaining-balance-for-open-source-maintainers.md b/_articles/fa/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..d1019690a19
--- /dev/null
+++ b/_articles/fa/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: fa
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From ececfd9cfee7ab878efefb35655162592e22de54 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:54:05 +0200
Subject: [PATCH 510/749] add maintaining balance file for FR

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/fr/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/fr/maintaining-balance-for-open-source-maintainers.md b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..a71d2cf9f81
--- /dev/null
+++ b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: fr
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From a0ae0c894a2c52d1c272c84eb1ddde46639dcd71 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:54:21 +0200
Subject: [PATCH 511/749] add maintaining balance file for HU

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/hu/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/hu/maintaining-balance-for-open-source-maintainers.md b/_articles/hu/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..b7825099585
--- /dev/null
+++ b/_articles/hu/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: hu
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From c2e1389290d84abb292866bd8b421f62bc18ba46 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:54:37 +0200
Subject: [PATCH 512/749] add maintaining balance file for ID

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/id/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/id/maintaining-balance-for-open-source-maintainers.md b/_articles/id/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..081eaa3069a
--- /dev/null
+++ b/_articles/id/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: id
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From 631a9a7d85577b934cd116a58cd9651e2b4ddf57 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:54:52 +0200
Subject: [PATCH 513/749] add maintaining balance file for JA

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/ja/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/ja/maintaining-balance-for-open-source-maintainers.md b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..0cea6e5c0fc
--- /dev/null
+++ b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: ja
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From ece7bc8079f9f12a785043ae1ee285571079c4b1 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:55:07 +0200
Subject: [PATCH 514/749] add maintaining balance file for KO

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/ko/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/ko/maintaining-balance-for-open-source-maintainers.md b/_articles/ko/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..1e9216a51ac
--- /dev/null
+++ b/_articles/ko/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: ko
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From 6a76efb293fa9707aa575337f20eb5274ed7efdf Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:55:28 +0200
Subject: [PATCH 515/749] add maintaining balance file for MS

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/ms/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/ms/maintaining-balance-for-open-source-maintainers.md b/_articles/ms/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..86b3d3f9cfd
--- /dev/null
+++ b/_articles/ms/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: ms
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From fc69fc5068880cfef1f099f153a2ec50391dbadd Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:55:46 +0200
Subject: [PATCH 516/749] add maintaining balance file for NL

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/nl/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/nl/maintaining-balance-for-open-source-maintainers.md b/_articles/nl/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..df593ff4b32
--- /dev/null
+++ b/_articles/nl/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: nl
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From 28f7c426205ca3e6f3e3f56b5f4bd9cffa7b2261 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:56:08 +0200
Subject: [PATCH 517/749] add maintaining balance file for PL

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/pl/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..3095b7603fa
--- /dev/null
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: pl
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From 80142d6589bfe065b3b33ba2403434830ae066b3 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:56:25 +0200
Subject: [PATCH 518/749] add maintaining balance file for PT

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/pt/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/pt/maintaining-balance-for-open-source-maintainers.md b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..1c832e12eaa
--- /dev/null
+++ b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: pt
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From ba97b9a7b3e33cb283b6f14c20233e748b77d3eb Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:56:38 +0200
Subject: [PATCH 519/749] add maintaining balance file for RO

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/ro/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/ro/maintaining-balance-for-open-source-maintainers.md b/_articles/ro/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..5c1efa15935
--- /dev/null
+++ b/_articles/ro/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: ro
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From 34cf5bacf4dadf23d9bf80327783dc01ec2cfb8c Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:56:54 +0200
Subject: [PATCH 520/749] add maintaining balance file for RU

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/ru/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/ru/maintaining-balance-for-open-source-maintainers.md b/_articles/ru/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..047e92d015a
--- /dev/null
+++ b/_articles/ru/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: ru
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From 05beb42578012ccb8a5ed4cab31f88e50d9cc430 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:57:09 +0200
Subject: [PATCH 521/749] add maintaining balance file for TA

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/ta/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/ta/maintaining-balance-for-open-source-maintainers.md b/_articles/ta/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..ed52f315d72
--- /dev/null
+++ b/_articles/ta/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: ta
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From 31fff7f1802d188a39557d2c49c8fa9848a6ea46 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:57:23 +0200
Subject: [PATCH 522/749] add maintaining balance file for TR

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/tr/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/tr/maintaining-balance-for-open-source-maintainers.md b/_articles/tr/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..3f3ca65161b
--- /dev/null
+++ b/_articles/tr/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: tr
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From df82787637ed3929dff7fd5a22b67d75e63a5620 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:57:53 +0200
Subject: [PATCH 523/749] add maintaining balance file for ZH-hans

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/zh-hans/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..df51babccb0
--- /dev/null
+++ b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: zh-hans
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From b89e0e7615ef8522e63d9f43c5d1e39200ea50b5 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 09:58:17 +0200
Subject: [PATCH 524/749] add maintaining balance file for ZH-hant

---
 ...ing-balance-for-open-source-maintainers.md | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 _articles/zh-hant/maintaining-balance-for-open-source-maintainers.md

diff --git a/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..dc77d26dbe9
--- /dev/null
+++ b/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: zh-hant
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!

From 27838630b4229ec48b1362eca4604d13ba1e22a6 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 10:30:00 +0200
Subject: [PATCH 525/749] add translate in the maintaining balance section 0
 part 1

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index a195bde87f9..0acf0f4c874 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -8,7 +8,7 @@ order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+W miarę jak popularność projektu open source rośnie, ważne staje się ustalenie jasnych granic, które pomogą zachować równowagę, aby zachować świeżość i produktywność na dłuższą metę.
 
 To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
 

From 4e35a397f757021adc867d66c666a76ce75b0ebb Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 10:30:20 +0200
Subject: [PATCH 526/749] add translate in the maintaining balance section 0
 part 2

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 0acf0f4c874..61c2cec6162 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -10,7 +10,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 
 W miarę jak popularność projektu open source rośnie, ważne staje się ustalenie jasnych granic, które pomogą zachować równowagę, aby zachować świeżość i produktywność na dłuższą metę.
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+Aby uzyskać zrozumienie doświadczeń opiekunów i ich strategii znajdowania równowagi, przeprowadziliśmy warsztaty z 40 członkami <a href="http://maintainers.github.com/">opiekunów społeczności</a>, pozwalając nam poznać ich własne doświadczenia z wypaleniem w open source i praktyki, które pomogły im zachować równowagę w pracy. W tym miejscu pojawia się koncepcja osobistej ekologii.
 
 So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
 

From 5e98a772c5ef124469dda1150105a4993cd811a8 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 10:49:41 +0200
Subject: [PATCH 527/749] add translate in the maintaining balance section 0
 part 3

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 61c2cec6162..8bfa956cb87 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -12,7 +12,7 @@ W miarę jak popularność projektu open source rośnie, ważne staje się ustal
 
 Aby uzyskać zrozumienie doświadczeń opiekunów i ich strategii znajdowania równowagi, przeprowadziliśmy warsztaty z 40 członkami <a href="http://maintainers.github.com/">opiekunów społeczności</a>, pozwalając nam poznać ich własne doświadczenia z wypaleniem w open source i praktyki, które pomogły im zachować równowagę w pracy. W tym miejscu pojawia się koncepcja osobistej ekologii.
 
-So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+Czym więc jest ekologia osobista? Zgodnie z <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">opisem Rockwood Leadership Institute</a>,obejmuje ona "<strong>utrzymywanie równowagi, tempa i wydajności, aby utrzymać naszą energię przez całe życie</strong>." To nadało ramy naszym rozmowom, pomagając opiekunom rozpoznać ich działania i wkład jako części większego ekosystemu, który ewoluuje w czasie.Wypalenie, syndrom wynikający z przewlekłego stresu w miejscu pracy, zgodnie z [definicja WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), nie jest niczym niezwykłym wśród opiekunów. Często prowadzi to do utraty motywacji, niemożności skupienia się i braku empatii dla współpracowników i społeczności, z którą pracujesz.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">

From 4ac1ae878749755789be7968e2c8d85088f1e7e0 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 10:51:00 +0200
Subject: [PATCH 528/749] add translate in the maintaining balance section 0
 part 4

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 8bfa956cb87..b82f0f17a40 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -22,7 +22,7 @@ Czym więc jest ekologia osobista? Zgodnie z <a href="https://rockwoodleadership
   </p>
 </aside>
 
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+Przyjmując koncepcję osobistej ekologii, opiekunowie mogą aktywnie unikać wypalenia, traktować priorytetowo dbanie o siebie i utrzymywać poczucie równowagi, aby wykonywać swoją najlepszą pracę.
 
 ## Tips for Self-Care and Avoiding Burnout as a Maintainer:
 

From b82c770d6dfa9842212160dd662365202afb2186 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 12:10:30 +0200
Subject: [PATCH 529/749] add translate in the maintaining balance section 1
 part 1

---
 .../pl/maintaining-balance-for-open-source-maintainers.md   | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index b82f0f17a40..7fe9060ac9d 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -24,11 +24,11 @@ Czym więc jest ekologia osobista? Zgodnie z <a href="https://rockwoodleadership
 
 Przyjmując koncepcję osobistej ekologii, opiekunowie mogą aktywnie unikać wypalenia, traktować priorytetowo dbanie o siebie i utrzymywać poczucie równowagi, aby wykonywać swoją najlepszą pracę.
 
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+## Wskazówki dotyczące dbania o siebie i unikania wypalenia zawodowego w roli opiekuna:
 
-### Identify your motivations for working in open source
+### Określ swoje motywacje do pracy w open source
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+Poświęć trochę czasu na zastanowienie się nad tym, jakie części utrzymania open source cię energetyzują. Zrozumienie swoich motywacji może pomóc w ustaleniu priorytetów pracy w sposób, który sprawi, że będziesz zaangażowany i gotowy na nowe wyzwania. Niezależnie od tego, czy chodzi o pozytywne opinie użytkowników, radość ze współpracy i kontaktów towarzyskich ze społecznością, czy też satysfakcję z zagłębiania się w kod, rozpoznanie motywacji może pomóc w skupieniu się na pracy.
 
 ### Reflect on what causes you to get out of balance and stressed out
 

From aa560204acc2ca21b4f57facc3585949da6e4c4e Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 12:14:21 +0200
Subject: [PATCH 530/749] add translate in the maintaining balance section 1
 part 2

---
 .../pl/maintaining-balance-for-open-source-maintainers.md     | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 7fe9060ac9d..ad871338d38 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -30,9 +30,9 @@ Przyjmując koncepcję osobistej ekologii, opiekunowie mogą aktywnie unikać wy
 
 Poświęć trochę czasu na zastanowienie się nad tym, jakie części utrzymania open source cię energetyzują. Zrozumienie swoich motywacji może pomóc w ustaleniu priorytetów pracy w sposób, który sprawi, że będziesz zaangażowany i gotowy na nowe wyzwania. Niezależnie od tego, czy chodzi o pozytywne opinie użytkowników, radość ze współpracy i kontaktów towarzyskich ze społecznością, czy też satysfakcję z zagłębiania się w kod, rozpoznanie motywacji może pomóc w skupieniu się na pracy.
 
-### Reflect on what causes you to get out of balance and stressed out
+### Zastanów się, co powoduje, że tracisz równowagę i stresujesz się
 
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+Ważne jest, aby zrozumieć, co powoduje nasze wypalenie. Oto kilka wspólnych tematów, które zaobserwowaliśmy wśród opiekunów open source:
 
 * **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
 

From 700413403fed59f3ab32c0aafa12f12b9dc36391 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 12:19:50 +0200
Subject: [PATCH 531/749] add translate in the maintaining balance section 1
 part 3

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index ad871338d38..5ea18f6bbd8 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -34,7 +34,7 @@ Poświęć trochę czasu na zastanowienie się nad tym, jakie części utrzymani
 
 Ważne jest, aby zrozumieć, co powoduje nasze wypalenie. Oto kilka wspólnych tematów, które zaobserwowaliśmy wśród opiekunów open source:
 
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+* **Brak pozytywnych opinii:** Użytkownicy są znacznie bardziej skłonni do zgłaszania swoich skarg. Jeśli wszystko działa świetnie, mają tendencję do milczenia. Może to być zniechęcające, gdy widzi się rosnącą listę problemów bez pozytywnych opinii pokazujących, w jaki sposób Twój wkład robi różnicę.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">

From 73d6d9da7080dccb0ce1cd52398658f2c9c72e1e Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 12:20:01 +0200
Subject: [PATCH 532/749] add translate in the maintaining balance section 1
 part 4

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 5ea18f6bbd8..88a3e882086 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -44,7 +44,7 @@ Ważne jest, aby zrozumieć, co powoduje nasze wypalenie. Oto kilka wspólnych t
   </p>
 </aside>
 
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **Nie mówienie 'nie':** Łatwo jest wziąć na siebie więcej obowiązków niż jest to konieczne w projekcie open source. Niezależnie od tego, czy chodzi o użytkowników, współpracowników czy innych opiekunów - nie zawsze możemy spełnić ich oczekiwania.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">

From a736fdaa550ed9ad13d14e7d992a48b171fca663 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 12:24:41 +0200
Subject: [PATCH 533/749] add translate in the maintaining balance section 1
 part 5

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 88a3e882086..82d15f7e8d6 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -54,7 +54,7 @@ Ważne jest, aby zrozumieć, co powoduje nasze wypalenie. Oto kilka wspólnych t
   </p>
 </aside>
 
-* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+* **Praca w samotności:** Bycie opiekunem może być niezwykle samotne. Nawet jeśli pracujesz z grupą opiekunów, ostatnie kilka lat było trudne dla osobistego zwoływania rozproszonych zespołów.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">

From 629ac3f69a7b8d486d83f4aa4460690989948c0a Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 12:29:44 +0200
Subject: [PATCH 534/749] add translate in the maintaining balance section 1
 part 6

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 82d15f7e8d6..8fe662a3a65 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -64,7 +64,7 @@ Ważne jest, aby zrozumieć, co powoduje nasze wypalenie. Oto kilka wspólnych t
   </p>
 </aside>
 
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **Niewystarczająca ilość czasu lub zasobów:** Jest to szczególnie prawdziwe w przypadku opiekunów-wolontariuszy, którzy muszą poświęcić swój wolny czas na pracę nad projektem.
 
 <aside markdown="1" class="pquote">
   [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.

From 08b5e61f8e37f86a68bdb5facd256f2782672247 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 12:29:58 +0200
Subject: [PATCH 535/749] add translate in the maintaining balance section 1
 part 7

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 8fe662a3a65..af7d2c36deb 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -73,7 +73,7 @@ Ważne jest, aby zrozumieć, co powoduje nasze wypalenie. Oto kilka wspólnych t
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Sprzeczne oczekiwania:** Open source jest pełne grup o różnych motywacjach, co może być trudne w obsłudze. Jeśli płacą ci za pracę nad open source, interesy twojego pracodawcy mogą być czasami sprzeczne ze społecznością.
 
 <aside markdown="1" class="pquote">
   With paid open source, conflict between employer's focus and what's best for the community

From ac08f9af8ad0a6bc2677aef110a610982da27828 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 12:36:11 +0200
Subject: [PATCH 536/749] add translate in the maintaining balance section 1
 part 8

---
 .../pl/maintaining-balance-for-open-source-maintainers.md     | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index af7d2c36deb..b5c231b45aa 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -82,9 +82,9 @@ Ważne jest, aby zrozumieć, co powoduje nasze wypalenie. Oto kilka wspólnych t
   </p>
 </aside>
 
-### Watch out for signs of burnout
+### Zwróć uwagę na oznaki wypalenia
 
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+Czy jesteś w stanie utrzymać tempo przez 10 tygodni? 10 miesięcy? 10 lat?
 
 There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 

From 05c58c796c131cc5ab775c1c25ee827b1a7ca191 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 12:36:48 +0200
Subject: [PATCH 537/749] add translate in the maintaining balance section 1
 part 9

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index b5c231b45aa..e1e3765874b 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ Ważne jest, aby zrozumieć, co powoduje nasze wypalenie. Oto kilka wspólnych t
 
 Czy jesteś w stanie utrzymać tempo przez 10 tygodni? 10 miesięcy? 10 lat?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+Istnieją narzędzia, takie jak [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) od [@shaunagm](https://github.com/shaunagm) i od Mozilla [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) , które mogą pomóc ci zastanowić się nad twoim obecnym tempem i sprawdzić, czy są jakieś poprawki, które możesz wprowadzić. Niektórzy opiekunowie używają również technologii do monitorowania takich wskaźników jak jakość snu i zmienność tętna (oba powiązane ze stresem).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.

From b3ca060f1bb63d7e0d69a62504d3d67d4f25bf56 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 12:53:20 +0200
Subject: [PATCH 538/749] add translate in the maintaining balance section 1
 part 10

---
 .../pl/maintaining-balance-for-open-source-maintainers.md     | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index e1e3765874b..6eac423190a 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -95,9 +95,9 @@ Istnieją narzędzia, takie jak [Burnout Checklist](https://governingopen.com/re
   </p>
 </aside>
 
-### What would you need to continue sustaining yourself and your community?
+### Czego potrzebujesz, aby utrzymać siebie i swoją społeczność?
 
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+Będzie to wyglądać inaczej dla każdego opiekuna i będzie się zmieniać w zależności od etapu życia i innych czynników zewnętrznych. Ale oto kilka tematów, które usłyszeliśmy:
 
 * **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
 

From cf609e14de6668ca4f2c4305be1b50e036ef8c6e Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 12:57:56 +0200
Subject: [PATCH 539/749] add translate in the maintaining balance section 1
 part 11

---
 .../pl/maintaining-balance-for-open-source-maintainers.md     | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 6eac423190a..5d77e44c07f 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -99,9 +99,9 @@ Istnieją narzędzia, takie jak [Burnout Checklist](https://governingopen.com/re
 
 Będzie to wyglądać inaczej dla każdego opiekuna i będzie się zmieniać w zależności od etapu życia i innych czynników zewnętrznych. Ale oto kilka tematów, które usłyszeliśmy:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **Odciążenie społeczności:** Delegowanie i znajdowanie współpracowników może zmniejszyć obciążenie pracą. Posiadanie wielu osób do kontaktu w sprawie projektu może pomóc ci zrobić sobie przerwę bez zmartwień. Nawiązuj kontakty z innymi opiekunami i szerszą społecznością - w grupach takich jak [Maintainer Community](http://maintainers.github.com/). Może to być świetne źródło wzajemnego wsparcia i nauki.
 
-  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+  Możesz także szukać sposobów na zaangażowanie społeczności użytkowników, aby regularnie otrzymywać informacje zwrotne i zrozumieć znaczenie swojej pracy w open source.
 
 * **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
 

From 7ae6b14f7c7435648c747b0f48ece73d63825ad4 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 13:01:17 +0200
Subject: [PATCH 540/749] add translate in the maintaining balance section 1
 part 12

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 5d77e44c07f..7b82b86a11f 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -103,7 +103,7 @@ Będzie to wyglądać inaczej dla każdego opiekuna i będzie się zmieniać w z
 
   Możesz także szukać sposobów na zaangażowanie społeczności użytkowników, aby regularnie otrzymywać informacje zwrotne i zrozumieć znaczenie swojej pracy w open source.
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **Znajdź finansowanie:** Niezależnie od tego, czy szukasz pieniędzy na pizzę, czy próbujesz przejść na pełny etat open source, istnieje wiele zasobów, które mogą Ci pomóc! Pierwszym krokiem jest włączenie opcji [Sponsorzy GitHub](https://github.com/sponsors), aby umożliwić innym sponsorowanie twojej pracy open source. Jeśli myślisz o przejściu na pełny etat, zgłoś się do następnej rundy [GitHub Accelerator](http://accelerator.github.com/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">

From a1642b0df60c12351f9e00d2690e92051d5a5f26 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 13:44:57 +0200
Subject: [PATCH 541/749] add translate in the maintaining balance section 1
 part 13

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 7b82b86a11f..05a0ed40dfa 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -113,7 +113,7 @@ Będzie to wyglądać inaczej dla każdego opiekuna i będzie się zmieniać w z
   </p>
 </aside>
 
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+* **Korzystaj z narzędzi:** Poznaj narzędzia takie jak [GitHub Copilot](https://github.com/features/copilot/) i [GitHub Actions](https://github.com/features/actions), aby zautomatyzować proste zadania i uwolnić swój czas na bardziej znaczący wkład.
 
 <aside markdown="1" class="pquote">
  Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff

From 19f1b820302f8a257b1efa11c02df220ae4989ab Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 13:48:40 +0200
Subject: [PATCH 542/749] add translate in the maintaining balance section 1
 part 14

---
 .../pl/maintaining-balance-for-open-source-maintainers.md     | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 05a0ed40dfa..053a2df9986 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -122,9 +122,9 @@ Będzie to wyglądać inaczej dla każdego opiekuna i będzie się zmieniać w z
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+* **Odpoczynek i regeneracja:** Znajdź czas na swoje hobby i zainteresowania poza open source. Weź wolne weekendy, aby się zrelaksować i zregenerować - i ustaw swój [status GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status), aby odzwierciedlał twoją dostępność! Dobry sen może mieć duży wpływ na twoją zdolność do utrzymania wysiłków w dłuższej perspektywie.
 
-  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+  Jeśli pewne aspekty projektu sprawiają ci szczególną przyjemność, postaraj się tak zaplanować pracę, abyś mógł doświadczać ich w ciągu dnia.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">

From 24b3787753cfa481e22f69dd6c7527b356a520a0 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 13:51:33 +0200
Subject: [PATCH 543/749] add translate in the maintaining balance section 1
 part 15

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 053a2df9986..b862fa0c34e 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -134,7 +134,7 @@ Będzie to wyglądać inaczej dla każdego opiekuna i będzie się zmieniać w z
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **Wyznacz granice:** Nie możesz zgodzić się na każdą prośbę. Może to być tak proste, jak powiedzenie: "Nie mogę się tym teraz zająć i nie planuję tego w przyszłości" lub wyszczególnienie tego, co chcesz zrobić, a czego nie, w pliku README. Na przykład, można powiedzieć: "Łączę tylko PR-y, które mają jasno wymienione powody, dla których zostały stworzone" lub "Przeglądam sprawy tylko we czwartki od 18:00 do 19:00". Określa to oczekiwania wobec innych i daje ci coś, na co możesz wskazać w innych momentach, aby pomóc zmniejszyć wymagania ze strony współpracowników lub użytkowników dotyczące twojego czasu.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">

From f26d9a0546120dd857d7bc8fa9adcaad9ac14963 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 13:56:53 +0200
Subject: [PATCH 544/749] add translate in the maintaining balance section 1
 part 16

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index b862fa0c34e..cb061346728 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -144,7 +144,7 @@ To meaningfully trust others on these axes, you cannot be someone who says yes t
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+  Naucz się stanowczo odrzucać szkodliwe zachowania i negatywne interakcje. W dobrym tonie jest nie poświęcać energii rzeczom, na których ci nie zależy.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">

From 6d700010f2a2b10992ff834126e59fef13f5a63d Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 14:13:23 +0200
Subject: [PATCH 545/749] add translate in the maintaining balance section 1
 part 17

---
 _articles/pl/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index cb061346728..6a8f54ddf0c 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -162,7 +162,7 @@ It's no secret that open source maintenance has its dark sides, and one of these
   </p>
 </aside>
 
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+Pamiętaj, że ekologia osobista to ciągła praktyka, która będzie ewoluować w miarę postępów w podróży open source. Traktując priorytetowo dbanie o siebie i utrzymywanie poczucia równowagi, możesz wnieść swój wkład w społeczność open source w sposób skuteczny i zrównoważony, zapewniając zarówno dobre samopoczucie, jak i sukces swoich projektów na dłuższą metę.
 
 ## Additional Resources
 

From 08d1176f6c1c0870607e19b39d1960599e69a0a6 Mon Sep 17 00:00:00 2001
From: Aman Prakash <futureofaman@gmail.com>
Date: Fri, 8 Sep 2023 19:45:44 +0530
Subject: [PATCH 546/749] Update best-practices.md

Fixed grammatical error in one line and typos in another line.
Silly ones
---
 _articles/best-practices.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/best-practices.md b/_articles/best-practices.md
index 01895803615..e842f33af14 100644
--- a/_articles/best-practices.md
+++ b/_articles/best-practices.md
@@ -134,7 +134,7 @@ To reduce the volume of unwanted contributions in the first place, explain your
 
 If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example:
 
-* Fill out a issue or PR template/checklist
+* Fill out an issue or PR template/checklist
 * Open an issue before submitting a PR
 
 If they don't follow your rules, close the issue immediately and point to your documentation.
@@ -173,7 +173,7 @@ Encouraging others to [share ownership of the project](../building-community/#sh
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
-  I’d been saying, "Yeah, anyone can be involved, you don’t have to have a lot of coding expertise [...]." We had people sign up to come [to an event] and that’s when I was really wondering: is this true, what I’ve been saying? There are gonna be 40 people who show up, and it’s not like I can sit with each of them...But people came together, and it just sort of worked. As soon as one person got it, they could teach their neighbor.
+  I’d been saying, "Yeah, anyone can be involved, you don’t have to have a lot of coding expertise [...]." We had people sign up to come [to an event] and that’s when I was really wondering: is this true, what I’ve been saying? There are gonna be 40 people who show up, and it’s not like I can sit with each of them...But people came together, and it just sort of worked. As soon as one person got it, they could teach their neighbour.
   <p markdown="1" class="pquote-credit">
 —  @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
   </p>

From de3e50f762260091c55e6e332fe6f0235568fbea Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 22:06:46 +0200
Subject: [PATCH 547/749] add translate in the maintaining balance section 2

---
 ...ning-balance-for-open-source-maintainers.md | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 6a8f54ddf0c..04507780ead 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -164,18 +164,18 @@ It's no secret that open source maintenance has its dark sides, and one of these
 
 Pamiętaj, że ekologia osobista to ciągła praktyka, która będzie ewoluować w miarę postępów w podróży open source. Traktując priorytetowo dbanie o siebie i utrzymywanie poczucia równowagi, możesz wnieść swój wkład w społeczność open source w sposób skuteczny i zrównoważony, zapewniając zarówno dobre samopoczucie, jak i sukces swoich projektów na dłuższą metę.
 
-## Additional Resources
+## Dodatkowe materiały
 
-* [Maintainer Community](http://maintainers.github.com/)
-* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Społeczność opiekunów](http://maintainers.github.com/)
+* [Umowa społeczna open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
-* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [Jak radzić sobie z toksycznymi ludźmi](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
-* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
-* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
-* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+* [Zestaw do samooceny ekologii osobistej](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Sztuka przywództwa](https://rockwoodleadership.org/art-of-leadership/), Rockwood
+* [Mówienie "nie"](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Otwartość zarządzania](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Program warsztatów został zaczerpnięty z serii [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org)
 
 ## Contributors
 

From 7e96fee8b6de64096f683930736ac6eabcb8c527 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 22:09:34 +0200
Subject: [PATCH 548/749] add translate in the maintaining balance section 3

---
 .../pl/maintaining-balance-for-open-source-maintainers.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index 04507780ead..bc1894fcfde 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -177,11 +177,11 @@ Pamiętaj, że ekologia osobista to ciągła praktyka, która będzie ewoluować
 * [Otwartość zarządzania](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
 * Program warsztatów został zaczerpnięty z serii [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org)
 
-## Contributors
+## Współtwórcy
 
-Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+Bardzo dziękujemy wszystkim opiekunom, którzy podzielili się z nami swoimi doświadczeniami i wskazówkami na potrzeby tego przewodnika!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+Ten przewodnik został napisany przez [@abbycabs](https://github.com/abbycabs) z wkładem od:
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
@@ -218,4 +218,4 @@ This guide was written by [@abbycabs](https://github.com/abbycabs) with contribu
 [@thisisnic](https://github.com/thisisnic)
 [@tudoramariei](https://github.com/tudoramariei)
 [@UlisesGascon](https://github.com/UlisesGascon)
-[@waldyrious](https://github.com/waldyrious) + many others!
+[@waldyrious](https://github.com/waldyrious) + wiele innych osób!

From 594873f61e67bed9359ddd4025adfaaf15be31a1 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Fri, 8 Sep 2023 23:57:02 +0200
Subject: [PATCH 549/749] add translate.scss file

---
 assets/css/translate.scss | 40 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100644 assets/css/translate.scss

diff --git a/assets/css/translate.scss b/assets/css/translate.scss
new file mode 100644
index 00000000000..099136eb3c2
--- /dev/null
+++ b/assets/css/translate.scss
@@ -0,0 +1,40 @@
+// Translation results of " Section x" in articles
+// Autor: Olsza
+// License: CC-BY-4.0
+
+// Enter the locale code and the translation of "Section" in the language.
+// The country code should be the same as the value of the lang attribute in html (use "-" instead of "_")
+$section_translation: (
+        "de": "",
+        "el": "",
+        "en": "",
+        "es": "",
+        "fa": "",
+        "fr": "",
+        "hu": "",
+        "id": "",
+        "ja": "",
+        "ko": "",
+        "ms": "",
+        "nl": "",
+        "pl": "Rozdział",
+        "pt": "",
+        "ro": "",
+        "ru": "",
+        "ta": "",
+        "tr": "",
+        "zh-hant": "",
+        "zh-hans": "",
+);
+
+@each $locale, $translation in $section_translation {
+  @if $translation != "" {
+    html[lang="#{$locale}"] .article-body {
+      @for $i from 1 through 9 {
+        h2:nth-of-type(#{$i}):before {
+          content: "#{$translation} #{$i}";
+        }
+      }
+    }
+  }
+}

From 54561a7ed466be4180ab9ba555f0f791b455c027 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Sat, 9 Sep 2023 00:00:41 +0200
Subject: [PATCH 550/749] add import translate.scss in index.scss

---
 assets/css/index.scss | 1 +
 1 file changed, 1 insertion(+)

diff --git a/assets/css/index.scss b/assets/css/index.scss
index bdd5da214f7..f554fa66473 100644
--- a/assets/css/index.scss
+++ b/assets/css/index.scss
@@ -11,3 +11,4 @@ $marketing-font-path: "/assets/fonts/";
 @import "covers.scss";
 @import "anchor.scss";
 @import "button.scss";
+@import "translate.scss";

From 10e52247bda8bb28becffc39479b729300dab3c4 Mon Sep 17 00:00:00 2001
From: omahs <73983677+omahs@users.noreply.github.com>
Date: Sat, 9 Sep 2023 08:10:18 +0200
Subject: [PATCH 551/749] fix anchor link

---
 _articles/fr/building-community.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fr/building-community.md b/_articles/fr/building-community.md
index 95c2531f6b4..1dec5be76ab 100644
--- a/_articles/fr/building-community.md
+++ b/_articles/fr/building-community.md
@@ -192,7 +192,7 @@ Pour la plupart, si vous avez cultivé une communauté amicale et respectueuse e
 
 Lorsque votre communauté est aux prises avec un problème difficile, la colère peut monter. Les gens peuvent devenir fâchés ou frustrés et s'en prendre à un autre ou à vous.
 
-Votre travail en tant que mainteneur consiste à éviter l'escalade de ces situations. Même si vous avez une opinion forte sur le sujet, essayez de prendre la position d'un modérateur ou d'un facilitateur, plutôt que de vous jeter dans la bagarre et de faire valoir vos points de vue. Si quelqu'un est méchant ou accapare la conversation, [agissez immédiatement](../building-community/#ne-tol&egrave;rez-pas-les-mauvais-acteurs) pour garder les discussions civiles et productives.
+Votre travail en tant que mainteneur consiste à éviter l'escalade de ces situations. Même si vous avez une opinion forte sur le sujet, essayez de prendre la position d'un modérateur ou d'un facilitateur, plutôt que de vous jeter dans la bagarre et de faire valoir vos points de vue. Si quelqu'un est méchant ou accapare la conversation, [agissez immédiatement](../building-community/#ne-tolérez-pas-les-mauvais-acteurs) pour garder les discussions civiles et productives.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">

From 0cb671943f060277a8b7a9d34698c7bb7db2bc53 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= <ulisesgascongonzalez@gmail.com>
Date: Sat, 9 Sep 2023 14:45:53 +0200
Subject: [PATCH 552/749] fix: remove broken link

---
 _articles/de/how-to-contribute.md | 1 -
 _articles/el/how-to-contribute.md | 1 -
 _articles/es/how-to-contribute.md | 1 -
 _articles/fa/how-to-contribute.md | 1 -
 _articles/fr/how-to-contribute.md | 1 -
 _articles/how-to-contribute.md    | 1 -
 _articles/hu/how-to-contribute.md | 1 -
 _articles/id/how-to-contribute.md | 1 -
 _articles/ja/how-to-contribute.md | 1 -
 _articles/ko/how-to-contribute.md | 1 -
 _articles/ms/how-to-contribute.md | 1 -
 _articles/nl/how-to-contribute.md | 1 -
 _articles/pl/how-to-contribute.md | 1 -
 _articles/pt/how-to-contribute.md | 1 -
 _articles/ro/how-to-contribute.md | 1 -
 _articles/ru/how-to-contribute.md | 1 -
 _articles/tr/how-to-contribute.md | 1 -
 17 files changed, 17 deletions(-)

diff --git a/_articles/de/how-to-contribute.md b/_articles/de/how-to-contribute.md
index 07a283b05e7..6dc1ed10d40 100644
--- a/_articles/de/how-to-contribute.md
+++ b/_articles/de/how-to-contribute.md
@@ -231,7 +231,6 @@ Weiterhin, können Sie auf folgenden Seiten neue Projekte zum Beitragen entdecke
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/el/how-to-contribute.md b/_articles/el/how-to-contribute.md
index e63ec27bd4c..e82a9d922c0 100644
--- a/_articles/el/how-to-contribute.md
+++ b/_articles/el/how-to-contribute.md
@@ -211,7 +211,6 @@ related:
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/es/how-to-contribute.md b/_articles/es/how-to-contribute.md
index d6ba5d58d41..25c330fd3f7 100644
--- a/_articles/es/how-to-contribute.md
+++ b/_articles/es/how-to-contribute.md
@@ -207,7 +207,6 @@ Puedes tambi&eacute;n utilizar algunos de los siguientes recursos para ayudarte
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 6bfdf1ffb77..d78fbdb7c8b 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -214,7 +214,6 @@ related:
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://www.sourcesort.com/)
 
diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md
index 79d9c25edf3..a9e2939e919 100644
--- a/_articles/fr/how-to-contribute.md
+++ b/_articles/fr/how-to-contribute.md
@@ -207,7 +207,6 @@ Vous pouvez également utiliser l'une des ressources suivantes pour vous aider 
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 17a04ad9821..bd1ae3d6a5a 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -213,7 +213,6 @@ You can also use one of the following resources to help you discover and contrib
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/hu/how-to-contribute.md b/_articles/hu/how-to-contribute.md
index e7be38930e1..0b8e185cef2 100644
--- a/_articles/hu/how-to-contribute.md
+++ b/_articles/hu/how-to-contribute.md
@@ -209,7 +209,6 @@ Az alábbiakban találsz néhány oldalt, amelyek segítenek abban, hogy felfede
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/id/how-to-contribute.md b/_articles/id/how-to-contribute.md
index b3d2cb2c763..6e25291ca99 100644
--- a/_articles/id/how-to-contribute.md
+++ b/_articles/id/how-to-contribute.md
@@ -207,7 +207,6 @@ Anda juga bisa menggunakan salah satu dari beberapa sumber daya berikut untuk me
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md
index dfecc9a1157..3b95817e956 100644
--- a/_articles/ja/how-to-contribute.md
+++ b/_articles/ja/how-to-contribute.md
@@ -207,7 +207,6 @@ README を読んで、壊れたリンクやタイポを見つけるかもしれ
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md
index 58ab9493e0c..d775b1dbb66 100644
--- a/_articles/ko/how-to-contribute.md
+++ b/_articles/ko/how-to-contribute.md
@@ -209,7 +209,6 @@ README를 스캔하여 깨진 링크나 오타를 찾을 수 있습니다. 또
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
index ea1bc6af630..285de934529 100644
--- a/_articles/ms/how-to-contribute.md
+++ b/_articles/ms/how-to-contribute.md
@@ -213,7 +213,6 @@ Anda juga boleh menggunakan salah satu sumber berikut untuk membantu anda menemu
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md
index 4d561689084..cc07950d858 100644
--- a/_articles/nl/how-to-contribute.md
+++ b/_articles/nl/how-to-contribute.md
@@ -221,7 +221,6 @@ U kunt ook een van de volgende bronnen gebruiken om u te helpen bij het ontdekke
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index 399cd50af2f..fd9c07fb69c 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -221,7 +221,6 @@ Możesz także skorzystać z jednego z następujących zasobów, aby pomóc ci o
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md
index e6ee8a1c380..efad946eb21 100644
--- a/_articles/pt/how-to-contribute.md
+++ b/_articles/pt/how-to-contribute.md
@@ -207,7 +207,6 @@ Você também pode usar um dos seguintes recursos para ajudá-lo a descobrir e c
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/ro/how-to-contribute.md b/_articles/ro/how-to-contribute.md
index ed1a435c010..3c2fcb95ebf 100644
--- a/_articles/ro/how-to-contribute.md
+++ b/_articles/ro/how-to-contribute.md
@@ -237,7 +237,6 @@ Poți de asemenea folosi una dintre următoarele resurse pentru a te ajuta să d
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index ddef7a39287..581fb52138d 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -213,7 +213,6 @@ related:
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 
diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md
index e97b7d07903..189f26e183e 100644
--- a/_articles/tr/how-to-contribute.md
+++ b/_articles/tr/how-to-contribute.md
@@ -213,7 +213,6 @@ Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aş
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 

From b6f7a6b5275814113317dea82a22373bf45e70c4 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Wed, 13 Sep 2023 07:56:30 +0200
Subject: [PATCH 553/749] Update translate for EN & ES
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Ulises Gascón <ulisesgascongonzalez@gmail.com>
---
 assets/css/translate.scss | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/assets/css/translate.scss b/assets/css/translate.scss
index 099136eb3c2..f2e711f075b 100644
--- a/assets/css/translate.scss
+++ b/assets/css/translate.scss
@@ -7,8 +7,8 @@
 $section_translation: (
         "de": "",
         "el": "",
-        "en": "",
-        "es": "",
+        "en": "section",
+        "es": "sección",
         "fa": "",
         "fr": "",
         "hu": "",

From efd6cc9b0ca545aa67f2250b43058f82ed2be6df Mon Sep 17 00:00:00 2001
From: Christine Belzie <shecoder30@gmail.com>
Date: Wed, 13 Sep 2023 20:56:28 -0400
Subject: [PATCH 554/749] fix: making revisions to how to contribute guide

---
 _articles/how-to-contribute.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index bd1ae3d6a5a..b3a7af95503 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -87,11 +87,11 @@ Even if you like to write code, other types of contributions are a great way to
 
 ### Do you like to write?
 
-* Write and improve the project's documentation
+* Write and improve the project's documentation, like [CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
 * Curate a folder of examples showing how the project is used
 * Start a newsletter for the project, or curate highlights from the mailing list
 * Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
-* Write a translation for the project's documentation
+* Write a translation for the project's documentation, like [frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">

From 92d72beb8d39c64fb7e6d24526633c007c0d855c Mon Sep 17 00:00:00 2001
From: Christine Belzie <shecoder30@gmail.com>
Date: Wed, 13 Sep 2023 21:16:51 -0400
Subject: [PATCH 555/749] feat: add another example of a contribution

---
 _articles/how-to-contribute.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index b3a7af95503..64bf474cf9e 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -87,11 +87,11 @@ Even if you like to write code, other types of contributions are a great way to
 
 ### Do you like to write?
 
-* Write and improve the project's documentation, like [CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
+* Write and improve the project's documentation, like [@CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
 * Curate a folder of examples showing how the project is used
-* Start a newsletter for the project, or curate highlights from the mailing list
+* Start a newsletter for the project, or curate highlights from the mailing list, like [@opensauced did for their product](https://news.opensauced.pizza/about/)
 * Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
-* Write a translation for the project's documentation, like [frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
+* Write a translation for the project's documentation, like [@frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">

From eb05f62a7efca3f0dcf7b8d75d6a1e08346a933e Mon Sep 17 00:00:00 2001
From: Christine Belzie <shecoder30@gmail.com>
Date: Wed, 13 Sep 2023 21:17:26 -0400
Subject: [PATCH 556/749] fix: revise sentence

---
 _articles/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 64bf474cf9e..6153b5f8e48 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -89,7 +89,7 @@ Even if you like to write code, other types of contributions are a great way to
 
 * Write and improve the project's documentation, like [@CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
 * Curate a folder of examples showing how the project is used
-* Start a newsletter for the project, or curate highlights from the mailing list, like [@opensauced did for their product](https://news.opensauced.pizza/about/)
+* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/)
 * Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
 * Write a translation for the project's documentation, like [@frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
 

From 52a7af5888e360d60341502121b163496eaac821 Mon Sep 17 00:00:00 2001
From: Christine Belzie <shecoder30@gmail.com>
Date: Wed, 13 Sep 2023 21:18:46 -0400
Subject: [PATCH 557/749] fix: revise first sentence in Do you like to write
 subsection

---
 _articles/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 6153b5f8e48..acbe2e5554b 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -87,7 +87,7 @@ Even if you like to write code, other types of contributions are a great way to
 
 ### Do you like to write?
 
-* Write and improve the project's documentation, like [@CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
+* Write and improve the project's documentation,[like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
 * Curate a folder of examples showing how the project is used
 * Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/)
 * Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)

From d0137865366974018754d3667c5061fd41432d82 Mon Sep 17 00:00:00 2001
From: Christine Belzie <shecoder30@gmail.com>
Date: Wed, 13 Sep 2023 21:21:06 -0400
Subject: [PATCH 558/749] fix: revise last point

---
 _articles/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index acbe2e5554b..6fd16765e99 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -91,7 +91,7 @@ Even if you like to write code, other types of contributions are a great way to
 * Curate a folder of examples showing how the project is used
 * Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/)
 * Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
-* Write a translation for the project's documentation, like [@frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
+* Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">

From 3ba7e06e01f6ae9052c846cf40d76b99b9f25d13 Mon Sep 17 00:00:00 2001
From: Christine Belzie <shecoder30@gmail.com>
Date: Thu, 14 Sep 2023 21:09:50 -0400
Subject: [PATCH 559/749] feat: hyperlink names of quoted individuals

---
 _articles/how-to-contribute.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 6fd16765e99..bff3bac5ab8 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
   Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
   <p markdown="1" class="pquote-credit">
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— [@errietta](https://github.com/errietta), ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
   </p>
 </aside>
 
@@ -66,7 +66,7 @@ A common misconception about contributing to open source is that you need to con
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
   I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
   <p markdown="1" class="pquote-credit">
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— [@orta](https://github.com/orta), ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
   </p>
 </aside>
 
@@ -502,7 +502,7 @@ If you make a polite bump and still nobody responds, it's possible that nobody w
 
 It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
 
-When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it.
+When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). 
 
 If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
 

From 9bd1f2a2badefd3fb589a1273f1b45954fc4e3a1 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Sat, 16 Sep 2023 17:02:42 +0200
Subject: [PATCH 560/749] Update translate for FR

Co-authored-by: Christine Belzie <105683440+CBID2@users.noreply.github.com>
---
 assets/css/translate.scss | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/assets/css/translate.scss b/assets/css/translate.scss
index f2e711f075b..bcb43786141 100644
--- a/assets/css/translate.scss
+++ b/assets/css/translate.scss
@@ -10,7 +10,7 @@ $section_translation: (
         "en": "section",
         "es": "sección",
         "fa": "",
-        "fr": "",
+        "fr": "partie",
         "hu": "",
         "id": "",
         "ja": "",

From 7372ba7aea6457b67b826b083f06694553ee3dbf Mon Sep 17 00:00:00 2001
From: Christine Belzie <shecoder30@gmail.com>
Date: Sat, 16 Sep 2023 15:35:09 -0400
Subject: [PATCH 561/749] feat: add more examples

---
 _articles/how-to-contribute.md | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index bff3bac5ab8..1534bdbe3c6 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -174,16 +174,16 @@ A project also has documentation. These files are usually listed in the top leve
 
 * **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
 * **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
-* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
+* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).  
 * **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
-* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.
+* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
 
 Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
 
-* **Issue tracker:** Where people discuss issues related to the project.
-* **Pull requests:** Where people discuss and review changes that are in progress.
-* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
-* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
+* **Issue tracker:** Where people discuss issues related to the project.  
+* **Pull requests:** Where people discuss and review changes that are in progress whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), use certain GitHub Action flows to automate and quicken their code reviews.  
+* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/)
+* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/).
 
 ## Finding a project to contribute to
 
@@ -201,7 +201,7 @@ Open source isn't an exclusive club; it's made by people just like you. "Open so
 
 You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
 
-> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+> According to a study conducted by Igor Steinmacher and other Computer Science researchers,[28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as  typo fixes, reformatting, or writing a translation.
 
 If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
 
@@ -215,6 +215,7 @@ You can also use one of the following resources to help you discover and contrib
 * [Up For Grabs](https://up-for-grabs.net/)
 * [First Contributions](https://firstcontributions.github.io)
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://opensauced.pizza/)
 
 ### A checklist before you contribute
 
@@ -233,7 +234,7 @@ Here's a handy checklist to evaluate whether a project is good for new contribut
 
 **Project actively accepts contributions**
 
-Look at the commit activity on the main branch. On GitHub, you can see this information on a repository's homepage.
+Look at the commit activity on the main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as[Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">

From 4f4e69630b998ff88fdd32f1534f1b4ce1bcee65 Mon Sep 17 00:00:00 2001
From: Christine Belzie <shecoder30@gmail.com>
Date: Fri, 22 Sep 2023 20:44:40 -0400
Subject: [PATCH 562/749] fix: revise sentences and add more examples

---
 _articles/how-to-contribute.md | 36 ++++++++++++++++------------------
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 1534bdbe3c6..271b2b68381 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -431,11 +431,11 @@ Before you open an issue or pull request, or ask a question in chat, keep these
 
 Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
 
-If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request:
+If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by doing the following:
 
-* **Issues** are like starting a conversation or discussion
-* **Pull requests** are for starting work on a solution
-* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one
+* **Raising an Issue:** These are like starting a conversation or discussion
+* **Pull requests** are for starting work on a solution.
+* **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution.
 
 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.
 
@@ -467,10 +467,10 @@ Tips for communicating on issues:
 
 You should usually open a pull request in the following situations:
 
-* Submit trivial fixes (for example, a typo, a broken link or an obvious error)
-* Start work on a contribution that was already asked for, or that you've already discussed, in an issue
+* Submit small fixes such a typo, a broken link or an obvious error.
+* Start work on a contribution that was already asked for, or that you've already discussed, in an issue.
 
-A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
+A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later.
 
 If the project is on GitHub, here's how to submit a pull request:
 
@@ -478,18 +478,16 @@ If the project is on GitHub, here's how to submit a pull request:
 * **[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.
-* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
+* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. It's important to make sure your changes don't break the existing project.
 * **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
 
 If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
 
-## What happens after you submit a contribution
+## What happens after you submit your contribution
 
-You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
+Before we start celebrating, one of the following will happen after you submit your contribution:
 
-After you submit a contribution, one of the following will happen:
-
-### 😭 You don't get a response.
+### 😭 You don't get a response
 
 Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
 
@@ -497,24 +495,24 @@ If you haven't gotten a response in over a week, it's fair to politely respond i
 
 **Don't** reach out to that person privately; remember that public communication is vital to open source projects.
 
-If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+If you give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
 
-### 🚧 Someone requests changes to your contribution.
+### 🚧 Someone requests changes to your contribution
 
 It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
 
 When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). 
 
-If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
+If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).
 
-### 👎 Your contribution doesn't get accepted.
+### 👎 Your contribution doesn't get accepted
 
 Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
 
-### 🎉 Your contribution gets accepted.
+### 🎉 Your contribution gets accepted
 
 Hooray! You've successfully made an open source contribution!
 
-## You did it!
+## You did it! 🎉
 
 Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.

From c04cd4a018b150e1498f525466c974a1c0aeff25 Mon Sep 17 00:00:00 2001
From: Christine Belzie <shecoder30@gmail.com>
Date: Fri, 22 Sep 2023 20:48:31 -0400
Subject: [PATCH 563/749] fix: revise formatting

---
 _articles/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 271b2b68381..22271a9d58e 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -493,7 +493,7 @@ Hopefully you [checked the project for signs of activity](#a-checklist-before-yo
 
 If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
 
-**Don't** reach out to that person privately; remember that public communication is vital to open source projects.
+**Don't reach out to that person privately**; remember that public communication is vital to open source projects.
 
 If you give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
 

From ce518ab1e77c262f55f6466d15b738248c944c81 Mon Sep 17 00:00:00 2001
From: Christine Belzie <105683440+CBID2@users.noreply.github.com>
Date: Sat, 23 Sep 2023 17:46:14 -0400
Subject: [PATCH 564/749] fix: remove trailing whitespace

Co-authored-by: Olsza <olsza@users.noreply.github.com>
---
 _articles/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 22271a9d58e..6e65ac964b9 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -501,7 +501,7 @@ If you give a polite reminder and still do not receive a response, it's possible
 
 It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
 
-When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). 
+When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286).
 
 If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).
 

From 5e61de612690d6938314a11a772461035fb38ab7 Mon Sep 17 00:00:00 2001
From: Christine Belzie <105683440+CBID2@users.noreply.github.com>
Date: Sat, 23 Sep 2023 17:46:55 -0400
Subject: [PATCH 565/749] fix: remove trailing whitespace part 2

Co-authored-by: Olsza <olsza@users.noreply.github.com>
---
 _articles/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 6e65ac964b9..cfbb476355c 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -180,7 +180,7 @@ A project also has documentation. These files are usually listed in the top leve
 
 Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
 
-* **Issue tracker:** Where people discuss issues related to the project.  
+* **Issue tracker:** Where people discuss issues related to the project.
 * **Pull requests:** Where people discuss and review changes that are in progress whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), use certain GitHub Action flows to automate and quicken their code reviews.  
 * **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/)
 * **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/).

From fc98f6b37fa6012c8a64518b983b20637ec27667 Mon Sep 17 00:00:00 2001
From: Christine Belzie <105683440+CBID2@users.noreply.github.com>
Date: Sat, 23 Sep 2023 17:47:13 -0400
Subject: [PATCH 566/749] fix: remove trailing whitespace part 3

Co-authored-by: Olsza <olsza@users.noreply.github.com>
---
 _articles/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index cfbb476355c..a46e9b53afa 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -174,7 +174,7 @@ A project also has documentation. These files are usually listed in the top leve
 
 * **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
 * **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
-* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).  
+* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).
 * **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
 * **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
 

From f40d931ba95487207ca39785c0d5f77ff2e221d1 Mon Sep 17 00:00:00 2001
From: Vincent Picavet <vpicavet@users.noreply.github.com>
Date: Mon, 25 Sep 2023 13:09:57 +0200
Subject: [PATCH 567/749] Update legal.md

Some fixes on french translation - legal page.
---
 _articles/fr/legal.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index 4eae765f715..3f727c76559 100644
--- a/_articles/fr/legal.md
+++ b/_articles/fr/legal.md
@@ -28,11 +28,11 @@ 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ée** ou **public**.
+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**.
 
 ![Créer un référentiel](/assets/images/legal/repo-create-name.png)
 
-**Rendre public votre projet GitHub n'est pas la même chose que la licence de votre projet.** Les projets publics sont couverts par les [Conditions d'utilisation de GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ce qui permet aux autres de voir et de forker votre projet, mais votre travail n'est pas autorisé.
+**Rendre public votre projet GitHub est différent d'appliquer une licence à votre projet.** Les projets publics sont couverts par les [Conditions d'utilisation de GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ce qui permet aux autres de voir et de forker votre projet, mais par défaut aucune permission ne leur est accordé sur votre travail.
 
 Si vous souhaitez que d'autres personnes utilisent, distribuent, modifient ou contribuent à votre projet, vous devez inclure une licence open source. Par exemple, quelqu'un ne peut légalement utiliser aucune partie de votre projet GitHub dans son code, même s'il est public, à moins que vous ne lui donniez explicitement le droit de le faire.
 

From 97ddfa90d1cec8d11005eb9bdb452d965c53b474 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Tue, 26 Sep 2023 10:20:37 +0200
Subject: [PATCH 568/749] refactoring - character correction

Co-authored-by: Rik Smale <13023439+WikiRik@users.noreply.github.com>
---
 assets/css/translate.scss | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/assets/css/translate.scss b/assets/css/translate.scss
index bcb43786141..8f964d664ab 100644
--- a/assets/css/translate.scss
+++ b/assets/css/translate.scss
@@ -7,10 +7,10 @@
 $section_translation: (
         "de": "",
         "el": "",
-        "en": "section",
-        "es": "sección",
+        "en": "Section",
+        "es": "Sección",
         "fa": "",
-        "fr": "partie",
+        "fr": "Partie",
         "hu": "",
         "id": "",
         "ja": "",

From a8b48496c4456ca0a35a61ec6f013bf74df4434f Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Tue, 26 Sep 2023 10:21:40 +0200
Subject: [PATCH 569/749] Update translate for DE

Co-authored-by: Tobias Hagemann <tobias.hagemann@gmail.com>
---
 assets/css/translate.scss | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/assets/css/translate.scss b/assets/css/translate.scss
index 8f964d664ab..4e801a32f1a 100644
--- a/assets/css/translate.scss
+++ b/assets/css/translate.scss
@@ -5,7 +5,7 @@
 // Enter the locale code and the translation of "Section" in the language.
 // The country code should be the same as the value of the lang attribute in html (use "-" instead of "_")
 $section_translation: (
-        "de": "",
+        "de": "Abschnitt",
         "el": "",
         "en": "Section",
         "es": "Sección",

From 57eeada9fc9a3048ad057c06934fdba2503291fe Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Tue, 26 Sep 2023 10:26:38 +0200
Subject: [PATCH 570/749] Update translate for NL

Co-authored-by: Rik Smale <13023439+WikiRik@users.noreply.github.com>
---
 assets/css/translate.scss | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/assets/css/translate.scss b/assets/css/translate.scss
index 4e801a32f1a..044308cb46b 100644
--- a/assets/css/translate.scss
+++ b/assets/css/translate.scss
@@ -16,7 +16,7 @@ $section_translation: (
         "ja": "",
         "ko": "",
         "ms": "",
-        "nl": "",
+        "nl": "Sectie",
         "pl": "Rozdział",
         "pt": "",
         "ro": "",

From 8a8bec978985766602b4257bbb5522c349d8353c Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Wed, 27 Sep 2023 09:40:42 +0200
Subject: [PATCH 571/749] Update translate for EO

Co-authored-by: Colin Dean <colindean@users.noreply.github.com>
---
 assets/css/translate.scss | 1 +
 1 file changed, 1 insertion(+)

diff --git a/assets/css/translate.scss b/assets/css/translate.scss
index 044308cb46b..4c0e8a99a20 100644
--- a/assets/css/translate.scss
+++ b/assets/css/translate.scss
@@ -8,6 +8,7 @@ $section_translation: (
         "de": "Abschnitt",
         "el": "",
         "en": "Section",
+        "eo": "Sekcio",
         "es": "Sección",
         "fa": "",
         "fr": "Partie",

From ae5544f4c555b91317dc20db8670e3ca68a6548b Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Wed, 27 Sep 2023 09:59:18 +0200
Subject: [PATCH 572/749] delete the non-existent yourfirstpr.github.io page in
 ZH-hant

---
 _articles/zh-hant/how-to-contribute.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md
index eb09d712faf..a74d706c7a3 100644
--- a/_articles/zh-hant/how-to-contribute.md
+++ b/_articles/zh-hant/how-to-contribute.md
@@ -204,7 +204,6 @@ redirect_from: /zh-tw/how-to-contribute/
 
 * [GitHub 探索](https://github.com/explore/)
 * [First Timers Only](http://www.firsttimersonly.com/)
-* [你的第一個 PR](https://yourfirstpr.github.io/)
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](http://up-for-grabs.net/)

From 2de7ba39d232add7e1ef81bfb9344665d8a44d7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= <ulisesgascongonzalez@gmail.com>
Date: Wed, 27 Sep 2023 13:21:32 +0200
Subject: [PATCH 573/749] docs: improved installation steps

---
 CONTRIBUTING.md | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d4c334a2ac6..b617f5a54e2 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -49,10 +49,21 @@ If you're writing content, see the [style guide](./docs/styleguide.md) to help y
 
 This site is powered by [Jekyll](https://jekyllrb.com/). Running it on your local machine requires a working [Ruby](https://www.ruby-lang.org/en/) installation with [Bundler](https://bundler.io/).
 
-Once you have that set up, run:
+Once you have that set up:
 
-    script/bootstrap
-    script/server
+1. Grant execution permissions to the scripts:
+
+```bash
+chmod +x script/bootstrap
+chmod +x script/server
+```
+
+2. Execute the scripts:
+
+```bash
+./script/bootstrap
+./script/server
+```
 
 …and open <http://localhost:4000> in your web browser.
 

From 929218c2fb75ec967c521e735d4ff56f5194bcf8 Mon Sep 17 00:00:00 2001
From: Ulises Gascon <ulisesgascongonzalez@gmail.com>
Date: Wed, 27 Sep 2023 13:36:51 +0200
Subject: [PATCH 574/749] feat: add John F.  Kennedy image

Image generated from Wikimedia: https://upload.wikimedia.org/wikipedia/commons/c/c3/John_F._Kennedy%2C_White_House_color_photo_portrait.jpg
---
 assets/images/how-to-contribute/johnfkennedy.jpg | Bin 0 -> 6269 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 assets/images/how-to-contribute/johnfkennedy.jpg

diff --git a/assets/images/how-to-contribute/johnfkennedy.jpg b/assets/images/how-to-contribute/johnfkennedy.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..28e670fcc916855c6da58a126d7d875f1aef336e
GIT binary patch
literal 6269
zcmbW)XEYqly8!T27x5~w1W}{g=)DtG?`3s~-X(}m)F>OhCInGe_mb6@Bs$UU>d{Lq
z5pDHy^Zx($+<VUbbnkuU%zT;W%$eVr5A!_tbN8zN3QbiFRR9hS0D$vn0PgPqGRlS!
zC1X89X%=S(KDSqn&Mf{y{DLgpe!i|=&MX?5YAl-i5H%KmabcdPEZ%;$9<Hy0SmanF
z1xfA~0m=YEd;&rOd_qD3LLiWkh=hWKgqWBFL`F_Z@d!jq`v^osL(j;;O#hgTfrf_V
zDGM7X7Y{EF9W$RGAGaU}HxKtehu{E#KoTMnDiRVZZh9Je?*DV#e+5ty0T2KL9?la0
zE+q~gCC+^>fcX!S0Owx;_|L$>#rtz#AQ3UigFgvP6aZWtJUm={JOToI{6E=YfA#_R
zlmri1g_H=X3~Yf<yg|Z|X+=bA&l<i_8%`dwi`e-@5tGn7qNStf;N;@w;T07Vmync_
zR#t(is;O&e8X22FP0h?L>>V7PoLyYqd|&(d2LuKMN5{O4jf+o!rDtSjW#_#AkXu|*
zT2>CPsH|%IjA&|ZX>Duo?&<C89~c}Oo|;CXXJ+T-7uMD{Hn+BSe(qw9j!#apXXh7}
zSO2(h0C@jq{aODF`yVdKKQ3H+d^~*MKQ0{HfIkzD5}$xoi14A30npZ)>WOe95$IW3
zQNuT4HW9-^YCE4v5*l{VHIAcyX#bM^?_g2?FWG;={@b+xAjQM^^LTia00ltP(Ms=^
z#Uso3)TjE*s$?3YL7;~RioR1F;UKOB(ev?g_c2d)1>v2ddT6JZPH9SBH_Fd$i*F?5
zQD5`Al#Elpe}K!o(`tF%=fXqJTdSsS7AWM=-#yKL_ALvsPpo(qkbkP4IX+MoODk=;
z(TYE-ZU){mj*2xB3j}3)E=m{4W3$#DtyFl=LCYe31aCL^DR&rzyA6jhg1T6n?*XBv
zI&1DHFYD(wS6@<(E((l8Yu}gMXd|hmYS=Hs4*CyMWKki7L4kIjSK4Ic#>~TQ*Fht9
zPaPGy!7^*ANHKEKe!AF;S>SO6k|&TKX&)$(52vmQK<&L=5_mLGxB;X&Q=3w<X3Be2
zq8=$Mf-n_2N;k0#ku6BaGnSR9efPb!cCrx!HAQ@w9vW8)VjRZSMe8xQQ;%~QSTjcS
zKC4nA)iOpzeI(F$276ULjnda*;Bmo);nNnwxbe0+6@#+*yU?3!iPD)z%of;knCja|
zMo5rCe2IAbSun8PmmZ;gsojZL7qODrCpxV<N?IVkGR{pKZJGH%eiKP+T8P4C_gTw&
zOq*Ss<Z<2ulzo4h6nnOtSLcRuAlCb`9(4$PE$w*3UsGE~`W+1YYmW0y8RPz`xvjB<
ztQ;C38(IP@^A4c72b{VXs9E<qR<UO_Ib|;D*@0zvV03gOYV&!Cw{ot#3<gVt!j5q-
zxGk$cSe_@3k=Kj8nrrHP^Wyo3;EmRr=U}KroT%f7-yP*eM5q9M0_jWdZSNKt@0-1s
z-&Uyj5S>2md+&nA3+Crqxv+iSG!~(RvQ~qg!o-7vH(xBGwwKY4+@%r0&PAs;;hIm{
z4ApllZAuqC4}y1k^%&<a8mE?AkMT3476uB7m=J{|z4w4cg6$W>J+Z(iNazkl<IooY
zl;BS8o-FhFBpjnJ-NCwqS8tDTZPzs1=B3?zR`}Un8Ph8Z`?*hk0P(h<DI=@4r5^35
zCS+LMA?)Cj+-6llCw@Ax0j+6+4&5Fw@pOO4ef3EtDm_w@o5Bue!Hu^w<UvPq@J#Zw
zp7A2XebYvbQ&8Cy^?CP@GOCq&^$UY&Z}fTE>1fDYg738Rz>AExCcYz0RCiH{JXA@v
zg%%8Sr-{j*48unrBBz%uDJ^>)K0{>rgT%B<JDk-wQotn16#lhDKa6x13zr2im1=4s
z#!s4wB!5C2rOeHiGrbNB6n(_0Olv(Ivbw9%-5!e#ZH63!i<=?pktBo%F-%G|bklb3
zU~WD}o#`s7`PN!?WK&FPhh|zbIrt*r228T`BZ0j2n!YCOdm@XR4^6tG89IG8G|uFw
zCD)gqZdr{(K7B078UP?%Q7){(V&P?6{Yy>R$@q=IjkX(U^x_&vZRW&0WUGp?&igyA
zLYDk%i_&vvaHV-zuJ+QBN+Sgs>N0^bg#juW6ZC~GU1YY*RnL=c>|3MyW|%a6C11uj
zeumJ}hvZErBe^nqIDtDxhv?ZnP^_iDhZbH&?D?5I7JD8kcCAPGQy)Xam+5`NBU=(c
z*hST{l#)uejNMzoxp7!#nw=Wn%G-bBL&Q93b~|%(azT&29*qB<b;)cFGcc$eRR`mh
z2EzFSjot#(dAi>tjuhV(r^5gzNtVXyRC3_{JMfsmzFFm%RK3zsM3!+(z4(!!@a_T8
zujk65oq6*7F@*@70_)P7GZB^G#EExF{3>!va93sybgxs*cQTgD;N0WvfsQau3GpqK
zh^$M0Y>l;Ne6}FbBEp`!eTtmNHZ+@S>y)}=HHB1p-RS969^#eCokeMwFX|p3-QChr
zxfrYa1|zjXzS|P8hKzp~v%|s!egoDRCgN%dO*!)c|70e04faYadmsZ2oD%!}qjLyb
zeGhPKAQ|y2lF`E#5bMVj^a@J5jT21EGWxx_O_RnB4NP^sB)gGvu;mytkii?O*N%aJ
zB5IK?@CtxaS$nH}dYyk{B4wY`_G{$_w4d{=Nv7uVTb*o#0i!;-XBn;}!+L{cVLrhW
z?h|wY4*4Z=-c~K|Sk;<&g>loOf~RBawq~LX8f8n2ujM`#tEW0wGIc7|1s~XgOXDLd
zBnQg8E^=9N@T7=><og>U72^Q*C8ll(YoqgXb*zi*FruB5y70lu^~`TRW?p#QOa5%h
zJo`n*#8Pa)E9R+uUXdXtRg><`f=#<R?ryckJ1V4fN-UzI|N6wTqy<$mzGn$ARXDsO
zjQ%Fg;2{W|l2=$|qn^Yu*Yd5BVO1;x8N!qqc)Ig6|H7q#Y4YG$8XfkP{d}UHIa?UG
zv-Yd;=d7?rIRlTZX@eJ2@n`I4Qu$bI6iM!WS$saqW+3Z10R%E8Epme05MMx51<JzO
z1cW3yW%><nGx{Ex?QXX+=c_%AixaaHPn@X~d9uok7)Y`BjRZ|DK%Qz87U+qlXdm5z
z6VfEC1sdvFdRSxY6oJlZ=^+k+_ki^;n%#{^y2Y46KC^;qxaP=5XCQU4#HCJaWd7(S
zlrgCfN%T%^#2`vue}uq&_ng>QM2)I6qG(g1vR)+f3g$;O(PkH`Mlj!~Fy?k`p{l>7
zI3OkGo`?3Enf9ELG=OgA!$-#P1J0{*ZHoMYq$KE(YALN7&RdYwEhB5PSd0kGdZ|6#
zU`_R+3bG-c6CkpKKV>!KOYF-4+e_|r({jxY@mnf0V^R$<=`)KH<0B_M(#g8Zuh4Q2
zVA2np7wQr4a(mmEJ47Lr{Zvg+X7-C)gXO3_yH9_*s&RCiZ%RK>{*HP7m!ad^=5lqb
zQ?Y5?fXM<IF7m<4G-yaTzxY$7H-u`TWSQ9JR!epM0%H5On|MJs;G)UbaFl1k@h=fi
zO5wD^E+A(olQrPE7Go`XNGqhnV}K~>S(K_G7T<66td`M)&TOoJ%*1Z~fC)5o*p)m$
zC;qBHVTrmLR<!n>X|X5R1lcMKaRqs(J$nXl*CvT;14HbDxd}gZ=c(IA!j0_;6$xER
zMfHK)UE&FGCO4S6%5`*hzX_C%Z3YS9hXdo>{`PV@p3CvD>)eWqni=So#ug+Mcpibm
zdzW3~f{1IXi6s_hR+98}9=Bq^1(Uj-x*_x@JEaS93)0h&4&xOmu50v{veC`)SBoD&
zoaS+k_)ZOo8!xWg5^I5&Psw4bw%o(CR?Gt_dj@<)5@kn4$AK{zShj^t9DBbmr1t~M
z>dAo3hkF1ScIrY`N;FCLg=|Fl?gt-u9r@^}V^@M$byidB{L49<L8dHtNw;TFx}qTM
z;pmWLJ-_x<FzCm@C^^Ley7VoRs(zyS{NA3`^E2Ii-mvUro`)|*8(LWsh)zcXa6`;C
z3H@1^I#hLRuH}%&pI{Jw+v79)JF)x))NU3Bn?TPUZBv}RnVx@IWFm6T=yx)9x-5M$
zscN(0l<gi+tA}W4ixplR1BFvm9S^awWy|P#=a%`Cq$gP18S4+ixoC%WPU=OEm{LSD
zvYnt(*R6g2=Z%t?kFGn9%pdiPSha}NymppzsRRq36*~J7M!rgY5;Yl5(HM)9a3GTm
zE=93--UDLnT<cYYFyalhUtMBBl(R2e42(l%7~1PHI7+FAHiPW>QguNOHE4hDTC~I1
zr<xGwkJHUdn$v^GByPSEFdHQn);`qfBq`k>!UW&Nnz@{@-kqm^xOwY>XTtJ;K|Nlu
z3O90}SAS!sS+>&cK!dg7L|Jmc;v3rUqK0E`Q=cuA-fEV!>uIw>FR#*io=4c4?g&|l
zsHxCBfLN~Kjuk@lfPv~pV0PjNU*|N{M9%W7G`2iXHg=>LJwB{dA5Pzta1Y4IyuozA
z>s)8DMRdeQLZ~%lXNw!M>Yb@}9COwT+bb_h))sGP^?#^-jf1j8FH(=XzUWV{T#a&X
zK{?0n*`Vv5D5j2jvsGQ;_P5aub9}F|&oD<_BvpLzdpQ5F!oB!#bNj*Cm;@W%rSlc^
zuVSi5jN9&eODmNh(WJLBD7j>q*R=NUg*^&VAMZ45g(p(kp}EVdxz0KMW-S4DTqVx8
z6PYnp=uVdJS5f%OY&|e~gM2_Q_&EEj(74KT*sU)tq{1Q&F=^I+`G8G2@mAPfbwJa$
zOts}<X6G|AkQ8yjGS+L>Wcq2bOH4y;>pcLP5RC{XL-RiGd!jz!dKCi$_zZcdfBWgX
ztEcKtGt=lm6a1t1si%PM<AXRk`dYDB{gU5)<0mybcI%E^S~5w(XH=}b<z|{b04`ty
z9d)e-t+|Th)&SjrMZP{-*8z%BeEqfm0GlM)ox1dQZAT+azYW{x+n%^eC~IGkRqP}p
zD$82c1OKr!BwAqQPA3<{)pAl}U%BF5@N|kLseuToN*Sd}_PcZ7m57;+xWS?<O|=az
z`j_a-hpz3h<-Zt9jd;?cHWNQOGkv_v>Xc*mHqCgwANC^SkXK30u*v1XbE9C{IGYY6
zEzMAkHxa#Lylh@RIqKuoD*4+Am_$9&tpmsH@K>!<>u-6&El!y&I*}*Y@Cs;=#!t2I
znQlynHHWckA2OPP;Hss5w=)Teet+g&PHLaqeUudYgVW3Mv0m_j|26bYy<JOlJ=G~2
z^>X<^sBdZd#KpDc2R`j$wiAX~KKJbR9ff7V0lh0gMzFr?6Ru&Oz<Pxc)x;Dp^jobq
zraC6qZ;w1_1?00VTuEo;0znmYMvNFSCj9`fCN9Gz3{ozzp3ZtjIKMRH9`F&`v)in{
zH*=L-(vBI8rJs96j3IwMh5YkRWHYLo?hL<qd_{k-Uw602)c^9m&tI>Mlkz8jt+`e9
zK@Nhw3fF6;#|{>BsJgw$mo6dk##}A>w7CtH7w>u>m6iCnOxwDs=+K9b5WP@#NS3yz
z{cRI~yF@`<`U0r*@l94+dEKm$=#qC2{qX*236a0FxO0|M_PVm@RM@T+X^Y1_pipzT
z;O8^8l-Bin>yfm+{3Y%U>H!RWG2*7s=(L>5U%>6$rTWBEau>ECX06BGAD4a0%jj$-
zq7G$CmApcSJ<!e2N0MH0OR=AqBLqKw%un-K{!zf)69p=O-&{eNlkLF8-+1$jwQA$#
zo>g*P*6&!C7e{C?h_7ZO!2p{Xs9BDqpzLYrG{U6+_4NzKft#}o(v|XW7p4&E0N)%c
ze)Z#Xt_$BI3Fx8Uh(T$+U%B&nwvWX3<gM`buz~fz!o-R~H4e+`-SPk46Zb#X1Rn4^
zn&s;i;bX5HOnV<E{i%v)@ejdOUc%^upd+Nef-=->nFX_!nHWW;M7>=g(S9P}kCzJG
z{tdj*I3ka=r!ad?^Lgyexa11++K+Ht@WksC*bIH1y&1wih}@i2X7-3tZO@3_6zyhI
z={c5Ps)T+^GI&cQrjh-Z4Xb#Lv~JQw(LF%2W_}<0nDa90>#sDE;kRS2l^#tPm=OmA
zgK*);#qi9~!K+j?gTap`<9q`K2AXlM>rL91J34i7xq&A=N0@7q_&poB^%Xou`5BG0
zyWe7%LQ1iO*NYXs4#zq{%!#2|0luzJvRTzD^FE{Yd;0kwC=b>7X?$u+e@cZ|Z${9T
zqD!O<!Ccxcmep;f(d@aWdJpEykX$afjqg134K?^kt364<zn(Oi>e6^$HVBcHWMQe5
z&5j_+IX*u%a&6I6EvVVYwSoOtH(3c?<K*Z1tA&+C(@@kxW*Hr4iop~-@xaxJ=4$4Y
zzA0xOh1A+k7Wrs8ei)cx@b+2Fr;Wrkos3@TcLmP83iH%M`?+#iNzl2o@P~of1kofH
z`v9?TOPGFD1^EY9uBkR^RB3pZc}k^NS*bE-Q4l@A-_I_DguW5=eNnR%A>onvL$i`%
z$cw<=zese?GdkyY^7dzzSg<jZ<_27DukMgJ<|Wd!5{Dk)pC)*+;}tIlyjGh&shRTe
zS2Ju98)eg4TaLYoE#a>Z#+^5hn)k|!7z-!+Vihtwe#eI<Y+Co!Gt_@(r91WsyI7#0
z2*!jbTfBuwb<ut=bB$0re|P4<IH(YK>z#XXn+H2(V^XgufS9*u_}Jz~8Rf{MexY$Z
z8p_1Ei`J@CGV6n*a>RI{JpJ1<c{R(sC&V6gWl>5u1`S5m`8mC}_I3jm2-AjSVGMNx
zmKjBV!h(M4rBu6NaV4jnFE(*zCeLCvMC%Mqya&AgGkL*-F(W|Q;-+o*+<3b6I0_eM
z50<p1%1}}13XVFHwlZ!}iw^Zc(9E8d1)Ac|#$4px$rW@(-G0iu70_nh7rKRnUam*q
zC8H7f=y55C5+d2O=lk`!Ja*DOclJyk2Bqm6xir29IHP8OaS_V{%MD0_kh4*Z=8ppu
zbBL1i^2rpDhBUSuyAcihA<hy}cr6F%?la@cNGj)#D7oFmR@`)dp8Tx3gg<o%xKgpP
z=BRYydq&e_tP=C!b+qL-!)3^|v`V~c;I8#b+`)~E#J3Qwdg|_}#f7g>Hp<?j9%>wN
zJ9WlD?5@?oH%~UbqrxPeq>*zTX9m7ksTwW5t0@_;WU&~)Ah6648ohn4^V80r_Ihyd
zjy{m)q%Q#MEfo^RE8d%t7IhEUhkyC<@=exhb{>3wm)^nO;`IXpq%ukM&Co#@Moxa=
z@#DbSUnS~Ai3BQ25ubud#*dt8Z$FgFq+nByxn>!|Nv85S7%B7J#)3a@6)srz!l6gT
z;zC_^2&1pE4j;)UoR8{h?Jc^%XtMhC2iNO9oLR7I0i`P(vk`X<Ic>X$W*jjJxYT-{
zxdz7NPaB-m#0o>^rg|HcDTsN`Wy^RMe}I_u*<;0{A*?kIWWi?<8Pc6mS1RH8p?{i}
z*xMe{_M7m~3m7_#^{#2vhS%enyK}?NOHSWrs@vS*bsG$v*<vgIoe)=L?c?vUmPRCp
zH9_Y!jV{5Aq8q5cI9NrEmlnS2u*gmceR^HVje(=fGQI};r|*Y0A+tTg8vz5DQH|9w
zBa^8c+tTI0H$0pu+xN6Zi4Pt2jU(q0qxW@u_e78`iEqqi-BLU<Zbn09_p4pYI}e(I
zSjeloE7A^_eK^O~yEYS<duE!K`=Je3j*lzuh}dwx5@Bwqq=rm6)Gc^eUV5)^{*DRF
zne_LIi0+v1aSeH^JGxu&<Rb$bTb~E)NuN{JWLNL9PR@U61wKV23Fs_agbXcgjfF=N
z0=J)^7KOA&&noXc3@WEm+SBpM%K!fNhf$D$zP{m<fg+iO)f9<EY2S-cP|T$6nmtxN
zbrRwvvQwA>zvB%I-;2L<LX!76T&lvrt{y?(*PRP~2=OJOttKHnUj99{oj;3V(Mp}W
zD?Jd<1bKXc`;3B9NWzngoGmsxsag(GrcW<YPzDfJrWp0B62o<(ulIn0lB?O_djO(o
z|6GB>aM^SOIuqYe|A{^0Dwn&euv<GoHg(#v3<M=bX>u2*l5mR}XcK@i+~s(dwIBm^
I^85M!0Jy#cxBvhE

literal 0
HcmV?d00001


From 77cd2eeda3498fd344817373736f8b7883df909f Mon Sep 17 00:00:00 2001
From: Ulises Gascon <ulisesgascongonzalez@gmail.com>
Date: Wed, 27 Sep 2023 13:37:32 +0200
Subject: [PATCH 575/749] feat: transform John F. Kennedy reference into a
 quote component

---
 _articles/how-to-contribute.md | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 17a04ad9821..f7536848f68 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -189,7 +189,15 @@ Finally, open source projects use the following tools to organize discussion. Re
 
 Now that you've figured out how open source projects work, it's time to find a project to contribute to!
 
-If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_
+If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said:, _"Ask not what your country can do for you - ask what you can do for your country."_
+
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/how-to-contribute/johnfkennedy.jpg" class="pquote-avatar" alt="avatar">
+  Ask not what your country can do for you - ask what you can do for your country.
+  <p markdown="1" class="pquote-credit">
+— [_John f. Kennedy Library_](https://www.jfklibrary.org/learn/education/teachers/curricular-resources/ask-not-what-your-country-can-do-for-you)
+  </p>
+</aside>
 
 Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
 

From d5cf66fee06fa20e6963bcb5db1b861e37a719cc Mon Sep 17 00:00:00 2001
From: Zack Koppert <zkoppert@github.com>
Date: Wed, 27 Sep 2023 11:50:08 -0700
Subject: [PATCH 576/749] Add formatting spaces

---
 _articles/hi/code-of-conduct.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/hi/code-of-conduct.md b/_articles/hi/code-of-conduct.md
index bd1c46ae7a0..cf0d9f21042 100644
--- a/_articles/hi/code-of-conduct.md
+++ b/_articles/hi/code-of-conduct.md
@@ -25,8 +25,8 @@ related:
 आपकी अपेक्षाओं को संप्रेषित करने के अलावा, आचार संहिता निम्नलिखित का वर्णन करती है:
 
 * जहां आचार संहिता प्रभावी होती है _(केवल मुद्दों और पुल अनुरोधों, या घटनाओं जैसी सामुदायिक गतिविधियों पर?)_
-*आचार संहिता किस पर लागू होती है _(समुदाय के सदस्यों और अनुरक्षकों पर, लेकिन प्रायोजकों के बारे में क्या?)_
-*यदि कोई आचार संहिता का उल्लंघन करता है तो क्या होगा
+* आचार संहिता किस पर लागू होती है _(समुदाय के सदस्यों और अनुरक्षकों पर, लेकिन प्रायोजकों के बारे में क्या?)_
+* यदि कोई आचार संहिता का उल्लंघन करता है तो क्या होगा
 * कोई कैसे उल्लंघन की रिपोर्ट कर सकता है
 
 जहां भी आप कर सकें, पूर्व कला का उपयोग करें। [योगदानकर्ता अनुबंध](https://contributor-covenant.org/) एक ड्रॉप-इन आचार संहिता है जिसका उपयोग कुबेरनेट्स, रेल्स और स्विफ्ट सहित 40,000 से अधिक ओपन सोर्स परियोजनाओं द्वारा किया जाता है।

From 00cb8f8864e8b6348df148986ebef50988843bcf Mon Sep 17 00:00:00 2001
From: Zack Koppert <zkoppert@github.com>
Date: Wed, 27 Sep 2023 12:16:45 -0700
Subject: [PATCH 577/749] Remove https://yourfirstpr.github.io/ which is no
 longer available

---
 _articles/zh-hant/how-to-contribute.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md
index eb09d712faf..a74d706c7a3 100644
--- a/_articles/zh-hant/how-to-contribute.md
+++ b/_articles/zh-hant/how-to-contribute.md
@@ -204,7 +204,6 @@ redirect_from: /zh-tw/how-to-contribute/
 
 * [GitHub 探索](https://github.com/explore/)
 * [First Timers Only](http://www.firsttimersonly.com/)
-* [你的第一個 PR](https://yourfirstpr.github.io/)
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](http://up-for-grabs.net/)

From 78818ef770caf760f774296e988cd817299e0802 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Thu, 28 Sep 2023 09:50:07 +0200
Subject: [PATCH 578/749] Update translate for ZH

Co-authored-by: LitoMore <LitoMore@users.noreply.github.com>
---
 assets/css/translate.scss | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/assets/css/translate.scss b/assets/css/translate.scss
index 4c0e8a99a20..63773b328f6 100644
--- a/assets/css/translate.scss
+++ b/assets/css/translate.scss
@@ -24,8 +24,8 @@ $section_translation: (
         "ru": "",
         "ta": "",
         "tr": "",
-        "zh-hant": "",
-        "zh-hans": "",
+        "zh-hant": "章節",
+        "zh-hans": "章节",
 );
 
 @each $locale, $translation in $section_translation {

From 31c79a8978776380fc631eee201fb19248477924 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Thu, 28 Sep 2023 09:50:28 +0200
Subject: [PATCH 579/749] Update translate for KO

Co-authored-by: SeongTae Jeong <seongtaejg@gmail.com>
---
 assets/css/translate.scss | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/assets/css/translate.scss b/assets/css/translate.scss
index 63773b328f6..d8403e141b2 100644
--- a/assets/css/translate.scss
+++ b/assets/css/translate.scss
@@ -15,7 +15,7 @@ $section_translation: (
         "hu": "",
         "id": "",
         "ja": "",
-        "ko": "",
+        "ko": "섹션",
         "ms": "",
         "nl": "Sectie",
         "pl": "Rozdział",

From b6289f38319271740c7decc0f428f690158d573b Mon Sep 17 00:00:00 2001
From: James Titus <titusjames299@gmail.com>
Date: Thu, 28 Sep 2023 18:48:26 +0530
Subject: [PATCH 580/749] Update how-to-contribute.md

---
 _articles/hi/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md
index d345f07f8c9..b1b0c714789 100644
--- a/_articles/hi/how-to-contribute.md
+++ b/_articles/hi/how-to-contribute.md
@@ -491,7 +491,7 @@ Main branch पर commit प्रतिबद्ध को देखें।
 
 ### 😭 आपको कोई प्रतिक्रिया नहीं मिलती।
 
-उम्मीद है कि आपने [गतिविधि के संकेतों के लिए परियोजना की जाँच की](#a-checklist-before-you-contribute) योगदान देने से पहले. हालाँकि, किसी सक्रिय प्रोजेक्ट पर भी, यह संभव है कि आपके योगदान को प्रतिक्रिया नहीं मिलेगी।
+उम्मीद है कि आपने [गतिविधि के संकेतों के लिए परियोजना की जाँच की](#योगदान-देने-से-पहले-एक-चेकलिस्ट) योगदान देने से पहले. हालाँकि, किसी सक्रिय प्रोजेक्ट पर भी, यह संभव है कि आपके योगदान को प्रतिक्रिया नहीं मिलेगी।
 
 यदि आपको एक सप्ताह से अधिक समय में कोई प्रतिक्रिया नहीं मिली है, तो किसी से समीक्षा के लिए पूछते हुए, उसी थ्रेड में विनम्रतापूर्वक प्रतिक्रिया देना उचित है। यदि आप अपने योगदान की समीक्षा करने के लिए सही व्यक्ति का नाम जानते हैं, तो आप उस थ्रेड में उनका @-mention कर सकते हैं।
 

From d8fcf5ca3b9ceeb5feee877f8c569959a0e8a9f3 Mon Sep 17 00:00:00 2001
From: Christine Belzie <105683440+CBID2@users.noreply.github.com>
Date: Thu, 28 Sep 2023 17:30:15 -0400
Subject: [PATCH 581/749] fix: revise typo

Co-authored-by: Zack Koppert <zkoppert@github.com>
---
 _articles/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index f42d1d1c3e7..db837415d40 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -475,7 +475,7 @@ Tips for communicating on issues:
 
 You should usually open a pull request in the following situations:
 
-* Submit small fixes such a typo, a broken link or an obvious error.
+* Submit small fixes such as a typo, a broken link or an obvious error.
 * Start work on a contribution that was already asked for, or that you've already discussed, in an issue.
 
 A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later.

From fff435de75a1eea29af854a7efcd089b7b013cc1 Mon Sep 17 00:00:00 2001
From: Joseph Hale <me@jhale.dev>
Date: Sat, 2 Sep 2023 16:16:11 -0700
Subject: [PATCH 582/749] Add link to git-authorship in legal.md

Git Authorship is a project that helps maintainers identify the
individuals who have committed code present in the current version
of the project.

Added with the permission of @ahpook to avoid "self-promotion"
concerns since this is one of my own projects.

The commented section at the end of the article discusses ideas
for future additions to this article.
---
 _articles/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/legal.md b/_articles/legal.md
index a64a77cd167..77a0f4fe245 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -84,7 +84,7 @@ For example, as your project grows it adds dependencies or users, or your compan
 
 **Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
 
-**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? [People who have commits in your project](https://github.com/thehale/git-authorship) is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
 
 Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- [see below](#does-my-project-need-an-additional-contributor-agreement)) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
 

From 42225c313798b57fa80bccbfb14755a14b8a12bf Mon Sep 17 00:00:00 2001
From: Zack Koppert <zkoppert@github.com>
Date: Mon, 2 Oct 2023 09:33:55 -0700
Subject: [PATCH 583/749] Add legal-oss team as codeowners

---
 CODEOWNERS | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/CODEOWNERS b/CODEOWNERS
index 4bbc6f01f99..787cb5dbadf 100644
--- a/CODEOWNERS
+++ b/CODEOWNERS
@@ -1 +1,3 @@
-*  @github/communities-oss-reviewers
+*                                        @github/communities-oss-reviewers
+articles/legal.md                        @github/legal-oss
+articles/leadership-and-governance.md    @github/legal-oss

From 1f0c219a5b68d140399987d480b3a9cbe8b113d0 Mon Sep 17 00:00:00 2001
From: Lin Jian An <kane@Lins-MacBook-Pro.local>
Date: Wed, 4 Oct 2023 14:25:54 +0800
Subject: [PATCH 584/749] feat: translate
 maintaining-balance-for-open-source-maintainers.md

---
 ...ing-balance-for-open-source-maintainers.md | 126 +++++++++---------
 1 file changed, 62 insertions(+), 64 deletions(-)

diff --git a/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md
index dc77d26dbe9..01518f796eb 100644
--- a/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md
@@ -1,170 +1,168 @@
 ---
 lang: zh-hant
-untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+untranslated: false
+title: 保持平衡——開源專案維護者的指南
+description: 作為一名維護者，照顧自己並避免疲憊的小建議。
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+隨著一個開源專案的受歡迎程度不斷增長，設定清晰的界限變得至關重要，以幫助您保持平衡，確保長期保持清新和高效。
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+為了深入了解維護者的經驗以及他們尋找平衡的策略，我們與<a href="http://maintainers.github.com/">Maintainer Community</a>的40名成員一起進行了一個工作坊，讓我們能夠從他們在開源領域遭受疲憊的第一手經驗中學習，以及幫助他們在工作中保持平衡的實踐。這就是個人生態學的概念派上用場的地方。
 
-So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+那麼，什麼是個人生態學？正如<a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">Rockwood Leadership Institute所描述的</a>，它涉及"<strong>保持平衡、節奏和效率，以維持我們在長期活動中的能量</strong>。" 這個概念幫助維護者認識到他們的行為和貢獻是一個隨時間演變的更大生態系統的一部分。在維護者中，經常出現由於長期的工作壓力而導致的疲憊，這通常會導致動機的喪失，無法集中注意力，以及對您一起工作的貢獻者和社區缺乏同理心。根據世界衛生組織的定義，疲憊是一種由於長期的工作場所壓力而引起的綜合症狀，這種情況在維護者中並不少見。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
-  I was unable to focus or start on a task. I had a lack of empathy for users.
+  我無法專注或開始進行任務。我對使用者缺乏同理心。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>，Owncast直播流媒體伺服器的維護者，談到疲憊對他的開源工作的影響
   </p>
 </aside>
 
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+透過擁抱個人生態學的概念，維護者可以主動避免疲憊，優先考慮自我照顧，並保持平衡感，以便做出最佳的工作表現。
 
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+## 作為維護者的自我照顧和避免疲憊的建議：
 
-### Identify your motivations for working in open source
+### 辨識您參與開源工作的動機
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+花些時間反思開源維護中哪些部分能夠為您注入活力。了解您的動機可以幫助您以一種讓自己保持參與和迎接新挑戰的方式來優先考慮工作。無論是來自使用者的積極反饋、與社區合作和社交的樂趣，還是深入研究程式碼所帶來的滿足感，認識自己的動機可以幫助引導您的關注點。
 
-### Reflect on what causes you to get out of balance and stressed out
+### 反思是什麼使您失去平衡並感到壓力重重
 
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+了解導致我們感到疲憊的原因至關重要。以下是一些我們在開源維護者中常見的主題：
 
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+* **缺乏積極的回饋：** 使用者更有可能在他們有投訴時聯絡您。如果一切都運作良好，他們通常會保持沉默。看到問題清單不斷增長，卻沒有積極的回饋顯示您的貢獻正在產生影響，可能會讓人感到沮喪。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
-  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  有時候感覺有點像在虛空中呼喊，我發現回饋真的能給我帶來活力。我們有很多滿意但寡言的使用者。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+— <a href="https://github.com/thisisnic">@thisisnic</a>，Apache Arrow的維護者
   </p>
 </aside>
 
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **不說"不"：** 在開源專案中，很容易承擔比您應該負責的更多責任。無論是來自使用者、貢獻者還是其他維護者，我們不能總是滿足他們的期望。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
-  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  我發現我承擔了比應該的更多責任，需要做多人份的工作，就像在自由開源軟體中常見的那樣。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>，Termux的維護者，談到導致他工作疲憊的原因
   </p>
 </aside>
 
-* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+* **單獨工作：** 做一名維護者可能會讓人感到極度孤獨。即使您與一組維護者一起工作，過去幾年來，因分散的團隊難以親自聚會而變得困難。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
- Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  特別是自從COVID疫情以來，在家工作使得很難再見到人或與人交談。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>，Owncast直播流媒體伺服器的維護者，談到疲憊對他的開源工作的影響
   </p>
 </aside>
 
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **時間和資源不足：** 對於那些必須犧牲自己的空閒時間來參與項目的志願維護者來說，這一點尤其真實。
 
 <aside markdown="1" class="pquote">
-  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  [我希望有] 更多的財務支持，這樣我就可以專注於開源工作，而不會消耗我的積蓄，並知道以後必須做很多合同工作來彌補。
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— 開源維護者
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **需求衝突：** 開源充滿了擁有不同動機的群體，這可能很難應對。如果您受薪工作於開源項目，您的雇主的利益有時可能與社區的利益相衝突。
 
 <aside markdown="1" class="pquote">
-  With paid open source, conflict between employer's focus and what's best for the community
+  有薪開源中，雇主的關注點與社區最佳利益之間的衝突
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— 開源維護者
   </p>
 </aside>
 
-### Watch out for signs of burnout
+### 注意疲憊的跡象
 
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+您能夠保持這種節奏達10週嗎？10個月？10年？
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+有一些工具，例如來自 [@shaunagm](https://github.com/shaunagm) 的 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) 和 Mozilla 的 [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw)，可以幫助您反思您目前的節奏，並查看是否有任何調整的空間。一些維護者還使用可穿戴技術來追蹤睡眠質量和心率變異性等指標（這些都與壓力有關）。
 
 <aside markdown="1" class="pquote">
- I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+ 我非常相信優質的可穿戴設備。有了背後的科學知識，您可以了解如何做得更好，以及如何達到您想要達到的最佳狀態。
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— 開源維護者
   </p>
 </aside>
 
-### What would you need to continue sustaining yourself and your community?
+### 您需要什麼來持續支持自己和您的社群？
 
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+對每位維護者來說，這可能因年齡階段和其他外部因素而有所不同。但以下是一些我們聽到的主題：
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **依賴社群：** 委託和找到貢獻者可以減輕工作負荷。項目有多個聯絡點可以幫助您在休息時不必擔心。與其他維護者和更廣泛的社群建立聯繫，例如 [Maintainer Community](http://maintainers.github.com/)。這可以是同儕支持和學習的重要資源。
 
-  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+您還可以尋找與使用者社群互動的方式，以便定期聽取反饋並了解您的開源工作的影響。
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **探索資金支持：** 無論您是尋找一些額外的財政支持，還是嘗試全職投入開源，都有許多資源可以幫助您！作為第一步，考慮啟用 [GitHub Sponsors](https://github.com/sponsors)，以允許其他人贊助您的開源工作。如果您考慮轉向全職，請申請下一輪的 [GitHub Accelerator](http://accelerator.github.com/)。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
- I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+ 我一段時間前參加了一個播客，我們討論了開源維護和可持續性的問題。我發現即使有少數人在 GitHub 上支持我的工作，也能迅速決定不玩遊戲，而是做一點點開源工作。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+— <a href="https://github.com/mansona">@mansona</a>，EmberJS的維護者
   </p>
 </aside>
 
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+* **使用工具：** 探索工具，如 [GitHub Copilot](https://github.com/features/copilot/) 和 [GitHub Actions](https://github.com/features/actions)，以自動化乏味的任務，釋放更多時間進行有意義的貢獻。
 
 <aside markdown="1" class="pquote">
- Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+ 使用 [Copilot](https://github.com/features/copilot/) 來處理沉悶的事情 - 做有趣的事情
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— 開源維護者
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+* **休息和恢復：** 為自己的興趣和愛好留出時間，遠離開源項目的工作。週末休息一下，放鬆身心，並設定您的 [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) 以反映您的可用性！一晚好的睡眠對於您長期維護努力的能力可能會產生重大影響。
 
-  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+如果您發現項目的某些方面特別令人愉快，請嘗試結構化您的工作，以便您可以在一天中體驗到這些樂趣。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+ 我發現在白天更多機會嵌入"創造性時刻"，而不是試圖在晚上關掉。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+— <a href="https://github.com/danielroe">@danielroe</a>，Nuxt的維護者
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **設定界限：** 您無法對每個請求都答應。這可以是簡單地說，"我現在無法處理這個，並且將來也沒有計劃"，或在 README 中列出您有興趣和不願意做的事情。例如，您可以說："我只會合併明確列出為什麼要這樣做的 PR"，或者，"我只會在每兩週的週四晚上 6 點到 7 點之間審查問題。" 這會讓其他人對您的期望有所了解，並且在其他時候有助於緩解貢獻者或使用者對您的時間的需求。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+要在這些方面真正信任其他人，您不能成為對每個請求都說"是"的人。這樣一來，您就不會在專業或個人方面保持界限，也不會成為可靠的同事。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>，Homebrew的維護者，在 [Saying No](https://mikemcquaid.com/saying-no/) 上談及
+
   </p>
 </aside>
-
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+學會堅定地制止有毒行為和負面互動。不對您不關心的事情付出精力是可以接受的。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-My software is gratis, but my time and attention is not.
+我的軟件是免費的，但我的時間和關注不是。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>，Leaflet的維護者
   </p>
 </aside>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
-  <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+開源維護有其黑暗面，其中之一是有時必須與相當不感激、自以為是或明顯有毒的人互動。隨著項目的受歡迎程度增加，這種互動的頻率也增加，增加了維護者的負擔，可能成為維護者疲憊的重要風險因素。
   </p>
 </aside>
 
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+請記住，個人生態學是一個不斷演變的實踐，隨著您在開源之旅中的進展而變化。通過優先考慮自我照顧和保持平衡感，您可以有效且持久地貢獻於開源社群，確保自己的幸福以及項目的長期成功。
 
-## Additional Resources
+## 額外資源
 
 * [Maintainer Community](http://maintainers.github.com/)
 * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
@@ -177,11 +175,11 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
 * Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
 
-## Contributors
+## 貢獻者
 
-Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+非常感謝所有與我們分享他們經驗和建議的維護者！
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+本指南由[@abbycabs](https://github.com/abbycabs)撰寫，[@jianan1104](https://github.com/jianan1104)翻譯，並得到以下貢獻者的貢獻：
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
@@ -218,4 +216,4 @@ This guide was written by [@abbycabs](https://github.com/abbycabs) with contribu
 [@thisisnic](https://github.com/thisisnic)
 [@tudoramariei](https://github.com/tudoramariei)
 [@UlisesGascon](https://github.com/UlisesGascon)
-[@waldyrious](https://github.com/waldyrious) + many others!
+[@waldyrious](https://github.com/waldyrious) + 很多人!

From d3ca9b209f2138563ec734c386b3abc2f07f1751 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?= <websnke@tutanota.com>
Date: Fri, 6 Oct 2023 21:40:35 +0300
Subject: [PATCH 585/749] Update German translation

---
 ...ing-balance-for-open-source-maintainers.md | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index 29808f19840..58d1d199c4f 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -1,16 +1,16 @@
 ---
 lang: de
-untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+untranslated: false
+title: Balance für Open-Source-Maintainer halten
+description: Tipps zur Selbsthilfe und zur Vermeidung von Burnout als Maintainer.
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+Wenn ein Open-Source-Projekt immer beliebter wird, ist es wichtig, sich klare Grenzen zu setzen, um die Balance zu halten, damit man auf lange Sicht motiviert und produktiv bleibt. 
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+Um Einblicke in die Erfahrungen von Maintainern und ihre Strategien, eine Balance zu finden, zu gewinnen, haben wir einen Workshop mit 40 Mitgliedern der <a href="http://maintainers.github.com/">Maintainer-Community</a> durchgeführt. So konnten wir aus erster Hand von ihren Erfahrungen mit Burnout in der Open-Source-Branche und den Praktiken lernen, die ihnen geholfen haben, bei ihrer Arbeit eine Balance zu halten. An dieser Stelle kommt das Konzept der persönlichen Ökologie ins Spiel.
 
 So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
 
@@ -22,25 +22,25 @@ So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprof
   </p>
 </aside>
 
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+Indem sie sich mit dem Konzept der persönlichen Ökologie vertraut machen, können Maintainer Burnout vorbeugen, der eigenen Gesundheit Priorität einräumen und ein Gefühl der Ausgeglichenheit bewahren, um ihre Bestleistung zu erbringen.
 
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+## Tipps zur Selbsthilfe und zur Vorbeugung von Burnout als Maintainer:
 
-### Identify your motivations for working in open source
+### Erkennen Sie Ihre Motivation für Open-Source-Arbeit
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+Nehmen Sie sich Zeit, darüber nachzudenken, was Sie an der Pflege von Open-Source-Projekten reizt. Wenn Sie Ihre Motivationen verstehen, können Sie die Arbeit so priorisieren, dass Sie engagiert und bereit für neue Herausforderungen bleiben. Ob es das positive Feedback der Benutzer ist, die Freude an der Zusammenarbeit und am Austausch mit der Gemeinschaft oder die Befriedigung, in den Code einzutauchen - das Erkennen Ihrer Motivationen kann Ihnen helfen, Ihren Fokus zu richten.
 
-### Reflect on what causes you to get out of balance and stressed out
+### Überlegen Sie, was Sie aus dem Gleichgewicht und in Stress bringt
 
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+Es ist wichtig zu verstehen, was die Ursachen für Burnout sind. Hier sind ein paar gemeinsame Ursachen, die wir bei Open-Source-Betreuern festgestellt haben:
 
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+* **Mangel an positivem Feedback:** Nutzer sind viel eher bereit, Beschwerden zu äußern, wenn sie ein Problem haben. Wenn alles gut läuft, schweigen sie eher. Es kann entmutigend sein, eine wachsende Liste von Problemen zu sehen, ohne positives Feedback, das zeigt, wie Ihre Beiträge etwas bewirken.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
-  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  Manchmal fühlt es sich so an, als würde man ins Leere schreien, und ich finde, dass mich dieses Feedback wirklich anspornt. Wir haben viele glückliche, aber stille Nutzer.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+— <a href="https://github.com/thisisnic">@thisisnic</a>, Maintainer von Apache Arrow
   </p>
 </aside>
 

From 05b6ec3e1784a7e97576385391f8aeffa5c580fa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?= <websnke@tutanota.com>
Date: Fri, 6 Oct 2023 21:44:49 +0300
Subject: [PATCH 586/749] Update German translation in footer

---
 _data/locales/de.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_data/locales/de.yml b/_data/locales/de.yml
index d2891744842..0997210c73a 100644
--- a/_data/locales/de.yml
+++ b/_data/locales/de.yml
@@ -28,4 +28,4 @@ de:
       # Label für das Herz-Octicon
       love_label: love
       # Label für das Octicon der Mitwirkenden
-      friends_label: friends
+      friends_label: Freunden

From 5ba5ad60a0287eca1c6f1fb67a101144b572d7a3 Mon Sep 17 00:00:00 2001
From: zaki-hussain <zakriyahussain6@gmail.com>
Date: Sat, 7 Oct 2023 16:24:49 +0100
Subject: [PATCH 587/749] Fixed typos by adding spaces after commas

---
 _articles/how-to-contribute.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index db837415d40..1a952f1c86e 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -87,7 +87,7 @@ Even if you like to write code, other types of contributions are a great way to
 
 ### Do you like to write?
 
-* Write and improve the project's documentation,[like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
+* Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
 * Curate a folder of examples showing how the project is used
 * Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/)
 * Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
@@ -209,7 +209,7 @@ Open source isn't an exclusive club; it's made by people just like you. "Open so
 
 You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
 
-> According to a study conducted by Igor Steinmacher and other Computer Science researchers,[28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as  typo fixes, reformatting, or writing a translation.
+> According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as  typo fixes, reformatting, or writing a translation.
 
 If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
 

From 80ccb34b23e35be6f162640a7ffe2d640f7ec83f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?= <websnke@tutanota.com>
Date: Sun, 8 Oct 2023 21:54:32 +0300
Subject: [PATCH 588/749] Update
 maintaining-balance-for-open-source-maintainers.md

---
 ...aintaining-balance-for-open-source-maintainers.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index 58d1d199c4f..23241359dcf 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -16,9 +16,9 @@ So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprof
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
-  I was unable to focus or start on a task. I had a lack of empathy for users.
+  Ich war nicht in der Lage, mich zu konzentrieren oder mit einer Aufgabe zu beginnen. Mir fehlte es an Empathie für die Benutzer.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, Maintainer des Owncast Live-Streaming-Servers, über die Folgen von Burnout auf seine Arbeit mit Open Source
   </p>
 </aside>
 
@@ -44,17 +44,17 @@ Es ist wichtig zu verstehen, was die Ursachen für Burnout sind. Hier sind ein p
   </p>
 </aside>
 
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **Nicht "Nein" sagen:** Es kann leicht passieren, dass man bei einem Open-Source-Projekt mehr Verantwortung übernimmt, als man sollte. Ob von Nutzern, Mitwirkenden oder anderen Betreuern - wir können nicht immer ihren Erwartungen gerecht werden.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
-  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  Ich stellte fest, dass ich mehr als eine Aufgabe übernehmen und die Arbeit mehrerer Personen erledigen musste, wie es bei FOSS üblich ist.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, Maintainer von Termux, über die Ursachen von Burnout bei seiner Arbeit
   </p>
 </aside>
 
-* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+* **Alleine arbeiten:** Ein Maintainer zu sein, kann unglaublich einsam sein. Selbst wenn Sie mit einer Gruppe von Betreuern zusammenarbeiten, war es in den letzten Jahren schwierig, sich persönlich mit zerstreuten Teams zu treffen.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">

From accfc83dbe57e7895d3aabf860e9ef3a6b158d6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?= <websnke@tutanota.com>
Date: Mon, 9 Oct 2023 14:15:58 +0300
Subject: [PATCH 589/749] Update
 maintaining-balance-for-open-source-maintainers.md

---
 ...ing-balance-for-open-source-maintainers.md | 26 +++++++++----------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index 23241359dcf..c4b508f5f72 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -58,44 +58,44 @@ Es ist wichtig zu verstehen, was die Ursachen für Burnout sind. Hier sind ein p
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
- Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+ Vor allem seit Corona und der Arbeit von zu Hause aus ist es schwieriger, nie jemanden zu sehen oder mit jemandem zu sprechen.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, Maintainer des Owncast Live-Streaming-Servers, über die Folgen von Burnout auf seine Open-Source-Arbeit
   </p>
 </aside>
 
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **Nicht genug Zeit oder Ressourcen:** Dies gilt insbesondere für freiwillige Maintainer, die ihre Freizeit für die Arbeit an einem Projekt opfern müssen.
 
 <aside markdown="1" class="pquote">
-  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  [Ich hätte gerne] mehr finanzielle Unterstützung, sodass ich mich auf die Open-Source-Arbeit konzentrieren kann, ohne mein Erspartes aufzubrauchen und zu wissen, dass ich später eine Menge Auftragsarbeiten erledigen muss, um das zu kompensieren.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— Open-Source-Maintainer
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Unterschiedliche Forderungen:**  Open Source ist voll von Gruppen mit unterschiedlichen Motivationen, die schwer zu durchschauen sind. Wenn Sie für Ihre Arbeit an Open Source bezahlt werden, können die Interessen Ihres Arbeitgebers manchmal mit denen der Community kollidieren.
 
 <aside markdown="1" class="pquote">
-  With paid open source, conflict between employer's focus and what's best for the community
+  Bei kommerziellen Produkten mit offenem Quellcode besteht ein Konflikt zwischen den Interessen des Arbeitgebers und dem, was das Beste für die Gemeinschaft ist
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— Open-Source-Maintainer
   </p>
 </aside>
 
-### Watch out for signs of burnout
+### Halte Ausschau nach Zeichen für Burnout
 
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+Können Sie Ihr Tempo 10 Wochen lang beibehalten? 10 Monate? 10 Jahre?
 
 There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
- I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+ Ich bin ein großer Befürworter von guten Wearables. Mit der Wissenschaft dahinter kann man verstehen, was man hätte besser machen können und wie man seine Ziele optimal erreichen kann.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— Open-Source-Maintainer
   </p>
 </aside>
 
-### What would you need to continue sustaining yourself and your community?
+### Was brauchen Sie, um sich und Ihre Gemeinschaft weiterhin zu erhalten?
 
 This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
 

From 280dc2c573e97bc07ede66c541c6fff024890812 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?= <websnke@tutanota.com>
Date: Mon, 9 Oct 2023 21:12:07 +0300
Subject: [PATCH 590/749] Update
 maintaining-balance-for-open-source-maintainers.md

---
 ...aining-balance-for-open-source-maintainers.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index c4b508f5f72..518a803ccd6 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -97,19 +97,19 @@ There are tools like the [Burnout Checklist](https://governingopen.com/resources
 
 ### Was brauchen Sie, um sich und Ihre Gemeinschaft weiterhin zu erhalten?
 
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+Dies wird für jeden Betreuer unterschiedlich sein und sich je nach Lebensphase und anderen äußeren Faktoren ändern. Aber hier sind ein paar Aspekte, die wir gehört haben:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **Vertrauen Sie der Community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
 
-  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+  Sie können auch nach Möglichkeiten suchen, mit der Nutzergemeinde in Kontakt zu treten, damit Sie regelmäßig Feedback erhalten und die Auswirkungen Ihrer Open-Source-Arbeit verstehen.
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **Finanzierung erforschen:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
- I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+ Ich war vor einiger Zeit in einem Podcast und wir sprachen über die Instandhaltung von Open Source und Nachhaltigkeit. Ich fand, dass selbst eine kleine Anzahl von Leuten, die meine Arbeit auf GitHub unterstützen, mir geholfen hat, eine schnelle Entscheidung zu treffen, nicht vor einem Spiel zu sitzen, sondern stattdessen eine kleine Sache mit Open Source zu machen.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+— <a href="https://github.com/mansona">@mansona</a>, Maintainer von EmberJS
   </p>
 </aside>
 
@@ -118,13 +118,13 @@ This will look different for each maintainer, and will change depending on your
 <aside markdown="1" class="pquote">
  Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— Open-Source-Maintainer
   </p>
 </aside>
 
 * **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
 
-  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+  Wenn Ihnen bestimmte Aspekte Ihres Projekts besonders viel Spaß machen, versuchen Sie, Ihre Arbeit so zu strukturieren, dass Sie sie während des Tages erleben können.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">

From db02ec4b9f64ff8837a5280604fa5ccfb51b95b2 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Wed, 11 Oct 2023 08:44:59 +0200
Subject: [PATCH 591/749] fix link in Legal for PL

---
 _articles/pl/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/legal.md b/_articles/pl/legal.md
index 20e7a4f713d..63fff32dc1d 100644
--- a/_articles/pl/legal.md
+++ b/_articles/pl/legal.md
@@ -70,7 +70,7 @@ Możesz także rozważyć **społeczności**, które mają nadzieję wykorzysta
 * **Czy chcesz, aby Twój projekt spodobał się dużym firmom?** Duży biznes prawdopodobnie będzie chciał uzyskać wyraźną licencję patentową od wszystkich autorów. W takim przypadku usługa [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) obejmuje Ciebie (i ich).
 * **Czy chcesz, aby Twój projekt był atrakcyjny dla autorów, którzy nie chcą, aby ich wkład był wykorzystywany w oprogramowaniu zamkniętym?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) lub (jeśli nie chcą również wnosić wkładu do usług zamkniętego źródła) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) przejdzie dobrze.
 
-Twoja **firma** może mieć określone wymagania licencyjne dla swoich projektów open source. Na przykład, może wymagać zezwolenia licencyjnego, aby firma mogła wykorzystać Twój projekt w zamkniętym źródłowym produkcie firmy. Lub Twoja firma może wymagać silnej licencji copyleft i dodatkowej umowy o współautorze (patrz poniżej), aby tylko Twoja firma i nikt inny nie mógł używać twojego projektu w oprogramowaniu zamkniętym. Lub Twoja firma może mieć pewne potrzeby związane ze standardami, odpowiedzialnością społeczną lub przejrzystością, z których każda może wymagać określonej strategii licencjonowania. Porozmawiaj z działem prawnym swojej firmy](#what-does-my-companys-legal-team-need-to-know).
+Twoja **firma** może mieć określone wymagania licencyjne dla swoich projektów open source. Na przykład, może wymagać zezwolenia licencyjnego, aby firma mogła wykorzystać Twój projekt w zamkniętym źródłowym produkcie firmy. Lub Twoja firma może wymagać silnej licencji copyleft i dodatkowej umowy o współautorze (patrz poniżej), aby tylko Twoja firma i nikt inny nie mógł używać twojego projektu w oprogramowaniu zamkniętym. Lub Twoja firma może mieć pewne potrzeby związane ze standardami, odpowiedzialnością społeczną lub przejrzystością, z których każda może wymagać określonej strategii licencjonowania. Porozmawiaj z [działem prawnym swojej firmy](#co-powinien-wiedzieć-zespół-prawny-mojej-firmy).
 
 Podczas tworzenia nowego projektu w GitHub masz możliwość wybrania licencji. Dołączenie jednej z wyżej wymienionych licencji sprawi, że Twój projekt GitHub stanie się open source. Jeśli chcesz zobaczyć inne opcje, sprawdź [choosealicense.com](https://choosealicense.com), aby znaleźć odpowiednią licencję dla swojego projektu, nawet jeśli nie jest to [oprogramowanie](https://choosealicense.com/non-software/).
 

From bf307a0b31c29635187d42deaf02351023552fff Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Wed, 11 Oct 2023 09:05:55 +0200
Subject: [PATCH 592/749] refactoring - space added in PL

---
 _articles/pl/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/pl/starting-a-project.md b/_articles/pl/starting-a-project.md
index 72bba217ab1..ed7caa0598b 100644
--- a/_articles/pl/starting-a-project.md
+++ b/_articles/pl/starting-a-project.md
@@ -38,7 +38,7 @@ _Wolne oprogramowanie_ odnosi się do tego samego zestawu projektów, co _otwart
 
 * **Współpraca:** Projekty open source mogą akceptować zmiany od każdego na świecie. [Exercism](https://github.com/exercism/), na przykład, jest platformą ćwiczeń programistycznych z ponad 350 uczestnikami.
 
-* **Adopcja i remiksowanie:** projekty open source mogą być wykorzystywane przez każdego do prawie dowolnego celu. Ludzie mogą nawet używać go do budowania innych rzeczy. [WordPress](https://github.com/WordPress), na przykład, zaczął się jako rozwidlenie istniejącego projektu o nazwie[b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **Adopcja i remiksowanie:** projekty open source mogą być wykorzystywane przez każdego do prawie dowolnego celu. Ludzie mogą nawet używać go do budowania innych rzeczy. [WordPress](https://github.com/WordPress), na przykład, zaczął się jako rozwidlenie istniejącego projektu o nazwie [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
 * **Transparentność:** Każdy może sprawdzić projekt open source pod kątem błędów lub niespójności. Przejrzystość ma znaczenie dla rządów takich jak [Bułgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) lub [Stany Zjednoczone](https://sourcecode.cio.gov/), regulowane branże, takie jak bankowość lub opieka zdrowotna, oraz oprogramowanie zabezpieczające, takie jak [Let's Encrypt](https://github.com/letsencrypt).
 

From 0db8d00f4071cf7a9d68ae145052ed353730c49d Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Wed, 11 Oct 2023 09:06:27 +0200
Subject: [PATCH 593/749] fix link in starting-a-project for HI

---
 _articles/hi/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md
index e1eb3ed63c0..dd0179ba62f 100644
--- a/_articles/hi/starting-a-project.md
+++ b/_articles/hi/starting-a-project.md
@@ -20,7 +20,7 @@ related:
 
 खुला स्रोत शक्तिशाली है क्योंकि यह अपनाने और सहयोग की बाधाओं को कम करता है, जिससे लोगों को परियोजनाओं को तेजी से फैलाने और सुधारने की अनुमति मिलती है। इसके अलावा, क्योंकि यह उपयोगकर्ताओं को बंद स्रोत के सापेक्ष, अपने स्वयं के कंप्यूटिंग को नियंत्रित करने की क्षमता देता है। उदाहरण के लिए, ओपन सोर्स सॉफ़्टवेयर का उपयोग करने वाले व्यवसाय के पास किसी बंद स्रोत विक्रेता के उत्पाद निर्णयों पर विशेष रूप से निर्भर रहने के बजाय सॉफ़्टवेयर में कस्टम सुधार करने के लिए किसी को नियुक्त करने का विकल्प होता है।
 
-_मुफ़्त सॉफ़्टवेयर_ परियोजनाओं के उसी सेट को संदर्भित करता है जो _ओपन सोर्स_ है। कभी-कभी आप [इन शर्तों](https://en.wikipedia.org/wiki/Free_and_open-source_software) को "फ्री और ओपन सोर्स सॉफ्टवेयर" (FOSS) या "फ्री, लिब्रे और ओपन सोर्स सॉफ्टवेयर" के रूप में भी देखेंगे। (दाँत साफ करने का धागा)। _मुक्त_ और _मुक्ति_ का तात्पर्य स्वतंत्रता से है, [कीमत से नहीं](#does-open-source-mean-free-of-charge)।
+_मुफ़्त सॉफ़्टवेयर_ परियोजनाओं के उसी सेट को संदर्भित करता है जो _ओपन सोर्स_ है। कभी-कभी आप [इन शर्तों](https://en.wikipedia.org/wiki/Free_and_open-source_software) को "फ्री और ओपन सोर्स सॉफ्टवेयर" (FOSS) या "फ्री, लिब्रे और ओपन सोर्स सॉफ्टवेयर" के रूप में भी देखेंगे। (दाँत साफ करने का धागा)। _मुक्त_ और _मुक्ति_ का तात्पर्य स्वतंत्रता से है, [कीमत से नहीं](#क्या-ओपन-सोर्स-का-मतलब-निःशुल्क-है)।
 
 ### लोग अपना काम ओपन सोर्स क्यों करते हैं?
 

From 65b5ca97cdfc260f5b98e35ad3cccc078675cfd4 Mon Sep 17 00:00:00 2001
From: Olsza <olsza@users.noreply.github.com>
Date: Wed, 11 Oct 2023 09:06:41 +0200
Subject: [PATCH 594/749] fix link in Legal for HI

---
 _articles/hi/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md
index aae22fa1d16..4e005274bba 100644
--- a/_articles/hi/legal.md
+++ b/_articles/hi/legal.md
@@ -71,7 +71,7 @@ related:
 * **क्या आप चाहते हैं कि आपका प्रोजेक्ट उन योगदानकर्ताओं को आकर्षित करे जो नहीं चाहते कि उनके योगदान का उपयोग बंद स्रोत सॉफ़्टवेयर में किया जाए?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) या (यदि वे भी बंद स्रोत सेवाओं में योगदान नहीं करना चाहते हैं) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) 
 अच्छा चलेगा।
 
-आपकी **कंपनी** को अपने ओपन सोर्स प्रोजेक्ट्स के लिए विशिष्ट लाइसेंसिंग आवश्यकताएं हो सकती हैं। उदाहरण के लिए, इसके लिए एक अनुमेय लाइसेंस की आवश्यकता हो सकती है ताकि कंपनी आपके प्रोजेक्ट का उपयोग कंपनी के बंद स्रोत उत्पाद में कर सके। या आपकी कंपनी को एक मजबूत कॉपीलेफ्ट लाइसेंस और एक अतिरिक्त योगदानकर्ता समझौते (नीचे देखें) की आवश्यकता हो सकती है ताकि केवल आपकी कंपनी, और कोई नहीं, बंद स्रोत सॉफ़्टवेयर में आपके प्रोजेक्ट का उपयोग कर सके। या आपकी कंपनी को मानकों, सामाजिक जिम्मेदारी, या पारदर्शिता से संबंधित कुछ ज़रूरतें हो सकती हैं, जिनमें से किसी के लिए एक विशेष लाइसेंसिंग रणनीति की आवश्यकता हो सकती है। आप अपने [कंपनी का कानूनी विभाग](#what-does-my-companys-legal-team-need-to-know) से बातें करें।
+आपकी **कंपनी** को अपने ओपन सोर्स प्रोजेक्ट्स के लिए विशिष्ट लाइसेंसिंग आवश्यकताएं हो सकती हैं। उदाहरण के लिए, इसके लिए एक अनुमेय लाइसेंस की आवश्यकता हो सकती है ताकि कंपनी आपके प्रोजेक्ट का उपयोग कंपनी के बंद स्रोत उत्पाद में कर सके। या आपकी कंपनी को एक मजबूत कॉपीलेफ्ट लाइसेंस और एक अतिरिक्त योगदानकर्ता समझौते (नीचे देखें) की आवश्यकता हो सकती है ताकि केवल आपकी कंपनी, और कोई नहीं, बंद स्रोत सॉफ़्टवेयर में आपके प्रोजेक्ट का उपयोग कर सके। या आपकी कंपनी को मानकों, सामाजिक जिम्मेदारी, या पारदर्शिता से संबंधित कुछ ज़रूरतें हो सकती हैं, जिनमें से किसी के लिए एक विशेष लाइसेंसिंग रणनीति की आवश्यकता हो सकती है। आप अपने [कंपनी का कानूनी विभाग](#मेरी-कंपनी-की-कानूनी-टीम-को-क्या-जानना-आवश्यक-है) से बातें करें।
 
 जब आप GitHub पर एक नया प्रोजेक्ट बनाते हैं, तो आपको लाइसेंस चुनने का विकल्प दिया जाता है। ऊपर उल्लिखित लाइसेंसों में से एक को शामिल करने से आपका GitHub प्रोजेक्ट खुला स्रोत बन जाएगा। यदि आप अन्य विकल्प देखना चाहते हैं, तो देखें [choosealicense.com](https://choosealicense.com) अपने प्रोजेक्ट के लिए सही लाइसेंस ढूँढ़ने के लिए, भले ही वह हो [isn't software](https://choosealicense.com/non-software/).
 

From ded20a7f42b0e92e4fd64774334807cc82455b16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?= <websnke@tutanota.com>
Date: Thu, 12 Oct 2023 17:09:02 +0300
Subject: [PATCH 595/749] Update
 maintaining-balance-for-open-source-maintainers.md

---
 .../maintaining-balance-for-open-source-maintainers.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index 518a803ccd6..8d29b5c8607 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -12,7 +12,7 @@ Wenn ein Open-Source-Projekt immer beliebter wird, ist es wichtig, sich klare Gr
 
 Um Einblicke in die Erfahrungen von Maintainern und ihre Strategien, eine Balance zu finden, zu gewinnen, haben wir einen Workshop mit 40 Mitgliedern der <a href="http://maintainers.github.com/">Maintainer-Community</a> durchgeführt. So konnten wir aus erster Hand von ihren Erfahrungen mit Burnout in der Open-Source-Branche und den Praktiken lernen, die ihnen geholfen haben, bei ihrer Arbeit eine Balance zu halten. An dieser Stelle kommt das Konzept der persönlichen Ökologie ins Spiel.
 
-So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+Was also ist persönliche Ökologie? <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">Laut dem Rockwood Leadership Institute</a> geht es darum, "<strong>das Gleichgewicht, das Tempo und die Effizienz aufrechtzuerhalten, um unsere Energie ein Leben lang zu erhalten</strong>." Dies gab unseren Gesprächen einen Rahmen und half den Maintainern, ihre Beiträge als Teil eines größeren Ökosystems zu erkennen, das sich im Laufe der Zeit weiterentwickelt. Burnout, ein Syndrom, das aus chronischem Stress am Arbeitsplatz resultiert, wie [von der WHO definiert](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), ist unter Maintainern keine Seltenheit. Dies führt oft zu einem Motivationsverlust, einer Unfähigkeit, sich zu konzentrieren, und einem Mangel an Empathie für die Mitwirkenden und die Community, mit der man arbeitet.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
@@ -67,7 +67,7 @@ Es ist wichtig zu verstehen, was die Ursachen für Burnout sind. Hier sind ein p
 * **Nicht genug Zeit oder Ressourcen:** Dies gilt insbesondere für freiwillige Maintainer, die ihre Freizeit für die Arbeit an einem Projekt opfern müssen.
 
 <aside markdown="1" class="pquote">
-  [Ich hätte gerne] mehr finanzielle Unterstützung, sodass ich mich auf die Open-Source-Arbeit konzentrieren kann, ohne mein Erspartes aufzubrauchen und zu wissen, dass ich später eine Menge Auftragsarbeiten erledigen muss, um das zu kompensieren.
+  Ich hätte gerne mehr finanzielle Unterstützung, sodass ich mich auf die Open-Source-Arbeit konzentrieren kann, ohne mein Erspartes aufzubrauchen und zu wissen, dass ich später eine Menge Auftragsarbeiten erledigen muss, um das zu kompensieren.
   <p markdown="1" class="pquote-credit">
 — Open-Source-Maintainer
   </p>
@@ -86,7 +86,7 @@ Es ist wichtig zu verstehen, was die Ursachen für Burnout sind. Hier sind ein p
 
 Können Sie Ihr Tempo 10 Wochen lang beibehalten? 10 Monate? 10 Jahre?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+Es gibt Tools wie die [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) von [@shaunagm](https://github.com/shaunagm) und Mozillas [Personal Ecology Self-Assessment Kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), die Ihnen dabei helfen können, Ihr aktuelles Tempo zu reflektieren und zu sehen, ob Sie Anpassungen vornehmen können. Einige Betreuer verwenden auch Wearables, um Messwerte wie Schlafqualität und Herzfrequenzvariabilität (die beide mit Stress in Verbindung stehen) zu verfolgen.
 
 <aside markdown="1" class="pquote">
  Ich bin ein großer Befürworter von guten Wearables. Mit der Wissenschaft dahinter kann man verstehen, was man hätte besser machen können und wie man seine Ziele optimal erreichen kann.
@@ -113,10 +113,10 @@ Dies wird für jeden Betreuer unterschiedlich sein und sich je nach Lebensphase
   </p>
 </aside>
 
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+* **Tools einsetzen:** Entdecken Sie Tools wie [GitHub Copilot](https://github.com/features/copilot/) und [GitHub Actions](https://github.com/features/actions), um alltägliche Aufgaben zu automatisieren und Zeit für sinnvollere Beiträge zu gewinnen.
 
 <aside markdown="1" class="pquote">
- Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+ Verwenden Sie [Copilot](https://github.com/features/copilot/) für die langweiligen Dinge - machen Sie die Dinge, die Ihnen Spaß machen
   <p markdown="1" class="pquote-credit">
 — Open-Source-Maintainer
   </p>

From d379e775313a82756ca7033f707dea091d28eefd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?= <websnke@tutanota.com>
Date: Fri, 13 Oct 2023 09:23:56 +0300
Subject: [PATCH 596/749] Update
 maintaining-balance-for-open-source-maintainers.md

---
 ...ing-balance-for-open-source-maintainers.md | 35 ++++++++++---------
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index 8d29b5c8607..3e0bd610559 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -122,49 +122,49 @@ Dies wird für jeden Betreuer unterschiedlich sein und sich je nach Lebensphase
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+* **Ausruhen und regenerieren:** Nehmen Sie sich Zeit für Ihre Hobbys und Interessen außerhalb von Open Source. Nehmen Sie sich am Wochenende frei, um sich zu entspannen und zu erholen - und stellen Sie Ihren [GitHub-Status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) so ein, dass er Ihre Verfügbarkeit widerspiegelt! Erholsamer Schlaf kann einen großen Unterschied machen, wenn es darum geht, Ihre Leistung langfristig aufrechtzuerhalten.
 
   Wenn Ihnen bestimmte Aspekte Ihres Projekts besonders viel Spaß machen, versuchen Sie, Ihre Arbeit so zu strukturieren, dass Sie sie während des Tages erleben können.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+ Ich finde mehr Zeit, um "kreative Momente" in den Tag zu bringen, als dass ich versuche, am Abend abzuschalten.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+— <a href="https://github.com/danielroe">@danielroe</a>, Maintainer von Nuxt
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **Grenzen setzen:** Sie können nicht zu jeder Anfrage Ja sagen. Das kann so einfach sein, wie zu sagen: "Das kann ich im Moment nicht machen und ich habe auch nicht vor, es in Zukunft zu machen", oder in der README aufzulisten, was Sie gerne machen würden und was nicht. Sie könnten zum Beispiel sagen: "Ich führe nur PRs zusammen, die eine klare Begründung haben, warum sie gemacht wurden", oder "Ich überprüfe Probleme nur abwechselnd donnerstags von 18 - 19 Uhr". Das setzt Erwartungen für andere und gibt Ihnen etwas, auf das Sie zu anderen Zeiten verweisen können, um Forderungen von Mitwirkenden oder Benutzern nach Ihrer Zeit zu deeskalieren.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+Um auf diesen Säulen wirklich vertrauen zu können, darf man nicht zu jeder Anfrage Ja sagen. Wenn Sie das tun, halten Sie sich weder beruflich noch persönlich an Grenzen und werden kein verlässlicher Mitarbeiter sein.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, Maintainer von Homebrew zum [Nein-Sagen](https://mikemcquaid.com/saying-no/)
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+  Lernen Sie, giftiges Verhalten und negative Interaktionen konsequent zu unterbinden. Es ist in Ordnung, keine Energie für Dinge aufzuwenden, die Ihnen egal sind.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-My software is gratis, but my time and attention is not.
+Meine Software ist gratis, aber meine Zeit und Aufmerksamkeit sind es nicht.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, Maintainer von Leaflet
   </p>
 </aside>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+Es ist kein Geheimnis, dass die Entwicklung von Open-Source-Projekten auch ihre Schattenseiten hat, und eine davon ist, dass man manchmal mit undankbaren, überheblichen oder regelrecht toxischen Leuten interagieren muss. Mit zunehmender Popularität eines Projekts steigt auch die Häufigkeit dieser Interaktion, was die Belastung der Maintainer erhöht und möglicherweise zu einem bedeutenden Risikofaktor für ein Burnout der Maintainer wird.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>, Maintainer von Octoprint zu [Umgang mit toxischen Leuten](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
 </aside>
 
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+Denken Sie daran, dass persönliche Ökologie eine fortlaufende Praxis ist, die sich im Laufe Ihrer Open-Source-Reise weiterentwickeln wird. Indem Sie Ihre Selbstfürsorge in den Vordergrund stellen und ein Gleichgewicht aufrechterhalten, können Sie einen effektiven und nachhaltigen Beitrag zur Open-Source-Gemeinschaft leisten und sowohl Ihr Wohlbefinden als auch den Erfolg Ihrer Projekte auf lange Sicht sicherstellen.
 
-## Additional Resources
+## Weitere Artikel
 
 * [Maintainer Community](http://maintainers.github.com/)
 * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
@@ -177,11 +177,11 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
 * Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
 
-## Contributors
+## Mitwirkende
 
-Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+Vielen Dank an alle Maintainer, die uns ihre Erfahrungen und Tipps für diesen Leitfaden zur Verfügung gestellt haben!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+Dieser Leitfaden wurde von [@abbycabs](https://github.com/abbycabs) geschrieben mit Beiträgen von: 
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
@@ -218,4 +218,5 @@ This guide was written by [@abbycabs](https://github.com/abbycabs) with contribu
 [@thisisnic](https://github.com/thisisnic)
 [@tudoramariei](https://github.com/tudoramariei)
 [@UlisesGascon](https://github.com/UlisesGascon)
-[@waldyrious](https://github.com/waldyrious) + many others!
+[@waldyrious](https://github.com/waldyrious)
+[@WebSnke(https://github.com/WebSnke)] + vielen anderen!

From cca727699824b8d58ebefc93471d6153c6224ea7 Mon Sep 17 00:00:00 2001
From: Joseph Hale <me@jhale.dev>
Date: Fri, 13 Oct 2023 21:28:11 -0700
Subject: [PATCH 597/749] Incorporate feedback into legal.md

---
 _articles/legal.md | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/_articles/legal.md b/_articles/legal.md
index 77a0f4fe245..b124e1e4477 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -12,7 +12,7 @@ related:
 
 ## Understanding the legal implications of open source
 
-Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this legal crash course you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this guide you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).)
 
 ## Why do people care so much about the legal side of open source?
 
@@ -20,7 +20,7 @@ Glad you asked! When you make a creative work (such as writing, graphics, or cod
 
 In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
 
-Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly state these permissions in a document called a license.
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly give these permissions with a license.
 
 These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions.
 
@@ -40,7 +40,7 @@ If you want others to use, distribute, modify, or contribute back to your projec
 
 You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
 
-[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 the [most popular open source licenses](https://libraries.io/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/).
+[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/).
 
@@ -60,17 +60,17 @@ Otherwise, picking the right open source license for your project depends on you
 
 Your project very likely has (or will have) **dependencies**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm).
 
-* **"Permissive" licenses** give you permission to use, modify, and share the library without any conditions on how you license your project. Common permissive licenses include [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause).
-* **"Limited copyleft" licenses** (sometimes called "weak copyleft") are similar to permissive licenses -- generally your project can use whatever license you want -- but modifications to the library itself must be shared under an identical/compatible license. Common limited copyleft licenses include the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and the [LGPL](https://choosealicense.com/licenses/lgpl-3.0/).
-* **"Strong copyleft" licenses** also give you permission to use, modify, and share the library, but only if your project uses an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses). Common strong copyleft licenses include [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), and [AGPLv3](https://choosealicense.com/licenses/agpl-3.0).
+Dependencies with **permissive licenses** like [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause) allow you to license your project however you want.
 
+Dependencies with **copyleft licenses** require closer attention. Including any library with a "strong" copyleft license like the [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), or [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) requires you to choose an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) for your project. Libraries with a "limited" or "weak" copyleft license like the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) can be included in projects with any license, provided you follow the [additional rules](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) they specify.
+ 
 You may also want to consider the **communities** you hope will use and contribute to your project:
 
 * **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
-* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors and the ability to use the project in proprietary software. In this case, the permissive [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) or the limited copyleft [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) has you (and them) covered.
+* **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) (and them) covered.
 * **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
 
-Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive or limited copyleft license so your project can be used in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+Your **company** may have policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance.
 
 When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
 
@@ -86,7 +86,7 @@ For example, as your project grows it adds dependencies or users, or your compan
 
 **Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? [People who have commits in your project](https://github.com/thehale/git-authorship) is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
 
-Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- [see below](#does-my-project-need-an-additional-contributor-agreement)) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+Alternatively, you can have contributors pre-approve certain license changes via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)). This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
 
 ## Does my project need an additional contributor agreement?
 

From f03a50462ab7d2bfb15cc16eb32ed59343b3d663 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?= <websnke@tutanota.com>
Date: Sat, 14 Oct 2023 10:48:38 +0300
Subject: [PATCH 598/749] Update
 _articles/de/maintaining-balance-for-open-source-maintainers.md

Co-authored-by: Eric Sorenson <ahpook@github.com>
---
 _articles/de/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index 3e0bd610559..a16f77db2d2 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -219,4 +219,4 @@ Dieser Leitfaden wurde von [@abbycabs](https://github.com/abbycabs) geschrieben
 [@tudoramariei](https://github.com/tudoramariei)
 [@UlisesGascon](https://github.com/UlisesGascon)
 [@waldyrious](https://github.com/waldyrious)
-[@WebSnke(https://github.com/WebSnke)] + vielen anderen!
+[@WebSnke](https://github.com/WebSnke) + vielen anderen!

From c82ffc6750b46c1c1a5849e3f9495b06225021cf Mon Sep 17 00:00:00 2001
From: Xudong Guo <guoxd@jihulab.com>
Date: Mon, 16 Oct 2023 16:55:16 +0800
Subject: [PATCH 599/749] docs: add zh-hans translation for
 maintaining-balance-for-open-source-maintainers

---
 ...ing-balance-for-open-source-maintainers.md | 134 +++++++++---------
 1 file changed, 67 insertions(+), 67 deletions(-)

diff --git a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
index df51babccb0..12db80a802d 100644
--- a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
@@ -1,187 +1,187 @@
 ---
 lang: zh-hans
 untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+title: 保持开源维护者的平衡
+description: 作为维护者的自我护理和避免倦怠的技巧。
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+当一个开源项目越来越受欢迎时，设定清晰的边界来帮助您长时间保持活力和生产力就变得尤为重要了。
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+为了深入了解维护者的经验及他们如何找到工作平衡，我们与<a href="http://maintainers.github.com/">维护者社区</a>的 40 名成员举办了一个 workshop。通过这样的方式，我们得以学习到他们在开源领域所经历的疲劳过度的第一手情况，以及他们采取了哪些实践来在工作中维持平衡。这正是“个人生态学”概念得以应用的场景。
 
-So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+那么，个人生态学是什么？根据 <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">Rockwood Leadership Institute 的描述</a>，它是“<strong>在我们的一生中，维持平衡、节奏和效率以保持能量</strong>”。这种观点为我们的交流提供了一个结构，帮助维护者意识到随时间发展，他们的行为和贡献是一个更大的生态系统中的组成部分。根据[世卫组织的定义](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281)，由长时间的工作压力引起的综合症状，即“疲劳过度”，在维护者中并不罕见。这常常会导致失去工作动力、无法集中精力，以及对与之合作的贡献者和社区感到缺乏同情和理解。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
-  I was unable to focus or start on a task. I had a lack of empathy for users.
+  我无法集中注意力或开始任务。我对用户缺乏同情心。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>，Owncast 直播服务的维护者，谈到疲劳对他的开源工作的影响
   </p>
 </aside>
 
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+通过理解个人生态学的理念，维护者可以主动避免疲劳，把自我护理放在首位，并保持心态平和，从而更好地工作。
 
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+## 作为维护者的自我护理和避免疲劳的提示：
 
-### Identify your motivations for working in open source
+### 确定您参与开源工作的动机
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+花时间思考哪些开源维护任务能激发您的热情。明白自己的驱动力可以帮您更有针对性地安排工作，保持热情并随时迎接新挑战。不论是用户的正面反馈、与社区的互动乐趣，还是深入探索代码带来的成就感，了解这些驱动力都能帮助您更好地集中精力。
 
-### Reflect on what causes you to get out of balance and stressed out
+### 反思什么使您失去平衡并感到压力
 
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+知道哪些因素导致我们感到疲倦是非常关键的。以下是在开源维护者中常见的一些情况：
 
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+* **缺乏积极的反馈：** 用户在遇到问题时更容易给出反馈。而当一切正常时，他们往往不会说什么。看到问题列表不断增长，而缺乏正面反馈来展示您的贡献所带来的改变，这可能会让人感到挫败。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
-  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  有时，我觉得自己有点像在虚空中大喊大叫，但我发现反馈意见真的让我充满活力。我们有很多快乐但安静的用户。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+— <a href="https://github.com/thisisnic">@thisisnic</a>，Apache Arrow 的维护者
   </p>
 </aside>
 
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **不说'不'：** 在开源项目中，很容易承担超过自己能力范围的责任。不论是来自用户、贡献者还是其他维护者，我们不能始终满足每个人的期望。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
-  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  我发现自己承担的工作超出了一个人的职责范围，不得不像 FOSS 中常见的那样，完成多人的工作。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>，Termux 的维护者，谈论他们工作中导致疲劳的原因
   </p>
 </aside>
 
-* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+* **独自工作：** 作为维护者可能会感到很孤单。即使你与一群维护者合作，过去几年也很难召集分布在各地的团队。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
- Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+ 特别是自从 COVID 和居家办公后，再也见不到人或和人说话就更难了。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>，Owncast 直播服务器的维护者，谈论疲劳对他的开源工作的影响
   </p>
 </aside>
 
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **时间或资源不足：** 对于那些不得不牺牲自己休息时间来参与项目的志愿维护者来说，这尤其是真实的。
 
 <aside markdown="1" class="pquote">
-  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  [我希望]能得到更多的经济支持，这样我可以全心投入到开源工作中，而不是消耗掉自己的储蓄，然后担心未来需要做大量的工作来补偿这一损失。
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— 开源维护者
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **需求冲突：** 开源社区有很多出于不同目的而参与的团队，这有时会难以处理。如果您是被雇来进行开源工作的，那么您的雇主的利益有时与社区的利益可能不会完全一致。
 
 <aside markdown="1" class="pquote">
-  With paid open source, conflict between employer's focus and what's best for the community
+  在有偿的开源工作中，雇主的关注点和对社区最有益的事物之间可能会存在矛盾。
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— 开源维护者
   </p>
 </aside>
 
-### Watch out for signs of burnout
+### 注意疲劳的迹象
 
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+这样的节奏你能保持多久？10周？10个月？还是10年？
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+有像 [@shaunagm](https://github.com/shaunagm) 的 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) 和 Mozilla 的[个人生态自评工具包](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw)这样的工具可以帮助你反思自己现在的工作节奏，看是否需要进行某些调整。一些维护者还利用可穿戴设备来监测睡眠质量和心率变异性等与压力有关的指标。
 
 <aside markdown="1" class="pquote">
- I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+ 我深信好的可穿戴设备的作用。有了其背后的科学依据，你可以了解如何更好地调整自己，达到完成任务的最佳状态。
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— 开源维护者
   </p>
 </aside>
 
-### What would you need to continue sustaining yourself and your community?
+### 您需要什么来继续支撑自己和您的社区？
 
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+对每位维护者而言，这都会有所区别，并且会随着您的生活阶段和其他外部因素发生变化。但以下是我们收到的一些共同点：
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **依赖社区：** 分配任务和寻找贡献者可以帮助减轻你的负担。对一个项目而言，有多个协作者能让你放心休息。与其他维护者以及更广大的社区，如 [Maintainer Community](http://maintainers.github.com/) 建立联系，这对于获得同行的支持和学习都是宝贵的资源。
 
-  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+  您还可以探索与用户社区的交互方式，这样可以定期收到反馈，了解您在开源工作中所做的贡献的影响。
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **寻找资金：** 不管您是想找点小钱买披萨，还是计划全职投身开源，都有众多资源可供参考！首先，可以考虑开通 [GitHub Sponsors](https://github.com/sponsors) 让其他人赞助您的开源项目。如果您打算全职转型，可以申请下一期的 [GitHub Accelerator](http://accelerator.github.com/)。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
- I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+我曾参与一个播客，其中我们谈到了开源维护和可持续性。我发现，尽管只有少数人支持我在 GitHub 的工作，但这也帮助我做出了迅速的选择，放下游戏前端的工作转而去做一些小的开源贡献。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+— <a href="https://github.com/mansona">@mansona</a>，EmberJS 的维护者
   </p>
 </aside>
 
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+* **使用工具：** 考虑使用像 [GitHub Copilot](https://github.com/features/copilot/) 和 [GitHub Actions](https://github.com/features/actions) 这样的工具，自动化常规任务，从而为更有价值的工作腾出时间。
 
 <aside markdown="1" class="pquote">
- Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+ 使用 [Copilot](https://github.com/features/copilot/) 来处理无聊的事情 - 做有趣的事情
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— 开源维护者
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+* **休息和充电：** 留出时间享受开源之外的爱好和兴趣。利用周末休息和充电，并调整您的 [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) 来显示您是否在线！良好的睡眠对于长期保持工作热情和效率至关重要。
 
-  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+  如果您发现项目中某些部分特别令人享受，试着调整您的工作，这样您每天都可以体验到这种愉悦。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+我发现在一天当中找到更多机会去散播“创意时刻”比起在晚上尝试放松更为有益。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+— <a href="https://github.com/danielroe">@danielroe</a>，Nuxt 的维护者
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **设定界限：** 您不能对每个请求都回应“好”。您可以简单地回答：“我现在做不到，而且未来可能也不会这么做。”或者在 README 中明确列出您愿意做和不愿意做的事情。例如，您可以写：“我只会合并那些清晰解释了为何创建的 PR。”或者，“我只在每两周的星期四的6-7点审查问题。”这样可以为他人设定预期，并在其他时间为您提供一个可以参考的依据，从而减少贡献者或用户对您时间的要求。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+为了在这些方面真正赢得他人的信任，你不能是一个对每个请求都说“是”的人。这样做意味着你没有设定职业和个人的界限，也难以成为一个可靠的合作伙伴。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>，Homebrew 的维护者在 [Saying No](https://mikemcquaid.com/saying-no/) 上
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+学会坚决制止有毒的行为和消极的互动。不对你不在乎的事情投入精力是完全可以的。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-My software is gratis, but my time and attention is not.
+我的软件是免费的，但我的时间和精力不是。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>，Leaflet 的维护者
   </p>
 </aside>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+开源代码维护工作有其阴暗面，这已经不是什么秘密了，其中之一就是有时不得不与那些忘恩负义、有权有势或完全有毒的人打交道。随着项目受欢迎程度的提高，这种互动的频率也会增加，从而加重维护者的负担，并可能成为维护者倦怠的一个重要风险因素。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>，Octoprint 的维护者，在[如何应对有毒的人](https://www.youtube.com/watch?v=7lIpP3GEyXs)上
   </p>
 </aside>
 
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+请记住，个人生态是随着您在开源之旅中不断前行而演变的持续实践。通过把自我护理和保持平衡放在首位，您可以为开源社区提供持续有效的贡献，确保自己的健康和项目的长久发展。
 
-## Additional Resources
+## 额外资源
 
 * [Maintainer Community](http://maintainers.github.com/)
-* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
-* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
-* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [开源的社会契约](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [如何应对有毒的人](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
-* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [个人生态自评工具包](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood领导艺术](https://rockwoodleadership.org/art-of-leadership/)
+* [说“不”](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
-* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+* Workshop 议程改编自 [Mozilla’s Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) 系列活动
 
-## Contributors
+## 贡献者
 
-Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+非常感谢所有与我们分享经验和技巧的维护者！
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+本指南是由[@abbycabs](https://github.com/abbycabs)编写的，由以下人员贡献：
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)

From 15ea2dcb3c8b42e45540bb74aba2ce2a00fb75b1 Mon Sep 17 00:00:00 2001
From: Xudong Guo <guoxd@jihulab.com>
Date: Mon, 16 Oct 2023 17:07:50 +0800
Subject: [PATCH 600/749] fixed warnings

---
 ...ntaining-balance-for-open-source-maintainers.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
index 12db80a802d..e4996e13c30 100644
--- a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
@@ -10,9 +10,9 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 
 当一个开源项目越来越受欢迎时，设定清晰的边界来帮助您长时间保持活力和生产力就变得尤为重要了。
 
-为了深入了解维护者的经验及他们如何找到工作平衡，我们与<a href="http://maintainers.github.com/">维护者社区</a>的 40 名成员举办了一个 workshop。通过这样的方式，我们得以学习到他们在开源领域所经历的疲劳过度的第一手情况，以及他们采取了哪些实践来在工作中维持平衡。这正是“个人生态学”概念得以应用的场景。
+为了深入了解维护者的经验及他们如何找到工作平衡，我们与<a href="http://maintainers.github.com/">维护者社区</a>的 40 名成员举办了一个 workshop。通过这样的方式，我们得以学习到他们在开源领域所经历的疲劳过度的第一手情况，以及他们采取了哪些实践来在工作中维持平衡。这正是"个人生态学"概念得以应用的场景。
 
-那么，个人生态学是什么？根据 <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">Rockwood Leadership Institute 的描述</a>，它是“<strong>在我们的一生中，维持平衡、节奏和效率以保持能量</strong>”。这种观点为我们的交流提供了一个结构，帮助维护者意识到随时间发展，他们的行为和贡献是一个更大的生态系统中的组成部分。根据[世卫组织的定义](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281)，由长时间的工作压力引起的综合症状，即“疲劳过度”，在维护者中并不罕见。这常常会导致失去工作动力、无法集中精力，以及对与之合作的贡献者和社区感到缺乏同情和理解。
+那么，个人生态学是什么？根据 <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">Rockwood Leadership Institute 的描述</a>，它是"<strong>在我们的一生中，维持平衡、节奏和效率以保持能量</strong>”。这种观点为我们的交流提供了一个结构，帮助维护者意识到随时间发展，他们的行为和贡献是一个更大的生态系统中的组成部分。根据[世卫组织的定义](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281)，由长时间的工作压力引起的综合症状，即"疲劳过度"，在维护者中并不罕见。这常常会导致失去工作动力、无法集中精力，以及对与之合作的贡献者和社区感到缺乏同情和理解。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
@@ -128,17 +128,17 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
-我发现在一天当中找到更多机会去散播“创意时刻”比起在晚上尝试放松更为有益。
+我发现在一天当中找到更多机会去散播"创意时刻"比起在晚上尝试放松更为有益。
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/danielroe">@danielroe</a>，Nuxt 的维护者
   </p>
 </aside>
 
-* **设定界限：** 您不能对每个请求都回应“好”。您可以简单地回答：“我现在做不到，而且未来可能也不会这么做。”或者在 README 中明确列出您愿意做和不愿意做的事情。例如，您可以写：“我只会合并那些清晰解释了为何创建的 PR。”或者，“我只在每两周的星期四的6-7点审查问题。”这样可以为他人设定预期，并在其他时间为您提供一个可以参考的依据，从而减少贡献者或用户对您时间的要求。
+* **设定界限：** 您不能对每个请求都回应"好"。您可以简单地回答："我现在做不到，而且未来可能也不会这么做。"或者在 README 中明确列出您愿意做和不愿意做的事情。例如，您可以写："我只会合并那些清晰解释了为何创建的 PR。”或者，"我只在每两周的星期四的6-7点审查问题。”这样可以为他人设定预期，并在其他时间为您提供一个可以参考的依据，从而减少贡献者或用户对您时间的要求。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-为了在这些方面真正赢得他人的信任，你不能是一个对每个请求都说“是”的人。这样做意味着你没有设定职业和个人的界限，也难以成为一个可靠的合作伙伴。
+为了在这些方面真正赢得他人的信任，你不能是一个对每个请求都说"是"的人。这样做意味着你没有设定职业和个人的界限，也难以成为一个可靠的合作伙伴。
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/mikemcquaid">@mikemcquaid</a>，Homebrew 的维护者在 [Saying No](https://mikemcquaid.com/saying-no/) 上
   </p>
@@ -173,9 +173,9 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 * [SustainOSS](https://sustainoss.org/)
 * [个人生态自评工具包](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood领导艺术](https://rockwoodleadership.org/art-of-leadership/)
-* [说“不”](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [说"不"](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
-* Workshop 议程改编自 [Mozilla’s Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) 系列活动
+* Workshop 议程改编自 [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) 系列活动
 
 ## 贡献者
 

From 083b57dd81f549bf4b5691392c23f1dce46b7309 Mon Sep 17 00:00:00 2001
From: Rodney Guillen <infrony@gmail.com>
Date: Mon, 16 Oct 2023 17:33:30 -0500
Subject: [PATCH 601/749] Update to es
 maintaining-balance-for-open-source-maintainers.md

---
 ...ing-balance-for-open-source-maintainers.md | 137 +++++++++---------
 1 file changed, 69 insertions(+), 68 deletions(-)

diff --git a/_articles/es/maintaining-balance-for-open-source-maintainers.md b/_articles/es/maintaining-balance-for-open-source-maintainers.md
index 776f4487381..aa82e1e204e 100644
--- a/_articles/es/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/es/maintaining-balance-for-open-source-maintainers.md
@@ -1,187 +1,188 @@
 ---
 lang: es
 untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+title: Mantener el equilibrio para los mantenedores de código abierto
+description: Consejos para el autocuidado y evitar el agotamiento como mantenedor.
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+A medida que un proyecto de código abierto gana popularidad, se vuelve importante establecer límites claros para ayudarte a mantener el equilibrio y mantenerte fresco y productivo a largo plazo.
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+Para obtener información sobre las experiencias de los mantenedores y sus estrategias para encontrar el equilibrio, realizamos un taller con 40 miembros de la <a href="http://maintainers.github.com/">Comunidad de Mantenedores</a>, lo que nos permitió aprender de sus experiencias de primera mano con el agotamiento en el código abierto y las prácticas que les han ayudado a mantener el equilibrio en su trabajo. Aquí es donde entra en juego el concepto de ecología personal.
 
-So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+Entonces, ¿qué es la ecología personal? Como <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">describió el Instituto de Liderazgo Rockwood</a>, implica "<strong>mantener el equilibrio, el ritmo y la eficiencia para mantener nuestra energía a lo largo de toda nuestra vida</strong>." Esto enmarcó nuestras conversaciones, ayudando a los mantenedores a reconocer sus acciones y contribuciones como parte de un ecosistema más amplio que evoluciona con el tiempo. El agotamiento, un síndrome resultante del estrés crónico en el lugar de trabajo según lo <a href="https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281">definido por la OMS</a>, no es infrecuente entre los mantenedores. Esto a menudo conduce a una pérdida de motivación, una incapacidad para concentrarse y una falta de empatía hacia los contribuyentes y la comunidad con la que trabajas.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
-  I was unable to focus or start on a task. I had a lack of empathy for users.
+  No podía concentrarme ni comenzar una tarea. Tenía falta de empatía hacia los usuarios.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, mantenedor del servidor de transmisión en vivo Owncast, sobre el impacto del agotamiento en su trabajo de código abierto
   </p>
 </aside>
 
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+Al abrazar el concepto de ecología personal, los mantenedores pueden evitar el agotamiento de manera proactiva, priorizar el autocuidado y mantener un sentido de equilibrio para hacer su mejor trabajo.
 
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+## Consejos para el autocuidado y evitar el agotamiento como mantenedor:
 
-### Identify your motivations for working in open source
+### Identifica tus motivaciones para trabajar en código abierto
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+Tómate un tiempo para reflexionar sobre qué partes del mantenimiento de código abierto te energizan. Comprender tus motivaciones puede ayudarte a priorizar el trabajo de una manera que te mantenga comprometido y listo para enfrentar nuevos desafíos. Ya sea por los comentarios positivos de los usuarios, la alegría de colaborar y socializar con la comunidad o la satisfacción de sumergirte en el código, reconocer tus motivaciones puede ayudarte a dirigir tu enfoque.
 
-### Reflect on what causes you to get out of balance and stressed out
+### Reflexiona sobre lo que te lleva a desequilibrarte y estresarte
 
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+Es importante entender qué nos lleva al agotamiento. Aquí hay algunas temas comunes que vimos entre los mantenedores de código abierto:
 
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+* **Falta de comentarios positivos:** Los usuarios son mucho más propensos a comunicarse cuando tienen una queja. Si todo funciona bien, tienden a quedarse en silencio. Puede ser desalentador ver una creciente lista de problemas sin los comentarios positivos que muestren cómo tus contribuciones están marcando la diferencia.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
-  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  A veces se siente un poco como gritar en el vacío y encuentro que los comentarios realmente me energizan. Tenemos muchos usuarios felices pero callados.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+— <a href="https://github.com/thisisnic">@thisisnic</a>, mantenedor de Apache Arrow
   </p>
 </aside>
 
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **No decir 'no':** Puede ser fácil asumir más responsabilidades de las que deberías en un proyecto de código abierto. Ya sea de usuarios, contribuyentes u otros mantenedores, no siempre podemos cumplir con sus expectativas.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
-  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  Descubrí que estaba asumiendo más de lo que uno debería y teniendo que hacer el trabajo de varias personas, como comúnmente se hace en el software de código abierto.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, mantenedor de Termux, sobre lo que causa el agotamiento en su trabajo
   </p>
 </aside>
 
-* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+* **Trabajar solo:** Ser un mantenedor puede ser increíblemente solitario. Incluso si trabajas con un grupo de mantenedores, los últimos años han sido difíciles para reunir equipos distribuidos en persona.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
- Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  Especialmente desde la COVID-19 y el trabajo desde casa, es más difícil no ver a nadie ni hablar con nadie.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, mantenedor del servidor de transmisión en vivo Owncast, sobre el impacto del agotamiento en su trabajo de código abierto
   </p>
 </aside>
 
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **Falta de tiempo o recursos:** Esto es especialmente cierto para los mantenedores voluntarios que tienen que sacrificar su tiempo libre para trabajar en un proyecto.
 
 <aside markdown="1" class="pquote">
-  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  [Me gustaría tener] más apoyo financiero, para poder enfocarme en el trabajo de código abierto sin gastar mis ahorros y sabiendo que tendré que hacer muchos contratos para compensarlo más tarde.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— mantenedor de código abierto
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Demandas en conflicto:** El código abierto está lleno de grupos con diferentes motivaciones, lo que puede ser difícil de navegar. Si te pagan por hacer código abierto, los intereses de tu empleador a veces pueden entrar en conflicto con la comunidad.
 
 <aside markdown="1" class="pquote">
-  With paid open source, conflict between employer's focus and what's best for the community
+  Con el código abierto pagado, conflicto entre el enfoque del empleador y lo que es mejor para la comunidad.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— mantenedor de código abierto
   </p>
 </aside>
 
-### Watch out for signs of burnout
+### Esté atento a los signos de agotamiento
 
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+¿Puedes mantener tu ritmo durante 10 semanas? ¿10 meses? ¿10 años?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+Existen herramientas como la [Lista de verificación de agotamiento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) y el [kit de autoevaluación de ecología personal de Mozilla](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que pueden ayudarte a reflexionar sobre tu ritmo actual y ver si hay ajustes que puedas hacer. Algunos mantenedores también utilizan tecnología portátil para realizar un seguimiento de métricas como la calidad del sueño y la variabilidad de la frecuencia cardíaca (ambas vinculadas al estrés).
 
 <aside markdown="1" class="pquote">
- I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  Soy un gran creyente en las buenas tecnologías portátiles. Con la ciencia detrás de ello, puedes entender cómo podrías haberlo hecho mejor y cómo llegar a un estado óptimo de lo que quieres hacer.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— mantenedor de código abierto
   </p>
 </aside>
 
-### What would you need to continue sustaining yourself and your community?
+### ¿Qué necesitarías para seguir sosteniéndote a ti mismo y a tu comunidad?
 
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+Esto será diferente para cada mantenedor y cambiará según tu fase de vida y otros factores externos. Pero aquí hay algunas temas que escuchamos:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **Apóyate en la comunidad:** Delegar y encontrar colaboradores puede aliviar la carga de trabajo. Tener múltiples puntos de contacto para un proyecto puede ayudarte a tomar un descanso sin preocupaciones. Conéctate con otros mantenedores y la comunidad en general, en grupos como la [Comunidad de Mantenedores](http://maintainers.github.com/). Esto puede ser un gran recurso para el apoyo entre pares y el aprendizaje.
 
-  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+  También puedes buscar formas de involucrarte con la comunidad de usuarios para escuchar regularmente comentarios y comprender el impacto de tu trabajo de código abierto.
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **Explora financiamiento:** Ya sea que estés buscando algo de dinero extra o tratando de dedicarte por completo al código abierto, ¡hay muchos recursos para ayudarte! Como primer paso, considera activar [Patrocinadores de GitHub](https://github.com/sponsors) para permitir que otros patrocinen tu trabajo de código abierto. Si estás pensando en dar el salto a tiempo completo, solicita la próxima ronda del [Acelerador de GitHub](http://accelerator.github.com/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
- I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  Estuve en un podcast hace un tiempo y estábamos hablando sobre el mantenimiento de código abierto y la sostenibilidad. Descubrí que incluso un pequeño número de personas que apoyan mi trabajo en GitHub me ayudó a tomar una decisión rápida de no sentarme frente a un juego, sino de hacer una pequeña cosa con el código abierto.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+— <a href="https://github.com/mansona">@mansona</a>, mantenedor de EmberJS
   </p>
 </aside>
 
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+* **Utiliza herramientas:** Explora herramientas como [GitHub Copilot](https://github.com/features/copilot/) y [GitHub Actions](https://github.com/features/actions/) para automatizar tareas mundanas y liberar tu tiempo para contribuciones más significativas.
 
 <aside markdown="1" class="pquote">
- Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  Usa [Copilot](https://github.com/features/copilot/) para las cosas aburridas; haz las cosas divertidas.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— mantenedor de código abierto
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+* **Descansa y recarga energías:** Dedica tiempo a tus pasatiempos e intereses fuera del código abierto. ¡Tómate los fines de semana libres para relajarte y rejuvenecer, y establece tu [estado de GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) para reflejar tu disponibilidad! Una buena noche de sueño puede marcar una gran diferencia en tu capacidad para mantener tus esfuerzos a largo plazo.
 
-  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+  Si encuentras que ciertos aspectos de tu proyecto son especialmente gratificantes, trata de estructurar tu trabajo para que puedas experimentarlos a lo largo del día.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  Estoy encontrando más oportunidades para "momentos de creatividad" en medio del día en lugar de intentar desconectar por la noche.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+— <a href="https://github.com/danielroe">@danielroe</a>, mantenedor de Nuxt
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **Establece límites:** No puedes decir que sí a todas las solicitudes. Esto puede ser tan simple como decir: "No puedo ocuparme de eso en este momento y no tengo planes de hacerlo en el futuro", o listar lo que estás interesado en hacer y lo que no en el README. Por ejemplo, podrías decir: "Solo fusiono PR que tengan razones claramente enumeradas por las que se hicieron", o "Solo reviso problemas los jueves alternos de 6 a 7 pm". Esto establece expectativas para los demás y te da algo a lo que puedes hacer referencia en otros momentos para ayudar a reducir las demandas de los contribuyentes o usuarios sobre tu tiempo.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  Para confiar de manera significativa en otros en estos aspectos, no puedes ser alguien que diga sí a todas las solicitudes. Al hacerlo, no mantienes límites, profesional o personalmente, y no serás un compañero confiable.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, mantenedor de Homebrew sobre [Cómo decir no](https://mikemcquaid.com/saying-no/)
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+  Aprende a ser firme en la eliminación del comportamiento tóxico y las interacciones negativas. Está bien no dar energía a las cosas que no te importan.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-My software is gratis, but my time and attention is not.
+  Mi software es gratuito, pero mi tiempo y atención no lo son.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, mantenedor de Leaflet
   </p>
 </aside>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  No es un secreto que el mantenimiento de código abierto tiene sus lados oscuros, y uno de ellos es tener que interactuar a veces con personas bastante ingratas, exigentes o directamente tóxicas. A medida que aumenta la popularidad de un proyecto, también aumenta la frecuencia de este tipo de interacción, lo que añade una carga adicional a los mantenedores y posiblemente se convierte en un factor de riesgo significativo para el agotamiento de los mantenedores.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>, mantenedor de Octoprint sobre [Cómo lidiar con personas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
 </aside>
 
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+Recuerda, la ecología personal es una práctica continua que evolucionará a medida que avances en tu viaje de código abierto. Al priorizar el autocuidado y mantener un sentido de equilibrio, puedes contribuir eficazmente a la comunidad de código abierto de manera sostenible, asegurando tanto tu bienestar como el éxito de tus proyectos a largo plazo.
 
-## Additional Resources
+## Recursos adicionales
 
-* [Maintainer Community](http://maintainers.github.com/)
-* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
-* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
-* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [Comunidad de Mantenedores](http://maintainers.github.com/)
+* [El contrato social del código abierto](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [Cómo lidiar con personas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Kit de autoevaluación de ecología personal](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
-* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
-* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+* [Cómo decir no](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Gobernanza del Código Abierto](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* La agenda del taller se basó en [Movimiento de construcción desde casa de Mozilla](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org)
 
-## Contributors
+## Colaboradores
 
-Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+¡Muchas gracias a todos los mantenedores que compartieron sus experiencias y consejos con nosotros para esta guía!
+
+Esta guía fue escrita por [@abbycabs](https://github.com/abbycabs) con contribuciones de:
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)

From 7cfe1967254fe80ac3d1c0f00317099adad808eb Mon Sep 17 00:00:00 2001
From: Rodney Guillen <infrony@gmail.com>
Date: Mon, 16 Oct 2023 17:34:10 -0500
Subject: [PATCH 602/749] Update
 maintaining-balance-for-open-source-maintainers.md

---
 _articles/es/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/es/maintaining-balance-for-open-source-maintainers.md b/_articles/es/maintaining-balance-for-open-source-maintainers.md
index aa82e1e204e..b2cf35edd64 100644
--- a/_articles/es/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/es/maintaining-balance-for-open-source-maintainers.md
@@ -219,4 +219,4 @@ Esta guía fue escrita por [@abbycabs](https://github.com/abbycabs) con contribu
 [@thisisnic](https://github.com/thisisnic)
 [@tudoramariei](https://github.com/tudoramariei)
 [@UlisesGascon](https://github.com/UlisesGascon)
-[@waldyrious](https://github.com/waldyrious) + many others!
+[@waldyrious](https://github.com/waldyrious) + muchos más!

From db04f5449d85f18fce724d97c1b7c9f244e29c83 Mon Sep 17 00:00:00 2001
From: Rodney Guillen <infrony@gmail.com>
Date: Mon, 16 Oct 2023 17:55:06 -0500
Subject: [PATCH 603/749] Update
 maintaining-balance-for-open-source-maintainers.md

fix 1 line before node
---
 _articles/es/maintaining-balance-for-open-source-maintainers.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/_articles/es/maintaining-balance-for-open-source-maintainers.md b/_articles/es/maintaining-balance-for-open-source-maintainers.md
index b2cf35edd64..6efa7100d23 100644
--- a/_articles/es/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/es/maintaining-balance-for-open-source-maintainers.md
@@ -183,7 +183,6 @@ Recuerda, la ecología personal es una práctica continua que evolucionará a me
 
 Esta guía fue escrita por [@abbycabs](https://github.com/abbycabs) con contribuciones de:
 
-
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
 [@antfu](https://github.com/antfu)

From 204180e89aad19d11a1b9df8bacfe1552f8cda62 Mon Sep 17 00:00:00 2001
From: Rodney Guillen <infrony@gmail.com>
Date: Mon, 16 Oct 2023 18:09:09 -0500
Subject: [PATCH 604/749] Update
 maintaining-balance-for-open-source-maintainers.md

change mantenedor to contribuidor
---
 ...ing-balance-for-open-source-maintainers.md | 58 +++++++++----------
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/_articles/es/maintaining-balance-for-open-source-maintainers.md b/_articles/es/maintaining-balance-for-open-source-maintainers.md
index 6efa7100d23..be5df5ff614 100644
--- a/_articles/es/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/es/maintaining-balance-for-open-source-maintainers.md
@@ -1,8 +1,8 @@
 ---
 lang: es
 untranslated: true
-title: Mantener el equilibrio para los mantenedores de código abierto
-description: Consejos para el autocuidado y evitar el agotamiento como mantenedor.
+title: Mantener el equilibrio para los contribuidores de código abierto
+description: Consejos para el autocuidado y evitar el agotamiento como contribuidor.
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
@@ -10,21 +10,21 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 
 A medida que un proyecto de código abierto gana popularidad, se vuelve importante establecer límites claros para ayudarte a mantener el equilibrio y mantenerte fresco y productivo a largo plazo.
 
-Para obtener información sobre las experiencias de los mantenedores y sus estrategias para encontrar el equilibrio, realizamos un taller con 40 miembros de la <a href="http://maintainers.github.com/">Comunidad de Mantenedores</a>, lo que nos permitió aprender de sus experiencias de primera mano con el agotamiento en el código abierto y las prácticas que les han ayudado a mantener el equilibrio en su trabajo. Aquí es donde entra en juego el concepto de ecología personal.
+Para obtener información sobre las experiencias de los contribuidores y sus estrategias para encontrar el equilibrio, realizamos un taller con 40 miembros de la <a href="http://maintainers.github.com/">Comunidad de Contribuidores</a>, lo que nos permitió aprender de sus experiencias de primera mano con el agotamiento en el código abierto y las prácticas que les han ayudado a mantener el equilibrio en su trabajo. Aquí es donde entra en juego el concepto de ecología personal.
 
-Entonces, ¿qué es la ecología personal? Como <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">describió el Instituto de Liderazgo Rockwood</a>, implica "<strong>mantener el equilibrio, el ritmo y la eficiencia para mantener nuestra energía a lo largo de toda nuestra vida</strong>." Esto enmarcó nuestras conversaciones, ayudando a los mantenedores a reconocer sus acciones y contribuciones como parte de un ecosistema más amplio que evoluciona con el tiempo. El agotamiento, un síndrome resultante del estrés crónico en el lugar de trabajo según lo <a href="https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281">definido por la OMS</a>, no es infrecuente entre los mantenedores. Esto a menudo conduce a una pérdida de motivación, una incapacidad para concentrarse y una falta de empatía hacia los contribuyentes y la comunidad con la que trabajas.
+Entonces, ¿qué es la ecología personal? Como <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">describió el Instituto de Liderazgo Rockwood</a>, implica "<strong>mantener el equilibrio, el ritmo y la eficiencia para mantener nuestra energía a lo largo de toda nuestra vida</strong>." Esto enmarcó nuestras conversaciones, ayudando a los contribuidores a reconocer sus acciones y contribuciones como parte de un ecosistema más amplio que evoluciona con el tiempo. El agotamiento, un síndrome resultante del estrés crónico en el lugar de trabajo según lo <a href="https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281">definido por la OMS</a>, no es infrecuente entre los contribuidores. Esto a menudo conduce a una pérdida de motivación, una incapacidad para concentrarse y una falta de empatía hacia los contribuyentes y la comunidad con la que trabajas.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
   No podía concentrarme ni comenzar una tarea. Tenía falta de empatía hacia los usuarios.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, mantenedor del servidor de transmisión en vivo Owncast, sobre el impacto del agotamiento en su trabajo de código abierto
+— <a href="https://github.com/gabek">@gabek</a>, contribuidor del servidor de transmisión en vivo Owncast, sobre el impacto del agotamiento en su trabajo de código abierto
   </p>
 </aside>
 
-Al abrazar el concepto de ecología personal, los mantenedores pueden evitar el agotamiento de manera proactiva, priorizar el autocuidado y mantener un sentido de equilibrio para hacer su mejor trabajo.
+Al abrazar el concepto de ecología personal, los contribuidores pueden evitar el agotamiento de manera proactiva, priorizar el autocuidado y mantener un sentido de equilibrio para hacer su mejor trabajo.
 
-## Consejos para el autocuidado y evitar el agotamiento como mantenedor:
+## Consejos para el autocuidado y evitar el agotamiento como contribuidor:
 
 ### Identifica tus motivaciones para trabajar en código abierto
 
@@ -32,7 +32,7 @@ Tómate un tiempo para reflexionar sobre qué partes del mantenimiento de códig
 
 ### Reflexiona sobre lo que te lleva a desequilibrarte y estresarte
 
-Es importante entender qué nos lleva al agotamiento. Aquí hay algunas temas comunes que vimos entre los mantenedores de código abierto:
+Es importante entender qué nos lleva al agotamiento. Aquí hay algunas temas comunes que vimos entre los contribuidores de código abierto:
 
 * **Falta de comentarios positivos:** Los usuarios son mucho más propensos a comunicarse cuando tienen una queja. Si todo funciona bien, tienden a quedarse en silencio. Puede ser desalentador ver una creciente lista de problemas sin los comentarios positivos que muestren cómo tus contribuciones están marcando la diferencia.
 
@@ -40,36 +40,36 @@ Es importante entender qué nos lleva al agotamiento. Aquí hay algunas temas co
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
   A veces se siente un poco como gritar en el vacío y encuentro que los comentarios realmente me energizan. Tenemos muchos usuarios felices pero callados.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/thisisnic">@thisisnic</a>, mantenedor de Apache Arrow
+— <a href="https://github.com/thisisnic">@thisisnic</a>, contribuidor de Apache Arrow
   </p>
 </aside>
 
-* **No decir 'no':** Puede ser fácil asumir más responsabilidades de las que deberías en un proyecto de código abierto. Ya sea de usuarios, contribuyentes u otros mantenedores, no siempre podemos cumplir con sus expectativas.
+* **No decir 'no':** Puede ser fácil asumir más responsabilidades de las que deberías en un proyecto de código abierto. Ya sea de usuarios, contribuyentes u otros contribuidores, no siempre podemos cumplir con sus expectativas.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
   Descubrí que estaba asumiendo más de lo que uno debería y teniendo que hacer el trabajo de varias personas, como comúnmente se hace en el software de código abierto.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, mantenedor de Termux, sobre lo que causa el agotamiento en su trabajo
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, contribuidor de Termux, sobre lo que causa el agotamiento en su trabajo
   </p>
 </aside>
 
-* **Trabajar solo:** Ser un mantenedor puede ser increíblemente solitario. Incluso si trabajas con un grupo de mantenedores, los últimos años han sido difíciles para reunir equipos distribuidos en persona.
+* **Trabajar solo:** Ser un contribuidor puede ser increíblemente solitario. Incluso si trabajas con un grupo de contribuidores, los últimos años han sido difíciles para reunir equipos distribuidos en persona.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
   Especialmente desde la COVID-19 y el trabajo desde casa, es más difícil no ver a nadie ni hablar con nadie.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, mantenedor del servidor de transmisión en vivo Owncast, sobre el impacto del agotamiento en su trabajo de código abierto
+— <a href="https://github.com/gabek">@gabek</a>, contribuidor del servidor de transmisión en vivo Owncast, sobre el impacto del agotamiento en su trabajo de código abierto
   </p>
 </aside>
 
-* **Falta de tiempo o recursos:** Esto es especialmente cierto para los mantenedores voluntarios que tienen que sacrificar su tiempo libre para trabajar en un proyecto.
+* **Falta de tiempo o recursos:** Esto es especialmente cierto para los contribuidores voluntarios que tienen que sacrificar su tiempo libre para trabajar en un proyecto.
 
 <aside markdown="1" class="pquote">
   [Me gustaría tener] más apoyo financiero, para poder enfocarme en el trabajo de código abierto sin gastar mis ahorros y sabiendo que tendré que hacer muchos contratos para compensarlo más tarde.
   <p markdown="1" class="pquote-credit">
-— mantenedor de código abierto
+— contribuidor de código abierto
   </p>
 </aside>
 
@@ -78,7 +78,7 @@ Es importante entender qué nos lleva al agotamiento. Aquí hay algunas temas co
 <aside markdown="1" class="pquote">
   Con el código abierto pagado, conflicto entre el enfoque del empleador y lo que es mejor para la comunidad.
   <p markdown="1" class="pquote-credit">
-— mantenedor de código abierto
+— contribuidor de código abierto
   </p>
 </aside>
 
@@ -86,20 +86,20 @@ Es importante entender qué nos lleva al agotamiento. Aquí hay algunas temas co
 
 ¿Puedes mantener tu ritmo durante 10 semanas? ¿10 meses? ¿10 años?
 
-Existen herramientas como la [Lista de verificación de agotamiento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) y el [kit de autoevaluación de ecología personal de Mozilla](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que pueden ayudarte a reflexionar sobre tu ritmo actual y ver si hay ajustes que puedas hacer. Algunos mantenedores también utilizan tecnología portátil para realizar un seguimiento de métricas como la calidad del sueño y la variabilidad de la frecuencia cardíaca (ambas vinculadas al estrés).
+Existen herramientas como la [Lista de verificación de agotamiento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) y el [kit de autoevaluación de ecología personal de Mozilla](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que pueden ayudarte a reflexionar sobre tu ritmo actual y ver si hay ajustes que puedas hacer. Algunos contribuidores también utilizan tecnología portátil para realizar un seguimiento de métricas como la calidad del sueño y la variabilidad de la frecuencia cardíaca (ambas vinculadas al estrés).
 
 <aside markdown="1" class="pquote">
   Soy un gran creyente en las buenas tecnologías portátiles. Con la ciencia detrás de ello, puedes entender cómo podrías haberlo hecho mejor y cómo llegar a un estado óptimo de lo que quieres hacer.
   <p markdown="1" class="pquote-credit">
-— mantenedor de código abierto
+— contribuidor de código abierto
   </p>
 </aside>
 
 ### ¿Qué necesitarías para seguir sosteniéndote a ti mismo y a tu comunidad?
 
-Esto será diferente para cada mantenedor y cambiará según tu fase de vida y otros factores externos. Pero aquí hay algunas temas que escuchamos:
+Esto será diferente para cada contribuidor y cambiará según tu fase de vida y otros factores externos. Pero aquí hay algunas temas que escuchamos:
 
-* **Apóyate en la comunidad:** Delegar y encontrar colaboradores puede aliviar la carga de trabajo. Tener múltiples puntos de contacto para un proyecto puede ayudarte a tomar un descanso sin preocupaciones. Conéctate con otros mantenedores y la comunidad en general, en grupos como la [Comunidad de Mantenedores](http://maintainers.github.com/). Esto puede ser un gran recurso para el apoyo entre pares y el aprendizaje.
+* **Apóyate en la comunidad:** Delegar y encontrar colaboradores puede aliviar la carga de trabajo. Tener múltiples puntos de contacto para un proyecto puede ayudarte a tomar un descanso sin preocupaciones. Conéctate con otros contribuidores y la comunidad en general, en grupos como la [Comunidad de Contribuidores](http://maintainers.github.com/). Esto puede ser un gran recurso para el apoyo entre pares y el aprendizaje.
 
   También puedes buscar formas de involucrarte con la comunidad de usuarios para escuchar regularmente comentarios y comprender el impacto de tu trabajo de código abierto.
 
@@ -109,7 +109,7 @@ Esto será diferente para cada mantenedor y cambiará según tu fase de vida y o
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
   Estuve en un podcast hace un tiempo y estábamos hablando sobre el mantenimiento de código abierto y la sostenibilidad. Descubrí que incluso un pequeño número de personas que apoyan mi trabajo en GitHub me ayudó a tomar una decisión rápida de no sentarme frente a un juego, sino de hacer una pequeña cosa con el código abierto.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mansona">@mansona</a>, mantenedor de EmberJS
+— <a href="https://github.com/mansona">@mansona</a>, contribuidor de EmberJS
   </p>
 </aside>
 
@@ -118,7 +118,7 @@ Esto será diferente para cada mantenedor y cambiará según tu fase de vida y o
 <aside markdown="1" class="pquote">
   Usa [Copilot](https://github.com/features/copilot/) para las cosas aburridas; haz las cosas divertidas.
   <p markdown="1" class="pquote-credit">
-— mantenedor de código abierto
+— contribuidor de código abierto
   </p>
 </aside>
 
@@ -130,7 +130,7 @@ Esto será diferente para cada mantenedor y cambiará según tu fase de vida y o
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
   Estoy encontrando más oportunidades para "momentos de creatividad" en medio del día en lugar de intentar desconectar por la noche.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/danielroe">@danielroe</a>, mantenedor de Nuxt
+— <a href="https://github.com/danielroe">@danielroe</a>, contribuidor de Nuxt
   </p>
 </aside>
 
@@ -140,7 +140,7 @@ Esto será diferente para cada mantenedor y cambiará según tu fase de vida y o
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
   Para confiar de manera significativa en otros en estos aspectos, no puedes ser alguien que diga sí a todas las solicitudes. Al hacerlo, no mantienes límites, profesional o personalmente, y no serás un compañero confiable.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, mantenedor de Homebrew sobre [Cómo decir no](https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, contribuidor de Homebrew sobre [Cómo decir no](https://mikemcquaid.com/saying-no/)
   </p>
 </aside>
 
@@ -150,15 +150,15 @@ Esto será diferente para cada mantenedor y cambiará según tu fase de vida y o
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
   Mi software es gratuito, pero mi tiempo y atención no lo son.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, mantenedor de Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, contribuidor de Leaflet
   </p>
 </aside>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-  No es un secreto que el mantenimiento de código abierto tiene sus lados oscuros, y uno de ellos es tener que interactuar a veces con personas bastante ingratas, exigentes o directamente tóxicas. A medida que aumenta la popularidad de un proyecto, también aumenta la frecuencia de este tipo de interacción, lo que añade una carga adicional a los mantenedores y posiblemente se convierte en un factor de riesgo significativo para el agotamiento de los mantenedores.
+  No es un secreto que el mantenimiento de código abierto tiene sus lados oscuros, y uno de ellos es tener que interactuar a veces con personas bastante ingratas, exigentes o directamente tóxicas. A medida que aumenta la popularidad de un proyecto, también aumenta la frecuencia de este tipo de interacción, lo que añade una carga adicional a los contribuidores y posiblemente se convierte en un factor de riesgo significativo para el agotamiento de los contribuidores.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, mantenedor de Octoprint sobre [Cómo lidiar con personas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>, contribuidor de Octoprint sobre [Cómo lidiar con personas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
 </aside>
 
@@ -166,7 +166,7 @@ Recuerda, la ecología personal es una práctica continua que evolucionará a me
 
 ## Recursos adicionales
 
-* [Comunidad de Mantenedores](http://maintainers.github.com/)
+* [Comunidad de Contribuidores](http://maintainers.github.com/)
 * [El contrato social del código abierto](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
 * [Cómo lidiar con personas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
@@ -179,7 +179,7 @@ Recuerda, la ecología personal es una práctica continua que evolucionará a me
 
 ## Colaboradores
 
-¡Muchas gracias a todos los mantenedores que compartieron sus experiencias y consejos con nosotros para esta guía!
+¡Muchas gracias a todos los contribuidores que compartieron sus experiencias y consejos con nosotros para esta guía!
 
 Esta guía fue escrita por [@abbycabs](https://github.com/abbycabs) con contribuciones de:
 

From 60ed246afaa2b3a8afe0db355e40bf306cb801ae Mon Sep 17 00:00:00 2001
From: KaitoMuraoka <kaitoboshi@icloud.com>
Date: Tue, 17 Oct 2023 15:51:14 +0900
Subject: [PATCH 605/749] Translated into Japanese

---
 ...ing-balance-for-open-source-maintainers.md | 124 +++++++++---------
 1 file changed, 62 insertions(+), 62 deletions(-)

diff --git a/_articles/ja/maintaining-balance-for-open-source-maintainers.md b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
index 0cea6e5c0fc..e472149bc65 100644
--- a/_articles/ja/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
@@ -1,174 +1,174 @@
 ---
 lang: ja
 untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+title: オープンソースメンテナーのバランス維持
+description: メンテナンス担当者としてのセルフケアと燃え尽き症候群を避けるためのヒント。
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+人気のあるオープンソースプロジェクトが成長するにつれて、バランスを保ち、長期的にリフレッシュし、生産性を維持するために明確な境界線を設定することが必要になります。
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+メンテナーの経験とバランスを取るための戦略を知るために、私たちは 40 人の <a href="http://maintainers.github.com/">maintainer community</a> のメンバーとワークショップを行い、彼らのオープンソースでの燃え尽き症候群に対する第一線での経験と、バランスを保つための実践を学ぶことができました。ここで「パーソナルエコロジー」という概念が登場します。
 
-So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+「パーソナルエコロジー」とはなんでしょうか？<a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a> によると、「<strong>生涯にわたってエネルギーを維持するために、バランス、ペース、効率を維持すること</strong>」を意味します。これにより、私たちの会話のフレームワークを作り、メンテナーが自分の行動や貢献を、時間とともに進化する大きな生態系の一部であると認識する助けとなりました。燃え尽き症候群は、[WHO によって定義されるように](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281) 、慢性的な職場でのストレスから生じる症候群であり、メンテナーの間では珍しくありません。これは、モチベーションの喪失、集中力の欠如、および共同作業者やコミュニティとの共感の欠如に繋がります。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
-  I was unable to focus or start on a task. I had a lack of empathy for users.
+  私は仕事を始めることや集中することができませんでした。ユーザーに対して共感の欠如がありました。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, Owncast ライブストリーミングサーバーのメンタナー、燃え尽き症候群がオープンソースの仕事に与える影響について語る
   </p>
 </aside>
 
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+パーソナルエコロジーの概念を取り入れることで、燃え尽き症候群を積極的に回避し、セルフケアを優先し、最高の仕事をするためのバランスを維持することができます。
 
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+## メンテナーとしてのセルフケアと燃え尽き症候群を回避するためのヒント
 
-### Identify your motivations for working in open source
+### オープンソースで働く動機を明確にする
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+オープンソースのメンテナンスのどの部分にあなたの活力が湧いてくるか、じっくり考えてみましょう。あなたのモチベーション理解することで、新しい課題に取り組む準備ができ、仕事に優先順位をつけることができます。ユーザーからの好意的なフィードバックであれ、コミュニティとの協力や交流の喜び、コードに没頭する満足感など、あなたのモチベーションを認識することで、集中力を高める指針になります。
 
-### Reflect on what causes you to get out of balance and stressed out
+### バランスを崩し、ストレスを感じる原因を振り返る
 
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
-
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+燃え尽きてしまう原因を理解することは重要です。オープンソースのメンテナーの間で見られるいくつかの共通のテーマは以下の通りです。
+* **肯定的なフィードバックの欠如:** ユーザーは苦情があるときに接触する可能性が高いです。全てが順調に進んでいる場合、ユーザーは黙っている傾向があります。あなたの貢献がどのような変化をもたらしているかを示すポジティブなフィードバックないまま、問題のリストが増えていくのを見るのは、がっかりするでしょう。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
-  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  まるで虚空に叫ぶようなもので、フィードバックが本当に活力を与えてくれます。私たちには、幸せだけど静かなユーザーがたくさんいます。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+— <a href="https://github.com/thisisnic">@thisisnic</a>, Apache Arrow のメンテナー
   </p>
 </aside>
 
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **「No」と言わない:** オープンソースプロジェクトでは、必要以上の責任を負うことは簡単です。それがユーザーであれ、貢献者であれ、他のメンテナーであれ、彼らの期待に答えられるとは限りません。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
-  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  私は、自分が一人で行うべきこと以上のことを引き受けて、多くの人々の仕事をしなければならないことに気がつきました。これは FOSS でよく行われています。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, Termux のメンテナー
   </p>
 </aside>
 
-* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+* **一人での作業:** メンテナーであることは非常に孤独です。例え同じメンテナーのグループで働いていたとしても、ここ数年、分散チームを直接集めるのは難しくなっている。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
- Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+ 特に COVID 以降、自宅で仕事をするようになってからは、誰とも会わず、誰とも話さない方が難しいです。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, Owncast ライブストリーミングサーバーのメンタナー、燃え尽き症候群がオープンソースの仕事に与える影響について語る
   </p>
 </aside>
 
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **時間やリソースの不足:** これは特にプロジェクトに取り組むために自分の自由な時間を犠牲にしなければならないボランティアのメンテナーにとって特に当てはまります。
 
 <aside markdown="1" class="pquote">
-  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  もっと経済的なサポートが欲しい。それによって私の貯金を使い果たさずに、後でそれを補うための多くの契約をする必要がなく、オープンソースの作業に専念できるのに。
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— オープンソースのメンテナー
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **矛盾する要求:**  オープンソースは様々な動機を持ったグループで溢れており、その間を行き来するのは難しいことがあります。オープンソースの仕事で給料をもらっている場合、雇用主の利益はコミュニティの利益と対立することがあります。
 
 <aside markdown="1" class="pquote">
-  With paid open source, conflict between employer's focus and what's best for the community
+  有料のオープンソースでは、雇用主が重視するものとコミュニティにとっての最善のものとの間に葛藤が生じる。
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— オープンソースのメンテナー
   </p>
 </aside>
 
-### Watch out for signs of burnout
+### 燃え尽きの兆候に注意
 
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+あなたは 10 週間、10 ヶ月、10 年とこのペースを続けることができますか？
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+[@shaunagm](https://github.com/shaunagm) による [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) や Mozilla の[自己評価キット](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw)のようなツールがあり、自分の現在のペースを振り返り、調整できる点があるかどうかを確認することができます。一部のメンテナーは、睡眠の質や心拍数変動 (両方ともストレスに関連している) のような指標を追跡するためにウェアラブル技術も利用しています。
 
 <aside markdown="1" class="pquote">
- I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+ 私は良質なウェアラブル技術を強く信じています。その背後にある科学的根拠によって、どのように改善的できたかや、目指す状態を最適にする方法を理解することができます。
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— オープンソースのメンテナー
   </p>
 </aside>
 
-### What would you need to continue sustaining yourself and your community?
+### 自分自身とコミュニティを維持し続けるためには何が必要だろうか？
 
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+これは各メンテナーによって異なるだろうし、生活の段階や外部要因によって変わるでしょう。しかし、以下は私たちが耳にしたいくつかのテーマです：
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **コミュニティに頼る:** 仕事の委譲や貢献者の探し方は、仕事の負担を軽減できます。プロジェクトの連絡窓口を複数持つことで、心配することなく休憩を取ることができます。[Maintainer Community](http://maintainers.github.com/) のようなグループで他のメンテナーや広いコミュニティと繋がることができます。これは、相互支援や学びのための素晴らしいリソースとなるでしょう。
 
-  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+  ユーザーコミュニティとの交流方法も探して、定期的にフィードバックを受け取り、オープンソースの作業の影響を理解することができます。
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on  to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **資金調達をさぐる:** ピザのお金を探しているのか、フルタイムのオープンソースを探しているのか、サポートするリソースはたくさんあります！最初のステップとして、[GitHub Sponsors](https://github.com/sponsors)を有効にして、他の人があなたのオープンソースの作業をスポンサーすることを許可します。フルタイムに移行することを考えている場合は、次回の　[GitHub Accelerator](http://accelerator.github.com/)　に応募してみて下さい。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
- I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+ ある時、ポッドキャストに出演して、オープンソースのメンテナンスや持続可能性について話していました。GitHub での私の作業をサポートする少数の人々が、ゲームの前に座るのではなく、オープンソースでちょっとしたことをするという素早い決定を下すのに役立ったことに気づきました。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+— <a href="https://github.com/mansona">@mansona</a>, EmberJS のメンテナー
   </p>
 </aside>
 
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+* **ツールを使う:** [GitHub Copilot](https://github.com/features/copilot/) や [GitHub Actions](https://github.com/features/actions) のようなツールを使って、退屈な作業を自動化し、より意味のある貢献のために時間を確保しましょう。
 
 <aside markdown="1" class="pquote">
- Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+ 退屈な時に [Copilot](http://github.com/features/copilot/) を使って、楽しいことをしましょう。
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— オープンソースメンテナー
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+* **休息と充電:** オープンソース以外の趣味や興味の時間を作りましょう。週末は休んでリフレッシュし、[GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) に反映させましょう！一晩ぐっすり眠れるかどうかで、長期的な努力を継続できるかどうかが大きく変わってきます。
 
-  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+  プロジェクトのある側面が特に楽しいと感じるのであれば、その楽しさを 1 日を通して体験できるように仕事を構成してみましょう。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+ 私は、夜にオフにするのではなく、日中に『創造的な瞬間』を散りばめる機会を増やしています。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+— <a href="https://github.com/danielroe">@danielroe</a>, Nuxt のメンテナー
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **境界線を設ける:** すべてのリクエストに「 Yes 」と言えません。これは、「今すぐにはできませんし、今後もその予定はありません」と言うだけのことかもしれません。また、README でやりたいこととやりたくないことをリストアップすることもできます。たとえば、「明確に理由を示して作成された PR のみをマージします。」とか、「issue をレビューするのは、隔週木曜日の午後6時から7時までです。」などを言うことができます。こうすることで、他の人たちに期待を持たせることができますし、他の時に、投稿者やユーザーからの時間に対する要求を緩和するのに役立つ何かを示すことができます。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+これらの軸において、他人を有意義に信頼するためには、全ての要求に対して Yes と答えるような人間になってはいけない。そうすることで、仕事上でも個人的にも境界線を保てず、信頼できる同僚にはなれない。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  — <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, Homebrew のメンテナー、 [Saying No](https://mikemcquaid.com/saying-no/) にて
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+  不利益な行動や否定的な交流を断ち切る毅然とした態度を身につけましょう。どうでもいいことにはエネルギーを使わなくても大丈夫です。。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-My software is gratis, but my time and attention is not.
+私のソフトウェアは無償だが、私の時間と気配りは無償ではない。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, Leaflet のメンテナー
   </p>
 </aside>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+オープンソースのメンテナンスに暗い側面があるのは周知の事実で、そのひとつが、時に恩知らずで権利意識が強く、あるいは明らかに有害な人々と接しなければならないことだ。プロジェクトの人気が高まるにつれて、このような交流の頻度も増え、メンテナーの負担が増し、おそらくメンテナーが燃え尽きる重大な危険因子となる。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>, Octoprint のメンテナー、 [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs) にて
   </p>
 </aside>
 
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+パーソナルエコロジーは、オープンソースの旅が進むにつれて進化していく、現在進行形の実践であることを忘れないでください。セルフケアを優先し、両立を保つことで、効果的かつ持続的にオープンソースコミュニティに貢献することができ、長期的に自分の幸福とプロジェクトの成功の両方を確保することができます。
 
-## Additional Resources
+## その他のリソース
 
 * [Maintainer Community](http://maintainers.github.com/)
 * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
-* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
 * [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
@@ -177,11 +177,11 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
 * Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
 
-## Contributors
+## 貢献者
 
-Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+このガイドのために経験やヒントを提供してくれた全てのメンテナーに感謝します！
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+このガイドブックは、[@abbycabs](https://github.com/abbycabs) によって作成されました。：
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)

From 5b130fcc1dd192737ba33ee8424837469092c33a Mon Sep 17 00:00:00 2001
From: KaitoMuraoka <kaitoboshi@icloud.com>
Date: Tue, 17 Oct 2023 22:55:50 +0900
Subject: [PATCH 606/749] partinally edited for natural Japanese

---
 ...ing-balance-for-open-source-maintainers.md | 29 +++++++++----------
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/_articles/ja/maintaining-balance-for-open-source-maintainers.md b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
index e472149bc65..7d99322c624 100644
--- a/_articles/ja/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
@@ -33,7 +33,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ### バランスを崩し、ストレスを感じる原因を振り返る
 
 燃え尽きてしまう原因を理解することは重要です。オープンソースのメンテナーの間で見られるいくつかの共通のテーマは以下の通りです。
-* **肯定的なフィードバックの欠如:** ユーザーは苦情があるときに接触する可能性が高いです。全てが順調に進んでいる場合、ユーザーは黙っている傾向があります。あなたの貢献がどのような変化をもたらしているかを示すポジティブなフィードバックないまま、問題のリストが増えていくのを見るのは、がっかりするでしょう。
+* **肯定的なフィードバックの欠如:** ユーザーは苦情があるときに接触する可能性が高いです。全てが順調に進んでいる場合、ユーザーは黙っている傾向があります。あなたの貢献がどのような変化をもたらしているかを示すポジティブなフィードバックがないまま、問題のリストが増えていくのを見るのは、がっかりするでしょう。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
@@ -53,7 +53,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
   </p>
 </aside>
 
-* **一人での作業:** メンテナーであることは非常に孤独です。例え同じメンテナーのグループで働いていたとしても、ここ数年、分散チームを直接集めるのは難しくなっている。
+* **一人での作業:** メンテナーであることは非常に孤独です。例え同じメンテナーのグループで働いていたとしても、ここ数年、分散チームを直接集めるのは難しくなっています。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
@@ -66,7 +66,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 * **時間やリソースの不足:** これは特にプロジェクトに取り組むために自分の自由な時間を犠牲にしなければならないボランティアのメンテナーにとって特に当てはまります。
 
 <aside markdown="1" class="pquote">
-  もっと経済的なサポートが欲しい。それによって私の貯金を使い果たさずに、後でそれを補うための多くの契約をする必要がなく、オープンソースの作業に専念できるのに。
+私はもっと経済的なサポートが欲しいのです。そうすれば、私の貯金を使い果たすことなくオープンソースの仕事に専念でき、後に多くの契約業務を行って補わなければならないというプレッシャーも感じずに済みます。
   <p markdown="1" class="pquote-credit">
 — オープンソースのメンテナー
   </p>
@@ -75,7 +75,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 * **矛盾する要求:**  オープンソースは様々な動機を持ったグループで溢れており、その間を行き来するのは難しいことがあります。オープンソースの仕事で給料をもらっている場合、雇用主の利益はコミュニティの利益と対立することがあります。
 
 <aside markdown="1" class="pquote">
-  有料のオープンソースでは、雇用主が重視するものとコミュニティにとっての最善のものとの間に葛藤が生じる。
+  有料のオープンソースでは、雇用主が重視するものとコミュニティにとっての最善のものとの間に葛藤が生じます。
   <p markdown="1" class="pquote-credit">
 — オープンソースのメンテナー
   </p>
@@ -96,18 +96,17 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 
 ### 自分自身とコミュニティを維持し続けるためには何が必要だろうか？
 
-これは各メンテナーによって異なるだろうし、生活の段階や外部要因によって変わるでしょう。しかし、以下は私たちが耳にしたいくつかのテーマです：
+これは各メンテナーによって異なり、生活の段階や外部要因によって変わるでしょう。しかし、以下は私たちが耳にしたいくつかのテーマです：
 
 * **コミュニティに頼る:** 仕事の委譲や貢献者の探し方は、仕事の負担を軽減できます。プロジェクトの連絡窓口を複数持つことで、心配することなく休憩を取ることができます。[Maintainer Community](http://maintainers.github.com/) のようなグループで他のメンテナーや広いコミュニティと繋がることができます。これは、相互支援や学びのための素晴らしいリソースとなるでしょう。
 
   ユーザーコミュニティとの交流方法も探して、定期的にフィードバックを受け取り、オープンソースの作業の影響を理解することができます。
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on  to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
-* **資金調達をさぐる:** ピザのお金を探しているのか、フルタイムのオープンソースを探しているのか、サポートするリソースはたくさんあります！最初のステップとして、[GitHub Sponsors](https://github.com/sponsors)を有効にして、他の人があなたのオープンソースの作業をスポンサーすることを許可します。フルタイムに移行することを考えている場合は、次回の　[GitHub Accelerator](http://accelerator.github.com/)　に応募してみて下さい。
+* **資金調達をさぐる:** ピザのお金を探しているのか、フルタイムのオープンソースを探しているのか、サポートするリソースはたくさんあります！最初のステップとして、[GitHub Sponsors](https://github.com/sponsors)を有効にして、他の人があなたのオープンソースの作業をスポンサーすることを許可します。フルタイムに移行することを考えている場合は、次回の [GitHub Accelerator](http://accelerator.github.com/) に応募してみて下さい。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
- ある時、ポッドキャストに出演して、オープンソースのメンテナンスや持続可能性について話していました。GitHub での私の作業をサポートする少数の人々が、ゲームの前に座るのではなく、オープンソースでちょっとしたことをするという素早い決定を下すのに役立ったことに気づきました。
+ 少し前にポッドキャストに出演し、オープンソースの維持と持続性について話していました。GitHubで私の作業をサポートしてくれる少数の人々がいるだけで、ゲームの前に座るのではなく、オープンソースでちょっとしたことをする決断をすぐに下す助けとなることに気づきました。
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/mansona">@mansona</a>, EmberJS のメンテナー
   </p>
@@ -128,27 +127,27 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- 私は、夜にオフにするのではなく、日中に『創造的な瞬間』を散りばめる機会を増やしています。
+ 夜にリラックスするよりも、日中に「創造的なひととき」を取り入れる機会が増えてきていると感じています。
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/danielroe">@danielroe</a>, Nuxt のメンテナー
   </p>
 </aside>
 
-* **境界線を設ける:** すべてのリクエストに「 Yes 」と言えません。これは、「今すぐにはできませんし、今後もその予定はありません」と言うだけのことかもしれません。また、README でやりたいこととやりたくないことをリストアップすることもできます。たとえば、「明確に理由を示して作成された PR のみをマージします。」とか、「issue をレビューするのは、隔週木曜日の午後6時から7時までです。」などを言うことができます。こうすることで、他の人たちに期待を持たせることができますし、他の時に、投稿者やユーザーからの時間に対する要求を緩和するのに役立つ何かを示すことができます。
+* **境界線を設ける:** 全ての要求に「 Yes 」と言うわけにはいきません。これは、「今すぐそれに対応することはできませんし、将来的にも考えていません」とシンプルに伝えることや、READMEに自分が取り組みたいことや取り組みたくないことを明記することも含みます。例として、「明確な理由が示されたPRだけをマージする」とか、「隔週の木曜日の18時から19時にだけ問題をレビューする」といったことを伝えることができます。これにより、他の人たちに対する期待値を明確にし、また、あなたの時間に求められることに対して柔軟に対応するための基準を提供することができます。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-これらの軸において、他人を有意義に信頼するためには、全ての要求に対して Yes と答えるような人間になってはいけない。そうすることで、仕事上でも個人的にも境界線を保てず、信頼できる同僚にはなれない。
+これらの点で他者を真に信頼するためには、全ての要求に「 Yes 」と答えるような人であってはいけません。そうすることで、プロフェッショナルにもプライベートにも境界線を持たなくなり、信頼性のある同僚としての立場も失ってしまいます。
   <p markdown="1" class="pquote-credit">
   — <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, Homebrew のメンテナー、 [Saying No](https://mikemcquaid.com/saying-no/) にて
   </p>
 </aside>
 
-  不利益な行動や否定的な交流を断ち切る毅然とした態度を身につけましょう。どうでもいいことにはエネルギーを使わなくても大丈夫です。。
+  不利益な行動や否定的な交流を断ち切る毅然とした態度を身につけましょう。どうでもいいことにはエネルギーを使わなくても大丈夫です。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-私のソフトウェアは無償だが、私の時間と気配りは無償ではない。
+私のソフトウェアは無料で提供していますが、私の時間やエネルギーは無料ではありません。
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, Leaflet のメンテナー
   </p>
@@ -156,13 +155,13 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-オープンソースのメンテナンスに暗い側面があるのは周知の事実で、そのひとつが、時に恩知らずで権利意識が強く、あるいは明らかに有害な人々と接しなければならないことだ。プロジェクトの人気が高まるにつれて、このような交流の頻度も増え、メンテナーの負担が増し、おそらくメンテナーが燃え尽きる重大な危険因子となる。
+オープンソースのメンテナンスに暗い面があるのは、誰もが知っていることです。その中には、ありがたみを感じない人や、過度な権利を主張する人、あるいは明らかにトラブルを起こす人との接触が含まれます。プロジェクトが人気を集めるにつれて、このようなやり取りが増え、メンテナの負担が増大し、その結果、燃え尽きるリスクが高まることが考えられます。
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/foosel">@foosel</a>, Octoprint のメンテナー、 [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs) にて
   </p>
 </aside>
 
-パーソナルエコロジーは、オープンソースの旅が進むにつれて進化していく、現在進行形の実践であることを忘れないでください。セルフケアを優先し、両立を保つことで、効果的かつ持続的にオープンソースコミュニティに貢献することができ、長期的に自分の幸福とプロジェクトの成功の両方を確保することができます。
+忘れないでください、パーソナルエコロジーは継続的な実践であり、オープンソースの旅を進める中で進化していきます。自分自身のケアを優先し、バランスを保つことで、効果的かつ持続可能にオープンソースコミュニティに貢献できます。これにより、あなた自身の幸福とプロジェクトの長期的な成功の両方を確保することができます。
 
 ## その他のリソース
 

From 972f89f9207fbb3dcf5724e9fd007d67fad8a6ef Mon Sep 17 00:00:00 2001
From: KaitoMuraoka <kaitoboshi@icloud.com>
Date: Tue, 17 Oct 2023 23:04:23 +0900
Subject: [PATCH 607/749] delete untraslated tag

---
 _articles/ja/maintaining-balance-for-open-source-maintainers.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/_articles/ja/maintaining-balance-for-open-source-maintainers.md b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
index 7d99322c624..ce0c2ea4f0c 100644
--- a/_articles/ja/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
@@ -1,6 +1,5 @@
 ---
 lang: ja
-untranslated: true
 title: オープンソースメンテナーのバランス維持
 description: メンテナンス担当者としてのセルフケアと燃え尽き症候群を避けるためのヒント。
 class: balance

From e1a0ae3c37dc74624c6da9c7a4e6a16e1b096800 Mon Sep 17 00:00:00 2001
From: KaitoMuraoka <kaitoboshi@icloud.com>
Date: Tue, 17 Oct 2023 23:15:15 +0900
Subject: [PATCH 608/749] fix blank line

---
 _articles/ja/maintaining-balance-for-open-source-maintainers.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/_articles/ja/maintaining-balance-for-open-source-maintainers.md b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
index ce0c2ea4f0c..228f6021f2a 100644
--- a/_articles/ja/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
@@ -32,6 +32,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ### バランスを崩し、ストレスを感じる原因を振り返る
 
 燃え尽きてしまう原因を理解することは重要です。オープンソースのメンテナーの間で見られるいくつかの共通のテーマは以下の通りです。
+
 * **肯定的なフィードバックの欠如:** ユーザーは苦情があるときに接触する可能性が高いです。全てが順調に進んでいる場合、ユーザーは黙っている傾向があります。あなたの貢献がどのような変化をもたらしているかを示すポジティブなフィードバックがないまま、問題のリストが増えていくのを見るのは、がっかりするでしょう。
 
 <aside markdown="1" class="pquote">

From 0b1b22f457afe481c3fb3a86c430875795099881 Mon Sep 17 00:00:00 2001
From: Om Sagar <126400988+Dreadlord075@users.noreply.github.com>
Date: Thu, 19 Oct 2023 00:23:35 +0530
Subject: [PATCH 609/749] Update how-to-contribute.md

---
 _articles/hi/how-to-contribute.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md
index b1b0c714789..51de09007b2 100644
--- a/_articles/hi/how-to-contribute.md
+++ b/_articles/hi/how-to-contribute.md
@@ -10,7 +10,7 @@ related:
   - building
 ---
 
-## Why contribute to open source?
+## ओपन सोर्स में योगदान क्यों करें?
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
@@ -207,9 +207,9 @@ related:
 
 नई परियोजनाओं को खोजने और उनमें योगदान देने में सहायता के लिए आप निम्नलिखित संसाधनों में से किसी एक का भी उपयोग कर सकते हैं:
 
-* [GitHub Explore](https://github.com/explore/)
-* [Open Source Friday](https://opensourcefriday.com)
-* [First Timers Only](https://www.firsttimersonly.com/)
+* [GitHub समन्वेषण](https://github.com/explore/)
+* [Open Source शुक्रवार](https://opensourcefriday.com)
+* [पहली बार आने वाले](https://www.firsttimersonly.com/)
 * [CodeTriage](https://www.codetriage.com/)
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](https://up-for-grabs.net/)

From 3c781321c7b2cd587c6f777da0b7e37db2c42f67 Mon Sep 17 00:00:00 2001
From: Om Sagar <126400988+Dreadlord075@users.noreply.github.com>
Date: Thu, 19 Oct 2023 00:25:58 +0530
Subject: [PATCH 610/749] Update starting-a-project.md

---
 _articles/hi/starting-a-project.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md
index dd0179ba62f..f9c122127f0 100644
--- a/_articles/hi/starting-a-project.md
+++ b/_articles/hi/starting-a-project.md
@@ -36,9 +36,9 @@ _मुफ़्त सॉफ़्टवेयर_ परियोजनाओ
 
 * **सहयोग:** ओपन सोर्स प्रोजेक्ट दुनिया में किसी से भी बदलाव स्वीकार कर सकते हैं। [व्यायाम](https://github.com/exercism/), उदाहरण के लिए, 350 से अधिक योगदानकर्ताओं वाला एक प्रोग्रामिंग अभ्यास मंच है।
 
-* **अडॉप्टेशन और रीमिक्सिंग:** ओपन सोर्स प्रोजेक्ट्स का उपयोग कोई भी लगभग किसी भी उद्देश्य के लिए कर सकता है। लोग इसका उपयोग अन्य चीजें बनाने में भी कर सकते हैं। [WordPress](https://github.com/WordPress), उदाहरण के लिए, किसी मौजूदा प्रोजेक्ट के फोर्क के रूप में शुरू किया गया, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **अडॉप्टेशन और रीमिक्सिंग:** ओपन सोर्स प्रोजेक्ट्स का उपयोग कोई भी लगभग किसी भी उद्देश्य के लिए कर सकता है। लोग इसका उपयोग अन्य चीजें बनाने में भी कर सकते हैं। [WordPress](https://github.com/WordPress), उदाहरण के लिए, किसी मौजूदा प्रोजेक्ट के फोर्क के रूप में शुरू किया गया, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md)।
 
-* **Transparency:** Anyone can inspect an open source project for errors or असंगतियाँ जैसी सरकारों के लिए पारदर्शिता मायने रखती है [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) या[United States](https://sourcecode.cio.gov/), बैंकिंग या स्वास्थ्य देखभाल जैसे विनियमित उद्योग और सुरक्षा सॉफ्टवेयर जैसे [Let's Encrypt](https://github.com/letsencrypt).
+* **पारदर्शिता:** त्रुटियों या विसंगतियों के लिए कोई भी ओपन सोर्स प्रोजेक्ट का निरीक्षण कर सकता है। पारदर्शिता [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) या [United States](https://sourcecode.cio.gov/) जैसी सरकारों, बैंकिंग या स्वास्थ्य देखभाल जैसे विनियमित उद्योगों और [Let's Encrypt](https://github.com/letsencrypt), जैसे सुरक्षा सॉफ़्टवेयर के लिए मायने रखती है।
 
 ओपन सोर्स सिर्फ सॉफ्टवेयर के लिए ही नहीं है। आप डेटा सेट से लेकर किताबों तक सब कुछ ओपन सोर्स कर सकते हैं। आप और क्या स्रोत खोल सकते हैं, इस बारे में विचारों के लिए [गिटहब एक्सप्लोर](https://github.com/explore) देखें।
 

From a56c8c46ef83d1e1841edd3b11fccc5ec5236ec5 Mon Sep 17 00:00:00 2001
From: Om Sagar <126400988+Dreadlord075@users.noreply.github.com>
Date: Thu, 19 Oct 2023 00:28:23 +0530
Subject: [PATCH 611/749] Update getting-paid.md

---
 _articles/hi/getting-paid.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/hi/getting-paid.md b/_articles/hi/getting-paid.md
index 7cada6b50b1..8b169d6566a 100644
--- a/_articles/hi/getting-paid.md
+++ b/_articles/hi/getting-paid.md
@@ -94,14 +94,14 @@ OSS प्रौद्योगिकी उद्योग को बड़े
 
 अपनी व्यक्तिगत परिस्थितियों के आधार पर, आप अपने ओपन सोर्स कार्य के वित्तपोषण के लिए स्वतंत्र रूप से धन जुटाने का प्रयास कर सकते हैं। उदाहरण के लिए:
 
-* @Homebrew (और [many other maintainers and organizations](https://github.com/sponsors/community)) [GitHub Sponsors](https://github.com/sponsors) के माध्यम से उनके काम को वित्तपोषित करें
+* @Homebrew (और [कई अन्य अनुरक्षक और संगठन](https://github.com/sponsors/community)) [GitHub Sponsors](https://github.com/sponsors) के माध्यम से उनके काम को वित्तपोषित करें
 * @gaearon उसके काम को वित्त पोषित किया [Redux](https://github.com/reactjs/redux) पर, और [Patreon crowdfunding campaign](https://redux.js.org/) के जरिए
 * @andrewgodwin स्कीमा माइग्रेशन पर वित्त पोषित कार्य [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
 अंत में, कभी-कभी ओपन सोर्स प्रोजेक्ट उन मुद्दों पर इनाम देते हैं जिनमें आप मदद करने पर विचार कर सकते हैं।
 
-* @ConnorChristie भुगतान पाने में सक्षम था [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
-* @mamiM ने इसके बाद @MetaMask का जापानी अनुवाद किया [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+* @ConnorChristie भुगतान पाने में सक्षम था [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol अपनी JavaScript लाइब्रेरी पर काम करता है [gitcoin पर इनाम के माध्यम से](https://gitcoin.co/).
+* @mamiM ने इसके बाद @MetaMask का जापानी अनुवाद किया [इस मुद्दे को बाउंटीज़ नेटवर्क पर वित्त पोषित किया गया था](https://explorer.bounties.network/bounty/134).
 
 ## अपने प्रोजेक्ट के लिए फंडिंग ढूँढना
 

From 061ca9602e7c47206c6c06000dc9f6d1c00df440 Mon Sep 17 00:00:00 2001
From: LizzyOrji123 <cegscutie4rill@yahoo.com>
Date: Sun, 22 Oct 2023 19:06:17 +0100
Subject: [PATCH 612/749] created a new language called pidgin and created
 best-practice.md and added all best practices in pidgin language

---
 _articles/pidgin/best-practice.md | 260 ++++++++++++++++++++++++++++++
 1 file changed, 260 insertions(+)
 create mode 100644 _articles/pidgin/best-practice.md

diff --git a/_articles/pidgin/best-practice.md b/_articles/pidgin/best-practice.md
new file mode 100644
index 00000000000..cf706933210
--- /dev/null
+++ b/_articles/pidgin/best-practice.md
@@ -0,0 +1,260 @@
+---
+lang: pidgin
+title: Best Practices for Maintainers
+description: Learn how to make your life easy as an open source maintainer, from documentation to community collaboration. Make sense of maintaining open source projects with these top-notch tips.
+class: best-practices
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+  - metrics
+  - leadership
+---
+
+## Wetin e mean to be maintainer?
+
+If you dey maintain one open source project wey plenty people dey use, you fit don notice say you dey write code sote you no dey rest. For the early days of your project, you dey try new tins and you dey make decisions based on wetin you wan. But as your project dey popular, you go dey work with users and contributors.
+
+To maintain project no be only about code. Plenty tins dey wey fit happen wey you no plan, but dem still dey important for your growing project. We don gather some ways wey go make your life easy, from writing down your process to involving your community.
+
+## Write the way waeh you use
+
+To write tins down, no be small work. E go make sense if you dey maintain your open source project.
+
+Documentation no be only for you to clear your mind, e go help other people understand wetin you need or wetin you dey expect before dem even ask. To write tins down go make am easy for you to yarn no when something no follow your project plan. E go also make am easy for people to fit join put hand for your project. You no go sabi who go fit read your project or use am.
+
+If you no get strength to dey update your documentation all the time, you fit delete the one wey don old or you fit talk say e don old so that people go sabi say dem fit update am.
+
+### Yarn Wetin Your Project Fit Be (Write Your Project's Vision)
+
+Start to write wetin you want make your project be. Put am for your README or create file wey you go call VISION. If you get other things wey fit help like project roadmap, e go make sense make you put dem for public make everybody sabi.
+
+As @lord don talk, project vision fit help you know wetin you go fit work on. As new maintainer, e talk say e no follow him project scope when e see first feature request for [Slate](https://github.com/lord/slate).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
+  I mess up. I no put effort to find correct solution. Instead of one kain solution, I for talk say, "I no get time for this now, but I go add am to the list for future when I fit do am well."
+  <p markdown="1" class="pquote-credit">
+— @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
+  </p>
+</aside>
+
+### Talk Wetin You Expect
+
+E fit hard you to write down rules. Sometimes you fit think say you dey police people or say you dey dull dem vibe.
+
+But if you write rules fairly and you dey follow am, e go empower you. E go prevent you from doing tins wey you no like. People wey see your project fit no sabi your condition or circumstances. Dem fit think say dem dey pay you for the work wey you dey do, especially if na wetin dem dey use well well. Dem fit even think say you dey busy with new work or family matter.
+
+E good make people sabi dis tins.
+
+If to maintain your project na part-time or you dey do am because you volunteer, make you talk the time wey you get. E no be say na the time wey your project need or wetin people dey ask you for, na the time wey you get na e you go talk. E fit good if you write down some rules like:
+
+- How dem go review contribution (dem need test? Issue template?)
+- The kind of contribution wey dem go accept (you wan make dem help you with specific part of your code?)
+- When e go make sense for dem to follow up (e.g., "you fit expect response from maintainer within 7 days, if you no see any response by then, you fit ping the thread")
+- How much time you dey spend for the project (e.g., "we dey spend like 5 hours per week on this project")
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) na some examples of projects wey get rules for maintainers and contributors.
+
+### Make Your Communication Public
+
+No forget to write down your talks. Where you fit, make all your communication for your project public. If person try contact you for private to discuss feature request or support matter, tell am politely make e follow public channel yarn you like mailing list or issue tracker.
+
+If you meet other maintainers or you take big decision for private, write the conversation for public so that person wey follow your community go see the same information wey dem wey dey for years see.
+
+## Sabi To Say No
+
+You don write down wetin you want, but people never read your documentation well. Sometimes you go still remind them say knowledge dey your documentation.
+
+Saying no no dey fun, but make you try yarn "Your contribution no dey follow this project criteria" e no too personal like "I no like your contribution."
+
+You go fit yarn no for plenty situations wey you go see as maintainer like feature requests wey no follow your project plan or person wey dey disturb discussion.
+
+### Make the chitchat dey friendly
+
+One important place wey you go practice how to talk no be yes na for your issue and pull request queue. As person wey dey maintain project, e dey natural say you go dey see suggestions wey you no go want accept.
+
+Maybe the contribution wan change how your project dey work or e no dey follow your own idea. Maybe the idea make sense, but the way dem take do am no too correct.
+
+No matter how e be, e fit possible to waka diplomatically for contributions wey no too follow your project standards.
+
+If you come across one contribution wey you no wan accept, your first reaction fit be to dey do like say you no see am or to dey form say you no see am. If you do am like that, e fit wound the person way submit am and e fit even discourage other people wey wan contribute for your community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
+    The main trick for managing support for big open source projects be say make you dey make issues dey waka. Try no make issues dey hang. If you be iOS developer, you sabi as e dey vex when you submit radars. You fit dey wait for like 2 years before dem go reply you, and dem go talk say make you try again with the latest iOS version.
+  <p markdown="1" class="pquote-credit">
+— @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
+  </p>
+</aside>
+
+No just allow one contribution wey you no want dey open because you dey feel bad or you dey try to dey nice. As time dey go, the issues and PRs wey you never answer go make your project come dey feel like say e too stress you and dey intimidate you.
+
+E better make you quick-close contributions wey you sabi say you no wan accept am. If your project don already gather plenti matter wey never resolve, @steveklabnik get some advice on [how to quickly arrange the issues] so e go dey efficient. (https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+
+If you no wan accept one contribution:
+
+* **Thank them** for their contribution
+* **Explain why e no follow** within the project's scope, and offer clear suggestions for how e fit improve, if you sabi. Make sure say you dey friendly but firm.
+* **Attach link to relevant documentation**, if you get am. If you dey see people dey request the same thing wey you no dey ready to accept, put am for your documentation so that you no go dey repeat yourself.
+* **Close the request**
+
+You no need talk pass 1-2 sentences for response. For example, when person wey dey use [celery](https://github.com/celery/celery/) report say e get one Windows-related error, @berkerpeksag [reply like this](https://github.com/celery/celery/issues/3383):
+
+![Celery screenshot](/assets/images/best-practices/celery.png)
+
+If the fear of saying "no" dey worry you, my brother, you no dey alone for this matter. As @jessfraz [talk am for here](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> I don chook mouth with maintainers wey dey run different open source projects like Mesos, Kubernetes, Chromium, and all of them gree say one of the hardest part for person wey dey maintain na to talk "No" to patches wey e no wan.
+
+No go dey feel bad say you no wan accept person contribution. The first law for open source, [as](https://twitter.com/solomonstre/status/715277134978113536) @shykes talk am: _"No na for time, yes na forever."_ While you dey reason the person wey get ginger, e no mean say you dey reject the person way submit contribution.
+
+At the end of the day, if contribution no follow standard, you no dey owe anybody obligation to accept am. Just dey friendly and ready to answer when people wan contribute to your project, but make you dey accept only the changes wey you believe say e go make your project better. As you dey practice to talk "no" often, e go dey easier. I promise you.
+
+### Dey Ahead of Time
+
+To reduce the plenty unwanted contributions from the start, explain your project process for submitting and accepting contributions for your contributing guide.
+
+If you dey receive plenty low-quality contributions, you fit tell contributors make them do small work before:
+
+* Fill out one kind issue or PR template/checklist
+* Open one issue before them submit PR
+
+If them no follow your rules, close the issue sharp-sharp and show them your documentation.
+
+Although e fit seem like say this approach no dey friendly at first, but e dey better for everybody. E dey reduce the chance say person go waste time dey work on top PR wey you no go accept. E also dey reduce your own work burden.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+  Make e clear to them, for one CONTRIBUTING.md file, how them fit sabi whether you go accept their work or no go accept am before them start work.
+  <p markdown="1" class="pquote-credit">
+— @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
+  </p>
+</aside>
+
+Sometimes, when you talk no, person fit vex or criticize your decision. If their behavior come bad, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if them no dey ready to work together positively.
+
+### Show Love for Mentorship
+
+E fit happen say one person for your community dey always submit contributions wey no meet your project standards. E fit dey vex both parties as them dey reject their work every time.
+
+If you see say person dey show interest for your project but e just need small touch, be patient. Make you clear for every situation why their contributions no dey up to the project standards. Try to show them where them fit do better, maybe by working on one small or less complex task, like issue wey dem mark "good first issue," to give them confidence. If you get time, you fit mentor them as them dey do their first contribution, or you find person for your community wey go fit mentor them.
+
+## Tap into your community
+
+You no need to do everything alone. Your project community dey exist for one reason! Even if you no get active community of contributors yet, if plenty people dey use your project, make them help you.
+
+### Share the workload
+
+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.
+
+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-ownership-of-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).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
+  I been dey talk say, "Yes, anybody fit participate, e no need make you sabi plenty coding [...]." People come sign up to join [one event], and I con dey wonder whether na true I talk or not. 40 people show up, and I no fit sit down with all of them...But people come together, and e just dey work. As soon as one person sabi am, e fit teach their neighbor.
+  <p markdown="1" class="pquote-credit">
+—  @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+  </p>
+</aside>
+
+If you need to step away from your project, whether on leave or permanently, no shame dey ask another person to take over for you.
+
+If other people dey happy about the project direction, give them access to make changes or formally hand over control to another person. If person don fork your project and dey actively maintain am for another place, consider put link to the fork from your original project. E good as plenty people dey show interest for your project!
+
+@progrium [talk say](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) as him documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), help others to carry on the goals even after he comot from the project:
+
+> I write one wiki page wey describe wetin I want and why I want am. For some reason, e shock me as the maintainers begin move the project in that direction! E no always dey exactly how I go do am? Not every time. But e still bring the project close to wetin I write down.
+
+### Make others build their own solutions
+
+If potential contributor get another idea for your project and e no follow your own idea, you fit encourage am gently to work on their own fork.
+
+Creating one fork of the project no dey bad at all. Make people sabi say them fit copy and modify projects, and e dey good thing about open source. Encourage your community members to work on their own fork because e fit give them creative freedom wey no go dey against your project vision.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
+  I dey consider the 80% use case. If you be one of the special people, please fork my work. I no go vex! My public projects almost always dey solve common problems; I dey try make am easy for person to dive deeper by forking or extending my work.
+  <p markdown="1" class="pquote-credit">
+— @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+  </p>
+</aside>
+
+The same thing fit apply to one user wey need solution wey you no get time to build. Offer APIs and customization options wey fit help other people meet their needs, without them needing to modify the source directly. @orta [see](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) say as them dey encourage plugins for CocoaPods, e lead to "some of the most interesting ideas":
+
+> Almost like magic, when project big well well, maintainers must dey more conservative about how them dey add new code. You go sabi how to talk "no," but plenty people get valid needs. Instead, you fit change your tool into one platform.
+
+## Bring them robots
+
+Just like how other people fit help you with some tasks, some tasks no go make sense for person to dey do. Robots go be your friends for this matter. Use them to make your life as one maintainer dey easier.
+
+### Make you dey run tests and checks to upgrade your code quality
+
+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.
+
+If you add tests, make sure say you explain how them dey work for your CONTRIBUTING file.
+
+<aside markdown="1" class="pquote">
+  <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)
+  </p>
+</aside>
+
+### Use tools to automate basic maintenance tasks
+
+The good news about maintaining a popular project be say other maintainers fit don face similar challenges and build solutions for them.
+
+Plenty [tools dey available](https://github.com/showcases/tools-for-open-source) wey fit help automate some parts of maintenance work. Some examples include:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) wey dey automate your releases
+* [mention-bot](https://github.com/facebook/mention-bot) wey dey mention potential reviewers for pull requests
+* [Danger](https://github.com/danger/danger) wey help automate code review
+* [no-response](https://github.com/probot/no-response) wey close issues wey the author no respond to requests for more information
+* [dependabot](https://github.com/dependabot) wey dey check your dependency files every day for outdated requirements and dey open individual pull requests for any wey e see.
+
+For bug reports and other common contributions, GitHub get [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), wey you fit create to streamline the communication wey you dey receive. @TalAter create [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.
+
+To manage your email notifications, you fit set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize them by priority.
+
+If you want to get more advanced, style guides and linters fit standardize project contributions and make them easy to review and accept.
+
+However, if your standards too complex, them fit dey increase the obstacles to contribution. Make sure say you just add enough rules wey go make everyone's life easier.
+
+If you no sure which tools to use, look at what other popular projects dey do, especially those for your ecosystem. For example, wetin the contribution process be like for other Node modules? Using similar tools and approaches go make your process more familiar to your target contributors.
+
+## E dey okay to pause
+
+Open source work wey once dey give you joy fit dey make you avoid or dey guilty now.
+
+Maybe you dey feel overwhelmed or one growing sense of dread when you think about your projects. Meanwhile, issues and pull requests just dey pile up.
+
+Burnout na real issue wey plenty maintainers dey face for open source work. As one maintainer, your happiness na one non-negotiable requirement for the survival of any open source project.
+
+Though e suppose dey obvious, make you take break! You no need wait until you feel burnt out before you take vacation. @brettcannon, one Python core developer, decide to take [one month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) after 14 years of volunteer OSS work.
+
+Just like any other work, make you dey take regular breaks so you go dey refreshed, happy, and excited about your work.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
+  In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
+  <p markdown="1" class="pquote-credit">
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https/danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+  </p>
+</aside>
+
+Sometimes, e fit hard to take break from open source work when e look like everybody need you. People fit even try to make you feel guilty as you dey step away.
+
+Try find support for your users and community if you dey away from one project. If you no fit find the support wey you need, just take break. Make you sure to communicate when you no dey available, so people no go dey confused when you no dey respond.
+
+Taking breaks no only apply to vacations, e fit include say you no wan do open source work during weekends or work hours. Communicate those expectations to others, so them go know say dem no suppose disturb you.
+
+## Make you dey take care of yourself first!
+
+To maintaining one popular project require different skills from the first first time of growth, but e no dey less rewarding. As one maintainer, you go dey practice leadership and personal skills for one level wey few people fit experience. Though e no dey easy to manage, setting clear boundaries and only taking on wetin you dey comfortable with go help you dey happy, refreshed, and productive.

From c550756e43649de5f0ecb8f494dc4338590257cf Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 24 Oct 2023 04:37:19 +0000
Subject: [PATCH 613/749] build(deps): bump actions/setup-node from 3 to 4

Bumps [actions/setup-node](https://github.com/actions/setup-node) from 3 to 4.
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/v3...v4)

---
updated-dependencies:
- dependency-name: actions/setup-node
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 7c2c57a47ec..ed3402cdbc8 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -17,7 +17,7 @@ jobs:
         bundler-cache: true
 
     - name: Set up Node
-      uses: actions/setup-node@v3
+      uses: actions/setup-node@v4
 
     - name: Bootstrap
       run: script/bootstrap

From 5adac1996777353f2377b6b4ba9e80a73b4da127 Mon Sep 17 00:00:00 2001
From: LizzyOrji123 <cegscutie4rill@yahoo.com>
Date: Tue, 24 Oct 2023 13:05:28 +0100
Subject: [PATCH 614/749] created building-communities.md and
 code-of-conduct.md, I also created the pidgin.yml

---
 _articles/pidgin/best-practice.md      |  18 +-
 _articles/pidgin/building-community.md | 258 +++++++++++++++++++++++++
 _articles/pidgin/code-of-conduct.md    |  58 ++++++
 _data/locales/pidgin.yml               |  31 +++
 assets/css/translate.scss              |   1 +
 5 files changed, 357 insertions(+), 9 deletions(-)
 create mode 100644 _articles/pidgin/building-community.md
 create mode 100644 _articles/pidgin/code-of-conduct.md
 create mode 100644 _data/locales/pidgin.yml

diff --git a/_articles/pidgin/best-practice.md b/_articles/pidgin/best-practice.md
index cf706933210..195f3d1d556 100644
--- a/_articles/pidgin/best-practice.md
+++ b/_articles/pidgin/best-practice.md
@@ -55,7 +55,7 @@ If to maintain your project na part-time or you dey do am because you volunteer,
 
 [Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) na some examples of projects wey get rules for maintainers and contributors.
 
-### Make Your Communication Public
+### Make Sure Your Communication Commot For Outside
 
 No forget to write down your talks. Where you fit, make all your communication for your project public. If person try contact you for private to discuss feature request or support matter, tell am politely make e follow public channel yarn you like mailing list or issue tracker.
 
@@ -69,7 +69,7 @@ Saying no no dey fun, but make you try yarn "Your contribution no dey follow thi
 
 You go fit yarn no for plenty situations wey you go see as maintainer like feature requests wey no follow your project plan or person wey dey disturb discussion.
 
-### Make the chitchat dey friendly
+### Make the talk-talk dey friendly
 
 One important place wey you go practice how to talk no be yes na for your issue and pull request queue. As person wey dey maintain project, e dey natural say you go dey see suggestions wey you no go want accept.
 
@@ -93,9 +93,9 @@ E better make you quick-close contributions wey you sabi say you no wan accept a
 
 If you no wan accept one contribution:
 
-* **Thank them** for their contribution
+* **Tell them thank you** for their contribution
 * **Explain why e no follow** within the project's scope, and offer clear suggestions for how e fit improve, if you sabi. Make sure say you dey friendly but firm.
-* **Attach link to relevant documentation**, if you get am. If you dey see people dey request the same thing wey you no dey ready to accept, put am for your documentation so that you no go dey repeat yourself.
+* **Link waeh get Relevant documentation na him you go add**, if you get am. If you dey see people dey request the same thing wey you no dey ready to accept, put am for your documentation so that you no go dey repeat yourself.
 * **Close the request**
 
 You no need talk pass 1-2 sentences for response. For example, when person wey dey use [celery](https://github.com/celery/celery/) report say e get one Windows-related error, @berkerpeksag [reply like this](https://github.com/celery/celery/issues/3383):
@@ -133,17 +133,17 @@ Although e fit seem like say this approach no dey friendly at first, but e dey b
 
 Sometimes, when you talk no, person fit vex or criticize your decision. If their behavior come bad, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if them no dey ready to work together positively.
 
-### Show Love for Mentorship
+### Dey Show Love for Mentorship
 
 E fit happen say one person for your community dey always submit contributions wey no meet your project standards. E fit dey vex both parties as them dey reject their work every time.
 
 If you see say person dey show interest for your project but e just need small touch, be patient. Make you clear for every situation why their contributions no dey up to the project standards. Try to show them where them fit do better, maybe by working on one small or less complex task, like issue wey dem mark "good first issue," to give them confidence. If you get time, you fit mentor them as them dey do their first contribution, or you find person for your community wey go fit mentor them.
 
-## Tap into your community
+## Put hand inside your community
 
 You no need to do everything alone. Your project community dey exist for one reason! Even if you no get active community of contributors yet, if plenty people dey use your project, make them help you.
 
-### Share the workload
+### Make you share the work
 
 If you dey find people wey go fit help, start to ask around.
 
@@ -167,7 +167,7 @@ If other people dey happy about the project direction, give them access to make
 
 > I write one wiki page wey describe wetin I want and why I want am. For some reason, e shock me as the maintainers begin move the project in that direction! E no always dey exactly how I go do am? Not every time. But e still bring the project close to wetin I write down.
 
-### Make others build their own solutions
+### Make other pesin build them own solutions
 
 If potential contributor get another idea for your project and e no follow your own idea, you fit encourage am gently to work on their own fork.
 
@@ -207,7 +207,7 @@ If you add tests, make sure say you explain how them dey work for your CONTRIBUT
   </p>
 </aside>
 
-### Use tools to automate basic maintenance tasks
+### Carry tools use am to automate basic maintenance tasks
 
 The good news about maintaining a popular project be say other maintainers fit don face similar challenges and build solutions for them.
 
diff --git a/_articles/pidgin/building-community.md b/_articles/pidgin/building-community.md
new file mode 100644
index 00000000000..315c2037cd2
--- /dev/null
+++ b/_articles/pidgin/building-community.md
@@ -0,0 +1,258 @@
+---
+lang: pidgin
+title: Na Welcoming Communities we go Build
+description: Make you build one community wey go encourage people make them use, contribute, and promote your project.
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+  - best-practices
+  - coc
+---
+
+## Set that your project make aeh succeed
+
+You don launch your project, you dey spread the word, and people dey check am out. Correct! Now, how you wan make them stick around?
+
+One welcoming community na one investment into your project's future and reputation. If your project just dey start to see its first contributions, make you start by dey give early contributors one positive experience, and make you dey easy for them to dey come back.
+
+### Make people dey feel welcome
+
+One way to think about your project's community na through wetin @MikeMcQuaid call the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+
+As you dey build your community, consider how person wey dey the top of the funnel (potential user) fit possibly waka reach the bottom (active maintainer). Your koko na to reduce any wahala for each stage of the contributor experience. Na when people fit see better results without too much stress, them go feel encouraged to do more.
+
+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.
+
+[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.
+
+* **When new person land for your project, thank them for their interest!** E fit just take one bad experience for person to no wan come back again.
+* **Be responsive.** If you no respond to their issue for one month, e possible say them don forget your project.
+* **Open mind about the types of contributions wey you go accept.** Many contributors start with one bug report or one small fix. Many ways dey to contribute to one project. Make people fit help the way wey them wan help.
+* **If one person submit one contribution wey you no gree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) e no follow your project scope, and you fit add link to the relevant documentation wey you get.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  Contributing to open source na easier for some pass others. Many people dey fear say them go shout for am because them no do am well or them no dey fit in. By giving contributors one place to contribute wey no need plenty technical knowledge (documentation, web content markdown, etc) you fit greatly reduce those fears.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+  </p>
+</aside>
+
+Most open source contributors na "casual contributors": people wey only occasionally contribute to one project. One casual contributor fit no get time to sabi everything about your project, so your work na to make am easy for them to contribute.
+
+Encouraging other contributors na one investment in yourself, too. When you empower your biggest fans to run with the work wey dem dey passionate about, e go reduce the pressure to dey do everything yourself.
+
+### Make you write everything for document
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  You don ever dey for one (tech) event wey you no sabi anybody, but all the other people dey form groups and dey yarn like old friends? (...) Now imagine say you wan contribute to one open source project, but you no dey see why or how this one dey happen.
+  <p markdown="1" class="pquote-credit">
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+When you start one new project, e fit be like say e natural to dey keep your work private. But open source projects dey flourish when you document your process for public.
+
+When you write things down, more people fit participate at every stage of the way. You fit get help for something wey you never sabi say you need am.
+
+To write things down no mean only technical documentation. Anytime you feel the urge to write something down or privately discuss your project, ask yourself whether you fit make am public.
+
+Make you transparent about your project's roadmap, the types of contributions wey you dey look for, how contributions dey review, or why you make certain decisions.
+
+If you see say many people dey run into the same problem, make you document the answers for the README.
+
+For meetings, consider say make you publish your notes or key points for one relevant issue. The feedback wey you go get from this level of transparency fit surprise you.
+
+To document everything apply to the work wey you dey do, too. If you dey work on one substantial update for your project, make you put am for one pull request and mark am as one work in progress (WIP). So, other people fit dey involved for the process from the beginning.
+
+### Be responsive
+
+As you [promote your project](../finding-users), people fit get feedback for you. Them fit get questions about how things dey work, or them fit need help to begin.
+
+Try to dey responsive when person open one issue, submit one pull request, or ask question about your project. When you respond quick, people go feel say them dey part of one discussion, and them go dey more enthusiastic about participation.
+
+Even if you no fit review the request immediately, acknowledge am early to help increase engagement. @tdreyno respond to one pull request for [Middleman](https://github.com/middleman/middleman/pull/1466) like this:
+
+![Middleman pull request](/assets/images/building-community/middleman_pr.png)
+
+A Mozilla study talk say if dem review code within 48 hours, plenty contributors dey return and contribute again.
+
+Any talku talku about your project fit dey happen for other places online like Stack Overflow, Twitter, or Reddit. You fit set notification for some of these places so dem go alert you if person talk about your project.
+
+### Make you create one place where your community go gather
+
+E get two reason why you suppose create community place. The first reason na for dem, e go helep dem know each other. People wey get common interest must dey find place wey dem go yan about am. And when communication dey public and easy to reach, anybody fit read past messages make e understand wetin dey happen and fit join the talk. The second reason na for you. If you no create public place for people to discuss your project, dem fit contact you directly. For beginning e fit dey easy for you to respond to private messages "just this once". But as time dey go, especially if your project dey popular, you go dey tire. No gree make you dey communicate with people about your project for private. Instead, direct dem go one public place.
+
+Public communication fit be as simple as directing people make dem go open issue instead of sending mail give you directly or make dem comment for your blog. You fit also create mailing list, or make you create Twitter account, Slack, or IRC channel for people to talk about your project. Or you fit even try all of them!
+
+[Kubernetes kops] (https://github.com/kubernetes/kops#getting-involved) "Kubernetes kops dey set time every other week make dem helep community members:
+
+> Kops still get time wey dem set aside every other week to offer guidance and help to the community. Kops maintainers don agree to set time wey dem go use work with newcomers, helep with PRs, and yan about new features.
+
+Notable exceptions to public communication be: 1) security issues and 2) sensitive code of conduct violations. You suppose always get one way wey people fit report these issues for private. If you no wan use your personal email, set up one email wey dem go use just for this.
+
+## Make your community dey climb
+
+Communities get power. That power fit be good thing or bad thing, depending on how you use am. As your project community dey grow, there dey ways wey you fit use make am be force for building, no be destruction.
+
+### No dey tolerate bad actors
+
+Any popular project go always attract people wey go dey do bad things instead of helep. Dem fit dey start arguments wey no dey necessary, dey quarrel on top small-small things, or dey bully others.
+
+Do your best make you get zero-tolerance policy for these kind people. If you no fit control dem, these bad people fit dey make others for your community no dey comfortable. Dem fit even run.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
+  Di true be say gettin' support from community na di koko. I for neva fit do dis work witout di help from my colleagues, friendly pipo wey dey internet, an' di people wey dey chatty for IRC channels. No settle for less. No settle for assholes.
+   <p markdown="1" class="pquote-credit">
+— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+  </p>
+</aside>
+
+Regular debates on top small-small parts of your project dey distract others, and even you, from focusing on important work. New people wey show for your project fit see these arguments and no wan join.
+
+Any time you see bad behavior wey dey happen for your project, yan am out for public. Explain, with kind but firm words, why their behavior no good. If the problem no stop, you fit need [tell them make dem waka](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) fit be useful guide for these talks.
+
+### Meet contributors where dem dey
+
+Good documentation dey very important as your community dey grow. People wey no dey familiar with your project fit read your documentation make dem quickly understand wetin dey happen.
+
+In your CONTRIBUTING file, tell new contributors explicitly how dem go take start. You fit even make one special section for this purpose. [Django](https://github.com/django/django), for example, get one special landing page to welcome new contributors.
+
+![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
+
+For your issue queue, label bugs wey dey suitable for different types of contributors, like [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) These labels go helep someone wey dey new to your project to easily look your issues and take start.
+
+Use your documentation to helep people feel welcome at every step.
+
+For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+You no go fit talk with most people wey go show for your project. Some people fit come helep you wey you no go sabi because dem feel say dem dey intimidated or dem no sabi where to take start. Even few kind words fit helep make person no commot for your project for frustration.
+
+### Share the person waeh get your project
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
+  Una leaders go get different opinions, as all healthy communities should! The thing be say, you gas take steps to make sure the loudest voice no dey always win by tiring people out, and that small small voices for our midst, we dey hear am.
+  <p markdown="1" class="pquote-credit">
+— @sagesharp, ["Wetin makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+  </p>
+</aside>
+
+People dey ginger to yan-kick for projects when dem feel like dem get sense of ownership. E no mean say you go come give dem your project vision or gree accept contributions wey you no want. But as you dey respect and appreciate other people efforts, e go make dem dey yan-kick.
+
+Try look for ways wey you fit share this ownership with your community as much as possible. Some yeye ideas wey you fit try include:
+
+* **No dey hurry to fix small-small (non-serious) wahala.** Instead, use am as chance to bring new contributors or show person way wan yan-kick. E fit look strange at first, but as time go dey, your investment go bring profit. For example, @michaeljoseph tell one person say make e submit pull request for [Cookiecutter](https://github.com/audreyr/cookiecutter) issue for down, instead of make e fix am himself.
+
+![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
+
+* **Start CONTRIBUTORS or AUTHORS file for your project** wey go list everybody wey don yan-kick for your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) do.
+
+* If your community don shapely well-well, **send newsletter or write blog post** to appreciate the people wey don yan-kick. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) na two examples wey dey good.
+
+* **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.
+
+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.
+
+Even if you no fit always find person to answer the call, once you put signal for there, e dey increase chance say other people go waka come yan-kick. The earlier you start, the better for you, because e go make people waka come fast-fast.
+
+Na for [Welcoming Communities](http://hood.ie/blog/welcoming-communities.html), @gr2m yarn say e dey for your [best interest](https://peerj.com/preprints/1233/) to find contributors wey sabi and enjoy to do the things wey you no sabi. If you like code but e no dey easy for you to answer issues, try find people for your community wey sabi, make dem handle am.
+
+## Settling Wahala
+
+As your project dey begin, e dey easy to make major decisions. When you wan do something, e fit be like breeze, you go just do am.
+
+As your project dey popular, more people go dey chook eye for the decisions wey you dey take. Even if you no get big community of contributors, if your project get many users, people go wan add their mouth for the decisions or raise their own issues.
+
+Aside small-small issues wey e clear say your community go fit resolve, sometimes you fit see say one issue dey tough small small.
+
+### Arrange everything make kindness dey
+
+When your community dey tackle one yeye issue, tempers fit dey rise. People fit vex or feel frustrated and dem fit they chook mouth for each other or for your matter.
+
+Your work as maintainer na to make sure say these situations no go high. Even if you get strong opinion on top the matter, try play moderator or facilitator role, no just enter the matter dey force your views. If person no dey polite or e dey use mouth scatter discussions, [take action immediately](../building-community/#dont-tolerate-bad-actors) to make sure say discussions dey civil and productive.
+
+Other people dey look you for guidance. Set example wey go make sense. You fit still yan your disappointment, sorrow or concern, but do am calmly.
+
+Make your head nor dey hot e nor easy, but as you set good example, e go make your community strong. The internet dey thank you.
+
+### Treat README like say na constitution
+
+Your README [no be only set of instructions](../starting-a-project/#writing-a-readme). E also na place to yan about your goals, product vision, and roadmap. If people dey focus too much on top argument about one particular feature, e fit help if you go back your README, talk about the higher vision of your project. To focus on your README go even make the matter no dey personal, so that you go fit yan-kick with sense.
+
+
+### Make we focus for the journey, nor be the destination
+
+Some projects dey use voting process to take make major decisions. E fit look sensible for eye at first, but voting dey show say them dey find 'answer,' instead of say them dey listen to each other concerns.
+
+Voting fit turn political, where people for the community go dey fear say them go gree do favors for each other or vote in one particular way. Nor be everybody go fit vote, whether e na the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) for your community or people wey dey use your project wey nor know say vote dey happen.
+
+Sometimes, voting na necessary way to take settle wahala. But as much as you fit, try dey emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) instead of consensus.
+
+For one consensus seeking process, community members go yan about major concerns until them believe say their talk don dey enough. When only small-small concerns still dey, the community go dey go front. "Consensus seeking" no dey expect say the community go reach perfect answer. Instead, e dey focus on listening and discussion.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
+  One major reason why Atom Issues nor get voting system na because the Atom team nor go follow voting system for all cases. Sometimes, we go dey choose wetin we believe say dey right, even if e nor dey popular. (...) The thing wey I fit offer and promise to do... na say, e dey my work to dey hear the community.
+  <p markdown="1" class="pquote-credit">
+— @lee-dohm on Atom's decision making process
+  </p>
+</aside>
+
+Even if you nor actually use consensus seeking process, as a project maintainer, e dey important make people know say you dey hear them. To show say you dey hear people and you dey ready to settle their wahala, e dey help to cool down tense situations. After that, follow your words with actions.
+
+Don't dey rush make you take decision just because you wan find solution. Try make everybody feel say dem don dey hear and all information dey public before you fit find solution.
+
+### Make we dey yan for action
+
+Discussion dey important, but difference dey between productive and unproductive talks.
+
+Encourage discussion as long as e dey carry us close to solution. If e clear say the talk dey delay or dem dey yan out of the matter or e dey like say dem dey yan personal talk, or people dey yan yeye about small details, e dey time to stop am.
+
+If you allow this kind talk to continue, e no go only bad for the issue wey dey ground, e go dey bad for the health of your community. E go show say this kind talk na normal thing wey them dey allow or even dey encourage, and e fit discourage people from raising or settling future issues.
+
+For every talk wey you talk or other people talk, ask yourself, _"How this one wan carry us closer to solution?
+
+If the talk dey scatter, make you ask the group, _"Which steps we wan take next?"_ to refocus the discussion.
+
+If the talk clear nor dey waka, e nor get clear action to take, or the right action don already happen, close the issue and yan why you close am.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+  </p>
+</aside>
+
+
+### Choose your battles with sense
+
+Context dey important. Think about the people wey dey the discussion and how them represent the rest of the community.
+
+Na all the community dey vex or even follow for this issue? Or na just one person wey wan dey find trouble? No forget say you suppose consider your silent community members, nor be only the people wey dey yan.
+
+If the issue nor dey show the real needs of your community, you fit just gree say the concerns of few people matter. If this one na issue wey dey always come up and nor dey get clear solution, tell them say make them check discussions wey dem don already talk about the matter before and close the discussion.
+
+### Identify person or group wey fit be community tiebreaker
+
+With correct attitude and clear communication, many difficult situations fit dey easy to settle. But even for productive talk, e fit still dey difference for opinion on how to dey move front. For this kind situation, identify one person or group of people wey fit help settle the wahala.
+
+One tiebreaker fit be the main person wey dey control the project, or e fit be small group of people wey fit make decision based on voting. E good make you don already identify tiebreaker and the process for GOVERNANCE file before e go happen.
+
+Your tiebreaker suppose be last option. Issues wey dey cause fight for community dey make the community fit grow and learn. Embrace the opportunity and use collaborative process to find solution where you fit.
+
+## Community na the ❤️ of open source
+
+Healthy and vibrant communities na the engine wey dey fuel the plenty hours wey dem spend for open source every week. Many contributors dey point to other people as the reason why dem dey work - or nor dey work - for open source. As you sabi tap into that power constructively, you go fit help person somewhere get unforgettable open source experience.
diff --git a/_articles/pidgin/code-of-conduct.md b/_articles/pidgin/code-of-conduct.md
new file mode 100644
index 00000000000..6ed301d9c81
--- /dev/null
+++ b/_articles/pidgin/code-of-conduct.md
@@ -0,0 +1,58 @@
+---
+lang: pidgin
+title: Una Code of Conduct
+description: Make community people dey behave well and do constructive tins, by accepting and enforcing the code of conduct.
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+  - building
+  - leadership
+---
+
+## Code of conduct and why you need am?
+
+Code of conduct na document wey dey establish expectation for the way wey people go take behave for your project. To adopt, and enforce, code of conduct fit help create positive social atmosphere for your community.
+
+Code of conduct epp to protect not just the people wey dey participate for your project, but you too. If you dey maintain a project, you fit see say unproductive attitude from other people fit dey drain your energy and make you unhappy about your work as time dey go.
+
+Code of conduct dey give you power to encourage healthy and constructive community behavior. To dey proactive dey reduce the chance say you, or other people, go dey tire for your project, and epp you take action if person do something wey you nor gree with.
+
+## How you go take arrange code of conduct
+
+Make you try your best to arrange code of conduct early, if you fit, ideally when you first create your project.
+
+Apart from just communicating your expectations, code of conduct fit describe the following:
+
+- Where the code of conduct dey apply _(only on issues and pull requests, or community activities like events?)_
+- Whom the code of conduct dey apply to _(community members and maintainers, but what about sponsors?)_
+- Wetin go happen if person violate the code of conduct
+- How person fit report violations
+
+Anywhere way you fit, try to use previous example. The [Contributor Covenant](https://contributor-covenant.org/) na code of conduct wey many open source projects, including Kubernetes, Rails, and Swift, don use, and e fit serve as example.
+
+The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) na two good examples of code of conduct.
+
+Put one CODE_OF_CONDUCT file for your project's main directory, and make sure say your community fit see am by linking am for your CONTRIBUTING or README file.
+
+## How to enforce your code of conduct
+
+You suppose explain how you go enforce your code of conduct **_before_** person violate am. Some reasons why you suppose do am be say:
+
+- E show say you dey serious about action when e dey necessary.
+
+- Your community go dey reassured say complaints go dey reviewed.
+
+- You go reassure your community say the review process go dey fair and transparent, if at any time dem dey investigated for violation.
+
+You suppose give people private way (like email address) to report code of conduct violation and explain who go receive that report. E fit be maintainer, group of maintainers, or code of conduct working group.
+
+No forget say person fit wan report violation about person wey dey receive those reports. In this case, give dem option to report violations to another person. For example, @ctb and @mr-c [explain for their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.
+
+For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+
+## How to enforce your code of conduct
+
+Sometimes, despite your best efforts, somebody go do something wey dey violate this code. There are several ways to address negative or harmful behavior when it comes up.
diff --git a/_data/locales/pidgin.yml b/_data/locales/pidgin.yml
new file mode 100644
index 00000000000..7a6a648f6dd
--- /dev/null
+++ b/_data/locales/pidgin.yml
@@ -0,0 +1,31 @@
+en:
+  locale_name: English
+  nav:
+    about: About
+    contribute: Put hand
+  index:
+    lead: Open source software na people wey dey like you epp build am. Learn how to start and make your project big.
+    opensourcefriday: Na Friday! Spend few hours to contribute to the software wey you dey use and love.
+  article:
+    table_of_contents: Table of Contents
+    back_to_all_guides: Abeg, make I run go back to all those guides
+    related_guides: Related Guides
+    footer:
+    contribute:
+      heading: Put hand
+      description: You wan yan something? This mata wey dey here, e fit be your own. Abeg, helep us make e better.
+      button: Put hand
+    subscribe:
+      heading: Make we dey in contact
+      description: Make you be the first wey go hear about GitHub's latest open source tips and resources..
+      label: Email adiress
+      button: Folow
+    byline:
+      # [code], [love], and [github] will be replaced by octicons
+      format: "[code] with [love] by [github] and [friends]"
+      # Label for code octicon
+      code_label: code
+      # Label for love octicon
+      love_label: love
+      # Label for the contributors link
+      friends_label: padi
diff --git a/assets/css/translate.scss b/assets/css/translate.scss
index d8403e141b2..98c0508c3c9 100644
--- a/assets/css/translate.scss
+++ b/assets/css/translate.scss
@@ -26,6 +26,7 @@ $section_translation: (
         "tr": "",
         "zh-hant": "章節",
         "zh-hans": "章节",
+        "pidgin": "Portion",
 );
 
 @each $locale, $translation in $section_translation {

From 05644cfd4ca0d874b24f18fc437e150d00cb7b04 Mon Sep 17 00:00:00 2001
From: LizzyOrji123 <cegscutie4rill@yahoo.com>
Date: Tue, 24 Oct 2023 13:49:02 +0100
Subject: [PATCH 615/749] finished up code-of-conduct.md and created
 finding-users.md and wrote in it

---
 _articles/pidgin/code-of-conduct.md |  60 +++++++++++-
 _articles/pidgin/finding-users.md   | 144 ++++++++++++++++++++++++++++
 2 files changed, 202 insertions(+), 2 deletions(-)
 create mode 100644 _articles/pidgin/finding-users.md

diff --git a/_articles/pidgin/code-of-conduct.md b/_articles/pidgin/code-of-conduct.md
index 6ed301d9c81..d008849c68f 100644
--- a/_articles/pidgin/code-of-conduct.md
+++ b/_articles/pidgin/code-of-conduct.md
@@ -35,7 +35,14 @@ The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Ci
 
 Put one CODE_OF_CONDUCT file for your project's main directory, and make sure say your community fit see am by linking am for your CONTRIBUTING or README file.
 
-## How to enforce your code of conduct
+## How you go take think your code of conduct to stand gidi gba
+
+<aside markdown="1" class="pquote">
+  Code of conduct wey dem nor dey enforce, or wey dem nor fit enforce, e bad pass if dem nor get any code of conduct: e show say the values wey dey the code of conduct nor dey important or dem nor dey respected for your community.
+  <p markdown="1" class="pquote-credit">
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+  </p>
+</aside>
 
 You suppose explain how you go enforce your code of conduct **_before_** person violate am. Some reasons why you suppose do am be say:
 
@@ -53,6 +60,55 @@ No forget say person fit wan report violation about person wey dey receive those
 
 For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
 
-## How to enforce your code of conduct
+## How your code of conduct go take stand gidi gba
 
 Sometimes, despite your best efforts, somebody go do something wey dey violate this code. There are several ways to address negative or harmful behavior when it comes up.
+
+### Gather plenty gist about the mata
+
+Arrange community member voice make aeh dey important as your own dey. If person report say somebody violate the code of conduct, take am seriously and investigate the matter, even if e nor match your own experience with that person. As you do like this, you dey show your community say you value their perspective and trust their judgment.
+
+The community member wey dey involved fit be person wey dey always cause trouble and dey make other people dey uncomfortable, or e fit be say e talk or do something just once. You fit take action based on the situation.
+
+Before you yarn, give yourself time to understand wetin happen. Read the person's past comments and conversations make you sabi who e be and why e fit do something like that. Try gather different perspectives from other people about the person and the way e take behave.
+
+<aside markdown="1" class="pquote">
+  No let yourself enter argument. No allow yourself sidetrack, dey address another person's behavior before you don finish with the main matter. Just focus on wetin you need.
+  <p markdown="1" class="pquote-credit">
+— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+  </p>
+</aside>
+
+### Carry action waeh make sense
+
+After you don gather and process enough information, you go need to decide wetin you go do. As you dey consider your next steps, remember say your goal as a moderator na to promote safe, respectful, and collaborative environment. Consider how you go take handle the matter and how your response fit affect the way other community members go take dey behave and their expectations for future.
+
+If person report say somebody violate the code of conduct, e na you suppose handle am, not the person wey report. Sometimes, the person wey report dey risk plenty things like e career, reputation, or physical safety. Forcing am to confront the person wey dey harass am fit put am for wahala. You suppose dey communicate directly with the person wey dey involved, except the person wey report request something different.
+
+You fit respond to code of conduct violation for different ways:
+
+- **Warn the person wey dey involved publicly** and explain how their behavior affect others, preferably for the place where e happen. If possible, public communication go show the rest of the community say you dey serious about the code of conduct. Make you dey kind but firm for your communication.
+
+- **Privately reach out to the person** wey dey involved to explain how their behavior affect others. You fit use private communication channel if the situation get sensitive personal information. If you communicate privately with person, e good make you CC those wey first report the situation, so dem go know say you don take action. Ask the person wey report make e agree before you CC am.
+
+Sometimes, you fit no fit resolve the matter. The person wey dey involved fit dey aggressive or hostile when you confront am, or e no fit change their behavior. For this kind situation, you fit consider stronger action. For example:
+
+- **Suspend the person** wey dey involved for the project, you go enforce am through temporary ban wey go stop am from participating for any aspect of the project.
+
+- **Permanently ban** the person from the project.
+
+Make you no take banning members lightly, e be like say e be something wey no fit change and no fit reconcile different perspectives. You suppose only take these measures if e clear say you no fit resolve the matter.
+
+## The work waeh you fit do as a maintainer
+
+Code of conduct nor be law wey dem just dey put as dem like. Na you be the enforcer of the code of conduct and e dey your responsibility to follow the rules wey the code of conduct don establish.
+
+As a maintainer, na you set the guidelines for your community and you go enforce those guidelines based on the rules wey dey your code of conduct. This one mean say, any report wey you receive about code of conduct violation, you suppose take am serious. The person wey report the matter suppose get thorough and fair review of wetin dem complain. If you come find out say the behavior wey dem report nor be violation, make you yan that one give dem straight and explain why you nor go take action on top am. As dem see that one, na them sabi how dem go fit take the behavior wey dem dey complain tolerate, or dem fit stop to dey participate for the community.
+
+If person report behavior wey nor _technically_ violate the code of conduct, e fit still show say there be problem for your community, and you suppose investigate this potential problem and take action as e dey necessary. This one fit include say you go revise your code of conduct to make am clear the kind behavior wey dem go accept, or make you talk to the person wey dem report say e dey skirt the edge of wetin dem expect and e dey make some participants dey uncomfortable, although e nor violate the code of conduct.
+
+In the end, as a maintainer, na you dey set and enforce the standards for acceptable behavior. You get the power to shape the community values of the project, and participants dey expect make you enforce those values in a way wey dey fair and even-handed.
+
+## Encourage the character wey you want make people see for this world 🌎
+
+When person see say one project nor dey friendly or e nor dey welcoming, even if e just one person behavior people still dey tolerate, e fit make plenty contributors run comot, some of dem wey you never go fit even see. E nor dey always easy to adopt or enforce code of conduct, but if you dey promote environment wey dey welcoming, e go help your community grow.
diff --git a/_articles/pidgin/finding-users.md b/_articles/pidgin/finding-users.md
new file mode 100644
index 00000000000..a1b620e1ed3
--- /dev/null
+++ b/_articles/pidgin/finding-users.md
@@ -0,0 +1,144 @@
+---
+lang: pidgin
+title: How to find the people to helep your project
+description: You go helep your open source project grow if you bin put am with people waeh dey happy happy.
+class: finding
+order: 3
+image: /assets/images/cards/finding.png
+related:
+  - beginners
+  - building
+---
+
+## Dey talk the koko
+
+Dem nor get law wey talk say you suppose promote open source project when you first launch am. Plenty reasons dey wey fit make person dey work for open source wey nor get to do with popularity. Instead make you hope say other people go find and use your open source project, you suppose spread the word about your hard work!
+
+## Make you dey find your message
+
+Before you start the real work of promotion for your project, you suppose sabi explain wetin your project dey do, and why e dey important.
+
+Wetin make your project different or interesting? Why you create am? As you dey think about your project's message and value, try look am through the eyes of the people wey fit use am and those wey fit contribute to am.
+
+For example, @robb dey use code examples to yan clearly why him project, [Cartography](https://github.com/robb/Cartography), dey useful:
+
+![Cartography README](/assets/images/finding-users/cartography.jpg)
+
+If you wan go deeper for messaging, check Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+
+## Helep people to dey find and folow your project
+
+<aside markdown="1" class="pquote">
+  Ideally, you suppose get one "home" URL wey you go fit promote and direct people to for your project. You nor need spend plenty money for fine design or even buy domain name, but your project suppose get one main place where people fit find am.
+  <p markdown="1" class="pquote-credit">
+— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+  </p>
+</aside>
+
+**Make you get clear handle to promote your work.** Twitter handle, GitHub URL, or IRC channel na easy way wey you fit use point people to your project. These outlets still dey give your project's growing community place wey dem go fit gather.
+
+If you nor wan set up outlets for your project now, make you dey promote your own Twitter or GitHub handle for everything wey you dey do. Promoting your Twitter or GitHub handle go show people how dem fit take contact you or follow your work. If you go talk for meeting or event, make you sure say your contact information dey for your bio or slides.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
+  One mistake wey I make for those early days... no be say I start Twitter account for the project. Twitter na better way to dey give people updates about the project and dey always show people the project.
+  <p markdown="1" class="pquote-credit">
+— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+  </p>
+</aside>
+
+**Make you think about create website for your project.** Website dey make your project dey friendly and easy to navigate, especially when you combine am with clear documentation and tutorials. Having website still show say your project dey active and e go make your audience feel comfortable say dem fit use am. Give examples to show people as dem fit take use your project.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, talk say website na _"by far the best thing we did with Django in the early days"_.
+
+If your project dey for GitHub, you fit use [GitHub Pages](https://pages.github.com/) create website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) na [few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+
+![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
+
+Now wey you don get message for your project and easy way wey people fit take find your project, make you waka comot go yan with your audience!
+
+## Go where your project's audience dey (online)
+
+Online outreach na correct way wey you fit take share and spread the word quickly. As you use online channels, e fit help you reach wide audience.
+
+Make you use existing online communities and platforms to reach your audience. If your open source project na software project, e possible say you fit find your audience for [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels wey you believe say people go benefit well or go dey excited about your work.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
+  Each program get specific functions wey only small number of users go find useful. Nor go dey disturb plenty people as you fit. Instead, focus your efforts on communities wey go gain from knowing about your project.
+  <p markdown="1" class="pquote-credit">
+— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+  </p>
+</aside>
+
+See as you fit find ways to share your project well:
+
+* **Know the relevant open source projects and communities.** Sometimes, you nor need promote your project directly. If your project dey perfect for data scientists wey dey use Python, make you sabi the Python data science community. As people sabi you, opportunities go naturally show face to talk about and share your work.
+* **Find people wey dey face the problem wey your project solve.** Search through forums wey relate to your project's target audience, and try to answer their questions. If e dey right, find polite way to suggest your project as solution.
+* **Ask for feedback.** Introduce yourself and your work to audience wey your project fit benefit. Make you specific about the people wey you think say your project go fit help. Try to complete the sentence: _"I think my project go really help X, people wey dey try do Y_". Listen and respond to others' feedback, rather than just promoting your work.
+
+Generally, focus on helping others before you ask for something in return. Because anybody fit easily promote project online, e go get plenty noise. To stand out from the crowd, give people background about who you be, nor be just wetin you want.
+
+If nobody pay attention or respond to your initial outreach, nor let am discourage you! Most project launches nor dey one-time thing, e fit take months or years. If you nor get response the first time, try different method, or look for ways to add value to other people's work first. Promotion and launch of your project go take time and dedication.
+
+## Waka go where your project's audience dey (offline)
+
+![Public speaking](/assets/images/finding-users/public_speaking.jpg)
+
+Offline events dey very popular to promote new projects to people. Dem be very good way to reach audience wey dey engage and build better human connections, especially if you wan reach developers.
+
+If you be [newbie for public speaking](https://speaking.io/), you fit start by dey find local meetup wey relate to the language or system wey your project dey based on.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
+  I bin dey very nervous about PyCon. I bin wan give talk, I only know few people wey dey there, I bin wan dey there for one whole week. (...) But I no suppose dey worry, PyCon bin sweet die! (...) Everybody bin friendly and I rarely get time wey I no dey talk with people!
+  <p markdown="1" class="pquote-credit">
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+  </p>
+</aside>
+
+If you never talk for event before, e dey normal to feel nervous! Just remember say the people wey dey the audience dey there because dem really wan hear wetin you wan talk about.
+
+As you dey write your talk, try focus on the things wey your audience go find interesting and get value from. Make your language dey friendly and approachable. Smile, breathe well, and enjoy yourself.
+
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
+  When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+  <p markdown="1" class="pquote-credit">
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+  </p>
+</aside>
+
+When you feel say you don ready, try consider talk for conference to promote your project. Conferences fit help you reach plenty people, sometimes from different parts of the world.
+
+Find conferences wey relate to the language or system wey your project dey use. Before you submit your talk, try do research about the conference so that you fit arrange your talk to match the people wey go attend and increase your chance to talk for the conference. Sometimes you fit know the kind of audience wey you wan get by checking the people wey don talk for the conference before.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt= "avatar">
+  I write polite message to the JSConf people beg them make dem give me small chance make I fit talk for JSConf EU. (...) I bin very scared, I wan present the thing wey I don work on for six months. (...) All the time I bin dey think, oh my God. Wetin I dey do here?
+  <p markdown="1" class="pquote-credit">
+— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+  </p>
+</aside>
+
+## Kulekule your reputation
+
+Apart from the strategies wey we don yarn before, the best way to invite people to share and contribute to your project na to share and contribute to their projects.
+
+To help newcomers, share resources, and make thoughtful contributions to other people's projects go help you build positive reputation. To be an active member for open source community go help people to understand wetin you dey do, and dem fit dey pay attention to and share your project. To dey develop relationships with other open source projects fit even lead to official partnerships.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
+  The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+  <p markdown="1" class="pquote-credit">
+— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+  </p>
+</aside>
+
+E no dey too early or too late to begin build your reputation. Even if you don launch your own project before, dey always look for ways to help others.
+
+No get quick fix wey go give you audience. To gain the trust and respect of others dey take time, and building your reputation no dey end.
+
+## No relent!
+
+E fit tey before people go notice your open source project. E dey okay! Some of the most popular projects wey dey today, e take years before dem reach the level wey dem dey now. Focus on building relationships instead of dey hope say your project go just blow. Be patient, and continue to dey share your work with those wey dey appreciate am.

From 9ce4c183618d8501a85a8b440fff6db888a4ff4f Mon Sep 17 00:00:00 2001
From: Eric Sorenson <eric.sorenson@puppetlabs.com>
Date: Thu, 26 Oct 2023 14:50:03 -0700
Subject: [PATCH 616/749] Fix broken link on spanish leadership-and-governance

The quote was just providing context in square brackets, but it had
gotten turned into a link in this translation. The destination didn't
exist, so tests were failing.
---
 _articles/es/leadership-and-governance.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/es/leadership-and-governance.md b/_articles/es/leadership-and-governance.md
index db7c75c3eb0..8c1425be265 100644
--- a/_articles/es/leadership-and-governance.md
+++ b/_articles/es/leadership-and-governance.md
@@ -32,7 +32,7 @@ Un mantenedor no necesariamente tiene que ser alguien que escribe c&oacute;digo
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  Para [Node.js](https://nodejs.org/es/), cada persona que se presenta para comentar un problema o env&iacute;a c&oacute;digo es un miembro de la comunidad de un proyecto. S&oacute;lo ser capaz de verlos significa que han cruzado la l&iacute;nea de ser un usuario a ser un contribuyente.
+  [Para Node.js], cada persona que se presenta para comentar un problema o env&iacute;a c&oacute;digo es un miembro de la comunidad de un proyecto. S&oacute;lo ser capaz de verlos significa que han cruzado la l&iacute;nea de ser un usuario a ser un contribuyente.
   <p markdown="1" class="pquote-credit">
 — @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
   </p>

From b80fb715495a62db52eddece327619f5f7eb5f03 Mon Sep 17 00:00:00 2001
From: Robson Cruz <ghost0092@gmail.com>
Date: Tue, 24 Oct 2023 19:32:19 -0300
Subject: [PATCH 617/749] docs(pt): translate article body

---
 ...ing-balance-for-open-source-maintainers.md | 153 ++++++++++--------
 1 file changed, 83 insertions(+), 70 deletions(-)

diff --git a/_articles/pt/maintaining-balance-for-open-source-maintainers.md b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
index 1c832e12eaa..f5f0556a629 100644
--- a/_articles/pt/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
@@ -8,180 +8,193 @@ order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+Com o crescimento de popularidade de projetos código aberto, se torna importante definir limites para te ajudar a equilibrar se manter motivado e produtivo ao longo do tempo.
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+Para obter insights sobre as experiências dos mantenedores e suas estratégias para encontrar equilíbrio, realizamos uma oficina com 40 membros da <a href="http://maintainers.github.com/">Comunidade de Mantenedores</a>, permitindo-nos aprender com suas experiências pessoais de esgotamento em código aberto e as práticas que os ajudaram a manter o equilíbrio em seu trabalho. É aqui que o conceito de ecologia pessoal entra em jogo.
 
-So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+Então, o que é a ecologia pessoal? Conforme <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">descrito pelo Instituto de Liderança Rockwood</a>, envolve "<strong>manter o equilíbrio, o ritmo e a eficiência para sustentar nossa energia ao longo de uma vida</strong>." Isso moldou nossas conversas, ajudando os mantenedores a reconhecerem suas ações e contribuições como partes de um ecossistema maior que evolui ao longo do tempo. O esgotamento, uma síndrome resultante do estresse crônico no local de trabalho, conforme [definido pela OMS](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), não é incomum entre mantenedores. Isso frequentemente leva a uma perda de motivação, incapacidade de se concentrar e falta de empatia pelos colaboradores e comunidade com os quais você trabalha.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
-  I was unable to focus or start on a task. I had a lack of empathy for users.
+  Eu não conseguia me concentrar ou começar uma tarefa. Eu tinha uma falta de empatia pelos usuários.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, mantenedor do servidor de streaming ao vivo Owncast, sobre o impacto do esgotamento em seu trabalho de código aberto
   </p>
 </aside>
 
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+Ao abraçar o conceito de ecologia pessoal, os mantenedores podem evitar o esgotamento de forma proativa, priorizar o autocuidado e manter um senso de equilíbrio para fazer o seu melhor trabalho.
 
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+## Dicas de Autocuidado e Prevenção do Esgotamento como Mantenedor:
 
-### Identify your motivations for working in open source
+### Identifique suas motivações para trabalhar em código aberto
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+Dedique um tempo para refletir sobre quais aspectos da manutenção em código aberto o energizam. Compreender suas motivações pode ajudá-lo a priorizar o trabalho de uma maneira que o mantenha envolvido e pronto para novos desafios. Seja o retorno positivo dos usuários, a alegria de colaborar e socializar com a comunidade ou a satisfação de mergulhar no código, reconhecer suas motivações pode ajudar a direcionar o seu foco.
 
-### Reflect on what causes you to get out of balance and stressed out
+### Reflita sobre o que causa desequilíbrio e estresse
 
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+É importante entender o que nos leva ao esgotamento. Aqui estão alguns temas comuns que encontramos entre mantenedores de código aberto:
 
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+* **Falta de feedback positivo:** Os usuários tendem a entrar em contato quando têm uma reclamação. Se tudo funciona bem, tendem a ficar em silêncio. Pode ser desanimador ver uma crescente lista de problemas sem o feedback positivo mostrando como suas contribuições fazem a diferença.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
-  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  Às vezes, parece um pouco como gritar no vazio e acho que o feedback realmente me energiza. Temos muitos usuários felizes, mas silenciosos.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+— <a href="https://github.com/thisisnic">@thisisnic</a>, mantenedor do Apache Arrow
   </p>
 </aside>
 
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **Não dizer 'não':** Pode ser fácil assumir mais responsabilidades do que se deveria em um projeto de código aberto. Seja de usuários, colaboradores ou outros mantenedores, nem sempre podemos corresponder às expectativas deles.
 
 <aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
-  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt "avatar">
+  Percebi que estava assumindo mais do que deveria e tendo que fazer o trabalho de várias pessoas, como comumente é feito em FOSS.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, mantenedor do Termux, sobre o que causa o esgotamento em seu trabalho
   </p>
 </aside>
 
-* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+* **Trabalhar sozinho:** Ser um mantenedor pode ser incrivelmente solitário. Mesmo se você trabalha com um grupo de mantenedores, os últimos anos têm sido difíceis para reunir equipes distribuídas pessoalmente.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
- Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  Especialmente desde a COVID e o trabalho em casa, é mais difícil nunca ver ninguém ou falar com ninguém.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, mantenedor do servidor de streaming ao vivo Owncast, sobre o impacto do esgotamento em seu trabalho de código aberto
   </p>
 </aside>
 
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **Falta de tempo ou recursos:** Isso é especialmente verdade para mantenedores voluntários que têm que sacrificar seu tempo livre para trabalhar em um projeto.
 
 <aside markdown="1" class="pquote">
-  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  [Eu gostaria de ter] mais apoio financeiro, para que eu possa me concentrar no trabalho de código aberto sem esgotar minhas economias e sabendo que terei que fazer muitos contratos para compensar depois.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— mantenedor de código aberto
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Demandas conflitantes:** O código aberto é cheio de grupos com diferentes motivações, o que pode ser difícil de navegar. Se você é pago para fazer código aberto, os interesses de seu empregador às vezes podem entrar em conflito com a comunidade.
 
 <aside markdown="1" class="pquote">
-  With paid open source, conflict between employer's focus and what's best for the community
+  Com código aberto pago, conflito entre o foco do empregador e o que é melhor para a comunidade.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— mantenedor de código aberto
   </p>
 </aside>
 
-### Watch out for signs of burnout
+### Fique atento aos sinais de esgotamento
 
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+Você consegue manter seu ritmo por 10 semanas? 10 meses? 10 anos?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+Existem ferramentas como a [Lista de Verificação de Esgotamento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) e o kit de autoavaliação de ecologia pessoal da Mozilla (https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que podem ajudá-lo a refletir sobre seu ritmo atual e ver se há ajustes que você pode fazer. Alguns mantenedores também usam tecnologia vestível para acompanhar métricas como qualidade do sono e variabilidade da frequência cardíaca (ambas relacionadas ao estresse).
 
 <aside markdown="1" class="pquote">
- I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+ Sou um grande defensor dos dispositivos vestíveis. Com a ciência por trás deles, você pode entender como poderia ter se saído melhor e como atingir um estado ideal do que deseja fazer.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— mantenedor de código aberto
   </p>
 </aside>
 
-### What would you need to continue sustaining yourself and your community?
+### Fique atento aos sinais de esgotamento
 
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+Você consegue manter seu ritmo por 10 semanas? 10 meses? 10 anos?
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+Existem ferramentas como a [Lista de Verificação de Esgotamento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) e o kit de autoavaliação de ecologia pessoal da Mozilla (https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que podem ajudá-lo a refletir sobre seu ritmo atual e ver se há ajustes que você pode fazer. Alguns mantenedores também usam tecnologia vestível para acompanhar métricas como qualidade do sono e variabilidade da frequência cardíaca (ambas ligadas ao estresse).
 
-  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+<aside markdown="1" class="pquote">
+ Sou um grande defensor de dispositivos vestíveis de qualidade. Com a ciência por trás deles, você pode entender como poderia ter se saído melhor e como atingir um estado ideal do que deseja fazer.
+  <p markdown="1" class="pquote-credit">
+— mantenedor de código aberto
+  </p>
+</aside>
+
+### O que você precisa para continuar sustentando a si mesmo e à sua comunidade?
+
+Isso será diferente para cada mantenedor e mudará dependendo de sua fase de vida e outros fatores externos. Mas aqui estão alguns temas que ouvimos:
+
+* **Conte com a comunidade:** Delegação e encontrar colaboradores podem aliviar a carga de trabalho. Ter vários pontos de contato para um projeto pode ajudar você a tirar uma folga sem preocupações. Conecte-se com outros mantenedores e a comunidade em geral – em grupos como a [Comunidade de Mantenedores](http://maintainers.github.com/). Isso pode ser uma ótima fonte de apoio mútuo e aprendizado.
+
+  Você também pode procurar maneiras de se envolver com a comunidade de usuários, para ouvir regularmente feedback e entender o impacto de seu trabalho de código aberto.
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **Explore o financiamento:** Esteja você procurando um dinheiro extra para pizza ou tentando se dedicar integralmente ao código aberto, há muitos recursos disponíveis! Como primeiro passo, considere ativar [Patrocinadores do GitHub](https://github.com/sponsors) para permitir que outros patrocinem seu trabalho de código aberto. Se você está pensando em dar o salto para o tempo integral, inscreva-se para a próxima rodada do [GitHub Accelerator](http://accelerator.github.com/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
- I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+ Participei de um podcast há algum tempo e estávamos conversando sobre manutenção de código aberto e sustentabilidade. Descobri que mesmo um pequeno número de pessoas apoiando meu trabalho no GitHub me ajudou a tomar uma decisão rápida de não ficar na frente de um jogo, mas sim fazer uma pequena contribuição ao código aberto.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+— <a href="https://github.com/mansona">@mansona</a>, mantenedor do EmberJS
   </p>
 </aside>
 
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+* **Use ferramentas:** Explore ferramentas como [GitHub Copilot](https://github.com/features/copilot/) e [GitHub Actions](https://github.com/features/actions/) para automatizar tarefas mundanas e liberar tempo para contribuições mais significativas.
 
 <aside markdown="1" class="pquote">
- Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+ Use o [Copilot](https://github.com/features/copilot/) para as coisas chatas - faça as coisas divertidas
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— mantenedor de código aberto
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+* **Descanse e recarregue:** Reserve tempo para seus hobbies e interesses fora do código aberto. Tire os fins de semana para relaxar e rejuvenescer - e ajuste seu [status do GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) para refletir sua disponibilidade! Uma boa noite de sono pode fazer uma grande diferença em sua capacidade de manter seus esforços a longo prazo.
 
-  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+  Se você encontrar certos aspectos de seu projeto particularmente agradáveis, tente estruturar seu trabalho de forma que você possa experimentá-los ao longo do dia.
 
 <aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class "pquote-avatar" alt="avatar">
+ Estou encontrando mais oportunidade para espalhar 'momentos de criatividade' no meio do dia, em vez de tentar desligar à noite.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+— <a href="https://github.com/danielroe">@danielroe</a>, mantenedor do Nuxt
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **Estabeleça limites:** Você não pode dizer sim para todos os pedidos. Isso pode ser tão simples quanto dizer: "Não consigo fazer isso agora e não tenho planos de fazê-lo no futuro" ou listar o que você tem interesse em fazer e o que não tem no README. Por exemplo, você pode dizer: "Só aceito solicitações de pull que tenham razões claras para sua criação" ou "Só reviso problemas em todas as quintas-feiras, das 18h às 19h." Isso estabelece expectativas para os outros e fornece algo a que você pode se referir em outros momentos para ajudar a reduzir as demandas de colaboradores ou usuários sobre o seu tempo.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+Para confiar de forma significativa em outras pessoas nesses aspectos, você não pode ser alguém que diz sim para todos os pedidos. Ao fazer isso, você não mantém limites, profissionais ou pessoais, e não será um colega confiável.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, mantenedor do Homebrew em [Dizer Não](https://mikemcquaid.com/saying-no/)
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+  Aprenda a ser firme em desligar comportamentos tóxicos e interações negativas. Não há problema em não dar energia a coisas com as quais você não se importa.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-My software is gratis, but my time and attention is not.
+Meu software é gratuito, mas meu tempo e atenção não são.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, mantenedor do Leaflet
   </p>
 </aside>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+Não é segredo que a manutenção de código aberto tem seus lados negros, e um deles é ter que interagir às vezes com pessoas bastante ingratas, arrogantes ou abertamente tóxicas. À medida que a popularidade de um projeto aumenta, aumenta também a frequência desse tipo de interação, aumentando o fardo dos mantenedores e se tornando possivelmente um fator de risco significativo para o esgotamento do mantenedor.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>, mantenedor do Octoprint em [Como lidar com pessoas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
 </aside>
 
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+Lembre-se, a ecologia pessoal é uma prática contínua que evoluirá à medida que você avança em sua jornada de código aberto. Ao priorizar o autocuidado e manter um senso de equilíbrio, você pode contribuir para a comunidade de código aberto de forma eficaz e sustentável, garantindo tanto o seu bem-estar quanto o sucesso de seus projetos a longo prazo.
 
-## Additional Resources
+## Recursos Adicionais
 
-* [Maintainer Community](http://maintainers.github.com/)
-* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
-* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
-* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [Comunidade de Mantenedores](http://maintainers.github.com/)
+* [O contrato social do código aberto](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [Como lidar com pessoas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
-* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
-* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
-* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+* [Kit de autoavaliação de ecologia pessoal](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Arte da Liderança Rockwood](https://rockwoodleadership.org/art-of-leadership/)
+* [Dizer Não](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governança do Código Aberto](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* A agenda do workshop foi adaptada a partir da série [Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) da Mozilla.
 
-## Contributors
+## Contribuidores
 
-Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+Muito obrigado a todos os mantenedores que compartilharam suas experiências e dicas conosco para este guia!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+Este guia foi escrito por [@abbycabs](https://github.com/abbycabs) com contribuições de:
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
@@ -218,4 +231,4 @@ This guide was written by [@abbycabs](https://github.com/abbycabs) with contribu
 [@thisisnic](https://github.com/thisisnic)
 [@tudoramariei](https://github.com/tudoramariei)
 [@UlisesGascon](https://github.com/UlisesGascon)
-[@waldyrious](https://github.com/waldyrious) + many others!
+[@waldyrious](https://github.com/waldyrious) + muitos outros!

From 7faba03ed44790d343b6bec55b13a553d791859d Mon Sep 17 00:00:00 2001
From: Robson Cruz <ghost0092@gmail.com>
Date: Tue, 24 Oct 2023 19:58:52 -0300
Subject: [PATCH 618/749] docs(pt): fix small typos on codeblocks

also update meta header
---
 ...maintaining-balance-for-open-source-maintainers.md | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/_articles/pt/maintaining-balance-for-open-source-maintainers.md b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
index f5f0556a629..d6a187e0e40 100644
--- a/_articles/pt/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
@@ -1,8 +1,7 @@
 ---
 lang: pt
-untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+title: Mantendo o Equilíbrio para Mantenedores de Código Aberto
+description: Dicas para o autocuidado e evitar o esgotamento como mantenedor.
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
@@ -47,7 +46,7 @@ Dedique um tempo para refletir sobre quais aspectos da manutenção em código a
 * **Não dizer 'não':** Pode ser fácil assumir mais responsabilidades do que se deveria em um projeto de código aberto. Seja de usuários, colaboradores ou outros mantenedores, nem sempre podemos corresponder às expectativas deles.
 
 <aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt "avatar">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
   Percebi que estava assumindo mais do que deveria e tendo que fazer o trabalho de várias pessoas, como comumente é feito em FOSS.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, mantenedor do Termux, sobre o que causa o esgotamento em seu trabalho
@@ -86,7 +85,7 @@ Dedique um tempo para refletir sobre quais aspectos da manutenção em código a
 
 Você consegue manter seu ritmo por 10 semanas? 10 meses? 10 anos?
 
-Existem ferramentas como a [Lista de Verificação de Esgotamento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) e o kit de autoavaliação de ecologia pessoal da Mozilla (https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que podem ajudá-lo a refletir sobre seu ritmo atual e ver se há ajustes que você pode fazer. Alguns mantenedores também usam tecnologia vestível para acompanhar métricas como qualidade do sono e variabilidade da frequência cardíaca (ambas relacionadas ao estresse).
+Existem ferramentas como a [Lista de Verificação de Esgotamento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) e o [kit de autoavaliação de ecologia pessoal da Mozilla](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que podem ajudá-lo a refletir sobre seu ritmo atual e ver se há ajustes que você pode fazer. Alguns mantenedores também usam tecnologia vestível para acompanhar métricas como qualidade do sono e variabilidade da frequência cardíaca (ambas relacionadas ao estresse).
 
 <aside markdown="1" class="pquote">
  Sou um grande defensor dos dispositivos vestíveis. Com a ciência por trás deles, você pode entender como poderia ter se saído melhor e como atingir um estado ideal do que deseja fazer.
@@ -99,7 +98,7 @@ Existem ferramentas como a [Lista de Verificação de Esgotamento](https://gover
 
 Você consegue manter seu ritmo por 10 semanas? 10 meses? 10 anos?
 
-Existem ferramentas como a [Lista de Verificação de Esgotamento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) e o kit de autoavaliação de ecologia pessoal da Mozilla (https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que podem ajudá-lo a refletir sobre seu ritmo atual e ver se há ajustes que você pode fazer. Alguns mantenedores também usam tecnologia vestível para acompanhar métricas como qualidade do sono e variabilidade da frequência cardíaca (ambas ligadas ao estresse).
+Existem ferramentas como a [Lista de Verificação de Esgotamento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) e o [kit de autoavaliação de ecologia pessoal da Mozilla](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que podem ajudá-lo a refletir sobre seu ritmo atual e ver se há ajustes que você pode fazer. Alguns mantenedores também usam tecnologia vestível para acompanhar métricas como qualidade do sono e variabilidade da frequência cardíaca (ambas ligadas ao estresse).
 
 <aside markdown="1" class="pquote">
  Sou um grande defensor de dispositivos vestíveis de qualidade. Com a ciência por trás deles, você pode entender como poderia ter se saído melhor e como atingir um estado ideal do que deseja fazer.

From 991c88e851a6697838e802b406dbe1d04567af69 Mon Sep 17 00:00:00 2001
From: Robson Cruz <ghost0092@gmail.com>
Date: Tue, 24 Oct 2023 20:10:21 -0300
Subject: [PATCH 619/749] docs: remove duplicated section

---
 ...intaining-balance-for-open-source-maintainers.md | 13 -------------
 1 file changed, 13 deletions(-)

diff --git a/_articles/pt/maintaining-balance-for-open-source-maintainers.md b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
index d6a187e0e40..7a97674bf76 100644
--- a/_articles/pt/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
@@ -85,19 +85,6 @@ Dedique um tempo para refletir sobre quais aspectos da manutenção em código a
 
 Você consegue manter seu ritmo por 10 semanas? 10 meses? 10 anos?
 
-Existem ferramentas como a [Lista de Verificação de Esgotamento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) e o [kit de autoavaliação de ecologia pessoal da Mozilla](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que podem ajudá-lo a refletir sobre seu ritmo atual e ver se há ajustes que você pode fazer. Alguns mantenedores também usam tecnologia vestível para acompanhar métricas como qualidade do sono e variabilidade da frequência cardíaca (ambas relacionadas ao estresse).
-
-<aside markdown="1" class="pquote">
- Sou um grande defensor dos dispositivos vestíveis. Com a ciência por trás deles, você pode entender como poderia ter se saído melhor e como atingir um estado ideal do que deseja fazer.
-  <p markdown="1" class="pquote-credit">
-— mantenedor de código aberto
-  </p>
-</aside>
-
-### Fique atento aos sinais de esgotamento
-
-Você consegue manter seu ritmo por 10 semanas? 10 meses? 10 anos?
-
 Existem ferramentas como a [Lista de Verificação de Esgotamento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) e o [kit de autoavaliação de ecologia pessoal da Mozilla](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que podem ajudá-lo a refletir sobre seu ritmo atual e ver se há ajustes que você pode fazer. Alguns mantenedores também usam tecnologia vestível para acompanhar métricas como qualidade do sono e variabilidade da frequência cardíaca (ambas ligadas ao estresse).
 
 <aside markdown="1" class="pquote">

From 481ae8cfef489a479d66211b700f1797caf4c714 Mon Sep 17 00:00:00 2001
From: Lakshmi N <79132440+lakshmi930@users.noreply.github.com>
Date: Sat, 28 Oct 2023 17:19:08 +0400
Subject: [PATCH 620/749] Add translation in hindi for section

---
 assets/css/translate.scss | 1 +
 1 file changed, 1 insertion(+)

diff --git a/assets/css/translate.scss b/assets/css/translate.scss
index d8403e141b2..4943d3a3730 100644
--- a/assets/css/translate.scss
+++ b/assets/css/translate.scss
@@ -12,6 +12,7 @@ $section_translation: (
         "es": "Sección",
         "fa": "",
         "fr": "Partie",
+        "hi": "खंड",
         "hu": "",
         "id": "",
         "ja": "",

From 4f42f167082e8d4a7b9320a14e3c378ad41acf92 Mon Sep 17 00:00:00 2001
From: KaitoMuraoka <kaitoboshi@icloud.com>
Date: Mon, 30 Oct 2023 23:38:31 +0900
Subject: [PATCH 621/749] Add punctuation

---
 _articles/ja/building-community.md        | 2 +-
 _articles/ja/code-of-conduct.md           | 2 +-
 _articles/ja/finding-users.md             | 2 +-
 _articles/ja/getting-paid.md              | 2 +-
 _articles/ja/leadership-and-governance.md | 2 +-
 _articles/ja/metrics.md                   | 2 +-
 _articles/ja/starting-a-project.md        | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/_articles/ja/building-community.md b/_articles/ja/building-community.md
index 90e84ac2a83..b0ba8ee8304 100644
--- a/_articles/ja/building-community.md
+++ b/_articles/ja/building-community.md
@@ -1,7 +1,7 @@
 ---
 lang: ja
 title: 居心地の良いコミュニティを築こう
-description: 人々があなたのプロジェクトを使ったり、コントリビュートしたり、人に伝えたくなるようなコミュニティを築きましょう
+description: 人々があなたのプロジェクトを使ったり、コントリビュートしたり、人に伝えたくなるようなコミュニティを築きましょう。
 class: building
 order: 4
 image: /assets/images/cards/building.png
diff --git a/_articles/ja/code-of-conduct.md b/_articles/ja/code-of-conduct.md
index 25b7e93c18e..91fa5226cbb 100644
--- a/_articles/ja/code-of-conduct.md
+++ b/_articles/ja/code-of-conduct.md
@@ -1,7 +1,7 @@
 ---
 lang: ja
 title: 行動規範
-description: 行動規範を採用し遵守してもらうことで、健全で建設的なコミュニティ作りを促進しよう
+description: 行動規範を採用し遵守してもらうことで、健全で建設的なコミュニティ作りを促進しよう。
 class: coc
 order: 8
 image: /assets/images/cards/coc.png
diff --git a/_articles/ja/finding-users.md b/_articles/ja/finding-users.md
index 2e2ff7fb836..43f12f8d94e 100644
--- a/_articles/ja/finding-users.md
+++ b/_articles/ja/finding-users.md
@@ -1,7 +1,7 @@
 ---
 lang: ja
 title: あなたのプロジェクトのユーザーを見つけよう
-description: あなたのプロジェクトを喜んで使ってくれるユーザーを獲得してプロジェクトを拡大しよう
+description: あなたのプロジェクトを喜んで使ってくれるユーザーを獲得してプロジェクトを拡大しよう。
 class: finding
 order: 3
 image: /assets/images/cards/finding.png
diff --git a/_articles/ja/getting-paid.md b/_articles/ja/getting-paid.md
index 26f2eaf24bc..801e4f70f4d 100644
--- a/_articles/ja/getting-paid.md
+++ b/_articles/ja/getting-paid.md
@@ -1,7 +1,7 @@
 ---
 lang: ja
 title: オープンソースで金銭を得る
-description: プロジェクト活動に対して金銭的サポートを得ることで、オープンソース活動を持続可能にしよう
+description: プロジェクト活動に対して金銭的サポートを得ることで、オープンソース活動を持続可能にしよう。
 class: getting-paid
 order: 7
 image: /assets/images/cards/getting-paid.png
diff --git a/_articles/ja/leadership-and-governance.md b/_articles/ja/leadership-and-governance.md
index dea45030763..48c6a9fc418 100644
--- a/_articles/ja/leadership-and-governance.md
+++ b/_articles/ja/leadership-and-governance.md
@@ -1,7 +1,7 @@
 ---
 lang: ja
 title: リーダーシップと組織運営
-description: 意思決定するためのルールを決めることで、オープンソースプロジェクトを成長させる助けとなります
+description: 意思決定するためのルールを決めることで、オープンソースプロジェクトを成長させる助けとなります。
 class: leadership
 order: 6
 image: /assets/images/cards/leadership.png
diff --git a/_articles/ja/metrics.md b/_articles/ja/metrics.md
index 1ae85e0a10b..756ff67548c 100644
--- a/_articles/ja/metrics.md
+++ b/_articles/ja/metrics.md
@@ -38,7 +38,7 @@ related:
 ![トラフィックグラフ](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
 もしプロジェクトを GitHub 上にホストしているのであれば、何人があなたのプロジェクトを訪れていて、どこから来たのかを[見ることが出来ます](https://help.github.com/articles/about-repository-graphs/#traffic)。プロジェクトのページで、 "Insights" をクリックし、 "Traffic" をクリックします。このページでは、下記を見ることが出来ます:
- 
+
 * **トータルページビュー:** プロジェクトが何回閲覧されたか
 
 * **トータルユニークビジター:** プロジェクトが何人に閲覧されたか
diff --git a/_articles/ja/starting-a-project.md b/_articles/ja/starting-a-project.md
index 434fd67511e..7247631ec12 100644
--- a/_articles/ja/starting-a-project.md
+++ b/_articles/ja/starting-a-project.md
@@ -1,7 +1,7 @@
 ---
 lang: ja
 title: オープンソースプロジェクトを始めよう
-description: オープンソースの世界のことをもっと学び、あなた自身のプロジェクトを立ち上げる準備をしましょう
+description: オープンソースの世界のことをもっと学び、あなた自身のプロジェクトを立ち上げる準備をしましょう。
 class: beginners
 order: 2
 image: /assets/images/cards/beginner.png

From 28f28e38a9d7aecdcef4df1ad0aaa39e44c8b5b9 Mon Sep 17 00:00:00 2001
From: ahi6 <60984726+ahi6@users.noreply.github.com>
Date: Tue, 28 Nov 2023 15:45:55 +0100
Subject: [PATCH 622/749] Fix capitalization of John F. Kennedy

---
 _articles/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 1a952f1c86e..196c21f34d4 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -195,7 +195,7 @@ If you've never contributed to open source before, take some advice from U.S. Pr
   <img src="/assets/images/how-to-contribute/johnfkennedy.jpg" class="pquote-avatar" alt="avatar">
   Ask not what your country can do for you - ask what you can do for your country.
   <p markdown="1" class="pquote-credit">
-— [_John f. Kennedy Library_](https://www.jfklibrary.org/learn/education/teachers/curricular-resources/ask-not-what-your-country-can-do-for-you)
+— [_John F. Kennedy Library_](https://www.jfklibrary.org/learn/education/teachers/curricular-resources/ask-not-what-your-country-can-do-for-you)
   </p>
 </aside>
 

From a0b4e8263ea7f7c3497176871bf865eea70c49db Mon Sep 17 00:00:00 2001
From: Xudong Guo <guoxudong.dev@gmail.com>
Date: Thu, 30 Nov 2023 18:03:19 +0800
Subject: [PATCH 623/749] optimized some statements to make them smoother.

---
 _articles/zh-hans/legal.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index ca8ac47e9be..f1b09c915bd 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -1,7 +1,7 @@
 ---
 lang: zh-hans
 title: 开源的法律保护
-description: 对于开源你应该了解的所有法律知识。
+description: 关于开源你应该了解的所有法律知识。
 class: legal
 order: 10
 image: /assets/images/cards/legal.png
@@ -17,9 +17,9 @@ redirect_from: /zh-cn/legal/
 
 ## 为什么人们这么关心开源的法律方面问题？
 
-很高兴你们提问了！当你们做创造性工作（例如写作，图形或代码）时，该作品默认为专有版权（copyright）。也就是说，法律承认你们是你们作品的作者，他人在没有经得你们同意的情况下不能使用你们的工作。
+很高兴你们提问了！当你们做创造性工作（例如写作，绘图或编码）时，该作品默认为专有版权（copyright）。也就是说，法律承认你们是你们作品的作者，他人在没有经得你们同意的情况下不能使用你们的工作。
 
-一般来说，这意味着没有人可以在没有你们授权的情况下使用，复制，分发或者修改你们的工作。
+通常而言，这代表除创作者本身外，任何人若试图使用、复制、分发或更改此作品，都将置身于被迫中止、面临勒索，甚至陷入法律纠纷的危险之中。
 
 然而，开源有着不一样的情况。因为作者希望他人使用，修改以及分享他们的工作。但因为法律默认依然是专有版权（copyright），所以你们需要一个明确说明这些权限的协议。
 
@@ -35,7 +35,7 @@ redirect_from: /zh-cn/legal/
 
 **公开你们的GitHub项目与许可你们的项目是不同的。**公开项目是由[GitHub的服务条款](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)保护，它允许他人浏览以及fork你们的项目，但是没有你的授权大家是不能使用你的工作成果的。
 
-如果你们想让他人使用，复制，修改你们的项目，或者参与贡献你们的项目，那么你们的项目就需要包含一个开源许可协议。例如，即使你们的项目是公开的，但没有你们的授权，一些人是不能合法在他们的代码中使用你们GitHub项目中的任何部分。
+如果你们想让他人使用、复制、修改你们的项目，或者参与贡献你们的项目，那么你们的项目就需要包含一个开源许可协议。例如，即使你的GitHub项目是公开的，除非你明确授权，否则他人在法律上无权将你项目中的任何内容用于自己的代码之中。
 
 ## 如何保护我们的项目
 

From a87b6c1d5d8a88a461148404e56a65b205eda0ad Mon Sep 17 00:00:00 2001
From: Eric Sorenson <eric.sorenson@puppetlabs.com>
Date: Mon, 4 Dec 2023 15:49:24 -0800
Subject: [PATCH 624/749] Remove references to the Personal Ecology doc, which
 has 404d

This document went away and tests fail because it is now 404ing. There is at least one other resource in both the inline text and the list context so it should be safe to simply remove the reference to it.

Note I may have introduced grammatical errors in the non-Roman character languages, because I couldn't tell whether the remaining words reference the doc which was deleted.
---
 .../de/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../el/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../es/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../fa/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../fr/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../hi/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../hu/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../id/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../ja/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../ko/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 _articles/maintaining-balance-for-open-source-maintainers.md   | 3 +--
 .../ms/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../nl/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../pl/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../pt/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../ro/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../ru/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../ta/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../tr/maintaining-balance-for-open-source-maintainers.md      | 3 +--
 .../zh-hans/maintaining-balance-for-open-source-maintainers.md | 3 +--
 .../zh-hant/maintaining-balance-for-open-source-maintainers.md | 3 +--
 21 files changed, 21 insertions(+), 42 deletions(-)

diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index a16f77db2d2..1eabae32614 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ Es ist wichtig zu verstehen, was die Ursachen für Burnout sind. Hier sind ein p
 
 Können Sie Ihr Tempo 10 Wochen lang beibehalten? 10 Monate? 10 Jahre?
 
-Es gibt Tools wie die [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) von [@shaunagm](https://github.com/shaunagm) und Mozillas [Personal Ecology Self-Assessment Kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), die Ihnen dabei helfen können, Ihr aktuelles Tempo zu reflektieren und zu sehen, ob Sie Anpassungen vornehmen können. Einige Betreuer verwenden auch Wearables, um Messwerte wie Schlafqualität und Herzfrequenzvariabilität (die beide mit Stress in Verbindung stehen) zu verfolgen.
+Es gibt Tools wie die [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) von [@shaunagm](https://github.com/shaunagm) die Ihnen dabei helfen können, Ihr aktuelles Tempo zu reflektieren und zu sehen, ob Sie Anpassungen vornehmen können. Einige Betreuer verwenden auch Wearables, um Messwerte wie Schlafqualität und Herzfrequenzvariabilität (die beide mit Stress in Verbindung stehen) zu verfolgen.
 
 <aside markdown="1" class="pquote">
  Ich bin ein großer Befürworter von guten Wearables. Mit der Wissenschaft dahinter kann man verstehen, was man hätte besser machen können und wie man seine Ziele optimal erreichen kann.
@@ -171,7 +171,6 @@ Denken Sie daran, dass persönliche Ökologie eine fortlaufende Praxis ist, die
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/el/maintaining-balance-for-open-source-maintainers.md b/_articles/el/maintaining-balance-for-open-source-maintainers.md
index ce653c289f3..b9ec0594ab2 100644
--- a/_articles/el/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/el/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/es/maintaining-balance-for-open-source-maintainers.md b/_articles/es/maintaining-balance-for-open-source-maintainers.md
index be5df5ff614..50eb093926f 100644
--- a/_articles/es/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/es/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ Es importante entender qué nos lleva al agotamiento. Aquí hay algunas temas co
 
 ¿Puedes mantener tu ritmo durante 10 semanas? ¿10 meses? ¿10 años?
 
-Existen herramientas como la [Lista de verificación de agotamiento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) y el [kit de autoevaluación de ecología personal de Mozilla](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que pueden ayudarte a reflexionar sobre tu ritmo actual y ver si hay ajustes que puedas hacer. Algunos contribuidores también utilizan tecnología portátil para realizar un seguimiento de métricas como la calidad del sueño y la variabilidad de la frecuencia cardíaca (ambas vinculadas al estrés).
+Existen herramientas como la [Lista de verificación de agotamiento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) que pueden ayudarte a reflexionar sobre tu ritmo actual y ver si hay ajustes que puedas hacer. Algunos contribuidores también utilizan tecnología portátil para realizar un seguimiento de métricas como la calidad del sueño y la variabilidad de la frecuencia cardíaca (ambas vinculadas al estrés).
 
 <aside markdown="1" class="pquote">
   Soy un gran creyente en las buenas tecnologías portátiles. Con la ciencia detrás de ello, puedes entender cómo podrías haberlo hecho mejor y cómo llegar a un estado óptimo de lo que quieres hacer.
@@ -171,7 +171,6 @@ Recuerda, la ecología personal es una práctica continua que evolucionará a me
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
 * [Cómo lidiar con personas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Kit de autoevaluación de ecología personal](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Cómo decir no](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Gobernanza del Código Abierto](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/fa/maintaining-balance-for-open-source-maintainers.md b/_articles/fa/maintaining-balance-for-open-source-maintainers.md
index d1019690a19..825437c3c38 100644
--- a/_articles/fa/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/fa/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/fr/maintaining-balance-for-open-source-maintainers.md b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
index a71d2cf9f81..766c23f7e20 100644
--- a/_articles/fr/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/hi/maintaining-balance-for-open-source-maintainers.md b/_articles/hi/maintaining-balance-for-open-source-maintainers.md
index 4282247015b..2f9ee5a188f 100644
--- a/_articles/hi/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/hi/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 
 क्या आप 10 सप्ताह तक अपनी गति बनाए रख सकते हैं? दस महीने? 10 वर्ष?
 
-उपकरण जैसे [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) [@shaunagm](https://github.com/shaunagm) से और मोज़िला का [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) इससे आपको अपनी वर्तमान गति पर विचार करने और यह देखने में मदद मिल सकती है कि क्या आप कोई समायोजन कर सकते हैं। कुछ अनुरक्षक नींद की गुणवत्ता और हृदय गति परिवर्तनशीलता (दोनों तनाव से जुड़े हुए हैं) जैसे मेट्रिक्स को ट्रैक करने के लिए पहनने योग्य तकनीक का भी उपयोग करते हैं।
+उपकरण जैसे [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) [@shaunagm](https://github.com/shaunagm) से और मोज़िला का इससे आपको अपनी वर्तमान गति पर विचार करने और यह देखने में मदद मिल सकती है कि क्या आप कोई समायोजन कर सकते हैं। कुछ अनुरक्षक नींद की गुणवत्ता और हृदय गति परिवर्तनशीलता (दोनों तनाव से जुड़े हुए हैं) जैसे मेट्रिक्स को ट्रैक करने के लिए पहनने योग्य तकनीक का भी उपयोग करते हैं।
 
 <aside markdown="1" class="pquote">
  मैं अच्छे पहनने योग्य वस्तुओं में बड़ा विश्वास रखता हूँ। इसके पीछे के विज्ञान से, आप समझ सकते हैं कि आप कैसे बेहतर कर सकते थे और आप जो करना चाहते हैं उसकी इष्टतम स्थिति कैसे प्राप्त करें।
@@ -171,7 +171,6 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 * [अनकर्लड](https://daniel.haxx.se/uncurled/), डेनियल स्टेनबर्ग
 * [जहरीले लोगों से कैसे निपटें](https://www.youtube.com/watch?v=7lIpP3GEyXs), जीना हाउजगे
 * [सस्टेनओएसएस](https://sustainoss.org/)
-* [व्यक्तिगत पारिस्थितिकी स्व-मूल्यांकन किट](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), मोज़िला
 * [नेतृत्व की रॉकवुड कला](https://rockwoodleadership.org/art-of-leadership/)
 * [नहीं कहना](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), माइक मैकक्यूएड
 * [गवर्निंग ओपन](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/hu/maintaining-balance-for-open-source-maintainers.md b/_articles/hu/maintaining-balance-for-open-source-maintainers.md
index b7825099585..0fafd4b317b 100644
--- a/_articles/hu/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/hu/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/id/maintaining-balance-for-open-source-maintainers.md b/_articles/id/maintaining-balance-for-open-source-maintainers.md
index 081eaa3069a..cbcb7a28a3f 100644
--- a/_articles/id/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/id/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/ja/maintaining-balance-for-open-source-maintainers.md b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
index 228f6021f2a..431394b3f44 100644
--- a/_articles/ja/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
@@ -85,7 +85,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 
 あなたは 10 週間、10 ヶ月、10 年とこのペースを続けることができますか？
 
-[@shaunagm](https://github.com/shaunagm) による [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) や Mozilla の[自己評価キット](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw)のようなツールがあり、自分の現在のペースを振り返り、調整できる点があるかどうかを確認することができます。一部のメンテナーは、睡眠の質や心拍数変動 (両方ともストレスに関連している) のような指標を追跡するためにウェアラブル技術も利用しています。
+[@shaunagm](https://github.com/shaunagm) による [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) や のようなツールがあり、自分の現在のペースを振り返り、調整できる点があるかどうかを確認することができます。一部のメンテナーは、睡眠の質や心拍数変動 (両方ともストレスに関連している) のような指標を追跡するためにウェアラブル技術も利用しています。
 
 <aside markdown="1" class="pquote">
  私は良質なウェアラブル技術を強く信じています。その背後にある科学的根拠によって、どのように改善的できたかや、目指す状態を最適にする方法を理解することができます。
@@ -170,7 +170,6 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/ko/maintaining-balance-for-open-source-maintainers.md b/_articles/ko/maintaining-balance-for-open-source-maintainers.md
index 1e9216a51ac..760c34dc468 100644
--- a/_articles/ko/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ko/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
index 51d312d3499..c418b476786 100644
--- a/_articles/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/ms/maintaining-balance-for-open-source-maintainers.md b/_articles/ms/maintaining-balance-for-open-source-maintainers.md
index 86b3d3f9cfd..ccafa950d7a 100644
--- a/_articles/ms/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ms/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/nl/maintaining-balance-for-open-source-maintainers.md b/_articles/nl/maintaining-balance-for-open-source-maintainers.md
index df593ff4b32..23551227016 100644
--- a/_articles/nl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/nl/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
index bc1894fcfde..621186595c7 100644
--- a/_articles/pl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ Ważne jest, aby zrozumieć, co powoduje nasze wypalenie. Oto kilka wspólnych t
 
 Czy jesteś w stanie utrzymać tempo przez 10 tygodni? 10 miesięcy? 10 lat?
 
-Istnieją narzędzia, takie jak [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) od [@shaunagm](https://github.com/shaunagm) i od Mozilla [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) , które mogą pomóc ci zastanowić się nad twoim obecnym tempem i sprawdzić, czy są jakieś poprawki, które możesz wprowadzić. Niektórzy opiekunowie używają również technologii do monitorowania takich wskaźników jak jakość snu i zmienność tętna (oba powiązane ze stresem).
+Istnieją narzędzia, takie jak [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) od [@shaunagm](https://github.com/shaunagm) które mogą pomóc ci zastanowić się nad twoim obecnym tempem i sprawdzić, czy są jakieś poprawki, które możesz wprowadzić. Niektórzy opiekunowie używają również technologii do monitorowania takich wskaźników jak jakość snu i zmienność tętna (oba powiązane ze stresem).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Pamiętaj, że ekologia osobista to ciągła praktyka, która będzie ewoluować
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [Jak radzić sobie z toksycznymi ludźmi](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Zestaw do samooceny ekologii osobistej](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Sztuka przywództwa](https://rockwoodleadership.org/art-of-leadership/), Rockwood
 * [Mówienie "nie"](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Otwartość zarządzania](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/pt/maintaining-balance-for-open-source-maintainers.md b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
index 1c832e12eaa..80d901c8156 100644
--- a/_articles/pt/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/ro/maintaining-balance-for-open-source-maintainers.md b/_articles/ro/maintaining-balance-for-open-source-maintainers.md
index 5c1efa15935..a2a0cef81d3 100644
--- a/_articles/ro/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ro/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/ru/maintaining-balance-for-open-source-maintainers.md b/_articles/ru/maintaining-balance-for-open-source-maintainers.md
index 047e92d015a..d13f69173da 100644
--- a/_articles/ru/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ru/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/ta/maintaining-balance-for-open-source-maintainers.md b/_articles/ta/maintaining-balance-for-open-source-maintainers.md
index ed52f315d72..47928f89179 100644
--- a/_articles/ta/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ta/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/tr/maintaining-balance-for-open-source-maintainers.md b/_articles/tr/maintaining-balance-for-open-source-maintainers.md
index 3f3ca65161b..1ac42c3058c 100644
--- a/_articles/tr/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/tr/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ It's important to understand what causes us to get burned out. Here are a few co
 
 Can you keep up your pace for 10 weeks? 10 months? 10 years?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
  I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
@@ -171,7 +171,6 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
index e4996e13c30..519a27de62e 100644
--- a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 
 这样的节奏你能保持多久？10周？10个月？还是10年？
 
-有像 [@shaunagm](https://github.com/shaunagm) 的 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) 和 Mozilla 的[个人生态自评工具包](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw)这样的工具可以帮助你反思自己现在的工作节奏，看是否需要进行某些调整。一些维护者还利用可穿戴设备来监测睡眠质量和心率变异性等与压力有关的指标。
+有像 [@shaunagm](https://github.com/shaunagm) 的 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) 这样的工具可以帮助你反思自己现在的工作节奏，看是否需要进行某些调整。一些维护者还利用可穿戴设备来监测睡眠质量和心率变异性等与压力有关的指标。
 
 <aside markdown="1" class="pquote">
  我深信好的可穿戴设备的作用。有了其背后的科学依据，你可以了解如何更好地调整自己，达到完成任务的最佳状态。
@@ -171,7 +171,6 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
 * [如何应对有毒的人](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [个人生态自评工具包](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood领导艺术](https://rockwoodleadership.org/art-of-leadership/)
 * [说"不"](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
diff --git a/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md
index 01518f796eb..5bc50a5380f 100644
--- a/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md
@@ -86,7 +86,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 
 您能夠保持這種節奏達10週嗎？10個月？10年？
 
-有一些工具，例如來自 [@shaunagm](https://github.com/shaunagm) 的 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) 和 Mozilla 的 [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw)，可以幫助您反思您目前的節奏，並查看是否有任何調整的空間。一些維護者還使用可穿戴技術來追蹤睡眠質量和心率變異性等指標（這些都與壓力有關）。
+有一些工具，例如來自 [@shaunagm](https://github.com/shaunagm) 的 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) 和 可以幫助您反思您目前的節奏，並查看是否有任何調整的空間。一些維護者還使用可穿戴技術來追蹤睡眠質量和心率變異性等指標（這些都與壓力有關）。
 
 <aside markdown="1" class="pquote">
  我非常相信優質的可穿戴設備。有了背後的科學知識，您可以了解如何做得更好，以及如何達到您想要達到的最佳狀態。
@@ -169,7 +169,6 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)

From e789cecdaadc37f31838cf2eaca085d393566530 Mon Sep 17 00:00:00 2001
From: Eric Sorenson <eric.sorenson@puppetlabs.com>
Date: Mon, 4 Dec 2023 16:25:11 -0800
Subject: [PATCH 625/749] Update legal.md with archived link to jquery CLA

The original document has gone 404 as jquery moved to the js foundation and then openjsf. They also now use the Apache CLA via Linux Foundation's EasyCLA, so they are no longer a good example of a "lightweight" CLA project. It seemed most straightforward to replace this link with the archive.org equivalent, and just put our faith in the Internet Archive.
---
 _articles/de/legal.md      | 2 +-
 _articles/el/legal.md      | 2 +-
 _articles/es/legal.md      | 2 +-
 _articles/fr/legal.md      | 2 +-
 _articles/hi/legal.md      | 2 +-
 _articles/hu/legal.md      | 2 +-
 _articles/id/legal.md      | 2 +-
 _articles/ja/legal.md      | 2 +-
 _articles/ko/legal.md      | 2 +-
 _articles/legal.md         | 2 +-
 _articles/ms/legal.md      | 2 +-
 _articles/nl/legal.md      | 2 +-
 _articles/pl/legal.md      | 2 +-
 _articles/pt/legal.md      | 2 +-
 _articles/ro/legal.md      | 2 +-
 _articles/ru/legal.md      | 2 +-
 _articles/ta/legal.md      | 2 +-
 _articles/tr/legal.md      | 2 +-
 _articles/zh-hans/legal.md | 2 +-
 _articles/zh-hant/legal.md | 2 +-
 20 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/_articles/de/legal.md b/_articles/de/legal.md
index 7535a9163e2..bcb45ca972a 100644
--- a/_articles/de/legal.md
+++ b/_articles/de/legal.md
@@ -112,7 +112,7 @@ Durch das Hinzufügen von "Papierkram", den einige für unnötig, schwer verstä
 
 Einige Situationen, in denen Sie eine zusätzliche Kontributionsvereinbarung für Ihr Projekt in Betracht ziehen sollten, sind z.B:
 
-* Ihre Anwälte wollen, dass alle Mitwirkenden ausdrücklich die Kontributionsbedingungen akzeptieren (_unterschreiben_, on- oder off-line), vielleicht weil sie der Meinung sind, dass die Open-Source-Lizenz selbst nicht ausreicht (obwohl sie ausreicht!). Wenn dies die einzige Sorge ist, sollte eine Kontributionsvereinbarung, welche die Open-Source-Lizenz des Projekts bestätigt, ausreichen. Das [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) ist ein gutes Beispiel für eine leichtgewichtige, zusätzliche Kontributionsvereinbarung. Für manche Projekte kann ein [Developer Certificate of Origin](https://github.com/probot/dco) eine Alternative sein.
+* Ihre Anwälte wollen, dass alle Mitwirkenden ausdrücklich die Kontributionsbedingungen akzeptieren (_unterschreiben_, on- oder off-line), vielleicht weil sie der Meinung sind, dass die Open-Source-Lizenz selbst nicht ausreicht (obwohl sie ausreicht!). Wenn dies die einzige Sorge ist, sollte eine Kontributionsvereinbarung, welche die Open-Source-Lizenz des Projekts bestätigt, ausreichen. Das [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) ist ein gutes Beispiel für eine leichtgewichtige, zusätzliche Kontributionsvereinbarung. Für manche Projekte kann ein [Developer Certificate of Origin](https://github.com/probot/dco) eine Alternative sein.
 * Sie oder Ihre Anwälte wollen Entwickler\*innen bestätigen lassen, dass Ihre Commits autorisiert sind. Viele Projekte nutzen dafür das [Developer Certificate of Origin](https://developercertificate.org/). Beispielsweise nutzt die Node.js-Community [ein DCO](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) anstatt ihres [vorherigen CLAs](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution). [DCO Probot](https://github.com/probot/dco) bietet eine einfache Möglichkeit, in Ihrem Projekt ein solches DCO automatisch einzufordern.
 * Ihr Projekt verwendet eine Open-Source-Lizenz, die keine ausdrückliche Patenterteilung enthält (z.B. MIT), die Sie aber von allen Mitwirkenden benötigen. Von denen können Einige für Unternehmen mit großen Patentportfolios arbeiten, die gegen Sie oder die anderen Mitwirkenden und Benutzer\*innen des Projekts verwendet werden könnten. Die [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) ist eine häufig verwendete zusätzliche Kontributionsvereinbarung mit einer der Apache License 2.0 entsprechenden Patenterteilung.
 * Ihr Projekt steht unter einer Copyleft-Lizenz, aber Sie müssen auch eine proprietäre Version des Projekts verbreiten. Sie werden von allen Kontributor\*innen eine Rechteverwertungsvereinbarung einholen müssen, die Ihnen (aber nicht der Öffentlichkeit) eine permissive Lizenz gewährt. Das [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) ist ein Beispiel für eine solche Vereinbarungen.
diff --git a/_articles/el/legal.md b/_articles/el/legal.md
index e3766ee754a..1abe77edf65 100644
--- a/_articles/el/legal.md
+++ b/_articles/el/legal.md
@@ -104,7 +104,7 @@ related:
 
 Ορισμένες περιπτώσεις στις οποίες μπορεί να θέλετε να εξετάσετε το ενδεχόμενο σύναψης πρόσθετης συμφωνίας συνεισφοράς για το πρότζεκτ σας περιλαμβάνουν:
 
-* Οι δικηγόροι σας θέλουν όλοι οι συνεισφέροντες να αποδέχονται ρητά (_υπογράφουν_, online ή offline) τους όρους συνεισφοράς, ίσως επειδή θεωρούν ότι η ίδια η άδεια ανοιχτού κώδικα δεν είναι αρκετή (παρόλο που είναι!). Εάν αυτό είναι το μόνο πρόβλημα, μια συμφωνία συνεισφοράς που επιβεβαιώνει την άδεια χρήσης ανοικτού κώδικα του έργου θα πρέπει να είναι αρκετή. Η [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) είναι ένα καλό παράδειγμα μιας ελαφριάς πρόσθετης συμφωνίας συνεισφοράς.
+* Οι δικηγόροι σας θέλουν όλοι οι συνεισφέροντες να αποδέχονται ρητά (_υπογράφουν_, online ή offline) τους όρους συνεισφοράς, ίσως επειδή θεωρούν ότι η ίδια η άδεια ανοιχτού κώδικα δεν είναι αρκετή (παρόλο που είναι!). Εάν αυτό είναι το μόνο πρόβλημα, μια συμφωνία συνεισφοράς που επιβεβαιώνει την άδεια χρήσης ανοικτού κώδικα του έργου θα πρέπει να είναι αρκετή. Η [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) είναι ένα καλό παράδειγμα μιας ελαφριάς πρόσθετης συμφωνίας συνεισφοράς.
 * Εσείς ή οι δικηγόροι σας θέλετε οι προγραμματιστές να δηλώνουν ότι κάθε δέσμευση που κάνουν είναι εξουσιοδοτημένη. Η απαίτηση [Πιστοποιητικό προέλευσης προγραμματιστή](https://developercertificate.org/) είναι ο τρόπος με τον οποίο πολλά πρότζεκτ το επιτυγχάνουν αυτό. Για παράδειγμα, η κοινότητα Node.js [χρησιμοποιεί](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) το DCO [αντί](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) του προηγούμενου CLA. Μια απλή επιλογή για να αυτοματοποιήσετε την επιβολή του DCO στο αποθετήριο σας είναι το [DCO Probot](https://github.com/probot/dco).
 * Το πρότζεκτ σας χρησιμοποιεί μια άδεια χρήσης ανοικτού κώδικα που δεν περιλαμβάνει ρητή παραχώρηση διπλωμάτων ευρεσιτεχνίας (όπως η MIT) και χρειάζεστε παραχώρηση διπλώματος ευρεσιτεχνίας από όλους τους συνεισφέροντες, ορισμένοι από τους οποίους μπορεί να εργάζονται σε εταιρείες με μεγάλα χαρτοφυλάκια διπλωμάτων ευρεσιτεχνίας που θα μπορούσαν να χρησιμοποιηθούν για να στοχεύσουν εσάς ή άλλους συνεισφέροντες και χρήστες του έργου. Η [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) είναι μια ευρέως χρησιμοποιούμενη πρόσθετη συμφωνία συνεισφοράς που έχει μια παραχώρηση διπλώματος ευρεσιτεχνίας που αντικατοπτρίζει αυτή που υπάρχει στην Άδεια Apache 2.0.
 * Το πρότζεκτ σας τελεί υπό άδεια copyleft, αλλά πρέπει επίσης να διανείμετε μια ιδιόκτητη έκδοση του έργου. Θα χρειαστείτε κάθε συνεισφέροντα να σας εκχωρήσει τα πνευματικά δικαιώματα ή να σας παραχωρήσει (αλλά όχι στο κοινό) μια επιτρεπτική άδεια. Το [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) είναι ένα παράδειγμα αυτού του τύπου συμφωνίας.
diff --git a/_articles/es/legal.md b/_articles/es/legal.md
index 9ca5e57f0cd..241af52cf3c 100644
--- a/_articles/es/legal.md
+++ b/_articles/es/legal.md
@@ -105,7 +105,7 @@ Tambi&eacute;n, al a&ntilde;adir "papeleo" que algunos consideran innecesario, d
 
 Algunas situaciones en las cuales deber&iacute;as considerar un acuerdo adicional de colaboradores pueden ser:
 
-* Tus abogados quieren que todos los colaboradores acepten expresamente (_firma_, online o offline) los t&eacute;rminos de contribuci&oacute;n, quiz&aacute;s porque sienten que una licencia de c&oacute;digo abierto no es suficiente (incluso cuando lo sea!). Si esta es la &uacute;nica preocupaci&oacute;n, un acuerdo adicional de colaboradores que afirme la licencia de c&oacute;digo abierto del proyecto, deber&iacute;a ser suficiente. El [Acuerdo Adicional de colaboradores Individual de jQuery](https://contribute.jquery.org/CLA/) es un buen ejemplo de un acuerdo adicional de colaboradores ligero. Para algunos proyectos, un [Certificado de Origen del Desarrollador](https://GitHub.com/probot/dco) puede ser una alternativa a&uacute;n m&aacute;s simple.
+* Tus abogados quieren que todos los colaboradores acepten expresamente (_firma_, online o offline) los t&eacute;rminos de contribuci&oacute;n, quiz&aacute;s porque sienten que una licencia de c&oacute;digo abierto no es suficiente (incluso cuando lo sea!). Si esta es la &uacute;nica preocupaci&oacute;n, un acuerdo adicional de colaboradores que afirme la licencia de c&oacute;digo abierto del proyecto, deber&iacute;a ser suficiente. El [Acuerdo Adicional de colaboradores Individual de jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) es un buen ejemplo de un acuerdo adicional de colaboradores ligero. Para algunos proyectos, un [Certificado de Origen del Desarrollador](https://GitHub.com/probot/dco) puede ser una alternativa a&uacute;n m&aacute;s simple.
 
 * Tu proyecto usa una licencia de c&oacute;digo abierto que no incluye una concesi&oacute;n de patentes explicita (como MIT), y necesitas una concesi&oacute;n de patentes por parte de todos los colaboradores, algunos de los cuales quiz&aacute;s trabajen para empresas con grandes cantidades de patentes que podr&iacute;an utilizarse para dirigirse a usted o a otros contribuyentes y usuarios del proyecto. El [Acuerdo Adicional de colaboradores Individual de Apache](https://www.apache.org/licenses/icla.pdf) es un acuerdo adicional de colaboradores que posee una concesi&oacute;n de patentes reflejando el que se encuentra en Apache License 2.0.
 
diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index 3fc4bbbb877..3a4c2818225 100644
--- a/_articles/fr/legal.md
+++ b/_articles/fr/legal.md
@@ -104,7 +104,7 @@ En outre, en ajoutant de la "paperasse" jugée inutile, difficile à comprendre
 
 Certaines situations où vous pourriez envisager un accord de contribution supplémentaire pour votre projet incluent:
 
-* Vos avocats veulent que tous les contributeurs acceptent expressément les termes de contribution (_signer_, en ligne ou hors ligne), peut-être parce qu'ils pensent que la licence Open Source n'est pas suffisante (même si c'est le cas !). Si c'est la seule préoccupation, un accord de contribution qui affirme la licence open source du projet devrait être suffisant. Le [Contrat de licence de contributeur individuel jQuery](https://contribute.jquery.org/CLA/) est un bon exemple d'accord de contributeur supplémentaire léger. Pour certains projets, un [Developer Certificate of Origin](https://github.com/probot/dco) peut être une alternative.
+* Vos avocats veulent que tous les contributeurs acceptent expressément les termes de contribution (_signer_, en ligne ou hors ligne), peut-être parce qu'ils pensent que la licence Open Source n'est pas suffisante (même si c'est le cas !). Si c'est la seule préoccupation, un accord de contribution qui affirme la licence open source du projet devrait être suffisant. Le [Contrat de licence de contributeur individuel jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) est un bon exemple d'accord de contributeur supplémentaire léger. Pour certains projets, un [Developer Certificate of Origin](https://github.com/probot/dco) peut être une alternative.
 * Votre projet utilise une licence open source qui n'inclut pas de brevet explicite (tel que MIT), et vous avez besoin d'une licence de brevet de tous les contributeurs, dont certains peuvent travailler pour des entreprises avec de grands portefeuilles de brevets qui pourraient vous servir ou les autres contributeurs et utilisateurs du projet. Le [Contrat de licence de contributeur individuel Apache](https://www.apache.org/licenses/icla.pdf) est un accord de contributeur supplémentaire communément utilisé qui a une licence de brevet reflétant celle de la licence Apache 2.0.
 * Votre projet est sous licence copyleft, mais vous devez également distribuer une version propriétaire du projet. Vous aurez besoin de chaque contributeur pour vous attribuer des droits d'auteur ou vous accorder (mais pas le public) une licence permissive. Le [Contrat de collaboration MongoDB](https://www.mongodb.com/legal/contributor-agreement) est un exemple de ce type d'accord.
 * Vous pensez que votre projet pourrait avoir besoin de changer de licence au cours de sa vie et que les contributeurs soient d'accord à l'avance sur de tels changements.
diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md
index 4e005274bba..7c41426a213 100644
--- a/_articles/hi/legal.md
+++ b/_articles/hi/legal.md
@@ -107,7 +107,7 @@ related:
 
 कुछ स्थितियाँ जहाँ आप अपने प्रोजेक्ट के लिए अतिरिक्त योगदानकर्ता समझौते पर विचार करना चाह सकते हैं उनमें शामिल हैं:
 
-* आपके वकील चाहते हैं कि सभी योगदानकर्ता स्पष्ट रूप से (_साइन_, ऑनलाइन या ऑफलाइन) योगदान शर्तों को स्वीकार करें, शायद इसलिए क्योंकि उन्हें लगता है कि ओपन सोर्स लाइसेंस ही पर्याप्त नहीं है (भले ही यह है!)। यदि यह एकमात्र चिंता का विषय है, तो एक योगदानकर्ता समझौता जो परियोजना के ओपन सोर्स लाइसेंस की पुष्टि करता है, पर्याप्त होना चाहिए। [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) हल्के अतिरिक्त योगदानकर्ता समझौते का एक अच्छा उदाहरण है।
+* आपके वकील चाहते हैं कि सभी योगदानकर्ता स्पष्ट रूप से (_साइन_, ऑनलाइन या ऑफलाइन) योगदान शर्तों को स्वीकार करें, शायद इसलिए क्योंकि उन्हें लगता है कि ओपन सोर्स लाइसेंस ही पर्याप्त नहीं है (भले ही यह है!)। यदि यह एकमात्र चिंता का विषय है, तो एक योगदानकर्ता समझौता जो परियोजना के ओपन सोर्स लाइसेंस की पुष्टि करता है, पर्याप्त होना चाहिए। [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) हल्के अतिरिक्त योगदानकर्ता समझौते का एक अच्छा उदाहरण है।
 * आप या आपके वकील चाहते हैं कि डेवलपर्स यह प्रतिनिधित्व करें कि उनकी प्रत्येक प्रतिबद्धता अधिकृत है. [Developer Certificate of Origin](https://developercertificate.org/) आवश्यकता यह है कि कितनी परियोजनाएँ इसे प्राप्त करती हैं। उदाहरण के लिए, Node.js समुदाय [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) उनके पूर्व CLI का। आपके भंडार पर डीसीओ के प्रवर्तन को स्वचालित करने का एक सरल विकल्प है [DCO Probot](https://github.com/probot/dco).
 *आपका प्रोजेक्ट एक ओपन सोर्स लाइसेंस का उपयोग करता है जिसमें एक्सप्रेस पेटेंट अनुदान (जैसे एमआईटी) शामिल नहीं है, और आपको सभी योगदानकर्ताओं से पेटेंट अनुदान की आवश्यकता है, जिनमें से कुछ बड़े पेटेंट पोर्टफोलियो वाली कंपनियों के लिए काम कर सकते हैं जिनका उपयोग आपको लक्षित करने के लिए किया जा सकता है या परियोजना के अन्य योगदानकर्ता और उपयोगकर्ता। The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) आमतौर पर इस्तेमाल किया जाने वाला अतिरिक्त योगदानकर्ता समझौता है जिसमें अपाचे लाइसेंस 2.0 में पाए गए पेटेंट अनुदान को प्रतिबिंबित किया गया है।
 * आपका प्रोजेक्ट कॉपीलेफ्ट लाइसेंस के अंतर्गत है, लेकिन आपको प्रोजेक्ट का मालिकाना संस्करण भी वितरित करने की आवश्यकता है। आपको प्रत्येक योगदानकर्ता से आपको कॉपीराइट सौंपने या आपको (लेकिन जनता को नहीं) अनुमेय लाइसेंस देने की आवश्यकता होगी। [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) इस प्रकार के समझौते का एक उदाहरण है.
diff --git a/_articles/hu/legal.md b/_articles/hu/legal.md
index 2762bf09b2d..53395f7487e 100644
--- a/_articles/hu/legal.md
+++ b/_articles/hu/legal.md
@@ -104,7 +104,7 @@ Amikor ez olyan "papírmunkát" okoz, amit egyesek szükségtelennek, nehezen é
 
 Egyes helyzetekben, szükséges lehet további, a projekthez kapcsolódó közreműködői megállapodást kötni:
 
-* A jogászok azt szeretnék, ha minden résztvevő kifejezetten elfogadná (_aláírná_, online vagy offline) a közreműködői feltételeket, talán azért, mert úgy érzik, hogy a nyílt forráskódú licenc nem elég (annak ellenére, hogy ez nem így van!). Ha csak ez az egyetlen gond, akkor elegendőnek kell lennie a nyílt forráskódú licencnek, és egy azt megerősítő közreműködői megállapodásnak. A [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) egy jó példa egy érthető, könnyen használható CLA-nak.
+* A jogászok azt szeretnék, ha minden résztvevő kifejezetten elfogadná (_aláírná_, online vagy offline) a közreműködői feltételeket, talán azért, mert úgy érzik, hogy a nyílt forráskódú licenc nem elég (annak ellenére, hogy ez nem így van!). Ha csak ez az egyetlen gond, akkor elegendőnek kell lennie a nyílt forráskódú licencnek, és egy azt megerősítő közreműködői megállapodásnak. A [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) egy jó példa egy érthető, könnyen használható CLA-nak.
 * Te vagy a jogászok azt szeretnék, hogy a fejlesztők minden commit-ja jogilag megállja a helyét. Ezt a projektek a [Developer Certificate of Origin](https://developercertificate.org/) segítségével érik el. Például, a Node.js közösség a saját CLA-juk helyett [inkább](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) a DCO-t [használja](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md). A DCO automatikus kikényszerítése egy Git repository-n legegyszerűbben a [DCO Probot-tal](https://github.com/probot/dco) érhető el.
 * A projekt egy olyan nyílt forráskódú licencet használ, amely nem tartalmaz kifejezetten szabadalom használati engedélyt (például MIT), így szükséges egy szabadalom használati engedély nyilatkozat minden résztvevőtől, akik közül néhányan nagy szabadalom portfólióval rendelkező cégeknek dolgoznak, amelyek a szabadalmaikat felhasználva támadhatnak téged vagy a projekt többi résztvevőjét és felhasználóit. Az [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) egy elterjedten használt kiegészítő közreműködői megállapodás, ami az Apache License 2.0 licencben szereplő szabadalom használati jogosultságot tartalmazza.
 * A projekted "copyleft" licencelésű, de a projektből egy szabadalmaztatott, saját verziót is terjeszteni szeretnél. Minden résztvevőnek át kell ruháznia rád a szerzői jogait, hogy megengedje neked (de nem a nyilvánosságnak) a szabad felhasználást. A [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) egy ilyen típusú megállapodás.
diff --git a/_articles/id/legal.md b/_articles/id/legal.md
index d688d4cefc3..2747d1ff891 100644
--- a/_articles/id/legal.md
+++ b/_articles/id/legal.md
@@ -104,7 +104,7 @@ Juga, dengan menambahkan "pekerjaan administratif" yang dipercaya oleh sebagian
 
 Beberapa situasi dimana Anda ingin mempertimbangkan perjanjian kontributor tambahan pada proyek Anda meliputi:
 
-* Pengacara Anda ingin semua kontributor menerima perjanjian kontribusi (_tandatangan_, online atau offline), karena mereka merasa lisensi open source tidaklah cukup (meskipun sebenarnya sudah!). Jika ini merupakan satu-satunya alasan, sebuah perjanjian kontributor yang mengakui lisensi open source sudahlah cukup. [Perjanjian Lisensi Kontributor Individual jQuery](https://contribute.jquery.org/CLA/) adalah contoh bagus dari perjanjian kontributor tambahan yang sederhana. Untuk beberapa proyek [Developer Certificate of Origin](https://github.com/probot/dco) mungkin menjadi alternatif yang lebih sederhana.
+* Pengacara Anda ingin semua kontributor menerima perjanjian kontribusi (_tandatangan_, online atau offline), karena mereka merasa lisensi open source tidaklah cukup (meskipun sebenarnya sudah!). Jika ini merupakan satu-satunya alasan, sebuah perjanjian kontributor yang mengakui lisensi open source sudahlah cukup. [Perjanjian Lisensi Kontributor Individual jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) adalah contoh bagus dari perjanjian kontributor tambahan yang sederhana. Untuk beberapa proyek [Developer Certificate of Origin](https://github.com/probot/dco) mungkin menjadi alternatif yang lebih sederhana.
 * Proyek Anda menggunakan lisensi open source yang tidak menyertakan ijin patent (seperti MIT), dan Anda perlu pengajuan patent dari semua kontributor, beberapa diantaranya yang mungkin bekerja pada perusahaan dengan portofolio paten yang besar yang bisa digunakan untuk menyerang Anda atau kontributor atau pengguna proyek Anda. [Perjanjian Lisensi Kontributor Individual Apache](https://www.apache.org/licenses/icla.pdf) adalah perjanjian kontributor tambahan yang sering dipakai dan memiliki ijin penggunaan patent mengikuti apa yang bisa ditemukan pada lisensi Apache 2.0.
 * Proyek Anda berada dibawah lisensi copyleft, tetapi Anda juga perlu mendistribusikan versi tertutup dari proyek Anda. Anda mungkin perlu meminta setiap kontributor untuk menyatakan hak cipta kepada Anda atau memberikan ijin kepada Anda (tetapi bukan kepada publik) sebuah lisensi yang bersifat _permissive_. [Perjanjian Kontributor MongoDB](https://www.mongodb.com/legal/contributor-agreement) adalah contoh jenis perjanjian ini.
 * Anda berpikir proyek Anda perlu mengubah lisensi dikemudian hari dan ingin para kontributor untuk menyetujuinya di awal terhadap perubahan tersebut.
diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md
index 707b71ae1a1..0f1be7475eb 100644
--- a/_articles/ja/legal.md
+++ b/_articles/ja/legal.md
@@ -104,7 +104,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
 
 追加のコントリビューターアグリーメントがプロジェクトに必要になってくるケースにはこういったものがあります：
 
-* あなたの弁護士が全てのコントリビューターが明示的にコントリビュート規約に同意する（オンラインかオフラインでの _サイン_）必要があると判断した場合。これはおそらく、オープンソースライセンスだけでは十分でない（たとえ実際には十分だったとしても！）と感じているからでしょう。もしこれが唯一の懸念なのであれば、あるオープンソースライセンスを支持する旨のコントリビューターアグリーメントで十分なはずです。 [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) が、軽量な追加のコントリビューターアグリーメントの良い例です。
+* あなたの弁護士が全てのコントリビューターが明示的にコントリビュート規約に同意する（オンラインかオフラインでの _サイン_）必要があると判断した場合。これはおそらく、オープンソースライセンスだけでは十分でない（たとえ実際には十分だったとしても！）と感じているからでしょう。もしこれが唯一の懸念なのであれば、あるオープンソースライセンスを支持する旨のコントリビューターアグリーメントで十分なはずです。 [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) が、軽量な追加のコントリビューターアグリーメントの良い例です。
 * あなたや弁護士が、開発者が行う全てのコミットは承認されていると表明してほしいと考える場合。[Developer Certificate of Origin](https://developercertificate.org/) の要件はこれを達成するプロジェクトの数です。例えば、Node.js コミュニティは彼らが以前使っていた CLA の[代わりに](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution)、DCO を[使っています](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md)。あなたのリポジトリでDCOの執行を自動化するためのシンプルなオプションは [DCO Probot](https://github.com/probot/dco) を使うことです。
 * プロジェクトで使っているオープンソースライセンスに特許許諾が明記されておらず（ MIT ライセンスのように）、全てのコントリビューターから特許許諾を取る必要がある場合。これは、コントリビューターの中にあなたのプロジェクトやプロジェクトのコントリビューター、ユーザーを巨大な特許ポートフォリオの対象にする企業があるかもしれないためです。 [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) は、 Apache License 2.0 に記載されている特許許諾をコピーした追加のコントリビューターアグリーメントで、一般的に使われています。
 * プロジェクトがコピーレフトライセンスを使っているが、プロプライエタリバージョンも提供する必要がある場合。この場合、全てのコントリビューターから、コピーライトをあなたに割り当てるか、寛容なライセンスを（パブリックに対してではなく）あなたに対して許諾する必要があるでしょう。 [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) はこの種の同意の例です。
diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index 37bc21b9f71..57ae35c31c8 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -104,7 +104,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
 
 프로젝트에 대한 추가 기여자 계약을 고려할 수 있는 몇 가지 상황은 다음과 같습니다:
 
-* 변호사는 기여자가 오픈소스 라이선스 자체가 충분하지 않다고 생각하기 때문에 모든 기여자가 기여 조항을 명시적으로 (_sign_, 온라인 또는 오프라인) 받아들이기를 원합니다. 이것이 유일한 관심사라면, 프로젝트의 오픈소스 라이선스를 인정하는 기여자 계약만으로 충분할 것입니다. [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/)는 경량 추가 제공자 계약의 좋은 예입니다. 일부 프로젝트의 경우, [개발자 인증서 발급](https://github.com/probot/dco)을 사용할 수 있습니다.
+* 변호사는 기여자가 오픈소스 라이선스 자체가 충분하지 않다고 생각하기 때문에 모든 기여자가 기여 조항을 명시적으로 (_sign_, 온라인 또는 오프라인) 받아들이기를 원합니다. 이것이 유일한 관심사라면, 프로젝트의 오픈소스 라이선스를 인정하는 기여자 계약만으로 충분할 것입니다. [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/)는 경량 추가 제공자 계약의 좋은 예입니다. 일부 프로젝트의 경우, [개발자 인증서 발급](https://github.com/probot/dco)을 사용할 수 있습니다.
 * 귀하의 프로젝트는 익스프레스 특허 부여 (MIT 등)가 포함되지 않은 오픈소스 라이선스를 사용하며, 모든 기여자의 특허 허여가 필요합니다. 그 중 일부는 귀하를 타겟으로 삼을 수 있는 대규모 특허 포트폴리오를 보유한 회사 또는 프로젝트의 다른 참여자 및 사용자가 사용할 수 있습니다. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)는 일반적으로 사용되는 추가 기여자 계약으로 Apache License 2.0에서 발견된 특허권 부여를 미러링합니다.
 * 프로젝트에 카피레프트 라이선스가 있지만, 프로젝트의 독점 버전을 배포해야 합니다. 모든 저작권자가 저작권을 양도하거나 관할권을 부여할 수 있는 허가권을 사용자에게 부여해야합니다. [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement)는 이러한 유형의 계약입니다.
 * 평생동안 프로젝트를 변경하고 기여자가 그러한 변경 사항에 동의하기를 원한다고 생각하십시오.
diff --git a/_articles/legal.md b/_articles/legal.md
index b124e1e4477..30d391b2f76 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -106,7 +106,7 @@ Also, by adding "paperwork" that some believe is unnecessary, hard to understand
 
 Some situations where you may want to consider an additional contributor agreement for your project include:
 
-* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
+* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
 * You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
 * Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
 * Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
diff --git a/_articles/ms/legal.md b/_articles/ms/legal.md
index 0881810920f..c235cf083c9 100644
--- a/_articles/ms/legal.md
+++ b/_articles/ms/legal.md
@@ -104,7 +104,7 @@ Juga, dengan menambahkan "kertas kerja" yang diyakini oleh beberapa orang tidak
 
 Beberapa situasi di mana anda mungkin ingin mempertimbangkan perjanjian penyumbang tambahan untuk projek anda termasuk:
 
-* Peguam anda mahu semua penyumbang menerima secara jelas syarat-syarat sumbangan (_sign_, online atau offline), mungkin kerana mereka merasakan lesen sumber terbuka itu sendiri tidak mencukupi (walaupun sudah!). Sekiranya ini satu-satunya masalah, perjanjian penyumbang yang mengesahkan lesen sumber terbuka projek harus mencukupi. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) adalah contoh yang baik dari perjanjian penyumbang tambahan ringan.
+* Peguam anda mahu semua penyumbang menerima secara jelas syarat-syarat sumbangan (_sign_, online atau offline), mungkin kerana mereka merasakan lesen sumber terbuka itu sendiri tidak mencukupi (walaupun sudah!). Sekiranya ini satu-satunya masalah, perjanjian penyumbang yang mengesahkan lesen sumber terbuka projek harus mencukupi. The [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) adalah contoh yang baik dari perjanjian penyumbang tambahan ringan.
 * Anda atau peguam anda mahu pembangun menyatakan bahawa setiap komitmen yang mereka buat diberi kuasa. [Developer Certificate of Origin](https://developercertificate.org/) keperluannya adalah berapa banyak projek yang mencapainya. Contohnya, komuniti Node.js [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) CLA mereka yang terdahulu. Pilihan mudah untuk mengotomatisasi pelaksanaan DCO di repositori anda adalah [DCO Probot](https://github.com/probot/dco).
 * Projek anda menggunakan lesen sumber terbuka yang tidak termasuk pemberian paten ekspres (seperti MIT), dan anda memerlukan pemberian paten dari semua penyumbang, beberapa di antaranya mungkin bekerja untuk syarikat yang mempunyai portfolio paten besar yang dapat digunakan untuk menargetkan anda atau penyumbang dan pengguna projek yang lain. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) adalah perjanjian penyumbang tambahan yang biasa digunakan yang mempunyai pemberian hak paten seperti yang terdapat dalam Apache License 2.0.
 * Projek anda di bawah lesen copyleft, tetapi anda juga perlu mengedarkan versi proprietari projek tersebut. Anda memerlukan setiap penyumbang untuk memberikan hak cipta kepada anda atau memberi anda (tetapi bukan orang ramai) lesen yang mengizinkan. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) adalah contoh jenis perjanjian ini.
diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
index 67be0267f2b..959495864a5 100644
--- a/_articles/nl/legal.md
+++ b/_articles/nl/legal.md
@@ -109,7 +109,7 @@ Door ook 'papierwerk' toe te voegen waarvan sommigen denken dat het onnodig, moe
 </aside>
 Enkele situaties waarin u wellicht een aanvullende bijdrageovereenkomst voor uw project wilt overwegen, zijn onder meer:
 
-* Uw advocaten willen dat alle bijdragers uitdrukkelijk (_tekenen_, online of offline) contributievoorwaarden accepteren, misschien omdat ze vinden dat de open source-licentie zelf niet voldoende is (ook al is het dat wel!). Als dit de enige zorg is, zou een bijdragersovereenkomst moeten volstaan ​​die de open source-licentie van het project bevestigt. De [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is een goed voorbeeld van een lichtgewicht aanvullende overeenkomst voor bijdragers.
+* Uw advocaten willen dat alle bijdragers uitdrukkelijk (_tekenen_, online of offline) contributievoorwaarden accepteren, misschien omdat ze vinden dat de open source-licentie zelf niet voldoende is (ook al is het dat wel!). Als dit de enige zorg is, zou een bijdragersovereenkomst moeten volstaan ​​die de open source-licentie van het project bevestigt. De [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is een goed voorbeeld van een lichtgewicht aanvullende overeenkomst voor bijdragers.
 * U of uw advocaten willen dat ontwikkelaars verklaren dat elke toezegging die ze doen, geautoriseerd is. Een [Developer Certificate of Origin](https://developercertificate.org/) vereiste is hoeveel projecten dit bereiken. De Node.js-community [gebruikt](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) bijvoorbeeld de DCO [in plaats daarvan](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) van hun eerdere cao. Een eenvoudige optie om de handhaving van de DCO op uw repository te automatiseren, is de [DCO Probot] (https://github.com/probot/dco).
 * Uw project maakt gebruik van een open source-licentie die geen uitdrukkelijke octrooiverlening omvat (zoals MIT), en u hebt een octrooiverlening nodig van alle bijdragers, van wie sommigen mogelijk werken voor bedrijven met grote octrooiportefeuilles die kunnen worden gebruikt om u te targeten of de andere bijdragers en gebruikers van het project. De [Apache-licentieovereenkomst voor individuele bijdragers](https://www.apache.org/licenses/icla.pdf) is een veelgebruikte aanvullende overeenkomst voor bijdragers met een octrooiverlening die overeenkomt met die in de Apache-licentie 2.0.
 * Uw project valt onder een auteursplichtlicentie, maar u moet ook een eigen versie van het project distribueren. Je hebt elke bijdrager nodig om het auteursrecht aan jou toe te wijzen of jou (maar niet het publiek) een permissieve licentie te verlenen. De [MongoDB-bijdragersovereenkomst](https://www.mongodb.com/legal/contributor-agreement) is een voorbeeld van dit type overeenkomst.
diff --git a/_articles/pl/legal.md b/_articles/pl/legal.md
index 63fff32dc1d..b04a307d79b 100644
--- a/_articles/pl/legal.md
+++ b/_articles/pl/legal.md
@@ -108,7 +108,7 @@ Ponadto poprzez dodanie „dokumentacji”, którą niektórzy uważają za niep
 
 Niektóre sytuacje, w których warto rozważyć zawarcie dodatkowej umowy wnoszącej wkład dla twojego projektu, obejmują:
 
-* Twoi prawnicy chcą, aby wszyscy współtwórcy wyraźnie zaakceptowali warunki udziału (_sign_, online lub offline), być może dlatego, że uważają, że sama licencja typu open source nie wystarczy (nawet jeśli jest!). Jeśli jest to jedyny problem, wystarczy umowa współtwórcy, która potwierdza licencję open source projektu. [Umowa licencyjna na indywidualnego dostawcę jQuery](https://contribute.jquery.org/CLA/) jest dobrym przykładem niewielkiej dodatkowej umowy na współautora.
+* Twoi prawnicy chcą, aby wszyscy współtwórcy wyraźnie zaakceptowali warunki udziału (_sign_, online lub offline), być może dlatego, że uważają, że sama licencja typu open source nie wystarczy (nawet jeśli jest!). Jeśli jest to jedyny problem, wystarczy umowa współtwórcy, która potwierdza licencję open source projektu. [Umowa licencyjna na indywidualnego dostawcę jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) jest dobrym przykładem niewielkiej dodatkowej umowy na współautora.
 * Ty lub twoi prawnicy chcielibyście, aby programiści oświadczyli, że każde dokonane przez nich zatwierdzenie jest dozwolone. Wymaganiem [Developer Certificate of Origin](https://developercertificate.org/) jest to, ile projektów to osiąga. Na przykład społeczność Node.js [używa](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [zamiast](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) wcześniejszego CLA. Prostą opcją zautomatyzowania wymuszania kontroli DCO w repozytorium jest [DCO Probot](https://github.com/probot/dco).
 * Twój projekt wykorzystuje licencję typu open source, która nie obejmuje wyraźnej granty patentowej (takiej jak MIT), i potrzebujesz grantu patentowego od wszystkich autorów, z których niektórzy mogą pracować dla firm z dużymi portfelami patentowymi, które mogłyby być wykorzystane do Ciebie lub inni uczestnicy projektu i użytkownicy. [Umowa licencyjna na indywidualnego dostawcę Apache](https://www.apache.org/licenses/icla.pdf) to powszechnie stosowana dodatkowa umowa na współautora, której udzielenie patentowe odzwierciedla kopię zawartą w licencji Apache 2.0.
 * Twój projekt jest objęty licencją copyleft, ale musisz także rozpowszechniać zastrzeżoną wersję projektu. Będziesz potrzebował każdego współtwórcy, aby przypisać Ci prawa autorskie lub udzielić (ale nie publicznie) zezwolenia na korzystanie z licencji. [Umowa współtwórcy MongoDB](https://www.mongodb.com/legal/contributor-agreement) jest przykładem tego rodzaju umowy.
diff --git a/_articles/pt/legal.md b/_articles/pt/legal.md
index be1934460d1..9f593bc73fe 100644
--- a/_articles/pt/legal.md
+++ b/_articles/pt/legal.md
@@ -105,7 +105,7 @@ Além disso, adicionando "papelada" que alguns acreditam ser desnecessária, dif
 
 Algumas situações em que você pode querer considerar um contrato de contribuição adicional para o seu projeto incluem:
 
-* Seus advogados querem que todos os colaboradores aceitem expressamente os termos de contribuição (_assinem_, online ou offline), talvez porque achem que a licença open source em si não é suficiente (mesmo que seja!). Se essa for a única preocupação, um acordo de contribuidores que afirme a licença open source do projeto deve ser suficiente. O [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) é um bom exemplo de um acordo de contribuição adicional leve. Para alguns projetos, um [Certificado de Origem do Desenvolvedor](https://github.com/probot/dco) pode ser uma alternativa.
+* Seus advogados querem que todos os colaboradores aceitem expressamente os termos de contribuição (_assinem_, online ou offline), talvez porque achem que a licença open source em si não é suficiente (mesmo que seja!). Se essa for a única preocupação, um acordo de contribuidores que afirme a licença open source do projeto deve ser suficiente. O [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) é um bom exemplo de um acordo de contribuição adicional leve. Para alguns projetos, um [Certificado de Origem do Desenvolvedor](https://github.com/probot/dco) pode ser uma alternativa.
 * Seu projeto usa uma licença open source que não inclui uma concessão de patente expressa (como MIT) e você precisa de uma concessão de patente de todos os contribuidores, alguns dos quais podem trabalhar para empresas com grandes portfólios de patentes que poderiam ser usados contra você ou os outros contribuidores e usuários do projeto. O [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) é um contrato de contribuição adicional comumente usado que tem uma concessão de patente espelhando a encontrada na Licença Apache 2.0.
 * Seu projeto está sob uma licença copyleft, mas você também precisa distribuir uma versão proprietária do projeto. Você precisará que todo colaborador assine, garantindo a você ou lhe outorgando direitos autorais (mas não ao público) uma licença permissiva. O [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) é um exemplo desse tipo de acordo.
 * Você acha que seu projeto talvez precise alterar as licenças ao longo de sua vida útil e deseja que os colaboradores concordem antecipadamente com essas alterações.
diff --git a/_articles/ro/legal.md b/_articles/ro/legal.md
index 14a1c197dab..ed324150c7f 100644
--- a/_articles/ro/legal.md
+++ b/_articles/ro/legal.md
@@ -118,7 +118,7 @@ De asemenea, prin adăugarea de „hârtii” pe care unii le cred nenecesare, g
 
 Unele situații în care ai putea dori să consideri un acord suplimentar de contributor pentru proiectul tău includ:
 
-* Avocații tăi vor ca toți contributorii să accepte în mod expres (_semneze_, online sau offline) termenii de contribuție, poate deoarece ei simt că licența open source în sine nu este destul (chiar dacă este!). Dacă aceasta este singura îngrijorare, un acord de contributor care afirmă licența de sursă deschisă a proiectului ar trebui să fie destul. [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) este un exemplu bun de un acord suplimentar ușor de contributor. Pentru unele proiecte, un [Developer Certificate of Origin](https://github.com/probot/dco) poate fi o alternativă.
+* Avocații tăi vor ca toți contributorii să accepte în mod expres (_semneze_, online sau offline) termenii de contribuție, poate deoarece ei simt că licența open source în sine nu este destul (chiar dacă este!). Dacă aceasta este singura îngrijorare, un acord de contributor care afirmă licența de sursă deschisă a proiectului ar trebui să fie destul. [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) este un exemplu bun de un acord suplimentar ușor de contributor. Pentru unele proiecte, un [Developer Certificate of Origin](https://github.com/probot/dco) poate fi o alternativă.
 * Proiectul tău folosește o licență de sursă deschisă care nu include o acordare expresă de brevet (cum ar fi MIT), și ai nevoie de o acordare de brevet de la toți contributorii, dintre care unii ar putea lucra pentru companii cu portofolii largi de brevete care ar putea să fie folosite să te țintească pe tine sau pe ceilalți contributori și utilizatori ai proiectului. [Individual Contributor License Agreement al Apache](https://www.apache.org/licenses/icla.pdf) este un acord suplimentar de contributor folosit în mod obișnuit care are o acordare de brevet oglindind-o pe cea găsită în Apache License 2.0.
 * Proiectul tău se află sub o licență copyleft, dar tu trebuie de asemenea să distribui o versiune de proprietate a proiectului. Îți va trebui ca fiecare contributor să-ți atribuie drepturile de autor ție sau să-ți acorde ție (dar nu publicului) o licență permisivă. [Contributor Agreement al MongoDB](https://www.mongodb.com/legal/contributor-agreement) este un exemplu de acest tip de acord.
 * Te gândești că proiectul tău ar putea necesita schimbarea licențelor de-a lungul duratei lui de viață și dorești ca acești contributori să fie de acord în avans cu asemenea schimbări.
diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md
index b010b6a7046..37b77211338 100644
--- a/_articles/ru/legal.md
+++ b/_articles/ru/legal.md
@@ -104,7 +104,7 @@ related:
 
 Вот некоторые ситуации, когда вы можете захотеть рассмотреть вопрос о дополнительном соглашении с участниками для вашего проекта:
 
-* Ваши юристы хотят, чтобы все участники явным образом приняли (подписать, онлайн или офлайн) условия вклада, возможно, потому, что они считают, что самой лицензии с открытым исходным кодом недостаточно (даже если это так!). Если это единственная проблема, должно быть достаточно соглашения с участником, подтверждающего лицензию проекта с открытым исходным кодом. [Лицензионное соглашение с индивидуальным участником jQuery](https://contribute.jquery.org/CLA/) является хорошим примером облегченного соглашения с дополнительным участником.
+* Ваши юристы хотят, чтобы все участники явным образом приняли (подписать, онлайн или офлайн) условия вклада, возможно, потому, что они считают, что самой лицензии с открытым исходным кодом недостаточно (даже если это так!). Если это единственная проблема, должно быть достаточно соглашения с участником, подтверждающего лицензию проекта с открытым исходным кодом. [Лицензионное соглашение с индивидуальным участником jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) является хорошим примером облегченного соглашения с дополнительным участником.
 * Вы или ваши юристы хотите, чтобы разработчики доказали, что каждое совершаемое ими действие санкционировано. Требование [Сертификата разработчика](https://developercertificate.org/) — это количество проектов, которые это обеспечивают. Например, сообщество Node.js [использует](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) их предыдущего CLA. Простым вариантом автоматизации принудительного применения DCO в вашем репозитории является [DCO Probot](https://github.com/probot/dco).
 * В вашем проекте используется лицензия с открытым исходным кодом, которая не включает прямую выдачу патента (например, MIT), и вам нужен патент от всех участников, некоторые из которых могут работать в компаниях с большими портфелями патентов, которые могут быть использованы для вашего таргетинга. или других участников и пользователей проекта. [Лицензионное соглашение с индивидуальным участником Apache](https://www.apache.org/licenses/icla.pdf) является часто используемым соглашением с дополнительным участником, в котором выдача патента является копией той, которая содержится в лицензии Apache License 2.0.
 * Ваш проект находится под лицензией с авторским левом, но вам также необходимо распространять проприетарную версию проекта. Вам потребуется, чтобы каждый участник назначил вам авторские права или предоставил вам (но не общественности) разрешительную лицензию. [Соглашение с участником MongoDB](https://www.mongodb.com/legal/contributor-agreement) является примером такого типа соглашения.
diff --git a/_articles/ta/legal.md b/_articles/ta/legal.md
index 57a0ca8ce29..21966f56f7d 100644
--- a/_articles/ta/legal.md
+++ b/_articles/ta/legal.md
@@ -104,7 +104,7 @@ Yஉங்கள் திட்டம் **சார்புகள்** கொ
 
 உங்கள் திட்டத்திற்கான கூடுதலான பங்களிப்பு ஒப்பந்தத்தை நீங்கள் பரிசீலிக்க விரும்பும் சில சூழ்நிலைகளில் பின்வருவன அடங்கும்:
 
-* உங்கள் வழக்கறிஞர்கள் பங்களிப்பவர்கள் எல்லோரும் பங்களிப்பு விதிமுறைகளை வெளிப்படையாக ஏற்றுக்கொள்ள வேண்டும் (_கையொப்பமிடல்_, இயக்கலை அல்லது முடக்கலை) திறந்த மூல உரிமம் தானே போதுமானது அல்ல (இருப்பினும் கூட!). இது மட்டுமே கவலையாக இருந்தால், திட்டத்தின் திறந்த மூல உரிமத்தை உறுதிப்படுத்தும் பங்களிப்பு ஒப்பந்தம் போதுமானதாக இருக்க வேண்டும். [JQuery தனிநபர் பங்களிப்பாளர் உரிம ஒப்பந்தம்](https://contribute.jquery.org/CLA/) இலகுரக கூடுதல் பங்களிப்பு ஒப்பந்தத்தின் சிறந்த உதாரணம். சில திட்டங்கள், ஒரு [உருவாக்குபவர் துவக்க சான்றிதழ்](https://github.com/probot/dco) ஒரு மாற்று இருக்க முடியும்.
+* உங்கள் வழக்கறிஞர்கள் பங்களிப்பவர்கள் எல்லோரும் பங்களிப்பு விதிமுறைகளை வெளிப்படையாக ஏற்றுக்கொள்ள வேண்டும் (_கையொப்பமிடல்_, இயக்கலை அல்லது முடக்கலை) திறந்த மூல உரிமம் தானே போதுமானது அல்ல (இருப்பினும் கூட!). இது மட்டுமே கவலையாக இருந்தால், திட்டத்தின் திறந்த மூல உரிமத்தை உறுதிப்படுத்தும் பங்களிப்பு ஒப்பந்தம் போதுமானதாக இருக்க வேண்டும். [JQuery தனிநபர் பங்களிப்பாளர் உரிம ஒப்பந்தம்](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) இலகுரக கூடுதல் பங்களிப்பு ஒப்பந்தத்தின் சிறந்த உதாரணம். சில திட்டங்கள், ஒரு [உருவாக்குபவர் துவக்க சான்றிதழ்](https://github.com/probot/dco) ஒரு மாற்று இருக்க முடியும்.
 * உங்கள் திட்டம் ஒரு வெளிப்படையான ஆதார உரிமையைப் பயன்படுத்துகிறது, இது ஒரு வெளிப்படையான காப்புரிமை வழங்கலை (MIT போன்றவை) உள்ளடக்குவதில்லை, மேலும் அனைத்து பங்களிப்பாளர்களிடமிருந்தும் ஒரு காப்புரிமை வழங்கல் உங்களுக்கு தேவைப்படுகிறது, அவர்களில் சிலர் உங்களிடமுள்ள பெரிய காப்புரிமை பிரிவில் உள்ள நிறுவனங்களுக்கு வேலை செய்யலாம், உங்களை அல்லது திட்டத்தின் மற்ற பங்களிப்பாளர்கள் மற்றும் பயனர்கள் குறி வைக்கலாம். [அப்பாச்சி உரிமையாளர் உரிம ஒப்பந்தம்](https://www.apache.org/licenses/icla.pdf) பொதுவாகப் பயன்படுத்தப்படும் கூடுதலான பங்களிப்பு ஒப்பந்தம் ஆகும், இது அப்பாச்சி உரிமம் 2.0 இல் காணப்பட்ட ஒரு காப்புரிமை மானியத்தை பிரதிபலிக்கிறது.
 * உங்கள் திட்டம் நகலெடுப்பு உரிமத்தின் கீழ் உள்ளது, ஆனால் நீங்கள் திட்டத்தின் தனியுரிம பதிப்புகளை விநியோகிக்க வேண்டும். உங்களிடம் பதிப்புரிமையை வழங்குவதற்கு அல்லது பங்களிப்பு உரிமத்தை உங்களுக்கு வழங்க (ஆனால் பொதுமக்கள் அல்ல) உங்களுக்கு ஒவ்வொரு பங்காளருக்கும் தேவைப்படும். [மாங்கோ பங்களிப்பாளர் ஒப்பந்தம்](https://www.mongodb.com/legal/contributor-agreement) என்பது இந்த வகை ஒப்பந்தத்தின் ஒரு எடுத்துக்காட்டு.
 * உங்கள் திட்டம் அதன் வாழ்நாளில் உரிமங்களை மாற்ற வேண்டும் மற்றும் பங்களிப்பாளர்களுக்கு அத்தகைய மாற்றங்களுக்கு முன்கூட்டியே ஒப்புக் கொள்ள வேண்டும் என்று நீங்கள் நினைக்கிறீர்கள்.
diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index 0a63171ce68..a12c6ec348f 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -104,7 +104,7 @@ Ayrıca, bazılarının gereksiz olduğuna, anlaşılmasının zor veya haksız
 
 Projeniz için ek bir katılımcı sözleşmesi düşünmek isteyebileceğiniz bazı durumlar şunlardır:
 
-* Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!)  tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı _işaretlemelerini_) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir.
+* Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!)  tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı _işaretlemelerini_) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir.
 * Projeniz, açık bir patent hibesi (MIT gibi) içermeyen bir açık kaynak lisansı kullanıyor ve bazıları sizi hedeflemek için kullanılabilecek büyük patent portföyleri olan şirketler için çalışabilecek tüm katılımcılardan bir patent hibesine ihtiyacınız var. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)  Apache License 2.0. lisansında bulunan ve çokça kullanılan bir katılımcı sözleşmesidir.
 * Projeniz bir copyleft lisansı altında, ancak aynı zamanda projenin tescilli bir versiyonunu da dağıtmanız gerekiyor. Size telif hakkı veren veya size (ancak halka değil) izin veren bir lisans veren her katılımcıya ihtiyacınız olacaktır. [MongoDB Katılımcı Anlaşması](https://www.mongodb.com/legal/contributor-agreement) bu tür bir anlaşma örneğidir.
 * Projenizin ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmesini isteyebileceğinizi düşünüyorsunuz.
diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index ca8ac47e9be..93a9bc6bd45 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -105,7 +105,7 @@ redirect_from: /zh-cn/legal/
 
 一些情况下你们可能想要为你们的项目考虑一个额外的贡献协议：
 
-* 你们的律师想要所有的贡献者明确接受贡献者条款，或者因为他们觉得只有开源许可协议还远远不够。如果这是唯一的问题，那么有肯定项目开源许可协议的贡献者协议就足够了。[jQuery个人贡献者许可协议](https://contribute.jquery.org/CLA/)就是一个很好的轻量级的个人贡献者协议。对于一些项目来说，[Developer Certificate of Origin](https://github.com/probot/dco)是一个很好的先择。
+* 你们的律师想要所有的贡献者明确接受贡献者条款，或者因为他们觉得只有开源许可协议还远远不够。如果这是唯一的问题，那么有肯定项目开源许可协议的贡献者协议就足够了。[jQuery个人贡献者许可协议](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/)就是一个很好的轻量级的个人贡献者协议。对于一些项目来说，[Developer Certificate of Origin](https://github.com/probot/dco)是一个很好的先择。
 * 你们的项目使用的开放源许可协议不包括明确的专利授权（如MIT），你们需要所有贡献者的专利授权，这些可能适合用于你们公司的专利组合或者项目的其他贡献者和用户。[Apache 个人贡献者许可协议](https://www.apache.org/licenses/icla.txt)是一种常用的附加贡献者协议，其具有与Apache许可2.0中的专利许可相同的专利许可。
 * 如果你们的项目使用的是copyleft许可协议，但你们也需要分发项目的专有版本。那你们需要每个贡献者分配版权给你们或者授予你们许可权。[MongoDB贡献者协议](https://www.mongodb.com/legal/contributor-agreement)就是这中类型的。
 * 你们认为你们的项目在其有效期内需要更换许可协议，以及事先得到贡献者的同意。
diff --git a/_articles/zh-hant/legal.md b/_articles/zh-hant/legal.md
index fcabcdc6ab0..df2d2ed9ef8 100644
--- a/_articles/zh-hant/legal.md
+++ b/_articles/zh-hant/legal.md
@@ -105,7 +105,7 @@ redirect_from: /zh-tw/legal/
 
 一些情況下你們可能想要爲你們的專案考慮一個額外的貢獻協議：
 
-* 你們的律師想要所有的貢獻者明確接受貢獻者條款，或者因爲他們覺得只有開源許可協議還遠遠不夠。如果這是唯一的問題，那麼有肯定專案開源許可協議的貢獻者協議就足夠了。[jQuery個人貢獻者許可協議](https://contribute.jquery.org/CLA/)就是一個很好的輕量級的個人貢獻者協議。對於一些專案來說，[Developer Certificate of Origin](https://github.com/probot/dco)是一個很好的先例。
+* 你們的律師想要所有的貢獻者明確接受貢獻者條款，或者因爲他們覺得只有開源許可協議還遠遠不夠。如果這是唯一的問題，那麼有肯定專案開源許可協議的貢獻者協議就足夠了。[jQuery個人貢獻者許可協議](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/)就是一個很好的輕量級的個人貢獻者協議。對於一些專案來說，[Developer Certificate of Origin](https://github.com/probot/dco)是一個很好的先例。
 * 你們的專案使用的開放源許可協議不包括明確的專利授權（如MIT），你們需要所有貢獻者的專利授權，這些可能適合用於你們公司的專利組合或者專案的其他貢獻者和用戶。[Apache 個人貢獻者許可協議](https://www.apache.org/licenses/icla.txt)是一種常用的附加貢獻者協議，其具有與Apache許可2.0中的專利許可相同的專利許可。
 * 如果你們的專案使用的是copyleft許可協議，但你們也需要分發專案的專有版本。那你們需要每個貢獻者分配版權給你們或者授予你們許可權。[MongoDB貢獻者協議](https://www.mongodb.com/legal/contributor-agreement)就是這中類型的。
 * 你們認爲你們的專案在其有效期內需要更換許可協議，以及事先得到貢獻者的同意。

From be22d4e96fcb082bff496910b8fecd59cd5ddede Mon Sep 17 00:00:00 2001
From: Eric Sorenson <eric.sorenson@puppetlabs.com>
Date: Mon, 4 Dec 2023 16:43:51 -0800
Subject: [PATCH 626/749] Fix linter failures for blank lines

Not sure what happened with the portuguese translation, here.
---
 .../pt/maintaining-balance-for-open-source-maintainers.md      | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/_articles/pt/maintaining-balance-for-open-source-maintainers.md b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
index c8745a9df99..ebf1e705b37 100644
--- a/_articles/pt/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
@@ -85,10 +85,8 @@ Dedique um tempo para refletir sobre quais aspectos da manutenção em código a
 
 Você consegue manter seu ritmo por 10 semanas? 10 meses? 10 anos?
 
-
 Existem ferramentas como a [Lista de Verificação de Esgotamento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) que podem ajudá-lo a refletir sobre seu ritmo atual e ver se há ajustes que você pode fazer. Alguns mantenedores também usam tecnologia vestível para acompanhar métricas como qualidade do sono e variabilidade da frequência cardíaca (ambas ligadas ao estresse).
 
-
 <aside markdown="1" class="pquote">
  Sou um grande defensor de dispositivos vestíveis de qualidade. Com a ciência por trás deles, você pode entender como poderia ter se saído melhor e como atingir um estado ideal do que deseja fazer.
   <p markdown="1" class="pquote-credit">
@@ -177,7 +175,6 @@ Lembre-se, a ecologia pessoal é uma prática contínua que evoluirá à medida
 * [Governança do Código Aberto](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
 * A agenda do workshop foi adaptada a partir da série [Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) da Mozilla.
 
-
 ## Contribuidores
 
 Muito obrigado a todos os mantenedores que compartilharam suas experiências e dicas conosco para este guia!

From f6a3aa70e182c2bf308bc403c2941298fdeae7c7 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 6 Dec 2023 05:00:39 +0000
Subject: [PATCH 627/749] build(deps): bump actions/deploy-pages from 2 to 3

Bumps [actions/deploy-pages](https://github.com/actions/deploy-pages) from 2 to 3.
- [Release notes](https://github.com/actions/deploy-pages/releases)
- [Commits](https://github.com/actions/deploy-pages/compare/v2...v3)

---
updated-dependencies:
- dependency-name: actions/deploy-pages
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/jekyll-preview.yml | 2 +-
 .github/workflows/jekyll.yml         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index 57cef2b5854..3d24a0ab833 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -63,6 +63,6 @@ jobs:
     steps:
       - name: Deploy to GitHub Pages
         id: deployment
-        uses: actions/deploy-pages@v2
+        uses: actions/deploy-pages@v3
         with:
           preview: 'true'
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index 2d280c8de2e..dc4c4a159c9 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -54,4 +54,4 @@ jobs:
     steps:
       - name: Deploy to GitHub Pages
         id: deployment
-        uses: actions/deploy-pages@v2
+        uses: actions/deploy-pages@v3

From 3c9209a6cf4b0a7b047d6b74e294b7ebacd60d9d Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 6 Dec 2023 05:00:41 +0000
Subject: [PATCH 628/749] build(deps): bump actions/configure-pages from 3 to 4

Bumps [actions/configure-pages](https://github.com/actions/configure-pages) from 3 to 4.
- [Release notes](https://github.com/actions/configure-pages/releases)
- [Commits](https://github.com/actions/configure-pages/compare/v3...v4)

---
updated-dependencies:
- dependency-name: actions/configure-pages
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/jekyll-preview.yml | 2 +-
 .github/workflows/jekyll.yml         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index 57cef2b5854..ab79158123b 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -38,7 +38,7 @@ jobs:
           ref: ${{ github.event.pull_request.head.ref }}
           repository: ${{ github.event.pull_request.head.repo.full_name }}
       - name: Setup Pages
-        uses: actions/configure-pages@v3
+        uses: actions/configure-pages@v4
       - name: Build with Jekyll
         uses: actions/jekyll-build-pages@v1
         with:
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index 2d280c8de2e..0c7511689b5 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -34,7 +34,7 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v4
       - name: Setup Pages
-        uses: actions/configure-pages@v3
+        uses: actions/configure-pages@v4
       - name: Build with Jekyll
         uses: actions/jekyll-build-pages@v1
         with:

From 9a31489425fc2d935ce8cfa98a81a274c8757524 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 8 Dec 2023 04:42:01 +0000
Subject: [PATCH 629/749] build(deps): bump actions/stale from 8 to 9

Bumps [actions/stale](https://github.com/actions/stale) from 8 to 9.
- [Release notes](https://github.com/actions/stale/releases)
- [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/stale/compare/v8...v9)

---
updated-dependencies:
- dependency-name: actions/stale
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/stale.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
index 8163ee6e226..1170f75b4cc 100644
--- a/.github/workflows/stale.yml
+++ b/.github/workflows/stale.yml
@@ -8,7 +8,7 @@ jobs:
   stale:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/stale@v8
+    - uses: actions/stale@v9
       with:
         stale-pr-message: >
           This pull request has been automatically marked as stale because it has not

From 92234be2b88094968fc3823b7a2cb54b442a3580 Mon Sep 17 00:00:00 2001
From: k-tecchan <tecchanboy+pc@gmail.com>
Date: Sat, 9 Dec 2023 14:50:29 +0900
Subject: [PATCH 630/749] fix typo in japanese article

---
 _articles/ja/building-community.md | 2 +-
 _articles/ja/how-to-contribute.md  | 4 ++--
 _articles/ja/starting-a-project.md | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/ja/building-community.md b/_articles/ja/building-community.md
index b0ba8ee8304..22a34b08a22 100644
--- a/_articles/ja/building-community.md
+++ b/_articles/ja/building-community.md
@@ -148,7 +148,7 @@ CONTRIBUTING ファイルに、新しいコントリビューターに始め方
   <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
   リーダーたちは異なる意見を持っていることでしょう。あらゆる健全なコミュニティはそうあるべきなのです！しかし、大きな声が人々を疲弊させることによって必ずしも勝つとは限らず、目立たない少数派の声も聞き入れられるように対策を講じる必要があります。
   <p markdown="1" class="pquote-credit">
-— @@sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
   </p>
 </aside>
 
diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md
index 3b95817e956..1dc22d13966 100644
--- a/_articles/ja/how-to-contribute.md
+++ b/_articles/ja/how-to-contribute.md
@@ -132,7 +132,7 @@ related:
 * @h5bp はフロントエンド開発者のための[面接での質問集](https://github.com/h5bp/Front-end-Developer-Interview-Questions)をまとめています
 * @stuartlynn と @nicole-a-tesla は[ツノメドリについての愉快な事柄のコレクション](https://github.com/stuartlynn/puffin_facts)を作っています
 
-たとえあなたがソフトウェアエンジニアだったとしても、ドキュメントを書くことはオープンソース活動を始めるにあたって良いスタートとなります。ときにはコードを書かないプロジェクトに関わること障壁が低く、コラボレーションのプロセスを通じて自身と経験を身につけることができます。
+たとえあなたがソフトウェアエンジニアだったとしても、ドキュメントを書くことはオープンソース活動を始めるにあたって良いスタートとなります。ときにはコードを書かないプロジェクトに関わることのほうが障壁が低く、コラボレーションのプロセスを通じて自信と経験を身につけることができます。
 
 ## 新しいプロジェクトに順応しよう
 
@@ -380,7 +380,7 @@ master ブランチのコミットアクティビティをみてみましょう
   </p>
 </aside>
 
-イシューやプルリクエストをオープンする前に、あなたのアイデアが効果的に扱われる助けのために、これらのことを心のとどめておきましょう。
+イシューやプルリクエストをオープンする前に、あなたのアイデアが効果的に扱われる助けのために、これらのことを心にとどめておきましょう。
 
 **コンテキストを与えましょう。** 他の人がすぐに把握する手助けをしましょう。もしあなたがエラーに遭遇しているのであれば、あなたが何をしようとしていて、どうやって再現させるのかを説明しましょう。もしあなたが新しいアイデアを提案しているのであれば、なぜそれがプロジェクトにとって（あなたにとってだけではなく！）便利だと思うのかを説明しましょう。
 
diff --git a/_articles/ja/starting-a-project.md b/_articles/ja/starting-a-project.md
index 7247631ec12..d0cce69eef7 100644
--- a/_articles/ja/starting-a-project.md
+++ b/_articles/ja/starting-a-project.md
@@ -56,7 +56,7 @@ _フリーソフトウェア_ という言葉も _オープンソース_ と同
 
 もし今までプロジェクトをオープンソースにしたことがないのであれば、他の人から何を言われるか、誰も全く気づいてくれないんじゃないかと心配になっているかもしれません。もしあなたがそうだとしたら、あなたは一人ではありません！
 
-オープンソース活動は他の執筆や絵画などのクリエイティブな活動を似ています。世界にあなたの作品を公開するのは怖いと感じるでしょうが、上達する唯一の方法は練習することなのです。たとえ、誰も見ている人が居ないとしても。
+オープンソース活動は他の執筆や絵画などのクリエイティブな活動と似ています。世界にあなたの作品を公開するのは怖いと感じるでしょうが、上達する唯一の方法は練習することなのです。たとえ、誰も見ている人が居ないとしても。
 
 もしまだ納得していないのであれば、あなたのゴールがどういったものであるかを少し考えてみましょう。
 

From 664cf3bd6ee1e253abbbe8ea901fe219529bf56d Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 20 Dec 2023 04:33:29 +0000
Subject: [PATCH 631/749] build(deps): bump actions/deploy-pages from 3 to 4

Bumps [actions/deploy-pages](https://github.com/actions/deploy-pages) from 3 to 4.
- [Release notes](https://github.com/actions/deploy-pages/releases)
- [Commits](https://github.com/actions/deploy-pages/compare/v3...v4)

---
updated-dependencies:
- dependency-name: actions/deploy-pages
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/jekyll-preview.yml | 2 +-
 .github/workflows/jekyll.yml         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index 27d2a26af96..474594ed85b 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -63,6 +63,6 @@ jobs:
     steps:
       - name: Deploy to GitHub Pages
         id: deployment
-        uses: actions/deploy-pages@v3
+        uses: actions/deploy-pages@v4
         with:
           preview: 'true'
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index b2bc7b88cbf..b2238b02884 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -54,4 +54,4 @@ jobs:
     steps:
       - name: Deploy to GitHub Pages
         id: deployment
-        uses: actions/deploy-pages@v3
+        uses: actions/deploy-pages@v4

From 2bfd98858ab28ed5530e6cdedb2b0a1bc07fa410 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 27 Dec 2023 04:04:33 +0000
Subject: [PATCH 632/749] build(deps): bump actions/upload-pages-artifact from
 2 to 3

Bumps [actions/upload-pages-artifact](https://github.com/actions/upload-pages-artifact) from 2 to 3.
- [Release notes](https://github.com/actions/upload-pages-artifact/releases)
- [Commits](https://github.com/actions/upload-pages-artifact/compare/v2...v3)

---
updated-dependencies:
- dependency-name: actions/upload-pages-artifact
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/jekyll-preview.yml | 2 +-
 .github/workflows/jekyll.yml         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index 474594ed85b..c7497118965 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -46,7 +46,7 @@ jobs:
           destination: ./_site
       - name: Upload artifact
         # Automatically uploads an artifact from the './_site' directory by default
-        uses: actions/upload-pages-artifact@v2
+        uses: actions/upload-pages-artifact@v3
 
   # Deployment job
   deploy:
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index b2238b02884..33ebf757a26 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -42,7 +42,7 @@ jobs:
           destination: ./_site
       - name: Upload artifact
         # Automatically uploads an artifact from the './_site' directory by default
-        uses: actions/upload-pages-artifact@v2
+        uses: actions/upload-pages-artifact@v3
 
   # Deployment job
   deploy:

From 46d2783965e03ab5eda9c658234e68d85c9e628b Mon Sep 17 00:00:00 2001
From: Chris Halbert <christopher.halbert@gmail.com>
Date: Wed, 27 Dec 2023 16:42:48 -0500
Subject: [PATCH 633/749] Add npm to list of requirements, since bootstrap uses
 it.

---
 CONTRIBUTING.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index b617f5a54e2..f64492b3dc1 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -47,7 +47,7 @@ If you're writing content, see the [style guide](./docs/styleguide.md) to help y
 
 ## Setting up your environment
 
-This site is powered by [Jekyll](https://jekyllrb.com/). Running it on your local machine requires a working [Ruby](https://www.ruby-lang.org/en/) installation with [Bundler](https://bundler.io/).
+This site is powered by [Jekyll](https://jekyllrb.com/). Running it on your local machine requires a working [Ruby](https://www.ruby-lang.org/en/) installation with [Bundler](https://bundler.io/) along with [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm).
 
 Once you have that set up:
 

From 0108ff10845b667fff19999e92a83232d9fdc160 Mon Sep 17 00:00:00 2001
From: Chris Halbert <christopher.halbert@gmail.com>
Date: Wed, 27 Dec 2023 16:43:08 -0500
Subject: [PATCH 634/749] Add exception for reddit.

---
 script/html-proofer | 1 +
 1 file changed, 1 insertion(+)

diff --git a/script/html-proofer b/script/html-proofer
index 45a74b85e26..2300e120cfc 100755
--- a/script/html-proofer
+++ b/script/html-proofer
@@ -14,6 +14,7 @@ url_ignores = [
   %r{^https://guides\.github\.com/},
   %r{^https://help\.github\.com/},
   %r{^https://github\.com/},
+  %r{^https?://(www\.)?reddit\.com/},
 ]
 
 HTMLProofer::Runner.new(

From de68a066c138c755a58be555f0d0b01fe3179857 Mon Sep 17 00:00:00 2001
From: Chris Halbert <christopher.halbert@gmail.com>
Date: Wed, 27 Dec 2023 16:49:51 -0500
Subject: [PATCH 635/749] Fix regex.

---
 script/html-proofer | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/script/html-proofer b/script/html-proofer
index 2300e120cfc..6ebe6940e95 100755
--- a/script/html-proofer
+++ b/script/html-proofer
@@ -14,7 +14,7 @@ url_ignores = [
   %r{^https://guides\.github\.com/},
   %r{^https://help\.github\.com/},
   %r{^https://github\.com/},
-  %r{^https?://(www\.)?reddit\.com/},
+  %r{^https?://(www\.)?reddit\.com},
 ]
 
 HTMLProofer::Runner.new(

From 60f4fb7baff402549d739716a2bac4f28868b56c Mon Sep 17 00:00:00 2001
From: Mohan ZHENG <91059829+CybCom@users.noreply.github.com>
Date: Tue, 2 Jan 2024 00:10:02 +0800
Subject: [PATCH 636/749] Update leadership-and-governance.md

Fixed some incorrect translations and unnatural words.
---
 _articles/zh-hans/leadership-and-governance.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/_articles/zh-hans/leadership-and-governance.md b/_articles/zh-hans/leadership-and-governance.md
index a27615e9bd8..e64b4cdb5ae 100644
--- a/_articles/zh-hans/leadership-and-governance.md
+++ b/_articles/zh-hans/leadership-and-governance.md
@@ -13,7 +13,7 @@ redirect_from: /zh-cn/leadership-and-governance/
 
 ## 了解社区治理对快速发展的项目的重要性
 
-当项目开始有条不紊的进行，人员也开始稳定，那么你就应该开始社区的治理了。对于社区的治理，你或许有一些疑问，诸如如何将常规项目的贡献者纳入你的工作流？如何才能判断应该赋予谁提交的权限？又或者是如何解决社区的债务？如果你对这些有疑问的话，我们这里会尽力帮你解决。
+当项目开始有条不紊的进行，人员也开始稳定，那么你就应该开始社区的治理了。对于社区的治理，你或许有一些疑问，诸如如何将常规项目的贡献者纳入你的工作流？如何才能判断应该赋予谁提交的权限？又或者是如何解决社区的争论？如果你对这些有疑问的话，我们这里会尽力帮你解决。
 
 ## 开源项目中常见的角色有哪些？
 
@@ -98,7 +98,7 @@ redirect_from: /zh-cn/leadership-and-governance/
 
 关于开源项目有三类通用的相关治理结构。
 
-* **BDFL:** BDFL 是 "仁慈的独裁者生活" 的缩写. 在此结构下，有一个人（通常是项目的最初的作者）拥有项目中所有的最后决定权。[Python](https://github.com/python) 就是一个非常经典的例子。较小的项目可能默认就是 BDFL 结构，因为他一般就是一到两位维护者。若是公司组织的项目也极有可能会采用BDFL结构。
+* **BDFL:** BDFL 是 "终身仁慈独裁者" 的缩写. 在此结构下，有一个人（通常是项目的最初的作者）拥有项目中所有的最后决定权。[Python](https://github.com/python) 就是一个非常经典的例子。较小的项目可能默认就是 BDFL 结构，因为他一般就是一到两位维护者。若是公司组织的项目也极有可能会采用BDFL结构。
 
 * **精英制:** **(注: 术语 "精英制" 对于一些社群可能具有消极的含义，其拥有较[复杂的社会和政治的历史](http://geekfeminism.wikia.com/wiki/Meritocracy).)** 在精英制下，活跃的项目贡献者（他们用行动证明自己是"精英"）给一个正式的决策作用，决定通常会基于纯粹的投票一致性。精英制的概念首次由[Apache Foundation](https://www.apache.org/)提出；[所有的Apache 项目](https://www.apache.org/index.html#projects-list) 都是基于精英制的。贡献者只能代表自己是独立的个体，不可以是公司。
 
@@ -112,9 +112,9 @@ redirect_from: /zh-cn/leadership-and-governance/
 
 ## 启动项目时是否需要治理文档？
 
-其实没有什么合适的时间来撰写项目的治理，但是一旦你看到社区活跃起来就更容易定义。开源治理最好（也是最难）的部分是它由社区塑造！
+其实没有什么合适的时间来撰写项目的治理，但是一旦你看到社区活跃起来，就更容易定义它。开源治理最好（也是最难）的部分是它由社区塑造！
 
-在项目的治理中，一些早期的文档将会不可避免的，然而也不必太强求，写下你所能够想到的。举例来说，你可以将某些预期的行为定义清楚，贡献的流程是如何的，或者项目是如何启动的，等等。
+然而，一些早期文档将不可避免地影响项目的治理，因此请一开始就写下您能写下的内容。举例来说，你可以将某些预期的行为定义清楚，贡献的流程是如何的，或者项目是如何启动的，等等。
 
 如果你要开源公司的项目，那么在发布之前，有必要进行内部讨论，了解你的公司希望如何维护并做出有关项目进展的决策。你可能还想公开解释贵公司将如何（或不会！）参与项目的具体内容。
 
@@ -146,7 +146,7 @@ redirect_from: /zh-cn/leadership-and-governance/
 
 如果你打算让自己的开源项目接受捐赠的话，你可以创建一个捐赠按钮（使用PayPal或Stripe，举例来说），但是你要知道，这些钱并非是免税的，除非你是认证过的非盈利性组织（在美国的话，诸如501c3）。
 
-很多项目都不愿意成立非盈利组织那么麻烦，所以他们会以赞助商的身份寻找一个非营利性组织。财政资助代表你接受捐款,通常以换取一定比例的捐赠。针对开源项目接受财政资助的非营利性组织有很多，如[Software Freedom Conservancy](https://sfconservancy.org/), [Apache 基金会](https://www.apache.org/), [Eclipse 基金会](https://eclipse.org/org/foundation/), [Linux 基金会](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) 等等。
+很多项目都不愿意成立非盈利组织那么麻烦，所以他们会以赞助商的身份寻找一个非营利性组织。财政资助代表你接受捐款,通常以换取一定比例的捐赠。针对开源项目接受财政资助的非营利性组织有很多，如[Software Freedom Conservancy](https://sfconservancy.org/), [Apache 基金会](https://www.apache.org/), [Eclipse 基金会](https://eclipse.org/org/foundation/), [Linux 基金会](https://www.linuxfoundation.org/projects) 以及 [Open Collective](https://opencollective.com/opensource) 等。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
@@ -156,4 +156,4 @@ redirect_from: /zh-cn/leadership-and-governance/
   </p>
 </aside>
 
-如果你的项目是和某特定的语言或生态系统紧密相连的，那么你可以直接在相关的软件基金会下工作。例如，[Python 软件基金会](https://www.python.org/psf/) 就帮衬着项目 [PyPI](https://pypi.org/)，这是一块优秀的Python包管理器，又比如[Node.js 基金会](https://foundation.nodejs.org/) 支撑着 [Express.js](https://expressjs.com/)，一款基于Node的框架。
+如果你的项目是和某特定的语言或生态系统紧密相连的，那么你可以直接在相关的软件基金会下工作。例如，[Python 软件基金会](https://www.python.org/psf/) 就帮衬着项目 [PyPI](https://pypi.org/)，一款优秀的Python包管理器；又比如[Node.js 基金会](https://foundation.nodejs.org/) 支持着 [Express.js](https://expressjs.com/)，一款基于Node的框架。

From b5866e42a91b83fdcb7b53ab6a58afa6e974c15e Mon Sep 17 00:00:00 2001
From: Elizabeth Orji <cegscutie4rill@yahoo.com>
Date: Sat, 6 Jan 2024 00:01:58 +0100
Subject: [PATCH 637/749] Changed pidgin to PCM

---
 _articles/{pidgin => pcm}/best-practice.md      | 0
 _articles/{pidgin => pcm}/building-community.md | 0
 _articles/{pidgin => pcm}/code-of-conduct.md    | 0
 _articles/{pidgin => pcm}/finding-users.md      | 0
 _data/locales/{pidgin.yml => pcm.yml}           | 0
 5 files changed, 0 insertions(+), 0 deletions(-)
 rename _articles/{pidgin => pcm}/best-practice.md (100%)
 rename _articles/{pidgin => pcm}/building-community.md (100%)
 rename _articles/{pidgin => pcm}/code-of-conduct.md (100%)
 rename _articles/{pidgin => pcm}/finding-users.md (100%)
 rename _data/locales/{pidgin.yml => pcm.yml} (100%)

diff --git a/_articles/pidgin/best-practice.md b/_articles/pcm/best-practice.md
similarity index 100%
rename from _articles/pidgin/best-practice.md
rename to _articles/pcm/best-practice.md
diff --git a/_articles/pidgin/building-community.md b/_articles/pcm/building-community.md
similarity index 100%
rename from _articles/pidgin/building-community.md
rename to _articles/pcm/building-community.md
diff --git a/_articles/pidgin/code-of-conduct.md b/_articles/pcm/code-of-conduct.md
similarity index 100%
rename from _articles/pidgin/code-of-conduct.md
rename to _articles/pcm/code-of-conduct.md
diff --git a/_articles/pidgin/finding-users.md b/_articles/pcm/finding-users.md
similarity index 100%
rename from _articles/pidgin/finding-users.md
rename to _articles/pcm/finding-users.md
diff --git a/_data/locales/pidgin.yml b/_data/locales/pcm.yml
similarity index 100%
rename from _data/locales/pidgin.yml
rename to _data/locales/pcm.yml

From 7beaca966bfad63685192910895be0b8d8f4741f Mon Sep 17 00:00:00 2001
From: AdithyaPadmashali <57041819+AdithyaPadmashali@users.noreply.github.com>
Date: Wed, 10 Jan 2024 23:21:01 +0530
Subject: [PATCH 638/749] Update how-to-contribute.md

Added missing space between text and link (line 245)
---
 _articles/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 196c21f34d4..88e3adefb17 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -242,7 +242,7 @@ Here's a handy checklist to evaluate whether a project is good for new contribut
 
 **Project actively accepts contributions**
 
-Look at the commit activity on the main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as[Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
+Look at the commit activity on the main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">

From 0a40a96523fa127959497956430c6e1d879d7630 Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Fri, 12 Jan 2024 15:49:55 -0800
Subject: [PATCH 639/749] Apply suggestions from code review

Fixing up the metadata
---
 _articles/pcm/code-of-conduct.md | 2 +-
 _articles/pcm/finding-users.md   | 2 +-
 _data/locales/pcm.yml            | 4 ++--
 assets/css/translate.scss        | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/_articles/pcm/code-of-conduct.md b/_articles/pcm/code-of-conduct.md
index d008849c68f..646f2a49d68 100644
--- a/_articles/pcm/code-of-conduct.md
+++ b/_articles/pcm/code-of-conduct.md
@@ -1,5 +1,5 @@
 ---
-lang: pidgin
+lang: pcm
 title: Una Code of Conduct
 description: Make community people dey behave well and do constructive tins, by accepting and enforcing the code of conduct.
 class: coc
diff --git a/_articles/pcm/finding-users.md b/_articles/pcm/finding-users.md
index a1b620e1ed3..09b6ddd00d6 100644
--- a/_articles/pcm/finding-users.md
+++ b/_articles/pcm/finding-users.md
@@ -1,5 +1,5 @@
 ---
-lang: pidgin
+lang: pcm
 title: How to find the people to helep your project
 description: You go helep your open source project grow if you bin put am with people waeh dey happy happy.
 class: finding
diff --git a/_data/locales/pcm.yml b/_data/locales/pcm.yml
index 7a6a648f6dd..6be4951f1f1 100644
--- a/_data/locales/pcm.yml
+++ b/_data/locales/pcm.yml
@@ -1,5 +1,5 @@
-en:
-  locale_name: English
+pcm:
+  locale_name: Pidgin
   nav:
     about: About
     contribute: Put hand
diff --git a/assets/css/translate.scss b/assets/css/translate.scss
index 4d183d220fd..b913b0d43b0 100644
--- a/assets/css/translate.scss
+++ b/assets/css/translate.scss
@@ -27,7 +27,7 @@ $section_translation: (
         "tr": "",
         "zh-hant": "章節",
         "zh-hans": "章节",
-        "pidgin": "Portion",
+        "pcm": "Portion",
 );
 
 @each $locale, $translation in $section_translation {

From bbd67b221965d46013bcbb99a433e7a0569d5f3a Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Fri, 12 Jan 2024 16:51:17 -0800
Subject: [PATCH 640/749] Fix test failures

- Markdown style wants `*` not `-` for lists
- Removed some extra blank lines
- The `retext-repeated-words` plugin has only a small list of
  words that are allowed to be repeated, but pidgin uses doubled
  words as intensifiers ("small small" for "very small"). I added
  hyphens ("small-small") because I saw some examples of that
- Renamed the `best-practice.md` -> `best-practices.md` to match
  the rest of the site
- Copied the untranslated articles in so the site build works
---
 .../{best-practice.md => best-practices.md}   |  20 +-
 _articles/pcm/building-community.md           |   4 +-
 _articles/pcm/code-of-conduct.md              |  22 +-
 _articles/pcm/getting-paid.md                 | 178 ++++++
 _articles/pcm/how-to-contribute.md            | 526 ++++++++++++++++++
 _articles/pcm/leadership-and-governance.md    | 156 ++++++
 _articles/pcm/legal.md                        | 160 ++++++
 ...ing-balance-for-open-source-maintainers.md | 220 ++++++++
 _articles/pcm/metrics.md                      | 128 +++++
 _articles/pcm/starting-a-project.md           | 356 ++++++++++++
 10 files changed, 1746 insertions(+), 24 deletions(-)
 rename _articles/pcm/{best-practice.md => best-practices.md} (96%)
 create mode 100644 _articles/pcm/getting-paid.md
 create mode 100644 _articles/pcm/how-to-contribute.md
 create mode 100644 _articles/pcm/leadership-and-governance.md
 create mode 100644 _articles/pcm/legal.md
 create mode 100644 _articles/pcm/maintaining-balance-for-open-source-maintainers.md
 create mode 100644 _articles/pcm/metrics.md
 create mode 100644 _articles/pcm/starting-a-project.md

diff --git a/_articles/pcm/best-practice.md b/_articles/pcm/best-practices.md
similarity index 96%
rename from _articles/pcm/best-practice.md
rename to _articles/pcm/best-practices.md
index 195f3d1d556..069470ed728 100644
--- a/_articles/pcm/best-practice.md
+++ b/_articles/pcm/best-practices.md
@@ -1,5 +1,5 @@
 ---
-lang: pidgin
+lang: pcm
 title: Best Practices for Maintainers
 description: Learn how to make your life easy as an open source maintainer, from documentation to community collaboration. Make sense of maintaining open source projects with these top-notch tips.
 class: best-practices
@@ -42,16 +42,16 @@ As @lord don talk, project vision fit help you know wetin you go fit work on. As
 
 E fit hard you to write down rules. Sometimes you fit think say you dey police people or say you dey dull dem vibe.
 
-But if you write rules fairly and you dey follow am, e go empower you. E go prevent you from doing tins wey you no like. People wey see your project fit no sabi your condition or circumstances. Dem fit think say dem dey pay you for the work wey you dey do, especially if na wetin dem dey use well well. Dem fit even think say you dey busy with new work or family matter.
+But if you write rules fairly and you dey follow am, e go empower you. E go prevent you from doing tins wey you no like. People wey see your project fit no sabi your condition or circumstances. Dem fit think say dem dey pay you for the work wey you dey do, especially if na wetin dem dey use well-well. Dem fit even think say you dey busy with new work or family matter.
 
 E good make people sabi dis tins.
 
 If to maintain your project na part-time or you dey do am because you volunteer, make you talk the time wey you get. E no be say na the time wey your project need or wetin people dey ask you for, na the time wey you get na e you go talk. E fit good if you write down some rules like:
 
-- How dem go review contribution (dem need test? Issue template?)
-- The kind of contribution wey dem go accept (you wan make dem help you with specific part of your code?)
-- When e go make sense for dem to follow up (e.g., "you fit expect response from maintainer within 7 days, if you no see any response by then, you fit ping the thread")
-- How much time you dey spend for the project (e.g., "we dey spend like 5 hours per week on this project")
+* How dem go review contribution (dem need test? Issue template?)
+* The kind of contribution wey dem go accept (you wan make dem help you with specific part of your code?)
+* When e go make sense for dem to follow up (e.g., "you fit expect response from maintainer within 7 days, if you no see any response by then, you fit ping the thread")
+* How much time you dey spend for the project (e.g., "we dey spend like 5 hours per week on this project")
 
 [Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) na some examples of projects wey get rules for maintainers and contributors.
 
@@ -65,7 +65,7 @@ If you meet other maintainers or you take big decision for private, write the co
 
 You don write down wetin you want, but people never read your documentation well. Sometimes you go still remind them say knowledge dey your documentation.
 
-Saying no no dey fun, but make you try yarn "Your contribution no dey follow this project criteria" e no too personal like "I no like your contribution."
+Saying "no" no dey fun, but make you try yarn "Your contribution no dey follow this project criteria" e no too personal like "I no like your contribution."
 
 You go fit yarn no for plenty situations wey you go see as maintainer like feature requests wey no follow your project plan or person wey dey disturb discussion.
 
@@ -89,7 +89,7 @@ If you come across one contribution wey you no wan accept, your first reaction f
 
 No just allow one contribution wey you no want dey open because you dey feel bad or you dey try to dey nice. As time dey go, the issues and PRs wey you never answer go make your project come dey feel like say e too stress you and dey intimidate you.
 
-E better make you quick-close contributions wey you sabi say you no wan accept am. If your project don already gather plenti matter wey never resolve, @steveklabnik get some advice on [how to quickly arrange the issues] so e go dey efficient. (https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+E better make you quick-close contributions wey you sabi say you no wan accept am. If your project don already gather plenti matter wey never resolve, @steveklabnik get some advice on [how to quickly arrange the issues](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) so e go dey efficient.
 
 If you no wan accept one contribution:
 
@@ -245,7 +245,7 @@ Just like any other work, make you dey take regular breaks so you go dey refresh
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
   In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
   <p markdown="1" class="pquote-credit">
-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https/danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
@@ -257,4 +257,4 @@ Taking breaks no only apply to vacations, e fit include say you no wan do open s
 
 ## Make you dey take care of yourself first!
 
-To maintaining one popular project require different skills from the first first time of growth, but e no dey less rewarding. As one maintainer, you go dey practice leadership and personal skills for one level wey few people fit experience. Though e no dey easy to manage, setting clear boundaries and only taking on wetin you dey comfortable with go help you dey happy, refreshed, and productive.
+To maintaining one popular project require different skills from the first-first time of growth, but e no dey less rewarding. As one maintainer, you go dey practice leadership and personal skills for one level wey few people fit experience. Though e no dey easy to manage, setting clear boundaries and only taking on wetin you dey comfortable with go help you dey happy, refreshed, and productive.
diff --git a/_articles/pcm/building-community.md b/_articles/pcm/building-community.md
index 315c2037cd2..1db3fef4f81 100644
--- a/_articles/pcm/building-community.md
+++ b/_articles/pcm/building-community.md
@@ -141,7 +141,7 @@ You no go fit talk with most people wey go show for your project. Some people fi
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
-  Una leaders go get different opinions, as all healthy communities should! The thing be say, you gas take steps to make sure the loudest voice no dey always win by tiring people out, and that small small voices for our midst, we dey hear am.
+  Una leaders go get different opinions, as all healthy communities should! The thing be say, you gas take steps to make sure the loudest voice no dey always win by tiring people out, and that small-small voices for our midst, we dey hear am.
   <p markdown="1" class="pquote-credit">
 — @sagesharp, ["Wetin makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
   </p>
@@ -191,7 +191,6 @@ Make your head nor dey hot e nor easy, but as you set good example, e go make yo
 
 Your README [no be only set of instructions](../starting-a-project/#writing-a-readme). E also na place to yan about your goals, product vision, and roadmap. If people dey focus too much on top argument about one particular feature, e fit help if you go back your README, talk about the higher vision of your project. To focus on your README go even make the matter no dey personal, so that you go fit yan-kick with sense.
 
-
 ### Make we focus for the journey, nor be the destination
 
 Some projects dey use voting process to take make major decisions. E fit look sensible for eye at first, but voting dey show say them dey find 'answer,' instead of say them dey listen to each other concerns.
@@ -236,7 +235,6 @@ If the talk clear nor dey waka, e nor get clear action to take, or the right act
   </p>
 </aside>
 
-
 ### Choose your battles with sense
 
 Context dey important. Think about the people wey dey the discussion and how them represent the rest of the community.
diff --git a/_articles/pcm/code-of-conduct.md b/_articles/pcm/code-of-conduct.md
index 646f2a49d68..93287322020 100644
--- a/_articles/pcm/code-of-conduct.md
+++ b/_articles/pcm/code-of-conduct.md
@@ -24,10 +24,10 @@ Make you try your best to arrange code of conduct early, if you fit, ideally whe
 
 Apart from just communicating your expectations, code of conduct fit describe the following:
 
-- Where the code of conduct dey apply _(only on issues and pull requests, or community activities like events?)_
-- Whom the code of conduct dey apply to _(community members and maintainers, but what about sponsors?)_
-- Wetin go happen if person violate the code of conduct
-- How person fit report violations
+* Where the code of conduct dey apply _(only on issues and pull requests, or community activities like events?)_
+* Whom the code of conduct dey apply to _(community members and maintainers, but what about sponsors?)_
+* Wetin go happen if person violate the code of conduct
+* How person fit report violations
 
 Anywhere way you fit, try to use previous example. The [Contributor Covenant](https://contributor-covenant.org/) na code of conduct wey many open source projects, including Kubernetes, Rails, and Swift, don use, and e fit serve as example.
 
@@ -46,11 +46,11 @@ Put one CODE_OF_CONDUCT file for your project's main directory, and make sure sa
 
 You suppose explain how you go enforce your code of conduct **_before_** person violate am. Some reasons why you suppose do am be say:
 
-- E show say you dey serious about action when e dey necessary.
+* E show say you dey serious about action when e dey necessary.
 
-- Your community go dey reassured say complaints go dey reviewed.
+* Your community go dey reassured say complaints go dey reviewed.
 
-- You go reassure your community say the review process go dey fair and transparent, if at any time dem dey investigated for violation.
+* You go reassure your community say the review process go dey fair and transparent, if at any time dem dey investigated for violation.
 
 You suppose give people private way (like email address) to report code of conduct violation and explain who go receive that report. E fit be maintainer, group of maintainers, or code of conduct working group.
 
@@ -87,15 +87,15 @@ If person report say somebody violate the code of conduct, e na you suppose hand
 
 You fit respond to code of conduct violation for different ways:
 
-- **Warn the person wey dey involved publicly** and explain how their behavior affect others, preferably for the place where e happen. If possible, public communication go show the rest of the community say you dey serious about the code of conduct. Make you dey kind but firm for your communication.
+* **Warn the person wey dey involved publicly** and explain how their behavior affect others, preferably for the place where e happen. If possible, public communication go show the rest of the community say you dey serious about the code of conduct. Make you dey kind but firm for your communication.
 
-- **Privately reach out to the person** wey dey involved to explain how their behavior affect others. You fit use private communication channel if the situation get sensitive personal information. If you communicate privately with person, e good make you CC those wey first report the situation, so dem go know say you don take action. Ask the person wey report make e agree before you CC am.
+* **Privately reach out to the person** wey dey involved to explain how their behavior affect others. You fit use private communication channel if the situation get sensitive personal information. If you communicate privately with person, e good make you CC those wey first report the situation, so dem go know say you don take action. Ask the person wey report make e agree before you CC am.
 
 Sometimes, you fit no fit resolve the matter. The person wey dey involved fit dey aggressive or hostile when you confront am, or e no fit change their behavior. For this kind situation, you fit consider stronger action. For example:
 
-- **Suspend the person** wey dey involved for the project, you go enforce am through temporary ban wey go stop am from participating for any aspect of the project.
+* **Suspend the person** wey dey involved for the project, you go enforce am through temporary ban wey go stop am from participating for any aspect of the project.
 
-- **Permanently ban** the person from the project.
+* **Permanently ban** the person from the project.
 
 Make you no take banning members lightly, e be like say e be something wey no fit change and no fit reconcile different perspectives. You suppose only take these measures if e clear say you no fit resolve the matter.
 
diff --git a/_articles/pcm/getting-paid.md b/_articles/pcm/getting-paid.md
new file mode 100644
index 00000000000..7fd4a32af4c
--- /dev/null
+++ b/_articles/pcm/getting-paid.md
@@ -0,0 +1,178 @@
+---
+lang: en
+title: Getting Paid for Open Source Work
+description: Sustain your work in open source by getting financial support for your time or your project.
+class: getting-paid
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+  - best-practices
+  - leadership
+---
+
+## Why some people seek financial support
+
+Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
+I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+  <p markdown="1" class="pquote-credit">
+— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+  </p>
+</aside>
+
+There are many reasons why a person would not want to be paid for their open source work.
+
+* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
+* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
+* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
+  Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+  <p markdown="1" class="pquote-credit">
+— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+  </p>
+</aside>
+
+For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+
+Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
+  Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+  <p markdown="1" class="pquote-credit">
+— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+  </p>
+</aside>
+
+Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
+   OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+  <p markdown="1" class="pquote-credit">
+— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+  </p>
+</aside>
+
+If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+
+## Funding your own time
+
+Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+
+It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+
+If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+
+Many companies are developing open source programs to build their brand and recruit quality talent.
+
+@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+
+> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+
+If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
+  Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+  <p markdown="1" class="pquote-credit">
+— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+  </p>
+</aside>
+
+If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+
+* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
+* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+
+Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+
+Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
+
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
+* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
+* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+Finally, sometimes open source projects put bounties on issues that you might consider helping with.
+
+* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
+* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+
+## Finding funding for your project
+
+Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+
+Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas.
+
+As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+
+### Raise money for your work through crowdfunding campaigns or sponsorships
+
+Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
+A few examples of sponsored projects include:
+
+* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
+* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+
+### Create a revenue stream
+
+Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
+* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
+* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+
+Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+
+### Apply for grant funding
+
+Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+
+For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+
+## Building a case for financial support
+
+Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+
+Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+
+### Impact
+
+Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+
+### Traction
+
+Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+
+### Value to funder
+
+Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+
+### Use of funds
+
+What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+
+### How you'll receive the funds
+
+Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
+  For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+  <p markdown="1" class="pquote-credit">
+— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+  </p>
+</aside>
+
+## Experiment and don't give up
+
+Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
diff --git a/_articles/pcm/how-to-contribute.md b/_articles/pcm/how-to-contribute.md
new file mode 100644
index 00000000000..196c21f34d4
--- /dev/null
+++ b/_articles/pcm/how-to-contribute.md
@@ -0,0 +1,526 @@
+---
+lang: en
+title: How to Contribute to Open Source
+description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans.
+class: contribute
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+  - beginners
+  - building
+---
+
+## Why contribute to open source?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
+  Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+  <p markdown="1" class="pquote-credit">
+— [@errietta](https://github.com/errietta), ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+  </p>
+</aside>
+
+Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+
+Why do people contribute to open source? Plenty of reasons!
+
+### Improve software you rely on
+
+Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+
+### Improve existing skills
+
+Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+
+### Meet people who are interested in similar things
+
+Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+
+### Find mentors and teach others
+
+Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+
+### Build public artifacts that help you grow a reputation (and a career)
+
+By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+
+### Learn people skills
+
+Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+
+### It's empowering to be able to make changes, even small ones
+
+You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+
+## What it means to contribute
+
+If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+
+Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+
+### You don't have to contribute code
+
+A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
+  I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+  <p markdown="1" class="pquote-credit">
+— [@orta](https://github.com/orta), ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+  </p>
+</aside>
+
+Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+
+### Do you like planning events?
+
+* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Organize the project's conference (if they have one)
+* Help community members find the right conferences and submit proposals for speaking
+
+### Do you like to design?
+
+* Restructure layouts to improve the project's usability
+* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Put together a style guide to help the project have a consistent visual design
+* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+
+### Do you like to write?
+
+* Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
+* Curate a folder of examples showing how the project is used
+* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/)
+* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
+  Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+  <p markdown="1" class="pquote-credit">
+— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+  </p>
+</aside>
+
+### Do you like organizing?
+
+* Link to duplicate issues, and suggest new issue labels, to keep things organized
+* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
+* Ask clarifying questions on recently opened issues to move the discussion forward
+
+### Do you like to code?
+
+* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Ask if you can help write a new feature
+* Automate project setup
+* Improve tooling and testing
+
+### Do you like helping people?
+
+* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
+* Answer questions for people on open issues
+* Help moderate the discussion boards or conversation channels
+
+### Do you like helping others code?
+
+* Review code on other people's submissions
+* Write tutorials for how a project can be used
+* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### You don't just have to work on software projects!
+
+While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+
+For example:
+
+* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
+* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
+* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+
+Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
+
+## Orienting yourself to a new project
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
+  If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+  <p markdown="1" class="pquote-credit">
+— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+  </p>
+</aside>
+
+For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+
+Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
+
+### Anatomy of an open source project
+
+Every open source community is different.
+
+Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+
+That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+
+A typical open source project has the following types of people:
+
+* **Author:** The person/s or organization that created the project
+* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
+* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
+* **Contributors:** Everyone who has contributed something back to the project
+* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+
+Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+
+A project also has documentation. These files are usually listed in the top level of a repository.
+
+* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
+* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
+* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).
+* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
+* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
+
+Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+
+* **Issue tracker:** Where people discuss issues related to the project.
+* **Pull requests:** Where people discuss and review changes that are in progress whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), use certain GitHub Action flows to automate and quicken their code reviews.  
+* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/)
+* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/).
+
+## Finding a project to contribute to
+
+Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+
+If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said:, _"Ask not what your country can do for you - ask what you can do for your country."_
+
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/how-to-contribute/johnfkennedy.jpg" class="pquote-avatar" alt="avatar">
+  Ask not what your country can do for you - ask what you can do for your country.
+  <p markdown="1" class="pquote-credit">
+— [_John F. Kennedy Library_](https://www.jfklibrary.org/learn/education/teachers/curricular-resources/ask-not-what-your-country-can-do-for-you)
+  </p>
+</aside>
+
+Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+
+Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+
+Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+
+Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+
+You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
+
+> According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as  typo fixes, reformatting, or writing a translation.
+
+If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+You can also use one of the following resources to help you discover and contribute to new projects:
+
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://opensauced.pizza/)
+
+### A checklist before you contribute
+
+When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+
+Here's a handy checklist to evaluate whether a project is good for new contributors.
+
+**Meets the definition of open source**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+  </label>
+</div>
+
+**Project actively accepts contributions**
+
+Look at the commit activity on the main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as[Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+  When was the latest commit?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+  How many contributors does the project have?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  </label>
+</div>
+
+Next, look at the project's issues.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    How many open issues are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to issues when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Are the issues recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+  </label>
+</div>
+
+Now do the same for the project's pull requests.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    How many open pull requests are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox20" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to pull requests when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the pull requests?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    Are the pull requests recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox13" class="overflow-hidden d-block text-normal">
+    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+  </label>
+</div>
+
+**Project is welcoming**
+
+A project that is friendly and welcoming signals that they will be receptive to new contributors.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox14" class="overflow-hidden d-block text-normal">
+    Do the maintainers respond helpfully to questions in issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox15" class="overflow-hidden d-block text-normal">
+    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox16" class="overflow-hidden d-block text-normal">
+    Do pull requests get reviewed?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox17" class="overflow-hidden d-block text-normal">
+    Do maintainers thank people for their contributions?
+  </label>
+</div>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+  </p>
+</aside>
+
+## How to submit a contribution
+
+You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+
+### Communicating effectively
+
+Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
+  \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+  <p markdown="1" class="pquote-credit">
+— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+  </p>
+</aside>
+
+Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+
+**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+
+> 😇 _"X doesn't happen when I do Y"_
+>
+> 😢 _"X is broken! Please fix it."_
+
+**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn.
+
+> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+>
+> 😢 _"How do I X?"_
+
+**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+
+> 😇 _"I'd like to write an API tutorial."_
+>
+> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+
+**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+
+> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+>
+> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+
+**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+
+> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+>
+> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+
+**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+
+> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+>
+> 😢 _"Why won't you support my use case? This is unacceptable!"_
+
+**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+
+### Gathering context
+
+Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+
+If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by doing the following:
+
+* **Raising an Issue:** These are like starting a conversation or discussion
+* **Pull requests** are for starting work on a solution.
+* **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution.
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
+  You'll learn <em>a lot</em> from taking a single project you actively use, "watching" it on GitHub and reading every issue and PR.
+<p markdown="1" class="pquote-credit">
+— @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
+  </p>
+</aside>
+
+### Opening an issue
+
+You should usually open an issue in the following situations:
+
+* Report an error you can't solve yourself
+* Discuss a high-level topic or idea (for example, community, vision or policies)
+* Propose a new feature or other project idea
+
+Tips for communicating on issues:
+
+* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
+* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
+* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+
+### Opening a pull request
+
+You should usually open a pull request in the following situations:
+
+* Submit small fixes such as a typo, a broken link or an obvious error.
+* Start work on a contribution that was already asked for, or that you've already discussed, in an issue.
+
+A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later.
+
+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/).)
+* **[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.
+* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. It's important to make sure your changes don't break the existing project.
+* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+
+If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+
+## What happens after you submit your contribution
+
+Before we start celebrating, one of the following will happen after you submit your contribution:
+
+### 😭 You don't get a response
+
+Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+
+If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+
+**Don't reach out to that person privately**; remember that public communication is vital to open source projects.
+
+If you give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+
+### 🚧 Someone requests changes to your contribution
+
+It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+
+When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286).
+
+If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).
+
+### 👎 Your contribution doesn't get accepted
+
+Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+
+### 🎉 Your contribution gets accepted
+
+Hooray! You've successfully made an open source contribution!
+
+## You did it! 🎉
+
+Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
diff --git a/_articles/pcm/leadership-and-governance.md b/_articles/pcm/leadership-and-governance.md
new file mode 100644
index 00000000000..6fd75930d5d
--- /dev/null
+++ b/_articles/pcm/leadership-and-governance.md
@@ -0,0 +1,156 @@
+---
+lang: en
+title: Leadership and Governance
+description: Growing open source projects can benefit from formal rules for making decisions.
+class: leadership
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+  - best-practices
+  - metrics
+---
+
+## Understanding governance for your growing project
+
+Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+
+## What are examples of formal roles used in open source projects?
+
+Many projects follow a similar structure for contributor roles and recognition.
+
+What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+
+* **Maintainer**
+* **Contributor**
+* **Committer**
+
+**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+
+A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+
+**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+  </p>
+</aside>
+
+**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+
+While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
+  You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+  <p markdown="1" class="pquote-credit">
+— @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+  </p>
+</aside>
+
+## How do I formalize these leadership roles?
+
+Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+
+For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+
+For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+
+If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+
+<aside markdown="1" class="pquote">
+  \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+  <p markdown="1" class="pquote-credit">
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+  </p>
+</aside>
+
+Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+
+Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+
+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).
+
+## When should I give someone commit access?
+
+Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
+  Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+  <p markdown="1" class="pquote-credit">
+— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+  </p>
+</aside>
+
+## What are some of the common governance structures for open source projects?
+
+There are three common governance structures associated with open source projects.
+
+* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+
+* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+
+* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
+
+Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Do I need governance docs when I launch my project?
+
+There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+
+Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+
+If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
+  We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+  <p markdown="1" class="pquote-credit">
+— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+  </p>
+</aside>
+
+## What happens if corporate employees start submitting contributions?
+
+Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+
+As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+
+It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+
+"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+
+Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+
+## Do I need a legal entity to support my project?
+
+You don't need a legal entity to support your open source project unless you're handling money.
+
+For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+
+If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+
+Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
+  Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+  <p markdown="1" class="pquote-credit">
+— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+  </p>
+</aside>
+
+If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
diff --git a/_articles/pcm/legal.md b/_articles/pcm/legal.md
new file mode 100644
index 00000000000..30d391b2f76
--- /dev/null
+++ b/_articles/pcm/legal.md
@@ -0,0 +1,160 @@
+---
+lang: en
+title: The Legal Side of Open Source
+description: Everything you've ever wondered about the legal side of open source, and a few things you didn't.
+class: legal
+order: 10
+image: /assets/images/cards/legal.png
+related:
+  - contribute
+  - leadership
+---
+
+## Understanding the legal implications of open source
+
+Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this guide you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+
+## Why do people care so much about the legal side of open source?
+
+Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+
+In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly give these permissions with a license.
+
+These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions.
+
+Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
+
+## 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**.
+
+![Create repository](/assets/images/legal/repo-create-name.png)
+
+**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+
+If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+
+## Just give me the TL;DR on what I need to protect my project.
+
+You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+
+[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/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
+  A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+  <p markdown="1" class="pquote-credit">
+— @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+  </p>
+</aside>
+
+## Which open source license is appropriate for my project?
+
+It's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/) if you're starting with a blank slate. It's short, easily understood, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+
+Otherwise, picking the right open source license for your project depends on your objectives.
+
+Your project very likely has (or will have) **dependencies**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm).
+
+Dependencies with **permissive licenses** like [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause) allow you to license your project however you want.
+
+Dependencies with **copyleft licenses** require closer attention. Including any library with a "strong" copyleft license like the [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), or [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) requires you to choose an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) for your project. Libraries with a "limited" or "weak" copyleft license like the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) can be included in projects with any license, provided you follow the [additional rules](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) they specify.
+ 
+You may also want to consider the **communities** you hope will use and contribute to your project:
+
+* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
+* **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) (and them) covered.
+* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+
+Your **company** may have policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance.
+
+When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+
+## What if I want to change the license of my project?
+
+Most projects never need to change licenses. But occasionally circumstances change.
+
+For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+
+**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+
+**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+
+**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? [People who have commits in your project](https://github.com/thehale/git-authorship) is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+
+Alternatively, you can have contributors pre-approve certain license changes via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)). This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+
+## 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).
+
+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.
+
+Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
+    We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+  <p markdown="1" class="pquote-credit">
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+  </p>
+</aside>
+
+Some situations where you may want to consider an additional contributor agreement for your project include:
+
+* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
+* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
+* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
+* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
+* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
+
+If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+
+## What does my company's legal team need to know?
+
+If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+
+For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+
+**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+
+* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses ([see above](#which-open-source-license-is-appropriate-for-my-project)). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+
+* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+
+* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement ([see above](#which-open-source-license-is-appropriate-for-my-project)).
+
+* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+
+* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+
+If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+
+Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+
+* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
+  Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+  <p markdown="1" class="pquote-credit">
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+  </p>
+</aside>
+
+* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
+* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+
+<aside markdown="1" class="pquote">
+  Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+  <p markdown="1" class="pquote-credit">
+— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+  </p>
+</aside>
+
+* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
+* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
diff --git a/_articles/pcm/maintaining-balance-for-open-source-maintainers.md b/_articles/pcm/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..c418b476786
--- /dev/null
+++ b/_articles/pcm/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,220 @@
+---
+lang: en
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/pcm/metrics.md b/_articles/pcm/metrics.md
new file mode 100644
index 00000000000..145dd18119b
--- /dev/null
+++ b/_articles/pcm/metrics.md
@@ -0,0 +1,128 @@
+---
+lang: en
+title: Open Source Metrics
+description: Make informed decisions to help your open source project thrive by measuring and tracking its success.
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+  - finding
+  - best-practices
+---
+
+## Why measure anything?
+
+Data, when used wisely, can help you make better decisions as an open source maintainer.
+
+With more information, you can:
+
+* Understand how users respond to a new feature
+* Figure out where new users come from
+* Identify, and decide whether to support, an outlier use case or functionality
+* Quantify your project's popularity
+* Understand how your project is used
+* Raise money through sponsorships and grants
+
+For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+
+> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+
+Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+
+If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+
+## Discovery
+
+Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+
+![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:
+
+* **Total page views:** Tells you how many times your project was viewed
+
+* **Total unique visitors:** Tells you how many people viewed your project
+
+* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+
+* **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.
+
+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.
+
+## Usage
+
+People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+
+If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+
+Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+
+If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+
+![Clone graph](/assets/images/metrics/clone_graph.png)
+
+If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+
+* Your project isn't successfully converting your audience, or
+* You're attracting the wrong audience
+
+For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+
+Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+
+Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+
+## Retention
+
+People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+
+It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+
+Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+
+Examples of community metrics that you may want to regularly track include:
+
+* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+
+![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+
+* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+
+* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+
+* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+
+* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
+  Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+  <p markdown="1" class="pquote-credit">
+— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+  </p>
+</aside>
+
+## Maintainer activity
+
+Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+
+Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+
+[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+
+Consider [tracking how long it takes for you (or another maintainer) to respond to contributions](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+
+You could also measure the time it takes to move between stages in the contribution process, such as:
+
+* Average time an issue remains open
+* Whether issues get closed by PRs
+* Whether stale issues get closed
+* Average time to merge a pull request
+
+## Use 📊 to learn about people
+
+Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+
+[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health.
diff --git a/_articles/pcm/starting-a-project.md b/_articles/pcm/starting-a-project.md
new file mode 100644
index 00000000000..15b01773ef7
--- /dev/null
+++ b/_articles/pcm/starting-a-project.md
@@ -0,0 +1,356 @@
+---
+lang: en
+title: Starting an Open Source Project
+description: Learn more about the world of open source and get ready to launch your own project.
+class: beginners
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+  - finding
+  - building
+---
+
+## The "what" and "why" of open source
+
+So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+
+### What does "open source" mean?
+
+When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+
+Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+
+_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+
+### Why do people open source their work?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+  One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+  <p markdown="1" class="pquote-credit">
+— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+  </p>
+</aside>
+
+[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+
+* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+
+* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+
+Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+
+### Does open source mean "free of charge"?
+
+One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+
+Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+
+As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+
+## Should I launch my own open source project?
+
+The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+
+If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+
+Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+
+If you're not yet convinced, take a moment to think about what your goals might be.
+
+### Setting your goals
+
+Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself,  _why am I open sourcing this project?_
+
+There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+
+If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+  At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+  <p markdown="1" class="pquote-credit">
+— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+  </p>
+</aside>
+
+As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+
+While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+
+**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+
+If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+  As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+  <p markdown="1" class="pquote-credit">
+— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+  </p>
+</aside>
+
+### Contributing to other projects
+
+If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+
+If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+
+## Launching your own open source project
+
+There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+
+Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+
+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/)
+* [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.
+
+If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+
+### Choosing a license
+
+An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+
+Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+
+[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 the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+
+When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+
+![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+
+If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+
+### Writing a README
+
+READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+
+In your README, try to answer the following questions:
+
+* What does this project do?
+* Why is this project useful?
+* How do I get started?
+* Where can I get more help, if I need it?
+
+You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+  Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+  <p markdown="1" class="pquote-credit">
+— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+  </p>
+</aside>
+
+Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+
+For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+
+When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+
+### Writing your contributing guidelines
+
+A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+
+* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
+* How to suggest a new feature
+* How to set up your environment and run tests
+
+In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+
+* The types of contributions you're looking for
+* Your roadmap or vision for the project
+* How contributors should (or should not) get in touch with you
+
+Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+
+For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+
+> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+
+In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+
+Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+
+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.
+
+![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+
+### Establishing a code of conduct
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+  We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+  <p markdown="1" class="pquote-credit">
+— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+  </p>
+</aside>
+
+Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+
+For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+
+In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+
+Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+
+Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+
+## Naming and branding your project
+
+Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+
+### Choosing the right name
+
+Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+
+* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
+* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+
+If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+
+Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+
+### Avoiding name conflicts
+
+[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+
+If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+
+Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+
+You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+
+Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+
+### How you write (and code) affects your brand, too!
+
+Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+
+Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+  <p markdown="1" class="pquote-credit">
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+
+Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+
+It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+
+## 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.
+
+**Documentation**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Project has a LICENSE file with an open source license
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    The issue queue is up-to-date, with issues clearly organized and labeled
+  </label>
+</div>
+
+**Code**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Project uses consistent code conventions and clear function/method/variable names
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    The code is clearly commented, documenting intentions and edge cases
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+  </label>
+</div>
+
+**People**
+
+If you're an individual:
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  </label>
+</div>
+
+If you're a company or organization:
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    You've talked to your legal department
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    You have a marketing plan for announcing and promoting the project
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    At least two people have administrative access to the project
+  </label>
+</div>
+
+## You did it!
+
+Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.

From 61402398873891ee73586a1a772cbea571038e26 Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Fri, 12 Jan 2024 18:18:44 -0800
Subject: [PATCH 641/749] More updates for test failures

- The missing `index.html` in this directory was preventing
  the site build from completely working
- Renamed Internal anchor links like `#sabi-to-say-no` to match
  the new section header names
- I'd blithely copied the untranslated files in but not changed
  their front matter to match the directory name
---
 _articles/pcm/building-community.md                       | 8 ++++----
 _articles/pcm/getting-paid.md                             | 2 +-
 _articles/pcm/how-to-contribute.md                        | 2 +-
 _articles/pcm/index.html                                  | 6 ++++++
 _articles/pcm/leadership-and-governance.md                | 2 +-
 _articles/pcm/legal.md                                    | 2 +-
 .../maintaining-balance-for-open-source-maintainers.md    | 2 +-
 _articles/pcm/metrics.md                                  | 2 +-
 _articles/pcm/starting-a-project.md                       | 2 +-
 9 files changed, 17 insertions(+), 11 deletions(-)
 create mode 100644 _articles/pcm/index.html

diff --git a/_articles/pcm/building-community.md b/_articles/pcm/building-community.md
index 1db3fef4f81..273a14338c8 100644
--- a/_articles/pcm/building-community.md
+++ b/_articles/pcm/building-community.md
@@ -1,5 +1,5 @@
 ---
-lang: pidgin
+lang: pcm
 title: Na Welcoming Communities we go Build
 description: Make you build one community wey go encourage people make them use, contribute, and promote your project.
 class: building
@@ -35,7 +35,7 @@ Start with your documentation:
 * **When new person land for your project, thank them for their interest!** E fit just take one bad experience for person to no wan come back again.
 * **Be responsive.** If you no respond to their issue for one month, e possible say them don forget your project.
 * **Open mind about the types of contributions wey you go accept.** Many contributors start with one bug report or one small fix. Many ways dey to contribute to one project. Make people fit help the way wey them wan help.
-* **If one person submit one contribution wey you no gree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) e no follow your project scope, and you fit add link to the relevant documentation wey you get.
+* **If one person submit one contribution wey you no gree with,** thank them for their idea and [explain why](../best-practices/#sabi-to-say-no) e no follow your project scope, and you fit add link to the relevant documentation wey you get.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -119,7 +119,7 @@ Do your best make you get zero-tolerance policy for these kind people. If you no
 
 Regular debates on top small-small parts of your project dey distract others, and even you, from focusing on important work. New people wey show for your project fit see these arguments and no wan join.
 
-Any time you see bad behavior wey dey happen for your project, yan am out for public. Explain, with kind but firm words, why their behavior no good. If the problem no stop, you fit need [tell them make dem waka](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) fit be useful guide for these talks.
+Any time you see bad behavior wey dey happen for your project, yan am out for public. Explain, with kind but firm words, why their behavior no good. If the problem no stop, you fit need [tell them make dem waka](../code-of-conduct/#how-you-go-take-think-your-code-of-conduct-to-stand-gidi-gba). Your [code of conduct](../code-of-conduct/) fit be useful guide for these talks.
 
 ### Meet contributors where dem dey
 
@@ -181,7 +181,7 @@ Aside small-small issues wey e clear say your community go fit resolve, sometime
 
 When your community dey tackle one yeye issue, tempers fit dey rise. People fit vex or feel frustrated and dem fit they chook mouth for each other or for your matter.
 
-Your work as maintainer na to make sure say these situations no go high. Even if you get strong opinion on top the matter, try play moderator or facilitator role, no just enter the matter dey force your views. If person no dey polite or e dey use mouth scatter discussions, [take action immediately](../building-community/#dont-tolerate-bad-actors) to make sure say discussions dey civil and productive.
+Your work as maintainer na to make sure say these situations no go high. Even if you get strong opinion on top the matter, try play moderator or facilitator role, no just enter the matter dey force your views. If person no dey polite or e dey use mouth scatter discussions, [take action immediately](../building-community/#no-dey-tolerate-bad-actors) to make sure say discussions dey civil and productive.
 
 Other people dey look you for guidance. Set example wey go make sense. You fit still yan your disappointment, sorrow or concern, but do am calmly.
 
diff --git a/_articles/pcm/getting-paid.md b/_articles/pcm/getting-paid.md
index 7fd4a32af4c..4328312ce7f 100644
--- a/_articles/pcm/getting-paid.md
+++ b/_articles/pcm/getting-paid.md
@@ -1,5 +1,5 @@
 ---
-lang: en
+lang: pcm
 title: Getting Paid for Open Source Work
 description: Sustain your work in open source by getting financial support for your time or your project.
 class: getting-paid
diff --git a/_articles/pcm/how-to-contribute.md b/_articles/pcm/how-to-contribute.md
index 196c21f34d4..95dcfc18df4 100644
--- a/_articles/pcm/how-to-contribute.md
+++ b/_articles/pcm/how-to-contribute.md
@@ -1,5 +1,5 @@
 ---
-lang: en
+lang: pcm
 title: How to Contribute to Open Source
 description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans.
 class: contribute
diff --git a/_articles/pcm/index.html b/_articles/pcm/index.html
new file mode 100644
index 00000000000..9ff1f730254
--- /dev/null
+++ b/_articles/pcm/index.html
@@ -0,0 +1,6 @@
+---
+layout: index
+title: Open Source Guides
+lang: pcm
+permalink: /pcm/
+---
diff --git a/_articles/pcm/leadership-and-governance.md b/_articles/pcm/leadership-and-governance.md
index 6fd75930d5d..13d07b1ae5f 100644
--- a/_articles/pcm/leadership-and-governance.md
+++ b/_articles/pcm/leadership-and-governance.md
@@ -1,5 +1,5 @@
 ---
-lang: en
+lang: pcm
 title: Leadership and Governance
 description: Growing open source projects can benefit from formal rules for making decisions.
 class: leadership
diff --git a/_articles/pcm/legal.md b/_articles/pcm/legal.md
index 30d391b2f76..7af472bef30 100644
--- a/_articles/pcm/legal.md
+++ b/_articles/pcm/legal.md
@@ -1,5 +1,5 @@
 ---
-lang: en
+lang: pcm
 title: The Legal Side of Open Source
 description: Everything you've ever wondered about the legal side of open source, and a few things you didn't.
 class: legal
diff --git a/_articles/pcm/maintaining-balance-for-open-source-maintainers.md b/_articles/pcm/maintaining-balance-for-open-source-maintainers.md
index c418b476786..f9be84228e5 100644
--- a/_articles/pcm/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pcm/maintaining-balance-for-open-source-maintainers.md
@@ -1,5 +1,5 @@
 ---
-lang: en
+lang: pcm
 untranslated: true
 title: Maintaining Balance for Open Source Maintainers
 description: Tips for self-care and avoiding burnout as a maintainer.
diff --git a/_articles/pcm/metrics.md b/_articles/pcm/metrics.md
index 145dd18119b..4a3142522e7 100644
--- a/_articles/pcm/metrics.md
+++ b/_articles/pcm/metrics.md
@@ -1,5 +1,5 @@
 ---
-lang: en
+lang: pcm
 title: Open Source Metrics
 description: Make informed decisions to help your open source project thrive by measuring and tracking its success.
 class: metrics
diff --git a/_articles/pcm/starting-a-project.md b/_articles/pcm/starting-a-project.md
index 15b01773ef7..a63ac866d45 100644
--- a/_articles/pcm/starting-a-project.md
+++ b/_articles/pcm/starting-a-project.md
@@ -1,5 +1,5 @@
 ---
-lang: en
+lang: pcm
 title: Starting an Open Source Project
 description: Learn more about the world of open source and get ready to launch your own project.
 class: beginners

From 5fc488fdabd0ea33b744913886a8825ba3c973f7 Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Fri, 12 Jan 2024 18:25:16 -0800
Subject: [PATCH 642/749] One last test failure

Weird, this one didn't come up locally
---
 _articles/pcm/building-community.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/pcm/building-community.md b/_articles/pcm/building-community.md
index 273a14338c8..b4dda5686fc 100644
--- a/_articles/pcm/building-community.md
+++ b/_articles/pcm/building-community.md
@@ -85,7 +85,7 @@ Even if you no fit review the request immediately, acknowledge am early to help
 
 A Mozilla study talk say if dem review code within 48 hours, plenty contributors dey return and contribute again.
 
-Any talku talku about your project fit dey happen for other places online like Stack Overflow, Twitter, or Reddit. You fit set notification for some of these places so dem go alert you if person talk about your project.
+Any talku-talku about your project fit dey happen for other places online like Stack Overflow, Twitter, or Reddit. You fit set notification for some of these places so dem go alert you if person talk about your project.
 
 ### Make you create one place where your community go gather
 
@@ -175,7 +175,7 @@ As your project dey begin, e dey easy to make major decisions. When you wan do s
 
 As your project dey popular, more people go dey chook eye for the decisions wey you dey take. Even if you no get big community of contributors, if your project get many users, people go wan add their mouth for the decisions or raise their own issues.
 
-Aside small-small issues wey e clear say your community go fit resolve, sometimes you fit see say one issue dey tough small small.
+Aside small-small issues wey e clear say your community go fit resolve, sometimes you fit see say one issue dey tough small-small.
 
 ### Arrange everything make kindness dey
 

From b8a99464581047c2c8a2732eb3cda8a8d886b231 Mon Sep 17 00:00:00 2001
From: TheGatesDev <69715898+thegatesdev@users.noreply.github.com>
Date: Thu, 25 Jan 2024 09:27:55 +0000
Subject: [PATCH 643/749] Fix missing text

Fix incorrect sentence missing text
---
 _articles/legal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/legal.md b/_articles/legal.md
index 30d391b2f76..f0727ca1200 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -67,7 +67,7 @@ Dependencies with **copyleft licenses** require closer attention. Including any
 You may also want to consider the **communities** you hope will use and contribute to your project:
 
 * **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
-* **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) (and them) covered.
+* **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
 * **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
 
 Your **company** may have policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance.

From 3abc58ae70d1e6b99aa9aeb70ff3692c88b2c91a Mon Sep 17 00:00:00 2001
From: Mathu-lmn <80094438+Mathu-lmn@users.noreply.github.com>
Date: Mon, 29 Jan 2024 21:13:11 +0100
Subject: [PATCH 644/749] fix(starting-a-project) : unknown link

---
 _articles/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/starting-a-project.md b/_articles/starting-a-project.md
index 15b01773ef7..b2e49d630af 100644
--- a/_articles/starting-a-project.md
+++ b/_articles/starting-a-project.md
@@ -46,7 +46,7 @@ Open source isn't just for software, either. You can open source everything from
 
 One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
 
-Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+Because [an open source license requires](https://opensource.org/definition-annotated/) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
 
 As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
 

From fb87ef44ed35e14640ec55c845c22c2808d456a1 Mon Sep 17 00:00:00 2001
From: cxhello <49056040+cxhello@users.noreply.github.com>
Date: Wed, 7 Feb 2024 15:18:20 +0800
Subject: [PATCH 645/749] Update building-community.md

---
 _articles/zh-hans/building-community.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/zh-hans/building-community.md b/_articles/zh-hans/building-community.md
index 1e0591f409e..67504dafbb1 100644
--- a/_articles/zh-hans/building-community.md
+++ b/_articles/zh-hans/building-community.md
@@ -39,7 +39,7 @@ redirect_from: /zh-cn/building-community/
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  为开源做贡献对一些人来说很简单，但对另外一些人可能就不是这样了。有很多人因为没有做正确的事而害怕叫喊，或者只是不适合。（。。。）通过允许贡献者参与一些对技术要求比较低的工作（文档，web content markdown，etc），可以极大的减少你对这些情况的关注。
+  对一些人来说，为开源做贡献比其他人更容易。有很多人害怕因为做得不对或不合群而被骂。这些情感需求是项目最难解决的问题，但通过为贡献者提供一个技术熟练度很低的贡献空间（文档、网页内容标记等），可以大大减少这些担忧。
   <p markdown="1" class="pquote-credit">
 — @mikeal, ["现代开源项目下如何增长贡献者"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
   </p>

From 2160c642828a569c1504081f5be495ba9f916bf6 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Mon, 25 Mar 2024 15:48:11 +0100
Subject: [PATCH 646/749] create folder with bulgarian language and translated
 best-practices documet

---
 .vs/VSWorkspaceState.json                     |   7 +
 .vs/opensource.guide/v17/.wsuo                | Bin 0 -> 11264 bytes
 .vs/opensource.guide/v17/DocumentLayout.json  |  12 +
 _articles/bg/best-practices.md                | 280 ++++++++++
 _articles/bg/building-community.md            | 276 +++++++++
 _articles/bg/code-of-conduct.md               | 114 ++++
 _articles/bg/finding-users.md                 | 148 +++++
 _articles/bg/getting-paid.md                  | 178 ++++++
 _articles/bg/how-to-contribute.md             | 526 ++++++++++++++++++
 _articles/bg/index.html                       |   6 +
 _articles/bg/leadership-and-governance.md     | 156 ++++++
 _articles/bg/legal.md                         | 160 ++++++
 ...ing-balance-for-open-source-maintainers.md | 220 ++++++++
 _articles/bg/metrics.md                       | 128 +++++
 _articles/bg/starting-a-project.md            | 356 ++++++++++++
 _data/locales/bg.yml                          |  31 ++
 16 files changed, 2598 insertions(+)
 create mode 100644 .vs/VSWorkspaceState.json
 create mode 100644 .vs/opensource.guide/v17/.wsuo
 create mode 100644 .vs/opensource.guide/v17/DocumentLayout.json
 create mode 100644 _articles/bg/best-practices.md
 create mode 100644 _articles/bg/building-community.md
 create mode 100644 _articles/bg/code-of-conduct.md
 create mode 100644 _articles/bg/finding-users.md
 create mode 100644 _articles/bg/getting-paid.md
 create mode 100644 _articles/bg/how-to-contribute.md
 create mode 100644 _articles/bg/index.html
 create mode 100644 _articles/bg/leadership-and-governance.md
 create mode 100644 _articles/bg/legal.md
 create mode 100644 _articles/bg/maintaining-balance-for-open-source-maintainers.md
 create mode 100644 _articles/bg/metrics.md
 create mode 100644 _articles/bg/starting-a-project.md
 create mode 100644 _data/locales/bg.yml

diff --git a/.vs/VSWorkspaceState.json b/.vs/VSWorkspaceState.json
new file mode 100644
index 00000000000..6fd1a26c67b
--- /dev/null
+++ b/.vs/VSWorkspaceState.json
@@ -0,0 +1,7 @@
+{
+  "ExpandedNodes": [
+    ""
+  ],
+  "SelectedNode": "\\C:\\Users\\Dsvk2\\Source\\Repos\\opensource.guide",
+  "PreviewInSolutionExplorer": false
+}
\ No newline at end of file
diff --git a/.vs/opensource.guide/v17/.wsuo b/.vs/opensource.guide/v17/.wsuo
new file mode 100644
index 0000000000000000000000000000000000000000..bc44734735d78d8274f3789e26600d29bfeba576
GIT binary patch
literal 11264
zcmeHN%WoS+82_A7pgfxv0+b#s6jeE3%eB%bDWVD_Eg)f%)=7gzknk&y#xL1UOD~)`
za|gtYEB^xrPJ}ZjxbinZ&F?q6V~^Ln<Mlcv3Gqa`JMZ6oubFQ?=eL8&KYsY>(x2i<
zH|2~xZl9B<jry38m-8Yoq0G9+?RJ|@%p*HaCx`=grG~$j#O0P$@omT>iZXPXlCvF|
zpB*qNK6$Y8?N`6Yo=3mMXPnNfK&;7q`3UG+$la1J2h7sjJS7tye6qc_)xUHZ)lgrR
zG(K_bQpO4zQo@r3FLHQFZoi<<v`oZIaR>D?>t9CUXSZTS_JLBCUC_^G+dy7MO~V}M
zlPCUDsGq<Smj2h#SKBq$@{dUX@)z8>SWP}X>y}@@_eDIf;GxY^-u#}!cM=c#vph~G
zhXenm{h$Bq*N*+m5!(No(ABa1g9%7lQ@I~-AE5nSM4q-yyJng8&#$)s=TJtmFHxj@
zmE($I%>l~Q@1ZQc^_0I^M;qe4&-22px8;vDGfv^+vhaAy$_Lp+t}09Fy#>!>8?_DP
z134`avQK&&{)g!=_;l&3qW_R`YgZ%>?=J(ihKo&~i=Jpx?#X=LSZ~E!z^6Z{_atw-
zUzz(G{UxR)P@e-9(RP9Sux}Mkzo0k#ubw?GsGnI+`_ScOVCKQ;ZT!*i+)x}Z$PP+P
z-O2KeN5JR3jWS?*AM&oro>YL_z&EVl>x>q;4F2=p$FqXwqw8(o*U&iQc34x~-;<BQ
z{U)TI1?BX?TT)P3Ifw`Jf6rhpefHRJb=wp&Jkyxy_fz8<(77CR;WpM$R=n3YgA!KK
z3e<`l5%}LL|C*w-0!(WC2Jov=1P>m{D&9?$TX<-je!NJ5e(jTo<^QXo`<kL&#H)X#
zpZMGtX#WMQ%a*PHpZcWze_LPOM&4`v3&wv0oy=nuWj)OI3;aX1zYOTD0G0P(Qx<-_
z=Yp{R4UJD<Yt5y`OTU9jOK@(Y@8MQj$Not9QxjNgrt9E8<xZJ~l|Owu-Wi!p8Z)o}
zT7k0@C86{C$|h^z$OpisM%3jK^q{sn9JvYnH!u%vDl9(t3;GgFVe!|1PF<ia)D263
z{l&=7OL)TK6IbJBq2UEs8mW7Lxr?BzAxWkG=DC=}4pjr?MYR*`gHJ6^BcOk1`IBFI
z{}~3K=Tr+jHc#a$R=tCH79-%3S6cpA(94~lvr)^4a2Iv7d(wCZGABoPHa0uEG$wG<
zJn$JqU`!z_|IPi+CjV8SR`FK?*KaGTyLzYbq5nhkpR{ZF+wkux%3HA29CjjoLUBY9
zoY_%Y2>!=-pCs)}dR?|J&nvzE+3+`jK`E?2<M|~YyeS=le)>N8{!3dtjCAMg@2c(e
z-`@{AS0%Sw{bKH$3sJ}alBoPR%J^Z|`+w_CI~YX=MjcN*90i|t#PQuZ>We6bPNS|r
zG?1mEzKfV$MyWIBdD8iq!TBgy`W%WfmSZUQO*~6-1K)M*$vmx^$S>pl05_U6@}@Vt
zsm`~$I_oy^cJ|gLa@yZb!UNiOeF4sGOY}WHlh18ktZiMrwRQ_^r0?Icp*#xO7-j}h
zmc$LC3F<i@bmw&!;lmVe@aA8lQ?lpGG0Y!z;=LsUX*-@}7Uw#>p%!ZDu2*;;J>JEy
zp**$U>02)EQQU*33s-Xs*RSPLiP=&qotWKPC?@99bGbw@Uq}__W{YzRv*-(E_e%WJ
z14b^Qr|G^Md{g3xWstX5;m7iAOF^-^Cl&uA-Z&i}4vgbJr#t?W!D+aT9m5+3jvJ9M
z+x`(H{=)l`zJJ-~4%=p0Q`j+w+3zIdd*e?L;(zM@fQ~T!r{Z7ypAO0)j9kt5gO~o(
z7XS0o&*%~(LVNIkYAXKHGGc%IQBcGm6#p6156gf0tlH}dgWr$ZmGTVm>HjjG78aks
z7cq9m<i+Rj0gQds;R6Oo-JP*~GyY9now_Z-Inu7<e}4GRFJMI#?-{fn#(%k&Uc|#S
x1fzCa_*+d7{#gD)%U|*Rq{_edHqzCRVRKRAccaGtsQZjRQ}d(5A5VMy@LvEj-Gu-E

literal 0
HcmV?d00001

diff --git a/.vs/opensource.guide/v17/DocumentLayout.json b/.vs/opensource.guide/v17/DocumentLayout.json
new file mode 100644
index 00000000000..2ca93c51a7b
--- /dev/null
+++ b/.vs/opensource.guide/v17/DocumentLayout.json
@@ -0,0 +1,12 @@
+{
+  "Version": 1,
+  "WorkspaceRootPath": "C:\\Users\\Dsvk2\\Source\\Repos\\opensource.guide\\",
+  "Documents": [],
+  "DocumentGroupContainers": [
+    {
+      "Orientation": 0,
+      "VerticalTabListWidth": 256,
+      "DocumentGroups": []
+    }
+  ]
+}
\ No newline at end of file
diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md
new file mode 100644
index 00000000000..e705d93b01c
--- /dev/null
+++ b/_articles/bg/best-practices.md
@@ -0,0 +1,280 @@
+---
+lang: en
+title: Best Practices for Maintainers
+description: Making your life easier as an open source maintainer, from documenting processes to leveraging your community.
+class: best-practices
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+  - metrics
+  - leadership
+---
+
+## Какво означава да си поддържащ на код?
+
+Ако поддържате проект с отворен код, който много хора използват, може би сте забелязали, че кодирате по-малко и отговаряте повече на проблеми.
+
+В ранните етапи на проекта вие експериментирате с нови идеи и вземате решения въз основа на това, което искате. С нарастването на популярността на проекта ви ще откриете, че работите повече с вашите потребители и сътрудници.
+
+Поддържането на проект изисква повече от код. Тези задачи често са неочаквани, но са също толкова важни за разрастващ се проект. Събрахме няколко начина да улесним живота ви, от документиране на процеси до използване на вашата общност.
+
+## Документиране на вашите процеси
+
+Записването на нещата е едно от най-важните неща, които можете да направите като поддържащ на код.
+
+Документацията не само изяснява вашето собствено мислене, но помага на другите хора да разберат от какво се нуждаете или очаквате, преди дори да попитат.
+
+Записването на нещата ви улеснява да кажете „не“, когато нещо не се вписва в обхвата ви. Освен това улеснява хората да се включат и да помогнат. Никога не знаете кой може да чете или използва вашия проект.
+
+Дори и да не използвате пълни абзаци, писането на точки е по-добре, отколкото да не пишете изобщо.
+
+Не забравяй да поддържате документацията си актуална. Ако не можете винаги да правите това, изтрийте остарялата си документация или посочете, че е остаряла, така че участниците да знаят, че актуализациите са добре дошли.
+
+### Запишете визията на вашия проект
+
+Започнете, като напишете целите на вашия проект. Добавете ги към вашия README или създайте отделен файл, наречен VISION. Ако има други фактори, които биха могли да помогнат, като пътна карта на проекта, направете и тях публични.
+
+Наличието на ясна, документирана визия ви държи фокусирани и ви помага да избегнете „да не ви се изплъзне целта“ от приноса на другите.
+
+Например, @lord откри, че наличието на визия за проекта му помага да разбере на кои заявки да отдели време. Като нов поддържащ, той съжаляваше, че не се придържа към обхвата на проекта си, когато получи първата си заявка за функция [Slate](https://github.com/lord/slate).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
+  Опитах. Не положих необходимите усилия, за да изляза с цялостно решение. Вместо полуготово решение, бих искал да бях казал „Нямам време за това в момента, но ще добавя функционалността към изоставането, което ще бъде разработено в бъдеще“.
+  <p markdown="1" class="pquote-credit">
+— @lord, ["Съвети за нови поддържащи отворен код"](https://lord.io/blog/2014/oss-tips/)
+  </p>
+</aside>
+
+### Съобщете вашите очаквания
+
+Записването на правила може да бъде изнервящо. Понякога може да се чувствате така, сякаш контролирате поведението на другите хора или убивате цялото забавление.
+
+Въпреки това, написани и приложени справедливо, добрите правила дават възможност на поддържащите кода. Те ви предпазват от това да бъдете въвлечени в неща, които не искате да правите..
+
+Повечето хора, които срещат вашия проект, не знаят нищо за вас или вашите обстоятелства. Те може да приемат, че ви е платено да работите по него, особено ако това е нещо, което те използват и от което зависят редовно. Може би в един момент сте отделили много време за проекта си, но сега сте заети с нова работа или член на семейството.
+
+Всичко това е напълно наред! Просто се уверете, че другите хора знаят за това.
+
+Независимо дали поддържането на вашия проект е на непълно работно време или просто доброволчество, бъдете честни с колко време разполагате. Това не е същото като колко време смятате, че изисква проектът или колко време другите искат да отделите.
+
+Ето някои правила, които си струва да имате предвид:
+
+* Как се преглежда и приема принос (_Имат ли нужда от тестове? Шаблон за проблем?_)
+* Типовете приноси, които ще приемете (_Искате ли помощ само за определена част от вашия код?_)
+* Когато е уместно да се проследи (_например, „Можете да очаквате отговор от поддържащия в рамките на 7 дни. Ако не сте чули нищо дотогава, не се колебайте да пингвате темата.“_)
+* Колко време отделяте за проекта (_например, „Прекарваме само около 5 часа на седмица в този проект“_)
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) са някои примери за проекти с ясни правила за поддържащите и сътрудниците.
+
+### Поддържайте публична комуникация
+
+Не забравяйте да документирате и вашите взаимодействия. Където можете, поддържайте публична комуникация относно вашия проект. Ако някой се опита да се свърже с вас насаме, за да обсъдите заявка за функция или нужда от поддръжка, учтиво го насочете към публичен комуникационен канал, като пощенски списък или инструмент за проследяване на проблеми.
+
+Ако се срещнете с други поддържащи или вземете важни решения насаме, документирайте тези разговори публично, дори ако просто публикувате бележките си.
+
+По този начин всеки, който се присъедини към вашата общност, ще има достъп до същата информация като някой, който е бил там от години.
+
+## Да се ​​научим да казваме не
+
+Вие сте записали нещата. В идеалния случай всеки ще прочете вашата документация, но в действителност ще трябва да напомните на другите, че това знание съществува.
+
+Записването на всичко обаче помага да се обезличи ситуациите, когато трябва да наложите правилата си.
+
+Да кажете „не“ не е забавно, но „Вашият принос не отговаря на критериите за този проект“ изглежда по-малко лично от „Не харесвам вашия принос“.
+
+Казването на „не“ се отнася за много ситуации, с които ще се сблъскате като поддържащ код: заявки за функции, които не отговарят на обхвата, някой дерайлира дискусия, върши ненужна работа за други.
+
+### Поддържайте разговора приятелски
+
+Едно от най-важните места, където ще се упражнявате да казвате „не“, е във вашите проблеми и опашката за изтегляне на заявки. Като ръководител на проекта вие неизбежно ще получите предложения, които не искате да приемете.
+
+Може би приносът променя обхвата на вашия проект или не отговаря на вашата визия. Може би идеята е добра, но изпълнението е лошо.
+
+Независимо от причината е възможно да се справите тактично с приноси, които не отговарят на стандартите на вашия проект.
+
+Ако получите принос, който не искате да приемете, първата ви реакция може да бъде да го игнорирате или да се престорите, че не сте го видели. Това може да нарани чувствата на другия човек и дори да демотивира други потенциални сътрудници във вашата общност.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
+  Ключът към управлението на поддръжката за широкомащабни проекти с отворен код е проблемите да се движат. Опитайте се да избегнете все още проблеми. Ако сте разработчик на iOS, знаете колко разочароващо може да бъде изпращането на радари. Може да получите някои новини две години по-късно и те ще бъдат помолени да опитат отново с най-новата версия на iOS.
+  <p markdown="1" class="pquote-credit">
+— @KrauseFx, ["Мащабиране на общности с отворен код"](https://krausefx.com/blog/scaling-open-source-communities)
+  </p>
+</aside>
+
+Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.
+
+Най-добре е незабавно да затворите приноси, които знаете, че не искате да приемете. Ако вашият проект вече страда от голямо изоставане или списък с функции за внедряване, @steveklabnik има предложения за [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+
+Второ, игнорирането на приносите изпраща отрицателен сигнал към вашата общност. Приносът към проект може да бъде смущаващ, особено ако на някого е за първи път. Дори и да не приемете техния принос, поздравете човека зад него и му благодарете за проявения интерес. Това е страхотен комплимент!
+
+Ако не искате да приемете принос:
+
+* **Благодари им** за техния принос
+* **Обяснете защо не се вписва** в обхвата на проекта и предложете ясни предложения за подобрение, ако можете. Бъдете мили, но твърди.
+* **Връзка към съответната документация**, ако я имате. Ако забележите повтарящи се искания за неща, които не искате да приемете, добавете ги в документацията си, за да избегнете повтаряне.
+* **Затворете заявката**
+
+Не трябва да имате повече от 1-2 изречения, за да отговорите. Например, когато потребител на [целъри](https://github.com/celery/celery/) съобщи за грешка, свързана с Windows, @berkerpeksag [отговаря с](https://github.com/celery/celery/issues/3383):
+
+![Екрана снимка на целина](/assets/images/best-practices/celery.png)
+
+Ако мисълта да кажете „не“ ви ужасява, не сте сами. Като @jessfraz [казва](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> Говорил съм с поддържащи кодове от множество различни проекти с отворен код, Mesos, Kubernetes, Chromium, и всички те са съгласни, че една от най-трудните части да си поддържащ код е да кажеш „Не“ на пачове, които не работят.
+
+Не се чувствайте виновни, че не искате да приемете нечий принос. Първото правило на отворения код, [съгласно с](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Не е временно, да завинаги е."_ Въпреки че съпричастността към ентусиазма на друг човек е нещо добро, отхвърлянето на принос не е същото като отхвърлянето на човека зад него.
+
+В крайна сметка, ако даден принос не е достатъчно добър, не сте длъжни да го приемете. Бъдете мили и приемащи, когато хората допринасят за вашия проект, но приемайте само промени, които наистина вярвате, че ще направят проекта ви по-добър. Колкото по-често се упражнявате да казвате „не“, толкова по-лесно става. Това е обещание.
+
+### Бъди проактивен
+
+За да намалите обема на нежеланите приноси на първо място, обяснете процеса на вашия проект за подаване и приемане на приноси във вашето ръководство за приноси.
+
+Ако получавате твърде много приноси с ниско качество, изискайте от сътрудниците да свършат малко работа предварително, като например:
+
+* Попълнете проблем или PR шаблон/контролен списък
+* Отворете проблем, преди да изпратите PR
+
+Ако не спазват вашите правила, незабавно затворете проблема и ги насочете към вашата документация.
+
+Въпреки че този подход може да изглежда неприятен в началото, проактивността всъщност е добра и за двете страни. Намалете шанса някой да вложи много часове пропиляна работа в заявка за изтегляне, която няма да приемете. И прави работата ви по-лесна за управление.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+ В идеалния случай, обяснете им и във файл CONTRIBUTING.md как могат да получат по-добра индикация в бъдеще за това какво би или не би било прието, преди да започнат работата.
+  <p markdown="1" class="pquote-credit">
+— @MikeMcQuaid, ["Любезно затваряне на заявки за изтегляне"](https://github.com/blog/2124-kindly-closing-pull-requests)
+  </p>
+</aside>
+
+Понякога, когато кажете „не“, вашият потенциален сътрудник може да се разстрои или да критикува решението ви. Ако поведението им стане враждебно, [вземете мерки за обезвреждане на ситуацията](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или дори да ги премахнете от вашата общност, ако не желаят да си сътрудничат конструктивно.
+
+### Прегърнете менторството
+
+Може би някой във вашата общност редовно изпраща приноси, които не отговарят на стандартите на вашия проект. Може да бъде разочароващо и за двете страни многократното преминаване през процеса на отхвърляне.
+
+Ако видите, че някой е развълнуван от вашия проект, но има нужда от малко практика, бъдете търпеливи. Обяснете ясно във всяка ситуация защо вашият принос не отговаря на очакванията на проекта. Опитайте да им дадете по-лесна или по-малко двусмислена задача, като например проблем, отбелязан като „good first issue“, за да ги загреете. Ако имате време, обмислете да ги наставлявате чрез първия им принос или намерете някой друг във вашата общност, който е готов да ги наставлява.
+
+## Използвайте общността си
+
+Не е нужно да правите всичко сами. Вашата проектна общност съществува с причина! Дори ако все още нямате активна общност от сътрудници, ако имате много потребители, оставете ги да работят.
+
+### Споделете натоварването
+
+Ако търсите други да се присъединят, започнете, като разпитате наоколо.
+
+Един от начините да спечелите нови сътрудници е изрично [Проблемите с етикетирането са достатъчно прости за начинаещи](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки тяхната видимост.
+
+Когато видите нови сътрудници, които правят повторни приноси, признайте работата им, като предложите повече отчетност. Документирайте как другите могат да израснат в лидерски роли, ако решат.
+
+Насърчаване на другите да [споделят собствеността върху проекта](../building-community/#share-ownership-of-your-project) може значително да намали вашето работното натоварване, както @lmccart откри в своя проект, [p5.js](https://github.com/processing/p5.js).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
+  Казвах: „Да, всеки може да участва, не е необходимо да имате много опит в програмирането [...].“ Имахме хора, които се регистрираха [за събития] и тогава се запитах: вярно ли е това, какво казвах? Ще има 40 души, които ще се появят и не е като да мога да седя с всеки един от тях... Но хората се събраха и се получи. Щом човек го получи, той може да учи съседите си.
+  <p markdown="1" class="pquote-credit">
+—  @lmccart, ["Какво изобщо означава „отворен код“? p5.js Издание"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+  </p>
+</aside>
+
+Ако трябва да се оттеглите от проекта си, независимо дали временно или за постоянно, не е срамно да помолите някой друг да поеме вместо вас.
+
+Ако други хора са ентусиазирани относно посоката на проекта, дайте им разрешение да се ангажират или официално предайте контрола на някой друг. Ако някой разклони вашия проект и го поддържа активно другаде, помислете за свързване на разклонението от оригиналния ви проект. Страхотно е, че толкова много хора искат вашият проект да се развива!
+
+@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) документира визията за своя проект, [Dokku](https://github.com/dokku/dokku), помогна на тези цели да продължат да съществуват дори след като се оттегли от проекта:
+
+> Написах уики страница, описваща какво искам и защо го искам. По някаква причина за мен беше изненада, че поддържащите започнаха да движат проекта в тази посока! Случи ли се точно както бих го направил? Не винаги. Но все пак доближи проекта до това, което записах.
+
+### Оставете другите да създават решенията, от които се нуждаят
+
+Ако потенциален сътрудник има различно мнение за това какво трябва да направи вашият проект, може да искате внимателно да го насърчите да работи върху собствената си вилица.
+
+Разклоняването на проект не трябва да е нещо лошо. Да можеш да копираш и модифицираш проекти е едно от най-добрите неща на отворения код. Насърчаването на членовете на вашата общност да работят върху собствената си вилица може да осигури творческия изход, от който се нуждаят, без да противоречи на визията на вашия проект.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
+  Обслужвам случая на 80% употреба. Ако сте един от еднорозите, моля, разклонете работата ми. Няма да се обидя! Моите обществени проекти почти винаги са предназначени да решават най-често срещаните проблеми; Опитвам се да улесня задълбочаването, като разклонявам работата си или я разширявам.
+  <p markdown="1" class="pquote-credit">
+— @geerlingguy, ["Защо затварям PR-и"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+  </p>
+</aside>
+
+Същото важи и за потребител, който наистина иска решение, което вие просто нямате възможност да създадете. Предлагането на адаптивни API и hooks може да помогне на другите да посрещнат собствените си нужди, без да се налага директно да променят източника. @orta [установи, че](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) насърчаването на плъгини за CocoaPods доведе до "някои от най-интересните идеи":
+
+> Почти неизбежно е след като проектът стане голям, поддържащите трябва да станат много по-консервативни по отношение на това как въвеждат нов код. Вие ставате добри в това да казвате „не“, но много хора имат законни нужди. Така вместо това в крайна сметка преобразувате своя инструмент в платформа.
+
+## Доведете роботите
+
+Точно както има задачи, с които други хора могат да ви помогнат, има и задачи, които никой човек никога не трябва да изпълнява. Роботите са ваши приятели. Използвайте ги, за да улесните живота си като поддържащ.
+
+### Изисквайте тестове и други проверки, за да подобрите качеството на вашия код
+
+Един от най-важните начини, по които можете да автоматизирате проекта си, е чрез добавяне на тестове.
+
+Тестовете помагат на сътрудниците да се чувстват уверени, че няма да нарушат нищо. Те също така ви улесняват да преглеждате и бързо приемате приноси. Колкото по-отзивчиви сте, толкова по-ангажирана може да бъде вашата общност.
+
+Настройте автоматични тестове, които ще се изпълняват на всички входящи приноси, и се уверете, че вашите тестове могат лесно да се изпълняват локално от сътрудниците. Изисквайте всички приноси на код да преминат вашите тестове, преди да могат да бъдат изпратени. Вие ще помогнете да се определи минимален стандарт за качество за всички изпратени документи. [Необходими проверки на състоянието](https://help.github.com/articles/about-required-status-checks/) в GitHub може да ви помогне да гарантирате, че нито една промяна не се обединява, без вашите тестове да преминат.
+
+Ако добавяте тестове, не забравяйте да обясните как работят във вашия CONTRIBUTING файл.
+
+<aside markdown="1" class="pquote">
+  <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)
+  </p>
+</aside>
+
+### Използвайте инструменти за автоматизиране на основните задачи по поддръжката
+
+Добрата новина за поддържането на популярен проект е, че други поддържащи вероятно са се сблъсквали с подобни проблеми и са създали решение за тях.
+
+Има [различни налични инструменти](https://github.com/showcases/tools-for-open-source), които да помогнат за автоматизирането на някои аспекти на работата по поддръжката. Няколко примера:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) автоматизира вашите издания
+* [mention-bot](https://github.com/facebook/mention-bot) споменава потенциални рецензенти за заявки за изтегляне
+* [Danger](https://github.com/danger/danger) помага за автоматизирането на прегледа на кода
+* [no-response](https://github.com/probot/no-response) затваря въпроси, при които авторът не е отговорил на искане за повече информация
+* [dependabot](https://github.com/dependabot) проверява вашите файлове за зависимости всеки ден за остарели изисквания и отваря индивидуални заявки за изтегляне за всяко, което открие
+
+За доклади за грешки и други общи приноси GitHub има [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), които можете да създадете, за да рационализирате комуникацията, която получавате. @TalAter създаде [Изберете свое собствено ръководство за приключение](https://www.talater.com/open-source-templates/#/) за да ви помогне да напишете вашия проблем и PR шаблони.
+
+За да управлявате вашите имейл известия, можете да настроите [имейл филтри](https://github.com/blog/2203-email-updates-about-your-own-activity), за да организирате по приоритет.
+
+Ако искате да станете малко по-напреднали, ръководствата за стилове и линтерите могат да стандартизират приноса на проекти и да ги направят по-лесни за преглед и приемане.
+
+Въпреки това, ако вашите стандарти са твърде сложни, те могат да увеличат бариерите пред приноса. Уверете се, че добавяте достатъчно правила, за да улесните живота на всички.
+
+Ако не сте сигурни кои инструменти да използвате, вижте какво правят други популярни проекти, особено тези във вашата екосистема. Например, как изглежда процесът на принос за други модули на Node? Използването на подобни инструменти и подходи също така ще направи вашия процес по-познат на вашите сътрудници.
+
+## Добре е да натиснете пауза
+
+Работата с отворен код някога ви е носила радост. Може би сега започва да ви кара да се чувствате отбягващи или виновни.
+
+Може би се чувствате претоварени или нарастващо чувство на страх, когато мислите за вашите проекти. И междувременно проблемите и заявките за изтегляне се натрупват.
+
+Измореностa е реален и широко разпространен проблем в работата с отворен код, особено сред поддържащите. Като поддържащ, вашето щастие е неподлежащо на обсъждане изискване за оцеляването на всеки проект с отворен код.
+
+Въпреки че трябва да се разбира от само себе си, вземете си почивка! Не трябва да чакате, като се почувствате изморени, за да си вземете ваканция. @brettcannon, разработчик на ядрото на Python, реши да си вземе [едномесечна ваканция](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) след 14 години доброволен OSS работа.
+
+Точно както всеки друг вид работа, правенето на редовни почивки ще ви държи освежени, щастливи и развълнувани от работата ви.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
+  При поддържането на WP-CLI открих, че първо трябва да направя себе си щастлив и да поставя ясни граници на моето участие. Най-добрият баланс, който открих, е 2-5 часа седмично като част от нормалния ми работен график. Това поддържа участието ми като страст и не го усещам като работа. Тъй като приоритизирам проблемите, по които работя, мога редовно да напредвам в това, което смятам за най-важно.
+  <p markdown="1" class="pquote-credit">
+— @danielbachhuber, ["Моите съболезнования, сега сте поддържащият популярен проект с отворен код"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+  </p>
+</aside>
+
+Понякога може да е трудно да си вземете почивка от работата с отворен код, когато чувствате, че всички се нуждаят от вас. Хората може дори да се опитат да ви накарат да се чувствате виновни, че сте се отдръпнали.
+
+Направете всичко възможно, за да намерите поддръжка за вашите потребители и общност, докато сте далеч от даден проект. Ако не можете да намерите подкрепата, от която се нуждаете, все пак си направете почивка. Не забравяйте да общувате, когато не сте на разположение, така че хората да не бъдат объркани от липсата ви на отзивчивост.
+
+Правенето на почивки се отнася и за нещо повече от ваканции. Ако не искате да работите с отворен код през почивните дни или по време на работното време, съобщете тези очаквания на другите, за да знаят, че няма да ви притесняват.
+
+## Погрижете се първо за себе си!
+
+Поддържането на популярен проект изисква различни умения от по-ранните етапи на растеж, но не е по-малко възнаграждаващо. Като поддържащ, вие ще практикувате лидерство и лични умения на ниво, което малко хора могат да изпитат. Въпреки че не винаги е лесно да се управлява, поставянето на ясни граници и поемането само на това, което ви харесва, ще ви помогне да останете щастливи, освежени и продуктивни.
\ No newline at end of file
diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
new file mode 100644
index 00000000000..90d73dd6eda
--- /dev/null
+++ b/_articles/bg/building-community.md
@@ -0,0 +1,276 @@
+---
+lang: en
+title: Building Welcoming Communities
+description: Building a community that encourages people to use, contribute to, and evangelize your project.
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+  - best-practices
+  - coc
+---
+
+## Setting your project up for success
+
+You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around?
+
+A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back.
+
+### Make people feel welcome
+
+One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+
+As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more.
+
+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.
+
+[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.
+
+* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
+* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
+* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or a small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
+* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+  </p>
+</aside>
+
+The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute.
+
+Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself.
+
+### Document everything
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
+  <p markdown="1" class="pquote-credit">
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public.
+
+When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed.
+
+Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public.
+
+Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions.
+
+If you notice multiple users running into the same problem, document the answers in the README.
+
+For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you.
+
+Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on.
+
+### Be responsive
+
+As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started.
+
+Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating.
+
+Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466):
+
+![Middleman pull request](/assets/images/building-community/middleman_pr.png)
+
+[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution.
+
+Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project.
+
+### Give your community a place to congregate
+
+There are two reasons to give your community a place to congregate.
+
+The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate.
+
+The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel.
+
+Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above!
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members:
+
+> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.
+
+Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address.
+
+## Growing your community
+
+Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction.
+
+### Don't tolerate bad actors
+
+Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others.
+
+Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
+  The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.
+  <p markdown="1" class="pquote-credit">
+— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+  </p>
+</aside>
+
+Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
+
+When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations.
+
+### Meet contributors where they're at
+
+Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need.
+
+In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors.
+
+![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
+
+In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started.
+
+Finally, use your documentation to make people feel welcome at every step of the way.
+
+You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration.
+
+For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
+
+### Share ownership of your project
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
+  Your leaders will have different opinions, as all healthy communities should! However, you need to take steps to ensure the loudest voice doesn't always win by tiring people out, and that less prominent and minority voices are heard.
+  <p markdown="1" class="pquote-credit">
+— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+  </p>
+</aside>
+
+People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around.
+
+See if you can find ways to share ownership with your community as much as possible. Here are some ideas:
+
+* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself.
+
+![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
+
+* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
+
+* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+
+* **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.
+
+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.
+
+While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
+  \[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it.
+  <p markdown="1" class="pquote-credit">
+— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+  </p>
+</aside>
+
+## Resolving conflicts
+
+In the early stages of your project, making major decisions is easy. When you want to do something, you just do it.
+
+As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own.
+
+For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address.
+
+### Set the bar for kindness
+
+When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you.
+
+Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
+  As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
+  <p markdown="1" class="pquote-credit">
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+  </p>
+</aside>
+
+Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly.
+
+Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you.
+
+### Treat your README as a constitution
+
+Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion.
+
+### Focus on the journey, not the destination
+
+Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns.
+
+Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place.
+
+Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus.
+
+Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
+  Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
+  <p markdown="1" class="pquote-credit">
+— @lee-dohm on Atom's decision making process
+  </p>
+</aside>
+
+Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions.
+
+Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution.
+
+### Keep the conversation focused on action
+
+Discussion is important, but there is a difference between productive and unproductive conversations.
+
+Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down.
+
+Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues.
+
+With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_
+
+If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation.
+
+If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+  </p>
+</aside>
+
+### Pick your battles wisely
+
+Context is important. Consider who is involved in the discussion and how they represent the rest of the community.
+
+Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices.
+
+If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread.
+
+### Identify a community tiebreaker
+
+With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker.
+
+A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it.
+
+Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible.
+
+## Community is the ❤️ of open source
+
+Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience.
diff --git a/_articles/bg/code-of-conduct.md b/_articles/bg/code-of-conduct.md
new file mode 100644
index 00000000000..3c3d187ae79
--- /dev/null
+++ b/_articles/bg/code-of-conduct.md
@@ -0,0 +1,114 @@
+---
+lang: en
+title: Your Code of Conduct
+description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct.
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+  - building
+  - leadership
+---
+
+## Why do I need a code of conduct?
+
+A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.
+
+Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.
+
+A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with.
+
+## Establishing a code of conduct
+
+Try to establish a code of conduct as early as possible: ideally, when you first create your project.
+
+In addition to communicating your expectations, a code of conduct describes the following:
+
+* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_
+* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_
+* What happens if someone violates the code of conduct
+* How someone can report violations
+
+Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
+
+The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples.
+
+Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
+
+## Deciding how you'll enforce your code of conduct
+
+<aside markdown="1" class="pquote">
+  A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
+  <p markdown="1" class="pquote-credit">
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+  </p>
+</aside>
+
+You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:
+
+* It demonstrates that you are serious about taking action when it's needed.
+
+* Your community will feel more reassured that complaints actually get reviewed.
+
+* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.
+
+You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
+
+Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+
+For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+
+## Enforcing your code of conduct
+
+Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up.
+
+### Gather information about the situation
+
+Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment.
+
+The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context.
+
+Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
+
+<aside markdown="1" class="pquote">
+  Don’t get pulled into an argument. Don’t get sidetracked into dealing with someone else’s behavior before you’ve finished dealing with the matter at hand. Focus on what you need.
+  <p markdown="1" class="pquote-credit">
+— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+  </p>
+</aside>
+
+### Take appropriate action
+
+After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward.
+
+When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise.
+
+There are a few ways you might respond to a code of conduct violation:
+
+* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication.
+
+* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them.
+
+Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example:
+
+* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project
+
+* **Permanently ban** the person from the project
+
+Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached.
+
+## Your responsibilities as a maintainer
+
+A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes.
+
+As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community.
+
+A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable.
+
+In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way.
+
+## Encourage the behavior you want to see in the world 🌎
+
+When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow.
diff --git a/_articles/bg/finding-users.md b/_articles/bg/finding-users.md
new file mode 100644
index 00000000000..61e7b3e98ff
--- /dev/null
+++ b/_articles/bg/finding-users.md
@@ -0,0 +1,148 @@
+---
+lang: en
+title: Finding Users for Your Project
+description: Help your open source project grow by getting it in the hands of happy users.
+class: finding
+order: 3
+image: /assets/images/cards/finding.png
+related:
+  - beginners
+  - building
+---
+
+## Spreading the word
+
+There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work!
+
+## Figure out your message
+
+Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters.
+
+What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance.
+
+Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want.
+
+For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
+
+![Cartography README](/assets/images/finding-users/cartography.jpg)
+
+For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+
+## Help people find and follow your project
+
+<aside markdown="1" class="pquote">
+  You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
+  <p markdown="1" class="pquote-credit">
+— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+  </p>
+</aside>
+
+Help people find and remember your project by pointing them to a single namespace.
+
+**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.
+
+If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
+  A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project.
+  <p markdown="1" class="pquote-credit">
+— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+  </p>
+</aside>
+
+**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_.
+
+If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+
+![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
+
+Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!
+
+## Go where your project's audience is (online)
+
+Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
+
+Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
+  Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project.
+  <p markdown="1" class="pquote-credit">
+— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+  </p>
+</aside>
+
+See if you can find ways to share your project in relevant ways:
+
+* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.
+* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.
+* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work.
+
+Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want.
+
+If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication.
+
+## Go where your project's audience is (offline)
+
+![Public speaking](/assets/images/finding-users/public_speaking.jpg)
+
+Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.
+
+If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
+  I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
+  <p markdown="1" class="pquote-credit">
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+  </p>
+</aside>
+
+If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.
+
+As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.
+
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
+  When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+  <p markdown="1" class="pquote-credit">
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+  </p>
+</aside>
+
+When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.
+
+Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
+  I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?
+  <p markdown="1" class="pquote-credit">
+— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+  </p>
+</aside>
+
+## Build a reputation
+
+In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.
+
+Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
+  The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+  <p markdown="1" class="pquote-credit">
+— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+  </p>
+</aside>
+
+It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others.
+
+There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.
+
+## Keep at it!
+
+It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.
diff --git a/_articles/bg/getting-paid.md b/_articles/bg/getting-paid.md
new file mode 100644
index 00000000000..7fd4a32af4c
--- /dev/null
+++ b/_articles/bg/getting-paid.md
@@ -0,0 +1,178 @@
+---
+lang: en
+title: Getting Paid for Open Source Work
+description: Sustain your work in open source by getting financial support for your time or your project.
+class: getting-paid
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+  - best-practices
+  - leadership
+---
+
+## Why some people seek financial support
+
+Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
+I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+  <p markdown="1" class="pquote-credit">
+— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+  </p>
+</aside>
+
+There are many reasons why a person would not want to be paid for their open source work.
+
+* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
+* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
+* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
+  Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+  <p markdown="1" class="pquote-credit">
+— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+  </p>
+</aside>
+
+For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+
+Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
+  Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+  <p markdown="1" class="pquote-credit">
+— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+  </p>
+</aside>
+
+Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
+   OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+  <p markdown="1" class="pquote-credit">
+— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+  </p>
+</aside>
+
+If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+
+## Funding your own time
+
+Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+
+It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+
+If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+
+Many companies are developing open source programs to build their brand and recruit quality talent.
+
+@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+
+> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+
+If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
+  Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+  <p markdown="1" class="pquote-credit">
+— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+  </p>
+</aside>
+
+If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+
+* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
+* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+
+Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+
+Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
+
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
+* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
+* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+Finally, sometimes open source projects put bounties on issues that you might consider helping with.
+
+* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
+* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+
+## Finding funding for your project
+
+Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+
+Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas.
+
+As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+
+### Raise money for your work through crowdfunding campaigns or sponsorships
+
+Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
+A few examples of sponsored projects include:
+
+* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
+* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+
+### Create a revenue stream
+
+Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
+* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
+* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+
+Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+
+### Apply for grant funding
+
+Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+
+For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+
+## Building a case for financial support
+
+Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+
+Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+
+### Impact
+
+Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+
+### Traction
+
+Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+
+### Value to funder
+
+Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+
+### Use of funds
+
+What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+
+### How you'll receive the funds
+
+Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
+  For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+  <p markdown="1" class="pquote-credit">
+— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+  </p>
+</aside>
+
+## Experiment and don't give up
+
+Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
diff --git a/_articles/bg/how-to-contribute.md b/_articles/bg/how-to-contribute.md
new file mode 100644
index 00000000000..88e3adefb17
--- /dev/null
+++ b/_articles/bg/how-to-contribute.md
@@ -0,0 +1,526 @@
+---
+lang: en
+title: How to Contribute to Open Source
+description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans.
+class: contribute
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+  - beginners
+  - building
+---
+
+## Why contribute to open source?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
+  Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+  <p markdown="1" class="pquote-credit">
+— [@errietta](https://github.com/errietta), ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+  </p>
+</aside>
+
+Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+
+Why do people contribute to open source? Plenty of reasons!
+
+### Improve software you rely on
+
+Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+
+### Improve existing skills
+
+Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+
+### Meet people who are interested in similar things
+
+Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+
+### Find mentors and teach others
+
+Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+
+### Build public artifacts that help you grow a reputation (and a career)
+
+By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+
+### Learn people skills
+
+Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+
+### It's empowering to be able to make changes, even small ones
+
+You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+
+## What it means to contribute
+
+If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+
+Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+
+### You don't have to contribute code
+
+A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
+  I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+  <p markdown="1" class="pquote-credit">
+— [@orta](https://github.com/orta), ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+  </p>
+</aside>
+
+Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+
+### Do you like planning events?
+
+* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Organize the project's conference (if they have one)
+* Help community members find the right conferences and submit proposals for speaking
+
+### Do you like to design?
+
+* Restructure layouts to improve the project's usability
+* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Put together a style guide to help the project have a consistent visual design
+* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+
+### Do you like to write?
+
+* Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
+* Curate a folder of examples showing how the project is used
+* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/)
+* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
+  Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+  <p markdown="1" class="pquote-credit">
+— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+  </p>
+</aside>
+
+### Do you like organizing?
+
+* Link to duplicate issues, and suggest new issue labels, to keep things organized
+* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
+* Ask clarifying questions on recently opened issues to move the discussion forward
+
+### Do you like to code?
+
+* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Ask if you can help write a new feature
+* Automate project setup
+* Improve tooling and testing
+
+### Do you like helping people?
+
+* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
+* Answer questions for people on open issues
+* Help moderate the discussion boards or conversation channels
+
+### Do you like helping others code?
+
+* Review code on other people's submissions
+* Write tutorials for how a project can be used
+* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### You don't just have to work on software projects!
+
+While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+
+For example:
+
+* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
+* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
+* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+
+Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
+
+## Orienting yourself to a new project
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
+  If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+  <p markdown="1" class="pquote-credit">
+— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+  </p>
+</aside>
+
+For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+
+Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
+
+### Anatomy of an open source project
+
+Every open source community is different.
+
+Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+
+That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+
+A typical open source project has the following types of people:
+
+* **Author:** The person/s or organization that created the project
+* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
+* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
+* **Contributors:** Everyone who has contributed something back to the project
+* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+
+Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+
+A project also has documentation. These files are usually listed in the top level of a repository.
+
+* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
+* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
+* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).
+* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
+* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
+
+Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+
+* **Issue tracker:** Where people discuss issues related to the project.
+* **Pull requests:** Where people discuss and review changes that are in progress whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), use certain GitHub Action flows to automate and quicken their code reviews.  
+* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/)
+* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/).
+
+## Finding a project to contribute to
+
+Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+
+If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said:, _"Ask not what your country can do for you - ask what you can do for your country."_
+
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/how-to-contribute/johnfkennedy.jpg" class="pquote-avatar" alt="avatar">
+  Ask not what your country can do for you - ask what you can do for your country.
+  <p markdown="1" class="pquote-credit">
+— [_John F. Kennedy Library_](https://www.jfklibrary.org/learn/education/teachers/curricular-resources/ask-not-what-your-country-can-do-for-you)
+  </p>
+</aside>
+
+Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+
+Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+
+Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+
+Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+
+You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
+
+> According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as  typo fixes, reformatting, or writing a translation.
+
+If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+You can also use one of the following resources to help you discover and contribute to new projects:
+
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://opensauced.pizza/)
+
+### A checklist before you contribute
+
+When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+
+Here's a handy checklist to evaluate whether a project is good for new contributors.
+
+**Meets the definition of open source**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+  </label>
+</div>
+
+**Project actively accepts contributions**
+
+Look at the commit activity on the main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+  When was the latest commit?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+  How many contributors does the project have?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  </label>
+</div>
+
+Next, look at the project's issues.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    How many open issues are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to issues when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    Are the issues recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+  </label>
+</div>
+
+Now do the same for the project's pull requests.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    How many open pull requests are there?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox20" class="overflow-hidden d-block text-normal">
+    Do maintainers respond quickly to pull requests when they are opened?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Is there active discussion on the pull requests?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    Are the pull requests recent?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox13" class="overflow-hidden d-block text-normal">
+    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+  </label>
+</div>
+
+**Project is welcoming**
+
+A project that is friendly and welcoming signals that they will be receptive to new contributors.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox14" class="overflow-hidden d-block text-normal">
+    Do the maintainers respond helpfully to questions in issues?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox15" class="overflow-hidden d-block text-normal">
+    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox16" class="overflow-hidden d-block text-normal">
+    Do pull requests get reviewed?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox17" class="overflow-hidden d-block text-normal">
+    Do maintainers thank people for their contributions?
+  </label>
+</div>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+  </p>
+</aside>
+
+## How to submit a contribution
+
+You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+
+### Communicating effectively
+
+Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
+  \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+  <p markdown="1" class="pquote-credit">
+— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+  </p>
+</aside>
+
+Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+
+**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+
+> 😇 _"X doesn't happen when I do Y"_
+>
+> 😢 _"X is broken! Please fix it."_
+
+**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn.
+
+> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+>
+> 😢 _"How do I X?"_
+
+**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+
+> 😇 _"I'd like to write an API tutorial."_
+>
+> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+
+**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+
+> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+>
+> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+
+**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+
+> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+>
+> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+
+**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+
+> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+>
+> 😢 _"Why won't you support my use case? This is unacceptable!"_
+
+**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+
+### Gathering context
+
+Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+
+If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by doing the following:
+
+* **Raising an Issue:** These are like starting a conversation or discussion
+* **Pull requests** are for starting work on a solution.
+* **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution.
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
+  You'll learn <em>a lot</em> from taking a single project you actively use, "watching" it on GitHub and reading every issue and PR.
+<p markdown="1" class="pquote-credit">
+— @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
+  </p>
+</aside>
+
+### Opening an issue
+
+You should usually open an issue in the following situations:
+
+* Report an error you can't solve yourself
+* Discuss a high-level topic or idea (for example, community, vision or policies)
+* Propose a new feature or other project idea
+
+Tips for communicating on issues:
+
+* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
+* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
+* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+
+### Opening a pull request
+
+You should usually open a pull request in the following situations:
+
+* Submit small fixes such as a typo, a broken link or an obvious error.
+* Start work on a contribution that was already asked for, or that you've already discussed, in an issue.
+
+A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later.
+
+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/).)
+* **[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.
+* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. It's important to make sure your changes don't break the existing project.
+* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+
+If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+
+## What happens after you submit your contribution
+
+Before we start celebrating, one of the following will happen after you submit your contribution:
+
+### 😭 You don't get a response
+
+Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+
+If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+
+**Don't reach out to that person privately**; remember that public communication is vital to open source projects.
+
+If you give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+
+### 🚧 Someone requests changes to your contribution
+
+It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+
+When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286).
+
+If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).
+
+### 👎 Your contribution doesn't get accepted
+
+Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+
+### 🎉 Your contribution gets accepted
+
+Hooray! You've successfully made an open source contribution!
+
+## You did it! 🎉
+
+Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
diff --git a/_articles/bg/index.html b/_articles/bg/index.html
new file mode 100644
index 00000000000..699f7d67dc3
--- /dev/null
+++ b/_articles/bg/index.html
@@ -0,0 +1,6 @@
+---
+layout: index
+title: Ръководства за отворен код
+lang: bg
+permalink: /bg/
+---
diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
new file mode 100644
index 00000000000..6fd75930d5d
--- /dev/null
+++ b/_articles/bg/leadership-and-governance.md
@@ -0,0 +1,156 @@
+---
+lang: en
+title: Leadership and Governance
+description: Growing open source projects can benefit from formal rules for making decisions.
+class: leadership
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+  - best-practices
+  - metrics
+---
+
+## Understanding governance for your growing project
+
+Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+
+## What are examples of formal roles used in open source projects?
+
+Many projects follow a similar structure for contributor roles and recognition.
+
+What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+
+* **Maintainer**
+* **Contributor**
+* **Committer**
+
+**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+
+A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+
+**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+  </p>
+</aside>
+
+**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+
+While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
+  You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+  <p markdown="1" class="pquote-credit">
+— @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+  </p>
+</aside>
+
+## How do I formalize these leadership roles?
+
+Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+
+For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+
+For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+
+If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+
+<aside markdown="1" class="pquote">
+  \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+  <p markdown="1" class="pquote-credit">
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+  </p>
+</aside>
+
+Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+
+Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+
+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).
+
+## When should I give someone commit access?
+
+Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
+  Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+  <p markdown="1" class="pquote-credit">
+— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+  </p>
+</aside>
+
+## What are some of the common governance structures for open source projects?
+
+There are three common governance structures associated with open source projects.
+
+* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+
+* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+
+* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
+
+Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Do I need governance docs when I launch my project?
+
+There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+
+Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+
+If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
+  We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+  <p markdown="1" class="pquote-credit">
+— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+  </p>
+</aside>
+
+## What happens if corporate employees start submitting contributions?
+
+Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+
+As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+
+It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+
+"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+
+Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+
+## Do I need a legal entity to support my project?
+
+You don't need a legal entity to support your open source project unless you're handling money.
+
+For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+
+If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+
+Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
+  Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+  <p markdown="1" class="pquote-credit">
+— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+  </p>
+</aside>
+
+If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
new file mode 100644
index 00000000000..f0727ca1200
--- /dev/null
+++ b/_articles/bg/legal.md
@@ -0,0 +1,160 @@
+---
+lang: en
+title: The Legal Side of Open Source
+description: Everything you've ever wondered about the legal side of open source, and a few things you didn't.
+class: legal
+order: 10
+image: /assets/images/cards/legal.png
+related:
+  - contribute
+  - leadership
+---
+
+## Understanding the legal implications of open source
+
+Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this guide you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+
+## Why do people care so much about the legal side of open source?
+
+Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+
+In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly give these permissions with a license.
+
+These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions.
+
+Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
+
+## 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**.
+
+![Create repository](/assets/images/legal/repo-create-name.png)
+
+**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+
+If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+
+## Just give me the TL;DR on what I need to protect my project.
+
+You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+
+[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/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
+  A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+  <p markdown="1" class="pquote-credit">
+— @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+  </p>
+</aside>
+
+## Which open source license is appropriate for my project?
+
+It's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/) if you're starting with a blank slate. It's short, easily understood, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+
+Otherwise, picking the right open source license for your project depends on your objectives.
+
+Your project very likely has (or will have) **dependencies**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm).
+
+Dependencies with **permissive licenses** like [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause) allow you to license your project however you want.
+
+Dependencies with **copyleft licenses** require closer attention. Including any library with a "strong" copyleft license like the [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), or [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) requires you to choose an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) for your project. Libraries with a "limited" or "weak" copyleft license like the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) can be included in projects with any license, provided you follow the [additional rules](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) they specify.
+ 
+You may also want to consider the **communities** you hope will use and contribute to your project:
+
+* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
+* **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
+* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+
+Your **company** may have policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance.
+
+When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+
+## What if I want to change the license of my project?
+
+Most projects never need to change licenses. But occasionally circumstances change.
+
+For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+
+**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+
+**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+
+**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? [People who have commits in your project](https://github.com/thehale/git-authorship) is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+
+Alternatively, you can have contributors pre-approve certain license changes via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)). This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+
+## 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).
+
+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.
+
+Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
+    We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+  <p markdown="1" class="pquote-credit">
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+  </p>
+</aside>
+
+Some situations where you may want to consider an additional contributor agreement for your project include:
+
+* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
+* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
+* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
+* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
+* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
+
+If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+
+## What does my company's legal team need to know?
+
+If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+
+For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+
+**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+
+* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses ([see above](#which-open-source-license-is-appropriate-for-my-project)). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+
+* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+
+* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement ([see above](#which-open-source-license-is-appropriate-for-my-project)).
+
+* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+
+* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+
+If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+
+Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+
+* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
+  Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+  <p markdown="1" class="pquote-credit">
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+  </p>
+</aside>
+
+* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
+* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+
+<aside markdown="1" class="pquote">
+  Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+  <p markdown="1" class="pquote-credit">
+— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+  </p>
+</aside>
+
+* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
+* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
diff --git a/_articles/bg/maintaining-balance-for-open-source-maintainers.md b/_articles/bg/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..c418b476786
--- /dev/null
+++ b/_articles/bg/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,220 @@
+---
+lang: en
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer's focus and what's best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/bg/metrics.md b/_articles/bg/metrics.md
new file mode 100644
index 00000000000..145dd18119b
--- /dev/null
+++ b/_articles/bg/metrics.md
@@ -0,0 +1,128 @@
+---
+lang: en
+title: Open Source Metrics
+description: Make informed decisions to help your open source project thrive by measuring and tracking its success.
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+  - finding
+  - best-practices
+---
+
+## Why measure anything?
+
+Data, when used wisely, can help you make better decisions as an open source maintainer.
+
+With more information, you can:
+
+* Understand how users respond to a new feature
+* Figure out where new users come from
+* Identify, and decide whether to support, an outlier use case or functionality
+* Quantify your project's popularity
+* Understand how your project is used
+* Raise money through sponsorships and grants
+
+For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+
+> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+
+Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+
+If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+
+## Discovery
+
+Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+
+![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:
+
+* **Total page views:** Tells you how many times your project was viewed
+
+* **Total unique visitors:** Tells you how many people viewed your project
+
+* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+
+* **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.
+
+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.
+
+## Usage
+
+People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+
+If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+
+Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+
+If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+
+![Clone graph](/assets/images/metrics/clone_graph.png)
+
+If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+
+* Your project isn't successfully converting your audience, or
+* You're attracting the wrong audience
+
+For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+
+Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+
+Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+
+## Retention
+
+People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+
+It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+
+Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+
+Examples of community metrics that you may want to regularly track include:
+
+* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+
+![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+
+* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+
+* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+
+* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+
+* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
+  Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+  <p markdown="1" class="pquote-credit">
+— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+  </p>
+</aside>
+
+## Maintainer activity
+
+Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+
+Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+
+[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+
+Consider [tracking how long it takes for you (or another maintainer) to respond to contributions](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+
+You could also measure the time it takes to move between stages in the contribution process, such as:
+
+* Average time an issue remains open
+* Whether issues get closed by PRs
+* Whether stale issues get closed
+* Average time to merge a pull request
+
+## Use 📊 to learn about people
+
+Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+
+[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health.
diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
new file mode 100644
index 00000000000..b2e49d630af
--- /dev/null
+++ b/_articles/bg/starting-a-project.md
@@ -0,0 +1,356 @@
+---
+lang: en
+title: Starting an Open Source Project
+description: Learn more about the world of open source and get ready to launch your own project.
+class: beginners
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+  - finding
+  - building
+---
+
+## The "what" and "why" of open source
+
+So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+
+### What does "open source" mean?
+
+When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+
+Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+
+_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+
+### Why do people open source their work?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+  One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+  <p markdown="1" class="pquote-credit">
+— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+  </p>
+</aside>
+
+[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+
+* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+
+* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+
+Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+
+### Does open source mean "free of charge"?
+
+One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+
+Because [an open source license requires](https://opensource.org/definition-annotated/) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+
+As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+
+## Should I launch my own open source project?
+
+The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+
+If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+
+Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+
+If you're not yet convinced, take a moment to think about what your goals might be.
+
+### Setting your goals
+
+Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself,  _why am I open sourcing this project?_
+
+There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+
+If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+  At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+  <p markdown="1" class="pquote-credit">
+— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+  </p>
+</aside>
+
+As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+
+While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+
+**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+
+If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+  As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+  <p markdown="1" class="pquote-credit">
+— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+  </p>
+</aside>
+
+### Contributing to other projects
+
+If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+
+If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+
+## Launching your own open source project
+
+There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+
+Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+
+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/)
+* [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.
+
+If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+
+### Choosing a license
+
+An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+
+Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+
+[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 the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+
+When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+
+![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+
+If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+
+### Writing a README
+
+READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+
+In your README, try to answer the following questions:
+
+* What does this project do?
+* Why is this project useful?
+* How do I get started?
+* Where can I get more help, if I need it?
+
+You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+  Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+  <p markdown="1" class="pquote-credit">
+— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+  </p>
+</aside>
+
+Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+
+For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+
+When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+
+### Writing your contributing guidelines
+
+A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+
+* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
+* How to suggest a new feature
+* How to set up your environment and run tests
+
+In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+
+* The types of contributions you're looking for
+* Your roadmap or vision for the project
+* How contributors should (or should not) get in touch with you
+
+Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+
+For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+
+> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+
+In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+
+Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+
+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.
+
+![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+
+### Establishing a code of conduct
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+  We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+  <p markdown="1" class="pquote-credit">
+— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+  </p>
+</aside>
+
+Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+
+For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+
+In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+
+Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+
+Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+
+## Naming and branding your project
+
+Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+
+### Choosing the right name
+
+Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+
+* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
+* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+
+If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+
+Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+
+### Avoiding name conflicts
+
+[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+
+If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+
+Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+
+You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+
+Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+
+### How you write (and code) affects your brand, too!
+
+Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+
+Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+  <p markdown="1" class="pquote-credit">
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+
+Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+
+It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+
+## 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.
+
+**Documentation**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Project has a LICENSE file with an open source license
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    The issue queue is up-to-date, with issues clearly organized and labeled
+  </label>
+</div>
+
+**Code**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Project uses consistent code conventions and clear function/method/variable names
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    The code is clearly commented, documenting intentions and edge cases
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+  </label>
+</div>
+
+**People**
+
+If you're an individual:
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  </label>
+</div>
+
+If you're a company or organization:
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    You've talked to your legal department
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    You have a marketing plan for announcing and promoting the project
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    At least two people have administrative access to the project
+  </label>
+</div>
+
+## You did it!
+
+Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.
diff --git a/_data/locales/bg.yml b/_data/locales/bg.yml
new file mode 100644
index 00000000000..184c8e665f5
--- /dev/null
+++ b/_data/locales/bg.yml
@@ -0,0 +1,31 @@
+en:
+  locale_name: Български
+  nav:
+    about: Относно нас
+    contribute: Допринеси
+  index:
+    lead: Софтуерът с отворен код е създаден от хора точно като теб. Научи как да стартираш и развиеш своя проект.
+    opensourcefriday: Петък е! Инвестирай няколко часа, като допринесеш за софтуера, който използвате и обичате
+  article:
+    table_of_contents: Съдържание
+    back_to_all_guides: Назад към всички ръководства
+    related_guides: Свързани ръководства
+  footer:
+    contribute:
+      heading: Допринеси
+      description: Искате ли да направите предложение? Това съдържание е с отворен код. Помогнете ни да го подобрим.
+      button: Допринеси
+    subscribe:
+      heading: Поддържай връзка
+      description: Бъди първите, който ще научи за най-новите съвети и ресурси с отворен код на GitHub.
+      label: Имейл адрес
+      button: Абонирай се
+    byline:
+      # [code], [love], and [github] will be replaced by octicons
+      format: "[code] с [love] от [github] и [приятели]"
+      # Label for code octicon
+      code_label: code
+      # Label for love octicon
+      love_label: love
+      # Label for the contributors link
+      friends_label: приятели

From f9382e9ce4d2b0386b2ddb9668f606968f5eec0b Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Tue, 26 Mar 2024 10:39:41 +0100
Subject: [PATCH 647/749] create folder with bulgarian language

---
 _articles/bg/best-practices.md     |  6 ++--
 _articles/bg/building-community.md | 46 +++++++++++++++---------------
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md
index e705d93b01c..c90e45458f3 100644
--- a/_articles/bg/best-practices.md
+++ b/_articles/bg/best-practices.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Best Practices for Maintainers
-description: Making your life easier as an open source maintainer, from documenting processes to leveraging your community.
+lang: bg
+title: Най-добри практики за поддържащи код
+description: Улесняване на живота ви като поддържащ отворен код, от документиране на процеси до използване на вашата общност.
 class: best-practices
 order: 5
 image: /assets/images/cards/best-practices.png
diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index 90d73dd6eda..79ca2c4dbbb 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Building Welcoming Communities
-description: Building a community that encourages people to use, contribute to, and evangelize your project.
+lang: bg
+title: Изграждане на приветливи общности
+description: Изграждане на общност, която насърчава хората да използват, допринасят и евангелизират вашия проект.
 class: building
 order: 4
 image: /assets/images/cards/building.png
@@ -10,44 +10,44 @@ related:
   - coc
 ---
 
-## Setting your project up for success
+## Настройване на вашия проект за успех
 
-You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around?
+Току-що стартирахте проекта си, разпространявате информацията и хората го следват. Брилянтно! Сега, как да ги накараш да останат?
 
-A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back.
+Гостоприемната общност е инвестиция в бъдещето на вашия проект и вашата репутация. Ако вашият проект едва започва да вижда първите си приноси, започнете, като дадете положителен опит на първите сътрудници и ги улеснете да се връщат отново.
 
-### Make people feel welcome
+### Накарайте хората да се чувстват добре дошли
 
-One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+Един от начините да мислите за общността на вашия проект е чрез това, което @MikeMcQuaid нарича [фуния на сътрудниците](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
 
-![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+![Фуния на сътрудник](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
 
-As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more.
+Докато изграждате общността си, помислете как някой на върха на фунията (потенциален потребител) може теоретично да си проправи път надолу (активен поддържащ). Вашата цел е да намалите триенето на всеки етап от опита на сътрудници. Когато хората имат лесни победи, те ще бъдат стимулирани да правят повече.
 
-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.
+* **Улеснете го за тези, които трябва да използват проекта.** [Приятелски README документ](../starting-a-project/#writing-a-readme) aи ясни примери за кодове ще улеснят всеки, който попадне на вашия проект, да започне.
+* **Обяснете ясно как да допринесат**, използвайки [вашият CONTRIBUTING архив](../starting-a-project/#writing-your-contributing-guidelines) и поддържане на вашите проблеми актуални.
+* **Добри първи издания**: За да помогнете на новите сътрудници да започнат, мислете ясно за [подчертаване на теми, които са достатъчно прости, за да се справи начинаещият](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки полезните приноси и намалявайки напрежението от потребителите, които се справят с проблеми, които са твърде трудни за тяхното ниво.
 
-[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.
+[Проучване на GitHub за отворен код от 2017 г](http://opensourcesurvey.org/2017/) показа, че непълната или объркваща документация е най-големият проблем за потребителите с отворен код. Добрата документация приканва хората да взаимодействат с вашия проект. В крайна сметка някой ще отвори проблем или заявка. Използвайте тези взаимодействия като възможности да ги преместите надолу по фунията..
 
-* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
-* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
-* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or a small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
-* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+* **Когато някой нов се присъедини към вашия проект, благодарете му за проявения интерес!** Необходим е само един негативен опит, за да накара някой да не иска да се върне.
+* **Бъдете отзивчиви.** Ако не отговорите на въпроса им в продължение на един месец, има вероятност те вече да са забравили за вашия проект.
+* **Бъдете непредубедени относно видовете вноски, които ще приемете.** Много сътрудници започват с доклад за грешка или малка корекция. Има [много начини да допринесете](../how-to-contribute/#what-it-means-to-contribute) за даден проект. Нека хората помагат по начина, по който искат.
+* **Ако има принос, с който не сте съгласни,** thank them for their idea and [обясни защо](../best-practices/#learning-to-say-no) не се вписва в обхвата на проекта, като се позовавате на съответната документация, ако я имате.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns.
+  Приносът към отворен код е по-лесен за някои, отколкото за други. Има голям страх да не бъдете извикани, че не правите нещо правилно или просто не се вписвате. (...) Като предоставяте на сътрудниците място да допринасят с много ниска техническа компетентност (документация, маркиране на уеб съдържание и т.н.), можете значително да намалите тези опасения.
   <p markdown="1" class="pquote-credit">
-— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+— @mikeal, ["Разрастване на база от сътрудници в съвременния отворен код"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
   </p>
 </aside>
 
-The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute.
+Повечето сътрудници с отворен код са „случайни сътрудници“: хора, които допринасят за проект само от време на време. Случаен сътрудник може да няма време да се запознае напълно с вашия проект, така че вашата работа е да го улесните да допринася.
 
-Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself.
+Насърчаването на други сътрудници е инвестиция и във вас самите. Когато дадете възможност на най-големите си фенове да работят с работата, която ги вълнува, има по-малко натиск да правите всичко сами.
 
 ### Document everything
 

From 5d666b4ac99791ab2e4ee322f3dbeb19311e1db3 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Tue, 26 Mar 2024 12:32:26 +0100
Subject: [PATCH 648/749] I translated building-community.md file

---
 _articles/bg/best-practices.md     |   2 +-
 _articles/bg/building-community.md | 196 ++++++++++++++---------------
 2 files changed, 99 insertions(+), 99 deletions(-)

diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md
index c90e45458f3..170adf54d87 100644
--- a/_articles/bg/best-practices.md
+++ b/_articles/bg/best-practices.md
@@ -277,4 +277,4 @@ Don't leave an unwanted contribution open because you feel guilty or want to be
 
 ## Погрижете се първо за себе си!
 
-Поддържането на популярен проект изисква различни умения от по-ранните етапи на растеж, но не е по-малко възнаграждаващо. Като поддържащ, вие ще практикувате лидерство и лични умения на ниво, което малко хора могат да изпитат. Въпреки че не винаги е лесно да се управлява, поставянето на ясни граници и поемането само на това, което ви харесва, ще ви помогне да останете щастливи, освежени и продуктивни.
\ No newline at end of file
+Поддържането на популярен проект изисква различни умения от по-ранните етапи на растеж, но не е по-малко възнаграждаващо. Като поддържащ, вие ще практикувате лидерство и лични умения на ниво, което малко хора могат да изпитат. Въпреки че не винаги е лесно да се управлява, поставянето на ясни граници и поемането само на това, което ви харесва, ще ви помогне да останете щастливи, освежени и продуктивни.
diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index 79ca2c4dbbb..2b1e86bf018 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -49,228 +49,228 @@ related:
 
 Насърчаването на други сътрудници е инвестиция и във вас самите. Когато дадете възможност на най-големите си фенове да работят с работата, която ги вълнува, има по-малко натиск да правите всичко сами.
 
-### Document everything
+### Документирайте всичко
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
+  Били ли сте някога на (техническо) събитие, където не познавате никого, но всички останали изглежда стоят на групи и чатят като стари приятели? (...) Сега си представете, че искате да допринесете за проект с отворен код, но не разбирате защо и как се случва това.
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Устойчив отворен код"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
-When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public.
+Когато започвате нов проект, може да ви се стори естествено да запазите работата си в тайна. Но проектите с отворен код процъфтяват, когато документирате процеса си публично.
 
-When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed.
+Когато документирате нещата, повече хора могат да бъдат включени във всяка стъпка от процеса. Може да получите помощ за нещо, от което дори не сте подозирали, че имате нужда.
 
-Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public.
+Записването на неща означава повече от просто техническа документация. Всеки път, когато почувствате нужда да напишете нещо или да обсъдите работата си насаме, запитайте се дали можете да я направите публично достояние.
 
-Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions.
+Бъдете прозрачни относно пътната карта на вашия проект, типовете приноси, които търсите, как се разглеждат приносите или защо сте взели определени решения.
 
-If you notice multiple users running into the same problem, document the answers in the README.
+Ако забележите, че много потребители имат същия проблем, моля, документирайте отговорите в README.
 
-For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you.
+За срещи помислете за публикуване на вашите бележки или изводи в свързана тема. Обратната връзка, която ще получите от това ниво на прозрачност, може да ви изненада.
 
-Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on.
+Документирането на всичко се отнася и за работата, която вършите. Ако работите върху голяма актуализация на вашия проект, поставете го в заявка за изтегляне и го маркирайте като работа в процес (WIP). По този начин други хора могат да се почувстват ангажирани в процеса на ранен етап.
 
-### Be responsive
+### Бъдете отзивчиви
 
-As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started.
+Докато [популяризирате своя проект](../finding-users), хората ще имат обратна връзка за вас. Те може да имат въпроси за това как работят нещата или да се нуждаят от помощ, за да започнат.
 
-Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating.
+Опитайте се да бъдете отзивчиви, когато някой подаде проблем, изпрати заявка за изтегляне или зададе въпрос относно вашия проект. Когато отговаряте бързо, хората ще се почувстват като част от диалог и ще бъдат по-ентусиазирани да участват.
 
-Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466):
+Дори и да не можете да прегледате заявката незабавно, потвърждаването й на ранен етап помага да се увеличи ангажираността. Ето как @tdreyno отговори на заявка за изтегляне на [Middleman](https://github.com/middleman/middleman/pull/1466):
 
-![Middleman pull request](/assets/images/building-community/middleman_pr.png)
+![Middleman заявка за изтегляне](/assets/images/building-community/middleman_pr.png)
 
-[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution.
+[Това установи проучване на Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) сътрудниците, които са получили прегледи на кода в рамките на 48 часа, са имали много по-висок процент на възвръщаемост и повторен принос.
 
-Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project.
+Дискусиите относно вашия проект може също да се случват другаде в мрежата, като Stack Overflow, Twitter или Reddit. Можете да настроите известия на някои от тези места, така че да получавате известия, когато някой спомене вашия проект.
 
-### Give your community a place to congregate
+### Дайте на вашата общност място за събиране
 
-There are two reasons to give your community a place to congregate.
+Има две причини да дадете на вашата общност място за събиране.
 
-The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate.
+Първата причина е за тях. Помогнете на хората да се опознаят. Хората с общи интереси неизбежно ще искат място, където да говорят за това. А когато комуникацията е публична и достъпна, всеки може да чете минали архиви, за да се запознае и да участва.
 
-The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel.
+Втората причина е за вас. Ако не дадете на хората обществено място да говорят за вашия проект, те вероятно ще се свържат директно с вас. В началото може да изглежда достатъчно лесно да отговаряте на лични съобщения „само този път“. Но с течение на времето, особено ако проектът ви стане популярен, ще се почувствате изтощени. Устояйте на изкушението да общувате с хората относно вашия проект насаме. Вместо това ги насочете към определен обществен канал.
 
-Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above!
+Публичната комуникация може да бъде толкова проста, колкото да насочите хората да отворят проблем, вместо да ви изпращат имейл директно или да коментират в блога ви. Можете също така да настроите пощенски списък или да създадете акаунт в Twitter, Slack или IRC канал, за да могат хората да говорят за вашия проект. Или опитайте всичко по-горе!
 
-[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members:
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) отделя работни часове през седмица, за да помогне на членовете на общността:
 
-> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.
+> Kops също така отделя време всяка седмица, за да предлага помощ и насоки на общността. Поддържащите Kops се съгласиха да отделят време, специално посветено на работа с новодошлите, подпомагане с PR и обсъждане на нови функции.
 
-Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address.
+Забележителни изключения от публичната комуникация са: 1) проблеми със сигурността и 2) чувствителни нарушения на кодекса за поведение. Винаги трябва да имате начин хората да докладват тези проблеми лично. Ако не искате да използвате личния си имейл, настройте специален имейл адрес.
 
-## Growing your community
+## Разрастване на вашата общност
 
-Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction.
+Общностите са изключително силни. Тази сила може да бъде благословия или проклятие, в зависимост от това как я владеете. Тъй като общността на вашия проект расте, има начини да му помогнете да се превърне в сила на изграждане, а не на разрушение.
 
-### Don't tolerate bad actors
+### Не толерирайте лоши актьори
 
-Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others.
+Всеки популярен проект неизбежно ще привлече хора, които вредят, а не помагат на вашата общност. Те могат да започнат ненужни дебати, да се карат за тривиални характеристики или да тормозят другите.
 
-Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave.
+Направете всичко възможно да приемете политика на нулева толерантност към този тип хора. Ако не бъдат отметнати, негативните хора ще накарат другите хора във вашата общност да се чувстват неудобно. Може дори да си тръгнат.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
-  The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.
+  Истината е, че наличието на подкрепяща общност е от ключово значение. Никога не бих могъл да свърша тази работа без помощта на моите колеги, дружелюбни непознати в интернет и разговорливи IRC канали. (...) Не се задоволявайте с по-малко. Не се задоволявайте с глупаци.
   <p markdown="1" class="pquote-credit">
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, ["Как да управлявате проект FOSS"](https://okdistribute.xyz/post/okf-de)
   </p>
 </aside>
 
-Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
+Редовните дискусии за тривиални аспекти на вашия проект разсейват другите, включително вас, от фокусирането върху важни задачи. Нови хора, които пристигат във вашия проект, може да видят тези разговори и да не искат да участват.
 
-When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations.
+Когато видите, че във вашия проект се случва негативно поведение, извикайте го публично. Обяснете, с любезен, но твърд тон, защо поведението им не е приемливо. Ако проблемът продължава, може да се наложи [да ги помолите да напуснат](../code-of-conduct/#enforcing-your-code-of-conduct). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
 
-### Meet contributors where they're at
+### Запознайте се с сътрудниците там, където са
 
-Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need.
+Добрата документация става все по-важна, когато вашата общност расте. Случайни сътрудници, които иначе може да не са запознати с вашия проект, четат вашата документация, за да получат бързо контекста, от който се нуждаят.
 
-In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors.
+Във вашия CONTRIBUTING файл кажете изрично на новите сътрудници как да започнат. Може дори да искате да направите специален раздел за тази цел. [Django](https://github.com/django/django), например, има специална целева страница за посрещане на нови сътрудници.
 
-![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
+![Django страница с нови сътрудници](/assets/images/building-community/django_new_contributors.png)
 
-In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started.
+В опашката си с теми маркирайте грешки, които са подходящи за различни типове сътрудници: например [_"за начинаещи"_](https://kentcdodds.com/blog/first-timers-only), _"добра първа тема "_ или _"документация"_. [Тези маркировки](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) улесняват някой който  е нов във вашия проект бързо да сканира вашите теми и първи стъпки.
 
-Finally, use your documentation to make people feel welcome at every step of the way.
+И накрая, използвайте вашата документация, за да накарате хората да се чувстват добре дошли на всяка стъпка от процеса.
 
-You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration.
+Никога няма да взаимодействате с повечето хора, които ще участват във вашия проект. Възможно е да има приноси, които не сте получили, защото някой се е почувствал уплашен или не е знаел откъде да започне. Дори няколко мили думи могат да попречат на някого да напусне проекта ви разочарован.
 
-For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+Например, ето как [Rubinius](https://github.com/rubinius/rubinius/) започва [неговото допринасящо ръководство](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
 
-> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
+> Искаме да започнем, като ви благодарим, че използвате Rubinius. Този проект е труд на любов и ние оценяваме всички потребители, които улавят грешки, правят подобрения на производителността и помагат с документацията. Всеки принос е значим, така че благодарим за участието. Имайки предвид това, ето няколко насоки, които ви молим да следвате, за да можем успешно да се справим с проблема ви.
 
-### Share ownership of your project
+### Споделете собствеността върху вашия проект
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
-  Your leaders will have different opinions, as all healthy communities should! However, you need to take steps to ensure the loudest voice doesn't always win by tiring people out, and that less prominent and minority voices are heard.
+  Вашите лидери ще имат различни мнения, както трябва да бъдат всички здрави общности! Трябва обаче да предприемете стъпки, за да гарантирате, че най-силният глас не винаги печели, изморявайки хората, и че по-малко видните и малцинствените гласове се чуват.
   <p markdown="1" class="pquote-credit">
-— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+— @sagesharp, ["Какво прави една добра общност?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
   </p>
 </aside>
 
-People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around.
+Хората са развълнувани да допринасят за проекти, когато изпитват чувство за собственост. Това не означава, че трябва да преобърнете визията на вашия проект или да приемете приноси, които не искате. Но колкото повече признавате другите, толкова повече те ще останат наоколо.
 
-See if you can find ways to share ownership with your community as much as possible. Here are some ideas:
+Вижте дали можете да намерите начини да споделите собствеността с вашата общност колкото е възможно повече. Ето няколко идеи:
 
-* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself.
+* **Отбягвайте коригирането на лесни (некритични) грешки.** Вместо това ги използвайте като възможности за набиране на нови сътрудници или наставничество на някой, който би искал да допринесе. В началото може да изглежда неестествено, но инвестицията ви ще се изплати с времето. Например @michaeljoseph помоли сътрудник да изпрати заявка за изтегляне на проблем с [Cookiecutter](https://github.com/audreyr/cookiecutter) по-долу, вместо да го коригира сам.
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
-* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
+* **Стартирайте файл CONTRIBUTORS или AUTHORS във вашия проект**, който изброява всички, които са допринесли за вашия проект, както прави [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
 
-* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+* Ако имате значителна общност, **изпратете бюлетин или напишете публикация в блог**, като благодарите на сътрудниците. [Тази седмица в Rust] на Rust (https://this-week-in-rust.org/) и [Shoutouts] на Hoodie (http://hood.ie/blog/shoutouts-week-24.html) са два добри примера.
 
-* **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.
+* **Дайте достъп за ангажиране на всеки сътрудник.** @felixge установи, че това кара хората [да бъдат по-развълнувани да усъвършенстват корекциите си](https://felixge.de/2013/03/11/the-pull-request-hack.html ) и дори намери нови поддържащи за проекти, по които не е работил от известно време.
 
-* 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.
+* Ако проектът ви е в GitHub, **преместете проекта си от личния си акаунт в [Организация](https://help.github.com/articles/creating-a-new-organization-account/)** и добавете поне един резервен администратор. Организациите улесняват работата по проекти с външни сътрудници.
 
-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.
+Реалността е, че [повечето проекти имат само] (https://peerj.com/preprints/1233/) един или двама поддържащи, които вършат по-голямата част от работата. Колкото по-голям е вашият проект и колкото по-голяма е вашата общност, толкова по-лесно е да намерите помощ.
 
-While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help.
+Въпреки че не винаги може да намерите някой, който да отговори на обаждането, подаването на сигнал там увеличава шансовете други хора да се включат. И колкото по-рано започнете, толкова по-скоро хората могат да помогнат.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
-  \[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it.
+  \[Във ваш\] най-добър интерес е да набирате сътрудници, които се радват и които са способни да правят нещата, които вие не сте. Обичате ли да кодирате, но не и да отговаряте на въпроси? След това идентифицирайте онези хора във вашата общност, които го правят, и им го позволете.
   <p markdown="1" class="pquote-credit">
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Приветстващи общности"](http://hood.ie/blog/welcoming-communities.html)
   </p>
 </aside>
 
-## Resolving conflicts
+## Разрешаване на конфликти
 
-In the early stages of your project, making major decisions is easy. When you want to do something, you just do it.
+В ранните етапи на вашия проект вземането на важни решения е лесно. Когато искаш да направиш нещо, просто го правиш.
 
-As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own.
+Тъй като вашият проект става по-популярен, повече хора ще се интересуват от решенията, които вземате. Дори и да нямате голяма общност от сътрудници, ако вашият проект има много потребители, ще намерите хора, които преценяват решенията или повдигат свои собствени проблеми.
 
-For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address.
+В по-голямата си част, ако сте култивирали приятелска, уважителна общност и сте документирали процесите си открито, вашата общност трябва да може да намери решение. Но понякога се натъквате на проблем, който е малко по-труден за разрешаване.
 
-### Set the bar for kindness
+### Поставете стандарта за учтивост
 
-When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you.
+Когато вашата общност се бори с труден проблем, настроението може да се надигне. Хората може да се ядосат или разочароват и да си го изкарат един на друг или на вас.
 
-Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive.
+Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#dont-tolerate-bad-actors), за да поддържате дискусията цивилизована и продуктивна.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
-  As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
+  Като поддържащ проект е изключително важно да се отнасяте с уважение към сътрудниците си. Те често приемат много лично това, което казвате.
   <p markdown="1" class="pquote-credit">
-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+— @kennethreitz, ["Бъдете сърдечни или бъдете на път"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
   </p>
 </aside>
 
-Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly.
+Други хора ви търсят за напътствие. Давайте добър пример. Все още можете да изразите разочарование, нещастие или загриженост, но го направете спокойно.
 
-Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you.
+Да запазите хладнокръвие не е лесно, но демонстрирането на лидерство подобрява здравето на вашата общност. Интернет ви благодари.
 
-### Treat your README as a constitution
+### Отнасяйте се към вашия README като към конституция
 
-Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion.
+Вашият README е [повече от просто набор от инструкции](../starting-a-project/#writing-a-readme). Това също е място да говорите за вашите цели, продуктова визия и пътна карта. Ако хората са прекалено съсредоточени върху обсъждането на достойнствата на определена функция, може да ви помогне да прегледате отново вашия README и да говорите за по-високата визия на вашия проект. Фокусирането върху вашия README също обезличава разговора, така че можете да водите конструктивна дискусия.
 
-### Focus on the journey, not the destination
+### Фокусирайте се върху пътуването, а не върху дестинацията
 
-Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns.
+Някои проекти използват процес на гласуване, за да вземат важни решения. Въпреки че е разумно на пръв поглед, гласуването набляга на достигането до „отговор“, а не на изслушване и разглеждане на притесненията на другия.
 
-Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place.
+Гласуването може да стане политическо, когато членовете на общността се чувстват принудени да си правят услуги или да гласуват по определен начин. Не всеки гласува също, независимо дали е [мълчаливото мнозинство](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority -на-потребители) във вашата общност или настоящи потребители, които не са знаели, че се провежда гласуване.
 
-Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus.
+Понякога е необходим равен вот. Доколкото можете обаче, наблягайте на [„търсенето на консенсус“](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), а не на консенсуса .
 
-Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion.
+При процес на търсене на консенсус членовете на общността обсъждат основните опасения, докато не почувстват, че са били адекватно изслушани. Когато останат само второстепенни грижи, общността върви напред. „Търсене на консенсус“ признава, че една общност може да не е в състояние да достигне до перфектен отговор. Вместо това дава приоритет на слушането и дискусията.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
-  Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
+  Част от причината да няма система за гласуване за темите на Atom е, че екипът на Atom няма да следва система за гласуване във всички случаи. Понякога трябва да изберем това, което смятаме за правилно, дори и да не е популярно. (...) Това, което мога да предложа и съм се ангажирал да направя... е, че моята работа е да слушам общността.
   <p markdown="1" class="pquote-credit">
-— @lee-dohm on Atom's decision making process
+— @lee-dohm върху процеса на вземане на решения на Atom
   </p>
 </aside>
 
-Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions.
+Дори ако всъщност не възприемете процес на търсене на консенсус, като поддържащ проект е важно хората да знаят, че слушате. Да накарате другите хора да се почувстват чути и да се ангажират с разрешаването на притесненията им допринася много за деескалацията на чувствителни ситуации. След това последвайте думите си с действия.
 
-Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution.
+Не бързайте с решение в името на решението. Уверете се, че всички се чувстват чути и че цялата информация е разпространена, преди да преминете към решение.
 
-### Keep the conversation focused on action
+### Поддържайте разговора фокусиран върху действието
 
-Discussion is important, but there is a difference between productive and unproductive conversations.
+Дискусията е важна, но има разлика между продуктивни и непродуктивни разговори.
 
-Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down.
+Насърчавайте дискусията, стига да върви активно към разрешаване. Ако е ясно, че разговорът затихва или се отклонява от темата, заяжданията стават лични или хората се бъзикат за незначителни подробности, време е да го затворите.
 
-Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues.
+Позволяването на тези разговори да продължат е не само лошо за разглеждания проблем, но и за здравето на вашата общност. Изпраща съобщение, че този тип разговори са разрешени или дори насърчавани, и може да обезсърчи хората да повдигат или разрешават бъдещи проблеми.
 
-With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_
+С всяка точка, изказана от вас или от други, запитайте се: „Как това ни доближава до решение?“_
 
-If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation.
+Ако разговорът започва да се разплита, попитайте групата _"Кои стъпки трябва да предприемем по-нататък?"_, за да пренасочите разговора.
 
-If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it.
+Ако разговорът очевидно не води до никъде, няма ясни действия, които да бъдат предприети, или подходящото действие вече е предприето, затворете проблема и обяснете защо сте го затворили.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-  Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
+  Насочването на нишка към полезност, без да се натрапва, е изкуство. Няма да работи просто да увещавате хората да спрат да си губят времето или да ги молите да не публикуват, освен ако нямат нещо конструктивно да кажат. (...) Вместо това трябва да предложите условия за по-нататъшен напредък: дайте на хората маршрут, пътека, която да следват, която води до резултатите, които искате, но без да звучи така, сякаш диктувате поведението.
   <p markdown="1" class="pquote-credit">
-— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+— @kfogel, [_Продуциране OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
   </p>
 </aside>
 
-### Pick your battles wisely
+### Подбирайте битките си мъдро
 
-Context is important. Consider who is involved in the discussion and how they represent the rest of the community.
+Важен е контекстът. Помислете кой участва в разговора и как той представлява останалата част от общността.
 
-Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices.
+Всички в общността разстроени ли са или дори загрижени за това? Или е самотен размирник? Не забравяйте да имате предвид мълчаливите членове на вашата общност, а не само активните гласове.
 
-If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread.
+Ако проблемът не представлява по-широките нужди на вашата общност, може просто да се наложи да приемете притесненията на някои хора. Ако това е повтарящ се проблем без ясно решение, моля, насочете ги към предишни дискусии по темата и затворете темата.
 
-### Identify a community tiebreaker
+### Определете критерий за равновесие на общността
 
-With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker.
+С добро поведение и ясна комуникация повечето трудни ситуации се разрешават. Въпреки това, дори при продуктивна дискусия, може просто да има разлика в мненията за това как да продължите. В тези случаи идентифицирайте човек или група от хора, които могат да служат като балансьор.
 
-A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it.
+Нивелирът може да бъде основният поддържащ проекта или може да бъде малка група хора, които вземат решение въз основа на гласуване. В идеалния случай вие сте дефинирали нивелир и свързаната процедура във файл GOVERNANCE, преди да се наложи да го използвате.
 
-Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible.
+Вашето решение за вратовръзка трябва да е последна мярка. Разделящите въпроси са възможност за вашата общност да расте и да се учи. Прегърнете тези възможности и използвайте процес на сътрудничество, за да преминете към разрешаване, когато е възможно.
 
-## Community is the ❤️ of open source
+## Общността е ❤️ на отворен код
 
-Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience.
+Здравите, процъфтяващи общности захранват хилядите часове, вложени в отворен код всяка седмица. Много сътрудници посочват други хора като причина да работят - или да не работят - с отворен код. Като се научите как да се възползвате от тази сила конструктивно, вие ще помогнете на някого да има незабравимо изживяване с отворен код.

From b32ef88114d99b9b228c1e8c87aeca1236937a63 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Wed, 27 Mar 2024 11:15:46 +0100
Subject: [PATCH 649/749] translated code-of-conduct.md, finding-users.md and
 getting-paid.md files

---
 _articles/bg/code-of-conduct.md | 106 ++++++++++-----------
 _articles/bg/finding-users.md   | 114 +++++++++++-----------
 _articles/bg/getting-paid.md    | 162 ++++++++++++++++----------------
 3 files changed, 191 insertions(+), 191 deletions(-)

diff --git a/_articles/bg/code-of-conduct.md b/_articles/bg/code-of-conduct.md
index 3c3d187ae79..6b8ebf70a3b 100644
--- a/_articles/bg/code-of-conduct.md
+++ b/_articles/bg/code-of-conduct.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Your Code of Conduct
-description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct.
+lang: bg
+title: Вашият кодекс на поведение
+description: Улеснявайте здравословното и конструктивно поведение на общността чрез приемане и прилагане на кодекс на поведение.
 class: coc
 order: 8
 image: /assets/images/cards/coc.png
@@ -10,105 +10,105 @@ related:
   - leadership
 ---
 
-## Why do I need a code of conduct?
+## Защо имам нужда от кодекс на поведение?
 
-A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.
+Кодексът на поведение е документ, който определя очакванията за поведение на участниците във вашия проект. Приемането и прилагането на кодекс на поведение може да помогне за създаването на положителна социална атмосфера за вашата общност.
 
-Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.
+Кодексите на поведение помагат да защитите не само вашите участници, но и себе си. Ако поддържате проект, може да откриете, че непродуктивното отношение на другите участници може да ви накара да се почувствате изтощени или нещастни от работата си с течение на времето.
 
-A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with.
+Кодексът на поведение ви дава възможност да улесните здравословното, конструктивно поведение в общността. Проактивността намалява вероятността вие или другите да се уморите от вашия проект и ви помага да предприемете действия, когато някой направи нещо, с което не сте съгласни.
 
-## Establishing a code of conduct
+## Създаване на кодекс на поведение
 
-Try to establish a code of conduct as early as possible: ideally, when you first create your project.
+Опитайте се да създадете кодекс на поведение възможно най-рано: в идеалния случай, когато за първи път създавате своя проект.
 
-In addition to communicating your expectations, a code of conduct describes the following:
+В допълнение към съобщаването на вашите очаквания, кодексът на поведение описва следното:
 
-* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_
-* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_
-* What happens if someone violates the code of conduct
-* How someone can report violations
+* Където кодексът на поведение влиза в сила _(само при проблеми и заявки за изтегляне или дейности на общността като събития?)_
+* За кого се прилага кодексът на поведение _(членове на общността и поддържащи лица, но какво да кажем за спонсори?)_
+* Какво се случва, ако някой наруши кодекса на поведение
+* Как някой може да докладва за нарушения
 
-Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
+Където можете, използвайте предшестващо състояние на техниката. [Споразумението на сътрудниците](https://contributor-covenant.org/) е код за поведение, който се използва от над 40 000 проекта с отворен код, включително Kubernetes, Rails и Swift.
 
-The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples.
+[Кодексът на поведение на Django](https://www.djangoproject.com/conduct/) и [Кодексът на поведение на гражданите](https://web.archive.org/web/20200330154000/http://citizencodeofconduct. org/) също са два добри примера на кодекс на поведение.
 
-Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file.
+Поставете файл CODE_OF_CONDUCT в основната директория на вашия проект и го направете видим за вашата общност, като го свържете от вашия CONTRIBUTING или README файл.
 
-## Deciding how you'll enforce your code of conduct
+## Решете как ще наложите своя кодекс на поведение
 
 <aside markdown="1" class="pquote">
-  A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community.
+  Един неприложен (или неприложим) кодекс на поведение е по-лош от липсата на кодекс на поведение: той изпраща съобщението, че ценностите на кодекса на поведение всъщност не са важни или уважавани във вашата общност.
   <p markdown="1" class="pquote-credit">
-— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+— [Инициатива Ада](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
   </p>
 </aside>
 
-You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:
+Трябва да обясните как вашият кодекс за поведение ще бъде прилаган **_преди_** нарушение. Има няколко причини да го направите:
 
-* It demonstrates that you are serious about taking action when it's needed.
+* Демонстрира, че сте сериозни относно предприемането на действия, когато е необходимо.
 
-* Your community will feel more reassured that complaints actually get reviewed.
+* Вашата общност ще се почувства по-уверена, че оплакванията действително се преглеждат.
 
-* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.
+* Ще уверите вашата общност, че процесът на преглед е честен и прозрачен, ако някога се окажат разследвани за нарушение.
 
-You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
+Трябва да дадете на хората личен начин (като имейл адрес) да докладват за нарушение на кодекса на поведение и да обясните кой получава този доклад. Това може да бъде поддържащ, група от поддържащи или работна група за кодекс на поведение.
 
-Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+Не забравяйте, че някой може да поиска да докладва за нарушение на лице, което получава тези доклади. В този случай им дайте възможност да докладват за нарушения на някой друг. Например @ctb и @mr-c [обясняват за техния проект](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github. com/dib-lab/khmer):
 
-> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+> Случаи на злоупотреба, тормоз или по друг начин неприемливо поведение могат да бъдат докладвани чрез имейл **khmer-project@idyll.org**, който отива само до C. Titus Brown и Michael R. Crusoe. За да съобщите за проблем, свързан с някой от тях, моля, изпратете имейл до **Judi Brown Clarke, Ph.D.** директора по разнообразието в BEACON Center for the Study of Evolution in Action, Център за науки и технологии на NSF.*
 
-For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+За вдъхновение вижте [ръководството за прилагане] на Django (https://www.djangoproject.com/conduct/enforcement-manual/) (въпреки че може да не се нуждаете от нещо толкова изчерпателно, в зависимост от размера на вашия проект).
 
-## Enforcing your code of conduct
+## Налагане на вашия кодекс на поведение
 
-Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up.
+Понякога, въпреки всичките ви усилия, някой ще направи нещо, което нарушава този кодекс. Има няколко начина за справяне с негативното или вредно поведение, когато се появи.
 
-### Gather information about the situation
+### Съберете информация за ситуацията
 
-Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment.
+Отнасяйте се към гласа на всеки член на общността също толкова важен, колкото и вашия собствен. Ако получите доклад, че някой е нарушил кодекса за поведение, приемете го сериозно и проучете въпроса, дори ако не съвпада с вашия собствен опит с този човек. Това сигнализира на вашата общност, че цените тяхната гледна точка и се доверявате на тяхната преценка.
 
-The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context.
+Въпросният член на общността може да е повторен нарушител, който постоянно кара другите да се чувстват неудобно, или може да е казал или направил нещо само веднъж. И в двата случея могат да бъдат основание за предприемане на действие в зависимост от контекста.
 
-Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
+Преди да отговорите, дайте си време да разберете какво се е случило. Прочетете миналите коментари и разговори на човека, за да разберете по-добре кои са те и защо може да са действали по този начин. Опитайте се да съберете гледни точки, различни от вашата собствена, за този човек и неговото поведение.
 
 <aside markdown="1" class="pquote">
-  Don’t get pulled into an argument. Don’t get sidetracked into dealing with someone else’s behavior before you’ve finished dealing with the matter at hand. Focus on what you need.
+  Не се въвличайте в спор. Не се отклонявайте да се занимавате с поведението на някой друг, преди да сте приключили с разглеждането на въпроса. Съсредоточете се върху това, от което се нуждаете.
   <p markdown="1" class="pquote-credit">
-— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+— Stephanie Zvan, ["Значи си имате политика. Сега какво?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
   </p>
 </aside>
 
-### Take appropriate action
+### Предприемете подходящи действия
 
-After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward.
+След като съберете и обработите достатъчно информация, ще трябва да решите какво да правите. Докато обмисляте следващите си стъпки, не забравяйте, че вашата цел като модератор е да насърчите безопасна, уважителна и съвместна среда. Помислете не само как да се справите с въпросната ситуация, но и как вашият отговор ще повлияе на останалата част от поведението и очакванията на вашата общност в бъдеще.
 
-When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise.
+Когато някой съобщи за нарушение на кодекса на поведение, ваша, а не негова работа е да се справите с него. Понякога репортерът разкрива информация с голям риск за своята кариера, репутация или физическа безопасност. Принуждаването им да се изправят срещу насилника си може да постави репортера в компрометираща позиция. Трябва да поддържате директна комуникация с въпросното лице, освен ако репортерът изрично не поиска друго.
 
-There are a few ways you might respond to a code of conduct violation:
+Има няколко начина, по които можете да реагирате на нарушение на кодекса на поведение:
 
-* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication.
+* **Дайте публично предупреждение на въпросното лице** и обяснете как поведението му е повлияло негативно на другите, за предпочитане в канала, където се е случило. Когато е възможно, публичната комуникация предава на останалата част от общността, че приемате кодекса за поведение сериозно. Бъдете мили, но твърди в общуването си.
 
-* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them.
+* **Свържете се лично с въпросното лице**, за да обясните как поведението му е повлияло негативно на другите. Може да искате да използвате личен канал за комуникация, ако ситуацията включва чувствителна лична информация. Ако общувате с някого насаме, добра идея е да изпратите CC на онези, които първи са съобщили за ситуацията, за да знаят, че сте предприели действия. Помолете подалото сигнал лице за съгласие, преди да му изпратите CC.
 
-Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example:
+Понякога не може да се постигне решение. Въпросното лице може да стане агресивно или враждебно, когато се сблъскаш с него или да не промени поведението си. В тази ситуация може да обмислите предприемането на по-строги действия. Например:
 
-* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project
+* **Забрана на въпросното лице** от проекта, наложено чрез временна забрана за участие във всеки аспект на проекта
 
-* **Permanently ban** the person from the project
+* **Забранете за постоянно** лицето от проекта
 
-Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached.
+Забраната на членове не трябва да се приема с лека ръка и представлява постоянна и непримирима разлика в гледните точки. Трябва да предприемате тези мерки само когато е ясно, че не може да се постигне решение.
 
-## Your responsibilities as a maintainer
+## Вашите отговорности като поддържащ
 
-A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes.
+Кодексът на поведение не е закон, който се прилага произволно. Вие сте наложителят на кодекса за поведение и е ваша отговорност да следвате правилата, установени от кодекса за поведение.
 
-As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community.
+Като поддържащ вие установявате насоките за вашата общност и налагате тези насоки в съответствие с правилата, изложени във вашия кодекс за поведение. Това означава да приемате сериозно всеки сигнал за нарушение на кодекса за поведение. На репортера се дължи задълбочено и справедливо разглеждане на жалбата им. Ако установите, че поведението, за което са докладвали, не е нарушение, съобщете им го ясно и обяснете защо няма да предприемете действия по него. Какво ще направят с това зависи от тях: да толерират поведението, с което са имали проблем, или да спрат да участват в общността.
 
-A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable.
+Докладът за поведение, което _технически_ не нарушава кодекса за поведение, все още може да показва, че има проблем във вашата общност и вие трябва да проучите този потенциален проблем и да действате съответно. Това може да включва преразглеждане на вашия кодекс за поведение, за да се изясни приемливото поведение и/или разговор с лицето, чието поведение е докладвано, и да му кажете, че макар да не е нарушил кодекса за поведение, те заобикалят ръба на очакваното и правят сигурни участниците се чувстват неудобно.
 
-In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way.
+В крайна сметка, като поддържащ, вие определяте и налагате стандартите за приемливо поведение. Вие имате способността да оформяте ценностите на общността на проекта и участниците очакват от вас да налагате тези ценности по справедлив и равностоен начин.
 
-## Encourage the behavior you want to see in the world 🌎
+## Насърчавайте поведението, което искате да видите в света 🌎
 
-When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow.
+Когато даден проект изглежда враждебен или неприветлив, дори ако това е само един човек, чието поведение се толерира от другите, рискувате да загубите много повече сътрудници, някои от които може дори никога да не срещнете. Не винаги е лесно да приемете или наложите кодекс на поведение, но насърчаването на гостоприемна среда ще помогне на вашата общност да расте.
diff --git a/_articles/bg/finding-users.md b/_articles/bg/finding-users.md
index 61e7b3e98ff..88e174c104e 100644
--- a/_articles/bg/finding-users.md
+++ b/_articles/bg/finding-users.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Finding Users for Your Project
-description: Help your open source project grow by getting it in the hands of happy users.
+lang: bg
+title: Намиране на потребители за вашия проект
+description: Помогнете на вашия проект с отворен код да се развие, като го предоставите в ръцете на щастливи потребители.
 class: finding
 order: 3
 image: /assets/images/cards/finding.png
@@ -10,139 +10,139 @@ related:
   - building
 ---
 
-## Spreading the word
+## Разпространяване на думата
 
-There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work!
+Няма правило, което да казва, че трябва да рекламирате проект с отворен код, когато стартирате. Има много основателни причини да работите с отворен код, които нямат нищо общо с популярността. Вместо да се надявате, че другите ще намерят и използват вашия проект с отворен код, вие трябва да разпространите думата за вашата упорита работа!
 
-## Figure out your message
+## Разберете съобщението си
 
-Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters.
+Преди да започнете действителната работа по популяризиране на вашия проект, трябва да можете да обясните какво прави и защо има значение.
 
-What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance.
+Какво прави вашия проект различен или интересен? Защо го създадохте? Отговорът на тези въпроси сам ще ви помогне да съобщите значението на вашия проект.
 
-Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want.
+Не забравяйте, че хората се включват като потребители и в крайна сметка стават сътрудници, защото вашият проект решава проблем вместо тях. Докато мислите за посланието и стойността на вашия проект, опитайте се да ги видите през призмата на това, което _потребителите и сътрудниците_ може да искат.
 
-For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
+Например, @robb използва примери за код, за да съобщи ясно защо неговият проект, [Картография](https://github.com/robb/Cartography), е полезен:
 
-![Cartography README](/assets/images/finding-users/cartography.jpg)
+![Картография README](/assets/images/finding-users/cartography.jpg)
 
-For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+За по-задълбочено потапяне в съобщенията вижте упражнението на Mozilla [„Личности и пътеки“](https://mozillascience.github.io/working-open-workshop/personas_pathways/) за разработване на потребителски персони.
 
 ## Help people find and follow your project
 
 <aside markdown="1" class="pquote">
-  You ideally need a single "home" URL that you can promote and point people to in relation to your project. You don't need to splash out on a fancy template or even a domain name, but your project needs a focal point.
+  В идеалния случай се нуждаете от един „начален“ URL адрес, който можете да рекламирате и да насочвате хората към вашия проект. Не е нужно да се занимавате с изискан шаблон или дори име на домейн, но вашият проект се нуждае от фокусна точка.
   <p markdown="1" class="pquote-credit">
-— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+— Peter Cooper & Robert Nyman, ["Как да разпространявате информация за своя код"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
   </p>
 </aside>
 
-Help people find and remember your project by pointing them to a single namespace.
+Помогнете на хората да намерят и запомнят вашия проект, като ги насочите към едно пространство от имена.
 
-**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.
+**Имайте ясен манипулатор, за да популяризирате работата си.** Twitter манипулатор, GitHub URL или IRC канал е лесен начин да насочите хората към вашия проект. Тези изходи също дават място за събиране на нарастващата общност на вашия проект.
 
-If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides.
+Ако все още не желаете да създавате изходи за вашия проект, популяризирайте свой собствен Twitter или GitHub манипулатор във всичко, което правите. Популяризирането на вашия Twitter или GitHub ще позволи на хората да знаят как да се свържат с вас или да следят работата ви. Ако говорите на среща или събитие, уверете се, че вашата информация за контакт е включена във вашата биография или слайдове.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
-  A mistake I made in those early days (...) was not starting a Twitter account for the project. Twitter's a great way to keep people up to date about a project as well as constantly expose people to the project.
+  Грешка, която направих в онези ранни дни (...) беше, че не започнах Twitter акаунт за проекта. Twitter е чудесен начин да информирате хората за даден проект, както и постоянно да излагате на хората информация за проекта.
   <p markdown="1" class="pquote-credit">
-— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+— @nathanmarz, ["История на Apache Storm и извлечени уроци"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
   </p>
 </aside>
 
-**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project.
+**Помислете за създаване на уебсайт за вашия проект.** Уеб сайтът прави проекта ви по-удобен и лесен за навигация, особено когато е съчетан с ясна документация и уроци. Наличието на уебсайт също предполага, че вашият проект е активен, което ще накара вашата аудитория да се чувства по-комфортно при използването му. Дайте примери, за да дадете на хората идеи как да използват вашия проект.
 
-[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_.
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), съ-създател на Django, каза, че уебсайтът е _"далеч най-доброто нещо, което направихме с Django в ранните дни"_ .
 
-If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+Ако вашият проект се хоства в GitHub, можете да използвате [GitHub Pages](https://pages.github.com/), за да създадете лесно уебсайт. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) и [Middleman](https://middlemanapp.com/) са [няколко примера] (https://github.com/showcases/github-pages-examples) от отлични, изчерпателни уебсайтове.
 
-![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
+![Начална страница на Vagrant](/assets/images/finding-users/vagrant_homepage.png)
 
-Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!
+Сега, след като имате съобщение за вашия проект и лесен начин за хората да го намерят, нека да излезем и да поговорим с вашата аудитория!
 
-## Go where your project's audience is (online)
+## Отидете там, където е аудиторията на вашия проект (онлайн)
 
-Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
+Онлайн обхватът е чудесен начин за бързо споделяне и разпространение на информацията. Използвайки онлайн канали, вие имате потенциала да достигнете до много широка аудитория.
 
-Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+Възползвайте се от съществуващите онлайн общности и платформи, за да достигнете до вашата аудитория. Ако вашият проект с отворен код е софтуерен проект, вероятно можете да намерите аудиторията си в [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News ](https://news.ycombinator.com/) или [Quora](https://www.quora.com/). Намерете каналите, от които смятате, че хората ще имат най-голяма полза или ще бъдат развълнувани от вашата работа.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
-  Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project.
+  Всяка програма има много специфични функции, които само малка част от потребителите ще намерят полезни. Не изпращайте спам на възможно най-много хора. Вместо това насочете усилията си към общности, които ще имат полза от това да знаят за вашия проект.
   <p markdown="1" class="pquote-credit">
-— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+— @pazdera, ["Маркетинг за проекти с отворен код"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
   </p>
 </aside>
 
-See if you can find ways to share your project in relevant ways:
+Вижте дали можете да намерите начини да споделите проекта си по подходящи начини:
 
-* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.
-* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.
-* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work.
+* **Запознайте се с подходящи проекти и общности с отворен код.** Понякога не е нужно директно да рекламирате проекта си. Ако вашият проект е идеален за специалисти по данни, които използват Python, запознайте се с общността за наука за данни на Python. Когато хората ви опознаят, ще се появят естествени възможности да говорите и споделяте работата си.
+* **Намерете хора, които се сблъскват с проблема, който вашият проект решава.** Потърсете в свързани форуми за хора, които попадат в целевата аудитория на вашия проект. Отговорете на техния въпрос и намерете тактичен начин, когато е подходящо, да предложите вашия проект като решение.
+* **Поискайте обратна връзка.** Представете себе си и работата си на публика, която ще я намери за подходяща и интересна. Бъдете конкретни относно това кой смятате, че ще има полза от вашия проект. Опитайте се да завършите изречението: _"Мисля, че моят проект наистина ще помогне на X, които се опитват да направят Y_". Слушайте и отговаряйте на отзивите на другите, вместо просто да популяризирате работата си.
 
-Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want.
+Най-общо казано, фокусирайте се върху това да помагате на другите, преди да поискате неща в замяна. Тъй като всеки може лесно да рекламира проект онлайн, ще има много шум. За да се откроите от тълпата, дайте на хората контекст за това кой сте, а не само това, което искате.
 
-If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication.
+Ако никой не обърне внимание или не отговори на първоначалния ви обхват, не се обезсърчавайте! Повечето стартирания на проекти са итеративен процес, който може да отнеме месеци или години. Ако не получите отговор от първия път, опитайте различна тактика или първо потърсете начини да добавите стойност към работата на другите. Популяризирането и стартирането на вашия проект изисква време и отдаденост.
 
-## Go where your project's audience is (offline)
+## Отидете там, където е аудиторията на вашия проект (офлайн)
 
-![Public speaking](/assets/images/finding-users/public_speaking.jpg)
+![Публично говорене](/assets/images/finding-users/public_speaking.jpg)
 
-Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.
+Офлайн събитията са популярен начин за популяризиране на нови проекти пред публика. Те са чудесен начин да достигнете до ангажирана аудитория и да изградите по-дълбоки човешки връзки, особено ако се интересувате от достигане до разработчици.
 
-If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.
+Ако сте [нов в публичното говорене](https://speaking.io/), започнете, като намерите местна среща, която е свързана с езика или екосистемата на вашия проект.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
-  I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
+  Бях доста нервен да отида в PyCon. Изнасях лекция, щях да се запозная само с няколко души там, отидох за цяла седмица. (...) Все пак не трябваше да се притеснявам. PyCon беше феноменално страхотен! (...) Всички бяха невероятно дружелюбни и общителни, толкова много, че рядко намирах време да не говоря с хората!
   <p markdown="1" class="pquote-credit">
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["Как се научих да спра да се тревожа и да обичам PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
   </p>
 </aside>
 
-If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.
+Ако никога преди не сте говорили на събитие, напълно нормално е да се чувствате нервни! Не забравяйте, че публиката ви е там, защото те наистина искат да чуят за работата ви.
 
-As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.
+Докато пишете речта си, съсредоточете се върху това, което аудиторията ви ще намери за интересно и от което ще извлече полза. Поддържайте езика си приятелски настроен и достъпен. Усмихвайте се, дишайте и се забавлявайте.
 
 <aside markdown="1" class="pquote">
   <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
-  When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+  Когато започнете да пишете речта си, независимо каква е темата ви, може да ви помогне, ако видите речта си като история, която разказвате на хората.
   <p markdown="1" class="pquote-credit">
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["Как да подготвим и напишем разговор за техническа конференция"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
   </p>
 </aside>
 
-When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.
+Когато се почувствате готови, обмислете да говорите на конференция, за да популяризирате проекта си. Конференциите могат да ви помогнат да достигнете до повече хора, понякога от цял свят.
 
-Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers.
+Потърсете конференции, които са специфични за вашия език или екосистема. Преди да изпратите своята реч, проучете конференцията, за да пригодите лекцията си за присъстващите и да увеличите шансовете си да бъдете приети да говорите на конференцията. Често можете да добиете представа за аудиторията си, като погледнете говорителите на конференцията.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
-  I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?
+  Писах много мило на хората от JSConf и ги помолих да ми дадат място, където мога да го представя на JSConf EU. (...) Бях изключително уплашен, представяйки това нещо, върху което работих шест месеца. (...) През цялото време си мислех, о, Боже мой. Какво правя тук?
   <p markdown="1" class="pquote-credit">
-— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+— @ry, ["История на Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
   </p>
 </aside>
 
 ## Build a reputation
 
-In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.
+В допълнение към стратегиите, описани по-горе, най-добрият начин да поканите хората да споделят и да допринесат за вашия проект е да споделяте и да допринесете за техните проекти.
 
-Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships.
+Подпомагането на новодошлите, споделянето на ресурси и обмисленият принос към чужди проекти ще ви помогнат да изградите положителна репутация. Това, че сте активен член в общността с отворен код, ще помогне на хората да имат контекст за вашата работа и е по-вероятно да обърнат внимание и да споделят вашия проект. Развитието на връзки с други проекти с отворен код може дори да доведе до официални партньорства.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
-  The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+  Единствената причина urllib3 да е най-популярната библиотека на Python на трети страни днес е, че е част от заявките.
   <p markdown="1" class="pquote-credit">
-— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+— @shazow, ["Как да накарате своя проект с отворен код да процъфтява"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
   </p>
 </aside>
 
-It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others.
+Никога не е твърде рано или твърде късно да започнете да изграждате репутацията си. Дори ако вече сте стартирали свой собствен проект, продължавайте да търсите начини да помагате на другите.
 
-There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.
+Няма еднодневно решение за изграждане на аудитория. Спечелването на доверието и уважението на другите отнема време и изграждането на вашата репутация никога не свършва.
 
-## Keep at it!
+## Продължавайте!
 
-It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.
+Може да отнеме много време, преди хората да забележат вашия проект с отворен код. Това е добре! Някои от най-популярните проекти днес отнеха години, за да достигнат високи нива на активност. Съсредоточете се върху изграждането на взаимоотношения, вместо да се надявате, че вашият проект спонтанно ще спечели популярност. Бъдете търпеливи и продължавайте да споделяте работата си с тези, които я оценяват.
diff --git a/_articles/bg/getting-paid.md b/_articles/bg/getting-paid.md
index 7fd4a32af4c..641e38a397d 100644
--- a/_articles/bg/getting-paid.md
+++ b/_articles/bg/getting-paid.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Getting Paid for Open Source Work
-description: Sustain your work in open source by getting financial support for your time or your project.
+lang: bg
+title: Получаване на заплащане за работа с отворен код
+description: Поддържайте работата си с отворен код, като получите финансова подкрепа за вашето време или за вашия проект.
 class: getting-paid
 order: 7
 image: /assets/images/cards/getting-paid.png
@@ -10,169 +10,169 @@ related:
   - leadership
 ---
 
-## Why some people seek financial support
+## Защо някои хора търсят финансова подкрепа
 
-Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+Голяма част от работата с отворен код е доброволна. Например, някой може да се натъкне на грешка в проект, който използва, и да изпрати бързо решение, или може да му хареса да бърника с проект с отворен код в свободното си време.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
-I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+Търсех "хоби" проект за програмиране, който да ме занимава през седмицата около Коледа. (...) Имах домашен компютър и нищо друго в ръцете си. Реших да напиша интерпретатор за новия скриптов език, за който си мислех напоследък. (...) Избрах Python като работно заглавие.
   <p markdown="1" class="pquote-credit">
-— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+— @gvanrossum, ["Програмиране на Python"](https://www.python.org/doc/essays/foreword/)
   </p>
 </aside>
 
-There are many reasons why a person would not want to be paid for their open source work.
+Има много причини, поради които човек не би искал да получава заплащане за работата си с отворен код.
 
-* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
-* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
-* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+* **Те може вече да имат работа на пълен работен ден, която обичат,** което им позволява да допринасят за отворен код в свободното си време.
+* **Харесва им да мислят за отворения код като за хоби** или творческо бягство и не искат да се чувстват финансово задължени да работят по проектите си.
+* **Те получават други ползи от приноса си към отворен код,** като например изграждане на репутация или портфолио, усвояване на нови умения или чувство за близост до общност.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
-  Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+  Финансовите дарения наистина добавят чувство за отговорност за някои. (...) За нас е важно, в глобално свързания, забързан свят, в който живеем, да можем да кажем „не сега, искам да правя нещо съвсем различно“.
   <p markdown="1" class="pquote-credit">
-— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+— @alloy, ["Защо не приемаме дарения"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
   </p>
 </aside>
 
-For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+За други, особено когато приносът е в ход или изисква значително време, получаването на плащане за принос към отворен код е единственият начин да участват, било защото проектът го изисква, или поради лични причини.
 
-Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
+Поддържането на популярни проекти може да бъде значителна отговорност, като отнема 10 или 20 часа на седмица вместо няколко часа на месец.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
-  Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+  Попитайте всеки поддържащ проект с отворен код и той ще ви разкаже за реалността на количеството работа, което отива в управлението на проект. Имате клиенти. Вие решавате проблеми вместо тях. Вие създавате нови функции. Това се превръща в истинска нужда от вашето време.
   <p markdown="1" class="pquote-credit">
-— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+— @ashedryden, ["Етиката на неплатения труд и OSS общността"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
   </p>
 </aside>
 
-Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+Платената работа също дава възможност на хора от различни сфери на живота да дадат значим принос. Някои хора не могат да си позволят да прекарват неплатено време в проекти с отворен код въз основа на текущото си финансово състояние, дълг или семейни или други задължения за грижа. Това означава, че светът никога не вижда приноси от талантливи хора, които не могат да си позволят да отделят доброволно времето си. Това има етични последици, както @ashedryden [описа](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), тъй като свършената работа е предубедени в полза на онези, които вече имат предимства в живота, които след това получават допълнителни предимства въз основа на техния доброволен принос, докато други, които не могат да бъдат доброволци, след това не получават по-късни възможности, което засилва текущата липса на разнообразие в отворения код общност.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
-   OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+   OSS носи огромни ползи за технологичната индустрия, което от своя страна означава ползи за всички индустрии. (...) Въпреки това, ако единствените хора, които могат да се съсредоточат върху това, са късметлиите и обсебените, тогава има огромен неизползван потенциал.
   <p markdown="1" class="pquote-credit">
-— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+— @isaacs, ["Пари и отворен код"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
   </p>
 </aside>
 
-If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+Ако търсите финансова подкрепа, трябва да обмислите два начина. Можете да финансирате собственото си време като сътрудник или можете да намерите организационно финансиране за проекта.
 
-## Funding your own time
+## Финансиране на вашето собствено време
 
-Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+Днес много хора получават заплащане, за да работят на непълен или пълен работен ден с отворен код. Най-често срещаният начин да получите заплащане за времето си е да говорите с вашия работодател.
 
-It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+По-лесно е да направите аргумент за работа с отворен код, ако вашият работодател действително използва проекта, но бъдете креативни с представянето си. Може би вашият работодател не използва проекта, но той използва Python и поддържането на популярен проект на Python помага за привличането на нови разработчици на Python. Може би това кара вашия работодател да изглежда по-приятелски настроен към разработчиците като цяло.
 
-If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+Ако нямате съществуващ проект с отворен код, върху който бихте искали да работите, но предпочитате текущата ви работа да е с отворен код, помолете вашия работодател да отвори част от техния вътрешен софтуер.
 
-Many companies are developing open source programs to build their brand and recruit quality talent.
+Много компании разработват програми с отворен код, за да изградят своята марка и да наемат качествени таланти.
 
-@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+@hueniverse например установи, че има финансови причини, които да оправдаят [инвестицията на Walmart в отворен код](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in- open-source-isn-t-cheap.html). И @jamesgpearce установи, че програмата с отворен код на Facebook [има значение](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) при набирането на персонал:
 
-> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+> Тя е тясно свързана с нашата хакерска култура и начина, по който нашата организация се възприемаше. Попитахме нашите служители: „Знаехте ли за софтуерната програма с отворен код във Facebook?“. Две трети казаха "Да". Половината казаха, че програмата е допринесла положително за решението им да работят за нас. Това не са пределни числа и се надявам, че тенденцията ще продължи.
 
-If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+Ако вашата компания тръгне по този път, важно е да поддържате ясни границите между общността и корпоративната дейност. В крайна сметка отвореният код се поддържа чрез принос от хора по целия свят и това е по-голямо от която и да е компания или местоположение.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
-  Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+  Получаването на заплащане за работа с отворен код е рядка и прекрасна възможност, но не трябва да се отказвате от страстта си в процеса. Вашата страст трябва да е причината, поради която компаниите искат да ви плащат.
   <p markdown="1" class="pquote-credit">
-— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+— @jessfraz, ["Размити линии"](https://blog.jessfraz.com/post/blurred-lines/)
   </p>
 </aside>
 
-If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+Ако не можете да убедите настоящия си работодател да даде приоритет на работата с отворен код, помислете за намиране на нов работодател, който насърчава приноса на служителите към отворен код. Потърсете компании, които подчертават своята отдаденост на работата с отворен код. Например:
 
-* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
-* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+* Някои компании, като [Netflix](https://netflix.github.io/) или [PayPal](https://paypal.github.io/), имат уебсайтове, които подчертават тяхното участие в отворен код
+* [Zalando](https://opensource.zalando.com) публикува своята [политика за принос с отворен код](https://opensource.zalando.com/docs/using/contributing/) за служители
 
-Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+Проекти, които произхождат от голяма компания, като [Go](https://github.com/golang) или [React](https://github.com/facebook/react), will also likely employ people to work on open source.
 
-Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
+В зависимост от вашите лични обстоятелства можете да опитате да съберете пари независимо, за да финансирате работата си с отворен код. Например:
 
-* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
-* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
-* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+* @Homebrew (и [много други поддържащи и организации](https://github.com/sponsors/community)) финансират работата си чрез [Спонсори на GitHub](https://github.com/sponsors)
+* @gaearon финансира работата си върху [Redux](https://github.com/reactjs/redux) чрез [кампания за групово финансиране на Patreon](https://redux.js.org/)
+* @andrewgodwin финансира работа по миграции на схема на Django [чрез кампания на Kickstarter] (https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
-Finally, sometimes open source projects put bounties on issues that you might consider helping with.
+И накрая, понякога проекти с отворен код дават премии за проблеми, за които може да обмислите да помогнете.
 
-* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
-* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+* @ConnorChristie успя да получи плащане за [помощ](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F %2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol работят по своята JavaScript библиотека [чрез награда за gitcoin](https://gitcoin.co/).
+* @mamiM направи японски преводи за @MetaMask след [изданието беше финансирано от Bounties Network](https://explorer.bounties.network/bounty/134).
 
-## Finding funding for your project
+## Намиране на финансиране за вашия проект
 
-Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+Освен договореностите за отделни сътрудници, понякога проектите набират пари от компании, физически лица или други за финансиране на текуща работа.
 
-Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas.
+Организационното финансиране може да отиде за плащане на настоящи сътрудници, покриване на разходите за управление на проекта (като такси за хостинг) или инвестиране в нови функции или идеи.
 
-As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+Тъй като популярността на отворения код нараства, намирането на финансиране за проекти все още е експериментално, но има няколко общи опции.
 
-### Raise money for your work through crowdfunding campaigns or sponsorships
+### Съберете пари за работата си чрез кампании за групово финансиране или спонсорство
 
-Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
-A few examples of sponsored projects include:
+Намирането на спонсорство работи добре, ако вече имате силна публика или репутация или проектът ви е много популярен.
+Няколко примера за спонсорирани проекти включват:
 
-* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+* **[webpack](https://github.com/webpack)** събира пари от компании и физически лица [чрез OpenCollective](https://opencollective.com/webpack)
+* **[Ruby Together](https://rubytogether.org/),** организация с нестопанска цел, която плаща за работата по [bundler](https://github.com/bundler/bundler), [RubyGems](https ://github.com/rubygems/rubygems) и други Ruby инфраструктурни проекти
 
-### Create a revenue stream
+### Създайте поток от приходи
 
-Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+В зависимост от вашия проект може да имате възможност да таксувате за търговска поддръжка, хоствани опции или допълнителни функции. Няколко примера включват:
 
-* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
-* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
-* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+* **[Sidekiq](https://github.com/mperham/sidekiq)** предлага платени версии за допълнителна поддръжка
+* **[Travis CI](https://github.com/travis-ci)** предлага платени версии на своя продукт
+* **[Ghost](https://github.com/TryGhost/Ghost)** е организация с нестопанска цел с платена управлявана услуга
 
-Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+Някои популярни проекти, като [npm](https://github.com/npm/cli) и [Docker](https://github.com/docker/docker), дори набират рисков капитал, за да подкрепят растежа на своя бизнес.
 
-### Apply for grant funding
+### Кандидатствайте за безвъзмездно финансиране
 
-Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+Някои софтуерни фондации и компании предлагат грантове за работа с отворен код. Понякога грантовете могат да се изплащат на физически лица, без да се създава юридическо лице за проекта.
 
-* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
-* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
-* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
-* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+* **[Прочетете документите](https://github.com/rtfd/readthedocs.org)** получи субсидия от [Поддръжка на Mozilla Open Source](https://www.mozilla.org/en-US/ субсидии/)
+* Работата по **[OpenMRS](https://github.com/openmrs)** е финансирана от [Retreat за отворен код на Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees )
+* **[Libraries.io](https://github.com/librariesio)** получи грант от [Фондация Слоун](https://sloan.org/programs/digital-technology)
+* **[Python Software Foundation](https://www.python.org/psf/grants/)** предлага грантове за работа, свързана с Python
 
-For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+За по-подробни опции и казуси @nayafia [написа ръководство](https://github.com/nayafia/lemonade-stand) за получаване на заплащане за работа с отворен код. Различните видове финансиране изискват различни умения, така че преценете силните си страни, за да разберете коя опция работи най-добре за вас.
 
-## Building a case for financial support
+## Изграждане на случай за финансова подкрепа
 
-Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+Независимо дали вашият проект е нова идея или съществува от години, трябва да очаквате да вложите значителни мисли в идентифицирането на вашия целеви финансист и в представянето на убедителни аргументи.
 
-Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+Независимо дали искате да платите за собственото си време или да наберете средства за проект, трябва да можете да отговорите на следните въпроси.
 
-### Impact
+### Въздействие
 
-Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+Защо този проект е полезен? Защо вашите потребители или потенциални потребители го харесват толкова много? Къде ще бъде след пет години?
 
-### Traction
+### Сцепление
 
-Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+Опитайте се да съберете доказателства, че вашият проект има значение, независимо дали става дума за показатели, анекдоти или препоръки. Има ли компании или забележителни хора, които използват вашия проект в момента? Ако не, виден човек го е одобрил?
 
-### Value to funder
+### Стойност за финансиращия
 
-Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+До финансиращите, независимо дали вашият работодател или фондация, предоставяща безвъзмездни средства, често се обръщат с възможности. Защо трябва да подкрепят вашия проект пред всяка друга възможност? Как се облагодетелстват те лично?
 
-### Use of funds
+### Използване на средства
 
-What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+Какво точно ще постигнете с предложеното финансиране? Съсредоточете се върху важни етапи или резултати на проекта, вместо да плащате заплата.
 
-### How you'll receive the funds
+### Как ще получите средствата
 
-Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+Финансиращият има ли някакви изисквания относно изплащането? Например, може да се наложи да сте организация с нестопанска цел или да имате фискален спонсор с нестопанска цел. Или може би средствата трябва да бъдат дадени на отделен изпълнител, а не на организация. Тези изисквания варират между финансиращите, така че не забравяйте да направите проучването си предварително.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
-  For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+  От години ние сме водещият ресурс за икони, удобни за уебсайтове, с общност от над 20 милиона души и сме представени в над 70 милиона уебсайта, включително Whitehouse.gov. (...) Версия 4 беше преди три години. Уеб технологиите се промениха много оттогава и честно казано, Font Awesome малко остаря. (...) Ето защо представяме Font Awesome 5. Модернизираме и пренаписваме CSS и преработваме всяка икона от горе до долу. Говорим за по-добър дизайн, по-добра последователност и по-добра четливост.
   <p markdown="1" class="pquote-credit">
-— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+— @davegandy, [Font Awesome Kickstarter видео](https://www.kickstarter.com/projects/232193852/font-awesome-5)
   </p>
 </aside>
 
-## Experiment and don't give up
+## Експериментирайте и не се отказвайте
 
-Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
+Събирането на пари не е лесно, независимо дали сте проект с отворен код, организация с нестопанска цел или стартиращ софтуер, и в повечето случаи изисква от вас да проявите креативност. Определянето на начина, по който искате да получавате заплащане, извършването на вашите проучвания и поставянето на мястото на вашия финансиращ ще ви помогне да изградите убедителна аргументация за финансиране.
\ No newline at end of file

From c345c38dadad8227ef49cbe310bab3188a92446c Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Wed, 27 Mar 2024 12:03:45 +0100
Subject: [PATCH 650/749] translated how-to-contribute.md file

---
 _articles/bg/how-to-contribute.md | 424 +++++++++++++++---------------
 1 file changed, 212 insertions(+), 212 deletions(-)

diff --git a/_articles/bg/how-to-contribute.md b/_articles/bg/how-to-contribute.md
index 88e3adefb17..0914691e170 100644
--- a/_articles/bg/how-to-contribute.md
+++ b/_articles/bg/how-to-contribute.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: How to Contribute to Open Source
-description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans.
+lang: bg
+title: Как да допринесете за отворения код
+description: Искате ли да допринесете за отворен код? Ръководство за правене на приноси с отворен код за начинаещи и за ветерани.
 class: contribute
 order: 1
 image: /assets/images/cards/contribute.png
@@ -14,206 +14,206 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
-  Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+  Работата върху \[freenode\] ми помогна да спечеля много от уменията, които по-късно използвах за обучението си в университета и действителната си работа. Мисля, че работата по проекти с отворен код ми помага толкова, колкото и на проекта!
   <p markdown="1" class="pquote-credit">
-— [@errietta](https://github.com/errietta), ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— [@errietta](https://github.com/errietta), ["Защо обичам да допринасям за софтуер с отворен код"](https://www.errietta.me/blog/open-source/)
   </p>
 </aside>
 
-Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+Приносът към отворен код може да бъде възнаграждаващ начин за учене, преподаване и изграждане на опит в почти всяко умение, което можете да си представите.
 
-Why do people contribute to open source? Plenty of reasons!
+Защо хората допринасят за отворен код? Много причини!
 
-### Improve software you rely on
+### Подобрете софтуера, на който разчитате
 
-Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+Много сътрудници с отворен код започват като потребители на софтуер, за който допринасят. Когато намерите грешка в софтуер с отворен код, който използвате, може да искате да погледнете източника, за да видите дали можете да го коригирате сами. Ако случаят е такъв, тогава връщането на корекцията е най-добрият начин да се уверите, че вашите приятели (и вие самите, когато актуализирате до следващото издание) ще могат да се възползват от нея.
 
-### Improve existing skills
+### Подобрете съществуващите умения
 
-Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+Независимо дали става въпрос за кодиране, дизайн на потребителски интерфейс, графичен дизайн, писане или организиране, ако търсите практика, има задача за вас по проект с отворен код.
 
-### Meet people who are interested in similar things
+### Запознайте се с хора, които се интересуват от подобни неща
 
-Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+Проекти с отворен код с топли, гостоприемни общности карат хората да се връщат с години. Много хора създават приятелства за цял живот чрез участието си в отворен код, независимо дали се срещат по време на конференции или късно вечерни онлайн чатове за бурито.
 
-### Find mentors and teach others
+### Намерете ментори и учете другите
 
-Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+Работата с други по споделен проект означава, че ще трябва да обясните как правите нещата, както и да помолите други хора за помощ. Действията на учене и преподаване могат да бъдат удовлетворяваща дейност за всички участници.
 
-### Build public artifacts that help you grow a reputation (and a career)
+### Изградете публични артефакти, които ви помагат да развиете репутация (и кариера)
 
-By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+По дефиниция цялата ви работа с отворен код е публична, което означава, че получавате безплатни примери, които да вземете навсякъде като демонстрация на това, което можете да правите.
 
-### Learn people skills
+### Научете умения за хора
 
-Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+Отвореният код предлага възможности за практикуване на лидерски и управленски умения, като разрешаване на конфликти, организиране на екипи от хора и приоритизиране на работата.
 
-### It's empowering to be able to make changes, even small ones
+### Овластяващо е да можеш да правиш промени, дори малки
 
-You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+Не е нужно да сте сътрудник през целия живот, за да се насладите на участието в отворен код. Случвало ли ви се е да видите печатна грешка в уебсайт и да ви се иска някой да я поправи? В проект с отворен код можете да направите точно това. Отвореният код помага на хората да се чувстват независими от живота си и начина, по който преживяват света, и това само по себе си е удовлетворяващо.
 
-## What it means to contribute
+## Какво означава да допринасяш
 
-If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+Ако сте нов сътрудник на отворен код, процесът може да бъде смущаващ. Как намирате правилния проект? Ами ако не знаете как да кодирате? Ами ако нещо се обърка?
 
-Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+Не се притеснявайте! Има всякакви начини да се включите в проект с отворен код и няколко съвета ще ви помогнат да извлечете максимума от опита си.
 
-### You don't have to contribute code
+### Не е нужно да добавяте код
 
-A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+Често срещано погрешно схващане относно приноса към отворен код е, че трябва да допринесете с код. Всъщност често другите части на проекта са [най-пренебрегвани или пренебрегвани] (https://github.com/blog/2195-the-shape-of-open-source). Ще направите _огромна_ услуга на проекта, като предложите да се включите с тези видове принос!
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
-  I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+  Известен съм с работата си върху CocoaPods, но повечето хора не знаят, че всъщност не правя реална работа върху самия инструмент CocoaPods. Времето ми по проекта минава предимно в правене на неща като документация и работа по брандиране.
   <p markdown="1" class="pquote-credit">
-— [@orta](https://github.com/orta), ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— [@orta](https://github.com/orta), ["Преминаване към OSS по подразбиране"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
   </p>
 </aside>
 
-Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+Дори ако обичате да пишете код, други видове приноси са чудесен начин да се включите в проект и да се срещнете с други членове на общността. Изграждането на тези взаимоотношения ще ви даде възможности да работите върху други части на проекта.
 
-### Do you like planning events?
+### Обичате ли да планирате събития?
 
-* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
-* Organize the project's conference (if they have one)
-* Help community members find the right conferences and submit proposals for speaking
+* Организирайте семинари или срещи за проекта, [както @fzamperin направи за NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Организирайте конференция на проекта (ако има такава)
+* Помогнете на членовете на общността да намерят правилните конференции и да представят предложения за изказване
 
-### Do you like to design?
+### Обичате ли да проектирате?
 
-* Restructure layouts to improve the project's usability
-* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
-* Put together a style guide to help the project have a consistent visual design
-* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+* Преструктурирайте оформленията, за да подобрите използваемостта на проекта
+* Извършете потребителско проучване, за да реорганизирате и прецизирате навигацията или менютата на проекта, [както предлага Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Съставете ръководство за стил, за да помогнете на проекта да има последователен визуален дизайн
+* Създайте изкуство за тениски или ново лого, [както направиха сътрудниците на hapi.js](https://github.com/hapijs/contrib/issues/68)
 
-### Do you like to write?
+### Обичаш ли да пишеш?
 
-* Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
-* Curate a folder of examples showing how the project is used
-* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/)
-* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
-* Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
+* Напишете и подобрете документацията на проекта, [както @CBID2 направи за документацията на OpenSauced](https://github.com/open-sauced/docs/pull/151)
+* Подгответе папка с примери, показващи как се използва проектът
+* Стартирайте бюлетин за проекта или подредете акценти от пощенския списък, [както направи @opensauced за своя продукт](https://news.opensauced.pizza/about/)
+* Напишете уроци за проекта, [както направиха сътрудниците на PyPA] (https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Напишете превод за документацията на проекта, [както @frontendwizard направи за инструкциите за CSS Flexbox предизвикателството на freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
-  Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+  Сериозно, \[документацията\] е изключително важна. Документацията досега беше страхотна и беше убийствена характеристика на Babel. Има раздели, които със сигурност биха могли да поработят и дори добавянето на параграф тук или там е изключително ценено.
   <p markdown="1" class="pquote-credit">
-— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+— @kittens, ["Покана за сътрудници"](https://github.com/babel/babel/issues/1347)
   </p>
 </aside>
 
-### Do you like organizing?
+### Обичате ли да организирате?
 
-* Link to duplicate issues, and suggest new issue labels, to keep things organized
-* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
-* Ask clarifying questions on recently opened issues to move the discussion forward
+* Връзка към дублирани проблеми и предлагане на теми за нови проблеми, за да поддържате организацията
+* Прегледайте отворените проблеми и предложете затваряне на стари, [както направи @nzakas за ESLint] (https://github.com/eslint/eslint/issues/6765)
+* Задавайте изясняващи въпроси по наскоро открити въпроси, за да придвижите дискусията напред
 
-### Do you like to code?
+### Обичате ли да кодирате?
 
-* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
-* Ask if you can help write a new feature
-* Automate project setup
-* Improve tooling and testing
+* Намерете открит проблем, който да решите, [както @dianjin направи за Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Попитайте дали можете да помогнете за записването на нова функция
+* Автоматизирайте настройките на проекта
+* Подобрете инструментите и тестването
 
-### Do you like helping people?
+### Обичате ли да помагате на хората?
 
-* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
-* Answer questions for people on open issues
-* Help moderate the discussion boards or conversation channels
+* Отговорете на въпроси относно проекта напр. Stack Overflow ([като този пример на Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying) -to-ge)) или Reddit
+* Отговаряйте на въпроси за хора по отворени въпроси
+* Помогнете за модерирането на дискусионните табла или каналите за разговори
 
-### Do you like helping others code?
+### Обичате ли да помагате на другите да кодират?
 
-* Review code on other people's submissions
-* Write tutorials for how a project can be used
-* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+* Прегледайте кода на изявленията на други хора
+* Напишете уроци за това как може да се използва проект
+* Предложете да наставлявате друг сътрудник, [както @ereichert направи за @bronzdoc в Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
 
-### You don't just have to work on software projects!
+### Не е нужно просто да работите върху софтуерни проекти!
 
-While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+Докато „отворен код“ често се отнася до софтуер, можете да си сътрудничите по почти всичко. Има книги, рецепти, списъци и класове, които се разработват като проекти с отворен код.
 
-For example:
+Например:
 
-* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
-* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
-* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+* @sindresorhus подготвя [списък с „страхотни“ списъци](https://github.com/sindresorhus/awesome)
+* @h5bp поддържа [списък с потенциални въпроси за интервю](https://github.com/h5bp/Front-end-Developer-Interview-Questions) за кандидати за фронтенд разработчици
+* @stuartlynn и @nicole-a-tesla направиха [колекция от забавни факти за пуфините](https://github.com/stuartlynn/puffin_facts)
 
-Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
+Дори и да сте разработчик на софтуер, работата по проект за документация може да ви помогне да започнете работа с отворен код. Често е по-малко смущаващо да работите по проекти, които не включват код, а процесът на сътрудничество ще изгради вашата увереност и опит.
 
 ## Orienting yourself to a new project
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
-  If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+  Ако отидете на инструмент за проследяване на проблеми и нещата изглеждат объркващи, не сте само вие. Тези инструменти изискват много имплицитни знания, но хората могат да ви помогнат да се ориентирате в тях и можете да им задавате въпроси.
   <p markdown="1" class="pquote-credit">
-— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+— @shaunagm, ["Как да допринесете за отворения код"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
   </p>
 </aside>
 
-For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+За нещо повече от поправка на печатна грешка, да допринесете за отворен код е като да отидете до група непознати на парти. Ако започнете да говорите за лами, докато те бяха потънали в дискусия за златните рибки, вероятно ще ви погледнат малко странно.
 
-Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
+Преди да се включите сляпо със собствените си предложения, започнете, като се научите как да четете стаята. По този начин увеличавате шансовете вашите идеи да бъдат забелязани и чути.
 
-### Anatomy of an open source project
+### Анатомия на проект с отворен код
 
-Every open source community is different.
+Всяка общност с отворен код е различна.
 
-Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+Прекарването на години в един проект с отворен код означава, че сте се запознали с един проект с отворен код. Преминете към друг проект и може да откриете, че речникът, нормите и стиловете на комуникация са напълно различни.
 
-That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+Въпреки това много проекти с отворен код следват подобна организационна структура. Разбирането на различните роли в общността и цялостния процес ще ви помогне бързо да се ориентирате към всеки нов проект.
 
-A typical open source project has the following types of people:
+Типичен проект с отворен код има следните типове хора:
 
-* **Author:** The person/s or organization that created the project
-* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
-* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
-* **Contributors:** Everyone who has contributed something back to the project
-* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+* **Автор:** Лицето/лицата или организацията, създали проекта
+* **Собственик:** Лицето/лицата, което има административна собственост върху организацията или хранилището (не винаги е същото като оригиналния автор)
+* **Поддържащи:** Сътрудници, които са отговорни за управлението на визията и управлението на организационните аспекти на проекта (Те също могат да бъдат автори или собственици на проекта.)
+* **Сътрудници:** Всеки, който е допринесъл с нещо обратно към проекта
+* **Членове на общността:** Хората, които използват проекта. Те могат да бъдат активни в разговорите или да изразят мнението си за посоката на проекта
 
-Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+По-големите проекти могат също да имат подкомисии или работни групи, фокусирани върху различни задачи, като инструменти, сортиране, модериране на общността и организиране на събития. Потърсете в уебсайта на даден проект страница за „екип“ или в хранилището за документация за управление, за да намерите тази информация.
 
-A project also has documentation. These files are usually listed in the top level of a repository.
+Към проекта има и документация. Тези файлове обикновено са изброени в горното ниво на хранилището.
 
-* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
-* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
-* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).
-* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
-* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
+* **ЛИЦЕНЗ:** По дефиниция всеки проект с отворен код трябва да има [лиценз за отворен код](https://choosealicense.com). Ако проектът няма лиценз, той не е с отворен код.
+* **README:** README е ръководството с инструкции, което приветства новите членове на общността в проекта. Той обяснява защо проектът е полезен и как да започнете.
+* **ПРИНОС:** Докато README помагат на хората да _използват_ проекта, допринасящите документи помагат на хората да _допринасят_ за проекта. Той обяснява какви видове вноски са необходими и как работи процесът. Въпреки че не всеки проект има ПРИНОСЯЩ файл, присъствието му сигнализира, че това е приветлив проект, за който можете да допринесете. Добър пример за ефективно ръководство за принос би било това от [хранилището на документи на Codecademy](https://www.codecademy.com/resources/docs/contribution-guide).
+* **CODE_OF_CONDUCT:** Кодексът за поведение определя основните правила за свързаното поведение на участниците и спомага за създаването на приятелска, гостоприемна среда. Въпреки че не всеки проект има файл CODE_OF_CONDUCT, присъствието му сигнализира, че това е приветлив проект, за който можете да допринесете.
+* **Друга документация:** Може да има допълнителна документация, като уроци, инструкции или политики за управление, особено за по-големи проекти като [Astro Docs](https://docs.astro.build/en/contribute/#contributing -към-документи).
 
-Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+И накрая, проектите с отворен код използват следните инструменти за организиране на дискусия. Четенето на архивите ще ви даде добра представа за това как общността мисли и работи.
 
-* **Issue tracker:** Where people discuss issues related to the project.
-* **Pull requests:** Where people discuss and review changes that are in progress whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), use certain GitHub Action flows to automate and quicken their code reviews.  
-* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/)
-* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/).
+* **Проследяване на проблеми:** Където хората обсъждат въпроси, свързани с проекта.
+* **Заявки за изтегляне:** Когато хората обсъждат и преглеждат промените, които са в ход, независимо дали са за подобряване на реда код на сътрудника, използването на граматика, използването на изображения и т.н. Някои проекти, като [MDN Web Docs](https: //github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), използват определени потоци за действие на GitHub, за да автоматизират и ускорят своите прегледи на кода.
+* **Дискусионни форуми или пощенски списъци:** Някои проекти могат да използват тези канали за теми за разговор (например _"Как да..."_ или _"Какво мислиш за..."_ вместо грешка отчети или заявки за функции). Други използват инструмента за проследяване на проблеми за всички разговори. Добър пример за това би бил [седмичният бюлетин на CHAOSS](https://chaoss.community/news/)
+* **Синхронен чат канал:** Някои проекти използват чат канали (като Slack или IRC) за непринуден разговор, сътрудничество и бърз обмен. Добър пример за това би била [общността на Discord на EddieHub](http://discord.eddiehub.org/).
 
-## Finding a project to contribute to
+## Намиране на проект, за който да допринесете
 
-Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+Сега, след като разбрахте как работят проектите с отворен код, време е да намерите проект, за който да допринесете!
 
-If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said:, _"Ask not what your country can do for you - ask what you can do for your country."_
+Ако никога преди не сте допринасяли за отворения код, приемете съвет от президента на САЩ Джон Ф. Кенеди, който веднъж каза: „Не питайте какво вашата страна може да направи за вас – попитайте какво можете да направите вие за вашата страна.“_
 
 <aside markdown="1" class="pquote">
   <img src="/assets/images/how-to-contribute/johnfkennedy.jpg" class="pquote-avatar" alt="avatar">
-  Ask not what your country can do for you - ask what you can do for your country.
+  Не питайте какво вашата страна може да направи за вас - попитайте какво можете да направите за вашата страна.
   <p markdown="1" class="pquote-credit">
-— [_John F. Kennedy Library_](https://www.jfklibrary.org/learn/education/teachers/curricular-resources/ask-not-what-your-country-can-do-for-you)
+— [_Библиотека Джон Ф. Кенеди_](https://www.jfklibrary.org/learn/education/teachers/curricular-resources/ask-not-what-your-country-can-do-for-you)
   </p>
 </aside>
 
-Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+Приносът към отворения код се случва на всички нива, във всички проекти. Не е нужно да мислите прекалено много какъв точно ще бъде първият ви принос или как ще изглежда.
 
-Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+Вместо това започнете, като помислите за проектите, които вече използвате или искате да използвате. Проектите, за които ще участвате активно, са тези, към които се връщате.
 
-Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+В рамките на тези проекти, всеки път, когато се хванете, че мислите, че нещо може да бъде по-добро или различно, действайте според инстинкта си.
 
-Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+Отвореният код не е изключителен клуб; направено е от хора точно като вас. „Отворен код“ е просто фантастичен термин за третиране на световните проблеми като поправими.
 
-You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
+Може да сканирате README и да намерите повредена връзка или правописна грешка. Или сте нов потребител и сте забелязали, че нещо е счупено, или проблем, който смятате, че наистина трябва да бъде в документацията. Вместо да го игнорирате и да продължите напред, или да помолите някой друг да го поправи, вижте дали можете да помогнете, като се включите. Това е смисълът на отворения код!
 
-> According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as  typo fixes, reformatting, or writing a translation.
+> Според проучване, проведено от Игор Щайнмахер и други изследователи на компютърните науки, [28% от случайните приноси](https://www.igor.pro.br/publica/papers/saner2016.pdf) в отворен код са документация, като като корекции на печатни грешки, преформатиране или писане на превод.
 
-If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+Ако търсите съществуващи проблеми, които можете да коригирате, всеки проект с отворен код има страница `/contribute`, която подчертава лесни за начинаещи проблеми, с които можете да започнете. Отидете до главната страница на хранилището в GitHub и добавете `/contribute` в края на URL адреса (например [`https://github.com/facebook/react/contribute`](https://github. com/facebook/react/contribute)).
 
-You can also use one of the following resources to help you discover and contribute to new projects:
+Можете също да използвате един от следните ресурси, за да ви помогне да откриете и допринесете за нови проекти:
 
 * [GitHub Explore](https://github.com/explore/)
 * [Open Source Friday](https://opensourcefriday.com)
@@ -225,84 +225,84 @@ You can also use one of the following resources to help you discover and contrib
 * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
 * [OpenSauced](https://opensauced.pizza/)
 
-### A checklist before you contribute
+### Контролен списък, преди да допринесете
 
-When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+Когато намерите проект, за който искате да допринесете, направете бързо сканиране, за да се уверите, че проектът е подходящ за приемане на приноси. В противен случай вашата упорита работа може никога да не получи отговор.
 
-Here's a handy checklist to evaluate whether a project is good for new contributors.
+Ето един удобен контролен списък, за да оцените дали даден проект е добър за нови сътрудници.
 
-**Meets the definition of open source**
+**Отговаря на определението за отворен код**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-  Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+  Има ли лиценз? Обикновено в корена на хранилището има файл, наречен ЛИЦЕНЗ.
   </label>
 </div>
 
-**Project actively accepts contributions**
+**Проектът активно приема вноски**
 
-Look at the commit activity on the main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
+Погледнете активността на комит в главния клон. В GitHub можете да видите тази информация в раздела Insights на началната страница на хранилище, като например [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-  When was the latest commit?
+  Кога беше последният ангажимент?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-  How many contributors does the project have?
+  Колко сътрудници има проектът?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-  How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+  Колко често хората се ангажират? (В GitHub можете да намерите това, като щракнете върху „Комити“ в горната лента.)
   </label>
 </div>
 
-Next, look at the project's issues.
+След това разгледайте проблемите на проекта.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    How many open issues are there?
+    Колко отворени въпроси има?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to issues when they are opened?
+    Поддържащите реагират ли бързо на проблеми, когато те бъдат отворени?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the issues?
+    Има ли активна дискусия по проблемите?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-    Are the issues recent?
+    Проблемите скорошни ли са?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+    Приключват ли се проблемите? (В GitHub щракнете върху раздела „затворен“ на страницата с проблеми, за да видите затворени проблеми.)
   </label>
 </div>
 
-Now do the same for the project's pull requests.
+Сега направете същото за заявките за изтегляне на проекта.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
@@ -314,213 +314,213 @@ Now do the same for the project's pull requests.
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox20" class="overflow-hidden d-block text-normal">
-    Do maintainers respond quickly to pull requests when they are opened?
+    Поддържащите реагират ли бързо на заявки за изтегляне, когато бъдат отворени?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Is there active discussion on the pull requests?
+    Има ли активно обсъждане на заявките за изтегляне?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    Are the pull requests recent?
+    Скорошни ли са заявките за изтегляне?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox13" class="overflow-hidden d-block text-normal">
-    How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+    Колко наскоро бяха обединени всички заявки за изтегляне? (В GitHub щракнете върху раздела „затворено“ на страницата „Заявки за изтегляне“, за да видите затворени PR-и.)
   </label>
 </div>
 
 **Project is welcoming**
 
-A project that is friendly and welcoming signals that they will be receptive to new contributors.
+Проект, който е приятелски настроен и гостоприемен, сигнализира, че те ще бъдат възприемчиви към нови сътрудници.
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox14" class="overflow-hidden d-block text-normal">
-    Do the maintainers respond helpfully to questions in issues?
+    Поддържащите отговарят ли услужливо на въпроси в проблеми?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox15" class="overflow-hidden d-block text-normal">
-    Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+    Хората дружелюбни ли са в проблемите, дискусионния форум и чата (например IRC или Slack)?
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox16" class="overflow-hidden d-block text-normal">
-    Do pull requests get reviewed?
+    Преглеждат ли се заявките за изтегляне?
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox17" class="overflow-hidden d-block text-normal">
-    Do maintainers thank people for their contributions?
+    Поддържащите благодарят ли на хората за техния принос?
   </label>
 </div>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-  Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+  Всеки път, когато видите дълга нишка, проверете на място отговорите от основните разработчици, идващи късно в нишката. Обобщават ли конструктивно и предприемат ли стъпки, за да доведат нишката до решение, като същевременно остават учтиви? Ако видите да се водят много пламъчни войни, това често е знак, че енергията отива в спор, вместо в развитие.
   <p markdown="1" class="pquote-credit">
-— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+— @kfogel, [_Произвеждайте OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
   </p>
 </aside>
 
-## How to submit a contribution
+## Как да изпратите принос
 
-You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+Намерихте проект, който харесвате, и сте готови да дадете своя принос. Най-накрая! Ето как да получите своя принос по правилния начин.
 
-### Communicating effectively
+### Ефективна комуникация
 
-Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+Независимо дали сте сътрудник еднократно, или се опитвате да се присъедините към общност, работата с други е едно от най-важните умения, които ще развиете в отворен код.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
-  \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+  \[Като нов сътрудник,\] бързо осъзнах, че трябва да задавам въпроси, ако искам да мога да затворя проблема. Прегледах набързо кодовата база. След като усетих какво се случва, помолих за повече насоки. И готово! Успях да разреша проблема, след като получих всички необходими подробности.
   <p markdown="1" class="pquote-credit">
-— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+— @shubheksha, [Много неравномерно пътешествие за начинаещи през света на отворения код](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
   </p>
 </aside>
 
-Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+Преди да отворите проблем или заявка за изтегляне, или да зададете въпрос в чата, имайте предвид тези моменти, за да помогнете на вашите идеи да се реализират ефективно.
 
-**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+**Дайте контекст.** Помогнете на другите да навлязат бързо. Ако попаднете на грешка, обяснете какво се опитвате да направите и как да я възпроизведете. Ако предлагате нова идея, обяснете защо смятате, че би била полезна за проекта (не само за вас!).
 
-> 😇 _"X doesn't happen when I do Y"_
+> 😇 _"X не се случва, когато направя Y"_
 >
-> 😢 _"X is broken! Please fix it."_
+> 😢 _"X е повреден! Моля, поправете го."_
 
-**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn.
+**Напишете си домашното предварително.** Добре е да не знаете нещата, но покажете, че сте опитали. Преди да поискате помощ, не забравяйте да проверите README на проекта, документацията, проблемите (отворени или затворени), пощенския списък и потърсете в интернет за отговор. Хората ще го оценят, когато демонстрирате, че се опитвате да учите.
 
-> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+> 😇 _"Не съм сигурен как да внедря X. Проверих помощните документи и не намерих никакви споменавания."_
 >
-> 😢 _"How do I X?"_
+> 😢 _"Как да направя X?"_
 
-**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+**Поддържайте заявките кратки и директни.** Подобно на изпращането на имейл, всеки принос, без значение колко прост или полезен, изисква преглед от някой друг. Много проекти имат повече входящи заявки, отколкото хора, които могат да помогнат. Бъдете кратки. Ще увеличите шанса някой да може да ви помогне.
 
-> 😇 _"I'd like to write an API tutorial."_
+> 😇 _"Бих искал да напиша урок за API."_
 >
-> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+> 😢 _"Онзи ден карах по магистралата и спрях за газ и тогава ми хрумна тази невероятна идея за нещо, което трябва да направим, но преди да обясня това, нека ви покажа..."_
 
-**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+**Пазете цялата комуникация публична.** Въпреки че е изкушаващо, не се свързвайте лично с поддържащите, освен ако не трябва да споделите чувствителна информация (като проблем със сигурността или сериозно нарушение на поведението). Когато поддържате разговора публичен, повече хора могат да научат и да се възползват от вашия обмен. Дискусиите могат сами по себе си да бъдат принос.
 
-> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+> 😇 _(като коментар) "@-maintainer Здравейте! Как да продължим с този PR?"_
 >
-> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+> 😢 _(като имейл) „Здравейте, съжалявам, че ви безпокоя по имейл, но се чудех дали сте имали възможност да прегледате моя PR“_
 
-**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+**Добре е да задавате въпроси (но бъдете търпеливи!).** Всеки е бил нов в проекта в някакъв момент и дори опитните сътрудници трябва да навлизат в крак, когато разглеждат нов проект. По същия принцип дори дългогодишните поддържащи не винаги са запознати с всяка част от проекта. Покажете им същото търпение, което бихте искали те да проявяват към вас.
 
-> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+> 😇 _"Благодаря, че разгледахте тази грешка. Следвах вашите предложения. Ето резултата."_
 >
-> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+> 😢 _"Защо не можете да решите проблема ми? Това не е ли вашият проект?"_
 
-**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+**Уважавайте решенията на общността.** Вашите идеи може да се различават от приоритетите или визията на общността. Те могат да предложат обратна връзка или да решат да не следват вашата идея. Въпреки че трябва да обсъждате и търсите компромис, поддържащите трябва да живеят с вашето решение по-дълго, отколкото вие ще го направите. Ако не сте съгласни с тяхната посока, винаги можете да работите върху своя собствена вилица или да започнете свой собствен проект.
 
-> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+> 😇 _"Разочарован съм, че не можете да подкрепите моя случай на употреба, но както обяснихте, той засяга само малка част от потребителите, разбирам защо. Благодаря, че ме изслушахте."_
 >
-> 😢 _"Why won't you support my use case? This is unacceptable!"_
+> 😢 _"Защо не подкрепите моя случай на употреба? Това е неприемливо!"_
 
-**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+**Преди всичко го поддържайте елегантно.** Отвореният код се състои от сътрудници от цял свят. Контекстът се губи между езиците, културите, географията и часовите зони. Освен това писмената комуникация прави по-трудно предаването на тон или настроение. Предполагайте добри намерения в тези разговори. Добре е учтиво да отхвърлите идея, да поискате повече контекст или да изясните допълнително позицията си. Просто се опитайте да оставите интернет по-добро място, отколкото когато сте го намерили.
 
-### Gathering context
+### Събиране на контекст
 
-Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+Преди да предприемете нещо, направете бърза проверка, за да се уверите, че идеята ви не е била обсъждана другаде. Прегледайте README на проекта, проблеми (отворени и затворени), пощенски списък и Stack Overflow. Не е нужно да прекарвате часове в разглеждане на всичко, но бързото търсене на няколко ключови термина върши дълъг път.
 
-If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by doing the following:
+Ако не можете да намерите идеята си другаде, вие сте готови да предприемете ход. Ако проектът е в GitHub, вероятно ще комуникирате, като направите следното:
 
-* **Raising an Issue:** These are like starting a conversation or discussion
-* **Pull requests** are for starting work on a solution.
-* **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution.
+* **Повдигане на проблем:** Това е като започване на разговор или дискусия
+* **Заявките за изтегляне** са за започване на работа по решение.
+* **Канали за комуникация:** Ако проектът има определен Discord, IRC или Slack канал, помислете дали да започнете разговор или да поискате разяснение относно вашия принос.
 
-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.
+Преди да отворите проблем или заявка за изтегляне, проверете допринасящите документи на проекта (обикновено файл, наречен CONTRIBUTING или в README), за да видите дали трябва да включите нещо конкретно. Например, те могат да поискат да следвате шаблон или да изискват да използвате тестове.
 
-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.
+Ако искате да направите значителен принос, отворете проблем, който да попитате, преди да работите по него. Полезно е да гледате проекта известно време (в GitHub, [можете да щракнете върху „Гледане“](https://help.github.com/articles/watching-repositories/), за да бъдете уведомени за всички разговори) и да стигнете до познавайте членовете на общността, преди да вършите работа, която може да не бъде приета.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
-  You'll learn <em>a lot</em> from taking a single project you actively use, "watching" it on GitHub and reading every issue and PR.
+  Ще научите <em>много</em>, като вземете един проект, който активно използвате, „гледате“ го в GitHub и четете всеки брой и PR.
 <p markdown="1" class="pquote-credit">
-— @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
+— @gaearon [за присъединяване към проекти](https://twitter.com/dan_abramov/status/819555257055322112)
   </p>
 </aside>
 
-### Opening an issue
+### Отваряне на проблем
 
-You should usually open an issue in the following situations:
+Обикновено трябва да отворите проблем в следните ситуации:
 
-* Report an error you can't solve yourself
-* Discuss a high-level topic or idea (for example, community, vision or policies)
-* Propose a new feature or other project idea
+* Докладвайте за грешка, която не можете да разрешите сами
+* Обсъдете тема или идея на високо ниво (например общност, визия или политики)
+* Предложете нова функция или друга идея за проект
 
-Tips for communicating on issues:
+Съвети за комуникация по проблеми:
 
-* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
-* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
-* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+* **Ако видите отворен проблем, с който искате да се заемете**, коментирайте проблема, за да уведомите хората, че работите по него. По този начин е по-малко вероятно хората да дублират вашата работа.
+* **Ако даден проблем е открит преди известно време,** е възможно той да се адресира някъде другаде или вече да е разрешен, така че коментирайте, за да поискате потвърждение, преди да започнете работа.
+* **Ако сте отворили проблем, но сте разбрали отговора по-късно сами,** коментирайте проблема, за да уведомите хората, след което затворете проблема. Дори документирането на този резултат е принос към проекта.
 
-### Opening a pull request
+### Отваряне на заявка за изтегляне
 
-You should usually open a pull request in the following situations:
+Обикновено трябва да отворите заявка за изтегляне в следните ситуации:
 
-* Submit small fixes such as a typo, a broken link or an obvious error.
-* Start work on a contribution that was already asked for, or that you've already discussed, in an issue.
+* Изпратете малки корекции като печатна грешка, повредена връзка или очевидна грешка.
+* Започнете работа по принос, който вече е поискан или който вече сте обсъждали в даден брой.
 
-A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later.
+Заявката за изтегляне не трябва да представлява завършена работа. Обикновено е по-добре да отворите заявка за изтегляне рано, така че другите да могат да гледат или да дадат обратна връзка за напредъка ви. Просто го отворете като „чернова“ или маркирайте като „WIP“ (Работа в процес) в реда за тема или в секциите „Бележки към рецензентите“, ако са предоставени (или можете просто да създадете свой собствен. Подобно на това: `**## Бележки към рецензента**`). Винаги можете да добавите още ангажименти по-късно.
 
-If the project is on GitHub, here's how to submit a pull request:
+Ако проектът е в GitHub, ето как да изпратите заявка за изтегляне:
 
-* **[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/).)
-* **[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.
-* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. It's important to make sure your changes don't break the existing project.
-* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+* **[Разклонете хранилището](https://guides.github.com/activities/forking/)** и го клонирайте локално. Свържете вашето локално към оригиналното хранилище „нагоре по веригата“, като го добавите като дистанционно. Изтегляйте често промените от „нагоре по веригата“, така че да сте в течение, така че когато изпратите заявката си за изтегляне, конфликтите при сливане ще бъдат по-малко вероятни. (Вижте по-подробни инструкции [тук](https://help.github.com/articles/syncing-a-fork/).)
+* **[Създайте клон](https://guides.github.com/introduction/flow/)** за вашите редакции.
+* **Посочете всички съответни проблеми** или подкрепяща документация във вашия PR (например „Затваря #37.“)
+* **Включете екранни снимки преди и след**, ако вашите промени включват разлики в HTML/CSS. Плъзнете и пуснете изображенията в тялото на вашата заявка за изтегляне.
+* **Тествайте промените си!** Стартирайте промените си срещу всички съществуващи тестове, ако съществуват, и създайте нови, когато е необходимо. Важно е да се уверите, че вашите промени не нарушават съществуващия проект.
+* **Допринесете в стила на проекта** според възможностите си. Това може да означава използване на отстъпи, точка и запетая или коментари по различен начин, отколкото бихте направили във вашето собствено хранилище, но улеснява поддържащия да слива, другите да разбират и поддържат в бъдеще.
 
-If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+Ако това е първата ви заявка за изтегляне, вижте [Направете заявка за изтегляне](http://makeapullrequest.com/), която @kentcdodds създаде като видеоурок с инструкции. Можете също така да практикувате да правите заявка за изтегляне в хранилището [First Contributions](https://github.com/Roshanjossey/first-contributions), създадено от @Roshanjossey.
 
-## What happens after you submit your contribution
+## Какво се случва, след като изпратите своя принос
 
-Before we start celebrating, one of the following will happen after you submit your contribution:
+Преди да започнем да празнуваме, едно от следните ще се случи, след като изпратите своя принос:
 
-### 😭 You don't get a response
+### 😭 Не получавате отговор
 
-Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+Надяваме се, че сте [проверили проекта за признаци на активност](#a-checklist-before-you-contribute), преди да направите принос. Дори при активен проект обаче е възможно вашият принос да не получи отговор.
 
-If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+Ако не сте получили отговор повече от седмица, е честно да отговорите учтиво в същата тема, като помолите някого за преглед. Ако знаете името на подходящия човек, който да прегледа вашия принос, можете да го споменете с @ в тази нишка.
 
-**Don't reach out to that person privately**; remember that public communication is vital to open source projects.
+**Не се свързвайте лично с този човек**; не забравяйте, че публичната комуникация е жизненоважна за проектите с отворен код.
 
-If you give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+Ако дадете учтиво напомняне и все още не получите отговор, възможно е никой никога да не отговори. Чувството не е страхотно, но не позволявайте това да ви обезсърчава! 😄 Има много възможни причини, поради които не сте получили отговор, включително лични обстоятелства, които може да са извън вашия контрол. Опитайте се да намерите друг проект или начин да допринесете. Ако не друго, това е добра причина да не инвестирате твърде много време в даването на принос, преди другите членове на общността да са ангажирани и отзивчиви.
 
-### 🚧 Someone requests changes to your contribution
+### 🚧 Някой иска промени във вашия принос
 
-It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+Обичайно е да бъдете помолени да направите промени във вашия принос, независимо дали това е обратна връзка относно обхвата на вашата идея или промени в кода ви.
 
-When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286).
+Когато някой поиска промени, бъдете отзивчиви. Те са отделили време да прегледат приноса ви. Да отвориш PR и да си тръгнеш е лоша форма. Ако не знаете как да правите промени, проучете проблема и след това поискайте помощ, ако имате нужда от нея. Добър пример за това би била [обратната връзка, която друг сътрудник е дал на @a-m-lamb относно тяхната заявка за изтегляне към документите на Codecademy](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286).
 
-If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).
+Ако вече нямате време да работите по проблема поради причини като разговорът продължава от месеци и обстоятелствата ви са се променили или не можете да намерите решение, уведомете поддържащия, за да може отворете проблема за някой друг, като [@RitaDee направи за проблем в хранилището за приложения на OpenSauced](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).
 
-### 👎 Your contribution doesn't get accepted
+### 👎 Вашият принос не се приема
 
-Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+Вашият принос може или не може да бъде приет в крайна сметка. Надяваме се, че вече не сте вложили твърде много работа в него. Ако не сте сигурни защо не е приет, е напълно разумно да помолите поддържащия за обратна връзка и разяснение. В крайна сметка обаче ще трябва да уважите, че това е тяхно решение. Не спорете и не бъдете враждебни. Винаги сте добре дошли да се разклоните и да работите върху собствената си версия, ако не сте съгласни!
 
-### 🎉 Your contribution gets accepted
+### 🎉 Вашият принос се приема
 
-Hooray! You've successfully made an open source contribution!
+Ура! Успешно направихте принос с отворен код!
 
-## You did it! 🎉
+## Направи го! 🎉
 
-Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
+Независимо дали току-що сте направили първия си принос с отворен код или търсите нови начини да допринесете, надяваме се, че сте вдъхновени да предприемете действие. Дори ако вашият принос не е бил приет, не забравяйте да благодарите, когато поддържащият положил усилия да ви помогне. Отвореният код е направен от хора като вас: един проблем, заявка за изтегляне, коментар или дай пет наведнъж.

From f33b50ad2c0932c92ef7bf0ea2ac24e7cbf7a5f9 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Wed, 27 Mar 2024 13:24:47 +0100
Subject: [PATCH 651/749] traslated leadership-and-governance.md, legal.md,
 maintaining-balance-for-open-source-maintainers.md,metrics.md,
 starting-a-project.md. And with this I finished translating everything

---
 _articles/bg/leadership-and-governance.md     | 122 ++++----
 _articles/bg/legal.md                         | 148 +++++-----
 ...ing-balance-for-open-source-maintainers.md | 124 ++++----
 _articles/bg/metrics.md                       | 128 ++++-----
 _articles/bg/starting-a-project.md            | 272 +++++++++---------
 5 files changed, 397 insertions(+), 397 deletions(-)

diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
index 6fd75930d5d..e5a50aa189d 100644
--- a/_articles/bg/leadership-and-governance.md
+++ b/_articles/bg/leadership-and-governance.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Leadership and Governance
-description: Growing open source projects can benefit from formal rules for making decisions.
+lang: bg
+title: Лидерство и управление
+description: Разрастващите се проекти с отворен код могат да се възползват от формалните правила за вземане на решения.
 class: leadership
 order: 6
 image: /assets/images/cards/leadership.png
@@ -10,147 +10,147 @@ related:
   - metrics
 ---
 
-## Understanding governance for your growing project
+## Разбиране на управлението за вашия разрастващ се проект
 
-Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+Вашият проект се разраства, хората са ангажирани и вие сте ангажирани да поддържате това нещо. На този етап може да се чудите как да включите редовни сътрудници на проекта във вашия работен процес, независимо дали става дума за даване на достъп за ангажимент или разрешаване на дебати в общността. Ако имате въпроси, ние имаме отговори.
 
-## What are examples of formal roles used in open source projects?
+## Какви са примерите за официални роли, използвани в проекти с отворен код?
 
-Many projects follow a similar structure for contributor roles and recognition.
+Много проекти следват подобна структура за роли на сътрудници и признание.
 
-What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+Какво всъщност означават тези роли обаче, зависи изцяло от вас. Ето няколко типа роли, които може да разпознаете:
 
-* **Maintainer**
-* **Contributor**
-* **Committer**
+* **Поддържащ**
+* **Сътрудник**
+* **Комитер**
 
-**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+**За някои проекти „поддържащите“** са единствените хора в проект с достъп за ангажиране. В други проекти те са просто хората, които са изброени в README като поддържащи.
 
-A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+Поддържащият не е задължително да е някой, който пише код за вашия проект. Може да е някой, който е свършил много работа по евангелизирането на вашия проект, или писмена документация, която е направила проекта по-достъпен за другите. Независимо от това, което прави всеки ден, поддържащият вероятно е някой, който се чувства отговорен за посоката на проекта и се е ангажирал да го подобри.
 
-**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+**„Сътрудник“ може да бъде всеки**, който коментира проблем или заявка за изтегляне, хора, които добавят стойност към проекта (независимо дали става въпрос за сортиране на проблеми, писане на код или организиране на събития), или всеки с обединена заявка за изтегляне (може би най-тясната дефиниция на сътрудник).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+  \[За Node.js,\] всеки човек, който се появява, за да коментира проблем или да изпрати код, е член на общността на проекта. Само възможността да ги видите означава, че са преминали границата от потребител до сътрудник.
   <p markdown="1" class="pquote-credit">
 — @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
   </p>
 </aside>
 
-**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+**Терминът „извършител“** може да се използва за разграничаване на достъпа за ангажиране, който е специфичен тип отговорност, от други форми на принос.
 
-While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+Въпреки че можете да дефинирате ролите си в проекта както желаете, [помислете дали да не използвате по-широки дефиниции](../how-to-contribute/#what-it-means-to-contribute), за да насърчите повече форми на принос. Можете да използвате лидерски роли, за да признаете официално хора, които са направили изключителен принос към вашия проект, независимо от техните технически умения.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
-  You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+  Може да ме познавате като „изобретателя“ на Django...но всъщност аз съм човекът, който беше нает да работи върху нещо година след като то вече беше направено. (...) Хората подозират, че съм успешен благодарение на уменията ми за програмиране...но в най-добрия случай съм среден програмист.
   <p markdown="1" class="pquote-credit">
-— @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+— @jacobian, ["Основна бележка на PyCon 2015" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
   </p>
 </aside>
 
-## How do I formalize these leadership roles?
+## Как да формализирам тези лидерски роли?
 
-Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+Формализирането на вашите лидерски роли помага на хората да се чувстват собственост и казва на другите членове на общността към кого да търсят помощ.
 
-For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+За по-малък проект определянето на лидери може да бъде толкова просто, колкото добавянето на техните имена към вашия README или текстов файл CONTRIBUTORS.
 
-For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+За по-голям проект, ако имате уебсайт, създайте страница на екип или избройте ръководителите на проекта си там. Например [Postgres](https://github.com/postgres/postgres/) има [изчерпателна екипна страница](https://www.postgresql.org/community/contributors/) с кратки профили за всеки участник.
 
-If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+Ако вашият проект има много активна общност на сътрудници, можете да сформирате „основен екип“ от поддържащи или дори подкомитети от хора, които поемат отговорност за различни проблемни области (например сигурност, сортиране на проблеми или поведение на общността). Позволете на хората да се самоорганизират и доброволно изпълняват ролите, които ги вълнуват най-много, вместо да ги възлагат.
 
 <aside markdown="1" class="pquote">
-  \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+  \[Ние\] допълваме основния екип с няколко "подекипа". Всеки подекип е фокусиран върху конкретна област, например езиков дизайн или библиотеки. (...) За да се осигури глобална координация и силна, съгласувана визия за проекта като цяло, всеки подекип се ръководи от член на основния екип.
   <p markdown="1" class="pquote-credit">
-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+— ["RFC за управление на Rust"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
   </p>
 </aside>
 
-Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+Лидерските екипи може да искат да създадат определен канал (като в IRC) или да се срещат редовно, за да обсъждат проекта (като в Gitter или Google Hangout). Можете дори да направите тези срещи публични, така че други хора да могат да слушат. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), например, [поема работно време всяка седмица](https://github.com/cucumber/cucumber-ruby/blob/HEAD/ CONTRIBUTING.md#talking-with-other-devs).
 
-Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+След като сте установили лидерски роли, не забравяйте да документирате как хората могат да ги постигнат! Установете ясен процес за това как някой може да стане поддържащ или да се присъедини към подкомисия във вашия проект и го напишете във вашия GOVERNANCE.md.
 
-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.
+Инструменти като [Vossibility](https://github.com/icecrime/vossibility-stack) могат да ви помогнат публично да проследите кой (или не) прави принос към проекта. Документирането на тази информация избягва възприемането на общността, че поддържащите са клика, която взема решенията си частно.
 
-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).
+И накрая, ако проектът ви е в GitHub, помислете за преместване на проекта от личния ви акаунт в организация и добавяне на поне един резервен администратор. [Организациите на GitHub](https://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](.. /building-community/#share-ownership-of-your-project).
 
-## When should I give someone commit access?
+## Кога трябва да дам на някого достъп за ангажиране?
 
-Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+Някои хора смятат, че трябва да дадете достъп за ангажиране на всеки, който направи принос. Това може да насърчи повече хора да почувстват собственост върху вашия проект.
 
-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.
+Ако вашият проект е в GitHub, можете да използвате [защитени клонове](https://help.github.com/articles/about-protected-branches/), за да управлявате кой може да насочва към определен клон и при какви обстоятелства.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
-  Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+  Всеки път, когато някой ви изпрати заявка за изтегляне, дайте му достъп до вашия проект. Въпреки че в началото може да звучи невероятно глупаво, използването на тази стратегия ще ви позволи да разгърнете истинската сила на GitHub. (...) След като хората имат достъп за ангажиране, те вече не се притесняват, че корекцията им може да остане необединена... което ги кара да положат много повече работа в нея.
   <p markdown="1" class="pquote-credit">
-— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+— @felixge, ["Хакът на заявка за изтегляне"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
   </p>
 </aside>
 
-## What are some of the common governance structures for open source projects?
+## Какви са някои от общите структури на управление за проекти с отворен код?
 
-There are three common governance structures associated with open source projects.
+Има три общи структури на управление, свързани с проекти с отворен код.
 
-* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+* **BDFL:** BDFL означава „Доброжелателен диктатор за цял живот“. При тази структура един човек (обикновено първоначалният автор на проекта) има последната дума за всички основни решения по проекта. [Python](https://github.com/python) е класически пример. По-малките проекти вероятно са BDFL по подразбиране, защото има само един или двама поддържащи. Проект, който произхожда от компания, може също да попадне в категорията BDFL.
 
-* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+* **Меритокрация:** **(Забележка: терминът „меритокрация“ носи отрицателни конотации за някои общности и има [сложна социална и политическа история](http://geekfeminism.wikia.com/wiki/Meritocracy).) ** При меритокрацията на активните участници в проекти (тези, които демонстрират „заслуги“) се дава официална роля за вземане на решения. Решенията обикновено се вземат въз основа на чист консенсус при гласуване. Концепцията за меритокрация е въведена от [Фондация Apache](https://www.apache.org/); [всички проекти на Apache](https://www.apache.org/index.html#projects-list) са меритокрации. Вноски могат да се правят само от лица, представляващи себе си, а не от компания.
 
-* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
+* **Либерален принос:** При либерален модел на принос хората, които вършат най-много работа, се признават за най-влиятелни, но това се основава на текуща работа, а не на исторически принос. Решенията за големи проекти се вземат въз основа на процес на търсене на консенсус (обсъждане на основните оплаквания), а не на чисто гласуване, и се стремят да включват възможно най-много гледни точки на общността. Популярни примери за проекти, които използват либерален модел на принос, включват [Node.js](https://foundation.nodejs.org/) и [Rust](https://www.rust-lang.org/).
 
-Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+Кое трябва да използвате? От теб зависи! Всеки модел има предимства и компромиси. И въпреки че в началото може да изглеждат доста различни, и трите модела имат повече общо, отколкото изглежда. Ако се интересувате от приемането на един от тези модели, вижтеthese templates:
 
 * [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
 * [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
 * [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
 
-## Do I need governance docs when I launch my project?
+## Имам ли нужда от документи за управление, когато стартирам проекта си?
 
-There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+Няма подходящ момент да запишете управлението на вашия проект, но е много по-лесно да го дефинирате, след като видите как се развива динамиката на вашата общност. Най-добрата (и най-трудната) част от управлението с отворен код е, че е оформено от общността!
 
-Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+Някои ранни документи обаче неизбежно ще допринесат за управлението на вашия проект, така че започнете да записвате каквото можете. Например, можете да дефинирате ясни очаквания за поведение или как работи вашият процес на сътрудник, дори при стартирането на вашия проект.
 
-If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
+Ако сте част от компания, стартираща проект с отворен код, струва си да проведете вътрешна дискусия преди стартирането за това как вашата компания очаква да поддържа и да взема решения за напредъка на проекта. Можете също така да искате публично да обясните нещо конкретно за това как вашата компания ще (или няма!) да бъде включена в проекта.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
-  We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+  Назначаваме малки екипи за управление на проекти в GitHub, които всъщност работят върху тях във Facebook. Например React се управлява от React инженер.
   <p markdown="1" class="pquote-credit">
 — @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
   </p>
 </aside>
 
-## What happens if corporate employees start submitting contributions?
+## Какво се случва, ако корпоративните служители започнат да изпращат вноски?
 
-Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+Успешните проекти с отворен код се използват от много хора и компании и някои компании може в крайна сметка да имат потоци от приходи, които в крайна сметка да са свързани с проекта. Например, една компания може да използва кода на проекта като един компонент в предлагането на търговска услуга.
 
-As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+Тъй като проектът се използва по-широко, хората, които имат опит в него, стават все по-търсени - вие може да сте един от тях! - и понякога ще получават заплащане за работата, която вършат в проекта.
 
-It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+Важно е търговската дейност да се третира като нормална и просто като още един източник на енергия за развитие. Разбира се, платените разработчици не трябва да получават специално отношение спрямо неплатените; всеки принос трябва да бъде оценен според техническите си качества. Въпреки това, хората трябва да се чувстват комфортно да участват в търговска дейност и да се чувстват комфортно да посочват своите случаи на употреба, когато спорят в полза на определено подобрение или функция.
 
-"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+"Комерсиален" е напълно съвместим с "отворен код". „Търговски“ просто означава, че някъде има замесени пари – че софтуерът се използва в търговията, което е все по-вероятно, тъй като даден проект получава приемане. (Когато софтуер с отворен код се използва като част от продукт с неотворен код, цялостният продукт все още е „патентован“ софтуер, въпреки че, подобно на отворен код, може да се използва за търговски или нетърговски цели.)
 
-Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+Като всеки друг, комерсиално мотивираните разработчици печелят влияние в проекта чрез качеството и количеството на техния принос. Очевидно програмист, който получава заплащане за времето си, може да е в състояние да направи повече от някой, който не получава заплащане, но това е добре: плащането е само един от многото възможни фактори, които могат да повлияят на това колко прави някой. Поддържайте дискусиите по проекта си фокусирани върху приноса, а не върху външните фактори, които позволяват на хората да направят този принос.
 
-## Do I need a legal entity to support my project?
+## Нуждая ли се от юридическо лице, което да поддържа моя проект?
 
-You don't need a legal entity to support your open source project unless you're handling money.
+Нямате нужда от юридическо лице, за да поддържате вашия проект с отворен код, освен ако не боравите с пари.
 
-For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+Например, ако искате да създадете търговски бизнес, ще искате да създадете C Corp или LLC (ако сте базирани в САЩ). Ако просто работите по договор, свързан с вашия проект с отворен код, можете да приемате пари като едноличен собственик или да създадете LLC (ако сте базирани в САЩ).
 
-If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+Ако искате да приемате дарения за вашия проект с отворен код, можете да настроите бутон за дарение (с помощта на PayPal или Stripe, например), но парите няма да се приспадат от данъци, освен ако не сте квалифицирана организация с нестопанска цел (501c3, ако вие сте в САЩ).
 
-Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+Много проекти не желаят да преминат през неприятностите при създаването на организация с нестопанска цел, така че вместо това намират фискален спонсор с нестопанска цел. Фискален спонсор приема дарения от ваше име, обикновено в замяна на процент от дарението. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/ ), [Linux Foundation](https://www.linuxfoundation.org/projects) и [Open Collective](https://opencollective.com/opensource) са примери за организации, които служат като фискални спонсори за проекти с отворен код.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
-  Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+  Нашата цел е да предоставим инфраструктура, която общностите могат да използват, за да бъдат самоустойчиви, като по този начин създаваме среда, в която всички —„сътрудници, поддръжници, спонсори — извличат конкретни ползи от това.
   <p markdown="1" class="pquote-credit">
-— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+— @piamancini, ["Преминаване извън рамката на благотворителността"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
   </p>
 </aside>
 
-If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
+Ако вашият проект е тясно свързан с определен език или екосистема, може да има и свързана софтуерна основа, с която можете да работите. Например [Python Software Foundation](https://www.python.org/psf/) помага за поддръжката на [PyPI](https://pypi.org/), мениджъра на пакети на Python и [Node.js Foundation](https://foundation.nodejs.org/) помага за поддръжката на [Express.js](https://expressjs.com/), базирана на възли рамка.
diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
index f0727ca1200..2b602d5f5fb 100644
--- a/_articles/bg/legal.md
+++ b/_articles/bg/legal.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: The Legal Side of Open Source
-description: Everything you've ever wondered about the legal side of open source, and a few things you didn't.
+lang: bg
+title: Правната страна на отворения код
+description: Всичко, което някога сте се чудили за правната страна на отворения код, и няколко неща, които не сте се чудили.
 class: legal
 order: 10
 image: /assets/images/cards/legal.png
@@ -10,151 +10,151 @@ related:
   - leadership
 ---
 
-## Understanding the legal implications of open source
+## Разбиране на правните последици от отворения код
 
-Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this guide you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+Споделянето на вашата творческа работа със света може да бъде вълнуващо и възнаграждаващо изживяване. Това може да означава и куп правни неща, за които не сте знаели, че трябва да се тревожите. За щастие, с това ръководство не е нужно да започвате от нулата. (Преди да се задълбочите, не забравяйте да прочетете нашия [отказ от отговорност](/notices/).)
 
-## Why do people care so much about the legal side of open source?
+## Защо хората се интересуват толкова много от правната страна на отворения код?
 
-Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+Радвам се, че попита! Когато правите творческо произведение (като писане, графики или код), това произведение е под изключителни авторски права по подразбиране. Тоест законът предполага, че като автор на вашето произведение вие имате думата какво другите могат да правят с него.
 
-In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+Като цяло това означава, че никой друг не може да използва, копира, разпространява или модифицира вашата работа, без да бъде изложен на риск от премахване, разклащане или съдебни спорове.
 
-Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly give these permissions with a license.
+Отвореният код обаче е необичайно обстоятелство, тъй като авторът очаква други да използват, променят и споделят работата. Но тъй като правното подразбиране все още е изключително авторско право, трябва изрично да дадете тези разрешения с лиценз.
 
-These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions.
+Тези правила се прилагат и когато някой допринася за вашия проект. Без лиценз или друго споразумение всички приноси са изключителна собственост на техните автори. Това означава, че никой – дори вие – не може да използва, копира, разпространява или променя техния принос.
 
-Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
+И накрая, вашият проект може да има зависимости с лицензионни изисквания, за които не сте знаели. Общността на вашия проект или политиките на вашия работодател може също да изискват вашият проект да използва конкретни лицензи с отворен код. Ще разгледаме тези ситуации по-долу.
 
-## Are public GitHub projects open source?
+## Публичните GitHub проекти с отворен код ли са?
 
-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**.
+Когато [създадете нов проект](https://help.github.com/articles/creating-a-new-repository/) в GitHub, имате опцията да направите хранилището **частно** или **публично **.
 
-![Create repository](/assets/images/legal/repo-create-name.png)
+![Създаване на хранилище](/assets/images/legal/repo-create-name.png)
 
-**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+**Да направите своя проект в GitHub публичен не е същото като да лицензирате проекта си.** Публичните проекти са обхванати от [Условията за ползване на GitHub](https://help.github.com/en/github/site-policy/github- Terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), което позволява на другите да преглеждат и разклоняват вашия проект, но иначе работата ви идва без разрешения.
 
-If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+Ако искате други да използват, разпространяват, модифицират или допринасят обратно към вашия проект, трябва да включите лиценз с отворен код. Например, някой не може законно да използва която и да е част от вашия GitHub проект в своя код, дори ако е публичен, освен ако изрично не му дадете правото да го направи.
 
-## Just give me the TL;DR on what I need to protect my project.
+## Просто ми дайте TL;DR за това, от което се нуждая, за да защитя проекта си.
 
-You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+Имате късмет, защото днес лицензите за отворен код са стандартизирани и лесни за използване. Можете да копирате и поставите съществуващ лиценз директно във вашия проект.
 
-[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/).
+[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/).
 
-When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/).
+Когато създадете нов проект в GitHub, ще бъдете [помолени да добавите лиценз](https://help.github.com/articles/open-source-licensing/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
-  A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+  Стандартизираният лиценз служи като заместител за тези без правно обучение, за да знаят точно какво могат и какво не могат да правят със софтуера. Освен ако не е абсолютно необходимо, избягвайте персонализирани, модифицирани или нестандартни условия, които ще послужат като пречка за използването на кода на агенцията надолу по веригата.
   <p markdown="1" class="pquote-credit">
-— @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+— @benbalter, ["Всичко, което един държавен адвокат трябва да знае за лицензирането на&nbsp;отворен код"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
   </p>
 </aside>
 
-## Which open source license is appropriate for my project?
+## Кой лиценз с отворен код е подходящ за моя проект?
 
-It's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/) if you're starting with a blank slate. It's short, easily understood, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+Трудно е да сгрешите с [MIT License](https://choosealicense.com/licenses/mit/), ако започвате с празен лист. Той е кратък, лесен за разбиране и позволява на всеки да прави каквото и да е, стига да пази копие от лиценза, включително вашето известие за авторски права. Ще можете да пуснете проекта под различен лиценз, ако някога се наложи.
 
-Otherwise, picking the right open source license for your project depends on your objectives.
+В противен случай изборът на правилния лиценз с отворен код за вашия проект зависи от вашите цели.
 
-Your project very likely has (or will have) **dependencies**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm).
+Вашият проект много вероятно има (или ще има) **зависимости**, всяка от които ще има собствен лиценз с отворен код с условия, които трябва да спазвате. Например, ако сте с отворен код за Node.js проект, вероятно ще използвате библиотеки от Node Package Manager (npm).
 
-Dependencies with **permissive licenses** like [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause) allow you to license your project however you want.
+Зависимости с **разрешителни лицензи** като [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC ](https://choosealicense.com/licenses/isc) и [BSD](https://choosealicense.com/licenses/bsd-3-clause) ви позволяват да лицензирате проекта си както искате.
 
-Dependencies with **copyleft licenses** require closer attention. Including any library with a "strong" copyleft license like the [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), or [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) requires you to choose an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) for your project. Libraries with a "limited" or "weak" copyleft license like the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) can be included in projects with any license, provided you follow the [additional rules](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) they specify.
+Зависимостите с **лицензи за авторско право** изискват по-голямо внимание. Включително всяка библиотека със „силен“ лиценз за копиралефт като [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), или [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) изисква да изберете идентичен или [съвместим лиценз](https://www.gnu.org/licenses/license-list.en.html #GPLCompatibleLicenses) за вашия проект. Библиотеки с „ограничен“ или „слаб“ лиценз за копиралефт като [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) и [LGPL](https://choosealicense.com/licenses/lgpl -3.0/) могат да бъдат включени в проекти с произволен лиценз, при условие че следвате [допълнителните правила](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft% 20лицензите%20също%20задължават%20потребителите%20да%20издават%20своите%20промени.%20Въпреки това%2C%20това%20изискване%20се прилага%20за%20%20по-тесен%20набор%20от%20код.) посочват те.
  
-You may also want to consider the **communities** you hope will use and contribute to your project:
+Можете също така да разгледате **общностите**, които се надявате да използвате и да допринесете за вашия проект:
 
-* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
-* **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
-* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+* **Искате ли вашият проект да бъде използван като зависимост от други проекти?** Вероятно най-добре е да използвате най-популярния лиценз в съответната общност. Например [MIT](https://choosealicense.com/licenses/mit/) е най-популярният лиценз за [npm библиотеки](https://libraries.io/search?platforms=NPM).
+* **Искате ли вашият проект да се хареса на големия бизнес?** Големият бизнес може да се утеши от изричен патентен лиценз от всички сътрудници. В този случай [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) покрива вас (и тях).
+* **Искате ли вашият проект да се хареса на сътрудници, които не искат техният принос да се използва в софтуер със затворен код?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) или (ако те също не желаят да допринасят за услуги със затворен код) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) ще мине добре.
 
-Your **company** may have policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance.
+Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник ([вижте по-долу](#does-my-project-need-an-additional-contributor-agreement)), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#what-does-my-companys-legal-team-need-to-know) за насоки.
 
-When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на един от лицензите, споменати по-горе, ще направи вашия проект GitHub с отворен код. Ако искате да видите други опции, вижте [choosealicense.com](https://choosealicense.com), за да намерите правилния лиценз за вашия проект, дори ако [не е софтуер](https://choosealicense .com/non-software/).
 
-## What if I want to change the license of my project?
+## Какво ще стане, ако искам да сменя лиценза на моя проект?
 
-Most projects never need to change licenses. But occasionally circumstances change.
+Повечето проекти никога не се нуждаят от промяна на лицензи. Но понякога обстоятелствата се променят.
 
-For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+Например, докато вашият проект расте, той добавя зависимости или потребители, или вашата компания променя стратегии, всяка от които може да изисква или иска различен лиценз. Освен това, ако сте пропуснали да лицензирате проекта си от самото начало, добавянето на лиценз е на практика същото като промяната на лицензите. Има три основни неща, които трябва да имате предвид, когато добавяте или променяте лиценза на вашия проект:
 
-**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+**Сложно е.** Определянето на съвместимостта и съответствието на лиценза и кой притежава авторските права може да стане сложно и объркващо много бързо. Преминаването към нов, но съвместим лиценз за нови версии и приноси е различно от повторното лицензиране на всички съществуващи приноси. Включете юридическия си екип при първия намек за всяко желание за промяна на лицензи. Дори ако имате или можете да получите разрешение от притежателите на авторските права на вашия проект за промяна на лиценза, помислете за въздействието на промяната върху другите потребители и сътрудници на вашия проект. Мислете за промяната на лиценза като за „управленско събитие“ за вашия проект, което е по-вероятно да протече гладко с ясна комуникация и консултация със заинтересованите страни във вашия проект. Още повече причина да изберете и използвате подходящ лиценз за вашия проект от самото му начало!
 
-**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+**Съществуващият лиценз на вашия проект.** Ако съществуващият лиценз на вашия проект е съвместим с лиценза, който искате да промените, можете просто да започнете да използвате новия лиценз. Това е така, защото ако лиценз A е съвместим с лиценз B, вие ще спазвате условията на A, докато спазвате условията на B (но не непременно обратното). Така че, ако в момента използвате разрешителен лиценз (напр. MIT), можете да промените на лиценз с повече условия, стига да запазите копие от лиценза на MIT и всички свързани бележки за авторски права (т.е. да продължите да спазвате минималните условия на лиценза на MIT). Но ако текущият ви лиценз не е разрешителен (напр. copyleft или нямате лиценз) и не сте единственият притежател на авторските права, не можете просто да промените лиценза на вашия проект на MIT. По същество, с разрешителен лиценз, притежателите на авторските права на проекта са дали предварително разрешение за промяна на лицензите.
 
-**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? [People who have commits in your project](https://github.com/thehale/git-authorship) is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+**Съществуващи носители на авторски права на вашия проект.** Ако вие сте единственият сътрудник на вашия проект, тогава вие или вашата компания сте единственият носител на авторските права на проекта. Можете да добавите или промените какъвто лиценз вие или вашата компания искате. В противен случай може да има други притежатели на авторски права, от които се нуждаете от съгласие, за да промените лицензите. Кои са те? [Хората, които имат ангажименти във вашия проект](https://github.com/thehale/git-authorship) е добро място да започнете. Но в някои случаи авторските права ще се държат от работодателите на тези хора. В някои случаи хората ще са направили само минимален принос, но няма твърдо и бързо правило, че приносите под определен брой редове код не са обект на авторско право. Какво да правя? Зависи. За сравнително малък и млад проект може да е възможно да накарате всички съществуващи сътрудници да се съгласят с промяна на лиценза в проблем или заявка за изтегляне. За големи и дълготрайни проекти може да се наложи да потърсите много сътрудници и дори техните наследници. Mozilla отне години (2001-2006), за да прелицензира Firefox, Thunderbird и свързания софтуер.
 
-Alternatively, you can have contributors pre-approve certain license changes via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)). This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+Като алтернатива можете да накарате сътрудниците предварително да одобрят определени промени в лиценза чрез споразумение за допълнителен сътрудник ([вижте по-долу](#does-my-project-need-an-additional-contributor-agreement)). Това измества малко сложността на промяната на лицензите. Ще имате нужда от повече помощ от вашите адвокати предварително и все пак ще искате да комуникирате ясно със заинтересованите страни във вашия проект, когато извършвате промяна на лиценза.
 
-## 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).
+Вероятно не. За по-голямата част от проектите с отворен код лицензът с отворен код имплицитно служи както за входящ (от сътрудници), така и за изходящ (към други сътрудници и потребители) лиценз. Ако вашият проект е в GitHub, Общите условия на GitHub правят „inbound=outbound“ [изрично по подразбиране](https://help.github.com/en/github/site-policy/github-terms-of-service# 6-приноси-под-лиценз за хранилище).
 
-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.
+Допълнително споразумение за сътрудник – често наричано Споразумение за лиценз на сътрудник (CLA) – може да създаде административна работа за поддържащите проекта. Колко работа добавя едно споразумение зависи от проекта и изпълнението. Обикновено споразумение може да изисква сътрудниците да потвърдят с едно щракване, че имат правата, необходими за принос съгласно лиценза за отворен код на проекта. По-сложно споразумение може да изисква правен преглед и подписване от работодателите на сътрудниците.
 
-Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
+Освен това, чрез добавяне на „бумащина“, която според някои е ненужна, трудна за разбиране или несправедлива (когато получателят на споразумението получава повече права от сътрудниците или обществеността чрез лиценза за отворен код на проекта), допълнително споразумение за сътрудник може да се възприеме като недружелюбно към общността на проекта.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
-    We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+    Премахнахме CLA за Node.js. Това намалява бариерата за навлизане на сътрудниците на Node.js, като по този начин разширява базата на сътрудниците.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Разширяване на Node.js приноси"](https://www.joyent.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
-Some situations where you may want to consider an additional contributor agreement for your project include:
+Някои ситуации, в които може да искате да обмислите споразумение за допълнителен сътрудник за вашия проект, включват:
 
-* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
-* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
-* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
-* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
-* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
+* Вашите адвокати искат всички сътрудници изрично да приемат (_подписват_, онлайн или офлайн) условията за принос, може би защото смятат, че самият лиценз за отворен код не е достатъчен (въпреки че е!). Ако това е единствената грижа, споразумение за сътрудник, което потвърждава лиценза за отворен код на проекта, трябва да е достатъчно. [Лицензионното споразумение за jQuery Individual Contributor](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) е добър пример за леко споразумение за допълнителен сътрудник.
+* Вие или вашите адвокати искате разработчиците да декларират, че всеки ангажимент, който правят, е разрешен. Изискването за [Сертификат за произход на разработчици](https://developercertificate.org/) е колко проекта постигат това. Например общността Node.js [използва](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо](https://nodejs.org/en/blog/ uncategorized/notes-from-the-road/#easier-contribution) от техния предишен CLA. Една проста опция за автоматизиране на прилагането на DCO във вашето хранилище е [DCO Probot](https://github.com/probot/dco).
+* Вашият проект използва лиценз с отворен код, който не включва изрично предоставяне на патент (като MIT) и се нуждаете от разрешение за патент от всички сътрудници, някои от които може да работят за компании с големи патентни портфейли, които биха могли да бъдат използвани за насочване към вас или други сътрудници и потребители на проекта. [Лицензионното споразумение за личен сътрудник на Apache] (https://www.apache.org/licenses/icla.pdf) е често използвано допълнително споразумение за сътрудник, което има предоставяне на патент, отразяващо това, което се намира в Лиценза на Apache 2.0.
+* Вашият проект е под лиценз за копиралефт, но също така трябва да разпространявате собствена версия на проекта. Ще трябва всеки сътрудник да ви прехвърли авторски права или да ви предостави (но не на обществеността) разрешителен лиценз. [Споразумението за сътрудник на MongoDB] (https://www.mongodb.com/legal/contributor-agreement) е пример за този тип споразумение.
+* Смятате, че вашият проект може да се наложи да промени лицензите през целия си живот и искате участниците да се съгласят предварително с такива промени.
 
-If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+Ако все пак трябва да използвате допълнително споразумение за сътрудници с вашия проект, обмислете използването на интеграция като [CLA помощник](https://github.com/cla-assistant/cla-assistant), за да сведете до минимум разсейването на сътрудниците.
 
-## What does my company's legal team need to know?
+## Какво трябва да знае правният екип на моята компания?
 
-If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+Ако пускате проект с отворен код като служител на компанията, първо, вашият правен екип трябва да знае, че сте проект с отворен код.
 
-For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+За добро или лошо, помислете да ги уведомите дори ако това е личен проект. Вероятно имате „споразумение за интелектуална собственост на служителите“ с вашата компания, което им дава известен контрол върху вашите проекти, особено ако изобщо са свързани с бизнеса на компанията или използвате ресурси на компанията за разработване на проекта. Вашата компания _би трябвало_ лесно да ви даде разрешение и може би вече го е направила чрез удобно за служителите IP споразумение или фирмена политика. Ако не, можете да преговаряте (например да обясните, че вашият проект служи на целите на компанията за професионално обучение и развитие за вас) или да избягвате да работите по проекта си, докато не намерите по-добра компания.
 
-**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+**Ако търсите проект с отворен код за вашата компания**, тогава определено ги уведомете. Вашият правен екип вероятно вече има политики за това какъв лиценз с отворен код (и може би допълнително споразумение за сътрудници) да използва въз основа на бизнес изискванията и експертния опит на компанията за гарантиране, че вашият проект е в съответствие с лицензите на неговите зависимости. Ако не, вие и те имате късмет! Вашият правен екип трябва да е нетърпелив да работи с вас, за да разберете тези неща. Някои неща, за които да помислите:
 
-* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses ([see above](#which-open-source-license-is-appropriate-for-my-project)). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+* **Материал на трета страна:** Вашият проект има ли зависимости, създадени от други или по друг начин включва или използва чужд код? Ако те са с отворен код, ще трябва да спазвате лицензите за отворен код на материалите. Това започва с избора на лиценз, който работи с лицензи с отворен код на трети страни ([вижте по-горе](#which-open-source-license-is-appropriate-for-my-project)). Ако вашият проект модифицира или разпространява материал с отворен код на трета страна, вашият правен екип също ще иска да знае, че отговаряте на други условия на лицензите за отворен код на трета страна, като запазване на бележки за авторски права. Ако вашият проект използва чужд код, който няма лиценз с отворен код, вероятно ще трябва да помолите поддържащите трети страни да [добавят лиценз с отворен код](https://choosealicense.com/no-license/# за потребители), и ако не можете да получите такъв, спрете да използвате техния код във вашия проект.
 
-* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+* **Търговски тайни:** Помислете дали има нещо в проекта, което компанията не иска да направи достъпно за широката общественост. Ако е така, можете да отворите останалата част от проекта си, след като извлечете материала, който искате да запазите поверителен.
 
-* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement ([see above](#which-open-source-license-is-appropriate-for-my-project)).
+* **Патенти:** Вашата компания кандидатства ли за патент, за който отвореният код на вашия проект би представлявал [публично разкриване](https://en.wikipedia.org/wiki/Public_disclosure)? За съжаление може да бъдете помолени да изчакате (или може би компанията ще преразгледа разумността на приложението). Ако очаквате принос към вашия проект от служители на компании с големи патентни портфейли, вашият правен екип може да поиска да използвате лиценз с изрично предоставяне на патент от сътрудници (като Apache 2.0 или GPLv3) или допълнително споразумение за сътрудници ( [вижте по-горе](#which-open-source-license-is-appropriate-for-my-project)).
 
-* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+* **Търговски марки:** Проверете отново дали името на вашия проект [не е в конфликт със съществуващи търговски марки](../starting-a-project/#avoiding-name-conflicts). Ако използвате търговските марки на собствената си компания в проекта, проверете дали това не предизвиква конфликти. [FOSSmarks](http://fossmarks.org/) е практическо ръководство за разбиране на търговските марки в контекста на безплатни проекти с отворен код.
 
-* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+* **Поверителност:** Вашият проект събира ли данни за потребители? „Домашен телефон“ към фирмени сървъри? Вашият правен екип може да ви помогне да спазвате фирмените политики и външните разпоредби.
 
-If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+Ако пускате първия проект с отворен код на вашата компания, горното е повече от достатъчно, за да преминете (но не се притеснявайте, повечето проекти не би трябвало да предизвикват големи притеснения).
 
-Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+В по-дългосрочен план вашият правен екип може да направи повече, за да помогне на компанията да извлече повече от участието си в отворен код и да остане в безопасност:
 
-* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+* **Правила за приноса на служителите:** Помислете за разработване на корпоративна политика, която определя как вашите служители допринасят за проекти с отворен код. Ясната политика ще намали объркването сред вашите служители и ще им помогне да допринесат за проекти с отворен код в най-добрия интерес на компанията, независимо дали като част от работата им или в свободното им време. Добър пример е [Модел IP и политика за принос с отворен код] на Rackspace (https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
-  Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+  Предоставянето на IP, свързано с корекция, изгражда база от знания и репутация на служителя. Това показва, че компанията е инвестирала в развитието на този служител и създава усещане за овластяване и автономност. Всички тези предимства също водят до по-висок морал и по-добро задържане на служителите.
   <p markdown="1" class="pquote-credit">
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["Модел на IP и политика за принос с отворен код"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
   </p>
 </aside>
 
-* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
-* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+* **Какво да публикувате:** [(Почти) всичко?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Ако вашият правен екип разбира и е инвестирани в стратегията на вашата компания за отворен код, те ще могат най-добре да помогнат, вместо да пречат на вашите усилия.
+* **Съответствие:** Дори ако вашата компания не пуска проекти с отворен код, тя използва чужд софтуер с отворен код. [Осъзнаването и процесът](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) могат да предотвратят главоболия, забавяния на продукти и съдебни дела .
 
 <aside markdown="1" class="pquote">
-  Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+  Организациите трябва да разполагат с лиценз и стратегия за съответствие, които отговарят както на категориите \["permissive" и "copyleft"\]. Това започва с водене на запис на лицензионните условия, които се прилагат за софтуера с отворен код, който използвате – включително подкомпоненти и зависимости.
   <p markdown="1" class="pquote-credit">
-— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+— Heather Meeker, ["Софтуер с отворен код: Основи на съответствието и най-добри практики"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
   </p>
 </aside>
 
-* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
-* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
+* **Патенти:** Вашата компания може да пожелае да се присъедини към [Open Invention Network](https://www.openinventionnetwork.com/), споделен защитен патентен пул за защита на използването на големи проекти с отворен код от членовете, или да проучи друго [алтернативно патентно лицензиране](https://www.eff.org/document/hacking-patent-system-2016).
+* **Управление:** Особено ако и когато има смисъл да се премести проект към [юридическо лице извън компанията](../leadership-and-governance/#do-i-need-a-legal-entity -to-support-my-project).
diff --git a/_articles/bg/maintaining-balance-for-open-source-maintainers.md b/_articles/bg/maintaining-balance-for-open-source-maintainers.md
index c418b476786..4d722cc6726 100644
--- a/_articles/bg/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/bg/maintaining-balance-for-open-source-maintainers.md
@@ -1,170 +1,170 @@
 ---
-lang: en
+lang: bg
 untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+title: Поддържане на баланс за поддържащите отворен код
+description: Съвети за самообслужване и избягване на прегаряне като поддържащ.
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+Тъй като популярността на проекта с отворен код нараства, става важно да поставите ясни граници, които да ви помогнат да поддържате баланс, за да останете освежени и продуктивни в дългосрочен план.
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+За да придобием представа за опита на поддържащите и техните стратегии за намиране на баланс, проведохме семинар с 40 членове на <a href="http://maintainers.github.com/">общността на поддържащите</a>, което ни позволи да се поучат от техния опит от първа ръка с бърнаут в отворен код и практиките, които са им помогнали да поддържат баланс в работата си. Тук влиза в действие концепцията за лична екология.
 
-So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+И така, какво е лична екология? Като <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance% 2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">описано от Rockwood Leadership Institute</a>, то включва "<strong>поддържане на баланс, темпо и ефективност за поддържане на енергията ни през целия живот</strong>." Това рамкира нашите разговори, помагайки на поддържащите да разпознаят своите действия и приноси като части от по-голяма екосистема, която се развива с течение на времето. Бърнаут, синдром в резултат на хроничен стрес на работното място, както [дефиниран от СЗО](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281) , не е необичайно сред поддържащите. Това често води до загуба на мотивация, невъзможност за фокусиране и липса на съпричастност към сътрудниците и общността, с която работите.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
-  I was unable to focus or start on a task. I had a lack of empathy for users.
+  Не можах да се съсредоточа или да започна задача. Липсваше ми съчувствие към потребителите.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, поддържащ сървъра за стрийминг на живо Owncast, за въздействието на прегарянето върху неговата работа с отворен код
   </p>
 </aside>
 
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+Възприемайки концепцията за лична екология, поддържащите могат проактивно да избягват прегарянето, да дават приоритет на грижата за себе си и да поддържат чувство за баланс, за да вършат най-добрата си работа.
 
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+## Съвети за самообслужване и избягване на прегаряне като поддържащ персонал:
 
-### Identify your motivations for working in open source
+### Определете вашите мотивации за работа с отворен код
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+Отделете време, за да помислите кои части от поддръжката с отворен код ви зареждат с енергия. Разбирането на вашата мотивация може да ви помогне да приоритизирате работата по начин, който ви държи ангажирани и готови за нови предизвикателства. Независимо дали става въпрос за положителната обратна връзка от потребителите, радостта от сътрудничеството и общуването с общността или удовлетворението от гмуркането в кода, разпознаването на вашите мотивации може да ви помогне да насочите фокуса си.
 
-### Reflect on what causes you to get out of balance and stressed out
+### Помислете какво ви кара да излизате от баланс и да сте стресирани
 
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+Важно е да разберем какво ни кара да изгаряме. Ето няколко общи теми, които видяхме сред поддържащите отворен код:
 
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+* **Липса на положителна обратна връзка:** Много по-вероятно е потребителите да се свържат, когато имат оплакване. Ако всичко работи добре, те са склонни да мълчат. Може да е обезкуражаващо да видите нарастващ списък от проблеми без положителната обратна връзка, показваща как вашият принос прави разликата.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
-  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  Понякога се чувствам малко като да крещя в празнотата и откривам, че обратната връзка наистина ме зарежда с енергия. Имаме много щастливи, но тихи потребители.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+— <a href="https://github.com/thisisnic">@thisisnic</a>, поддържащ Apache Arrow
   </p>
 </aside>
 
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **Да не казваш „не“:** Може да е лесно да поемеш повече отговорности, отколкото би трябвало за проект с отворен код. Независимо дали е от потребители, сътрудници или други поддържащи – ние не винаги можем да оправдаем техните очаквания.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
-  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  Открих, че поемам повече от един и трябва да върша работата на множество хора, както обикновено се прави във FOSS.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, поддържащ Termux, за това какво причинява прегаряне в тяхната работа
   </p>
 </aside>
 
-* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+* **Да работиш сам:** Да си поддържащ може да бъде невероятно самотен. Дори ако работите с група поддържащи, последните няколко години бяха трудни за свикване на разпределени екипи лично.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
- Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+ Особено след COVID и работата от вкъщи е по-трудно никога да не виждаш никого или да говориш с никого.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, поддържащ сървъра за стрийминг на живо Owncast, за въздействието на прегарянето върху неговата работа с отворен код
   </p>
 </aside>
 
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **Няма достатъчно време или ресурси:** Това е особено вярно за поддържащи доброволци, които трябва да жертват свободното си време, за да работят по проект.
 
 <aside markdown="1" class="pquote">
-  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  [Бих искал да имам] повече финансова подкрепа, за да мога да се съсредоточа върху работата с отворен код, без да изразходвам спестяванията си и да знам, че ще трябва да сключвам много договори, за да компенсирам това по-късно.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— поддържащ отворен код
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Противоречиви изисквания: ** Отвореният код е пълен с групи с различни мотивации, които могат да бъдат трудни за ориентиране. Ако ви се плаща да работите с отворен код, интересите на вашия работодател понякога могат да бъдат в противоречие с общността.
 
 <aside markdown="1" class="pquote">
-  With paid open source, conflict between employer's focus and what's best for the community
+  С платен отворен код, конфликт между фокуса на работодателя и най-доброто за общността
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— поддържащ отворен код
   </p>
 </aside>
 
-### Watch out for signs of burnout
+### Внимавайте за признаци на прегаряне
 
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+Можете ли да поддържате темпото си 10 седмици? 10 месеца? 10 години?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+Има инструменти като [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) от [@shaunagm](https://github.com/shaunagm), които могат да ви помогнат помислете върху текущото си темпо и вижте дали има някакви корекции, които можете да направите. Някои поддържащи също използват технология за носене, за да проследяват показатели като качество на съня и променливост на сърдечната честота (и двете свързани със стреса).
 
 <aside markdown="1" class="pquote">
- I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+ Аз съм голям привърженик на добрите облекла. С науката зад това можете да разберете как бихте могли да се справите по-добре и как да стигнете до оптимално състояние на това, което искате да правите.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— поддържащ отворен код
   </p>
 </aside>
 
-### What would you need to continue sustaining yourself and your community?
+### От какво се нуждаете, за да продължите да поддържате себе си и общността си?
 
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+Това ще изглежда различно за всеки поддържащ и ще се променя в зависимост от вашата фаза от живота и други външни фактори. Но ето няколко теми, които чухме:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **Разчитайте на общността:** Делегирането и намирането на сътрудници може да облекчи работното натоварване. Наличието на множество точки за контакт за даден проект може да ви помогне да си починете, без да се притеснявате. Свържете се с други поддържащи и по-широката общност – в групи като [Maintainer Community](http://maintainers.github.com/). Това може да бъде чудесен ресурс за партньорска подкрепа и обучение.
 
-  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+   Можете също така да търсите начини да се ангажирате с потребителската общност, така че да можете редовно да чувате обратна връзка и да разбирате въздействието на вашата работа с отворен код.
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **Разгледайте финансирането:** Независимо дали търсите малко пари за пица или се опитвате да преминете на пълен работен ден към отворен код, има много ресурси, които да ви помогнат! Като първа стъпка помислете дали да не включите [Спонсорите на GitHub](https://github.com/sponsors), за да позволите на други да спонсорират вашата работа с отворен код. Ако обмисляте да преминете към пълен работен ден, кандидатствайте за следващия кръг на [GitHub Accelerator](http://accelerator.github.com/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
- I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+ Бях в подкаст преди малко и си говорехме за поддръжка с отворен код и устойчивост. Открих, че дори малък брой хора, които подкрепят работата ми в GitHub, ми помогнаха да взема бързо решение да не седя пред игра, а вместо това да направя едно малко нещо с отворен код.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+— <a href="https://github.com/mansona">@mansona</a>, поддържащ EmberJS
   </p>
 </aside>
 
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+* **Използвайте инструменти:** Разгледайте инструменти като [GitHub Copilot](https://github.com/features/copilot/) и [GitHub Actions](https://github.com/features/actions), за да автоматизирате светски задачи и освободете времето си за по-значими приноси.
 
 <aside markdown="1" class="pquote">
- Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+ Use [Copilot](https://github.com/features/copilot/) за скучните неща - правете забавните неща
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— поддържащ отворен код
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+* **Почивка и презареждане:** Отделете време за вашите хобита и интереси извън отворен код. Вземете почивни дни, за да се отпуснете и да се подмладите – и задайте своя [статус в GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your- profile/personalizing-your-profile#setting-a-status), за да отразява вашата наличност! Добрият нощен сън може да направи голяма разлика в способността ви да поддържате усилията си в дългосрочен план.
 
-  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+   Ако намирате определени аспекти от вашия проект за особено приятни, опитайте се да структурирате работата си, така че да можете да я изживявате през целия си ден.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+ Намирам повече възможност да поръся „моменти на творчество“ в средата на деня, вместо да се опитвам да се изключа вечер.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+— <a href="https://github.com/danielroe">@danielroe</a>, поддържащ Nuxt
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **Задайте граници:** Не можете да кажете „да“ на всяка молба. Това може да бъде толкова просто, колкото да кажете: „Не мога да стигна до това в момента и нямам планове за бъдещето“ или да посочите какво искате да правите и какво да не правите в README. Например, можете да кажете: „Аз обединявам само PR-и, които имат ясно изброени причини, поради които са направени“, или „Преглеждам проблемите само в четвъртък от 18 до 19 часа“. Това определя очакванията за другите и ви дава нещо да посочите в други моменти, за да помогнете за намаляване на изискванията от сътрудници или потребители във вашето време.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+За да се доверите смислено на другите по тези оси, не можете да сте някой, който казва „да“ на всяка молба. Правейки това, вие не поддържате никакви граници, професионално или лично, и няма да бъдете надежден колега.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, поддържащ Homebrew на [Saying No](https://mikemcquaid.com/saying-no/)
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+  Научете се да сте твърди в спирането на токсичното поведение и негативните взаимодействия. Добре е да не давате енергия на неща, които не ви интересуват.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-My software is gratis, but my time and attention is not.
+Моят софтуер е безплатен, но моето време и внимание не са.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, поддържащ Leaflet
   </p>
 </aside>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+Не е тайна, че поддръжката с отворен код има своите тъмни страни и една от тях е понякога да се налага да взаимодействате с доста неблагодарни, имащи право или направо токсични хора. С нарастването на популярността на даден проект нараства и честотата на този вид взаимодействие, което увеличава тежестта, поета от поддържащите, и вероятно се превръща в значителен рисков фактор за прегаряне на поддържащия.  
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>, поддържащ Octoprint на [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
 </aside>
 
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+Не забравяйте, че личната екология е постоянна практика, която ще се развива, докато напредвате във вашето пътуване с отворен код. Като приоритизирате грижата за себе си и поддържате чувството за баланс, можете да допринесете за общността с отворен код ефективно и устойчиво, гарантирайки както вашето благополучие, така и успеха на вашите проекти в дългосрочен план.
 
-## Additional Resources
+## Допълнителни ресурси
 
 * [Maintainer Community](http://maintainers.github.com/)
 * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
@@ -176,11 +176,11 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
 * Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
 
-## Contributors
+## Сътрудници
 
-Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+Много благодаря на всички поддържащи, които споделиха своя опит и съвети с нас за това ръководство!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+Това ръководство е написано от [@abbycabs](https://github.com/abbycabs) с принос от: 
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
@@ -217,4 +217,4 @@ This guide was written by [@abbycabs](https://github.com/abbycabs) with contribu
 [@thisisnic](https://github.com/thisisnic)
 [@tudoramariei](https://github.com/tudoramariei)
 [@UlisesGascon](https://github.com/UlisesGascon)
-[@waldyrious](https://github.com/waldyrious) + many others!
+[@waldyrious](https://github.com/waldyrious) + много други!
diff --git a/_articles/bg/metrics.md b/_articles/bg/metrics.md
index 145dd18119b..d2f4450da79 100644
--- a/_articles/bg/metrics.md
+++ b/_articles/bg/metrics.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Open Source Metrics
-description: Make informed decisions to help your open source project thrive by measuring and tracking its success.
+lang: bg
+title: Показатели за отворен код
+description: Вземете информирани решения, за да помогнете на вашия проект с отворен код да процъфтява, като измервате и проследявате неговия успех.
 class: metrics
 order: 9
 image: /assets/images/cards/metrics.png
@@ -10,119 +10,119 @@ related:
   - best-practices
 ---
 
-## Why measure anything?
+## Защо да измервате нещо?
 
-Data, when used wisely, can help you make better decisions as an open source maintainer.
+Данните, когато се използват разумно, могат да ви помогнат да вземете по-добри решения като поддържащ отворен код.
 
-With more information, you can:
+С повече информация можете:
 
-* Understand how users respond to a new feature
-* Figure out where new users come from
-* Identify, and decide whether to support, an outlier use case or functionality
-* Quantify your project's popularity
-* Understand how your project is used
-* Raise money through sponsorships and grants
+* Разберете как потребителите реагират на нова функция
+* Разберете откъде идват новите потребители
+* Идентифицирайте и решете дали да поддържате извънреден случай на употреба или функционалност
+* Определете количествено популярността на вашия проект
+* Разберете как се използва вашият проект
+* Събирайте пари чрез спонсорства и безвъзмездни средства
 
-For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+Например [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) открива, че Google Анализ им помага да приоритизират работата:
 
-> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+> Homebrew се предоставя безплатно и се управлява изцяло от доброволци в свободното им време. В резултат на това нямаме ресурсите да направим подробни потребителски проучвания на потребителите на Homebrew, за да решим как най-добре да проектираме бъдещи функции и да дадем приоритет на текущата работа. Анонимните обобщени потребителски анализи ни позволяват да приоритизираме поправки и функции въз основа на това как, къде и кога хората използват Homebrew.
 
-Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+Популярността не е всичко. Всеки влиза в отворен код по различни причини. Ако целта ви като поддържащ отворен код е да покажете работата си, да сте прозрачни относно кода си или просто да се забавлявате, показателите може да не са важни за вас.
 
-If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+Ако се интересувате от разбирането на вашия проект на по-дълбоко ниво, прочетете за начини да анализирате дейността на вашия проект.
 
-## Discovery
+## Откритие
 
-Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+Преди някой да може да използва или да допринесе обратно за вашия проект, той трябва да знае, че той съществува. Запитайте се: _хората намират ли този проект?_
 
-![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
+![Графика на трафика](/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:
+Ако вашият проект се хоства в GitHub, [можете да видите](https://help.github.com/articles/about-repository-graphs/#traffic) колко хора попадат на вашия проект и откъде идват. От страницата на вашия проект щракнете върху „Прозрения“, след това върху „Трафик“. На тази страница можете да видите:
 
-* **Total page views:** Tells you how many times your project was viewed
+* **Общ брой показвания на страници:** Ви казва колко пъти е бил прегледан вашият проект
 
-* **Total unique visitors:** Tells you how many people viewed your project
+* **Общ брой уникални посетители:** Ви казва колко души са видели проекта Ви
 
-* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+* **Препоръчващи сайтове:** Ви казва откъде идват посетителите. Този показател може да ви помогне да разберете къде да достигнете до аудиторията си и дали усилията ви за промоция работят.
 
-* **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](https://help.github.com/articles/about-stars/) също могат да помогнат за предоставяне на основна мярка за популярност. Въпреки че звездите на GitHub не са непременно свързани с изтегляния и използване, те могат да ви кажат колко хора обръщат внимание на работата ви.
 
-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.
+Може също да искате да [проследите откриваемостта на конкретни места](https://opensource.com/business/16/6/pirate-metrics): например Google PageRank, трафик от препоръчани потребители от уебсайта на вашия проект или препоръчани потребители от други отворени изходни проекти или уебсайтове.
 
-## Usage
+## Използване
 
-People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+Хората намират вашия проект в това диво и лудо нещо, което наричаме интернет. В идеалния случай, когато видят вашия проект, те ще се почувстват принудени да направят нещо. Вторият въпрос, който ще искате да зададете е: _хората използват ли този проект?_
 
-If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+Ако използвате мениджър на пакети, като npm или RubyGems.org, за разпространение на вашия проект, може да сте в състояние да проследявате изтеглянията на вашия проект.
 
-Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+Всеки мениджър на пакети може да използва малко по-различна дефиниция на „изтегляне“ и изтеглянията не са непременно свързани с инсталиранията или използването, но предоставя някаква базова линия за сравнение. Опитайте да използвате [Libraries.io](https://libraries.io/), за да проследявате статистическите данни за използването в много популярни мениджъри на пакети.
 
-If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+Ако вашият проект е в GitHub, отворете отново страницата „Трафик“. Можете да използвате [графиката за клониране](https://github.com/blog/1873-clone-graphs), за да видите колко пъти вашият проект е бил клониран за даден ден, разбити на общия брой клонинги и уникални клонинги.
 
-![Clone graph](/assets/images/metrics/clone_graph.png)
+![Графика за клониране](/assets/images/metrics/clone_graph.png)
 
-If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+Ако употребата е ниска в сравнение с броя на хората, които са открили вашия проект, трябва да имате предвид два проблема. Или:
 
-* Your project isn't successfully converting your audience, or
-* You're attracting the wrong audience
+* Вашият проект не преобразува успешно вашата аудитория, или
+* Привличате грешната аудитория
 
-For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+Например, ако вашият проект попадне на първа страница на Hacker News, вероятно ще видите скок в откриването (трафик), но по-нисък процент на реализация, защото достигате до всички в Hacker News. Ако обаче вашият Ruby проект бъде представен на Ruby конференция, е по-вероятно да видите висок процент на реализация от целева аудитория.
 
-Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+Опитайте се да разберете откъде идва вашата аудитория и помолете другите за обратна връзка на страницата на вашия проект, за да разберете с кой от тези два проблема се сблъсквате.
 
-Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+След като разберете, че хората използват вашия проект, може да искате да опитате да разберете какво правят с него. Надграждат ли го, като разклоняват вашия код и добавят функции? Използват ли го за наука или за бизнес?
 
-## Retention
+## Задържане
 
-People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+Хората намират вашия проект и го използват. Следващият въпрос, който ще искате да си зададете, е: _хората допринасят ли обратно за този проект?_
 
-It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+Никога не е твърде рано да започнете да мислите за сътрудници. Без други хора да се намесят, рискувате да се поставите в нездравословна ситуация, в която вашият проект е _популярен_ (много хора го използват), но не е _поддържан_ (няма достатъчно време за поддръжка, за да отговори на търсенето).
 
-Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+Задържането също така изисква [приток на нови сътрудници](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), тъй като предишните активни сътрудници в крайна сметка ще продължат напред към други неща.
 
-Examples of community metrics that you may want to regularly track include:
+Примери за показатели на общността, които може да искате да проследявате редовно, включват:
 
-* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+* **Общ брой сътрудници и брой ангажименти на сътрудник:** Ви казва колко сътрудници имате и кой е повече или по-малко активен. В GitHub можете да видите това под „Прозрения“ -> „Сътрудници“. В момента тази графика отчита само сътрудници, които са се ангажирали с клона по подразбиране на хранилището.
 
-![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+![Графика на сътрудник](/assets/images/metrics/repo_contributors_specific_graph.png)
 
-* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+* **Първи, случайни и повторни сътрудници:** Помага ви да проследите дали получавате нови сътрудници и дали те се връщат. (Случайните сътрудници са сътрудници с малък брой ангажименти. Дали това е един комит, по-малко от пет ангажимента или нещо друго зависи от вас.) Без нови сътрудници общността на вашия проект може да изпадне в застой.
 
-* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+* **Брой отворени проблеми и отворени заявки за изтегляне: ** Ако тези числа станат твърде високи, може да се нуждаете от помощ при сортирането на проблеми и прегледите на кода.
 
-* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+* **Брой _отворени_ проблеми и _отворени_ заявки за изтегляне: ** Отворените проблеми означават, че някой се интересува достатъчно от вашия проект, за да отвори проблем. Ако този брой се увеличи с течение на времето, това предполага, че хората се интересуват от вашия проект.
 
-* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+* **Видове приноси: ** Например ангажименти, коригиране на правописни грешки или грешки или коментиране на проблем.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
-  Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+  Отвореният код е нещо повече от код. Успешните проекти с отворен код включват принос на код и документация заедно с разговори за тези промени.
   <p markdown="1" class="pquote-credit">
-— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+— @arfon, ["Формата на отворения код"](https://github.com/blog/2195-the-shape-of-open-source)
   </p>
 </aside>
 
-## Maintainer activity
+## Поддържаща дейност
 
-Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+И накрая, ще искате да затворите цикъла, като се уверите, че поддържащите вашия проект са в състояние да се справят с обема на получените вноски. Последният въпрос, който ще искате да си зададете е: _отговарям ли (или ние) на нашата общност?_
 
-Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+Неотзивчивите поддържащи се превръщат в пречка за проекти с отворен код. Ако някой изпрати принос, но никога не получи отговор от поддържащия, той може да се почувства обезсърчен и да напусне.
 
-[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+[Изследване от Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) предполага, че отзивчивостта на поддържащия е критичен фактор за насърчаване на повтарящи се приноси.
 
-Consider [tracking how long it takes for you (or another maintainer) to respond to contributions](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+Помислете за [проследяване колко време отнема на вас (или на друг поддържащ) да отговорите на приносите](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), дали проблем или заявка за изтегляне. Отговорът не изисква предприемане на действие. Може да бъде толкова просто, колкото да кажете: _„Благодаря за вашето изпращане! Ще прегледам това през следващата седмица.“_
 
-You could also measure the time it takes to move between stages in the contribution process, such as:
+Можете също да измерите времето, необходимо за преминаване между етапите в процеса на принос, като например:
 
-* Average time an issue remains open
-* Whether issues get closed by PRs
-* Whether stale issues get closed
-* Average time to merge a pull request
+*Средно време, през което проблемът остава отворен
+* Дали проблемите се затварят от PR
+* Дали остарелите проблеми се затварят
+* Средно време за обединяване на заявка за изтегляне
 
-## Use 📊 to learn about people
+## Използвайте 📊, за да научите за хората
 
-Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+Разбирането на показателите ще ви помогне да изградите активен, разрастващ се проект с отворен код. Дори и да не проследявате всеки показател на таблото за управление, използвайте рамката по-горе, за да фокусирате вниманието си върху типа поведение, което ще помогне на вашия проект да процъфтява.
 
-[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health.
+[CHAOSS](https://chaoss.community/) е гостоприемна общност с отворен код, фокусирана върху анализи, показатели и софтуер за здравето на общността.
diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index b2e49d630af..28516c8f46b 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -1,7 +1,7 @@
 ---
-lang: en
-title: Starting an Open Source Project
-description: Learn more about the world of open source and get ready to launch your own project.
+lang: bg
+title: Стартиране на проект с отворен код
+description:Научете повече за света на отворения код и се пригответе да стартирате свой собствен проект.
 class: beginners
 order: 2
 image: /assets/images/cards/beginner.png
@@ -10,273 +10,273 @@ related:
   - building
 ---
 
-## The "what" and "why" of open source
+## „Какво“ и „защо“ на отворения код
 
-So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+Значи обмисляте да започнете с отворен код? Честито! Светът оценява вашия принос. Нека поговорим какво е отворен код и защо хората го правят.
 
-### What does "open source" mean?
+### Какво означава "отворен код"?
 
-When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+Когато даден проект е с отворен код, това означава, че **всеки е свободен да използва, изучава, променя и разпространява вашия проект за всякакви цели.** Тези разрешения се прилагат чрез [лиценз за отворен код](https://opensource.org /лицензи).
 
-Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+Отвореният код е мощен, защото намалява бариерите пред приемането и сътрудничеството, позволявайки на хората да разпространяват и подобряват проекти бързо. Също така защото дава на потребителите потенциал да контролират собствените си компютри, в сравнение със затворения код. Например, бизнес, използващ софтуер с отворен код, има опцията да наеме някой, който да направи персонализирани подобрения на софтуера, вместо да разчита изключително на продуктовите решения на доставчик със затворен код.
 
-_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като „свободен софтуер с отворен код“ (FOSS) или „безплатен софтуер с отворен код“ (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената] (#does-open-source-mean-of-charge).
 
-### Why do people open source their work?
+### Защо хората отварят кода на работата си?
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
-  One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+  Едно от най-възнаграждаващите преживявания, които получавам от използването и сътрудничеството с отворен код, идва от взаимоотношенията, които изграждам с други разработчици, изправени пред много от същите проблеми като мен.
   <p markdown="1" class="pquote-credit">
-— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+— @kentcdodds, ["Как навлизането в Open Source беше страхотно за мен"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
   </p>
 </aside>
 
-[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+[Има много причини](https://ben.balter.com/2015/11/23/why-open-source/), поради които дадено лице или организация би искала да отвори проект с отворен код. Някои примери включват:
 
-* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+* **Сътрудничество:** Проектите с отворен код могат да приемат промени от всеки по света. [Exercism](https://github.com/exercism/), например, е платформа за упражнения по програмиране с над 350 участници.
 
-* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **Приемане и ремиксиране:** Проектите с отворен код могат да се използват от всеки за почти всякакви цели. Хората дори могат да го използват за изграждане на други неща. [WordPress](https://github.com/WordPress), например, стартира като разклонение на съществуващ проект, наречен [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part %201/2-b2-cafelog.md).
 
-* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+* **Прозрачност:** Всеки може да провери проект с отворен код за грешки или несъответствия. Прозрачността има значение за правителства като [България](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) или [Съединените щати](https://sourcecode.cio .gov/), регулирани отрасли като банкиране или здравеопазване и софтуер за сигурност като [Let's Encrypt](https://github.com/letsencrypt).
 
-Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+Отвореният код също не е само за софтуер. Можете да отворите всичко - от набори от данни до книги. Разгледайте [GitHub Explore](https://github.com/explore) за идеи какво още можете да отворите.
 
-### Does open source mean "free of charge"?
+### Отворен код означава ли „безплатно“?
 
-One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+Едно от най-големите предимства на отворения код е, че не струва пари. „Безплатно“ обаче е страничен продукт от общата стойност на отворения код.
 
-Because [an open source license requires](https://opensource.org/definition-annotated/) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+Тъй като [лицензът с отворен код изисква] (https://opensource.org/definition-annotated/) всеки да може да използва, променя и споделя вашия проект за почти всякакви цели, самите проекти обикновено са безплатни. Ако използването на проекта струва пари, всеки може законно да направи копие и вместо това да използва безплатната версия.
 
-As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+В резултат на това повечето проекти с отворен код са безплатни, но „безплатно“ не е част от определението за отворен код. Има начини за таксуване за проекти с отворен код индиректно чрез двойно лицензиране или ограничени функции, като същевременно се спазва официалното определение за отворен код.
 
-## Should I launch my own open source project?
+## Трябва ли да стартирам собствен проект с отворен код?
 
-The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+Краткият отговор е да, защото независимо от резултата, стартирането на собствен проект е чудесен начин да научите как работи отвореният код.
 
-If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+Ако никога преди не сте отваряли проект с отворен код, може да се притеснявате какво ще кажат хората или дали някой изобщо ще забележи. Ако това звучи като вас, не сте сами!
 
-Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+Работата с отворен код е като всяка друга творческа дейност, независимо дали е писане или рисуване. Може да ви е страшно да споделяте работата си със света, но единственият начин да станете по-добри е да практикувате – дори и да нямате публика.
 
-If you're not yet convinced, take a moment to think about what your goals might be.
+Ако все още не сте убедени, отделете малко време, за да помислите какви може да са вашите цели.
 
-### Setting your goals
+### Поставяне на вашите цели
 
-Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself,  _why am I open sourcing this project?_
+Целите могат да ви помогнат да разберете върху какво да работите, на какво да кажете „не“ и къде имате нужда от помощ от другите. Започнете, като се запитате _защо използвам този проект с отворен код?_
 
-There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+Няма един правилен отговор на този въпрос. Може да имате множество цели за един проект или различни проекти с различни цели.
 
-If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+Ако единствената ви цел е да покажете работата си, може дори да не искате принос и дори да го кажете във вашия README. От друга страна, ако искате сътрудници, ще инвестирате време в ясна документация и ще накарате новодошлите да се почувстват добре дошли.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
-  At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+  В един момент създадох персонализиран UIAlertView, който използвах... и реших да го направя с отворен код. Затова го модифицирах, за да бъде по-динамичен, и го качих в GitHub. Написах и първата си документация, обяснявайки на други разработчици как да я използват в своите проекти. Вероятно никой никога не го е използвал, защото беше прост проект, но се чувствах добре от моя принос.
   <p markdown="1" class="pquote-credit">
-— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+— @mavris, ["Самоуки разработчици на софтуер: Защо отвореният код е важен за нас"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
   </p>
 </aside>
 
-As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+С разрастването на проекта ви, общността ви може да се нуждае от нещо повече от код - от вас. Отговарянето на проблеми, прегледът на кода и евангелизирането на вашия проект са важни задачи в проект с отворен код.
 
-While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+Макар че времето, което отделяте за задачи, които не са свързани с кодиране, ще зависи от размера и обхвата на вашия проект, вие трябва да сте подготвени като поддържащ да се справите с тях сами или да намерите някой, който да ви помогне.
 
-**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+**Ако сте част от компания, предлагаща проект с отворен код,** се уверете, че вашият проект разполага с необходимите вътрешни ресурси, за да процъфтява. Ще искате да определите кой е отговорен за поддържането на проекта след стартирането и как ще споделите тези задачи с вашата общност.
 
-If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+Ако имате нужда от специален бюджет или персонал за промоция, операции и поддържане на проекта, започнете тези разговори отрано.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
-  As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+  Когато започнете да отваряте проекта с отворен код, е важно да се уверите, че вашите процеси на управление вземат предвид приноса и способностите на общността около вашия проект. Не се страхувайте да включите сътрудници, които не са заети във вашия бизнес, в ключови аспекти на проекта — особено ако те често сътрудничат.
   <p markdown="1" class="pquote-credit">
-— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+— @captainsafia, ["Значи искате проект с отворен код, а?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
   </p>
 </aside>
 
-### Contributing to other projects
+### Принос към други проекти
 
-If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+Ако целта ви е да научите как да си сътрудничите с други или да разберете как работи отворен код, помислете дали да допринесете за съществуващ проект. Започнете с проект, който вече използвате и харесвате. Приносът към проект може да бъде толкова прост, колкото коригиране на правописни грешки или актуализиране на документация.
 
-If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+Ако не сте сигурни как да започнете като сътрудник, вижте нашето [Как да допринесете за ръководство с отворен код](../how-to-contribute/).
 
-## Launching your own open source project
+## Стартиране на ваш собствен проект с отворен код
 
-There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+Няма идеално време за отваряне на вашата работа. Можете да отворите кода на идея, в процес на работа или след години на затворен код.
 
-Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+Най-общо казано, трябва да отворите своя проект, когато се чувствате комфортно другите да гледат и дават обратна връзка за работата ви.
 
-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/)
 * [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.
+Като поддържащ, тези компоненти ще ви помогнат да съобщите очакванията, да управлявате приносите и да защитите законните права на всички (включително вашите собствени). Те значително увеличават шансовете ви за положително преживяване.
 
-If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+Ако вашият проект е в GitHub, поставянето на тези файлове в основната ви директория с препоръчаните файлови имена ще помогне на GitHub да ги разпознае и автоматично да ги покаже на вашите читатели.
 
-### Choosing a license
+### Избор на лиценз
 
-An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+Лицензът с отворен код гарантира, че други могат да използват, копират, модифицират и допринасят обратно към вашия проект без последствия. Освен това ви предпазва от трудни правни ситуации. **Трябва да включите лиценз, когато стартирате проект с отворен код.**
 
-Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+Легалната работа не е забавна. Добрата новина е, че можете да копирате и поставите съществуващ лиценз във вашето хранилище. Ще отнеме само минута, за да защитите упоритата си работа.
 
-[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 the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) и [GPLv3](https://choosealicense. com/licenses/gpl-3.0/) са най-популярните лицензи с отворен код, но [има и други опции](https://choosealicense.com), от които да избирате.
 
-When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на лиценз с отворен код ще направи вашия проект GitHub отворен код.
 
-![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+![Изберете лиценз](/assets/images/starting-a-project/repository-license-picker.png)
 
-If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+Ако имате други въпроси или притеснения относно правните аспекти на управлението на проект с отворен код, [ние ще ви покрием](../legal/).
 
-### Writing a README
+### Писане на README
 
-READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+README правят повече от това да обяснят как да използвате вашия проект. Те също така обясняват защо вашият проект има значение и какво могат да правят вашите потребители с него.
 
-In your README, try to answer the following questions:
+В README опитайте да отговорите на следните въпроси:
 
-* What does this project do?
-* Why is this project useful?
-* How do I get started?
-* Where can I get more help, if I need it?
+* Какво прави този проект?
+* Защо този проект е полезен?
+* Как да започна?
+* Къде мога да получа повече помощ, ако имам нужда от нея?
 
-You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+Можете да използвате вашия README, за да отговорите на други въпроси, като например как се справяте с приносите, какви са целите на проекта и информация за лицензи и приписване. Ако не искате да приемате принос или вашият проект все още не е готов за производство, запишете тази информация.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
-  Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+  По-добрата документация означава повече потребители, по-малко заявки за поддръжка и повече сътрудници. (...) Помнете, че вашите читатели не сте вие. Има хора, които могат да дойдат на проект, които имат напълно различен опит.
   <p markdown="1" class="pquote-credit">
-— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+— @tracymakes, ["Пишете така, че думите ви да се четат (видео)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
   </p>
 </aside>
 
-Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+Понякога хората избягват да пишат README, защото смятат, че проектът е незавършен или не искат приноси. Всичко това са много добри причини да напиша такъв.
 
-For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+За повече вдъхновение опитайте да използвате [ръководството „Направете README“ на @dguo](https://www.makeareadme.com/) или [шаблона README] на @PurpleBooth(https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) за да напишете пълен README.
 
-When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+Когато включите файл README в основната директория, GitHub автоматично ще го покаже на началната страница на хранилището.
 
-### Writing your contributing guidelines
+### Писане на вашите указания за принос
 
-A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+CONTRIBUTING файл казва на вашата публика как да участва във вашия проект. Например можете да включите информация за:
 
-* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
-* How to suggest a new feature
-* How to set up your environment and run tests
+* Как да подадете доклад за грешка (опитайте да използвате [шаблони за заявка за проблем и изтегляне](https://github.com/blog/2111-issue-and-pull-request-templates))
+* Как да предложим нова функция
+* Как да настроите вашата среда и да стартирате тестове
 
-In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+В допълнение към техническите подробности, файлът CONTRIBUTING е възможност да съобщите вашите очаквания за приноси, като например:
 
-* The types of contributions you're looking for
-* Your roadmap or vision for the project
-* How contributors should (or should not) get in touch with you
+* Типовете приноси, които търсите
+* Вашата пътна карта или визия за проекта
+* Как сътрудниците трябва (или не трябва) да се свързват с вас
 
-Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+Използването на топъл, приятелски тон и предлагането на конкретни предложения за принос (като например писане на документация или създаване на уебсайт) може да помогне много на новодошлите да се почувстват добре дошли и развълнувани да участват.
 
-For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+Например [Active Admin](https://github.com/activeadmin/activeadmin/) започва [своето ръководство за принос](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) с:
 
-> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+> Първо, благодаря ви, че обмислихте да допринесете за Active Admin. Именно хора като вас правят Active Admin толкова страхотен инструмент.
 
-In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+В най-ранните етапи на вашия проект, вашият CONTRIBUTING файл може да бъде прост. Винаги трябва да обяснявате как да докладвате бъгове или проблеми с файлове, както и всякакви технически изисквания (като тестове), за да направите принос.
 
-Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+С течение на времето може да добавите други често задавани въпроси към вашия CONTRIBUTING файл. Записването на тази информация означава, че по-малко хора ще ви задават едни и същи въпроси отново и отново.
 
-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/).
+За повече помощ при писането на вашия CONTRIBUTING файл вижте @nayafia [шаблон за ръководство за допринасяне](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) или @mozilla [„Как да Създайте 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.
+Връзка към вашия ПРИНОСЕН файл от вашия README, така че повече хора да го видят. Ако [поставите файла CONTRIBUTING в хранилището на вашия проект](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub автоматично ще се свърже с вашия файл, когато участник създаде проблем или отваря заявка за изтегляне.
 
-![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+![Указания за принос](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
-### Establishing a code of conduct
+### Създаване на кодекс на поведение
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
-  We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+  Всички сме имали опит, в който сме се сблъсквали с това, което вероятно е било злоупотреба, или като поддържащ, който се опитва да обясни защо нещо трябва да бъде по определен начин, или като потребител... задавайки прост въпрос. (...) Кодексът на поведение се превръща в документ с лесни препратки и връзки, който показва, че вашият екип приема много сериозно конструктивния дискурс.
   <p markdown="1" class="pquote-credit">
-— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+— @mlynch, ["Превръщане на отворения код в по-щастливо място"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
   </p>
 </aside>
 
-Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+И накрая, кодексът на поведение помага да се определят основните правила за поведение на участниците във вашия проект. Това е особено ценно, ако стартирате проект с отворен код за общност или компания. Кодексът на поведение ви дава възможност да улесните здравословното, конструктивно поведение в общността, което ще намали стреса ви като поддържащ.
 
-For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+За повече информация вижте нашето [Ръководство за кодекс на поведение](../code-of-conduct/).
 
-In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+В допълнение към комуникацията _как_ очаквате да се държат участниците, кодексът за поведение също има тенденция да описва към кого се отнасят тези очаквания, кога се прилагат и какво да направите, ако възникне нарушение.
 
-Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+Подобно на лицензите с отворен код, има и нововъзникващи стандарти за кодекси за поведение, така че не е нужно да пишете свои собствени. [Споразумението на сътрудниците](https://contributor-covenant.org/) е код за поведение, който се използва от [над 40 000 проекта с отворен код](https://www.contributor-covenant.org/adopters ), включително Kubernetes, Rails и Swift. Без значение кой текст използвате, трябва да сте готови да наложите своя кодекс на поведение, когато е необходимо.
 
-Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+Поставете текста директно във файл CODE_OF_CONDUCT във вашето хранилище. Съхранявайте файла в главната директория на вашия проект, за да е лесен за намиране, и свържете към него от вашия README.
 
-## Naming and branding your project
+## Наименуване и брандиране на вашия проект
 
-Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+Брандирането е повече от крещящо лого или закачливо име на проект. Става въпрос за това как говорите за вашия проект и до кого достигате с вашето послание.
 
-### Choosing the right name
+### Избор на правилното име
 
-Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+Изберете име, което е лесно за запомняне и в идеалния случай дава някаква представа какво прави проектът. Например:
 
-* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
-* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+* [Sentry](https://github.com/getsentry/sentry) следи приложенията за докладване на сривове
+* [Thin](https://github.com/macournoyer/thin) е бърз и лесен Ruby уеб сървър
 
-If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+Ако надграждате върху съществуващ проект, използването на тяхното име като префикс може да ви помогне да изясните какво прави вашият проект (например [node-fetch](https://github.com/bitinn/node-fetch) носи `window .fetch` към Node.js).
 
-Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+Помислете за яснотата преди всичко. Каламбурите са забавни, но не забравяйте, че някои вицове може да не се преведат в други култури или хора с различен опит от вашия. Някои от вашите потенциални потребители може да са служители на компанията: не искате да ги карате да се чувстват неудобно, когато трябва да обясняват вашия проект по време на работа!
 
-### Avoiding name conflicts
+### Избягване на конфликти с имена
 
-[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+[Проверете за проекти с отворен код с подобно име](http://ivantomic.com/projects/ospnc/), особено ако споделяте същия език или екосистема. Ако името ви се припокрива с популярен съществуващ проект, може да объркате аудиторията си.
 
-If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+Ако искате уебсайт, Twitter манипулатор или други свойства да представляват вашия проект, уверете се, че можете да получите имената, които искате. В идеалния случай [запазете тези имена сега](https://instantdomainsearch.com/) за спокойствие, дори ако все още не възнамерявате да ги използвате.
 
-Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+Уверете се, че името на вашия проект не нарушава никакви търговски марки. Една компания може да поиска от вас да премахнете проекта си по-късно или дори да предприеме съдебни действия срещу вас. Просто не си струва риска.
 
-You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+Можете да проверите [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) за конфликти на търговски марки. Ако сте в компания, това е едно от нещата, с които вашият [правен екип може да ви помогне](../legal/).
 
-Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+И накрая, направете бързо търсене в Google за името на вашия проект. Ще могат ли хората лесно да намерят вашия проект? Показва ли се нещо друго в резултатите от търсенето, което не бихте искали да виждат?
 
-### How you write (and code) affects your brand, too!
+### Как пишете (и кодирате) също влияе върху вашата марка!
 
-Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+През целия живот на вашия проект ще пишете много: README, уроци, документи на общността, отговаряне на проблеми, може би дори бюлетини и пощенски списъци.
 
-Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+Независимо дали става въпрос за официална документация или случаен имейл, вашият стил на писане е част от марката на вашия проект. Помислете как бихте могли да възприемете публиката си и дали това е тонът, който искате да предадете.
 
 <aside markdown="1" class="pquote">
-  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
-  I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
-  <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
-  </p>
+   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+   Опитах се да участвам във всяка нишка в пощенския списък и да показвам примерно поведение, да бъда любезен с хората, да приемам проблемите им сериозно и да се опитвам да бъда полезен като цяло. След известно време хората останаха наоколо не само за да задават въпроси, но и за да помогнат с отговорите и за моя пълна радост имитираха моя стил.
+   <p markdown="1" class="pquote-credit">
+— @janl в [CouchDB](https://github.com/apache/couchdb), ["Устойчив отворен код"](https://web.archive.org/web/20200723213552/https://writing.jan .io/2015/11/20/sustainable-open-source.html)
+   </p>
 </aside>
 
-Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+Използването на топъл, приобщаващ език (като „тях“, дори когато се отнася до един човек) може много да помогне на вашия проект да се почувства добре дошъл за новите сътрудници. Придържайте се към простия език, тъй като много от вашите читатели може да не са носители на английски език.
 
-Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+Освен начина, по който пишете думи, вашият стил на кодиране може също да стане част от марката на вашия проект. [Angular](https://angular.io/guide/styleguide) и [jQuery](https://contribute.jquery.org/style-guide/js/) са два примера за проекти със строги стилове и насоки за кодиране.
 
-It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+Не е необходимо да пишете стилово ръководство за вашия проект, когато току-що започвате, и може да откриете, че така или иначе ви харесва да включвате различни стилове на кодиране във вашия проект. Но трябва да предвидите как вашият стил на писане и кодиране може да привлече или обезсърчи различни типове хора. Най-ранните етапи на вашия проект са вашата възможност да създадете прецедента, който искате да видите.
 
-## 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.
+Готови ли сте да отворите вашия проект? Ето контролен списък за помощ. Поставете отметка във всички квадратчета? Готови сте за работа! [Щракнете върху „публикувай“](https://help.github.com/articles/making-a-private-repository-public/) и се потупайте по рамото.
 
-**Documentation**
+**Документация**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox1" class="overflow-hidden d-block text-normal">
-    Project has a LICENSE file with an open source license
+    Проектът има файл LICENSE с лиценз с отворен код
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox2" class="overflow-hidden d-block text-normal">
-    Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+    Проектът има основна документация (README, CONTRIBUTING, CODE_OF_CONDUCT)
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox3" class="overflow-hidden d-block text-normal">
-    The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+    Името е лесно за запомняне, дава известна представа какво прави проектът и не е в конфликт със съществуващ проект или нарушава търговски марки
   </label>
 </div>
 
@@ -292,65 +292,65 @@ Ready to open source your project? Here's a checklist to help. Check all the box
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox5" class="overflow-hidden d-block text-normal">
-    Project uses consistent code conventions and clear function/method/variable names
+    Проектът използва последователни кодови конвенции и ясни имена на функции/методи/променливи
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    The code is clearly commented, documenting intentions and edge cases
+    Кодът е ясно коментиран, документирайки намеренията и крайните случаи
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+    Няма чувствителни материали в хронологията на редакциите, проблеми или заявки за изтегляне (например пароли или друга непублична информация)
   </label>
 </div>
 
-**People**
+**Хора**
 
-If you're an individual:
+Ако сте физическо лице:
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-  You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+  Говорили сте с правния отдел и/или разбирате политиките за IP и отворен код на вашата компания (ако сте служител някъде)
   </label>
 </div>
 
-If you're a company or organization:
+Ако сте компания или организация:
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    You've talked to your legal department
+    Говорили сте с правния си отдел
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    You have a marketing plan for announcing and promoting the project
+    Имате маркетингов план за анонсиране и популяризиране на проекта
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox11" class="overflow-hidden d-block text-normal">
-    Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+    Някой се ангажира да управлява взаимодействията на общността (отговаряне на проблеми, преглед и обединяване на заявки за изтегляне)
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    At least two people have administrative access to the project
+    Най-малко двама души имат административен достъп до проекта
   </label>
 </div>
 
-## You did it!
+## Направи го!
 
-Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.
+Поздравления за първия ви проект с отворен код. Без значение от резултата, публичната работа е дар за общността. С всеки ангажимент, коментар и заявка за изтегляне вие създавате възможности за себе си и за другите да се учат и да растат.

From 549322d73eda73bc9d5dcf0c130790c5b4715e3f Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Fri, 29 Mar 2024 20:21:40 +0100
Subject: [PATCH 652/749] Removed folder from repository

---
 .vs/VSWorkspaceState.json                    |   7 -------
 .vs/opensource.guide/v17/.wsuo               | Bin 11264 -> 0 bytes
 .vs/opensource.guide/v17/DocumentLayout.json |  12 ------------
 3 files changed, 19 deletions(-)
 delete mode 100644 .vs/VSWorkspaceState.json
 delete mode 100644 .vs/opensource.guide/v17/.wsuo
 delete mode 100644 .vs/opensource.guide/v17/DocumentLayout.json

diff --git a/.vs/VSWorkspaceState.json b/.vs/VSWorkspaceState.json
deleted file mode 100644
index 6fd1a26c67b..00000000000
--- a/.vs/VSWorkspaceState.json
+++ /dev/null
@@ -1,7 +0,0 @@
-{
-  "ExpandedNodes": [
-    ""
-  ],
-  "SelectedNode": "\\C:\\Users\\Dsvk2\\Source\\Repos\\opensource.guide",
-  "PreviewInSolutionExplorer": false
-}
\ No newline at end of file
diff --git a/.vs/opensource.guide/v17/.wsuo b/.vs/opensource.guide/v17/.wsuo
deleted file mode 100644
index bc44734735d78d8274f3789e26600d29bfeba576..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 11264
zcmeHN%WoS+82_A7pgfxv0+b#s6jeE3%eB%bDWVD_Eg)f%)=7gzknk&y#xL1UOD~)`
za|gtYEB^xrPJ}ZjxbinZ&F?q6V~^Ln<Mlcv3Gqa`JMZ6oubFQ?=eL8&KYsY>(x2i<
zH|2~xZl9B<jry38m-8Yoq0G9+?RJ|@%p*HaCx`=grG~$j#O0P$@omT>iZXPXlCvF|
zpB*qNK6$Y8?N`6Yo=3mMXPnNfK&;7q`3UG+$la1J2h7sjJS7tye6qc_)xUHZ)lgrR
zG(K_bQpO4zQo@r3FLHQFZoi<<v`oZIaR>D?>t9CUXSZTS_JLBCUC_^G+dy7MO~V}M
zlPCUDsGq<Smj2h#SKBq$@{dUX@)z8>SWP}X>y}@@_eDIf;GxY^-u#}!cM=c#vph~G
zhXenm{h$Bq*N*+m5!(No(ABa1g9%7lQ@I~-AE5nSM4q-yyJng8&#$)s=TJtmFHxj@
zmE($I%>l~Q@1ZQc^_0I^M;qe4&-22px8;vDGfv^+vhaAy$_Lp+t}09Fy#>!>8?_DP
z134`avQK&&{)g!=_;l&3qW_R`YgZ%>?=J(ihKo&~i=Jpx?#X=LSZ~E!z^6Z{_atw-
zUzz(G{UxR)P@e-9(RP9Sux}Mkzo0k#ubw?GsGnI+`_ScOVCKQ;ZT!*i+)x}Z$PP+P
z-O2KeN5JR3jWS?*AM&oro>YL_z&EVl>x>q;4F2=p$FqXwqw8(o*U&iQc34x~-;<BQ
z{U)TI1?BX?TT)P3Ifw`Jf6rhpefHRJb=wp&Jkyxy_fz8<(77CR;WpM$R=n3YgA!KK
z3e<`l5%}LL|C*w-0!(WC2Jov=1P>m{D&9?$TX<-je!NJ5e(jTo<^QXo`<kL&#H)X#
zpZMGtX#WMQ%a*PHpZcWze_LPOM&4`v3&wv0oy=nuWj)OI3;aX1zYOTD0G0P(Qx<-_
z=Yp{R4UJD<Yt5y`OTU9jOK@(Y@8MQj$Not9QxjNgrt9E8<xZJ~l|Owu-Wi!p8Z)o}
zT7k0@C86{C$|h^z$OpisM%3jK^q{sn9JvYnH!u%vDl9(t3;GgFVe!|1PF<ia)D263
z{l&=7OL)TK6IbJBq2UEs8mW7Lxr?BzAxWkG=DC=}4pjr?MYR*`gHJ6^BcOk1`IBFI
z{}~3K=Tr+jHc#a$R=tCH79-%3S6cpA(94~lvr)^4a2Iv7d(wCZGABoPHa0uEG$wG<
zJn$JqU`!z_|IPi+CjV8SR`FK?*KaGTyLzYbq5nhkpR{ZF+wkux%3HA29CjjoLUBY9
zoY_%Y2>!=-pCs)}dR?|J&nvzE+3+`jK`E?2<M|~YyeS=le)>N8{!3dtjCAMg@2c(e
z-`@{AS0%Sw{bKH$3sJ}alBoPR%J^Z|`+w_CI~YX=MjcN*90i|t#PQuZ>We6bPNS|r
zG?1mEzKfV$MyWIBdD8iq!TBgy`W%WfmSZUQO*~6-1K)M*$vmx^$S>pl05_U6@}@Vt
zsm`~$I_oy^cJ|gLa@yZb!UNiOeF4sGOY}WHlh18ktZiMrwRQ_^r0?Icp*#xO7-j}h
zmc$LC3F<i@bmw&!;lmVe@aA8lQ?lpGG0Y!z;=LsUX*-@}7Uw#>p%!ZDu2*;;J>JEy
zp**$U>02)EQQU*33s-Xs*RSPLiP=&qotWKPC?@99bGbw@Uq}__W{YzRv*-(E_e%WJ
z14b^Qr|G^Md{g3xWstX5;m7iAOF^-^Cl&uA-Z&i}4vgbJr#t?W!D+aT9m5+3jvJ9M
z+x`(H{=)l`zJJ-~4%=p0Q`j+w+3zIdd*e?L;(zM@fQ~T!r{Z7ypAO0)j9kt5gO~o(
z7XS0o&*%~(LVNIkYAXKHGGc%IQBcGm6#p6156gf0tlH}dgWr$ZmGTVm>HjjG78aks
z7cq9m<i+Rj0gQds;R6Oo-JP*~GyY9now_Z-Inu7<e}4GRFJMI#?-{fn#(%k&Uc|#S
x1fzCa_*+d7{#gD)%U|*Rq{_edHqzCRVRKRAccaGtsQZjRQ}d(5A5VMy@LvEj-Gu-E

diff --git a/.vs/opensource.guide/v17/DocumentLayout.json b/.vs/opensource.guide/v17/DocumentLayout.json
deleted file mode 100644
index 2ca93c51a7b..00000000000
--- a/.vs/opensource.guide/v17/DocumentLayout.json
+++ /dev/null
@@ -1,12 +0,0 @@
-{
-  "Version": 1,
-  "WorkspaceRootPath": "C:\\Users\\Dsvk2\\Source\\Repos\\opensource.guide\\",
-  "Documents": [],
-  "DocumentGroupContainers": [
-    {
-      "Orientation": 0,
-      "VerticalTabListWidth": 256,
-      "DocumentGroups": []
-    }
-  ]
-}
\ No newline at end of file

From 51425052dbd50d782d03b4e8a98d2898702e7b97 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Fri, 29 Mar 2024 20:22:25 +0100
Subject: [PATCH 653/749] Removed folder from repository

---
 .vs/VSWorkspaceState.json                    |   7 +++++++
 .vs/opensource.guide/v17/.wsuo               | Bin 0 -> 11264 bytes
 .vs/opensource.guide/v17/DocumentLayout.json |  12 ++++++++++++
 3 files changed, 19 insertions(+)
 create mode 100644 .vs/VSWorkspaceState.json
 create mode 100644 .vs/opensource.guide/v17/.wsuo
 create mode 100644 .vs/opensource.guide/v17/DocumentLayout.json

diff --git a/.vs/VSWorkspaceState.json b/.vs/VSWorkspaceState.json
new file mode 100644
index 00000000000..6fd1a26c67b
--- /dev/null
+++ b/.vs/VSWorkspaceState.json
@@ -0,0 +1,7 @@
+{
+  "ExpandedNodes": [
+    ""
+  ],
+  "SelectedNode": "\\C:\\Users\\Dsvk2\\Source\\Repos\\opensource.guide",
+  "PreviewInSolutionExplorer": false
+}
\ No newline at end of file
diff --git a/.vs/opensource.guide/v17/.wsuo b/.vs/opensource.guide/v17/.wsuo
new file mode 100644
index 0000000000000000000000000000000000000000..bc44734735d78d8274f3789e26600d29bfeba576
GIT binary patch
literal 11264
zcmeHN%WoS+82_A7pgfxv0+b#s6jeE3%eB%bDWVD_Eg)f%)=7gzknk&y#xL1UOD~)`
za|gtYEB^xrPJ}ZjxbinZ&F?q6V~^Ln<Mlcv3Gqa`JMZ6oubFQ?=eL8&KYsY>(x2i<
zH|2~xZl9B<jry38m-8Yoq0G9+?RJ|@%p*HaCx`=grG~$j#O0P$@omT>iZXPXlCvF|
zpB*qNK6$Y8?N`6Yo=3mMXPnNfK&;7q`3UG+$la1J2h7sjJS7tye6qc_)xUHZ)lgrR
zG(K_bQpO4zQo@r3FLHQFZoi<<v`oZIaR>D?>t9CUXSZTS_JLBCUC_^G+dy7MO~V}M
zlPCUDsGq<Smj2h#SKBq$@{dUX@)z8>SWP}X>y}@@_eDIf;GxY^-u#}!cM=c#vph~G
zhXenm{h$Bq*N*+m5!(No(ABa1g9%7lQ@I~-AE5nSM4q-yyJng8&#$)s=TJtmFHxj@
zmE($I%>l~Q@1ZQc^_0I^M;qe4&-22px8;vDGfv^+vhaAy$_Lp+t}09Fy#>!>8?_DP
z134`avQK&&{)g!=_;l&3qW_R`YgZ%>?=J(ihKo&~i=Jpx?#X=LSZ~E!z^6Z{_atw-
zUzz(G{UxR)P@e-9(RP9Sux}Mkzo0k#ubw?GsGnI+`_ScOVCKQ;ZT!*i+)x}Z$PP+P
z-O2KeN5JR3jWS?*AM&oro>YL_z&EVl>x>q;4F2=p$FqXwqw8(o*U&iQc34x~-;<BQ
z{U)TI1?BX?TT)P3Ifw`Jf6rhpefHRJb=wp&Jkyxy_fz8<(77CR;WpM$R=n3YgA!KK
z3e<`l5%}LL|C*w-0!(WC2Jov=1P>m{D&9?$TX<-je!NJ5e(jTo<^QXo`<kL&#H)X#
zpZMGtX#WMQ%a*PHpZcWze_LPOM&4`v3&wv0oy=nuWj)OI3;aX1zYOTD0G0P(Qx<-_
z=Yp{R4UJD<Yt5y`OTU9jOK@(Y@8MQj$Not9QxjNgrt9E8<xZJ~l|Owu-Wi!p8Z)o}
zT7k0@C86{C$|h^z$OpisM%3jK^q{sn9JvYnH!u%vDl9(t3;GgFVe!|1PF<ia)D263
z{l&=7OL)TK6IbJBq2UEs8mW7Lxr?BzAxWkG=DC=}4pjr?MYR*`gHJ6^BcOk1`IBFI
z{}~3K=Tr+jHc#a$R=tCH79-%3S6cpA(94~lvr)^4a2Iv7d(wCZGABoPHa0uEG$wG<
zJn$JqU`!z_|IPi+CjV8SR`FK?*KaGTyLzYbq5nhkpR{ZF+wkux%3HA29CjjoLUBY9
zoY_%Y2>!=-pCs)}dR?|J&nvzE+3+`jK`E?2<M|~YyeS=le)>N8{!3dtjCAMg@2c(e
z-`@{AS0%Sw{bKH$3sJ}alBoPR%J^Z|`+w_CI~YX=MjcN*90i|t#PQuZ>We6bPNS|r
zG?1mEzKfV$MyWIBdD8iq!TBgy`W%WfmSZUQO*~6-1K)M*$vmx^$S>pl05_U6@}@Vt
zsm`~$I_oy^cJ|gLa@yZb!UNiOeF4sGOY}WHlh18ktZiMrwRQ_^r0?Icp*#xO7-j}h
zmc$LC3F<i@bmw&!;lmVe@aA8lQ?lpGG0Y!z;=LsUX*-@}7Uw#>p%!ZDu2*;;J>JEy
zp**$U>02)EQQU*33s-Xs*RSPLiP=&qotWKPC?@99bGbw@Uq}__W{YzRv*-(E_e%WJ
z14b^Qr|G^Md{g3xWstX5;m7iAOF^-^Cl&uA-Z&i}4vgbJr#t?W!D+aT9m5+3jvJ9M
z+x`(H{=)l`zJJ-~4%=p0Q`j+w+3zIdd*e?L;(zM@fQ~T!r{Z7ypAO0)j9kt5gO~o(
z7XS0o&*%~(LVNIkYAXKHGGc%IQBcGm6#p6156gf0tlH}dgWr$ZmGTVm>HjjG78aks
z7cq9m<i+Rj0gQds;R6Oo-JP*~GyY9now_Z-Inu7<e}4GRFJMI#?-{fn#(%k&Uc|#S
x1fzCa_*+d7{#gD)%U|*Rq{_edHqzCRVRKRAccaGtsQZjRQ}d(5A5VMy@LvEj-Gu-E

literal 0
HcmV?d00001

diff --git a/.vs/opensource.guide/v17/DocumentLayout.json b/.vs/opensource.guide/v17/DocumentLayout.json
new file mode 100644
index 00000000000..2ca93c51a7b
--- /dev/null
+++ b/.vs/opensource.guide/v17/DocumentLayout.json
@@ -0,0 +1,12 @@
+{
+  "Version": 1,
+  "WorkspaceRootPath": "C:\\Users\\Dsvk2\\Source\\Repos\\opensource.guide\\",
+  "Documents": [],
+  "DocumentGroupContainers": [
+    {
+      "Orientation": 0,
+      "VerticalTabListWidth": 256,
+      "DocumentGroups": []
+    }
+  ]
+}
\ No newline at end of file

From 712389c37649741c0b0f2b605b4acadcc4574256 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Fri, 29 Mar 2024 20:25:03 +0100
Subject: [PATCH 654/749] Removed folder from repository

---
 .vs/VSWorkspaceState.json                    |   7 -------
 .vs/opensource.guide/v17/.wsuo               | Bin 11264 -> 0 bytes
 .vs/opensource.guide/v17/DocumentLayout.json |  12 ------------
 3 files changed, 19 deletions(-)
 delete mode 100644 .vs/VSWorkspaceState.json
 delete mode 100644 .vs/opensource.guide/v17/.wsuo
 delete mode 100644 .vs/opensource.guide/v17/DocumentLayout.json

diff --git a/.vs/VSWorkspaceState.json b/.vs/VSWorkspaceState.json
deleted file mode 100644
index 6fd1a26c67b..00000000000
--- a/.vs/VSWorkspaceState.json
+++ /dev/null
@@ -1,7 +0,0 @@
-{
-  "ExpandedNodes": [
-    ""
-  ],
-  "SelectedNode": "\\C:\\Users\\Dsvk2\\Source\\Repos\\opensource.guide",
-  "PreviewInSolutionExplorer": false
-}
\ No newline at end of file
diff --git a/.vs/opensource.guide/v17/.wsuo b/.vs/opensource.guide/v17/.wsuo
deleted file mode 100644
index bc44734735d78d8274f3789e26600d29bfeba576..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 11264
zcmeHN%WoS+82_A7pgfxv0+b#s6jeE3%eB%bDWVD_Eg)f%)=7gzknk&y#xL1UOD~)`
za|gtYEB^xrPJ}ZjxbinZ&F?q6V~^Ln<Mlcv3Gqa`JMZ6oubFQ?=eL8&KYsY>(x2i<
zH|2~xZl9B<jry38m-8Yoq0G9+?RJ|@%p*HaCx`=grG~$j#O0P$@omT>iZXPXlCvF|
zpB*qNK6$Y8?N`6Yo=3mMXPnNfK&;7q`3UG+$la1J2h7sjJS7tye6qc_)xUHZ)lgrR
zG(K_bQpO4zQo@r3FLHQFZoi<<v`oZIaR>D?>t9CUXSZTS_JLBCUC_^G+dy7MO~V}M
zlPCUDsGq<Smj2h#SKBq$@{dUX@)z8>SWP}X>y}@@_eDIf;GxY^-u#}!cM=c#vph~G
zhXenm{h$Bq*N*+m5!(No(ABa1g9%7lQ@I~-AE5nSM4q-yyJng8&#$)s=TJtmFHxj@
zmE($I%>l~Q@1ZQc^_0I^M;qe4&-22px8;vDGfv^+vhaAy$_Lp+t}09Fy#>!>8?_DP
z134`avQK&&{)g!=_;l&3qW_R`YgZ%>?=J(ihKo&~i=Jpx?#X=LSZ~E!z^6Z{_atw-
zUzz(G{UxR)P@e-9(RP9Sux}Mkzo0k#ubw?GsGnI+`_ScOVCKQ;ZT!*i+)x}Z$PP+P
z-O2KeN5JR3jWS?*AM&oro>YL_z&EVl>x>q;4F2=p$FqXwqw8(o*U&iQc34x~-;<BQ
z{U)TI1?BX?TT)P3Ifw`Jf6rhpefHRJb=wp&Jkyxy_fz8<(77CR;WpM$R=n3YgA!KK
z3e<`l5%}LL|C*w-0!(WC2Jov=1P>m{D&9?$TX<-je!NJ5e(jTo<^QXo`<kL&#H)X#
zpZMGtX#WMQ%a*PHpZcWze_LPOM&4`v3&wv0oy=nuWj)OI3;aX1zYOTD0G0P(Qx<-_
z=Yp{R4UJD<Yt5y`OTU9jOK@(Y@8MQj$Not9QxjNgrt9E8<xZJ~l|Owu-Wi!p8Z)o}
zT7k0@C86{C$|h^z$OpisM%3jK^q{sn9JvYnH!u%vDl9(t3;GgFVe!|1PF<ia)D263
z{l&=7OL)TK6IbJBq2UEs8mW7Lxr?BzAxWkG=DC=}4pjr?MYR*`gHJ6^BcOk1`IBFI
z{}~3K=Tr+jHc#a$R=tCH79-%3S6cpA(94~lvr)^4a2Iv7d(wCZGABoPHa0uEG$wG<
zJn$JqU`!z_|IPi+CjV8SR`FK?*KaGTyLzYbq5nhkpR{ZF+wkux%3HA29CjjoLUBY9
zoY_%Y2>!=-pCs)}dR?|J&nvzE+3+`jK`E?2<M|~YyeS=le)>N8{!3dtjCAMg@2c(e
z-`@{AS0%Sw{bKH$3sJ}alBoPR%J^Z|`+w_CI~YX=MjcN*90i|t#PQuZ>We6bPNS|r
zG?1mEzKfV$MyWIBdD8iq!TBgy`W%WfmSZUQO*~6-1K)M*$vmx^$S>pl05_U6@}@Vt
zsm`~$I_oy^cJ|gLa@yZb!UNiOeF4sGOY}WHlh18ktZiMrwRQ_^r0?Icp*#xO7-j}h
zmc$LC3F<i@bmw&!;lmVe@aA8lQ?lpGG0Y!z;=LsUX*-@}7Uw#>p%!ZDu2*;;J>JEy
zp**$U>02)EQQU*33s-Xs*RSPLiP=&qotWKPC?@99bGbw@Uq}__W{YzRv*-(E_e%WJ
z14b^Qr|G^Md{g3xWstX5;m7iAOF^-^Cl&uA-Z&i}4vgbJr#t?W!D+aT9m5+3jvJ9M
z+x`(H{=)l`zJJ-~4%=p0Q`j+w+3zIdd*e?L;(zM@fQ~T!r{Z7ypAO0)j9kt5gO~o(
z7XS0o&*%~(LVNIkYAXKHGGc%IQBcGm6#p6156gf0tlH}dgWr$ZmGTVm>HjjG78aks
z7cq9m<i+Rj0gQds;R6Oo-JP*~GyY9now_Z-Inu7<e}4GRFJMI#?-{fn#(%k&Uc|#S
x1fzCa_*+d7{#gD)%U|*Rq{_edHqzCRVRKRAccaGtsQZjRQ}d(5A5VMy@LvEj-Gu-E

diff --git a/.vs/opensource.guide/v17/DocumentLayout.json b/.vs/opensource.guide/v17/DocumentLayout.json
deleted file mode 100644
index 2ca93c51a7b..00000000000
--- a/.vs/opensource.guide/v17/DocumentLayout.json
+++ /dev/null
@@ -1,12 +0,0 @@
-{
-  "Version": 1,
-  "WorkspaceRootPath": "C:\\Users\\Dsvk2\\Source\\Repos\\opensource.guide\\",
-  "Documents": [],
-  "DocumentGroupContainers": [
-    {
-      "Orientation": 0,
-      "VerticalTabListWidth": 256,
-      "DocumentGroups": []
-    }
-  ]
-}
\ No newline at end of file

From 0bd51bc18fac38dfc7e2e7f204dfe1b806c373d3 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 1 Apr 2024 04:29:15 +0000
Subject: [PATCH 655/749] build(deps): bump actions/configure-pages from 4 to 5

Bumps [actions/configure-pages](https://github.com/actions/configure-pages) from 4 to 5.
- [Release notes](https://github.com/actions/configure-pages/releases)
- [Commits](https://github.com/actions/configure-pages/compare/v4...v5)

---
updated-dependencies:
- dependency-name: actions/configure-pages
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/jekyll-preview.yml | 2 +-
 .github/workflows/jekyll.yml         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index c7497118965..99b8d2287b0 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -38,7 +38,7 @@ jobs:
           ref: ${{ github.event.pull_request.head.ref }}
           repository: ${{ github.event.pull_request.head.repo.full_name }}
       - name: Setup Pages
-        uses: actions/configure-pages@v4
+        uses: actions/configure-pages@v5
       - name: Build with Jekyll
         uses: actions/jekyll-build-pages@v1
         with:
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index 33ebf757a26..3d037c61fe1 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -34,7 +34,7 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v4
       - name: Setup Pages
-        uses: actions/configure-pages@v4
+        uses: actions/configure-pages@v5
       - name: Build with Jekyll
         uses: actions/jekyll-build-pages@v1
         with:

From 3a7df69ac6786c251a8bea2c1d881181910d7686 Mon Sep 17 00:00:00 2001
From: Siyana Zdravkova <52591976+BlueButterflies@users.noreply.github.com>
Date: Tue, 2 Apr 2024 18:37:51 +0200
Subject: [PATCH 656/749] Update starting-a-project.md Added space that was
 suggested to me

---
 _articles/bg/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index 28516c8f46b..ebeababb593 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -1,7 +1,7 @@
 ---
 lang: bg
 title: Стартиране на проект с отворен код
-description:Научете повече за света на отворения код и се пригответе да стартирате свой собствен проект.
+description: Научете повече за света на отворения код и се пригответе да стартирате свой собствен проект.
 class: beginners
 order: 2
 image: /assets/images/cards/beginner.png

From 3b22bb0ed7cc660856e2b083b23578443f23458f Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Wed, 3 Apr 2024 09:28:00 +0200
Subject: [PATCH 657/749] Update starting-a-project.md .Added space that was
 suggested to me

---
 _articles/bg/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index 28516c8f46b..ebeababb593 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -1,7 +1,7 @@
 ---
 lang: bg
 title: Стартиране на проект с отворен код
-description:Научете повече за света на отворения код и се пригответе да стартирате свой собствен проект.
+description: Научете повече за света на отворения код и се пригответе да стартирате свой собствен проект.
 class: beginners
 order: 2
 image: /assets/images/cards/beginner.png

From 8912233ef973ac07f43cd705cea262e85132bc09 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Wed, 3 Apr 2024 10:36:35 +0200
Subject: [PATCH 658/749] I fixed brackets in any file in folder bg

---
 _articles/bg/best-practices.md                | 32 ++++++++---------
 _articles/bg/building-community.md            | 20 +++++------
 _articles/bg/code-of-conduct.md               |  4 +--
 _articles/bg/finding-users.md                 |  4 +--
 _articles/bg/getting-paid.md                  | 10 +++---
 _articles/bg/how-to-contribute.md             | 34 +++++++++----------
 _articles/bg/leadership-and-governance.md     | 18 +++++-----
 _articles/bg/legal.md                         | 26 +++++++-------
 ...ing-balance-for-open-source-maintainers.md |  8 ++---
 _articles/bg/metrics.md                       |  8 ++---
 _articles/bg/starting-a-project.md            | 28 +++++++--------
 11 files changed, 96 insertions(+), 96 deletions(-)

diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md
index 170adf54d87..36a0fbdc074 100644
--- a/_articles/bg/best-practices.md
+++ b/_articles/bg/best-practices.md
@@ -24,7 +24,7 @@ related:
 
 Документацията не само изяснява вашето собствено мислене, но помага на другите хора да разберат от какво се нуждаете или очаквате, преди дори да попитат.
 
-Записването на нещата ви улеснява да кажете „не“, когато нещо не се вписва в обхвата ви. Освен това улеснява хората да се включат и да помогнат. Никога не знаете кой може да чете или използва вашия проект.
+Записването на нещата ви улеснява да кажете "не", когато нещо не се вписва в обхвата ви. Освен това улеснява хората да се включат и да помогнат. Никога не знаете кой може да чете или използва вашия проект.
 
 Дори и да не използвате пълни абзаци, писането на точки е по-добре, отколкото да не пишете изобщо.
 
@@ -34,13 +34,13 @@ related:
 
 Започнете, като напишете целите на вашия проект. Добавете ги към вашия README или създайте отделен файл, наречен VISION. Ако има други фактори, които биха могли да помогнат, като пътна карта на проекта, направете и тях публични.
 
-Наличието на ясна, документирана визия ви държи фокусирани и ви помага да избегнете „да не ви се изплъзне целта“ от приноса на другите.
+Наличието на ясна, документирана визия ви държи фокусирани и ви помага да избегнете "да не ви се изплъзне целта" от приноса на другите.
 
 Например, @lord откри, че наличието на визия за проекта му помага да разбере на кои заявки да отдели време. Като нов поддържащ, той съжаляваше, че не се придържа към обхвата на проекта си, когато получи първата си заявка за функция [Slate](https://github.com/lord/slate).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
-  Опитах. Не положих необходимите усилия, за да изляза с цялостно решение. Вместо полуготово решение, бих искал да бях казал „Нямам време за това в момента, но ще добавя функционалността към изоставането, което ще бъде разработено в бъдеще“.
+  Опитах. Не положих необходимите усилия, за да изляза с цялостно решение. Вместо полуготово решение, бих искал да бях казал "Нямам време за това в момента, но ще добавя функционалността към изоставането, което ще бъде разработено в бъдеще".
   <p markdown="1" class="pquote-credit">
 — @lord, ["Съвети за нови поддържащи отворен код"](https://lord.io/blog/2014/oss-tips/)
   </p>
@@ -50,7 +50,7 @@ related:
 
 Записването на правила може да бъде изнервящо. Понякога може да се чувствате така, сякаш контролирате поведението на другите хора или убивате цялото забавление.
 
-Въпреки това, написани и приложени справедливо, добрите правила дават възможност на поддържащите кода. Те ви предпазват от това да бъдете въвлечени в неща, които не искате да правите..
+Въпреки това, написани и приложени справедливо, добрите правила дават възможност на поддържащите кода. Те ви предпазват от това да бъдете въвлечени в неща, които не искате да правите.
 
 Повечето хора, които срещат вашия проект, не знаят нищо за вас или вашите обстоятелства. Те може да приемат, че ви е платено да работите по него, особено ако това е нещо, което те използват и от което зависят редовно. Може би в един момент сте отделили много време за проекта си, но сега сте заети с нова работа или член на семейството.
 
@@ -81,13 +81,13 @@ related:
 
 Записването на всичко обаче помага да се обезличи ситуациите, когато трябва да наложите правилата си.
 
-Да кажете „не“ не е забавно, но „Вашият принос не отговаря на критериите за този проект“ изглежда по-малко лично от „Не харесвам вашия принос“.
+Да кажете "не" не е забавно, но "Вашият принос не отговаря на критериите за този проект" изглежда по-малко лично от "Не харесвам вашия принос".
 
-Казването на „не“ се отнася за много ситуации, с които ще се сблъскате като поддържащ код: заявки за функции, които не отговарят на обхвата, някой дерайлира дискусия, върши ненужна работа за други.
+Казването на "не" се отнася за много ситуации, с които ще се сблъскате като поддържащ код: заявки за функции, които не отговарят на обхвата, някой дерайлира дискусия, върши ненужна работа за други.
 
 ### Поддържайте разговора приятелски
 
-Едно от най-важните места, където ще се упражнявате да казвате „не“, е във вашите проблеми и опашката за изтегляне на заявки. Като ръководител на проекта вие неизбежно ще получите предложения, които не искате да приемете.
+Едно от най-важните места, където ще се упражнявате да казвате "не", е във вашите проблеми и опашката за изтегляне на заявки. Като ръководител на проекта вие неизбежно ще получите предложения, които не искате да приемете.
 
 Може би приносът променя обхвата на вашия проект или не отговаря на вашата визия. Може би идеята е добра, но изпълнението е лошо.
 
@@ -103,7 +103,7 @@ related:
   </p>
 </aside>
 
-Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.
+Не оставяйте отворен нежелан принос, защото се чувствате виновни или искате да сте мили. С течение на времето вашите въпроси без отговор и PR ще направят работата по проекта ви да се чувства много по-стресираща и смущаваща.
 
 Най-добре е незабавно да затворите приноси, които знаете, че не искате да приемете. Ако вашият проект вече страда от голямо изоставане или списък с функции за внедряване, @steveklabnik има предложения за [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
 
@@ -120,13 +120,13 @@ Don't leave an unwanted contribution open because you feel guilty or want to be
 
 ![Екрана снимка на целина](/assets/images/best-practices/celery.png)
 
-Ако мисълта да кажете „не“ ви ужасява, не сте сами. Като @jessfraz [казва](https://blog.jessfraz.com/post/the-art-of-closing/):
+Ако мисълта да кажете "не" ви ужасява, не сте сами. Като @jessfraz [казва](https://blog.jessfraz.com/post/the-art-of-closing/):
 
-> Говорил съм с поддържащи кодове от множество различни проекти с отворен код, Mesos, Kubernetes, Chromium, и всички те са съгласни, че една от най-трудните части да си поддържащ код е да кажеш „Не“ на пачове, които не работят.
+> Говорил съм с поддържащи кодове от множество различни проекти с отворен код, Mesos, Kubernetes, Chromium, и всички те са съгласни, че една от най-трудните части да си поддържащ код е да кажеш "не" на пачове, които не работят.
 
 Не се чувствайте виновни, че не искате да приемете нечий принос. Първото правило на отворения код, [съгласно с](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Не е временно, да завинаги е."_ Въпреки че съпричастността към ентусиазма на друг човек е нещо добро, отхвърлянето на принос не е същото като отхвърлянето на човека зад него.
 
-В крайна сметка, ако даден принос не е достатъчно добър, не сте длъжни да го приемете. Бъдете мили и приемащи, когато хората допринасят за вашия проект, но приемайте само промени, които наистина вярвате, че ще направят проекта ви по-добър. Колкото по-често се упражнявате да казвате „не“, толкова по-лесно става. Това е обещание.
+В крайна сметка, ако даден принос не е достатъчно добър, не сте длъжни да го приемете. Бъдете мили и приемащи, когато хората допринасят за вашия проект, но приемайте само промени, които наистина вярвате, че ще направят проекта ви по-добър. Колкото по-често се упражнявате да казвате "не", толкова по-лесно става. Това е обещание.
 
 ### Бъди проактивен
 
@@ -149,7 +149,7 @@ Don't leave an unwanted contribution open because you feel guilty or want to be
   </p>
 </aside>
 
-Понякога, когато кажете „не“, вашият потенциален сътрудник може да се разстрои или да критикува решението ви. Ако поведението им стане враждебно, [вземете мерки за обезвреждане на ситуацията](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или дори да ги премахнете от вашата общност, ако не желаят да си сътрудничат конструктивно.
+Понякога, когато кажете "не", вашият потенциален сътрудник може да се разстрои или да критикува решението ви. Ако поведението им стане враждебно, [вземете мерки за обезвреждане на ситуацията](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или дори да ги премахнете от вашата общност, ако не желаят да си сътрудничат конструктивно.
 
 ### Прегърнете менторството
 
@@ -173,9 +173,9 @@ Don't leave an unwanted contribution open because you feel guilty or want to be
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
-  Казвах: „Да, всеки може да участва, не е необходимо да имате много опит в програмирането [...].“ Имахме хора, които се регистрираха [за събития] и тогава се запитах: вярно ли е това, какво казвах? Ще има 40 души, които ще се появят и не е като да мога да седя с всеки един от тях... Но хората се събраха и се получи. Щом човек го получи, той може да учи съседите си.
+  Казвах: "Да, всеки може да участва, не е необходимо да имате много опит в програмирането [...]." Имахме хора, които се регистрираха [за събития] и тогава се запитах: вярно ли е това, какво казвах? Ще има 40 души, които ще се появят и не е като да мога да седя с всеки един от тях... Но хората се събраха и се получи. Щом човек го получи, той може да учи съседите си.
   <p markdown="1" class="pquote-credit">
-—  @lmccart, ["Какво изобщо означава „отворен код“? p5.js Издание"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+—  @lmccart, ["Какво изобщо означава "отворен код"? p5.js Издание"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
   </p>
 </aside>
 
@@ -203,7 +203,7 @@ Don't leave an unwanted contribution open because you feel guilty or want to be
 
 Същото важи и за потребител, който наистина иска решение, което вие просто нямате възможност да създадете. Предлагането на адаптивни API и hooks може да помогне на другите да посрещнат собствените си нужди, без да се налага директно да променят източника. @orta [установи, че](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) насърчаването на плъгини за CocoaPods доведе до "някои от най-интересните идеи":
 
-> Почти неизбежно е след като проектът стане голям, поддържащите трябва да станат много по-консервативни по отношение на това как въвеждат нов код. Вие ставате добри в това да казвате „не“, но много хора имат законни нужди. Така вместо това в крайна сметка преобразувате своя инструмент в платформа.
+> Почти неизбежно е след като проектът стане голям, поддържащите трябва да станат много по-консервативни по отношение на това как въвеждат нов код. Вие ставате добри в това да казвате "не", но много хора имат законни нужди. Така вместо това в крайна сметка преобразувате своя инструмент в платформа.
 
 ## Доведете роботите
 
@@ -221,7 +221,7 @@ Don't leave an unwanted contribution open because you feel guilty or want to be
 
 <aside markdown="1" class="pquote">
   <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)
   </p>
diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index 2b1e86bf018..287a612f7fb 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -30,7 +30,7 @@ related:
 * **Обяснете ясно как да допринесат**, използвайки [вашият CONTRIBUTING архив](../starting-a-project/#writing-your-contributing-guidelines) и поддържане на вашите проблеми актуални.
 * **Добри първи издания**: За да помогнете на новите сътрудници да започнат, мислете ясно за [подчертаване на теми, които са достатъчно прости, за да се справи начинаещият](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки полезните приноси и намалявайки напрежението от потребителите, които се справят с проблеми, които са твърде трудни за тяхното ниво.
 
-[Проучване на GitHub за отворен код от 2017 г](http://opensourcesurvey.org/2017/) показа, че непълната или объркваща документация е най-големият проблем за потребителите с отворен код. Добрата документация приканва хората да взаимодействат с вашия проект. В крайна сметка някой ще отвори проблем или заявка. Използвайте тези взаимодействия като възможности да ги преместите надолу по фунията..
+[Проучване на GitHub за отворен код от 2017 г](http://opensourcesurvey.org/2017/) показа, че непълната или объркваща документация е най-големият проблем за потребителите с отворен код. Добрата документация приканва хората да взаимодействат с вашия проект. В крайна сметка някой ще отвори проблем или заявка. Използвайте тези взаимодействия като възможности да ги преместите надолу по фунията.
 
 * **Когато някой нов се присъедини към вашия проект, благодарете му за проявения интерес!** Необходим е само един негативен опит, за да накара някой да не иска да се върне.
 * **Бъдете отзивчиви.** Ако не отговорите на въпроса им в продължение на един месец, има вероятност те вече да са забравили за вашия проект.
@@ -45,7 +45,7 @@ related:
   </p>
 </aside>
 
-Повечето сътрудници с отворен код са „случайни сътрудници“: хора, които допринасят за проект само от време на време. Случаен сътрудник може да няма време да се запознае напълно с вашия проект, така че вашата работа е да го улесните да допринася.
+Повечето сътрудници с отворен код са "случайни сътрудници": хора, които допринасят за проект само от време на време. Случаен сътрудник може да няма време да се запознае напълно с вашия проект, така че вашата работа е да го улесните да допринася.
 
 Насърчаването на други сътрудници е инвестиция и във вас самите. Когато дадете възможност на най-големите си фенове да работят с работата, която ги вълнува, има по-малко натиск да правите всичко сами.
 
@@ -93,7 +93,7 @@ related:
 
 Първата причина е за тях. Помогнете на хората да се опознаят. Хората с общи интереси неизбежно ще искат място, където да говорят за това. А когато комуникацията е публична и достъпна, всеки може да чете минали архиви, за да се запознае и да участва.
 
-Втората причина е за вас. Ако не дадете на хората обществено място да говорят за вашия проект, те вероятно ще се свържат директно с вас. В началото може да изглежда достатъчно лесно да отговаряте на лични съобщения „само този път“. Но с течение на времето, особено ако проектът ви стане популярен, ще се почувствате изтощени. Устояйте на изкушението да общувате с хората относно вашия проект насаме. Вместо това ги насочете към определен обществен канал.
+Втората причина е за вас. Ако не дадете на хората обществено място да говорят за вашия проект, те вероятно ще се свържат директно с вас. В началото може да изглежда достатъчно лесно да отговаряте на лични съобщения "само този път". Но с течение на времето, особено ако проектът ви стане популярен, ще се почувствате изтощени. Устояйте на изкушението да общувате с хората относно вашия проект насаме. Вместо това ги насочете към определен обществен канал.
 
 Публичната комуникация може да бъде толкова проста, колкото да насочите хората да отворят проблем, вместо да ви изпращат имейл директно или да коментират в блога ви. Можете също така да настроите пощенски списък или да създадете акаунт в Twitter, Slack или IRC канал, за да могат хората да говорят за вашия проект. Или опитайте всичко по-горе!
 
@@ -133,7 +133,7 @@ related:
 
 ![Django страница с нови сътрудници](/assets/images/building-community/django_new_contributors.png)
 
-В опашката си с теми маркирайте грешки, които са подходящи за различни типове сътрудници: например [_"за начинаещи"_](https://kentcdodds.com/blog/first-timers-only), _"добра първа тема "_ или _"документация"_. [Тези маркировки](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) улесняват някой който  е нов във вашия проект бързо да сканира вашите теми и първи стъпки.
+В опашката си с теми маркирайте грешки, които са подходящи за различни типове сътрудници: например [_"за начинаещи"_](https://kentcdodds.com/blog/first-timers-only), _"добра първа тема"_ или _"документация"_. [Тези маркировки](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) улесняват някой който  е нов във вашия проект бързо да сканира вашите теми и първи стъпки.
 
 И накрая, използвайте вашата документация, за да накарате хората да се чувстват добре дошли на всяка стъпка от процеса.
 
@@ -163,13 +163,13 @@ related:
 
 * **Стартирайте файл CONTRIBUTORS или AUTHORS във вашия проект**, който изброява всички, които са допринесли за вашия проект, както прави [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
 
-* Ако имате значителна общност, **изпратете бюлетин или напишете публикация в блог**, като благодарите на сътрудниците. [Тази седмица в Rust] на Rust (https://this-week-in-rust.org/) и [Shoutouts] на Hoodie (http://hood.ie/blog/shoutouts-week-24.html) са два добри примера.
+* Ако имате значителна общност, **изпратете бюлетин или напишете публикация в блог**, като благодарите на сътрудниците. [Тази седмица в Rust](https://this-week-in-rust.org/) на Rust и [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) на Hoodie са два добри примера.
 
 * **Дайте достъп за ангажиране на всеки сътрудник.** @felixge установи, че това кара хората [да бъдат по-развълнувани да усъвършенстват корекциите си](https://felixge.de/2013/03/11/the-pull-request-hack.html ) и дори намери нови поддържащи за проекти, по които не е работил от известно време.
 
 * Ако проектът ви е в GitHub, **преместете проекта си от личния си акаунт в [Организация](https://help.github.com/articles/creating-a-new-organization-account/)** и добавете поне един резервен администратор. Организациите улесняват работата по проекти с външни сътрудници.
 
-Реалността е, че [повечето проекти имат само] (https://peerj.com/preprints/1233/) един или двама поддържащи, които вършат по-голямата част от работата. Колкото по-голям е вашият проект и колкото по-голяма е вашата общност, толкова по-лесно е да намерите помощ.
+Реалността е, че [повечето проекти имат само](https://peerj.com/preprints/1233/) един или двама поддържащи, които вършат по-голямата част от работата. Колкото по-голям е вашият проект и колкото по-голяма е вашата общност, толкова по-лесно е да намерите помощ.
 
 Въпреки че не винаги може да намерите някой, който да отговори на обаждането, подаването на сигнал там увеличава шансовете други хора да се включат. И колкото по-рано започнете, толкова по-скоро хората могат да помогнат.
 
@@ -213,13 +213,13 @@ related:
 
 ### Фокусирайте се върху пътуването, а не върху дестинацията
 
-Някои проекти използват процес на гласуване, за да вземат важни решения. Въпреки че е разумно на пръв поглед, гласуването набляга на достигането до „отговор“, а не на изслушване и разглеждане на притесненията на другия.
+Някои проекти използват процес на гласуване, за да вземат важни решения. Въпреки че е разумно на пръв поглед, гласуването набляга на достигането до "отговор", а не на изслушване и разглеждане на притесненията на другия.
 
 Гласуването може да стане политическо, когато членовете на общността се чувстват принудени да си правят услуги или да гласуват по определен начин. Не всеки гласува също, независимо дали е [мълчаливото мнозинство](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority -на-потребители) във вашата общност или настоящи потребители, които не са знаели, че се провежда гласуване.
 
-Понякога е необходим равен вот. Доколкото можете обаче, наблягайте на [„търсенето на консенсус“](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), а не на консенсуса .
+Понякога е необходим равен вот. Доколкото можете обаче, наблягайте на ["търсенето на консенсус"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), а не на консенсуса .
 
-При процес на търсене на консенсус членовете на общността обсъждат основните опасения, докато не почувстват, че са били адекватно изслушани. Когато останат само второстепенни грижи, общността върви напред. „Търсене на консенсус“ признава, че една общност може да не е в състояние да достигне до перфектен отговор. Вместо това дава приоритет на слушането и дискусията.
+При процес на търсене на консенсус членовете на общността обсъждат основните опасения, докато не почувстват, че са били адекватно изслушани. Когато останат само второстепенни грижи, общността върви напред. "Търсене на консенсус" признава, че една общност може да не е в състояние да достигне до перфектен отговор. Вместо това дава приоритет на слушането и дискусията.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
@@ -241,7 +241,7 @@ related:
 
 Позволяването на тези разговори да продължат е не само лошо за разглеждания проблем, но и за здравето на вашата общност. Изпраща съобщение, че този тип разговори са разрешени или дори насърчавани, и може да обезсърчи хората да повдигат или разрешават бъдещи проблеми.
 
-С всяка точка, изказана от вас или от други, запитайте се: „Как това ни доближава до решение?“_
+С всяка точка, изказана от вас или от други, запитайте се: "Как това ни доближава до решение?"_
 
 Ако разговорът започва да се разплита, попитайте групата _"Кои стъпки трябва да предприемем по-нататък?"_, за да пренасочите разговора.
 
diff --git a/_articles/bg/code-of-conduct.md b/_articles/bg/code-of-conduct.md
index 6b8ebf70a3b..9e20d1f7e1a 100644
--- a/_articles/bg/code-of-conduct.md
+++ b/_articles/bg/code-of-conduct.md
@@ -31,7 +31,7 @@ related:
 
 Където можете, използвайте предшестващо състояние на техниката. [Споразумението на сътрудниците](https://contributor-covenant.org/) е код за поведение, който се използва от над 40 000 проекта с отворен код, включително Kubernetes, Rails и Swift.
 
-[Кодексът на поведение на Django](https://www.djangoproject.com/conduct/) и [Кодексът на поведение на гражданите](https://web.archive.org/web/20200330154000/http://citizencodeofconduct. org/) също са два добри примера на кодекс на поведение.
+[Кодексът на поведение на Django](https://www.djangoproject.com/conduct/) и [Кодексът на поведение на гражданите](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) също са два добри примера на кодекс на поведение.
 
 Поставете файл CODE_OF_CONDUCT в основната директория на вашия проект и го направете видим за вашата общност, като го свържете от вашия CONTRIBUTING или README файл.
 
@@ -58,7 +58,7 @@ related:
 
 > Случаи на злоупотреба, тормоз или по друг начин неприемливо поведение могат да бъдат докладвани чрез имейл **khmer-project@idyll.org**, който отива само до C. Titus Brown и Michael R. Crusoe. За да съобщите за проблем, свързан с някой от тях, моля, изпратете имейл до **Judi Brown Clarke, Ph.D.** директора по разнообразието в BEACON Center for the Study of Evolution in Action, Център за науки и технологии на NSF.*
 
-За вдъхновение вижте [ръководството за прилагане] на Django (https://www.djangoproject.com/conduct/enforcement-manual/) (въпреки че може да не се нуждаете от нещо толкова изчерпателно, в зависимост от размера на вашия проект).
+За вдъхновение вижте [ръководството за прилагане](https://www.djangoproject.com/conduct/enforcement-manual/) на Django (въпреки че може да не се нуждаете от нещо толкова изчерпателно, в зависимост от размера на вашия проект).
 
 ## Налагане на вашия кодекс на поведение
 
diff --git a/_articles/bg/finding-users.md b/_articles/bg/finding-users.md
index 88e174c104e..d30a49dd486 100644
--- a/_articles/bg/finding-users.md
+++ b/_articles/bg/finding-users.md
@@ -26,7 +26,7 @@ related:
 
 ![Картография README](/assets/images/finding-users/cartography.jpg)
 
-За по-задълбочено потапяне в съобщенията вижте упражнението на Mozilla [„Личности и пътеки“](https://mozillascience.github.io/working-open-workshop/personas_pathways/) за разработване на потребителски персони.
+За по-задълбочено потапяне в съобщенията вижте упражнението на Mozilla ["Личности и пътеки"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) за разработване на потребителски персони.
 
 ## Help people find and follow your project
 
@@ -55,7 +55,7 @@ related:
 
 [@adrianholovaty](https://news.ycombinator.com/item?id=7531689), съ-създател на Django, каза, че уебсайтът е _"далеч най-доброто нещо, което направихме с Django в ранните дни"_ .
 
-Ако вашият проект се хоства в GitHub, можете да използвате [GitHub Pages](https://pages.github.com/), за да създадете лесно уебсайт. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) и [Middleman](https://middlemanapp.com/) са [няколко примера] (https://github.com/showcases/github-pages-examples) от отлични, изчерпателни уебсайтове.
+Ако вашият проект се хоства в GitHub, можете да използвате [GitHub Pages](https://pages.github.com/), за да създадете лесно уебсайт. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) и [Middleman](https://middlemanapp.com/) са [няколко примера](https://github.com/showcases/github-pages-examples) от отлични, изчерпателни уебсайтове.
 
 ![Начална страница на Vagrant](/assets/images/finding-users/vagrant_homepage.png)
 
diff --git a/_articles/bg/getting-paid.md b/_articles/bg/getting-paid.md
index 641e38a397d..218a61a6aa1 100644
--- a/_articles/bg/getting-paid.md
+++ b/_articles/bg/getting-paid.md
@@ -30,7 +30,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
-  Финансовите дарения наистина добавят чувство за отговорност за някои. (...) За нас е важно, в глобално свързания, забързан свят, в който живеем, да можем да кажем „не сега, искам да правя нещо съвсем различно“.
+  Финансовите дарения наистина добавят чувство за отговорност за някои. (...) За нас е важно, в глобално свързания, забързан свят, в който живеем, да можем да кажем "не сега, искам да правя нещо съвсем различно".
   <p markdown="1" class="pquote-credit">
 — @alloy, ["Защо не приемаме дарения"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
   </p>
@@ -70,9 +70,9 @@ related:
 
 Много компании разработват програми с отворен код, за да изградят своята марка и да наемат качествени таланти.
 
-@hueniverse например установи, че има финансови причини, които да оправдаят [инвестицията на Walmart в отворен код](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in- open-source-isn-t-cheap.html). И @jamesgpearce установи, че програмата с отворен код на Facebook [има значение](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) при набирането на персонал:
+@hueniverse например установи, че има финансови причини, които да оправдаят [инвестицията на Walmart в отворен код](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). И @jamesgpearce установи, че програмата с отворен код на Facebook [има значение](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) при набирането на персонал:
 
-> Тя е тясно свързана с нашата хакерска култура и начина, по който нашата организация се възприемаше. Попитахме нашите служители: „Знаехте ли за софтуерната програма с отворен код във Facebook?“. Две трети казаха "Да". Половината казаха, че програмата е допринесла положително за решението им да работят за нас. Това не са пределни числа и се надявам, че тенденцията ще продължи.
+> Тя е тясно свързана с нашата хакерска култура и начина, по който нашата организация се възприемаше. Попитахме нашите служители: "Знаехте ли за софтуерната програма с отворен код във Facebook?". Две трети казаха "Да". Половината казаха, че програмата е допринесла положително за решението им да работят за нас. Това не са пределни числа и се надявам, че тенденцията ще продължи.
 
 Ако вашата компания тръгне по този път, важно е да поддържате ясни границите между общността и корпоративната дейност. В крайна сметка отвореният код се поддържа чрез принос от хора по целия свят и това е по-голямо от която и да е компания или местоположение.
 
@@ -95,11 +95,11 @@ related:
 
 * @Homebrew (и [много други поддържащи и организации](https://github.com/sponsors/community)) финансират работата си чрез [Спонсори на GitHub](https://github.com/sponsors)
 * @gaearon финансира работата си върху [Redux](https://github.com/reactjs/redux) чрез [кампания за групово финансиране на Patreon](https://redux.js.org/)
-* @andrewgodwin финансира работа по миграции на схема на Django [чрез кампания на Kickstarter] (https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+* @andrewgodwin финансира работа по миграции на схема на Django [чрез кампания на Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
 
 И накрая, понякога проекти с отворен код дават премии за проблеми, за които може да обмислите да помогнете.
 
-* @ConnorChristie успя да получи плащане за [помощ](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F %2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol работят по своята JavaScript библиотека [чрез награда за gitcoin](https://gitcoin.co/).
+* @ConnorChristie успя да получи плащане за [помощ](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol работят по своята JavaScript библиотека [чрез награда за gitcoin](https://gitcoin.co/).
 * @mamiM направи японски преводи за @MetaMask след [изданието беше финансирано от Bounties Network](https://explorer.bounties.network/bounty/134).
 
 ## Намиране на финансиране за вашия проект
diff --git a/_articles/bg/how-to-contribute.md b/_articles/bg/how-to-contribute.md
index 0914691e170..73795bec604 100644
--- a/_articles/bg/how-to-contribute.md
+++ b/_articles/bg/how-to-contribute.md
@@ -60,7 +60,7 @@ related:
 
 ### Не е нужно да добавяте код
 
-Често срещано погрешно схващане относно приноса към отворен код е, че трябва да допринесете с код. Всъщност често другите части на проекта са [най-пренебрегвани или пренебрегвани] (https://github.com/blog/2195-the-shape-of-open-source). Ще направите _огромна_ услуга на проекта, като предложите да се включите с тези видове принос!
+Често срещано погрешно схващане относно приноса към отворен код е, че трябва да допринесете с код. Всъщност често другите части на проекта са [най-пренебрегвани или пренебрегвани](https://github.com/blog/2195-the-shape-of-open-source). Ще направите _огромна_ услуга на проекта, като предложите да се включите с тези видове принос!
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
@@ -90,7 +90,7 @@ related:
 * Напишете и подобрете документацията на проекта, [както @CBID2 направи за документацията на OpenSauced](https://github.com/open-sauced/docs/pull/151)
 * Подгответе папка с примери, показващи как се използва проектът
 * Стартирайте бюлетин за проекта или подредете акценти от пощенския списък, [както направи @opensauced за своя продукт](https://news.opensauced.pizza/about/)
-* Напишете уроци за проекта, [както направиха сътрудниците на PyPA] (https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Напишете уроци за проекта, [както направиха сътрудниците на PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
 * Напишете превод за документацията на проекта, [както @frontendwizard направи за инструкциите за CSS Flexbox предизвикателството на freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
 
 <aside markdown="1" class="pquote">
@@ -104,7 +104,7 @@ related:
 ### Обичате ли да организирате?
 
 * Връзка към дублирани проблеми и предлагане на теми за нови проблеми, за да поддържате организацията
-* Прегледайте отворените проблеми и предложете затваряне на стари, [както направи @nzakas за ESLint] (https://github.com/eslint/eslint/issues/6765)
+* Прегледайте отворените проблеми и предложете затваряне на стари, [както направи @nzakas за ESLint](https://github.com/eslint/eslint/issues/6765)
 * Задавайте изясняващи въпроси по наскоро открити въпроси, за да придвижите дискусията напред
 
 ### Обичате ли да кодирате?
@@ -116,7 +116,7 @@ related:
 
 ### Обичате ли да помагате на хората?
 
-* Отговорете на въпроси относно проекта напр. Stack Overflow ([като този пример на Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying) -to-ge)) или Reddit
+* Отговорете на въпроси относно проекта напр. Stack Overflow ([като този пример на Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) или Reddit
 * Отговаряйте на въпроси за хора по отворени въпроси
 * Помогнете за модерирането на дискусионните табла или каналите за разговори
 
@@ -128,7 +128,7 @@ related:
 
 ### Не е нужно просто да работите върху софтуерни проекти!
 
-Докато „отворен код“ често се отнася до софтуер, можете да си сътрудничите по почти всичко. Има книги, рецепти, списъци и класове, които се разработват като проекти с отворен код.
+Докато "отворен код" често се отнася до софтуер, можете да си сътрудничите по почти всичко. Има книги, рецепти, списъци и класове, които се разработват като проекти с отворен код.
 
 Например:
 
@@ -168,7 +168,7 @@ related:
 * **Сътрудници:** Всеки, който е допринесъл с нещо обратно към проекта
 * **Членове на общността:** Хората, които използват проекта. Те могат да бъдат активни в разговорите или да изразят мнението си за посоката на проекта
 
-По-големите проекти могат също да имат подкомисии или работни групи, фокусирани върху различни задачи, като инструменти, сортиране, модериране на общността и организиране на събития. Потърсете в уебсайта на даден проект страница за „екип“ или в хранилището за документация за управление, за да намерите тази информация.
+По-големите проекти могат също да имат подкомисии или работни групи, фокусирани върху различни задачи, като инструменти, сортиране, модериране на общността и организиране на събития. Потърсете в уебсайта на даден проект страница за "екип" или в хранилището за документация за управление, за да намерите тази информация.
 
 Към проекта има и документация. Тези файлове обикновено са изброени в горното ниво на хранилището.
 
@@ -176,12 +176,12 @@ related:
 * **README:** README е ръководството с инструкции, което приветства новите членове на общността в проекта. Той обяснява защо проектът е полезен и как да започнете.
 * **ПРИНОС:** Докато README помагат на хората да _използват_ проекта, допринасящите документи помагат на хората да _допринасят_ за проекта. Той обяснява какви видове вноски са необходими и как работи процесът. Въпреки че не всеки проект има ПРИНОСЯЩ файл, присъствието му сигнализира, че това е приветлив проект, за който можете да допринесете. Добър пример за ефективно ръководство за принос би било това от [хранилището на документи на Codecademy](https://www.codecademy.com/resources/docs/contribution-guide).
 * **CODE_OF_CONDUCT:** Кодексът за поведение определя основните правила за свързаното поведение на участниците и спомага за създаването на приятелска, гостоприемна среда. Въпреки че не всеки проект има файл CODE_OF_CONDUCT, присъствието му сигнализира, че това е приветлив проект, за който можете да допринесете.
-* **Друга документация:** Може да има допълнителна документация, като уроци, инструкции или политики за управление, особено за по-големи проекти като [Astro Docs](https://docs.astro.build/en/contribute/#contributing -към-документи).
+* **Друга документация:** Може да има допълнителна документация, като уроци, инструкции или политики за управление, особено за по-големи проекти като [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
 
 И накрая, проектите с отворен код използват следните инструменти за организиране на дискусия. Четенето на архивите ще ви даде добра представа за това как общността мисли и работи.
 
 * **Проследяване на проблеми:** Където хората обсъждат въпроси, свързани с проекта.
-* **Заявки за изтегляне:** Когато хората обсъждат и преглеждат промените, които са в ход, независимо дали са за подобряване на реда код на сътрудника, използването на граматика, използването на изображения и т.н. Някои проекти, като [MDN Web Docs](https: //github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), използват определени потоци за действие на GitHub, за да автоматизират и ускорят своите прегледи на кода.
+* **Заявки за изтегляне:** Когато хората обсъждат и преглеждат промените, които са в ход, независимо дали са за подобряване на реда код на сътрудника, използването на граматика, използването на изображения и т.н. Някои проекти, като [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), използват определени потоци за действие на GitHub, за да автоматизират и ускорят своите прегледи на кода.
 * **Дискусионни форуми или пощенски списъци:** Някои проекти могат да използват тези канали за теми за разговор (например _"Как да..."_ или _"Какво мислиш за..."_ вместо грешка отчети или заявки за функции). Други използват инструмента за проследяване на проблеми за всички разговори. Добър пример за това би бил [седмичният бюлетин на CHAOSS](https://chaoss.community/news/)
 * **Синхронен чат канал:** Някои проекти използват чат канали (като Slack или IRC) за непринуден разговор, сътрудничество и бърз обмен. Добър пример за това би била [общността на Discord на EddieHub](http://discord.eddiehub.org/).
 
@@ -189,7 +189,7 @@ related:
 
 Сега, след като разбрахте как работят проектите с отворен код, време е да намерите проект, за който да допринесете!
 
-Ако никога преди не сте допринасяли за отворения код, приемете съвет от президента на САЩ Джон Ф. Кенеди, който веднъж каза: „Не питайте какво вашата страна може да направи за вас – попитайте какво можете да направите вие за вашата страна.“_
+Ако никога преди не сте допринасяли за отворения код, приемете съвет от президента на САЩ Джон Ф. Кенеди, който веднъж каза: "Не питайте какво вашата страна може да направи за вас – попитайте какво можете да направите вие за вашата страна."_
 
 <aside markdown="1" class="pquote">
   <img src="/assets/images/how-to-contribute/johnfkennedy.jpg" class="pquote-avatar" alt="avatar">
@@ -261,7 +261,7 @@ related:
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-  Колко често хората се ангажират? (В GitHub можете да намерите това, като щракнете върху „Комити“ в горната лента.)
+  Колко често хората се ангажират? (В GitHub можете да намерите това, като щракнете върху "Комити" в горната лента.)
   </label>
 </div>
 
@@ -298,7 +298,7 @@ related:
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    Приключват ли се проблемите? (В GitHub щракнете върху раздела „затворен“ на страницата с проблеми, за да видите затворени проблеми.)
+    Приключват ли се проблемите? (В GitHub щракнете върху раздела "затворен" на страницата с проблеми, за да видите затворени проблеми.)
   </label>
 </div>
 
@@ -335,7 +335,7 @@ related:
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox13" class="overflow-hidden d-block text-normal">
-    Колко наскоро бяха обединени всички заявки за изтегляне? (В GitHub щракнете върху раздела „затворено“ на страницата „Заявки за изтегляне“, за да видите затворени PR-и.)
+    Колко наскоро бяха обединени всички заявки за изтегляне? (В GitHub щракнете върху раздела "затворено" на страницата "Заявки за изтегляне", за да видите затворени PR-и.)
   </label>
 </div>
 
@@ -419,7 +419,7 @@ related:
 
 > 😇 _(като коментар) "@-maintainer Здравейте! Как да продължим с този PR?"_
 >
-> 😢 _(като имейл) „Здравейте, съжалявам, че ви безпокоя по имейл, но се чудех дали сте имали възможност да прегледате моя PR“_
+> 😢 _(като имейл) "Здравейте, съжалявам, че ви безпокоя по имейл, но се чудех дали сте имали възможност да прегледате моя PR"_
 
 **Добре е да задавате въпроси (но бъдете търпеливи!).** Всеки е бил нов в проекта в някакъв момент и дори опитните сътрудници трябва да навлизат в крак, когато разглеждат нов проект. По същия принцип дори дългогодишните поддържащи не винаги са запознати с всяка част от проекта. Покажете им същото търпение, което бихте искали те да проявяват към вас.
 
@@ -447,7 +447,7 @@ related:
 
 Преди да отворите проблем или заявка за изтегляне, проверете допринасящите документи на проекта (обикновено файл, наречен CONTRIBUTING или в README), за да видите дали трябва да включите нещо конкретно. Например, те могат да поискат да следвате шаблон или да изискват да използвате тестове.
 
-Ако искате да направите значителен принос, отворете проблем, който да попитате, преди да работите по него. Полезно е да гледате проекта известно време (в GitHub, [можете да щракнете върху „Гледане“](https://help.github.com/articles/watching-repositories/), за да бъдете уведомени за всички разговори) и да стигнете до познавайте членовете на общността, преди да вършите работа, която може да не бъде приета.
+Ако искате да направите значителен принос, отворете проблем, който да попитате, преди да работите по него. Полезно е да гледате проекта известно време (в GitHub, [можете да щракнете върху "Гледане"](https://help.github.com/articles/watching-repositories/), за да бъдете уведомени за всички разговори) и да стигнете до познавайте членовете на общността, преди да вършите работа, която може да не бъде приета.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -478,13 +478,13 @@ related:
 * Изпратете малки корекции като печатна грешка, повредена връзка или очевидна грешка.
 * Започнете работа по принос, който вече е поискан или който вече сте обсъждали в даден брой.
 
-Заявката за изтегляне не трябва да представлява завършена работа. Обикновено е по-добре да отворите заявка за изтегляне рано, така че другите да могат да гледат или да дадат обратна връзка за напредъка ви. Просто го отворете като „чернова“ или маркирайте като „WIP“ (Работа в процес) в реда за тема или в секциите „Бележки към рецензентите“, ако са предоставени (или можете просто да създадете свой собствен. Подобно на това: `**## Бележки към рецензента**`). Винаги можете да добавите още ангажименти по-късно.
+Заявката за изтегляне не трябва да представлява завършена работа. Обикновено е по-добре да отворите заявка за изтегляне рано, така че другите да могат да гледат или да дадат обратна връзка за напредъка ви. Просто го отворете като "чернова" или маркирайте като "WIP" (Работа в процес) в реда за тема или в секциите „Бележки към рецензентите“, ако са предоставени (или можете просто да създадете свой собствен. Подобно на това: `**## Бележки към рецензента**`). Винаги можете да добавите още ангажименти по-късно.
 
 Ако проектът е в GitHub, ето как да изпратите заявка за изтегляне:
 
-* **[Разклонете хранилището](https://guides.github.com/activities/forking/)** и го клонирайте локално. Свържете вашето локално към оригиналното хранилище „нагоре по веригата“, като го добавите като дистанционно. Изтегляйте често промените от „нагоре по веригата“, така че да сте в течение, така че когато изпратите заявката си за изтегляне, конфликтите при сливане ще бъдат по-малко вероятни. (Вижте по-подробни инструкции [тук](https://help.github.com/articles/syncing-a-fork/).)
+* **[Разклонете хранилището](https://guides.github.com/activities/forking/)** и го клонирайте локално. Свържете вашето локално към оригиналното хранилище "нагоре по веригата", като го добавите като дистанционно. Изтегляйте често промените от "нагоре по веригата", така че да сте в течение, така че когато изпратите заявката си за изтегляне, конфликтите при сливане ще бъдат по-малко вероятни. (Вижте по-подробни инструкции [тук](https://help.github.com/articles/syncing-a-fork/).)
 * **[Създайте клон](https://guides.github.com/introduction/flow/)** за вашите редакции.
-* **Посочете всички съответни проблеми** или подкрепяща документация във вашия PR (например „Затваря #37.“)
+* **Посочете всички съответни проблеми** или подкрепяща документация във вашия PR (например "Затваря #37.")
 * **Включете екранни снимки преди и след**, ако вашите промени включват разлики в HTML/CSS. Плъзнете и пуснете изображенията в тялото на вашата заявка за изтегляне.
 * **Тествайте промените си!** Стартирайте промените си срещу всички съществуващи тестове, ако съществуват, и създайте нови, когато е необходимо. Важно е да се уверите, че вашите промени не нарушават съществуващия проект.
 * **Допринесете в стила на проекта** според възможностите си. Това може да означава използване на отстъпи, точка и запетая или коментари по различен начин, отколкото бихте направили във вашето собствено хранилище, но улеснява поддържащия да слива, другите да разбират и поддържат в бъдеще.
diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
index e5a50aa189d..ede0f600629 100644
--- a/_articles/bg/leadership-and-governance.md
+++ b/_articles/bg/leadership-and-governance.md
@@ -24,11 +24,11 @@ related:
 * **Сътрудник**
 * **Комитер**
 
-**За някои проекти „поддържащите“** са единствените хора в проект с достъп за ангажиране. В други проекти те са просто хората, които са изброени в README като поддържащи.
+**За някои проекти "поддържащите"** са единствените хора в проект с достъп за ангажиране. В други проекти те са просто хората, които са изброени в README като поддържащи.
 
 Поддържащият не е задължително да е някой, който пише код за вашия проект. Може да е някой, който е свършил много работа по евангелизирането на вашия проект, или писмена документация, която е направила проекта по-достъпен за другите. Независимо от това, което прави всеки ден, поддържащият вероятно е някой, който се чувства отговорен за посоката на проекта и се е ангажирал да го подобри.
 
-**„Сътрудник“ може да бъде всеки**, който коментира проблем или заявка за изтегляне, хора, които добавят стойност към проекта (независимо дали става въпрос за сортиране на проблеми, писане на код или организиране на събития), или всеки с обединена заявка за изтегляне (може би най-тясната дефиниция на сътрудник).
+**"Сътрудник" може да бъде всеки**, който коментира проблем или заявка за изтегляне, хора, които добавят стойност към проекта (независимо дали става въпрос за сортиране на проблеми, писане на код или организиране на събития), или всеки с обединена заявка за изтегляне (може би най-тясната дефиниция на сътрудник).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -38,13 +38,13 @@ related:
   </p>
 </aside>
 
-**Терминът „извършител“** може да се използва за разграничаване на достъпа за ангажиране, който е специфичен тип отговорност, от други форми на принос.
+**Терминът "извършител"** може да се използва за разграничаване на достъпа за ангажиране, който е специфичен тип отговорност, от други форми на принос.
 
 Въпреки че можете да дефинирате ролите си в проекта както желаете, [помислете дали да не използвате по-широки дефиниции](../how-to-contribute/#what-it-means-to-contribute), за да насърчите повече форми на принос. Можете да използвате лидерски роли, за да признаете официално хора, които са направили изключителен принос към вашия проект, независимо от техните технически умения.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
-  Може да ме познавате като „изобретателя“ на Django...но всъщност аз съм човекът, който беше нает да работи върху нещо година след като то вече беше направено. (...) Хората подозират, че съм успешен благодарение на уменията ми за програмиране...но в най-добрия случай съм среден програмист.
+  Може да ме познавате като "изобретателя" на Django...но всъщност аз съм човекът, който беше нает да работи върху нещо година след като то вече беше направено. (...) Хората подозират, че съм успешен благодарение на уменията ми за програмиране...но в най-добрия случай съм среден програмист.
   <p markdown="1" class="pquote-credit">
 — @jacobian, ["Основна бележка на PyCon 2015" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
   </p>
@@ -58,7 +58,7 @@ related:
 
 За по-голям проект, ако имате уебсайт, създайте страница на екип или избройте ръководителите на проекта си там. Например [Postgres](https://github.com/postgres/postgres/) има [изчерпателна екипна страница](https://www.postgresql.org/community/contributors/) с кратки профили за всеки участник.
 
-Ако вашият проект има много активна общност на сътрудници, можете да сформирате „основен екип“ от поддържащи или дори подкомитети от хора, които поемат отговорност за различни проблемни области (например сигурност, сортиране на проблеми или поведение на общността). Позволете на хората да се самоорганизират и доброволно изпълняват ролите, които ги вълнуват най-много, вместо да ги възлагат.
+Ако вашият проект има много активна общност на сътрудници, можете да сформирате "основен екип" от поддържащи или дори подкомитети от хора, които поемат отговорност за различни проблемни области (например сигурност, сортиране на проблеми или поведение на общността). Позволете на хората да се самоорганизират и доброволно изпълняват ролите, които ги вълнуват най-много, вместо да ги възлагат.
 
 <aside markdown="1" class="pquote">
   \[Ние\] допълваме основния екип с няколко "подекипа". Всеки подекип е фокусиран върху конкретна област, например езиков дизайн или библиотеки. (...) За да се осигури глобална координация и силна, съгласувана визия за проекта като цяло, всеки подекип се ръководи от член на основния екип.
@@ -95,9 +95,9 @@ related:
 
 Има три общи структури на управление, свързани с проекти с отворен код.
 
-* **BDFL:** BDFL означава „Доброжелателен диктатор за цял живот“. При тази структура един човек (обикновено първоначалният автор на проекта) има последната дума за всички основни решения по проекта. [Python](https://github.com/python) е класически пример. По-малките проекти вероятно са BDFL по подразбиране, защото има само един или двама поддържащи. Проект, който произхожда от компания, може също да попадне в категорията BDFL.
+* **BDFL:** BDFL означава "Доброжелателен диктатор за цял живот". При тази структура един човек (обикновено първоначалният автор на проекта) има последната дума за всички основни решения по проекта. [Python](https://github.com/python) е класически пример. По-малките проекти вероятно са BDFL по подразбиране, защото има само един или двама поддържащи. Проект, който произхожда от компания, може също да попадне в категорията BDFL.
 
-* **Меритокрация:** **(Забележка: терминът „меритокрация“ носи отрицателни конотации за някои общности и има [сложна социална и политическа история](http://geekfeminism.wikia.com/wiki/Meritocracy).) ** При меритокрацията на активните участници в проекти (тези, които демонстрират „заслуги“) се дава официална роля за вземане на решения. Решенията обикновено се вземат въз основа на чист консенсус при гласуване. Концепцията за меритокрация е въведена от [Фондация Apache](https://www.apache.org/); [всички проекти на Apache](https://www.apache.org/index.html#projects-list) са меритокрации. Вноски могат да се правят само от лица, представляващи себе си, а не от компания.
+* **Меритокрация:** **(Забележка: терминът "меритокрация" носи отрицателни конотации за някои общности и има [сложна социална и политическа история](http://geekfeminism.wikia.com/wiki/Meritocracy).) ** При меритокрацията на активните участници в проекти (тези, които демонстрират "заслуги") се дава официална роля за вземане на решения. Решенията обикновено се вземат въз основа на чист консенсус при гласуване. Концепцията за меритокрация е въведена от [Фондация Apache](https://www.apache.org/); [всички проекти на Apache](https://www.apache.org/index.html#projects-list) са меритокрации. Вноски могат да се правят само от лица, представляващи себе си, а не от компания.
 
 * **Либерален принос:** При либерален модел на принос хората, които вършат най-много работа, се признават за най-влиятелни, но това се основава на текуща работа, а не на исторически принос. Решенията за големи проекти се вземат въз основа на процес на търсене на консенсус (обсъждане на основните оплаквания), а не на чисто гласуване, и се стремят да включват възможно най-много гледни точки на общността. Популярни примери за проекти, които използват либерален модел на принос, включват [Node.js](https://foundation.nodejs.org/) и [Rust](https://www.rust-lang.org/).
 
@@ -131,7 +131,7 @@ related:
 
 Важно е търговската дейност да се третира като нормална и просто като още един източник на енергия за развитие. Разбира се, платените разработчици не трябва да получават специално отношение спрямо неплатените; всеки принос трябва да бъде оценен според техническите си качества. Въпреки това, хората трябва да се чувстват комфортно да участват в търговска дейност и да се чувстват комфортно да посочват своите случаи на употреба, когато спорят в полза на определено подобрение или функция.
 
-"Комерсиален" е напълно съвместим с "отворен код". „Търговски“ просто означава, че някъде има замесени пари – че софтуерът се използва в търговията, което е все по-вероятно, тъй като даден проект получава приемане. (Когато софтуер с отворен код се използва като част от продукт с неотворен код, цялостният продукт все още е „патентован“ софтуер, въпреки че, подобно на отворен код, може да се използва за търговски или нетърговски цели.)
+"Комерсиален" е напълно съвместим с "отворен код". "Търговски" просто означава, че някъде има замесени пари – че софтуерът се използва в търговията, което е все по-вероятно, тъй като даден проект получава приемане. (Когато софтуер с отворен код се използва като част от продукт с неотворен код, цялостният продукт все още е „патентован“ софтуер, въпреки че, подобно на отворен код, може да се използва за търговски или нетърговски цели.)
 
 Като всеки друг, комерсиално мотивираните разработчици печелят влияние в проекта чрез качеството и количеството на техния принос. Очевидно програмист, който получава заплащане за времето си, може да е в състояние да направи повече от някой, който не получава заплащане, но това е добре: плащането е само един от многото възможни фактори, които могат да повлияят на това колко прави някой. Поддържайте дискусиите по проекта си фокусирани върху приноса, а не върху външните фактори, които позволяват на хората да направят този принос.
 
@@ -147,7 +147,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
-  Нашата цел е да предоставим инфраструктура, която общностите могат да използват, за да бъдат самоустойчиви, като по този начин създаваме среда, в която всички —„сътрудници, поддръжници, спонсори — извличат конкретни ползи от това.
+  Нашата цел е да предоставим инфраструктура, която общностите могат да използват, за да бъдат самоустойчиви, като по този начин създаваме среда, в която всички — сътрудници, поддръжници, спонсори — извличат конкретни ползи от това.
   <p markdown="1" class="pquote-credit">
 — @piamancini, ["Преминаване извън рамката на благотворителността"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
   </p>
diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
index 2b602d5f5fb..6c5496680df 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://help.github.com/articles/creating-a-new-repository/) в GitHub, имате опцията да направите хранилището **частно** или **публично**.
 
 ![Създаване на хранилище](/assets/images/legal/repo-create-name.png)
 
@@ -60,9 +60,9 @@ related:
 
 Вашият проект много вероятно има (или ще има) **зависимости**, всяка от които ще има собствен лиценз с отворен код с условия, които трябва да спазвате. Например, ако сте с отворен код за Node.js проект, вероятно ще използвате библиотеки от Node Package Manager (npm).
 
-Зависимости с **разрешителни лицензи** като [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC ](https://choosealicense.com/licenses/isc) и [BSD](https://choosealicense.com/licenses/bsd-3-clause) ви позволяват да лицензирате проекта си както искате.
+Зависимости с **разрешителни лицензи** като [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc) и [BSD](https://choosealicense.com/licenses/bsd-3-clause) ви позволяват да лицензирате проекта си както искате.
 
-Зависимостите с **лицензи за авторско право** изискват по-голямо внимание. Включително всяка библиотека със „силен“ лиценз за копиралефт като [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), или [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) изисква да изберете идентичен или [съвместим лиценз](https://www.gnu.org/licenses/license-list.en.html #GPLCompatibleLicenses) за вашия проект. Библиотеки с „ограничен“ или „слаб“ лиценз за копиралефт като [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) и [LGPL](https://choosealicense.com/licenses/lgpl -3.0/) могат да бъдат включени в проекти с произволен лиценз, при условие че следвате [допълнителните правила](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft% 20лицензите%20също%20задължават%20потребителите%20да%20издават%20своите%20промени.%20Въпреки това%2C%20това%20изискване%20се прилага%20за%20%20по-тесен%20набор%20от%20код.) посочват те.
+Зависимостите с **лицензи за авторско право** изискват по-голямо внимание. Включително всяка библиотека със "силен" лиценз за копиралефт като [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), или [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) изисква да изберете идентичен или [съвместим лиценз](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) за вашия проект. Библиотеки с „ограничен“ или „слаб“ лиценз за копиралефт като [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) и [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) могат да бъдат включени в проекти с произволен лиценз, при условие че следвате [допълнителните правила](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) посочват те.
  
 Можете също така да разгледате **общностите**, които се надявате да използвате и да допринесете за вашия проект:
 
@@ -72,7 +72,7 @@ related:
 
 Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник ([вижте по-долу](#does-my-project-need-an-additional-contributor-agreement)), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#what-does-my-companys-legal-team-need-to-know) за насоки.
 
-Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на един от лицензите, споменати по-горе, ще направи вашия проект GitHub с отворен код. Ако искате да видите други опции, вижте [choosealicense.com](https://choosealicense.com), за да намерите правилния лиценз за вашия проект, дори ако [не е софтуер](https://choosealicense .com/non-software/).
+Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на един от лицензите, споменати по-горе, ще направи вашия проект GitHub с отворен код. Ако искате да видите други опции, вижте [choosealicense.com](https://choosealicense.com), за да намерите правилния лиценз за вашия проект, дори ако [не е софтуер](https://choosealicense.com/non-software/).
 
 ## Какво ще стане, ако искам да сменя лиценза на моя проект?
 
@@ -80,7 +80,7 @@ related:
 
 Например, докато вашият проект расте, той добавя зависимости или потребители, или вашата компания променя стратегии, всяка от които може да изисква или иска различен лиценз. Освен това, ако сте пропуснали да лицензирате проекта си от самото начало, добавянето на лиценз е на практика същото като промяната на лицензите. Има три основни неща, които трябва да имате предвид, когато добавяте или променяте лиценза на вашия проект:
 
-**Сложно е.** Определянето на съвместимостта и съответствието на лиценза и кой притежава авторските права може да стане сложно и объркващо много бързо. Преминаването към нов, но съвместим лиценз за нови версии и приноси е различно от повторното лицензиране на всички съществуващи приноси. Включете юридическия си екип при първия намек за всяко желание за промяна на лицензи. Дори ако имате или можете да получите разрешение от притежателите на авторските права на вашия проект за промяна на лиценза, помислете за въздействието на промяната върху другите потребители и сътрудници на вашия проект. Мислете за промяната на лиценза като за „управленско събитие“ за вашия проект, което е по-вероятно да протече гладко с ясна комуникация и консултация със заинтересованите страни във вашия проект. Още повече причина да изберете и използвате подходящ лиценз за вашия проект от самото му начало!
+**Сложно е.** Определянето на съвместимостта и съответствието на лиценза и кой притежава авторските права може да стане сложно и объркващо много бързо. Преминаването към нов, но съвместим лиценз за нови версии и приноси е различно от повторното лицензиране на всички съществуващи приноси. Включете юридическия си екип при първия намек за всяко желание за промяна на лицензи. Дори ако имате или можете да получите разрешение от притежателите на авторските права на вашия проект за промяна на лиценза, помислете за въздействието на промяната върху другите потребители и сътрудници на вашия проект. Мислете за промяната на лиценза като за "управленско събитие" за вашия проект, което е по-вероятно да протече гладко с ясна комуникация и консултация със заинтересованите страни във вашия проект. Още повече причина да изберете и използвате подходящ лиценз за вашия проект от самото му начало!
 
 **Съществуващият лиценз на вашия проект.** Ако съществуващият лиценз на вашия проект е съвместим с лиценза, който искате да промените, можете просто да започнете да използвате новия лиценз. Това е така, защото ако лиценз A е съвместим с лиценз B, вие ще спазвате условията на A, докато спазвате условията на B (но не непременно обратното). Така че, ако в момента използвате разрешителен лиценз (напр. MIT), можете да промените на лиценз с повече условия, стига да запазите копие от лиценза на MIT и всички свързани бележки за авторски права (т.е. да продължите да спазвате минималните условия на лиценза на MIT). Но ако текущият ви лиценз не е разрешителен (напр. copyleft или нямате лиценз) и не сте единственият притежател на авторските права, не можете просто да промените лиценза на вашия проект на MIT. По същество, с разрешителен лиценз, притежателите на авторските права на проекта са дали предварително разрешение за промяна на лицензите.
 
@@ -90,11 +90,11 @@ related:
 
 ## Моят проект има ли нужда от споразумение за допълнителен сътрудник?
 
-Вероятно не. За по-голямата част от проектите с отворен код лицензът с отворен код имплицитно служи както за входящ (от сътрудници), така и за изходящ (към други сътрудници и потребители) лиценз. Ако вашият проект е в GitHub, Общите условия на GitHub правят „inbound=outbound“ [изрично по подразбиране](https://help.github.com/en/github/site-policy/github-terms-of-service# 6-приноси-под-лиценз за хранилище).
+Вероятно не. За по-голямата част от проектите с отворен код лицензът с отворен код имплицитно служи както за входящ (от сътрудници), така и за изходящ (към други сътрудници и потребители) лиценз. Ако вашият проект е в GitHub, Общите условия на GitHub правят "inbound=outbound" [изрично по подразбиране](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
 
 Допълнително споразумение за сътрудник – често наричано Споразумение за лиценз на сътрудник (CLA) – може да създаде административна работа за поддържащите проекта. Колко работа добавя едно споразумение зависи от проекта и изпълнението. Обикновено споразумение може да изисква сътрудниците да потвърдят с едно щракване, че имат правата, необходими за принос съгласно лиценза за отворен код на проекта. По-сложно споразумение може да изисква правен преглед и подписване от работодателите на сътрудниците.
 
-Освен това, чрез добавяне на „бумащина“, която според някои е ненужна, трудна за разбиране или несправедлива (когато получателят на споразумението получава повече права от сътрудниците или обществеността чрез лиценза за отворен код на проекта), допълнително споразумение за сътрудник може да се възприеме като недружелюбно към общността на проекта.
+Освен това, чрез добавяне на "бумащина", която според някои е ненужна, трудна за разбиране или несправедлива (когато получателят на споразумението получава повече права от сътрудниците или обществеността чрез лиценза за отворен код на проекта), допълнително споразумение за сътрудник може да се възприеме като недружелюбно към общността на проекта.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
@@ -108,8 +108,8 @@ related:
 
 * Вашите адвокати искат всички сътрудници изрично да приемат (_подписват_, онлайн или офлайн) условията за принос, може би защото смятат, че самият лиценз за отворен код не е достатъчен (въпреки че е!). Ако това е единствената грижа, споразумение за сътрудник, което потвърждава лиценза за отворен код на проекта, трябва да е достатъчно. [Лицензионното споразумение за jQuery Individual Contributor](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) е добър пример за леко споразумение за допълнителен сътрудник.
 * Вие или вашите адвокати искате разработчиците да декларират, че всеки ангажимент, който правят, е разрешен. Изискването за [Сертификат за произход на разработчици](https://developercertificate.org/) е колко проекта постигат това. Например общността Node.js [използва](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо](https://nodejs.org/en/blog/ uncategorized/notes-from-the-road/#easier-contribution) от техния предишен CLA. Една проста опция за автоматизиране на прилагането на DCO във вашето хранилище е [DCO Probot](https://github.com/probot/dco).
-* Вашият проект използва лиценз с отворен код, който не включва изрично предоставяне на патент (като MIT) и се нуждаете от разрешение за патент от всички сътрудници, някои от които може да работят за компании с големи патентни портфейли, които биха могли да бъдат използвани за насочване към вас или други сътрудници и потребители на проекта. [Лицензионното споразумение за личен сътрудник на Apache] (https://www.apache.org/licenses/icla.pdf) е често използвано допълнително споразумение за сътрудник, което има предоставяне на патент, отразяващо това, което се намира в Лиценза на Apache 2.0.
-* Вашият проект е под лиценз за копиралефт, но също така трябва да разпространявате собствена версия на проекта. Ще трябва всеки сътрудник да ви прехвърли авторски права или да ви предостави (но не на обществеността) разрешителен лиценз. [Споразумението за сътрудник на MongoDB] (https://www.mongodb.com/legal/contributor-agreement) е пример за този тип споразумение.
+* Вашият проект използва лиценз с отворен код, който не включва изрично предоставяне на патент (като MIT) и се нуждаете от разрешение за патент от всички сътрудници, някои от които може да работят за компании с големи патентни портфейли, които биха могли да бъдат използвани за насочване към вас или други сътрудници и потребители на проекта. [Лицензионното споразумение за личен сътрудник на Apache](https://www.apache.org/licenses/icla.pdf) е често използвано допълнително споразумение за сътрудник, което има предоставяне на патент, отразяващо това, което се намира в Лиценза на Apache 2.0.
+* Вашият проект е под лиценз за копиралефт, но също така трябва да разпространявате собствена версия на проекта. Ще трябва всеки сътрудник да ви прехвърли авторски права или да ви предостави (но не на обществеността) разрешителен лиценз. [Споразумението за сътрудник на MongoDB](https://www.mongodb.com/legal/contributor-agreement) е пример за този тип споразумение.
 * Смятате, че вашият проект може да се наложи да промени лицензите през целия си живот и искате участниците да се съгласят предварително с такива промени.
 
 Ако все пак трябва да използвате допълнително споразумение за сътрудници с вашия проект, обмислете използването на интеграция като [CLA помощник](https://github.com/cla-assistant/cla-assistant), за да сведете до минимум разсейването на сътрудниците.
@@ -118,11 +118,11 @@ related:
 
 Ако пускате проект с отворен код като служител на компанията, първо, вашият правен екип трябва да знае, че сте проект с отворен код.
 
-За добро или лошо, помислете да ги уведомите дори ако това е личен проект. Вероятно имате „споразумение за интелектуална собственост на служителите“ с вашата компания, което им дава известен контрол върху вашите проекти, особено ако изобщо са свързани с бизнеса на компанията или използвате ресурси на компанията за разработване на проекта. Вашата компания _би трябвало_ лесно да ви даде разрешение и може би вече го е направила чрез удобно за служителите IP споразумение или фирмена политика. Ако не, можете да преговаряте (например да обясните, че вашият проект служи на целите на компанията за професионално обучение и развитие за вас) или да избягвате да работите по проекта си, докато не намерите по-добра компания.
+За добро или лошо, помислете да ги уведомите дори ако това е личен проект. Вероятно имате "споразумение за интелектуална собственост на служителите" с вашата компания, което им дава известен контрол върху вашите проекти, особено ако изобщо са свързани с бизнеса на компанията или използвате ресурси на компанията за разработване на проекта. Вашата компания _би трябвало_ лесно да ви даде разрешение и може би вече го е направила чрез удобно за служителите IP споразумение или фирмена политика. Ако не, можете да преговаряте (например да обясните, че вашият проект служи на целите на компанията за професионално обучение и развитие за вас) или да избягвате да работите по проекта си, докато не намерите по-добра компания.
 
 **Ако търсите проект с отворен код за вашата компания**, тогава определено ги уведомете. Вашият правен екип вероятно вече има политики за това какъв лиценз с отворен код (и може би допълнително споразумение за сътрудници) да използва въз основа на бизнес изискванията и експертния опит на компанията за гарантиране, че вашият проект е в съответствие с лицензите на неговите зависимости. Ако не, вие и те имате късмет! Вашият правен екип трябва да е нетърпелив да работи с вас, за да разберете тези неща. Някои неща, за които да помислите:
 
-* **Материал на трета страна:** Вашият проект има ли зависимости, създадени от други или по друг начин включва или използва чужд код? Ако те са с отворен код, ще трябва да спазвате лицензите за отворен код на материалите. Това започва с избора на лиценз, който работи с лицензи с отворен код на трети страни ([вижте по-горе](#which-open-source-license-is-appropriate-for-my-project)). Ако вашият проект модифицира или разпространява материал с отворен код на трета страна, вашият правен екип също ще иска да знае, че отговаряте на други условия на лицензите за отворен код на трета страна, като запазване на бележки за авторски права. Ако вашият проект използва чужд код, който няма лиценз с отворен код, вероятно ще трябва да помолите поддържащите трети страни да [добавят лиценз с отворен код](https://choosealicense.com/no-license/# за потребители), и ако не можете да получите такъв, спрете да използвате техния код във вашия проект.
+* **Материал на трета страна:** Вашият проект има ли зависимости, създадени от други или по друг начин включва или използва чужд код? Ако те са с отворен код, ще трябва да спазвате лицензите за отворен код на материалите. Това започва с избора на лиценз, който работи с лицензи с отворен код на трети страни ([вижте по-горе](#which-open-source-license-is-appropriate-for-my-project)). Ако вашият проект модифицира или разпространява материал с отворен код на трета страна, вашият правен екип също ще иска да знае, че отговаряте на други условия на лицензите за отворен код на трета страна, като запазване на бележки за авторски права. Ако вашият проект използва чужд код, който няма лиценз с отворен код, вероятно ще трябва да помолите поддържащите трети страни да [добавят лиценз с отворен код](https://choosealicense.com/no-license/#for-users), и ако не можете да получите такъв, спрете да използвате техния код във вашия проект.
 
 * **Търговски тайни:** Помислете дали има нещо в проекта, което компанията не иска да направи достъпно за широката общественост. Ако е така, можете да отворите останалата част от проекта си, след като извлечете материала, който искате да запазите поверителен.
 
@@ -130,7 +130,7 @@ related:
 
 * **Търговски марки:** Проверете отново дали името на вашия проект [не е в конфликт със съществуващи търговски марки](../starting-a-project/#avoiding-name-conflicts). Ако използвате търговските марки на собствената си компания в проекта, проверете дали това не предизвиква конфликти. [FOSSmarks](http://fossmarks.org/) е практическо ръководство за разбиране на търговските марки в контекста на безплатни проекти с отворен код.
 
-* **Поверителност:** Вашият проект събира ли данни за потребители? „Домашен телефон“ към фирмени сървъри? Вашият правен екип може да ви помогне да спазвате фирмените политики и външните разпоредби.
+* **Поверителност:** Вашият проект събира ли данни за потребители? "Домашен телефон" към фирмени сървъри? Вашият правен екип може да ви помогне да спазвате фирмените политики и външните разпоредби.
 
 Ако пускате първия проект с отворен код на вашата компания, горното е повече от достатъчно, за да преминете (но не се притеснявайте, повечето проекти не би трябвало да предизвикват големи притеснения).
 
@@ -157,4 +157,4 @@ related:
 </aside>
 
 * **Патенти:** Вашата компания може да пожелае да се присъедини към [Open Invention Network](https://www.openinventionnetwork.com/), споделен защитен патентен пул за защита на използването на големи проекти с отворен код от членовете, или да проучи друго [алтернативно патентно лицензиране](https://www.eff.org/document/hacking-patent-system-2016).
-* **Управление:** Особено ако и когато има смисъл да се премести проект към [юридическо лице извън компанията](../leadership-and-governance/#do-i-need-a-legal-entity -to-support-my-project).
+* **Управление:** Особено ако и когато има смисъл да се премести проект към [юридическо лице извън компанията](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
diff --git a/_articles/bg/maintaining-balance-for-open-source-maintainers.md b/_articles/bg/maintaining-balance-for-open-source-maintainers.md
index 4d722cc6726..84444f0a2b4 100644
--- a/_articles/bg/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/bg/maintaining-balance-for-open-source-maintainers.md
@@ -122,23 +122,23 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
   </p>
 </aside>
 
-* **Почивка и презареждане:** Отделете време за вашите хобита и интереси извън отворен код. Вземете почивни дни, за да се отпуснете и да се подмладите – и задайте своя [статус в GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your- profile/personalizing-your-profile#setting-a-status), за да отразява вашата наличност! Добрият нощен сън може да направи голяма разлика в способността ви да поддържате усилията си в дългосрочен план.
+* **Почивка и презареждане:** Отделете време за вашите хобита и интереси извън отворен код. Вземете почивни дни, за да се отпуснете и да се подмладите – и задайте своя [статус в GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status), за да отразява вашата наличност! Добрият нощен сън може да направи голяма разлика в способността ви да поддържате усилията си в дългосрочен план.
 
    Ако намирате определени аспекти от вашия проект за особено приятни, опитайте се да структурирате работата си, така че да можете да я изживявате през целия си ден.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- Намирам повече възможност да поръся „моменти на творчество“ в средата на деня, вместо да се опитвам да се изключа вечер.
+ Намирам повече възможност да поръся "моменти на творчество" в средата на деня, вместо да се опитвам да се изключа вечер.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/danielroe">@danielroe</a>, поддържащ Nuxt
   </p>
 </aside>
 
-* **Задайте граници:** Не можете да кажете „да“ на всяка молба. Това може да бъде толкова просто, колкото да кажете: „Не мога да стигна до това в момента и нямам планове за бъдещето“ или да посочите какво искате да правите и какво да не правите в README. Например, можете да кажете: „Аз обединявам само PR-и, които имат ясно изброени причини, поради които са направени“, или „Преглеждам проблемите само в четвъртък от 18 до 19 часа“. Това определя очакванията за другите и ви дава нещо да посочите в други моменти, за да помогнете за намаляване на изискванията от сътрудници или потребители във вашето време.
+* **Задайте граници:** Не можете да кажете "да" на всяка молба. Това може да бъде толкова просто, колкото да кажете: "Не мога да стигна до това в момента и нямам планове за бъдещето" или да посочите какво искате да правите и какво да не правите в README. Например, можете да кажете: "Аз обединявам само PR-и, които имат ясно изброени причини, поради които са направени", или "Преглеждам проблемите само в четвъртък от 18 до 19 часа". Това определя очакванията за другите и ви дава нещо да посочите в други моменти, за да помогнете за намаляване на изискванията от сътрудници или потребители във вашето време.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-За да се доверите смислено на другите по тези оси, не можете да сте някой, който казва „да“ на всяка молба. Правейки това, вие не поддържате никакви граници, професионално или лично, и няма да бъдете надежден колега.
+За да се доверите смислено на другите по тези оси, не можете да сте някой, който казва "да" на всяка молба. Правейки това, вие не поддържате никакви граници, професионално или лично, и няма да бъдете надежден колега.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, поддържащ Homebrew на [Saying No](https://mikemcquaid.com/saying-no/)
   </p>
diff --git a/_articles/bg/metrics.md b/_articles/bg/metrics.md
index d2f4450da79..5d0b4d2d850 100644
--- a/_articles/bg/metrics.md
+++ b/_articles/bg/metrics.md
@@ -57,9 +57,9 @@ related:
 
 Ако използвате мениджър на пакети, като npm или RubyGems.org, за разпространение на вашия проект, може да сте в състояние да проследявате изтеглянията на вашия проект.
 
-Всеки мениджър на пакети може да използва малко по-различна дефиниция на „изтегляне“ и изтеглянията не са непременно свързани с инсталиранията или използването, но предоставя някаква базова линия за сравнение. Опитайте да използвате [Libraries.io](https://libraries.io/), за да проследявате статистическите данни за използването в много популярни мениджъри на пакети.
+Всеки мениджър на пакети може да използва малко по-различна дефиниция на "изтегляне" и изтеглянията не са непременно свързани с инсталиранията или използването, но предоставя някаква базова линия за сравнение. Опитайте да използвате [Libraries.io](https://libraries.io/), за да проследявате статистическите данни за използването в много популярни мениджъри на пакети.
 
-Ако вашият проект е в GitHub, отворете отново страницата „Трафик“. Можете да използвате [графиката за клониране](https://github.com/blog/1873-clone-graphs), за да видите колко пъти вашият проект е бил клониран за даден ден, разбити на общия брой клонинги и уникални клонинги.
+Ако вашият проект е в GitHub, отворете отново страницата "Трафик". Можете да използвате [графиката за клониране](https://github.com/blog/1873-clone-graphs), за да видите колко пъти вашият проект е бил клониран за даден ден, разбити на общия брой клонинги и уникални клонинги.
 
 ![Графика за клониране](/assets/images/metrics/clone_graph.png)
 
@@ -84,7 +84,7 @@ related:
 
 Примери за показатели на общността, които може да искате да проследявате редовно, включват:
 
-* **Общ брой сътрудници и брой ангажименти на сътрудник:** Ви казва колко сътрудници имате и кой е повече или по-малко активен. В GitHub можете да видите това под „Прозрения“ -> „Сътрудници“. В момента тази графика отчита само сътрудници, които са се ангажирали с клона по подразбиране на хранилището.
+* **Общ брой сътрудници и брой ангажименти на сътрудник:** Ви казва колко сътрудници имате и кой е повече или по-малко активен. В GitHub можете да видите това под „Прозрения“ -> "Сътрудници". В момента тази графика отчита само сътрудници, които са се ангажирали с клона по подразбиране на хранилището.
 
 ![Графика на сътрудник](/assets/images/metrics/repo_contributors_specific_graph.png)
 
@@ -112,7 +112,7 @@ related:
 
 [Изследване от Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) предполага, че отзивчивостта на поддържащия е критичен фактор за насърчаване на повтарящи се приноси.
 
-Помислете за [проследяване колко време отнема на вас (или на друг поддържащ) да отговорите на приносите](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), дали проблем или заявка за изтегляне. Отговорът не изисква предприемане на действие. Може да бъде толкова просто, колкото да кажете: _„Благодаря за вашето изпращане! Ще прегледам това през следващата седмица.“_
+Помислете за [проследяване колко време отнема на вас (или на друг поддържащ) да отговорите на приносите](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), дали проблем или заявка за изтегляне. Отговорът не изисква предприемане на действие. Може да бъде толкова просто, колкото да кажете: _"Благодаря за вашето изпращане! Ще прегледам това през следващата седмица."_
 
 Можете също да измерите времето, необходимо за преминаване между етапите в процеса на принос, като например:
 
diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index ebeababb593..cfedd5ad8cd 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -10,17 +10,17 @@ related:
   - building
 ---
 
-## „Какво“ и „защо“ на отворения код
+## "Какво" и "защо" на отворения код
 
 Значи обмисляте да започнете с отворен код? Честито! Светът оценява вашия принос. Нека поговорим какво е отворен код и защо хората го правят.
 
 ### Какво означава "отворен код"?
 
-Когато даден проект е с отворен код, това означава, че **всеки е свободен да използва, изучава, променя и разпространява вашия проект за всякакви цели.** Тези разрешения се прилагат чрез [лиценз за отворен код](https://opensource.org /лицензи).
+Когато даден проект е с отворен код, това означава, че **всеки е свободен да използва, изучава, променя и разпространява вашия проект за всякакви цели.** Тези разрешения се прилагат чрез [лиценз за отворен код](https://opensource.org/licenses).
 
 Отвореният код е мощен, защото намалява бариерите пред приемането и сътрудничеството, позволявайки на хората да разпространяват и подобряват проекти бързо. Също така защото дава на потребителите потенциал да контролират собствените си компютри, в сравнение със затворения код. Например, бизнес, използващ софтуер с отворен код, има опцията да наеме някой, който да направи персонализирани подобрения на софтуера, вместо да разчита изключително на продуктовите решения на доставчик със затворен код.
 
-_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като „свободен софтуер с отворен код“ (FOSS) или „безплатен софтуер с отворен код“ (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената] (#does-open-source-mean-of-charge).
+_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената] (#does-open-source-mean-of-charge).
 
 ### Защо хората отварят кода на работата си?
 
@@ -36,19 +36,19 @@ _Свободен софтуер_ се отнася до същия набор 
 
 * **Сътрудничество:** Проектите с отворен код могат да приемат промени от всеки по света. [Exercism](https://github.com/exercism/), например, е платформа за упражнения по програмиране с над 350 участници.
 
-* **Приемане и ремиксиране:** Проектите с отворен код могат да се използват от всеки за почти всякакви цели. Хората дори могат да го използват за изграждане на други неща. [WordPress](https://github.com/WordPress), например, стартира като разклонение на съществуващ проект, наречен [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part %201/2-b2-cafelog.md).
+* **Приемане и ремиксиране:** Проектите с отворен код могат да се използват от всеки за почти всякакви цели. Хората дори могат да го използват за изграждане на други неща. [WordPress](https://github.com/WordPress), например, стартира като разклонение на съществуващ проект, наречен [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Прозрачност:** Всеки може да провери проект с отворен код за грешки или несъответствия. Прозрачността има значение за правителства като [България](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) или [Съединените щати](https://sourcecode.cio .gov/), регулирани отрасли като банкиране или здравеопазване и софтуер за сигурност като [Let's Encrypt](https://github.com/letsencrypt).
+* **Прозрачност:** Всеки може да провери проект с отворен код за грешки или несъответствия. Прозрачността има значение за правителства като [България](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) или [Съединените щати](https://sourcecode.cio.gov/), регулирани отрасли като банкиране или здравеопазване и софтуер за сигурност като [Let's Encrypt](https://github.com/letsencrypt).
 
 Отвореният код също не е само за софтуер. Можете да отворите всичко - от набори от данни до книги. Разгледайте [GitHub Explore](https://github.com/explore) за идеи какво още можете да отворите.
 
 ### Отворен код означава ли „безплатно“?
 
-Едно от най-големите предимства на отворения код е, че не струва пари. „Безплатно“ обаче е страничен продукт от общата стойност на отворения код.
+Едно от най-големите предимства на отворения код е, че не струва пари. "Безплатно" обаче е страничен продукт от общата стойност на отворения код.
 
-Тъй като [лицензът с отворен код изисква] (https://opensource.org/definition-annotated/) всеки да може да използва, променя и споделя вашия проект за почти всякакви цели, самите проекти обикновено са безплатни. Ако използването на проекта струва пари, всеки може законно да направи копие и вместо това да използва безплатната версия.
+Тъй като [лицензът с отворен код изисква](https://opensource.org/definition-annotated/) всеки да може да използва, променя и споделя вашия проект за почти всякакви цели, самите проекти обикновено са безплатни. Ако използването на проекта струва пари, всеки може законно да направи копие и вместо това да използва безплатната версия.
 
-В резултат на това повечето проекти с отворен код са безплатни, но „безплатно“ не е част от определението за отворен код. Има начини за таксуване за проекти с отворен код индиректно чрез двойно лицензиране или ограничени функции, като същевременно се спазва официалното определение за отворен код.
+В резултат на това повечето проекти с отворен код са безплатни, но "безплатно" не е част от определението за отворен код. Има начини за таксуване за проекти с отворен код индиректно чрез двойно лицензиране или ограничени функции, като същевременно се спазва официалното определение за отворен код.
 
 ## Трябва ли да стартирам собствен проект с отворен код?
 
@@ -62,7 +62,7 @@ _Свободен софтуер_ се отнася до същия набор 
 
 ### Поставяне на вашите цели
 
-Целите могат да ви помогнат да разберете върху какво да работите, на какво да кажете „не“ и къде имате нужда от помощ от другите. Започнете, като се запитате _защо използвам този проект с отворен код?_
+Целите могат да ви помогнат да разберете върху какво да работите, на какво да кажете "не" и къде имате нужда от помощ от другите. Започнете, като се запитате _защо използвам този проект с отворен код?_
 
 Няма един правилен отговор на този въпрос. Може да имате множество цели за един проект или различни проекти с различни цели.
 
@@ -202,7 +202,7 @@ CONTRIBUTING файл казва на вашата публика как да у
 
 В допълнение към комуникацията _как_ очаквате да се държат участниците, кодексът за поведение също има тенденция да описва към кого се отнасят тези очаквания, кога се прилагат и какво да направите, ако възникне нарушение.
 
-Подобно на лицензите с отворен код, има и нововъзникващи стандарти за кодекси за поведение, така че не е нужно да пишете свои собствени. [Споразумението на сътрудниците](https://contributor-covenant.org/) е код за поведение, който се използва от [над 40 000 проекта с отворен код](https://www.contributor-covenant.org/adopters ), включително Kubernetes, Rails и Swift. Без значение кой текст използвате, трябва да сте готови да наложите своя кодекс на поведение, когато е необходимо.
+Подобно на лицензите с отворен код, има и нововъзникващи стандарти за кодекси за поведение, така че не е нужно да пишете свои собствени. [Споразумението на сътрудниците](https://contributor-covenant.org/) е код за поведение, който се използва от [над 40 000 проекта с отворен код](https://www.contributor-covenant.org/adopters), включително Kubernetes, Rails и Swift. Без значение кой текст използвате, трябва да сте готови да наложите своя кодекс на поведение, когато е необходимо.
 
 Поставете текста директно във файл CODE_OF_CONDUCT във вашето хранилище. Съхранявайте файла в главната директория на вашия проект, за да е лесен за намиране, и свържете към него от вашия README.
 
@@ -243,11 +243,11 @@ CONTRIBUTING файл казва на вашата публика как да у
    <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
    Опитах се да участвам във всяка нишка в пощенския списък и да показвам примерно поведение, да бъда любезен с хората, да приемам проблемите им сериозно и да се опитвам да бъда полезен като цяло. След известно време хората останаха наоколо не само за да задават въпроси, но и за да помогнат с отговорите и за моя пълна радост имитираха моя стил.
    <p markdown="1" class="pquote-credit">
-— @janl в [CouchDB](https://github.com/apache/couchdb), ["Устойчив отворен код"](https://web.archive.org/web/20200723213552/https://writing.jan .io/2015/11/20/sustainable-open-source.html)
+— @janl в [CouchDB](https://github.com/apache/couchdb), ["Устойчив отворен код"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
    </p>
 </aside>
 
-Използването на топъл, приобщаващ език (като „тях“, дори когато се отнася до един човек) може много да помогне на вашия проект да се почувства добре дошъл за новите сътрудници. Придържайте се към простия език, тъй като много от вашите читатели може да не са носители на английски език.
+Използването на топъл, приобщаващ език (като "тях", дори когато се отнася до един човек) може много да помогне на вашия проект да се почувства добре дошъл за новите сътрудници. Придържайте се към простия език, тъй като много от вашите читатели може да не са носители на английски език.
 
 Освен начина, по който пишете думи, вашият стил на кодиране може също да стане част от марката на вашия проект. [Angular](https://angular.io/guide/styleguide) и [jQuery](https://contribute.jquery.org/style-guide/js/) са два примера за проекти със строги стилове и насоки за кодиране.
 
@@ -255,7 +255,7 @@ CONTRIBUTING файл казва на вашата публика как да у
 
 ## Вашият контролен списък преди стартиране
 
-Готови ли сте да отворите вашия проект? Ето контролен списък за помощ. Поставете отметка във всички квадратчета? Готови сте за работа! [Щракнете върху „публикувай“](https://help.github.com/articles/making-a-private-repository-public/) и се потупайте по рамото.
+Готови ли сте да отворите вашия проект? Ето контролен списък за помощ. Поставете отметка във всички квадратчета? Готови сте за работа! [Щракнете върху "публикувай"](https://help.github.com/articles/making-a-private-repository-public/) и се потупайте по рамото.
 
 **Документация**
 
@@ -283,7 +283,7 @@ CONTRIBUTING файл казва на вашата публика как да у
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox4" class="overflow-hidden d-block text-normal">
-    The issue queue is up-to-date, with issues clearly organized and labeled
+    Опашката с проблеми е актуална, с ясно организирани и етикетирани проблеми
   </label>
 </div>
 

From d9ca0f01fc4dfbb269fb49e3f3817533201ce1f1 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Wed, 3 Apr 2024 11:18:24 +0200
Subject: [PATCH 659/749] fixed spaces and brackets

---
 _articles/bg/best-practices.md                         |  4 ++--
 _articles/bg/building-community.md                     |  2 +-
 _articles/bg/code-of-conduct.md                        |  2 +-
 _articles/bg/finding-users.md                          |  2 +-
 _articles/bg/getting-paid.md                           |  2 +-
 _articles/bg/how-to-contribute.md                      |  6 +++---
 _articles/bg/leadership-and-governance.md              |  8 ++++----
 _articles/bg/legal.md                                  | 10 +++++-----
 .../maintaining-balance-for-open-source-maintainers.md |  6 +++---
 _articles/bg/metrics.md                                |  2 +-
 _articles/bg/starting-a-project.md                     | 10 +++++-----
 11 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md
index 36a0fbdc074..50c1674ef01 100644
--- a/_articles/bg/best-practices.md
+++ b/_articles/bg/best-practices.md
@@ -62,7 +62,7 @@ related:
 
 * Как се преглежда и приема принос (_Имат ли нужда от тестове? Шаблон за проблем?_)
 * Типовете приноси, които ще приемете (_Искате ли помощ само за определена част от вашия код?_)
-* Когато е уместно да се проследи (_например, „Можете да очаквате отговор от поддържащия в рамките на 7 дни. Ако не сте чули нищо дотогава, не се колебайте да пингвате темата.“_)
+* Когато е уместно да се проследи (_например, "Можете да очаквате отговор от поддържащия в рамките на 7 дни. Ако не сте чули нищо дотогава, не се колебайте да пингвате темата."_)
 * Колко време отделяте за проекта (_например, „Прекарваме само около 5 часа на седмица в този проект“_)
 
 [Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) са някои примери за проекти с ясни правила за поддържащите и сътрудниците.
@@ -155,7 +155,7 @@ related:
 
 Може би някой във вашата общност редовно изпраща приноси, които не отговарят на стандартите на вашия проект. Може да бъде разочароващо и за двете страни многократното преминаване през процеса на отхвърляне.
 
-Ако видите, че някой е развълнуван от вашия проект, но има нужда от малко практика, бъдете търпеливи. Обяснете ясно във всяка ситуация защо вашият принос не отговаря на очакванията на проекта. Опитайте да им дадете по-лесна или по-малко двусмислена задача, като например проблем, отбелязан като „good first issue“, за да ги загреете. Ако имате време, обмислете да ги наставлявате чрез първия им принос или намерете някой друг във вашата общност, който е готов да ги наставлява.
+Ако видите, че някой е развълнуван от вашия проект, но има нужда от малко практика, бъдете търпеливи. Обяснете ясно във всяка ситуация защо вашият принос не отговаря на очакванията на проекта. Опитайте да им дадете по-лесна или по-малко двусмислена задача, като например проблем, отбелязан като "good first issue", за да ги загреете. Ако имате време, обмислете да ги наставлявате чрез първия им принос или намерете някой друг във вашата общност, който е готов да ги наставлява.
 
 ## Използвайте общността си
 
diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index 287a612f7fb..208a5458050 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -215,7 +215,7 @@ related:
 
 Някои проекти използват процес на гласуване, за да вземат важни решения. Въпреки че е разумно на пръв поглед, гласуването набляга на достигането до "отговор", а не на изслушване и разглеждане на притесненията на другия.
 
-Гласуването може да стане политическо, когато членовете на общността се чувстват принудени да си правят услуги или да гласуват по определен начин. Не всеки гласува също, независимо дали е [мълчаливото мнозинство](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority -на-потребители) във вашата общност или настоящи потребители, които не са знаели, че се провежда гласуване.
+Гласуването може да стане политическо, когато членовете на общността се чувстват принудени да си правят услуги или да гласуват по определен начин. Не всеки гласува също, независимо дали е [мълчаливото мнозинство](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) във вашата общност или настоящи потребители, които не са знаели, че се провежда гласуване.
 
 Понякога е необходим равен вот. Доколкото можете обаче, наблягайте на ["търсенето на консенсус"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), а не на консенсуса .
 
diff --git a/_articles/bg/code-of-conduct.md b/_articles/bg/code-of-conduct.md
index 9e20d1f7e1a..22af32a478d 100644
--- a/_articles/bg/code-of-conduct.md
+++ b/_articles/bg/code-of-conduct.md
@@ -54,7 +54,7 @@ related:
 
 Трябва да дадете на хората личен начин (като имейл адрес) да докладват за нарушение на кодекса на поведение и да обясните кой получава този доклад. Това може да бъде поддържащ, група от поддържащи или работна група за кодекс на поведение.
 
-Не забравяйте, че някой може да поиска да докладва за нарушение на лице, което получава тези доклади. В този случай им дайте възможност да докладват за нарушения на някой друг. Например @ctb и @mr-c [обясняват за техния проект](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github. com/dib-lab/khmer):
+Не забравяйте, че някой може да поиска да докладва за нарушение на лице, което получава тези доклади. В този случай им дайте възможност да докладват за нарушения на някой друг. Например @ctb и @mr-c [обясняват за техния проект](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
 
 > Случаи на злоупотреба, тормоз или по друг начин неприемливо поведение могат да бъдат докладвани чрез имейл **khmer-project@idyll.org**, който отива само до C. Titus Brown и Michael R. Crusoe. За да съобщите за проблем, свързан с някой от тях, моля, изпратете имейл до **Judi Brown Clarke, Ph.D.** директора по разнообразието в BEACON Center for the Study of Evolution in Action, Център за науки и технологии на NSF.*
 
diff --git a/_articles/bg/finding-users.md b/_articles/bg/finding-users.md
index d30a49dd486..8ea56b9d206 100644
--- a/_articles/bg/finding-users.md
+++ b/_articles/bg/finding-users.md
@@ -65,7 +65,7 @@ related:
 
 Онлайн обхватът е чудесен начин за бързо споделяне и разпространение на информацията. Използвайки онлайн канали, вие имате потенциала да достигнете до много широка аудитория.
 
-Възползвайте се от съществуващите онлайн общности и платформи, за да достигнете до вашата аудитория. Ако вашият проект с отворен код е софтуерен проект, вероятно можете да намерите аудиторията си в [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News ](https://news.ycombinator.com/) или [Quora](https://www.quora.com/). Намерете каналите, от които смятате, че хората ще имат най-голяма полза или ще бъдат развълнувани от вашата работа.
+Възползвайте се от съществуващите онлайн общности и платформи, за да достигнете до вашата аудитория. Ако вашият проект с отворен код е софтуерен проект, вероятно можете да намерите аудиторията си в [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/) или [Quora](https://www.quora.com/). Намерете каналите, от които смятате, че хората ще имат най-голяма полза или ще бъдат развълнувани от вашата работа.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/bg/getting-paid.md b/_articles/bg/getting-paid.md
index 218a61a6aa1..3c418b879f4 100644
--- a/_articles/bg/getting-paid.md
+++ b/_articles/bg/getting-paid.md
@@ -175,4 +175,4 @@ related:
 
 ## Експериментирайте и не се отказвайте
 
-Събирането на пари не е лесно, независимо дали сте проект с отворен код, организация с нестопанска цел или стартиращ софтуер, и в повечето случаи изисква от вас да проявите креативност. Определянето на начина, по който искате да получавате заплащане, извършването на вашите проучвания и поставянето на мястото на вашия финансиращ ще ви помогне да изградите убедителна аргументация за финансиране.
\ No newline at end of file
+Събирането на пари не е лесно, независимо дали сте проект с отворен код, организация с нестопанска цел или стартиращ софтуер, и в повечето случаи изисква от вас да проявите креативност. Определянето на начина, по който искате да получавате заплащане, извършването на вашите проучвания и поставянето на мястото на вашия финансиращ ще ви помогне да изградите убедителна аргументация за финансиране.
diff --git a/_articles/bg/how-to-contribute.md b/_articles/bg/how-to-contribute.md
index 73795bec604..b4cfd26addc 100644
--- a/_articles/bg/how-to-contribute.md
+++ b/_articles/bg/how-to-contribute.md
@@ -132,7 +132,7 @@ related:
 
 Например:
 
-* @sindresorhus подготвя [списък с „страхотни“ списъци](https://github.com/sindresorhus/awesome)
+* @sindresorhus подготвя [списък с "страхотни" списъци](https://github.com/sindresorhus/awesome)
 * @h5bp поддържа [списък с потенциални въпроси за интервю](https://github.com/h5bp/Front-end-Developer-Interview-Questions) за кандидати за фронтенд разработчици
 * @stuartlynn и @nicole-a-tesla направиха [колекция от забавни факти за пуфините](https://github.com/stuartlynn/puffin_facts)
 
@@ -205,13 +205,13 @@ related:
 
 В рамките на тези проекти, всеки път, когато се хванете, че мислите, че нещо може да бъде по-добро или различно, действайте според инстинкта си.
 
-Отвореният код не е изключителен клуб; направено е от хора точно като вас. „Отворен код“ е просто фантастичен термин за третиране на световните проблеми като поправими.
+Отвореният код не е изключителен клуб; направено е от хора точно като вас. "Отворен код" е просто фантастичен термин за третиране на световните проблеми като поправими.
 
 Може да сканирате README и да намерите повредена връзка или правописна грешка. Или сте нов потребител и сте забелязали, че нещо е счупено, или проблем, който смятате, че наистина трябва да бъде в документацията. Вместо да го игнорирате и да продължите напред, или да помолите някой друг да го поправи, вижте дали можете да помогнете, като се включите. Това е смисълът на отворения код!
 
 > Според проучване, проведено от Игор Щайнмахер и други изследователи на компютърните науки, [28% от случайните приноси](https://www.igor.pro.br/publica/papers/saner2016.pdf) в отворен код са документация, като като корекции на печатни грешки, преформатиране или писане на превод.
 
-Ако търсите съществуващи проблеми, които можете да коригирате, всеки проект с отворен код има страница `/contribute`, която подчертава лесни за начинаещи проблеми, с които можете да започнете. Отидете до главната страница на хранилището в GitHub и добавете `/contribute` в края на URL адреса (например [`https://github.com/facebook/react/contribute`](https://github. com/facebook/react/contribute)).
+Ако търсите съществуващи проблеми, които можете да коригирате, всеки проект с отворен код има страница `/contribute`, която подчертава лесни за начинаещи проблеми, с които можете да започнете. Отидете до главната страница на хранилището в GitHub и добавете `/contribute` в края на URL адреса (например [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
 
 Можете също да използвате един от следните ресурси, за да ви помогне да откриете и допринесете за нови проекти:
 
diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
index ede0f600629..6e0bdf0d69c 100644
--- a/_articles/bg/leadership-and-governance.md
+++ b/_articles/bg/leadership-and-governance.md
@@ -67,13 +67,13 @@ related:
   </p>
 </aside>
 
-Лидерските екипи може да искат да създадат определен канал (като в IRC) или да се срещат редовно, за да обсъждат проекта (като в Gitter или Google Hangout). Можете дори да направите тези срещи публични, така че други хора да могат да слушат. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), например, [поема работно време всяка седмица](https://github.com/cucumber/cucumber-ruby/blob/HEAD/ CONTRIBUTING.md#talking-with-other-devs).
+Лидерските екипи може да искат да създадат определен канал (като в IRC) или да се срещат редовно, за да обсъждат проекта (като в Gitter или Google Hangout). Можете дори да направите тези срещи публични, така че други хора да могат да слушат. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), например, [поема работно време всяка седмица](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 След като сте установили лидерски роли, не забравяйте да документирате как хората могат да ги постигнат! Установете ясен процес за това как някой може да стане поддържащ или да се присъедини към подкомисия във вашия проект и го напишете във вашия GOVERNANCE.md.
 
 Инструменти като [Vossibility](https://github.com/icecrime/vossibility-stack) могат да ви помогнат публично да проследите кой (или не) прави принос към проекта. Документирането на тази информация избягва възприемането на общността, че поддържащите са клика, която взема решенията си частно.
 
-И накрая, ако проектът ви е в GitHub, помислете за преместване на проекта от личния ви акаунт в организация и добавяне на поне един резервен администратор. [Организациите на GitHub](https://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](.. /building-community/#share-ownership-of-your-project).
+И накрая, ако проектът ви е в GitHub, помислете за преместване на проекта от личния ви акаунт в организация и добавяне на поне един резервен администратор. [Организациите на GitHub](https://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community/#share-ownership-of-your-project).
 
 ## Кога трябва да дам на някого достъп за ангажиране?
 
@@ -131,7 +131,7 @@ related:
 
 Важно е търговската дейност да се третира като нормална и просто като още един източник на енергия за развитие. Разбира се, платените разработчици не трябва да получават специално отношение спрямо неплатените; всеки принос трябва да бъде оценен според техническите си качества. Въпреки това, хората трябва да се чувстват комфортно да участват в търговска дейност и да се чувстват комфортно да посочват своите случаи на употреба, когато спорят в полза на определено подобрение или функция.
 
-"Комерсиален" е напълно съвместим с "отворен код". "Търговски" просто означава, че някъде има замесени пари – че софтуерът се използва в търговията, което е все по-вероятно, тъй като даден проект получава приемане. (Когато софтуер с отворен код се използва като част от продукт с неотворен код, цялостният продукт все още е „патентован“ софтуер, въпреки че, подобно на отворен код, може да се използва за търговски или нетърговски цели.)
+"Комерсиален" е напълно съвместим с "отворен код". "Търговски" просто означава, че някъде има замесени пари – че софтуерът се използва в търговията, което е все по-вероятно, тъй като даден проект получава приемане. (Когато софтуер с отворен код се използва като част от продукт с неотворен код, цялостният продукт все още е "патентован" софтуер, въпреки че, подобно на отворен код, може да се използва за търговски или нетърговски цели.)
 
 Като всеки друг, комерсиално мотивираните разработчици печелят влияние в проекта чрез качеството и количеството на техния принос. Очевидно програмист, който получава заплащане за времето си, може да е в състояние да направи повече от някой, който не получава заплащане, но това е добре: плащането е само един от многото възможни фактори, които могат да повлияят на това колко прави някой. Поддържайте дискусиите по проекта си фокусирани върху приноса, а не върху външните фактори, които позволяват на хората да направят този принос.
 
@@ -143,7 +143,7 @@ related:
 
 Ако искате да приемате дарения за вашия проект с отворен код, можете да настроите бутон за дарение (с помощта на PayPal или Stripe, например), но парите няма да се приспадат от данъци, освен ако не сте квалифицирана организация с нестопанска цел (501c3, ако вие сте в САЩ).
 
-Много проекти не желаят да преминат през неприятностите при създаването на организация с нестопанска цел, така че вместо това намират фискален спонсор с нестопанска цел. Фискален спонсор приема дарения от ваше име, обикновено в замяна на процент от дарението. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/ ), [Linux Foundation](https://www.linuxfoundation.org/projects) и [Open Collective](https://opencollective.com/opensource) са примери за организации, които служат като фискални спонсори за проекти с отворен код.
+Много проекти не желаят да преминат през неприятностите при създаването на организация с нестопанска цел, така че вместо това намират фискален спонсор с нестопанска цел. Фискален спонсор приема дарения от ваше име, обикновено в замяна на процент от дарението. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) и [Open Collective](https://opencollective.com/opensource) са примери за организации, които служат като фискални спонсори за проекти с отворен код.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
index 6c5496680df..ad6c122064d 100644
--- a/_articles/bg/legal.md
+++ b/_articles/bg/legal.md
@@ -32,7 +32,7 @@ related:
 
 ![Създаване на хранилище](/assets/images/legal/repo-create-name.png)
 
-**Да направите своя проект в GitHub публичен не е същото като да лицензирате проекта си.** Публичните проекти са обхванати от [Условията за ползване на GitHub](https://help.github.com/en/github/site-policy/github- Terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), което позволява на другите да преглеждат и разклоняват вашия проект, но иначе работата ви идва без разрешения.
+**Да направите своя проект в GitHub публичен не е същото като да лицензирате проекта си.** Публичните проекти са обхванати от [Условията за ползване на GitHub](https://help.github.com/en/github/site-policy/github-Terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), което позволява на другите да преглеждат и разклоняват вашия проект, но иначе работата ви идва без разрешения.
 
 Ако искате други да използват, разпространяват, модифицират или допринасят обратно към вашия проект, трябва да включите лиценз с отворен код. Например, някой не може законно да използва която и да е част от вашия GitHub проект в своя код, дори ако е публичен, освен ако изрично не му дадете правото да го направи.
 
@@ -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/) са [популярни лицензи за отворен код](https://innovationgraph.github.com/global-metrics/licenses), но има и други опции за избор. Можете да намерите пълния текст на тези лицензи и инструкции как да ги използвате на [choosealicense.com](https://choosealicense.com/).
+[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/).
 
@@ -62,7 +62,7 @@ related:
 
 Зависимости с **разрешителни лицензи** като [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc) и [BSD](https://choosealicense.com/licenses/bsd-3-clause) ви позволяват да лицензирате проекта си както искате.
 
-Зависимостите с **лицензи за авторско право** изискват по-голямо внимание. Включително всяка библиотека със "силен" лиценз за копиралефт като [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), или [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) изисква да изберете идентичен или [съвместим лиценз](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) за вашия проект. Библиотеки с „ограничен“ или „слаб“ лиценз за копиралефт като [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) и [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) могат да бъдат включени в проекти с произволен лиценз, при условие че следвате [допълнителните правила](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) посочват те.
+Зависимостите с **лицензи за авторско право** изискват по-голямо внимание. Включително всяка библиотека със "силен" лиценз за копиралефт като [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), или [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) изисква да изберете идентичен или [съвместим лиценз](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) за вашия проект. Библиотеки с „ограничен“ или "слаб" лиценз за копиралефт като [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) и [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) могат да бъдат включени в проекти с произволен лиценз, при условие че следвате [допълнителните правила](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) посочват те.
  
 Можете също така да разгледате **общностите**, които се надявате да използвате и да допринесете за вашия проект:
 
@@ -126,7 +126,7 @@ related:
 
 * **Търговски тайни:** Помислете дали има нещо в проекта, което компанията не иска да направи достъпно за широката общественост. Ако е така, можете да отворите останалата част от проекта си, след като извлечете материала, който искате да запазите поверителен.
 
-* **Патенти:** Вашата компания кандидатства ли за патент, за който отвореният код на вашия проект би представлявал [публично разкриване](https://en.wikipedia.org/wiki/Public_disclosure)? За съжаление може да бъдете помолени да изчакате (или може би компанията ще преразгледа разумността на приложението). Ако очаквате принос към вашия проект от служители на компании с големи патентни портфейли, вашият правен екип може да поиска да използвате лиценз с изрично предоставяне на патент от сътрудници (като Apache 2.0 или GPLv3) или допълнително споразумение за сътрудници ( [вижте по-горе](#which-open-source-license-is-appropriate-for-my-project)).
+* **Патенти:** Вашата компания кандидатства ли за патент, за който отвореният код на вашия проект би представлявал [публично разкриване](https://en.wikipedia.org/wiki/Public_disclosure)? За съжаление може да бъдете помолени да изчакате (или може би компанията ще преразгледа разумността на приложението). Ако очаквате принос към вашия проект от служители на компании с големи патентни портфейли, вашият правен екип може да поиска да използвате лиценз с изрично предоставяне на патент от сътрудници (като Apache 2.0 или GPLv3) или допълнително споразумение за сътрудници ([вижте по-горе](#which-open-source-license-is-appropriate-for-my-project)).
 
 * **Търговски марки:** Проверете отново дали името на вашия проект [не е в конфликт със съществуващи търговски марки](../starting-a-project/#avoiding-name-conflicts). Ако използвате търговските марки на собствената си компания в проекта, проверете дали това не предизвиква конфликти. [FOSSmarks](http://fossmarks.org/) е практическо ръководство за разбиране на търговските марки в контекста на безплатни проекти с отворен код.
 
@@ -136,7 +136,7 @@ related:
 
 В по-дългосрочен план вашият правен екип може да направи повече, за да помогне на компанията да извлече повече от участието си в отворен код и да остане в безопасност:
 
-* **Правила за приноса на служителите:** Помислете за разработване на корпоративна политика, която определя как вашите служители допринасят за проекти с отворен код. Ясната политика ще намали объркването сред вашите служители и ще им помогне да допринесат за проекти с отворен код в най-добрия интерес на компанията, независимо дали като част от работата им или в свободното им време. Добър пример е [Модел IP и политика за принос с отворен код] на Rackspace (https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+* **Правила за приноса на служителите:** Помислете за разработване на корпоративна политика, която определя как вашите служители допринасят за проекти с отворен код. Ясната политика ще намали объркването сред вашите служители и ще им помогне да допринесат за проекти с отворен код в най-добрия интерес на компанията, независимо дали като част от работата им или в свободното им време. Добър пример е [Модел IP и политика за принос с отворен код](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) на Rackspace.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/bg/maintaining-balance-for-open-source-maintainers.md b/_articles/bg/maintaining-balance-for-open-source-maintainers.md
index 84444f0a2b4..26d0601d32c 100644
--- a/_articles/bg/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/bg/maintaining-balance-for-open-source-maintainers.md
@@ -140,7 +140,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
 За да се доверите смислено на другите по тези оси, не можете да сте някой, който казва "да" на всяка молба. Правейки това, вие не поддържате никакви граници, професионално или лично, и няма да бъдете надежден колега.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, поддържащ Homebrew на [Saying No](https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, поддържащ Homebrew на [Казвайки не](https://mikemcquaid.com/saying-no/)
   </p>
 </aside>
 
@@ -148,7 +148,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-Моят софтуер е безплатен, но моето време и внимание не са.
+    Моят софтуер е безплатен, но моето време и внимание не са.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, поддържащ Leaflet
   </p>
@@ -156,7 +156,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-Не е тайна, че поддръжката с отворен код има своите тъмни страни и една от тях е понякога да се налага да взаимодействате с доста неблагодарни, имащи право или направо токсични хора. С нарастването на популярността на даден проект нараства и честотата на този вид взаимодействие, което увеличава тежестта, поета от поддържащите, и вероятно се превръща в значителен рисков фактор за прегаряне на поддържащия.  
+    Не е тайна, че поддръжката с отворен код има своите тъмни страни и една от тях е понякога да се налага да взаимодействате с доста неблагодарни, имащи право или направо токсични хора. С нарастването на популярността на даден проект нараства и честотата на този вид взаимодействие, което увеличава тежестта, поета от поддържащите, и вероятно се превръща в значителен рисков фактор за прегаряне на поддържащия.  
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/foosel">@foosel</a>, поддържащ Octoprint на [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
diff --git a/_articles/bg/metrics.md b/_articles/bg/metrics.md
index 5d0b4d2d850..c64806b6b48 100644
--- a/_articles/bg/metrics.md
+++ b/_articles/bg/metrics.md
@@ -84,7 +84,7 @@ related:
 
 Примери за показатели на общността, които може да искате да проследявате редовно, включват:
 
-* **Общ брой сътрудници и брой ангажименти на сътрудник:** Ви казва колко сътрудници имате и кой е повече или по-малко активен. В GitHub можете да видите това под „Прозрения“ -> "Сътрудници". В момента тази графика отчита само сътрудници, които са се ангажирали с клона по подразбиране на хранилището.
+* **Общ брой сътрудници и брой ангажименти на сътрудник:** Ви казва колко сътрудници имате и кой е повече или по-малко активен. В GitHub можете да видите това под "Прозрения" -> "Сътрудници". В момента тази графика отчита само сътрудници, които са се ангажирали с клона по подразбиране на хранилището.
 
 ![Графика на сътрудник](/assets/images/metrics/repo_contributors_specific_graph.png)
 
diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index cfedd5ad8cd..84b26a241f8 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -20,7 +20,7 @@ related:
 
 Отвореният код е мощен, защото намалява бариерите пред приемането и сътрудничеството, позволявайки на хората да разпространяват и подобряват проекти бързо. Също така защото дава на потребителите потенциал да контролират собствените си компютри, в сравнение със затворения код. Например, бизнес, използващ софтуер с отворен код, има опцията да наеме някой, който да направи персонализирани подобрения на софтуера, вместо да разчита изключително на продуктовите решения на доставчик със затворен код.
 
-_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената] (#does-open-source-mean-of-charge).
+_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#does-open-source-mean-of-charge).
 
 ### Защо хората отварят кода на работата си?
 
@@ -38,7 +38,7 @@ _Свободен софтуер_ се отнася до същия набор 
 
 * **Приемане и ремиксиране:** Проектите с отворен код могат да се използват от всеки за почти всякакви цели. Хората дори могат да го използват за изграждане на други неща. [WordPress](https://github.com/WordPress), например, стартира като разклонение на съществуващ проект, наречен [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Прозрачност:** Всеки може да провери проект с отворен код за грешки или несъответствия. Прозрачността има значение за правителства като [България](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) или [Съединените щати](https://sourcecode.cio.gov/), регулирани отрасли като банкиране или здравеопазване и софтуер за сигурност като [Let's Encrypt](https://github.com/letsencrypt).
+* **Прозрачност:** Всеки може да провери проект с отворен код за грешки или несъответствия. Прозрачността има значение за правителства като [България](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) или [Съединените щати](https://sourcecode.cio.gov/), регулирани отрасли като банкиране или здравеопазване и софтуер за сигурност като [Да шифроваме](https://github.com/letsencrypt).
 
 Отвореният код също не е само за софтуер. Можете да отворите всичко - от набори от данни до книги. Разгледайте [GitHub Explore](https://github.com/explore) за идеи какво още можете да отворите.
 
@@ -121,7 +121,7 @@ _Свободен софтуер_ се отнася до същия набор 
 
 Легалната работа не е забавна. Добрата новина е, че можете да копирате и поставите съществуващ лиценз във вашето хранилище. Ще отнеме само минута, за да защитите упоритата си работа.
 
-[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) и [GPLv3](https://choosealicense. com/licenses/gpl-3.0/) са най-популярните лицензи с отворен код, но [има и други опции](https://choosealicense.com), от които да избирате.
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) и [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) са най-популярните лицензи с отворен код, но [има и други опции](https://choosealicense.com), от които да избирате.
 
 Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на лиценз с отворен код ще направи вашия проект GitHub отворен код.
 
@@ -152,7 +152,7 @@ README правят повече от това да обяснят как да 
 
 Понякога хората избягват да пишат README, защото смятат, че проектът е незавършен или не искат приноси. Всичко това са много добри причини да напиша такъв.
 
-За повече вдъхновение опитайте да използвате [ръководството „Направете README“ на @dguo](https://www.makeareadme.com/) или [шаблона README] на @PurpleBooth(https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) за да напишете пълен README.
+За повече вдъхновение опитайте да използвате [ръководството "Направете README" на @dguo](https://www.makeareadme.com/) или [шаблона README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) на @PurpleBooth за да напишете пълен README.
 
 Когато включите файл README в основната директория, GitHub автоматично ще го покаже на началната страница на хранилището.
 
@@ -180,7 +180,7 @@ CONTRIBUTING файл казва на вашата публика как да у
 
 С течение на времето може да добавите други често задавани въпроси към вашия 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/).
+За повече помощ при писането на вашия 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 автоматично ще се свърже с вашия файл, когато участник създаде проблем или отваря заявка за изтегляне.
 

From a9ace88a7e25e21d596349e1f6997d030cb7cf34 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Wed, 3 Apr 2024 11:34:29 +0200
Subject: [PATCH 660/749] fixed issues space and brackets

---
 _articles/bg/best-practices.md                       |  2 +-
 _articles/bg/getting-paid.md                         |  6 +++---
 _articles/bg/how-to-contribute.md                    |  2 +-
 _articles/bg/leadership-and-governance.md            |  2 +-
 _articles/bg/legal.md                                |  4 ++--
 ...aintaining-balance-for-open-source-maintainers.md |  4 ++--
 _articles/bg/metrics.md                              | 12 ++++++------
 _articles/bg/starting-a-project.md                   |  2 +-
 8 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md
index 50c1674ef01..70239d8f360 100644
--- a/_articles/bg/best-practices.md
+++ b/_articles/bg/best-practices.md
@@ -63,7 +63,7 @@ related:
 * Как се преглежда и приема принос (_Имат ли нужда от тестове? Шаблон за проблем?_)
 * Типовете приноси, които ще приемете (_Искате ли помощ само за определена част от вашия код?_)
 * Когато е уместно да се проследи (_например, "Можете да очаквате отговор от поддържащия в рамките на 7 дни. Ако не сте чули нищо дотогава, не се колебайте да пингвате темата."_)
-* Колко време отделяте за проекта (_например, „Прекарваме само около 5 часа на седмица в този проект“_)
+* Колко време отделяте за проекта (_например, "Прекарваме само около 5 часа на седмица в този проект"_)
 
 [Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) са някои примери за проекти с ясни правила за поддържащите и сътрудниците.
 
diff --git a/_articles/bg/getting-paid.md b/_articles/bg/getting-paid.md
index 3c418b879f4..d7f074985b8 100644
--- a/_articles/bg/getting-paid.md
+++ b/_articles/bg/getting-paid.md
@@ -116,7 +116,7 @@ related:
 Няколко примера за спонсорирани проекти включват:
 
 * **[webpack](https://github.com/webpack)** събира пари от компании и физически лица [чрез OpenCollective](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** организация с нестопанска цел, която плаща за работата по [bundler](https://github.com/bundler/bundler), [RubyGems](https ://github.com/rubygems/rubygems) и други Ruby инфраструктурни проекти
+* **[Ruby Together](https://rubytogether.org/),** организация с нестопанска цел, която плаща за работата по [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems) и други Ruby инфраструктурни проекти
 
 ### Създайте поток от приходи
 
@@ -132,8 +132,8 @@ related:
 
 Някои софтуерни фондации и компании предлагат грантове за работа с отворен код. Понякога грантовете могат да се изплащат на физически лица, без да се създава юридическо лице за проекта.
 
-* **[Прочетете документите](https://github.com/rtfd/readthedocs.org)** получи субсидия от [Поддръжка на Mozilla Open Source](https://www.mozilla.org/en-US/ субсидии/)
-* Работата по **[OpenMRS](https://github.com/openmrs)** е финансирана от [Retreat за отворен код на Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees )
+* **[Прочетете документите](https://github.com/rtfd/readthedocs.org)** получи субсидия от [Поддръжка на Mozilla Open Source](https://www.mozilla.org/en-US/grants/)
+* Работата по **[OpenMRS](https://github.com/openmrs)** е финансирана от [Retreat за отворен код на Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees)
 * **[Libraries.io](https://github.com/librariesio)** получи грант от [Фондация Слоун](https://sloan.org/programs/digital-technology)
 * **[Python Software Foundation](https://www.python.org/psf/grants/)** предлага грантове за работа, свързана с Python
 
diff --git a/_articles/bg/how-to-contribute.md b/_articles/bg/how-to-contribute.md
index b4cfd26addc..1952f1ceb27 100644
--- a/_articles/bg/how-to-contribute.md
+++ b/_articles/bg/how-to-contribute.md
@@ -478,7 +478,7 @@ related:
 * Изпратете малки корекции като печатна грешка, повредена връзка или очевидна грешка.
 * Започнете работа по принос, който вече е поискан или който вече сте обсъждали в даден брой.
 
-Заявката за изтегляне не трябва да представлява завършена работа. Обикновено е по-добре да отворите заявка за изтегляне рано, така че другите да могат да гледат или да дадат обратна връзка за напредъка ви. Просто го отворете като "чернова" или маркирайте като "WIP" (Работа в процес) в реда за тема или в секциите „Бележки към рецензентите“, ако са предоставени (или можете просто да създадете свой собствен. Подобно на това: `**## Бележки към рецензента**`). Винаги можете да добавите още ангажименти по-късно.
+Заявката за изтегляне не трябва да представлява завършена работа. Обикновено е по-добре да отворите заявка за изтегляне рано, така че другите да могат да гледат или да дадат обратна връзка за напредъка ви. Просто го отворете като "чернова" или маркирайте като "WIP" (Работа в процес) в реда за тема или в секциите "Бележки към рецензентите", ако са предоставени (или можете просто да създадете свой собствен. Подобно на това: `**## Бележки към рецензента**`). Винаги можете да добавите още ангажименти по-късно.
 
 Ако проектът е в GitHub, ето как да изпратите заявка за изтегляне:
 
diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
index 6e0bdf0d69c..9b67738eaa8 100644
--- a/_articles/bg/leadership-and-governance.md
+++ b/_articles/bg/leadership-and-governance.md
@@ -97,7 +97,7 @@ related:
 
 * **BDFL:** BDFL означава "Доброжелателен диктатор за цял живот". При тази структура един човек (обикновено първоначалният автор на проекта) има последната дума за всички основни решения по проекта. [Python](https://github.com/python) е класически пример. По-малките проекти вероятно са BDFL по подразбиране, защото има само един или двама поддържащи. Проект, който произхожда от компания, може също да попадне в категорията BDFL.
 
-* **Меритокрация:** **(Забележка: терминът "меритокрация" носи отрицателни конотации за някои общности и има [сложна социална и политическа история](http://geekfeminism.wikia.com/wiki/Meritocracy).) ** При меритокрацията на активните участници в проекти (тези, които демонстрират "заслуги") се дава официална роля за вземане на решения. Решенията обикновено се вземат въз основа на чист консенсус при гласуване. Концепцията за меритокрация е въведена от [Фондация Apache](https://www.apache.org/); [всички проекти на Apache](https://www.apache.org/index.html#projects-list) са меритокрации. Вноски могат да се правят само от лица, представляващи себе си, а не от компания.
+* **Меритокрация:** (Забележка: терминът "меритокрация" носи отрицателни конотации за някои общности и има [сложна социална и политическа история](http://geekfeminism.wikia.com/wiki/Meritocracy).) ** При меритокрацията на активните участници в проекти (тези, които демонстрират "заслуги") се дава официална роля за вземане на решения. Решенията обикновено се вземат въз основа на чист консенсус при гласуване. Концепцията за меритокрация е въведена от [Фондация Apache](https://www.apache.org/); [всички проекти на Apache](https://www.apache.org/index.html#projects-list) са меритокрации. Вноски могат да се правят само от лица, представляващи себе си, а не от компания.
 
 * **Либерален принос:** При либерален модел на принос хората, които вършат най-много работа, се признават за най-влиятелни, но това се основава на текуща работа, а не на исторически принос. Решенията за големи проекти се вземат въз основа на процес на търсене на консенсус (обсъждане на основните оплаквания), а не на чисто гласуване, и се стремят да включват възможно най-много гледни точки на общността. Популярни примери за проекти, които използват либерален модел на принос, включват [Node.js](https://foundation.nodejs.org/) и [Rust](https://www.rust-lang.org/).
 
diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
index ad6c122064d..524693514a0 100644
--- a/_articles/bg/legal.md
+++ b/_articles/bg/legal.md
@@ -62,7 +62,7 @@ related:
 
 Зависимости с **разрешителни лицензи** като [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc) и [BSD](https://choosealicense.com/licenses/bsd-3-clause) ви позволяват да лицензирате проекта си както искате.
 
-Зависимостите с **лицензи за авторско право** изискват по-голямо внимание. Включително всяка библиотека със "силен" лиценз за копиралефт като [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), или [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) изисква да изберете идентичен или [съвместим лиценз](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) за вашия проект. Библиотеки с „ограничен“ или "слаб" лиценз за копиралефт като [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) и [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) могат да бъдат включени в проекти с произволен лиценз, при условие че следвате [допълнителните правила](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) посочват те.
+Зависимостите с **лицензи за авторско право** изискват по-голямо внимание. Включително всяка библиотека със "силен" лиценз за копиралефт като [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), или [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) изисква да изберете идентичен или [съвместим лиценз](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) за вашия проект. Библиотеки с "ограничен" или "слаб" лиценз за копиралефт като [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) и [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) могат да бъдат включени в проекти с произволен лиценз, при условие че следвате [допълнителните правила](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) посочват те.
  
 Можете също така да разгледате **общностите**, които се надявате да използвате и да допринесете за вашия проект:
 
@@ -107,7 +107,7 @@ related:
 Някои ситуации, в които може да искате да обмислите споразумение за допълнителен сътрудник за вашия проект, включват:
 
 * Вашите адвокати искат всички сътрудници изрично да приемат (_подписват_, онлайн или офлайн) условията за принос, може би защото смятат, че самият лиценз за отворен код не е достатъчен (въпреки че е!). Ако това е единствената грижа, споразумение за сътрудник, което потвърждава лиценза за отворен код на проекта, трябва да е достатъчно. [Лицензионното споразумение за jQuery Individual Contributor](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) е добър пример за леко споразумение за допълнителен сътрудник.
-* Вие или вашите адвокати искате разработчиците да декларират, че всеки ангажимент, който правят, е разрешен. Изискването за [Сертификат за произход на разработчици](https://developercertificate.org/) е колко проекта постигат това. Например общността Node.js [използва](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо](https://nodejs.org/en/blog/ uncategorized/notes-from-the-road/#easier-contribution) от техния предишен CLA. Една проста опция за автоматизиране на прилагането на DCO във вашето хранилище е [DCO Probot](https://github.com/probot/dco).
+* Вие или вашите адвокати искате разработчиците да декларират, че всеки ангажимент, който правят, е разрешен. Изискването за [Сертификат за произход на разработчици](https://developercertificate.org/) е колко проекта постигат това. Например общността Node.js [използва](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) от техния предишен CLA. Една проста опция за автоматизиране на прилагането на DCO във вашето хранилище е [DCO Probot](https://github.com/probot/dco).
 * Вашият проект използва лиценз с отворен код, който не включва изрично предоставяне на патент (като MIT) и се нуждаете от разрешение за патент от всички сътрудници, някои от които може да работят за компании с големи патентни портфейли, които биха могли да бъдат използвани за насочване към вас или други сътрудници и потребители на проекта. [Лицензионното споразумение за личен сътрудник на Apache](https://www.apache.org/licenses/icla.pdf) е често използвано допълнително споразумение за сътрудник, което има предоставяне на патент, отразяващо това, което се намира в Лиценза на Apache 2.0.
 * Вашият проект е под лиценз за копиралефт, но също така трябва да разпространявате собствена версия на проекта. Ще трябва всеки сътрудник да ви прехвърли авторски права или да ви предостави (но не на обществеността) разрешителен лиценз. [Споразумението за сътрудник на MongoDB](https://www.mongodb.com/legal/contributor-agreement) е пример за този тип споразумение.
 * Смятате, че вашият проект може да се наложи да промени лицензите през целия си живот и искате участниците да се съгласят предварително с такива промени.
diff --git a/_articles/bg/maintaining-balance-for-open-source-maintainers.md b/_articles/bg/maintaining-balance-for-open-source-maintainers.md
index 26d0601d32c..d6cf1585838 100644
--- a/_articles/bg/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/bg/maintaining-balance-for-open-source-maintainers.md
@@ -44,7 +44,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
   </p>
 </aside>
 
-* **Да не казваш „не“:** Може да е лесно да поемеш повече отговорности, отколкото би трябвало за проект с отворен код. Независимо дали е от потребители, сътрудници или други поддържащи – ние не винаги можем да оправдаем техните очаквания.
+* **Да не казваш "не":** Може да е лесно да поемеш повече отговорности, отколкото би трябвало за проект с отворен код. Независимо дали е от потребители, сътрудници или други поддържащи – ние не винаги можем да оправдаем техните очаквания.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
@@ -73,7 +73,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
   </p>
 </aside>
 
-* **Противоречиви изисквания: ** Отвореният код е пълен с групи с различни мотивации, които могат да бъдат трудни за ориентиране. Ако ви се плаща да работите с отворен код, интересите на вашия работодател понякога могат да бъдат в противоречие с общността.
+* **Противоречиви изисквания:** Отвореният код е пълен с групи с различни мотивации, които могат да бъдат трудни за ориентиране. Ако ви се плаща да работите с отворен код, интересите на вашия работодател понякога могат да бъдат в противоречие с общността.
 
 <aside markdown="1" class="pquote">
   С платен отворен код, конфликт между фокуса на работодателя и най-доброто за общността
diff --git a/_articles/bg/metrics.md b/_articles/bg/metrics.md
index c64806b6b48..47b617ee8dc 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://help.github.com/articles/about-repository-graphs/#traffic) колко хора попадат на вашия проект и откъде идват. От страницата на вашия проект щракнете върху "Прозрения", след това върху "Трафик". На тази страница можете да видите:
 
 * **Общ брой показвания на страници:** Ви казва колко пъти е бил прегледан вашият проект
 
@@ -90,11 +90,11 @@ related:
 
 * **Първи, случайни и повторни сътрудници:** Помага ви да проследите дали получавате нови сътрудници и дали те се връщат. (Случайните сътрудници са сътрудници с малък брой ангажименти. Дали това е един комит, по-малко от пет ангажимента или нещо друго зависи от вас.) Без нови сътрудници общността на вашия проект може да изпадне в застой.
 
-* **Брой отворени проблеми и отворени заявки за изтегляне: ** Ако тези числа станат твърде високи, може да се нуждаете от помощ при сортирането на проблеми и прегледите на кода.
+* **Брой отворени проблеми и отворени заявки за изтегляне:** Ако тези числа станат твърде високи, може да се нуждаете от помощ при сортирането на проблеми и прегледите на кода.
 
-* **Брой _отворени_ проблеми и _отворени_ заявки за изтегляне: ** Отворените проблеми означават, че някой се интересува достатъчно от вашия проект, за да отвори проблем. Ако този брой се увеличи с течение на времето, това предполага, че хората се интересуват от вашия проект.
+* **Брой _отворени_ проблеми и _отворени_ заявки за изтегляне:** Отворените проблеми означават, че някой се интересува достатъчно от вашия проект, за да отвори проблем. Ако този брой се увеличи с течение на времето, това предполага, че хората се интересуват от вашия проект.
 
-* **Видове приноси: ** Например ангажименти, коригиране на правописни грешки или грешки или коментиране на проблем.
+* **Видове приноси:** Например ангажименти, коригиране на правописни грешки или грешки или коментиране на проблем.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
@@ -116,8 +116,8 @@ related:
 
 Можете също да измерите времето, необходимо за преминаване между етапите в процеса на принос, като например:
 
-*Средно време, през което проблемът остава отворен
-* Дали проблемите се затварят от PR
+* Средно време, през което проблемът остава отворен
+* Дали проблемите се затварят от PRте
 * Дали остарелите проблеми се затварят
 * Средно време за обединяване на заявка за изтегляне
 
diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index 84b26a241f8..d4e624008b2 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -42,7 +42,7 @@ _Свободен софтуер_ се отнася до същия набор 
 
 Отвореният код също не е само за софтуер. Можете да отворите всичко - от набори от данни до книги. Разгледайте [GitHub Explore](https://github.com/explore) за идеи какво още можете да отворите.
 
-### Отворен код означава ли „безплатно“?
+### Отворен код означава ли "безплатно"?
 
 Едно от най-големите предимства на отворения код е, че не струва пари. "Безплатно" обаче е страничен продукт от общата стойност на отворения код.
 

From bbae6a456beb3caf1fbaf798136e9d773d56d7cd Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Wed, 3 Apr 2024 11:51:19 +0200
Subject: [PATCH 661/749] fixed issues translate

---
 _articles/bg/leadership-and-governance.md | 2 +-
 _articles/bg/starting-a-project.md        | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
index 9b67738eaa8..96602d64243 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/#share-ownership-of-your-project).
+И накрая, ако проектът ви е в GitHub, помислете за преместване на проекта от личния ви акаунт в организация и добавяне на поне един резервен администратор. [Организациите на GitHub](https://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community/#дял-собственост-на-вашия-проект).
 
 ## Кога трябва да дам на някого достъп за ангажиране?
 
diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index d4e624008b2..0c133f35ebc 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -20,7 +20,7 @@ related:
 
 Отвореният код е мощен, защото намалява бариерите пред приемането и сътрудничеството, позволявайки на хората да разпространяват и подобряват проекти бързо. Също така защото дава на потребителите потенциал да контролират собствените си компютри, в сравнение със затворения код. Например, бизнес, използващ софтуер с отворен код, има опцията да наеме някой, който да направи персонализирани подобрения на софтуера, вместо да разчита изключително на продуктовите решения на доставчик със затворен код.
 
-_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#does-open-source-mean-of-charge).
+_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#прави-отворен-код-означава-безплатен).
 
 ### Защо хората отварят кода на работата си?
 

From 761a9afe6d0321420187f050b89ae1001a535167 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Wed, 3 Apr 2024 13:12:21 +0200
Subject: [PATCH 662/749] fixed issues

---
 _articles/bg/best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md
index 70239d8f360..8878c22a338 100644
--- a/_articles/bg/best-practices.md
+++ b/_articles/bg/best-practices.md
@@ -105,7 +105,7 @@ related:
 
 Не оставяйте отворен нежелан принос, защото се чувствате виновни или искате да сте мили. С течение на времето вашите въпроси без отговор и PR ще направят работата по проекта ви да се чувства много по-стресираща и смущаваща.
 
-Най-добре е незабавно да затворите приноси, които знаете, че не искате да приемете. Ако вашият проект вече страда от голямо изоставане или списък с функции за внедряване, @steveklabnik има предложения за [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Най-добре е незабавно да затворите приноси, които знаете, че не искате да приемете. Ако вашият проект вече страда от голямо изоставане или списък с функции за внедряване, @steveklabnik има предложения за [как да сортирате проблемите ефективно](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
 
 Второ, игнорирането на приносите изпраща отрицателен сигнал към вашата общност. Приносът към проект може да бъде смущаващ, особено ако на някого е за първи път. Дори и да не приемете техния принос, поздравете човека зад него и му благодарете за проявения интерес. Това е страхотен комплимент!
 

From 3f09e95a22f06cf897152213adcd11c211cc799f Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Wed, 3 Apr 2024 14:55:12 +0200
Subject: [PATCH 663/749] ...

---
 _articles/bg/building-community.md        | 2 +-
 _articles/bg/leadership-and-governance.md | 2 +-
 _articles/bg/legal.md                     | 2 +-
 _articles/bg/starting-a-project.md        | 2 +-
 _data/locales/bg.yml                      | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index 208a5458050..c574fff209b 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -165,7 +165,7 @@ related:
 
 * Ако имате значителна общност, **изпратете бюлетин или напишете публикация в блог**, като благодарите на сътрудниците. [Тази седмица в Rust](https://this-week-in-rust.org/) на Rust и [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) на Hoodie са два добри примера.
 
-* **Дайте достъп за ангажиране на всеки сътрудник.** @felixge установи, че това кара хората [да бъдат по-развълнувани да усъвършенстват корекциите си](https://felixge.de/2013/03/11/the-pull-request-hack.html ) и дори намери нови поддържащи за проекти, по които не е работил от известно време.
+* **Дайте достъп за ангажиране на всеки сътрудник.** @felixge установи, че това кара хората [да бъдат по-развълнувани да усъвършенстват корекциите си](https://felixge.de/2013/03/11/the-pull-request-hack.html) и дори намери нови поддържащи за проекти, по които не е работил от известно време.
 
 * Ако проектът ви е в GitHub, **преместете проекта си от личния си акаунт в [Организация](https://help.github.com/articles/creating-a-new-organization-account/)** и добавете поне един резервен администратор. Организациите улесняват работата по проекти с външни сътрудници.
 
diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
index 96602d64243..9b67738eaa8 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://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community/#share-ownership-of-your-project).
 
 ## Кога трябва да дам на някого достъп за ангажиране?
 
diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
index 524693514a0..01850e96dd0 100644
--- a/_articles/bg/legal.md
+++ b/_articles/bg/legal.md
@@ -86,7 +86,7 @@ related:
 
 **Съществуващи носители на авторски права на вашия проект.** Ако вие сте единственият сътрудник на вашия проект, тогава вие или вашата компания сте единственият носител на авторските права на проекта. Можете да добавите или промените какъвто лиценз вие или вашата компания искате. В противен случай може да има други притежатели на авторски права, от които се нуждаете от съгласие, за да промените лицензите. Кои са те? [Хората, които имат ангажименти във вашия проект](https://github.com/thehale/git-authorship) е добро място да започнете. Но в някои случаи авторските права ще се държат от работодателите на тези хора. В някои случаи хората ще са направили само минимален принос, но няма твърдо и бързо правило, че приносите под определен брой редове код не са обект на авторско право. Какво да правя? Зависи. За сравнително малък и млад проект може да е възможно да накарате всички съществуващи сътрудници да се съгласят с промяна на лиценза в проблем или заявка за изтегляне. За големи и дълготрайни проекти може да се наложи да потърсите много сътрудници и дори техните наследници. Mozilla отне години (2001-2006), за да прелицензира Firefox, Thunderbird и свързания софтуер.
 
-Като алтернатива можете да накарате сътрудниците предварително да одобрят определени промени в лиценза чрез споразумение за допълнителен сътрудник ([вижте по-долу](#does-my-project-need-an-additional-contributor-agreement)). Това измества малко сложността на промяната на лицензите. Ще имате нужда от повече помощ от вашите адвокати предварително и все пак ще искате да комуникирате ясно със заинтересованите страни във вашия проект, когато извършвате промяна на лиценза.
+Като алтернатива можете да накарате сътрудниците предварително да одобрят определени промени в лиценза чрез споразумение за допълнителен сътрудник ([вижте по-долу](#which-open-source-license-is-appropriate-for-my-project)). Това измества малко сложността на промяната на лицензите. Ще имате нужда от повече помощ от вашите адвокати предварително и все пак ще искате да комуникирате ясно със заинтересованите страни във вашия проект, когато извършвате промяна на лиценза.
 
 ## Моят проект има ли нужда от споразумение за допълнителен сътрудник?
 
diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index 0c133f35ebc..4d27eeaf040 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -20,7 +20,7 @@ related:
 
 Отвореният код е мощен, защото намалява бариерите пред приемането и сътрудничеството, позволявайки на хората да разпространяват и подобряват проекти бързо. Също така защото дава на потребителите потенциал да контролират собствените си компютри, в сравнение със затворения код. Например, бизнес, използващ софтуер с отворен код, има опцията да наеме някой, който да направи персонализирани подобрения на софтуера, вместо да разчита изключително на продуктовите решения на доставчик със затворен код.
 
-_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#прави-отворен-код-означава-безплатен).
+_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#does-open-source-mean-free-of-charge).
 
 ### Защо хората отварят кода на работата си?
 
diff --git a/_data/locales/bg.yml b/_data/locales/bg.yml
index 184c8e665f5..f2b963f522f 100644
--- a/_data/locales/bg.yml
+++ b/_data/locales/bg.yml
@@ -28,4 +28,4 @@ en:
       # Label for love octicon
       love_label: love
       # Label for the contributors link
-      friends_label: приятели
+      friends_label: friends

From 45a476dbe43b2667a412a6fe6e13441446386cdd Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Thu, 4 Apr 2024 20:53:27 +0200
Subject: [PATCH 664/749] correct links

---
 _articles/bg/building-community.md        | 6 +++---
 _articles/bg/leadership-and-governance.md | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index c574fff209b..7e77fe1abbe 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -35,7 +35,7 @@ related:
 * **Когато някой нов се присъедини към вашия проект, благодарете му за проявения интерес!** Необходим е само един негативен опит, за да накара някой да не иска да се върне.
 * **Бъдете отзивчиви.** Ако не отговорите на въпроса им в продължение на един месец, има вероятност те вече да са забравили за вашия проект.
 * **Бъдете непредубедени относно видовете вноски, които ще приемете.** Много сътрудници започват с доклад за грешка или малка корекция. Има [много начини да допринесете](../how-to-contribute/#what-it-means-to-contribute) за даден проект. Нека хората помагат по начина, по който искат.
-* **Ако има принос, с който не сте съгласни,** thank them for their idea and [обясни защо](../best-practices/#learning-to-say-no) не се вписва в обхвата на проекта, като се позовавате на съответната документация, ако я имате.
+* **Ако има принос, с който не сте съгласни,** thank them for their idea and [обясни защо](../best-practices.d#learning-to-say-no) не се вписва в обхвата на проекта, като се позовавате на съответната документация, ако я имате.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -123,7 +123,7 @@ related:
 
 Редовните дискусии за тривиални аспекти на вашия проект разсейват другите, включително вас, от фокусирането върху важни задачи. Нови хора, които пристигат във вашия проект, може да видят тези разговори и да не искат да участват.
 
-Когато видите, че във вашия проект се случва негативно поведение, извикайте го публично. Обяснете, с любезен, но твърд тон, защо поведението им не е приемливо. Ако проблемът продължава, може да се наложи [да ги помолите да напуснат](../code-of-conduct/#enforcing-your-code-of-conduct). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
+Когато видите, че във вашия проект се случва негативно поведение, извикайте го публично. Обяснете, с любезен, но твърд тон, защо поведението им не е приемливо. Ако проблемът продължава, може да се наложи [да ги помолите да напуснат](../code-of-conduct.md#enforcing-your-code-of-conduct). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
 
 ### Запознайте се с сътрудниците там, където са
 
@@ -193,7 +193,7 @@ related:
 
 Когато вашата общност се бори с труден проблем, настроението може да се надигне. Хората може да се ядосат или разочароват и да си го изкарат един на друг или на вас.
 
-Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#dont-tolerate-bad-actors), за да поддържате дискусията цивилизована и продуктивна.
+Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community.md#dont-tolerate-bad-actors), за да поддържате дискусията цивилизована и продуктивна.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
index 9b67738eaa8..2ddb6418d37 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/#share-ownership-of-your-project).
+И накрая, ако проектът ви е в GitHub, помислете за преместване на проекта от личния ви акаунт в организация и добавяне на поне един резервен администратор. [Организациите на GitHub](https://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community.md#share-ownership-of-your-project).
 
 ## Кога трябва да дам на някого достъп за ангажиране?
 

From 6d870ef1d6f5f5648d567f0b580c027949985404 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Thu, 4 Apr 2024 21:11:56 +0200
Subject: [PATCH 665/749] chnage again urls

---
 _articles/bg/building-community.md        | 6 +++---
 _articles/bg/leadership-and-governance.md | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index 7e77fe1abbe..2edff972f90 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -35,7 +35,7 @@ related:
 * **Когато някой нов се присъедини към вашия проект, благодарете му за проявения интерес!** Необходим е само един негативен опит, за да накара някой да не иска да се върне.
 * **Бъдете отзивчиви.** Ако не отговорите на въпроса им в продължение на един месец, има вероятност те вече да са забравили за вашия проект.
 * **Бъдете непредубедени относно видовете вноски, които ще приемете.** Много сътрудници започват с доклад за грешка или малка корекция. Има [много начини да допринесете](../how-to-contribute/#what-it-means-to-contribute) за даден проект. Нека хората помагат по начина, по който искат.
-* **Ако има принос, с който не сте съгласни,** thank them for their idea and [обясни защо](../best-practices.d#learning-to-say-no) не се вписва в обхвата на проекта, като се позовавате на съответната документация, ако я имате.
+* **Ако има принос, с който не сте съгласни,** thank them for their idea and [обясни защо](../best-practices/#научаване-да-казваш-не) не се вписва в обхвата на проекта, като се позовавате на съответната документация, ако я имате.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -123,7 +123,7 @@ related:
 
 Редовните дискусии за тривиални аспекти на вашия проект разсейват другите, включително вас, от фокусирането върху важни задачи. Нови хора, които пристигат във вашия проект, може да видят тези разговори и да не искат да участват.
 
-Когато видите, че във вашия проект се случва негативно поведение, извикайте го публично. Обяснете, с любезен, но твърд тон, защо поведението им не е приемливо. Ако проблемът продължава, може да се наложи [да ги помолите да напуснат](../code-of-conduct.md#enforcing-your-code-of-conduct). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
+Когато видите, че във вашия проект се случва негативно поведение, извикайте го публично. Обяснете, с любезен, но твърд тон, защо поведението им не е приемливо. Ако проблемът продължава, може да се наложи [да ги помолите да напуснат](../code-of-conduct/#налагане-на-вашия-кодекс-на-поведение). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
 
 ### Запознайте се с сътрудниците там, където са
 
@@ -193,7 +193,7 @@ related:
 
 Когато вашата общност се бори с труден проблем, настроението може да се надигне. Хората може да се ядосат или разочароват и да си го изкарат един на друг или на вас.
 
-Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community.md#dont-tolerate-bad-actors), за да поддържате дискусията цивилизована и продуктивна.
+Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#не-толерирайте-лошите-актьори), за да поддържате дискусията цивилизована и продуктивна.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
index 2ddb6418d37..96602d64243 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.md#share-ownership-of-your-project).
+И накрая, ако проектът ви е в GitHub, помислете за преместване на проекта от личния ви акаунт в организация и добавяне на поне един резервен администратор. [Организациите на GitHub](https://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community/#дял-собственост-на-вашия-проект).
 
 ## Кога трябва да дам на някого достъп за ангажиране?
 

From a2607bb208cc3d9b0879dfd56e19bdd82d69e8f4 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Fri, 5 Apr 2024 09:14:31 +0200
Subject: [PATCH 666/749] try again change url

---
 _articles/bg/building-community.md        | 6 +++---
 _articles/bg/leadership-and-governance.md | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index 2edff972f90..c574fff209b 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -35,7 +35,7 @@ related:
 * **Когато някой нов се присъедини към вашия проект, благодарете му за проявения интерес!** Необходим е само един негативен опит, за да накара някой да не иска да се върне.
 * **Бъдете отзивчиви.** Ако не отговорите на въпроса им в продължение на един месец, има вероятност те вече да са забравили за вашия проект.
 * **Бъдете непредубедени относно видовете вноски, които ще приемете.** Много сътрудници започват с доклад за грешка или малка корекция. Има [много начини да допринесете](../how-to-contribute/#what-it-means-to-contribute) за даден проект. Нека хората помагат по начина, по който искат.
-* **Ако има принос, с който не сте съгласни,** thank them for their idea and [обясни защо](../best-practices/#научаване-да-казваш-не) не се вписва в обхвата на проекта, като се позовавате на съответната документация, ако я имате.
+* **Ако има принос, с който не сте съгласни,** thank them for their idea and [обясни защо](../best-practices/#learning-to-say-no) не се вписва в обхвата на проекта, като се позовавате на съответната документация, ако я имате.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -123,7 +123,7 @@ related:
 
 Редовните дискусии за тривиални аспекти на вашия проект разсейват другите, включително вас, от фокусирането върху важни задачи. Нови хора, които пристигат във вашия проект, може да видят тези разговори и да не искат да участват.
 
-Когато видите, че във вашия проект се случва негативно поведение, извикайте го публично. Обяснете, с любезен, но твърд тон, защо поведението им не е приемливо. Ако проблемът продължава, може да се наложи [да ги помолите да напуснат](../code-of-conduct/#налагане-на-вашия-кодекс-на-поведение). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
+Когато видите, че във вашия проект се случва негативно поведение, извикайте го публично. Обяснете, с любезен, но твърд тон, защо поведението им не е приемливо. Ако проблемът продължава, може да се наложи [да ги помолите да напуснат](../code-of-conduct/#enforcing-your-code-of-conduct). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
 
 ### Запознайте се с сътрудниците там, където са
 
@@ -193,7 +193,7 @@ related:
 
 Когато вашата общност се бори с труден проблем, настроението може да се надигне. Хората може да се ядосат или разочароват и да си го изкарат един на друг или на вас.
 
-Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#не-толерирайте-лошите-актьори), за да поддържате дискусията цивилизована и продуктивна.
+Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#dont-tolerate-bad-actors), за да поддържате дискусията цивилизована и продуктивна.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
index 96602d64243..9b67738eaa8 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://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community/#share-ownership-of-your-project).
 
 ## Кога трябва да дам на някого достъп за ангажиране?
 

From 36b2bcf2fee2ea53647af3ba25fc1b02223d4bd3 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Fri, 5 Apr 2024 09:34:31 +0200
Subject: [PATCH 667/749] try again

---
 _articles/bg/building-community.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index c574fff209b..d803f58ea94 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -35,7 +35,7 @@ related:
 * **Когато някой нов се присъедини към вашия проект, благодарете му за проявения интерес!** Необходим е само един негативен опит, за да накара някой да не иска да се върне.
 * **Бъдете отзивчиви.** Ако не отговорите на въпроса им в продължение на един месец, има вероятност те вече да са забравили за вашия проект.
 * **Бъдете непредубедени относно видовете вноски, които ще приемете.** Много сътрудници започват с доклад за грешка или малка корекция. Има [много начини да допринесете](../how-to-contribute/#what-it-means-to-contribute) за даден проект. Нека хората помагат по начина, по който искат.
-* **Ако има принос, с който не сте съгласни,** thank them for their idea and [обясни защо](../best-practices/#learning-to-say-no) не се вписва в обхвата на проекта, като се позовавате на съответната документация, ако я имате.
+* **Ако има принос, с който не сте съгласни,** thank them for their idea and [обясни защо](../best-practices/#sabi-to-say-no) не се вписва в обхвата на проекта, като се позовавате на съответната документация, ако я имате.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -123,7 +123,7 @@ related:
 
 Редовните дискусии за тривиални аспекти на вашия проект разсейват другите, включително вас, от фокусирането върху важни задачи. Нови хора, които пристигат във вашия проект, може да видят тези разговори и да не искат да участват.
 
-Когато видите, че във вашия проект се случва негативно поведение, извикайте го публично. Обяснете, с любезен, но твърд тон, защо поведението им не е приемливо. Ако проблемът продължава, може да се наложи [да ги помолите да напуснат](../code-of-conduct/#enforcing-your-code-of-conduct). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
+Когато видите, че във вашия проект се случва негативно поведение, извикайте го публично. Обяснете, с любезен, но твърд тон, защо поведението им не е приемливо. Ако проблемът продължава, може да се наложи [да ги помолите да напуснат](../code-of-conduct/#how-you-go-take-think-your-code-of-conduct-to-stand-gidi-gba). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
 
 ### Запознайте се с сътрудниците там, където са
 
@@ -193,7 +193,7 @@ related:
 
 Когато вашата общност се бори с труден проблем, настроението може да се надигне. Хората може да се ядосат или разочароват и да си го изкарат един на друг или на вас.
 
-Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#dont-tolerate-bad-actors), за да поддържате дискусията цивилизована и продуктивна.
+Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#no-dey-tolerate-bad-actors), за да поддържате дискусията цивилизована и продуктивна.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">

From 0564b92de3fb1fd4e1ac044a27e6fd258bd0600f Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Fri, 12 Apr 2024 13:21:18 -0700
Subject: [PATCH 668/749] Fix test failures caused by untranslated internal
 link

Prior to this change the tests would fail with:

Checking 358 external links...
Ran on 300 files!
- _site/pcm/best-practices/index.html
  *  linking to internal hash #share-ownership-of-your-project that does not exist (line 557)
       <a href="../building-community/#share-ownership-of-your-project">share ownership of the project</a>

This fixes the internal anchor to match the translated header text.
---
 _articles/pcm/best-practices.md            | 2 +-
 _articles/pcm/leadership-and-governance.md | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/pcm/best-practices.md b/_articles/pcm/best-practices.md
index 069470ed728..785dc0e87e1 100644
--- a/_articles/pcm/best-practices.md
+++ b/_articles/pcm/best-practices.md
@@ -149,7 +149,7 @@ 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.
 
-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-ownership-of-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).
+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).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/pcm/leadership-and-governance.md b/_articles/pcm/leadership-and-governance.md
index 13d07b1ae5f..be65ea87eef 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-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://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).
 
 ## When should I give someone commit access?
 

From a21e701c035e66c069fb5dd36d149368a5da7bcb Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Mon, 15 Apr 2024 11:58:40 +0200
Subject: [PATCH 669/749] change agan url after #

---
 _articles/bg/best-practices.md            |  2 +-
 _articles/bg/building-community.md        | 14 +++++++-------
 _articles/bg/leadership-and-governance.md |  4 ++--
 _articles/bg/legal.md                     |  6 +++---
 _articles/bg/starting-a-project.md        |  2 +-
 5 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md
index 8878c22a338..355f934d385 100644
--- a/_articles/bg/best-practices.md
+++ b/_articles/bg/best-practices.md
@@ -169,7 +169,7 @@ related:
 
 Когато видите нови сътрудници, които правят повторни приноси, признайте работата им, като предложите повече отчетност. Документирайте как другите могат да израснат в лидерски роли, ако решат.
 
-Насърчаване на другите да [споделят собствеността върху проекта](../building-community/#share-ownership-of-your-project) може значително да намали вашето работното натоварване, както @lmccart откри в своя проект, [p5.js](https://github.com/processing/p5.js).
+Насърчаване на другите да [споделят собствеността върху проекта](../building-community/#дял-собственост-на-вашия-проект) може значително да намали вашето работното натоварване, както @lmccart откри в своя проект, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index d803f58ea94..9bc2bb4e304 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -26,16 +26,16 @@ related:
 
 Започнете с вашата документация:
 
-* **Улеснете го за тези, които трябва да използват проекта.** [Приятелски README документ](../starting-a-project/#writing-a-readme) aи ясни примери за кодове ще улеснят всеки, който попадне на вашия проект, да започне.
-* **Обяснете ясно как да допринесат**, използвайки [вашият CONTRIBUTING архив](../starting-a-project/#writing-your-contributing-guidelines) и поддържане на вашите проблеми актуални.
+* **Улеснете го за тези, които трябва да използват проекта.** [Приятелски README документ](../starting-a-project/#писане-нa-readme) aи ясни примери за кодове ще улеснят всеки, който попадне на вашия проект, да започне.
+* **Обяснете ясно как да допринесат**, използвайки [вашият CONTRIBUTING архив](../starting-a-project/#писане-на-допринасящите-насоки) и поддържане на вашите проблеми актуални.
 * **Добри първи издания**: За да помогнете на новите сътрудници да започнат, мислете ясно за [подчертаване на теми, които са достатъчно прости, за да се справи начинаещият](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки полезните приноси и намалявайки напрежението от потребителите, които се справят с проблеми, които са твърде трудни за тяхното ниво.
 
 [Проучване на GitHub за отворен код от 2017 г](http://opensourcesurvey.org/2017/) показа, че непълната или объркваща документация е най-големият проблем за потребителите с отворен код. Добрата документация приканва хората да взаимодействат с вашия проект. В крайна сметка някой ще отвори проблем или заявка. Използвайте тези взаимодействия като възможности да ги преместите надолу по фунията.
 
 * **Когато някой нов се присъедини към вашия проект, благодарете му за проявения интерес!** Необходим е само един негативен опит, за да накара някой да не иска да се върне.
 * **Бъдете отзивчиви.** Ако не отговорите на въпроса им в продължение на един месец, има вероятност те вече да са забравили за вашия проект.
-* **Бъдете непредубедени относно видовете вноски, които ще приемете.** Много сътрудници започват с доклад за грешка или малка корекция. Има [много начини да допринесете](../how-to-contribute/#what-it-means-to-contribute) за даден проект. Нека хората помагат по начина, по който искат.
-* **Ако има принос, с който не сте съгласни,** thank them for their idea and [обясни защо](../best-practices/#sabi-to-say-no) не се вписва в обхвата на проекта, като се позовавате на съответната документация, ако я имате.
+* **Бъдете непредубедени относно видовете вноски, които ще приемете.** Много сътрудници започват с доклад за грешка или малка корекция. Има [много начини да допринесете](../how-to-contribute/#какво-означава-да-допринесеш) за даден проект. Нека хората помагат по начина, по който искат.
+* **Ако има принос, с който не сте съгласни,** thank them for their idea and [обясни защо](../best-practices/#научаи-се-да-казваш-не) не се вписва в обхвата на проекта, като се позовавате на съответната документация, ако я имате.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -123,7 +123,7 @@ related:
 
 Редовните дискусии за тривиални аспекти на вашия проект разсейват другите, включително вас, от фокусирането върху важни задачи. Нови хора, които пристигат във вашия проект, може да видят тези разговори и да не искат да участват.
 
-Когато видите, че във вашия проект се случва негативно поведение, извикайте го публично. Обяснете, с любезен, но твърд тон, защо поведението им не е приемливо. Ако проблемът продължава, може да се наложи [да ги помолите да напуснат](../code-of-conduct/#how-you-go-take-think-your-code-of-conduct-to-stand-gidi-gba). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
+Когато видите, че във вашия проект се случва негативно поведение, извикайте го публично. Обяснете, с любезен, но твърд тон, защо поведението им не е приемливо. Ако проблемът продължава, може да се наложи [да ги помолите да напуснат](../code-of-conduct/#прилагане-на-вашия-кодекс-на-поведение). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
 
 ### Запознайте се с сътрудниците там, където са
 
@@ -193,7 +193,7 @@ related:
 
 Когато вашата общност се бори с труден проблем, настроението може да се надигне. Хората може да се ядосат или разочароват и да си го изкарат един на друг или на вас.
 
-Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#no-dey-tolerate-bad-actors), за да поддържате дискусията цивилизована и продуктивна.
+Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#недей-толерирай-лоши-актьори), за да поддържате дискусията цивилизована и продуктивна.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
@@ -209,7 +209,7 @@ related:
 
 ### Отнасяйте се към вашия README като към конституция
 
-Вашият README е [повече от просто набор от инструкции](../starting-a-project/#writing-a-readme). Това също е място да говорите за вашите цели, продуктова визия и пътна карта. Ако хората са прекалено съсредоточени върху обсъждането на достойнствата на определена функция, може да ви помогне да прегледате отново вашия README и да говорите за по-високата визия на вашия проект. Фокусирането върху вашия README също обезличава разговора, така че можете да водите конструктивна дискусия.
+Вашият README е [повече от просто набор от инструкции](../starting-a-project/#писане-нa-readme). Това също е място да говорите за вашите цели, продуктова визия и пътна карта. Ако хората са прекалено съсредоточени върху обсъждането на достойнствата на определена функция, може да ви помогне да прегледате отново вашия README и да говорите за по-високата визия на вашия проект. Фокусирането върху вашия README също обезличава разговора, така че можете да водите конструктивна дискусия.
 
 ### Фокусирайте се върху пътуването, а не върху дестинацията
 
diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
index 9b67738eaa8..e899d2926ab 100644
--- a/_articles/bg/leadership-and-governance.md
+++ b/_articles/bg/leadership-and-governance.md
@@ -40,7 +40,7 @@ related:
 
 **Терминът "извършител"** може да се използва за разграничаване на достъпа за ангажиране, който е специфичен тип отговорност, от други форми на принос.
 
-Въпреки че можете да дефинирате ролите си в проекта както желаете, [помислете дали да не използвате по-широки дефиниции](../how-to-contribute/#what-it-means-to-contribute), за да насърчите повече форми на принос. Можете да използвате лидерски роли, за да признаете официално хора, които са направили изключителен принос към вашия проект, независимо от техните технически умения.
+Въпреки че можете да дефинирате ролите си в проекта както желаете, [помислете дали да не използвате по-широки дефиниции](../how-to-contribute/#какво-значи-да-допринесеш), за да насърчите повече форми на принос. Можете да използвате лидерски роли, за да признаете официално хора, които са направили изключителен принос към вашия проект, независимо от техните технически умения.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
@@ -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/#share-ownership-of-your-project).
+И накрая, ако проектът ви е в GitHub, помислете за преместване на проекта от личния ви акаунт в организация и добавяне на поне един резервен администратор. [Организациите на GitHub](https://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community/#дял-собственост-на-вашия-проект).
 
 ## Кога трябва да дам на някого достъп за ангажиране?
 
diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
index 01850e96dd0..677efad3fcf 100644
--- a/_articles/bg/legal.md
+++ b/_articles/bg/legal.md
@@ -70,7 +70,7 @@ related:
 * **Искате ли вашият проект да се хареса на големия бизнес?** Големият бизнес може да се утеши от изричен патентен лиценз от всички сътрудници. В този случай [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) покрива вас (и тях).
 * **Искате ли вашият проект да се хареса на сътрудници, които не искат техният принос да се използва в софтуер със затворен код?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) или (ако те също не желаят да допринасят за услуги със затворен код) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) ще мине добре.
 
-Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник ([вижте по-долу](#does-my-project-need-an-additional-contributor-agreement)), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#what-does-my-companys-legal-team-need-to-know) за насоки.
+Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник (вижте по-долу), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#какво-трябва-да-знае-юридическият-екип-на-моята-компания) за насоки.
 
 Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на един от лицензите, споменати по-горе, ще направи вашия проект GitHub с отворен код. Ако искате да видите други опции, вижте [choosealicense.com](https://choosealicense.com), за да намерите правилния лиценз за вашия проект, дори ако [не е софтуер](https://choosealicense.com/non-software/).
 
@@ -128,7 +128,7 @@ related:
 
 * **Патенти:** Вашата компания кандидатства ли за патент, за който отвореният код на вашия проект би представлявал [публично разкриване](https://en.wikipedia.org/wiki/Public_disclosure)? За съжаление може да бъдете помолени да изчакате (или може би компанията ще преразгледа разумността на приложението). Ако очаквате принос към вашия проект от служители на компании с големи патентни портфейли, вашият правен екип може да поиска да използвате лиценз с изрично предоставяне на патент от сътрудници (като Apache 2.0 или GPLv3) или допълнително споразумение за сътрудници ([вижте по-горе](#which-open-source-license-is-appropriate-for-my-project)).
 
-* **Търговски марки:** Проверете отново дали името на вашия проект [не е в конфликт със съществуващи търговски марки](../starting-a-project/#avoiding-name-conflicts). Ако използвате търговските марки на собствената си компания в проекта, проверете дали това не предизвиква конфликти. [FOSSmarks](http://fossmarks.org/) е практическо ръководство за разбиране на търговските марки в контекста на безплатни проекти с отворен код.
+* **Търговски марки:** Проверете отново дали името на вашия проект [не е в конфликт със съществуващи търговски марки](../starting-a-project/#избягване-на-конфликти-с-имена). Ако използвате търговските марки на собствената си компания в проекта, проверете дали това не предизвиква конфликти. [FOSSmarks](http://fossmarks.org/) е практическо ръководство за разбиране на търговските марки в контекста на безплатни проекти с отворен код.
 
 * **Поверителност:** Вашият проект събира ли данни за потребители? "Домашен телефон" към фирмени сървъри? Вашият правен екип може да ви помогне да спазвате фирмените политики и външните разпоредби.
 
@@ -157,4 +157,4 @@ related:
 </aside>
 
 * **Патенти:** Вашата компания може да пожелае да се присъедини към [Open Invention Network](https://www.openinventionnetwork.com/), споделен защитен патентен пул за защита на използването на големи проекти с отворен код от членовете, или да проучи друго [алтернативно патентно лицензиране](https://www.eff.org/document/hacking-patent-system-2016).
-* **Управление:** Особено ако и когато има смисъл да се премести проект към [юридическо лице извън компанията](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
+* **Управление:** Особено ако и когато има смисъл да се премести проект към [юридическо лице извън компанията](../leadership-and-governance/#имам-нужда-от-юридическо-лице-което-да-подкрепи-моя-проект).
diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index 4d27eeaf040..bc03ff7fa98 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -20,7 +20,7 @@ related:
 
 Отвореният код е мощен, защото намалява бариерите пред приемането и сътрудничеството, позволявайки на хората да разпространяват и подобряват проекти бързо. Също така защото дава на потребителите потенциал да контролират собствените си компютри, в сравнение със затворения код. Например, бизнес, използващ софтуер с отворен код, има опцията да наеме някой, който да направи персонализирани подобрения на софтуера, вместо да разчита изключително на продуктовите решения на доставчик със затворен код.
 
-_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#does-open-source-mean-free-of-charge).
+_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#отворен-код-без-средства).
 
 ### Защо хората отварят кода на работата си?
 

From 90c56219b9cc63e12256df529e9dddb137ecae5a Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Mon, 15 Apr 2024 15:29:23 +0200
Subject: [PATCH 670/749] I deleted and rewrote the best-practice.md file again
 and changed the link again after # in the building-community.md file

---
 _articles/bg/best-practices.md     | 213 ++++++++++++++---------------
 _articles/bg/building-community.md |  14 +-
 2 files changed, 111 insertions(+), 116 deletions(-)

diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md
index 355f934d385..4bc0c86aa34 100644
--- a/_articles/bg/best-practices.md
+++ b/_articles/bg/best-practices.md
@@ -1,7 +1,7 @@
 ---
 lang: bg
-title: Най-добри практики за поддържащи код
-description: Улесняване на живота ви като поддържащ отворен код, от документиране на процеси до използване на вашата общност.
+title: Добри практики за поддържащи кода.
+description: Улесняване на живота ви като поддържащ отворен код, от процеса на документиране до извличане на максимума от общността.
 class: best-practices
 order: 5
 image: /assets/images/cards/best-practices.png
@@ -10,154 +10,153 @@ related:
   - leadership
 ---
 
-## Какво означава да си поддържащ на код?
+## Какво означава да си поддържащ код?
 
-Ако поддържате проект с отворен код, който много хора използват, може би сте забелязали, че кодирате по-малко и отговаряте повече на проблеми.
+Ако вашата работа е да поддържате проект с отворен код, който много хора използват, вероятно сте забелязали, че прекарвате повече време в отговаряне на въпроси, отколкото в програмиране.
 
-В ранните етапи на проекта вие експериментирате с нови идеи и вземате решения въз основа на това, което искате. С нарастването на популярността на проекта ви ще откриете, че работите повече с вашите потребители и сътрудници.
+В ранните етапи на проекта прекарвате време в експериментиране с нови идеи и вземане на решения въз основа на това, което харесвате. С нарастването на популярността на проекта ви ще се окажете в ситуация, в която ще работите с вашите потребители и сътрудници все повече и повече.
 
-Поддържането на проект изисква повече от код. Тези задачи често са неочаквани, но са също толкова важни за разрастващ се проект. Събрахме няколко начина да улесним живота ви, от документиране на процеси до използване на вашата общност.
+Поддържането на проект изисква повече от просто код. Тези задачи обикновено не се вземат предвид, но са също толкова важни за разрастващ се проект. Събрахме няколко идеи, които ще улеснят живота ви, от процеса на документиране до извличането на максимума от общността.
 
 ## Документиране на вашите процеси
 
-Записването на нещата е едно от най-важните неща, които можете да направите като поддържащ на код.
+Отбелязването на процедурите е една от най-добрите практики, които можете да направите като поддържащ код.
 
-Документацията не само изяснява вашето собствено мислене, но помага на другите хора да разберат от какво се нуждаете или очаквате, преди дори да попитат.
+Документирането не само изяснява вашето мислене, но също така помага на другите да разберат от какво се нуждаете или очаквате, без дори да се налага да питате.
 
-Записването на нещата ви улеснява да кажете "не", когато нещо не се вписва в обхвата ви. Освен това улеснява хората да се включат и да помогнат. Никога не знаете кой може да чете или използва вашия проект.
+Като вземете под внимание процесите, ви е по-лесно да кажете "не", когато нечие предложение не отговаря на вашия контекст. Така Освен това улеснява други хора да се присъединят и да помогнат. Никога не знаете кой може да чете или използва вашия проект.
 
-Дори и да не използвате пълни абзаци, писането на точки е по-добре, отколкото да не пишете изобщо.
+Дори и да не сте от хората, които пишат цели параграфи, записването на ключови моменти е по-добро от никакви.
 
-Не забравяй да поддържате документацията си актуална. Ако не можете винаги да правите това, изтрийте остарялата си документация или посочете, че е остаряла, така че участниците да знаят, че актуализациите са добре дошли.
+### Изясняване на визията на вашия проект
 
-### Запишете визията на вашия проект
+Започнете, като напишете целите на вашия проект. Добавете ги към вашия файл README или създайте отделен файл, наречен VISION. Ако има други артефакти, които могат да помогнат, като например карта на проект, направете и тях публични.
 
-Започнете, като напишете целите на вашия проект. Добавете ги към вашия README или създайте отделен файл, наречен VISION. Ако има други фактори, които биха могли да помогнат, като пътна карта на проекта, направете и тях публични.
+Наличието на ясна документирана визия ви държи фокусирани и помага да избегнете неразбиране на обхвата от други сътрудници.
 
-Наличието на ясна, документирана визия ви държи фокусирани и ви помага да избегнете "да не ви се изплъзне целта" от приноса на другите.
-
-Например, @lord откри, че наличието на визия за проекта му помага да разбере на кои заявки да отдели време. Като нов поддържащ, той съжаляваше, че не се придържа към обхвата на проекта си, когато получи първата си заявка за функция [Slate](https://github.com/lord/slate).
+Например:
+@lord откри фактът, че наличието на визия за проект му помогна да разбере кои заявки да даде приоритет. Като начинаещ поддържащ код, той се оплака че не е бил верен на обхвата на проекта, когато е получил първата ви заявка за функционалност [Slate](https://github.com/lord/slate).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
-  Опитах. Не положих необходимите усилия, за да изляза с цялостно решение. Вместо полуготово решение, бих искал да бях казал "Нямам време за това в момента, но ще добавя функционалността към изоставането, което ще бъде разработено в бъдеще".
+  Опитах. Не положих необходимите усилия, за да изляза с цялостно решение. Вместо половинчато решение, бих искал да бях казал "Нямам време за това в момента, но ще добавя функционалността към изоставането, което ще бъде разработено в бъдеще".
   <p markdown="1" class="pquote-credit">
-— @lord, ["Съвети за нови поддържащи отворен код"](https://lord.io/blog/2014/oss-tips/)
+— @lord, ["Съвети за поддържащите отворен код"](https://lord.io/blog/2014/oss-tips/)
   </p>
 </aside>
 
 ### Съобщете вашите очаквания
 
-Записването на правила може да бъде изнервящо. Понякога може да се чувствате така, сякаш контролирате поведението на другите хора или убивате цялото забавление.
+Понякога може да е трудно да се формулират правилата, така че други хора да могат да допринесат. Може да почувствате, че се държите като ченге или разваляте забавлението на другите.
 
 Въпреки това, написани и приложени справедливо, добрите правила дават възможност на поддържащите кода. Те ви предпазват от това да бъдете въвлечени в неща, които не искате да правите.
 
-Повечето хора, които срещат вашия проект, не знаят нищо за вас или вашите обстоятелства. Те може да приемат, че ви е платено да работите по него, особено ако това е нещо, което те използват и от което зависят редовно. Може би в един момент сте отделили много време за проекта си, но сега сте заети с нова работа или член на семейството.
+Повечето хора, които срещат вашия проект, не знаят нищо за вас или вашите обстоятелства. Те може да приемат, че ви е платено да работите по него, особено ако това е нещо, което те използват и от което зависят редовно. Може би някога сте отделяли много време за проекта си, но сега сте заети с нова работа или член на семейството.
 
-Всичко това е напълно наред! Просто се уверете, че другите хора знаят за това.
+Всичко е наред! Просто се уверете, че хората знаят.
 
-Независимо дали поддържането на вашия проект е на непълно работно време или просто доброволчество, бъдете честни с колко време разполагате. Това не е същото като колко време смятате, че изисква проектът или колко време другите искат да отделите.
+Независимо дали поддържането на вашия проект е на непълно работно време или просто доброволно, бъдете честни за това колко време имате. Това не е същото като колко време мислите, че ще отнеме проектът или колко време другите искат да отделите.
 
 Ето някои правила, които си струва да имате предвид:
 
-* Как се преглежда и приема принос (_Имат ли нужда от тестове? Шаблон за проблем?_)
-* Типовете приноси, които ще приемете (_Искате ли помощ само за определена част от вашия код?_)
-* Когато е уместно да се проследи (_например, "Можете да очаквате отговор от поддържащия в рамките на 7 дни. Ако не сте чули нищо дотогава, не се колебайте да пингвате темата."_)
-* Колко време отделяте за проекта (_например, "Прекарваме само около 5 часа на седмица в този проект"_)
+* Как се преглежда и приема принос (_Трябва ли да направите някои тестове? Някакви шаблони, които да използвате за проблеми?_)
+* Типовете приноси, които ще приемете (_Искате ли помощ само за част от кода?_)
+* Кога е уместно да се проследи (_напр. "Можете да очаквате отговор от поддържащия код в рамките на следващите 7 дни. Ако не сте чули нищо дотогава, не се колебайте да изпратите ping на нишката."_)
+*Колко време посвещавате на проекта (_напр. "Ние инвестираме само около 5 часа на седмица в този проект"_)
 
-[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) са някои примери за проекти с ясни правила за поддържащите и сътрудниците.
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), и [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) това са някои примери за проекти с ясни правила за поддържащи и сътрудници.
 
 ### Поддържайте публична комуникация
 
-Не забравяйте да документирате и вашите взаимодействия. Където можете, поддържайте публична комуникация относно вашия проект. Ако някой се опита да се свърже с вас насаме, за да обсъдите заявка за функция или нужда от поддръжка, учтиво го насочете към публичен комуникационен канал, като пощенски списък или инструмент за проследяване на проблеми.
+Не забравяйте да документирате и вашите взаимодействия. Където можете, поддържайте публична комуникация относно вашия проект. Ако някой се опита да се свърже с вас лично, за да обсъдите заявка за функция или нужда от поддръжка, учтиво го насочете към обществен канал за комуникация, като списък с имейли или инструмент за проследяване на проблеми.
 
 Ако се срещнете с други поддържащи или вземете важни решения насаме, документирайте тези разговори публично, дори ако просто публикувате бележките си.
 
-По този начин всеки, който се присъедини към вашата общност, ще има достъп до същата информация като някой, който е бил там от години.
+По този начин всеки, който се присъедини към вашата общност, ще има достъп до същата информация като някой, който е бил там. От години.
 
-## Да се ​​научим да казваме не
+## Научете се да казвате не
 
-Вие сте записали нещата. В идеалния случай всеки ще прочете вашата документация, но в действителност ще трябва да напомните на другите, че това знание съществува.
+Написахте нещата. В идеалния случай всеки ще прочете вашата документация, но в действителност ще трябва да напомняте на другите, че това знание съществува.
 
-Записването на всичко обаче помага да се обезличи ситуациите, когато трябва да наложите правилата си.
+Наличието на всичко написано обаче помага да се обезличат ситуациите, в които е необходимо да се налагат правилата.
 
-Да кажете "не" не е забавно, но "Вашият принос не отговаря на критериите за този проект" изглежда по-малко лично от "Не харесвам вашия принос".
+Да кажете "не" не е забавно, но _"Вашият принос не отговаря на критериите за този проект"_ изглежда по-малко лично от _"Не харесвам приноса ви"_.
 
-Казването на "не" се отнася за много ситуации, с които ще се сблъскате като поддържащ код: заявки за функции, които не отговарят на обхвата, някой дерайлира дискусия, върши ненужна работа за други.
+Казването "не" се отнася за много ситуации, които ще срещнете като поддържащ код: заявки за функции, които са извън обхвата, някой дерайлира дискусия, върши ненужна работа за други.
 
 ### Поддържайте разговора приятелски
 
-Едно от най-важните места, където ще се упражнявате да казвате "не", е във вашите проблеми и опашката за изтегляне на заявки. Като ръководител на проекта вие неизбежно ще получите предложения, които не искате да приемете.
+Едно от най-важните места, където ще практикувате да казвате "не", е в опашката за издаване и изтегляне на заявки. Като ръководител на проекти вие неизбежно ще получите предложения, които не искате да приемете.
 
-Може би приносът променя обхвата на вашия проект или не отговаря на вашата визия. Може би идеята е добра, но изпълнението е лошо.
+Може би приносът променя обхвата на вашия проект или не отговаря на вашата визия. Може би идеята е добра, но изпълнението е ужасно.
 
-Независимо от причината е възможно да се справите тактично с приноси, които не отговарят на стандартите на вашия проект.
+Независимо от причината, можете тактично да се справите с приноси, които не отговарят на стандартите на проекта.
 
-Ако получите принос, който не искате да приемете, първата ви реакция може да бъде да го игнорирате или да се престорите, че не сте го видели. Това може да нарани чувствата на другия човек и дори да демотивира други потенциални сътрудници във вашата общност.
+Ако получите изпращане, което не искате да приемете, първата ви реакция може да бъде да го игнорирате или да се престорите, че не сте го видели. Това може да нарани чувствата на другия човек и дори да обезкуражи други потенциални сътрудници във вашата общност.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
-  Ключът към управлението на поддръжката за широкомащабни проекти с отворен код е проблемите да се движат. Опитайте се да избегнете все още проблеми. Ако сте разработчик на iOS, знаете колко разочароващо може да бъде изпращането на радари. Може да получите някои новини две години по-късно и те ще бъдат помолени да опитат отново с най-новата версия на iOS.
+  Ключът към управлението на поддръжката за широкомащабни проекти с отворен код е проблемите да се движат. Опитайте се да избегнете все още проблеми. Ако сте разработчик на iOS, знаете колко разочароващо може да бъде изпращането на радари. Може да получите някои новини две години по-късно и те ще бъдат помолени да ги потвърдят. Моля, опитайте отново с най-новата версия на iOS.
   <p markdown="1" class="pquote-credit">
 — @KrauseFx, ["Мащабиране на общности с отворен код"](https://krausefx.com/blog/scaling-open-source-communities)
   </p>
 </aside>
 
-Не оставяйте отворен нежелан принос, защото се чувствате виновни или искате да сте мили. С течение на времето вашите въпроси без отговор и PR ще направят работата по проекта ви да се чувства много по-стресираща и смущаваща.
+Не оставяйте отворен нежелан принос, защото се чувствате виновни или искате да сте мили. С течение на времето вашите въпроси без отговор и PR ще станат излишни. Това ще направи работата по вашия проект много по-стресираща и смущаваща.
 
-Най-добре е незабавно да затворите приноси, които знаете, че не искате да приемете. Ако вашият проект вече страда от голямо изоставане или списък с функции за внедряване, @steveklabnik има предложения за [как да сортирате проблемите ефективно](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Най-добре е незабавно да затворите приноси, които знаете, че не искате да приемете. Ако вашият проект вече страда от голямо изоставане или списък с функции за внедряване, @steveklabnik има предложения за [как да избирате ефективно въпроси](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
 
 Второ, игнорирането на приносите изпраща отрицателен сигнал към вашата общност. Приносът към проект може да бъде смущаващ, особено ако на някого е за първи път. Дори и да не приемете техния принос, поздравете човека зад него и му благодарете за проявения интерес. Това е страхотен комплимент!
 
-Ако не искате да приемете принос:
+Ако не желаете да приемете дарение:
 
-* **Благодари им** за техния принос
-* **Обяснете защо не се вписва** в обхвата на проекта и предложете ясни предложения за подобрение, ако можете. Бъдете мили, но твърди.
-* **Връзка към съответната документация**, ако я имате. Ако забележите повтарящи се искания за неща, които не искате да приемете, добавете ги в документацията си, за да избегнете повтаряне.
+* **Благодаря им** за техния принос.
+* **Обясни защо не отговаря** на обхвата на проекта и предлага ясни предложения за подобрение, ако е възможно. Знам мил, но твърд.
+* **Споделете подходяща информация**, ако я имате. Ако забележите повтарящи се искания за неща, които не искате да приемете, добавете ги към документацията си, за да избегнете винаги да обяснявате едно и също нещо.
 * **Затворете заявката**
 
-Не трябва да имате повече от 1-2 изречения, за да отговорите. Например, когато потребител на [целъри](https://github.com/celery/celery/) съобщи за грешка, свързана с Windows, @berkerpeksag [отговаря с](https://github.com/celery/celery/issues/3383):
+Не трябва да имате повече от 1-2 изречения, за да отговорите. Например, когато потребител [celery](https://github.com/celery/celery/) съобщи за грешка, свързана с Windows, @berkerpeksag [той отговори с](https://github.com/celery/celery/issues/3383):
 
-![Екрана снимка на целина](/assets/images/best-practices/celery.png)
+[celery screenshot](/assets/images/best-practices/celery.png)
 
-Ако мисълта да кажете "не" ви ужасява, не сте сами. Като @jessfraz [казва](https://blog.jessfraz.com/post/the-art-of-closing/):
+Ако идеята да кажете "не" ви ужасява, не се чувствайте сами. Както @jessfraz [казва](https://blog.jessfraz.com/post/the-art-of-closing/):
 
-> Говорил съм с поддържащи кодове от множество различни проекти с отворен код, Mesos, Kubernetes, Chromium, и всички те са съгласни, че една от най-трудните части да си поддържащ код е да кажеш "не" на пачове, които не работят.
+> Говорил съм с поддържащи кодове от множество различни проекти с отворен код, Mesos, Kubernetes, Chromium, и всички те са съгласни, че една от най-трудните части да си поддържащ код е: да кажеш "Не" на пачове, които не искаш да използваш.
 
-Не се чувствайте виновни, че не искате да приемете нечий принос. Първото правило на отворения код, [съгласно с](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Не е временно, да завинаги е."_ Въпреки че съпричастността към ентусиазма на друг човек е нещо добро, отхвърлянето на принос не е същото като отхвърлянето на човека зад него.
+Не се чувствайте виновни, че не искате да приемете нечий принос. Първото правило на отворения код, [в съответствие със](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Не, е временно; да, това е завинаги."_ Докато мъченичеството на ентусиазма на друг човек е добро нещо, отхвърлянето на принос не е същото като отхвърлянето на човека зад него.
 
-В крайна сметка, ако даден принос не е достатъчно добър, не сте длъжни да го приемете. Бъдете мили и приемащи, когато хората допринасят за вашия проект, но приемайте само промени, които наистина вярвате, че ще направят проекта ви по-добър. Колкото по-често се упражнявате да казвате "не", толкова по-лесно става. Това е обещание.
+В крайна сметка, ако даден принос не е достатъчно добър, не сте длъжни да го приемете. Знам Бъдете мили и отзивчиви, когато хората допринасят за вашия проект, но приемайте само промени, които наистина вярвате, че ще направят проекта ви по-добър. Колкото по-често се упражнявате да казвате "не", толкова по-лесно става. Това е обещание.
 
 ### Бъди проактивен
 
-За да намалите обема на нежеланите приноси на първо място, обяснете процеса на вашия проект за подаване и приемане на приноси във вашето ръководство за приноси.
+За да намалите първо обема на нежеланите приноси, обяснете процеса на вашия проект за подаване и приемане на приноси в ръководството за приноси.
 
-Ако получавате твърде много приноси с ниско качество, изискайте от сътрудниците да свършат малко работа предварително, като например:
+Ако получите твърде много подавания с ниско качество, помолете сътрудниците да свършат малко работа предварително, например:
 
-* Попълнете проблем или PR шаблон/контролен списък
-* Отворете проблем, преди да изпратите PR
+* Попълнете шаблон или контролен списък за проблеми или PR
+*Отворете проблем, преди да изпратите PR
 
 Ако не спазват вашите правила, незабавно затворете проблема и ги насочете към вашата документация.
 
-Въпреки че този подход може да изглежда неприятен в началото, проактивността всъщност е добра и за двете страни. Намалете шанса някой да вложи много часове пропиляна работа в заявка за изтегляне, която няма да приемете. И прави работата ви по-лесна за управление.
+Въпреки че този подход може да изглежда неприятен в началото, проактивността всъщност е добра и за двете страни. Намалете шанса някой да инвестира много часове пропиляна работа върху заявка за изтегляне, която не приемате. И опростява управлението на натоварването.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
- В идеалния случай, обяснете им и във файл CONTRIBUTING.md как могат да получат по-добра индикация в бъдеще за това какво би или не би било прието, преди да започнат работата.
+  В идеалния случай, обяснете във файл CONTRIBUTING.md как могат да получат по-добра индикация в бъдеще за това какво би или не би било прието, преди да започнат работата.
   <p markdown="1" class="pquote-credit">
 — @MikeMcQuaid, ["Любезно затваряне на заявки за изтегляне"](https://github.com/blog/2124-kindly-closing-pull-requests)
   </p>
 </aside>
 
-Понякога, когато кажете "не", вашият потенциален сътрудник може да се разстрои или да критикува решението ви. Ако поведението им стане враждебно, [вземете мерки за обезвреждане на ситуацията](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или дори да ги премахнете от вашата общност, ако не желаят да си сътрудничат конструктивно.
+Понякога, когато кажете „не“, вашият потенциален сътрудник може да се ядоса или да критикува решението ви. Ако поведението ви стане враждебно, [вземете мерки за обезвреждане на ситуацията](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или дори ги отстранете от вашата общност, ако не желаят да си сътрудничат конструктивно.
 
-### Прегърнете менторството
+### Прегърнете наставничеството
 
 Може би някой във вашата общност редовно изпраща приноси, които не отговарят на стандартите на вашия проект. Може да бъде разочароващо и за двете страни многократното преминаване през процеса на отхвърляне.
 
-Ако видите, че някой е развълнуван от вашия проект, но има нужда от малко практика, бъдете търпеливи. Обяснете ясно във всяка ситуация защо вашият принос не отговаря на очакванията на проекта. Опитайте да им дадете по-лесна или по-малко двусмислена задача, като например проблем, отбелязан като "good first issue", за да ги загреете. Ако имате време, обмислете да ги наставлявате чрез първия им принос или намерете някой друг във вашата общност, който е готов да ги наставлява.
+Ако видите, че някой е Ако сте развълнувани от проекта си, но той се нуждае от малко практика, бъдете търпеливи. Обяснете ясно във всяка ситуация защо. техният принос не отговаря на очакванията на проекта. Опитайте да им дадете по-лесна или по-малко двусмислена задача, като например проблем, означен с _"добър първи проблем,"_, за да ги загреете. Ако имате време, помислете за менторство чрез първия си принос или намерете някой друг във вашата общност, който се интересува. готови да ги наставляват.
 
-## Използвайте общността си
+##Използване на общността
 
 Не е нужно да правите всичко сами. Вашата проектна общност съществува с причина! Дори ако все още нямате активна общност от сътрудници, ако имате много потребители, оставете ги да работят.
 
@@ -165,116 +164,112 @@ related:
 
 Ако търсите други да се присъединят, започнете, като разпитате наоколо.
 
-Един от начините да спечелите нови сътрудници е изрично [Проблемите с етикетирането са достатъчно прости за начинаещи](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки тяхната видимост.
-
-Когато видите нови сътрудници, които правят повторни приноси, признайте работата им, като предложите повече отчетност. Документирайте как другите могат да израснат в лидерски роли, ако решат.
+Когато видите нови сътрудници да правят повторни приноси, трябва да признаете работата им, като им предложите повече отговорности. Документирайте как другите могат да постигнат лидерски роли, ако желаят.
 
-Насърчаване на другите да [споделят собствеността върху проекта](../building-community/#дял-собственост-на-вашия-проект) може значително да намали вашето работното натоварване, както @lmccart откри в своя проект, [p5.js](https://github.com/processing/p5.js).
+Насърчаването на други да [споделят собствеността върху проекта](../building-community/#share-ownership-of-your-project) може значително да намали работното ви натоварване, както установи @lmccart във вашия проект, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
-  Казвах: "Да, всеки може да участва, не е необходимо да имате много опит в програмирането [...]." Имахме хора, които се регистрираха [за събития] и тогава се запитах: вярно ли е това, какво казвах? Ще има 40 души, които ще се появят и не е като да мога да седя с всеки един от тях... Но хората се събраха и се получи. Щом човек го получи, той може да учи съседите си.
+ Казвах: "Да, всеки може да участва, не е необходимо да имате много опит в програмирането [...]." Имаме регистрирани хора [за събития] и ето ни Тогава се запитах: вярно ли е това, което казвам? Ще има 40 души, които ще се появят и не е като да мога да седя с всеки един от тях... Но хората се събраха и се получи. Щом човек го получи, той може да учи съседите си.
   <p markdown="1" class="pquote-credit">
-—  @lmccart, ["Какво изобщо означава "отворен код"? p5.js Издание"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+—  @lmccart, ["Какво в крайна сметка означава "Отворен код"? p5.js Редактиране"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
   </p>
 </aside>
 
 Ако трябва да се оттеглите от проекта си, независимо дали временно или за постоянно, не е срамно да помолите някой друг да поеме вместо вас.
 
-Ако други хора са ентусиазирани относно посоката на проекта, дайте им разрешение да се ангажират или официално предайте контрола на някой друг. Ако някой разклони вашия проект и го поддържа активно другаде, помислете за свързване на разклонението от оригиналния ви проект. Страхотно е, че толкова много хора искат вашият проект да се развива!
+Ако други хора са ентусиазирани относно посоката на проекта, дайте им разрешение да се ангажират или официално предайте контрола на някой друг. Ако някой направи разклонение на вашия проект и това е активно поддържане някъде другаде, помислете за свързване на разклонението от вашия оригинален проект. Страхотно е, че толкова много хора искат вашият проект да се развива!
 
-@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) документира визията за своя проект, [Dokku](https://github.com/dokku/dokku), помогна на тези цели да продължат да съществуват дори след като се оттегли от проекта:
+@progrium [установи, че](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) документирайки визията на вашия проект, [Dokku](https://github.com/dokku/dokku), помогне тези цели да продължават, включително и след това, което е останало на проекта:
 
-> Написах уики страница, описваща какво искам и защо го искам. По някаква причина за мен беше изненада, че поддържащите започнаха да движат проекта в тази посока! Случи ли се точно както бих го направил? Не винаги. Но все пак доближи проекта до това, което записах.
+> Написах wiki страница, описваща какво искам и защо го искам. По някаква причина бях изненадан от това! Нека поддържащите започнат да движат проекта в тази посока! Случи се? Как точно бихте го направили? Не винаги. Но както и да се приближи, аз реализирах проекта, както исках.
 
-### Оставете другите да създават решенията, от които се нуждаят
+### Позволете на другите да създават решенията, от които се нуждаят
 
-Ако потенциален сътрудник има различно мнение за това какво трябва да направи вашият проект, може да искате внимателно да го насърчите да работи върху собствената си вилица.
+Ако потенциален сътрудник има различно мнение за това какво трябва да направи вашият проект, може да се наложи внимателно да го насърчите да работи върху собствената си вилка.
 
-Разклоняването на проект не трябва да е нещо лошо. Да можеш да копираш и модифицираш проекти е едно от най-добрите неща на отворения код. Насърчаването на членовете на вашата общност да работят върху собствената си вилица може да осигури творческия изход, от който се нуждаят, без да противоречи на визията на вашия проект.
+Разклоняването на проект не е задължително да е лошо нещо. Да можеш да копираш и модифицираш проекти е едно от най-добрите неща на отворения код. Насърчаването на членовете на вашата общност да работят върху своя собствена вилица може да осигури творческия изход, от който се нуждаят, без да противоречи на визията на вашия проект.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
-  Обслужвам случая на 80% употреба. Ако сте един от еднорозите, моля, разклонете работата ми. Няма да се обидя! Моите обществени проекти почти винаги са предназначени да решават най-често срещаните проблеми; Опитвам се да улесня задълбочаването, като разклонявам работата си или я разширявам.
+  Аз се справям с 80% от случаите на употреба. Ако сте един от еднорозите, моля, разклонете работата ми. Няма да се обидя! Моите обществени проекти почти винаги са насочени към решаване на най-често срещаните проблеми; Опитвам се да улесня отиването по-нататък или с разклонение на моята работа, или като я разширя.
   <p markdown="1" class="pquote-credit">
 — @geerlingguy, ["Защо затварям PR-и"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
   </p>
 </aside>
 
-Същото важи и за потребител, който наистина иска решение, което вие просто нямате възможност да създадете. Предлагането на адаптивни API и hooks може да помогне на другите да посрещнат собствените си нужди, без да се налага директно да променят източника. @orta [установи, че](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) насърчаването на плъгини за CocoaPods доведе до "някои от най-интересните идеи":
+Същото важи и за потребител, който наистина иска решение, което вие просто нямате възможност да създадете. Предлагането на адаптивни API и кукички може да помогне на другите да посрещнат собствените си нужди, без да се налага директно да променят източника.
+@orta [намери че](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) окуражаващи плъгини за CocoaPods към "някои от по-интересните идеи":
 
-> Почти неизбежно е след като проектът стане голям, поддържащите трябва да станат много по-консервативни по отношение на това как въвеждат нов код. Вие ставате добри в това да казвате "не", но много хора имат законни нужди. Така вместо това в крайна сметка преобразувате своя инструмент в платформа.
+> Почти неизбежно е след като проектът стане голям, поддържащите трябва да бъдат много по-консервативни по отношение на това как въвеждат нов код. Умеете да казвате "не", но много хора имат законни нужди. Следователно в крайна сметка превръщате инструмента си в платформа.
 
 ## Доведете роботите
 
-Точно както има задачи, с които други хора могат да ви помогнат, има и задачи, които никой човек никога не трябва да изпълнява. Роботите са ваши приятели. Използвайте ги, за да улесните живота си като поддържащ.
+Така Точно както има задачи, с които други хора могат да ви помогнат, има и задачи, които никое човешко същество не трябва да изпълнява. Роботите са ваши приятели. Използвайте ги, за да улесните живота си като поддържащ код.
 
-### Изисквайте тестове и други проверки, за да подобрите качеството на вашия код
+### Изисквайте тестване и други проверки, за да подобрите качеството на вашия код
 
-Един от най-важните начини, по които можете да автоматизирате проекта си, е чрез добавяне на тестове.
+Един от най-важните начини за автоматизиране на вашия проект е чрез тестване.
 
-Тестовете помагат на сътрудниците да се чувстват уверени, че няма да нарушат нищо. Те също така ви улесняват да преглеждате и бързо приемате приноси. Колкото по-отзивчиви сте, толкова по-ангажирана може да бъде вашата общност.
+Тестването помага на сътрудниците да се чувстват уверени, че няма да нарушат нищо. Те също така улесняват прегледа и бързото приемане на приноси. Колкото по-възприемчиви сте, толкова по-ангажирани ще бъдете. бъдете вашата общност.
 
-Настройте автоматични тестове, които ще се изпълняват на всички входящи приноси, и се уверете, че вашите тестове могат лесно да се изпълняват локално от сътрудниците. Изисквайте всички приноси на код да преминат вашите тестове, преди да могат да бъдат изпратени. Вие ще помогнете да се определи минимален стандарт за качество за всички изпратени документи. [Необходими проверки на състоянието](https://help.github.com/articles/about-required-status-checks/) в GitHub може да ви помогне да гарантирате, че нито една промяна не се обединява, без вашите тестове да преминат.
+Настройте автоматични тестове за изпълнение на всички входящи приноси и се уверете, че могат да се изпълняват локално от сътрудниците. Изисква всички приноси на код да преминат през тестване, преди да могат да бъдат изпратени. Ще помогне за установяване на минимален стандарт за качество за всички приложения.
+[Необходими са проверки на състоянието](https://help.github.com/articles/about-required-status-checks/) в GitHub може да помогне да се гарантира, че никакви промени не се обединяват, без първо да преминете през тестване.
 
-Ако добавяте тестове, не забравяйте да обясните как работят във вашия CONTRIBUTING файл.
+Ако добавите тестове, не забравяйте да обясните как работят във вашия CONTRIBUTING файл.
 
 <aside markdown="1" class="pquote">
   <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://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
-### Използвайте инструменти за автоматизиране на основните задачи по поддръжката
-
-Добрата новина за поддържането на популярен проект е, че други поддържащи вероятно са се сблъсквали с подобни проблеми и са създали решение за тях.
+### Използвайте инструменти за автоматизиране на основни задачи по поддръжката
 
-Има [различни налични инструменти](https://github.com/showcases/tools-for-open-source), които да помогнат за автоматизирането на някои аспекти на работата по поддръжката. Няколко примера:
+Добрата новина за поддържането на популярен проект е, че други поддържащи вероятно са се сблъсквали с подобни проблеми и са създали решение за него.
 
-* [semantic-release](https://github.com/semantic-release/semantic-release) автоматизира вашите издания
-* [mention-bot](https://github.com/facebook/mention-bot) споменава потенциални рецензенти за заявки за изтегляне
-* [Danger](https://github.com/danger/danger) помага за автоматизирането на прегледа на кода
-* [no-response](https://github.com/probot/no-response) затваря въпроси, при които авторът не е отговорил на искане за повече информация
-* [dependabot](https://github.com/dependabot) проверява вашите файлове за зависимости всеки ден за остарели изисквания и отваря индивидуални заявки за изтегляне за всяко, което открие
+Има [различни налични инструменти](https://github.com/showcases/tools-for-open-source) за подпомагане на автоматизирането на някои аспекти на работата по поддръжката. Няколко примера:
 
-За доклади за грешки и други общи приноси GitHub има [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), които можете да създадете, за да рационализирате комуникацията, която получавате. @TalAter създаде [Изберете свое собствено ръководство за приключение](https://www.talater.com/open-source-templates/#/) за да ви помогне да напишете вашия проблем и PR шаблони.
+* [semantic-release](https://github.com/semantic-release/semantic-release) автоматизирайте вашите версии
+* [mention-bot](https://github.com/facebook/mention-bot) споменете възможни рецензенти за заявки за рул
+* [Danger](https://github.com/danger/danger) помага за автоматизиране на прегледа на кода
 
-За да управлявате вашите имейл известия, можете да настроите [имейл филтри](https://github.com/blog/2203-email-updates-about-your-own-activity), за да организирате по приоритет.
+За доклади за грешки и други общи приноси GitHub има [Шаблони за проблеми и заявки за изтегляне](https://github.com/blog/2111-issue-and-pull-request-templates), които можете да създадете, за да рационализирате комуникацията, която получавате. Можете също да конфигурирате [имейл филтри](https://github.com/blog/2203-email-updates-about-your-own-activity)за управление на вашите имейл известия.
 
-Ако искате да станете малко по-напреднали, ръководствата за стилове и линтерите могат да стандартизират приноса на проекти и да ги направят по-лесни за преглед и приемане.
+Ако искате да станете малко по-напреднали, ръководствата за стил могат да стандартизират приноса към проекта и да ги направят по-лесни за преглед и приемане.
 
-Въпреки това, ако вашите стандарти са твърде сложни, те могат да увеличат бариерите пред приноса. Уверете се, че добавяте достатъчно правила, за да улесните живота на всички.
+Въпреки това, ако вашите стандарти са твърде сложни, те могат да увеличат бариерите пред приноса. Уверете се, че добавяте само правила, за да улесните живота на всички.
 
-Ако не сте сигурни кои инструменти да използвате, вижте какво правят други популярни проекти, особено тези във вашата екосистема. Например, как изглежда процесът на принос за други модули на Node? Използването на подобни инструменти и подходи също така ще направи вашия процес по-познат на вашите сътрудници.
+Ако не сте сигурни какво инструменти, които да използвате, вижте какво правят други популярни проекти, особено тези във вашата екосистема. Например какво Как изглежда процесът на принос за други модули на Node? Използването на подобни инструменти и подходи също ще улесни. Направете своя процес по-познат на вашите целеви сътрудници.
 
-## Добре е да натиснете пауза
+## То е добре пауза
 
-Работата с отворен код някога ви е носила радост. Може би сега започва да ви кара да се чувствате отбягващи или виновни.
+Работата с отворен код някога ви е носила радост. Може би сега е така започват да ви карат да се чувствате отбягващи или виновни.
 
-Може би се чувствате претоварени или нарастващо чувство на страх, когато мислите за вашите проекти. И междувременно проблемите и заявките за изтегляне се натрупват.
+Може би се чувствате претоварени или нарастващо чувство на страх, когато мислите за вашите проекти. И междувременно се натрупват проблеми и заявки за изтегляне.
 
-Измореностa е реален и широко разпространен проблем в работата с отворен код, особено сред поддържащите. Като поддържащ, вашето щастие е неподлежащо на обсъждане изискване за оцеляването на всеки проект с отворен код.
+Прегарянето е реален и всеобхватен проблем в работата с отворен код, особено сред поддържащите. Като поддържащ, вашето щастие е неподлежащо на обсъждане изискване за оцеляването на всеки проект с отворен код.
 
-Въпреки че трябва да се разбира от само себе си, вземете си почивка! Не трябва да чакате, като се почувствате изморени, за да си вземете ваканция. @brettcannon, разработчик на ядрото на Python, реши да си вземе [едномесечна ваканция](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) след 14 години доброволен OSS работа.
+Въпреки че трябва да се разбира от само себе си, вземете си почивка! Не трябва да чакате, докато се почувствате изморени, за да си вземете почивка. @brettcannon, разработчик на Python, реши да вземете [едномесечна ваканция](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering) след 14 години OSS доброволчество.
 
-Точно както всеки друг вид работа, правенето на редовни почивки ще ви държи освежени, щастливи и развълнувани от работата ви.
+Като всеки друг вид работа, редовните почивки ще ви поддържат мотивирани. свежи, щастливи и развълнувани от работата си.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
-  При поддържането на WP-CLI открих, че първо трябва да направя себе си щастлив и да поставя ясни граници на моето участие. Най-добрият баланс, който открих, е 2-5 часа седмично като част от нормалния ми работен график. Това поддържа участието ми като страст и не го усещам като работа. Тъй като приоритизирам проблемите, по които работя, мога редовно да напредвам в това, което смятам за най-важно.
+  Докато поддържах WP-CLI, открих Че първо трябва да се тревожа за щастието си и да поставя ясни граници на моето участие. Най-добрият баланс, който съм намерил, е 2-5 часа седмично, като част от нормалния ми работен график. Това предпазва моето участие като страст и не ме чувства твърде много като работа. Тъй като приоритизирам проблемите, по които работя, мога редовно да напредвам в това, което смятам за най-важно.
   <p markdown="1" class="pquote-credit">
 — @danielbachhuber, ["Моите съболезнования, сега сте поддържащият популярен проект с отворен код"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
   </p>
 </aside>
 
-Понякога може да е трудно да си вземете почивка от работата с отворен код, когато чувствате, че всички се нуждаят от вас. Хората може дори да се опитат да ви накарат да се чувствате виновни, че сте се отдръпнали.
+Понякога може да е трудно да си вземете почивка от работата с отворен код, когато чувствате, че целият свят има нужда от вас. Хората може дори да се опитат да ви накарат да се чувствате виновни, че сте се отдалечили.
 
-Направете всичко възможно, за да намерите поддръжка за вашите потребители и общност, докато сте далеч от даден проект. Ако не можете да намерите подкрепата, от която се нуждаете, все пак си направете почивка. Не забравяйте да общувате, когато не сте на разположение, така че хората да не бъдат объркани от липсата ви на отзивчивост.
+Направете всичко възможно, за да намерите поддръжка за вашите потребители и общност, докато сте далеч от даден проект. Ако не можете да намерите подкрепата, от която се нуждаете, все пак си направете почивка. Не забравяйте да общувате, когато не сте на разположение, така че хората да не се чувстват объркани от липсата ви на отзивчивост.
 
-Правенето на почивки се отнася и за нещо повече от ваканции. Ако не искате да работите с отворен код през почивните дни или по време на работното време, съобщете тези очаквания на другите, за да знаят, че няма да ви притесняват.
+Правенето на почивки се отнася и за нещо повече от ваканции. Ако не искате да работите с отворен код през почивните дни или по време на работното време, съобщете тези решения на другите, за да знаят, че няма да ви притесняват.
 
 ## Погрижете се първо за себе си!
 
-Поддържането на популярен проект изисква различни умения от по-ранните етапи на растеж, но не е по-малко възнаграждаващо. Като поддържащ, вие ще практикувате лидерство и лични умения на ниво, което малко хора могат да изпитат. Въпреки че не винаги е лесно да се управлява, поставянето на ясни граници и поемането само на това, което ви харесва, ще ви помогне да останете щастливи, освежени и продуктивни.
+Поддържането на популярен проект изисква различни умения от ранните етапи на растеж, но е не по-малко възнаграждаващо. Като поддържащ, вие ще практикувате лидерски умения и умения за хора на ниво, което малко хора могат да изпитат. Въпреки че не винаги е лесно да се управлява, поставянето на ясни граници и вземането само на това, което ви кара да се чувствате комфортно, ще ви помогне. за да сте щастливи, актуализирани и продуктивни.
diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index 9bc2bb4e304..f6caf5cfeb4 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -1,7 +1,7 @@
 ---
 lang: bg
 title: Изграждане на приветливи общности
-description: Изграждане на общност, която насърчава хората да използват, допринасят и евангелизират вашия проект.
+description: Изграждане на общност, която насърчава хората да използват, допринасят и образоват с вашия проект
 class: building
 order: 4
 image: /assets/images/cards/building.png
@@ -26,16 +26,16 @@ related:
 
 Започнете с вашата документация:
 
-* **Улеснете го за тези, които трябва да използват проекта.** [Приятелски README документ](../starting-a-project/#писане-нa-readme) aи ясни примери за кодове ще улеснят всеки, който попадне на вашия проект, да започне.
-* **Обяснете ясно как да допринесат**, използвайки [вашият CONTRIBUTING архив](../starting-a-project/#писане-на-допринасящите-насоки) и поддържане на вашите проблеми актуални.
+* **Направете го лесен за тези, които трябва да използват проекта.** [Приятелски документ README](../starting-a-project/#writing-a-readme) и ясни примери за код ще улеснят използването му .Това е лесно начало за всеки, който попадне на вашия проект.
+* **Ясно обяснете как да допринесете**, като използвате [файл за CONTRIBUTING](../starting-a-project/#writing-the-contributing-guidelines) и поддържате проблемите си актуални.
 * **Добри първи издания**: За да помогнете на новите сътрудници да започнат, мислете ясно за [подчертаване на теми, които са достатъчно прости, за да се справи начинаещият](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки полезните приноси и намалявайки напрежението от потребителите, които се справят с проблеми, които са твърде трудни за тяхното ниво.
 
 [Проучване на GitHub за отворен код от 2017 г](http://opensourcesurvey.org/2017/) показа, че непълната или объркваща документация е най-големият проблем за потребителите с отворен код. Добрата документация приканва хората да взаимодействат с вашия проект. В крайна сметка някой ще отвори проблем или заявка. Използвайте тези взаимодействия като възможности да ги преместите надолу по фунията.
 
 * **Когато някой нов се присъедини към вашия проект, благодарете му за проявения интерес!** Необходим е само един негативен опит, за да накара някой да не иска да се върне.
 * **Бъдете отзивчиви.** Ако не отговорите на въпроса им в продължение на един месец, има вероятност те вече да са забравили за вашия проект.
-* **Бъдете непредубедени относно видовете вноски, които ще приемете.** Много сътрудници започват с доклад за грешка или малка корекция. Има [много начини да допринесете](../how-to-contribute/#какво-означава-да-допринесеш) за даден проект. Нека хората помагат по начина, по който искат.
-* **Ако има принос, с който не сте съгласни,** thank them for their idea and [обясни защо](../best-practices/#научаи-се-да-казваш-не) не се вписва в обхвата на проекта, като се позовавате на съответната документация, ако я имате.
+* **Бъдете непредубедени относно видовете приноси, които ще приемете.** Много сътрудници започват с докладване на грешка или извършване на малка корекция. Има [много начини да допринесете](../how-to-contribute/#what-it-means-to-contribute) към проект. Позволете на хората да помагат по начина, по който искат да помогнат.
+* **Ако има принос, с който не сте съгласни,** им благодарете за тяхната идея и [обяснете защо](../best-practices/#learning-to-say-no ) не отговаря на обхвата на проекта , с връзка към съответната документация, ако я имате.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -123,7 +123,7 @@ related:
 
 Редовните дискусии за тривиални аспекти на вашия проект разсейват другите, включително вас, от фокусирането върху важни задачи. Нови хора, които пристигат във вашия проект, може да видят тези разговори и да не искат да участват.
 
-Когато видите, че във вашия проект се случва негативно поведение, извикайте го публично. Обяснете, с любезен, но твърд тон, защо поведението им не е приемливо. Ако проблемът продължава, може да се наложи [да ги помолите да напуснат](../code-of-conduct/#прилагане-на-вашия-кодекс-на-поведение). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
+Когато видите, че се появява негативно поведение, направете публично наблюдение за него. Обяснете с приятелски тон защо Такова поведение не е приемливо. Ако проблемът продължава, може да се наложи [да го помолите да напусне](../code-of-conduct/#вашия-кодекс-на-поведение). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
 
 ### Запознайте се с сътрудниците там, където са
 
@@ -193,7 +193,7 @@ related:
 
 Когато вашата общност се бори с труден проблем, настроението може да се надигне. Хората може да се ядосат или разочароват и да си го изкарат един на друг или на вас.
 
-Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#недей-толерирай-лоши-актьори), за да поддържате дискусията цивилизована и продуктивна.
+Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#не-толерирай-лоши-актьори), за да поддържате дискусията цивилизована и продуктивна.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">

From 2ae967c6a31ffbe4d92370e73e3d588a20e7834c Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Tue, 16 Apr 2024 10:28:31 +0200
Subject: [PATCH 671/749] I tried again to fix the links

---
 _articles/bg/best-practices.md            |  2 +-
 _articles/bg/building-community.md        | 12 ++++++------
 _articles/bg/how-to-contribute.md         |  2 +-
 _articles/bg/leadership-and-governance.md |  4 ++--
 _articles/bg/legal.md                     | 10 +++++-----
 5 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md
index 4bc0c86aa34..6073ec247e4 100644
--- a/_articles/bg/best-practices.md
+++ b/_articles/bg/best-practices.md
@@ -148,7 +148,7 @@ related:
   </p>
 </aside>
 
-Понякога, когато кажете „не“, вашият потенциален сътрудник може да се ядоса или да критикува решението ви. Ако поведението ви стане враждебно, [вземете мерки за обезвреждане на ситуацията](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или дори ги отстранете от вашата общност, ако не желаят да си сътрудничат конструктивно.
+Понякога, когато кажете "не", вашият потенциален сътрудник може да се ядоса или да критикува решението ви. Ако поведението ви стане враждебно, [вземете мерки за обезвреждане на ситуацията](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или дори ги отстранете от вашата общност, ако не желаят да си сътрудничат конструктивно.
 
 ### Прегърнете наставничеството
 
diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index f6caf5cfeb4..010dcf040b2 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -26,16 +26,16 @@ related:
 
 Започнете с вашата документация:
 
-* **Направете го лесен за тези, които трябва да използват проекта.** [Приятелски документ README](../starting-a-project/#writing-a-readme) и ясни примери за код ще улеснят използването му .Това е лесно начало за всеки, който попадне на вашия проект.
-* **Ясно обяснете как да допринесете**, като използвате [файл за CONTRIBUTING](../starting-a-project/#writing-the-contributing-guidelines) и поддържате проблемите си актуални.
+* **Направете го лесен за тези, които трябва да използват проекта.** [Приятелски документ README](../starting-a-project/#Писане-на-README) и ясни примери за код ще улеснят използването му .Това е лесно начало за всеки, който попадне на вашия проект.
+* **Ясно обяснете как да допринесете**, като използвате [файл за CONTRIBUTING](../starting-a-project/#Писане-на-вашите-указания-за-принос) и поддържате проблемите си актуални.
 * **Добри първи издания**: За да помогнете на новите сътрудници да започнат, мислете ясно за [подчертаване на теми, които са достатъчно прости, за да се справи начинаещият](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки полезните приноси и намалявайки напрежението от потребителите, които се справят с проблеми, които са твърде трудни за тяхното ниво.
 
 [Проучване на GitHub за отворен код от 2017 г](http://opensourcesurvey.org/2017/) показа, че непълната или объркваща документация е най-големият проблем за потребителите с отворен код. Добрата документация приканва хората да взаимодействат с вашия проект. В крайна сметка някой ще отвори проблем или заявка. Използвайте тези взаимодействия като възможности да ги преместите надолу по фунията.
 
 * **Когато някой нов се присъедини към вашия проект, благодарете му за проявения интерес!** Необходим е само един негативен опит, за да накара някой да не иска да се върне.
 * **Бъдете отзивчиви.** Ако не отговорите на въпроса им в продължение на един месец, има вероятност те вече да са забравили за вашия проект.
-* **Бъдете непредубедени относно видовете приноси, които ще приемете.** Много сътрудници започват с докладване на грешка или извършване на малка корекция. Има [много начини да допринесете](../how-to-contribute/#what-it-means-to-contribute) към проект. Позволете на хората да помагат по начина, по който искат да помогнат.
-* **Ако има принос, с който не сте съгласни,** им благодарете за тяхната идея и [обяснете защо](../best-practices/#learning-to-say-no ) не отговаря на обхвата на проекта , с връзка към съответната документация, ако я имате.
+* **Бъдете непредубедени относно видовете приноси, които ще приемете.** Много сътрудници започват с докладване на грешка или извършване на малка корекция. Има [много начини да допринесете](../how-to-contribute/#Какво-означава-да-допринасяш) към проект. Позволете на хората да помагат по начина, по който искат да помогнат.
+* **Ако има принос, с който не сте съгласни,** им благодарете за тяхната идея и [обяснете защо](../best-practices/#Научете-се-да-казвате-не) не отговаря на обхвата на проекта , с връзка към съответната документация, ако я имате.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -123,7 +123,7 @@ related:
 
 Редовните дискусии за тривиални аспекти на вашия проект разсейват другите, включително вас, от фокусирането върху важни задачи. Нови хора, които пристигат във вашия проект, може да видят тези разговори и да не искат да участват.
 
-Когато видите, че се появява негативно поведение, направете публично наблюдение за него. Обяснете с приятелски тон защо Такова поведение не е приемливо. Ако проблемът продължава, може да се наложи [да го помолите да напусне](../code-of-conduct/#вашия-кодекс-на-поведение). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
+Когато видите, че се появява негативно поведение, направете публично наблюдение за него. Обяснете с приятелски тон защо Такова поведение не е приемливо. Ако проблемът продължава, може да се наложи [да го помолите да напусне](../code-of-conduct/#Налагане-на-вашия-кодекс-на-поведение). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
 
 ### Запознайте се с сътрудниците там, където са
 
@@ -193,7 +193,7 @@ related:
 
 Когато вашата общност се бори с труден проблем, настроението може да се надигне. Хората може да се ядосат или разочароват и да си го изкарат един на друг или на вас.
 
-Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#не-толерирай-лоши-актьори), за да поддържате дискусията цивилизована и продуктивна.
+Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#Не-толерирайте-лоши-актьори), за да поддържате дискусията цивилизована и продуктивна.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/bg/how-to-contribute.md b/_articles/bg/how-to-contribute.md
index 1952f1ceb27..904a4e225f1 100644
--- a/_articles/bg/how-to-contribute.md
+++ b/_articles/bg/how-to-contribute.md
@@ -10,7 +10,7 @@ related:
   - building
 ---
 
-## Why contribute to open source?
+## Защо да допринасяте за отворен код?
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
index e899d2926ab..996dfa74dcd 100644
--- a/_articles/bg/leadership-and-governance.md
+++ b/_articles/bg/leadership-and-governance.md
@@ -40,7 +40,7 @@ related:
 
 **Терминът "извършител"** може да се използва за разграничаване на достъпа за ангажиране, който е специфичен тип отговорност, от други форми на принос.
 
-Въпреки че можете да дефинирате ролите си в проекта както желаете, [помислете дали да не използвате по-широки дефиниции](../how-to-contribute/#какво-значи-да-допринесеш), за да насърчите повече форми на принос. Можете да използвате лидерски роли, за да признаете официално хора, които са направили изключителен принос към вашия проект, независимо от техните технически умения.
+Въпреки че можете да дефинирате ролите си в проекта както желаете, [помислете дали да не използвате по-широки дефиниции](../how-to-contribute/#Какво-означава-да-допринасяш), за да насърчите повече форми на принос. Можете да използвате лидерски роли, за да признаете официално хора, които са направили изключителен принос към вашия проект, независимо от техните технически умения.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
@@ -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://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community/#Споделете-собствеността-върху-вашия-проект).
 
 ## Кога трябва да дам на някого достъп за ангажиране?
 
diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
index 677efad3fcf..43ba6dacb2b 100644
--- a/_articles/bg/legal.md
+++ b/_articles/bg/legal.md
@@ -70,7 +70,7 @@ related:
 * **Искате ли вашият проект да се хареса на големия бизнес?** Големият бизнес може да се утеши от изричен патентен лиценз от всички сътрудници. В този случай [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) покрива вас (и тях).
 * **Искате ли вашият проект да се хареса на сътрудници, които не искат техният принос да се използва в софтуер със затворен код?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) или (ако те също не желаят да допринасят за услуги със затворен код) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) ще мине добре.
 
-Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник (вижте по-долу), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#какво-трябва-да-знае-юридическият-екип-на-моята-компания) за насоки.
+Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник (вижте по-долу), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#Какво-трябва-да-знае-юридическият-екип-на-моята-компания) за насоки.
 
 Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на един от лицензите, споменати по-горе, ще направи вашия проект GitHub с отворен код. Ако искате да видите други опции, вижте [choosealicense.com](https://choosealicense.com), за да намерите правилния лиценз за вашия проект, дори ако [не е софтуер](https://choosealicense.com/non-software/).
 
@@ -86,7 +86,7 @@ related:
 
 **Съществуващи носители на авторски права на вашия проект.** Ако вие сте единственият сътрудник на вашия проект, тогава вие или вашата компания сте единственият носител на авторските права на проекта. Можете да добавите или промените какъвто лиценз вие или вашата компания искате. В противен случай може да има други притежатели на авторски права, от които се нуждаете от съгласие, за да промените лицензите. Кои са те? [Хората, които имат ангажименти във вашия проект](https://github.com/thehale/git-authorship) е добро място да започнете. Но в някои случаи авторските права ще се държат от работодателите на тези хора. В някои случаи хората ще са направили само минимален принос, но няма твърдо и бързо правило, че приносите под определен брой редове код не са обект на авторско право. Какво да правя? Зависи. За сравнително малък и млад проект може да е възможно да накарате всички съществуващи сътрудници да се съгласят с промяна на лиценза в проблем или заявка за изтегляне. За големи и дълготрайни проекти може да се наложи да потърсите много сътрудници и дори техните наследници. Mozilla отне години (2001-2006), за да прелицензира Firefox, Thunderbird и свързания софтуер.
 
-Като алтернатива можете да накарате сътрудниците предварително да одобрят определени промени в лиценза чрез споразумение за допълнителен сътрудник ([вижте по-долу](#which-open-source-license-is-appropriate-for-my-project)). Това измества малко сложността на промяната на лицензите. Ще имате нужда от повече помощ от вашите адвокати предварително и все пак ще искате да комуникирате ясно със заинтересованите страни във вашия проект, когато извършвате промяна на лиценза.
+Като алтернатива можете да накарате сътрудниците предварително да одобрят определени промени в лиценза чрез споразумение за допълнителен сътрудник ([вижте по-долу](#Кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)). Това измества малко сложността на промяната на лицензите. Ще имате нужда от повече помощ от вашите адвокати предварително и все пак ще искате да комуникирате ясно със заинтересованите страни във вашия проект, когато извършвате промяна на лиценза.
 
 ## Моят проект има ли нужда от споразумение за допълнителен сътрудник?
 
@@ -122,13 +122,13 @@ related:
 
 **Ако търсите проект с отворен код за вашата компания**, тогава определено ги уведомете. Вашият правен екип вероятно вече има политики за това какъв лиценз с отворен код (и може би допълнително споразумение за сътрудници) да използва въз основа на бизнес изискванията и експертния опит на компанията за гарантиране, че вашият проект е в съответствие с лицензите на неговите зависимости. Ако не, вие и те имате късмет! Вашият правен екип трябва да е нетърпелив да работи с вас, за да разберете тези неща. Някои неща, за които да помислите:
 
-* **Материал на трета страна:** Вашият проект има ли зависимости, създадени от други или по друг начин включва или използва чужд код? Ако те са с отворен код, ще трябва да спазвате лицензите за отворен код на материалите. Това започва с избора на лиценз, който работи с лицензи с отворен код на трети страни ([вижте по-горе](#which-open-source-license-is-appropriate-for-my-project)). Ако вашият проект модифицира или разпространява материал с отворен код на трета страна, вашият правен екип също ще иска да знае, че отговаряте на други условия на лицензите за отворен код на трета страна, като запазване на бележки за авторски права. Ако вашият проект използва чужд код, който няма лиценз с отворен код, вероятно ще трябва да помолите поддържащите трети страни да [добавят лиценз с отворен код](https://choosealicense.com/no-license/#for-users), и ако не можете да получите такъв, спрете да използвате техния код във вашия проект.
+* **Материал на трета страна:** Вашият проект има ли зависимости, създадени от други или по друг начин включва или използва чужд код? Ако те са с отворен код, ще трябва да спазвате лицензите за отворен код на материалите. Това започва с избора на лиценз, който работи с лицензи с отворен код на трети страни ([вижте по-горе](#Кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)). Ако вашият проект модифицира или разпространява материал с отворен код на трета страна, вашият правен екип също ще иска да знае, че отговаряте на други условия на лицензите за отворен код на трета страна, като запазване на бележки за авторски права. Ако вашият проект използва чужд код, който няма лиценз с отворен код, вероятно ще трябва да помолите поддържащите трети страни да [добавят лиценз с отворен код](https://choosealicense.com/no-license/#for-users), и ако не можете да получите такъв, спрете да използвате техния код във вашия проект.
 
 * **Търговски тайни:** Помислете дали има нещо в проекта, което компанията не иска да направи достъпно за широката общественост. Ако е така, можете да отворите останалата част от проекта си, след като извлечете материала, който искате да запазите поверителен.
 
 * **Патенти:** Вашата компания кандидатства ли за патент, за който отвореният код на вашия проект би представлявал [публично разкриване](https://en.wikipedia.org/wiki/Public_disclosure)? За съжаление може да бъдете помолени да изчакате (или може би компанията ще преразгледа разумността на приложението). Ако очаквате принос към вашия проект от служители на компании с големи патентни портфейли, вашият правен екип може да поиска да използвате лиценз с изрично предоставяне на патент от сътрудници (като Apache 2.0 или GPLv3) или допълнително споразумение за сътрудници ([вижте по-горе](#which-open-source-license-is-appropriate-for-my-project)).
 
-* **Търговски марки:** Проверете отново дали името на вашия проект [не е в конфликт със съществуващи търговски марки](../starting-a-project/#избягване-на-конфликти-с-имена). Ако използвате търговските марки на собствената си компания в проекта, проверете дали това не предизвиква конфликти. [FOSSmarks](http://fossmarks.org/) е практическо ръководство за разбиране на търговските марки в контекста на безплатни проекти с отворен код.
+* **Търговски марки:** Проверете отново дали името на вашия проект [не е в конфликт със съществуващи търговски марки](../starting-a-project/#Избягване-на-конфликти-с-имена). Ако използвате търговските марки на собствената си компания в проекта, проверете дали това не предизвиква конфликти. [FOSSmarks](http://fossmarks.org/) е практическо ръководство за разбиране на търговските марки в контекста на безплатни проекти с отворен код.
 
 * **Поверителност:** Вашият проект събира ли данни за потребители? "Домашен телефон" към фирмени сървъри? Вашият правен екип може да ви помогне да спазвате фирмените политики и външните разпоредби.
 
@@ -157,4 +157,4 @@ related:
 </aside>
 
 * **Патенти:** Вашата компания може да пожелае да се присъедини към [Open Invention Network](https://www.openinventionnetwork.com/), споделен защитен патентен пул за защита на използването на големи проекти с отворен код от членовете, или да проучи друго [алтернативно патентно лицензиране](https://www.eff.org/document/hacking-patent-system-2016).
-* **Управление:** Особено ако и когато има смисъл да се премести проект към [юридическо лице извън компанията](../leadership-and-governance/#имам-нужда-от-юридическо-лице-което-да-подкрепи-моя-проект).
+* **Управление:** Особено ако и когато има смисъл да се премести проект към [юридическо лице извън компанията](../leadership-and-governance/#Нуждая-ли-се-от-юридическо-лице-което-да-поддържа-моя-проект).

From aa0cb0b3292165e29049c094722cce8c7fe1ac0e Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Tue, 16 Apr 2024 10:51:13 +0200
Subject: [PATCH 672/749] change again link in folder bg

---
 _articles/bg/best-practices.md     |  2 +-
 _articles/bg/legal.md              | 14 +++++++-------
 _articles/bg/starting-a-project.md |  2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md
index 6073ec247e4..c94d9ef9a36 100644
--- a/_articles/bg/best-practices.md
+++ b/_articles/bg/best-practices.md
@@ -166,7 +166,7 @@ related:
 
 Когато видите нови сътрудници да правят повторни приноси, трябва да признаете работата им, като им предложите повече отговорности. Документирайте как другите могат да постигнат лидерски роли, ако желаят.
 
-Насърчаването на други да [споделят собствеността върху проекта](../building-community/#share-ownership-of-your-project) може значително да намали работното ви натоварване, както установи @lmccart във вашия проект, [p5.js](https://github.com/processing/p5.js).
+Насърчаването на други да [споделят собствеността върху проекта](../building-community/#споделете-собствеността-върху-вашия-проект) може значително да намали работното ви натоварване, както установи @lmccart във вашия проект, [p5.js](https://github.com/processing/p5.js).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
index 43ba6dacb2b..d4774ae810c 100644
--- a/_articles/bg/legal.md
+++ b/_articles/bg/legal.md
@@ -36,7 +36,7 @@ related:
 
 Ако искате други да използват, разпространяват, модифицират или допринасят обратно към вашия проект, трябва да включите лиценз с отворен код. Например, някой не може законно да използва която и да е част от вашия GitHub проект в своя код, дори ако е публичен, освен ако изрично не му дадете правото да го направи.
 
-## Просто ми дайте TL;DR за това, от което се нуждая, за да защитя проекта си.
+## Просто ми дайте обобщение за това, от което се нуждая, за да защитя проекта си.
 
 Имате късмет, защото днес лицензите за отворен код са стандартизирани и лесни за използване. Можете да копирате и поставите съществуващ лиценз директно във вашия проект.
 
@@ -70,7 +70,7 @@ related:
 * **Искате ли вашият проект да се хареса на големия бизнес?** Големият бизнес може да се утеши от изричен патентен лиценз от всички сътрудници. В този случай [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) покрива вас (и тях).
 * **Искате ли вашият проект да се хареса на сътрудници, които не искат техният принос да се използва в софтуер със затворен код?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) или (ако те също не желаят да допринасят за услуги със затворен код) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) ще мине добре.
 
-Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник (вижте по-долу), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#Какво-трябва-да-знае-юридическият-екип-на-моята-компания) за насоки.
+Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник (вижте по-долу), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#какво-трябва-да-знае-юридическият-екип-на-моята-компания) за насоки.
 
 Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на един от лицензите, споменати по-горе, ще направи вашия проект GitHub с отворен код. Ако искате да видите други опции, вижте [choosealicense.com](https://choosealicense.com), за да намерите правилния лиценз за вашия проект, дори ако [не е софтуер](https://choosealicense.com/non-software/).
 
@@ -86,7 +86,7 @@ related:
 
 **Съществуващи носители на авторски права на вашия проект.** Ако вие сте единственият сътрудник на вашия проект, тогава вие или вашата компания сте единственият носител на авторските права на проекта. Можете да добавите или промените какъвто лиценз вие или вашата компания искате. В противен случай може да има други притежатели на авторски права, от които се нуждаете от съгласие, за да промените лицензите. Кои са те? [Хората, които имат ангажименти във вашия проект](https://github.com/thehale/git-authorship) е добро място да започнете. Но в някои случаи авторските права ще се държат от работодателите на тези хора. В някои случаи хората ще са направили само минимален принос, но няма твърдо и бързо правило, че приносите под определен брой редове код не са обект на авторско право. Какво да правя? Зависи. За сравнително малък и млад проект може да е възможно да накарате всички съществуващи сътрудници да се съгласят с промяна на лиценза в проблем или заявка за изтегляне. За големи и дълготрайни проекти може да се наложи да потърсите много сътрудници и дори техните наследници. Mozilla отне години (2001-2006), за да прелицензира Firefox, Thunderbird и свързания софтуер.
 
-Като алтернатива можете да накарате сътрудниците предварително да одобрят определени промени в лиценза чрез споразумение за допълнителен сътрудник ([вижте по-долу](#Кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)). Това измества малко сложността на промяната на лицензите. Ще имате нужда от повече помощ от вашите адвокати предварително и все пак ще искате да комуникирате ясно със заинтересованите страни във вашия проект, когато извършвате промяна на лиценза.
+Като алтернатива можете да накарате сътрудниците предварително да одобрят определени промени в лиценза чрез споразумение за допълнителен сътрудник ([вижте по-долу](#кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)). Това измества малко сложността на промяната на лицензите. Ще имате нужда от повече помощ от вашите адвокати предварително и все пак ще искате да комуникирате ясно със заинтересованите страни във вашия проект, когато извършвате промяна на лиценза.
 
 ## Моят проект има ли нужда от споразумение за допълнителен сътрудник?
 
@@ -122,13 +122,13 @@ related:
 
 **Ако търсите проект с отворен код за вашата компания**, тогава определено ги уведомете. Вашият правен екип вероятно вече има политики за това какъв лиценз с отворен код (и може би допълнително споразумение за сътрудници) да използва въз основа на бизнес изискванията и експертния опит на компанията за гарантиране, че вашият проект е в съответствие с лицензите на неговите зависимости. Ако не, вие и те имате късмет! Вашият правен екип трябва да е нетърпелив да работи с вас, за да разберете тези неща. Някои неща, за които да помислите:
 
-* **Материал на трета страна:** Вашият проект има ли зависимости, създадени от други или по друг начин включва или използва чужд код? Ако те са с отворен код, ще трябва да спазвате лицензите за отворен код на материалите. Това започва с избора на лиценз, който работи с лицензи с отворен код на трети страни ([вижте по-горе](#Кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)). Ако вашият проект модифицира или разпространява материал с отворен код на трета страна, вашият правен екип също ще иска да знае, че отговаряте на други условия на лицензите за отворен код на трета страна, като запазване на бележки за авторски права. Ако вашият проект използва чужд код, който няма лиценз с отворен код, вероятно ще трябва да помолите поддържащите трети страни да [добавят лиценз с отворен код](https://choosealicense.com/no-license/#for-users), и ако не можете да получите такъв, спрете да използвате техния код във вашия проект.
+* **Материал на трета страна:** Вашият проект има ли зависимости, създадени от други или по друг начин включва или използва чужд код? Ако те са с отворен код, ще трябва да спазвате лицензите за отворен код на материалите. Това започва с избора на лиценз, който работи с лицензи с отворен код на трети страни ([вижте по-горе](#кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)). Ако вашият проект модифицира или разпространява материал с отворен код на трета страна, вашият правен екип също ще иска да знае, че отговаряте на други условия на лицензите за отворен код на трета страна, като запазване на бележки за авторски права. Ако вашият проект използва чужд код, който няма лиценз с отворен код, вероятно ще трябва да помолите поддържащите трети страни да [добавят лиценз с отворен код](https://choosealicense.com/no-license/#for-users), и ако не можете да получите такъв, спрете да използвате техния код във вашия проект.
 
 * **Търговски тайни:** Помислете дали има нещо в проекта, което компанията не иска да направи достъпно за широката общественост. Ако е така, можете да отворите останалата част от проекта си, след като извлечете материала, който искате да запазите поверителен.
 
-* **Патенти:** Вашата компания кандидатства ли за патент, за който отвореният код на вашия проект би представлявал [публично разкриване](https://en.wikipedia.org/wiki/Public_disclosure)? За съжаление може да бъдете помолени да изчакате (или може би компанията ще преразгледа разумността на приложението). Ако очаквате принос към вашия проект от служители на компании с големи патентни портфейли, вашият правен екип може да поиска да използвате лиценз с изрично предоставяне на патент от сътрудници (като Apache 2.0 или GPLv3) или допълнително споразумение за сътрудници ([вижте по-горе](#which-open-source-license-is-appropriate-for-my-project)).
+* **Патенти:** Вашата компания кандидатства ли за патент, за който отвореният код на вашия проект би представлявал [публично разкриване](https://en.wikipedia.org/wiki/Public_disclosure)? За съжаление може да бъдете помолени да изчакате (или може би компанията ще преразгледа разумността на приложението). Ако очаквате принос към вашия проект от служители на компании с големи патентни портфейли, вашият правен екип може да поиска да използвате лиценз с изрично предоставяне на патент от сътрудници (като Apache 2.0 или GPLv3) или допълнително споразумение за сътрудници ([вижте по-горе](#кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)).
 
-* **Търговски марки:** Проверете отново дали името на вашия проект [не е в конфликт със съществуващи търговски марки](../starting-a-project/#Избягване-на-конфликти-с-имена). Ако използвате търговските марки на собствената си компания в проекта, проверете дали това не предизвиква конфликти. [FOSSmarks](http://fossmarks.org/) е практическо ръководство за разбиране на търговските марки в контекста на безплатни проекти с отворен код.
+* **Търговски марки:** Проверете отново дали името на вашия проект [не е в конфликт със съществуващи търговски марки](../starting-a-project/#избягване-на-конфликти-с-имена). Ако използвате търговските марки на собствената си компания в проекта, проверете дали това не предизвиква конфликти. [FOSSmarks](http://fossmarks.org/) е практическо ръководство за разбиране на търговските марки в контекста на безплатни проекти с отворен код.
 
 * **Поверителност:** Вашият проект събира ли данни за потребители? "Домашен телефон" към фирмени сървъри? Вашият правен екип може да ви помогне да спазвате фирмените политики и външните разпоредби.
 
@@ -157,4 +157,4 @@ related:
 </aside>
 
 * **Патенти:** Вашата компания може да пожелае да се присъедини към [Open Invention Network](https://www.openinventionnetwork.com/), споделен защитен патентен пул за защита на използването на големи проекти с отворен код от членовете, или да проучи друго [алтернативно патентно лицензиране](https://www.eff.org/document/hacking-patent-system-2016).
-* **Управление:** Особено ако и когато има смисъл да се премести проект към [юридическо лице извън компанията](../leadership-and-governance/#Нуждая-ли-се-от-юридическо-лице-което-да-поддържа-моя-проект).
+* **Управление:** Особено ако и когато има смисъл да се премести проект към [юридическо лице извън компанията](../leadership-and-governance/#нуждая-ли-се-от-юридическо-лице-което-да-поддържа-моя-проект).
diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index bc03ff7fa98..30bc8ad84b3 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -287,7 +287,7 @@ CONTRIBUTING файл казва на вашата публика как да у
   </label>
 </div>
 
-**Code**
+**Код**
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">

From 05f344b1e4a36d5302fd90139affe2eab9703438 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Tue, 16 Apr 2024 11:32:48 +0200
Subject: [PATCH 673/749] change agan links in the folder bg

---
 _articles/bg/building-community.md        | 16 ++++++++--------
 _articles/bg/leadership-and-governance.md |  4 ++--
 _articles/bg/legal.md                     |  2 +-
 _articles/bg/starting-a-project.md        |  6 +++---
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index 010dcf040b2..e7d14af227b 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -24,18 +24,18 @@ related:
 
 Докато изграждате общността си, помислете как някой на върха на фунията (потенциален потребител) може теоретично да си проправи път надолу (активен поддържащ). Вашата цел е да намалите триенето на всеки етап от опита на сътрудници. Когато хората имат лесни победи, те ще бъдат стимулирани да правят повече.
 
-Започнете с вашата документация:
+Започнете с вашата документация: 
 
-* **Направете го лесен за тези, които трябва да използват проекта.** [Приятелски документ README](../starting-a-project/#Писане-на-README) и ясни примери за код ще улеснят използването му .Това е лесно начало за всеки, който попадне на вашия проект.
-* **Ясно обяснете как да допринесете**, като използвате [файл за CONTRIBUTING](../starting-a-project/#Писане-на-вашите-указания-за-принос) и поддържате проблемите си актуални.
+* **Направете го лесен за тези, които трябва да използват проекта.** [Приятелски документ README](../starting-a-project/#напишете-README) и ясни примери за код ще улеснят използването му .Това е лесно начало за всеки, който попадне на вашия проект.
+* **Ясно обяснете как да допринесете**, като използвате [файл за CONTRIBUTING](../starting-a-project/#напишете-вашите-указания-за-принос) и поддържате проблемите си актуални.
 * **Добри първи издания**: За да помогнете на новите сътрудници да започнат, мислете ясно за [подчертаване на теми, които са достатъчно прости, за да се справи начинаещият](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки полезните приноси и намалявайки напрежението от потребителите, които се справят с проблеми, които са твърде трудни за тяхното ниво.
 
 [Проучване на GitHub за отворен код от 2017 г](http://opensourcesurvey.org/2017/) показа, че непълната или объркваща документация е най-големият проблем за потребителите с отворен код. Добрата документация приканва хората да взаимодействат с вашия проект. В крайна сметка някой ще отвори проблем или заявка. Използвайте тези взаимодействия като възможности да ги преместите надолу по фунията.
 
 * **Когато някой нов се присъедини към вашия проект, благодарете му за проявения интерес!** Необходим е само един негативен опит, за да накара някой да не иска да се върне.
 * **Бъдете отзивчиви.** Ако не отговорите на въпроса им в продължение на един месец, има вероятност те вече да са забравили за вашия проект.
-* **Бъдете непредубедени относно видовете приноси, които ще приемете.** Много сътрудници започват с докладване на грешка или извършване на малка корекция. Има [много начини да допринесете](../how-to-contribute/#Какво-означава-да-допринасяш) към проект. Позволете на хората да помагат по начина, по който искат да помогнат.
-* **Ако има принос, с който не сте съгласни,** им благодарете за тяхната идея и [обяснете защо](../best-practices/#Научете-се-да-казвате-не) не отговаря на обхвата на проекта , с връзка към съответната документация, ако я имате.
+* **Бъдете непредубедени относно видовете приноси, които ще приемете.** Много сътрудници започват с докладване на грешка или извършване на малка корекция. Има [много начини да допринесете](../how-to-contribute/#какво-означава-да-допринасяш) към проект. Позволете на хората да помагат по начина, по който искат да помогнат.
+* **Ако има принос, с който не сте съгласни,** им благодарете за тяхната идея и [обяснете защо](../best-practices/#научете-се-да-казвате-не) не отговаря на обхвата на проекта , с връзка към съответната документация, ако я имате.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -123,7 +123,7 @@ related:
 
 Редовните дискусии за тривиални аспекти на вашия проект разсейват другите, включително вас, от фокусирането върху важни задачи. Нови хора, които пристигат във вашия проект, може да видят тези разговори и да не искат да участват.
 
-Когато видите, че се появява негативно поведение, направете публично наблюдение за него. Обяснете с приятелски тон защо Такова поведение не е приемливо. Ако проблемът продължава, може да се наложи [да го помолите да напусне](../code-of-conduct/#Налагане-на-вашия-кодекс-на-поведение). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
+Когато видите, че се появява негативно поведение, направете публично наблюдение за него. Обяснете с приятелски тон защо Такова поведение не е приемливо. Ако проблемът продължава, може да се наложи [да го помолите да напусне](../code-of-conduct/#вашите-отговорности-като-поддържащ). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.
 
 ### Запознайте се с сътрудниците там, където са
 
@@ -193,7 +193,7 @@ related:
 
 Когато вашата общност се бори с труден проблем, настроението може да се надигне. Хората може да се ядосат или разочароват и да си го изкарат един на друг или на вас.
 
-Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#Не-толерирайте-лоши-актьори), за да поддържате дискусията цивилизована и продуктивна.
+Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#не-толерирайте-лоши-актьори), за да поддържате дискусията цивилизована и продуктивна.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
@@ -209,7 +209,7 @@ related:
 
 ### Отнасяйте се към вашия README като към конституция
 
-Вашият README е [повече от просто набор от инструкции](../starting-a-project/#писане-нa-readme). Това също е място да говорите за вашите цели, продуктова визия и пътна карта. Ако хората са прекалено съсредоточени върху обсъждането на достойнствата на определена функция, може да ви помогне да прегледате отново вашия README и да говорите за по-високата визия на вашия проект. Фокусирането върху вашия README също обезличава разговора, така че можете да водите конструктивна дискусия.
+Вашият README е [повече от просто набор от инструкции](../starting-a-project/#напишете-README). Това също е място да говорите за вашите цели, продуктова визия и пътна карта. Ако хората са прекалено съсредоточени върху обсъждането на достойнствата на определена функция, може да ви помогне да прегледате отново вашия README и да говорите за по-високата визия на вашия проект. Фокусирането върху вашия README също обезличава разговора, така че можете да водите конструктивна дискусия.
 
 ### Фокусирайте се върху пътуването, а не върху дестинацията
 
diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
index 996dfa74dcd..93d1e55d6ea 100644
--- a/_articles/bg/leadership-and-governance.md
+++ b/_articles/bg/leadership-and-governance.md
@@ -40,7 +40,7 @@ related:
 
 **Терминът "извършител"** може да се използва за разграничаване на достъпа за ангажиране, който е специфичен тип отговорност, от други форми на принос.
 
-Въпреки че можете да дефинирате ролите си в проекта както желаете, [помислете дали да не използвате по-широки дефиниции](../how-to-contribute/#Какво-означава-да-допринасяш), за да насърчите повече форми на принос. Можете да използвате лидерски роли, за да признаете официално хора, които са направили изключителен принос към вашия проект, независимо от техните технически умения.
+Въпреки че можете да дефинирате ролите си в проекта както желаете, [помислете дали да не използвате по-широки дефиниции](../how-to-contribute/#какво-означава-да-допринасяш), за да насърчите повече форми на принос. Можете да използвате лидерски роли, за да признаете официално хора, които са направили изключителен принос към вашия проект, независимо от техните технически умения.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
@@ -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://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community/#споделете-собствеността-върху-вашия-проект).
 
 ## Кога трябва да дам на някого достъп за ангажиране?
 
diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
index d4774ae810c..cc5b5f3aa3e 100644
--- a/_articles/bg/legal.md
+++ b/_articles/bg/legal.md
@@ -70,7 +70,7 @@ related:
 * **Искате ли вашият проект да се хареса на големия бизнес?** Големият бизнес може да се утеши от изричен патентен лиценз от всички сътрудници. В този случай [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) покрива вас (и тях).
 * **Искате ли вашият проект да се хареса на сътрудници, които не искат техният принос да се използва в софтуер със затворен код?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) или (ако те също не желаят да допринасят за услуги със затворен код) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) ще мине добре.
 
-Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник (вижте по-долу), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#какво-трябва-да-знае-юридическият-екип-на-моята-компания) за насоки.
+Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник (вижте по-долу), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#патенти) за насоки.
 
 Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на един от лицензите, споменати по-горе, ще направи вашия проект GitHub с отворен код. Ако искате да видите други опции, вижте [choosealicense.com](https://choosealicense.com), за да намерите правилния лиценз за вашия проект, дори ако [не е софтуер](https://choosealicense.com/non-software/).
 
diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index 30bc8ad84b3..65d01eada41 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -20,7 +20,7 @@ related:
 
 Отвореният код е мощен, защото намалява бариерите пред приемането и сътрудничеството, позволявайки на хората да разпространяват и подобряват проекти бързо. Също така защото дава на потребителите потенциал да контролират собствените си компютри, в сравнение със затворения код. Например, бизнес, използващ софтуер с отворен код, има опцията да наеме някой, който да направи персонализирани подобрения на софтуера, вместо да разчита изключително на продуктовите решения на доставчик със затворен код.
 
-_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#отворен-код-без-средства).
+_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#отворен-код-означава-ли-безплатно-).
 
 ### Защо хората отварят кода на работата си?
 
@@ -129,7 +129,7 @@ _Свободен софтуер_ се отнася до същия набор 
 
 Ако имате други въпроси или притеснения относно правните аспекти на управлението на проект с отворен код, [ние ще ви покрием](../legal/).
 
-### Писане на README
+### Напишете README
 
 README правят повече от това да обяснят как да използвате вашия проект. Те също така обясняват защо вашият проект има значение и какво могат да правят вашите потребители с него.
 
@@ -156,7 +156,7 @@ README правят повече от това да обяснят как да 
 
 Когато включите файл README в основната директория, GitHub автоматично ще го покаже на началната страница на хранилището.
 
-### Писане на вашите указания за принос
+### Напишете вашите указания за принос
 
 CONTRIBUTING файл казва на вашата публика как да участва във вашия проект. Например можете да включите информация за:
 

From ba0ccacb1e393def6f772e18914ac17e51529c98 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Tue, 16 Apr 2024 11:44:34 +0200
Subject: [PATCH 674/749] correct agan link in file starting-a-project.md and
 building-community.md according to the test errors

---
 _articles/bg/building-community.md | 4 ++--
 _articles/bg/legal.md              | 2 +-
 _articles/bg/starting-a-project.md | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index e7d14af227b..2d3ffd75b20 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -26,7 +26,7 @@ related:
 
 Започнете с вашата документация: 
 
-* **Направете го лесен за тези, които трябва да използват проекта.** [Приятелски документ README](../starting-a-project/#напишете-README) и ясни примери за код ще улеснят използването му .Това е лесно начало за всеки, който попадне на вашия проект.
+* **Направете го лесен за тези, които трябва да използват проекта.** [Приятелски документ README](../starting-a-project/#напишете-readme) и ясни примери за код ще улеснят използването му .Това е лесно начало за всеки, който попадне на вашия проект.
 * **Ясно обяснете как да допринесете**, като използвате [файл за CONTRIBUTING](../starting-a-project/#напишете-вашите-указания-за-принос) и поддържате проблемите си актуални.
 * **Добри първи издания**: За да помогнете на новите сътрудници да започнат, мислете ясно за [подчертаване на теми, които са достатъчно прости, за да се справи начинаещият](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки полезните приноси и намалявайки напрежението от потребителите, които се справят с проблеми, които са твърде трудни за тяхното ниво.
 
@@ -209,7 +209,7 @@ related:
 
 ### Отнасяйте се към вашия README като към конституция
 
-Вашият README е [повече от просто набор от инструкции](../starting-a-project/#напишете-README). Това също е място да говорите за вашите цели, продуктова визия и пътна карта. Ако хората са прекалено съсредоточени върху обсъждането на достойнствата на определена функция, може да ви помогне да прегледате отново вашия README и да говорите за по-високата визия на вашия проект. Фокусирането върху вашия README също обезличава разговора, така че можете да водите конструктивна дискусия.
+Вашият README е [повече от просто набор от инструкции](../starting-a-project/#напишете-readme). Това също е място да говорите за вашите цели, продуктова визия и пътна карта. Ако хората са прекалено съсредоточени върху обсъждането на достойнствата на определена функция, може да ви помогне да прегледате отново вашия README и да говорите за по-високата визия на вашия проект. Фокусирането върху вашия README също обезличава разговора, така че можете да водите конструктивна дискусия.
 
 ### Фокусирайте се върху пътуването, а не върху дестинацията
 
diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
index cc5b5f3aa3e..2e56c75652d 100644
--- a/_articles/bg/legal.md
+++ b/_articles/bg/legal.md
@@ -70,7 +70,7 @@ related:
 * **Искате ли вашият проект да се хареса на големия бизнес?** Големият бизнес може да се утеши от изричен патентен лиценз от всички сътрудници. В този случай [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) покрива вас (и тях).
 * **Искате ли вашият проект да се хареса на сътрудници, които не искат техният принос да се използва в софтуер със затворен код?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) или (ако те също не желаят да допринасят за услуги със затворен код) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) ще мине добре.
 
-Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник (вижте по-долу), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#патенти) за насоки.
+Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник (вижте по-долу), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#моят-проект-има-ли-нужда-от-споразумение-за-допълнителен-сътрудник) за насоки.
 
 Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на един от лицензите, споменати по-горе, ще направи вашия проект GitHub с отворен код. Ако искате да видите други опции, вижте [choosealicense.com](https://choosealicense.com), за да намерите правилния лиценз за вашия проект, дори ако [не е софтуер](https://choosealicense.com/non-software/).
 
diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index 65d01eada41..78b5be61f7b 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -20,7 +20,7 @@ related:
 
 Отвореният код е мощен, защото намалява бариерите пред приемането и сътрудничеството, позволявайки на хората да разпространяват и подобряват проекти бързо. Също така защото дава на потребителите потенциал да контролират собствените си компютри, в сравнение със затворения код. Например, бизнес, използващ софтуер с отворен код, има опцията да наеме някой, който да направи персонализирани подобрения на софтуера, вместо да разчита изключително на продуктовите решения на доставчик със затворен код.
 
-_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#отворен-код-означава-ли-безплатно-).
+_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#отворен-код-означава-ли-безплатно).
 
 ### Защо хората отварят кода на работата си?
 

From 7d2578b1ffbc579c430c3cf723cadfed79fc4dcc Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Mon, 29 Apr 2024 16:16:30 -0700
Subject: [PATCH 675/749] Remove version lock from html-proofer

There have been 2 major revs of HTML-Proofer since the one
we pinned. The current one is causing flaky tests - it's missing
clear errors w/internal links and only reports the first
error it finds rather than running to completion and reporting
all of them.

The latest version (5.0.8 at the moment) does catch all of the
errors but has a problem locally where UTF-8 encoded anchor links
are not properly decoded. This might be a problem local to me though;
I coded up a spec test in html-proofer with an exact copy-paste
of one of the failing links and ... it passes there.

So i'll unpin this and see if there's some local gem issue that's
causing this on my machine and maybe it works in the Actions env.
---
 Gemfile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile b/Gemfile
index a76c33fb51c..ca9b7428d0e 100644
--- a/Gemfile
+++ b/Gemfile
@@ -3,6 +3,6 @@ source "https://rubygems.org"
 gem "github-pages", group: :jekyll_plugins
 
 group :test do
-  gem "html-proofer", "~> 3.19.4"
+  gem "html-proofer"
   gem "rake"
 end

From 81f75fbdab9042d360c23f1d0b15bca2117394e9 Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Mon, 29 Apr 2024 18:09:00 -0700
Subject: [PATCH 676/749] Bump ruby-version to 3.2.x

---
 .ruby-version | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.ruby-version b/.ruby-version
index a603bb50a29..a3ec5a4bd3d 100644
--- a/.ruby-version
+++ b/.ruby-version
@@ -1 +1 @@
-2.7.5
+3.2

From 0c42faae08fce1bf0f2c566708a7c47c34c556ae Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Mon, 29 Apr 2024 18:32:42 -0700
Subject: [PATCH 677/749] Update html-proofer config stanza for new version

based on html-proofer's UPGRADING.md , many of the old configuration directives have changed names in the new version.
---
 script/html-proofer | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/script/html-proofer b/script/html-proofer
index 45a74b85e26..1e49fe96e94 100755
--- a/script/html-proofer
+++ b/script/html-proofer
@@ -20,12 +20,13 @@ HTMLProofer::Runner.new(
   ["_site"],
   parallel: { in_threads: 4 },
   type: :directory,
-  url_ignore: url_ignores,
+  ignore_urls: url_ignores,
   check_html: true,
   check_opengraph: true,
-  check_img_http: true,
   favicon: true,
   assume_extension: true,
+  allow_missing_href: true,
+  enforce_https: false,
   only_4xx: true,
-  http_status_ignore: [429]
+  ignore_status_codes: [429]
 ).run

From aadd4d1e93aa3b631a73ab614af3e6330a1a0144 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Tue, 30 Apr 2024 07:59:53 +0200
Subject: [PATCH 678/749] correction of incorrect link and and some
 untranslated sentences

---
 _articles/bg/how-to-contribute.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/_articles/bg/how-to-contribute.md b/_articles/bg/how-to-contribute.md
index 904a4e225f1..68d7cfbb6c9 100644
--- a/_articles/bg/how-to-contribute.md
+++ b/_articles/bg/how-to-contribute.md
@@ -138,7 +138,7 @@ related:
 
 Дори и да сте разработчик на софтуер, работата по проект за документация може да ви помогне да започнете работа с отворен код. Често е по-малко смущаващо да работите по проекти, които не включват код, а процесът на сътрудничество ще изгради вашата увереност и опит.
 
-## Orienting yourself to a new project
+## Ориентиране към нов проект
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
@@ -307,7 +307,7 @@ related:
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox10" class="overflow-hidden d-block text-normal">
-    How many open pull requests are there?
+    Колко отворени заявки за изтегляне има?
   </label>
 </div>
 
@@ -339,7 +339,7 @@ related:
   </label>
 </div>
 
-**Project is welcoming**
+**Проектът е приветлив**
 
 Проект, който е приятелски настроен и гостоприемен, сигнализира, че те ще бъдат възприемчиви към нови сътрудници.
 
@@ -489,7 +489,7 @@ related:
 * **Тествайте промените си!** Стартирайте промените си срещу всички съществуващи тестове, ако съществуват, и създайте нови, когато е необходимо. Важно е да се уверите, че вашите промени не нарушават съществуващия проект.
 * **Допринесете в стила на проекта** според възможностите си. Това може да означава използване на отстъпи, точка и запетая или коментари по различен начин, отколкото бихте направили във вашето собствено хранилище, но улеснява поддържащия да слива, другите да разбират и поддържат в бъдеще.
 
-Ако това е първата ви заявка за изтегляне, вижте [Направете заявка за изтегляне](http://makeapullrequest.com/), която @kentcdodds създаде като видеоурок с инструкции. Можете също така да практикувате да правите заявка за изтегляне в хранилището [First Contributions](https://github.com/Roshanjossey/first-contributions), създадено от @Roshanjossey.
+Ако това е първата ви заявка за изтегляне, вижте [Направете заявка за изтегляне](http://makeapullrequest.com/), която @kentcdodds създаде като видеоурок с инструкции. Можете също така да практикувате да правите заявка за изтегляне в хранилището [Първи вноски](https://github.com/Roshanjossey/first-contributions), създадено от @Roshanjossey.
 
 ## Какво се случва, след като изпратите своя принос
 
@@ -497,7 +497,7 @@ related:
 
 ### 😭 Не получавате отговор
 
-Надяваме се, че сте [проверили проекта за признаци на активност](#a-checklist-before-you-contribute), преди да направите принос. Дори при активен проект обаче е възможно вашият принос да не получи отговор.
+Надяваме се, че сте [проверили проекта за признаци на активност](#контролен-списък-преди-да-допринесете), преди да направите принос. Дори при активен проект обаче е възможно вашият принос да не получи отговор.
 
 Ако не сте получили отговор повече от седмица, е честно да отговорите учтиво в същата тема, като помолите някого за преглед. Ако знаете името на подходящия човек, който да прегледа вашия принос, можете да го споменете с @ в тази нишка.
 

From 11b712faea4614b8efcb3904ed2169778824adbe Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Tue, 30 Apr 2024 00:42:37 -0700
Subject: [PATCH 679/749] Fix data structure problem in bg

---
 _data/locales/bg.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_data/locales/bg.yml b/_data/locales/bg.yml
index f2b963f522f..476d56ed674 100644
--- a/_data/locales/bg.yml
+++ b/_data/locales/bg.yml
@@ -1,4 +1,4 @@
-en:
+bg:
   locale_name: Български
   nav:
     about: Относно нас

From 95b552c5a39d604e5ca6f9a512b68311e1372957 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Thu, 16 May 2024 18:35:20 +0200
Subject: [PATCH 680/749] add Italian translation

---
 _articles/it/best-practices.md                | 275 +++++++++
 _articles/it/building-community.md            | 276 +++++++++
 _articles/it/code-of-conduct.md               | 113 ++++
 _articles/it/finding-users.md                 | 148 +++++
 _articles/it/getting-paid.md                  | 178 ++++++
 _articles/it/how-to-contribute.md             | 526 ++++++++++++++++++
 _articles/it/index.html                       |   7 +
 _articles/it/leadership-and-governance.md     | 156 ++++++
 _articles/it/legal.md                         | 160 ++++++
 ...ing-balance-for-open-source-maintainers.md | 220 ++++++++
 _articles/it/metrics.md                       | 128 +++++
 _articles/it/starting-a-project.md            | 355 ++++++++++++
 _data/locales/it.yml                          |  31 ++
 13 files changed, 2573 insertions(+)
 create mode 100644 _articles/it/best-practices.md
 create mode 100644 _articles/it/building-community.md
 create mode 100644 _articles/it/code-of-conduct.md
 create mode 100644 _articles/it/finding-users.md
 create mode 100644 _articles/it/getting-paid.md
 create mode 100644 _articles/it/how-to-contribute.md
 create mode 100644 _articles/it/index.html
 create mode 100644 _articles/it/leadership-and-governance.md
 create mode 100644 _articles/it/legal.md
 create mode 100644 _articles/it/maintaining-balance-for-open-source-maintainers.md
 create mode 100644 _articles/it/metrics.md
 create mode 100644 _articles/it/starting-a-project.md
 create mode 100644 _data/locales/it.yml

diff --git a/_articles/it/best-practices.md b/_articles/it/best-practices.md
new file mode 100644
index 00000000000..b9128aa7c16
--- /dev/null
+++ b/_articles/it/best-practices.md
@@ -0,0 +1,275 @@
+---
+lang: it
+title: Buone pratiche per i manutentori del codice.
+description: Semplificarti la vita come sostenitore dell'open source, dal processo di documentazione fino a ottenere il massimo dalla community.
+class: best-practices
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+  - metrics
+  - leadership
+---
+
+## Cosa significa essere un manutentore del codice?
+
+Se il tuo lavoro è mantenere un progetto open source utilizzato da molte persone, probabilmente avrai notato che passi più tempo a rispondere alle domande che a programmare.
+
+Nelle prime fasi di un progetto, trascorri del tempo sperimentando nuove idee e prendendo decisioni in base a ciò che ti piace. Man mano che il tuo progetto cresce in popolarità, ti ritroverai in una situazione in cui lavorerai sempre di più con i tuoi utenti e collaboratori.
+
+Il mantenimento di un progetto richiede molto più del semplice codice. Questi compiti vengono solitamente trascurati, ma sono altrettanto importanti per un progetto in crescita. Abbiamo messo insieme alcune idee che ti semplificheranno la vita, dal processo di documentazione all'ottenimento del massimo dalla community.
+
+## Documentare i tuoi processi
+
+Contrassegnare le procedure è una delle migliori pratiche che puoi seguire come manutentore del codice.
+
+Documentare non solo chiarisce il tuo pensiero, ma aiuta anche gli altri a capire di cosa hai bisogno o cosa ti aspetti senza nemmeno doverlo chiedere.
+
+Tenendo conto dei processi, è più facile per te dire di no quando la proposta di qualcuno non si adatta al tuo contesto. Quindi rende anche più facile per altre persone unirsi e aiutare. Non sai mai chi potrebbe leggere o utilizzare il tuo progetto.
+
+Anche se non sei il tipo che scrive interi paragrafi, annotare i punti chiave è meglio di niente.
+
+### Chiarire la visione del tuo progetto
+
+Inizia scrivendo gli obiettivi del tuo progetto. Aggiungili al tuo file README o crea un file separato chiamato VISION. Se ci sono altri elementi che possono essere d'aiuto, come una mappa di progetto, rendili pubblici.
+
+Avere una visione chiara e documentata ti mantiene concentrato e aiuta a evitare malintesi sull'ambito da parte di altri contributori.
+
+Per esempio:
+@lord ha scoperto che avere una visione del progetto lo ha aiutato a capire a quali richieste dare priorità. Essendo un sostenitore del codice alle prime armi, si è lamentato di non essere fedele allo scopo del progetto quando ha ricevuto la tua prima richiesta di funzionalità [Slate](https://github.com/lord/slate).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
+  Ho provato. Non ho fatto lo sforzo necessario per trovare una soluzione completa. Invece di una soluzione a metà, vorrei aver detto "Non ho tempo per questo adesso, ma aggiungerò la funzionalità al backlog che verrà sviluppato in futuro".
+  <p markdown="1" class="pquote-credit">
+— @lord, ["Suggerimenti per i sostenitori dell'Open Source"](https://lord.io/blog/2014/oss-tips/)
+  </p>
+</aside>
+
+### Comunica le tue aspettative
+
+A volte può essere difficile formulare le regole in modo che altre persone possano contribuire. Potresti avere la sensazione di comportarti come un poliziotto o di rovinare il divertimento degli altri.
+
+Tuttavia, le buone regole scritte e applicate in modo equo danno potere ai manutentori del codice. Ti impediscono di farti coinvolgere in cose che non vuoi fare.
+
+La maggior parte delle persone che incontrano il tuo progetto non sanno nulla di te o delle tue circostanze. Potrebbero presumere che tu sia pagato per lavorarci, soprattutto se è qualcosa che usano e da cui dipendono regolarmente. Forse una volta dedicavi molto tempo al tuo progetto, ma ora sei impegnato con un nuovo lavoro o con un membro della famiglia.
+
+Va tutto bene! Assicurati solo che la gente lo sappia.
+
+Sia che il mantenimento del tuo progetto sia part-time o solo volontario, sii onesto su quanto tempo hai. Questo non è lo stesso di quanto tempo pensi che richiederà il progetto o di quanto tempo gli altri vogliono che tu spenda.
+
+Ecco alcune regole che vale la pena tenere a mente:
+
+* Come viene esaminato e accettato l'input (_Hai bisogno di fare qualche test? Qualche modello da utilizzare per i problemi?_)
+* I tipi di contributi che accetterai (_Vuoi aiuto solo con una parte del codice?_)
+* Quando è opportuno dare seguito (_ad esempio "Puoi aspettarti una risposta dal supporto del codice entro i prossimi 7 giorni. Se non hai ricevuto alcuna risposta entro allora, sentiti libero di eseguire il ping del thread."_)
+*Quanto tempo dedichi al progetto (_es. "Investiamo solo circa 5 ore settimanali in questo progetto"_)
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), e [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) questi sono alcuni esempi di progetti con regole chiare per manutentori e contributori.
+
+### Mantenere la comunicazione pubblica
+
+Non dimenticare di documentare anche le tue interazioni. Dove puoi, mantieni la comunicazione pubblica sul tuo progetto. Se qualcuno tenta di contattarti personalmente per discutere di una richiesta di funzionalità o di un'esigenza di supporto, indirizzalo educatamente a un canale di comunicazione pubblico, come un elenco di posta elettronica o un tracker dei problemi.
+
+Se incontri altri sostenitori o prendi decisioni importanti in privato, documenta tali conversazioni pubblicamente, anche se pubblichi solo i tuoi appunti.
+
+In questo modo, chiunque si unisca alla tua comunità avrà accesso alle stesse informazioni di chi è stato lì. Per anni.
+
+## Impara a dire di "No"
+
+Hai scritto tu la roba. Idealmente, tutti leggeranno la tua documentazione, ma in realtà dovrai ricordare agli altri che questa conoscenza esiste.
+
+Tuttavia, avere tutto scritto aiuta a spersonalizzare le situazioni in cui le regole devono essere applicate.
+
+Dire di no non è divertente, ma _"Il tuo contributo non soddisfa i criteri per questo progetto"_ sembra meno personale di _"Non mi piace il tuo contributo"_.
+
+Dire "no" si applica a molte situazioni che incontrerai come sostenitore del codice: richieste di funzionalità che non rientrano nell'ambito, qualcuno che deraglia una discussione, che fa lavoro non necessario per altri.
+
+### Mantieni la conversazione amichevole
+
+Uno dei posti più importanti in cui ti eserciterai a dire di no è nella coda di rilascio e richiesta pull. Come project manager, riceverai inevitabilmente proposte che non vuoi accettare.
+
+Forse il contributo cambia la portata del tuo progetto o non si adatta alla tua visione. Forse l'idea è buona, ma la realizzazione è pessima.
+
+Indipendentemente dal motivo, puoi gestire con tatto i contributi che non soddisfano gli standard del progetto.
+
+Se ricevi un messaggio che non vuoi accettare, la tua prima reazione potrebbe essere quella di ignorarlo o di far finta di non averlo visto. Ciò può ferire i sentimenti dell'altra persona e persino scoraggiare altri potenziali contributori nella tua comunità.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
+  La chiave per gestire il supporto per progetti open source su larga scala è mantenere i problemi in movimento. Cerca di evitare ulteriori problemi. Se sei uno sviluppatore iOS, sai quanto può essere frustrante l'invio di radar. Potresti ricevere alcune notizie due anni dopo e ti verrà chiesto di confermarle. Riprova con l'ultima versione di iOS.
+  <p markdown="1" class="pquote-credit">
+— @KrauseFx, ["Scalare le comunità open source"](https://krausefx.com/blog/scaling-open-source-communities)
+  </p>
+</aside>
+
+Non lasciare aperto un contributo non richiesto perché ti senti in colpa o vuoi essere gentile. Nel corso del tempo, le tue domande senza risposta e le tue PR diventeranno ridondanti. Ciò renderà il lavoro sul tuo progetto molto più stressante e imbarazzante.
+
+È meglio chiudere immediatamente i contributi che sai di non voler accettare. Se il tuo progetto soffre già di un ampio arretrato o di un elenco di funzionalità da implementare, @steveklabnik ha suggerimenti su [come selezionare le domande in modo efficace](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+
+In secondo luogo, ignorare i contributi invia un segnale negativo alla tua comunità. Contribuire a un progetto può essere intimidatorio, soprattutto se è la prima volta per qualcuno. Anche se non accetti il ​​loro contributo, congratulati con la persona che sta dietro al progetto e ringraziala per il suo interesse. È un grande complimento!
+
+Se non desideri accettare una donazione:
+
+* **Grazie** per il loro contributo.
+* **Spiegare perché non soddisfa** l'ambito del progetto e offrire chiari suggerimenti per il miglioramento, se possibile. Lo so, gentile ma fermo.
+* **Condividi informazioni rilevanti** se ne hai. Se noti ripetute richieste di cose che non vuoi accettare, aggiungile alla tua documentazione per evitare di spiegare sempre la stessa cosa.
+* **Chiudi la richiesta**
+
+Non dovresti avere più di 1-2 frasi a cui rispondere. Ad esempio, quando un utente [celery](https://github.com/celery/celery/) segnalato un errore relativo a Windows, @berkerpeksag [lui a risposto con](https://github.com/celery/celery/issues/3383):
+
+[celery screenshot](/assets/images/best-practices/celery.png)
+
+Se l’idea di dire di no ti terrorizza, non sentirti sola. Come @jessfraz [dice](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> Ho parlato con manutentori del codice di molti diversi progetti open source, Mesos, Kubernetes, Chromium, e sono tutti d'accordo sul fatto che una delle parti più difficili dell'essere un manutentore del codice è: dire "No" alle patch che non vuoi utilizzare
+
+Non sentirti in colpa per non voler accettare il contributo di qualcuno. La prima regola dell'open source, [secondo](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No, è temporaneo; sì, è per sempre."_ Sebbene martirizzare l'entusiasmo di un'altra persona sia una buona cosa, rifiutare un contributo non è la stessa cosa che rifiutare la persona che sta dietro ad esso.
+
+Dopotutto, se un contributo non è abbastanza buono, non sei obbligato ad accettarlo. So che sii gentile e accomodante quando le persone contribuiscono al tuo progetto, ma accetta solo i cambiamenti che ritieni veramente miglioreranno il tuo progetto. Più ti eserciti a dire di no, più diventa facile. È una promessa.
+
+### Sii proattivo
+
+Per ridurre innanzitutto il volume dei contributi non richiesti, spiega il processo del tuo progetto per l'invio e l'accettazione dei contributi nella guida ai contributi.
+
+Se ricevi troppi contributi di bassa qualità, chiedi ai contributori di svolgere del lavoro in anticipo, ad esempio:
+
+* Completa un modello o un elenco di controllo per problemi o PR
+*Apri un problema prima di inviare un PR
+
+Se non seguono le tue regole, chiudi immediatamente il problema e indirizzali alla tua documentazione.
+
+Sebbene questo approccio possa sembrare inizialmente imbarazzante, essere proattivi è in realtà positivo per entrambe le parti. Riduci la possibilità che qualcuno investa molte ore di lavoro sprecato su una richiesta pull che non accetti. E semplifica la gestione del carico.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+  Idealmente, spiegare in un file CONTRIBUTING.md come possono ottenere in futuro un'indicazione migliore di cosa verrebbe o non verrebbe accettato prima di iniziare il lavoro.
+  <p markdown="1" class="pquote-credit">
+— @MikeMcQuaid, ["Si prega di chiudere le richieste pull"](https://github.com/blog/2124-kindly-closing-pull-requests)
+  </p>
+</aside>
+
+A volte, quando dici di no, il tuo potenziale collaboratore potrebbe arrabbiarsi o criticare la tua decisione. Se il tuo comportamento diventa ostile, [prendi provvedimenti per disinnescare la situazione](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) o addirittura rimuoverli dalla tua comunità se non sono disposti a collaborare in modo costruttivo.
+
+### Scegli il tutoraggio
+
+Forse qualcuno nella tua comunità invia regolarmente contributi che non soddisfano gli standard del tuo progetto. Può essere frustrante per entrambe le parti sottoporsi ripetutamente al processo di rifiuto.
+
+Se vedi qualcuno che ti entusiasma, ma ha bisogno di un po' di pratica, sii paziente. In ogni situazione, spiega chiaramente il motivo. il loro contributo non soddisfa le aspettative del progetto. Prova a dare loro un compito più semplice o meno ambiguo, come un problema etichettato come "buon primo problema" per riscaldarli. Se hai tempo, valuta la possibilità di fare da mentore tramite il tuo primo contributo o trova qualcun altro nella tua comunità che sia interessato. pronto ad istruirli.
+
+##Utilizzo della comunità
+
+Non devi fare tutto da solo. La tua community di progetto esiste per un motivo! Anche se non hai ancora una comunità attiva di contributori, se hai molti utenti, lasciali lavorare.
+
+### Condividi il carico
+
+Se stai cercando altri a cui unirsi, inizia chiedendo in giro.
+
+Quando vedi nuovi contributori che contribuiscono ripetutamente, dovresti riconoscere il loro lavoro offrendo loro maggiori responsabilità. Documenta come gli altri possono ottenere ruoli di leadership, se lo desiderano.
+
+Incoraggiare gli altri a [condividere la proprietà del progetto](../building-community/#condividi-la-proprietà-del-tuo-progetto) può ridurre significativamente il carico di lavoro, come ha trovato @lmccart nel suo progetto, [p5.js](https://github.com/processing/p5.js).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
+ Dicevo: "Sì, può partecipare chiunque, non è necessario avere molta esperienza di programmazione [...]." Abbiamo persone iscritte [agli eventi] ed eccoci qui. Allora mi sono chiesto: è vero quello che dico? Ci saranno 40 persone che si presenteranno e non è che posso sedermi con ognuna di loro... Ma le persone si sono riunite e ha funzionato. Una volta che una persona l’ha capito, può insegnarlo ai suoi vicini.
+  <p markdown="1" class="pquote-credit">
+—  @lmccart, ["Dopo tutto, cosa significa "Open Source"?"? p5.js La modifica"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+  </p>
+</aside>
+
+Se hai bisogno di allontanarti dal tuo progetto, temporaneamente o permanentemente, non c'è vergogna nel chiedere a qualcun altro di subentrare al tuo posto.
+
+Se altre persone sono entusiaste della direzione del progetto, dai loro il permesso di essere coinvolte o di cedere formalmente il controllo a qualcun altro. Se qualcuno crea un fork del tuo progetto e questo viene mantenuto attivamente da qualche altra parte, considera di collegare il fork dal tuo progetto originale. È fantastico che così tante persone vogliano che il tuo progetto venga sviluppato!
+
+@progrium [trovato quello](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documentare la visione del tuo progetto, [Dokku](https://github.com/dokku/dokku), aiutare questi obiettivi a continuare, anche oltre ciò che resta del progetto:
+
+> Ho scritto una pagina wiki che descrive cosa voglio e perché lo voglio. Per qualche motivo sono rimasto sorpreso da questo! Lasciamo che i manutentori inizino a muovere il progetto in questa direzione! È successo? Come lo faresti esattamente? Non sempre. Ma comunque sia stato affrontato, ho realizzato il progetto come volevo.
+
+### Lascia che siano gli altri a creare le soluzioni di cui hanno bisogno
+
+Se un potenziale collaboratore ha un'opinione diversa su ciò che dovrebbe fare il tuo progetto, potresti dover incoraggiarlo gentilmente a lavorare sul proprio fork.
+
+Biforcare un progetto non è necessariamente una cosa negativa. Essere in grado di copiare e modificare progetti è una delle cose migliori dell'open source. Incoraggiare i membri della tua comunità a lavorare sul proprio fork può fornire lo sbocco creativo di cui hanno bisogno senza entrare in conflitto con la visione del tuo progetto.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
+  Gestisco l'80% dei casi d'uso. Se sei uno degli unicorni, per favore sgancia il mio lavoro. Non mi offenderò! I miei progetti comunitari sono quasi sempre finalizzati alla risoluzione dei problemi più comuni; Cerco di rendere più semplice andare oltre ramificando il mio lavoro o espandendolo.
+  <p markdown="1" class="pquote-credit">
+— @geerlingguy, ["Perchè sto chiudendo PR"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+  </p>
+</aside>
+
+Lo stesso vale per un utente che desidera davvero una soluzione che semplicemente non hai la capacità di creare. Offrire API e hook personalizzati può aiutare gli altri a soddisfare le proprie esigenze senza dover modificare direttamente la fonte.
+@orta [ha trovato che](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) incoraggiando i plugin CocoaPods ad "alcune delle idee più interessanti":
+
+> È quasi inevitabile che una volta che un progetto diventa grande, i manutentori debbano essere molto più conservatori su come introdurre il nuovo codice. Sai dire di no, ma molte persone hanno bisogni legittimi. Pertanto, finisci per trasformare il tuo strumento in una piattaforma.
+
+## Porta avanti i robot
+
+Quindi, proprio come ci sono compiti in cui altre persone possono aiutarti, ci sono anche compiti che nessun essere umano dovrebbe svolgere. I robot sono tuoi amici. Usali per semplificarti la vita come manutentore del codice.
+
+### Richiedi test e altri controlli per migliorare la qualità del tuo codice
+
+Uno dei modi più importanti per automatizzare il tuo progetto è attraverso i test.
+
+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.
+
+Se aggiungi test, assicurati di spiegare come funzionano nel tuo file CONTRIBUTING.
+
+<aside markdown="1" class="pquote">
+  <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)
+  </p>
+</aside>
+
+### Utilizza strumenti per automatizzare le attività di manutenzione di base
+
+La buona notizia nel mantenere un progetto popolare è che altri manutentori hanno probabilmente riscontrato problemi simili e hanno creato una soluzione per questo.
+
+Sono disponibili [vari strumenti](https://github.com/showcases/tools-for-open-source) per automatizzare alcuni aspetti del lavoro di manutenzione. Alcuni esempi:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) automatizzare i tuoi rilasci
+* [mention-bot](https://github.com/facebook/mention-bot) menzionare possibili revisori per le richieste del timone
+* [Danger](https://github.com/danger/danger) aiuta ad automatizzare la revisione del codice
+
+Per segnalazioni di bug e altri contributi generali, GitHub dispone di [modelli di richiesta di rilascio e pull](https://github.com/blog/2111-issue-and-pull-request-templates), che puoi creare per semplificare la comunicazione che ricevi. Puoi anche configurare [filtri email](https://github.com/blog/2203-email-updates-about-your-own-activity) per gestire le tue notifiche email.
+
+Se vuoi diventare un po' più avanzato, le guide di stile possono standardizzare i contributi del progetto e renderli più facili da rivedere e adottare.
+
+Tuttavia, se i tuoi standard sono troppo complessi, possono aumentare gli ostacoli alla contribuzione. Assicurati di aggiungere solo regole per rendere la vita più semplice a tutti.
+
+Se non sei sicuro di quali strumenti utilizzare, controlla cosa stanno facendo altri progetti popolari, in particolare quelli nel tuo ecosistema. Ad esempio, come si presenta il processo di contribuzione per gli altri moduli Node? Anche l’utilizzo di strumenti e approcci simili faciliterà. Rendi il tuo processo più familiare ai tuoi associati target.
+
+## È una bella pausa
+
+Il lavoro open source una volta ti dava gioia. Forse ora è così che iniziano a farti sentire evasivo o colpevole.
+
+Forse ti senti sopraffatto o provi un crescente senso di paura quando pensi ai tuoi progetti. E nel frattempo si accumulano problemi e pull request.
+
+Il burnout è un problema reale e pervasivo nel lavoro open source, soprattutto tra i manutentori. In qualità di manutentore, la tua felicità è un requisito non negoziabile per la sopravvivenza di qualsiasi progetto open source.
+
+Anche se dovrebbe essere ovvio, prenditi una pausa! Non devi aspettare finché non ti senti stanco per fare una pausa. @brettcannon, uno sviluppatore Python, ha deciso di prendersi una [mese di vacanza](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering) dopo 14 anni OSS volantariato.
+
+Come qualsiasi altro tipo di lavoro, fare delle pause regolari ti manterrà motivato. freschi, felici ed entusiasti del loro lavoro.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
+  Pur mantenendo WP-CLI, ho scoperto che dovevo preoccuparmi prima della mia felicità e stabilire limiti chiari al mio coinvolgimento. Il miglior equilibrio che ho trovato è 2-5 ore settimanali come parte del mio normale orario di lavoro. Mantiene il mio coinvolgimento come passione e non sembra troppo un lavoro. Poiché do la priorità alle questioni su cui sto lavorando, posso fare regolarmente progressi su ciò che ritengo più importante.
+  <p markdown="1" class="pquote-credit">
+— @danielbachhuber, ["Le mie condoglianze, ora sei il manutentore di un popolare progetto open source"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+  </p>
+</aside>
+
+A volte può essere difficile prendersi una pausa dal lavoro open source quando ritieni che il mondo intero abbia bisogno di te. Le persone potrebbero anche provare a farti sentire in colpa per esserti allontanato.
+
+Fai del tuo meglio per trovare supporto per i tuoi utenti e la tua comunità mentre sei lontano da un progetto. Se non riesci a trovare il supporto di cui hai bisogno, prenditi comunque una pausa. Ricordati di comunicare quando non sei disponibile in modo che le persone non si sentano confuse dalla tua mancanza di reattività.
+
+Fare le vacanze è qualcosa di più delle semplici vacanze. Se non vuoi lavorare con l'open source nei fine settimana o durante l'orario lavorativo, comunica queste decisioni ad altri in modo che sappiano che non sarai disturbato.
+
+## Prenditi cura di te prima!
+
+Mantenere un progetto popolare richiede competenze diverse rispetto alle prime fasi di crescita, ma non è per questo meno gratificante. In qualità di manutentore, eserciterai le capacità di leadership e di gestione delle persone a un livello che poche persone possono sperimentare. Anche se non è sempre facile da gestire, stabilire dei limiti chiari e prendere solo ciò che ti fa sentire a tuo agio ti aiuterà. per mantenerti felice, aggiornato e produttivo.
\ No newline at end of file
diff --git a/_articles/it/building-community.md b/_articles/it/building-community.md
new file mode 100644
index 00000000000..ca9bbc4b76a
--- /dev/null
+++ b/_articles/it/building-community.md
@@ -0,0 +1,276 @@
+---
+lang: it
+title: Costruire comunità accoglienti
+description: Costruire una comunità che incoraggi le persone a utilizzare, contribuire ed educare con il tuo progetto
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+  - best-practices
+  - coc
+---
+
+## Prepara il tuo progetto per il successo
+
+Hai appena lanciato il tuo progetto, stai spargendo la voce e le persone ti seguono. Brillante! Ora, come fai a farli restare?
+
+Una comunità accogliente è un investimento sul futuro del tuo progetto e della tua reputazione. Se il tuo progetto sta appena iniziando a vedere i primi contributi, inizia offrendo ai primi contributori un'esperienza positiva e rendendo facile per loro continuare a tornare.
+
+### Fai sentire le persone benvenute
+
+Un modo di pensare alla community del tuo progetto è attraverso quello che @MikeMcQuaid chiama [funnel del collaboratore](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+![Canalizzazione del collaboratore](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+
+Mentre costruisci la tua community, considera come qualcuno in cima alla canalizzazione (un potenziale utente) potrebbe teoricamente scendere verso il basso (un sostenitore attivo). Il tuo obiettivo è ridurre l'attrito in ogni fase dell'esperienza associata. Quando le persone ottengono vittorie facili, saranno motivate a fare di più.
+
+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.
+
+[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.
+
+* **Quando qualcuno di nuovo si unisce al tuo progetto, ringrazialo per il suo interesse!** Basta un'esperienza negativa per far sì che qualcuno non voglia più tornare.
+* **Sii reattivo.** Se non rispondi alla loro domanda per un mese, è probabile che si siano già dimenticati del tuo progetto.
+* **Sii di mentalità aperta riguardo ai tipi di contributi che accetti.** Molti contributori iniziano segnalando un bug o apportando una piccola correzione. Ci sono [molti modi per contribuire](../how-to-contribute/#cosa-significa-contribuire) ad un progetto. Lascia che le persone aiutino nel modo in cui vogliono aiutare.
+* **Se c'è un contributo con cui non sei d'accordo,** ringrazialo per la sua idea e [spiegate perchè](../best-practices/#impara-a-dire-di-no) non soddisfa lo scopo del progetto, con un collegamento alla documentazione pertinente, se disponibile.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  Contribuire all'open source è più facile per alcuni che per altri. C’è una grande paura di essere accusati di non aver fatto qualcosa di giusto o semplicemente di non adattarsi. (...) Dando ai contributori un posto dove contribuire con competenze tecniche molto basse (documentazione, markup di contenuti web, ecc.), puoi ridurre notevolmente queste preoccupazioni.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Crescere una base di contributori nel moderno open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+  </p>
+</aside>
+
+La maggior parte dei contributori open source sono "collaboratori occasionali": persone che contribuiscono a un progetto solo occasionalmente. Un collaboratore occasionale potrebbe non avere il tempo di familiarizzare completamente con il tuo progetto, quindi il tuo compito è facilitare il suo contributo.
+
+Incoraggiare altri contributori è anche un investimento su te stesso. Quando permetti ai tuoi più grandi fan di lavorare sul lavoro che li appassiona, c'è meno pressione nel dover fare tutto da solo.
+
+### Documenta tutto
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+  Sei mai stato a un evento (tecnologico) in cui non conosci nessuno, ma tutti gli altri sembrano essere in gruppo a chiacchierare come vecchi amici? (...) Ora immagina di voler contribuire ad un progetto open source, ma non capisci perché e come ciò avvenga.
+  <p markdown="1" class="pquote-credit">
+— @janl, ["Open source sostenibile"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+Quando si inizia un nuovo progetto, può sembrare naturale mantenere segreto il proprio lavoro. Ma i progetti open source prosperano quando documenti pubblicamente il tuo processo.
+
+Quando documenti le cose, più persone possono essere coinvolte in ogni fase del processo. Potresti ricevere aiuto per qualcosa di cui non sapevi nemmeno di aver bisogno.
+
+Annotare le cose significa molto più che una semplice documentazione tecnica. Ogni volta che senti il ​​bisogno di scrivere qualcosa o discutere del tuo lavoro in privato, chiediti se puoi renderlo pubblico.
+
+Sii trasparente riguardo alla roadmap del tuo progetto, ai tipi di contributi che stai cercando, a come vengono considerati i contributi o al motivo per cui hai preso determinate decisioni.
+
+Se noti che molti utenti hanno lo stesso problema, documenta le risposte nel README.
+
+Per le riunioni, valuta la possibilità di pubblicare i tuoi appunti o i tuoi appunti in un thread correlato. Il feedback che otterrai da questo livello di trasparenza potrebbe sorprenderti.
+
+Documentare tutto vale anche per il lavoro che svolgi. Se stai lavorando a un aggiornamento importante del tuo progetto, inseriscilo in una richiesta pull e contrassegnalo come work in progress (WIP). In questo modo, altre persone possono sentirsi coinvolte fin dall’inizio nel processo.
+
+### Sii reattivo
+
+Mentre [promuovi il tuo progetto](../finding-users), le persone avranno feedback su di te. Potrebbero avere domande su come funzionano le cose o aver bisogno di aiuto per iniziare.
+
+Cerca di essere reattivo quando qualcuno segnala un problema, invia una richiesta pull o pone una domanda sul tuo progetto. Quando rispondi rapidamente, le persone si sentiranno parte di un dialogo e saranno più entusiaste di partecipare.
+
+Anche se non puoi esaminare immediatamente la richiesta, confermarla tempestivamente aiuta ad aumentare il coinvolgimento. Ecco come @tdreyno ha risposto a una richiesta pull su [Middleman](https://github.com/middleman/middleman/pull/1466):
+
+![Middleman richiesta di download](/assets/images/building-community/middleman_pr.png)
+
+[Questo è ciò che ha scoperto uno studio Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) i contributori che hanno ricevuto revisioni del codice entro 48 ore hanno avuto un tasso di rendimento e ricontribuzione molto più elevato.
+
+Le discussioni sul tuo progetto potrebbero svolgersi anche altrove sul Web, come Stack Overflow, Twitter o Reddit. Puoi impostare le notifiche in alcuni di questi luoghi in modo da ricevere una notifica quando qualcuno menziona il tuo progetto.
+
+### Offri alla tua comunità un luogo in cui riunirsi
+
+Ci sono due ragioni per dare alla tua comunità un luogo in cui riunirsi.
+
+Il primo motivo è per loro. Aiuta le persone a conoscersi. Le persone con interessi comuni vorranno inevitabilmente un posto dove parlarne. E quando la comunicazione è pubblica e accessibile, chiunque può leggere gli archivi del passato per imparare e partecipare.
+
+Il secondo motivo è per te. Se non offri alle persone un luogo pubblico in cui parlare del tuo progetto, probabilmente ti contatteranno direttamente. All'inizio può sembrare abbastanza semplice rispondere ai messaggi privati ​​"solo per questa volta". Ma col tempo, soprattutto se il tuo progetto diventa popolare, ti sentirai esausto. Resisti alla tentazione di comunicare in privato con le persone riguardo al tuo progetto. Indirizzali invece a un canale pubblico specifico.
+
+La comunicazione pubblica può essere semplice come invitare le persone ad aprire un problema invece di inviarti direttamente un'e-mail o commentare sul tuo blog. Puoi anche impostare una mailing list o creare un account Twitter, Slack o un canale IRC affinché le persone possano parlare del tuo progetto. Oppure prova tutto quanto sopra!
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) dedica ore di lavoro ogni due settimane per aiutare i membri della comunità:
+
+> Kops inoltre dedica del tempo ogni settimana per offrire aiuto e guida alla comunità. I manutentori di Kops hanno concordato di dedicare del tempo specificatamente dedicato al lavoro con i nuovi arrivati, aiutando con le PR e discutendo le nuove funzionalità.
+
+Eccezioni notevoli alla comunicazione pubblica sono: 1) questioni di sicurezza e 2) violazioni sensibili del codice di condotta. Dovresti sempre avere la possibilità che le persone possano segnalare questi problemi di persona. Se non desideri utilizzare la tua email personale, imposta un indirizzo email dedicato.
+
+## Fai crescere la tua comunità
+
+Le comunità sono estremamente forti. Questo potere può essere una benedizione o una maledizione, a seconda di come lo eserciti. Man mano che la community del tuo progetto cresce, ci sono modi per aiutarla a diventare una forza di costruzione, non di demolizione.
+
+### Non tollerare i cattivi attori
+
+Qualsiasi progetto popolare attirerà inevitabilmente persone che danneggiano, non aiutano, la tua comunità. Potrebbero avviare dibattiti non necessari, discutere su aspetti banali o fare il prepotente con gli altri.
+
+Fai del tuo meglio per adottare una politica di tolleranza zero nei confronti di questo tipo di persone. Se lasciate senza controllo, le persone negative metteranno a disagio le altre persone nella tua comunità. Potrebbero anche andarsene.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
+  La verità è che avere una comunità solidale è fondamentale. Non avrei mai potuto svolgere questo lavoro senza l'aiuto dei miei colleghi, di amichevoli sconosciuti su Internet e di canali IRC chiacchieroni. (...) Non accontentarti di meno. Non accontentarti degli sciocchi.
+  <p markdown="1" class="pquote-credit">
+— @okdistribute, ["Come gestire un progetto FOSS"](https://okdistribute.xyz/post/okf-de)
+  </p>
+</aside>
+
+Discussioni regolari su aspetti banali del tuo progetto distraggono gli altri, te compreso, dal concentrarsi su compiti importanti. Le nuove persone che arrivano al tuo progetto potrebbero vedere queste conversazioni e non voler partecipare.
+
+Quando vedi che si verifica un comportamento negativo, fai un'osservazione pubblica al riguardo. Spiegare in tono amichevole perché tale comportamento non è accettabile. Se il problema persiste, potrebbe essere necessario [chiedergli di andarsene](../code-of-conduct/#le-tue-responsabilità-come-manutentore). Il tuo [codice di condotta](../code-of-conduct/) può essere una guida costruttiva per queste conversazioni.
+
+### Incontra i contributori ovunque si trovino
+
+Una buona documentazione diventa sempre più importante man mano che la tua comunità cresce. I contributori occasionali che altrimenti potrebbero non avere familiarità con il tuo progetto leggono la tua documentazione per ottenere rapidamente il contesto di cui hanno bisogno.
+
+Nel tuo file CONTRIBUTING, indica esplicitamente ai nuovi contributori come iniziare. Potresti anche voler creare una sezione speciale per questo scopo. [Django](https://github.com/django/django), ad esempio, ha una pagina di destinazione speciale per accogliere i nuovi contributori.
+
+![Django pagin acon i nuovi contributori](/assets/images/building-community/django_new_contributors.png)
+
+Nella coda degli argomenti, contrassegna i bug appropriati per i diversi tipi di contributori: ad esempio [_"per principianti"_](https://kentcdodds.com/blog/first-timers-only), _"buon primo argomento"_ o _"documentazione"_. [Questi appunti](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) rendi facile per qualcuno che non conosce il tuo progetto scansionare rapidamente i tuoi argomenti e iniziare.
+
+Infine, usa la tua documentazione per far sentire le persone benvenute in ogni fase del processo.
+
+Non interagirai mai con la maggior parte delle persone che saranno coinvolte nel tuo progetto. Potrebbero esserci contributi che non hai ricevuto perché qualcuno si è sentito intimidito o non sapeva da dove cominciare. Anche poche parole gentili possono evitare che qualcuno lasci deluso il tuo progetto.
+
+Ad esempio, ecco come [Rubinius](https://github.com/rubinius/rubinius/) ha iniziato [la sua guida che contribuisce](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+> Vogliamo iniziare ringraziandoti per aver utilizzato Rubinius. Questo progetto è un lavoro d'amore e apprezziamo tutti gli utenti che rilevano bug, apportano miglioramenti alle prestazioni e aiutano con la documentazione. Ogni contributo conta, quindi grazie per aver partecipato. Tenendo questo a mente, ecco alcune linee guida che ti chiediamo di seguire per poter risolvere con successo il tuo problema.
+
+### Condividi la proprietà del tuo progetto
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
+  I tuoi leader avranno opinioni diverse, come dovrebbero fare tutte le comunità sane! Tuttavia, è necessario adottare misure per garantire che la voce più forte non sempre prevalga, logorando le persone, e che le voci meno importanti e minoritarie siano ascoltate.
+  <p markdown="1" class="pquote-credit">
+— @sagesharp, ["Ciò che rende una buona comunità?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+  </p>
+</aside>
+
+Le persone sono entusiaste di contribuire ai progetti quando sentono un senso di appartenenza. Ciò non significa che devi stravolgere la visione del tuo progetto o accettare input che non desideri. Ma più riconosci gli altri, più rimarranno presenti.
+
+Vedi se riesci a trovare modi per condividere il più possibile la proprietà con la tua comunità. Ecco alcune idee:
+
+* **Evita di correggere bug facili (non critici).** Usali invece come opportunità per reclutare nuovi contributori o fare da mentore a qualcuno che vorrebbe contribuire. All’inizio può sembrare innaturale, ma il tuo investimento verrà ripagato nel tempo. Ad esempio, @michaeljoseph ha chiesto a un collaboratore di inviare una richiesta pull per il problema [Cookiecutter](https://github.com/audreyr/cookiecutter) di seguito invece di risolverlo da solo.
+
+![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
+
+* **Avvia un file CONTRIBUTORI o AUTORI nel tuo progetto** che elenca tutti coloro che hanno contribuito al tuo progetto come [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
+
+* Se hai una community numerosa, **invia una newsletter o scrivi un post sul blog** ringraziando i contributori. [This Week in Rust](https://this-week-in-rust.org/) di Rust e [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) di Hood sono due ottimi esempi.
+
+* **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.
+
+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.
+
+Anche se potresti non trovare sempre qualcuno che risponda alla chiamata, diffondere il segnale aumenta le possibilità che altre persone vengano coinvolte. E prima inizi, prima le persone potranno aiutarti.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
+  \[Nel tuo\] miglior interesse è reclutare collaboratori che si divertano e siano capaci di fare cose che tu non sei. Ti piace programmare ma non rispondi alle domande? Quindi identifica le persone nella tua comunità che lo fanno e consenti loro di farlo.
+  <p markdown="1" class="pquote-credit">
+— @gr2m, ["Comunità accoglienti"](http://hood.ie/blog/welcoming-communities.html)
+  </p>
+</aside>
+
+## Risoluzione dei conflitti
+
+Nelle prime fasi del tuo progetto, prendere decisioni importanti è facile. Quando vuoi fare qualcosa, fallo e basta.
+
+Man mano che il tuo progetto diventa più popolare, sempre più persone saranno interessate alle decisioni che prendi. Anche se non hai una grande comunità di contributori, se il tuo progetto ha molti utenti, troverai persone che valutano soluzioni o sollevano i propri problemi.
+
+Nella maggior parte dei casi, se hai coltivato una comunità amichevole e rispettosa e hai documentato apertamente i tuoi processi, la tua comunità dovrebbe essere in grado di trovare una soluzione. Ma a volte ti imbatti in un problema un po’ più difficile da risolvere.
+
+### Stabilisci lo standard di civiltà
+
+Quando la tua comunità è alle prese con una questione difficile, il morale può risollevarsi. Le persone potrebbero arrabbiarsi o frustrarsi e prendersela con gli altri o con te.
+
+Il tuo compito come sostenitore è evitare che queste situazioni peggiorino. Anche se hai una forte opinione sulla questione, prova ad assumere la posizione di moderatore o facilitatore invece di buttarti nella mischia e promuovere le tue opinioni. Se qualcuno è scortese o monopolizza la conversazione, [agisci immediatamente](../building-community/#non-tollerare-i-cattivi-attori) per mantenere la discussione civile e produttiva.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
+  Essendo un progetto di supporto, è estremamente importante trattare i tuoi contributori con rispetto. Spesso prendono quello che dici in modo molto personale.
+  <p markdown="1" class="pquote-credit">
+— @kennethreitz, ["Sii cordiale o vai per la tua strada"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+  </p>
+</aside>
+
+Altre persone si rivolgono a te per avere una guida. Dai il buon esempio. Puoi ancora esprimere frustrazione, infelicità o preoccupazione, ma fallo con calma.
+
+Mantenere la calma non è facile, ma mostrare leadership migliora la salute della tua comunità. Internet ti ringrazia.
+
+### Tratta il tuo README come una costituzione
+
+Il tuo README è [più di un semplice insieme di istruzioni](../starting-a-project/#scrivi-readme). È anche un luogo in cui parlare dei tuoi obiettivi, della visione del prodotto e della tabella di marcia. Se le persone sono troppo concentrate nel discutere i meriti di una particolare funzionalità, potrebbe essere utile rivisitare il tuo README e parlare della visione più elevata del tuo progetto. Concentrarsi sul README spersonalizza anche la conversazione in modo da poter avere una discussione costruttiva.
+
+### Concentrati sul viaggio, non sulla destinazione
+
+Alcuni progetti utilizzano un processo di voto per prendere decisioni importanti. Anche se a prima vista ragionevole, il voto enfatizza il raggiungimento di una "risposta" piuttosto che l'ascolto e la considerazione delle preoccupazioni degli altri.
+
+Il voto può diventare politico quando i membri della comunità si sentono spinti a fare favori o a votare in un certo modo. Non tutti votano, siano essi [la maggioranza silenziosa](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) nella tua comunità o tra gli utenti attuali che non sapevano che fosse in corso una votazione.
+
+A volte è richiesto un voto di parità. Tuttavia, per quanto puoi, enfatizza ["la ricerca del consenso"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), piuttosto che consenso.
+
+In un processo di ricerca del consenso, i membri della comunità discutono le preoccupazioni chiave finché non sentono di essere stati adeguatamente ascoltati. Quando rimangono solo preoccupazioni secondarie, la comunità va avanti. La ricerca del consenso riconosce che una comunità potrebbe non essere in grado di arrivare a una risposta perfetta. Invece, dà priorità all’ascolto e alla discussione.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
+  ЧParte del motivo per cui non esiste un sistema di voto per gli argomenti Atom è che il team Atom non seguirà un sistema di voto in tutti i casi. A volte dobbiamo scegliere ciò che riteniamo giusto, anche se non è popolare. (...) Ciò che posso offrire e mi impegno a fare... è che il mio lavoro è ascoltare la comunità.
+  <p markdown="1" class="pquote-credit">
+— @lee-dohm sul processo decisionale di Atom
+  </p>
+</aside>
+
+Anche se in realtà non adotti un processo di ricerca del consenso, come progetto di supporto è importante che le persone sappiano che stai ascoltando. Far sì che le altre persone si sentano ascoltate e impegnate a risolvere le loro preoccupazioni è molto utile per allentare la tensione in situazioni delicate. Quindi segui le tue parole con l'azione.
+
+Non affrettarti a prendere una decisione per il gusto di prendere una decisione. Assicurati che tutti si sentano ascoltati e che tutte le informazioni siano condivise prima di passare a una decisione.
+
+### Mantieni la conversazione focalizzata sull'azione
+
+La discussione è importante, ma esiste una differenza tra conversazioni produttive e improduttive.
+
+Incoraggiare la discussione fintanto che si muove attivamente verso la risoluzione. Se è chiaro che la conversazione sta morendo o sta andando fuori tema, che il fastidio sta diventando personale o che le persone litigano su dettagli minori, è ora di chiuderla.
+
+Consentire che queste conversazioni continuino non è solo dannoso per il problema in questione, ma anche per la salute della tua comunità. Invia il messaggio che questo tipo di conversazione è consentito o addirittura incoraggiato e potrebbe scoraggiare le persone dal sollevare o risolvere problemi futuri.
+
+Per ogni punto sollevato da te o da altri, chiediti: "In che modo questo ci avvicina a una soluzione?"_
+
+Se la conversazione inizia a sgretolarsi, chiedi al gruppo _"Quali passi dovremmo intraprendere dopo?"_ per reindirizzare la conversazione.
+
+Se la conversazione non sta chiaramente andando da nessuna parte, non c'è alcuna azione chiara da intraprendere o l'azione appropriata è già stata intrapresa, chiudi il problema e spiega perché l'hai chiuso.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Rendere utile un thread senza essere invadente è un'arte. Dire semplicemente alle persone di smettere di sprecare il loro tempo o chiedere loro di non postare a meno che non abbiano qualcosa di costruttivo da dire non funzionerà. (...) Bisogna invece offrire le condizioni per ulteriori progressi: dare alle persone una rotta, un percorso da seguire che porti ai risultati desiderati, ma senza dare l'impressione di dettare comportamenti.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Produzione OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+  </p>
+</aside>
+
+### Scegli saggiamente le tue battaglie
+
+Il contesto è importante. Considera chi partecipa alla conversazione e come rappresenta il resto della comunità.
+
+Tutti nella comunità sono sconvolti o addirittura preoccupati per questo? Oppure è un piantagrane solitario? Ricorda di considerare i membri silenziosi della tua comunità, non solo le voci attive.
+
+Se il problema non rappresenta le esigenze più ampie della tua comunità, potresti dover semplicemente accogliere le preoccupazioni di alcune persone. Se si tratta di un problema ricorrente senza una soluzione chiara, rimandali alle discussioni precedenti sull'argomento e chiudi l'argomento.
+
+### Definire il criterio di equilibrio comunitario
+
+Con un buon comportamento e una comunicazione chiara, le situazioni più difficili vengono risolte. Tuttavia, anche in una discussione produttiva, potrebbe esserci semplicemente una divergenza di opinioni su come procedere. In questi casi, identifica una persona o un gruppo di persone che possano fungere da equilibratore.
+
+Un livellatore può essere il principale sostenitore del progetto, oppure può essere un piccolo gruppo di persone che prendono una decisione in base a un voto. Idealmente, è necessario definire un livellatore e la procedura associata in un file GOVERNANCE prima di doverlo utilizzare.
+
+La decisione sulla parità dovrebbe essere l'ultima risorsa. Le questioni di divisione rappresentano un’opportunità per la tua comunità di crescere e imparare. Cogli queste opportunità e utilizza un processo collaborativo per procedere verso la risoluzione quando possibile.
+
+## La community è ❤️ open source
+
+Comunità sane e fiorenti alimentano le migliaia di ore investite ogni settimana nell'open source. Molti contributori citano altre persone come motivo per lavorare - o non lavorare - con l'open source. Imparando a sfruttare questo potere in modo costruttivo, aiuterai qualcuno a vivere un'esperienza open source indimenticabile.
diff --git a/_articles/it/code-of-conduct.md b/_articles/it/code-of-conduct.md
new file mode 100644
index 00000000000..1459c665d5e
--- /dev/null
+++ b/_articles/it/code-of-conduct.md
@@ -0,0 +1,113 @@
+---
+lang: it
+title: Il tuo codice di condotta
+description: Facilitare un comportamento comunitario sano e costruttivo adottando e applicando un codice di condotta.
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+  - building
+  - leadership
+---
+
+## Perché ho bisogno di un codice di condotta?
+
+Un codice di condotta è un documento che definisce le aspettative comportamentali dei partecipanti al tuo progetto. L’adozione e l’applicazione di un codice di condotta può contribuire a creare un’atmosfera sociale positiva per la tua comunità.
+
+I codici di condotta aiutano a proteggere non solo i tuoi partecipanti ma anche te stesso. Se stai portando avanti un progetto, potresti scoprire che l'atteggiamento improduttivo degli altri partecipanti può farti sentire svuotato o insoddisfatto del tuo lavoro nel tempo.
+
+Un Codice di condotta ti consente di facilitare un comportamento sano e costruttivo nella comunità. Essere proattivi riduce le probabilità che tu o gli altri vi stanchiate del vostro progetto e vi aiuta ad agire quando qualcuno fa qualcosa con cui non siete d'accordo.
+
+## Stabilire un codice di condotta
+
+Cerca di creare un codice di condotta il prima possibile: idealmente quando crei per la prima volta il tuo progetto.
+
+Oltre a comunicare le vostre aspettative, il codice di condotta descrive quanto segue:
+
+* Dove entra in vigore il codice di condotta _(solo per problemi e pull request o attività della community come eventi?)_
+* A chi si applica il codice di condotta _(membri della comunità e sostenitori, ma per quanto riguarda gli sponsor?)_
+* Cosa succede se qualcuno infrange il codice di condotta
+* Come qualcuno può segnalare violazioni
+
+Usa la tecnica precedente dove puoi. [Accordo dei contributori](https://contributor-covenant.org/) è un codice di comportamento utilizzato da oltre 40.000 progetti open source, inclusi Kubernetes, Rails e Swift.
+
+[Il codice di condotta di Django](https://www.djangoproject.com/conduct/) e [Il codice di condotta dei cittadini](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sono due buoni esempi di codice di condotta.
+
+Inserisci un file CODE_OF_CONDUCT nella directory principale del tuo progetto e rendilo visibile alla tua comunità collegandolo dal tuo file CONTRIBUTING o README.
+
+## Decidi come applicherai il tuo codice di condotta
+<aside markdown="1" class="pquote">
+  Un codice di condotta non applicato (o inapplicabile) è peggio di nessun codice di condotta: invia il messaggio che i valori del codice di condotta non sono realmente importanti o rispettati nella tua comunità.
+  <p markdown="1" class="pquote-credit">
+— [Iniziativa di Ada](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+  </p>
+</aside>
+
+È necessario spiegare come verrà applicato il codice di condotta **_prima_** di una violazione. Ci sono diversi motivi per farlo:
+
+* Dimostra che sei seriamente intenzionato ad agire quando necessario.
+
+* La tua comunità si sentirà più sicura che i reclami vengano effettivamente esaminati.
+
+* Assicurerai alla tua comunità che il processo di revisione è giusto e trasparente nel caso in cui si trovassero indagati per una violazione.
+
+Dovresti fornire alle persone un modo personale (ad esempio un indirizzo e-mail) per segnalare una violazione del codice di condotta e spiegare chi riceve tale segnalazione. Potrebbe trattarsi di un manutentore, di un gruppo di manutentori o di un gruppo di lavoro sul codice di condotta.
+
+Ricorda che qualcuno può chiedere di segnalare una violazione a una persona che riceve queste segnalazioni. In questo caso, date loro la possibilità di segnalare le violazioni a qualcun altro. Ad esempio, @ctb e @mr-c [spiegano il loro progetto](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Casi di abuso, molestie o comportamenti altrimenti inaccettabili possono essere segnalati inviando un'e-mail a **khmer-project@idyll.org** solo a C. Titus Brown e Michael R. Crusoe. Per segnalare un problema con uno di questi, inviare un'e-mail a **Judi Brown Clarke, Ph.D.** Direttore della Diversità presso il BEACON Center for the Study of Evolution in Action, NSF Science and Technology Center.*
+
+Per trovare ispirazione, consulta il [manuale di applicazione delle norme](https://www.djangoproject.com/conduct/enforcement-manual/) di Django (anche se potresti non aver bisogno di qualcosa di così completo, a seconda delle dimensioni del tuo progetto).
+
+## Applicare il codice di condotta
+
+A volte, nonostante i tuoi migliori sforzi, qualcuno fa qualcosa che viola questo codice. Esistono diversi modi per affrontare un comportamento negativo o dannoso quando si verifica.
+
+### Raccogli informazioni sulla situazione
+
+Considera la voce di ogni membro della comunità importante quanto la tua. Se ricevi una segnalazione secondo cui qualcuno ha violato il codice di condotta, prendila sul serio e indaga sulla questione, anche se non corrisponde alla tua esperienza con quella persona. Ciò segnala alla tua comunità che apprezzi la loro prospettiva e ti fidi del loro giudizio.
+
+Il membro della comunità in questione potrebbe essere un recidivo che mette costantemente a disagio gli altri, o potrebbe aver detto o fatto qualcosa solo una volta. In entrambi i casi, possono costituire motivo di azione a seconda del contesto.
+
+Prima di rispondere, concediti il ​​tempo di capire cosa è successo. Leggi i commenti e le conversazioni passate della persona per capire meglio chi è e perché potrebbe essersi comportato in quel modo. Prova a raccogliere punti di vista diversi dal tuo su questa persona e sul suo comportamento.
+
+<aside markdown="1" class="pquote">
+  Non entrare in una discussione. Non esitare ad affrontare il comportamento di qualcun altro prima di aver finito di esaminare la questione. Concentrati su ciò di cui hai bisogno.
+  <p markdown="1" class="pquote-credit">
+— Stephanie Zvan, ["Quindi avete una politica. E adesso?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+  </p>
+</aside>
+
+### Intraprendi le azioni appropriate
+
+Una volta raccolte ed elaborate informazioni sufficienti, dovrai decidere cosa fare. Mentre consideri i passaggi successivi, ricorda che il tuo obiettivo come moderatore è promuovere un ambiente sicuro, rispettoso e collaborativo. Considera non solo come gestire la situazione in questione, ma anche come la tua risposta influenzerà il comportamento e le aspettative del resto della tua comunità in futuro.
+
+Quando qualcuno segnala una violazione del codice di condotta, è compito tuo, non suo, occupartene. A volte un giornalista rivela informazioni che mettono a grave rischio la sua carriera, reputazione o incolumità fisica. Costringerli ad affrontare il loro aggressore può mettere il giornalista in una posizione compromettente. È necessario mantenere una comunicazione diretta con la persona in questione, a meno che chi ha segnalato non richieda espressamente il contrario.
+
+Esistono diversi modi per rispondere a una violazione del codice di condotta:
+
+* **Dai alla persona in questione un avvertimento pubblico** e spiega come il suo comportamento ha influenzato negativamente gli altri, preferibilmente nel canale in cui è successo. Quando possibile, la comunicazione pubblica comunica al resto della comunità che si prende sul serio il codice di condotta. Sii gentile ma fermo nella tua comunicazione.
+
+* **Contatta di persona la persona in questione** per spiegare in che modo il suo comportamento ha influenzato negativamente gli altri. Potresti voler utilizzare un canale di comunicazione privato se la situazione coinvolge informazioni personali sensibili. Se stai comunicando con qualcuno in privato, è una buona idea mettere in copia coloro che per primi hanno segnalato la situazione in modo che sappiano che hai preso provvedimenti. Chiedere il consenso all'informatore prima di inviarlo in CC.
+
+A volte non è possibile raggiungere alcuna soluzione. La persona in questione può diventare aggressiva o ostile quando confrontata o non cambiare il proprio comportamento. In questa situazione, potresti prendere in considerazione l’idea di intraprendere azioni più drastiche. Per esempio:
+
+* **Espulsione della persona in questione** dal progetto, imposta tramite un'interdizione temporanea dalla partecipazione a qualsiasi aspetto del progetto
+
+* **Permanente** banna la persona dal progetto
+
+L’esclusione dei membri non dovrebbe essere presa alla leggera e rappresenta una divergenza di opinioni permanente e inconciliabile. Dovresti adottare queste misure solo quando è chiaro che non è possibile raggiungere una soluzione.
+
+## Le tue responsabilità come manutentore
+
+Un codice di condotta non è una legge applicata arbitrariamente. Tu sei il garante del codice di condotta ed è tua responsabilità seguire le regole stabilite dal codice di condotta.
+
+In qualità di manutentore, stabilisci le linee guida per la tua comunità e applichi tali linee guida secondo le regole stabilite nel tuo codice di condotta. Ciò significa prendere sul serio ogni segnalazione di violazione del codice di condotta. Al giornalista è dovuta un'analisi approfondita e corretta della sua denuncia. Se ritieni che il comportamento segnalato non costituisca una violazione, chiariscilo e spiega perché non intendi intraprendere alcuna azione in merito. Ciò che fanno dipende da loro: tollerare il comportamento con cui hanno avuto problemi o smettere di partecipare alla comunità.
+
+Segnalare un comportamento che _tecnicamente_ non viola il codice di condotta può comunque indicare che c'è un problema nella tua comunità e dovresti indagare su quel potenziale problema e agire di conseguenza. Ciò potrebbe comportare la revisione del codice di condotta per chiarire quale sia il comportamento accettabile e/o parlare alla persona il cui comportamento è stato segnalato e dirle che, sebbene non abbia violato il codice di condotta, sta aggirando il limite di ciò che ci si aspetta e assicurarsi che i partecipanti si sentano a disagio.
+
+In definitiva, come sostenitore, definisci e applichi gli standard di comportamento accettabile. Hai la capacità di plasmare i valori della comunità del progetto e i partecipanti si aspettano che tu applichi tali valori in modo giusto ed equo.
+
+## Incoraggia il comportamento che vuoi vedere nel mondo 🌎
+
+Quando un progetto appare ostile o inospitale, anche se si tratta di una sola persona il cui comportamento è tollerato dagli altri, rischi di perdere molti altri contributori, alcuni dei quali potresti non incontrare nemmeno. Non è sempre facile adottare o far rispettare un codice di condotta, ma promuovere un ambiente accogliente aiuterà la tua comunità a crescere.
diff --git a/_articles/it/finding-users.md b/_articles/it/finding-users.md
new file mode 100644
index 00000000000..6eedbf024c0
--- /dev/null
+++ b/_articles/it/finding-users.md
@@ -0,0 +1,148 @@
+---
+lang: it
+title: Trovare utenti per il tuo progetto
+description: Aiuta il tuo progetto open source a crescere mettendolo nelle mani di utenti soddisfatti.
+class: finding
+order: 3
+image: /assets/images/cards/finding.png
+related:
+  - beginners
+  - building
+---
+
+## Diffondere la parola
+
+Non esiste una regola che dice che devi pubblicizzare un progetto open source al momento del lancio. Ci sono molte buone ragioni per passare all'open source che non hanno nulla a che fare con la popolarità. Invece di sperare che altri trovino e utilizzino il tuo progetto open source, dovresti spargere la voce sul tuo duro lavoro!
+
+## Trasmetti il ​​tuo messaggio
+
+Prima di iniziare il lavoro vero e proprio di promozione del tuo progetto, devi essere in grado di spiegare cosa fa e perché è importante.
+
+Cosa rende il tuo progetto diverso o interessante? Perché l'hai creato? Rispondere solo a queste domande ti aiuterà a comunicare l’importanza del tuo progetto.
+
+Ricorda che le persone vengono coinvolte come utenti e alla fine diventano contributori perché il tuo progetto risolve loro un problema. Mentre pensi al messaggio e al valore del tuo progetto, prova a vederlo attraverso la lente di ciò che _utenti e contributori_ potrebbero desiderare.
+
+Ad esempio, @robb utilizza esempi di codice per comunicare chiaramente perché il suo progetto, [Cartography](https://github.com/robb/Cartography), è utile:
+
+![Cartography README](/assets/images/finding-users/cartography.jpg)
+
+Per un approfondimento sulla messaggistica, consulta l'esercizio ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) di Mozilla sullo sviluppo dei personaggi degli utenti.
+
+## Aiuta le persone a trovare e seguire il tuo progetto
+
+<aside markdown="1" class="pquote">
+  Idealmente, hai bisogno di un URL "home" che puoi promuovere e indirizzare le persone al tuo progetto. Non devi preoccuparti di un modello fantasioso o addirittura di un nome di dominio, ma il tuo progetto ha bisogno di un punto focale.
+  <p markdown="1" class="pquote-credit">
+— Peter Cooper & Robert Nyman, ["Come distribuire le informazioni sul tuo codice"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+  </p>
+</aside>
+
+Aiuta le persone a trovare e ricordare il tuo progetto indirizzandole a un singolo spazio dei nomi.
+
+**Avere un approccio chiaro per promuovere il tuo lavoro.** Un handle di Twitter, un URL GitHub o un canale IRC è un modo semplice per indirizzare le persone al tuo progetto. Questi punti vendita forniscono anche un luogo di ritrovo per la crescente comunità del tuo progetto.
+
+Se ancora non vuoi creare output per il tuo progetto, promuovi il tuo account Twitter o GitHub in tutto ciò che fai. Promuovere il tuo Twitter o GitHub permetterà alle persone di sapere come contattarti o seguire il tuo lavoro. Se parli a una riunione o a un evento, assicurati che le informazioni di contatto siano incluse nella biografia o nelle diapositive.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
+  Un errore che ho commesso in quei primi giorni (...) è stato non creare un account Twitter per il progetto. Twitter è un ottimo modo per mantenere le persone informate su un progetto e per esporre costantemente le persone alle informazioni sul progetto.
+  <p markdown="1" class="pquote-credit">
+— @nathanmarz, ["Storia di Apache Storm e lezioni apprese"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+  </p>
+</aside>
+
+**Considera l'idea di creare un sito web per il tuo progetto.** Un sito web rende il tuo progetto più user-friendly e facile da navigare, soprattutto se abbinato a documentazione e tutorial chiari. Avere un sito web suggerisce anche che il tuo progetto è attivo, il che farà sentire il tuo pubblico più a suo agio nell'utilizzarlo. Fornisci esempi per dare alle persone idee su come utilizzare il tuo progetto.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), сco-creatore di Django, ha detto che il sito web è stato _"di gran lunga la cosa migliore che abbiamo fatto con Django nei primi giorni"_.
+
+Se il tuo progetto è ospitato su GitHub, puoi utilizzare [GitHub Pages](https://pages.github.com/) per creare facilmente un sito web. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) e [Middleman](https://middlemanapp.com/) sono [alcuni esempi](https://github.com/showcases/github-pages-examples) di siti Web eccellenti e completi.
+
+![Pagina iniziale di Vagrant](/assets/images/finding-users/vagrant_homepage.png)
+
+Ora che hai un annuncio sul tuo progetto e un modo semplice per consentire alle persone di trovarlo, usciamo e parliamo con il tuo pubblico!
+
+## Vai dove si trova il pubblico del tuo progetto (online)
+
+La sensibilizzazione online è un ottimo modo per condividere e spargere rapidamente la voce. Utilizzando i canali online, hai il potenziale per raggiungere un pubblico molto vasto.
+
+Sfrutta le community e le piattaforme online esistenti per raggiungere il tuo pubblico. Se il tuo progetto open source è un progetto software, probabilmente puoi trovare il tuo pubblico in [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/) o [Quora](https://www.quora.com/). Trova i canali in cui ritieni che le persone trarranno maggiori benefici o saranno entusiaste del tuo lavoro.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
+  Ogni programma ha funzionalità molto specifiche che solo una minoranza di utenti troverà utili. Non inviare spam a quante più persone possibile. Concentra invece i tuoi sforzi sulle comunità che trarranno beneficio dalla conoscenza del tuo progetto.
+  <p markdown="1" class="pquote-credit">
+— @pazdera, ["Marketing per progetti open source"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+  </p>
+</aside>
+
+Vedi se riesci a trovare modi per condividere il tuo progetto in modi appropriati:
+
+* **Conosci progetti e comunità open source rilevanti.** A volte non è necessario pubblicizzare direttamente il tuo progetto. Se il tuo progetto è perfetto per i data scientist che utilizzano Python, consulta la community di data science di Python. Man mano che le persone ti conosceranno, ci saranno opportunità naturali per parlare e condividere il tuo lavoro.
+* **Trova persone che affrontano il problema risolto dal tuo progetto.** Cerca nei forum correlati le persone che rientrano nel pubblico target del tuo progetto. Rispondi alla loro domanda e trova un modo discreto, se appropriato, per presentare il tuo progetto come soluzione.
+* **Chiedi feedback.** Presenta te stesso e il tuo lavoro a un pubblico che lo troverà pertinente e interessante. Sii specifico su chi ritieni trarrà beneficio dal tuo progetto. Prova a completare la frase: _"Penso che il mio progetto aiuterà davvero X persone che stanno cercando di fare Y_". Ascolta e rispondi al feedback degli altri invece di limitarti a promuovere il tuo lavoro.
+
+In generale, concentrati sull’aiutare gli altri prima di chiedere qualcosa in cambio. Dato che chiunque può facilmente pubblicizzare un progetto online, ci sarà molto fermento. Per distinguerti dalla massa, dai alle persone un contesto su chi sei, non solo cosa vuoi.
+
+Se nessuno presta attenzione o risponde al tuo contatto iniziale, non scoraggiarti! La maggior parte dei lanci di progetti sono un processo iterativo che può richiedere mesi o anni. Se non ricevi risposta la prima volta, prova una tattica diversa o cerca prima modi per aggiungere valore al lavoro degli altri. Promuovere e lanciare il tuo progetto richiede tempo e dedizione.
+
+## Vai dove si trova il pubblico del tuo progetto (offline)
+
+![Discorso pubblico](/assets/images/finding-users/public_speaking.jpg)
+
+Gli eventi offline sono un modo popolare per promuovere nuovi progetti al pubblico. Sono un ottimo modo per raggiungere un pubblico coinvolto e creare connessioni umane più profonde, soprattutto se sei interessato a raggiungere gli sviluppatori.
+
+Se sei [nuovo nel parlare in pubblico](https://Speaking.io/), inizia trovando un incontro locale correlato alla lingua o all'ecosistema del tuo progetto.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
+  Ero piuttosto nervoso andando a PyCon. Stavo tenendo una conferenza, avrei incontrato solo poche persone lì, sono andato per un'intera settimana. (...) Non avrei dovuto preoccuparmi però. PyCon è stato straordinariamente fantastico! (...) Tutti erano incredibilmente cordiali e socievoli, tanto che raramente avevo il tempo di non parlare con la gente!
+  <p markdown="1" class="pquote-credit">
+— @jhamrick, ["Come ho imparato a smettere di preoccuparmi e ad amare PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+  </p>
+</aside>
+
+Se non hai mai parlato a un evento prima, è del tutto normale sentirsi nervoso! Ricorda che il tuo pubblico è lì perché vuole davvero conoscere il tuo lavoro.
+
+Mentre scrivi il tuo discorso, concentrati su ciò che il tuo pubblico troverà interessante e da cui trarrà beneficio. Mantieni il tuo linguaggio amichevole e accessibile. Sorridi, respira e divertiti.
+
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
+  Quando inizi a scrivere il tuo discorso, indipendentemente dall'argomento, può essere utile vedere il tuo discorso come una storia da raccontare alla gente.
+  <p markdown="1" class="pquote-credit">
+— Lena Reinhard, ["Come preparare e scrivere un discorso di conferenza tecnica"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+  </p>
+</aside>
+
+Quando ti senti pronto, considera di parlare a una conferenza per promuovere il tuo progetto. Le conferenze possono aiutarti a raggiungere più persone, a volte da tutto il mondo.
+
+Cerca conferenze specifiche per la tua lingua o ecosistema. Prima di inviare il tuo discorso, fai ricerche sulla conferenza per adattare il tuo discorso ai tuoi partecipanti e aumentare le tue possibilità di essere accettato a parlare alla conferenza. Spesso puoi farti un'idea del tuo pubblico guardando i relatori della conferenza.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
+  Ho scritto molto gentilmente al personale di JSConf e ho chiesto loro di darmi un posto dove avrei potuto presentarlo al JSConf EU. (...) Avevo una grandissima paura nel presentare questa cosa su cui stavo lavorando da sei mesi. (...) Per tutto il tempo ho pensato, oh mio Dio. Cosa sto facendo qui?
+  <p markdown="1" class="pquote-credit">
+— @ry, ["История на Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+  </p>
+</aside>
+
+## Costruisci una reputazione
+
+Oltre alle strategie sopra descritte, il modo migliore per invitare le persone a condividere e contribuire al tuo progetto è condividere e contribuire ai loro progetti.
+
+Aiutare i nuovi arrivati, condividere risorse e contribuire in modo ponderato ai progetti di altre persone ti aiuterà a costruire una reputazione positiva. Essere un membro attivo della comunità open source aiuterà le persone a trovare un contesto per il tuo lavoro e ad essere più propense a prestare attenzione e a condividere il tuo progetto. Lo sviluppo di collegamenti con altri progetti open source può anche portare a partenariati formali.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
+  L'unico motivo per cui urllib3 è oggi la libreria Python di terze parti più popolare è perché fa parte delle richieste.
+  <p markdown="1" class="pquote-credit">
+— @shazow, ["Come far prosperare il tuo progetto open source"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+  </p>
+</aside>
+
+Non è mai troppo presto o troppo tardi per iniziare a costruire la tua reputazione. Anche se hai già avviato il tuo progetto, continua a cercare modi per aiutare gli altri.
+
+Non esiste una soluzione immediata per creare un pubblico. Guadagnarsi la fiducia e il rispetto degli altri richiede tempo e costruire la propria reputazione non finisce mai.
+
+## Continuare!
+
+Può volerci molto tempo prima che le persone notino il tuo progetto open source. Questo è buono! Alcuni dei progetti più popolari oggi hanno impiegato anni per raggiungere livelli elevati di attività. Concentrati sulla costruzione di relazioni invece di sperare che il tuo progetto ottenga spontaneamente popolarità. Sii paziente e continua a condividere il tuo lavoro con chi lo apprezza.
\ No newline at end of file
diff --git a/_articles/it/getting-paid.md b/_articles/it/getting-paid.md
new file mode 100644
index 00000000000..7f35ab451ad
--- /dev/null
+++ b/_articles/it/getting-paid.md
@@ -0,0 +1,178 @@
+---
+lang: it
+title: Essere pagati per il lavoro open source
+description: Mantieni il tuo lavoro open source ottenendo supporto finanziario per il tuo tempo o il tuo progetto.
+class: getting-paid
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+  - best-practices
+  - leadership
+---
+
+## Perché alcune persone cercano un sostegno finanziario
+
+Gran parte del lavoro open source è volontario. Ad esempio, qualcuno potrebbe imbattersi in un bug in un progetto che sta utilizzando e inviare una soluzione rapida, oppure potrebbe divertirsi armeggiare con un progetto open source nel tempo libero.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
+Stavo cercando un progetto di programmazione "hobby" per tenermi occupato durante la settimana intorno a Natale. (...) Avevo tra le mani un computer di casa e nient'altro. Ho deciso di scrivere un interprete per il nuovo linguaggio di scripting a cui ho pensato ultimamente. (...) Ho scelto Python come titolo provvisorio.
+  <p markdown="1" class="pquote-credit">
+— @gvanrossum, ["Programmazione di Python"](https://www.python.org/doc/essays/foreword/)
+  </p>
+</aside>
+
+Ci sono molte ragioni per cui non si vorrebbe essere pagati per il proprio lavoro open source.
+
+* **Potrebbero già avere un lavoro a tempo pieno che amano,** che consente loro di contribuire all'open source nel tempo libero.
+* **A loro piace pensare all'open source come a un hobby** o a una fuga creativa e non vogliono sentirsi finanziariamente obbligati a lavorare sui propri progetti.
+* **Ottengono altri vantaggi dal contributo all'open source,** come costruire una reputazione o un portfolio, apprendere nuove competenze o sentirsi vicini a una comunità.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
+  Le donazioni finanziarie aggiungono un senso di responsabilità per alcuni. (...) È importante per noi, nel mondo globalmente connesso e frenetico in cui viviamo, poter dire "non ora, voglio fare qualcosa di completamente diverso".
+  <p markdown="1" class="pquote-credit">
+— @alloy, ["Perchè non accettiamo donazioni?"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+  </p>
+</aside>
+
+Per altri, soprattutto quando il contributo è in corso o richiede molto tempo, essere pagati per contribuire all'open source è l'unico modo per partecipare, sia perché il progetto lo richiede sia per motivi personali.
+
+Mantenere progetti popolari può essere una responsabilità significativa, impiegando 10 o 20 ore a settimana invece di poche ore al mese.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
+  Chiedi a qualsiasi sostenitore di progetti open source e ti diranno la realtà della quantità di lavoro necessaria per gestire un progetto. Hai clienti. Risolvi i problemi per loro. Crei nuove funzionalità. Diventa una vera e propria richiesta del tuo tempo.
+  <p markdown="1" class="pquote-credit">
+— @ashedryden, ["L'etica del lavoro non retribuito e la comunità OSS"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+  </p>
+</aside>
+
+Il lavoro retribuito consente inoltre a persone provenienti da percorsi di vita diversi di dare un contributo significativo. Alcune persone non possono permettersi di dedicare tempo non retribuito a progetti open source a causa della loro attuale situazione finanziaria, dei debiti, delle responsabilità familiari o di altro tipo. Ciò significa che il mondo non vede mai contributi da parte di persone di talento che non possono permettersi di offrire volontariato. Ciò ha implicazioni etiche, come @ashedryden [descritto](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) poiché il lavoro svolto è distorto nel favorire coloro che hanno già vantaggi nella vita, che poi ricevono ulteriori vantaggi in base ai loro contributi volontari, mentre ad altri che non possono fare volontariato vengono negate opportunità successive, rafforzando l'attuale mancanza di diversità nella comunità open source.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
+   L’OSS apporta enormi vantaggi al settore tecnologico, che a loro volta si traducono in vantaggi per tutti i settori. (...) Tuttavia, se le uniche persone che riescono a focalizzarsi su di esso sono i fortunati e gli ossessionati, allora c'è un enorme potenziale non sfruttato.
+  <p markdown="1" class="pquote-credit">
+— @isaacs, ["Soldi e open source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+  </p>
+</aside>
+
+Se stai cercando un sostegno finanziario, ci sono due modi da considerare. Puoi finanziare il tuo tempo come collaboratore oppure puoi trovare finanziamenti organizzativi per il progetto.
+
+## Finanziare il proprio tempo
+
+Oggi molte persone vengono pagate per lavorare part-time o full-time nell’open source. Il modo più comune per essere pagato per il tuo tempo è parlare con il tuo datore di lavoro.
+
+È più semplice sostenere il lavoro open source se il tuo datore di lavoro utilizza effettivamente il progetto, ma sii creativo con la tua presentazione. Forse il tuo datore di lavoro non utilizza il progetto, ma usa Python e il mantenimento di un progetto Python popolare aiuta ad attrarre nuovi sviluppatori Python. Forse fa sembrare il tuo datore di lavoro più amichevole agli sviluppatori in generale.
+
+Se non hai un progetto open source esistente su cui ti piacerebbe lavorare, ma preferisci che il tuo lavoro attuale sia open source, chiedi al tuo datore di lavoro di rendere open source alcuni dei loro software interni.
+
+Molte aziende stanno sviluppando programmi open source per rafforzare il proprio marchio e assumere talenti di qualità.
+
+@hueniverse ad esempio, ha scoperto che c'erano ragioni finanziarie per giustificare [l'investimento di Walmart nell'open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). E @jamesgpearce ha scoperto che il programma open source di Facebook [è importante](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) nel reclutamento:
+
+> È strettamente correlato alla nostra cultura hacker e al modo in cui la nostra organizzazione veniva percepita. Abbiamo chiesto ai nostri dipendenti: "Conoscevi il programma software open source di Facebook?". Due terzi hanno detto "Sì". La metà ha affermato che il programma ha contribuito positivamente alla decisione di lavorare per noi. Questi non sono numeri estremi e spero che la tendenza continui.
+
+Se la tua azienda segue questa strada, è importante mantenere chiari i confini tra le operazioni comunitarie e aziendali. Dopotutto, l'open source è supportato dal contributo di persone di tutto il mondo, e questo è più grande di quello di qualsiasi altra azienda o luogo.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
+  Essere pagati per un lavoro open source è un'opportunità rara e meravigliosa, ma non devi rinunciare alla tua passione nel processo. La tua passione dovrebbe essere il motivo per cui le aziende vogliono pagarti.
+  <p markdown="1" class="pquote-credit">
+— @jessfraz, ["Linee sfocate"](https://blog.jessfraz.com/post/blurred-lines/)
+  </p>
+</aside>
+
+Se non riesci a convincere il tuo attuale datore di lavoro a dare priorità al lavoro open source, valuta la possibilità di trovare un nuovo datore di lavoro che incoraggi il contributo dei dipendenti all'open source. Cerca aziende che sottolineano il loro impegno verso l'open source. Per esempio:
+
+* Ad alcune aziende piace [Netflix](https://netflix.github.io/) o [PayPal](https://paypal.github.io/), hanno siti web che evidenziano il loro coinvolgimento nell'open source
+* [Zalando](https://opensource.zalando.com) пdivulga la sua [politica di contributo open source](https://opensource.zalando.com/docs/using/contributing/) per i dipendenti
+
+È probabile che anche i progetti che provengono da una grande azienda, come [Go](https://github.com/golang) o [React](https://github.com/facebook/react), assumano persone per lavorare con l'open source.
+
+A seconda delle tue circostanze personali, puoi provare a raccogliere fondi in modo indipendente per finanziare il tuo lavoro open source. Per esempio:
+
+* @Homebrew (e [molti altri sostenitori e organizzazioni](https://github.com/sponsors/community)) finanziano il loro lavoro tramite [Sponsor Github](https://github.com/sponsors)
+* @gaearon ha finanziato il suo lavoro su [Redux](https://github.com/reactjs/redux) attraverso una [campagna di crowdfunding Patreon](https://redux.js.org/)
+* I fondi @andrewgodwin lavorano sulle migrazioni dello schema Django [tramite campagna Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+Infine, a volte i progetti open source offrono premi per problemi che potresti considerare di aiutare.
+
+* @ConnorChristie è riuscito a essere pagato per [aiuto](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F% 2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol sta lavorando sulla propria libreria JavaScript [tramite ricompensa gitcoin](https://gitcoin.co/).
+* @mamiM ha realizzato traduzioni giapponesi per @MetaMask dopo [il rilascio è stato finanziato da Bounties Network](https://explorer.bounties.network/bounty/134).
+
+## Trovare finanziamenti per il tuo progetto
+
+Oltre agli accordi per i singoli contributori, i progetti a volte raccolgono fondi da aziende, individui o altri per finanziare il lavoro in corso.
+
+I finanziamenti organizzativi possono essere utilizzati per pagare i contributori attuali, coprire i costi di gestione del progetto (come le tariffe di hosting) o investire in nuove funzionalità o idee.
+
+Con la crescente popolarità dell’open source, trovare finanziamenti per i progetti è ancora sperimentale, ma esistono alcune opzioni comuni.
+
+### Raccogli fondi per il tuo lavoro attraverso il crowdfunding o campagne di sponsorizzazione
+
+Trovare una sponsorizzazione funziona bene se hai già un pubblico o una reputazione forti o se il tuo progetto è molto popolare.
+Alcuni esempi di progetti sponsorizzati includono:
+
+* **[webpack](https://github.com/webpack)** raccoglie denaro da aziende e privati ​​[via OpenCollective](https://opencollective.com/webpack)
+* **[Ruby Together](https://rubytogether.org/),** organizzazione no-profit che paga il lavoro di [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems) e altri progetti infrastrutturali di Ruby
+
+### Crea un flusso di reddito
+
+A seconda del tuo progetto, potresti essere in grado di addebitare il supporto commerciale, le opzioni di hosting o le funzionalità aggiuntive. Alcuni esempi includono:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** offre versioni a pagamento per ulteriore supporto
+* **[Travis CI](https://github.com/travis-ci)** offre versioni a pagamento del suo prodotto
+* **[Ghost](https://github.com/TryGhost/Ghost)** è un'organizzazione no-profit con un servizio gestito a pagamento
+
+Alcuni progetti popolari, come [npm](https://github.com/npm/cli) e [Docker](https://github.com/docker/docker), stanno addirittura raccogliendo capitali di rischio per sostenere la crescita di i loro affari.
+
+### Richiedi un finanziamento
+
+Alcune fondazioni e aziende di software offrono sovvenzioni per il lavoro open source. A volte le sovvenzioni possono essere pagate a individui senza creare un'entità legale per il progetto.
+
+* **[Leggi i documenti](https://github.com/rtfd/readthedocs.org)** ha ricevuto una sovvenzione da [Support of Mozilla Open Source](https://www.mozilla.org/en-US/grants/)
+* Il lavoro su **[OpenMRS](https://github.com/openmrs)** è finanziato dall'[Open Source Retreat of Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** ha ricevuto una sovvenzione dalla [Fondazione Sloan](https://sloan.org/programs/digital-technology)
+* **[Python Software Foundation](https://www.python.org/psf/grants/)** offre sovvenzioni per lavori legati a Python
+
+Per opzioni più dettagliate e casi di studio @nayafia [ha scritto una guida](https://github.com/nayafia/lemonade-stand) su come essere pagato per il lavoro open source. Diversi tipi di finanziamento richiedono competenze diverse, quindi considera i tuoi punti di forza per scoprire quale opzione funziona meglio per te.
+
+## Costruire una causa per il sostegno finanziario
+
+Che il tuo progetto sia una nuova idea o sia in circolazione da anni, dovresti aspettarti di dedicare molta attenzione all'identificazione del finanziatore target e alla presentazione di un caso convincente.
+
+Sia che tu voglia pagare per il tuo tempo libero o raccogliere fondi per un progetto, devi essere in grado di rispondere alle seguenti domande.
+
+### Impatto
+
+Perchè è utile questo progetto? Perché piace così tanto ai tuoi utenti o potenziali utenti? Dove sarà tra cinque anni?
+
+### Trazione
+
+Cerca di raccogliere prove dell'importanza del tuo progetto, che si tratti di parametri, aneddoti o testimonianze. Ci sono aziende o persone importanti che utilizzano il tuo progetto in questo momento? In caso contrario, una persona di spicco lo ha approvato?
+
+### Valore per il finanziatore
+
+Ai finanziatori, siano essi il tuo datore di lavoro o una fondazione che concede sovvenzioni, vengono spesso offerte opportunità. Perché dovrebbero sostenere il tuo progetto rispetto a qualsiasi altra opzione? Come ne traggono beneficio personalmente?
+
+### Utilizzo dei fondi
+
+Cosa otterrete esattamente con il finanziamento proposto? Concentrarsi sulle tappe fondamentali o sui risultati finali del progetto piuttosto che sul pagamento di uno stipendio.
+
+### Come riceverai i fondi
+
+Il finanziatore ha dei requisiti di rimborso? Ad esempio, potrebbe essere necessario essere un'organizzazione senza scopo di lucro o avere uno sponsor fiscale senza scopo di lucro. O forse i fondi dovrebbero essere assegnati a un singolo appaltatore piuttosto che a un’organizzazione. Questi requisiti variano tra i finanziatori, quindi assicurati di fare le tue ricerche in anticipo.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
+  Per anni siamo stati la risorsa principale per le icone ottimizzate per i siti Web, con una community di oltre 20 milioni di persone e presenti su oltre 70 milioni di siti Web, incluso Whitehouse.gov. (...) La versione 4 risale a tre anni fa. La tecnologia web è cambiata molto da allora e, a dire il vero, Font Awesome è invecchiato. (...) Ecco perché stiamo introducendo Font Awesome 5. Stiamo modernizzando e riscrivendo i CSS e rifacendo ogni icona dall'alto verso il basso. Stiamo parlando di un design migliore, di una migliore coerenza e di una migliore leggibilità.
+  <p markdown="1" class="pquote-credit">
+— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+  </p>
+</aside>
+
+## Sperimenta e non mollare
+
+Raccogliere fondi non è facile, che tu sia un progetto open source, un'organizzazione no profit o una startup di software, e nella maggior parte dei casi richiede che tu sia creativo. Determinare come vuoi essere pagato, fare le tue ricerche e metterti nei panni del tuo finanziatore ti aiuterà a costruire un caso convincente per il finanziamento.
diff --git a/_articles/it/how-to-contribute.md b/_articles/it/how-to-contribute.md
new file mode 100644
index 00000000000..5462d85c9d2
--- /dev/null
+++ b/_articles/it/how-to-contribute.md
@@ -0,0 +1,526 @@
+---
+lang: it
+title: Come contribuire all'open source
+description: Vuoi contribuire all'open source? Una guida per fornire contributi open source sia per principianti che per veterani.
+class: contribute
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+  - beginners
+  - building
+---
+
+## Perché contribuire all'Open Source?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
+  Lavorare su \[freenode\] mi ha aiutato ad acquisire molte delle competenze che poi ho utilizzato per i miei studi universitari e per il mio lavoro vero e proprio. Penso che lavorare su progetti open source mi aiuti tanto quanto il progetto stesso!
+  <p markdown="1" class="pquote-credit">
+— [@errietta](https://github.com/errietta), ["Защо обичам да допринасям за софтуер с отворен код"](https://www.errietta.me/blog/open-source/)
+  </p>
+</aside>
+
+Contribuire all'open source può essere un modo gratificante per apprendere, insegnare e sviluppare competenze in quasi tutte le competenze immaginabili.
+
+Perché le persone contribuiscono all'open source? Molte ragioni!
+
+### Migliora il software su cui fai affidamento
+
+Molti contributori open source iniziano come utenti del software a cui contribuiscono. Quando trovi un bug nel software open source che stai utilizzando, potresti voler guardare la fonte per vedere se puoi risolverlo da solo. Se questo è il caso, ripristinare la patch è il modo migliore per garantire che i tuoi amici (e te stesso quando aggiorni alla versione successiva) possano trarne vantaggio.
+
+### Migliorare le competenze esistenti
+
+Che si tratti di codifica, progettazione dell'interfaccia utente, progettazione grafica, scrittura o organizzazione, se stai cercando pratica, c'è un progetto open source adatto a te.
+
+### Incontra persone interessate a cose simili
+
+I progetti open source con comunità calorose e accoglienti fanno sì che le persone ritornino per anni. Molte persone stringono amicizie durature attraverso la loro partecipazione all'open source, sia che si incontrino alle conferenze o alle chat di burrito online a tarda notte.
+
+### Trova mentori e insegna agli altri
+
+Lavorare con altri su un progetto condiviso significa che dovrai spiegare come stai facendo le cose e chiedere aiuto ad altre persone. Gli atti di apprendimento e insegnamento possono essere un'attività soddisfacente per tutti i soggetti coinvolti.
+
+### Costruisci artefatti pubblici che ti aiutino a sviluppare una reputazione (e una carriera)
+
+Per definizione, tutto il tuo lavoro open source è pubblico, il che significa che ottieni esempi gratuiti da portare ovunque come dimostrazione di ciò che sai fare.
+
+### Impara le abilità delle persone
+
+L'open source offre opportunità per esercitare capacità di leadership e gestione, come la risoluzione dei conflitti, l'organizzazione di gruppi di persone e la definizione delle priorità del lavoro.
+
+### Essere in grado di apportare cambiamenti, anche piccoli, dà potere
+
+Non è necessario essere un collaboratore permanente per apprezzare la partecipazione all'open source. Hai mai visto un errore di battitura su un sito web e vorresti che qualcuno lo correggesse? In un progetto open source, puoi fare proprio questo. L’open source aiuta le persone a sentirsi indipendenti riguardo alla propria vita e al modo in cui sperimentano il mondo, e questo di per sé è soddisfacente.
+
+## Cosa significa contribuire
+
+Se sei un nuovo collaboratore open source, il processo può creare confusione. Come trovi il progetto giusto? E se non sai programmare? E se qualcosa va storto?
+
+Non preoccuparti! Esistono molti modi per essere coinvolti in un progetto open source e alcuni suggerimenti ti aiuteranno a ottenere il massimo dalla tua esperienza.
+
+### Non è necessario aggiungere alcun codice
+
+Un malinteso comune riguardo al contributo all'open source è che si debba contribuire con il codice. In effetti, sono spesso le altre parti del progetto ad essere [più trascurate o trascurate](https://github.com/blog/2195-the-shape-of-open-source). Farai un _enorme_ favore al progetto offrendoti di contribuire con questo tipo di contributi!
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
+  Sono conosciuto per il mio lavoro su CocoaPods, ma la maggior parte delle persone non sa che in realtà non svolgo alcun lavoro reale sullo strumento CocoaPods stesso. Il mio tempo nel progetto è dedicato principalmente a cose come la documentazione e il lavoro di branding.
+  <p markdown="1" class="pquote-credit">
+— [@orta](https://github.com/orta), ["Преминаване към OSS по подразбиране"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+  </p>
+</aside>
+
+Anche se ti piace scrivere codice, altri tipi di contributi sono un ottimo modo per essere coinvolto in un progetto e incontrare altri membri della comunità. Costruire queste relazioni ti darà l’opportunità di lavorare su altre parti del progetto.
+
+### Ti piace pianificare eventi?
+
+* Organizzare workshop o incontri per il progetto, [come ha fatto @fzamperin per NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Organizzare una conferenza di progetto (se applicabile)
+* Aiuta i membri della comunità a trovare le conferenze giuste e a inviare proposte di interventi
+
+### Ti piace progettare?
+
+* Ristrutturare i layout per migliorare l'usabilità del progetto
+* Condurre ricerche sugli utenti per riorganizzare e perfezionare la navigazione o i menu del progetto, [come suggerito da Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Compila una guida di stile per aiutare il progetto ad avere un design visivo coerente
+* Crea una grafica per la maglietta o un nuovo logo, [come hanno fatto i contributori di hapi.js](https://github.com/hapijs/contrib/issues/68)
+
+### Ti piace scrivere?
+
+* Scrivi e migliora la documentazione del progetto, [come ha fatto @CBID2 per la documentazione di OpenSauced](https://github.com/open-sauced/docs/pull/151)
+* Preparare una cartella di esempi che mostrano come viene utilizzato il progetto
+* Avvia una newsletter del progetto o cura i punti salienti della mailing list, [come ha fatto @opensauced per il suo prodotto](https://news.opensauced.pizza/about/)
+* Scrivi tutorial per il progetto, [come hanno fatto i contributori PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Scrivi una traduzione per la documentazione del progetto, [come ha fatto @frontendwizard per le istruzioni CSS Flexbox della sfida freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
+  Seriamente, la \[documentazione\] è estremamente importante. La documentazione finora è stata eccezionale ed è una caratteristica fondamentale di Babel. Ci sono sezioni che potrebbero sicuramente funzionare, e anche aggiungere un paragrafo qua o là è molto apprezzato.
+  <p markdown="1" class="pquote-credit">
+— @kittens, ["Invito per contribuire"](https://github.com/babel/babel/issues/1347)
+  </p>
+</aside>
+
+### Ti piace organizzare?
+
+* Collegamento a problemi duplicati e suggerimento di nuovi thread di problemi per mantenerti organizzato
+* Esamina i problemi aperti e suggerisci di chiudere quelli vecchi, [come ha fatto @nzakas per ESLint](https://github.com/eslint/eslint/issues/6765)
+* Fai domande chiarificatrici sui problemi appena scoperti per portare avanti la discussione
+
+### Ti piace programmare?
+
+* Trova un problema aperto da risolvere, [come ha fatto @dianjin per Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Chiedi se puoi aiutare a registrare una nuova funzionalità
+* Automatizza le impostazioni del progetto
+* Migliorare strumenti e test
+
+### Ti piace aiutare le persone?
+
+* Rispondi alle domande sul progetto, ad es. Stack Overflow ([come questo esempio di Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) o Reddit
+* Rispondi alle domande delle persone in domande aperte
+* Aiuta a moderare forum di discussione o canali di chat
+
+### Ti piace aiutare gli altri a programmare?
+
+* Rivedi il codice delle dichiarazioni di altre persone
+* Scrivi tutorial su come utilizzare un progetto
+* Offrirti di fare da mentore a un altro collaboratore, [come ha fatto @ereichert per @bronzdoc in Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### Non devi lavorare solo su progetti software!
+
+Sebbene "open source" si riferisca spesso al software, puoi collaborare praticamente su qualsiasi cosa. Ci sono libri, ricette, elenchi e lezioni che vengono sviluppati come progetti open source.
+
+Per esempio:
+
+* @sindresorhus preparare [un elenco di elenchi "grandi".](https://github.com/sindresorhus/awesome)
+* @h5bp mantenere un [elenco di potenziali domande per l'intervista](https://github.com/h5bp/Front-end-Developer-Interview-Questions) per i candidati sviluppatori front-end
+* @stuartlynn e @nicole-a-tesla hanno realizzato una [raccolta di curiosità sui puffini](https://github.com/stuartlynn/puffin_facts)
+
+Anche se sei uno sviluppatore di software, lavorare su un progetto di documentazione può aiutarti a iniziare con l'open source. Spesso è meno intimidatorio lavorare su progetti che non implicano codice e il processo collaborativo aumenterà la tua sicurezza e la tua esperienza.
+
+## Orientamento verso un nuovo progetto
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
+  Se vai a un rilevatore di problemi e le cose sembrano confuse, non sei solo tu. Questi strumenti richiedono molta conoscenza implicita, ma le persone possono aiutarti a esplorarli e puoi porre loro domande.
+  <p markdown="1" class="pquote-credit">
+— @shaunagm, ["Come contribuire all'open source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+  </p>
+</aside>
+
+Oltre a correggere un errore di battitura, contribuire all'open source è come avvicinarsi a un gruppo di sconosciuti a una festa. Se inizi a parlare dei lama mentre sono immersi in una discussione sui pesci rossi, probabilmente ti guarderanno in modo un po' strano.
+
+Prima di lanciarti alla cieca con i tuoi suggerimenti, inizia imparando a leggere la stanza. In questo modo aumenti le possibilità che le tue idee vengano notate e ascoltate.
+
+### Anatomia di un progetto open source
+
+Ogni comunità open source è diversa.
+
+Trascorrere anni su un progetto open source significa che hai acquisito familiarità con un progetto open source. Passa a un altro progetto e potresti scoprire che il vocabolario, le norme e gli stili di comunicazione sono completamente diversi.
+
+Tuttavia, molti progetti open source seguono una struttura organizzativa simile. Comprendere i diversi ruoli nella comunità e il processo complessivo ti aiuterà a navigare rapidamente in qualsiasi nuovo progetto.
+
+Un tipico progetto open source prevede i seguenti tipi di persone:
+
+* **Autore:** La/e persona/e o organizzazione che ha creato il progetto
+* **Proprietario:** la/e persona/e che ha la proprietà amministrativa dell'organizzazione o del repository (non sempre coincide con l'autore originale)
+* **Sostenitori:** Collaboratori responsabili della gestione della visione e della gestione degli aspetti organizzativi del progetto (possono anche essere autori o proprietari del progetto.)
+* **Contributori:** chiunque abbia contribuito con qualcosa al progetto
+* **Membri della comunità:** le persone che utilizzano il progetto. Possono essere attivi nelle conversazioni o esprimere la loro opinione sulla direzione del progetto
+
+I progetti più grandi possono anche avere sottocomitati o gruppi di lavoro focalizzati su compiti diversi, come strumenti, smistamento, moderazione della comunità e organizzazione di eventi. Cerca nel sito web di un progetto una pagina "team" o il repository della documentazione di gestione per trovare queste informazioni.
+
+C'è anche la documentazione del progetto. Questi file sono generalmente elencati al livello più alto del repository.
+
+* **LICENZA:** Per definizione, ogni progetto open source deve avere una [licenza open source](https://choosealicense.com). Se il progetto non ha una licenza, non è open source.
+* **README:** Il README è la guida pratica che accoglie i nuovi membri della comunità nel progetto. Spiega perché il progetto è utile e come iniziare.
+* **CONTRIBUTO:** Mentre i README aiutano le persone a _utilizzare_ il progetto, i documenti che contribuiscono aiutano le persone a _contribuire_ al progetto. Spiega quali tipi di contributi sono richiesti e come funziona il processo. Anche se non tutti i progetti hanno un file CONTRIBUTOR, la sua presenza segnala che è un progetto accogliente a cui contribuire. Un buon esempio di guida ai contributi efficace sarebbe questo dal [repository di documenti Codecademy](https://www.codecademy.com/resources/docs/contribution-guide).
+* **CODE_OF_CONDUCT:** Il Codice di condotta stabilisce le regole di base per la condotta associata dei partecipanti e aiuta a creare un ambiente amichevole e accogliente. Anche se non tutti i progetti hanno un file CODE_OF_CONDUCT, la sua presenza segnala che si tratta di un progetto accogliente a cui contribuire.
+* **Altra documentazione:** Potrebbe essere presente documentazione aggiuntiva come tutorial, istruzioni o politiche di gestione, in particolare per progetti più grandi come [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
+
+Infine, i progetti open source utilizzano i seguenti strumenti per organizzare la discussione. Leggere gli archivi ti darà una buona idea di come pensa e funziona la comunità.
+
+* **Tracciamento dei problemi:** dove le persone discutono questioni relative al progetto.
+* **Richieste pull:** quando le persone discutono e rivedono le modifiche in corso, sia che si tratti di migliorare l'ordine del codice dei contributori, l'utilizzo della grammatica, l'utilizzo delle immagini, ecc. Alcuni progetti, come [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), utilizzano determinati flussi di azioni GitHub per automatizzare e velocizzare le loro revisioni del codice.
+* **Forum di discussione o mailing list:** Alcuni progetti possono utilizzare questi canali per argomenti di conversazione (ad esempio _"Come..."_ o _"Cosa ne pensi di..."_ invece di segnalazioni di bug o richieste per le funzioni). Altri utilizzano il tracker dei problemi per tutte le chiamate. Un buon esempio di ciò potrebbe essere la [newsletter settimanale CHAOSS](https://chaoss.community/news/)
+* **Canale di chat sincrono:** alcuni progetti utilizzano canali di chat (come Slack o IRC) per conversazioni informali, collaborazione e scambi rapidi. Un buon esempio di ciò potrebbe essere [EddieHub Discord Community](http://discord.eddiehub.org/).
+
+## Trova un progetto a cui contribuire
+
+Ora che hai capito come funzionano i progetti open source, è il momento di trovare un progetto a cui contribuire!
+
+Se non hai mai contribuito all'open source prima, segui il consiglio del presidente degli Stati Uniti John F. Kennedy, che una volta disse: "Non chiederti cosa può fare il tuo paese per te, chiediti cosa puoi fare tu per il tuo paese".
+
+<aside markdown="1" class="pquote">
+  <img src="/assets/images/how-to-contribute/johnfkennedy.jpg" class="pquote-avatar" alt="avatar">
+  Non chiederti cosa può fare il tuo Paese per te: chiediti cosa puoi fare tu per il tuo Paese.
+  <p markdown="1" class="pquote-credit">
+— [_Biblioteca John F. Kennedy_](https://www.jfklibrary.org/learn/education/teachers/curricular-resources/ask-not-what-your-country-can-do-for-you)
+  </p>
+</aside>
+
+Il contributo all'open source avviene a tutti i livelli, in tutti i progetti. Non devi pensare troppo a quale sarà esattamente il tuo primo contributo o come sarà.
+
+Inizia invece pensando ai progetti che già usi o che desideri utilizzare. I progetti a cui partecipi attivamente sono quelli a cui continui a tornare.
+
+All'interno di questi progetti, ogni volta che ti sorprendi a pensare che qualcosa potrebbe essere migliore o diverso, agisci secondo il tuo istinto.
+
+L'open source non è un club esclusivo; è fatto da persone proprio come te. "Open source" è solo un termine elegante per considerare i problemi del mondo come risolvibili.
+
+È possibile eseguire la scansione del README e trovare un collegamento interrotto o un errore di battitura. O sei un nuovo utente e hai notato che qualcosa non funziona, oppure c'è un problema che ritieni dovrebbe essere presente nella documentazione. Invece di ignorarlo e andare avanti o chiedere a qualcun altro di risolverlo, vedi se puoi aiutare partecipando. Ecco cos'è l'open source!
+
+> Secondo uno studio di Igor Steinmacher e altri ricercatori di informatica, [il 28% dei contributi accessori](https://www.igor.pro.br/publica/papers/saner2016.pdf) in open source sono documenti, come come correzioni di errori di battitura, riformattazione o scrittura di traduzioni.
+
+Se stai cercando problemi esistenti che puoi risolvere, ogni progetto open source ha una pagina "/contribute" che evidenzia problemi adatti ai principianti con cui puoi iniziare. Vai alla pagina principale del repository GitHub e aggiungi "/contribute" alla fine dell'URL (ad es.[`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+Puoi anche utilizzare una delle seguenti risorse per aiutarti a scoprire e contribuire a nuovi progetti:
+
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://opensauced.pizza/)
+
+### Lista di controllo prima di contribuire
+
+Quando trovi un progetto a cui vuoi contribuire, esegui una rapida scansione per assicurarti che il progetto sia idoneo ad accettare contributi. Altrimenti, il tuo duro lavoro potrebbe non ricevere mai risposta.
+
+Ecco una pratica lista di controllo per valutare se un progetto è adatto ai nuovi contributori.
+
+**Soddisfa la definizione di open source**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+  Ha la licenza? Di solito c'è un file chiamato LICENSE nella radice del repository.
+  </label>
+</div>
+
+**Il progetto accetta attivamente contributi**
+
+Guarda l'attività di commit sul ramo master. Su GitHub, puoi vedere queste informazioni nella scheda Approfondimenti della home page di un repository, ad esempio[Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+  Quando è stato l'ultimo fidanzamento?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+  Quanti collaboratori ha il progetto?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+  Quanto spesso le persone si impegnano? (Su GitHub, puoi trovarlo facendo clic su "Commit" nella barra in alto.)
+  </label>
+</div>
+
+Poi guarda i problemi del progetto.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Quante domande aperte ci sono?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    I manutentori sono rapidi nel rispondere ai problemi quando vengono sollevati?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    C’è una discussione attiva sulle questioni?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+    I problemi sono recenti?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    I problemi stanno finendo? (Su GitHub, fai clic sulla scheda "chiuso" nella pagina dei problemi per visualizzare i problemi chiusi.)
+  </label>
+</div>
+
+Ora fai lo stesso per le richieste pull del progetto.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    Quante richieste pull aperte ci sono?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox20" class="overflow-hidden d-block text-normal">
+    I manutentori rispondono rapidamente alle richieste pull quando vengono aperte?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Esiste una discussione attiva sulle richieste pull?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    Le richieste di download sono recenti?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox13" class="overflow-hidden d-block text-normal">
+    Quanto tempo fa sono state unite tutte le richieste pull? (Su GitHub, fai clic sulla scheda "chiuso" nella pagina Pull Requests per vedere i PR chiusi.)
+  </label>
+</div>
+
+**Il progetto è accogliente**
+
+Un progetto amichevole e accogliente segnala che saranno ricettivi verso nuovi collaboratori.
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox14" class="overflow-hidden d-block text-normal">
+    I manutentori rispondono in modo utile alle domande sui problemi?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox15" class="overflow-hidden d-block text-normal">
+    Le persone sono amichevoli nei problemi, nei forum di discussione e nelle chat (ad esempio IRC o Slack)?
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox16" class="overflow-hidden d-block text-normal">
+    Пvengono prese in considerazione le richieste pull?
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox17" class="overflow-hidden d-block text-normal">
+    I manutentori ringraziano le persone per i loro contributi?
+  </label>
+</div>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
+  Ogni volta che vedi un thread lungo, controlla a campione le risposte degli sviluppatori principali che arrivano alla fine del thread. Riassumono in modo costruttivo e adottano misure per portare il thread a una risoluzione pur rimanendo educati? Se vedi molte guerre di fiamma in corso, spesso è un segno che l'energia viene utilizzata nella discussione invece che nello sviluppo.
+  <p markdown="1" class="pquote-credit">
+— @kfogel, [_Produrre OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+  </p>
+</aside>
+
+## Come inviare un contributo
+
+Hai trovato un progetto che ti piace e sei pronto a contribuire. Finalmente! Ecco come ottenere il tuo contributo nel modo giusto.
+
+### Comunicazione effettiva
+
+Che tu collabori occasionalmente o cerchi di entrare a far parte di una comunità, lavorare con gli altri è una delle competenze più importanti che svilupperai nell'open source.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
+  \[Come nuovo collaboratore,\] mi sono reso conto subito che dovevo fare domande se volevo riuscire a chiudere la questione. Ho dato una rapida occhiata al codice base. Dopo aver percepito cosa stava succedendo, ho chiesto ulteriori indicazioni. E fatto! Sono riuscito a risolvere il problema dopo aver ottenuto tutti i dettagli di cui avevo bisogno.
+  <p markdown="1" class="pquote-credit">
+— @shubheksha, [Un viaggio molto accidentato per principianti attraverso il mondo dell'open source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+  </p>
+</aside>
+
+Prima di aprire un problema o una richiesta pull o porre una domanda in chat, tieni a mente questi punti per aiutare le tue idee a prendere vita in modo efficace.
+
+**Fornisci contesto.** Aiuta gli altri a salire a bordo rapidamente. Se riscontri un errore, spiega cosa stai cercando di fare e come riprodurlo. Se stai proponendo una nuova idea, spiega perché pensi che sarebbe utile per il progetto (non solo per te!).
+
+> 😇 _"X non accade quando faccio Y"_
+>
+> 😢 _"X è rotto! Per favore aggiustalo."_
+
+**Fai i compiti in anticipo.** Va bene non sapere le cose, ma dimostra che ci hai provato. Prima di chiedere aiuto, assicurati di controllare il README del progetto, la documentazione, i problemi (aperti o chiusi), la mailing list e cerca una risposta in Internet. Le persone apprezzeranno quando dimostrerai che stai cercando di imparare.
+
+> 😇 _"Non sono sicuro di come implementare X. Ho controllato i documenti di aiuto e non ho trovato alcuna menzione."_
+>
+> 😢 _"Come faccio X?"_
+
+**Mantieni le richieste brevi e dirette.** Come inviare un'email, qualsiasi contributo, non importa quanto semplice o utile, richiede che qualcun altro lo esamini. Molti progetti hanno più richieste in arrivo che persone che possono aiutare. Sii breve. Aumenterai le possibilità che qualcuno possa aiutarti.
+
+> 😇 _"Vorrei scrivere un tutorial API."_
+>
+> 😢 _"L'altro giorno stavo guidando lungo l'autostrada e mi sono fermato per fare benzina e poi ho avuto questa fantastica idea di qualcosa che dovremmo fare, ma prima di spiegartelo, lascia che te lo mostri..."_
+
+**Mantieni pubbliche tutte le comunicazioni.** Sebbene sia allettante, non contattare personalmente i manutentori a meno che non sia necessario condividere informazioni sensibili (come un problema di sicurezza o una cattiva condotta grave). Quando mantieni pubblica la conversazione, più persone possono imparare e trarre vantaggio dal tuo scambio. Le discussioni possono essere di per sé un contributo.
+
+> 😇 _(come commento) "@-maintainer Ciao! Come procediamo con questo PR?"_
+>
+> 😢 _(come email) "Ciao, scusa se ti disturbo via email, ma mi chiedevo se avessi la possibilità di rivedere il mio PR"_
+
+**Va bene fare domande (ma sii paziente!).** Tutti sono stati nuovi ad un progetto ad un certo punto, e anche i contributori più esperti devono aggiornarsi quando guardano un nuovo progetto. Allo stesso modo, anche i manutentori di lunga data non hanno sempre familiarità con ogni parte del progetto. Mostra loro la stessa pazienza che vorresti che mostrassero a te.
+
+> 😇 _"Grazie per aver esaminato questo errore. Ho seguito i tuoi suggerimenti. Ecco il risultato."_
+>
+> 😢 _"Perché non riesci a risolvere il mio problema? Non è questo il tuo progetto?"_
+
+**Rispetta le decisioni della comunità.** Le tue idee potrebbero differire dalle priorità o dalla visione della comunità. Potrebbero offrire feedback o decidere di non perseguire la tua idea. Anche se dovresti discutere e trovare un compromesso, i manutentori devono convivere con la tua decisione più a lungo di te. Se non sei d'accordo con la loro direzione, puoi sempre lavorare sul tuo fork o iniziare il tuo progetto.
+
+> 😇 _"Mi dispiace che tu non possa supportare il mio caso d'uso, ma come hai spiegato tu riguarda solo una piccola parte di utenti, capisco il motivo. Grazie per l'ascolto."_
+>
+> 😢 _"Perché non supporti il ​​mio caso d'uso? Questo è inaccettabile!"_
+
+**Soprattutto, mantienilo elegante.** L'open source è composto da contributori provenienti da tutto il mondo. Si perde il contesto tra lingue, culture, aree geografiche e fusi orari. Inoltre, la comunicazione scritta rende più difficile trasmettere il tono o l’umore. Assumi buone intenzioni in queste conversazioni. Va bene rifiutare educatamente un'idea, chiedere più contesto o chiarire ulteriormente la tua posizione. Prova solo a lasciare Internet in un posto migliore di quando l'hai trovato.
+
+### Raccogli il contesto
+
+Prima di agire, fai un rapido controllo per assicurarti che la tua idea non sia stata discussa altrove. Visualizza il README del progetto, i problemi (aperti e chiusi), la mailing list e Stack Overflow. Non devi passare ore a esaminare tutto, ma una rapida ricerca di alcuni termini chiave può fare molto.
+
+Se non riesci a trovare la tua idea altrove, sei pronto a fare una mossa. Se il progetto è su GitHub, probabilmente comunicherai nel modo seguente:
+
+* **Sollevare un problema:** è come avviare una conversazione o una discussione
+* **Le richieste pull** servono per iniziare a lavorare su una soluzione.
+* **Canali di comunicazione:** se il progetto ha un canale Discord, IRC o Slack designato, valuta la possibilità di avviare una conversazione o chiedere chiarimenti sul tuo contributo.
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
+  Imparerai <em>molto</em> prendendo un progetto che stai utilizzando attivamente, "guardandolo" su GitHub e leggendo ogni numero e PR.
+<p markdown="1" class="pquote-credit">
+— @gaearon [per partecipare ai progetti](https://twitter.com/dan_abramov/status/819555257055322112)
+  </p>
+</aside>
+
+### Apertura di un problema
+
+Di solito dovresti aprire un problema nelle seguenti situazioni:
+
+* Segnala un bug che non puoi risolvere da solo
+* Discutere un argomento o un'idea di alto livello (ad esempio comunità, visione o politiche)
+* Suggerisci una nuova funzionalità o un'altra idea di progetto
+
+Suggerimenti per comunicare sui problemi:
+
+* **Se vedi un problema aperto su cui vuoi lavorare**, commenta il problema per far sapere alle persone che ci stai lavorando. In questo modo, le persone avranno meno probabilità di duplicare il tuo lavoro.
+* **Se un problema è stato scoperto qualche tempo fa,** potrebbe essere stato risolto altrove o già risolto, quindi commenta per chiedere conferma prima di iniziare il lavoro.
+* **Se hai aperto un problema ma hai trovato la risposta da solo in seguito,** commenta il problema per farlo sapere alle persone, quindi chiudi il problema. Anche documentare questo risultato è un contributo al progetto.
+
+### Apertura di una richiesta pull
+
+Di solito dovresti aprire una richiesta pull nelle seguenti situazioni:
+
+* Invia correzioni minori come errori di battitura, collegamenti interrotti o errori evidenti.
+* Inizia a lavorare su un contributo che ti è già stato richiesto o di cui hai già parlato in un numero.
+
+Una richiesta pull non deve rappresentare un lavoro completato. Di solito è meglio aprire una richiesta pull in anticipo in modo che altri possano guardare o fornire feedback sui tuoi progressi. Basta aprirlo come "bozza" o contrassegnarlo come "WIP" (Lavori in corso) nella riga dell'oggetto o nelle sezioni "Note ai revisori" se fornite (oppure puoi semplicemente crearne una tua. In questo modo: `** # # Note per il revisore**`). Puoi sempre aggiungere altri impegni in un secondo momento.
+
+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/).)
+* **[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.
+* **Testa le tue modifiche!** Esegui le tue modifiche confrontandole con eventuali test esistenti, se presenti, e creane di nuovi quando necessario. È importante assicurarsi che le modifiche non interrompano il progetto esistente.
+* **Contribuisci allo stile del progetto** secondo le tue capacità. Ciò può significare utilizzare il rientro, il punto e virgola o i commenti in modo diverso rispetto a quanto faresti nel tuo repository, ma rende più facile per il manutentore unirli e per gli altri comprenderli e mantenerli in futuro.
+
+Se questa è la tua prima richiesta pull, dai un'occhiata a [Crea una richiesta pull](http://makeapullrequest.com/) che @kentcdodds ha creato come tutorial video dimostrativo. Puoi anche esercitarti a creare una richiesta pull sul repository [First Contributions](https://github.com/Roshanjossey/first-contributions) creato da @Roshanjossey.
+
+## Cosa succede dopo aver inviato il tuo contributo
+
+Prima di iniziare a festeggiare, dopo che avrai inviato il tuo contributo si verificherà una delle seguenti situazioni:
+
+### 😭 Non riceverai risposta
+
+Ci auguriamo che tu abbia [controllato eventuali segni di attività nel progetto](#lista-di-controllo-prima-di-contribuire) prima di contribuire. Anche con un progetto attivo, però, è possibile che il tuo contributo non riceva risposta.
+
+Se non ricevi notizie da più di una settimana, è giusto rispondere educatamente nello stesso thread chiedendo a qualcuno di recensire. Se conosci il nome della persona giusta per rivedere il tuo contributo, puoi @ menzionarla in questo thread.
+
+**Non contattare personalmente questa persona**; ricorda che la comunicazione pubblica è vitale per i progetti open source.
+
+Se fai un cortese promemoria e continui a non ricevere risposta, è possibile che nessuno risponderà mai. Non è una sensazione fantastica, ma non lasciarti scoraggiare! 😄 Esistono molte possibili ragioni per cui non hai ricevuto una risposta, comprese circostanze personali che potrebbero andare oltre il tuo controllo. Prova a trovare un altro progetto o un modo per contribuire. Se non altro, è un buon motivo per non investire troppo tempo nel contribuire prima che gli altri membri della comunità siano coinvolti e reattivi.
+
+### 🚧 Qualcuno vuole modifiche al tuo contributo
+
+È comune che ti venga chiesto di apportare modifiche al tuo contributo, che si tratti di feedback sulla portata della tua idea o di modifiche al tuo codice.
+
+Quando qualcuno chiede modifiche, sii reattivo. Si sono presi il tempo per rivedere il tuo contributo. Aprire un PR e andarsene è una cattiva forma. Se non sai come apportare modifiche, ricerca il problema e poi chiedi aiuto se ne hai bisogno. Un buon esempio di ciò potrebbe essere [il feedback che un altro collaboratore ha dato a @a-m-lamb sulla sua richiesta di pull ai documenti Codecademy](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286).
+
+Se non hai più tempo per lavorare sul problema perché la conversazione va avanti da mesi e le tue circostanze sono cambiate o non riesci a trovare una soluzione, informa un manutentore in modo che possa aprire il problema a qualcun altro , come ha fatto [@RitaDee per un problema nelle applicazioni OpenSauced](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).
+
+### 👎 Il tuo contributo non è accettato
+
+Il tuo contributo potrebbe essere accettato o meno alla fine. Spero che tu non ci abbia già dedicato troppo lavoro. Se non sei sicuro del motivo per cui non è stato accettato, è perfettamente ragionevole chiedere al manutentore feedback e chiarimenti. Alla fine, però, dovrai rispettare il fatto che è una loro decisione. Non discutere e non essere ostile. Sei sempre il benvenuto ad espanderti e lavorare sulla tua versione se non sei d'accordo!
+
+### 🎉 Il tuo contributo è accettato
+
+Evviva! Hai dato con successo un contributo open source!
+
+## Fallo! 🎉
+
+Se hai appena dato il tuo primo contributo open source o stai cercando nuovi modi per contribuire, speriamo che tu sia ispirato ad agire. Anche se il tuo contributo non è stato accettato, assicurati di dire grazie quando il manutentore ha fatto uno sforzo per aiutarti. L'open source è creato da persone come te: un problema, una richiesta pull, un commento o il cinque alla volta.
\ No newline at end of file
diff --git a/_articles/it/index.html b/_articles/it/index.html
new file mode 100644
index 00000000000..4944583ea67
--- /dev/null
+++ b/_articles/it/index.html
@@ -0,0 +1,7 @@
+---
+layout: index
+title: Guide Open Source
+lang: it
+permalink: /it/
+---
+
diff --git a/_articles/it/leadership-and-governance.md b/_articles/it/leadership-and-governance.md
new file mode 100644
index 00000000000..e2d0c9aca80
--- /dev/null
+++ b/_articles/it/leadership-and-governance.md
@@ -0,0 +1,156 @@
+---
+lang: it
+title: Leadership e governo
+description: I progetti open source in crescita possono trarre vantaggio da regole formali per prendere decisioni.
+class: leadership
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+  - best-practices
+  - metrics
+---
+
+## Comprendere la gestione del tuo progetto in crescita
+
+Il tuo progetto sta crescendo, le persone sono coinvolte e tu ti impegni a mantenere questa cosa. A questo punto, ti starai chiedendo come includere contributori regolari al progetto nel tuo flusso di lavoro, sia che si tratti di fornire accesso al commit o di risolvere i dibattiti della comunità. Se hai domande, abbiamo le risposte.
+
+## Quali sono esempi di ruoli formali utilizzati nei progetti open source?
+
+Molti progetti seguono una struttura simile per quanto riguarda i ruoli dei contributori e il riconoscimento.
+
+Il significato effettivo di questi ruoli, tuttavia, dipende interamente da te. Ecco alcuni tipi di ruoli che potresti riconoscere:
+
+* **Supporto**
+* **Associato**
+* **Committente**
+
+**Per alcuni progetti, i "sostenitori"** sono le uniche persone in un progetto con accesso come commit. In altri progetti, sono semplicemente le persone elencate nel README come manutentori.
+
+Un manutentore non deve essere qualcuno che scrive il codice per il tuo progetto. Potrebbe essere qualcuno che ha svolto molto lavoro per evangelizzare il tuo progetto o documentazione scritta che ha reso il progetto più accessibile agli altri. Indipendentemente da ciò che fa quotidianamente, un manutentore è probabilmente qualcuno che si sente responsabile della direzione del progetto e si impegna a migliorarlo.
+
+Un **"Collaboratore" può essere chiunque** commenti un problema o una richiesta pull, persone che aggiungono valore al progetto (che si tratti di valutare problemi, scrivere codice o organizzare eventi) o chiunque abbia una richiesta pull combinata (magari la definizione più ristretta di contributore).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
+  \[Per Node.js,\] ogni persona che sembra commentare un problema o inviare codice è un membro della comunità del progetto. Il solo fatto di poterli vedere significa che hanno superato il limite da utente a collaboratore.
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+  </p>
+</aside>
+
+**Il termine "agente"** può essere utilizzato per distinguere l'accesso all'impegno, che è un tipo specifico di responsabilità, da altre forme di contributo.
+
+Sebbene tu possa definire i ruoli del tuo progetto come desideri, [considera l'utilizzo di definizioni più ampie](../how-to-contribute/#cosa-significa-contribuire) per incoraggiare più forme di contributo. Puoi utilizzare i ruoli di leadership per riconoscere formalmente le persone che hanno apportato contributi eccezionali al tuo progetto, indipendentemente dalle loro competenze tecniche.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
+  Potresti conoscermi come l'"inventore" di Django... ma in realtà sono la persona che è stata assunta per lavorare su qualcosa un anno dopo che era già stato realizzato. (...) La gente sospetta che io abbia successo grazie alle mie capacità di programmazione... ma nella migliore delle ipotesi sono un programmatore medio.
+  <p markdown="1" class="pquote-credit">
+— @jacobian, ["Nota chiave di PyCon 2015" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+  </p>
+</aside>
+
+## Come formalizzo questi ruoli di leadership?
+
+Formalizzare i ruoli di leadership aiuta le persone a sentirsi proprietarie e dice agli altri membri della comunità a chi rivolgersi per chiedere aiuto.
+
+Per un progetto più piccolo, designare i leader può essere semplice come aggiungere i loro nomi al file di testo README o CONTRIBUTORS.
+
+Per un progetto più ampio, se hai un sito web, crea una pagina del team o elenca lì i tuoi project manager. Ad esempio, [Postgres](https://github.com/postgres/postgres/) ha una [pagina completa del team](https://www.postgresql.org/community/contributors/) con brevi profili di ciascun contributore.
+
+Se il tuo progetto ha una comunità di contributori molto attiva, puoi formare un "core team" di manutentori o anche sottocomitati di persone che si assumono la responsabilità di diverse aree problematiche (ad esempio sicurezza, classificazione dei problemi o comportamento della comunità). Consentire alle persone di auto-organizzarsi e fare volontariato per i ruoli che li appassionano di più, piuttosto che esternalizzarli.
+
+<aside markdown="1" class="pquote">
+  \[Noi\] integriamo la squadra principale con diverse "sotto-squadre". Ogni sottoteam si concentra su un'area specifica, come la progettazione del linguaggio o le biblioteche. (...) Per garantire un coordinamento globale e una visione forte e coerente per il progetto nel suo insieme, ogni sotto-team è guidato da un membro del team principale.
+  <p markdown="1" class="pquote-credit">
+— ["RFC per la gestione di Rust"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+  </p>
+</aside>
+
+I team dirigenti potrebbero voler creare un canale designato (come su IRC) o incontrarsi regolarmente per discutere del progetto (come su Gitter o Google Hangout). Puoi anche rendere pubbliche queste riunioni in modo che altre persone possano ascoltarle. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), ad esempio, [prende ore di lavoro ogni settimana](https://github.com/cucumber/cucumber-ruby/blob/HEAD/ CONTRIBUIRE .md#talking-with-other-devs).
+
+Una volta stabiliti i ruoli di leadership, assicurati di documentare come le persone possono raggiungerli! Stabilisci un processo chiaro su come qualcuno può diventare un sostenitore o unirsi a un sottocomitato nel tuo progetto e scrivilo nel tuo GOVERNANCE.md.
+
+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).
+
+## Quando dovrei dare a qualcuno l'accesso per impegnarsi?
+
+Alcune persone pensano che dovresti dare accesso al coinvolgimento a tutti coloro che danno un contributo. Ciò può incoraggiare più persone a sentirsi proprietarie del tuo progetto.
+
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
+  Ogni volta che qualcuno ti invia una richiesta pull, consentigli l'accesso al tuo progetto. Anche se all'inizio può sembrare incredibilmente sciocco, l'utilizzo di questa strategia ti consentirà di liberare il vero potere di GitHub. (...) Una volta che le persone hanno accesso al commit, non si preoccupano più che la loro correzione possa essere disgregata... il che li porta a dedicarci molto più lavoro.
+  <p markdown="1" class="pquote-credit">
+— @felixge, ["Хакът на заявка за изтегляне"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+  </p>
+</aside>
+
+## Quali sono alcune delle strutture di governance comuni per i progetti open source?
+
+Esistono tre strutture di governance generale associate ai progetti open source.
+
+* **BDFL:** BDFL sta per "Dittatore benevolo per la vita". In questa struttura, una persona (di solito l'autore originale del progetto) ha l'ultima parola su tutte le principali decisioni del progetto. [Python](https://github.com/python) è un classico esempio. I progetti più piccoli probabilmente utilizzano BDFL per impostazione predefinita perché ci sono solo uno o due manutentori. Anche un progetto che nasce da un'azienda può rientrare nella categoria BDFL.
+
+* **Meritocrazia:** (Nota: il termine "meritocrazia" ha connotazioni negative per alcune comunità e ha una [storia sociale e politica complessa](http://geekfeminism.wikia.com/wiki/Meritocracy).) ** Nella meritocrazia ai partecipanti attivi al progetto (coloro che dimostrano "merito") viene assegnato un ruolo decisionale formale. Le decisioni vengono solitamente prese sulla base del voto per puro consenso. Il concetto di meritocrazia è stato introdotto dalla [Fondazione Apache](https://www.apache.org/); [tutti i progetti Apache](https://www.apache.org/index.html#projects-list) sono meritocrazie. I contributi possono essere versati solo da individui che rappresentano se stessi e non da un'azienda.
+
+* **Contributo liberale:** In un modello di contribuzione liberale, le persone che lavorano di più sono riconosciute come le più influenti, ma questo si basa sul lavoro attuale, non sul contributo storico. Le decisioni sui grandi progetti vengono prese sulla base di un processo di ricerca del consenso (discussione delle principali lamentele) piuttosto che sul puro voto, e cercano di includere quante più prospettive comunitarie possibile. Esempi popolari di progetti che utilizzano un modello di contribuzione liberale includono [Node.js](https://foundation.nodejs.org/) e [Rust](https://www.rust-lang.org/).
+
+Quale dovresti usare? Sta a te! Ogni modello presenta vantaggi e compromessi. E anche se a prima vista possono sembrare molto diversi, tutti e tre i modelli hanno più cose in comune di quanto sembri. Se sei interessato ad adottare uno di questi modelli, dai un'occhiata a questi modelli:
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Ho bisogno di documenti gestionali quando inizio il mio progetto?
+
+Non esiste un momento giusto per scrivere la gestione del tuo progetto, ma è molto più semplice definirlo una volta che hai visto svolgersi le dinamiche della tua comunità. La parte migliore (e più difficile) della gestione open source è che è modellata dalla comunità!
+
+Tuttavia, alcuni dei primi documenti contribuiranno inevitabilmente alla gestione del progetto, quindi inizia a registrare ciò che puoi. Ad esempio, puoi definire aspettative chiare sul comportamento o sul funzionamento del processo di collaborazione, anche all'inizio del tuo progetto.
+
+Se fai parte di un'azienda che lancia un progetto open source, vale la pena tenere una discussione interna prima del lancio su come la tua azienda prevede di supportare e prendere decisioni sui progressi del progetto. Potresti anche voler spiegare pubblicamente qualcosa di specifico su come la tua azienda sarà (o non sarà!) coinvolta nel progetto.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
+  Assegniamo a piccoli team la gestione dei progetti GitHub che effettivamente lavorano su di essi su Facebook. Ad esempio, React è gestito da un ingegnere React.
+  <p markdown="1" class="pquote-credit">
+— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+  </p>
+</aside>
+
+## Cosa succede se i dipendenti aziendali iniziano a inviare contributi?
+
+I progetti open source di successo vengono utilizzati da molte persone e aziende e alcune aziende potrebbero finire per avere flussi di entrate che sono in definitiva legati al progetto. Ad esempio, un'azienda può utilizzare il codice di progetto come componente nell'offerta di un servizio commerciale.
+
+Man mano che il progetto diventa più diffuso, le persone con esperienza in esso diventano più richieste: potresti essere uno di loro! - e talvolta verranno pagati per il lavoro svolto sul progetto.
+
+È importante considerare l'attività commerciale come una cosa normale e semplicemente come un'altra fonte di energia per lo sviluppo. Naturalmente, gli sviluppatori pagati non dovrebbero ricevere un trattamento speciale rispetto a quelli non pagati; ogni contributo dovrebbe essere giudicato in base ai suoi meriti tecnici. Tuttavia, le persone dovrebbero sentirsi a proprio agio nell’impegnarsi in attività commerciali e sentirsi a proprio agio nel citare i propri casi d’uso quando si discute a favore di un particolare miglioramento o funzionalità.
+
+"Commerciale" è pienamente compatibile con "open source". "Commerciale" significa semplicemente che da qualche parte sono coinvolti dei soldi, che il software viene utilizzato commercialmente, il che è sempre più probabile man mano che un progetto ottiene l'accettazione. (Quando il software open source viene utilizzato come parte di un prodotto non open source, il prodotto complessivo è ancora software "proprietario", sebbene, come l'open source, possa essere utilizzato per scopi commerciali e non commerciali.)
+
+Come chiunque altro, gli sviluppatori motivati ​​dal punto di vista commerciale ottengono influenza nel progetto attraverso la qualità e la quantità del loro contributo. Ovviamente, un programmatore che viene pagato per il suo tempo può essere in grado di guadagnare più di qualcuno che non lo fa, ma va bene così: il pagamento è solo uno dei tanti possibili fattori che possono influenzare quanto qualcuno guadagna. Mantieni le discussioni del tuo progetto focalizzate sul contributo, non sui fattori esterni che consentono alle persone di dare quel contributo.
+
+## Ho bisogno di una persona giuridica per sostenere il mio progetto?
+
+Non hai bisogno di un'entità legale per supportare il tuo progetto open source a meno che non gestisci denaro.
+
+Ad esempio, se desideri avviare un'attività commerciale, ti consigliamo di costituire una C Corp o LLC (se risiedi negli Stati Uniti). Se stai solo lavorando a un contratto relativo al tuo progetto open source, puoi accettare denaro come unico proprietario o formare una LLC (se risiedi negli Stati Uniti).
+
+Se desideri accettare donazioni per il tuo progetto open source, puoi impostare un pulsante di donazione (utilizzando PayPal o Stripe, ad esempio), ma il denaro non sarà deducibile dalle tasse a meno che tu non sia un'organizzazione no-profit qualificata (501c3, se sei sono negli Stati Uniti).
+
+Molti progetti non vogliono prendersi la briga di creare un'organizzazione no-profit, quindi trovano invece uno sponsor fiscale senza scopo di lucro. Uno sponsor fiscale accetta donazioni per tuo conto, solitamente in cambio di una percentuale della donazione. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) e [Open Collective](https://opencollective.com/opensource) sono esempi di organizzazioni che fungono da sponsor fiscali per progetti open source.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
+  Il nostro obiettivo è fornire infrastrutture che le comunità possano utilizzare per essere autosostenibili, creando così un ambiente in cui tutti — contributori, sostenitori, sponsor — ne traggano benefici concreti.
+  <p markdown="1" class="pquote-credit">
+— @piamancini, ["Andare oltre la beneficenza"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+  </p>
+</aside>
+
+Se il tuo progetto è strettamente correlato a un particolare linguaggio o ecosistema, potrebbe esserci anche una base software associata con cui puoi lavorare. Ad esempio, la [Python Software Foundation](https://www.python.org/psf/) aiuta a supportare [PyPI](https://pypi.org/), il gestore pacchetti Python e [Node.js Foundation] (https://foundation.nodejs.org/) aiuta a mantenere [Express.js](https://expressjs.com/), un framework basato su Node.
diff --git a/_articles/it/legal.md b/_articles/it/legal.md
new file mode 100644
index 00000000000..6f0c1b50011
--- /dev/null
+++ b/_articles/it/legal.md
@@ -0,0 +1,160 @@
+---
+lang: it
+title: Il lato legale dell'open source
+description: Tutto quello che ti sei sempre chiesto riguardo al lato legale dell'open source e alcune cose che non ti sei chiesto.
+class: legal
+order: 10
+image: /assets/images/cards/legal.png
+related:
+  - contribute
+  - leadership
+---
+
+## Comprendere le implicazioni legali dell'open source
+
+Condividere il tuo lavoro creativo con il mondo può essere un'esperienza emozionante e gratificante. Può anche significare un sacco di cose legali di cui non sapevi di doverti preoccupare. Fortunatamente, con questa guida non è necessario ricominciare da zero. (Prima di approfondire, assicurati di leggere il nostro [disclaimer](/notices/).)
+
+## Perché le persone si preoccupano così tanto del lato legale dell'open source?
+
+Sono felice che tu l'abbia chiesto! Quando realizzi un'opera creativa (come scrittura, grafica o codice), quell'opera è protetta da copyright esclusivo per impostazione predefinita. Cioè, la legge presuppone che, come autore del tuo lavoro, tu abbia voce in capitolo su ciò che gli altri possono fare con esso.
+
+In genere, ciò significa che nessun altro può utilizzare, copiare, distribuire o modificare il tuo lavoro senza correre il rischio di rimozione, squalifica o contenzioso.
+
+Tuttavia, l'open source è una circostanza insolita perché l'autore si aspetta che altri utilizzino, modifichino e condividano il lavoro. Ma poiché il valore legale predefinito è ancora il diritto d'autore esclusivo, è necessario concedere esplicitamente queste autorizzazioni con una licenza.
+
+Queste regole si applicano anche quando qualcuno contribuisce al tuo progetto. Senza licenza o altro accordo, tutti i contributi sono di proprietà esclusiva dei loro autori. Ciò significa che nessuno – nemmeno tu – può utilizzare, copiare, distribuire o modificare il proprio contributo.
+
+Infine, il tuo progetto potrebbe avere dipendenze con requisiti di licenza di cui non eri a conoscenza. La comunità del tuo progetto o le politiche del tuo datore di lavoro potrebbero anche richiedere che il tuo progetto utilizzi licenze open source specifiche. Esamineremo queste situazioni di seguito.
+
+## Публичните 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**.
+
+![Crea un archivio](/assets/images/legal/repo-create-name.png)
+
+**Rendere pubblico il tuo progetto GitHub non equivale a concedergli una licenza.** I progetti pubblici sono coperti dai [Termini di servizio di GitHub](https://help.github.com/en/github/site-policy/github-Terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), che consente ad altri di rivedere e creare un fork del tuo progetto, ma per il resto il tuo lavoro arriva senza autorizzazioni.
+
+Se desideri che altri utilizzino, distribuiscano, modifichino o contribuiscano al tuo progetto, devi includere una licenza open source. Ad esempio, qualcuno non può utilizzare legalmente alcuna parte del tuo progetto GitHub nel proprio codice, anche se è pubblico, a meno che tu non gli conceda specificatamente il diritto di farlo.
+
+## Dammi solo un riepilogo di ciò di cui ho bisogno per proteggere il mio progetto.
+
+Sei fortunato perché oggi le licenze open source sono standardizzate e facili da usare. Puoi copiare e incollare una licenza esistente direttamente nel tuo progetto.
+
+[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/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
+  La licenza standardizzata funge da sostituto per coloro che non hanno una formazione legale per sapere esattamente cosa possono e non possono fare con il software. A meno che non sia assolutamente necessario, evitare termini personalizzati, modificati o non standard che costituiranno un ostacolo all'utilizzo del codice dell'agenzia a valle.
+  <p markdown="1" class="pquote-credit">
+— @benbalter, ["Tutto ciò che un avvocato governativo deve sapere sulle licenze open source"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+  </p>
+</aside>
+
+## Quale licenza open source è adatta al mio progetto?
+
+È difficile sbagliare con la [licenza MIT](https://choosealicense.com/licenses/mit/) se inizi con un foglio bianco. È breve, facile da capire e consente a chiunque di fare qualsiasi cosa purché conservi una copia della licenza, inclusa la nota sul copyright. Potrai rilasciare il progetto con una licenza diversa, se mai ne avessi bisogno.
+
+Altrimenti, la scelta della giusta licenza open source per il tuo progetto dipende dai tuoi obiettivi.
+
+Molto probabilmente il tuo progetto ha (o avrà) **dipendenze**, ognuna delle quali avrà la propria licenza open source con termini che dovrai rispettare. Ad esempio, se stai rendendo open source un progetto Node.js, probabilmente utilizzerai le librerie di Node Package Manager (npm).
+
+Dipendenze con **licenze permissive** come [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ ISC](https://choosealicense.com/licenses/isc) e [BSD](https://choosealicense.com/licenses/bsd-3-clause) ti consentono di concedere in licenza il tuo progetto come preferisci.
+
+Le dipendenze con **licenze di copyright** richiedono maggiore attenzione. Inclusa qualsiasi libreria con una licenza copyleft "forte" come [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), o [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) richiede la scelta di una licenza identica o [compatibile](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) per il tuo progetto. Librerie con una licenza copyleft "limitata" o "debole" come [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) e [LGPL](https://choosealicense.com/licenses/lgpl - 3.0/) può essere incluso in progetti con qualsiasi licenza, a condizione che si seguano le [regole aggiuntive](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) sottolineano.
+ 
+Puoi anche controllare le **community** che speri di utilizzare e contribuire al tuo progetto:
+
+* **Vuoi che il tuo progetto venga utilizzato come dipendenza da altri progetti?** Probabilmente è meglio utilizzare la licenza più popolare nella comunità pertinente. Ad esempio, [MIT](https://choosealicense.com/licenses/mit/) è la licenza più popolare per [librerie npm](https://libraries.io/search?platforms=NPM).
+* **Vuoi che il tuo progetto attiri le grandi imprese?** Le grandi imprese possono essere confortate da una licenza di brevetto espressa da parte di tutti i contributori. In tal caso, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) copre te (e loro).
+* **Vuoi che il tuo progetto attiri i contributori che non vogliono che i loro contributi vengano utilizzati in software closed source?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) o (se non vogliono contribuire ai servizi closed source) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) andrà benissimo.
+
+La tua **azienda** potrebbe avere politiche di licenza per progetti open source. Alcune aziende richiedono che i tuoi progetti abbiano una licenza permissiva per consentire l'integrazione con i prodotti proprietari dell'azienda. Altre politiche impongono una forte licenza copyleft e un accordo di collaborazione aggiuntivo (vedi sotto), in modo che solo la tua azienda possa utilizzare il progetto nel software closed source. Le organizzazioni possono anche avere determinati standard, obiettivi di responsabilità sociale o esigenze di trasparenza che potrebbero richiedere una strategia di licenza specifica. Rivolgiti a [l'ufficio legale della tua azienda](#il-mio-progetto-necessita-di-un-contratto-di-collaborazione-aggiuntivo) per ricevere assistenza.
+
+Quando crei un nuovo progetto su GitHub, ti viene data la possibilità di scegliere una licenza. Includere una delle licenze sopra menzionate renderà il tuo progetto GitHub open source. Se vuoi vedere altre opzioni, controlla [choosealicense.com](https://choosealicense.com) per trovare la licenza giusta per il tuo progetto, anche se è [non software](https://choosealicense.com/non-software/).
+
+## Cosa succede se voglio cambiare la licenza del mio progetto?
+
+Nella maggior parte dei progetti non è mai necessario modificare le licenze. Ma a volte le circostanze cambiano.
+
+Ad esempio, man mano che il tuo progetto cresce, aggiunge dipendenze o utenti oppure la tua azienda cambia strategie, ognuna delle quali potrebbe richiedere o richiedere una licenza diversa. Inoltre, se hai dimenticato di concedere la licenza al tuo progetto fin dall'inizio, aggiungere una licenza equivale praticamente a modificare le licenze. Ci sono tre cose principali da tenere a mente quando aggiungi o modifichi la licenza del tuo progetto:
+
+**È complicato.** Determinare la compatibilità e la conformità della licenza e chi possiede il copyright può diventare complicato e creare confusione molto rapidamente. Passare a una licenza nuova ma compatibile per nuove versioni e contributi è diverso dal concedere nuovamente in licenza tutti i contributi esistenti. Coinvolgi il tuo team legale al primo accenno di desiderio di modificare le licenze. Anche se hai o puoi ottenere il permesso dai detentori del copyright del tuo progetto per modificare la licenza, considera l'impatto della modifica sugli altri utenti e contributori al tuo progetto. Pensa a una modifica della licenza come a un "evento di gestione" per il tuo progetto, che è più probabile che si svolga senza intoppi con una comunicazione chiara e una consultazione con le parti interessate del progetto. Un motivo in più per scegliere e utilizzare una licenza adeguata per il tuo progetto fin dal suo inizio!
+
+**Licenza esistente del tuo progetto.** Se la licenza esistente del tuo progetto è compatibile con la licenza che desideri modificare, puoi semplicemente iniziare a utilizzare la nuova licenza. Questo perché se la licenza A è compatibile con la licenza B, rispetterai i termini di A rispettando allo stesso tempo i termini di B (ma non necessariamente il contrario). Pertanto, se stai attualmente utilizzando una licenza permissiva (ad esempio MIT), puoi passare a una licenza con più termini purché conservi una copia della licenza MIT e di eventuali avvisi di copyright associati (ovvero continui a rispettare i termini minimi della licenza licenza MIT). Ma se la tua licenza attuale non è permissiva (ad esempio copyleft o non hai una licenza) e non sei l'unico detentore del copyright, non puoi semplicemente cambiare la licenza del tuo progetto MIT. In sostanza, con una licenza permissiva, i detentori dei diritti d'autore del progetto hanno dato il permesso preventivo di modificare le licenze.
+
+**Detentori del copyright esistenti del tuo progetto.** Se sei l'unico collaboratore del tuo progetto, tu o la tua azienda siete gli unici detentori del copyright del progetto. Puoi aggiungere o modificare qualsiasi licenza tu o la tua azienda desideriate. In caso contrario, potrebbero esserci altri titolari di copyright di cui è necessario il consenso per modificare le licenze. Loro chi sono? [Le persone che si sono impegnate nel tuo progetto](https://github.com/thehale/git-authorship) è un buon punto di partenza. Ma in alcuni casi i diritti d'autore saranno detenuti dai datori di lavoro di quelle persone. In alcuni casi le persone avranno dato solo un contributo minimo, ma non esiste una regola ferrea secondo cui i contributi al di sotto di un certo numero di righe di codice non sono soggetti a copyright. Cosa fare? Dipende. Per un progetto relativamente piccolo e giovane, potrebbe essere possibile convincere tutti i contributori esistenti ad accettare una modifica della licenza in un problema o in una richiesta pull. Per progetti grandi e a lungo termine, potrebbe essere necessario cercare molti collaboratori e persino i loro successori. Mozilla ha impiegato anni (2001-2006) per concedere nuovamente la licenza a Firefox, Thunderbird e al relativo software.
+
+In alternativa, puoi chiedere ai contributori di pre-approvare alcune modifiche alla licenza tramite un contratto di collaborazione aggiuntivo ([vedi su](#quale-licenza-open-ource-è-datta-al-mio-progetto)). Ciò elimina parte della complessità della modifica delle licenze. Avrai bisogno di maggiore aiuto da parte dei tuoi avvocati in anticipo e vorrai comunque comunicare chiaramente con le parti interessate del progetto quando effettui una modifica della licenza.
+
+## 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).
+
+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.
+
+Inoltre, aggiungendo "documentazione" che alcuni ritengono non necessaria, difficile da comprendere o ingiusta (quando il destinatario dell'accordo ottiene più diritti dei contributori o del pubblico attraverso la licenza open source del progetto), un ulteriore accordo con il contributore può essere percepito come ostile alla comunità del progetto.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
+    Abbiamo rimosso il CLA per Node.js. Ciò riduce la barriera all’ingresso per i contributori di Node.js, espandendo così la base dei contributori.
+  <p markdown="1" class="pquote-credit">
+— @bcantrill, ["Estensione dei contributi Node.js"](https://www.joyent.com/blog/broadening-node-js-contributions)
+  </p>
+</aside>
+
+Alcune situazioni in cui potresti prendere in considerazione un accordo di collaborazione aggiuntivo per il tuo progetto includono:
+
+* I tuoi avvocati vogliono che tutti i contributori accettino esplicitamente (_firmano_, online o offline) i termini del contributo, forse perché ritengono che la licenza open source da sola non sia sufficiente (anche se lo è!). Se questa è l'unica preoccupazione, dovrebbe essere sufficiente un accordo di collaborazione che riconosca la licenza open source del progetto. Il contratto di licenza per collaboratore individuale jQuery è un buon esempio di contratto per collaboratore aggiuntivo leggero.
+* Tu o i tuoi avvocati volete che gli sviluppatori dichiarino che ogni impegno che assumono è autorizzato. Il requisito del [Certificato di origine dello sviluppatore](https://developercertificate.org/) indica quanti progetti raggiungono questo obiettivo. Ad esempio, la comunità Node.js [utilizza](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [invece di](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) dal loro precedente CLA. Una semplice opzione per automatizzare l'implementazione di DCO nel tuo repository è [DCO Probot](https://github.com/probot/dco).
+* Il tuo progetto utilizza una licenza open source che non include una concessione espressa di brevetto (come il MIT) e hai bisogno dell'autorizzazione al brevetto da parte di tutti i contributori, alcuni dei quali potrebbero lavorare per aziende con ampi portafogli di brevetti che potrebbero essere utilizzati per prendere di mira te o altri contributori e utenti del progetto. Il [Contratto di licenza per collaboratore personale Apache](https://www.apache.org/licenses/icla.pdf) è un contratto per collaboratore supplementare comunemente utilizzato che prevede una concessione di brevetto che rispecchia quella presente nella licenza Apache 2.0.
+* Il tuo progetto è protetto da licenza copyleft, ma devi anche distribuire la tua versione del progetto. Ogni collaboratore dovrà assegnarti il ​​copyright o concedere a te (ma non al pubblico) una licenza permissiva. Il [Contratto di collaborazione MongoDB](https://www.mongodb.com/legal/contributor-agreement) è un esempio di questo tipo di contratto.
+* Ritieni che il tuo progetto potrebbe dover modificare le licenze nel corso della sua vita e desideri che i partecipanti accettino tali modifiche in anticipo.
+
+Se hai comunque bisogno di utilizzare un contratto di collaborazione aggiuntivo con il tuo progetto, prendi in considerazione l'utilizzo di un'integrazione come [Assistente CLA](https://github.com/cla-assistant/cla-assistant) per ridurre al minimo la distrazione del collaboratore.
+
+## Cosa deve sapere il team legale della mia azienda?
+
+Se stai lanciando un progetto open source come dipendente dell'azienda, innanzitutto il tuo team legale deve sapere che sei un progetto open source.
+
+Nel bene e nel male, considera di farglielo sapere, anche se si tratta di un progetto personale. Probabilmente hai un "accordo di proprietà intellettuale dei dipendenti" con la tua azienda che dà loro un certo controllo sui tuoi progetti, soprattutto se sono legati all'attività aziendale o se stai utilizzando risorse aziendali per sviluppare il progetto. La tua azienda _dovrebbe_ concederti facilmente l'autorizzazione e potrebbe già averlo fatto tramite un accordo IP o una politica aziendale favorevole ai dipendenti. In caso contrario, puoi negoziare (ad esempio spiegando che il tuo progetto serve agli obiettivi di apprendimento e sviluppo professionale dell'azienda per te) o evitare di lavorare sul tuo progetto finché non trovi un'azienda migliore.
+
+**Se stai cercando un progetto open source per la tua azienda**, faglielo sapere. Probabilmente il tuo team legale ha già delle politiche su quale licenza open source (e forse un accordo di collaborazione aggiuntivo) da utilizzare in base ai requisiti aziendali e all'esperienza dell'azienda nel garantire che il tuo progetto sia conforme alle licenze delle sue dipendenze. In caso contrario, tu e loro siete fortunati! Il tuo team legale dovrebbe essere desideroso di lavorare con te per capire queste cose. Alcune cose a cui pensare:
+
+* **Materiale di terze parti:** Il tuo progetto ha dipendenze create da altri o include o utilizza in altro modo codice di terze parti? Se sono open source, dovrai rispettare le licenze open source dei materiali. Questo inizia con la scelta di una licenza che funzioni con licenze open source di terze parti ([vedi sopra](#quale-licenza-open-ource-è-datta-al-mio-progetto)). Se il tuo progetto modifica o distribuisce materiale open source di terze parti, il tuo team legale vorrà anche sapere se rispetti altri termini delle licenze open source di terze parti, come il mantenimento degli avvisi di copyright. Se il tuo progetto utilizza codice di terze parti che non dispone di una licenza open source, potresti dover chiedere ai manutentori di terze parti di [aggiungere una licenza open source](https://choosealicense.com/no-license/#for-users) e, se non riesci a ottenerne uno, smetti di usare il loro codice nel tuo progetto.
+
+* **Segreti commerciali:** Considera se c'è qualcosa nel progetto che l'azienda non vuole rendere disponibile al pubblico in generale. In tal caso, puoi aprire il resto del tuo progetto dopo aver estratto il materiale che desideri mantenere privato.
+
+* **Brevetti:** La tua azienda sta richiedendo un brevetto per il quale l'open source del tuo progetto costituirebbe [divulgazione pubblica](https://en.wikipedia.org/wiki/Public_disclosure)? Sfortunatamente, ti potrebbe essere chiesto di attendere (o forse la società riconsidererà la ragionevolezza della richiesta). Se ti aspetti contributi al tuo progetto da dipendenti di aziende con un ampio portafoglio di brevetti, il tuo team legale potrebbe richiederti di utilizzare una licenza con una concessione esplicita di brevetto da parte dei contributori (come Apache 2.0 o GPLv3) o un ulteriore accordo con il collaboratore ([vedi sopra ] (#quale-licenza-open-source-è-adatta-al-mio-progetto)).
+
+* **Marchi commerciali:** Controlla che il nome del tuo progetto [non sia in conflitto con i marchi esistenti](../starting-a-project/#evitare-conflitti-di-nomi). Se utilizzi i marchi della tua azienda nel progetto, controlla che non ci siano conflitti. [FOSSmarks](http://fossmarks.org/) è una guida pratica per comprendere i marchi nel contesto di progetti gratuiti e open source.
+
+* **Privacy:** Il tuo progetto raccoglie dati degli utenti? "Telefono di casa" ai server aziendali? Il tuo team legale può aiutarti a rispettare le politiche aziendali e le normative esterne.
+
+Se stai lanciando il primo progetto open source della tua azienda, quanto sopra è più che sufficiente per farcela (ma non preoccuparti, la maggior parte dei progetti non dovrebbe essere un grosso problema).
+
+Nel lungo termine, il tuo team legale può fare di più per aiutare l'azienda a ottenere di più dal suo coinvolgimento open source e rimanere al sicuro:
+
+* **Regole per il contributo dei dipendenti:** Valuta la possibilità di sviluppare una politica aziendale che definisca il modo in cui i tuoi dipendenti contribuiscono ai progetti open source. Una politica chiara ridurrà la confusione tra i tuoi dipendenti e li aiuterà a contribuire a progetti open source nel migliore interesse dell'azienda, sia come parte del loro lavoro che nel loro tempo libero. Un buon esempio è [un IP modello e una politica di contributo open source](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) di Rackspace.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
+  Fornire proprietà intellettuale correzionale rafforza la base di conoscenze e la reputazione di un dipendente. Ciò dimostra che l'azienda ha investito nello sviluppo del dipendente e crea un senso di empowerment e autonomia. Tutti questi vantaggi portano anche a un morale più alto e a una migliore fidelizzazione dei dipendenti.
+  <p markdown="1" class="pquote-credit">
+— @vanl, ["Modello IP e politica di contributo open source"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+  </p>
+</aside>
+
+* **Cosa pubblicare:** [(Quasi) tutto?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) АQuando il tuo team legale comprende ed è investito nella strategia open source della tua azienda, sarà in grado di aiutarti meglio piuttosto che ostacolare i tuoi sforzi.
+* **Conformità:** Anche se la tua azienda non rilascia progetti open source, utilizza software open source di terze parti. [Consapevolezza e processo](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) possono prevenire mal di testa, ritardi nei prodotti e azioni legali.
+
+<aside markdown="1" class="pquote">
+  Le organizzazioni devono disporre di una strategia di licenza e conformità che soddisfi entrambe le categorie \["permissivo" e "copyleft"\]. Ciò inizia con la tenuta di un registro dei termini di licenza che si applicano al software open source utilizzato, inclusi sottocomponenti e dipendenze.
+  <p markdown="1" class="pquote-credit">
+— Heather Meeker, ["Software open source: nozioni di base e best practice sulla conformità"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+  </p>
+</aside>
+
+* **Brevetti:** la tua azienda potrebbe voler aderire a [Open Invention Network](https://www.openinventionnetwork.com/), un pool di brevetti condiviso e sicuro per proteggere l'uso da parte dei membri di grandi progetti open source o per esplorare altre [licenze di brevetti alternative](https://www.eff.org/document/hacking-patent-system-2016).
+* **Governance:** Soprattutto se e quando ha senso trasferire un progetto a [un'entità legale esterna all'azienda](../leadership-and-governance/#ho-bisogno-di-una-persona-giuridica-per-sostenere-il-mio-progetto).
\ No newline at end of file
diff --git a/_articles/it/maintaining-balance-for-open-source-maintainers.md b/_articles/it/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..644b85b34c5
--- /dev/null
+++ b/_articles/it/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,220 @@
+---
+lang: it
+untranslated: true
+title: Mantenere l'equilibrio per i sostenitori dell'open source
+description: Suggerimenti per la cura di sé ed evitare il burnout come caregiver.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+Man mano che il progetto open source cresce in popolarità, diventa importante stabilire confini chiari per aiutarti a mantenere un equilibrio e rimanere aggiornato e produttivo a lungo termine.
+
+Per ottenere informazioni dettagliate sulle esperienze dei manutentori e sulle loro strategie di bilanciamento, abbiamo condotto un workshop con 40 membri della <a href="http://maintainers.github.com/">comunità dei manutentori</a>, che ci ha permesso di imparare da le loro esperienze di prima mano con il burnout open source e le pratiche che li hanno aiutati a mantenere l'equilibrio nel loro lavoro. È qui che entra in gioco il concetto di ecologia personale.
+
+Allora, cos’è l’ecologia personale? Come <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance% 2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">descritto dal Rockwood Leadership Institute</a>, implica "<strong>mantenere equilibrio, ritmo ed efficienza per sostenere la nostra energia per tutta la vita</strong>". Questo inquadra le nostre conversazioni, aiutando i sostenitori a riconoscere le loro azioni e i loro contributi come parti di un ecosistema più ampio che si evolve nel tempo. Burnout, una sindrome derivante dallo stress cronico sul lavoro, come [definita dall’OMS](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), non è raro tra i manutentori. Ciò spesso porta a una perdita di motivazione, incapacità di concentrazione e mancanza di empatia verso i colleghi e la comunità con cui lavori.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+  Non riuscivo a concentrarmi o ad avviare un'attività. Mi mancava l’empatia nei confronti del consumatore.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, che supporta il server di streaming live Owncast, sull'impatto del burnout sul suo funzionamento open source
+  </p>
+</aside>
+
+Abbracciando il concetto di ecologia personale, gli operatori sanitari possono evitare in modo proattivo il burnout, dare priorità alla cura di sé e mantenere un senso di equilibrio per svolgere al meglio il proprio lavoro.
+
+## Suggerimenti per la cura di sé ed evitare il burnout come personale di supporto:
+
+### Determina le tue motivazioni per lavorare con l'open source
+
+Prenditi del tempo per pensare a quali parti del supporto open source ti danno energia. Comprendere la tua motivazione può aiutarti a dare priorità al lavoro in un modo che ti mantenga impegnato e pronto per nuove sfide. Che si tratti del feedback positivo degli utenti, della gioia di collaborare e interagire con la community o della soddisfazione di immergersi nel codice, riconoscere le proprie motivazioni può aiutarti a dirigere la tua attenzione.
+
+### Pensa a cosa ti fa sentire sbilanciato e stressato
+
+È importante capire cosa ci fa bruciare. Ecco alcuni temi comuni che abbiamo riscontrato tra i sostenitori dell'open source:
+
+* **Mancanza di feedback positivo:** è molto più probabile che gli utenti si mettano in contatto con noi in caso di reclamo. Se tutto funziona bene, tendono a tacere. Può essere scoraggiante vedere un elenco crescente di problemi senza il feedback positivo che mostri come il tuo contributo stia facendo la differenza.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  A volte è un po' come gridare nel vuoto e trovo che il feedback mi dia davvero energia. Abbiamo molti utenti felici ma tranquilli.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, supporto Apache Arrow
+  </p>
+</aside>
+
+* **Non dire di "NO":** Può essere facile assumersi più responsabilità del dovuto per un progetto open source. Che si tratti di utenti, contributori o altri sostenitori, non sempre possiamo essere all'altezza delle loro aspettative.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+ Mi sono ritrovato ad assumerne più di uno e a dover svolgere il lavoro di più persone come di solito si fa in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, supporto Termux, su cosa causa il burnout nel loro lavoro
+  </p>
+</aside>
+
+* **Lavorare da soli:** Essere un manutentore può essere incredibilmente solitario. Anche se lavori con un gruppo di manutentori, negli ultimi anni è stato difficile convocare di persona i team distribuiti.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Soprattutto dopo il COVID e il lavoro da casa, è più difficile non vedere né parlare mai con nessuno.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, che supporta il server di streaming live Owncast, sull'impatto del burnout sul suo funzionamento open source
+  </p>
+</aside>
+
+* **Tempo o risorse insufficienti:** Ciò è particolarmente vero per i volontari di supporto che devono sacrificare il proprio tempo libero per lavorare a un progetto.
+
+<aside markdown="1" class="pquote">
+  [Mi piacerebbe avere] più sostegno finanziario in modo da potermi concentrare sul lavoro open source senza spendere i miei risparmi e sapendo che dovrò stipulare molti contratti per compensare in seguito.
+  <p markdown="1" class="pquote-credit">
+— supporto open source
+  </p>
+</aside>
+
+* **Richieste contrastanti:** L'open source è pieno di gruppi con motivazioni diverse che possono essere difficili da orientare. Se sei pagato per lavorare nell'open source, gli interessi del tuo datore di lavoro a volte possono essere in contrasto con quelli della comunità.
+
+<aside markdown="1" class="pquote">
+  Con l'open source a pagamento, il conflitto tra l'attenzione del datore di lavoro e ciò che è meglio per la comunità
+  <p markdown="1" class="pquote-credit">
+— supporto open source
+  </p>
+</aside>
+
+### Fai attenzione ai segni di esaurimento
+
+Riesci a mantenere il tuo ritmo per 10 settimane? 10 mesi? 10 anni?
+
+Esistono strumenti come [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) di [@shaunagm](https://github.com/shaunagm) che possono aiutarti a riflettere sul tuo ritmo attuale e vedi se ci sono modifiche che puoi apportare. Alcuni operatori sanitari utilizzano anche la tecnologia indossabile per monitorare parametri come la qualità del sonno e la variabilità della frequenza cardiaca (entrambi legati allo stress).
+
+<aside markdown="1" class="pquote">
+ Sono un grande fan dei bei vestiti. Con la scienza alla base, puoi capire come potresti fare meglio e come arrivare allo stato ottimale di ciò che vuoi fare.
+  <p markdown="1" class="pquote-credit">
+— supporto open source
+  </p>
+</aside>
+
+### Di cosa hai bisogno per continuare a sostenere te stesso e la tua comunità?
+
+Questo apparirà diverso per ogni manutentore e cambierà a seconda della fase della tua vita e di altri fattori esterni. Ma ecco alcuni temi che abbiamo sentito:
+
+* **Affidati alla community:** Delegare e trovare collaboratori può alleggerire il carico di lavoro. Avere più punti di contatto per un progetto può aiutarti a stare tranquillo. Connettiti con altri manutentori e con la comunità più ampia - in gruppi come [Comunità dei manutentori](http://maintainers.github.com/). Questa può essere una grande risorsa per il supporto e la formazione tra pari.
+
+  Puoi anche cercare modi per interagire con la comunità di utenti in modo da poter ascoltare regolarmente feedback e comprendere l'impatto del tuo lavoro open source.
+
+* **Esplora i finanziamenti:** Che tu stia cercando dei soldi per la pizza o stia cercando di passare a tempo pieno all'open source, ci sono molte risorse per aiutarti! Come primo passo, valuta la possibilità di attivare [Sponsor Github](https://github.com/sponsors) per consentire ad altri di sponsorizzare il tuo lavoro open source. Se stai pensando di trasferirti a tempo pieno, fai domanda per il turno successivo [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ Ero su un podcast poco fa e stavamo parlando di supporto e sostenibilità open source. Ho scoperto che anche un piccolo numero di persone che supportano il mio lavoro su GitHub mi hanno aiutato a prendere la rapida decisione di non sedermi davanti a un gioco e invece di fare una piccola cosa open source.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, supporto EmberJS
+  </p>
+</aside>
+
+* **Utilizza gli strumenti:** esplora strumenti come [GitHub Copilot](https://github.com/features/copilot/) e [GitHub Actions](https://github.com/features/actions), per automatizzare le attività banali e liberare tempo per contributi più significativi.
+
+<aside markdown="1" class="pquote">
+ Usa [Copilot](https://github.com/features/copilot/) per le cose noiose, fai le cose divertenti
+  <p markdown="1" class="pquote-credit">
+— supporto open source
+  </p>
+</aside>
+
+* **Riposati e ricaricati:** prenditi del tempo per i tuoi hobby e interessi al di fuori dell'open source. Prenditi dei giorni liberi per rilassarti e rigenerarti e imposta il tuo [stato GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status), per riflettere la tua disponibilità! Una buona notte di sonno può fare una grande differenza nella tua capacità di sostenere i tuoi sforzi a lungo termine.
+
+   Se trovi particolarmente piacevoli alcuni aspetti del tuo progetto, prova a strutturare il tuo lavoro in modo da poterlo sperimentare durante tutta la giornata.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ Trovo più opportunità per dedicarmi a "momenti di creatività" a metà giornata invece di cercare di staccare la spina la sera.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, supporto Nuxt
+  </p>
+</aside>
+
+* **Imposta dei limiti:** non puoi dire sì a ogni richiesta. Può essere semplice come dire "Non posso farlo adesso e non ho piani per il futuro" o specificare cosa vuoi fare e cosa non fare nel README. Ad esempio, potresti dire: "Unisco solo i PR che hanno chiaramente elencato i motivi per cui sono stati creati" oppure "Esamino i problemi solo il giovedì dalle 18:00 alle 19:00". Ciò definisce le aspettative per gli altri e ti dà qualcosa a cui puntare in altri momenti per ridurre le richieste di tempo da parte di collaboratori o utenti.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+Per fidarsi significativamente degli altri lungo questi assi, non puoi essere qualcuno che dice sì a ogni richiesta. In questo modo, non manterrai alcun confine, professionale o personale, e non sarai un collega affidabile.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, supporto Homebrew di [Dire NO](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  Impara ad essere fermo nel fermare comportamenti tossici e interazioni negative. È bene non dare energia a cose che non ti interessano.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+    Il mio software è gratuito, ma il mio tempo e la mia attenzione no.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, supporto Leaflet
+  </p>
+</aside>
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+    Non è un segreto che il supporto open source abbia i suoi lati oscuri, e uno di questi a volte è dover interagire con persone piuttosto ingrate, autorizzate o addirittura tossiche. Man mano che la popolarità di un progetto cresce, aumenta anche la frequenza di questo tipo di interazione, aumentando il carico sui manutentori e diventando forse un fattore di rischio significativo per il burnout dei manutentori..  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, supporto Octoprint di [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Ricorda che l'ecologia personale è una pratica continua che si evolverà man mano che avanzi nel tuo viaggio open source. Dando priorità alla cura di sé e mantenendo un senso di equilibrio, puoi contribuire alla comunità open source in modo efficace e sostenibile, garantendo sia il tuo benessere che il successo a lungo termine dei tuoi progetti.
+
+## Risorse addizionali
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Associati
+
+Mille grazie a tutti i manutentori che hanno condiviso con noi la loro esperienza e i loro consigli per questa guida!
+
+Questa guida è stata scritta da [@abbycabs](https://github.com/abbycabs) con il contributo di:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + moltri altri!
\ No newline at end of file
diff --git a/_articles/it/metrics.md b/_articles/it/metrics.md
new file mode 100644
index 00000000000..dbb3d9e49d2
--- /dev/null
+++ b/_articles/it/metrics.md
@@ -0,0 +1,128 @@
+---
+lang: it
+title: Metriche Open Source
+description: Prendi decisioni informate per aiutare il tuo progetto open source a prosperare misurando e monitorandone il successo.
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+  - finding
+  - best-practices
+---
+
+## Perché misurare qualcosa?
+
+I dati, se utilizzati con saggezza, possono aiutarti a prendere decisioni migliori come sostenitore dell'open source.
+
+Per ulteriori informazioni, puoi:
+
+* Scopri come gli utenti reagiscono a una nuova funzionalità
+* Scopri da dove provengono i nuovi utenti
+* Identificare e decidere se supportare un caso d'uso o una funzionalità eccezionale
+*Quantificare la popolarità del tuo progetto
+* Scopri come viene utilizzato il tuo progetto
+* Raccogliere fondi attraverso sponsorizzazioni e sovvenzioni
+
+Per esempio [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) scopre che Google Analytics li aiuta a dare priorità al lavoro:
+
+> Homebrew è fornito gratuitamente ed è gestito interamente da volontari nel loro tempo libero. Di conseguenza, non abbiamo le risorse per effettuare studi dettagliati sugli utenti di Homebrew per decidere come progettare al meglio le funzionalità future e dare priorità al lavoro attuale. L'analisi anonima degli utenti aggregati ci consente di dare priorità a correzioni e funzionalità in base a come, dove e quando le persone utilizzano Homebrew.
+
+La popolarità non è tutto. Tutti entrano nell'open source per motivi diversi. Se il tuo obiettivo come sostenitore dell'open source è mostrare il tuo lavoro, essere trasparente riguardo al tuo codice o semplicemente divertirti, le metriche potrebbero non essere importanti per te.
+
+Se sei interessato a comprendere il tuo progetto a un livello più profondo, leggi i modi per analizzare l'attività del tuo progetto.
+
+## Scoperta
+
+Prima che chiunque possa utilizzare o contribuire al tuo progetto, deve sapere che esiste. Chiediti: _le persone trovano questo progetto?_
+
+![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:
+
+* **Visualizzazioni di pagina totali:** indica quante volte il tuo progetto è stato visualizzato
+
+* **Visitatori unici totali:** Ti dice quante persone hanno visto il tuo progetto
+
+* **Siti di riferimento:** ti dice da dove provengono i tuoi visitatori. Questa metrica può aiutarti a capire dove raggiungere il tuo pubblico e se i tuoi sforzi di promozione stanno funzionando.
+
+* **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.
+
+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.
+
+## Utilizzo
+
+Le persone trovano il tuo progetto in questa cosa selvaggia e folle che chiamiamo Internet. Idealmente, quando vedranno il tuo progetto, si sentiranno obbligati a fare qualcosa. La seconda domanda che dovrai porre è: _ci sono persone che utilizzano questo progetto?_
+
+Se utilizzi un gestore di pacchetti come npm o RubyGems.org per distribuire il tuo progetto, potresti essere in grado di monitorare i download del tuo progetto.
+
+Ogni gestore di pacchetti può utilizzare una definizione leggermente diversa di "download" e i download non sono necessariamente correlati alle installazioni o all'utilizzo, ma forniscono alcune linee di base per il confronto. Prova a utilizzare [Libraries.io](https://libraries.io/) per tenere traccia delle statistiche di utilizzo su molti gestori di pacchetti popolari.
+
+Se il tuo progetto è su GitHub, apri nuovamente la pagina Traffico. Puoi utilizzare il [grafico dei cloni](https://github.com/blog/1873-clone-graphs) per vedere quante volte il tuo progetto è stato clonato in un determinato giorno, suddiviso in cloni totali e cloni unici.
+
+![Grafico dei cloni](/assets/images/metrics/clone_graph.png)
+
+Se l'utilizzo è basso rispetto al numero di persone che hanno scoperto il tuo progetto, ci sono due problemi da considerare. O:
+
+* Il tuo progetto non sta convertendo con successo il tuo pubblico, o
+* Stai attirando il pubblico sbagliato
+
+Ad esempio, se il tuo progetto arriva sulla prima pagina di Hacker News, probabilmente noterai un picco nella scoperta (traffico) ma un tasso di conversione inferiore perché stai raggiungendo tutti su Hacker News. Tuttavia, se il tuo progetto Ruby viene presentato a una conferenza Ruby, è più probabile che tu ottenga un tasso di conversione elevato da un pubblico target.
+
+Cerca di capire da dove proviene il tuo pubblico e chiedi feedback agli altri sulla pagina del tuo progetto per scoprire quale di questi due problemi stai affrontando.
+
+Una volta che sai che le persone utilizzano il tuo progetto, potresti provare a scoprire cosa ne fanno. Si basano su di esso biforcando il codice e aggiungendo funzionalità? Lo usano per la scienza o per gli affari?
+
+## Presa
+
+Le persone trovano il tuo progetto e lo usano. La prossima domanda che ti dovrai porre è: _le persone contribuiscono a questo progetto?_
+
+Non è mai troppo presto per iniziare a pensare ai collaboratori. Senza l'intervento di altre persone, rischi di metterti in una situazione malsana in cui il tuo progetto è _popolare_ (molte persone lo usano) ma non _mantenuto_ (non abbastanza tempo di supporto per soddisfare la domanda).
+
+La conservazione richiede anche [un afflusso di nuovi contributori](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2) poiché i contributori precedentemente attivi alla fine passeranno a altre cose.
+
+Esempi di parametri della community che potresti voler monitorare regolarmente includono:
+
+* **Totale contributori e impegni per collaboratore:** indica quanti collaboratori hai e chi è più o meno attivo. Su GitHub puoi vederlo in Approfondimenti -> Collaboratori. Attualmente, questo grafico riporta solo i contributori che si sono impegnati nel ramo predefinito del repository.
+
+![Graffico dei collaboratori](/assets/images/metrics/repo_contributors_specific_graph.png)
+
+* **Primi contributori, collaboratori occasionali e ricorrenti:** ti aiuta a monitorare se ottieni nuovi contributori e se ritornano. (I contributori occasionali sono contributori con un numero limitato di commit. Che si tratti di un commit, di meno di cinque commit o di qualcos'altro dipende da te.) Senza nuovi contributori, la comunità del tuo progetto può ristagnare.
+
+* **Numero di problemi aperti e richieste pull aperte:** Se questi numeri diventano troppo alti, potresti aver bisogno di aiuto con l'ordinamento dei problemi e le revisioni del codice.
+
+* **Numero di problemi _aperti_ e richieste pull _aperte_:** I problemi aperti indicano che qualcuno è sufficientemente interessato al tuo progetto da aprire un problema. Se questo numero aumenta nel tempo, significa che le persone sono interessate al tuo progetto.
+
+* **Tipi di contributi:** Ad esempio, commit, correzione di errori di battitura o di commento o commento su un problema.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
+  L'open source è più del semplice codice. I progetti open source di successo includono il contributo di codice e documentazione insieme a conversazioni su tali modifiche.
+  <p markdown="1" class="pquote-credit">
+— @arfon, ["Il formato open source"](https://github.com/blog/2195-the-shape-of-open-source)
+  </p>
+</aside>
+
+## Attività di supporto
+
+Infine, ti consigliamo di chiudere il ciclo assicurandoti che i sostenitori del tuo progetto siano in grado di gestire il volume dei contributi ricevuti. L'ultima domanda che vorrai farti è: _sto (o stiamo) rispondendo alla nostra community?_
+
+I manutentori che non rispondono diventano un ostacolo per i progetti open source. Se qualcuno invia un contributo ma non riceve mai risposta dal manutentore, potrebbe sentirsi scoraggiato e andarsene.
+
+[Una ricerca di Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggerisce che la reattività del manutentore è un fattore critico nell'incoraggiare la ripetizione dei contributi.
+
+Prendi in considerazione [il monitoraggio del tempo impiegato da te (o da un altro manutentore) per rispondere alle richieste pull](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), che si tratti di un problema o di una richiesta di download. La risposta non richiede alcuna azione. Potrebbe essere semplice come dire: _"Grazie per il tuo contributo! Esaminerò la questione la prossima settimana."_
+
+Puoi anche misurare il tempo necessario per passare da una fase all'altra del processo di contribuzione, ad esempio:
+
+*Tempo medio in cui il problema rimane aperto
+* Se i problemi vengono risolti dai PR
+* Se i problemi obsoleti sono chiusi
+*Tempo medio per unire una richiesta pull
+
+## Usa 📊 per conoscere le persone
+
+Comprendere le metriche ti aiuterà a costruire un progetto open source attivo e in crescita. Anche se non tieni traccia di tutte le metriche della dashboard, utilizza la struttura sopra per focalizzare la tua attenzione sul tipo di comportamento che aiuterà il tuo progetto a prosperare.
+
+[CHAOSS](https://chaoss.community/) è un'accogliente comunità open source focalizzata su analisi, metriche e software sulla salute della comunità.
\ No newline at end of file
diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md
new file mode 100644
index 00000000000..82476c0fd9e
--- /dev/null
+++ b/_articles/it/starting-a-project.md
@@ -0,0 +1,355 @@
+---
+lang: it
+title: Avvio di un progetto open source
+description: Scopri di più sul mondo dell'open source e preparati a iniziare il tuo progetto.
+class: beginners
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+  - finding
+  - building
+---
+
+## Il "cosa" e il "perché" dell'open source
+
+Quindi stai pensando di iniziare con l'open source? Congratulazioni! Il mondo apprezza il tuo contributo. Parliamo di cos'è l'open source e perché le persone lo fanno.
+
+### Cosa significa "open source"?
+
+Quando un progetto è open source, significa che **chiunque è libero di utilizzare, studiare, modificare e distribuire il tuo progetto per qualsiasi scopo.** Queste autorizzazioni si applicano tramite la [licenza open source](https://opensource.org/licenze).
+
+L’open source è potente perché abbassa le barriere all’adozione e alla collaborazione, consentendo alle persone di distribuire e migliorare rapidamente i progetti. Anche perché offre agli utenti la possibilità di controllare i propri computer, rispetto al closed source. Ad esempio, un'azienda che utilizza software open source ha la possibilità di assumere qualcuno per apportare miglioramenti personalizzati al software invece di affidarsi esclusivamente alle soluzioni di prodotto di un fornitore closed source.
+
+_Software Libero_ si riferisce allo stesso insieme di progetti di _Open Source_. A volte vedrai anche [questi termini](https://en.wikipedia.org/wiki/Free_and_open-source_software) combinati come "software libero e open source" (FOSS) o "software libero e open source" (FLOSS). _Free_ e _libre_ si riferiscono alla libertà, [non al prezzo](#open-source-significa-gratuito).
+
+### Защо хората отварят кода на работата си?
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/kentcdodds?s=180" class="pquote-avatar" alt="avatar">
+  Una delle esperienze più gratificanti che ottengo utilizzando e collaborando con l'open source deriva dalle relazioni che instauro con altri sviluppatori che affrontano molti dei miei stessi problemi.
+  <p markdown="1" class="pquote-credit">
+— @kentcdodds, ["Come è stato fantastico per me entrare nell'Open Source"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+  </p>
+</aside>
+
+[Ci sono molte ragioni](https://ben.balter.com/2015/11/23/why-open-source/) per cui un individuo o un'organizzazione vorrebbe rendere open source un progetto. Alcuni esempi includono:
+
+* **Collaborazione:** I progetti open source possono accettare modifiche da chiunque nel mondo. [Exercism](https://github.com/exercism/), ad esempio, è una piattaforma di esercizi di programmazione con oltre 350 contributori.
+
+* **Adozione e remix:** i progetti open source possono essere utilizzati da chiunque per quasi tutti gli scopi. Le persone possono persino usarlo per costruire altre cose. [WordPress](https://github.com/WordPress), ad esempio, è iniziato come fork di un progetto esistente chiamato [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Trasparenza:** chiunque può verificare la presenza di bug o incoerenze in un progetto open source. La trasparenza è importante per governi come la [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o gli [Stati Uniti](https://sourcecode.cio.gov/), settori regolamentati come quello bancario o sanitario e software di sicurezza come [Let's Encrypt](https://github.com/letsencrypt).
+
+L'open source non riguarda solo il software. Puoi aprire qualsiasi cosa, dai set di dati ai libri. Dai un'occhiata a [GitHub Explore](https://github.com/explore) per idee su cos'altro puoi aprire.
+
+### Open source significa "gratuito"?
+
+Uno dei maggiori vantaggi dell'open source è che non costa denaro. Tuttavia, "gratuito" è un sottoprodotto del valore complessivo dell'open source.
+
+Poiché la [licenza open source richiede](https://opensource.org/definition-annotated/) che chiunque sia in grado di utilizzare, modificare e condividere il tuo progetto per quasi tutti gli scopi, i progetti stessi sono generalmente gratuiti. Se l'utilizzo del progetto costa denaro, chiunque può legalmente farne una copia e utilizzare invece la versione gratuita.
+
+Di conseguenza, la maggior parte dei progetti open source sono gratuiti, ma "gratuito" non fa parte della definizione di open source. Esistono modi per far pagare i progetti open source indirettamente attraverso doppia licenza o funzionalità limitate, pur rispettando la definizione ufficiale di open source.
+
+## Dovrei iniziare il mio progetto open source?
+
+La risposta breve è sì, perché indipendentemente dal risultato, avviare il proprio progetto è un ottimo modo per imparare come funziona l'open source.
+
+Se non hai mai aperto un progetto open source prima, potresti essere preoccupato per ciò che la gente dirà o se qualcuno se ne accorgerà. Se suona come te, non sei solo!
+
+Il lavoro open source è come qualsiasi altra attività creativa, che si tratti di scrivere o disegnare. Potresti avere paura di condividere il tuo lavoro con il mondo, ma l'unico modo per migliorare è esercitarsi, anche se non hai un pubblico.
+
+Se non sei ancora convinto, prenditi un momento per pensare a quali potrebbero essere i tuoi obiettivi.
+
+### Stabilisci i tuoi obiettivi
+
+Gli obiettivi possono aiutarti a capire su cosa lavorare, a cosa dire di no e dove hai bisogno dell'aiuto degli altri. Inizia chiedendoti _perché sto utilizzando questo progetto open source?_
+
+Non esiste un’unica risposta corretta a questa domanda. Puoi avere più obiettivi per un progetto o progetti diversi con obiettivi diversi.
+
+Se il tuo unico obiettivo è mettere in mostra il tuo lavoro, potresti non volere nemmeno un contributo e addirittura dirlo nel tuo README. D'altra parte, se desideri contributori, investirai tempo in una documentazione chiara e farai sentire i nuovi arrivati ​​i benvenuti.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mavris?s=180" class="pquote-avatar" alt="avatar">
+  Ad un certo punto ho creato un UIAlertView personalizzato che ho utilizzato... e ho deciso di renderlo open source. Quindi l'ho modificato per renderlo più dinamico e l'ho caricato su GitHub. Ho anche scritto la mia prima documentazione spiegando ad altri sviluppatori come utilizzarlo nei loro progetti. Probabilmente nessuno lo ha mai usato perché era un progetto semplice, ma mi sono sentito bene con il mio contributo.
+  <p markdown="1" class="pquote-credit">
+— @mavris, ["Sviluppatori di software autodidatti: perché l'open source è importante per noi"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+  </p>
+</aside>
+
+Man mano che il tuo progetto cresce, la tua comunità potrebbe aver bisogno di qualcosa di più del semplice codice, da parte tua. Rispondere ai problemi, rivedere il codice ed evangelizzare il tuo progetto sono compiti importanti in un progetto open source.
+
+Anche se la quantità di tempo che dedichi ad attività non di codifica dipenderà dalle dimensioni e dall'ambito del tuo progetto, dovresti essere preparato come manutentore a gestirle da solo o a trovare qualcuno che ti aiuti.
+
+**Se fai parte di un'azienda che offre un progetto open source,** assicurati che il tuo progetto disponga delle risorse interne necessarie per prosperare. Ti consigliamo di determinare chi è responsabile del mantenimento del progetto dopo il lancio e come condividerai tali attività con la tua comunità.
+
+Se hai bisogno di un budget o di personale dedicato per la promozione, le operazioni e la manutenzione del progetto, avvia queste conversazioni in anticipo.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/captainsafia?s=180" class="pquote-avatar" alt="avatar">
+  Quando inizi a rendere open source il tuo progetto, è importante assicurarti che i tuoi processi di governance tengano conto del contributo e delle capacità della comunità attorno al tuo progetto. Non aver paura di coinvolgere collaboratori esterni alla tua azienda negli aspetti chiave del progetto, soprattutto se collaborano spesso.
+  <p markdown="1" class="pquote-credit">
+— @captainsafia, ["Quindi vuoi un progetto open source eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+  </p>
+</aside>
+
+### Contributo ad altri progetti
+
+Se il tuo obiettivo è imparare a collaborare con gli altri o capire come funziona l'open source, valuta la possibilità di contribuire a un progetto esistente. Inizia con un progetto che già usi e che ti piace. Contribuire a un progetto può essere semplice come correggere un errore di battitura o aggiornare la documentazione.
+
+Se non sei sicuro di come iniziare come collaboratore, consulta la nostra [Come contribuire alla guida Open Source](../how-to-contribute/).
+
+## Inizia il tuo progetto open source
+
+Non esiste il momento perfetto per aprire la tua attività. Puoi rendere open source un'idea, in lavorazione o dopo anni di closed source.
+
+In generale, dovresti aprire il tuo progetto quando ti senti a tuo agio con gli altri che visualizzano e forniscono feedback sul tuo lavoro.
+
+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/)
+* [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.
+
+Se il tuo progetto è su GitHub, posizionare questi file nella directory root con i nomi file consigliati aiuterà GitHub a riconoscerli e a mostrarli automaticamente ai tuoi lettori.
+
+### Selezione della licenza
+
+Una licenza open source garantisce che altri possano utilizzare, copiare, modificare e contribuire al tuo progetto senza conseguenze. Ti protegge anche da situazioni legali difficili. **Devi includere una licenza quando avvii un progetto open source.**
+
+Il lavoro legale non è divertente. La buona notizia è che puoi copiare e incollare una licenza esistente nel tuo repository. Ci vorrà solo un minuto per proteggere il tuo duro lavoro.
+
+[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 le licenze open source più popolari, ma [ci sono altre opzioni](https://choosealicense.com), da qualle scegliere .
+
+Quando crei un nuovo progetto su GitHub, ti viene data la possibilità di scegliere una licenza. Includere una licenza open source renderà il tuo progetto GitHub open source.
+
+![Seleziona una licenza](/assets/images/starting-a-project/repository-license-picker.png)
+
+Se hai altre domande o dubbi sugli aspetti legali della gestione di un progetto open source, [ti abbiamo coperto](../legal/).
+
+### Scrivi README
+
+I README fanno molto di più che spiegare come utilizzare il tuo progetto. Spiegano anche perché il tuo progetto è importante e cosa possono farci i tuoi utenti.
+
+Nel README, prova a rispondere alle seguenti domande:
+
+*Cosa fa questo progetto?
+*Perché è utile questo progetto?
+* Come iniziare?
+* Dove posso ottenere ulteriore aiuto se ne ho bisogno?
+
+Puoi utilizzare il file README per rispondere ad altre domande, ad esempio come gestisci i contributi, quali sono gli obiettivi del progetto e informazioni su licenza e attribuzione. Se non vuoi accettare contributi o il tuo progetto non è ancora pronto per la produzione, salva queste informazioni.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
+  Una migliore documentazione significa più utenti, meno richieste di supporto e più contributori. (...) Ricorda che i tuoi lettori non sei tu. Ci sono persone che possono venire a un progetto che hanno background completamente diversi.
+  <p markdown="1" class="pquote-credit">
+— @tracymakes, ["Пишете така, че думите ви да се четат (видео)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+  </p>
+</aside>
+
+Понякога хората избягват да пишат README, защото смятат, че проектът е незавършен или не искат приноси. Всичко това са много добри причини да напиша такъв.
+
+Per ulteriore ispirazione, prova a utilizzare [la guida "Crea un README" di @dguo](https://www.makeareadme.com/) o [README nel modello](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) di @PurpleBooth per scrivere un completo README.
+
+Quando includi un file README nella directory root, GitHub lo visualizzerà automaticamente nella home page del repository.
+
+### Scrivi le linee guida per il tuo contributo
+
+Un file CONTRIBUTO indica al tuo pubblico come partecipare al tuo progetto. Ad esempio, puoi includere informazioni su:
+
+* Come inviare una segnalazione di bug (prova a utilizzare [modelli di richiesta problemi e pull](https://github.com/blog/2111-issue-and-pull-request-templates))
+* Come proporre una nuova funzionalità
+* Come configurare il tuo ambiente ed eseguire i test
+
+Oltre ai dettagli tecnici, il file CONTRIBUTI è un'opportunità per comunicare le vostre aspettative per i contributi, come ad esempio:
+
+*I tipi di contributi che stai cercando
+* La tua tabella di marcia o visione per il progetto
+* Come i contributori dovrebbero (o non dovrebbero) contattarti
+
+Usare un tono caldo e amichevole e offrire suggerimenti specifici per i contributi (come scrivere documentazione o creare un sito web) può fare molto per far sentire i nuovi arrivati ​​benvenuti ed entusiasti di partecipare.
+Per esempio [Active Admin](https://github.com/activeadmin/activeadmin/) inizia [la sua guida ai contributi](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) con:
+
+> Innanzitutto, grazie per aver considerato di contribuire ad Active Admin. Sono le persone come te che rendono Active Admin uno strumento così eccezionale.
+
+Nelle prime fasi del tuo progetto, il tuo file CONTRIBUTO può essere semplice. Dovresti sempre spiegare come segnalare bug o problemi, ed eventuali requisiti tecnici (come i test) per dare un contributo.
+
+Nel tempo, potresti aggiungere altre domande frequenti al tuo file CONTRIBUTING. Annotare queste informazioni significa che meno persone ti faranno sempre le stesse domande.
+
+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.
+
+![Linee guida per i contributi](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+
+### Creazione di un codice di condotta
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
+  Tutti abbiamo avuto esperienze in cui ci siamo imbattuti in quello che probabilmente era un abuso, sia come manutentore che cercava di spiegare perché qualcosa dovrebbe essere in un certo modo, sia come utente... che poneva una semplice domanda. (...) Il Codice di condotta diventa un documento con riferimenti e collegamenti facili che dimostra che il vostro team prende molto sul serio il discorso costruttivo.
+  <p markdown="1" class="pquote-credit">
+— @mlynch, ["Rendere l’open source un luogo più felice"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+  </p>
+</aside>
+
+Infine, un codice di condotta aiuta a definire le regole di base per la condotta dei partecipanti al progetto. Ciò è particolarmente utile se stai avviando un progetto open source per una comunità o un'azienda. Un codice di condotta ti consente di facilitare un comportamento sano e costruttivo nella comunità che ridurrà il tuo stress come sostenitore.
+
+Per ulteriori informazioni, consultare la nostra [Guida al Codice di condotta](../code-of-conduct/).
+
+Oltre a comunicare _come_ ci si aspetta che i partecipanti si comportino, un codice di condotta tende anche a descrivere a chi si applicano tali aspettative, quando si applicano e cosa fare se si verifica una violazione.
+
+Come per le licenze open source, esistono standard emergenti per i codici di condotta, quindi non è necessario scriverne uno proprio. Il [Contributor Covenant](https://contributor-covenant.org/) è un codice di condotta utilizzato da [oltre 40.000 progetti open source](https://www.contributor-covenant.org/adopters), incluso Kubernetes, Rails e Swift. Indipendentemente dal testo che utilizzi, devi essere pronto a far rispettare il tuo codice di condotta quando necessario.
+
+Incolla il testo direttamente in un file CODE_OF_CONDUCT nel tuo repository. Archivia il file nella directory principale del tuo progetto in modo che sia facile da trovare e collegalo dal tuo file README.
+
+## Assegna un nome e un marchio al tuo progetto
+
+Il branding è più di un logo appariscente o di un nome di progetto accattivante. Riguarda il modo in cui parli del tuo progetto e chi raggiungi con il tuo messaggio.
+
+### Scegliere il nome giusto
+
+Scegli un nome che sia facile da ricordare e che, idealmente, dia un'idea di ciò che fa il progetto. Per esempio:
+
+* [Sentry](https://github.com/getsentry/sentry) monitora le applicazioni di segnalazione degli arresti anomali
+* [Thin](https://github.com/macournoyer/thin) è un server web Ruby facile e veloce
+
+Se stai sviluppando un progetto esistente, usare il loro nome come prefisso può aiutarti a chiarire cosa fa il tuo progetto (ad esempio [node-fetch](https://github.com/bitinn/node-fetch) porta `window .fetch ` a Node.js).
+
+Pensa prima alla chiarezza. I giochi di parole sono divertenti, ma ricorda che alcune battute potrebbero non essere applicabili ad altre culture o persone con esperienze diverse dalle tue. Alcuni dei tuoi potenziali utenti potrebbero essere dipendenti dell'azienda: non vuoi farli sentire a disagio quando devono spiegare il tuo progetto al lavoro!
+
+### Evitare conflitti di nomi
+
+[Verifica la presenza di progetti open source con nomi simili](http://ivatomic.com/projects/ospnc/), soprattutto se condividi la stessa lingua o ecosistema. Se il tuo nome si sovrappone a un popolare progetto esistente, potresti confondere il tuo pubblico.
+
+Se desideri che un sito web, un account Twitter o altre proprietà rappresentino il tuo progetto, assicurati di poter ottenere i nomi che desideri. Idealmente, [salva questi nomi adesso](https://instantdomainsearch.com/) per la massima tranquillità, anche se non intendi ancora utilizzarli.
+
+Assicurati che il nome del tuo progetto non violi alcun marchio. Un'azienda potrebbe chiederti di rimuovere il tuo progetto in un secondo momento o addirittura intraprendere un'azione legale contro di te. Non vale la pena rischiare.
+
+Puoi controllare il [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) per eventuali conflitti tra marchi. Se lavori in un'azienda, questa è una delle cose in cui il tuo [team legale può aiutarti](../legal/).
+
+Infine, esegui una rapida ricerca su Google per il nome del tuo progetto. Le persone riusciranno a trovare facilmente il tuo progetto? C'è qualcos'altro che appare nei risultati di ricerca che non vuoi che venga visualizzato?
+
+### Anche il modo in cui scrivi (e codifichi) influisce sul tuo marchio!
+
+Nel corso della vita del tuo progetto, scriverai molto: README, tutorial, documenti della community, risposte a problemi, forse anche newsletter e mailing list.
+
+Che si tratti di documentazione formale o di un'e-mail informale, il tuo stile di scrittura fa parte del marchio del tuo progetto. Pensa a come potresti percepire il tuo pubblico e se questo è il tono che vuoi trasmettere.
+
+<aside markdown="1" class="pquote">
+   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
+   Ho cercato di partecipare a ogni discussione della mailing list e di mostrare un comportamento esemplare, di essere gentile con le persone, di prendere sul serio i loro problemi e di cercare di essere d'aiuto in generale. Dopo un po', le persone si sono fermate non solo per fare domande, ma anche per aiutare con le risposte, e con mia grande gioia hanno imitato il mio stile.
+   <p markdown="1" class="pquote-credit">
+— @janl в [CouchDB](https://github.com/apache/couchdb), ["Open source sostenibile"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+   </p>
+</aside>
+
+Usare un linguaggio caldo e inclusivo (come "loro" anche quando si riferisce a una sola persona) può fare molto per far sì che il tuo progetto si senta accogliente per i nuovi contributori. Attieniti a un linguaggio semplice poiché molti dei tuoi lettori potrebbero non essere di madrelingua inglese.
+
+Oltre al modo in cui digiti le parole, anche il tuo stile di codifica può diventare parte del marchio del tuo progetto. [Angular](https://angular.io/guide/styleguide) e [jQuery](https://contribute.jquery.org/style-guide/js/) sono due esempi di progetti con stili e linee guida di codifica rigorosi.
+
+Non è necessario scrivere una guida di stile per il tuo progetto quando hai appena iniziato e potresti scoprire che ti diverti comunque a incorporare diversi stili di codifica nel tuo progetto. Ma devi prevedere in che modo il tuo stile di scrittura e programmazione potrebbe attrarre o scoraggiare diversi tipi di persone. Le prime fasi del tuo progetto sono la tua opportunità per creare il precedente che desideri vedere.
+
+## 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.
+
+**Documentazione**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox1" class="overflow-hidden d-block text-normal">
+    Il progetto ha un file LICENSE di licenza open source
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox2" class="overflow-hidden d-block text-normal">
+    Il progetto ha la documentazione di base (README, CONTRIBUTING, CODE_OF_CONDUCT)
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox3" class="overflow-hidden d-block text-normal">
+    Името е лесно за запомняне, дава известна представа какво прави проектът и не е в конфликт със съществуващ проект или нарушава търговски марки
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox4" class="overflow-hidden d-block text-normal">
+    La coda dei problemi è aggiornata, con problemi chiaramente organizzati ed etichettati
+  </label>
+</div>
+
+**Код**
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox5" class="overflow-hidden d-block text-normal">
+    Il progetto utilizza convenzioni di codifica coerenti e nomi chiari di funzioni/metodi/variabili
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox6" class="overflow-hidden d-block text-normal">
+    Il codice è chiaramente commentato, documentando intenti e casi limite
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox7" class="overflow-hidden d-block text-normal">
+    Няма чувствителни материали в хронологията на редакциите, проблеми или заявки за изтегляне (например пароли или друга непублична информация)
+  </label>
+</div>
+
+**Хора**
+
+Se sei un privato:
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox8" class="overflow-hidden d-block text-normal">
+  Говорили сте с правния отдел и/или разбирате политиките за IP и отворен код на вашата компания (ако сте служител някъде)
+  </label>
+</div>
+
+Se sei un'azienda o un ente:
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox9" class="overflow-hidden d-block text-normal">
+    Hai parlato con il tuo dipartimento legale
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox10" class="overflow-hidden d-block text-normal">
+    Hai un piano di marketing per annunciare e promuovere il progetto
+  </label>
+</div>
+
+<div class="clearfix mb-2">
+  <input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox11" class="overflow-hidden d-block text-normal">
+    Qualcuno è impegnato a gestire le interazioni della comunità (rispondere ai problemi, rivedere e unire le richieste pull)
+  </label>
+</div>
+
+<div class="clearfix mb-4">
+  <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
+  <label for="cbox12" class="overflow-hidden d-block text-normal">
+    Almeno due persone hanno accesso amministrativo al progetto
+  </label>
+</div>
+
+## Fallo!
+
+Congratulazioni per il tuo primo progetto open source. Qualunque sia il risultato, il servizio pubblico è un dono per la comunità. Con ogni coinvolgimento, commento e richiesta pull, crei opportunità per te e gli altri di apprendere e crescere.
\ No newline at end of file
diff --git a/_data/locales/it.yml b/_data/locales/it.yml
new file mode 100644
index 00000000000..a475c6c4a1b
--- /dev/null
+++ b/_data/locales/it.yml
@@ -0,0 +1,31 @@
+it:
+  locale_name: Italiano
+  nav:
+    about: Chi siamo
+    contribute: Contribuire
+  index:
+    lead: Il software open source è creato da persone come te. Scopri come avviare e sviluppare il tuo progetto.
+    opensourcefriday: È venerdì! Investi qualche ora contribuendo al software che usi e ami
+  article:
+    table_of_contents: Contenuto
+    back_to_all_guides: Torna a tutte le guide
+    related_guides: Guide correlate
+  footer:
+    contribute:
+      heading: Contribuire
+      description: Vuoi dare un suggerimento? Questo contenuto è open source. Aiutaci a migliorarlo.
+      button: Contribuire
+    subscribe:
+      heading: Rimania in contatto
+      description: Sii il primo a conoscere gli ultimi suggerimenti e risorse open source su GitHub.
+      label: Email
+      button: Sottoscrivi
+    byline:
+      # [code], [love], and [github] will be replaced by octicons
+      format: "[code] con [love] da [github] e [amici]"
+      # Label for code octicon
+      code_label: code
+      # Label for love octicon
+      love_label: love
+      # Label for the contributors link
+      friends_label: friends
\ No newline at end of file

From 64676ee3cc22b447d7d4a3d7fa0ec56d1d626ab3 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Thu, 16 May 2024 19:15:45 +0200
Subject: [PATCH 681/749] fix the links

---
 _articles/it/building-community.md | 2 +-
 _articles/it/legal.md              | 6 +++---
 _articles/it/starting-a-project.md | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/_articles/it/building-community.md b/_articles/it/building-community.md
index ca9bbc4b76a..dc310250523 100644
--- a/_articles/it/building-community.md
+++ b/_articles/it/building-community.md
@@ -165,7 +165,7 @@ Vedi se riesci a trovare modi per condividere il più possibile la proprietà co
 
 * Se hai una community numerosa, **invia una newsletter o scrivi un post sul blog** ringraziando i contributori. [This Week in Rust](https://this-week-in-rust.org/) di Rust e [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) di Hood sono due ottimi esempi.
 
-* **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'.
+* **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.
 
diff --git a/_articles/it/legal.md b/_articles/it/legal.md
index 6f0c1b50011..8db4806177d 100644
--- a/_articles/it/legal.md
+++ b/_articles/it/legal.md
@@ -86,7 +86,7 @@ Ad esempio, man mano che il tuo progetto cresce, aggiunge dipendenze o utenti op
 
 **Detentori del copyright esistenti del tuo progetto.** Se sei l'unico collaboratore del tuo progetto, tu o la tua azienda siete gli unici detentori del copyright del progetto. Puoi aggiungere o modificare qualsiasi licenza tu o la tua azienda desideriate. In caso contrario, potrebbero esserci altri titolari di copyright di cui è necessario il consenso per modificare le licenze. Loro chi sono? [Le persone che si sono impegnate nel tuo progetto](https://github.com/thehale/git-authorship) è un buon punto di partenza. Ma in alcuni casi i diritti d'autore saranno detenuti dai datori di lavoro di quelle persone. In alcuni casi le persone avranno dato solo un contributo minimo, ma non esiste una regola ferrea secondo cui i contributi al di sotto di un certo numero di righe di codice non sono soggetti a copyright. Cosa fare? Dipende. Per un progetto relativamente piccolo e giovane, potrebbe essere possibile convincere tutti i contributori esistenti ad accettare una modifica della licenza in un problema o in una richiesta pull. Per progetti grandi e a lungo termine, potrebbe essere necessario cercare molti collaboratori e persino i loro successori. Mozilla ha impiegato anni (2001-2006) per concedere nuovamente la licenza a Firefox, Thunderbird e al relativo software.
 
-In alternativa, puoi chiedere ai contributori di pre-approvare alcune modifiche alla licenza tramite un contratto di collaborazione aggiuntivo ([vedi su](#quale-licenza-open-ource-è-datta-al-mio-progetto)). Ciò elimina parte della complessità della modifica delle licenze. Avrai bisogno di maggiore aiuto da parte dei tuoi avvocati in anticipo e vorrai comunque comunicare chiaramente con le parti interessate del progetto quando effettui una modifica della licenza.
+In alternativa, puoi chiedere ai contributori di pre-approvare alcune modifiche alla licenza tramite un contratto di collaborazione aggiuntivo ([vedi su](#quale-licenza-open-source-è-datta-al-mio-progetto)). Ciò elimina parte della complessità della modifica delle licenze. Avrai bisogno di maggiore aiuto da parte dei tuoi avvocati in anticipo e vorrai comunque comunicare chiaramente con le parti interessate del progetto quando effettui una modifica della licenza.
 
 ## Il mio progetto necessita di un contratto di collaborazione aggiuntivo?
 
@@ -122,11 +122,11 @@ Nel bene e nel male, considera di farglielo sapere, anche se si tratta di un pro
 
 **Se stai cercando un progetto open source per la tua azienda**, faglielo sapere. Probabilmente il tuo team legale ha già delle politiche su quale licenza open source (e forse un accordo di collaborazione aggiuntivo) da utilizzare in base ai requisiti aziendali e all'esperienza dell'azienda nel garantire che il tuo progetto sia conforme alle licenze delle sue dipendenze. In caso contrario, tu e loro siete fortunati! Il tuo team legale dovrebbe essere desideroso di lavorare con te per capire queste cose. Alcune cose a cui pensare:
 
-* **Materiale di terze parti:** Il tuo progetto ha dipendenze create da altri o include o utilizza in altro modo codice di terze parti? Se sono open source, dovrai rispettare le licenze open source dei materiali. Questo inizia con la scelta di una licenza che funzioni con licenze open source di terze parti ([vedi sopra](#quale-licenza-open-ource-è-datta-al-mio-progetto)). Se il tuo progetto modifica o distribuisce materiale open source di terze parti, il tuo team legale vorrà anche sapere se rispetti altri termini delle licenze open source di terze parti, come il mantenimento degli avvisi di copyright. Se il tuo progetto utilizza codice di terze parti che non dispone di una licenza open source, potresti dover chiedere ai manutentori di terze parti di [aggiungere una licenza open source](https://choosealicense.com/no-license/#for-users) e, se non riesci a ottenerne uno, smetti di usare il loro codice nel tuo progetto.
+* **Materiale di terze parti:** Il tuo progetto ha dipendenze create da altri o include o utilizza in altro modo codice di terze parti? Se sono open source, dovrai rispettare le licenze open source dei materiali. Questo inizia con la scelta di una licenza che funzioni con licenze open source di terze parti ([vedi sopra](#quale-licenza-open-source-è-datta-al-mio-progetto)). Se il tuo progetto modifica o distribuisce materiale open source di terze parti, il tuo team legale vorrà anche sapere se rispetti altri termini delle licenze open source di terze parti, come il mantenimento degli avvisi di copyright. Se il tuo progetto utilizza codice di terze parti che non dispone di una licenza open source, potresti dover chiedere ai manutentori di terze parti di [aggiungere una licenza open source](https://choosealicense.com/no-license/#for-users) e, se non riesci a ottenerne uno, smetti di usare il loro codice nel tuo progetto.
 
 * **Segreti commerciali:** Considera se c'è qualcosa nel progetto che l'azienda non vuole rendere disponibile al pubblico in generale. In tal caso, puoi aprire il resto del tuo progetto dopo aver estratto il materiale che desideri mantenere privato.
 
-* **Brevetti:** La tua azienda sta richiedendo un brevetto per il quale l'open source del tuo progetto costituirebbe [divulgazione pubblica](https://en.wikipedia.org/wiki/Public_disclosure)? Sfortunatamente, ti potrebbe essere chiesto di attendere (o forse la società riconsidererà la ragionevolezza della richiesta). Se ti aspetti contributi al tuo progetto da dipendenti di aziende con un ampio portafoglio di brevetti, il tuo team legale potrebbe richiederti di utilizzare una licenza con una concessione esplicita di brevetto da parte dei contributori (come Apache 2.0 o GPLv3) o un ulteriore accordo con il collaboratore ([vedi sopra ] (#quale-licenza-open-source-è-adatta-al-mio-progetto)).
+* **Brevetti:** La tua azienda sta richiedendo un brevetto per il quale l'open source del tuo progetto costituirebbe [divulgazione pubblica](https://en.wikipedia.org/wiki/Public_disclosure)? Sfortunatamente, ti potrebbe essere chiesto di attendere (o forse la società riconsidererà la ragionevolezza della richiesta). Se ti aspetti contributi al tuo progetto da dipendenti di aziende con un ampio portafoglio di brevetti, il tuo team legale potrebbe richiederti di utilizzare una licenza con una concessione esplicita di brevetto da parte dei contributori (come Apache 2.0 o GPLv3) o un ulteriore accordo con il collaboratore ([vedi sopra ](#quale-licenza-open-source-è-adatta-al-mio-progetto)).
 
 * **Marchi commerciali:** Controlla che il nome del tuo progetto [non sia in conflitto con i marchi esistenti](../starting-a-project/#evitare-conflitti-di-nomi). Se utilizzi i marchi della tua azienda nel progetto, controlla che non ci siano conflitti. [FOSSmarks](http://fossmarks.org/) è una guida pratica per comprendere i marchi nel contesto di progetti gratuiti e open source.
 
diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md
index 82476c0fd9e..1a8ced0e053 100644
--- a/_articles/it/starting-a-project.md
+++ b/_articles/it/starting-a-project.md
@@ -222,7 +222,7 @@ Pensa prima alla chiarezza. I giochi di parole sono divertenti, ma ricorda che a
 
 ### Evitare conflitti di nomi
 
-[Verifica la presenza di progetti open source con nomi simili](http://ivatomic.com/projects/ospnc/), soprattutto se condividi la stessa lingua o ecosistema. Se il tuo nome si sovrappone a un popolare progetto esistente, potresti confondere il tuo pubblico.
+[Verifica la presenza di progetti open source con nomi simili](https://ivatomic.com/), soprattutto se condividi la stessa lingua o ecosistema. Se il tuo nome si sovrappone a un popolare progetto esistente, potresti confondere il tuo pubblico.
 
 Se desideri che un sito web, un account Twitter o altre proprietà rappresentino il tuo progetto, assicurati di poter ottenere i nomi che desideri. Idealmente, [salva questi nomi adesso](https://instantdomainsearch.com/) per la massima tranquillità, anche se non intendi ancora utilizzarli.
 

From 9db15471f28fe0b451efdd0ea1f34b14972cdb82 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Fri, 17 May 2024 09:46:59 +0200
Subject: [PATCH 682/749] fix the links file legal and starting-a-project

---
 _articles/it/legal.md              | 2 +-
 _articles/it/starting-a-project.md | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/it/legal.md b/_articles/it/legal.md
index 8db4806177d..14a361f9044 100644
--- a/_articles/it/legal.md
+++ b/_articles/it/legal.md
@@ -62,7 +62,7 @@ Molto probabilmente il tuo progetto ha (o avrà) **dipendenze**, ognuna delle qu
 
 Dipendenze con **licenze permissive** come [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ ISC](https://choosealicense.com/licenses/isc) e [BSD](https://choosealicense.com/licenses/bsd-3-clause) ti consentono di concedere in licenza il tuo progetto come preferisci.
 
-Le dipendenze con **licenze di copyright** richiedono maggiore attenzione. Inclusa qualsiasi libreria con una licenza copyleft "forte" come [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), o [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) richiede la scelta di una licenza identica o [compatibile](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) per il tuo progetto. Librerie con una licenza copyleft "limitata" o "debole" come [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) e [LGPL](https://choosealicense.com/licenses/lgpl - 3.0/) può essere incluso in progetti con qualsiasi licenza, a condizione che si seguano le [regole aggiuntive](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) sottolineano.
+Le dipendenze con **licenze di copyright** richiedono maggiore attenzione. Inclusa qualsiasi libreria con una licenza copyleft "forte" come [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), o [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) richiede la scelta di una licenza identica o [compatibile](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) per il tuo progetto. Librerie con una licenza copyleft "limitata" o "debole" come [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) e [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) può essere incluso in progetti con qualsiasi licenza, a condizione che si seguano le [regole aggiuntive](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) sottolineano.
  
 Puoi anche controllare le **community** che speri di utilizzare e contribuire al tuo progetto:
 
diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md
index 1a8ced0e053..6866d09921d 100644
--- a/_articles/it/starting-a-project.md
+++ b/_articles/it/starting-a-project.md
@@ -16,7 +16,7 @@ Quindi stai pensando di iniziare con l'open source? Congratulazioni! Il mondo ap
 
 ### Cosa significa "open source"?
 
-Quando un progetto è open source, significa che **chiunque è libero di utilizzare, studiare, modificare e distribuire il tuo progetto per qualsiasi scopo.** Queste autorizzazioni si applicano tramite la [licenza open source](https://opensource.org/licenze).
+Quando un progetto è open source, significa che **chiunque è libero di utilizzare, studiare, modificare e distribuire il tuo progetto per qualsiasi scopo.** Queste autorizzazioni si applicano tramite la [licenza open source](https://opensource.org/licenses).
 
 L’open source è potente perché abbassa le barriere all’adozione e alla collaborazione, consentendo alle persone di distribuire e migliorare rapidamente i progetti. Anche perché offre agli utenti la possibilità di controllare i propri computer, rispetto al closed source. Ad esempio, un'azienda che utilizza software open source ha la possibilità di assumere qualcuno per apportare miglioramenti personalizzati al software invece di affidarsi esclusivamente alle soluzioni di prodotto di un fornitore closed source.
 

From 1df5ad8fe20542a1ba417f0c4359b300b7f15710 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Fri, 17 May 2024 09:54:35 +0200
Subject: [PATCH 683/749] fix the links file legam.md

---
 _articles/it/legal.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/_articles/it/legal.md b/_articles/it/legal.md
index 14a361f9044..0a841e46029 100644
--- a/_articles/it/legal.md
+++ b/_articles/it/legal.md
@@ -86,7 +86,7 @@ Ad esempio, man mano che il tuo progetto cresce, aggiunge dipendenze o utenti op
 
 **Detentori del copyright esistenti del tuo progetto.** Se sei l'unico collaboratore del tuo progetto, tu o la tua azienda siete gli unici detentori del copyright del progetto. Puoi aggiungere o modificare qualsiasi licenza tu o la tua azienda desideriate. In caso contrario, potrebbero esserci altri titolari di copyright di cui è necessario il consenso per modificare le licenze. Loro chi sono? [Le persone che si sono impegnate nel tuo progetto](https://github.com/thehale/git-authorship) è un buon punto di partenza. Ma in alcuni casi i diritti d'autore saranno detenuti dai datori di lavoro di quelle persone. In alcuni casi le persone avranno dato solo un contributo minimo, ma non esiste una regola ferrea secondo cui i contributi al di sotto di un certo numero di righe di codice non sono soggetti a copyright. Cosa fare? Dipende. Per un progetto relativamente piccolo e giovane, potrebbe essere possibile convincere tutti i contributori esistenti ad accettare una modifica della licenza in un problema o in una richiesta pull. Per progetti grandi e a lungo termine, potrebbe essere necessario cercare molti collaboratori e persino i loro successori. Mozilla ha impiegato anni (2001-2006) per concedere nuovamente la licenza a Firefox, Thunderbird e al relativo software.
 
-In alternativa, puoi chiedere ai contributori di pre-approvare alcune modifiche alla licenza tramite un contratto di collaborazione aggiuntivo ([vedi su](#quale-licenza-open-source-è-datta-al-mio-progetto)). Ciò elimina parte della complessità della modifica delle licenze. Avrai bisogno di maggiore aiuto da parte dei tuoi avvocati in anticipo e vorrai comunque comunicare chiaramente con le parti interessate del progetto quando effettui una modifica della licenza.
+In alternativa, puoi chiedere ai contributori di pre-approvare alcune modifiche alla licenza tramite un contratto di collaborazione aggiuntivo ([vedi su](#quale-licenza-open-source-è-adatta-al-mio-progetto)). Ciò elimina parte della complessità della modifica delle licenze. Avrai bisogno di maggiore aiuto da parte dei tuoi avvocati in anticipo e vorrai comunque comunicare chiaramente con le parti interessate del progetto quando effettui una modifica della licenza.
 
 ## Il mio progetto necessita di un contratto di collaborazione aggiuntivo?
 
@@ -122,11 +122,11 @@ Nel bene e nel male, considera di farglielo sapere, anche se si tratta di un pro
 
 **Se stai cercando un progetto open source per la tua azienda**, faglielo sapere. Probabilmente il tuo team legale ha già delle politiche su quale licenza open source (e forse un accordo di collaborazione aggiuntivo) da utilizzare in base ai requisiti aziendali e all'esperienza dell'azienda nel garantire che il tuo progetto sia conforme alle licenze delle sue dipendenze. In caso contrario, tu e loro siete fortunati! Il tuo team legale dovrebbe essere desideroso di lavorare con te per capire queste cose. Alcune cose a cui pensare:
 
-* **Materiale di terze parti:** Il tuo progetto ha dipendenze create da altri o include o utilizza in altro modo codice di terze parti? Se sono open source, dovrai rispettare le licenze open source dei materiali. Questo inizia con la scelta di una licenza che funzioni con licenze open source di terze parti ([vedi sopra](#quale-licenza-open-source-è-datta-al-mio-progetto)). Se il tuo progetto modifica o distribuisce materiale open source di terze parti, il tuo team legale vorrà anche sapere se rispetti altri termini delle licenze open source di terze parti, come il mantenimento degli avvisi di copyright. Se il tuo progetto utilizza codice di terze parti che non dispone di una licenza open source, potresti dover chiedere ai manutentori di terze parti di [aggiungere una licenza open source](https://choosealicense.com/no-license/#for-users) e, se non riesci a ottenerne uno, smetti di usare il loro codice nel tuo progetto.
+* **Materiale di terze parti:** Il tuo progetto ha dipendenze create da altri o include o utilizza in altro modo codice di terze parti? Se sono open source, dovrai rispettare le licenze open source dei materiali. Questo inizia con la scelta di una licenza che funzioni con licenze open source di terze parti ([vedi sopra](#quale-licenza-open-source-è-adatta-al-mio-progetto)). Se il tuo progetto modifica o distribuisce materiale open source di terze parti, il tuo team legale vorrà anche sapere se rispetti altri termini delle licenze open source di terze parti, come il mantenimento degli avvisi di copyright. Se il tuo progetto utilizza codice di terze parti che non dispone di una licenza open source, potresti dover chiedere ai manutentori di terze parti di [aggiungere una licenza open source](https://choosealicense.com/no-license/#for-users) e, se non riesci a ottenerne uno, smetti di usare il loro codice nel tuo progetto.
 
 * **Segreti commerciali:** Considera se c'è qualcosa nel progetto che l'azienda non vuole rendere disponibile al pubblico in generale. In tal caso, puoi aprire il resto del tuo progetto dopo aver estratto il materiale che desideri mantenere privato.
 
-* **Brevetti:** La tua azienda sta richiedendo un brevetto per il quale l'open source del tuo progetto costituirebbe [divulgazione pubblica](https://en.wikipedia.org/wiki/Public_disclosure)? Sfortunatamente, ti potrebbe essere chiesto di attendere (o forse la società riconsidererà la ragionevolezza della richiesta). Se ti aspetti contributi al tuo progetto da dipendenti di aziende con un ampio portafoglio di brevetti, il tuo team legale potrebbe richiederti di utilizzare una licenza con una concessione esplicita di brevetto da parte dei contributori (come Apache 2.0 o GPLv3) o un ulteriore accordo con il collaboratore ([vedi sopra ](#quale-licenza-open-source-è-adatta-al-mio-progetto)).
+* **Brevetti:** La tua azienda sta richiedendo un brevetto per il quale l'open source del tuo progetto costituirebbe [divulgazione pubblica](https://en.wikipedia.org/wiki/Public_disclosure)? Sfortunatamente, ti potrebbe essere chiesto di attendere (o forse la società riconsidererà la ragionevolezza della richiesta). Se ti aspetti contributi al tuo progetto da dipendenti di aziende con un ampio portafoglio di brevetti, il tuo team legale potrebbe richiederti di utilizzare una licenza con una concessione esplicita di brevetto da parte dei contributori (come Apache 2.0 o GPLv3) o un ulteriore accordo con il collaboratore ([vedi sopra](#quale-licenza-open-source-è-adatta-al-mio-progetto)).
 
 * **Marchi commerciali:** Controlla che il nome del tuo progetto [non sia in conflitto con i marchi esistenti](../starting-a-project/#evitare-conflitti-di-nomi). Se utilizzi i marchi della tua azienda nel progetto, controlla che non ci siano conflitti. [FOSSmarks](http://fossmarks.org/) è una guida pratica per comprendere i marchi nel contesto di progetti gratuiti e open source.
 

From 473a814b199e5274f1aec55233fc1c29c47ff13e Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Fri, 17 May 2024 10:04:42 +0200
Subject: [PATCH 684/749] fix the link into folder "ms" file legal.md line 101
 because it doesn't exist

---
 _articles/it/legal.md | 2 +-
 _articles/ms/legal.md | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/_articles/it/legal.md b/_articles/it/legal.md
index 0a841e46029..d8fcd5d6768 100644
--- a/_articles/it/legal.md
+++ b/_articles/it/legal.md
@@ -100,7 +100,7 @@ Inoltre, aggiungendo "documentazione" che alcuni ritengono non necessaria, diffi
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     Abbiamo rimosso il CLA per Node.js. Ciò riduce la barriera all’ingresso per i contributori di Node.js, espandendo così la base dei contributori.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Estensione dei contributi Node.js"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Estensione dei contributi Node.js"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/ms/legal.md b/_articles/ms/legal.md
index c235cf083c9..3885ab5f60b 100644
--- a/_articles/ms/legal.md
+++ b/_articles/ms/legal.md
@@ -98,7 +98,7 @@ Juga, dengan menambahkan "kertas kerja" yang diyakini oleh beberapa orang tidak
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
    Kami telah menghilangkan CLA untuk Node.js. Melakukan ini mengurangkan halangan kemasukan penyumbang Node.js sehingga memperluas pangkalan penyumbang.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 

From 9f42419ff6d91a8e1319c94eff09db056701f245 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Fri, 17 May 2024 10:16:32 +0200
Subject: [PATCH 685/749] I changed the link between lines 101 and 115 for the
 text Broadening Node.js Contributions in each legal.md file because it was
 persistent

---
 _articles/bg/legal.md      | 2 +-
 _articles/de/legal.md      | 2 +-
 _articles/el/legal.md      | 2 +-
 _articles/es/legal.md      | 2 +-
 _articles/fa/legal.md      | 2 +-
 _articles/fr/legal.md      | 2 +-
 _articles/hi/legal.md      | 2 +-
 _articles/hu/legal.md      | 2 +-
 _articles/id/legal.md      | 2 +-
 _articles/ja/legal.md      | 2 +-
 _articles/ko/legal.md      | 2 +-
 _articles/legal.md         | 2 +-
 _articles/nl/legal.md      | 2 +-
 _articles/pcm/legal.md     | 2 +-
 _articles/pl/legal.md      | 2 +-
 _articles/pt/legal.md      | 2 +-
 _articles/ro/legal.md      | 2 +-
 _articles/ru/legal.md      | 2 +-
 _articles/ta/legal.md      | 2 +-
 _articles/tr/legal.md      | 2 +-
 _articles/zh-hans/legal.md | 2 +-
 _articles/zh-hant/legal.md | 2 +-
 22 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
index 2e56c75652d..dc0024794da 100644
--- a/_articles/bg/legal.md
+++ b/_articles/bg/legal.md
@@ -100,7 +100,7 @@ related:
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     Премахнахме CLA за Node.js. Това намалява бариерата за навлизане на сътрудниците на Node.js, като по този начин разширява базата на сътрудниците.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Разширяване на Node.js приноси"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Разширяване на Node.js приноси"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/de/legal.md b/_articles/de/legal.md
index bcb45ca972a..919e8c8b671 100644
--- a/_articles/de/legal.md
+++ b/_articles/de/legal.md
@@ -106,7 +106,7 @@ Durch das Hinzufügen von "Papierkram", den einige für unnötig, schwer verstä
     _We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base._
 
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/el/legal.md b/_articles/el/legal.md
index 1abe77edf65..17a3a23c88a 100644
--- a/_articles/el/legal.md
+++ b/_articles/el/legal.md
@@ -98,7 +98,7 @@ related:
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     Εξαλείψαμε το CLA για το Node.js. Με αυτόν τον τρόπο μειώνουμε το εμπόδιο εισόδου για τους συνεισφέροντες του Node.js, διευρύνοντας έτσι τη βάση των συνεισφερόντων.
   <p markdown="1" class="pquote-credit">
-- @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+- @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/es/legal.md b/_articles/es/legal.md
index 241af52cf3c..3a35a1d90e2 100644
--- a/_articles/es/legal.md
+++ b/_articles/es/legal.md
@@ -99,7 +99,7 @@ Tambi&eacute;n, al a&ntilde;adir "papeleo" que algunos consideran innecesario, d
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     Hemos eliminado la CLA para Node.js. Esto, reduce la barrera de entrada para colaboradores de Node.js, ampliando as&iacute; la base de contribuyentes.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index 6184e649a43..ec3c92d0b54 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -98,7 +98,7 @@ related:
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     ما «توافق‌نامه مجوز مشارکت‌کننده» را برای «Node.js» حذف کردیم. انجام این کار موانع ورود مشارکت‌کنندگان به Node.js را کاهش می‌دهد و در نتیجه میزان مشارکت‌کنندگان را گسترش می‌دهد.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index 3a4c2818225..d1f6684bb81 100644
--- a/_articles/fr/legal.md
+++ b/_articles/fr/legal.md
@@ -98,7 +98,7 @@ En outre, en ajoutant de la "paperasse" jugée inutile, difficile à comprendre
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     Nous avons éliminé le CLA pour Node.js. Cela réduit la barrière à l'entrée pour les contributeurs Node.js, élargissant ainsi la base des contributeurs.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md
index 7c41426a213..e2338bbd91a 100644
--- a/_articles/hi/legal.md
+++ b/_articles/hi/legal.md
@@ -101,7 +101,7 @@ related:
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     हमने Node.js के लिए CLA को हटा दिया है। ऐसा करने से Node.js योगदानकर्ताओं के लिए प्रवेश की बाधा कम हो जाती है जिससे योगदानकर्ता आधार का विस्तार होता है।
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/hu/legal.md b/_articles/hu/legal.md
index 53395f7487e..bac119d5a27 100644
--- a/_articles/hu/legal.md
+++ b/_articles/hu/legal.md
@@ -98,7 +98,7 @@ Amikor ez olyan "papírmunkát" okoz, amit egyesek szükségtelennek, nehezen é
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     Megszüntettük a CLA-kat a Node.js projektben. Ezzel csökkenthető a közreműködői belépés előtt álló akadályok száma, ezáltal növelve a projektben résztvevők bázisát.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/id/legal.md b/_articles/id/legal.md
index 2747d1ff891..55a93340dc6 100644
--- a/_articles/id/legal.md
+++ b/_articles/id/legal.md
@@ -98,7 +98,7 @@ Juga, dengan menambahkan "pekerjaan administratif" yang dipercaya oleh sebagian
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     Kami telah menghilangkan CLA untuk Node.js. Dengan melakukan hal ini akan mengurangi hambatan bagi kontributor Node.js untuk bergabung sehingga memperluas area basis kontributor.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md
index 0f1be7475eb..3acc4cf2e65 100644
--- a/_articles/ja/legal.md
+++ b/_articles/ja/legal.md
@@ -98,7 +98,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
   Node.js では CLA を廃止しました。こうすることによって、 Node.js のコントリビューターになる敷居が下がり、コントリビューターの層を広げる事ができます。
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index 57ae35c31c8..de3c53fb3d0 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -98,7 +98,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Node.js 기여 확대"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Node.js 기여 확대"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/legal.md b/_articles/legal.md
index f0727ca1200..4f71db10270 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -100,7 +100,7 @@ Also, by adding "paperwork" that some believe is unnecessary, hard to understand
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
index 959495864a5..db8c07a420c 100644
--- a/_articles/nl/legal.md
+++ b/_articles/nl/legal.md
@@ -104,7 +104,7 @@ Door ook 'papierwerk' toe te voegen waarvan sommigen denken dat het onnodig, moe
     _We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base._
 
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Node.js-bijdragen verbreden"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Node.js-bijdragen verbreden"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 Enkele situaties waarin u wellicht een aanvullende bijdrageovereenkomst voor uw project wilt overwegen, zijn onder meer:
diff --git a/_articles/pcm/legal.md b/_articles/pcm/legal.md
index 7af472bef30..e4064022d10 100644
--- a/_articles/pcm/legal.md
+++ b/_articles/pcm/legal.md
@@ -100,7 +100,7 @@ Also, by adding "paperwork" that some believe is unnecessary, hard to understand
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/pl/legal.md b/_articles/pl/legal.md
index b04a307d79b..82a1d32419f 100644
--- a/_articles/pl/legal.md
+++ b/_articles/pl/legal.md
@@ -102,7 +102,7 @@ Ponadto poprzez dodanie „dokumentacji”, którą niektórzy uważają za niep
     We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
    </i>
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/pt/legal.md b/_articles/pt/legal.md
index 9f593bc73fe..83933ba9c30 100644
--- a/_articles/pt/legal.md
+++ b/_articles/pt/legal.md
@@ -99,7 +99,7 @@ Além disso, adicionando "papelada" que alguns acreditam ser desnecessária, dif
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     Nós eliminamos o CLA do Node.js. Isso reduziu a barreira de entrada para contribuidores Node.js, consequentemente expandindo a base de contribuidores.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/ro/legal.md b/_articles/ro/legal.md
index ed324150c7f..cc8aac227d2 100644
--- a/_articles/ro/legal.md
+++ b/_articles/ro/legal.md
@@ -112,7 +112,7 @@ De asemenea, prin adăugarea de „hârtii” pe care unii le cred nenecesare, g
     </em>
   </p>
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md
index 37b77211338..30681090907 100644
--- a/_articles/ru/legal.md
+++ b/_articles/ru/legal.md
@@ -98,7 +98,7 @@ related:
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     Мы удалили CLA для Node.js. Это снижает барьер для входа в Node.js, тем самым расширяя базу участников.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Расширение сообщества Node.js"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Расширение сообщества Node.js"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/ta/legal.md b/_articles/ta/legal.md
index 21966f56f7d..ea5d212b395 100644
--- a/_articles/ta/legal.md
+++ b/_articles/ta/legal.md
@@ -98,7 +98,7 @@ Yஉங்கள் திட்டம் **சார்புகள்** கொ
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     நாம் CLA ஐ Node.js க்கு அகற்றினோம். இதை செய்வதால், Node.js பங்களிப்பாளர்களுக்கு நுழைவுக்கான தடையை குறைக்கிறது, இதனால் பங்களிப்பு தளத்தை அதிகரிக்கிறது.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Node.js பங்களிப்புகளை அதிகரிக்கிறது"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Node.js பங்களிப்புகளை அதிகரிக்கிறது"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index a12c6ec348f..b6e7b77122a 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -98,7 +98,7 @@ Ayrıca, bazılarının gereksiz olduğuna, anlaşılmasının zor veya haksız
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
   Node.js için CLA'yı kaldırdık. Bunu yapmak, Node.js katılımcısı için giriş engelini azalttı ve böylece katılımcı tabanını genişletti.
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index 3f6fe8d3306..763d1149944 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -99,7 +99,7 @@ redirect_from: /zh-cn/legal/
   <img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
     我们已经删除了Node.js的CLA。这样做降低了Node.js贡献者的参与门槛，从而吸引更多的贡献者。
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 
diff --git a/_articles/zh-hant/legal.md b/_articles/zh-hant/legal.md
index df2d2ed9ef8..cd40cf324b8 100644
--- a/_articles/zh-hant/legal.md
+++ b/_articles/zh-hant/legal.md
@@ -99,7 +99,7 @@ redirect_from: /zh-tw/legal/
   <img src="https://avatars1.githubusercontent.com/u/328614?v=3&s=460" class="pquote-avatar" alt="avatar">
     我們已經刪除了Node.js的CLA。這樣做降低了Node.js貢獻者的參與門檻，從而吸引更多的貢獻者。
   <p markdown="1" class="pquote-credit">
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
   </p>
 </aside>
 

From 3d619adcbb8f267714e9d23b3fa009f7f948d89a Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Fri, 17 May 2024 10:51:50 +0200
Subject: [PATCH 686/749] fix the apostrophe in folder "it"

---
 _articles/it/best-practices.md                         |  4 ++--
 _articles/it/building-community.md                     | 10 +++++-----
 _articles/it/code-of-conduct.md                        |  7 ++++---
 _articles/it/finding-users.md                          |  4 ++--
 _articles/it/getting-paid.md                           |  8 ++++----
 _articles/it/how-to-contribute.md                      |  6 +++---
 _articles/it/leadership-and-governance.md              |  4 ++--
 _articles/it/legal.md                                  |  4 ++--
 .../maintaining-balance-for-open-source-maintainers.md |  4 ++--
 _articles/it/metrics.md                                |  4 ++--
 _articles/it/starting-a-project.md                     | 10 +++++-----
 11 files changed, 33 insertions(+), 32 deletions(-)

diff --git a/_articles/it/best-practices.md b/_articles/it/best-practices.md
index b9128aa7c16..73f290d99ec 100644
--- a/_articles/it/best-practices.md
+++ b/_articles/it/best-practices.md
@@ -119,7 +119,7 @@ Non dovresti avere più di 1-2 frasi a cui rispondere. Ad esempio, quando un ute
 
 [celery screenshot](/assets/images/best-practices/celery.png)
 
-Se l’idea di dire di no ti terrorizza, non sentirti sola. Come @jessfraz [dice](https://blog.jessfraz.com/post/the-art-of-closing/):
+Se l'idea di dire di no ti terrorizza, non sentirti sola. Come @jessfraz [dice](https://blog.jessfraz.com/post/the-art-of-closing/):
 
 > Ho parlato con manutentori del codice di molti diversi progetti open source, Mesos, Kubernetes, Chromium, e sono tutti d'accordo sul fatto che una delle parti più difficili dell'essere un manutentore del codice è: dire "No" alle patch che non vuoi utilizzare
 
@@ -242,7 +242,7 @@ Se vuoi diventare un po' più avanzato, le guide di stile possono standardizzare
 
 Tuttavia, se i tuoi standard sono troppo complessi, possono aumentare gli ostacoli alla contribuzione. Assicurati di aggiungere solo regole per rendere la vita più semplice a tutti.
 
-Se non sei sicuro di quali strumenti utilizzare, controlla cosa stanno facendo altri progetti popolari, in particolare quelli nel tuo ecosistema. Ad esempio, come si presenta il processo di contribuzione per gli altri moduli Node? Anche l’utilizzo di strumenti e approcci simili faciliterà. Rendi il tuo processo più familiare ai tuoi associati target.
+Se non sei sicuro di quali strumenti utilizzare, controlla cosa stanno facendo altri progetti popolari, in particolare quelli nel tuo ecosistema. Ad esempio, come si presenta il processo di contribuzione per gli altri moduli Node? Anche l'utilizzo di strumenti e approcci simili faciliterà. Rendi il tuo processo più familiare ai tuoi associati target.
 
 ## È una bella pausa
 
diff --git a/_articles/it/building-community.md b/_articles/it/building-community.md
index dc310250523..94ec2a38069 100644
--- a/_articles/it/building-community.md
+++ b/_articles/it/building-community.md
@@ -71,7 +71,7 @@ Se noti che molti utenti hanno lo stesso problema, documenta le risposte nel REA
 
 Per le riunioni, valuta la possibilità di pubblicare i tuoi appunti o i tuoi appunti in un thread correlato. Il feedback che otterrai da questo livello di trasparenza potrebbe sorprenderti.
 
-Documentare tutto vale anche per il lavoro che svolgi. Se stai lavorando a un aggiornamento importante del tuo progetto, inseriscilo in una richiesta pull e contrassegnalo come work in progress (WIP). In questo modo, altre persone possono sentirsi coinvolte fin dall’inizio nel processo.
+Documentare tutto vale anche per il lavoro che svolgi. Se stai lavorando a un aggiornamento importante del tuo progetto, inseriscilo in una richiesta pull e contrassegnalo come work in progress (WIP). In questo modo, altre persone possono sentirsi coinvolte fin dall'inizio nel processo.
 
 ### Sii reattivo
 
@@ -157,7 +157,7 @@ Le persone sono entusiaste di contribuire ai progetti quando sentono un senso di
 
 Vedi se riesci a trovare modi per condividere il più possibile la proprietà con la tua comunità. Ecco alcune idee:
 
-* **Evita di correggere bug facili (non critici).** Usali invece come opportunità per reclutare nuovi contributori o fare da mentore a qualcuno che vorrebbe contribuire. All’inizio può sembrare innaturale, ma il tuo investimento verrà ripagato nel tempo. Ad esempio, @michaeljoseph ha chiesto a un collaboratore di inviare una richiesta pull per il problema [Cookiecutter](https://github.com/audreyr/cookiecutter) di seguito invece di risolverlo da solo.
+* **Evita di correggere bug facili (non critici).** Usali invece come opportunità per reclutare nuovi contributori o fare da mentore a qualcuno che vorrebbe contribuire. All'inizio può sembrare innaturale, ma il tuo investimento verrà ripagato nel tempo. Ad esempio, @michaeljoseph ha chiesto a un collaboratore di inviare una richiesta pull per il problema [Cookiecutter](https://github.com/audreyr/cookiecutter) di seguito invece di risolverlo da solo.
 
 ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
@@ -187,7 +187,7 @@ Nelle prime fasi del tuo progetto, prendere decisioni importanti è facile. Quan
 
 Man mano che il tuo progetto diventa più popolare, sempre più persone saranno interessate alle decisioni che prendi. Anche se non hai una grande comunità di contributori, se il tuo progetto ha molti utenti, troverai persone che valutano soluzioni o sollevano i propri problemi.
 
-Nella maggior parte dei casi, se hai coltivato una comunità amichevole e rispettosa e hai documentato apertamente i tuoi processi, la tua comunità dovrebbe essere in grado di trovare una soluzione. Ma a volte ti imbatti in un problema un po’ più difficile da risolvere.
+Nella maggior parte dei casi, se hai coltivato una comunità amichevole e rispettosa e hai documentato apertamente i tuoi processi, la tua comunità dovrebbe essere in grado di trovare una soluzione. Ma a volte ti imbatti in un problema un po' più difficile da risolvere.
 
 ### Stabilisci lo standard di civiltà
 
@@ -219,7 +219,7 @@ Il voto può diventare politico quando i membri della comunità si sentono spint
 
 A volte è richiesto un voto di parità. Tuttavia, per quanto puoi, enfatizza ["la ricerca del consenso"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), piuttosto che consenso.
 
-In un processo di ricerca del consenso, i membri della comunità discutono le preoccupazioni chiave finché non sentono di essere stati adeguatamente ascoltati. Quando rimangono solo preoccupazioni secondarie, la comunità va avanti. La ricerca del consenso riconosce che una comunità potrebbe non essere in grado di arrivare a una risposta perfetta. Invece, dà priorità all’ascolto e alla discussione.
+In un processo di ricerca del consenso, i membri della comunità discutono le preoccupazioni chiave finché non sentono di essere stati adeguatamente ascoltati. Quando rimangono solo preoccupazioni secondarie, la comunità va avanti. La ricerca del consenso riconosce che una comunità potrebbe non essere in grado di arrivare a una risposta perfetta. Invece, dà priorità all'ascolto e alla discussione.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
@@ -269,7 +269,7 @@ Con un buon comportamento e una comunicazione chiara, le situazioni più diffici
 
 Un livellatore può essere il principale sostenitore del progetto, oppure può essere un piccolo gruppo di persone che prendono una decisione in base a un voto. Idealmente, è necessario definire un livellatore e la procedura associata in un file GOVERNANCE prima di doverlo utilizzare.
 
-La decisione sulla parità dovrebbe essere l'ultima risorsa. Le questioni di divisione rappresentano un’opportunità per la tua comunità di crescere e imparare. Cogli queste opportunità e utilizza un processo collaborativo per procedere verso la risoluzione quando possibile.
+La decisione sulla parità dovrebbe essere l'ultima risorsa. Le questioni di divisione rappresentano un'opportunità per la tua comunità di crescere e imparare. Cogli queste opportunità e utilizza un processo collaborativo per procedere verso la risoluzione quando possibile.
 
 ## La community è ❤️ open source
 
diff --git a/_articles/it/code-of-conduct.md b/_articles/it/code-of-conduct.md
index 1459c665d5e..678174ad1e2 100644
--- a/_articles/it/code-of-conduct.md
+++ b/_articles/it/code-of-conduct.md
@@ -12,7 +12,7 @@ related:
 
 ## Perché ho bisogno di un codice di condotta?
 
-Un codice di condotta è un documento che definisce le aspettative comportamentali dei partecipanti al tuo progetto. L’adozione e l’applicazione di un codice di condotta può contribuire a creare un’atmosfera sociale positiva per la tua comunità.
+Un codice di condotta è un documento che definisce le aspettative comportamentali dei partecipanti al tuo progetto. L'adozione e l'applicazione di un codice di condotta può contribuire a creare un'atmosfera sociale positiva per la tua comunità.
 
 I codici di condotta aiutano a proteggere non solo i tuoi partecipanti ma anche te stesso. Se stai portando avanti un progetto, potresti scoprire che l'atteggiamento improduttivo degli altri partecipanti può farti sentire svuotato o insoddisfatto del tuo lavoro nel tempo.
 
@@ -36,6 +36,7 @@ Usa la tecnica precedente dove puoi. [Accordo dei contributori](https://contribu
 Inserisci un file CODE_OF_CONDUCT nella directory principale del tuo progetto e rendilo visibile alla tua comunità collegandolo dal tuo file CONTRIBUTING o README.
 
 ## Decidi come applicherai il tuo codice di condotta
+
 <aside markdown="1" class="pquote">
   Un codice di condotta non applicato (o inapplicabile) è peggio di nessun codice di condotta: invia il messaggio che i valori del codice di condotta non sono realmente importanti o rispettati nella tua comunità.
   <p markdown="1" class="pquote-credit">
@@ -90,13 +91,13 @@ Esistono diversi modi per rispondere a una violazione del codice di condotta:
 
 * **Contatta di persona la persona in questione** per spiegare in che modo il suo comportamento ha influenzato negativamente gli altri. Potresti voler utilizzare un canale di comunicazione privato se la situazione coinvolge informazioni personali sensibili. Se stai comunicando con qualcuno in privato, è una buona idea mettere in copia coloro che per primi hanno segnalato la situazione in modo che sappiano che hai preso provvedimenti. Chiedere il consenso all'informatore prima di inviarlo in CC.
 
-A volte non è possibile raggiungere alcuna soluzione. La persona in questione può diventare aggressiva o ostile quando confrontata o non cambiare il proprio comportamento. In questa situazione, potresti prendere in considerazione l’idea di intraprendere azioni più drastiche. Per esempio:
+A volte non è possibile raggiungere alcuna soluzione. La persona in questione può diventare aggressiva o ostile quando confrontata o non cambiare il proprio comportamento. In questa situazione, potresti prendere in considerazione l'idea di intraprendere azioni più drastiche. Per esempio:
 
 * **Espulsione della persona in questione** dal progetto, imposta tramite un'interdizione temporanea dalla partecipazione a qualsiasi aspetto del progetto
 
 * **Permanente** banna la persona dal progetto
 
-L’esclusione dei membri non dovrebbe essere presa alla leggera e rappresenta una divergenza di opinioni permanente e inconciliabile. Dovresti adottare queste misure solo quando è chiaro che non è possibile raggiungere una soluzione.
+L'esclusione dei membri non dovrebbe essere presa alla leggera e rappresenta una divergenza di opinioni permanente e inconciliabile. Dovresti adottare queste misure solo quando è chiaro che non è possibile raggiungere una soluzione.
 
 ## Le tue responsabilità come manutentore
 
diff --git a/_articles/it/finding-users.md b/_articles/it/finding-users.md
index 6eedbf024c0..afb1811e05f 100644
--- a/_articles/it/finding-users.md
+++ b/_articles/it/finding-users.md
@@ -18,7 +18,7 @@ Non esiste una regola che dice che devi pubblicizzare un progetto open source al
 
 Prima di iniziare il lavoro vero e proprio di promozione del tuo progetto, devi essere in grado di spiegare cosa fa e perché è importante.
 
-Cosa rende il tuo progetto diverso o interessante? Perché l'hai creato? Rispondere solo a queste domande ti aiuterà a comunicare l’importanza del tuo progetto.
+Cosa rende il tuo progetto diverso o interessante? Perché l'hai creato? Rispondere solo a queste domande ti aiuterà a comunicare l'importanza del tuo progetto.
 
 Ricorda che le persone vengono coinvolte come utenti e alla fine diventano contributori perché il tuo progetto risolve loro un problema. Mentre pensi al messaggio e al valore del tuo progetto, prova a vederlo attraverso la lente di ciò che _utenti e contributori_ potrebbero desiderare.
 
@@ -81,7 +81,7 @@ Vedi se riesci a trovare modi per condividere il tuo progetto in modi appropriat
 * **Trova persone che affrontano il problema risolto dal tuo progetto.** Cerca nei forum correlati le persone che rientrano nel pubblico target del tuo progetto. Rispondi alla loro domanda e trova un modo discreto, se appropriato, per presentare il tuo progetto come soluzione.
 * **Chiedi feedback.** Presenta te stesso e il tuo lavoro a un pubblico che lo troverà pertinente e interessante. Sii specifico su chi ritieni trarrà beneficio dal tuo progetto. Prova a completare la frase: _"Penso che il mio progetto aiuterà davvero X persone che stanno cercando di fare Y_". Ascolta e rispondi al feedback degli altri invece di limitarti a promuovere il tuo lavoro.
 
-In generale, concentrati sull’aiutare gli altri prima di chiedere qualcosa in cambio. Dato che chiunque può facilmente pubblicizzare un progetto online, ci sarà molto fermento. Per distinguerti dalla massa, dai alle persone un contesto su chi sei, non solo cosa vuoi.
+In generale, concentrati sull'aiutare gli altri prima di chiedere qualcosa in cambio. Dato che chiunque può facilmente pubblicizzare un progetto online, ci sarà molto fermento. Per distinguerti dalla massa, dai alle persone un contesto su chi sei, non solo cosa vuoi.
 
 Se nessuno presta attenzione o risponde al tuo contatto iniziale, non scoraggiarti! La maggior parte dei lanci di progetti sono un processo iterativo che può richiedere mesi o anni. Se non ricevi risposta la prima volta, prova una tattica diversa o cerca prima modi per aggiungere valore al lavoro degli altri. Promuovere e lanciare il tuo progetto richiede tempo e dedizione.
 
diff --git a/_articles/it/getting-paid.md b/_articles/it/getting-paid.md
index 7f35ab451ad..53c164bacbb 100644
--- a/_articles/it/getting-paid.md
+++ b/_articles/it/getting-paid.md
@@ -62,7 +62,7 @@ Se stai cercando un sostegno finanziario, ci sono due modi da considerare. Puoi
 
 ## Finanziare il proprio tempo
 
-Oggi molte persone vengono pagate per lavorare part-time o full-time nell’open source. Il modo più comune per essere pagato per il tuo tempo è parlare con il tuo datore di lavoro.
+Oggi molte persone vengono pagate per lavorare part-time o full-time nell'open source. Il modo più comune per essere pagato per il tuo tempo è parlare con il tuo datore di lavoro.
 
 È più semplice sostenere il lavoro open source se il tuo datore di lavoro utilizza effettivamente il progetto, ma sii creativo con la tua presentazione. Forse il tuo datore di lavoro non utilizza il progetto, ma usa Python e il mantenimento di un progetto Python popolare aiuta ad attrarre nuovi sviluppatori Python. Forse fa sembrare il tuo datore di lavoro più amichevole agli sviluppatori in generale.
 
@@ -99,7 +99,7 @@ A seconda delle tue circostanze personali, puoi provare a raccogliere fondi in m
 
 Infine, a volte i progetti open source offrono premi per problemi che potresti considerare di aiutare.
 
-* @ConnorChristie è riuscito a essere pagato per [aiuto](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F% 2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol sta lavorando sulla propria libreria JavaScript [tramite ricompensa gitcoin](https://gitcoin.co/).
+* @ConnorChristie è riuscito a essere pagato per [aiuto](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol stanno lavorando sulla propria libreria JavaScript [tramite ricompensa gitcoin](https://gitcoin.co/).
 * @mamiM ha realizzato traduzioni giapponesi per @MetaMask dopo [il rilascio è stato finanziato da Bounties Network](https://explorer.bounties.network/bounty/134).
 
 ## Trovare finanziamenti per il tuo progetto
@@ -108,7 +108,7 @@ Oltre agli accordi per i singoli contributori, i progetti a volte raccolgono fon
 
 I finanziamenti organizzativi possono essere utilizzati per pagare i contributori attuali, coprire i costi di gestione del progetto (come le tariffe di hosting) o investire in nuove funzionalità o idee.
 
-Con la crescente popolarità dell’open source, trovare finanziamenti per i progetti è ancora sperimentale, ma esistono alcune opzioni comuni.
+Con la crescente popolarità dell'open source, trovare finanziamenti per i progetti è ancora sperimentale, ma esistono alcune opzioni comuni.
 
 ### Raccogli fondi per il tuo lavoro attraverso il crowdfunding o campagne di sponsorizzazione
 
@@ -163,7 +163,7 @@ Cosa otterrete esattamente con il finanziamento proposto? Concentrarsi sulle tap
 
 ### Come riceverai i fondi
 
-Il finanziatore ha dei requisiti di rimborso? Ad esempio, potrebbe essere necessario essere un'organizzazione senza scopo di lucro o avere uno sponsor fiscale senza scopo di lucro. O forse i fondi dovrebbero essere assegnati a un singolo appaltatore piuttosto che a un’organizzazione. Questi requisiti variano tra i finanziatori, quindi assicurati di fare le tue ricerche in anticipo.
+Il finanziatore ha dei requisiti di rimborso? Ad esempio, potrebbe essere necessario essere un'organizzazione senza scopo di lucro o avere uno sponsor fiscale senza scopo di lucro. O forse i fondi dovrebbero essere assegnati a un singolo appaltatore piuttosto che a un'organizzazione. Questi requisiti variano tra i finanziatori, quindi assicurati di fare le tue ricerche in anticipo.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/it/how-to-contribute.md b/_articles/it/how-to-contribute.md
index 5462d85c9d2..20e2308cfda 100644
--- a/_articles/it/how-to-contribute.md
+++ b/_articles/it/how-to-contribute.md
@@ -50,7 +50,7 @@ L'open source offre opportunità per esercitare capacità di leadership e gestio
 
 ### Essere in grado di apportare cambiamenti, anche piccoli, dà potere
 
-Non è necessario essere un collaboratore permanente per apprezzare la partecipazione all'open source. Hai mai visto un errore di battitura su un sito web e vorresti che qualcuno lo correggesse? In un progetto open source, puoi fare proprio questo. L’open source aiuta le persone a sentirsi indipendenti riguardo alla propria vita e al modo in cui sperimentano il mondo, e questo di per sé è soddisfacente.
+Non è necessario essere un collaboratore permanente per apprezzare la partecipazione all'open source. Hai mai visto un errore di battitura su un sito web e vorresti che qualcuno lo correggesse? In un progetto open source, puoi fare proprio questo. L'open source aiuta le persone a sentirsi indipendenti riguardo alla propria vita e al modo in cui sperimentano il mondo, e questo di per sé è soddisfacente.
 
 ## Cosa significa contribuire
 
@@ -70,7 +70,7 @@ Un malinteso comune riguardo al contributo all'open source è che si debba contr
   </p>
 </aside>
 
-Anche se ti piace scrivere codice, altri tipi di contributi sono un ottimo modo per essere coinvolto in un progetto e incontrare altri membri della comunità. Costruire queste relazioni ti darà l’opportunità di lavorare su altre parti del progetto.
+Anche se ti piace scrivere codice, altri tipi di contributi sono un ottimo modo per essere coinvolto in un progetto e incontrare altri membri della comunità. Costruire queste relazioni ti darà l'opportunità di lavorare su altre parti del progetto.
 
 ### Ti piace pianificare eventi?
 
@@ -433,7 +433,7 @@ Prima di aprire un problema o una richiesta pull o porre una domanda in chat, ti
 >
 > 😢 _"Perché non supporti il ​​mio caso d'uso? Questo è inaccettabile!"_
 
-**Soprattutto, mantienilo elegante.** L'open source è composto da contributori provenienti da tutto il mondo. Si perde il contesto tra lingue, culture, aree geografiche e fusi orari. Inoltre, la comunicazione scritta rende più difficile trasmettere il tono o l’umore. Assumi buone intenzioni in queste conversazioni. Va bene rifiutare educatamente un'idea, chiedere più contesto o chiarire ulteriormente la tua posizione. Prova solo a lasciare Internet in un posto migliore di quando l'hai trovato.
+**Soprattutto, mantienilo elegante.** L'open source è composto da contributori provenienti da tutto il mondo. Si perde il contesto tra lingue, culture, aree geografiche e fusi orari. Inoltre, la comunicazione scritta rende più difficile trasmettere il tono o l'umore. Assumi buone intenzioni in queste conversazioni. Va bene rifiutare educatamente un'idea, chiedere più contesto o chiarire ulteriormente la tua posizione. Prova solo a lasciare Internet in un posto migliore di quando l'hai trovato.
 
 ### Raccogli il contesto
 
diff --git a/_articles/it/leadership-and-governance.md b/_articles/it/leadership-and-governance.md
index e2d0c9aca80..896018a83eb 100644
--- a/_articles/it/leadership-and-governance.md
+++ b/_articles/it/leadership-and-governance.md
@@ -67,7 +67,7 @@ Se il tuo progetto ha una comunità di contributori molto attiva, puoi formare u
   </p>
 </aside>
 
-I team dirigenti potrebbero voler creare un canale designato (come su IRC) o incontrarsi regolarmente per discutere del progetto (come su Gitter o Google Hangout). Puoi anche rendere pubbliche queste riunioni in modo che altre persone possano ascoltarle. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), ad esempio, [prende ore di lavoro ogni settimana](https://github.com/cucumber/cucumber-ruby/blob/HEAD/ CONTRIBUIRE .md#talking-with-other-devs).
+I team dirigenti potrebbero voler creare un canale designato (come su IRC) o incontrarsi regolarmente per discutere del progetto (come su Gitter o Google Hangout). Puoi anche rendere pubbliche queste riunioni in modo che altre persone possano ascoltarle. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), ad esempio, [prende ore di lavoro ogni settimana](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUIRE.md#talking-with-other-devs).
 
 Una volta stabiliti i ruoli di leadership, assicurati di documentare come le persone possono raggiungerli! Stabilisci un processo chiaro su come qualcuno può diventare un sostenitore o unirsi a un sottocomitato nel tuo progetto e scrivilo nel tuo GOVERNANCE.md.
 
@@ -129,7 +129,7 @@ I progetti open source di successo vengono utilizzati da molte persone e aziende
 
 Man mano che il progetto diventa più diffuso, le persone con esperienza in esso diventano più richieste: potresti essere uno di loro! - e talvolta verranno pagati per il lavoro svolto sul progetto.
 
-È importante considerare l'attività commerciale come una cosa normale e semplicemente come un'altra fonte di energia per lo sviluppo. Naturalmente, gli sviluppatori pagati non dovrebbero ricevere un trattamento speciale rispetto a quelli non pagati; ogni contributo dovrebbe essere giudicato in base ai suoi meriti tecnici. Tuttavia, le persone dovrebbero sentirsi a proprio agio nell’impegnarsi in attività commerciali e sentirsi a proprio agio nel citare i propri casi d’uso quando si discute a favore di un particolare miglioramento o funzionalità.
+È importante considerare l'attività commerciale come una cosa normale e semplicemente come un'altra fonte di energia per lo sviluppo. Naturalmente, gli sviluppatori pagati non dovrebbero ricevere un trattamento speciale rispetto a quelli non pagati; ogni contributo dovrebbe essere giudicato in base ai suoi meriti tecnici. Tuttavia, le persone dovrebbero sentirsi a proprio agio nell'impegnarsi in attività commerciali e sentirsi a proprio agio nel citare i propri casi d'uso quando si discute a favore di un particolare miglioramento o funzionalità.
 
 "Commerciale" è pienamente compatibile con "open source". "Commerciale" significa semplicemente che da qualche parte sono coinvolti dei soldi, che il software viene utilizzato commercialmente, il che è sempre più probabile man mano che un progetto ottiene l'accettazione. (Quando il software open source viene utilizzato come parte di un prodotto non open source, il prodotto complessivo è ancora software "proprietario", sebbene, come l'open source, possa essere utilizzato per scopi commerciali e non commerciali.)
 
diff --git a/_articles/it/legal.md b/_articles/it/legal.md
index d8fcd5d6768..35f67a1c26f 100644
--- a/_articles/it/legal.md
+++ b/_articles/it/legal.md
@@ -60,7 +60,7 @@ Altrimenti, la scelta della giusta licenza open source per il tuo progetto dipen
 
 Molto probabilmente il tuo progetto ha (o avrà) **dipendenze**, ognuna delle quali avrà la propria licenza open source con termini che dovrai rispettare. Ad esempio, se stai rendendo open source un progetto Node.js, probabilmente utilizzerai le librerie di Node Package Manager (npm).
 
-Dipendenze con **licenze permissive** come [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ ISC](https://choosealicense.com/licenses/isc) e [BSD](https://choosealicense.com/licenses/bsd-3-clause) ti consentono di concedere in licenza il tuo progetto come preferisci.
+Dipendenze con **licenze permissive** come [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc) e [BSD](https://choosealicense.com/licenses/bsd-3-clause) ti consentono di concedere in licenza il tuo progetto come preferisci.
 
 Le dipendenze con **licenze di copyright** richiedono maggiore attenzione. Inclusa qualsiasi libreria con una licenza copyleft "forte" come [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), o [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) richiede la scelta di una licenza identica o [compatibile](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) per il tuo progetto. Librerie con una licenza copyleft "limitata" o "debole" come [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) e [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) può essere incluso in progetti con qualsiasi licenza, a condizione che si seguano le [regole aggiuntive](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) sottolineano.
  
@@ -82,7 +82,7 @@ Ad esempio, man mano che il tuo progetto cresce, aggiunge dipendenze o utenti op
 
 **È complicato.** Determinare la compatibilità e la conformità della licenza e chi possiede il copyright può diventare complicato e creare confusione molto rapidamente. Passare a una licenza nuova ma compatibile per nuove versioni e contributi è diverso dal concedere nuovamente in licenza tutti i contributi esistenti. Coinvolgi il tuo team legale al primo accenno di desiderio di modificare le licenze. Anche se hai o puoi ottenere il permesso dai detentori del copyright del tuo progetto per modificare la licenza, considera l'impatto della modifica sugli altri utenti e contributori al tuo progetto. Pensa a una modifica della licenza come a un "evento di gestione" per il tuo progetto, che è più probabile che si svolga senza intoppi con una comunicazione chiara e una consultazione con le parti interessate del progetto. Un motivo in più per scegliere e utilizzare una licenza adeguata per il tuo progetto fin dal suo inizio!
 
-**Licenza esistente del tuo progetto.** Se la licenza esistente del tuo progetto è compatibile con la licenza che desideri modificare, puoi semplicemente iniziare a utilizzare la nuova licenza. Questo perché se la licenza A è compatibile con la licenza B, rispetterai i termini di A rispettando allo stesso tempo i termini di B (ma non necessariamente il contrario). Pertanto, se stai attualmente utilizzando una licenza permissiva (ad esempio MIT), puoi passare a una licenza con più termini purché conservi una copia della licenza MIT e di eventuali avvisi di copyright associati (ovvero continui a rispettare i termini minimi della licenza licenza MIT). Ma se la tua licenza attuale non è permissiva (ad esempio copyleft o non hai una licenza) e non sei l'unico detentore del copyright, non puoi semplicemente cambiare la licenza del tuo progetto MIT. In sostanza, con una licenza permissiva, i detentori dei diritti d'autore del progetto hanno dato il permesso preventivo di modificare le licenze.
+**Licenza esistente del tuo progetto.** Se la licenza esistente del tuo progetto è compatibile con la licenza che desideri modificare, puoi semplicemente iniziare a utilizzare la nuova licenza. Questo perché se la licenza A è compatibile con la licenza B, rispetterai i termini di A rispettando allo stesso tempo i termini di B (ma non necessariamente il contrario). Pertanto, se stai attualmente utilizzando una licenza permissiva (ad esempio MIT), puoi passare a una licenza con più termini purché conservi una copia della licenza MIT e di eventuali avvisi di copyright associati (ovvero continui a rispettare i termini minimi della licenza MIT). Ma se la tua licenza attuale non è permissiva (ad esempio copyleft o non hai una licenza) e non sei l'unico detentore del copyright, non puoi semplicemente cambiare la licenza del tuo progetto MIT. In sostanza, con una licenza permissiva, i detentori dei diritti d'autore del progetto hanno dato il permesso preventivo di modificare le licenze.
 
 **Detentori del copyright esistenti del tuo progetto.** Se sei l'unico collaboratore del tuo progetto, tu o la tua azienda siete gli unici detentori del copyright del progetto. Puoi aggiungere o modificare qualsiasi licenza tu o la tua azienda desideriate. In caso contrario, potrebbero esserci altri titolari di copyright di cui è necessario il consenso per modificare le licenze. Loro chi sono? [Le persone che si sono impegnate nel tuo progetto](https://github.com/thehale/git-authorship) è un buon punto di partenza. Ma in alcuni casi i diritti d'autore saranno detenuti dai datori di lavoro di quelle persone. In alcuni casi le persone avranno dato solo un contributo minimo, ma non esiste una regola ferrea secondo cui i contributi al di sotto di un certo numero di righe di codice non sono soggetti a copyright. Cosa fare? Dipende. Per un progetto relativamente piccolo e giovane, potrebbe essere possibile convincere tutti i contributori esistenti ad accettare una modifica della licenza in un problema o in una richiesta pull. Per progetti grandi e a lungo termine, potrebbe essere necessario cercare molti collaboratori e persino i loro successori. Mozilla ha impiegato anni (2001-2006) per concedere nuovamente la licenza a Firefox, Thunderbird e al relativo software.
 
diff --git a/_articles/it/maintaining-balance-for-open-source-maintainers.md b/_articles/it/maintaining-balance-for-open-source-maintainers.md
index 644b85b34c5..bc4173c0dca 100644
--- a/_articles/it/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/it/maintaining-balance-for-open-source-maintainers.md
@@ -12,11 +12,11 @@ Man mano che il progetto open source cresce in popolarità, diventa importante s
 
 Per ottenere informazioni dettagliate sulle esperienze dei manutentori e sulle loro strategie di bilanciamento, abbiamo condotto un workshop con 40 membri della <a href="http://maintainers.github.com/">comunità dei manutentori</a>, che ci ha permesso di imparare da le loro esperienze di prima mano con il burnout open source e le pratiche che li hanno aiutati a mantenere l'equilibrio nel loro lavoro. È qui che entra in gioco il concetto di ecologia personale.
 
-Allora, cos’è l’ecologia personale? Come <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance% 2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">descritto dal Rockwood Leadership Institute</a>, implica "<strong>mantenere equilibrio, ritmo ed efficienza per sostenere la nostra energia per tutta la vita</strong>". Questo inquadra le nostre conversazioni, aiutando i sostenitori a riconoscere le loro azioni e i loro contributi come parti di un ecosistema più ampio che si evolve nel tempo. Burnout, una sindrome derivante dallo stress cronico sul lavoro, come [definita dall’OMS](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), non è raro tra i manutentori. Ciò spesso porta a una perdita di motivazione, incapacità di concentrazione e mancanza di empatia verso i colleghi e la comunità con cui lavori.
+Allora, cos'è l'ecologia personale? Come <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance% 2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">descritto dal Rockwood Leadership Institute</a>, implica "<strong>mantenere equilibrio, ritmo ed efficienza per sostenere la nostra energia per tutta la vita</strong>". Questo inquadra le nostre conversazioni, aiutando i sostenitori a riconoscere le loro azioni e i loro contributi come parti di un ecosistema più ampio che si evolve nel tempo. Burnout, una sindrome derivante dallo stress cronico sul lavoro, come [definita dall'OMS](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), non è raro tra i manutentori. Ciò spesso porta a una perdita di motivazione, incapacità di concentrazione e mancanza di empatia verso i colleghi e la comunità con cui lavori.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
-  Non riuscivo a concentrarmi o ad avviare un'attività. Mi mancava l’empatia nei confronti del consumatore.
+  Non riuscivo a concentrarmi o ad avviare un'attività. Mi mancava l'empatia nei confronti del consumatore.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/gabek">@gabek</a>, che supporta il server di streaming live Owncast, sull'impatto del burnout sul suo funzionamento open source
   </p>
diff --git a/_articles/it/metrics.md b/_articles/it/metrics.md
index dbb3d9e49d2..4b0001f1e8e 100644
--- a/_articles/it/metrics.md
+++ b/_articles/it/metrics.md
@@ -116,10 +116,10 @@ Prendi in considerazione [il monitoraggio del tempo impiegato da te (o da un alt
 
 Puoi anche misurare il tempo necessario per passare da una fase all'altra del processo di contribuzione, ad esempio:
 
-*Tempo medio in cui il problema rimane aperto
+* Tempo medio in cui il problema rimane aperto
 * Se i problemi vengono risolti dai PR
 * Se i problemi obsoleti sono chiusi
-*Tempo medio per unire una richiesta pull
+* Tempo medio per unire una richiesta pull
 
 ## Usa 📊 per conoscere le persone
 
diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md
index 6866d09921d..46052d7debf 100644
--- a/_articles/it/starting-a-project.md
+++ b/_articles/it/starting-a-project.md
@@ -18,7 +18,7 @@ Quindi stai pensando di iniziare con l'open source? Congratulazioni! Il mondo ap
 
 Quando un progetto è open source, significa che **chiunque è libero di utilizzare, studiare, modificare e distribuire il tuo progetto per qualsiasi scopo.** Queste autorizzazioni si applicano tramite la [licenza open source](https://opensource.org/licenses).
 
-L’open source è potente perché abbassa le barriere all’adozione e alla collaborazione, consentendo alle persone di distribuire e migliorare rapidamente i progetti. Anche perché offre agli utenti la possibilità di controllare i propri computer, rispetto al closed source. Ad esempio, un'azienda che utilizza software open source ha la possibilità di assumere qualcuno per apportare miglioramenti personalizzati al software invece di affidarsi esclusivamente alle soluzioni di prodotto di un fornitore closed source.
+L'open source è potente perché abbassa le barriere all'adozione e alla collaborazione, consentendo alle persone di distribuire e migliorare rapidamente i progetti. Anche perché offre agli utenti la possibilità di controllare i propri computer, rispetto al closed source. Ad esempio, un'azienda che utilizza software open source ha la possibilità di assumere qualcuno per apportare miglioramenti personalizzati al software invece di affidarsi esclusivamente alle soluzioni di prodotto di un fornitore closed source.
 
 _Software Libero_ si riferisce allo stesso insieme di progetti di _Open Source_. A volte vedrai anche [questi termini](https://en.wikipedia.org/wiki/Free_and_open-source_software) combinati come "software libero e open source" (FOSS) o "software libero e open source" (FLOSS). _Free_ e _libre_ si riferiscono alla libertà, [non al prezzo](#open-source-significa-gratuito).
 
@@ -64,7 +64,7 @@ Se non sei ancora convinto, prenditi un momento per pensare a quali potrebbero e
 
 Gli obiettivi possono aiutarti a capire su cosa lavorare, a cosa dire di no e dove hai bisogno dell'aiuto degli altri. Inizia chiedendoti _perché sto utilizzando questo progetto open source?_
 
-Non esiste un’unica risposta corretta a questa domanda. Puoi avere più obiettivi per un progetto o progetti diversi con obiettivi diversi.
+Non esiste un'unica risposta corretta a questa domanda. Puoi avere più obiettivi per un progetto o progetti diversi con obiettivi diversi.
 
 Se il tuo unico obiettivo è mettere in mostra il tuo lavoro, potresti non volere nemmeno un contributo e addirittura dirlo nel tuo README. D'altra parte, se desideri contributori, investirai tempo in una documentazione chiara e farai sentire i nuovi arrivati ​​i benvenuti.
 
@@ -135,8 +135,8 @@ I README fanno molto di più che spiegare come utilizzare il tuo progetto. Spieg
 
 Nel README, prova a rispondere alle seguenti domande:
 
-*Cosa fa questo progetto?
-*Perché è utile questo progetto?
+* Cosa fa questo progetto?
+* Perché è utile questo progetto?
 * Come iniziare?
 * Dove posso ottenere ulteriore aiuto se ne ho bisogno?
 
@@ -166,7 +166,7 @@ Un file CONTRIBUTO indica al tuo pubblico come partecipare al tuo progetto. Ad e
 
 Oltre ai dettagli tecnici, il file CONTRIBUTI è un'opportunità per comunicare le vostre aspettative per i contributi, come ad esempio:
 
-*I tipi di contributi che stai cercando
+* I tipi di contributi che stai cercando
 * La tua tabella di marcia o visione per il progetto
 * Come i contributori dovrebbero (o non dovrebbero) contattarti
 

From 5fe755f5dde3982cdaa3c6254a6071a66679c75a Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Fri, 17 May 2024 11:00:56 +0200
Subject: [PATCH 687/749] I translated the forgotten phrases in the file
 it/starting-a-project.md and
 bg/maintaining-balance-for-open-source-maintainers.md and add empty line
 files int folder "it"

---
 ...ntaining-balance-for-open-source-maintainers.md |  4 ++--
 _articles/it/best-practices.md                     |  2 +-
 _articles/it/finding-users.md                      |  2 +-
 _articles/it/how-to-contribute.md                  |  2 +-
 _articles/it/legal.md                              |  2 +-
 _articles/it/metrics.md                            |  2 +-
 _articles/it/starting-a-project.md                 | 14 +++++++-------
 7 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/_articles/bg/maintaining-balance-for-open-source-maintainers.md b/_articles/bg/maintaining-balance-for-open-source-maintainers.md
index d6cf1585838..3fdbc3a0b9e 100644
--- a/_articles/bg/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/bg/maintaining-balance-for-open-source-maintainers.md
@@ -116,7 +116,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 * **Използвайте инструменти:** Разгледайте инструменти като [GitHub Copilot](https://github.com/features/copilot/) и [GitHub Actions](https://github.com/features/actions), за да автоматизирате светски задачи и освободете времето си за по-значими приноси.
 
 <aside markdown="1" class="pquote">
- Use [Copilot](https://github.com/features/copilot/) за скучните неща - правете забавните неща
+ Използвайте [Copilot](https://github.com/features/copilot/) за скучните неща - правете забавните неща
   <p markdown="1" class="pquote-credit">
 — поддържащ отворен код
   </p>
@@ -158,7 +158,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
     Не е тайна, че поддръжката с отворен код има своите тъмни страни и една от тях е понякога да се налага да взаимодействате с доста неблагодарни, имащи право или направо токсични хора. С нарастването на популярността на даден проект нараства и честотата на този вид взаимодействие, което увеличава тежестта, поета от поддържащите, и вероятно се превръща в значителен рисков фактор за прегаряне на поддържащия.  
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, поддържащ Octoprint на [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>, поддържащ Octoprint на [Как да се справим с токсичните хора](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
 </aside>
 
diff --git a/_articles/it/best-practices.md b/_articles/it/best-practices.md
index 73f290d99ec..15064842755 100644
--- a/_articles/it/best-practices.md
+++ b/_articles/it/best-practices.md
@@ -272,4 +272,4 @@ Fare le vacanze è qualcosa di più delle semplici vacanze. Se non vuoi lavorare
 
 ## Prenditi cura di te prima!
 
-Mantenere un progetto popolare richiede competenze diverse rispetto alle prime fasi di crescita, ma non è per questo meno gratificante. In qualità di manutentore, eserciterai le capacità di leadership e di gestione delle persone a un livello che poche persone possono sperimentare. Anche se non è sempre facile da gestire, stabilire dei limiti chiari e prendere solo ciò che ti fa sentire a tuo agio ti aiuterà. per mantenerti felice, aggiornato e produttivo.
\ No newline at end of file
+Mantenere un progetto popolare richiede competenze diverse rispetto alle prime fasi di crescita, ma non è per questo meno gratificante. In qualità di manutentore, eserciterai le capacità di leadership e di gestione delle persone a un livello che poche persone possono sperimentare. Anche se non è sempre facile da gestire, stabilire dei limiti chiari e prendere solo ciò che ti fa sentire a tuo agio ti aiuterà. per mantenerti felice, aggiornato e produttivo.
diff --git a/_articles/it/finding-users.md b/_articles/it/finding-users.md
index afb1811e05f..080b6a433a0 100644
--- a/_articles/it/finding-users.md
+++ b/_articles/it/finding-users.md
@@ -145,4 +145,4 @@ Non esiste una soluzione immediata per creare un pubblico. Guadagnarsi la fiduci
 
 ## Continuare!
 
-Può volerci molto tempo prima che le persone notino il tuo progetto open source. Questo è buono! Alcuni dei progetti più popolari oggi hanno impiegato anni per raggiungere livelli elevati di attività. Concentrati sulla costruzione di relazioni invece di sperare che il tuo progetto ottenga spontaneamente popolarità. Sii paziente e continua a condividere il tuo lavoro con chi lo apprezza.
\ No newline at end of file
+Può volerci molto tempo prima che le persone notino il tuo progetto open source. Questo è buono! Alcuni dei progetti più popolari oggi hanno impiegato anni per raggiungere livelli elevati di attività. Concentrati sulla costruzione di relazioni invece di sperare che il tuo progetto ottenga spontaneamente popolarità. Sii paziente e continua a condividere il tuo lavoro con chi lo apprezza.
diff --git a/_articles/it/how-to-contribute.md b/_articles/it/how-to-contribute.md
index 20e2308cfda..d09af23984d 100644
--- a/_articles/it/how-to-contribute.md
+++ b/_articles/it/how-to-contribute.md
@@ -523,4 +523,4 @@ Evviva! Hai dato con successo un contributo open source!
 
 ## Fallo! 🎉
 
-Se hai appena dato il tuo primo contributo open source o stai cercando nuovi modi per contribuire, speriamo che tu sia ispirato ad agire. Anche se il tuo contributo non è stato accettato, assicurati di dire grazie quando il manutentore ha fatto uno sforzo per aiutarti. L'open source è creato da persone come te: un problema, una richiesta pull, un commento o il cinque alla volta.
\ No newline at end of file
+Se hai appena dato il tuo primo contributo open source o stai cercando nuovi modi per contribuire, speriamo che tu sia ispirato ad agire. Anche se il tuo contributo non è stato accettato, assicurati di dire grazie quando il manutentore ha fatto uno sforzo per aiutarti. L'open source è creato da persone come te: un problema, una richiesta pull, un commento o il cinque alla volta.
diff --git a/_articles/it/legal.md b/_articles/it/legal.md
index 35f67a1c26f..18ae5091cf3 100644
--- a/_articles/it/legal.md
+++ b/_articles/it/legal.md
@@ -157,4 +157,4 @@ Nel lungo termine, il tuo team legale può fare di più per aiutare l'azienda a
 </aside>
 
 * **Brevetti:** la tua azienda potrebbe voler aderire a [Open Invention Network](https://www.openinventionnetwork.com/), un pool di brevetti condiviso e sicuro per proteggere l'uso da parte dei membri di grandi progetti open source o per esplorare altre [licenze di brevetti alternative](https://www.eff.org/document/hacking-patent-system-2016).
-* **Governance:** Soprattutto se e quando ha senso trasferire un progetto a [un'entità legale esterna all'azienda](../leadership-and-governance/#ho-bisogno-di-una-persona-giuridica-per-sostenere-il-mio-progetto).
\ No newline at end of file
+* **Governance:** Soprattutto se e quando ha senso trasferire un progetto a [un'entità legale esterna all'azienda](../leadership-and-governance/#ho-bisogno-di-una-persona-giuridica-per-sostenere-il-mio-progetto).
diff --git a/_articles/it/metrics.md b/_articles/it/metrics.md
index 4b0001f1e8e..08716db858f 100644
--- a/_articles/it/metrics.md
+++ b/_articles/it/metrics.md
@@ -125,4 +125,4 @@ Puoi anche misurare il tempo necessario per passare da una fase all'altra del pr
 
 Comprendere le metriche ti aiuterà a costruire un progetto open source attivo e in crescita. Anche se non tieni traccia di tutte le metriche della dashboard, utilizza la struttura sopra per focalizzare la tua attenzione sul tipo di comportamento che aiuterà il tuo progetto a prosperare.
 
-[CHAOSS](https://chaoss.community/) è un'accogliente comunità open source focalizzata su analisi, metriche e software sulla salute della comunità.
\ No newline at end of file
+[CHAOSS](https://chaoss.community/) è un'accogliente comunità open source focalizzata su analisi, metriche e software sulla salute della comunità.
diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md
index 46052d7debf..296c2fc91ed 100644
--- a/_articles/it/starting-a-project.md
+++ b/_articles/it/starting-a-project.md
@@ -146,11 +146,11 @@ Puoi utilizzare il file README per rispondere ad altre domande, ad esempio come
   <img src="https://avatars.githubusercontent.com/tracymakes?s=180" class="pquote-avatar" alt="avatar">
   Una migliore documentazione significa più utenti, meno richieste di supporto e più contributori. (...) Ricorda che i tuoi lettori non sei tu. Ci sono persone che possono venire a un progetto che hanno background completamente diversi.
   <p markdown="1" class="pquote-credit">
-— @tracymakes, ["Пишете така, че думите ви да се четат (видео)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+— @tracymakes, ["Scrivi in ​​modo che le tue parole vengano lette (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
   </p>
 </aside>
 
-Понякога хората избягват да пишат README, защото смятат, че проектът е незавършен или не искат приноси. Всичко това са много добри причини да напиша такъв.
+A volte le persone evitano di scrivere un README perché pensano che il progetto sia incompiuto o non vogliono contributi. Questi sono tutti ottimi motivi per scriverne uno.
 
 Per ulteriore ispirazione, prova a utilizzare [la guida "Crea un README" di @dguo](https://www.makeareadme.com/) o [README nel modello](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) di @PurpleBooth per scrivere un completo README.
 
@@ -191,7 +191,7 @@ Collega il tuo file CONTRIBUTE dal tuo README in modo che più persone possano v
   <img src="https://avatars.githubusercontent.com/mlynch?s=180" class="pquote-avatar" alt="avatar">
   Tutti abbiamo avuto esperienze in cui ci siamo imbattuti in quello che probabilmente era un abuso, sia come manutentore che cercava di spiegare perché qualcosa dovrebbe essere in un certo modo, sia come utente... che poneva una semplice domanda. (...) Il Codice di condotta diventa un documento con riferimenti e collegamenti facili che dimostra che il vostro team prende molto sul serio il discorso costruttivo.
   <p markdown="1" class="pquote-credit">
-— @mlynch, ["Rendere l’open source un luogo più felice"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+— @mlynch, ["Rendere l'open source un luogo più felice"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
   </p>
 </aside>
 
@@ -216,7 +216,7 @@ Scegli un nome che sia facile da ricordare e che, idealmente, dia un'idea di ci
 * [Sentry](https://github.com/getsentry/sentry) monitora le applicazioni di segnalazione degli arresti anomali
 * [Thin](https://github.com/macournoyer/thin) è un server web Ruby facile e veloce
 
-Se stai sviluppando un progetto esistente, usare il loro nome come prefisso può aiutarti a chiarire cosa fa il tuo progetto (ad esempio [node-fetch](https://github.com/bitinn/node-fetch) porta `window .fetch ` a Node.js).
+Se stai sviluppando un progetto esistente, usare il loro nome come prefisso può aiutarti a chiarire cosa fa il tuo progetto (ad esempio [node-fetch](https://github.com/bitinn/node-fetch) porta `window.fetch` a Node.js).
 
 Pensa prima alla chiarezza. I giochi di parole sono divertenti, ma ricorda che alcune battute potrebbero non essere applicabili ad altre culture o persone con esperienze diverse dalle tue. Alcuni dei tuoi potenziali utenti potrebbero essere dipendenti dell'azienda: non vuoi farli sentire a disagio quando devono spiegare il tuo progetto al lavoro!
 
@@ -305,7 +305,7 @@ Pronto per aprire il tuo progetto? Ecco una lista di controllo per aiutarti. Sel
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    Няма чувствителни материали в хронологията на редакциите, проблеми или заявки за изтегляне (например пароли или друга непублична информация)
+    Nessun materiale sensibile nella cronologia delle modifiche, nei problemi o nelle richieste pull (ad esempio password o altre informazioni non pubbliche)
   </label>
 </div>
 
@@ -316,7 +316,7 @@ Se sei un privato:
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-  Говорили сте с правния отдел и/или разбирате политиките за IP и отворен код на вашата компания (ако сте служител някъде)
+  Hai parlato con l'ufficio legale e/o hai compreso le politiche open source e IP della tua azienda (se sei un dipendente da qualche parte)
   </label>
 </div>
 
@@ -352,4 +352,4 @@ Se sei un'azienda o un ente:
 
 ## Fallo!
 
-Congratulazioni per il tuo primo progetto open source. Qualunque sia il risultato, il servizio pubblico è un dono per la comunità. Con ogni coinvolgimento, commento e richiesta pull, crei opportunità per te e gli altri di apprendere e crescere.
\ No newline at end of file
+Congratulazioni per il tuo primo progetto open source. Qualunque sia il risultato, il servizio pubblico è un dono per la comunità. Con ogni coinvolgimento, commento e richiesta pull, crei opportunità per te e gli altri di apprendere e crescere.

From 0b001cd99d8466f6a48b098a98858f6b957a9280 Mon Sep 17 00:00:00 2001
From: BlueButterflies <dsvk23020818@outlook.it>
Date: Fri, 17 May 2024 11:04:52 +0200
Subject: [PATCH 688/749] add new empty line file maintainin-balance folder it

---
 _articles/it/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/it/maintaining-balance-for-open-source-maintainers.md b/_articles/it/maintaining-balance-for-open-source-maintainers.md
index bc4173c0dca..6ed6b760fc8 100644
--- a/_articles/it/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/it/maintaining-balance-for-open-source-maintainers.md
@@ -217,4 +217,4 @@ Questa guida è stata scritta da [@abbycabs](https://github.com/abbycabs) con il
 [@thisisnic](https://github.com/thisisnic)
 [@tudoramariei](https://github.com/tudoramariei)
 [@UlisesGascon](https://github.com/UlisesGascon)
-[@waldyrious](https://github.com/waldyrious) + moltri altri!
\ No newline at end of file
+[@waldyrious](https://github.com/waldyrious) + moltri altri!

From 21ac79b5146f8aede5862a7ae0b7d81b03881f7f Mon Sep 17 00:00:00 2001
From: jmeridth <jmeridth@gmail.com>
Date: Fri, 17 May 2024 17:35:22 -0500
Subject: [PATCH 689/749] fix: use SHAs for GitHub Actions instead of tags

Adhere to best security practices and use SHAs for GitHub Actions
and not tags (they can be changed).

I used [`frizbee`](https://github.com/stacklok/frizbee) to do this.

`frizbee ghactions -d .github/workflows/`

Signed-off-by: jmeridth <jmeridth@gmail.com>
---
 .github/workflows/jekyll-preview.yml | 15 +++++--------
 .github/workflows/jekyll.yml         | 16 +++++---------
 .github/workflows/stale.yml          | 26 +++++++++++-----------
 .github/workflows/tests.yml          | 32 ++++++++++++----------------
 4 files changed, 36 insertions(+), 53 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index 99b8d2287b0..8101051d204 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -5,24 +5,20 @@
 
 # Sample workflow for building and deploying a Jekyll site to GitHub Pages
 name: Deploy Jekyll site to Pages preview environment
-
 on:
   # Runs on pull requests targeting the default branch
   pull_request_target:
     branches: ["main"]
-
 # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
 permissions:
   contents: read
   pages: write
   id-token: write
-
 # Allow only one concurrent deployment per PR, skipping runs queued between the run in-progress and latest queued.
 # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
 concurrency:
   group: 'pages-preview @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}'
   cancel-in-progress: false
-
 jobs:
   # Build job
   build:
@@ -32,22 +28,21 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4
         with:
           # For PRs make sure to checkout the PR branch
           ref: ${{ github.event.pull_request.head.ref }}
           repository: ${{ github.event.pull_request.head.repo.full_name }}
       - name: Setup Pages
-        uses: actions/configure-pages@v5
+        uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5
       - name: Build with Jekyll
-        uses: actions/jekyll-build-pages@v1
+        uses: actions/jekyll-build-pages@b178f9334b208360999a0a57b523613563698c66 # v1
         with:
           source: ./
           destination: ./_site
       - name: Upload artifact
         # Automatically uploads an artifact from the './_site' directory by default
-        uses: actions/upload-pages-artifact@v3
-
+        uses: actions/upload-pages-artifact@56afc609e74202658d3ffba0e8f6dda462b719fa # v3
   # Deployment job
   deploy:
     environment:
@@ -63,6 +58,6 @@ jobs:
     steps:
       - name: Deploy to GitHub Pages
         id: deployment
-        uses: actions/deploy-pages@v4
+        uses: actions/deploy-pages@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4
         with:
           preview: 'true'
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index 3d037c61fe1..5dc667e5159 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -5,45 +5,39 @@
 
 # Sample workflow for building and deploying a Jekyll site to GitHub Pages
 name: Deploy Jekyll site to Pages
-
 on:
   # Runs on pushes targeting the default branch
   push:
     branches: ["main"]
-
   # Allows you to run this workflow manually from the Actions tab
   workflow_dispatch:
-
 # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
 permissions:
   contents: read
   pages: write
   id-token: write
-
 # Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
 # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
 concurrency:
   group: "pages"
   cancel-in-progress: false
-
 jobs:
   # Build job
   build:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4
       - name: Setup Pages
-        uses: actions/configure-pages@v5
+        uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5
       - name: Build with Jekyll
-        uses: actions/jekyll-build-pages@v1
+        uses: actions/jekyll-build-pages@b178f9334b208360999a0a57b523613563698c66 # v1
         with:
           source: ./
           destination: ./_site
       - name: Upload artifact
         # Automatically uploads an artifact from the './_site' directory by default
-        uses: actions/upload-pages-artifact@v3
-
+        uses: actions/upload-pages-artifact@56afc609e74202658d3ffba0e8f6dda462b719fa # v3
   # Deployment job
   deploy:
     environment:
@@ -54,4 +48,4 @@ jobs:
     steps:
       - name: Deploy to GitHub Pages
         id: deployment
-        uses: actions/deploy-pages@v4
+        uses: actions/deploy-pages@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4
diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
index 1170f75b4cc..063c3c76c9f 100644
--- a/.github/workflows/stale.yml
+++ b/.github/workflows/stale.yml
@@ -2,21 +2,19 @@ name: Mark stale PRs
 on:
   workflow_dispatch:
   schedule:
-  - cron: "0 12 * * *"
-
+    - cron: "0 12 * * *"
 jobs:
   stale:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/stale@v9
-      with:
-        stale-pr-message: >
-          This pull request has been automatically marked as stale because it has not
-          had recent activity. It will be closed if no further activity occurs.
-          Thank you for your contributions.
-        stale-pr-label: "stale"
-        exempt-pr-labels: "pinned,security"
-        days-before-pr-stale: 30
-        days-before-pr-close: 7
-        ascending: true
-        operations-per-run: 100
+      - uses: actions/stale@28ca1036281a5e5922ead5184a1bbf96e5fc984e # v9
+        with:
+          stale-pr-message: >
+            This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
+
+          stale-pr-label: "stale"
+          exempt-pr-labels: "pinned,security"
+          days-before-pr-stale: 30
+          days-before-pr-close: 7
+          ascending: true
+          operations-per-run: 100
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index ed3402cdbc8..a727901f594 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -8,21 +8,17 @@ jobs:
   tests:
     runs-on: ubuntu-latest
     steps:
-    - name: Set up Git repository
-      uses: actions/checkout@v4
-
-    - name: Set up Ruby
-      uses: ruby/setup-ruby@v1
-      with:
-        bundler-cache: true
-
-    - name: Set up Node
-      uses: actions/setup-node@v4
-
-    - name: Bootstrap
-      run: script/bootstrap
-      env:
-        SKIP_BUNDLER: true
-
-    - name: Tests
-      run: script/test
+      - name: Set up Git repository
+        uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4
+      - name: Set up Ruby
+        uses: ruby/setup-ruby@cacc9f1c0b3f4eb8a16a6bb0ed10897b43b9de49 # v1
+        with:
+          bundler-cache: true
+      - name: Set up Node
+        uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4
+      - name: Bootstrap
+        run: script/bootstrap
+        env:
+          SKIP_BUNDLER: true
+      - name: Tests
+        run: script/test

From 201390f1fbf24c8152d33a4f8821afc52f0f8c2a Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 24 May 2024 04:55:12 +0000
Subject: [PATCH 690/749] build(deps): bump actions/checkout from 4.1.4 to
 4.1.6

Bumps [actions/checkout](https://github.com/actions/checkout) from 4.1.4 to 4.1.6.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/0ad4b8fadaa221de15dcec353f45205ec38ea70b...a5ac7e51b41094c92402da3b24376905380afc29)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/jekyll-preview.yml | 2 +-
 .github/workflows/jekyll.yml         | 2 +-
 .github/workflows/tests.yml          | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index 8101051d204..88984408e0f 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -28,7 +28,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4
+        uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # v4
         with:
           # For PRs make sure to checkout the PR branch
           ref: ${{ github.event.pull_request.head.ref }}
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index 5dc667e5159..41037d9c29f 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -27,7 +27,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4
+        uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # v4
       - name: Setup Pages
         uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5
       - name: Build with Jekyll
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index a727901f594..cb569354e8e 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -9,7 +9,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Git repository
-        uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4
+        uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # v4
       - name: Set up Ruby
         uses: ruby/setup-ruby@cacc9f1c0b3f4eb8a16a6bb0ed10897b43b9de49 # v1
         with:

From b58f25306144788b2614c7e220676b0bfd3dbec0 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 24 May 2024 04:55:15 +0000
Subject: [PATCH 691/749] build(deps): bump ruby/setup-ruby from 1.176.0 to
 1.177.1

Bumps [ruby/setup-ruby](https://github.com/ruby/setup-ruby) from 1.176.0 to 1.177.1.
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Commits](https://github.com/ruby/setup-ruby/compare/cacc9f1c0b3f4eb8a16a6bb0ed10897b43b9de49...943103cae7d3f1bb1e4951d5fcc7928b40e4b742)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index a727901f594..21e949bdff1 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@cacc9f1c0b3f4eb8a16a6bb0ed10897b43b9de49 # v1
+        uses: ruby/setup-ruby@943103cae7d3f1bb1e4951d5fcc7928b40e4b742 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From fe4f356299a767ebe5d110dc772a22686d25b5d3 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 4 Jun 2024 05:02:43 +0000
Subject: [PATCH 692/749] build(deps): bump ruby/setup-ruby from 1.177.1 to
 1.179.0

Bumps [ruby/setup-ruby](https://github.com/ruby/setup-ruby) from 1.177.1 to 1.179.0.
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Commits](https://github.com/ruby/setup-ruby/compare/943103cae7d3f1bb1e4951d5fcc7928b40e4b742...d5fb7a202fc07872cb44f00ba8e6197b70cb0c55)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index e91b75062a6..31615dd045b 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@943103cae7d3f1bb1e4951d5fcc7928b40e4b742 # v1
+        uses: ruby/setup-ruby@d5fb7a202fc07872cb44f00ba8e6197b70cb0c55 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 934a9ddc4ee0fcf933072ba9f9dfeb9f8c8a92b6 Mon Sep 17 00:00:00 2001
From: Jason Meridth <jmeridth@gmail.com>
Date: Mon, 10 Jun 2024 00:37:45 -0500
Subject: [PATCH 693/749] chore: group dependencies

Group dependencies by minor/patch to reduce PRs. Keep major version updates in their own PRs for visibility and testing.
---
 .github/dependabot.yml | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index 7614cdd021b..b65eb374905 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -10,15 +10,39 @@ updates:
       separator: "-"
     open-pull-requests-limit: 99
     rebase-strategy: disabled
+    commit-message:
+      prefix: "chore(deps)"
+    groups:
+      dependencies:
+        applies-to: version-updates
+        update-types:
+          - "minor"
+          - "patch"
   - package-ecosystem: "github-actions"
     directory: "/"
     schedule: 
      interval: daily
     open-pull-requests-limit: 99
     rebase-strategy: disabled
+    commit-message:
+      prefix: "chore(deps)"
+    groups:
+      dependencies:
+        applies-to: version-updates
+        update-types:
+          - "minor"
+          - "patch"
   - package-ecosystem: bundler
     directory: "/"
     schedule:
       interval: daily
     versioning-strategy: increase
     open-pull-requests-limit: 99
+    commit-message:
+      prefix: "chore(deps)"
+    groups:
+      dependencies:
+        applies-to: version-updates
+        update-types:
+          - "minor"
+          - "patch"

From 4fd2e41b32fa4a9a5bb3e12987f679e5b7b28c5b Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 13 Jun 2024 04:26:20 +0000
Subject: [PATCH 694/749] build(deps): bump actions/checkout from 4.1.6 to
 4.1.7

Bumps [actions/checkout](https://github.com/actions/checkout) from 4.1.6 to 4.1.7.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/a5ac7e51b41094c92402da3b24376905380afc29...692973e3d937129bcbf40652eb9f2f61becf3332)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/jekyll-preview.yml | 2 +-
 .github/workflows/jekyll.yml         | 2 +-
 .github/workflows/tests.yml          | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index 88984408e0f..6900c3bc23f 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -28,7 +28,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # v4
+        uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
         with:
           # For PRs make sure to checkout the PR branch
           ref: ${{ github.event.pull_request.head.ref }}
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index 41037d9c29f..662d70b0d57 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -27,7 +27,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # v4
+        uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Setup Pages
         uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5
       - name: Build with Jekyll
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 31615dd045b..57d9f086478 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -9,7 +9,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Git repository
-        uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # v4
+        uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Set up Ruby
         uses: ruby/setup-ruby@d5fb7a202fc07872cb44f00ba8e6197b70cb0c55 # v1
         with:

From d80d4e798fee70118c8eab64c6f18d1c0ac2514c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Oskar=20Dudzi=C5=84ski?=
 <56404247+oskvr37@users.noreply.github.com>
Date: Thu, 13 Jun 2024 14:06:58 +0200
Subject: [PATCH 695/749] Changed outdated URL

---
 _articles/starting-a-project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/starting-a-project.md b/_articles/starting-a-project.md
index b2e49d630af..713b8df38d1 100644
--- a/_articles/starting-a-project.md
+++ b/_articles/starting-a-project.md
@@ -223,7 +223,7 @@ Consider clarity above all. Puns are fun, but remember that some jokes might not
 
 ### Avoiding name conflicts
 
-[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+[Check for open source projects with a similar name](https://namechecker.vercel.app/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
 
 If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
 

From ac4411293a8188ef63c4035ac23c0c8beee2b2d8 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 13 Jun 2024 12:13:34 +0000
Subject: [PATCH 696/749] build(deps): bump ruby/setup-ruby from 1.179.0 to
 1.180.0

Bumps [ruby/setup-ruby](https://github.com/ruby/setup-ruby) from 1.179.0 to 1.180.0.
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Commits](https://github.com/ruby/setup-ruby/compare/d5fb7a202fc07872cb44f00ba8e6197b70cb0c55...ff740bc00a01b3a50fffc55a1071b1060eeae9dc)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 57d9f086478..edfa656136b 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@d5fb7a202fc07872cb44f00ba8e6197b70cb0c55 # v1
+        uses: ruby/setup-ruby@ff740bc00a01b3a50fffc55a1071b1060eeae9dc # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 16f679bb448441b87fb3d437fbbc8f888f59564e Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Fri, 14 Jun 2024 15:46:49 -0700
Subject: [PATCH 697/749] Fix 404d link to MDN workflow file

---
 _articles/bg/how-to-contribute.md  | 2 +-
 _articles/how-to-contribute.md     | 2 +-
 _articles/it/how-to-contribute.md  | 2 +-
 _articles/pcm/how-to-contribute.md | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/bg/how-to-contribute.md b/_articles/bg/how-to-contribute.md
index 68d7cfbb6c9..4cce7d2aee3 100644
--- a/_articles/bg/how-to-contribute.md
+++ b/_articles/bg/how-to-contribute.md
@@ -181,7 +181,7 @@ related:
 И накрая, проектите с отворен код използват следните инструменти за организиране на дискусия. Четенето на архивите ще ви даде добра представа за това как общността мисли и работи.
 
 * **Проследяване на проблеми:** Където хората обсъждат въпроси, свързани с проекта.
-* **Заявки за изтегляне:** Когато хората обсъждат и преглеждат промените, които са в ход, независимо дали са за подобряване на реда код на сътрудника, използването на граматика, използването на изображения и т.н. Някои проекти, като [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), използват определени потоци за действие на GitHub, за да автоматизират и ускорят своите прегледи на кода.
+* **Заявки за изтегляне:** Когато хората обсъждат и преглеждат промените, които са в ход, независимо дали са за подобряване на реда код на сътрудника, използването на граматика, използването на изображения и т.н. Някои проекти, като [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), използват определени потоци за действие на GitHub, за да автоматизират и ускорят своите прегледи на кода.
 * **Дискусионни форуми или пощенски списъци:** Някои проекти могат да използват тези канали за теми за разговор (например _"Как да..."_ или _"Какво мислиш за..."_ вместо грешка отчети или заявки за функции). Други използват инструмента за проследяване на проблеми за всички разговори. Добър пример за това би бил [седмичният бюлетин на CHAOSS](https://chaoss.community/news/)
 * **Синхронен чат канал:** Някои проекти използват чат канали (като Slack или IRC) за непринуден разговор, сътрудничество и бърз обмен. Добър пример за това би била [общността на Discord на EddieHub](http://discord.eddiehub.org/).
 
diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 88e3adefb17..42877c233ee 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -181,7 +181,7 @@ A project also has documentation. These files are usually listed in the top leve
 Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
 
 * **Issue tracker:** Where people discuss issues related to the project.
-* **Pull requests:** Where people discuss and review changes that are in progress whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), use certain GitHub Action flows to automate and quicken their code reviews.  
+* **Pull requests:** Where people discuss and review changes that are in progress whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), use certain GitHub Action flows to automate and quicken their code reviews.  
 * **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/)
 * **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/).
 
diff --git a/_articles/it/how-to-contribute.md b/_articles/it/how-to-contribute.md
index d09af23984d..66c3084b058 100644
--- a/_articles/it/how-to-contribute.md
+++ b/_articles/it/how-to-contribute.md
@@ -181,7 +181,7 @@ C'è anche la documentazione del progetto. Questi file sono generalmente elencat
 Infine, i progetti open source utilizzano i seguenti strumenti per organizzare la discussione. Leggere gli archivi ti darà una buona idea di come pensa e funziona la comunità.
 
 * **Tracciamento dei problemi:** dove le persone discutono questioni relative al progetto.
-* **Richieste pull:** quando le persone discutono e rivedono le modifiche in corso, sia che si tratti di migliorare l'ordine del codice dei contributori, l'utilizzo della grammatica, l'utilizzo delle immagini, ecc. Alcuni progetti, come [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), utilizzano determinati flussi di azioni GitHub per automatizzare e velocizzare le loro revisioni del codice.
+* **Richieste pull:** quando le persone discutono e rivedono le modifiche in corso, sia che si tratti di migliorare l'ordine del codice dei contributori, l'utilizzo della grammatica, l'utilizzo delle immagini, ecc. Alcuni progetti, come [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), utilizzano determinati flussi di azioni GitHub per automatizzare e velocizzare le loro revisioni del codice.
 * **Forum di discussione o mailing list:** Alcuni progetti possono utilizzare questi canali per argomenti di conversazione (ad esempio _"Come..."_ o _"Cosa ne pensi di..."_ invece di segnalazioni di bug o richieste per le funzioni). Altri utilizzano il tracker dei problemi per tutte le chiamate. Un buon esempio di ciò potrebbe essere la [newsletter settimanale CHAOSS](https://chaoss.community/news/)
 * **Canale di chat sincrono:** alcuni progetti utilizzano canali di chat (come Slack o IRC) per conversazioni informali, collaborazione e scambi rapidi. Un buon esempio di ciò potrebbe essere [EddieHub Discord Community](http://discord.eddiehub.org/).
 
diff --git a/_articles/pcm/how-to-contribute.md b/_articles/pcm/how-to-contribute.md
index 95dcfc18df4..a5d75d92db8 100644
--- a/_articles/pcm/how-to-contribute.md
+++ b/_articles/pcm/how-to-contribute.md
@@ -181,7 +181,7 @@ A project also has documentation. These files are usually listed in the top leve
 Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
 
 * **Issue tracker:** Where people discuss issues related to the project.
-* **Pull requests:** Where people discuss and review changes that are in progress whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), use certain GitHub Action flows to automate and quicken their code reviews.  
+* **Pull requests:** Where people discuss and review changes that are in progress whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), use certain GitHub Action flows to automate and quicken their code reviews.  
 * **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/)
 * **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/).
 

From 2242696e2519e6eb3edd871a5c0d713c4f162e49 Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Fri, 14 Jun 2024 16:02:47 -0700
Subject: [PATCH 698/749] Update changed link for terms of service

---
 _articles/bg/legal.md      | 2 +-
 _articles/de/legal.md      | 2 +-
 _articles/el/legal.md      | 2 +-
 _articles/es/legal.md      | 2 +-
 _articles/fa/legal.md      | 2 +-
 _articles/fr/legal.md      | 2 +-
 _articles/hi/legal.md      | 2 +-
 _articles/hu/legal.md      | 2 +-
 _articles/id/legal.md      | 2 +-
 _articles/it/legal.md      | 2 +-
 _articles/ja/legal.md      | 2 +-
 _articles/ko/legal.md      | 2 +-
 _articles/legal.md         | 2 +-
 _articles/ms/legal.md      | 2 +-
 _articles/nl/legal.md      | 2 +-
 _articles/pcm/legal.md     | 2 +-
 _articles/pt/legal.md      | 2 +-
 _articles/ro/legal.md      | 2 +-
 _articles/ta/legal.md      | 2 +-
 _articles/tr/legal.md      | 2 +-
 _articles/zh-hans/legal.md | 2 +-
 _articles/zh-hant/legal.md | 2 +-
 22 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
index dc0024794da..b85e6b83f71 100644
--- a/_articles/bg/legal.md
+++ b/_articles/bg/legal.md
@@ -32,7 +32,7 @@ related:
 
 ![Създаване на хранилище](/assets/images/legal/repo-create-name.png)
 
-**Да направите своя проект в GitHub публичен не е същото като да лицензирате проекта си.** Публичните проекти са обхванати от [Условията за ползване на GitHub](https://help.github.com/en/github/site-policy/github-Terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), което позволява на другите да преглеждат и разклоняват вашия проект, но иначе работата ви идва без разрешения.
+**Да направите своя проект в GitHub публичен не е същото като да лицензирате проекта си.** Публичните проекти са обхванати от [Условията за ползване на GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), което позволява на другите да преглеждат и разклоняват вашия проект, но иначе работата ви идва без разрешения.
 
 Ако искате други да използват, разпространяват, модифицират или допринасят обратно към вашия проект, трябва да включите лиценз с отворен код. Например, някой не може законно да използва която и да е част от вашия GitHub проект в своя код, дори ако е публичен, освен ако изрично не му дадете правото да го направи.
 
diff --git a/_articles/de/legal.md b/_articles/de/legal.md
index 919e8c8b671..af54098b06d 100644
--- a/_articles/de/legal.md
+++ b/_articles/de/legal.md
@@ -32,7 +32,7 @@ Wenn Sie [ein neues Projekt auf GitHub erstellen](https://help.github.com/articl
 
 ![Ein Repo erstellen](/assets/images/legal/repo-create-name.png)
 
-**Ihr GitHub-Projekt öffentlich zu machen, ist nicht dasselbe, wie eine Lizenz zu vergeben.** Öffentliche Projekte unterliegen [GitHubs Servicebedingungen](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), die Anderen das Ansehen und Forken Ihres Projektes erlauben. Dies bringt allerdings keine weiteren Erlaubnisse für Ihr Werk mit sich.
+**Ihr GitHub-Projekt öffentlich zu machen, ist nicht dasselbe, wie eine Lizenz zu vergeben.** Öffentliche Projekte unterliegen [GitHubs Servicebedingungen](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), die Anderen das Ansehen und Forken Ihres Projektes erlauben. Dies bringt allerdings keine weiteren Erlaubnisse für Ihr Werk mit sich.
 
 Wenn Sie anderen die Nutzung, Verbreitung, Modifikation Ihres Projektes sowie das Beitragen erlauben möchten, müssen Sie eine Open-Source-Lizenz vergeben. Beispielsweise darf legalerweise kein Mensch irgendeinen Teil Ihres GitHub-Projektes in seinen/ihren eigenen Code nutzen (selbst wenn er öffentlich ist), solange Sie nicht das Recht dazu explizit eingeräumt haben.
 
diff --git a/_articles/el/legal.md b/_articles/el/legal.md
index 17a3a23c88a..79c96d97b76 100644
--- a/_articles/el/legal.md
+++ b/_articles/el/legal.md
@@ -32,7 +32,7 @@ related:
 
 ![Δημιουργία αποθετηρίου](/assets/images/legal/repo-create-name.png)
 
-**Η δημοσιοποίηση του έργου σας στο GitHub δεν είναι το ίδιο με την αδειοδότηση του έργου σας.** Τα δημόσια πρότζεκτ καλύπτονται από τους [Όρους χρήσης του GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), οι οποίοι επιτρέπουν σε άλλους να βλέπουν και να διαιρούν το πρότζεκτ σας, αλλά η εργασία σας δεν συνοδεύεται από άλλα δικαιώματα.
+**Η δημοσιοποίηση του έργου σας στο GitHub δεν είναι το ίδιο με την αδειοδότηση του έργου σας.** Τα δημόσια πρότζεκτ καλύπτονται από τους [Όρους χρήσης του GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), οι οποίοι επιτρέπουν σε άλλους να βλέπουν και να διαιρούν το πρότζεκτ σας, αλλά η εργασία σας δεν συνοδεύεται από άλλα δικαιώματα.
 
 Αν θέλετε να χρησιμοποιούν, να διανέμουν, να τροποποιούν ή να συνεισφέρουν άλλοι στο πρότζεκτ σας, πρέπει να συμπεριλάβετε μια άδεια χρήσης ανοικτού κώδικα. Για παράδειγμα, κάποιος δεν μπορεί νομικά να χρησιμοποιήσει οποιοδήποτε μέρος του έργου σας στο GitHub στον κώδικά του, ακόμη και αν είναι δημόσιο, εκτός αν του δώσετε ρητά το δικαίωμα να το κάνει.
 
diff --git a/_articles/es/legal.md b/_articles/es/legal.md
index 3a35a1d90e2..b2dc5d2561e 100644
--- a/_articles/es/legal.md
+++ b/_articles/es/legal.md
@@ -32,7 +32,7 @@ Cuando t&uacute; [creas un nuevo proyecto](https://help.github.com/articles/crea
 
 ![crear repositorio](/assets/images/legal/repo-create-name.png)
 
-**Hacer tu proyecto de GitHub p&uacute;blico, no es lo mismo que licenciar tu proyecto.** Los proyectos p&uacute;blicos son cubiertos por [los T&eacute;rminos de Servicio de GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), lo que les permite a otros ver y bifurcar el proyecto, pero su trabajo viene de otra manera sin permisos.
+**Hacer tu proyecto de GitHub p&uacute;blico, no es lo mismo que licenciar tu proyecto.** Los proyectos p&uacute;blicos son cubiertos por [los T&eacute;rminos de Servicio de GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), lo que les permite a otros ver y bifurcar el proyecto, pero su trabajo viene de otra manera sin permisos.
 
 Si quieres que otros usen, copien, modifiquen, o contribuyan a tu proyecto, debes incluir una licencia de c&oacute;digo abierto. Por ejemplo, nadie puede usar legalmente cualquier parte de tu proyecto de GitHub en su c&oacute;digo, incluso si es p&uacute;blico, a menos que expl&iacute;citamente le concedas dicho derecho.
 
diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index ec3c92d0b54..bf0f3430322 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -30,7 +30,7 @@ related:
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**عمومی کردن پروژه‌تان در «GitHub» به منزلۀ مجوزدار کردن پروژه نیست.** پروژه‌های عمومی‌ای که [تحت شرایط خدمات «GitHub»](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) قرار می‌گیرند این امکان را برای افراد میسر می‌سازد که پروژه شما را مشاهده کنند و آن را فورک (fork) کنند، اما در غیر این افراد همچین اجازه‌ای ندارند.
+**عمومی کردن پروژه‌تان در «GitHub» به منزلۀ مجوزدار کردن پروژه نیست.** پروژه‌های عمومی‌ای که [تحت شرایط خدمات «GitHub»](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) قرار می‌گیرند این امکان را برای افراد میسر می‌سازد که پروژه شما را مشاهده کنند و آن را فورک (fork) کنند، اما در غیر این افراد همچین اجازه‌ای ندارند.
 
 اگر می‌خواهید دیگران از پروژۀ شما استفاده کنند، آن را توزیع دهند یا اصلاح نمایند و در آن مشارکت کنند، باید پروانۀ مخصوص پروژه‌های متن باز داشته باشید. به عنوان مثال، کسی قانونا نمی‌تواند از هر بخشی از پروژۀ «GitHub» شما در کد خود استفاده کند، حتی اگر عمومی باشد؛ مگر اینکه صریحاً به او اجازۀ چنین کاری را بدهید.
 
diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index d1f6684bb81..dd24386ecc5 100644
--- a/_articles/fr/legal.md
+++ b/_articles/fr/legal.md
@@ -32,7 +32,7 @@ Lorsque vous [créez un nouveau projet](https://help.github.com/articles/creatin
 
 ![Créer un référentiel](/assets/images/legal/repo-create-name.png)
 
-**Rendre public votre projet GitHub est différent d'appliquer une licence à votre projet.** Les projets publics sont couverts par les [Conditions d'utilisation de GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ce qui permet aux autres de voir et de forker votre projet, mais par défaut aucune permission ne leur est accordé sur votre travail.
+**Rendre public votre projet GitHub est différent d'appliquer une licence à votre projet.** Les projets publics sont couverts par les [Conditions d'utilisation de GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ce qui permet aux autres de voir et de forker votre projet, mais par défaut aucune permission ne leur est accordé sur votre travail.
 
 Si vous souhaitez que d'autres personnes utilisent, distribuent, modifient ou contribuent à votre projet, vous devez inclure une licence open source. Par exemple, quelqu'un ne peut légalement utiliser aucune partie de votre projet GitHub dans son code, même s'il est public, à moins que vous ne lui donniez explicitement le droit de le faire.
 
diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md
index e2338bbd91a..14ef55872cc 100644
--- a/_articles/hi/legal.md
+++ b/_articles/hi/legal.md
@@ -32,7 +32,7 @@ related:
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**अपने GitHub प्रोजेक्ट को सार्वजनिक बनाना आपके प्रोजेक्ट को लाइसेंस देने के समान नहीं है।** सार्वजनिक परियोजनाएँ इसके अंतर्गत आती हैं [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), जो दूसरों को आपके प्रोजेक्ट को देखने और फोर्क करने की अनुमति देता है, लेकिन अन्यथा आपका काम बिना किसी अनुमति के आता है।
+**अपने GitHub प्रोजेक्ट को सार्वजनिक बनाना आपके प्रोजेक्ट को लाइसेंस देने के समान नहीं है।** सार्वजनिक परियोजनाएँ इसके अंतर्गत आती हैं [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), जो दूसरों को आपके प्रोजेक्ट को देखने और फोर्क करने की अनुमति देता है, लेकिन अन्यथा आपका काम बिना किसी अनुमति के आता है।
 
 यदि आप चाहते हैं कि अन्य लोग आपके प्रोजेक्ट का उपयोग, वितरण, संशोधन या योगदान करें, तो आपको एक ओपन सोर्स लाइसेंस शामिल करना होगा। उदाहरण के लिए, कोई व्यक्ति आपके GitHub प्रोजेक्ट के किसी भी हिस्से को अपने कोड में कानूनी रूप से उपयोग नहीं कर सकता, भले ही वह सार्वजनिक हो, जब तक कि आप स्पष्ट रूप से उन्हें ऐसा करने का अधिकार नहीं देते।
 
diff --git a/_articles/hu/legal.md b/_articles/hu/legal.md
index bac119d5a27..5509a21a1de 100644
--- a/_articles/hu/legal.md
+++ b/_articles/hu/legal.md
@@ -32,7 +32,7 @@ Amikor [létrehozol egy új projektet](https://help.github.com/articles/creating
 
 ![Projekt létrehozása](/assets/images/legal/repo-create-name.png)
 
-**A GitHub projekt nyilvánossága nem azonos a projekt licencével!** A publikus projekt fogalma itt van definiálva: [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ami engedélyezi ezek megtekintését, vagy e célból ennek elágaztatását (fork), de más egyebet nem.
+**A GitHub projekt nyilvánossága nem azonos a projekt licencével!** A publikus projekt fogalma itt van definiálva: [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ami engedélyezi ezek megtekintését, vagy e célból ennek elágaztatását (fork), de más egyebet nem.
 
 Ha azt szeretnéd, hogy mások használhassák, terjesszék, módosítsák vagy hozzájáruljanak a projekthez, meg kell nevezned egy nyílt forráskódú licencet. Például attól, hogy a projekt nyilvános, még senki sem jogosult bármely részének törvényes használatára, kivéve, ha kifejezetten feljogosítod erre a megfelelő licenccel.
 
diff --git a/_articles/id/legal.md b/_articles/id/legal.md
index 55a93340dc6..661be839ea4 100644
--- a/_articles/id/legal.md
+++ b/_articles/id/legal.md
@@ -32,7 +32,7 @@ Ketika Anda [membuat proyek baru](https://help.github.com/articles/creating-a-ne
 
 ![create repository](/assets/images/legal/repo-create-name.png)
 
-**Membuat proyek GitHub Anda sebagai publik tidaklah sama dengan melisensikan proyek Anda.** Proyek publik dibahas pada [Perjanjian Layanan GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), yang mengijinkan orang lain untuk melihat dan melakukan fork terhadap proyek Anda, tetapi jika tidak, maka tidak ada hak akses terhadap proyek Anda.
+**Membuat proyek GitHub Anda sebagai publik tidaklah sama dengan melisensikan proyek Anda.** Proyek publik dibahas pada [Perjanjian Layanan GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), yang mengijinkan orang lain untuk melihat dan melakukan fork terhadap proyek Anda, tetapi jika tidak, maka tidak ada hak akses terhadap proyek Anda.
 
 Jika Anda menginginkan orang lain untuk bisa menggunakan, menyalin, memodifikasi, atau berkontribusi balik pada proyek Anda, Anda perlu menyertakan sebuah lisensi open source. Sebagai contoh, seseorang tidak dapat menggunakan sembarang bagian dari proyek GitHub Anda pada kode mereka secara legal, meskipun bersifat publik, kecuali Anda memberikan ijin kepada mereka.
 
diff --git a/_articles/it/legal.md b/_articles/it/legal.md
index 18ae5091cf3..d8a81af032c 100644
--- a/_articles/it/legal.md
+++ b/_articles/it/legal.md
@@ -32,7 +32,7 @@ Quando [crei nuovo progetto](https://help.github.com/articles/creating-a-new-rep
 
 ![Crea un archivio](/assets/images/legal/repo-create-name.png)
 
-**Rendere pubblico il tuo progetto GitHub non equivale a concedergli una licenza.** I progetti pubblici sono coperti dai [Termini di servizio di GitHub](https://help.github.com/en/github/site-policy/github-Terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), che consente ad altri di rivedere e creare un fork del tuo progetto, ma per il resto il tuo lavoro arriva senza autorizzazioni.
+**Rendere pubblico il tuo progetto GitHub non equivale a concedergli una licenza.** I progetti pubblici sono coperti dai [Termini di servizio di GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), che consente ad altri di rivedere e creare un fork del tuo progetto, ma per il resto il tuo lavoro arriva senza autorizzazioni.
 
 Se desideri che altri utilizzino, distribuiscano, modifichino o contribuiscano al tuo progetto, devi includere una licenza open source. Ad esempio, qualcuno non può utilizzare legalmente alcuna parte del tuo progetto GitHub nel proprio codice, anche se è pubblico, a meno che tu non gli conceda specificatamente il diritto di farlo.
 
diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md
index 3acc4cf2e65..aab80375fd2 100644
--- a/_articles/ja/legal.md
+++ b/_articles/ja/legal.md
@@ -32,7 +32,7 @@ GitHub 上で[新しいプロジェクトを作る](https://help.github.com/arti
 
 ![リポジトリの作成](/assets/images/legal/repo-create-name.png)
 
-**GitHub 上のプロジェクトをパブリックにするということと、プロジェクトにライセンスを設定することは同じではありません。** パブリックプロジェクトは [GitHub の Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) によって保護されます。これによって、他の人があなたのプロジェクトを見たりフォークすることを許可します。しかし、それ以外の点については許可していません。
+**GitHub 上のプロジェクトをパブリックにするということと、プロジェクトにライセンスを設定することは同じではありません。** パブリックプロジェクトは [GitHub の Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) によって保護されます。これによって、他の人があなたのプロジェクトを見たりフォークすることを許可します。しかし、それ以外の点については許可していません。
 
 もし、他に人に対してプロジェクトの利用、配布、変更、コントリビュートをしてもらいたいと思うのであれば、オープンソースライセンスをプロジェクトに含める必要があります。たとえあなたのプロジェクトがパブリックだったとしても、もしあなたがプロジェクトのソースコードを他のプロジェクトで使って良いと明記しない限りは、他の人はそのプロジェクトのコードのどの部分も合法的に使うことができません。
 
diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index de3c53fb3d0..8489e2b9f9a 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -32,7 +32,7 @@ related:
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**GitHub 프로젝트를 공개하는 것은 프로젝트 라이센싱과 동일하지 않습니다.** 공개 프로젝트는 [GitHub의 서비스 약관](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)에 명시되어 있으며, 다른 사람들이 프로젝트를 보거나 포크할 수는 있지만, 다른 권한은 없습니다.
+**GitHub 프로젝트를 공개하는 것은 프로젝트 라이센싱과 동일하지 않습니다.** 공개 프로젝트는 [GitHub의 서비스 약관](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)에 명시되어 있으며, 다른 사람들이 프로젝트를 보거나 포크할 수는 있지만, 다른 권한은 없습니다.
 
 다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게 하려면, 오픈소스 라이선스를 포함해야 합니다. 예를 들어, GitHub 프로젝트가 공개되어 있다 하더라도 명시적으로 권한을 부여하지 않는다면, 그 코드의 어느 부분도 사용할 수 없습니다. 
 
diff --git a/_articles/legal.md b/_articles/legal.md
index 4f71db10270..30d67f11c12 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -32,7 +32,7 @@ When you [create a new project](https://help.github.com/articles/creating-a-new-
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
 
 If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
 
diff --git a/_articles/ms/legal.md b/_articles/ms/legal.md
index 3885ab5f60b..f967a817702 100644
--- a/_articles/ms/legal.md
+++ b/_articles/ms/legal.md
@@ -32,7 +32,7 @@ Bila kamu [create a new project](https://help.github.com/articles/creating-a-new
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**Membuat projek GitHub anda umum tidak sama dengan melesenkan projek anda.** Projek awam dilindungi oleh [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), yang membolehkan orang lain melihat dan melengkapkan projek anda, tetapi pekerjaan anda sebaliknya tidak mempunyai kebenaran.
+**Membuat projek GitHub anda umum tidak sama dengan melesenkan projek anda.** Projek awam dilindungi oleh [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), yang membolehkan orang lain melihat dan melengkapkan projek anda, tetapi pekerjaan anda sebaliknya tidak mempunyai kebenaran.
 
 Sekiranya anda ingin orang lain menggunakan, menyebarkan, mengubah suai, atau menyumbang kembali ke projek anda, anda perlu memasukkan lesen sumber terbuka. Sebagai contoh, seseorang tidak boleh menggunakan bahagian projek GitHub anda secara sah dalam kod mereka, walaupun secara terbuka, melainkan anda secara jelas memberi mereka hak untuk melakukannya.
 
diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
index db8c07a420c..1922507fad3 100644
--- a/_articles/nl/legal.md
+++ b/_articles/nl/legal.md
@@ -32,7 +32,7 @@ Wanneer je [een nieuw project maakt](https://help.github.com/articles/creating-a
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**Het openbaar maken van uw GitHub-project is niet hetzelfde als het licentiëren van uw project.** Openbare projecten vallen onder de [Servicevoorwaarden van GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), waarmee anderen uw project kunnen bekijken en splitsen (_een fork_), maar uw werk heeft verder geen rechten.
+**Het openbaar maken van uw GitHub-project is niet hetzelfde als het licentiëren van uw project.** Openbare projecten vallen onder de [Servicevoorwaarden van GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), waarmee anderen uw project kunnen bekijken en splitsen (_een fork_), maar uw werk heeft verder geen rechten.
 
 Als u wilt dat anderen uw project gebruiken, distribueren, wijzigen of eraan bijdragen, moet u een open source-licentie opnemen. Iemand kan bijvoorbeeld geen enkel deel van je GitHub-project legaal in zijn code gebruiken, zelfs niet als het openbaar is, tenzij je hem expliciet het recht geeft om dit te doen.
 
diff --git a/_articles/pcm/legal.md b/_articles/pcm/legal.md
index e4064022d10..169720b48fb 100644
--- a/_articles/pcm/legal.md
+++ b/_articles/pcm/legal.md
@@ -32,7 +32,7 @@ When you [create a new project](https://help.github.com/articles/creating-a-new-
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
 
 If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
 
diff --git a/_articles/pt/legal.md b/_articles/pt/legal.md
index 83933ba9c30..8feed5246d2 100644
--- a/_articles/pt/legal.md
+++ b/_articles/pt/legal.md
@@ -32,7 +32,7 @@ Quando você [cria um novo projeto](https://help.github.com/articles/creating-a-
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**Tornar seu projeto no GitHub publico não é o mesmo que licenciar seu projeto.** Projetos publicos são cobertos pelos [Termos de Servicos do GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), o que permite que outras pessoas vejam e copiem seu projeto, mas seu trabalho vem sem permissões.
+**Tornar seu projeto no GitHub publico não é o mesmo que licenciar seu projeto.** Projetos publicos são cobertos pelos [Termos de Servicos do GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), o que permite que outras pessoas vejam e copiem seu projeto, mas seu trabalho vem sem permissões.
 
 Se você quiser que outras pessoas usem, distribuam, modifiquem ou contribuam com seu projeto, você precisa incluir uma licença open source. Por exemplo, alguém não pode usar legalmente qualquer parte de seu projeto do GitHub em seu código pessoal, mesmo que seu projeto seja público, a menos que você conceda explicitamente a eles o direito de fazer isso.
 
diff --git a/_articles/ro/legal.md b/_articles/ro/legal.md
index cc8aac227d2..bc152be4c9d 100644
--- a/_articles/ro/legal.md
+++ b/_articles/ro/legal.md
@@ -32,7 +32,7 @@ Când tu [creezi un proiect nou](https://help.github.com/articles/creating-a-new
 
 ![Creează depozit](/assets/images/legal/repo-create-name.png)
 
-**A face proiectul tău GitHub public nu este același lucru cu licențierea proiectului tău.** Proiectele publice sunt acoperite de [Termenii serviciului GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), care permite altora să vadă și să bifurce proiectul tău, dar munca ta în rest vine fără permisiuni.
+**A face proiectul tău GitHub public nu este același lucru cu licențierea proiectului tău.** Proiectele publice sunt acoperite de [Termenii serviciului GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), care permite altora să vadă și să bifurce proiectul tău, dar munca ta în rest vine fără permisiuni.
 
 Dacă dorești ca alții să folosească, să distribuie, să modifice, sau să contribuie înapoi la proiectul tău, tu trebuie să incluzi o licență open source. De exemplu, cineva nu poate în mod legal folosi nicio parte a proiectului tău GitHub în codul lor, chiar dacă este public, decât dacă tu le dai în mod explicit dreptul să facă acest lucru.
 
diff --git a/_articles/ta/legal.md b/_articles/ta/legal.md
index ea5d212b395..9d1dac55fc9 100644
--- a/_articles/ta/legal.md
+++ b/_articles/ta/legal.md
@@ -32,7 +32,7 @@ related:
 
 ![களஞ்சியத்தை உருவாக்கவும்](/assets/images/legal/repo-create-name.png)
 
-**உங்கள் கிட்ஹப் திட்டப்பணியை பொதுவில் வைப்பது என்பது உங்கள் திட்டத்திற்கு உரிமம் அளிப்பதை போல் அல்ல.** பொது திட்டங்கள் [கிட்ஹப் இன் சேவை விதிமுறைகளால்](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) பாதுகாக்கப்படுகின்றது,இது உங்கள் திட்டத்தை மற்றவர்களுக்குக் காண்பிப்பதற்கு மற்றும் கவைய அனுமதிக்கிறது, ஆனால் உங்கள் வேலை அனுமதி இன்றி வருகிறது.
+**உங்கள் கிட்ஹப் திட்டப்பணியை பொதுவில் வைப்பது என்பது உங்கள் திட்டத்திற்கு உரிமம் அளிப்பதை போல் அல்ல.** பொது திட்டங்கள் [கிட்ஹப் இன் சேவை விதிமுறைகளால்](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) பாதுகாக்கப்படுகின்றது,இது உங்கள் திட்டத்தை மற்றவர்களுக்குக் காண்பிப்பதற்கு மற்றும் கவைய அனுமதிக்கிறது, ஆனால் உங்கள் வேலை அனுமதி இன்றி வருகிறது.
 
 மற்றவர்கள் பயன்படுத்த விரும்பினால், விநியோகிக்கவும், மாற்றவும் அல்லது உங்கள் திட்டத்திற்கு பங்களிக்கவும் விரும்பினால், நீங்கள் திறந்த மூல உரிமத்தை சேர்க்க வேண்டும். எடுத்துக்காட்டுக்கு, உங்கள் கிட்ஹப் திட்டத்தின் எந்தவொரு பகுதியையும் அவர்கள் குறியீட்டில் சட்டபூர்வமாகப் பயன்படுத்த முடியாது, பொதுவில் இருந்தாலும், அவற்றை வெளிப்படையாக வழங்குவதற்கு உரிமை இல்லை.
 
diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index b6e7b77122a..cf9aa183e2c 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -32,7 +32,7 @@ GitHub'da [yeni bir proje oluşturduğunuzda](https://help.github.com/articles/c
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**GitHub projenizi herkese açık hale getirmek, projenizi lisanslamakla aynı değildir.** Genel projeler, başkalarının projenizi görüntülemesine ve düzenlemesine izin veren [GitHub'ın Hizmet Koşulları](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) kapsamındadır, gizli yaparsanız işiniz başkalarına izinsizdir.
+**GitHub projenizi herkese açık hale getirmek, projenizi lisanslamakla aynı değildir.** Genel projeler, başkalarının projenizi görüntülemesine ve düzenlemesine izin veren [GitHub'ın Hizmet Koşulları](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) kapsamındadır, gizli yaparsanız işiniz başkalarına izinsizdir.
 
 Başkalarının projenizi kullanmasını, dağıtmasını, değiştirmesini veya katkıda bulunmasını istiyorsanız, açık kaynaklı bir lisans eklemeniz gerekir. Örneğin, birileri, açıkça yapma hakkını vermediğiniz sürece, kamuya açık olsa bile, GitHub projenizin herhangi bir bölümünü yasalarında kullanamaz.
 
diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index 763d1149944..b462df4e621 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -33,7 +33,7 @@ redirect_from: /zh-cn/legal/
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**公开你们的GitHub项目与许可你们的项目是不同的。**公开项目是由[GitHub的服务条款](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)保护，它允许他人浏览以及fork你们的项目，但是没有你的授权大家是不能使用你的工作成果的。
+**公开你们的GitHub项目与许可你们的项目是不同的。**公开项目是由[GitHub的服务条款](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)保护，它允许他人浏览以及fork你们的项目，但是没有你的授权大家是不能使用你的工作成果的。
 
 如果你们想让他人使用、复制、修改你们的项目，或者参与贡献你们的项目，那么你们的项目就需要包含一个开源许可协议。例如，即使你的GitHub项目是公开的，除非你明确授权，否则他人在法律上无权将你项目中的任何内容用于自己的代码之中。
 
diff --git a/_articles/zh-hant/legal.md b/_articles/zh-hant/legal.md
index cd40cf324b8..26d49af4d06 100644
--- a/_articles/zh-hant/legal.md
+++ b/_articles/zh-hant/legal.md
@@ -33,7 +33,7 @@ redirect_from: /zh-tw/legal/
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**讓你們的GitHub專案公開與許可你們的專案是不同的。**公開專案是由[GitHub的服務條款](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)保護，它允許他人瀏覽以及fork你們的專案，但是沒有權限參與你們的工作。
+**讓你們的GitHub專案公開與許可你們的專案是不同的。**公開專案是由[GitHub的服務條款](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)保護，它允許他人瀏覽以及fork你們的專案，但是沒有權限參與你們的工作。
 
 如果你們想讓他人使用，複製，修改你們的專案，或者參與貢獻你們的專案，那麼你們的專案就需要包含一個開源許可協議。例如，即使你們的專案是公開的，但沒有你們的授權，一些人是不能合法在他們的程式碼中使用你們GitHub專案中的任何部分。
 

From b1b393a7cbeeb75d47e0a63923c4fb7c59e8c40f Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Fri, 14 Jun 2024 16:11:56 -0700
Subject: [PATCH 699/749] Repo was renamed and the issue number lost; linking
 instead to the website

---
 _articles/bg/how-to-contribute.md      | 2 +-
 _articles/de/how-to-contribute.md      | 2 +-
 _articles/el/how-to-contribute.md      | 2 +-
 _articles/fa/how-to-contribute.md      | 2 +-
 _articles/fr/how-to-contribute.md      | 2 +-
 _articles/how-to-contribute.md         | 2 +-
 _articles/hu/how-to-contribute.md      | 2 +-
 _articles/it/how-to-contribute.md      | 2 +-
 _articles/ja/how-to-contribute.md      | 2 +-
 _articles/ko/how-to-contribute.md      | 2 +-
 _articles/ms/how-to-contribute.md      | 2 +-
 _articles/nl/how-to-contribute.md      | 2 +-
 _articles/pcm/how-to-contribute.md     | 2 +-
 _articles/pl/how-to-contribute.md      | 2 +-
 _articles/pt/how-to-contribute.md      | 2 +-
 _articles/ro/how-to-contribute.md      | 2 +-
 _articles/ru/how-to-contribute.md      | 2 +-
 _articles/ta/how-to-contribute.md      | 2 +-
 _articles/tr/how-to-contribute.md      | 2 +-
 _articles/zh-hant/how-to-contribute.md | 2 +-
 20 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/_articles/bg/how-to-contribute.md b/_articles/bg/how-to-contribute.md
index 4cce7d2aee3..391fb43c374 100644
--- a/_articles/bg/how-to-contribute.md
+++ b/_articles/bg/how-to-contribute.md
@@ -90,7 +90,7 @@ related:
 * Напишете и подобрете документацията на проекта, [както @CBID2 направи за документацията на OpenSauced](https://github.com/open-sauced/docs/pull/151)
 * Подгответе папка с примери, показващи как се използва проектът
 * Стартирайте бюлетин за проекта или подредете акценти от пощенския списък, [както направи @opensauced за своя продукт](https://news.opensauced.pizza/about/)
-* Напишете уроци за проекта, [както направиха сътрудниците на PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Напишете уроци за проекта, [както направиха сътрудниците на PyPA](https://packaging.python.org/)
 * Напишете превод за документацията на проекта, [както @frontendwizard направи за инструкциите за CSS Flexbox предизвикателството на freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/de/how-to-contribute.md b/_articles/de/how-to-contribute.md
index 6dc1ed10d40..fc1669644f6 100644
--- a/_articles/de/how-to-contribute.md
+++ b/_articles/de/how-to-contribute.md
@@ -98,7 +98,7 @@ Auch wenn Sie gerne Code schreiben, gibt es vielleicht bessere Möglichkeiten, s
 * Erstellen und verbessern Sie die Projektdokumentation
 * Erstellen Sie eine Übersicht von Anwendungsbeispielen, welche die Verwendungsmöglichkeiten der Software zeigen
 * Starten Sie einen Newsletter für das Projekt oder kuratieren Sie Highlights aus der Mailingliste
-* Schreiben Sie Tutorials für das Projekt, so [wie die Mitwirkenden von PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Schreiben Sie Tutorials für das Projekt, so [wie die Mitwirkenden von PyPA](https://packaging.python.org/)
 * Übersetzen Sie die Projektdokumentation
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/el/how-to-contribute.md b/_articles/el/how-to-contribute.md
index e82a9d922c0..821a118f2a1 100644
--- a/_articles/el/how-to-contribute.md
+++ b/_articles/el/how-to-contribute.md
@@ -88,7 +88,7 @@ related:
 * Γράφετε και βελτιώνετε την τεκμηρίωση του έργου
 * Επιμεληθείτε έναν φάκελο με παραδείγματα που δείχνουν πώς χρησιμοποιείται το έργο
 * Ξεκινήστε ένα ενημερωτικό δελτίο για το έργο, ή επιμεληθείτε τα σημαντικότερα σημεία από τη λίστα αλληλογραφίας
-* Γράφετε εκπαιδευτικά προγράμματα για το έργο, [όπως έκαναν οι συντελεστές του PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Γράφετε εκπαιδευτικά προγράμματα για το έργο, [όπως έκαναν οι συντελεστές του PyPA](https://packaging.python.org/)
 * Γράψτε μια μετάφραση για την τεκμηρίωση του έργου
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index d78fbdb7c8b..6c94427f2cc 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -90,7 +90,7 @@ related:
 * اسناد پروژه را بنویسید و اصلاح کنید
 * پوشه‌ی نمونه‌ها را تنظیم کنید تا نحوه‌ی استفاده‌ی پروژه را نشان دهد
 * برای پروژه یک خبرنامه راه‌اندازی کنید، یا شاخصه‌های آن را نوشته و تنظیم کنید
-* برای پروژه، مطالب آموزشی بنویسید، مانند مشارکت‌کننده‌هایی که برای [PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194) مطالب آموزشی نوشتند
+* برای پروژه، مطالب آموزشی بنویسید، مانند مشارکت‌کننده‌هایی که برای [PyPA](https://packaging.python.org/) مطالب آموزشی نوشتند
 * مستندات پروژه را به زبانی دیگر ترجمه کنید
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md
index 2920403445c..91efe84f0f6 100644
--- a/_articles/fr/how-to-contribute.md
+++ b/_articles/fr/how-to-contribute.md
@@ -86,7 +86,7 @@ Même si vous aimez écrire du code, d'autres types de contributions sont un exc
 * Écrire et améliorer la documentation du projet
 * Curate un dossier d'exemples montrant comment le projet est utilisé
 * Démarrer un bulletin d'information pour le projet, ou organiser des faits marquants de la liste de diffusion
-* Rédiger des tutoriels pour le projet, [comme les contributeurs de PyPA l'ont fait](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Rédiger des tutoriels pour le projet, [comme les contributeurs de PyPA l'ont fait](https://packaging.python.org/)
 * Écrire une traduction pour la documentation du projet
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 42877c233ee..278cf71e35a 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -90,7 +90,7 @@ Even if you like to write code, other types of contributions are a great way to
 * Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
 * Curate a folder of examples showing how the project is used
 * Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/)
-* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Write tutorials for the project, [like PyPA's contributors did](https://packaging.python.org/)
 * Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/hu/how-to-contribute.md b/_articles/hu/how-to-contribute.md
index 0b8e185cef2..5ca3d2f5f05 100644
--- a/_articles/hu/how-to-contribute.md
+++ b/_articles/hu/how-to-contribute.md
@@ -86,7 +86,7 @@ Még ha szeretsz is programozni, akkor is nagyszerű módja a projektben való r
 * Írd és javítsd a projekt dokumentációját
 * Tarts karban egy példa könyvtárat a projekt használatáról
 * Indíts hírlevelet a projektről, vagy a levelező listáról készít összefoglalót
-* Írj útmutatókat a projektről, [ahogy PyPA fejlesztői tették](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Írj útmutatókat a projektről, [ahogy PyPA fejlesztői tették](https://packaging.python.org/)
 * Fordíts le a projekt dokumentációját
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/it/how-to-contribute.md b/_articles/it/how-to-contribute.md
index 66c3084b058..150bbfe9d0b 100644
--- a/_articles/it/how-to-contribute.md
+++ b/_articles/it/how-to-contribute.md
@@ -90,7 +90,7 @@ Anche se ti piace scrivere codice, altri tipi di contributi sono un ottimo modo
 * Scrivi e migliora la documentazione del progetto, [come ha fatto @CBID2 per la documentazione di OpenSauced](https://github.com/open-sauced/docs/pull/151)
 * Preparare una cartella di esempi che mostrano come viene utilizzato il progetto
 * Avvia una newsletter del progetto o cura i punti salienti della mailing list, [come ha fatto @opensauced per il suo prodotto](https://news.opensauced.pizza/about/)
-* Scrivi tutorial per il progetto, [come hanno fatto i contributori PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Scrivi tutorial per il progetto, [come hanno fatto i contributori PyPA](https://packaging.python.org/)
 * Scrivi una traduzione per la documentazione del progetto, [come ha fatto @frontendwizard per le istruzioni CSS Flexbox della sfida freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md
index 1dc22d13966..11f99b72484 100644
--- a/_articles/ja/how-to-contribute.md
+++ b/_articles/ja/how-to-contribute.md
@@ -86,7 +86,7 @@ related:
 * プロジェクトのドキュメントを書いたり改善する
 * プロジェクトがどのように使われているかの事例を選別する
 * プロジェクトのニュースレターを始めたり、メーリングリストのハイライトを整理する
-* [PyPA のコントリビューターがやったように](https://github.com/pypa/python-packaging-user-guide/issues/194)、プロジェクトのチュートリアルを書く
+* [PyPA のコントリビューターがやったように](https://packaging.python.org/)、プロジェクトのチュートリアルを書く
 * プロジェクトのドキュメントを翻訳する
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md
index d775b1dbb66..6b407016da2 100644
--- a/_articles/ko/how-to-contribute.md
+++ b/_articles/ko/how-to-contribute.md
@@ -86,7 +86,7 @@ related:
 * 프로젝트 문서 작성 및 개선하기
 * 프로젝트 사용법을 보여주는 예제 폴더 선별하기
 * 프로젝트의 뉴스레터 발행을 시작하거나 메일링 리스트의 하이라이트를 관리하기
-* [PyPA의 기여처럼](https://github.com/pypa/python-packaging-user-guide/issues/194), 프로젝트 튜토리얼 작성하기
+* [PyPA의 기여처럼](https://packaging.python.org/), 프로젝트 튜토리얼 작성하기
 * 프로젝트 문서 번역 작성하기
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
index 285de934529..1c7baa6a543 100644
--- a/_articles/ms/how-to-contribute.md
+++ b/_articles/ms/how-to-contribute.md
@@ -90,7 +90,7 @@ Walaupun anda suka menulis kod, jenis sumbangan lain adalah kaedah terbaik untuk
 * Tulis dan perbaiki dokumentasi projek
 * Buat folder contoh yang menunjukkan bagaimana projek itu digunakan
 * Mulakan buletin untuk projek ini, atau pilih sorotan dari senarai surat
-* Tulis tutorial untuk projek itu,[like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Tulis tutorial untuk projek itu,[like PyPA's contributors did](https://packaging.python.org/)
 * Tulis terjemahan untuk dokumentasi projek
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md
index cc07950d858..75dd39dc03c 100644
--- a/_articles/nl/how-to-contribute.md
+++ b/_articles/nl/how-to-contribute.md
@@ -95,7 +95,7 @@ Zelfs als je graag code schrijft, zijn andere soorten bijdragen een geweldige ma
 * Schrijf en verbeter de projectdocumentatie
 * Beheer een map met voorbeelden die laten zien hoe het project wordt gebruikt
 * Start een nieuwsbrief voor het project of cureer hoogtepunten uit de mailinglijst
-* Schrijf tutorials voor het project, [zoals de bijdragers van PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Schrijf tutorials voor het project, [zoals de bijdragers van PyPA](https://packaging.python.org/)
 * Schrijf een vertaling voor de documentatie van het project
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/pcm/how-to-contribute.md b/_articles/pcm/how-to-contribute.md
index a5d75d92db8..a44f4d53d1d 100644
--- a/_articles/pcm/how-to-contribute.md
+++ b/_articles/pcm/how-to-contribute.md
@@ -90,7 +90,7 @@ Even if you like to write code, other types of contributions are a great way to
 * Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
 * Curate a folder of examples showing how the project is used
 * Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/)
-* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Write tutorials for the project, [like PyPA's contributors did](https://packaging.python.org/)
 * Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index fd9c07fb69c..8b88446baa9 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -94,7 +94,7 @@ Nawet jeśli lubisz pisać kod, inne rodzaje wkładów to świetny sposób na za
 * Napisz i popraw dokumentację projektu
 * Wybierz folder z przykładami pokazującymi, w jaki sposób projekt jest używany
 * Rozpocznij biuletyn dotyczący projektu lub wybieraj najważniejsze informacje z listy mailingowej
-* Napisz tutoriale do projektu [jak zrobili to autorzy PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Napisz tutoriale do projektu [jak zrobili to autorzy PyPA](https://packaging.python.org/)
 * Napisz tłumaczenie dokumentacji projektu
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md
index efad946eb21..cf301825273 100644
--- a/_articles/pt/how-to-contribute.md
+++ b/_articles/pt/how-to-contribute.md
@@ -86,7 +86,7 @@ Mesmo se você gosta de escrever código, outros tipos de contribuições são u
 * Escreva e melhore a documentação do projeto
 * Organize uma pasta de exemplos mostrando como o projeto é usado
 * Inicie uma newsletter para o projeto ou selecione resumos da lista de discussão
-* Escreva tutoriais para o projeto, [como os contribuidores do PyPA fizeram](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Escreva tutoriais para o projeto, [como os contribuidores do PyPA fizeram](https://packaging.python.org/)
 * Escreva uma tradução para a documentação do projeto
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/ro/how-to-contribute.md b/_articles/ro/how-to-contribute.md
index 3c2fcb95ebf..232e425d4ad 100644
--- a/_articles/ro/how-to-contribute.md
+++ b/_articles/ro/how-to-contribute.md
@@ -100,7 +100,7 @@ Chiar dacă îți place să scrii cod, alte tipuri de contribuții sunt o cale g
 * Scrie și îmbunătățește documentația proiectului
 * Selectează un dosar de exemple arătând cum este folosit proiectul
 * Începe un buletin informativ pentru proiect, sau selectează sublinieri din lista de email-uri
-* Scrie tutoriale pentru proiect, [cum au făcut contribuitorii PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Scrie tutoriale pentru proiect, [cum au făcut contribuitorii PyPA](https://packaging.python.org/)
 * Scrie o traducere pentru documentația proiectului
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index 581fb52138d..f06ea729330 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -90,7 +90,7 @@ related:
 * Напишите и улучшите документацию по проекту
 * Создайте папку с примерами по использованию проекта
 * Запустите рассылку новостей по проекту или освещайте самое важное из списка рассылки
-* Составьте обучающие руководства по проекту, [как это сделали участники PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Составьте обучающие руководства по проекту, [как это сделали участники PyPA](https://packaging.python.org/)
 * Переведите документацию проекта
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/ta/how-to-contribute.md b/_articles/ta/how-to-contribute.md
index 38afc0e72ea..193a4102653 100644
--- a/_articles/ta/how-to-contribute.md
+++ b/_articles/ta/how-to-contribute.md
@@ -86,7 +86,7 @@ related:
 * திட்டத்தின் ஆவணங்களை எழுதுவது மற்றும் மேம்படுத்துவது
 * திட்டம் எவ்வாறு பயன்படுத்தப்படுகிறது என்பதை காட்டும் உதாரணங்கள் ஒரு கோப்புறையை தொகுத்தல்
 * திட்டத்திற்கான ஒரு செய்திமடலைத் தொடங்கவும் அல்லது அஞ்சல் பட்டியலிலிருந்த சிறப்பம்சங்களைக் தொகுக்கவும்
-* திட்டத்திற்கான பயிற்சியை எழுதுங்கள், [PyPA's பங்களிப்பாளர்கள் செய்ததைப்போல](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* திட்டத்திற்கான பயிற்சியை எழுதுங்கள், [PyPA's பங்களிப்பாளர்கள் செய்ததைப்போல](https://packaging.python.org/)
 * திட்டத்தின் ஆவணங்களுக்கான ஒரு மொழிபெயர்ப்பை எழுதுங்கள்
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md
index 189f26e183e..c6fc1f3f498 100644
--- a/_articles/tr/how-to-contribute.md
+++ b/_articles/tr/how-to-contribute.md
@@ -90,7 +90,7 @@ Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve d
 * Proje dokümantasyonunu yazın ve geliştirin
 * Projenin nasıl kullanıldığını gösteren örnekler oluşturun
 * Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın
-* [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın
+* [PyPA'nın katılımcılarının yaptığı gibi](https://packaging.python.org/) proje için dersler yazın
 * Projenin dokümantasyonu için çeviri yapın
 
 <aside markdown="1" class="pquote">
diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md
index a74d706c7a3..f47749bc226 100644
--- a/_articles/zh-hant/how-to-contribute.md
+++ b/_articles/zh-hant/how-to-contribute.md
@@ -87,7 +87,7 @@ redirect_from: /zh-tw/how-to-contribute/
 * 撰寫和改善專案的說明文件
 * 策劃一個資料夾來蒐集專案的實際應用案例
 * 辦一個專案的電子報，或者蒐整郵件列表的摘要
-* 寫一個專案教學，就像 [PyPA 的貢獻者做的](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* 寫一個專案教學，就像 [PyPA 的貢獻者做的](https://packaging.python.org/)
 * 翻譯專案的說明文件
 
 <aside markdown="1" class="pquote">

From f92b072b41851878ecfd99c76cccf9259433b336 Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Fri, 14 Jun 2024 16:15:17 -0700
Subject: [PATCH 700/749] Fix typo in link to @sindresorhus/awesome

---
 _articles/hi/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md
index 51de09007b2..2d8d7da3c71 100644
--- a/_articles/hi/how-to-contribute.md
+++ b/_articles/hi/how-to-contribute.md
@@ -132,7 +132,7 @@ related:
 
 उदाहरण के लिए:
 
-* @sindresorhas एक ["भयानक" सूचियों की सूची तैयार करता है](https://github.com/sindresorhas/awesome)
+* @sindresorhus एक ["भयानक" सूचियों की सूची तैयार करता है](https://github.com/sindresorhus/awesome)
 * @h5bp फ्रंट-एंड डेवलपर उम्मीदवारों के लिए [संभावित साक्षात्कार प्रश्नों की सूची] (https://github.com/h5bp/Front-end-Developer-Interview-Questions) रखता है
 * @stuartlynn और @nicole-a-tesla ने [पफिन्स के बारे में मजेदार तथ्यों का संग्रह](https://github.com/stuartlynn/puffin_facts) बनाया।
 

From eea2f4b954cbf8212ccc9840acdda88da637e293 Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Fri, 14 Jun 2024 16:16:58 -0700
Subject: [PATCH 701/749] Translated filename crept in: CONTRIBUIRE.md should
 be CONTRIBUTING.md

---
 _articles/it/leadership-and-governance.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/it/leadership-and-governance.md b/_articles/it/leadership-and-governance.md
index 896018a83eb..950233f0140 100644
--- a/_articles/it/leadership-and-governance.md
+++ b/_articles/it/leadership-and-governance.md
@@ -67,7 +67,7 @@ Se il tuo progetto ha una comunità di contributori molto attiva, puoi formare u
   </p>
 </aside>
 
-I team dirigenti potrebbero voler creare un canale designato (come su IRC) o incontrarsi regolarmente per discutere del progetto (come su Gitter o Google Hangout). Puoi anche rendere pubbliche queste riunioni in modo che altre persone possano ascoltarle. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), ad esempio, [prende ore di lavoro ogni settimana](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUIRE.md#talking-with-other-devs).
+I team dirigenti potrebbero voler creare un canale designato (come su IRC) o incontrarsi regolarmente per discutere del progetto (come su Gitter o Google Hangout). Puoi anche rendere pubbliche queste riunioni in modo che altre persone possano ascoltarle. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), ad esempio, [prende ore di lavoro ogni settimana](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
 
 Una volta stabiliti i ruoli di leadership, assicurati di documentare come le persone possono raggiungerli! Stabilisci un processo chiaro su come qualcuno può diventare un sostenitore o unirsi a un sottocomitato nel tuo progetto e scrivilo nel tuo GOVERNANCE.md.
 

From 3b2a208e01ddb8a42be3d35e4181a74cdef886dd Mon Sep 17 00:00:00 2001
From: Eric Sorenson <ahpook@github.com>
Date: Fri, 14 Jun 2024 16:37:31 -0700
Subject: [PATCH 702/749] Fixup stray stale link - previous regex didn't catch
 this one

---
 _articles/hi/how-to-contribute.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md
index 2d8d7da3c71..4508ac05fb2 100644
--- a/_articles/hi/how-to-contribute.md
+++ b/_articles/hi/how-to-contribute.md
@@ -90,7 +90,7 @@ related:
 * प्रोजेक्ट के दस्तावेज़ीकरण को लिखें और सुधारें
 * प्रोजेक्ट का उपयोग कैसे किया जाता है, यह दर्शाने वाले उदाहरणों का एक फ़ोल्डर बनाएं
 * प्रोजेक्ट के लिए एक न्यूज़लेटर शुरू करें, या मेलिंग सूची से हाइलाइट्स क्यूरेट करें
-* प्रोजेक्ट के लिए ट्यूटोरियल लिखें, [जैसे PyPA के योगदानकर्ताओं ने किया](https://github.com/pypa/python-package-user-guide/issues/194)
+* प्रोजेक्ट के लिए ट्यूटोरियल लिखें, [जैसे PyPA के योगदानकर्ताओं ने किया](https://packaging.python.org/)
 * परियोजना के दस्तावेज़ीकरण के लिए एक अनुवाद लिखें
 
 <aside markdown="1" class="pquote">

From 0e8f552fff3aa99a9e0844f09170a3181c5f9606 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 18 Jun 2024 04:39:28 +0000
Subject: [PATCH 703/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.180.0 to 1.180.1
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Commits](https://github.com/ruby/setup-ruby/compare/ff740bc00a01b3a50fffc55a1071b1060eeae9dc...3783f195e29b74ae398d7caca108814bbafde90e)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index edfa656136b..2086eedf331 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@ff740bc00a01b3a50fffc55a1071b1060eeae9dc # v1
+        uses: ruby/setup-ruby@3783f195e29b74ae398d7caca108814bbafde90e # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 6bbbc52757cacc566deda0fb56be7985b4fc3bf3 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 28 Jun 2024 04:17:22 +0000
Subject: [PATCH 704/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.180.1 to 1.182.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/3783f195e29b74ae398d7caca108814bbafde90e...af43264f2b94cc8451805dc51af7408f01de6471)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 2086eedf331..351cce6ca1b 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@3783f195e29b74ae398d7caca108814bbafde90e # v1
+        uses: ruby/setup-ruby@af43264f2b94cc8451805dc51af7408f01de6471 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 4d90dbcbc699d8bae4ad9bd76e21fecf5438a83a Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 1 Jul 2024 04:33:19 +0000
Subject: [PATCH 705/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.182.0 to 1.183.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/af43264f2b94cc8451805dc51af7408f01de6471...1d0e911f615a112e322369596f10ee0b95b010ae)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 351cce6ca1b..a1d21173736 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@af43264f2b94cc8451805dc51af7408f01de6471 # v1
+        uses: ruby/setup-ruby@1d0e911f615a112e322369596f10ee0b95b010ae # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 980dd0d3cde1205f276193b0bb7b4a7573bcf5e5 Mon Sep 17 00:00:00 2001
From: Janghyeon <hwahyeon@knou.ac.kr>
Date: Wed, 3 Jul 2024 21:21:41 +0200
Subject: [PATCH 706/749] fix: Correct typos and spacing in Korean
 documentation

---
 _articles/ko/metrics.md | 48 ++++++++++++++++++++---------------------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/_articles/ko/metrics.md b/_articles/ko/metrics.md
index ab5d16f187d..e32172b03f9 100644
--- a/_articles/ko/metrics.md
+++ b/_articles/ko/metrics.md
@@ -14,7 +14,7 @@ related:
 
 데이터를 현명하게 사용하면, 오픈소스 메인테이너로서 더 나은 의사 결정을 내릴 수 있습니다.
 
-자세한 정보를 통해 다음을 수행 할 수 있습니다:
+자세한 정보를 통해 다음을 수행할 수 있습니다:
 
 * 사용자가 새로운 기능에 어떻게 반응하는지 이해하기
 * 새로운 사용자가 어디서 왔는지 파악하기
@@ -23,9 +23,9 @@ related:
 * 프로젝트 사용 방법 이해하기
 * 스폰서십과 보조금을 통해 돈을 모으기
 
-예시로, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md)는 Google 웹 로그 분석으로 우선 순위를 결정하는 데 도움이 되는 것으로 나타났습니다:
+예시로, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md)는 Google 웹 로그 분석으로 우선순위를 결정하는 데 도움이 되는 것으로 나타났습니다:
 
-> Homebrew는 무료로 제공되며, 여가 시간에 자원 봉사자들에 의해 전적으로 운영됩니다. 결과적으로, 우리는 미래의 기능을 설계하고 현재 작업의 우선 순위를 정하는 최선의 방법을 결정하기 위해 Homebrew 사용자에 대한 상세한 사용자 연구를 할 수 있는 자원이 없습니다. 익명 집계 사용자 분석을 사용하면 사람들이 Homebrew를 사용하는 방법, 장소 및 시기에 따라 수정 및 기능의 우선 순위를 지정할 수 있습니다.
+> Homebrew는 무료로 제공되며, 여가 시간에 자원 봉사자들에 의해 전적으로 운영됩니다. 결과적으로, 우리는 미래의 기능을 설계하고 현재 작업의 우선순위를 정하는 최선의 방법을 결정하기 위해 Homebrew 사용자에 대한 상세한 사용자 연구를 할 수 있는 자원이 없습니다. 익명 집계 사용자 분석을 사용하면 사람들이 Homebrew를 사용하는 방법, 장소 및 시기에 따라 수정 및 기능의 우선순위를 지정할 수 있습니다.
 
 인기가 모든 것이 아닙니다. 누구나 다른 이유로 오픈소스를 사용합니다. 오픈소스 메인테이너로서의 목표가 업무를 과시하거나, 코드에 대해 투명하게 표현하거나, 재미있게 만나는 것이라면, 측정이 중요하지 않을 수도 있습니다.
 
@@ -33,7 +33,7 @@ If you _are_ interested in understanding your project on a deeper level, read on
 
 ## 발견
 
-누구든지 프로젝트를 사용하거나 기여할 수 있게 하기전에, 이것이 존재 하는 지를 알아야합니다. 자신에게 물어보십시오: _이 프로젝트를 찾는 사람들입니까?_
+누구든지 프로젝트를 사용하거나 기여할 수 있게 하기 전에, 이것이 존재하는 지를 알아야 합니다. 자신에게 물어보십시오: _이 프로젝트를 찾는 사람들입니까?_
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
@@ -43,56 +43,56 @@ 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://help.github.com/articles/about-stars/)는 또한 인기의 기준치 측정을 제공하는 데 도움이 될 수 있습니다. GitHub star는 반드시 다운로드 및 사용량과 상관관계가 있는 것은 아니지만, 얼마나 많은 사람들이 귀하의 작업에 주의를 기울이고 있는지 말해 줄 수 있습니다.
 
-[특정 장소에서 검색 가능성을 추적](https://opensource.com/business/16/6/pirate-metrics) 할 수도 있습니다: 예를 들어, Google 페이지랭크, 프로젝트 웹 사이트의 추천 트래픽 또는 다른 오픈소스 프로젝트 또는 웹 사이트의 추천을 포함 할 수 있습니다.
+[특정 장소에서 검색 가능성을 추적](https://opensource.com/business/16/6/pirate-metrics) 할 수도 있습니다: 예를 들어, Google 페이지랭크, 프로젝트 웹 사이트의 추천 트래픽 또는 다른 오픈소스 프로젝트 또는 웹 사이트의 추천을 포함할 수 있습니다.
 
 ## 사용
 
-사람들은 우리가 인터넷이라고 부르는 이 거칠고 미친 일로 프로젝트를 찾고 있습니다. 이상적으로는, 프로젝트를 보았을 때 뭔가 할 것을 강요 당할 것입니다. 두 번째 질문은 다음과 같습니다: _이 프로젝트를 사용하는 사람들입니까?_
+사람들은 우리가 인터넷이라고 부르는 이 거칠고 미친 일로 프로젝트를 찾고 있습니다. 이상적으로는, 프로젝트를 보았을 때 뭔가 할 것을 강요당할 것입니다. 두 번째 질문은 다음과 같습니다: _이 프로젝트를 사용하는 사람들입니까?_
 
 npm 또는 RubyGems.org와 같은 패키지 관리자를 사용하여 프로젝트를 배포하는 경우 프로젝트 다운로드를 추적할 수 있습니다.
 
-각 패키지 매니저는 "다운로드"와 약간 다른 정의를 사용할 수 있으며, 다운로드가 반드시 설치 또는 사용과 관련이 있는 것은 아니지만 비교를 위한 기준을 제공합니다. [Libraries.io](https://libraries.io/)를 사용해 많은 인기있는 패키지 매니저의 사용 통계를 추적 해보십시오.
+각 패키지 매니저는 "다운로드"와 약간 다른 정의를 사용할 수 있으며, 다운로드가 반드시 설치 또는 사용과 관련이 있는 것은 아니지만 비교를 위한 기준을 제공합니다. [Libraries.io](https://libraries.io/)를 사용해 많은 인기 있는 패키지 매니저의 사용 통계를 추적해보십시오.
 
-만약 프로젝트가 깃허브에 있다면, "Traffic"페이지로 사디 이동하보십시오. [clone graph](https://github.com/blog/1873-clone-graphs)를 사용하여 주어진 날에 프로젝트가 복제 된 횟수를 전체 클론 및 클론 받은 사람으로 세분화 할 수 있습니다.
+만약 프로젝트가 깃허브에 있다면, "Traffic"페이지로 다시 이동해 보십시오. [clone graph](https://github.com/blog/1873-clone-graphs)를 사용하여 주어진 날에 프로젝트가 복제된 횟수를 전체 클론 및 클론 받은 사람으로 세분화할 수 있습니다.
 
 ![Clone graph](/assets/images/metrics/clone_graph.png)
 
-프로젝트를 발견한 사람의 수에 비해 사용량이 적을 경우, 고려해야 할 두 가지 문제가 있습니다. 어느 한 쪽으로는:
+프로젝트를 발견한 사람의 수에 비해 사용량이 적을 경우, 고려해야 할 두 가지 문제가 있습니다. 어느 한쪽으로는:
 
 * 프로젝트가 잠재 고객을 성공적으로 전환하지 못했거나, 또는
 * 틀린 지지자를 끌어들이고 있습니다.
 
-예를 들어, 프로젝트가 Hacker News의 첫 페이지에있는 경우, Hacker News의 모든 사용자에게 도달했기 때문에 발견(트래픽)은 증가하지만 전환율은 낮아질 수 있습니다. 그러나 Ruby 프로젝트가 Ruby 컨퍼런스에 등장한다면 타겟 잠재 고객의 전환율이 높아질 가능성이 큽니다.
+예를 들어, 프로젝트가 Hacker News의 첫 페이지에 있는 경우, Hacker News의 모든 사용자에게 도달했기 때문에 발견(트래픽)은 증가하지만 전환율은 낮아질 수 있습니다. 그러나 Ruby 프로젝트가 Ruby 컨퍼런스에 등장한다면 타겟 잠재 고객의 전환율이 높아질 가능성이 큽니다.
 
-잠재 고객이 어디에서 왔는지 파악하고 프로젝트 페이지에서 다른 사람들에게 당신이 직면한 두가지 문제점을 파악하도록 요청하십시오.
+잠재 고객이 어디에서 왔는지 파악하고 프로젝트 페이지에서 다른 사람들에게 당신이 직면한 두 가지 문제점을 파악하도록 요청하십시오.
 
-사람들이 프로젝트를 사용하고 있다는 것을 알게되면, 사람들이 프로젝트를 통해 무엇을 하고 있는지 파악하려고 할 수 있습니다. 그들은 당신의 코드를 포크하고 기능을 추가함으로써 그것을 구축하고 있습니까? 그들은 과학이나 비즈니스를 위해 그것을 사용하고 있습니까?
+사람들이 프로젝트를 사용하고 있다는 것을 알게 되면, 사람들이 프로젝트를 통해 무엇을 하고 있는지 파악하려고 할 수 있습니다. 그들은 당신의 코드를 포크하고 기능을 추가함으로써 그것을 구축하고 있습니까? 그들은 과학이나 비즈니스를 위해 그것을 사용하고 있습니까?
 
 ## 유지
 
 사람들이 프로젝트를 찾고 있으며 프로젝트를 사용하고 있습니다. 다음 질문은 스스로에게 물어볼 것입니다: _이 프로젝트에 다시 기여한 사람들입니까?_
 
-기여자를 생각하는 것은 너무 이릅니다.다른 사람이 참여하지 않으면 프로젝트가 _인기있고_(많은 사람들이 그것을 사용하지만) _지원_되지 않는(요구 사항을 충족시키는 데 필요한 유지 보수 시간이 충분하지 않음) 좋지 못한 상황에 처할 위험이 있습니다.
+기여자를 생각하는 것은 너무 이릅니다. 다른 사람이 참여하지 않으면 프로젝트가 _인기 있고_(많은 사람들이 그것을 사용하지만) _지원_되지 않는(요구 사항을 충족시키는 데 필요한 유지 보수 시간이 충분하지 않음) 좋지 못한 상황에 처할 위험이 있습니다.
 
 보유자는 이전에 활동적인 기여자가 결국 다른 것들로 이동하기 때문에 [새로운 기여자가 유입](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2)되어야합니다.
 
 정기적으로 추적할 수 있는 커뮤니티 측정 항목의 예는 다음과 같습니다:
 
-* **기여자 중 총 기여 수 및 커밋 수 :** 얼마나 많은 기여자가 있고, 누가 더 많이 또는 적게 활동 하는지를 알려줍니다. GitHub에서는 "Graphs"-> "Contributors"에서 볼 수 있습니다. 현재 이 그래프는 저장소의 기본 브랜치에 작성한 기여자만 계산합니다.
+* **기여자 중 총 기여 수 및 커밋 수 :** 얼마나 많은 기여자가 있고, 누가 더 많이 또는 적게 활동하는지를 알려줍니다. GitHub에서는 "Graphs"-> "Contributors"에서 볼 수 있습니다. 현재 이 그래프는 저장소의 기본 브랜치에 작성한 기여자만 계산합니다.
 
 ![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
 
-* **처음, 캐주얼, 그리고 다시 기여한 사람:** 새로운 참여자를 얻었는지 여부와 그들이 다시 돌아 왔는지 여부를 추적하는 데 도움이됩니다. (캐주얼 기여자는 커밋 수가 적고 커밋 수가 5회 이하이거나, 또 다른 기준은 당신에게 달려 있습니다.) 새로운 참여자가 없으면 프로젝트 커뮤니티가 정체 될 수 있습니다.
+* **처음, 캐주얼, 그리고 다시 기여한 사람:** 새로운 참여자를 얻었는지 여부와 그들이 다시 돌아왔는지 여부를 추적하는 데 도움이됩니다. (캐주얼 기여자는 커밋 수가 적고 커밋 수가 5회 이하이거나, 또 다른 기준은 당신에게 달려 있습니다.) 새로운 참여자가 없으면 프로젝트 커뮤니티가 정체될 수 있습니다.
 
 * **열린 이슈와 pull requests의 수:**  수치가 너무 높으면 이슈 검토 및 코드 검토에 대한 도움이 필요할 수 있습니다.
 
-* **_열렸던_ 이슈와 _열렸던_ pull requests의 수:** 열렸던 이슈는 누군가가 프로젝트의 이슈를 열어 신청할 수 있음을 의미합니다. 그 숫자가 시간이 지남에 따라 증가하면 사람들이 귀하의 프로젝트에 관심을 보였다고 나타낼수 있습니다.
+* **_열렸던_ 이슈와 _열렸던_ pull requests의 수:** 열렸던 이슈는 누군가가 프로젝트의 이슈를 열어 신청할 수 있음을 의미합니다. 그 숫자가 시간이 지남에 따라 증가하면 사람들이 귀하의 프로젝트에 관심을 보였다고 나타낼 수 있습니다.
 
 * **기여 유형:** 예시로, 커밋, 오타 혹은 버그 수정, 또는 이슈에 답변하기가 있습니다.
 
@@ -106,21 +106,21 @@ npm 또는 RubyGems.org와 같은 패키지 관리자를 사용하여 프로젝
 
 ## 메인테이너의 활동
 
-마지막으로, 프로젝트 메인테이너가 받은 기여 분량을 처리 할 수 있는지 확인하여 루프를 닫으십시오. 자신에게 묻고 싶은 마지막 질문은 다음과 같습니다: _나는 (또는 우리가) 우리 커뮤니티에 반응하고 있습니까?_
+마지막으로, 프로젝트 메인테이너가 받은 기여 분량을 처리할 수 있는지 확인하여 루프를 닫으십시오. 자신에게 묻고 싶은 마지막 질문은 다음과 같습니다: _나는 (또는 우리가) 우리 커뮤니티에 반응하고 있습니까?_
 
 응답이 없는 메인테이너는 오픈소스 프로젝트의 병목 현상이 됩니다. 누군가 기여를 제출했지만 메인테이너가 듣지 못하면 기분이 나빠져서 떠나기도 합니다.
 
 [Mozilla의 연구](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177)는 관리자의 응답성이 반복 기여도를 장려하는 중요한 요소임을 시사합니다.
 
-당사자(또는 다른 메인테이너)가 이슈 또는 pull request 여부에 관계없이 기여에 응답하는 데 걸리는 시간을 고려하십시오. 응답은 조치를 취할 필요가 없습니다. 다음과 같이 간단하게 말할 수 있습니다: _"제출해 주셔서 감사합니다. 저는 다음 주에 이것을 검토 할 것입니다."_
+당사자(또는 다른 메인테이너)가 이슈 또는 pull request 여부에 관계없이 기여에 응답하는 데 걸리는 시간을 고려하십시오. 응답은 조치를 취할 필요가 없습니다. 다음과 같이 간단하게 말할 수 있습니다: _"제출해 주셔서 감사합니다. 저는 다음 주에 이것을 검토할 것입니다."_
 
-다음과 같이 기여 프로세스의 단계간에 이동하는 데 걸리는 시간을 측정 할 수도 있습니다:
+다음과 같이 기여 프로세스의 단계 간에 이동하는 데 걸리는 시간을 측정할 수도 있습니다:
 
 * 이슈가 열려있는 평균 시간
 * 이슈가 PR에 의해 폐쇄되는지 여부
-* 부실 이슈가 종결 되는지 여부
+* 부실 이슈가 종결되는지 여부
 * pull request을 병합하는 평균 시간
 
 ## 사람들에 대해 배우려면 📊를 사용하세요
 
-측정 기준을 이해하면 적극적으로 성장하는 오픈소스 프로젝트를 구축하는 데 도움이됩니다. 대시 보드의 모든 측정치를 추적하지 않더라도, 위의 프레임워크를 사용하여 프로젝트가 성공하는 데 도움이 되는 동작 유형에 주의를 기울이십시오.
+측정 기준을 이해하면 적극적으로 성장하는 오픈소스 프로젝트를 구축하는 데 도움이 됩니다. 대시 보드의 모든 측정치를 추적하지 않더라도, 위의 프레임워크를 사용하여 프로젝트가 성공하는 데 도움이 되는 동작 유형에 주의를 기울이십시오.

From ef987fc0d925aaa9ff5fe257106dc106a52ffc7a Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 4 Jul 2024 04:52:02 +0000
Subject: [PATCH 707/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.183.0 to 1.184.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/1d0e911f615a112e322369596f10ee0b95b010ae...97e35c5302afcf3f5ac1df3fca9343d32536b286)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index a1d21173736..ebf1ef1f8b6 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@1d0e911f615a112e322369596f10ee0b95b010ae # v1
+        uses: ruby/setup-ruby@97e35c5302afcf3f5ac1df3fca9343d32536b286 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From bd7c97320dff60ff66c7f5f99721e44dadcdcc98 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 8 Jul 2024 04:12:00 +0000
Subject: [PATCH 708/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.184.0 to 1.185.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/97e35c5302afcf3f5ac1df3fca9343d32536b286...3a77c29278ae80936b4cb030fefc7d21c96c786f)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index ebf1ef1f8b6..d6ea6ef5fe3 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@97e35c5302afcf3f5ac1df3fca9343d32536b286 # v1
+        uses: ruby/setup-ruby@3a77c29278ae80936b4cb030fefc7d21c96c786f # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 24a3958acc251a27dffd779226f02a4b908b8d47 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 11 Jul 2024 04:37:12 +0000
Subject: [PATCH 709/749] chore(deps): bump the dependencies group across 1
 directory with 2 updates

Bumps the dependencies group with 2 updates in the / directory: [ruby/setup-ruby](https://github.com/ruby/setup-ruby) and [actions/setup-node](https://github.com/actions/setup-node).


Updates `ruby/setup-ruby` from 1.185.0 to 1.187.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/3a77c29278ae80936b4cb030fefc7d21c96c786f...161cd54b698f1fb3ea539faab2e036d409550e3c)

Updates `actions/setup-node` from 4.0.2 to 4.0.3
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/60edb5dd545a775178f52524783378180af0d1f8...1e60f620b9541d16bece96c5465dc8ee9832be0b)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
- dependency-name: actions/setup-node
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index d6ea6ef5fe3..004186a5924 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,11 +11,11 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@3a77c29278ae80936b4cb030fefc7d21c96c786f # v1
+        uses: ruby/setup-ruby@161cd54b698f1fb3ea539faab2e036d409550e3c # v1
         with:
           bundler-cache: true
       - name: Set up Node
-        uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4
+        uses: actions/setup-node@1e60f620b9541d16bece96c5465dc8ee9832be0b # v4
       - name: Bootstrap
         run: script/bootstrap
         env:

From 430edd5a5ba716080109d447aa4344bcce6a0a28 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 23 Jul 2024 04:46:18 +0000
Subject: [PATCH 710/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.187.0 to 1.188.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/161cd54b698f1fb3ea539faab2e036d409550e3c...50ba3386b050ad5b97a41fcb81240cbee1d1821f)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 004186a5924..f4c3737ab25 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@161cd54b698f1fb3ea539faab2e036d409550e3c # v1
+        uses: ruby/setup-ruby@50ba3386b050ad5b97a41fcb81240cbee1d1821f # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 2bbfc3cace12d33587f330ee2f7c2af8ff910f60 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 29 Jul 2024 04:38:37 +0000
Subject: [PATCH 711/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.188.0 to 1.190.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/50ba3386b050ad5b97a41fcb81240cbee1d1821f...a6e6f86333f0a2523ece813039b8b4be04560854)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index f4c3737ab25..6770585b3e2 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@50ba3386b050ad5b97a41fcb81240cbee1d1821f # v1
+        uses: ruby/setup-ruby@a6e6f86333f0a2523ece813039b8b4be04560854 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 3196f0fe3cc83f6adfc521b68b05cb0584c43fe2 Mon Sep 17 00:00:00 2001
From: zkVlad <zkVlad@proton.me>
Date: Fri, 2 Aug 2024 10:18:19 +0200
Subject: [PATCH 712/749] French/metrics.md: typo corrections, small
 reorganizations

---
 _articles/fr/metrics.md | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/_articles/fr/metrics.md b/_articles/fr/metrics.md
index b34030e1e65..0d3c83adc01 100644
--- a/_articles/fr/metrics.md
+++ b/_articles/fr/metrics.md
@@ -17,9 +17,9 @@ Les données, lorsqu'elles sont utilisées à bon escient, peuvent vous aider à
 Avec plus d'informations, vous pouvez:
 
 * Comprendre comment les utilisateurs répondent à une nouvelle fonctionnalité
-* Déterminez d'où viennent les nouveaux utilisateurs
+* Déterminer d'où viennent les nouveaux utilisateurs
 * Identifier, et décider de soutenir, un cas d'utilisation aberrant ou une fonctionnalité
-* Quantifiez la popularité de votre projet
+* Quantifier la popularité de votre projet
 * Comprendre comment votre projet est utilisé
 * Recueillir de l'argent grâce à des parrainages et des subventions
 
@@ -49,15 +49,15 @@ Si votre projet est hébergé sur GitHub, [vous pouvez voir](https://help.github
 
 [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.
 
-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.
+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.
 
 ## Usage
 
 Les gens trouvent votre projet sur cette chose sauvage et folle que nous appelons l'Internet. Idéalement, quand ils verront votre projet, ils se sentiront obligés de faire quelque chose. La deuxième question que vous voudrez poser est: _Est-ce que les gens utilisent ce projet ?_
 
-Si vous utilisez un gestionnaire de paquets, tel que npm ou RubyGems.org, pour distribuer votre projet, vous pourrez peut-être suivre les téléchargements de votre projet.
+Si vous utilisez un gestionnaire de paquets pour distribuer votre projet, tels que npm ou RubyGems.org, vous pourrez peut-être suivre les téléchargements de votre projet.
 
-Chaque gestionnaire de paquets peut utiliser une définition légèrement différente de "téléchargement", et les téléchargements ne sont pas nécessairement corrélés aux installations ou à l'utilisation, mais il fournit une base de comparaison. Essayez d'utiliser [Libraries.io](https://libraries.io/) pour suivre les statistiques d'utilisation de nombreux gestionnaires de paquets populaires.
+Chaque gestionnaire de paquets peut utiliser une définition légèrement différente de "téléchargement", et les téléchargements ne sont pas nécessairement corrélés aux installations ou à l'utilisation, mais ils fournissent une base de comparaison. Essayez d'utiliser [Libraries.io](https://libraries.io/) pour suivre les statistiques d'utilisation de nombreux gestionnaires de paquets populaires.
 
 Si votre projet est sur GitHub, naviguez à nouveau vers la page "Trafic". Vous pouvez utiliser le [graphe clone](https://github.com/blog/1873-clone-graphs) pour voir combien de fois votre projet a été cloné un jour donné, ventilé par clone total et clonage unique.
 
@@ -88,7 +88,7 @@ Les exemples de statistiques de communauté que vous souhaitez suivre régulièr
 
 ![Graphique des contributeurs](/assets/images/metrics/repo_contributors_specific_graph.png)
 
-* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+* **Types de contributions:** Par exemple, s'il s'agit de commits, de corrections de fautes de frappe ou de bugs, de commentaires sur une issue.
 
 * **Premiers contributeurs occasionnels et répétitifs :** Vous aide à savoir si vous recevez de nouveaux contributeurs et s'ils reviennent. (Les contributeurs occasionnels sont des contributeurs avec un faible nombre de commit, que ce soit un commit, moins de cinq commits, ou autre chose selon vos critères.) Sans de nouveaux contributeurs, la communauté de votre projet peut devenir stagnante.
 
@@ -96,8 +96,6 @@ Les exemples de statistiques de communauté que vous souhaitez suivre régulièr
 
 * **Nombre d'issue _opened_ et de pull request _opened_ :** Les issues ouvertes signifient que quelqu'un se soucie suffisamment de votre projet pour ouvrir une issue. Si ce nombre augmente avec le temps, cela suggère que les gens s'intéressent à votre projet.
 
-* **Types de contributions :** Par exemple, commit, corrige des fautes de frappe ou des bugs, ou commente une issue.
-
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/arfon?s=180" class="pquote-avatar" alt="avatar">
   L'open source, c'est plus que du code. Les projets Open Source qui réussissent comprennent des contributions au code et à la documentation ainsi que des conversations sur ces changements.
@@ -119,8 +117,8 @@ Pensez à suivre le temps qu'il vous faut (ou à un autre responsable) pour rép
 Vous pouvez également mesurer le temps nécessaire pour passer d'une étape à l'autre du processus de contribution, par exemple:
 
 * Temps moyen d'ouverture d'une issue
-* Si les issues sont fermés par des PR
-* Si les issues périmés se ferment
+* Si les issues sont fermées par des PR
+* Si les issues périmées se ferment
 * Temps moyen pour merger une pull request
 
 ## Utilisez 📊 pour en savoir plus sur les gens

From 29cd3982ca78ed43e7b6fcf64df9b803c0169514 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 7 Aug 2024 04:54:00 +0000
Subject: [PATCH 713/749] chore(deps): bump actions/jekyll-build-pages in the
 dependencies group

Bumps the dependencies group with 1 update: [actions/jekyll-build-pages](https://github.com/actions/jekyll-build-pages).


Updates `actions/jekyll-build-pages` from 1.0.12 to 1.0.13
- [Release notes](https://github.com/actions/jekyll-build-pages/releases)
- [Commits](https://github.com/actions/jekyll-build-pages/compare/b178f9334b208360999a0a57b523613563698c66...44a6e6beabd48582f863aeeb6cb2151cc1716697)

---
updated-dependencies:
- dependency-name: actions/jekyll-build-pages
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/jekyll-preview.yml | 2 +-
 .github/workflows/jekyll.yml         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index 6900c3bc23f..164427f6426 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -36,7 +36,7 @@ jobs:
       - name: Setup Pages
         uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5
       - name: Build with Jekyll
-        uses: actions/jekyll-build-pages@b178f9334b208360999a0a57b523613563698c66 # v1
+        uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1
         with:
           source: ./
           destination: ./_site
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index 662d70b0d57..fd37751763c 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -31,7 +31,7 @@ jobs:
       - name: Setup Pages
         uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5
       - name: Build with Jekyll
-        uses: actions/jekyll-build-pages@b178f9334b208360999a0a57b523613563698c66 # v1
+        uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1
         with:
           source: ./
           destination: ./_site

From 866d90549595e2ce35a16b97eb75cb09e7457b8e Mon Sep 17 00:00:00 2001
From: Dimitri Kandassamy <dimitri.kandassamy@gmail.com>
Date: Fri, 16 Aug 2024 11:26:31 +0200
Subject: [PATCH 714/749] docs: fix broken link to sourcecode.cio.gov

Change url to https://www.cio.gov/2016/08/11/peoples-code.html in all languages

Signed-off-by: Dimitri Kandassamy <dimitri.kandassamy@gmail.com>
---
 _articles/bg/starting-a-project.md      | 2 +-
 _articles/de/starting-a-project.md      | 2 +-
 _articles/el/starting-a-project.md      | 2 +-
 _articles/es/starting-a-project.md      | 2 +-
 _articles/fa/starting-a-project.md      | 2 +-
 _articles/fr/starting-a-project.md      | 2 +-
 _articles/hi/starting-a-project.md      | 2 +-
 _articles/hu/starting-a-project.md      | 2 +-
 _articles/id/starting-a-project.md      | 2 +-
 _articles/it/starting-a-project.md      | 2 +-
 _articles/ja/starting-a-project.md      | 2 +-
 _articles/ko/starting-a-project.md      | 2 +-
 _articles/ms/starting-a-project.md      | 2 +-
 _articles/nl/starting-a-project.md      | 2 +-
 _articles/pcm/starting-a-project.md     | 2 +-
 _articles/pl/starting-a-project.md      | 2 +-
 _articles/pt/starting-a-project.md      | 2 +-
 _articles/ro/starting-a-project.md      | 2 +-
 _articles/ru/starting-a-project.md      | 2 +-
 _articles/starting-a-project.md         | 2 +-
 _articles/ta/starting-a-project.md      | 2 +-
 _articles/tr/starting-a-project.md      | 2 +-
 _articles/zh-hans/starting-a-project.md | 2 +-
 _articles/zh-hant/starting-a-project.md | 2 +-
 24 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index 78b5be61f7b..90f6331162e 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -38,7 +38,7 @@ _Свободен софтуер_ се отнася до същия набор 
 
 * **Приемане и ремиксиране:** Проектите с отворен код могат да се използват от всеки за почти всякакви цели. Хората дори могат да го използват за изграждане на други неща. [WordPress](https://github.com/WordPress), например, стартира като разклонение на съществуващ проект, наречен [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Прозрачност:** Всеки може да провери проект с отворен код за грешки или несъответствия. Прозрачността има значение за правителства като [България](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) или [Съединените щати](https://sourcecode.cio.gov/), регулирани отрасли като банкиране или здравеопазване и софтуер за сигурност като [Да шифроваме](https://github.com/letsencrypt).
+* **Прозрачност:** Всеки може да провери проект с отворен код за грешки или несъответствия. Прозрачността има значение за правителства като [България](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) или [Съединените щати](https://www.cio.gov/2016/08/11/peoples-code.html), регулирани отрасли като банкиране или здравеопазване и софтуер за сигурност като [Да шифроваме](https://github.com/letsencrypt).
 
 Отвореният код също не е само за софтуер. Можете да отворите всичко - от набори от данни до книги. Разгледайте [GitHub Explore](https://github.com/explore) за идеи какво още можете да отворите.
 
diff --git a/_articles/de/starting-a-project.md b/_articles/de/starting-a-project.md
index d281d3b9dd8..60640710914 100644
--- a/_articles/de/starting-a-project.md
+++ b/_articles/de/starting-a-project.md
@@ -42,7 +42,7 @@ _Freie Software_ meint dieselbe Art von Projekten wie _Open-Source_. Der [Begrif
 
 * **Anpassungen:** Open-Source-Projekte können von jedem Menschen für fast jeden Zweck benutzt werden. Leute können daraus sogar andere Dinge bauen. [WordPress](https://github.com/WordPress) beispielsweise begann als ein Fork eines existierenden Projekts namens [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparenz:** In einem Open-Source-Projekt können Fehler oder Ungereimtheiten von jedem behoben werden. Transparenz ist sowohl für Regierungen in [Bulgarien](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) oder den [Vereinigten Staaten](https://web.archive.org/web/20180306072551/https://sourcecode.cio.gov/), für regulierte Industrien wie den Banken- oder Gesundheitssektor und für Sicherheitssoftware wie [Let's Encrypt](https://github.com/letsencrypt) gleichermaßen wichtig.
+* **Transparenz:** In einem Open-Source-Projekt können Fehler oder Ungereimtheiten von jedem behoben werden. Transparenz ist sowohl für Regierungen in [Bulgarien](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) oder den [Vereinigten Staaten](https://web.archive.org/web/20180306072551/https://www.cio.gov/2016/08/11/peoples-code.html), für regulierte Industrien wie den Banken- oder Gesundheitssektor und für Sicherheitssoftware wie [Let's Encrypt](https://github.com/letsencrypt) gleichermaßen wichtig.
 
 Open-Source ist nicht nur für Software, sondern auch für alle anderen Bereiche geeignet, von Datensätzen bis hin zu Büchern. Stöbern Sie durch [GitHub Explore](https://github.com/explore), um einen Eindruck der thematischen Breite von Open-Source-Projekten zu bekommen.
 
diff --git a/_articles/el/starting-a-project.md b/_articles/el/starting-a-project.md
index 2b1d19ee7df..d04ba75cd33 100644
--- a/_articles/el/starting-a-project.md
+++ b/_articles/el/starting-a-project.md
@@ -38,7 +38,7 @@ related:
 
 * **Υιοθέτηση και επανασύνθεση:** Τα πρότζεκτ ανοικτού κώδικα μπορούν να χρησιμοποιηθούν από οποιονδήποτε για σχεδόν οποιονδήποτε σκοπό. Οι άνθρωποι μπορούν ακόμη και να τα χρησιμοποιήσουν για να κατασκευάσουν άλλα πράγματα. Το [WordPress](https://github.com/WordPress), για παράδειγμα, ξεκίνησε ως διακλάδωση ενός υπάρχοντος έργου που ονομαζόταν [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Διαφάνεια:** Οποιοσδήποτε μπορεί να επιθεωρήσει ένα πρότζεκτ ανοικτού κώδικα για λάθη ή ασυνέπειες. Η διαφάνεια έχει σημασία για κυβερνήσεις όπως η [Βουλγαρία](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ή οι [Ηνωμένες Πολιτείες](https://sourcecode.cio.gov/), ρυθμιζόμενες βιομηχανίες όπως οι τράπεζες ή η υγειονομική περίθαλψη και λογισμικό ασφαλείας όπως το [Let's Encrypt](https://github.com/letsencrypt).
+* **Διαφάνεια:** Οποιοσδήποτε μπορεί να επιθεωρήσει ένα πρότζεκτ ανοικτού κώδικα για λάθη ή ασυνέπειες. Η διαφάνεια έχει σημασία για κυβερνήσεις όπως η [Βουλγαρία](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ή οι [Ηνωμένες Πολιτείες](https://www.cio.gov/2016/08/11/peoples-code.html), ρυθμιζόμενες βιομηχανίες όπως οι τράπεζες ή η υγειονομική περίθαλψη και λογισμικό ασφαλείας όπως το [Let's Encrypt](https://github.com/letsencrypt).
 
 Ο ανοικτός κώδικας δεν είναι μόνο για το λογισμικό. Μπορείτε να ανοίξετε τα πάντα, από σύνολα δεδομένων μέχρι βιβλία. Ελέγξτε το [GitHub Explore](https://github.com/explore) για ιδέες σχετικά με το τι άλλο μπορείτε να ανοίξετε με ανοικτό κώδικα.
 
diff --git a/_articles/es/starting-a-project.md b/_articles/es/starting-a-project.md
index 8810fc58b07..2d6a6867420 100644
--- a/_articles/es/starting-a-project.md
+++ b/_articles/es/starting-a-project.md
@@ -45,7 +45,7 @@ Realicemos una comparaci&oacute;n: un proceso de c&oacute;digo cerrado ser&iacut
 
 * **Adopci&oacute;n y remezcla:** Los proyectos de c&oacute;digo abierto pueden ser usados por cualquiera para casi cualquier pr&oacute;p&oacute;sito. Las personas pueden usarlos hasta para construir otras cosas. [WordPress](https://github.com/WordPress), por ejemplo, comenzaron como un "fork" de un proyecto existente llamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparencia:** Cualquiera puede inspeccionar un proyecto de este tipo, ya sea para encontrar errores como inconsistencias. La transparencia es de importancia para gobiernos como el de [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o [United States](https://sourcecode.cio.gov/), para industrias reguladas como la bancaria o la del cuidado de la salud, y para la seguridad del software como [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparencia:** Cualquiera puede inspeccionar un proyecto de este tipo, ya sea para encontrar errores como inconsistencias. La transparencia es de importancia para gobiernos como el de [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o [United States](https://www.cio.gov/2016/08/11/peoples-code.html), para industrias reguladas como la bancaria o la del cuidado de la salud, y para la seguridad del software como [Let's Encrypt](https://github.com/letsencrypt).
 
 C&oacute;digo abierto no es solamente software. Uno puede "abrir" cualquier cosa, desde conjuntos de datos, hasta libros. Mira esto [GitHub Explore](https://github.com/explore) para tener otros ejemplos.
 
diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md
index 4cd9ebb47f7..bab7309f492 100644
--- a/_articles/fa/starting-a-project.md
+++ b/_articles/fa/starting-a-project.md
@@ -38,7 +38,7 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 * **اقتباس و تغییر مجدد:** هر فردی تقریباً با هر هدفی می‌تواند از پروژه‌های متن باز استفاده کند. افراد حتی می‌توانند از یک پروژه، پروژه‌های دیگری به وجود بیاورند. به عنوان مثال می‌توانیم به [وردپرس](https://github.com/WordPress) اشاره کنیم که از پروژه موجودی به نام [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) منشعب شده است.
 
-* **شفافیت:** هرکسی می‌تواند خطاها و تناقض پروژه‌های متن باز را بازرسی کند. از این رو، شفافیت برای دولت‌هایی مانند دولت [بلغارستان](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) یا [ایالات متحده آمریکا](https://sourcecode.cio.gov/) و صنایع مقرراتی مانند بانکداری، مراکز بهداشت وُ درمانی و نرم‌افزار امنیتی مانند [Let's Encrypt](https://github.com/letsencrypt) اهمیت بالایی پیدا می‌کند تا زمان بازرسی خطاها توسط افراد مختلف، دچار مشکل نشوند.
+* **شفافیت:** هرکسی می‌تواند خطاها و تناقض پروژه‌های متن باز را بازرسی کند. از این رو، شفافیت برای دولت‌هایی مانند دولت [بلغارستان](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) یا [ایالات متحده آمریکا](https://www.cio.gov/2016/08/11/peoples-code.html) و صنایع مقرراتی مانند بانکداری، مراکز بهداشت وُ درمانی و نرم‌افزار امنیتی مانند [Let's Encrypt](https://github.com/letsencrypt) اهمیت بالایی پیدا می‌کند تا زمان بازرسی خطاها توسط افراد مختلف، دچار مشکل نشوند.
 
 ویژگی متن باز فقط مختص به نرم‌افزارها نیست، شما هر چیزی حتی مجموعه‌ای از داده‌های یک کتابخانه را می‌توانید متن باز کنید. اگر می‌خواهید بیشتر بدانید که چه چیزهای دیگری را می‌شود متن باز کرد، می‌توانید به [GitHub Explore](https://github.com/explore) مراجعه کنید.
 
diff --git a/_articles/fr/starting-a-project.md b/_articles/fr/starting-a-project.md
index f4b297c65f1..e2884d972f2 100644
--- a/_articles/fr/starting-a-project.md
+++ b/_articles/fr/starting-a-project.md
@@ -45,7 +45,7 @@ Par comparaison, un processus de source fermée serait de se rendre dans un rest
 
 * **Adoption et remixage :** Les projets open source peuvent être utilisés par n'importe qui dans presque n'importe quel but. Les gens peuvent même l'utiliser pour construire d'autres choses. [WordPress](https://github.com/WordPress), par exemple, a commencé en tant que fork (nous verrons plus tard ce qu'on appelle un fork, pour le moment voyez ceci comme une copie à un instant donné) d'un projet existant appelé [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparence :** Tout le monde peut inspecter un projet open source pour y chercher des erreurs ou des incohérences. La transparence est importante pour des gouvernements comme celui de [Bulgarie](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou des [États-Unis](https://sourcecode.cio.gov/), les industries réglementées comme les banques ou les soins de santé, et les logiciels de sécurité comme [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparence :** Tout le monde peut inspecter un projet open source pour y chercher des erreurs ou des incohérences. La transparence est importante pour des gouvernements comme celui de [Bulgarie](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou des [États-Unis](https://www.cio.gov/2016/08/11/peoples-code.html), les industries réglementées comme les banques ou les soins de santé, et les logiciels de sécurité comme [Let's Encrypt](https://github.com/letsencrypt).
 
 L'open source n'est pas seulement pour les logiciels. Vous pouvez tout rendre open source depuis les jeux de données aux livres. Jetez un coup d'œil sur [GitHub Explore](https://github.com/explore) pour trouver des idées sur ce que vous pouvez faire d'autre.
 
diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md
index f9c122127f0..676b1cb07b7 100644
--- a/_articles/hi/starting-a-project.md
+++ b/_articles/hi/starting-a-project.md
@@ -38,7 +38,7 @@ _मुफ़्त सॉफ़्टवेयर_ परियोजनाओ
 
 * **अडॉप्टेशन और रीमिक्सिंग:** ओपन सोर्स प्रोजेक्ट्स का उपयोग कोई भी लगभग किसी भी उद्देश्य के लिए कर सकता है। लोग इसका उपयोग अन्य चीजें बनाने में भी कर सकते हैं। [WordPress](https://github.com/WordPress), उदाहरण के लिए, किसी मौजूदा प्रोजेक्ट के फोर्क के रूप में शुरू किया गया, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md)।
 
-* **पारदर्शिता:** त्रुटियों या विसंगतियों के लिए कोई भी ओपन सोर्स प्रोजेक्ट का निरीक्षण कर सकता है। पारदर्शिता [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) या [United States](https://sourcecode.cio.gov/) जैसी सरकारों, बैंकिंग या स्वास्थ्य देखभाल जैसे विनियमित उद्योगों और [Let's Encrypt](https://github.com/letsencrypt), जैसे सुरक्षा सॉफ़्टवेयर के लिए मायने रखती है।
+* **पारदर्शिता:** त्रुटियों या विसंगतियों के लिए कोई भी ओपन सोर्स प्रोजेक्ट का निरीक्षण कर सकता है। पारदर्शिता [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) या [United States](https://www.cio.gov/2016/08/11/peoples-code.html) जैसी सरकारों, बैंकिंग या स्वास्थ्य देखभाल जैसे विनियमित उद्योगों और [Let's Encrypt](https://github.com/letsencrypt), जैसे सुरक्षा सॉफ़्टवेयर के लिए मायने रखती है।
 
 ओपन सोर्स सिर्फ सॉफ्टवेयर के लिए ही नहीं है। आप डेटा सेट से लेकर किताबों तक सब कुछ ओपन सोर्स कर सकते हैं। आप और क्या स्रोत खोल सकते हैं, इस बारे में विचारों के लिए [गिटहब एक्सप्लोर](https://github.com/explore) देखें।
 
diff --git a/_articles/hu/starting-a-project.md b/_articles/hu/starting-a-project.md
index 28ef6528c3d..0007069bea4 100644
--- a/_articles/hu/starting-a-project.md
+++ b/_articles/hu/starting-a-project.md
@@ -38,7 +38,7 @@ _Free software_ kifejezés ugyanazokra a projektekre vonatkozik, mint amire az _
 
 * **Elterjedés és újrafelhasználás:** A nyílt forráskódú projekteket bárki használhatja szinte bármilyen célra. Az emberek akár más dolgok létrehozására is felhasználhatják. A [WordPress](https://github.com/WordPress) például úgy kezdte, hogy egy létező, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) nevű projektet elágaztattak.
 
-* **Átláthatóság:** A nyílt forráskódú projektet bárki megvizsgálhatja, vagy hibákat kereshet benne. Az átláthatóság a kormányoknak is fontos, mint ahogy [Bulgária](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) teszi ezt, vagy ahogy az [Amerikai Egyesült Államok](https://sourcecode.cio.gov/) szabályozza a bank, és egészségügy iparát, de fontos a biztonsági szoftverek esetén is, mint a [Let's Encrypt](https://github.com/letsencrypt).
+* **Átláthatóság:** A nyílt forráskódú projektet bárki megvizsgálhatja, vagy hibákat kereshet benne. Az átláthatóság a kormányoknak is fontos, mint ahogy [Bulgária](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) teszi ezt, vagy ahogy az [Amerikai Egyesült Államok](https://www.cio.gov/2016/08/11/peoples-code.html) szabályozza a bank, és egészségügy iparát, de fontos a biztonsági szoftverek esetén is, mint a [Let's Encrypt](https://github.com/letsencrypt).
 
 A nyílt forráskódú projekt nem csak szoftver lehet. Lehet ez adat, vagy könyv is akár, de bármi más is. Nézd meg a [GitHub Explore](https://github.com/explore) helyen, hogy mi minden lehet nyílt forráskódú projekt.
 
diff --git a/_articles/id/starting-a-project.md b/_articles/id/starting-a-project.md
index 7822b03b815..1757809b743 100644
--- a/_articles/id/starting-a-project.md
+++ b/_articles/id/starting-a-project.md
@@ -45,7 +45,7 @@ Sebagai perbandingan, sebuah proses yang tertutup akan seperti dimana Anda pergi
 
 * **Adopsi dan menggabungkan:** Proyek open source bisa digunakan oleh siapapun untuk hampir semua tujuan. Bahkan bisa digunakan untuk membangun proyek lain. [WordPress](https://github.com/WordPress), sebagai contoh, dimulai dari hasil _fork_ dari proyek yang sudah ada bernama [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparansi:** Setiap orang dapat melihat kesalahan atau inkonsistensi pada proyek open source. Transparansi sangat penting bagi pemerintah seperti [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) atau  [Amerika Serikat](https://sourcecode.cio.gov/), industri yang memiliki regulasi seperti perbankan atau kesehatan, dan perangkat lunak keamanan seperti [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparansi:** Setiap orang dapat melihat kesalahan atau inkonsistensi pada proyek open source. Transparansi sangat penting bagi pemerintah seperti [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) atau  [Amerika Serikat](https://www.cio.gov/2016/08/11/peoples-code.html), industri yang memiliki regulasi seperti perbankan atau kesehatan, dan perangkat lunak keamanan seperti [Let's Encrypt](https://github.com/letsencrypt).
 
 Open source bukan hanya untuk perangkat lunak saja. Anda bisa membuka tentang apa saja mulai dari kumpulan data hingga buku. Silahkan lihat [GitHub Explore](https://github.com/explore) untuk ide yang dapat Anda buka sebagai open source.
 
diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md
index 296c2fc91ed..8e0ed4070ef 100644
--- a/_articles/it/starting-a-project.md
+++ b/_articles/it/starting-a-project.md
@@ -38,7 +38,7 @@ _Software Libero_ si riferisce allo stesso insieme di progetti di _Open Source_.
 
 * **Adozione e remix:** i progetti open source possono essere utilizzati da chiunque per quasi tutti gli scopi. Le persone possono persino usarlo per costruire altre cose. [WordPress](https://github.com/WordPress), ad esempio, è iniziato come fork di un progetto esistente chiamato [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Trasparenza:** chiunque può verificare la presenza di bug o incoerenze in un progetto open source. La trasparenza è importante per governi come la [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o gli [Stati Uniti](https://sourcecode.cio.gov/), settori regolamentati come quello bancario o sanitario e software di sicurezza come [Let's Encrypt](https://github.com/letsencrypt).
+* **Trasparenza:** chiunque può verificare la presenza di bug o incoerenze in un progetto open source. La trasparenza è importante per governi come la [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o gli [Stati Uniti](https://www.cio.gov/2016/08/11/peoples-code.html), settori regolamentati come quello bancario o sanitario e software di sicurezza come [Let's Encrypt](https://github.com/letsencrypt).
 
 L'open source non riguarda solo il software. Puoi aprire qualsiasi cosa, dai set di dati ai libri. Dai un'occhiata a [GitHub Explore](https://github.com/explore) per idee su cos'altro puoi aprire.
 
diff --git a/_articles/ja/starting-a-project.md b/_articles/ja/starting-a-project.md
index d0cce69eef7..8d374687a9e 100644
--- a/_articles/ja/starting-a-project.md
+++ b/_articles/ja/starting-a-project.md
@@ -38,7 +38,7 @@ _フリーソフトウェア_ という言葉も _オープンソース_ と同
 
 * **取り入れて再構成：** オープンソースプロジェクトは誰しもがほとんどいかなる理由のためにも使えるものです。人々は他のものを作るためにでも使うことができます。例えば [WordPress](https://github.com/WordPress) は、 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) と呼ばれる既存のプロジェクトのフォークとして始まりました。
 
-* **透明性：** 誰でもオープンソースプロジェクトにエラーがないかや一貫していないところがないか調べることができます。透明性は[ブルガリア](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a)や[アメリカ](https://sourcecode.cio.gov/)のような政府、銀行やヘルスケアのような規制産業、 [Let's Encrypt](https://github.com/letsencrypt) のようなセキュリティソフトウェアにとって重要です。
+* **透明性：** 誰でもオープンソースプロジェクトにエラーがないかや一貫していないところがないか調べることができます。透明性は[ブルガリア](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a)や[アメリカ](https://www.cio.gov/2016/08/11/peoples-code.html)のような政府、銀行やヘルスケアのような規制産業、 [Let's Encrypt](https://github.com/letsencrypt) のようなセキュリティソフトウェアにとって重要です。
 
 オープンソースはソフトウェアのためだけのものでもありません。データセットから本まであらゆるものをオープンソースにできるのです。他になにかオープンソースにできるものはないかアイデアを得るために [GitHub Explore](https://github.com/explore) をチェックしてみましょう。
 
diff --git a/_articles/ko/starting-a-project.md b/_articles/ko/starting-a-project.md
index bad3e06be84..0125b4cbf49 100644
--- a/_articles/ko/starting-a-project.md
+++ b/_articles/ko/starting-a-project.md
@@ -45,7 +45,7 @@ related:
 
 * **채택과 재가공:** 오픈소스 프로젝트는 거의 모든 용도로 누구나 사용할 수 있습니다. 심지어 사람들이 그 프로젝트를 기반으로 다른 프로젝트를 만들 수도 있습니다. 예컨대 [WordPress](https://github.com/WordPress)는 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md)라는 기존 프로젝트의 포크로 시작했습니다.
 
-* **투명성:** 누구나 오픈소스 프로젝트에서 오류나 불일치를 검사 할 수 있습니다. 투명성은 [불가리아](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a)나 [미국](https://sourcecode.cio.gov/) 같은 정부, 은행 또는 의료 같은 규제 대상 산업, Let's Encrypt 등의 보안 소프트웨어에는 투명성이 중요합니다.
+* **투명성:** 누구나 오픈소스 프로젝트에서 오류나 불일치를 검사 할 수 있습니다. 투명성은 [불가리아](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a)나 [미국](https://www.cio.gov/2016/08/11/peoples-code.html) 같은 정부, 은행 또는 의료 같은 규제 대상 산업, Let's Encrypt 등의 보안 소프트웨어에는 투명성이 중요합니다.
 
 오픈소스는 소프트웨어만을 위한 것이 아닙니다. 데이터 세트에서부터 서적에 이르기까지 모두 오픈소스로 만들 수 있습니다. [GitHub Explore](https://github.com/explore)에서 다른 오픈소스 아이디어를 확인해 보세요.
 
diff --git a/_articles/ms/starting-a-project.md b/_articles/ms/starting-a-project.md
index 0c3209277d4..f0b8f82d705 100644
--- a/_articles/ms/starting-a-project.md
+++ b/_articles/ms/starting-a-project.md
@@ -38,7 +38,7 @@ _Perisian percuma_ merujuk kepada set projek yang sama dengan _open source_. Kad
 
 * **Adopsi dan pencampuran semula:** Projek sumber terbuka dapat digunakan oleh siapa saja untuk hampir semua tujuan. Orang bahkan boleh menggunakannya untuk membina perkara lain.[WordPress](https://github.com/WordPress),sebagai contoh, dimulakan sebagai garpu projek sedia ada yang dipanggil [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Ketelusan:** Sesiapa sahaja dapat memeriksa projek sumber terbuka untuk kesilapan atau ketidakkonsistenan. Perkara ketelusan kepada kerajaan seperti [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/),industri terkawal seperti perbankan atau penjagaan kesihatan, dan perisian keselamatan seperti [Let's Encrypt](https://github.com/letsencrypt).
+* **Ketelusan:** Sesiapa sahaja dapat memeriksa projek sumber terbuka untuk kesilapan atau ketidakkonsistenan. Perkara ketelusan kepada kerajaan seperti [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://www.cio.gov/2016/08/11/peoples-code.html),industri terkawal seperti perbankan atau penjagaan kesihatan, dan perisian keselamatan seperti [Let's Encrypt](https://github.com/letsencrypt).
 
 Sumber terbuka bukan hanya untuk perisian. Anda boleh membuka sumber semuanya dari set data hingga buku. Lihatlah[GitHub Explore](https://github.com/explore)untuk idea mengenai apa lagi yang boleh anda buka sumber.
 
diff --git a/_articles/nl/starting-a-project.md b/_articles/nl/starting-a-project.md
index 6cb613a87ac..ddcfb0b8625 100644
--- a/_articles/nl/starting-a-project.md
+++ b/_articles/nl/starting-a-project.md
@@ -41,7 +41,7 @@ _Vrije software (Free software)_ verwijst naar dezelfde reeks projecten als _ope
 
 * **Adoptie en remixen:** Open source-projecten kunnen door iedereen voor bijna elk doel worden gebruikt. Mensen kunnen er zelfs andere dingen mee bouwen. [WordPress](https://github.com/WordPress) is bijvoorbeeld begonnen als een splitsing van een bestaand project met de naam [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparantie:** Iedereen kan een open source-project inspecteren op fouten of inconsistenties. Transparantie is belangrijk voor regeringen zoals [Bulgarije](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) of de [Verenigde Staten](https://sourcecode.cio.gov/), gereguleerde industrieën zoals het bankwezen of de gezondheidszorg, en beveiligingssoftware zoals [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparantie:** Iedereen kan een open source-project inspecteren op fouten of inconsistenties. Transparantie is belangrijk voor regeringen zoals [Bulgarije](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) of de [Verenigde Staten](https://www.cio.gov/2016/08/11/peoples-code.html), gereguleerde industrieën zoals het bankwezen of de gezondheidszorg, en beveiligingssoftware zoals [Let's Encrypt](https://github.com/letsencrypt).
 
 Open source is niet alleen voor software. U kunt alles openen, van datasets tot boeken. Bekijk [GitHub Explore](https://github.com/explore) voor ideeën over wat je nog meer kunt open source.
 
diff --git a/_articles/pcm/starting-a-project.md b/_articles/pcm/starting-a-project.md
index a63ac866d45..3f46dda2f0b 100644
--- a/_articles/pcm/starting-a-project.md
+++ b/_articles/pcm/starting-a-project.md
@@ -38,7 +38,7 @@ _Free software_ refers to the same set of projects as _open source_. Sometimes y
 
 * **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://www.cio.gov/2016/08/11/peoples-code.html), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
 
 Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
 
diff --git a/_articles/pl/starting-a-project.md b/_articles/pl/starting-a-project.md
index ed7caa0598b..3e6f9bd6030 100644
--- a/_articles/pl/starting-a-project.md
+++ b/_articles/pl/starting-a-project.md
@@ -40,7 +40,7 @@ _Wolne oprogramowanie_ odnosi się do tego samego zestawu projektów, co _otwart
 
 * **Adopcja i remiksowanie:** projekty open source mogą być wykorzystywane przez każdego do prawie dowolnego celu. Ludzie mogą nawet używać go do budowania innych rzeczy. [WordPress](https://github.com/WordPress), na przykład, zaczął się jako rozwidlenie istniejącego projektu o nazwie [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparentność:** Każdy może sprawdzić projekt open source pod kątem błędów lub niespójności. Przejrzystość ma znaczenie dla rządów takich jak [Bułgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) lub [Stany Zjednoczone](https://sourcecode.cio.gov/), regulowane branże, takie jak bankowość lub opieka zdrowotna, oraz oprogramowanie zabezpieczające, takie jak [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparentność:** Każdy może sprawdzić projekt open source pod kątem błędów lub niespójności. Przejrzystość ma znaczenie dla rządów takich jak [Bułgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) lub [Stany Zjednoczone](https://www.cio.gov/2016/08/11/peoples-code.html), regulowane branże, takie jak bankowość lub opieka zdrowotna, oraz oprogramowanie zabezpieczające, takie jak [Let's Encrypt](https://github.com/letsencrypt).
 
 Open source to nie tylko oprogramowanie. Możesz otworzyć wszystko, od zbiorów danych po książki. Sprawdź [GitHub Explore](https://github.com/explore), aby uzyskać pomysły na to, co jeszcze możesz otworzyć.
 
diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index fbad818ce44..5b5ec530f5a 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -45,7 +45,7 @@ Em comparação, um processo de código fechado seria ir a um restaurante e pedi
 
 * **Adoção e remixing:** Projetos open source podem ser utilizados por qualquer um para praticamente qualquer propósito. As pessoas podem até mesmo utilizá-lo para construir outras coisas. [WordPress](https://github.com/WordPress), por exemplo, começou como um fork de um projeto chamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparência:** Qualquer um pode inspecionar um projeto open source por erros ou inconsistências. A transparência importa a governos como a [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou os [Estados Unidos](https://sourcecode.cio.gov/), indústrias regulamentadas como bancos ou indústrias de saúde, e softwares de segurança como [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparência:** Qualquer um pode inspecionar um projeto open source por erros ou inconsistências. A transparência importa a governos como a [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou os [Estados Unidos](https://www.cio.gov/2016/08/11/peoples-code.html), indústrias regulamentadas como bancos ou indústrias de saúde, e softwares de segurança como [Let's Encrypt](https://github.com/letsencrypt).
 
 Open source não é só sobre software. Você pode tornar qualquer coisa open source, de conjuntos de dados a livros. Dê uma olhada no [GitHub Explore](https://github.com/explore) por ideias do que você pode tornar open source.
 
diff --git a/_articles/ro/starting-a-project.md b/_articles/ro/starting-a-project.md
index 4b59148bda0..3f8fb1b048c 100644
--- a/_articles/ro/starting-a-project.md
+++ b/_articles/ro/starting-a-project.md
@@ -52,7 +52,7 @@ Prin comparație, într-un proces cu sursă închisă mergi la un restaurant și
 
 * **Adoptarea și remixarea:** Proiectele cu sursă deschisă pot fi folosite de oricine pentru aproape orice scop. Oamenii le pot folosi chiar și pentru a construi alte lucruri. [WordPress](https://github.com/WordPress), de exemplu, a început ca o bifurcație a unui proiect existent numit [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparența:** Oricine poate inspecta un proiect cu sursă deschisă pentru erori sau neconcordanțe. Transparența contează pentru guverne, cum ar fi [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) sau [Statele Unite](https://sourcecode.cio.gov/), industrii reglementate cum ar fi sectorul bancar sau asistența medicală, și software-uri de securitate cum ar fi [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparența:** Oricine poate inspecta un proiect cu sursă deschisă pentru erori sau neconcordanțe. Transparența contează pentru guverne, cum ar fi [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) sau [Statele Unite](https://www.cio.gov/2016/08/11/peoples-code.html), industrii reglementate cum ar fi sectorul bancar sau asistența medicală, și software-uri de securitate cum ar fi [Let's Encrypt](https://github.com/letsencrypt).
 
 Open source nici nu este doar pentru software. Poți deschide sursa a orice de la seturi de date la cărți. Aruncă o privire la [GitHub Explore](https://github.com/explore) pentru idei despre sursa a ce altceva poți deschide.
 
diff --git a/_articles/ru/starting-a-project.md b/_articles/ru/starting-a-project.md
index 1389cecd585..fa465dd824e 100644
--- a/_articles/ru/starting-a-project.md
+++ b/_articles/ru/starting-a-project.md
@@ -38,7 +38,7 @@ _Свободное ПО_ относится к тем же проектам, ч
 
 * **Адаптация и доработки:** Опенсорс-проекты могут использоваться кем угодно практически для любой цели. Люди могут использовать ваш проект для создания чего-то нового. [WordPress](https://github.com/WordPress), например, стартовал как форк (ответвление) уже существовавшего проекта [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
 
-* **Прозрачность:** Любой может проверить опенсорс-проект на наличие ошибок и несоответствий. Прозрачность важна даже на государственном уровне. Например, правительство [Болгарии](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) и [США](https://sourcecode.cio.gov/) законодательно предписали прозрачность для таких отраслей как банковское дело, здравоохранение, и программ безопасности, вроде [Let's Encrypt](https://github.com/letsencrypt).
+* **Прозрачность:** Любой может проверить опенсорс-проект на наличие ошибок и несоответствий. Прозрачность важна даже на государственном уровне. Например, правительство [Болгарии](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) и [США](https://www.cio.gov/2016/08/11/peoples-code.html) законодательно предписали прозрачность для таких отраслей как банковское дело, здравоохранение, и программ безопасности, вроде [Let's Encrypt](https://github.com/letsencrypt).
 
 Опенсорсом может быть не только ПО, но и многое другое: от наборов данных до книг. В разделе [GitHub Explore](https://github.com/explore) можно ознакомится с идеями проектов, которые можно заопенсорсить.
 
diff --git a/_articles/starting-a-project.md b/_articles/starting-a-project.md
index 713b8df38d1..2beeac5fb83 100644
--- a/_articles/starting-a-project.md
+++ b/_articles/starting-a-project.md
@@ -38,7 +38,7 @@ _Free software_ refers to the same set of projects as _open source_. Sometimes y
 
 * **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
-* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://www.cio.gov/2016/08/11/peoples-code.html), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
 
 Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
 
diff --git a/_articles/ta/starting-a-project.md b/_articles/ta/starting-a-project.md
index 04b33e646a2..34fe826f8ea 100644
--- a/_articles/ta/starting-a-project.md
+++ b/_articles/ta/starting-a-project.md
@@ -45,7 +45,7 @@ related:
 
 * **ஏற்றல் மற்றும் மறுகலப்பு செய்தல்:** திறந்த மூல திட்டங்களை ஏறக்குறைய எந்த நோக்கத்திற்காகவும் பயன்படுத்தலாம். மற்ற விஷயங்களை உருவாக்க மக்கள் அதை பயன்படுத்தலாம். உதாரணமாக, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) என்று அழைக்கப்படும் ஒரு திட்டத்தின் ஒரு முனையாகத் துவங்கியது [வேர்ட்பிரஸ்](https://github.com/WordPress).
 
-* **வெளிப்படைத்தன்மை:** தவறுகள் அல்லது முரண்பாடுகளுக்கு எவரும் திறந்த மூல திட்டத்தை ஆய்வு செய்ய முடியும். [பல்கேரியா](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-source-98bf626cf70a) அல்லது [ஐக்கிய நாடுகள்](https://sourcecode.cio.gov/) போன்ற அரசாங்கங்களுக்கு, வங்கி அல்லது சுகாதாரம் போன்ற ஒழுங்குபடுத்தப்பட்ட தொழிற்சாலைகள், மற்றும் பாதுகாப்பு மென்பொருள் [Let's Encrypt](https://github.com/letsencrypt) போன்றவற்றிற்கு வெளிப்படைத்தன்மை முக்கியமானது.
+* **வெளிப்படைத்தன்மை:** தவறுகள் அல்லது முரண்பாடுகளுக்கு எவரும் திறந்த மூல திட்டத்தை ஆய்வு செய்ய முடியும். [பல்கேரியா](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-source-98bf626cf70a) அல்லது [ஐக்கிய நாடுகள்](https://www.cio.gov/2016/08/11/peoples-code.html) போன்ற அரசாங்கங்களுக்கு, வங்கி அல்லது சுகாதாரம் போன்ற ஒழுங்குபடுத்தப்பட்ட தொழிற்சாலைகள், மற்றும் பாதுகாப்பு மென்பொருள் [Let's Encrypt](https://github.com/letsencrypt) போன்றவற்றிற்கு வெளிப்படைத்தன்மை முக்கியமானது.
 
 திறந்த மூலம் மென்பொருளுக்கு மட்டும் அல்ல. தரவு தொகுப்புகளிலிருந்து புத்தகங்கள் வரை அனைத்தையும் திறக்கலாம். நீங்கள் மூலத்தைத் திறக்க முடியும் என்பதில் கருத்துக்களுக்கு [கிட்ஹப் Explore](https://github.com/explore) என்பதைப் பார்க்கவும்.
 
diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index 1f19b0efcf1..b562faeedc7 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -38,7 +38,7 @@ Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](htt
 
 * **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
 
-* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
+* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://www.cio.gov/2016/08/11/peoples-code.html) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
 
 Açık kaynak sadece yazılım için değil. Veri kümelerinden kitaplara kadar her şeyi açık kaynak koduyla açabilirsiniz. Açık kaynak başka neler yapabileceğiniz hakkında fikir edinmek için [GitHub Explore](https://github.com/explore)'a göz atın.
 
diff --git a/_articles/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md
index c0e03af3875..d946215aee5 100644
--- a/_articles/zh-hans/starting-a-project.md
+++ b/_articles/zh-hans/starting-a-project.md
@@ -46,7 +46,7 @@ redirect_from: /zh-cn/starting-a-project/
 
 * **采用和重组：** 任何人几乎可以出于任何目的使用开源项目。人们甚至可以使用它来构建其他东西。例如，[WordPress](https://github.com/WordPress) 就是派生自一个名为 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) 的现有项目。
 
-* **透明度：** 任何人都可以检查开源项目是否有错误或不一致。 透明度对[保加利亚](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美国](https://sourcecode.cio.gov/)等政府，银行或医疗保健等受监管行业以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全软件都很重要。
+* **透明度：** 任何人都可以检查开源项目是否有错误或不一致。 透明度对[保加利亚](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美国](https://www.cio.gov/2016/08/11/peoples-code.html)等政府，银行或医疗保健等受监管行业以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全软件都很重要。
 
 开源并不仅仅限于软件。您可以开源任何事物，从数据集到书本。查看 [GitHub Explore](https://github.com/explore) 来找找有什么是你可以开源的。
 
diff --git a/_articles/zh-hant/starting-a-project.md b/_articles/zh-hant/starting-a-project.md
index 537bcf8ffa2..0d6ed41e0e0 100644
--- a/_articles/zh-hant/starting-a-project.md
+++ b/_articles/zh-hant/starting-a-project.md
@@ -46,7 +46,7 @@ redirect_from: /zh-tw/starting-a-project/
 
 * **採用和重組：** 任何人幾乎可以出於任何目的使用開源專案。人們甚至可以使用它來構建其他東西。例如，[WordPress](https://github.com/WordPress) 就是派生自一個名爲 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) 的現有專案。
 
-* **透明度：** 任何人都可以檢查開源專案是否有錯誤或不一致。 透明度對[保加利亞](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美國](https://sourcecode.cio.gov/)等政府，銀行或醫療保健等受監管行業以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全軟件都很重要。
+* **透明度：** 任何人都可以檢查開源專案是否有錯誤或不一致。 透明度對[保加利亞](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美國](https://www.cio.gov/2016/08/11/peoples-code.html)等政府，銀行或醫療保健等受監管行業以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全軟件都很重要。
 
 開源並不僅僅限於軟件。您可以開源任何事物，從數據集到書本。查看 [GitHub Explore](https://github.com/explore) 開找找有什麼是你可以開源的。
 

From 76bfcab5518f8ad8f2743fd7798b6df54cb39345 Mon Sep 17 00:00:00 2001
From: jmeridth <jmeridth@gmail.com>
Date: Mon, 2 Sep 2024 11:30:58 -0500
Subject: [PATCH 715/749] fix: code scanning alerts re: workflows permissions

- [x] add permissions to stale workflow
- [x] add permissions to tests workflow
  - [x] remove empty brackers on pull_request branch in tests workflow

Signed-off-by: jmeridth <jmeridth@gmail.com>
---
 .github/workflows/stale.yml | 4 ++++
 .github/workflows/tests.yml | 4 +++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
index 063c3c76c9f..1aeb25b78b6 100644
--- a/.github/workflows/stale.yml
+++ b/.github/workflows/stale.yml
@@ -3,6 +3,10 @@ on:
   workflow_dispatch:
   schedule:
     - cron: "0 12 * * *"
+permissions:
+  contents: read
+  issues: write
+  pull-requests: write
 jobs:
   stale:
     runs-on: ubuntu-latest
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 6770585b3e2..3ecf804d727 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -2,8 +2,10 @@ name: GitHub Actions CI
 on:
   push:
     branches: master
-  pull_request: []
+  pull_request:
   merge_group:
+permissions:
+  contents: read
 jobs:
   tests:
     runs-on: ubuntu-latest

From b3d7de0ffeb6a06eab4e90061407744205cf2f3f Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 4 Sep 2024 04:13:19 +0000
Subject: [PATCH 716/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.190.0 to 1.191.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/a6e6f86333f0a2523ece813039b8b4be04560854...52753b7da854d5c07df37391a986c76ab4615999)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 6770585b3e2..47935338fce 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@a6e6f86333f0a2523ece813039b8b4be04560854 # v1
+        uses: ruby/setup-ruby@52753b7da854d5c07df37391a986c76ab4615999 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From b4b16ee043328e08338e8a86887527171a6ec6fe Mon Sep 17 00:00:00 2001
From: Berenice Monsivais <153947742+beremonsivais@users.noreply.github.com>
Date: Fri, 6 Sep 2024 16:13:14 -0600
Subject: [PATCH 717/749] Corrected typographic errors
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Added "¡" marks where needed. Corrected some words with written accents.
---
 _articles/es/starting-a-project.md | 34 +++++++++++++++---------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/_articles/es/starting-a-project.md b/_articles/es/starting-a-project.md
index 2d6a6867420..32309c3c196 100644
--- a/_articles/es/starting-a-project.md
+++ b/_articles/es/starting-a-project.md
@@ -12,7 +12,7 @@ related:
 
 ## El c&oacute;mo y el por qu&eacute; del C&oacute;digo Abierto
 
-&iquest;Est&aacute;s pensando c&oacute;mo comenzar un proyecto de c&oacut;digo abierto? &iexcl;Felicitaciones! El mundo aprecia tu contribuci&oacute;n. Hablemos sobre lo que es un proyecto de c&oacute;digo abierto y porqu&eacute; la gente lo lleva adelante
+&iquest;Est&aacute;s pensando c&oacute;mo comenzar un proyecto de c&oacute;digo abierto? &iexcl;Felicitaciones! El mundo aprecia tu contribuci&oacute;n. Hablemos sobre lo que es un proyecto de c&oacute;digo abierto y por qu&eacute; la gente lo lleva adelante
 
 ### &iquest;Qu&eacute; significa "C&oacute;digo Abierto"?
 
@@ -22,10 +22,10 @@ Cuando un proyecto es de c&oacute;digo abierto, significa que **cualquier person
 
 Para entender c&oacute;mo funciona, imagina a un amigo que organiza una comida, te invita, y llevas una torta.
 
-* Todos prueban la torta (_usarlo_)
-* &iexcl;La torta es un &eacute;xito! Te piden la receta, la cu&aacute;l t&uacute; das. (_estudiarlo/verlo_)
-* Un amigo, Pedro, es cocinero, y te sugiere colocar menos az&uacute;car (_modificarlo_)
-* Otro amigo, Juan, te pide permiso para usarlo en una cena que tendr&aacute; la pr&oacute;xima semana (_distribuirlo_)
+* Todos prueban la torta. (_usarlo_)
+* &iexcl;La torta es un &eacute;xito! Te piden la receta, la cual tu das. (_estudiarlo/verlo_)
+* Un amigo, Pedro, es cocinero, y te sugiere colocar menos az&uacute;car. (_modificarlo_)
+* Otro amigo, Juan, te pide permiso para usarlo en una cena que tendr&aacute; la pr&oacute;xima semana. (_distribuirlo_)
 
 Realicemos una comparaci&oacute;n: un proceso de c&oacute;digo cerrado ser&iacute;a ir a un restaurante y pedir una porci&oacute;n de torta. Para ello tendr&iacute;as que pagar por la misma, y el restaurante muy probablemente no te dar&aacute; su receta. Si decidieras copiar su torta y venderla bajo otro nombre, el restaurante podr&iacute;a recurrir a acciones legales en contra.
 
@@ -41,9 +41,9 @@ Realicemos una comparaci&oacute;n: un proceso de c&oacute;digo cerrado ser&iacut
 
 [Hay muchas razones](https://ben.balter.com/2015/11/23/why-open-source/) por las cuales una persona u organizaci&oacute;n querr&iacute;an involucrarse en un proyecto de c&oacute;digo abierto. Algunos ejemplos son:
 
-* **Colaboraci&oacute;n:** Los proyectos de c&oacute;digo abierto pueden aceptar cambios efectuados por cualquier persona alrededor del mundo. [Exercism](https://github.com/exercism/), por ejemplo, una plataforma para ejercicios de programaci&oacute;n con m&aacute;s de 350 colaboradores.
+* **Colaboraci&oacute;n:** Los proyectos de c&oacute;digo abierto pueden aceptar cambios efectuados por cualquier persona alrededor del mundo. [Exercism](https://github.com/exercism/), por ejemplo, es una plataforma para ejercicios de programaci&oacute;n con m&aacute;s de 350 colaboradores.
 
-* **Adopci&oacute;n y remezcla:** Los proyectos de c&oacute;digo abierto pueden ser usados por cualquiera para casi cualquier pr&oacute;p&oacute;sito. Las personas pueden usarlos hasta para construir otras cosas. [WordPress](https://github.com/WordPress), por ejemplo, comenzaron como un "fork" de un proyecto existente llamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **Adopci&oacute;n y remezcla:** Los proyectos de c&oacute;digo abierto pueden ser usados por cualquiera para casi cualquier prop&oacute;sito. Las personas pueden usarlos hasta para construir otras cosas. [WordPress](https://github.com/WordPress), por ejemplo, comenzaron como un "fork" de un proyecto existente llamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
 
 * **Transparencia:** Cualquiera puede inspeccionar un proyecto de este tipo, ya sea para encontrar errores como inconsistencias. La transparencia es de importancia para gobiernos como el de [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o [United States](https://www.cio.gov/2016/08/11/peoples-code.html), para industrias reguladas como la bancaria o la del cuidado de la salud, y para la seguridad del software como [Let's Encrypt](https://github.com/letsencrypt).
 
@@ -71,7 +71,7 @@ Si no estás convencido todav&iacute;a, toma un momento para pensar acerca de cu
 
 Los objetivos pueden ayudarte a detectar puntos en los que continuar trabajando, a qu&eacute; decirle que no, y a d&oacute;nde recurrir por ayuda. Comienza pregunt&aacute;ndote, _&iquest;Por qu&eacute; estoy haciendo "c&oacute;digo abierto" a mi proyecto?_
 
-No hay nunca una respuesta correcta a esta pregunta. Puedes tener m&uacute;ltiples objetivos para un solo proyecto, o diferentes proyectos con diferentes objetivos.
+No hay nunca una respuesta correcta a esta pregunta. Puedes tener m&uacute;ltiples objetivos para un solo proyecto o diferentes proyectos con diferentes objetivos.
 
 Si tu &uacute;nico objetivo es mostrar al mundo tu trabajo, quiz&aacute;s no necesites ni quieras contribuci&oacute;n, y quiz&aacute;s digas eso en el README. Por otra parte, si quieres ayuda, invertir&aacute;s tiempo en clarificar la documentaci&oacute;n y en hacer sentir a los reci&eacute;n llegados bienvenidos.
 
@@ -87,7 +87,7 @@ A medida que tu proyecto crezca, tu comunidad podr&aacute; llegar a necesitar m&
 
 El tiempo que dediques a tareas ajenas a codificar depender&aacute; del tama&ntilde;o y alcance de tus proyectos, deber&iacute;as estar preparado, como encargado de mantenimiento, a afrontarlas por tu cuenta o encontrar a alguien que pueda ayudarte.
 
-**Si eres parte de una compa&ntilde;ia que quiere "abrir" el c&oacute;digo de un proyecto,** debes asegurarte que el mismo tiene recursos internos que necesitan mejorar. Necesitar&aacute;s identificar al responsable de mantener el proyecto una vez lanzado, y definir c&oacute;mo vas a compartir esas tareas con tu comunidad.
+**Si eres parte de una compa&ntilde;ia que quiere "abrir" el c&oacute;digo de un proyecto,** debes asegurarte que el mismo tiene recursos internos que necesitan mejorar. Necesitar&aacute;s identificar al responsable de mantener el proyecto una vez lanzado y definir c&oacute;mo vas a compartir esas tareas con tu comunidad.
 
 Si necesitas un presupuesto dedicado o personal para la promoci&oacute;n, operaci&oacute;n y mantenimiento del proyecto, empieza esas conversaciones de forma temprana.
 
@@ -101,13 +101,13 @@ Si necesitas un presupuesto dedicado o personal para la promoci&oacute;n, operac
 
 ### Contribuyendo en otros proyectos.
 
-Si tu meta es aprender c&oacute;mo contribuir con otros o entender c&oacute;mo funciona el "c&oacute;digo abierto", considera contribuir en proyectos existentes. Comienza con proyectos que ya has estado usando y que te gustan. Contribuir a un proyecto puede ser tan simple como arreglar "typos" o actualizar documentaci&oacute;n.
+Si tu meta es aprender c&oacute;mo contribuir con otros o entender c&oacute;mo funciona el "C&oacute;digo Abierto", considera contribuir en proyectos existentes. Comienza con proyectos que ya has estado usando y que te gustan. Contribuir a un proyecto puede ser tan simple como arreglar "typos" o actualizar documentaci&oacute;n.
 
 Si no sab&eacute;s como comenzar a contribuir, mira esta [Gu&iacute;a sobre c&oacute;mo contribuir](../how-to-contribute/).
 
 ## Lanzando tu propio proyecto de C&oacute;digo Abierto
 
-No hay momento perfecto para abrir el c&oacute;digo de tu trabajo. Puedes abrir el de una idea, el de un trabajo en progreso, o despu&eacute;s de varios a&ntilde;os de ser un proyecto cerrado.
+No hay momento perfecto para abrir el c&oacute;digo de tu trabajo. Puedes abrir el de una idea, el de un trabajo en progreso o despu&eacute;s de varios a&ntilde;os de ser un proyecto cerrado.
 
 Generalmente, puedes abrir el c&oacute;digo de tu proyecto cuando te sientas c&oacute;modo de que otras personas vean y te aconsejen sobre tu trabajo.
 
@@ -124,7 +124,7 @@ Si tu proyecto est&aacute; en GitHub, colocar estos archivos en tu directorio ra
 
 ### Eligiendo una licencia
 
-Una licencia de C&oacute;digo Abierto garantiza que otros puedan usar, copiar, modificar y contribuir en tu proyecto sin problemas. Adem&aacute;s ayuda a protegerte de situaciones legales complejas. **Debes elegir una licencia cuando inicias tu proyecto!**
+Una licencia de C&oacute;digo Abierto garantiza que otros puedan usar, copiar, modificar y contribuir en tu proyecto sin problemas. Adem&aacute;s ayuda a protegerte de situaciones legales complejas. **&iexcl;Debes elegir una licencia cuando inicias tu proyecto!**
 
 El trabajo legal no es divertido. La buena noticia es que puedes copiar y pegar una licencia existente en tu repositorio. Solo llevar&aacute; un minuto proteger tu trabajo.
 
@@ -168,14 +168,14 @@ Cuando incluyes un archivo de este tipo en tu directorio ra&iacute;z, GitHub aut
 Un archivo CONTRIBUTING le da informaci&oacute;n a la audiencia acerca de c&oacute;mo participar en el proyecto, por ejemplo:
 
 * C&oacute;mo archivar un reporte de bug (trata de usar [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
-* C&oacute;mo sugerir una nueva funcionalidad/caracter&iacute;stica.
-* C&oacute;mo establecer tu entorno y correr pruebas.
+* C&oacute;mo sugerir una nueva funcionalidad/caracter&iacute;stica
+* C&oacute;mo establecer tu entorno y correr pruebas
 
 Adem&aacute;s de detalles t&eacute;cnicos, este archivo es una oportunidad para comunicar tus expectativas, como:
 
 * Los tipos de contribuci&oacute;n que esperas
 * Tu visi&oacute;n del proyecto (La hoja de ruta)
-* C&oacute;mo deber&iacute;an comunicarse (o c&oacute;mo no) los contribuyentes contigo.
+* C&oacute;mo deber&iacute;an comunicarse (o c&oacute;mo no) los contribuyentes contigo
 
 Usando un tono c&aacute;lido y amigable, y ofreciendo sugerencias espec&iacute;ficas para contribuciones puede ayudar a los iniciados a sentirse bienvenidos y ansiosos de participar.
 
@@ -226,7 +226,7 @@ Debes elegir un nombre sencillo de recordar y que en lo posible de una idea de l
 
 Si est&aacute;s construyendo sobre un proyecto ya existente, usar su nombre como prefijo suele clarificar lo que el mismo hace (ejemplo: [node-fetch](https://github.com/bitinn/node-fetch) trae `window.fetch` a Node.js).
 
-Considera claridad por sobre todo. Los chismes son divertidos,pero recuerda que algunas bromas pueden no ser traducidas otros idiomas o llevadas a otras culturas, con gente que posee diferentes experiencias a las tuyas. Algunos de tus potenciales usuarios pueden ser empleados de la compa&ntilde;&iacute;a: no debes hacerlos sentir inc&oacute;modos cuando tienen que explicar tu proyecto en el trabajo!
+Considera claridad por sobre todo. Los chismes son divertidos, pero recuerda que algunas bromas pueden no ser traducidas otros idiomas o llevadas a otras culturas, con gente que posee diferentes experiencias a las tuyas. Algunos de tus potenciales usuarios pueden ser empleados de la compa&ntilde;&iacute;a: &iexcl;no debes hacerlos sentir inc&oacute;modos cuando tienen que explicar tu proyecto en el trabajo!
 
 ### Evitando conflictos con los nombres
 
@@ -360,4 +360,4 @@ Si eres una compa&ntilde;&iacute;a u organizaci&oacute;n:
 
 ## &iexcl;Lo has hecho!
 
-Felicitaciones por abrir el c&oacute;digo de tu primer proyecto! Sin importar el devenir, trabajar en p&uacute;blico es un regalo a la comunidad. Con cada commit, comentario y pull request, est&aacute;s creando oportunidades no solo para ti, si no para que otras personas puedan aprender y crecer.
+&iexcl;Felicitaciones por abrir el c&oacute;digo de tu primer proyecto! Sin importar el devenir, trabajar en p&uacute;blico es un regalo a la comunidad. Con cada commit, comentario y pull request, est&aacute;s creando oportunidades no solo para ti, si no para que otras personas puedan aprender y crecer.

From 9ed61455608ca3cd14130d9bc687ace217621367 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 17 Sep 2024 04:14:38 +0000
Subject: [PATCH 718/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.191.0 to 1.192.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/52753b7da854d5c07df37391a986c76ab4615999...a6b46b8a08edb18935835849f2a17072d5cc8c73)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index da2f4d77241..c9d5f6bc577 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -13,7 +13,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@52753b7da854d5c07df37391a986c76ab4615999 # v1
+        uses: ruby/setup-ruby@a6b46b8a08edb18935835849f2a17072d5cc8c73 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From d7537332f0d4a7696491f45cc80a7fe8d5c56ecf Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 18 Sep 2024 04:38:29 +0000
Subject: [PATCH 719/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.192.0 to 1.193.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/a6b46b8a08edb18935835849f2a17072d5cc8c73...f321cf5a4d1533575411f8752cf25b86478b0442)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index c9d5f6bc577..64ef4de1a4e 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -13,7 +13,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@a6b46b8a08edb18935835849f2a17072d5cc8c73 # v1
+        uses: ruby/setup-ruby@f321cf5a4d1533575411f8752cf25b86478b0442 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 284da256139632215efe8d1cc2f18c5d5a4aba04 Mon Sep 17 00:00:00 2001
From: Sudo Arash <ghalbeyou6@gmail.com>
Date: Wed, 18 Sep 2024 16:11:59 +0330
Subject: [PATCH 720/749] Update fa.yml

---
 _data/locales/fa.yml | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/_data/locales/fa.yml b/_data/locales/fa.yml
index 9a17d1650ef..3fa27bc8c5a 100644
--- a/_data/locales/fa.yml
+++ b/_data/locales/fa.yml
@@ -1,30 +1,30 @@
 fa:
   locale_name: Farsi
   nav:
-    about: درباره
+    about: درباره پروژه
     contribute: مشارکت
   index:
-    lead: نرم‌افزار متن باز توسط افرادی مشابه شما ساخته شده است. اینجا می‌توانید راه اندازی و رشد دادن پروژه خود را یاد بگیرید.
-    opensourcefriday: امروز جمعه‌اس! چند ساعت صرف مشارکت در نرم افزاری کن که عاشقش هستی    
+    lead: نرم افزار های متن باز توسط افرادی نظیر شما ساخته شده است. یاد بگیرید چطور پروژه خود را رشد و راه اندازی کنید.
+    opensourcefriday: امروز جمعه است! چند ساعت به پروژه ای که دوست دارید و استفاده می کنید، مشارکت کنید.
   article:
     table_of_contents: فهرست مطالب
-    back_to_all_guides: بازگشت به صفحه اصلی
-    related_guides: راهنماهای مرتبط
+    back_to_all_guides: بازگشت به راهنمای اصلی
+    related_guides: راهنما های مشابه
   footer:
     contribute:
-      heading: مشارکت
-      description: پیشنهاد یا نظری داری؟ این مطلب به صورت متن باز منتشر شد. می‌تونی در بهبودش کمک کنی.
-      button: مشارکت می‌کنم
+      heading: مشارکت کنید
+      description: آیا پیشنهاد یا نظری دارید؟ این مطلب متن باز است. به ما کمک کنید تا بهبودش دهیم.
+      button: مشارکت
     subscribe:
-      heading: در ارتباط باش
-      description: اولین نفر ی باش که در خصوص آخرین نکات و ترفندهای متن باز در گیتهاب باخبر میشه.
+      heading: درارتباط باشید
+      description: اولین نفری باشید که در خصوص آخرین نکات و ترفندهای متن باز در گیتهاب باخبر می شود.
       label: آدرس ایمیل
-      button: شروع اشتراک
+      button: مشترک شوید
     byline:
       # [code], [love], and [github] will be replaced by octicons
       format: "[code] با [love] توسط [github] و [friends]"
       # Label for code octicon
-      code_label: code
+      code_label: کد
       # Label for love octicon
       love_label: عشق
       # Label for the contributors link

From b0cc5b6be363aea6d7a5f786d7e444b587752ebe Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 20 Sep 2024 04:10:16 +0000
Subject: [PATCH 721/749] chore(deps): bump actions/setup-node in the
 dependencies group

Bumps the dependencies group with 1 update: [actions/setup-node](https://github.com/actions/setup-node).


Updates `actions/setup-node` from 4.0.3 to 4.0.4
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/1e60f620b9541d16bece96c5465dc8ee9832be0b...0a44ba7841725637a19e28fa30b79a866c81b0a6)

---
updated-dependencies:
- dependency-name: actions/setup-node
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 64ef4de1a4e..26f4e4204a4 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -17,7 +17,7 @@ jobs:
         with:
           bundler-cache: true
       - name: Set up Node
-        uses: actions/setup-node@1e60f620b9541d16bece96c5465dc8ee9832be0b # v4
+        uses: actions/setup-node@0a44ba7841725637a19e28fa30b79a866c81b0a6 # v4
       - name: Bootstrap
         run: script/bootstrap
         env:

From 26efe93f6f6419411c2cfd3419868a1575d6950b Mon Sep 17 00:00:00 2001
From: Onur Ravli <onur@onurravli.com>
Date: Fri, 20 Sep 2024 10:00:44 +0300
Subject: [PATCH 722/749] docs: fix wrong translation

---
 _articles/tr/best-practices.md | 36 +++++++++++++++++-----------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md
index 5f698d8036a..0608502b0a8 100644
--- a/_articles/tr/best-practices.md
+++ b/_articles/tr/best-practices.md
@@ -6,8 +6,8 @@ class: best-practices
 order: 5
 image: /assets/images/cards/best-practices.png
 related:
-- metrics
-- leadership
+  - metrics
+  - leadership
 ---
 
 ## Geliştirici olmak ne demektir?
@@ -60,10 +60,10 @@ Projenizi yarı zamanlı veya tamamen gönüllü olarak sürdürmekteyseniz, ne
 
 Yazmaya değer birkaç kural:
 
-* Bir katkı nasıl gözden geçirilir ve kabul edilir ( _Testlere ihtiyaçları var mı? Bir sorun şablonu var mı?_ )
-* Kabul edeceğiniz katkı türleri ( _Kodunuzun yalnızca belirli bir bölümünde yardım mı istiyorsunuz?_ )
-* Bekleme süresi ne kadardır (_örneğin, "7 gün içinde bir bakıcıdan bir yanıt bekleyebilirsiniz. O zamana kadar bir şey duymadıysanız, ipliğe ping atmaktan çekinmeyin."_)
-* Projeye ne kadar zaman harcıyorsunuz (_örneğin, "Bu projeye haftada sadece 5 saat harcıyoruz"_)
+- Bir katkı nasıl gözden geçirilir ve kabul edilir ( _Testlere ihtiyaçları var mı? Bir sorun şablonu var mı?_ )
+- Kabul edeceğiniz katkı türleri ( _Kodunuzun yalnızca belirli bir bölümünde yardım mı istiyorsunuz?_ )
+- Bekleme süresi ne kadardır (_örneğin, "7 gün içinde bir bakıcıdan bir yanıt bekleyebilirsiniz. O zamana kadar bir şey duymadıysanız, ipliğe ping atmaktan çekinmeyin."_)
+- Projeye ne kadar zaman harcıyorsunuz (_örneğin, "Bu projeye haftada sadece 5 saat harcıyoruz"_)
 
 [Jekyll](https://github.com/jekyll/jekyll/tree/HEAD/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) ve [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) geliştiriciler ve katkıda bulunanlar için temel kuralları olan projelere birkaç örnektir.
 
@@ -111,12 +111,12 @@ Kabul etmek istemediğinizi bildiğiniz katkıları derhal kapatmak daha iyidir.
 
 Bir katkıyı kabul etmek istemiyorsanız:
 
-* Katkıdan dolayı **teşekkür edin**.
-* **Neden proje kapsamına girmediğini açıklayın** ve mümkünse iyileştirme için net önerilerde bulunun. Nazik ama kararlı olun.
-* Varsa, **ilgili belgelere link verin**. Kabul etmek istemediğiniz şeyler için tekrarlanan istekler fark ederseniz, tekrar etmemek için bunları belgelerinize ekleyin.
-* **İsteği kapatın.**
+- Katkıdan dolayı **teşekkür edin**.
+- **Neden proje kapsamına girmediğini açıklayın** ve mümkünse iyileştirme için net önerilerde bulunun. Nazik ama kararlı olun.
+- Varsa, **ilgili belgelere link verin**. Kabul etmek istemediğiniz şeyler için tekrarlanan istekler fark ederseniz, tekrar etmemek için bunları belgelerinize ekleyin.
+- **İsteği kapatın.**
 
-Cevap vermek için 1-2 cümleden fazlasına ihtiyacınız yoktur. Örneğin, [kerevizin](https://github.com/celery/celery/) kullanıcısı Windows ile ilgili bir hata bildirdiğinde, @berkerpeksag [verdiği cevap](https://github.com/celery/celery/issues/3383):
+Cevap vermek için 1-2 cümleden fazlasına ihtiyacınız yoktur. Örneğin, [Celery](https://github.com/celery/celery/) kullanıcısı Windows ile ilgili bir hata bildirdiğinde, @berkerpeksag [verdiği cevap](https://github.com/celery/celery/issues/3383):
 
 ![Celery screenshot](/assets/images/best-practices/celery.png)
 
@@ -134,8 +134,8 @@ Sonuçta, eğer bir katkı yeterince iyi değilse, kabul etme yükümlülüğün
 
 Çok fazla düşük kaliteli katkı alıyorsanız, katkıda bulunanların önceden biraz çalışma yapmasını isteyin, örneğin:
 
-* Bir sorun veya PR şablonunu veya kontrol listesi doldurma
-* PR göndermeden önce bir sorun açma
+- Bir sorun veya PR şablonunu veya kontrol listesi doldurma
+- PR göndermeden önce bir sorun açma
 
 Kurallarınıza uymuyorlarsa, belgelerinizi referans göstererek sorunu hemen kapatın.
 
@@ -233,11 +233,11 @@ Popüler bir projeyi sürdürmenin iyi haberi, diğer geliştiricilerin de benze
 
 Bakım çalışmalarının bazı yönlerini otomatikleştirmeye yardımcı olacak [çeşitli araçlar vardır](https://github.com/showcases/tools-for-open-source). Birkaç örnek:
 
-* [semantic-release](https://github.com/semantic-release/semantic-release) sürümlerinizi otomatikleştirir
-* [mention-bot](https://github.com/facebook/mention-bot) PR talepleri için potansiyel denetçilerden bahseder
-* [Danger](https://github.com/danger/danger) kod incelemesini otomatikleştirmeye yardımcı olur
-* [no-response](https://github.com/probot/no-response) geliştiricilerin uzun süre yanıt vermediği sorunları kapatır
-* [dependabot](https://github.com/dependabot) bağımlılık dosyalarınızı her gün eski gereksinimler için kontrol eder ve bulduğu her biri için PR istekleri açar
+- [semantic-release](https://github.com/semantic-release/semantic-release) sürümlerinizi otomatikleştirir
+- [mention-bot](https://github.com/facebook/mention-bot) PR talepleri için potansiyel denetçilerden bahseder
+- [Danger](https://github.com/danger/danger) kod incelemesini otomatikleştirmeye yardımcı olur
+- [no-response](https://github.com/probot/no-response) geliştiricilerin uzun süre yanıt vermediği sorunları kapatır
+- [dependabot](https://github.com/dependabot) bağımlılık dosyalarınızı her gün eski gereksinimler için kontrol eder ve bulduğu her biri için PR istekleri açar
 
 Hata raporları ve diğer genel katkılar için GitHub, aldığınız iletişimi kolaylaştırmak için oluşturabileceğiniz [Sorun Şablonlarına ve PR İsteği Şablonlarına](https://github.com/blog/2111-issue-and-pull-request-templates) sahiptir. @TalAter sorununuzu ve PR şablonlarınızı yazmanıza yardımcı olmak için [Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/) rehberini geliştirdi.
 

From 4c07502ad8daa63394cb4cd34a5f7e72a467da99 Mon Sep 17 00:00:00 2001
From: Onur Ravli <onur@onurravli.com>
Date: Fri, 20 Sep 2024 10:02:10 +0300
Subject: [PATCH 723/749] docs: revert formatting

---
 _articles/tr/best-practices.md | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md
index 0608502b0a8..8f25c0418ff 100644
--- a/_articles/tr/best-practices.md
+++ b/_articles/tr/best-practices.md
@@ -6,8 +6,8 @@ class: best-practices
 order: 5
 image: /assets/images/cards/best-practices.png
 related:
-  - metrics
-  - leadership
+- metrics
+- leadership
 ---
 
 ## Geliştirici olmak ne demektir?
@@ -60,10 +60,10 @@ Projenizi yarı zamanlı veya tamamen gönüllü olarak sürdürmekteyseniz, ne
 
 Yazmaya değer birkaç kural:
 
-- Bir katkı nasıl gözden geçirilir ve kabul edilir ( _Testlere ihtiyaçları var mı? Bir sorun şablonu var mı?_ )
-- Kabul edeceğiniz katkı türleri ( _Kodunuzun yalnızca belirli bir bölümünde yardım mı istiyorsunuz?_ )
-- Bekleme süresi ne kadardır (_örneğin, "7 gün içinde bir bakıcıdan bir yanıt bekleyebilirsiniz. O zamana kadar bir şey duymadıysanız, ipliğe ping atmaktan çekinmeyin."_)
-- Projeye ne kadar zaman harcıyorsunuz (_örneğin, "Bu projeye haftada sadece 5 saat harcıyoruz"_)
+* Bir katkı nasıl gözden geçirilir ve kabul edilir ( _Testlere ihtiyaçları var mı? Bir sorun şablonu var mı?_ )
+* Kabul edeceğiniz katkı türleri ( _Kodunuzun yalnızca belirli bir bölümünde yardım mı istiyorsunuz?_ )
+* Bekleme süresi ne kadardır (_örneğin, "7 gün içinde bir bakıcıdan bir yanıt bekleyebilirsiniz. O zamana kadar bir şey duymadıysanız, ipliğe ping atmaktan çekinmeyin."_)
+* Projeye ne kadar zaman harcıyorsunuz (_örneğin, "Bu projeye haftada sadece 5 saat harcıyoruz"_)
 
 [Jekyll](https://github.com/jekyll/jekyll/tree/HEAD/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) ve [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) geliştiriciler ve katkıda bulunanlar için temel kuralları olan projelere birkaç örnektir.
 
@@ -111,10 +111,10 @@ Kabul etmek istemediğinizi bildiğiniz katkıları derhal kapatmak daha iyidir.
 
 Bir katkıyı kabul etmek istemiyorsanız:
 
-- Katkıdan dolayı **teşekkür edin**.
-- **Neden proje kapsamına girmediğini açıklayın** ve mümkünse iyileştirme için net önerilerde bulunun. Nazik ama kararlı olun.
-- Varsa, **ilgili belgelere link verin**. Kabul etmek istemediğiniz şeyler için tekrarlanan istekler fark ederseniz, tekrar etmemek için bunları belgelerinize ekleyin.
-- **İsteği kapatın.**
+* Katkıdan dolayı **teşekkür edin**.
+* **Neden proje kapsamına girmediğini açıklayın** ve mümkünse iyileştirme için net önerilerde bulunun. Nazik ama kararlı olun.
+* Varsa, **ilgili belgelere link verin**. Kabul etmek istemediğiniz şeyler için tekrarlanan istekler fark ederseniz, tekrar etmemek için bunları belgelerinize ekleyin.
+* **İsteği kapatın.**
 
 Cevap vermek için 1-2 cümleden fazlasına ihtiyacınız yoktur. Örneğin, [Celery](https://github.com/celery/celery/) kullanıcısı Windows ile ilgili bir hata bildirdiğinde, @berkerpeksag [verdiği cevap](https://github.com/celery/celery/issues/3383):
 
@@ -134,8 +134,8 @@ Sonuçta, eğer bir katkı yeterince iyi değilse, kabul etme yükümlülüğün
 
 Çok fazla düşük kaliteli katkı alıyorsanız, katkıda bulunanların önceden biraz çalışma yapmasını isteyin, örneğin:
 
-- Bir sorun veya PR şablonunu veya kontrol listesi doldurma
-- PR göndermeden önce bir sorun açma
+* Bir sorun veya PR şablonunu veya kontrol listesi doldurma
+* PR göndermeden önce bir sorun açma
 
 Kurallarınıza uymuyorlarsa, belgelerinizi referans göstererek sorunu hemen kapatın.
 
@@ -233,11 +233,11 @@ Popüler bir projeyi sürdürmenin iyi haberi, diğer geliştiricilerin de benze
 
 Bakım çalışmalarının bazı yönlerini otomatikleştirmeye yardımcı olacak [çeşitli araçlar vardır](https://github.com/showcases/tools-for-open-source). Birkaç örnek:
 
-- [semantic-release](https://github.com/semantic-release/semantic-release) sürümlerinizi otomatikleştirir
-- [mention-bot](https://github.com/facebook/mention-bot) PR talepleri için potansiyel denetçilerden bahseder
-- [Danger](https://github.com/danger/danger) kod incelemesini otomatikleştirmeye yardımcı olur
-- [no-response](https://github.com/probot/no-response) geliştiricilerin uzun süre yanıt vermediği sorunları kapatır
-- [dependabot](https://github.com/dependabot) bağımlılık dosyalarınızı her gün eski gereksinimler için kontrol eder ve bulduğu her biri için PR istekleri açar
+* [semantic-release](https://github.com/semantic-release/semantic-release) sürümlerinizi otomatikleştirir
+* [mention-bot](https://github.com/facebook/mention-bot) PR talepleri için potansiyel denetçilerden bahseder
+* [Danger](https://github.com/danger/danger) kod incelemesini otomatikleştirmeye yardımcı olur
+* [no-response](https://github.com/probot/no-response) geliştiricilerin uzun süre yanıt vermediği sorunları kapatır
+* [dependabot](https://github.com/dependabot) bağımlılık dosyalarınızı her gün eski gereksinimler için kontrol eder ve bulduğu her biri için PR istekleri açar
 
 Hata raporları ve diğer genel katkılar için GitHub, aldığınız iletişimi kolaylaştırmak için oluşturabileceğiniz [Sorun Şablonlarına ve PR İsteği Şablonlarına](https://github.com/blog/2111-issue-and-pull-request-templates) sahiptir. @TalAter sorununuzu ve PR şablonlarınızı yazmanıza yardımcı olmak için [Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/) rehberini geliştirdi.
 

From ea1324e98fcdc06ff1df1c3384720382a78a74d1 Mon Sep 17 00:00:00 2001
From: Onur Ravli <onur@onurravli.com>
Date: Fri, 20 Sep 2024 10:09:57 +0300
Subject: [PATCH 724/749] docs: start turkish translation for
 maintaining-balance-for-open-source-maintainers

---
 .../tr/maintaining-balance-for-open-source-maintainers.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/_articles/tr/maintaining-balance-for-open-source-maintainers.md b/_articles/tr/maintaining-balance-for-open-source-maintainers.md
index 1ac42c3058c..bad85e2995e 100644
--- a/_articles/tr/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/tr/maintaining-balance-for-open-source-maintainers.md
@@ -1,16 +1,16 @@
 ---
 lang: tr
 untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+title: Açık Kaynak Geliştiricileri için Dengeyi Korumak
+description: Bir açık kaynak geliştiricisi olarak öz bakım ve tükenmişlikten kaçınmak için ipuçları.
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+Açık kaynaklı bir projenin popülaritesi arttıkça, uzun vadede yenilenmiş ve üretken kalmak için dengeyi korumanıza yardımcı olacak net sınırlar belirlemek önemli hale gelir. 
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+Bakımcıların deneyimleri ve dengeyi bulma stratejileri hakkında bilgi edinmek için <a href=“http://maintainers.github.com/”>Bakımcı Topluluğu</a>'nun 40 üyesiyle bir atölye çalışması gerçekleştirdik ve açık kaynakta tükenmişlikle ilgili ilk elden deneyimlerini ve işlerinde dengeyi korumalarına yardımcı olan uygulamaları öğrenmemizi sağladık. Kişisel ekoloji kavramı burada devreye giriyor.
 
 So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
 

From 108d3e541535080643b02c6c1a6876046f04b43d Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 26 Sep 2024 04:30:27 +0000
Subject: [PATCH 725/749] chore(deps): bump the dependencies group with 2
 updates

Bumps the dependencies group with 2 updates: [actions/checkout](https://github.com/actions/checkout) and [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `actions/checkout` from 4.1.7 to 4.2.0
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/692973e3d937129bcbf40652eb9f2f61becf3332...d632683dd7b4114ad314bca15554477dd762a938)

Updates `ruby/setup-ruby` from 1.193.0 to 1.194.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/f321cf5a4d1533575411f8752cf25b86478b0442...c04af2bb7258bb6a03df1d3c1865998ac9390972)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/jekyll-preview.yml | 2 +-
 .github/workflows/jekyll.yml         | 2 +-
 .github/workflows/tests.yml          | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index 164427f6426..44727364115 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -28,7 +28,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
+        uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938 # v4
         with:
           # For PRs make sure to checkout the PR branch
           ref: ${{ github.event.pull_request.head.ref }}
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index fd37751763c..123b7166ebf 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -27,7 +27,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
+        uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938 # v4
       - name: Setup Pages
         uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5
       - name: Build with Jekyll
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 26f4e4204a4..0b0cb46efd4 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,9 +11,9 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Git repository
-        uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
+        uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@f321cf5a4d1533575411f8752cf25b86478b0442 # v1
+        uses: ruby/setup-ruby@c04af2bb7258bb6a03df1d3c1865998ac9390972 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From b14fd8c161486a66f2acbe897c733c87e9881d74 Mon Sep 17 00:00:00 2001
From: Terence Eden <edent@users.noreply.github.com>
Date: Tue, 1 Oct 2024 10:44:18 +0100
Subject: [PATCH 726/749] Remove invalid media query

The value `no-preference` was never implemented by any browser and has been removed from the specification.

See https://www.w3.org/TR/mediaqueries-5/#prefers-color-scheme and https://github.com/w3c/csswg-drafts/issues/3857#issuecomment-634779976
---
 _includes/head.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_includes/head.html b/_includes/head.html
index 74084a42cd3..fbba27e5ef2 100644
--- a/_includes/head.html
+++ b/_includes/head.html
@@ -2,7 +2,7 @@
   <meta charset="utf-8">
   <meta name="viewport" content="width=device-width, initial-scale=1">
   <meta name="google-site-verification" content="c1kuD-K2HIVF635lypcsWPoD4kilo5-jA_wBFyT4uMY" />
-  <link rel="icon" type="image/x-icon" href="https://github.githubassets.com/favicon.ico" media="(prefers-color-scheme:no-preference)">
+  <link rel="icon" type="image/x-icon" href="https://github.githubassets.com/favicon.ico">
   <link rel="icon" type="image/png" href="https://github.githubassets.com/favicons/favicon.png" media="(prefers-color-scheme:light)">
   <link rel="icon" type="image/png" href="https://github.githubassets.com/favicons/favicon-dark.png" media="(prefers-color-scheme:dark)">
   <link href="https://fonts.googleapis.com/css?family=Roboto:300,300i,400,400i,700,700i" rel="stylesheet">

From 49333ed7e80cbc89b476663cee9e80b9cc4a9e8c Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 7 Oct 2024 04:39:06 +0000
Subject: [PATCH 727/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.194.0 to 1.195.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/c04af2bb7258bb6a03df1d3c1865998ac9390972...086ffb1a2090c870a3f881cc91ea83aa4243d408)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 0b0cb46efd4..07e1ca7b364 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -13,7 +13,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@c04af2bb7258bb6a03df1d3c1865998ac9390972 # v1
+        uses: ruby/setup-ruby@086ffb1a2090c870a3f881cc91ea83aa4243d408 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From acb7366cfb02659e18e9da52a32f9873bc471445 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 8 Oct 2024 04:35:11 +0000
Subject: [PATCH 728/749] chore(deps): bump the dependencies group with 2
 updates

Bumps the dependencies group with 2 updates: [actions/checkout](https://github.com/actions/checkout) and [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `actions/checkout` from 4.2.0 to 4.2.1
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/d632683dd7b4114ad314bca15554477dd762a938...eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871)

Updates `ruby/setup-ruby` from 1.195.0 to 1.196.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/086ffb1a2090c870a3f881cc91ea83aa4243d408...f26937343756480a8cb3ae1f623b9c8d89ed6984)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dependencies
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/jekyll-preview.yml | 2 +-
 .github/workflows/jekyll.yml         | 2 +-
 .github/workflows/tests.yml          | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index 44727364115..e9173b89f82 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -28,7 +28,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938 # v4
+        uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 # v4
         with:
           # For PRs make sure to checkout the PR branch
           ref: ${{ github.event.pull_request.head.ref }}
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index 123b7166ebf..6a0e0063a5d 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -27,7 +27,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938 # v4
+        uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 # v4
       - name: Setup Pages
         uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5
       - name: Build with Jekyll
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 07e1ca7b364..642f9a71835 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,9 +11,9 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Git repository
-        uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938 # v4
+        uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@086ffb1a2090c870a3f881cc91ea83aa4243d408 # v1
+        uses: ruby/setup-ruby@f26937343756480a8cb3ae1f623b9c8d89ed6984 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 79c318cd006c88f7f777f8d973e7ff259a2029df Mon Sep 17 00:00:00 2001
From: Kpoti Ametepe <patrickametepe@outlook.com>
Date: Tue, 8 Oct 2024 22:48:36 +0000
Subject: [PATCH 729/749] Update
 maintaining-balance-for-open-source-maintainers.md

Translate to French
---
 ...ing-balance-for-open-source-maintainers.md | 117 ++++++++++--------
 1 file changed, 62 insertions(+), 55 deletions(-)

diff --git a/_articles/fr/maintaining-balance-for-open-source-maintainers.md b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
index 766c23f7e20..824cc178841 100644
--- a/_articles/fr/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
@@ -8,163 +8,170 @@ order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+Au fure et a mesure qu'un projet open source gagne en popularité, il devient important de fixer des limites claires pour vous aider à maintenir l'équilibre afin de rester frais et productif à long terme. 
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+Afin de mieux comprendre les expériences des mainteneurs et leurs stratégies pour trouver un équilibre, nous avons organisé un atelier avec 40 membres de la <a href="http://maintainers.github.com/">communauté des mainteneurs</a>, ce qui nous a permis d'apprendre de leurs expériences directes de l'épuisement professionnel dans l'open source et des pratiques qui les ont aidés à maintenir l'équilibre dans leur travail. C'est là que le concept d'écologie personnelle entre en jeu.
+
+Alors, qu'est-ce que l'écologie personnelle ? Comme <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">le décrit le Rockwood Leadership Institute</a>, il s'agit de « maintenir l'équilibre, le rythme et l'efficacité pour soutenir notre énergie tout au long de la vie ». Cela a encadré nos conversations, en aidant les responsables à reconnaître que leurs actions et leurs contributions font partie d'un écosystème plus large qui évolue au fil du temps. L'épuisement professionnel, un syndrome résultant d'un stress chronique sur le lieu de travail [tel que défini par l'OMS](https://icd.who.int/browse/2024-01/mms/fr#129180281), n'est pas rare chez les responsables de la maintenance. Il se traduit souvent par une perte de motivation, une incapacité à se concentrer et un manque d'empathie à l'égard des contributeurs et de la communauté avec laquelle vous travaillez.
 
-So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
-  I was unable to focus or start on a task. I had a lack of empathy for users.
+  J'étais incapable de me concentrer ou de commencer une tâche. Je manquais d'empathie pour les utilisateurs.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, mainteneur du serveur de streaming en direct Owncast, à propos de l'impact de l'épuisement professionnel sur son travail dans le domaine de l'open source.
   </p>
 </aside>
 
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
 
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+En adoptant le concept d'écologie personnelle, les responsables de la maintenance peuvent éviter de manière proactive l'épuisement professionnel, donner la priorité aux soins personnels et maintenir un sens de l'équilibre afin de faire leur meilleur travail.
+
+
 
-### Identify your motivations for working in open source
+## Astuces pour prendre soin de soi et éviter l'épuisement en tant que responsable de maintenance :
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+### Identifier vos motivations pour travailler dans l'open source
 
-### Reflect on what causes you to get out of balance and stressed out
+Prenez le temps de réfléchir aux aspects de la maintenance des logiciels libres qui vous stimulent. Comprendre vos motivations peut vous aider à prioriser le travail de manière à rester engagé et prêt à relever de nouveaux défis. Qu'il s'agisse des réactions positives des utilisateurs, de la joie de collaborer et de socialiser avec la communauté ou de la satisfaction de se plonger dans le code, le fait de reconnaître vos motivations peut vous aider à vous concentrer.
 
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+### Réfléchissez à ce qui vous déséquilibre et vous stresse.
 
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+Il est important de comprendre les causes de l'épuisement professionnel. Voici quelques thèmes communs aux mainteneurs de logiciels libres :
+
+* **Absence de retours positifs:** Les utilisateurs sont beaucoup plus enclins à se manifester lorsqu'ils ont une plainte à formuler. Si tout fonctionne parfaitement, ils ont tendance à rester silencieux. Il peut être décourageant de voir la liste des problèmes s'allonger sans que les commentaires positifs montrent que votre contribution fait la différence.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
-  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  Parfois, j'ai l'impression de crier dans le vide et je trouve que le retour d'information me donne beaucoup d'énergie. Nous avons beaucoup d'utilisateurs heureux mais silencieux.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+— <a href="https://github.com/thisisnic">@thisisnic</a>, mainteneur d'Apache Arrow
   </p>
 </aside>
 
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **Ne pas dire « non »:** Il peut être facile de prendre plus de responsabilités qu'on ne le devrait sur un projet open source. Que ce soit de la part des utilisateurs, des contributeurs ou d'autres mainteneurs, nous ne pouvons pas toujours répondre à leurs attentes.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
-  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+ Je me suis rendu compte que j'assumais plus qu'il ne fallait et que je devais faire le travail de plusieurs personnes, comme c'est souvent le cas dans les logiciels libres.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, mainteneur de Termux, sur les causes de l'épuisement au travail
   </p>
 </aside>
 
-* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+* **Travailler en solitaire :** Être un mainteneur peut être incroyablement solitaire. Même si vous travaillez avec un groupe de mainteneurs, les dernières années ont été difficiles pour réunir des équipes dispersées en personne.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
- Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+ Surtout depuis COVID et le travail à domicile, il est plus difficile de ne voir personne et de ne parler à personne.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, mainteneur du serveur de streaming en direct Owncast, à propos de l'impact de l'épuisement professionnel sur son travail dans le domaine de l'open source.
   </p>
 </aside>
 
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **Manque de temps et de ressources :** C'est particulièrement vrai pour les mainteneurs bénévoles qui doivent sacrifier leur temps libre pour travailler sur un projet.
 
 <aside markdown="1" class="pquote">
-  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  [J'aimerais avoir]  plus de soutien financier, afin que je puisse me concentrer sur le travail de l'open source sans brûler mes économies et en sachant que je devrai faire beaucoup de contrats pour me rattraper plus tard.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— Un Mainteneur Open Source
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Demandes contradictoires :**  L'open source est un ensemble de groupes aux motivations diverses, dans lequel il peut être difficile de s'y retrouver. Si vous êtes payé pour faire de l'open source, les intérêts de votre employeur peuvent parfois être en contradiction avec ceux de la communauté.
 
+  
 <aside markdown="1" class="pquote">
-  With paid open source, conflict between employer's focus and what's best for the community
+   Dans le cas des logiciels libres payants, il existe un conflit entre l'objectif de l'employeur et ce qui est le mieux pour la communauté.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— Un Mainteneur Open Source
   </p>
 </aside>
 
-### Watch out for signs of burnout
+### Faites attention aux signes d'épuisement professionnel
+
+Pouvez-vous maintenir votre rythme pendant 10 semaines ? 10 mois ? 10 ans ?
 
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+Il existe des outils comme la [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) qui peuvent vous aider à réfléchir à votre rythme actuel et à voir s'il y a des ajustements à faire. Certains mainteneurs utilisent également une technologie portable pour suivre des paramètres tels que la qualité du sommeil et la variabilité du rythme cardiaque (tous deux liés au stress).
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
 
 <aside markdown="1" class="pquote">
- I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+ Je suis un fervent partisan des outils portables de qualité. Grâce à la science, vous pouvez comprendre comment vous auriez pu faire mieux et comment atteindre un état optimal de ce que vous voulez faire.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— Un Mainteneur Open Source
   </p>
 </aside>
 
-### What would you need to continue sustaining yourself and your community?
+### De quoi auriez-vous besoin pour continuer à subvenir à vos besoins et à ceux de votre communauté ?
 
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+Cela sera différent pour chaque responsable, et changera en fonction de votre phase de vie et d'autres facteurs externes. Mais voici quelques thèmes que nous avons entendus :
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **Appuyez-vous sur la communauté:**  La délégation et la recherche de collaborateurs peuvent alléger la charge de travail. Le fait d'avoir plusieurs points de contact pour un projet peut vous aider à faire une pause sans vous inquiéter. Entrez en contact avec d'autres mainteneurs et la communauté au sens large, dans des groupes tels que la [Communauté des mainteneurs] (http://maintainers.github.com/). Il peut s'agir d'une excellente ressource pour l'entraide et l'apprentissage.
 
-  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+  Vous pouvez également chercher des moyens de vous engager auprès de la communauté des utilisateurs, afin d'obtenir régulièrement des informations en retour et de comprendre l'impact de votre travail sur les logiciels libres.
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **Explorer le financement :** Que vous soyez à la recherche d'un peu d'argent pour une pizza ou que vous essayiez de vous lancer à plein temps dans l'open source, il existe de nombreuses ressources pour vous aider ! Dans un premier temps, pensez à activer [GitHub Sponsors] (https://github.com/sponsors) pour permettre à d'autres de sponsoriser votre travail open source. Si vous envisagez de passer à temps plein, postulez pour le prochain cycle de l'[Accélérateur GitHub] (http://accelerator.github.com/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
- I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+ Il y a quelque temps, j'ai participé à un podcast et nous avons discuté de la maintenance et de la durabilité des logiciels libres. J'ai constaté que même un petit nombre de personnes soutenant mon travail sur GitHub m'a aidé à prendre la décision rapide de ne pas m'asseoir devant un jeu, mais plutôt de faire une petite chose avec l'open source.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+— <a href="https://github.com/mansona">@mansona</a>, maintainer de EmberJS
   </p>
 </aside>
 
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+* **Utilisez les outils:** Profitez d'outils tels que [GitHub Copilot] (https://github.com/features/copilot/) et [GitHub Actions] (https://github.com/features/actions) pour automatiser les tâches banales et libérer votre temps pour des contributions plus significatives.
 
 <aside markdown="1" class="pquote">
- Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+ Utilisez [Copilot](https://github.com/features/copilot/) pour les choses ennuyeuses - faites les choses amusantes.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— Un Mainteneur Open Source
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+* **Se reposer et se ressourcer :** Consacrez du temps à vos loisirs et à vos centres d'intérêt en dehors de l'open source. Prenez vos week-ends pour vous détendre et vous ressourcer, et réglez votre [statut GitHub] (https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) pour qu'il reflète votre disponibilité ! Une bonne nuit de sommeil peut faire une grande différence dans votre capacité à soutenir vos efforts à long terme.
 
-  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
 
+  Si certains aspects de votre projet vous plaisent particulièrement, essayez de structurer votre travail de manière à en faire l'expérience tout au long de la journée.
+  
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+ Je trouve davantage d'occasions de ménager des « moments de créativité » au milieu de la journée plutôt que d'essayer de me déconnecter le soir.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+— <a href="https://github.com/danielroe">@danielroe</a>, maintaineur de Nuxt
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **Definir des limites :** Vous ne pouvez pas dire oui à toutes les demandes. Cela peut être aussi simple que de dire « Je ne peux pas le faire maintenant et je n'ai pas l'intention de le faire à l'avenir », ou d'énumérer ce que vous souhaitez faire et ne pas faire dans le fichier README. Par exemple, vous pourriez dire : « Je ne fusionne que les PR dont les raisons sont clairement listées » ou “Je n'examine les problèmes qu'un jeudi sur deux, de 18 à 19 heures”. Cela définit les attentes des autres et vous donne un point de repère à d'autres moments pour aider à désamorcer les demandes de contributeurs ou d'utilisateurs sur votre temps.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+Pour faire confiance aux autres sur ces axes, vous ne pouvez pas être quelqu'un qui dit oui à toutes les demandes. Ce faisant, vous ne respectez aucune limite, ni sur le plan professionnel ni sur le plan personnel, et vous ne serez pas un collègue fiable.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, mainteneur de Homebrew sur [Saying No] (https://mikemcquaid.com/saying-no/)
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+  Apprenez à faire preuve de fermeté pour mettre fin aux comportements toxiques et aux interactions négatives. Il est normal de ne pas donner d'énergie à des choses qui ne vous intéressent pas.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-My software is gratis, but my time and attention is not.
+Mon logiciel est gratuit, mais mon temps et mon attention ne le sont pas.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintaineur de Leaflet
   </p>
 </aside>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+Ce n'est un secret pour personne que la maintenance des logiciels libres a ses côtés sombres, et l'un d'entre eux est d'avoir parfois à interagir avec des personnes assez ingrates, qui ont le droit d'agir ou qui sont carrément toxiques. À mesure que la popularité d'un projet augmente, la fréquence de ce type d'interaction s'accroît, ce qui alourdit le fardeau des mainteneurs et peut devenir un facteur de risque important pour l'épuisement des mainteneurs.  
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>, mainteneur de Octoprint sur [Comment gérer les personnes toxiques](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
 </aside>
 
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+N'oubliez pas que l'écologie personnelle est une pratique permanente qui évoluera au fur et à mesure que vous progresserez dans votre voyage vers l'open source. En accordant la priorité à la prise en charge de soi et au maintien d'un équilibre, vous pouvez contribuer à la communauté open source de manière efficace et durable, en assurant à la fois votre bien-être et le succès de vos projets sur le long terme.
 
-## Additional Resources
+## Ressources complémentaires
 
 * [Maintainer Community](http://maintainers.github.com/)
 * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon

From 5c4384a2ccdcaa05150577539c577f8f3970f70c Mon Sep 17 00:00:00 2001
From: Kpoti Ametepe <patrickametepe@outlook.com>
Date: Tue, 8 Oct 2024 22:58:38 +0000
Subject: [PATCH 730/749] Update
 maintaining-balance-for-open-source-maintainers.md

Remove blank line
---
 .../fr/maintaining-balance-for-open-source-maintainers.md  | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/_articles/fr/maintaining-balance-for-open-source-maintainers.md b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
index 824cc178841..17ea66c87b2 100644
--- a/_articles/fr/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
@@ -14,7 +14,6 @@ Afin de mieux comprendre les expériences des mainteneurs et leurs stratégies p
 
 Alors, qu'est-ce que l'écologie personnelle ? Comme <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">le décrit le Rockwood Leadership Institute</a>, il s'agit de « maintenir l'équilibre, le rythme et l'efficacité pour soutenir notre énergie tout au long de la vie ». Cela a encadré nos conversations, en aidant les responsables à reconnaître que leurs actions et leurs contributions font partie d'un écosystème plus large qui évolue au fil du temps. L'épuisement professionnel, un syndrome résultant d'un stress chronique sur le lieu de travail [tel que défini par l'OMS](https://icd.who.int/browse/2024-01/mms/fr#129180281), n'est pas rare chez les responsables de la maintenance. Il se traduit souvent par une perte de motivation, une incapacité à se concentrer et un manque d'empathie à l'égard des contributeurs et de la communauté avec laquelle vous travaillez.
 
-
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
   J'étais incapable de me concentrer ou de commencer une tâche. Je manquais d'empathie pour les utilisateurs.
@@ -23,11 +22,8 @@ Alors, qu'est-ce que l'écologie personnelle ? Comme <a href="https://rockwoodle
   </p>
 </aside>
 
-
 En adoptant le concept d'écologie personnelle, les responsables de la maintenance peuvent éviter de manière proactive l'épuisement professionnel, donner la priorité aux soins personnels et maintenir un sens de l'équilibre afin de faire leur meilleur travail.
 
-
-
 ## Astuces pour prendre soin de soi et éviter l'épuisement en tant que responsable de maintenance :
 
 ### Identifier vos motivations pour travailler dans l'open source
@@ -78,7 +74,6 @@ Il est important de comprendre les causes de l'épuisement professionnel. Voici
 </aside>
 
 * **Demandes contradictoires :**  L'open source est un ensemble de groupes aux motivations diverses, dans lequel il peut être difficile de s'y retrouver. Si vous êtes payé pour faire de l'open source, les intérêts de votre employeur peuvent parfois être en contradiction avec ceux de la communauté.
-
   
 <aside markdown="1" class="pquote">
    Dans le cas des logiciels libres payants, il existe un conflit entre l'objectif de l'employeur et ce qui est le mieux pour la communauté.
@@ -93,7 +88,6 @@ Pouvez-vous maintenir votre rythme pendant 10 semaines ? 10 mois ? 10 ans ?
 
 Il existe des outils comme la [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) qui peuvent vous aider à réfléchir à votre rythme actuel et à voir s'il y a des ajustements à faire. Certains mainteneurs utilisent également une technologie portable pour suivre des paramètres tels que la qualité du sommeil et la variabilité du rythme cardiaque (tous deux liés au stress).
 
-
 <aside markdown="1" class="pquote">
  Je suis un fervent partisan des outils portables de qualité. Grâce à la science, vous pouvez comprendre comment vous auriez pu faire mieux et comment atteindre un état optimal de ce que vous voulez faire.
   <p markdown="1" class="pquote-credit">
@@ -130,7 +124,6 @@ Cela sera différent pour chaque responsable, et changera en fonction de votre p
 
 * **Se reposer et se ressourcer :** Consacrez du temps à vos loisirs et à vos centres d'intérêt en dehors de l'open source. Prenez vos week-ends pour vous détendre et vous ressourcer, et réglez votre [statut GitHub] (https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) pour qu'il reflète votre disponibilité ! Une bonne nuit de sommeil peut faire une grande différence dans votre capacité à soutenir vos efforts à long terme.
 
-
   Si certains aspects de votre projet vous plaisent particulièrement, essayez de structurer votre travail de manière à en faire l'expérience tout au long de la journée.
   
 <aside markdown="1" class="pquote">

From 45ef9f0e04528046b7af679441c85bb705b63ee0 Mon Sep 17 00:00:00 2001
From: Kpoti Ametepe <patrickametepe@outlook.com>
Date: Tue, 8 Oct 2024 23:05:12 +0000
Subject: [PATCH 731/749] Update
 maintaining-balance-for-open-source-maintainers.md

Fix bugs
---
 .../fr/maintaining-balance-for-open-source-maintainers.md     | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/_articles/fr/maintaining-balance-for-open-source-maintainers.md b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
index 17ea66c87b2..353d2889d3c 100644
--- a/_articles/fr/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
@@ -74,6 +74,7 @@ Il est important de comprendre les causes de l'épuisement professionnel. Voici
 </aside>
 
 * **Demandes contradictoires :**  L'open source est un ensemble de groupes aux motivations diverses, dans lequel il peut être difficile de s'y retrouver. Si vous êtes payé pour faire de l'open source, les intérêts de votre employeur peuvent parfois être en contradiction avec ceux de la communauté.
+
   
 <aside markdown="1" class="pquote">
    Dans le cas des logiciels libres payants, il existe un conflit entre l'objectif de l'employeur et ce qui est le mieux pour la communauté.
@@ -125,6 +126,7 @@ Cela sera différent pour chaque responsable, et changera en fonction de votre p
 * **Se reposer et se ressourcer :** Consacrez du temps à vos loisirs et à vos centres d'intérêt en dehors de l'open source. Prenez vos week-ends pour vous détendre et vous ressourcer, et réglez votre [statut GitHub] (https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) pour qu'il reflète votre disponibilité ! Une bonne nuit de sommeil peut faire une grande différence dans votre capacité à soutenir vos efforts à long terme.
 
   Si certains aspects de votre projet vous plaisent particulièrement, essayez de structurer votre travail de manière à en faire l'expérience tout au long de la journée.
+
   
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
@@ -134,7 +136,7 @@ Cela sera différent pour chaque responsable, et changera en fonction de votre p
   </p>
 </aside>
 
-* **Definir des limites :** Vous ne pouvez pas dire oui à toutes les demandes. Cela peut être aussi simple que de dire « Je ne peux pas le faire maintenant et je n'ai pas l'intention de le faire à l'avenir », ou d'énumérer ce que vous souhaitez faire et ne pas faire dans le fichier README. Par exemple, vous pourriez dire : « Je ne fusionne que les PR dont les raisons sont clairement listées » ou “Je n'examine les problèmes qu'un jeudi sur deux, de 18 à 19 heures”. Cela définit les attentes des autres et vous donne un point de repère à d'autres moments pour aider à désamorcer les demandes de contributeurs ou d'utilisateurs sur votre temps.
+* **Definir des limites :** Vous ne pouvez pas dire oui à toutes les demandes. Cela peut être aussi simple que de dire « Je ne peux pas le faire maintenant et je n'ai pas l'intention de le faire à l'avenir », ou d'énumérer ce que vous souhaitez faire et ne pas faire dans le fichier README. Par exemple, vous pourriez dire : « Je ne fusionne que les PR dont les raisons sont clairement listées » ou "Je n'examine les problèmes qu'un jeudi sur deux, de 18 à 19 heures". Cela définit les attentes des autres et vous donne un point de repère à d'autres moments pour aider à désamorcer les demandes de contributeurs ou d'utilisateurs sur votre temps.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">

From 488c04ec1caa7aef0edffd19c2ded16ea9fed6ce Mon Sep 17 00:00:00 2001
From: Kpoti Ametepe <patrickametepe@outlook.com>
Date: Tue, 8 Oct 2024 23:22:04 +0000
Subject: [PATCH 732/749] Update
 maintaining-balance-for-open-source-maintainers.md

---
 ...aining-balance-for-open-source-maintainers.md | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/_articles/fr/maintaining-balance-for-open-source-maintainers.md b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
index 353d2889d3c..c508d41087f 100644
--- a/_articles/fr/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
@@ -74,10 +74,10 @@ Il est important de comprendre les causes de l'épuisement professionnel. Voici
 </aside>
 
 * **Demandes contradictoires :**  L'open source est un ensemble de groupes aux motivations diverses, dans lequel il peut être difficile de s'y retrouver. Si vous êtes payé pour faire de l'open source, les intérêts de votre employeur peuvent parfois être en contradiction avec ceux de la communauté.
-
   
 <aside markdown="1" class="pquote">
    Dans le cas des logiciels libres payants, il existe un conflit entre l'objectif de l'employeur et ce qui est le mieux pour la communauté.
+  
   <p markdown="1" class="pquote-credit">
 — Un Mainteneur Open Source
   </p>
@@ -91,6 +91,7 @@ Il existe des outils comme la [Burnout Checklist](https://governingopen.com/reso
 
 <aside markdown="1" class="pquote">
  Je suis un fervent partisan des outils portables de qualité. Grâce à la science, vous pouvez comprendre comment vous auriez pu faire mieux et comment atteindre un état optimal de ce que vous voulez faire.
+  
   <p markdown="1" class="pquote-credit">
 — Un Mainteneur Open Source
   </p>
@@ -118,19 +119,19 @@ Cela sera différent pour chaque responsable, et changera en fonction de votre p
 
 <aside markdown="1" class="pquote">
  Utilisez [Copilot](https://github.com/features/copilot/) pour les choses ennuyeuses - faites les choses amusantes.
+  
   <p markdown="1" class="pquote-credit">
 — Un Mainteneur Open Source
   </p>
 </aside>
 
 * **Se reposer et se ressourcer :** Consacrez du temps à vos loisirs et à vos centres d'intérêt en dehors de l'open source. Prenez vos week-ends pour vous détendre et vous ressourcer, et réglez votre [statut GitHub] (https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) pour qu'il reflète votre disponibilité ! Une bonne nuit de sommeil peut faire une grande différence dans votre capacité à soutenir vos efforts à long terme.
+Si certains aspects de votre projet vous plaisent particulièrement, essayez de structurer votre travail de manière à en faire l'expérience tout au long de la journée.
 
-  Si certains aspects de votre projet vous plaisent particulièrement, essayez de structurer votre travail de manière à en faire l'expérience tout au long de la journée.
-
-  
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- Je trouve davantage d'occasions de ménager des « moments de créativité » au milieu de la journée plutôt que d'essayer de me déconnecter le soir.
+   Je trouve davantage d'occasions de ménager des « moments de créativité » au milieu de la journée plutôt que d'essayer de me déconnecter le soir.
+  
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/danielroe">@danielroe</a>, maintaineur de Nuxt
   </p>
@@ -141,6 +142,7 @@ Cela sera différent pour chaque responsable, et changera en fonction de votre p
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
 Pour faire confiance aux autres sur ces axes, vous ne pouvez pas être quelqu'un qui dit oui à toutes les demandes. Ce faisant, vous ne respectez aucune limite, ni sur le plan professionnel ni sur le plan personnel, et vous ne serez pas un collègue fiable.
+  
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, mainteneur de Homebrew sur [Saying No] (https://mikemcquaid.com/saying-no/)
   </p>
@@ -151,6 +153,7 @@ Pour faire confiance aux autres sur ces axes, vous ne pouvez pas être quelqu'un
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
 Mon logiciel est gratuit, mais mon temps et mon attention ne le sont pas.
+  
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintaineur de Leaflet
   </p>
@@ -158,7 +161,8 @@ Mon logiciel est gratuit, mais mon temps et mon attention ne le sont pas.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-Ce n'est un secret pour personne que la maintenance des logiciels libres a ses côtés sombres, et l'un d'entre eux est d'avoir parfois à interagir avec des personnes assez ingrates, qui ont le droit d'agir ou qui sont carrément toxiques. À mesure que la popularité d'un projet augmente, la fréquence de ce type d'interaction s'accroît, ce qui alourdit le fardeau des mainteneurs et peut devenir un facteur de risque important pour l'épuisement des mainteneurs.  
+Ce n'est un secret pour personne que la maintenance des logiciels libres a ses côtés sombres, et l'un d'entre eux est d'avoir parfois à interagir avec des personnes assez ingrates, qui ont le droit d'agir ou qui sont carrément toxiques. À mesure que la popularité d'un projet augmente, la fréquence de ce type d'interaction s'accroît, ce qui alourdit le fardeau des mainteneurs et peut devenir un facteur de risque important pour l'épuisement des mainteneurs.
+  
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/foosel">@foosel</a>, mainteneur de Octoprint sur [Comment gérer les personnes toxiques](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>

From 8a27f934005af294602ab35f90234cd693ea8f64 Mon Sep 17 00:00:00 2001
From: Kpoti Ametepe <patrickametepe@outlook.com>
Date: Tue, 8 Oct 2024 23:25:17 +0000
Subject: [PATCH 733/749] Update
 maintaining-balance-for-open-source-maintainers.md

---
 _articles/fr/maintaining-balance-for-open-source-maintainers.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/_articles/fr/maintaining-balance-for-open-source-maintainers.md b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
index c508d41087f..2c3010f18fd 100644
--- a/_articles/fr/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
@@ -76,6 +76,7 @@ Il est important de comprendre les causes de l'épuisement professionnel. Voici
 * **Demandes contradictoires :**  L'open source est un ensemble de groupes aux motivations diverses, dans lequel il peut être difficile de s'y retrouver. Si vous êtes payé pour faire de l'open source, les intérêts de votre employeur peuvent parfois être en contradiction avec ceux de la communauté.
   
 <aside markdown="1" class="pquote">
+  
    Dans le cas des logiciels libres payants, il existe un conflit entre l'objectif de l'employeur et ce qui est le mieux pour la communauté.
   
   <p markdown="1" class="pquote-credit">

From 9f6b22b113102f3fbe929bd9cbe2fe22f5adf01f Mon Sep 17 00:00:00 2001
From: Kpoti Ametepe <patrickametepe@outlook.com>
Date: Tue, 8 Oct 2024 23:50:34 +0000
Subject: [PATCH 734/749] Update
 maintaining-balance-for-open-source-maintainers.md

---
 .../maintaining-balance-for-open-source-maintainers.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/_articles/fr/maintaining-balance-for-open-source-maintainers.md b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
index 2c3010f18fd..1c1e6d98edc 100644
--- a/_articles/fr/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
@@ -102,11 +102,11 @@ Il existe des outils comme la [Burnout Checklist](https://governingopen.com/reso
 
 Cela sera différent pour chaque responsable, et changera en fonction de votre phase de vie et d'autres facteurs externes. Mais voici quelques thèmes que nous avons entendus :
 
-* **Appuyez-vous sur la communauté:**  La délégation et la recherche de collaborateurs peuvent alléger la charge de travail. Le fait d'avoir plusieurs points de contact pour un projet peut vous aider à faire une pause sans vous inquiéter. Entrez en contact avec d'autres mainteneurs et la communauté au sens large, dans des groupes tels que la [Communauté des mainteneurs] (http://maintainers.github.com/). Il peut s'agir d'une excellente ressource pour l'entraide et l'apprentissage.
+* **Appuyez-vous sur la communauté:**  La délégation et la recherche de collaborateurs peuvent alléger la charge de travail. Le fait d'avoir plusieurs points de contact pour un projet peut vous aider à faire une pause sans vous inquiéter. Entrez en contact avec d'autres mainteneurs et la communauté au sens large, dans des groupes tels que la [Communauté des mainteneurs](http://maintainers.github.com/). Il peut s'agir d'une excellente ressource pour l'entraide et l'apprentissage.
 
   Vous pouvez également chercher des moyens de vous engager auprès de la communauté des utilisateurs, afin d'obtenir régulièrement des informations en retour et de comprendre l'impact de votre travail sur les logiciels libres.
 
-* **Explorer le financement :** Que vous soyez à la recherche d'un peu d'argent pour une pizza ou que vous essayiez de vous lancer à plein temps dans l'open source, il existe de nombreuses ressources pour vous aider ! Dans un premier temps, pensez à activer [GitHub Sponsors] (https://github.com/sponsors) pour permettre à d'autres de sponsoriser votre travail open source. Si vous envisagez de passer à temps plein, postulez pour le prochain cycle de l'[Accélérateur GitHub] (http://accelerator.github.com/).
+* **Explorer le financement :** Que vous soyez à la recherche d'un peu d'argent pour une pizza ou que vous essayiez de vous lancer à plein temps dans l'open source, il existe de nombreuses ressources pour vous aider ! Dans un premier temps, pensez à activer [GitHub Sponsors](https://github.com/sponsors) pour permettre à d'autres de sponsoriser votre travail open source. Si vous envisagez de passer à temps plein, postulez pour le prochain cycle de l'[Accélérateur GitHub](http://accelerator.github.com/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
@@ -116,7 +116,7 @@ Cela sera différent pour chaque responsable, et changera en fonction de votre p
   </p>
 </aside>
 
-* **Utilisez les outils:** Profitez d'outils tels que [GitHub Copilot] (https://github.com/features/copilot/) et [GitHub Actions] (https://github.com/features/actions) pour automatiser les tâches banales et libérer votre temps pour des contributions plus significatives.
+* **Utilisez les outils:** Profitez d'outils tels que [GitHub Copilot](https://github.com/features/copilot/) et [GitHub Actions](https://github.com/features/actions) pour automatiser les tâches banales et libérer votre temps pour des contributions plus significatives.
 
 <aside markdown="1" class="pquote">
  Utilisez [Copilot](https://github.com/features/copilot/) pour les choses ennuyeuses - faites les choses amusantes.
@@ -126,7 +126,7 @@ Cela sera différent pour chaque responsable, et changera en fonction de votre p
   </p>
 </aside>
 
-* **Se reposer et se ressourcer :** Consacrez du temps à vos loisirs et à vos centres d'intérêt en dehors de l'open source. Prenez vos week-ends pour vous détendre et vous ressourcer, et réglez votre [statut GitHub] (https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) pour qu'il reflète votre disponibilité ! Une bonne nuit de sommeil peut faire une grande différence dans votre capacité à soutenir vos efforts à long terme.
+* **Se reposer et se ressourcer :** Consacrez du temps à vos loisirs et à vos centres d'intérêt en dehors de l'open source. Prenez vos week-ends pour vous détendre et vous ressourcer, et réglez votre [statut GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) pour qu'il reflète votre disponibilité ! Une bonne nuit de sommeil peut faire une grande différence dans votre capacité à soutenir vos efforts à long terme.
 Si certains aspects de votre projet vous plaisent particulièrement, essayez de structurer votre travail de manière à en faire l'expérience tout au long de la journée.
 
 <aside markdown="1" class="pquote">
@@ -145,7 +145,7 @@ Si certains aspects de votre projet vous plaisent particulièrement, essayez de
 Pour faire confiance aux autres sur ces axes, vous ne pouvez pas être quelqu'un qui dit oui à toutes les demandes. Ce faisant, vous ne respectez aucune limite, ni sur le plan professionnel ni sur le plan personnel, et vous ne serez pas un collègue fiable.
   
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, mainteneur de Homebrew sur [Saying No] (https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, mainteneur de Homebrew sur [Saying No](https://mikemcquaid.com/saying-no/)
   </p>
 </aside>
 

From 037272ecff39dba956e2129035503a16af4415a7 Mon Sep 17 00:00:00 2001
From: Kpoti Ametepe <patrickametepe@outlook.com>
Date: Tue, 8 Oct 2024 23:55:39 +0000
Subject: [PATCH 735/749] Update
 maintaining-balance-for-open-source-maintainers.md

---
 _articles/fr/maintaining-balance-for-open-source-maintainers.md | 2 --
 1 file changed, 2 deletions(-)

diff --git a/_articles/fr/maintaining-balance-for-open-source-maintainers.md b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
index 1c1e6d98edc..66f76c8e497 100644
--- a/_articles/fr/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
@@ -76,9 +76,7 @@ Il est important de comprendre les causes de l'épuisement professionnel. Voici
 * **Demandes contradictoires :**  L'open source est un ensemble de groupes aux motivations diverses, dans lequel il peut être difficile de s'y retrouver. Si vous êtes payé pour faire de l'open source, les intérêts de votre employeur peuvent parfois être en contradiction avec ceux de la communauté.
   
 <aside markdown="1" class="pquote">
-  
    Dans le cas des logiciels libres payants, il existe un conflit entre l'objectif de l'employeur et ce qui est le mieux pour la communauté.
-  
   <p markdown="1" class="pquote-credit">
 — Un Mainteneur Open Source
   </p>

From d71efd8d3578d210ceaee0ce5825bc5f35b28cd6 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 18 Oct 2024 04:14:48 +0000
Subject: [PATCH 736/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.196.0 to 1.197.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/f26937343756480a8cb3ae1f623b9c8d89ed6984...7bae1d00b5db9166f4f0fc47985a3a5702cb58f0)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 642f9a71835..94d577c08c0 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -13,7 +13,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@f26937343756480a8cb3ae1f623b9c8d89ed6984 # v1
+        uses: ruby/setup-ruby@7bae1d00b5db9166f4f0fc47985a3a5702cb58f0 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 251ef139fc6f079dc89052e9c429edd4eccbf5f1 Mon Sep 17 00:00:00 2001
From: jmeridth <jmeridth@gmail.com>
Date: Sun, 20 Oct 2024 11:43:50 -0500
Subject: [PATCH 737/749] fix: add readwrite url to ignored urls to pass CI

Will look into why this is 403ing but we need to unblock other PRs

Signed-off-by: jmeridth <jmeridth@gmail.com>
---
 script/html-proofer | 1 +
 1 file changed, 1 insertion(+)

diff --git a/script/html-proofer b/script/html-proofer
index f634cc1db80..4187f49b2f1 100755
--- a/script/html-proofer
+++ b/script/html-proofer
@@ -9,6 +9,7 @@ url_ignores = [
   "https://scripts.sil.org/ofl",
   "https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/",
   "https://pages.18f.gov/open-source-guide/making-readmes-readable/",
+  %r{^https?://readwrite\.com/2014/10/10/open-source-diversity-how-to-contribute/},
   %r{^https?://twitter\.com/},
   %r{^https?://(www\.)?kickstarter\.com/},
   %r{^https://guides\.github\.com/},

From c591be94d5c14d428f190e59324d1a5b52f8aa9f Mon Sep 17 00:00:00 2001
From: jmeridth <jmeridth@gmail.com>
Date: Fri, 18 Oct 2024 22:25:55 -0500
Subject: [PATCH 738/749] chore: upgrade to latest jekyll and ruby

- [x] latest jekyll
- [x] ruby 3.3.5
- [x] devcontainer setup also
  - allows us to work in environment matching prod
  - was getting errorlocally when trying to run bundle install, this is easier IMO
- [x] update dependabot config for npm
- [x] removed Gemfile.lock from .gitignore so dependabot can actually issue gem updates

Signed-off-by: jmeridth <jmeridth@gmail.com>
---
 .devcontainer/devcontainer.json |  19 ++
 .github/dependabot.yml          |   4 -
 .gitignore                      |   1 -
 .ruby-version                   |   2 +-
 Gemfile                         |   2 +-
 Gemfile.lock                    | 347 ++++++++++++++++++++++++++++++++
 6 files changed, 368 insertions(+), 7 deletions(-)
 create mode 100644 .devcontainer/devcontainer.json
 create mode 100644 Gemfile.lock

diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json
new file mode 100644
index 00000000000..94bceb23e12
--- /dev/null
+++ b/.devcontainer/devcontainer.json
@@ -0,0 +1,19 @@
+{
+  "name": "Jekyll website",
+  "image": "mcr.microsoft.com/devcontainers/jekyll:latest",
+  "features": {
+    "ghcr.io/devcontainers/features/node:1": {
+      "version": "22"
+    },
+    "ghcr.io/devcontainers/features/ruby:1": {
+      "version": "3.3.5"
+    }
+  },
+  "forwardPorts": [
+    // Jekyll server
+    4000,
+    // Live reload server
+    35729
+  ],
+  "postCreateCommand": "bundle exec jekyll serve --incremental"
+}
diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index b65eb374905..4655c5304be 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -4,10 +4,6 @@ updates:
     directory: "/"
     schedule:
       interval: daily
-      time: "10:00"
-      timezone: Europe/Vienna
-    pull-request-branch-name:
-      separator: "-"
     open-pull-requests-limit: 99
     rebase-strategy: disabled
     commit-message:
diff --git a/.gitignore b/.gitignore
index 177fab1a1b5..1e32f1a37a4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,4 +10,3 @@ bin
 css/main.scss
 test/node_modules
 test/package-lock.json
-Gemfile.lock
diff --git a/.ruby-version b/.ruby-version
index a3ec5a4bd3d..fa7adc7ac72 100644
--- a/.ruby-version
+++ b/.ruby-version
@@ -1 +1 @@
-3.2
+3.3.5
diff --git a/Gemfile b/Gemfile
index ca9b7428d0e..48663d8fc93 100644
--- a/Gemfile
+++ b/Gemfile
@@ -1,6 +1,6 @@
 source "https://rubygems.org"
 
-gem "github-pages", group: :jekyll_plugins
+gem "github-pages", "~> 232", group: :jekyll_plugins
 
 group :test do
   gem "html-proofer"
diff --git a/Gemfile.lock b/Gemfile.lock
new file mode 100644
index 00000000000..a04883a3dde
--- /dev/null
+++ b/Gemfile.lock
@@ -0,0 +1,347 @@
+GEM
+  remote: https://rubygems.org/
+  specs:
+    Ascii85 (1.1.1)
+    activesupport (7.2.1.1)
+      base64
+      bigdecimal
+      concurrent-ruby (~> 1.0, >= 1.3.1)
+      connection_pool (>= 2.2.5)
+      drb
+      i18n (>= 1.6, < 2)
+      logger (>= 1.4.2)
+      minitest (>= 5.1)
+      securerandom (>= 0.3)
+      tzinfo (~> 2.0, >= 2.0.5)
+    addressable (2.8.7)
+      public_suffix (>= 2.0.2, < 7.0)
+    afm (0.2.2)
+    async (2.17.0)
+      console (~> 1.26)
+      fiber-annotation
+      io-event (~> 1.6, >= 1.6.5)
+    base64 (0.2.0)
+    bigdecimal (3.1.8)
+    coffee-script (2.4.1)
+      coffee-script-source
+      execjs
+    coffee-script-source (1.12.2)
+    colorator (1.1.0)
+    commonmarker (0.23.10)
+    concurrent-ruby (1.3.4)
+    connection_pool (2.4.1)
+    console (1.27.0)
+      fiber-annotation
+      fiber-local (~> 1.1)
+      json
+    csv (3.3.0)
+    dnsruby (1.72.2)
+      simpleidn (~> 0.2.1)
+    drb (2.2.1)
+    em-websocket (0.5.3)
+      eventmachine (>= 0.12.9)
+      http_parser.rb (~> 0)
+    ethon (0.16.0)
+      ffi (>= 1.15.0)
+    eventmachine (1.2.7)
+    execjs (2.9.1)
+    faraday (2.12.0)
+      faraday-net_http (>= 2.0, < 3.4)
+      json
+      logger
+    faraday-net_http (3.3.0)
+      net-http
+    ffi (1.17.0-aarch64-linux-gnu)
+    ffi (1.17.0-aarch64-linux-musl)
+    ffi (1.17.0-arm-linux-gnu)
+    ffi (1.17.0-arm-linux-musl)
+    ffi (1.17.0-arm64-darwin)
+    ffi (1.17.0-x86-linux-gnu)
+    ffi (1.17.0-x86-linux-musl)
+    ffi (1.17.0-x86_64-darwin)
+    ffi (1.17.0-x86_64-linux-gnu)
+    ffi (1.17.0-x86_64-linux-musl)
+    fiber-annotation (0.2.0)
+    fiber-local (1.1.0)
+      fiber-storage
+    fiber-storage (1.0.0)
+    forwardable-extended (2.6.0)
+    gemoji (4.1.0)
+    github-pages (232)
+      github-pages-health-check (= 1.18.2)
+      jekyll (= 3.10.0)
+      jekyll-avatar (= 0.8.0)
+      jekyll-coffeescript (= 1.2.2)
+      jekyll-commonmark-ghpages (= 0.5.1)
+      jekyll-default-layout (= 0.1.5)
+      jekyll-feed (= 0.17.0)
+      jekyll-gist (= 1.5.0)
+      jekyll-github-metadata (= 2.16.1)
+      jekyll-include-cache (= 0.2.1)
+      jekyll-mentions (= 1.6.0)
+      jekyll-optional-front-matter (= 0.3.2)
+      jekyll-paginate (= 1.1.0)
+      jekyll-readme-index (= 0.3.0)
+      jekyll-redirect-from (= 0.16.0)
+      jekyll-relative-links (= 0.6.1)
+      jekyll-remote-theme (= 0.4.3)
+      jekyll-sass-converter (= 1.5.2)
+      jekyll-seo-tag (= 2.8.0)
+      jekyll-sitemap (= 1.4.0)
+      jekyll-swiss (= 1.0.0)
+      jekyll-theme-architect (= 0.2.0)
+      jekyll-theme-cayman (= 0.2.0)
+      jekyll-theme-dinky (= 0.2.0)
+      jekyll-theme-hacker (= 0.2.0)
+      jekyll-theme-leap-day (= 0.2.0)
+      jekyll-theme-merlot (= 0.2.0)
+      jekyll-theme-midnight (= 0.2.0)
+      jekyll-theme-minimal (= 0.2.0)
+      jekyll-theme-modernist (= 0.2.0)
+      jekyll-theme-primer (= 0.6.0)
+      jekyll-theme-slate (= 0.2.0)
+      jekyll-theme-tactile (= 0.2.0)
+      jekyll-theme-time-machine (= 0.2.0)
+      jekyll-titles-from-headings (= 0.5.3)
+      jemoji (= 0.13.0)
+      kramdown (= 2.4.0)
+      kramdown-parser-gfm (= 1.1.0)
+      liquid (= 4.0.4)
+      mercenary (~> 0.3)
+      minima (= 2.5.1)
+      nokogiri (>= 1.16.2, < 2.0)
+      rouge (= 3.30.0)
+      terminal-table (~> 1.4)
+      webrick (~> 1.8)
+    github-pages-health-check (1.18.2)
+      addressable (~> 2.3)
+      dnsruby (~> 1.60)
+      octokit (>= 4, < 8)
+      public_suffix (>= 3.0, < 6.0)
+      typhoeus (~> 1.3)
+    hashery (2.1.2)
+    html-pipeline (2.14.3)
+      activesupport (>= 2)
+      nokogiri (>= 1.4)
+    html-proofer (5.0.9)
+      addressable (~> 2.3)
+      async (~> 2.1)
+      nokogiri (~> 1.13)
+      pdf-reader (~> 2.11)
+      rainbow (~> 3.0)
+      typhoeus (~> 1.3)
+      yell (~> 2.0)
+      zeitwerk (~> 2.5)
+    http_parser.rb (0.8.0)
+    i18n (1.14.6)
+      concurrent-ruby (~> 1.0)
+    io-event (1.7.2)
+    jekyll (3.10.0)
+      addressable (~> 2.4)
+      colorator (~> 1.0)
+      csv (~> 3.0)
+      em-websocket (~> 0.5)
+      i18n (>= 0.7, < 2)
+      jekyll-sass-converter (~> 1.0)
+      jekyll-watch (~> 2.0)
+      kramdown (>= 1.17, < 3)
+      liquid (~> 4.0)
+      mercenary (~> 0.3.3)
+      pathutil (~> 0.9)
+      rouge (>= 1.7, < 4)
+      safe_yaml (~> 1.0)
+      webrick (>= 1.0)
+    jekyll-avatar (0.8.0)
+      jekyll (>= 3.0, < 5.0)
+    jekyll-coffeescript (1.2.2)
+      coffee-script (~> 2.2)
+      coffee-script-source (~> 1.12)
+    jekyll-commonmark (1.4.0)
+      commonmarker (~> 0.22)
+    jekyll-commonmark-ghpages (0.5.1)
+      commonmarker (>= 0.23.7, < 1.1.0)
+      jekyll (>= 3.9, < 4.0)
+      jekyll-commonmark (~> 1.4.0)
+      rouge (>= 2.0, < 5.0)
+    jekyll-default-layout (0.1.5)
+      jekyll (>= 3.0, < 5.0)
+    jekyll-feed (0.17.0)
+      jekyll (>= 3.7, < 5.0)
+    jekyll-gist (1.5.0)
+      octokit (~> 4.2)
+    jekyll-github-metadata (2.16.1)
+      jekyll (>= 3.4, < 5.0)
+      octokit (>= 4, < 7, != 4.4.0)
+    jekyll-include-cache (0.2.1)
+      jekyll (>= 3.7, < 5.0)
+    jekyll-mentions (1.6.0)
+      html-pipeline (~> 2.3)
+      jekyll (>= 3.7, < 5.0)
+    jekyll-optional-front-matter (0.3.2)
+      jekyll (>= 3.0, < 5.0)
+    jekyll-paginate (1.1.0)
+    jekyll-readme-index (0.3.0)
+      jekyll (>= 3.0, < 5.0)
+    jekyll-redirect-from (0.16.0)
+      jekyll (>= 3.3, < 5.0)
+    jekyll-relative-links (0.6.1)
+      jekyll (>= 3.3, < 5.0)
+    jekyll-remote-theme (0.4.3)
+      addressable (~> 2.0)
+      jekyll (>= 3.5, < 5.0)
+      jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0)
+      rubyzip (>= 1.3.0, < 3.0)
+    jekyll-sass-converter (1.5.2)
+      sass (~> 3.4)
+    jekyll-seo-tag (2.8.0)
+      jekyll (>= 3.8, < 5.0)
+    jekyll-sitemap (1.4.0)
+      jekyll (>= 3.7, < 5.0)
+    jekyll-swiss (1.0.0)
+    jekyll-theme-architect (0.2.0)
+      jekyll (> 3.5, < 5.0)
+      jekyll-seo-tag (~> 2.0)
+    jekyll-theme-cayman (0.2.0)
+      jekyll (> 3.5, < 5.0)
+      jekyll-seo-tag (~> 2.0)
+    jekyll-theme-dinky (0.2.0)
+      jekyll (> 3.5, < 5.0)
+      jekyll-seo-tag (~> 2.0)
+    jekyll-theme-hacker (0.2.0)
+      jekyll (> 3.5, < 5.0)
+      jekyll-seo-tag (~> 2.0)
+    jekyll-theme-leap-day (0.2.0)
+      jekyll (> 3.5, < 5.0)
+      jekyll-seo-tag (~> 2.0)
+    jekyll-theme-merlot (0.2.0)
+      jekyll (> 3.5, < 5.0)
+      jekyll-seo-tag (~> 2.0)
+    jekyll-theme-midnight (0.2.0)
+      jekyll (> 3.5, < 5.0)
+      jekyll-seo-tag (~> 2.0)
+    jekyll-theme-minimal (0.2.0)
+      jekyll (> 3.5, < 5.0)
+      jekyll-seo-tag (~> 2.0)
+    jekyll-theme-modernist (0.2.0)
+      jekyll (> 3.5, < 5.0)
+      jekyll-seo-tag (~> 2.0)
+    jekyll-theme-primer (0.6.0)
+      jekyll (> 3.5, < 5.0)
+      jekyll-github-metadata (~> 2.9)
+      jekyll-seo-tag (~> 2.0)
+    jekyll-theme-slate (0.2.0)
+      jekyll (> 3.5, < 5.0)
+      jekyll-seo-tag (~> 2.0)
+    jekyll-theme-tactile (0.2.0)
+      jekyll (> 3.5, < 5.0)
+      jekyll-seo-tag (~> 2.0)
+    jekyll-theme-time-machine (0.2.0)
+      jekyll (> 3.5, < 5.0)
+      jekyll-seo-tag (~> 2.0)
+    jekyll-titles-from-headings (0.5.3)
+      jekyll (>= 3.3, < 5.0)
+    jekyll-watch (2.2.1)
+      listen (~> 3.0)
+    jemoji (0.13.0)
+      gemoji (>= 3, < 5)
+      html-pipeline (~> 2.2)
+      jekyll (>= 3.0, < 5.0)
+    json (2.7.2)
+    kramdown (2.4.0)
+      rexml
+    kramdown-parser-gfm (1.1.0)
+      kramdown (~> 2.0)
+    liquid (4.0.4)
+    listen (3.9.0)
+      rb-fsevent (~> 0.10, >= 0.10.3)
+      rb-inotify (~> 0.9, >= 0.9.10)
+    logger (1.6.1)
+    mercenary (0.3.6)
+    minima (2.5.1)
+      jekyll (>= 3.5, < 5.0)
+      jekyll-feed (~> 0.9)
+      jekyll-seo-tag (~> 2.1)
+    minitest (5.25.1)
+    net-http (0.4.1)
+      uri
+    nokogiri (1.16.7-aarch64-linux)
+      racc (~> 1.4)
+    nokogiri (1.16.7-arm-linux)
+      racc (~> 1.4)
+    nokogiri (1.16.7-arm64-darwin)
+      racc (~> 1.4)
+    nokogiri (1.16.7-x86-linux)
+      racc (~> 1.4)
+    nokogiri (1.16.7-x86_64-darwin)
+      racc (~> 1.4)
+    nokogiri (1.16.7-x86_64-linux)
+      racc (~> 1.4)
+    octokit (4.25.1)
+      faraday (>= 1, < 3)
+      sawyer (~> 0.9)
+    pathutil (0.16.2)
+      forwardable-extended (~> 2.6)
+    pdf-reader (2.12.0)
+      Ascii85 (~> 1.0)
+      afm (~> 0.2.1)
+      hashery (~> 2.0)
+      ruby-rc4
+      ttfunk
+    public_suffix (5.1.1)
+    racc (1.8.1)
+    rainbow (3.1.1)
+    rake (13.2.1)
+    rb-fsevent (0.11.2)
+    rb-inotify (0.11.1)
+      ffi (~> 1.0)
+    rexml (3.3.8)
+    rouge (3.30.0)
+    ruby-rc4 (0.1.5)
+    rubyzip (2.3.2)
+    safe_yaml (1.0.5)
+    sass (3.7.4)
+      sass-listen (~> 4.0.0)
+    sass-listen (4.0.0)
+      rb-fsevent (~> 0.9, >= 0.9.4)
+      rb-inotify (~> 0.9, >= 0.9.7)
+    sawyer (0.9.2)
+      addressable (>= 2.3.5)
+      faraday (>= 0.17.3, < 3)
+    securerandom (0.3.1)
+    simpleidn (0.2.3)
+    terminal-table (1.8.0)
+      unicode-display_width (~> 1.1, >= 1.1.1)
+    ttfunk (1.8.0)
+      bigdecimal (~> 3.1)
+    typhoeus (1.4.1)
+      ethon (>= 0.9.0)
+    tzinfo (2.0.6)
+      concurrent-ruby (~> 1.0)
+    unicode-display_width (1.8.0)
+    uri (0.13.1)
+    webrick (1.8.2)
+    yell (2.2.2)
+    zeitwerk (2.7.1)
+
+PLATFORMS
+  aarch64-linux-gnu
+  aarch64-linux-musl
+  arm-linux
+  arm-linux-gnu
+  arm-linux-musl
+  arm64-darwin
+  x86-linux
+  x86-linux-gnu
+  x86-linux-musl
+  x86_64-darwin
+  x86_64-linux
+  x86_64-linux-gnu
+  x86_64-linux-musl
+
+DEPENDENCIES
+  github-pages (~> 232)
+  html-proofer
+  rake
+
+BUNDLED WITH
+   2.5.19

From 96c8196a624c57939f708dffa0974f68f9b4cb84 Mon Sep 17 00:00:00 2001
From: jmeridth <jmeridth@gmail.com>
Date: Tue, 22 Oct 2024 08:38:40 -0500
Subject: [PATCH 739/749] fix: use deploy environment for build job and replace
 ref with sha to prevent TOCTOU

based on feedback from security folks

Signed-off-by: jmeridth <jmeridth@gmail.com>
Co-authored-by: Kylie Stradley <4666485+KyFaSt@users.noreply.github.com>
---
 .github/workflows/jekyll-preview.yml | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index e9173b89f82..bf756705105 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -17,11 +17,13 @@ permissions:
 # Allow only one concurrent deployment per PR, skipping runs queued between the run in-progress and latest queued.
 # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
 concurrency:
-  group: 'pages-preview @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}'
+  group: "pages-preview @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}"
   cancel-in-progress: false
 jobs:
   # Build job
   build:
+    environment:
+      name: "Pages Preview"
     # Limit permissions of the GITHUB_TOKEN for untrusted code
     permissions:
       contents: read
@@ -31,7 +33,7 @@ jobs:
         uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 # v4
         with:
           # For PRs make sure to checkout the PR branch
-          ref: ${{ github.event.pull_request.head.ref }}
+          ref: ${{ github.event.pull_request.head.sha }}
           repository: ${{ github.event.pull_request.head.repo.full_name }}
       - name: Setup Pages
         uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5
@@ -46,7 +48,7 @@ jobs:
   # Deployment job
   deploy:
     environment:
-      name: 'Pages Preview'
+      name: "Pages Preview"
       url: ${{ steps.deployment.outputs.page_url }}
     # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
     permissions:
@@ -60,4 +62,4 @@ jobs:
         id: deployment
         uses: actions/deploy-pages@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4
         with:
-          preview: 'true'
+          preview: "true"

From 5bcc4e2c57b804e2256f8ac8186c462bc4601936 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 24 Oct 2024 05:01:07 +0000
Subject: [PATCH 740/749] chore(deps): bump actions/checkout in the
 dependencies group

Bumps the dependencies group with 1 update: [actions/checkout](https://github.com/actions/checkout).


Updates `actions/checkout` from 4.2.1 to 4.2.2
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871...11bd71901bbe5b1630ceea73d27597364c9af683)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/jekyll-preview.yml | 2 +-
 .github/workflows/jekyll.yml         | 2 +-
 .github/workflows/tests.yml          | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml
index bf756705105..f281aed4ff2 100644
--- a/.github/workflows/jekyll-preview.yml
+++ b/.github/workflows/jekyll-preview.yml
@@ -30,7 +30,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 # v4
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
         with:
           # For PRs make sure to checkout the PR branch
           ref: ${{ github.event.pull_request.head.sha }}
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
index 6a0e0063a5d..8fcab6dbb40 100644
--- a/.github/workflows/jekyll.yml
+++ b/.github/workflows/jekyll.yml
@@ -27,7 +27,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 # v4
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
       - name: Setup Pages
         uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5
       - name: Build with Jekyll
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 94d577c08c0..8dab89e9308 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -11,7 +11,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Git repository
-        uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 # v4
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
       - name: Set up Ruby
         uses: ruby/setup-ruby@7bae1d00b5db9166f4f0fc47985a3a5702cb58f0 # v1
         with:

From 41a44e19c812dfa7b18814aee7ba23dfc367f562 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 25 Oct 2024 04:41:33 +0000
Subject: [PATCH 741/749] chore(deps): bump actions/setup-node in the
 dependencies group

Bumps the dependencies group with 1 update: [actions/setup-node](https://github.com/actions/setup-node).


Updates `actions/setup-node` from 4.0.4 to 4.1.0
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/0a44ba7841725637a19e28fa30b79a866c81b0a6...39370e3970a6d050c480ffad4ff0ed4d3fdee5af)

---
updated-dependencies:
- dependency-name: actions/setup-node
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 8dab89e9308..9b8dd0deb9e 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -17,7 +17,7 @@ jobs:
         with:
           bundler-cache: true
       - name: Set up Node
-        uses: actions/setup-node@0a44ba7841725637a19e28fa30b79a866c81b0a6 # v4
+        uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4
       - name: Bootstrap
         run: script/bootstrap
         env:

From d9f5f8c94bcd485f1a6617814938ed3d70f89c16 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 28 Oct 2024 19:09:15 +0000
Subject: [PATCH 742/749] chore(deps): bump rexml from 3.3.8 to 3.3.9 in the
 bundler group

Bumps the bundler group with 1 update: [rexml](https://github.com/ruby/rexml).


Updates `rexml` from 3.3.8 to 3.3.9
- [Release notes](https://github.com/ruby/rexml/releases)
- [Changelog](https://github.com/ruby/rexml/blob/master/NEWS.md)
- [Commits](https://github.com/ruby/rexml/compare/v3.3.8...v3.3.9)

---
updated-dependencies:
- dependency-name: rexml
  dependency-type: indirect
  dependency-group: bundler
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 Gemfile.lock | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index a04883a3dde..9325fdd0501 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -294,7 +294,7 @@ GEM
     rb-fsevent (0.11.2)
     rb-inotify (0.11.1)
       ffi (~> 1.0)
-    rexml (3.3.8)
+    rexml (3.3.9)
     rouge (3.30.0)
     ruby-rc4 (0.1.5)
     rubyzip (2.3.2)

From 2b9f5905df771a5a411bbc1c8579d1950595cee0 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 31 Oct 2024 04:11:53 +0000
Subject: [PATCH 743/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.197.0 to 1.198.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/7bae1d00b5db9166f4f0fc47985a3a5702cb58f0...98aefb3c83eea830993080938ed245dc8e2b843b)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 9b8dd0deb9e..e6282aa03d4 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -13,7 +13,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@7bae1d00b5db9166f4f0fc47985a3a5702cb58f0 # v1
+        uses: ruby/setup-ruby@98aefb3c83eea830993080938ed245dc8e2b843b # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 49df6d12144690507bb7661fb557f7699c5dbcec Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 1 Nov 2024 04:40:40 +0000
Subject: [PATCH 744/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.198.0 to 1.199.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/98aefb3c83eea830993080938ed245dc8e2b843b...7d3497fd78c07c0d84ebafa58d8dac60cd1f0763)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index e6282aa03d4..d4e63437aca 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -13,7 +13,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@98aefb3c83eea830993080938ed245dc8e2b843b # v1
+        uses: ruby/setup-ruby@7d3497fd78c07c0d84ebafa58d8dac60cd1f0763 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 1195ea1f0cf181661e5213cc13b87161e91ab704 Mon Sep 17 00:00:00 2001
From: "JM (Jason Meridth)" <jmeridth@gmail.com>
Date: Fri, 1 Nov 2024 08:22:12 -0500
Subject: [PATCH 745/749] fix: add newline to fix warning

To fix warning in CI

```
_articles/fr/maintaining-balance-for-open-source-maintainers.md
  78:1-83:9  warning  Missing blank line before block node  no-missing-blank-lines  remark-lint
```
---
 .../fr/maintaining-balance-for-open-source-maintainers.md      | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/_articles/fr/maintaining-balance-for-open-source-maintainers.md b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
index 66f76c8e497..65c2b5ffd9b 100644
--- a/_articles/fr/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
@@ -76,7 +76,8 @@ Il est important de comprendre les causes de l'épuisement professionnel. Voici
 * **Demandes contradictoires :**  L'open source est un ensemble de groupes aux motivations diverses, dans lequel il peut être difficile de s'y retrouver. Si vous êtes payé pour faire de l'open source, les intérêts de votre employeur peuvent parfois être en contradiction avec ceux de la communauté.
   
 <aside markdown="1" class="pquote">
-   Dans le cas des logiciels libres payants, il existe un conflit entre l'objectif de l'employeur et ce qui est le mieux pour la communauté.
+  Dans le cas des logiciels libres payants, il existe un conflit entre l'objectif de l'employeur et ce qui est le mieux pour la communauté.
+  
   <p markdown="1" class="pquote-credit">
 — Un Mainteneur Open Source
   </p>

From efe819da560785e594f6c92868ac491e42c51816 Mon Sep 17 00:00:00 2001
From: "JM (Jason Meridth)" <jmeridth@gmail.com>
Date: Fri, 1 Nov 2024 08:47:30 -0500
Subject: [PATCH 746/749] fix: remove whitespace

---
 _articles/fr/maintaining-balance-for-open-source-maintainers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_articles/fr/maintaining-balance-for-open-source-maintainers.md b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
index 65c2b5ffd9b..c9767d2016c 100644
--- a/_articles/fr/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
@@ -74,7 +74,7 @@ Il est important de comprendre les causes de l'épuisement professionnel. Voici
 </aside>
 
 * **Demandes contradictoires :**  L'open source est un ensemble de groupes aux motivations diverses, dans lequel il peut être difficile de s'y retrouver. Si vous êtes payé pour faire de l'open source, les intérêts de votre employeur peuvent parfois être en contradiction avec ceux de la communauté.
-  
+
 <aside markdown="1" class="pquote">
   Dans le cas des logiciels libres payants, il existe un conflit entre l'objectif de l'employeur et ce qui est le mieux pour la communauté.
   

From 20ff4020b3676d10d4aeb6fdadde07e2a231c8f5 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Wed, 6 Nov 2024 04:49:23 +0000
Subject: [PATCH 747/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.199.0 to 1.200.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/7d3497fd78c07c0d84ebafa58d8dac60cd1f0763...217c988b8c2bf2bacb2d5c78a7e7b18f8c34daed)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index d4e63437aca..37b8c59c743 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -13,7 +13,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@7d3497fd78c07c0d84ebafa58d8dac60cd1f0763 # v1
+        uses: ruby/setup-ruby@217c988b8c2bf2bacb2d5c78a7e7b18f8c34daed # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 8eb9c3c6c6c0e706b945a6014c70236b2aeb4c59 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Fri, 8 Nov 2024 04:28:11 +0000
Subject: [PATCH 748/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.200.0 to 1.201.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/217c988b8c2bf2bacb2d5c78a7e7b18f8c34daed...46ca53beb334a2329bcd0e46a694816a6ae6d173)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index 37b8c59c743..c453f3fe030 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -13,7 +13,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@217c988b8c2bf2bacb2d5c78a7e7b18f8c34daed # v1
+        uses: ruby/setup-ruby@46ca53beb334a2329bcd0e46a694816a6ae6d173 # v1
         with:
           bundler-cache: true
       - name: Set up Node

From 07503adb45b5d9ff3748ed66583440937479c746 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 11 Nov 2024 04:05:09 +0000
Subject: [PATCH 749/749] chore(deps): bump ruby/setup-ruby in the dependencies
 group

Bumps the dependencies group with 1 update: [ruby/setup-ruby](https://github.com/ruby/setup-ruby).


Updates `ruby/setup-ruby` from 1.201.0 to 1.202.0
- [Release notes](https://github.com/ruby/setup-ruby/releases)
- [Changelog](https://github.com/ruby/setup-ruby/blob/master/release.rb)
- [Commits](https://github.com/ruby/setup-ruby/compare/46ca53beb334a2329bcd0e46a694816a6ae6d173...a2bbe5b1b236842c1cb7dd11e8e3b51e0a616acc)

---
updated-dependencies:
- dependency-name: ruby/setup-ruby
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
---
 .github/workflows/tests.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index c453f3fe030..772e432a791 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -13,7 +13,7 @@ jobs:
       - name: Set up Git repository
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
       - name: Set up Ruby
-        uses: ruby/setup-ruby@46ca53beb334a2329bcd0e46a694816a6ae6d173 # v1
+        uses: ruby/setup-ruby@a2bbe5b1b236842c1cb7dd11e8e3b51e0a616acc # v1
         with:
           bundler-cache: true
       - name: Set up Node